450-SNUG

450 / Exploration and Space Communications Projects Division

Space Network Users Guide (SNUG)

Publication Date: August 2007 Expiration Date: August 2012 Revision 9

National Aeronautics and Space Administration

Goddard Space Flight Center Greenbelt, Maryland

CHECK THE GSFC CENTRALIZED CONFIGURATION MANAGEMENT SYSTEM AT: http://gdms.gsfc.nasa.gov PRIOR TO USE TO VERIFY THAT THIS IS THE CORRECT VERSION

This page intentionally left blank.

Revision 9

ii

450-SNUG

This page intentionally left blank.

Revision 9

iv

450-SNUG

Preface
The Space Network Users Guide (SNUG) is intended as a guide to the customer community for obtaining communication support from the National Aeronautics and Space Administration (NASA) Space Network (SN). The emphasis in the SNUG is on the interfaces between the customer and the SN. This document is under the configuration management of the Goddard Space Flight Center (GSFC) Exploration and Space Communications (ESC) Projects Division, Code 450, Configuration Control Board (CCB). Configuration Change Requests (CCRs) to this document shall be submitted to GSFC Code 450 CCB, along with supportive material justifying the proposed change. Changes to this document shall be made by Document Change Notice (DCN) or by complete revision. Questions and proposed changes concerning this document shall be addressed to: RF Interface Manager Exploration and Space Communications Projects Division (ESC), Code 450 Goddard Space Flight Center Greenbelt, Maryland 20771 This document has been placed on the GSFC Centralized Configuration Management System (GSFC/CCMS). The GSFC/CCMS is accessible via the World Wide Web at: http://gdms.gsfc.nasa.gov The Space Network Users Guide is also available via the World Wide Web at the following URL address: http://scp.gsfc.nasa.gov/tdrss/guide.html Public access via the World Wide Web to a number of documents and URL addresses referenced in this document may be restricted. Please contact GSFC Code 450 for assistance with any documents to which SN customer access is denied.

Revision 9

450-SNUG

This page intentionally left blank

Revision 9

vi

450-SNUG

Change Information Page

List of Effective Pages Page Number
Title iii / iv v / vi vii / viii ix / xxiv 1-1 through 1-10 2-1 through 2-14 3-1 through 3-18 4-1 through 4-4 5-1 through 5-44 6-1 through 50 7-1 through 7-52 8-1 through 8-40 9-1 through 9-10 10-1 through 10-50 A-1 through A-48 B-1 through B-24

Issue
Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9

Page Number
C-1 through C-22 D-1 through D-20 E-1 through E-16 F-1 through F-4 G-1 through G-6 H-1 through H-18 I-1 through I-10 J-1 through J-4 K-1 through K-6 L-1 through L-2 M-1 through M-2 N-1 through N-8 O-1 through O-6 P-1 through P-8 Q-1 through Q-6 GL-1 through GL-14

Issue
Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9 Revision 9

Document History Document Number

STDN 101.2 STDN 101.2 STDN 101.2 STDN 101.2 STDN 101.2 STDN 101.2 STDN 101.2 530-SNUG 450-SNUG 450-SNUG

Status/Issue
Original Issue Revision 1 Revision 2 Revision 3 Revision 4 Revision 5 Revision 6 Revision 7 Revision 8 Revision 9

Publication Date
April 1974 September 1974 May 1975 January 1978 January 1980 September 1984 September 1988 November 1995 June 2002 August 2007

CCR Number

452/070 450/303

Revision 9

vii

450-SNUG

This page intentionally left blank

Revision 9

viii

450-SNUG

Table of Contents

Section 1. Introduction ................................................................................................... 1-1 1.1 Purpose and Scope ..................................................................................... 1-1 1.1.1 Purpose ........................................................................................ 1-1 1.1.2 Scope............................................................................................ 1-1 Additional Information .................................................................................. 1-1 Document Organization ............................................................................... 1-1 Reference Documents ................................................................................. 1-5 Reference Web Sites ................................................................................... 1-6

1.2 1.3 1.4 1.5

Section 2. SN Overview .................................................................................................. 2-1 2.1 2.2 General ........................................................................................................ 2-1 Customer Interfaces with the SN ................................................................. 2-1 2.2.1 Customer Commitment Interface .................................................. 2-1 2.2.2 RF Interface .................................................................................. 2-1 2.2.3 Operations Interface ..................................................................... 2-1 Elements of the SN ...................................................................................... 2-1 2.3.1 Space Segment ............................................................................ 2-4 2.3.2 Ground Segment ........................................................................ 2-11 Supporting Elements Outside the SN ........................................................ 2-12

2.3

2.4

Section 3. Services Available to Customers................................................................. 3-1 3.1 3.2 General ........................................................................................................ 3-1 Telecommunications Services ..................................................................... 3-1 3.2.1 MA Service Overview.................................................................... 3-4 3.2.2 SA Service Overview .................................................................... 3-4 3.2.3 Cross-support Service Overview .................................................. 3-9 Tracking and Clock Calibration Services ..................................................... 3-9 Testing Services ........................................................................................ 3-10 Analysis Services....................................................................................... 3-11 3.5.1 Network Loading Analysis Services ............................................ 3-11 3.5.2 Communications Link and Coverage Analysis Services ............. 3-11 3.5.3 Tracking Analysis Services ......................................................... 3-12 Data Distribution/Processing Services and Data Interfaces....................... 3-12 3.6.1 Introduction ................................................................................. 3-12 3.6.2 MDM/IONet................................................................................. 3-12 3.6.3 High Data Rate Service .............................................................. 3-16 3.6.4 Local Interface ............................................................................ 3-16 ix
450-SNUG

3.3 3.4 3.5

3.6

Revision 9

3.6.5 3.6.6 3.6.7 3.6.8

WDISC........................................................................................ 3-16 DAS ............................................................................................ 3-16 IF Services.................................................................................. 3-16 GRGT Constraints ...................................................................... 3-17

Section 4. Obtaining SN Services .................................................................................. 4-1 4.1 4.2 4.3 4.4 4.5 Overview...................................................................................................... 4-1 Authorities and Responsibilities ................................................................... 4-1 Procedures for Obtaining SN Support ......................................................... 4-1 System Reviews .......................................................................................... 4-2 SN Services and Mission Support Documentation ...................................... 4-2 4.5.1 General ......................................................................................... 4-2 4.5.2 Space Transportation System (STS) Documentation ................... 4-2 4.5.3 Configuration Management........................................................... 4-3

Section 5. MA Telecommunications Services .............................................................. 5-1 5.1 General ........................................................................................................ 5-1 5.1.1 Available Services ........................................................................ 5-1 5.1.2 Interface Definition ........................................................................ 5-1 5.1.3 Customer Acquisition Requirements............................................. 5-2 5.1.4 TDRSS Acquisition Support to Customers.................................... 5-2 MA Forward Services................................................................................... 5-2 5.2.1 General ......................................................................................... 5-2 5.2.2 Signal Parameters ........................................................................ 5-3 5.2.3 Communications Services ............................................................ 5-7 5.2.4 Real-Time Configuration Changes................................................ 5-7 5.2.5 Acquisition Scenarios.................................................................. 5-10 MA Return Services ................................................................................... 5-12 5.3.1 General ....................................................................................... 5-12 5.3.2 Signal Parameters ...................................................................... 5-12 5.3.3 Communication Services ............................................................ 5-21 5.3.4 Real-Time Configuration Changes.............................................. 5-31 5.3.5 Acquisition Scenarios.................................................................. 5-33

5.2

5.3

Section 6. SSA Telecommunications Services............................................................. 6-1 6.1 General ........................................................................................................ 6-1 6.1.1 Available Services ........................................................................ 6-1 6.1.2 Interface Definition ........................................................................ 6-1 6.1.3 Customer Acquisition Requirements............................................. 6-2 6.1.4 TDRSS Acquisition Support to Customers.................................... 6-2 SSA Forward Services................................................................................. 6-2 x
450-SNUG

6.2
Revision 9

6.3

6.2.1 General ......................................................................................... 6-2 6.2.2 PSK Signal Parameters ................................................................ 6-3 6.2.3 Phase Modulation (PM) Signal Parameters .................................. 6-8 6.2.4 Communications Services .......................................................... 6-11 6.2.5 Real-Time Configuration Changes.............................................. 6-11 6.2.6 Acquisition Scenarios.................................................................. 6-11 SSA Return Services ................................................................................. 6-16 6.3.1 General ....................................................................................... 6-16 6.3.2 Signal Parameters ...................................................................... 6-17 6.3.3 Communications Services .......................................................... 6-25 6.3.4 Real-Time Configuration Changes.............................................. 6-35 6.3.5 Acquisition Scenarios.................................................................. 6-35 6.3.6 Automated IF Service ................................................................. 6-46

Section 7. KuSA Telecommunications Services .......................................................... 7-1 7.1 General ........................................................................................................ 7-1 7.1.1 Available Services ........................................................................ 7-1 7.1.2 Interface Definition ........................................................................ 7-1 7.1.3 Customer Acquisition Requirements............................................. 7-2 7.1.4 TDRSS Acquisition Support to Customers.................................... 7-2 KuSA Forward Services............................................................................... 7-3 7.2.1 General ......................................................................................... 7-3 7.2.2 Signal Parameters ........................................................................ 7-3 7.2.3 Communications Services ............................................................ 7-8 7.2.4 Real-Time Configuration Changes................................................ 7-8 7.2.5 Acquisition Scenarios.................................................................... 7-9 KuSA Return Services ............................................................................... 7-13 7.3.1 General ....................................................................................... 7-13 7.3.2 Signal Parameters ...................................................................... 7-13 7.3.3 Communications Services .......................................................... 7-22 7.3.4 Real-Time Configuration Changes.............................................. 7-34 7.3.5 Autotrack/Signal Acquisition Scenarios....................................... 7-34 7.3.6 225 MHz IF Service .................................................................... 7-46

7.2

7.3

Section 8. KaSA Telecommunications Services........................................................... 8-1 8.1 General ........................................................................................................ 8-1 8.1.1 Available Services ........................................................................ 8-1 8.1.2 Interface Definition ........................................................................ 8-1 8.1.3 Customer Acquisition Requirements............................................. 8-2 8.1.4 TDRSS Acquisition Support to Customers.................................... 8-2 KaSA Forward Services............................................................................... 8-3 xi

8.2

Revision 9

450-SNUG

8.3

8.2.1 General ......................................................................................... 8-3 8.2.2 Signal Parameters ........................................................................ 8-3 8.2.3 Communications Services ............................................................ 8-8 8.2.4 Real-Time Configuration Changes.............................................. 8-11 8.2.5 Acquisition Scenarios.................................................................. 8-11 KaSA Return Services ............................................................................... 8-12 8.3.1 General ....................................................................................... 8-12 8.3.2 Signal Parameters ...................................................................... 8-13 8.3.3 Communications Services .......................................................... 8-15 8.3.4 Real-Time Configuration Changes.............................................. 8-27 8.3.5 Autotrack/Signal Acquisition Scenarios....................................... 8-27 8.3.6 225 MHz and 650 MHz IF Service .............................................. 8-30

Section 9. Tracking and Clock Calibration Services .................................................... 9-1 9.1 9.2 9.3 9.4 9.5 General ........................................................................................................ 9-1 Range Measurement ................................................................................... 9-3 Doppler Measurement ................................................................................. 9-4 Time Transfer Measurement........................................................................ 9-7 Return Channel Time Delay (RCTD) Measurement .................................... 9-8

Section 10. SN Operations for TDRSS Services ......................................................... 10-1 10.1 Purpose and Scope ................................................................................... 10-1 10.1.1 Purpose ...................................................................................... 10-1 10.1.2 Scope.......................................................................................... 10-1 10.1.3 SN Message Terminology........................................................... 10-1 SN Scheduling Operations......................................................................... 10-3 10.2.1 General ....................................................................................... 10-3 10.2.2 Database Setup .......................................................................... 10-3 10.2.3 NCCDS Scheduling .................................................................... 10-6 10.2.4 MOC/NCCDS Interfaces ........................................................... 10-14 10.2.5 NCCDS/FDF Scheduling Interface ........................................... 10-19 10.2.6 GT/NCCDS Scheduling Interface ............................................. 10-21 10.2.7 NCCDS/NEST Scheduling Interface ......................................... 10-22 SN Real-Time Operations........................................................................ 10-24 10.3.1 General ..................................................................................... 10-24 10.3.2 Real-Time Operations Functional Overview ............................. 10-24 10.3.3 Real-Time Operations Messages ............................................. 10-24 10.3.4 MOC Real Time Interfaces ....................................................... 10-24 Customer Platform Emergency Operations ............................................. 10-47 10.4.1 General ..................................................................................... 10-47 10.4.2 Emergency Scheduling ............................................................. 10-47 xii

10.2

10.3

10.4

Revision 9

450-SNUG

10.4.3

Real-Time Customer Platform Emergency Operations ............. 10-49

Appendices
Appendix A. Example Link Calculations .......................................................................A-1 A.1 A.2 A.3 A.4 General ........................................................................................................ A-1 Customer Platform-to-TDRS-Range ............................................................ A-1 Forward Service Link Calculations............................................................... A-1 Return Service Link Calculations ............................................................... A-11

Appendix B. Functional Configurations for TDRSS Forward and Return Services (with Emphasis on Resolving Customers Data Polarity and I-Q Channel Ambiguities) ....................................................................................................................B-1 B.1 General ........................................................................................................ B-1 B.2 Forward Service........................................................................................... B-1 B.3 Return Service ............................................................................................. B-8 Appendix C. Operational Aspects of Signal and Autotrack Acquisition ....................C-1 C.1 C.2 C.3 C.4 General ........................................................................................................C-1 Key Parameters which Impact Acquisition Sequences and Times ..............C-2 Acquisition Events .......................................................................................C-6 Reacquisition .............................................................................................C-15

Appendix D. Spectrum Considerations.........................................................................D-1 D.1 D.2 D.3 D.4 D.5 D.6 D.7 D.8 D.9 Introduction ..................................................................................................D-1 RF Equipment Licensing..............................................................................D-1 Power Flux Density (PFD) Considerations...................................................D-2 Unwanted Emissions .................................................................................D-11 Frequency Tolerance .................................................................................D-16 Cessation Of Transmissions ......................................................................D-16 Protection Of Deep Space Earth Stations..................................................D-16 Preferred Frequencies for Launch Vehicles...............................................D-18 Additional Applicable Recommendations...................................................D-18

Appendix E. Customer Platform and TDRS Signal Parameter Definitions................. E-1 E.1 E.2 E.3 E.4 E.5
Revision 9

General ........................................................................................................ E-1 Symbol (Data) Asymmetry ........................................................................... E-1 Symbol (Data) Rise Time............................................................................. E-1 Symbol (Data Bit) Jitter and Jitter Rate........................................................ E-2 Phase Imbalance ......................................................................................... E-5 xiii
450-SNUG

E.6 E.7 E.8 E.9 E.10 E.11 E.12 E.13 E.14 E.15 E.16 E.17 E.18 E.19 E.20 E.21 E.22 E.23 E.24 E.25 E.26 E.27 E.28 E.29 E.30 E.31 E.32 E.33 E.34 E.35 E.36 E.37 E.38

Gain Imbalance............................................................................................ E-6 Phase Nonlinearity....................................................................................... E-8 Gain Flatness............................................................................................... E-8 Gain Slope ................................................................................................... E-9 AM/PM ......................................................................................................... E-9 Frequency Stability .................................................................................... E-10 Incidental AM ............................................................................................. E-10 Spurious PM .............................................................................................. E-10 Phase Noise .............................................................................................. E-11 In-band Spurious Outputs .......................................................................... E-11 Out-of-Band Emissions .............................................................................. E-11 I/Q Symbol (Data) Skew ............................................................................ E-12 PN Chip Skew............................................................................................ E-12 PN Chip Asymmetry .................................................................................. E-13 PN Chip Jitter............................................................................................. E-13 PN Chip Rate............................................................................................. E-14 Noncoherent and Coherent Turnaround PN Power Suppression .............. E-14 Antenna-Induced AM ................................................................................. E-14 Antenna-Induced PM ................................................................................. E-14 Axial Ratio.................................................................................................. E-14 Data Rate Tolerance.................................................................................. E-14 Power Ratio Tolerance .............................................................................. E-14 Permissible EIRP Variation........................................................................ E-15 Rate of EIRP Variation............................................................................... E-15 Maximum User EIRP ................................................................................. E-15 Modulation Index Accuracy........................................................................ E-15 Subcarrier Frequency Accuracy................................................................. E-15 Data Transition and Subcarrier Coherency................................................ E-15 Subcarrier Phase Noise ............................................................................. E-15 Maximum Frequency Error of 8.5 MHz Subcarrier..................................... E-15 Minimum EIRP for TDRSS Ku-Band Autotrack.......................................... E-16 Short Term EIRP Stability .......................................................................... E-16 Minimum 3 dB Bandwidth Prior to the Power Amplifier.............................. E-16

Appendix F. Periodic Convolutional Interleaving with a Cover Sequence for Synchronization......................................................................................... F-1 F.1 F.2 General ........................................................................................................ F-1 (30,116) Periodic Convolutional Interleaving ............................................... F-1

Appendix G. Predicted Performance Degradations Due to RFI .................................G-1 G.1 General ........................................................................................................G-1

Revision 9

xiv

450-SNUG

G.2 G.3 G.4 G.5 G.6

Factors Influencing Degradation ..................................................................G-2 Need For Channel Coding and Periodic Convolutional Interleaving ............G-2 SSA RFI Degradation Estimates..................................................................G-3 MA RFI Degradation Estimates ...................................................................G-4 SSA and MA Forward Service RFI Degradation ..........................................G-5

Appendix H. Demand Access System (DAS) ................................................................H-1 H.1 H.2 H.3 Overview and Purpose.................................................................................H-1 Obtaining DAS Services ............................................................................H-13 Customer Interface with the DAS...............................................................H-13

Appendix I. NASA Integrated Services Network (NISN) Services ................................ I-1 I.1 I.2 General ......................................................................................................... I-1 Services Available ........................................................................................ I-1

Appendix J. Customer Constraints for the Expendable Launch Vehicle Class of TDRSS Customers ...................................................................................................... J-1 J.1 General .........................................................................................................J-1 J.2 Customer Constraints ...................................................................................J-1 J.3 Acquisition ....................................................................................................J-3 J.4 Signal Tracking .............................................................................................J-3 J.5 BER Performance .........................................................................................J-3 Appendix K. Use of Reed-Solomon Coding in Conjunction with SN User Services K.1 K.2 K.3 K.4 .....................................................................................................................K-1 General ........................................................................................................ K-1 Concatenated Coding: A (255, 223) Reed-Solomon Outer Code with a Rate 1/2 Convolutional Inner Code ........................................................... K-1 (255, 223) Reed-Solomon Coding (Without Convolutional Coding)............. K-3 Summary ..................................................................................................... K-3

Appendix L. McMurdo TDRSS Relay System (MTRS) .................................................. L-1 L.1 L.2 General ........................................................................................................ L-1 Operational Overview .................................................................................. L-1

Appendix M. South Pole TDRSS Relay (SPTR) and WSC Alternate Relay Terminal (WART) ............................................................................................................ M-1 M.1 General ....................................................................................................... M-1 M.2 Operational Overview ................................................................................. M-1

Revision 9

xv

450-SNUG

Appendix N. Network Test Services ..............................................................................N-1 N.1 N.2 N.3 N.4 N.5 N.6 General ........................................................................................................N-1 Verification Methods ....................................................................................N-1 Test Services Description ............................................................................N-2 Network Test Support Organizations ...........................................................N-3 Determining Required Testing .....................................................................N-4 Test Planning, Scheduling, and Reporting...................................................N-4

Appendix O. Self/Mutual Interference Considerations for New Customers at 2287.5 MHz O.1 O.2 O.3 O.4 .....................................................................................................................O-1 Introduction ..................................................................................................O-1 Interference Study .......................................................................................O-1 Conclusions From Interference Study..........................................................O-3 Effect of Prec Margin on Interference ............................................................O-3

Appendix P. SN Web Services Interface (SWSI) ........................................................... P-1 P.1 P.2 P.3 P.4 P.5 P.6 General ........................................................................................................ P-1 Major System Components.......................................................................... P-2 External Interfaces....................................................................................... P-2 SWSI Features and Operations ................................................................... P-3 Performance Characteristics........................................................................ P-7 Provisions for Safety and Security ............................................................... P-8

Appendix Q. WSC Transmission Control Protocol (TCP)/Internet Protocol (IP) Data Interface Service Capability (WDISC) System......................................................Q-1 Q.1 General ........................................................................................................Q-1 Q.2 General Requirements.................................................................................Q-1 Glossary .GL-1

List of Figures
Figure 2-1. Figure 2-2. Figure 2-3. Figure 2-4. SN Customer RF and Operations Interfaces............................................... 2-2 SN Elements and Interfaces .......................................................................... 2-3 First Generation Tracking and Data Relay Satellite (F1-F7) .......................... 2-5 Second Generation Tracking and Data Relay Satellite (F8-F10 also known as H, I, J) ............................................................................................ 2-6 Figure 2-5. Example Average Line-of-Sight Coverage for LEOFOV ................................ 2-9
Revision 9

xvi

450-SNUG

Example Average Line-of-Sight Coverage for MA PFOV............................... 2-9 Example Average Line-of-Sight Coverage for SA PFOV ............................. 2-10 Example Average Line-of-Sight Coverage for SA EEFOV ........................... 2-10 Telecommunications Services for each SGLT ............................................... 3-8 Data Distribution/Processing Services and Data Interfaces ......................... 3-13 Example SSA Forward Phase Modulation Service Frequency Sweep Profile........................................................................................................... 6-10 Figure 10-1. SN Event Schedule Process .................................................................... 10-12 Figure 10-2. MOC UPS/NCCDS Scheduling Message Exchange ............................... 10-15 Figure 10-3. NCCDS/FDF Scheduling Information Exchange...................................... 10-20 Figure 10-4. NCCDS/GT Data Exchange..................................................................... 10-21 Figure 10-5. NCCDS/NEST Scheduling Data Exchange.............................................. 10-23 Figure A-1. Geometry Depicting Nominal Ranges Used for Example Link Calculations .. A-2 Figure A-2. MA/SMA Forward ADR versus G/T ............................................................... A-5 Figure A-3. SSA Forward ADR versus G/T for F1-F10..................................................... A-6 Figure A-4. KuSA Forward ADR versus G/T (Autotrack for F1-F10) ................................ A-7 Figure A-5. KuSA Forward ADR versus G/T (LEO Program Track for F1-F10) ............... A-8 Figure A-6. KuSA Forward ADR versus G/T (Program Track for F1-F10)........................ A-9 Figure A-7. KaSA Forward ADR versus G/T (F8-F10) ................................................... A-10 Figure A-8. MA DG1 Modes 1, 2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F1-F7).................................... A-13 Figure A-9. SMA DG1 Modes 1, 2, 3I (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))................................. A-14 Figure A-10. SMA DG1 Modes 1, 2, 3I (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10) . A-15 Figure A-11. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))................. A-16 Figure A-12. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10) . A-17 Figure A-13. SMA DG1 Mode 3Q and DG2 (Rate1/3) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))................. A-18 Figure A-14. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10) . A-19 Figure A-15. MA DG1 Modes 1, 2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F1-F7).......................................... A-20 Figure A-16. SMA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot)) ....................... A-21

Figure 2-6. Figure 2-7. Figure 2-8. Figure 3-1. Figure 3-2. Figure 6-1.

Revision 9

xvii

450-SNUG

Figure A-17. SMA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10) ....... A-22 Figure A-18. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot)) ....................... A-23 Figure A-19. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10) ....... A-24 Figure A-20. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot)) ....................... A-25 Figure A-21. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10) ....... A-26 Figure A-22. SSA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-27 Figure A-23. SSA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-28 Figure A-24. SSA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-29 Figure A-25. KuSA Autotrack DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec).............................................. A-30 Figure A-26. KuSA Autotrack DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec) .................................. A-31 Figure A-27. KuSA Autotrack DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec).............................................. A-32 Figure A-28. KuSA Autotrack DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) .................................. A-33 Figure A-29. KuSA LEO Program Track DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec).......................... A-34 Figure A-30. KuSA LEO Program Track DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec) .............. A-35 Figure A-31. KuSA LEO Program Track DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec).......................... A-36 Figure A-32. KuSA LEO Program Track DG1 Mode 3Q and DG2 (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec).......................... A-37 Figure A-33. KuSA Program Track DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec) ................................ A-38 Figure A-34. KuSA Program Track DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec).......................... A-39 Figure A-35. KuSA Program Track DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) ................................ A-40
Revision 9

xviii

450-SNUG

Figure A-36. KuSA Program Track DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec).......................... A-41 Figure A-37. KaSA Autotrack DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-42 Figure A-38. KaSA Autotrack DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-43 Figure A-39. KaSA LEO Program Track DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec).............................................. A-44 Figure A-40. KaSA LEO Program Track DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec).............................................. A-45 Figure A-41. KaSA Program Track DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-46 Figure A-42. KaSA Program Track DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) ............................................................. A-47 Figure A-43. MAR DG1 Modes 1 (Rate 1/2) ADR versus EIRP (LEOFOV for F1-F7).... A-48 Figure B-1. Digital Signal Formats.................................................................................... B-2 Figure B-2. Forward Service End-to-End System Functional Configuration..................... B-3 Figure B-3. TDRSS Functional Configuration for PSK Forward Services......................... B-5 Figure B-4. TDRSS Functional Configuration for PM Forward Services .......................... B-7 Figure B-5. Return Service End-to-End System Functional Configuration ....................... B-8 Figure B-6. Customer Platform Functional Configuration for DG1 and DG2 .................. B-10 Figure B-7. Data Conditioning Operations for DG1 Modes 1 and 2 (I and Q Channels) and DG1 Mode 3 I Channel ........................................................................ B-11 Figure B-8. Data Conditioning Operations for DG1 Mode 3 Q Channel and DG2 (except SQPSK with Alternate I/Q Encoded Symbols) ................................ B-12 Figure B-9. Data Conditioning Operations for DG2 SQPSK with Alternate I/Q Encoded Symbols ....................................................................................................... B-13 Figure B-10. Data Encoders........................................................................................... B-15 Figure C-1. Reacquisition Initiation Logic: Forward Service ..........................................C-19 Figure C-2. Reacquisition Initiation Logic: Return Service ............................................C-20 Figure D-1. Geometry for Determining PFD Conformance...............................................D-6 Figure D-2. ITU-R S.672 Antenna Pattern Recommendation...........................................D-8 Figure D-3. Geometry for the Minimum Angle Between the Pointing Vectors Towards the Horizon and the TDRS ...........................................................................D-10 Figure D-4. Calculation of the Minimum Antenna Angle Between the Pointing Vector to the Horizon and the Pointing Vector to TDRS..........................................D-12 Figure D-5. NTIA OOB Emission Mask for Space Services ...........................................D-13 xix

Revision 9

450-SNUG

Figure D-6. Example of Unfiltered and Filtered BPSK PSDs and NTIA Mask ................D-15 Figure D-7. Spectral Output for NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier ................................................................D-17 Figure D-8. Example of Unfiltered and Filtered 3 Mcps Code with DSN Protection Criteria .........................................................................................................D-17 Figure E-1. Symbol (Data) Rise Time............................................................................... E-2 Figure E-2. Coded and Uncoded Data at 0.01% Jitter ..................................................... E-3 Figure E-3. Uncoded Data at 0.1% Jitter for Rs < 20 MSPS ............................................ E-4 Figure E-4. Uncoded Data at 0.1% Jitter for (20 < Rs < 40) MSPS.................................. E-4 Figure E-5. Uncoded Data at 0.1% Jitter for (40 < Rs < 75) MSPS.................................. E-4 Figure E-6. Uncoded Data at 0.1% Jitter for (75 < Rs < 150) MSPS Coded Data at 0.1% Jitter for (Rs < 150) MSPS .................................................................... E-4 Figure E-7. BPSK Phase Imbalance ................................................................................ E-5 Figure E-8. QPSK Phase Imbalance ................................................................................ E-5 Figure E-9. BPSK Gain Imbalance ................................................................................... E-6 Figure E-10. QPSK Gain Imbalance................................................................................. E-7 Figure E-11. Residual Carrier Gain Imbalance................................................................. E-7 Figure E-12. Phase Nonlinearity ...................................................................................... E-8 Figure E-13. Gain Flatness .............................................................................................. E-8 Figure E-14. Gain Slope................................................................................................... E-9 Figure E-15. AM/PM Definition......................................................................................... E-9 Figure E-16. Description of I/Q Data Skew Assuming QPSK Modulation....................... E-12 Figure E-17. Definition of I/Q PN Code Chip Skew ........................................................ E-13 Figure F-1. Periodic Convolutional Interleaving................................................................ F-3 Figure H-1. DAS Any-TDRS Mode ...................................................................................H-4 Figure H-2. DAS All-TDRS Mode .....................................................................................H-5 Figure H-3. DAS Specific-TDRS Mode.............................................................................H-6 Figure H-4. Simplified DAS Signal Flow .........................................................................H-10 Figure H-5. Generic DAS Acquisition and Transmission Timeline .................................H-14 Figure I-1. NISN/SN Legacy Interfaces ............................................................................. I-3 Figure I-2. NISN/SN WDISC Interfaces............................................................................. I-3 Figure I-3. NISN/SN SWSI Interfaces................................................................................ I-4 Figure I-4. Functional Configuration of High Data Rate System Block Format Description ...................................................................................................... I-5 Figure I-5. NISN/TDRSS Forward Channel Command and Return Telemetry Transmission 4800-Bit Block Format .............................................................. I-7

Revision 9

xx

450-SNUG

Figure K-1. Theoretical Performance of Concatenated, R-S, and Convolutional Coding (from [2]) ........................................................................................................ K-2 Figure L-1. MTRS Data Flow............................................................................................ L-2 Figure M-1. SPTR/WART Data Flow............................................................................... M-2 Figure N-1. SN Baseline Characterization........................................................................N-6 Figure O-1. Average Service Impact Versus Prec Margin, Scenario 1 ..............................O-4 Figure O-2. Average Service Impact Versus Prec Margin, Scenario 2 ..............................O-4 Figure O-3. Average Service Impact Versus Prec Margin, Scenario 4 ..............................O-5 Figure P-1. High Level SWSI Architecture ....................................................................... P-1 Figure Q-1. WDISC Overview ..........................................................................................Q-2 Figure Q-2. NISN/SN Legacy Interfaces ..........................................................................Q-3 Figure Q-3. NISN/SN WDISC Interfaces ..........................................................................Q-4

List of Tables
Document Organization .................................................................................. 1-2 Reference Web Sites ...................................................................................... 1-7 Example of TDRS Constellation Plans ............................................................ 2-7 TDRSS Forward Service Characteristics ........................................................ 3-2 TDRSS Return Service Characteristics........................................................... 3-5 Return Link Data Group and Mode Description............................................... 3-7 Interface Capabilities..................................................................................... 3-14 TDRSS MA Forward PSK Service Signal Parameters .................................... 5-4 TDRSS MA Forward Service........................................................................... 5-8 Salient Characteristics for TDRSS MA Forward Services ............................... 5-9 MA Forward Service Real-Time Configuration Changes............................... 5-10 MA Forward Service Example Acquisition Times for the Fourth Generation NASA Standard Transponder ...................................................................... 5-11 Table 5-6. TDRSS MA Return Service Signal Parameters............................................. 5-13 Table 5-7. MA/SMA Return Service Configurations ....................................................... 5-16 Table 5-8. TDRSS MA Return Service ........................................................................... 5-22 Table 5-9. Customer Dynamics Supported through TDRSS MAR Service .................... 5-26 Table 5-10. MA Return Service Real-Time Configuration Changes ............................... 5-32 Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints ............ 5-36 Table 6-1. TDRSS SSA Forward PSK Service Signal Parameters .................................. 6-4 Table 6-2. TDRSS SSA Forward Phase Modulation Service Signal Parameters............. 6-9 Table 6-3. TDRSS SSA Forward Service....................................................................... 6-12 Table 6-4. Salient Characteristics for TDRSS SSA Forward Service ............................. 6-13
Revision 9

Table 1-1. Table 1-2. Table 2-1. Table 3-1. Table 3-2. Table 3-3. Table 3-4. Table 5-1. Table 5-2. Table 5-3. Table 5-4. Table 5-5.

xxi

450-SNUG

Table 6-5. SSA Forward Service Real-Time Configuration Changes ............................. 6-15 Table 6-6. SSA Forward Service Example Acquisition Times for the Fourth Generation NASA Standard Transponder ...................................................................... 6-17 Table 6-7. TDRSS SSA Return Service Signal Parameters........................................... 6-18 Table 6-8. SSA Return Service Configurations .............................................................. 6-23 Table 6-9. TDRSS SSA Return Service ......................................................................... 6-27 Table 6-10. Customer Dynamics Supported through TDRSS SSAR Service................. 6-30 Table 6-11. SSA Return Service Real-Time Configuration Changes ............................. 6-36 Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints .......... 6-39 Table 6-13. SSA Return IF Service Real-Time Configuration Changes ......................... 6-47 Table 6-14. TDRS SSAR IF Service Spacecraft and Ground Segment Channel Characteristics ............................................................................................. 6-48 Table 6-15. Example SSAR IF Service Implementation Loss Amounts and Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques ...................................................................................... 6-50 Table 7-1. TDRSS KuSA Forward Service Signal Parameters ........................................ 7-5 Table 7-2. TDRSS KuSA Forward Service..................................................................... 7-10 Table 7-3. Salient Characteristics for TDRSS KuSA Forward Services ......................... 7-12 Table 7-4. KuSA Forward Service Real-Time Configuration Changes ........................... 7-13 Table 7-5. TDRSS KuSA Return Service Signal Parameters......................................... 7-14 Table 7-6. KuSA Return Service Configurations ............................................................ 7-20 Table 7-7. TDRSS KuSA Return Service ....................................................................... 7-24 Table 7-8. KuSA Return Service Real-Time Configuration Changes ............................. 7-35 Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints .......... 7-40 Table 7-10. KuSA Return IF Service Real-Time Configuration Changes ....................... 7-47 Table 7-11. TDRS KuSAR IF Service Spacecraft and Ground Segment Channel Characteristics ............................................................................................. 7-48 Table 7-12. Potential TDRSS KuSA IF Return Service Configurations (Customer interfaces with the SN at a 370 MHz IF & Customer provides the Receiver) 7-49 Table 7-13. Potential KuSAR IF Service Implementation Loss Amounts & LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation & Coding Techniques ................................................................ 7-51 Table 8-1. TDRSS KaSA Forward Service Signal Parameters ........................................ 8-4 Table 8-2. TDRSS KaSA Forward Service....................................................................... 8-9 Table 8-3. Salient Characteristics for TDRSS KaSA Forward Services ......................... 8-10 Table 8-4. KaSA Forward Service Real-Time Configuration Changes ........................... 8-11 Table 8-5. TDRSS KaSA Return 225 MHz Service Signal Parameters.......................... 8-14 Table 8-6. KaSA Return 225 MHz Service Configurations ............................................. 8-16
Revision 9

xxii

450-SNUG

Table 8-7. TDRSS KaSA Return Service ....................................................................... 8-17 Table 8-8. KaSA Return Service Real-Time Configuration Changes ............................. 8-28 Table 8-9. TDRSS KaSA Return 225 MHz Service Customer Platform Signal Constraints................................................................................................... 8-31 Table 8-10. KaSA Return IF Service Real-Time Configuration Changes ....................... 8-34 Table 8-11. TDRS KaSAR 225 MHz and 650 MHz IF Service Spacecraft and Ground Segment Channel Characteristics................................................................ 8-35 Table 8-12. Potential TDRSS KaSA 225 MHz and 650 MHz IF Return Service Configurations (Customer interfaces with the SN at a 370 MHz IF for 225 MHz and 1.2 GHz IF for 650 MHz & Customer provides the Receiver)................ 8-37 Table 8-13. Potential KaSAR IF Service Implementation Loss and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques ............................................................................... 8-38 Table 9-1. Tracking Services by Data Group and Mode................................................... 9-2 Table 9-2. Signal Doppler Maxima ................................................................................... 9-3 Table 9-3. TDRSS Tracking Service Range Measurement Error ..................................... 9-3 Table 9-4. TDRSS Tracking Service Doppler Measurement rms Phase Noise................ 9-6 Table 10-1. MOC, NCCDS and TDRSS Ground Terminals Responsibilities and Functions ..................................................................................................... 10-2 Table 10-2. Overview of SN Message Terminology ....................................................... 10-3 Table 10-3. Schedule Request Descriptions .................................................................. 10-7 Table 10-4. Scheduling Flexibility Options ..................................................................... 10-8 Table 10-5. SN Scheduling Event Time Ground Rules .................................................. 10-9 Table 10-6. NCCDS Customer Types and Available Message Types ......................... 10-16 Table 10-7. Real-time Operations Activities Overview for NCCDS .............................. 10-25 Table 10-8. Real-time Operations Activities Overview for MOC................................... 10-26 Table 10-9. Real-time Operations Activities Overview for FDF and NISN.................... 10-27 Table 10-10. Real-time Operations Activities Overview for GTs .................................. 10-27 Table 10-11. Real-time Message Flow Between the NCCDS and MOCs .................... 10-32 Table 10-12. Real-time Message Flow Between the NCCDS and the GTs.................. 10-36 Table 10-13. Real-time Message Flow Between the NCCDS and NISN...................... 10-46 Table B-1. Forward Service Modulation and Data Rate Restrictions ............................... B-4 Table B-2. Data Configuration Constraints for DG1 Modes 1 & 2, Single Data Source.. B-14 Table B-3. Data Configuration Constraints for DG1 Modes 1 & 2, Dual Data Sources .. B-17 Table B-4. Data Configuration Constraints for DG1, Mode 3 ......................................... B-18 Table B-5. Data Configuration Constraints for DG2, Single Data Source (SQPSK) ....... B-21 Table B-6. Data Configuration Constraints for DG2, BPSK............................................ B-22

Revision 9

xxiii

450-SNUG

Table B-7. Data Configuration Constraints for DG2, Dual Data Sources (QPSK, SQPSK) .......................................................................................... B-23 Table C-1. Customer MOC Controllable Parameters Which Impact Acquisition ..............C-4 Table C-2. Additional Items and Parameters Which Impact Acquisition...........................C-6 Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return)..........C-7 Table C-4. Parameters Which Impact Forward Service .................................................C-17 Table C-5. Parameters Which Impact Return Service....................................................C-18 Table D-1. International and National PFD Limits Applicable to TDRSS Links ................D-3 Table D-2. S-Band Space-to-Space PFD Limits Given in ITU-R SA.1273 .......................D-4 Table D-3. Ku-Band Space Research PFD Limits Given in ITU-R SA.510 ......................D-4 Table D-4. Minimum Bandwidth as Defined for NTIA OOB Emission Mask .................D-14 Table G-1. Estimates of RFI Degradations on SSA Return Services ...............................G-4 Table H-1. Planning Sequence ......................................................................................H-15 Table H-2. DAS/Customer Interaction via SWSI ............................................................H-15 Table J-1. Customer Constraints for the S-Band ELV Class of TDRSS Customers..........J-1 Table J-2. Prec Adjustment for TDRSS ELV Customers ....................................................J-4 Table K-1. Performance of R-S Encoding in Conjunction with SN Services..................... K-4 Table O-1. Defined Interference Scenarios ......................................................................O-2

Revision 9

xxiv

450-SNUG

Section 1. Introduction
1.1 Purpose and Scope

1.1.1 Purpose This document describes the customer services provided by the National Aeronautics and Space Administration (NASA) Space Network (SN) and guides the customer through the process of obtaining support from the SN. 1.1.2 Scope The SN was established in the early 1980s to replace NASAs worldwide network of ground tracking stations. It consists of a constellation of geosynchronous satellites and associated ground systems and operates as a bent pipe relay system between customer platforms and customer ground facilities. For customer platforms operating in a low earth orbit (LEO) above 73 km in altitude, the SN is capable of providing tracking and data acquisition services over 100% of the customer platforms orbit. A more detailed description of the SN and its elements is provided in Section 2 of this guide. The emphasis in this guide is on the interfaces between the customer and the SN. Topics covered include the following: a. Ground interfaces between the customer Mission Operations Center (MOC) and the SN. b. Radio Frequency (RF) interfaces between the customer platform and the SN. c. Procedures for working with the Goddard Space Flight Center (GSFC) Exploration and Space Communications (ESC) Projects Division (Code 450), which has the management and operational responsibility for the SN, to establish customer interfaces. d. The capabilities, service characteristics, and operational aspects of the SN. e. Generalized capabilities and technical characteristics of non-SN elements that support the SN customer. 1.2 Additional Information The SN is constantly evolving. Circumstances may exist in which SN customers need more information than is provided in this document and in the referenced documents. SN customers are encouraged to directly contact GSFC Code 450 for further information. The GSFC Code 450 web page can be found at http://scp.gsfc.nasa.gov/. 1.3 Document Organization This document is organized as shown in Table 1-1.

Revision 9

1-1

450-SNUG

Table 1-1. Document Organization Section/ Appendix 1 Introduction Title Purpose Provides an introduction to the SN Users Guide. Describes the purpose, scope, and organization of the document, and provides the list of reference documents. Describes the SN and non-SN elements that provide support during SN operations, and describes the interfaces between the SN and the customer. Briefly describes the various services available to SN customers. Describes the process for obtaining SN services. Describes the Multiple Access (MA) telecommunications services available to SN customers. Describes the S-band Single Access (SSA) telecommunications services available to SN customers. Describes the Ku-band Single Access (KuSA) telecommunications services available to SN customers. Describes the Ka-band Single Access (KaSA) telecommunications services available to SN customers. Describes the tracking and clock calibration services available to customers for MA, SSA, and KuSA telecommunications services.

SN Overview

3 4 5

Service Available to Customers Obtaining SN Services MA Telecommunications Services SSA Telecommunications Services KuSA Telecommunications Services KaSA Telecommunications Services Tracking and Clock Calibration Services

Revision 9

1-2

450-SNUG

Table 1-1. Document Organization (contd) Section/ Appendix 10 Title SN Operations for Tracking and Data Relay Satellite System (TDRSS) Services Example Link Calculations Functional Configurations for TDRSS Forward and Return Services with Emphasis on Customers Data Phase and Data Channel Ambiguity Resolution Purpose Provides a general description of scheduling operations, real-time operations, and customer platform emergency operations. Contains example link calculations for SN telecommunications services. Provides data communication functional configurations for TDRSS telecommunications services; and for these functional configurations, identifies the conditions under which either a data phase ambiguity or a data channel ambiguity may exist at the SN/customer data interface. Details the operational aspects associated with acquisition. Describes some of the applicable treaty agreements on spectrum usage relevant to space missions utilizing the SN. Contains the definitions of parameters applicable to the transmitted signal, where the forward definitions describe the signal characteristics from the TDRS spacecraft and the return definitions describe the signal characteristics from the customer platform.

A B

C D

Operational Aspects of Signal and Autotrack Acquisition Spectrum Considerations

Customer Platform and Tracking and Data Relay Satellite (TDRS) Signal Parameters Definition

Periodic Convolutional Describes Periodic Convolutional Interleaving with a Cover Interleaving (PCI). Sequence for Synchronization Predicted Performance Degradations Due to RFI Describes the possible degradation to SN telecommunications services caused by Radio Frequency Interference (RFI).

Revision 9

1-3

450-SNUG

Table 1-1. Document Organization (contd) Section/ Appendix H I Title Demand Access System (DAS) NISN Services Purpose Describes the TDRSS MA Return (MAR) DAS capability. Describes the networked data services provided by the NASA Integrated Services Network (NISN). Describes the customer constraint requirements for the S-band Expendable Launch Vehicle (ELV) class of SN customers.

ELV Customer Constraints

Use of Reed-Solomon Coding Describes the use of Reed-Solomon in Conjunction with SN (R-S) coding in conjunction with the SN Customer Services customer services. McMurdo TDRSS Relay System (MTRS) South Pole TDRSS Relay (SPTR) and White Sands Complex (WSC) Alternate Relay Terminal (WART) Network Test Services Describes the support available through the MTRS capability. Describes the capabilities provided through SPTR and WART.

L M

Summarizes the methodology, configurations, resources, responsibilities, and planning activities for SN testing services. Provides an assessment of selfinterference in the SN MA environment at 2287.5 MHz. Describes the secure network-based GUI to the NCCDS and DAS to perform SN customer scheduling, real-time service monitoring and control, and state vector storage. Describes the capabilities provided through the WDISC System for customer data interface.

Self/Mutual Interference Considerations for New Customers at 2287.5 MHz Space Network (SN) Web Services Interface (SWSI)

WSC Transmission Control Protocol (TCP)/Internet Protocol (IP) Data Interface Service Capability (WDISC) System

Revision 9

1-4

450-SNUG

1.4 Reference Documents This section lists the specifications, standards, and other documents which serve as references. The most recent version of these documents should be referenced. 1. Requirements Specification for the White Sands Complex, 530-RSD-WSC. 2. White Sands Complex (WSC) Ground Terminal Requirements for the TDRS H, I, J Era, 405-TDRS-RP-SY-011. 3. Ground Network (GN) Users Guide, 453-GNUG. 4. Simulation Operations Center (SOC) Radio Frequency Simulation Operations Center (RFSOC) Functional Description and Capabilities Document, 450-FDCDSOC/RFSOC (Formerly STDN No. 101.6). 5. Space and Ground Networks Compatibility Test Systems Specifications, 450SPEC-CTV. 6. STDN Spacecraft RF Compatibility Test Procedures and Data Sheets, STDN No. 408.1. 7. Space Network Interoperable PN Code Libraries, 451-PN Code-SNIP. 8. CLASS ACRS/TLAS Operators Manual and Reference, NCC 98. 9. Interface Control Document Between the Space Network and Customers for Service Management, 452-ICD-SN/CSM. (formerly 451-ICD-NCCDS/MOC). 10. Space Network Operations Policy, STDN No. 119. 11. Interface Control Document (ICD) Between the Network Control Center (NCC)/Flight Dynamics Facility (FDF) and the White Sands Complex (WSC), 530-ICD-NCC-FDF/WSC 12. Interface Control Document (ICD) Between the Space Network and the Flight Dynamics Facility (FDF), 452-ICD-SN/FDF. 13. POCC Capabilities Document, Volume II, MCC/Remote POCC Interface Capabilities Description, JSC-14433. 14. NASCOM Interface Standard for Digital Data Transmission (NISDDT), 542-003. 15. Performance and Design Requirements and Specification for the Fourth Generation TDRSS User Transponder, 531-RSD-IVGXPDR. 16. NASA Integrated Services Network (NISN) Services Document, (NISN/001-001). 17. Interface Control Document Between the Space Network (SN) and the NASA Integrated Services Network, 452-ICD-SN/NISN 18. NASA Space Flight Program and Project Management Requirements, NPR 7120.5. 19. Customer Commitments and Review, GPR 1310.1. 20. Detailed Networks Requirements Process, 450-PG-1310.1.2. 21. Customer Commitment Process, 450-PG-1310.1.1. 22. Engineering Peer Reviews, GPR 8700.6.

Revision 9

1-5

450-SNUG

23. Data Service Management Center (DSMC) Operations Interface Procedures (OIP), 450-OIP-DSMC. 24. Space Network (SN) Web Services Interface (SWSI) Client Software Users Guide, 452-UG-SWSI. 25. Interface Control Document Between Demand Access System (DAS) and the SN Web Services Interface (SWSI) ,452-ICD-DAS/SWSI. 26. Security of Information Technology, NPR 2810.1. 27. IONet Security Plan, 290-003. 28. WSC Transmission Control Protocol (TCP)/Internet Protocol (IP) Data Interface Service Capability (WDISC) Operations Concept, CSOC-GSFC-RD-002091. 29. TDRSS Constellation Management Plan, 452-PLAN-0002. 30. IP Operational Network (IONet) Access Protection Policy and Requirements, 290-004. 31. WSC Alternate Relay Terminal (WART) Operations Concept Document, CSOCWSC-OC-001310 (available in pdf). 1.5 Reference Web Sites Web sites that have been used as reference for these documents and throughout the SNUG are listed in Table 1-2. Many of the links require access to the Government Centralized Configuration Management System (CCMS) website. Access to the CCMS may be obtained at http://gdms.gsfc.nasa.gov. An ID and password are required and may be requested at this site.

Revision 9

1-6

450-SNUG

Revision 9
URL http://gdms.gsfc.nasa.gov/ http://gdms.gsfc.nasa.gov/ http://gdms.gsfc.nasa.gov/

Table 1-2. Reference Web Sites

Web Site Description Government Centralized Configuration Management System (CCMS) document depository Requirements Specification for the White Sands Complex, 530-RSD-WSC Interface Control Document Between the Space Network and Customers for Service Management, 451-ICD-SN/CSM (formerly 451ICD-NCCDS/MOC) Interface Control Document (ICD) Between the Space Network (SN) and the Flight Dynamics Facility (FDF), 451-ICD-SN/FDF Interface Control Document Between the Space Network (SN) and the NASA Integrated Services Network (NISN), 452-ICD-SN/NISN Data Service Management Center (DSMC) Operations Interface Procedures (OIP), 450-OIPDSMC Whats New web page from the Space Network Online Information Center Homepage

http://msc-docsrv.gsfc.nasa.gov/cmdata/400/450/452/ICD/452-ICD-SN-CSM/452-ICD-SNCSM.pdf

1-7
http://gdms.gsfc.nasa.gov/ http://gdms.gsfc.nasa.gov/ http://scp.gsfc.nasa.gov/tdrss/new.html#loc

450-SNUG

Revision 9
https://cds02.gsfc.nasa.gov/ http://gdms.gsfc.nasa.gov/ http://scp.gsfc.nasa.gov/tdrss/usccs.pdf http://classwww.gsfc.nasa.gov/GSAMS/

Table 1-2. Reference Web Sites (contd)

URL http://fdf.gsfc.nasa.gov/prod_center/pc_frame_page.htm Web Site Description Flight Dynamics Facility (FDF) Product Center web page Network Advisory Message Page Code 450 Customer Commitment Process, 450PG-1310.1.1. User Spacecraft Clock Calibration System (USCCS) Users Guide Return Data Delay web page GSFC Spectrum Allocation and Management Site NTIA regulations CCSDS 401.0-B Blue Handbook on RF Frequency and Modulation Systems, Part 1, Earth Stations DAS web page Space Network Web Services Interface web page Internet Protocol Operational Network (IONet) Access Protection Policy and Requirements Operations Interface Procedures for the McMurdo TDRS Relay System, 532-OIP-NCC/MTRS RF SOC and GSFC Antenna Range web page

http://scp.gsfc.nasa.gov/tdrss/return_data_delay.htm

1-8 450-SNUG

http://www.ntia.doc.gov/osmhome/osmhome.html http://public.ccsds.org/publications/archive/401x0b09s.pdf

http://stelwscpo.gsfc.nasa.gov/Das http://swsi.gsfc.nasa.gov http://www.nisn.nasa.gov/DOCUMENTS1/IONet_Access_Policy_Rev3.doc http://gdms.gsfc.nasa.gov/ http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#RFSOC

Revision 9
http://www.ccsds.org http://www.nisn.nasa.gov

Table 1-2. Reference Web Sites (contd)

URL http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#SOC http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#CTL_CTV Web Site Description SOC web page Compatibility Test Lab web page Consultative Committee for Space Data Systems (CCSDS) NISN Homepage

1-9 450-SNUG

This page intentionally left blank.

Revision 9

1-10

450-SNUG

Section 2. SN Overview
2.1 General The purpose of this section is to provide a description of the interfaces between the customer and the SN, and an overview of the SN and non-SN elements that provide support during SN operations. 2.2 Customer Interfaces with the SN There are three types of interfaces between the customer and the SN: the Customer Commitment Interface, the RF Interface, and the Operations Interface. 2.2.1 Customer Commitment Interface The Customer Commitment Interface is the interface between the customer and the GSFC Networks Integration Management Office (NIMO) through which the customer requests SN services. The process for obtaining SN services is described in Section 4. 2.2.2 RF Interface The RF Interface is the two-way interface between the customer platform and the SN, as shown in Figure 2-1. This interface provides for the transmission of RF signals between the customer platform and the SN. These signals are described in detail in Sections 5 through 8 for SN telecommunications services and in Section 9 for the SN tracking service. 2.2.3 Operations Interface The Operations Interface is the two-way interface between the customer ground facilities and the SN, as shown in Figure 2-1. This interface provides for the scheduling of SN support and the conduct of real-time SN operations. All aspects of this interface, with the exception of tracking measurements, are described in Section 10. Details regarding tracking measurements are provided in Section 9. 2.3 Elements of the SN The SN is operated under the control of GSFC Code 450 with the objective of providing tracking and data relay services to customer missions. The SN consists of a space segment and a ground segment. The space segment consists of a constellation of Tracking and Data Relay Satellites (TDRS). This TDRS constellation is divided as follows: a. The basic TDRS program Flight 1 (F1) through Flight 6 (F6). b. The TDRS replacement program Flight 7 (F7). c. The TDRS follow-on program, known as Flight 8 (F8) through Flight 10 (F10).

Revision 9

2-1

450-SNUG

SN Space Segment

SN - Customer RF Interfaces Customer Data

Space Network
SN SpaceGround Link

Customer Platform Commands

Customer Platform

SN - Customer Operations Interfaces Customer Data from Platform Scheduling & Performance Tracking Measurements

NISN

SN Ground Segment

Scheduling Aids Service Requests Customer Platform Commands

Customer Ground Facilities

Figure 2-1. SN Customer RF and Operations Interfaces NOTE: The F8 spacecraft is unavailable for normal customer scheduling. The ground segment consists of the White Sands Complex (WSC), the Guam Remote Ground Terminal (GRGT), the Bilateration Ranging Transponder System (BRTS), the Merritt Island Launch Annex (MILA) TDRSS Relay, the Network Control Center Data System (NCCDS), and the Network Integration Center (NIC). WSC, GRGT, BRTS, MILA Relay, and the NCCDS are dedicated to SN operations only, but the NIC is shared with another NASA element, the Ground Network (GN). The combination of the WSC, the GRGT and the TDRS constellation is also known as the Tracking and Data Relay Satellite System (TDRSS). The SN elements and interfaces are shown in Figure 2-2 and described in paragraphs 2.3.1 and 2.3.2 below.

Revision 9

2-2

450-SNUG

Revision 9
Customer Platform
SSL (RF)

TDRSS SN Ground Terminal WSC

Schedule Control & Monitoring State Vectors

NCCDS

STGT BRTS
SGL (RF) SGL (RF) State Vectors IFL Scheduling and Performance Service Requests Scheduling and Performance Service Requests

T MILA RELAY
SGL (RF)

D WSGT R
Customer Data Customer Data

Customer MOC

EET (RF)

VIA NISN Guam Remote Station

Tracking Data & Measurements

N I S N

Tracking Measurements

Scheduling Aids

2-3
Legend: SN Customer Elements

Tracking Data & Measurements

Scheduling Aids

FDF GRGT
State Vectors

Figure 2-2. SN Elements and Interfaces

450-SNUG

The procurement of TDRS-K&L spacecraft was initiated in August 2006 by letter from the Deputy Associate Administrator (DAA), Space Communications and Navigation Office, Office of Space Operations, to NASA GSFC. The TDRS-K&L Request for Proposal was released in April 2007 and Proposals were received in May of 2007. The K&L TDRSS spacecraft are to be the functional, performance and operational equivalent of TDRS HIJ (F8-F10) for Single Access Services (S, Ku and Ka-bands) and better than TDRS 1-TDRS 7 for ground based beam-formed MA Return Services. The MA Return antenna element specifications and MA ensemble return channel specifications are such that the MA Return formed beam G/T should be degraded by no more than 1 dB from TDRS HIJ performance allowing for fewer return elements and ground beam-forming. The dual frequency TT&C for collocation of spacecraft is also retained. The ground terminal upgrades for the K&L spacecraft include the addition of Ka-band end-to-end test terminals, new MA return ground beam-formers, and retention of a compatible interface to the Demand Access Subsystem. NOTE: The SNUG reflects performance characteristics that may differ from those specified in TDR Spacecraft and Ground Terminal Specifications. The specific TDRS K&L characteristics will be analyzed based on test data prior to incorporation into the SNUG. TDRS-K is to be launched no later than December 2012, with TDRS L launched no later than December of 2013. Ground terminal upgrades are to be completed, installed and verified with existing on-orbit assets by December of 2011.

2.3.1 Space Segment The space segment of the SN consists of up to six operational TDRSs in geosynchronous orbit at allocated longitudes for relaying forward and return service signals to and from customers for data transfer and tracking. An additional TDRS, F1, provides dedicated support to the National Science Foundation (NSF) through the use of the WSC Alternate Relay Terminal (WART) (refer to paragraph 2.4.h and Appendix M for further information). Additional spare TDRSs may be in geosynchronous orbit. All first generation TDRSs (F1-F7) carry functionally identical payloads and all second generation TDRSs (F8-F10) carry functionally identical payloads. Figure 2-3 and Figure 2-4 identify the pertinent communications components and associated parameters of the first generation (F1-F7) and second generation (F8-F10) TDRSs, respectively.

Revision 9

2-4

450-SNUG

Multiple Access Antenna 30 elements: 12 diplexed for transmit/30 for receive S-band communications: - 2.1064 GHz (Forward) - 2.2875 GHz (Return) Circular polarization (LHC only) +13 conical Field-of-View Single Access Antenna Omni Antenna S-band TT&C LHC polarization

Space-to-Ground Link Antenna 2.0 m Ku-band antenna: - 14.6-15.25 GHz (Uplink) - 13.4-14.05 GHz (Downlink) WSC/GRGT-TDRS uplink/downlink Orthogonal, linear polarization

Single Access Antenna Dual-frequency communications: - S-band: 2.025-2.120 GHz (Forward) 2.200-2.300 GHz (Return) - Ku-band: 13.775 GHz (Forward) 15.0034 GHz (Return) Circular polarization (LHC or RHC) +22 E-W, +28 N-S rectangular Field-of-View

Figure 2-3. First Generation Tracking and Data Relay Satellite (F1-F7)

Revision 9

2-5

450-SNUG

Multiple Access Antenna 32 receive antenna elements 15 transmit antenna elements S-band communication: - 2.1064 GHz (Forward) - 2.2875 GHz (Return) LHC polarization +13 conical Field-of-View

Single Access Antenna Tri-frequency communications: - S-band: 2.025-2.120 GHz (Forward) 2.200-2.300 GHz (Return) - Ku-band: 13.775 GHz (Forward) 15.0034 GHz (Return) - Ka-band: 22.55-23.55 GHz (Forward) 25.25-27.50 GHz (Return) Circular polarization (LHC or RHC) Field-of-View: - +22 E-W, +28 N-S rectangular (primary) - 76.8 E-W (outboard), 24 E-W (inboard), +30.5 N-S elliptical (extended) (Note: Outboard is west for the west SA antenna and is east for the east SA antenna. Inboard is east for the west SA antenna and is west for the east SA antenna.)

Omni Antenna S-band TT&C LHC polarization

Single Access Antenna Space-Ground Link Antenna 1.8 m Ku-band antenna: - 14.6-15.25 GHz (Uplink) - 13.4-14.05 GHz (Downlink) WSC/GRGT-TDRS uplink/downlink Orthogonal, linear polarization Modified frequency plan allows collocation

On-Board Operational Enhancements On-board SA antenna control Autonomous recovery from anomalies Improved monitoring

Figure 2-4. Second Generation Tracking and Data Relay Satellite (F8-F10 also known as H, I, J) 2.3.1.1 Change of TDRS Location The GSFC Code 450 may change the geosynchronous location of any TDRS to any other geosynchronous location assigned to NASA. SN customers should refer to the current location of the TDRS spacecraft on the Whats New web page from the Space Network Online Information Center Homepage, which can be found at Additionally, TDRS constellation http://scp.gsfc.nasa.gov/tdrss/new.html#loc. information can be found in the TDRS Constellation Management Plan, 452-PLAN0002. Table 2-1 provides examples of TDRS constellation plans. With TDRSs F8-F10, up to two spacecraft can be collocated in one longitudinal location. These two spacecraft may be either two second-generation TDRSs or one first-generation TDRS and one second-generation TDRS. This feature allows the use of two partially failed spacecraft to be collocated in order to conserve orbital slots. 2.3.1.2 TDRS Line-of-Sight Coverage TDRS line-of-sight coverage depends on customer platform altitude and inclination as well as TDRS geosynchronous longitude, inclination, and field-of-view (FOV). Assuming TDRS located at 41W, 174W, and 275W with a 0 inclination, 100 percent line-of-sight global coverage can be provided for:

Revision 9

2-6

450-SNUG

Table 2-1. Example of TDRS Constellation Plans

WSC

F-7 150 Stored

F-9 62 Stored

GRGT

F-6 173.7W TDW

F-5 171W TD-171

F-1 F-4 F-10 49W 46W 41W TDS TDE

F-3 275W TD-275

F-8 271W

Example of TDRS Constellation Spring 2007 Geosynchronous Longitudes of First Generation Satellites (TDRSs F1-F7) 46W (F4) 49W (F1) (note 3) 171W (F5) 275W (F3) 150W (F7) (storage) 174W (F6) Notes: For exact TDRS orbital locations, please refer to the current location of the TDRS spacecraft on the Whats New web page from the Space Network Online Information Center Homepage, which can be found at http://scp.gsfc.nasa.gov/tdrss/new.html#loc. The TDRSS Constellation Management Plan, 452-Plan-002, also provides constellation location information. Additionally, the detailed TDRS spacecraft orbit (including inclination) can be found by referring to the element reports under the view mission products on the Flight Dynamics Facility (FDF) Product Center web page, which can be found at http://fdf.gsfc.nasa.gov/prod_center/pc_frame_page.htm. The TDRS F8-F10 (H, I, J) spacecraft have the capability of supporting collocation on-orbit. When collocated, TDRS telecommunications services are provided from: 1) 2 TDRS F8-F10 in the same assigned orbital location (slot) with nodal crossings within 0.1 degrees of the assigned longitude, or 2) 1 TDRS F8-F10 and 1 TDRS F1-F7 in the same assigned orbital location (slot) with nodal crossings within 0.1 degrees of the assigned longitude. All services scheduled for a customer in a single event must be provided by a single TDRS; therefore, collocation may preclude scheduling of certain combinations of services. Not available for normal customer scheduling used for WART operation. The F8 spacecraft is unavailable for normal customer scheduling. Geosynchronous Longitudes of Second Generation Satellites (TDRSs F8-F10) (note 2) 41W (F10) 62W (F9) (storage) 271W (F8) (note 4)

Example Constellation Plan (note 1) First Generation TDRSs and 3 Second Generation TDRSs

1.

2.

3. 4.

Revision 9

2-7

450-SNUG

a. Customer altitudes between 73 km and 1000 km for the Multiple Access (MA) and Ku- and Ka-band Single Access (SA) low earth orbit (LEO) FOV (LEOFOV) limits of +10.5 (conical) (refer to Figure 2-5 for an example average percent coverage and Sections 5, 7, and 8 for a description of MA, KuSA, and KaSA LEOFOV services) b. Customer altitudes between approximately 73 km and 3000 km for the MA Primary FOV (PFOV) limits of +13 (conical) (refer to Figure 2-6 for an example average percent coverage and Section 5 for a description of MA service). c. Customer altitudes between approximately 73 km and 9000 km for the SA PFOV limits of +22E-W and +28N-S (rectangular) (refer to Figure 2-7 for an example average percent coverage and Sections 6 through 8 for a description of PFOV SA services). The TDRSs F8-F10 SA antennas have an Extended Elliptical FOV (EEFOV) of 76.8E-W (outboard), 24E-W (inboard), and +30.5N-S, which will allow for coverage to customers in geosynchronous orbit. Figure 2-8 depicts the average percent coverage assuming the SA EEFOV for TDRSs F8-F10 located at 41W and 174W with 0 inclination and the SA PFOV for TDRSs F1-F7 located at 275W with a 0 inclination. The average percent coverage figures consider only geometric line-of-sight coverage and do not consider other coverage constraints such as flux density restrictions, periods of RFI, customer platform constraints, and service limitations, including sun and weather interference, scheduling availability, or mutual interference. In this document, the percent coverage is provided for example and more detailed coverage analysis (refer to Section 3, paragraph 3.5.2) is available for a customers specific conditions. Please contact the Code 450 Project office if additional coverage analysis is needed. NOTE: The TDRSs are geosynchronous satellites, which have the same orbit period as a geostationary satellite, but their orbit may be elliptical and inclined. A geosynchronous satellite in an inclined circular orbit moves in a figure-8 pattern as viewed from earth. The TDRSs F1-F7 and F8-F10 maintain nodal crossings to within +0.1 of the assigned longitude. In general, the SN does not require stringent north-south station keeping to maintain TDRSS services. The detailed TDRS spacecraft orbit (including inclination) can be found by referring to the Element Reports under the View Mission Products on the Flight Dynamics Facility (FDF) Product Center web page, which can be found at http://fdf.gsfc.nasa.gov/prod_center/pc_frame_page.htm.

Revision 9

2-8

450-SNUG

TDRS Coverage (LEOFOV for 41W, 174W, 275W)

100 90 80 70 Average Coverage (%) 60 50 40 30 20 10 0 0 1000 2000 3000 4000 5000 6000 7000 8000 Customer Altitude (km) Inclination=28.5 deg Inclination=99 deg Inclination=55 deg

TDRS at 41W and 0 Deg. Inclination (FOV: +/- 10.5 deg conical) TDRS at 174W and 0 Deg. Inclination (FOV: +/- 10.5 deg conical) TDRS at 275W and 0 Deg. Inclination (FOV: +/- 10.5 deg conical)

Note: The customer minimum altitude for 100% line-of-sight coverage is 73 km.

Figure 2-5. Example Average Line-of-Sight Coverage for LEOFOV

TDRS Coverage (MA PFOV for 41W, 174W, 275W)

100 90 80 70 Average Coverage (%) 60 50 40 30 20 10 0 0 1000 2000 3000 4000 5000 6000 7000 8000 Customer Altitude (km) Inclination=28.5 deg Inclination=99 deg Inclination=55 deg

TDRS at 41W and 0 Deg. Inclination (FOV: +/- 13 deg conical) TDRS at 174W and 0 Deg. Inclination (FOV: +/- 13 deg conical) TDRS at 275W and 0 Deg. Inclination (FOV: +/- 13 deg conical)

Note: The customer minimum altitude for 100% line-of-sight coverage is 73 km.

Figure 2-6. Example Average Line-of-Sight Coverage for MA PFOV

Revision 9

2-9

450-SNUG

TDRS Coverage (SA PFOV for 41W, 174W, 275W)

100
TDRS at 41 W and 0 Deg. Inclination (FOV: +/- 28 deg N-S; +/22 deg. E-W rectangular) TDRS at 174W and 0 Deg. Inclination (FOV: +/- 28 deg N-S; +/-22 deg E-W rectangular) TDRS at 275W and 0 Deg. Inclination (FOV: +/- 28 deg N-S; +/-22 deg E-W rectangular)

95

90

Average Coverage (%)

85 Inclination=28.5 deg Inclination=99 deg Inclination=55 deg

80

75

70

65

60 0 5000 10000 15000 20000 25000 Customer Altitude (km)

Note: The customer minimum altitude for 100% line-of-sight coverage is 73 km.

Figure 2-7. Example Average Line-of-Sight Coverage for SA PFOV

TDRS Coverage (SA EEFOV for 41W & 174W; SA PFOV for 275W)
100

95

90 Average Coverage (%)

85 Inclination=28.5 deg Inclination=99 deg Inclination=55 deg

80

75
TDRS at 41W and 0 Deg. Inclination (FOV: +/-30.5 deg N-S; +/-76.8 deg E-W elliptical) TDRS at 174W and 0 Deg. Inclination (FOV: +/- 30.5deg N-S; +/-76.8 deg E-W elliptical)

70

TDRS at 275W and 0 Deg. Inclination (FOV: +/- 28 deg N-S; +/-22 deg E-W rectangular)

65 0 5000 10000 15000 20000 25000 30000 35000 Customer Altitude (km)

Note: The customer minimum altitude for 100% line-of-sight coverage is 73 km.

Figure 2-8. Example Average Line-of-Sight Coverage for SA EEFOV

Revision 9

2-10

450-SNUG

2.3.2

Ground Segment

2.3.2.1 Dedicated Ground Elements The majority of SN ground segment elements are dedicated to SN operations only. The SN dedicated ground elements are as follows: a. Ground Terminals. The White Sands Complex (WSC) and Guam Remote Station (GRS) provide the communications equipment necessary for transmitting and receiving data and tracking information relayed via each TDRS. The WSC consists of two ground terminals: the White Sands Ground Terminal (WSGT), and the Second TDRSS Ground Terminal (STGT). The Guam Remote Station consists of one ground terminal: the Guam Remote Ground Terminal (GRGT). The WSGT and STGT are independently operated ground terminals, each containing a number of autonomous Space-Ground Link Terminals (SGLTs). WSGT contains two SGLTs and STGT contains three SGLTs. GRGT SGLT 6 is a SGLT that is extended from and operated remotely via the WSGT. GRGT SGLT 7, which is in the process of being constructed for a dedicated set of customers, will not be available for SN Customer services. Each SGLT contains the hardware and software required to provide customer telecommunications and tracking services and tracking, telemetry, and command (TT&C) functions for the assigned TDRS. SGLT operations are controlled and monitored through the TDRSS Operations Control Center (TOCC). A data link, known as the Interfacility Link (IFL), exists between the WSGT and the STGT for the exchange of customer data and tracking information. The interface between WSGT and GRGT is accomplished by a commercial common carrier provided by the NASA Integrated Services Network (NISN). Equipment is available at all three sites to provide the customers with end-to-end system testing capabilities. Additional WSC and GRGT functions include both data handling (refer to Section 3, paragraph 3.6) and unique support for the Shuttle. b. Merritt Island Launch Annex (MILA) TDRSS Relay. The MILA Relay provides RF signal routing between the TDRS and payloads or platforms under test prior to launch in support of Kennedy Space Center (KSC), Johnson Space Center (JSC), or customer MOCs. MILA also provides a relay between payloads and NISN facilities for the MOCs during the pre-launch period, when needed. c. Bilateration Ranging Transponder System (BRTS). The BRTS consists of unmanned and totally automated transponders and provides, in conjunction with the TDRSS and the Flight Dynamics Facility (FDF), metric tracking data for the accurate determination of the ephemerides for each in-orbit TDRS. The BRTS transponders are presently located at the WSC, central Australia, Ascension Island, and American Samoa. d. Network Control Center Data System (NCCDS). An additional element of the SN ground segment is the Network Control Center (NCCDS). Collocated with WSC, the NCCDS is the operations control facility for the SN. It schedules

Revision 9

2-11

450-SNUG

most SN elements and supporting elements and provides interfaces for planning, acquisition, control, and status of the SN. The NCCDS is the point-of-contact between customers and the SN for most scheduling and real-time performance. A customer may obtain SN support by submitting specific schedule requests to or establishing generic requirements with the NCCDS. The NCCDS translates customers requirements into specific events. Additionally, the NCCDS notifies affected customers of scheduled system outages so that MOCs can properly plan mission activities. Upon MOC request, the NCCDS provides operational performance information (such as data presence monitoring indicators and data quality monitoring data) on scheduled services during actual support to determine if conditions exist that will affect data quality. For further information on the MOC/NCCDS interface, please refer to Section 10 of this document. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessible via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. GSFC Code 450 uses the NAMs as a means of letting customers know of any performance constraints associated with the TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452PLAN-0002. 2.3.2.2 Shared Ground Elements a. Network Integration Center (NIC). The NIC, which is located at GSFC, Building 13, provides the capability to monitor data, perform testing and fault isolation services. The NIC provides critical monitoring and fault isolation support for Shuttle Missions and Expendable Launch Vehicle (ELV) launch/early orbit activities. 2.4 Supporting Elements Outside the SN NASA elements not part of the SN that support SN operations are as follows: a. NASA Integrated Services Network (NISN). NISN is a global system of communications transmission, switching and terminal facilities that provide NASA with wide area network communications services. NISN services which support the SN include real-time and mission critical Internet Protocol (IP) routed data as well as high rate data and video services connecting the WSC to NASA Centers. Inter-center mission voice communications services are also provided for management of the network and support of the customers mission. For further information on NISN, refer to Appendix I. b. Flight Dynamics Facility (FDF). Located at GSFC, the FDF provides support to the SN and NASA approved customer platform missions for acquisition data

Revision 9

2-12

450-SNUG

generation, orbit determination, and orbit maneuver support. The FDF validates and calibrates the SN tracking data. The FDF also controls and provides schedule requirements for the BRTS for TDRS tracking and monitors the BRTS status. c. RF Simulation Operations Center (RF SOC)/Simulation Operations Center (SOC). The RF SOC and SOC, located at GSFC, provide facilities for conducting customer flight project mission simulations for SN customers. They can monitor SN performance during these mission simulations, simulate a mission-unique customer platform, verify SN/customer MOC interfaces, and simulate a customer MOC in support of fault isolation. d. Compatibility Test Van (CTV)/Compatibility Test Laboratory (CTL). Home-based at GSFC, two CTVs provide the means to test customer platforms at remote locations for RF compatibility with the SN, which may include an end-to-end test after compatibility testing is completed. Each CTV can provide cabled RF interfaces to a customer platform for local RF compatibility testing. The CTV also has a rooftop antenna for TDRSS relay performance tests. Similar in capability to the CTV, the GSFC-based CTL can provide cable RF interfaces to a customer platform for local RF testing and a rooftop antenna for SN performance tests. In this case, the customer brings the platform RF components to the GSFC CTL and these components are set up in an RF-shielded screen room for testing. e. Ground Network (GN). The GN consists of NASA ground stations in Merritt Island (MILA) and Ponce de Leon (PDL), Florida; McMurdo, Antarctica; and Wallops Island, Virginia. Under contract are commercial operators at Spitsbergen, Norway; Poker Flat Research Range and the Alaska Satellite Facility (ASF) in Fairbanks, Alaska; Santiago Chile; South Point, Hawaii, North Pole, Alaska, and Dongara, Australia. These stations provide orbital communications support for Near-Earth orbiting customer platforms. Additionally, the MILA and Wallops stations provide pre-launch, launch, and landing communications support for the Space Transportation System (STS). The GN and SN combined were previously referred to as the Spaceflight Tracking and Data Network (STDN). f. Deep Space Network (DSN). Managed by the Jet Propulsion Laboratory (JPL), Pasadena, CA, the DSN is comprised of ground tracking stations at Canberra, Australia; Goldstone, California; and Madrid, Spain. The DSN stations are used to support a standard mission set and provide emergency support in the event of customer contingency or degraded STDN support. The DSN also provides telecommunications and tracking support during TDRS launch and the subsequent transfer operations. g. McMurdo TDRSS Relay System (MTRS). The MTRS consists of two TDRS relay ground systems which are within the NSF McMurdo facilities in the Antarctic. The MTRS can be used to relay up to 300 Mbps through TDRS to WSC. Presently, these systems are evolving into a future operational status;

Revision 9

2-13

450-SNUG

they are currently being used for special purpose data relay. For further information on the MTRS, please refer to Appendix L. h. South Pole TDRSS Relay (SPTR) and WSC Alternate Relay Terminal (WART). The SPTR, located at the Amundsen-Scott South Pole Station, Antarctica, provides high data rate communications links with the South Pole on a daily basis via the TDRSS to support interactive connectivity for the Antarctic scientific experimenter community. The SPTR is a dedicated service specifically for relay of data from the South Pole and utilizes a partial SGLT at WSC, which is known as WART. For further information of the SPTR/WART, please refer to Appendix M.

Revision 9

2-14

450-SNUG

Section 3. Services Available to Customers

3.1 General The SN along with its supporting elements can provide various services to customers including: Telecommunications, Tracking, Testing, Analysis, and Data Distribution/ Processing Services. 3.2 Telecommunications Services Several types of telecommunications services are simultaneously available to customers. The type of telecommunications service selected is determined by the data rate required, duration of service period, and customer platform telecommunications system design. The two primary telecommunications services are termed Multiple Access (MA) and Single Access (SA). The SA services are available at S-band, Ku-band, and Ka-band (F8-F10 only) frequencies. The SN can provide any of the following services: a. A forward service, defined as the communication path that generally originates at the customer control center and is routed through WSC or GRGT to the TDRS to the customer platform. b. A return service, defined as the communication path that generally originates at the customer platform and is routed through the TDRS to WSC or GRGT back to the customer control center and/or data acquisition location. c. Both forward and return services simultaneously. The forward service is typically utilized for customer platform commanding and may include a separate ranging channel for use in tracking services. Forward service data rates are variable depending on the forward service type, which are S-band Multiple Access Forward (MAF) through TDRS F1-F7, S-band Multiple Access Forward (SMAF) through TDRS F8-F10, S-band Single Access Forward (SSAF), Ku-band Single Access Forward (KuSAF), and Ka-band Single Access Forward (KaSAF) through TDRS F8-F10. Table 3-1 provides an overview of the TDRSS forward service characteristics. The return service is typically utilized for the return of science data and customer platform status information. The return service consists of up to two channels, which may include a pseudorandom noise (PN) code for use in ranging services and to reduce power flux density. Similar to the forward service, return service data rates are variable depending on the return service type, which are S-band Multiple Access Return (MAR) through TDRS F1-F7, S-band Multiple Access Return (SMAR) through TDRS F8-F10, S-band Single Access Return (SSAR), Ku-band Single Access Return (KuSAR), and Ka-band Single Access Return (KaSAR) through TDRS F8-F10. Return services are divided into two major groups, Data Group 1 (DG1) and Data Group 2 (DG2). DG1 services utilize spread spectrum modulation while DG2 services are non-spread.

Revision 9

3-1

450-SNUG

Table 3-1. TDRSS Forward Service Characteristics

MA (TDRS F1-F7 / TDRS F8-F10) (note 10) 1 2106.4 MHz LHCP only 6 MHz 300 kbps QPSK/SS-BPSK; data rates 300 kbps SSA (note 10) 2 2025.8-2117.9 MHz (note 6) LHCP and RHCP (selectable) (note 9) 20 MHz 7 Mbps QPSK/SS-BPSK for data rates < 300 kbps BPSK: 300 kbps < dr < 7 Mbps PCM/PM for data rates < 1 Mbps PCM/PSK/PM for data rate < 8 kbps PFOV: (rectangular) 22 east-west 28 north-south Extended Elliptical (EEFOV) (F8-F10 only): 76.8 east-west (outboard) 24 east-west (inboard) 30.5 north-south PFOV (F1-F10) and EEFOV (F8-F10 only): Normal: 43.6 dBW High: 46.3 dBW (F1-F7)/ 48.5 dBW (F8-F10) (note 7) 2 13.775 GHz LHCP and RHCP (selectable) (note 9) 50 MHz 25 Mbps (note 5) QPSK/SS-BPSK for data rates <300 kbps BPSK: 300 kbps < dr < 25 Mbps KuSA (note 10) KaSA (TDRS F8-F10) (note 10) 2/TDRS up to 8/WSC 22.55-23.55 GHz (note 6) LHCP and RHCP (selectable) (note 9) 50 MHz 25 Mbps (note 5) QPSK/SS-BPSK for data rates <300 kbps BPSK: 300 kbps < dr < 25 Mbps

Revision 9
Customer service links/satellite (note 2) Space-to-Space Freq. Bands Space-Space Polarization RF Channel BW (3 dB, minimum) Max Data Rate Modulation Scheme (notes 1 and 4)

3-2 450-SNUG

Field of View (max.) (note 3)

Primary (PFOV): 13 conical LEOFOV: 10.5 conical

Minimum Forward Link EIRP (note 3)

PFOV: F1-F7: 34 dBW F8-F10: 40 dBW LEOFOV: F1-F7: 34 dBW F8-F10: 42 dBW

PFOV: (rectangular) 22 east-west 28 north-south LEOFOV: 10.5 conical EEFOV (F8-F10 only): 76.8 east-west (outboard) 24 east-west (inboard) 30.5 north-south PFOV (F1-F10) and EEFOV (F8-F10 only): Normal/high autotrack mode: 46.5 dBW/48.5 dBW (notes 7,8) Normal/high program track mode: 40.5 dBW/42.5 dBW (note 7) LEOFOV: Normal/high autotrack mode: 46.5 dBW/48.5 dBW (note 7) Normal/high program track mode: 44.0 dBW/46 dBW (note 7)

PFOV: (rectangular) 22 east-west 28 north-south LEOFOV: 10.5 conical

PFOV: Autotrack: 63.0 dBW Program track: 56.2 dBW LEOFOV: Autotrack: 63.0 dBW Program track: 59.5 dBW

Table 3-1. TDRSS Forward Service Characteristics (contd)

NOTES: TDRSS spacecraft are capable of bent-pipe operation to support user defined (non-TDRSS) signal formats. Non-TDRSS signal formats may require the addition of ground terminal modulation/demodulation equipment. Precise performance will have to be handled on a case-by-case basis. 2. TDRS F8-F10 Ku and Ka-band forward services cannot be supported simultaneously through the same SA antenna. GRGT SGLT 6 is not currently planned to support a TDRS F8-F10 spacecraft. 3. For a thorough description of the service performance and additional constraints for the various FOVs, please see Sections 5 through 8 for MA, SSA, KuSA, and KaSA services. 4. For data rates <300 kbps, the I channel contains the command data and is modulo-2 added to a 3 Mcps PN code and the Q channel is a 3 Mcps PN code. 5. Current WSC/GRGT data interface supports up to 7 Mbps; however, upgrades to support up to 25 Mbps are planned. 6. For specific center frequency assignments, please coordinate with GSFC Code 450 and your associated spectrum management office. 7. Use of the high power mode is restricted, and must be coordinated with GSFC Code 450 prior to use. 8. The KuSA forward autotrack performance for EEFOV is a goal and will be supported on a best-effort basis. 9. The forward and return polarization for each band must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 10. The F8 spacecraft is unavailable for normal customer scheduling. 1.

Revision 9 3-3 450-SNUG

Table 3-2 provides an overview of the TDRSS return service characteristics. Table 3-3 summarizes the differences between the SN data group and modes used for return service operations. Each TDRS providing customer services is assigned a SGLT. The assigned SGLT performs both TT&C functions and customer telecommunications and tracking functions in support of TDRS operations. However, not all SGLTs possess the same telecommunications service capabilities. Figure 3-1 provides an overview of customer services available through each SGLT. 3.2.1 MA Service Overview MA (also referred to as S-band Multiple Access (SMA) for TDRS F8-F10) forward and return services operate at fixed S-band frequencies (nominally 2106.4 MHz forward and 2287.5 MHz return) and polarization (Left Hand Circular). Forward service operations are time-shared among TDRS customers where one customer is supported per TDRS at a time. The TDRS F1-F7 MA return service is provided by an on-board 30 element phased array antenna in conjunction with beamforming equipment located in the ground station. The TDRS F8-F10 SMA return service is provided by an array of 32 elements in conjunction with TDRS on-board beamforming. The arrays on both generations of TDRSs allow for spatial discrimination due to the phase differential of the customer signal received at each spaced antenna element on the TDRS. The standard network MA services through TDRS F1-F7 and F8-F10 are one forward and five return services per TDRS. The number of TDRS F1-F7 MA return services supported by a SGLT is limited by the quantity of ground MA equipment and the level of self-interference among customers. The SN Demand Access System (DAS) allows expansion of the TDRSS F1-F7 MAR DG1 mode 2 services well beyond the standard number of return services per TDRS/SGLT. For further information on DAS, refer to Appendix H. NOTE: Unless denoted by the TDRS fleet, the term MA is used throughout this document to denote MA services through TDRS F1-F7 and TDRS F8-F10. If the term SMA is used, these capabilities are specific to TDRS F8-F10. 3.2.2 SA Service Overview SA services available through each TDRS SA antenna are: SSAF, SSAR, KuSAF, KuSAR, KaSAF (F8-F10 only), and KaSAR (F8-F10 only). Each TDRS SA antenna has one polarizer (either Left Hand Circular or Right Hand Circular) for each frequency band (S, Ku, or Ka). The forward and return polarization for each band must be the same in order to obtain simultaneous forward and return services through the same SA antenna. The SN can simultaneously support S-band and K-band (either Ku-band or Ka-band (F8-F10 only)) forward and/or return services through one SA antenna to the same ephemeris. TDRS F8-F10 cannot simultaneously support Ku-band and Ka-band services through one SA antenna.

Revision 9

3-4

450-SNUG

Revision 9
Customer service links/satellite (notes 2 and 5) Space-to-Space Freq. Bands Space-Space Polarization RF Channel BW (3 dB, minimum) Max Total (I+Q) Data Rate Return FEC Scheme Return Data Group and Mode (note 1) Field of View (max.) (note 3)

Table 3-2. TDRSS Return Service Characteristics

MA (note 6) (TDRS F1-F7 / TDRS F8-F10) (note 13) 5/TDRS up to 20/WSC 2/TDRS through GRGT 2287.5 MHz LHCP only 6 MHz SSA (note 13) 2 2200-2300 MHz (note 7) LHCP and RHCP (selectable) (note 10) 10 MHz 2 15.0034 GHz LHCP and RHCP (selectable) (note 10) 225 MHz 300 Mbps (uncoded) (note 12) Rate 1/2 convol. or uncoded DG1 and DG2 PFOV: (rectangular) 22 east-west 28 north-south LEOFOV: 10.5 conical EEFOV (F8-F10 only): 76.8 east-west (outboard) 24 east-west (inboard) 30.5 north-south PFOV (F1-F10) and EEFOV (F8-F10 only): Autotrack: 24.4 dB/K (note 8) Program track: 18.4 dB/K LEOFOV: Autotrack: 24.4 dB/K Program Track: 21.9 dB/K KuSA (note 13) KaSA (TDRS F8-F10) (note 13) 2/TDRS up to 8/WSC 25.25-27.5 GHz (note 7) LHCP and RHCP (selectable) (note 10) 225 or 650 MHz (note 4) 300 Mbps (uncoded) (note 4) Rate 1/2 convol. or uncoded DG2 PFOV: (rectangular) 22 east-west 28 north-south LEOFOV: 10.5 conical EEFOV: 76.8 east-west (outboard) 24 east-west (inboard) 30.5 north-south PFOV and EEFOV: Autotrack: 26.5 dB (notes 8,11) Program track: 19.1 dB/K (PFOV only) LEOFOV: Autotrack: 26.5 dB (note 11) Program Track: 23.0 dB/K

300 kbps (F1-F7) / 6 Mbps (rate coded) 3 Mbps (F8-F10) (rate coded) Rate 1/2 convol. (F1-F7) / Rate 1/2 or 1/3 convol. Rate 1/2 or 1/3 convol. (F8-F10) DG1 modes 1 and 2 (F1-F7) / DG1 and DG2 DG1 and DG2 (F8-F10) PFOV: 13 conical PFOV: (rectangular) 22 east-west LEOFOV: 10.5 conical 28 north-south EEFOV (F8-F10 only): 76.8 east-west (outboard) 24 east-west (inboard) 30.5 north-south Formed Beam: PFOV: F1-F7: 2.2 dB/K F8 (cold)-F10: 3.2 dB/K F8 (hot): -0.2 dB/K (note 9) LEOFOV: F1-F7: 3.1 dB/K F8 (cold), F9-F10: 4.5 dB/K F8 (hot): 1.2 dB/K (note 9) PFOV: 9.5 dB/K EEFOV (F8-F10 only): 9.5 dB/K

3-5 450-SNUG

TDRS G/T (Nadir, minimum) (note 3)

Revision 9
1. 2. 3. 4. 5. 6. 7. 8. 9.

Table 3-2. TDRSS Return Service Characteristics (contd)

NOTES: TDRSS spacecraft are capable of bent-pipe operations to support user defined (non-TDRSS) signal formats. Non-TDRSS signal formats may require the addition of ground terminal modulation/demodulation equipment. Precise performance will have to be handled on a case-by-case basis. TDRS HIJ Ku and Ka-band return services cannot be supported simultaneously through the same SA antenna. For a thorough description of the service performance and additional constraints for the various FOVs and antenna tracking modes, please see Sections 5 through 8 for MA, SSA, KuSA, and KaSA services. The TDRS G/T is a component of the Prec equations provided in Sections 5 through 8. The required Prec values should be used as a guide for determining SN performance. Higher return link data rates are possible through the Ka-band 650 MHz bandwidth automated IF service, which requires customer receive equipment at WSC. Please see Section 8, paragraph 8.3.6 and contact GSFC Code 450 for further information. Guam Remote Ground Terminal (GRGT) SGLT 6 is not currently planned to support a TDRS F8-F10 spacecraft. The Space Network Demand Access System (DAS) allows expansion of the TDRSS F1-F7 MAR DG1 mode 2 services well beyond the standard number of return services per TDRS/SGLT. For further information on DAS, refer to Appendix H. For specific center frequency assignments, please coordinate with GSFC Code 450 and your associated spectrum management office. The KuSA and KaSA return autotrack performance for EEFOV is a goal and will be supported on a best-effort basis. The F8 spacecraft has some SMA return G/T performance variations due to an MA element array and sunshield proximity problem. The G/T varies based upon the normal daily TDRS diurnal cycle. The hot periods can be predicted and will occur at regular intervals with a total hot period of less than 12 hours/day. Note that F8 is unavailable for customer scheduling. The forward and return polarization for each band must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. Autotrack service is not available through the Ka-band 650 MHz bandwidth IF service. GRGT support of KuSA return data rates in excess of 150 Mbps should be discussed with GSFC Code 450. The F8 spacecraft is unavailable for normal customer scheduling.

3-6 450-SNUG

10. 11. 12. 13.

Table 3-3. Return Link Data Group and Mode Description

Data Group and Mode (note 4) Doppler Measurements 1-way Return 1-way Forward (note 5) 2-way (note 1) Range and Time Transfer Measurements (note 2) 3 Mcps PN code added asynchronously to channel symbol stream I and Q I and Q I only Baud Rate Transmission

DG1 mode 1 DG1 mode 2 DG1 mode 3

I: Low rate (< 300 ksps MA, SSA, KuSA) Q: Low rate (< 300 ksps MA, SSA, KuSA) I: Low rate (< 300 ksps MA, SSA, KuSA) Q: Low rate (< 300 ksps MA, SSA, KuSA) I: Low rate (< 300 ksps SMA F8-F10, SSA, KuSA) Q: up to High rate (< 3 Msps SMA F8-F10; < 6 Msps SSA; < 6 Msps KuSA) I: up to High rate (< 3 Msps SMA F8-F10; < 6 Msps SSA; < 300 Msps Ku/KaSA) Q: up to High rate (< 3 Msps SMA F8-F10; < 6 Msps SSA; < 300 Msps Ku/KaSA (note 3)

DG2 coherent DG2 noncoherent

None None

1. 2. 3.

4. 5.

NOTES: Requires that the customer transponder coherently turns around the received forward service carrier. Requires that the customer transponder coherently turns around the PN code epoch received in the forward service range channel. TDRS F8-F10 support KaSA forward and return DG2 noncoherent services. Tracking services are not available through KaSA service. Higher KaSA return link symbol rates are possible through the Ka-band 650 MHz bandwidth automated IF service, which requires customer receive equipment at WSC. Return channel time delay (RCTD) is available for all return link data groups and modes for 4800-bit block customers. Requires customer receiver capability to measure Doppler on forward carrier. Additionally, Doppler compensation must be disabled.

3.2.2.1 Virtual Customer Platforms It is normally impossible for two customer platforms to use the same SA antenna at the same time. However if a single customer MOC operates two platforms that dock while on-orbit or that otherwise maintain a close physical relationship while on-orbit, it may be possible for both of these platforms to use the same SA antenna at the same time. This can be done by defining a virtual customer platform with the S-band characteristics of one of the real platforms and the K-band (Ku or Ka) characteristics of the other. Data for this virtual platform can be entered into the NCCDS database in the same manner as is data for any other platform. After the database is established, the MOC's interaction with the SN for the virtual customer platform is the same as for a real platform and SN operations proceed normally. This approach allows both of these

Revision 9

3-7

450-SNUG

Revision 9
19m

White Sands Complex

Second TDRSS Ground Terminal
19m 4.5m 4.5m 19m 4.5m
SGL Antennas S/Ku-Band (note 1) EET Antennas S/Ku-Band (note 2)

Guam Remote Station

White Sands Ground Terminal
18.3m 4.5m 4.5m SGLT-5 18.3m 4.5m GDIS 5.0m

Guam Remote Ground Terminal

16.5m (note 8) 11m 16.5m
SGL Antennas S/Ku-Band EET Antenna S/Ku-Band

SGLT-1

SGLT-2

SGLT-3 SGLT-3: 2 SSA, FWD & RTN (note 5) 2 KuSA, FWD & RTN (notes 3 and 5) Customer Tracking End-to-End Testing

SGLT-4

SGLT-1 and SGLT-2 each provide: Same services as SGLT-3, plus 2 KaSA, FWD & RTN (notes 3 and 5) 1 MA FWD, 5 MA RTN (note 6)

IFL

SGLT-4 and SGLT-5 each provide: Same services as SGLT-3, plus 2 KaSA, FWD & RTN (notes 3 and 5) 1 MA FWD, 5 MA RTN (note 6)

SGLT-6 (note 4): 2 SSA, FWD & RTN (note 5) 2 KuSA, FWD & RTN (note 5) 1 MA FWD, 2 MA RTN (note 6) Customer Tracking End-to-End Testing

SGLT-7 (note 7): 2 SSA, FWD & RTN (note 5) 2 KuSA, FWD & RTN (note 5) 1 SMA FWD, 5 SMA RTN

1. 2. 3. 4. 5. 6. 7. 8.

Notes: The WSGT SGL antennas support Ku-band operations only. Currently, there is no end-to-end test services at Ka-band. Each TDRS F8-F10 supports either KuSA or KaSA services through each SA at a time. There is no requirement to support TDRS F8-F10 through GRGT SGLT-6. The 5.0m EET antenna is provided for redundancy, and is expected to be operational in 2008. The SN can simultaneously support S-band and K-band (either Ku or Ka for F8-F10) forward and/or return services through one SA antenna to the same ephemeris. The SN DAS allows expansion of the TDRSS F1-F7 MAR DG1 mode 2 services well beyond the standard number of return services per TDRS/SGLT. There is no requirement to support TDRS F1-F7 through GRGT SGLT-7. GRGT SGLT-7 is not available for SN Customer services (dedicated set of Customers only). The 16.5m SGL antenna is provided for redundancy for both GRGT SGLT-6 and GRGT SGLT-7, and is expected to be operational in 2008.

3-8 450-SNUG

Figure 3-1. Telecommunications Services for each SGLT

platforms to have SA support on one of a TDRS's SA antennas while leaving the other SA antenna available for other users. Use of this approach is encouraged whenever feasible. For the virtual customer platform concept to be viable, the differences between the vectors for the two real platforms should be small. Either the customer MOC or the FDF must provide the NCCDS with improved interrange vectors (IIRVs) for the virtual platforms. The IIRVs for the virtual platforms can be copies of the IIRVs for either of the two real platforms. Two virtual customer platforms can be defined for a pair of real platforms. One of the virtual customer platforms is defined to have the S-band characteristics of the first real platform and the K-band characteristics of the second real platform. The other virtual customer platform complements the first, and is defined to have the K-band characteristics of the first real platform and the S-band characteristics of the second real platform. 3.2.3 Cross-support Service Overview Any customer platform that is compatible with MA service can use forward or return support from either the TDRSS MA or the TDRSS SSA services. When the forward and return services are supplied by different TDRSS telecommunications services (e.g., MA forward and SSA return), the configuration is called a cross-support service. 3.3 Tracking and Clock Calibration Services The SN provides tracking and clock calibration measurements for MA, SSA, and KuSA customers, as well as SSA/MA cross-support customers. Note that the SN does not provide these services for KaSA customers. Table 3-3 describes the tracking and clock calibration services available for each return link data group and mode. a. Range. Range measurements may be provided when the customer is configured to transmit a PN code on the return link with the epoch synchronized to the epoch of the PN code received on the forward link range channel. b. Doppler. Two-way Doppler measurements may be provided when the customer is configured such that the return link carrier is coherently related to the received forward link carrier. One-way return Doppler measurements may be provided when the return link carrier is not coherently related to a forward link carrier. c. Customer Time Transfer. The time transfer function provides a method to acquire the data necessary to update a customer platform clock. It gives the customer MOC the ability to determine the time difference between the on-board platform clock and Universal Time Coordinated (UTC). To facilitate the time transfer measurement, the customer must cause the platform to note and store the platform clock reading at the time of arrival of the epoch portion of the PN range code. The clock reading must be included in the platform telemetry for processing by the MOC. It is the MOC's responsibility to make the necessary adjustment to the customer clock using the SN-supplied data.

Revision 9

3-9

450-SNUG

d. Return Channel Time Delay (RCTD). RCTD measurements, in conjunction with other data delays, enable the customer MOC to calculate the time onboard the customer platform. RCTD measures the time delay from the SN ground station antenna input to the SN ground station baseband output (at the point of time tagging within the data transport) for each I and Q channel in the return link. Unlike time transfer, RCTD can be measured with either a coherent or noncoherent service. 3.4 Testing Services The SN provides customer test services through the functional capabilities of the SN and its supporting elements. Mutually agreed upon end-to-end tests are conducted to validate all telecommunications system functions, as defined in the applicable Interface Control Documents (ICDs). In addition, operational exercises (i.e., simulations, data flows) are conducted to ensure that operations will satisfy requirements and timelines. a. TDRSS End-to-End Test Services. The TDRSS End-to-End Test (EET) services are provided within each SGLT at WSC. The EET provides customer projects the capability of testing the end-to-end SN data communications through a ground-based simulation of the customer platform to MOC link via TDRSS thus eliminating the need for the actual customer platform. Each EET system can simultaneously provide end-to-end testing of forward, return, and tracking services for one S-band (SSA or MA) and one Ku-band (KuSA) customer. Please note, TDRSS does not provide EET services for KaSA customers. NOTE: Since GRGT has no interface to support receiving and transmitting test data with the customer, end-to-end testing via GRGT is limited to local mode. Refer to Appendix N for further information on end-to-end testing. b. TDRSS Compatibility and SN End-to-End Testing. Customers are provided a set of testing functions prior to and as part of the TDRSS services. This testing consists of the following customer platform compatibility testing and customer/SN simulation testing: 1. Compatibility Testing. A TDRSS CTV and CTL are used to validate customer platform/TDRS RF interface compatibility prior to launch. The customers RF ICD with the SN is one of the primary documents used to develop the Compatibility Test Plan (CTP). The TDRSS CTV/CTL emulate the TDRSS in data modulation/demodulation capabilities and provide an RF relay between the customer platform and a TDRS. Compatibility testing is performed as early as possible after fabrication of the customer platform communication devices (i.e., transceiver, transponder - either the flight model, which is preferred, or the prototype model) is completed. Compatibility tests are normally rerun following

Revision 9

3-10

450-SNUG

2.

resolution of significant problems encountered during the original test or following post-test flight segment design modification. Results of these tests are formally published in the mission-specific Compatibility Test Report. Satisfactory completion of this testing (such as end-to-end Bit Error Rate (BER) tests) and certification is required to meet the SN readiness-for-launch criteria, specifically the statement of TDRSS RF compatibility. Information about TDRSS compatibility testing is contained in Space and Ground Networks Compatibility Test Systems Specifications, 450-SPEC-CTV. SN Simulation Testing. Customer/SN simulation testing is performed before launch, using the customer ground facilities (customer MOC and/or data processing facility), TDRSS, RFSOC/SOC, and CTV/CTL. The purpose of pre-launch simulation testing is to validate SN performance with the customer communications equipment. Validation includes operations checkout, end-to-end tests, and fault simulation tests. SN simulation testing is also provided during the customer's mission operations to validate support procedures. Information for customers about the RFSOC/SOC is contained in SOC/RFSOC Functional Description and Capabilities Document, 450-FDCD-SOC/RFSOC.

3.5

Analysis Services

3.5.1 Network Loading Analysis Services NASAs Network Planning and Analysis System (NPAS) provides the means to assess the capability of the SN to provide service to new and changing missions in terms of resource capacity and resource allocation (scheduling). It is also used to examine future workload and architecture changes and contingency situations. This assessment is typically performed for each new mission, as well as for operational missions with changing needs, before Code 450 commits to provide service. This capability is also used to aid the project/program in its telecommunications design/trade analyses. The applicable analysis is performed any time in the program/project life. 3.5.2 Communications Link and Coverage Analysis Services NASAs Communications Link Analysis and Simulation System (CLASS) provides the capability to perform space communications link evaluations for support via the SN. Information exchange for the RF communications link and coverage analysis begins during the early customer requirements phases and continues until firm coverage requirements and flight segment design are finalized. The CLASS analysis tool is used to help achieve a flight segment telecommunications design which is compatible with the TDRSS, and will achieve the desired level of performance. Design deficiencies (including non-compliance of customer transmit constraints and performance degradations) and possible trade-offs are defined during these analyses. The minimum required Power Received (Prec) equations given in this document are customer guidelines to begin evaluation of SN support services. CLASS analysis will produce more accurate performance projections based upon the specific customer needs. The

Revision 9

3-11

450-SNUG

results of CLASS are used to aid in the development of the RF Interface Control Document (ICD), which is a controlling input to the flight segment telecommunications specifications. The performance parameters in the ICD are defined for each RF link with a zero dB customer margin. Customer links that do not meet RF ICD requirements may be supported by the SN on a best effort basis, where performance is not guaranteed. Completion of the RF ICD is required prior to the Space Network service commitment. 3.5.3 Tracking Analysis Services The FDF can perform tracking analysis services including customer platform trajectory computation and platform history of the on-board oscillator frequency based upon one-way return Doppler data. Pre-launch orbital error analyses may be performed to determine the frequency and interval of tracking data needed to provide the customer platform state vectors at the accuracies required by the customer project. 3.6 Data Distribution/Processing Services and Data Interfaces

3.6.1 Introduction SN data distribution/processing services can be accommodated via a number of interfaces, as shown in Figure 3-2: the Multiplexer/Demultiplexer (MDM)/IP Operational Network (IONet), the High Data Rate Service (> 7 Mbps), the Local Interface (LI), the WSC Transmission Control Protocol (TCP)/Internet Protocol (IP) Data Interface Service Capability (WDISC), the SN DAS, and on a case-by-case basis, Intermediate Frequency (IF) interfaces with the SGLTs. Table 3-4 provides an overview of the capabilities of these interfaces. All WSC return service baseband output is recorded to preserve data in the event of a downstream problem, with the exception of the LI output. For distribution/processing, data that is < 7 Mbps (such as MDM data) goes through the Low Rate Switch (LRS) and data that is above 7 Mbps goes through the High Rate Switch (HRS). SN DAS data does not go through either switch, but instead interfaces directly with the SGLTs, the NISN IONet, and Local Interfaces at WSGT and GRGT. 3.6.2 MDM/IONet The MDM system is a full-duplex 150 channel outbound (return), 30 channel inbound (forward) interface between WSC and the NISN IONet. The Data Interface System (DIS) of STGT and WSGT each contain an MDM, as shown in Figure 3-2. The MDM blocks the outbound data in a NASA-unique 4800 bit block and then encapsulates the block in a User Datagram Protocol (UDP) packet. Similarly, the MDM un-encapsulates and de-blocks inbound data. The IONet is a routed data network that connects the WSC to various customer locations (see Appendix I for additional information on the NISN IONet). Customer ground facilities are equipped with conversion devices to perform the inverse functions of the MDM. This legacy interface is targeted for End of Life in the near future and as such, it is not recommended that any new project interfaces be implemented on it.

Revision 9

3-12

450-SNUG

FWD 370 MHz IF

DAS RTN (via IFL)

STGT

GRGT

DAS RTN

DAS

DAS RTN

LI
FWD IF

SGLT-1
Customer Equipment (370 MHz or 1.2 GHz IF Service)
FWD 370 MHz IF

RTN 370MHz IF (via IFL) FWD/RTN

GDIS SGLT-2
FWD/RTN FWD/RTN (via NISN)

FWD/ RTN

DAS RTN

SGLT-6

RTN IF

370 MHz RTN IF Switch IF

Customer Equipment (370 MHz IF Service)

Revision 9 3-13 450-SNUG

FWD 370 MHz IF

WSGT

RTN 1.2 GHz IF (via IFL) RTN 1.2 GHz IF (via IFL) FWD/RTN RTN 370 MHz IF FWD/ RTN

SGLT-3
RTN 1.2 GHz IF FWD/ RTN

SGLT-4

FWD 370 MHz IF FWD 370 MHz IF

RTN 1.2 GHz IF

RTN 1.2 GHz IF

GDIS
FWD/ DAS RTN RTN

SGLT-5

Customer Equipment (370 MHz IF Service)

1.2 GHz IF Switch

RTN 370MHz IF

DAS RTN DAS RTN DAS RTN (via IFL)

RTN 370MHz IF (via IFL) RTN 370MHz IF (via IFL)

STGT DIS
Low-Rate (LR) & High-Rate (HR) LR Mux/Demux (MDM) HR Mux/Demux (STAT MUX) Line Outage & HR Recording
HR RTN LR FWD/RTN LR FWD/RTN MDM LR FWD/ RTN STAT MUX HR RTN (via IFL)

WSGT DIS
370 MHz IF Switch

DAS

Switching to/from SGLTs

LR & HR Switching to/from SGLTs LR Mux/Demux (MDM) HR Mux/Demux (STAT MUX) Line Outage & HR Recording
STAT MUX HR RTN LR FWD/RTN MDM LR FWD/ RTN HR RTN LR FWD/ RTN

DAS RTN

DAS RTN

RTN 370 MHz IF

LI

WDISC

Site Selector Unit

WDISC

LI

LR FWD/RTN

NISN HRDS

STAT MUX HR RTN

LR FWD/RTN

NISN IONet

Figure 3-2. Data Distribution/Processing Services and Data Interfaces

Table 3-4. Interface Capabilities

Forward Service (note 7) Interface MDM/IONet Data Rate < 7 Mbps per channel (note 1) Encoding Function Provided PSK: N/A SSA PM: Differential encoding from NRZ-L to NRZ-M, NRZ-S, BiL, Bi-M, or Bi-S N/A PSK: N/A SSA PM: Differential encoding from NRZ-L to NRZ-M, NRZ-S, BiL, Bi-M, or Bi-S WDISC < 50 kbps per channel (note 5) PSK or SSA PM: Differential encoding from NRZ-L to NRZM, NRZ-S, Bi-L, Bi-M, or Bi-S BCH encoding Rate 1/2 convolutional encoding N/A < 7.5 Mbps aggregate (up to 50 simultaneous DAS Customer data streams with each DAS channel < 150 kbps) (note 8) note 6 Yes Yes < 512 kbps per channel (note 5) Yes Yes Data Rate < 7 Mbps per channel (note 1) Return Service (note 7) R-S Decoding Function Provided N/A Line Outage Recording Yes

Revision 9 3-14 450-SNUG

High Data Rate Service LI

N/A < 7 Mbps (note 2)

< 48 Mbps per channel (note 3) < 300 Mbps

N/A N/A

Yes (note 4) No

DAS

N/A

IF Service

note 6

N/A

N/A

No

Table 3-4. Interface Capabilities (contd)

Revision 9 3-15 450-SNUG
Notes: 1. The MDM/IONet is limited to a maximum of 7 Mbps per channel; however, due to current loading of the 9 Mbps composite, IONet bandwidth would have to be augmented to accommodate new high-rate MDM customers. 2. The current WSC/GRGT data interface supports up to 7 Mbps; however, upgrades to support up to 25 Mbps are planned. 3. The High Data Rate Service composite data rates are < 48 Mbps. 4. For the High Data Rate Service, high rate recording is provided for data rates between 1.5 Mbps and 50 Mbps. Additionally, rate buffering is provided at playback rates < 48 Mbps for any High Data Rate Service recorded data rate. 5. Higher single channel forward and return data rates may be possible; however, forward rates above 50 kbps and return rates above 512 kbps have the potential to cause overloading of the WDISC. If a customer has a higher data rate requirement, workload analysis and testing will be necessary to ensure that reliable operation is possible. 6. SN IF services are available to customers on a case-by-case basis. The SSA return IF service and KaSA return 650 MHz bandwidth IF service is automated. All other SN IF services require manual configuration and support must be negotiated through GSFC Code 450. All the IF services operate at 370 MHz, except for the KaSA return 650 MHz bandwidth IF service which operates at 1.2 GHz. Automation of the KuSA/KaSA 225 MHz return IF service is being considered for implementation. Contact Code 450 for availability. Once automation is complete, customers will be able to schedule either a SSA return IF service or a KuSA/KaSA 225 MHz return IF service, but not simultaneously. 7. For SN customers using GRGT services: The GRGT WSGT connection via NISN is currently limited in bandwidth to a 45 Mbps composite. New customers intending to use GRGT services should consult with GSFC Code 450 regarding GRGT to WSGT bandwidth utilization. In case of a break in communications between GRGT and WSGT during a customer return service, there is no provision to record data at GRGT. 8. The DAS aggregate data rate shown is the maximum capability of the DAS data distribution equipment. For SN customers that receive DAS MAR data via the NISN IONet, the operational bandwidth allocated to DAS is managed by NISN and subject to change depending on SN and NISN operational requirements.

3.6.3 High Data Rate Service The High Data Rate Service is a four channel outbound (return) service that is provided via the Statistical Multiplexer (STAT MUX) located in the STGT and WSGT DIS and the NISN High Rate Data System (HRDS) (a full-period leased C-band domestic communications satellite transponder), as shown in Figure 3-2 (see Appendix I for additional information on the NISN HRDS). The STAT MUXs only support the Shuttle. They are targeted for End of Life and will be used until the end of Shuttle support in 2010. The receive location of this support is the JSC. 3.6.4 Local Interface Customers can provide interfaces at the ground terminals, as shown in Figure 3-2. Local interfaces are serial clock and data. 3.6.5 WDISC The WDISC supports customers who require TCP/IP access to the WSC for telemetry and command processing. WDISC is located at both STGT and WSGT, as shown in Figure 3-2. WDISC supports up to six simultaneous forward data channels and six simultaneous return data channels at both STGT and WSGT. WDISC customers who make use of GRGT are supported by the WDISC located at WSGT. The SN customer MOC sends commands and data playback requests to WDISC via the NISN IONet. The WDISC sends real-time IP-encapsulated data and playback data files to the MOC, also via the NISN IONet. Refer to Appendix Q for more detailed WDISC information. 3.6.6 DAS The SN DAS provides distribution of DAS MAR service data to customers via a TCP/IP interface to the NISN IONet and/or customer-provided LI equipment. DAS data distribution equipment is located at WSGT and GRGT, as shown in Figure 3-2. Refer to Appendix H for more detailed DAS information. 3.6.7 IF Services SN SSA, KuSA, and KaSA forward and return IF services are available to customers on a case-by-case basis. The SSA return IF service has been automated and operates at 370 MHz. The KaSA return 650 MHz bandwidth IF service has also been automated; however, it operates at 1.2 GHz. The KuSA/KaSA 225 MHz return IF service is not currently automated; however, automation of this service is being considered for implementation. Contact Code 450 for availability. The KuSA/KaSA 225 MHz return IF service also operates at 370 MHz. After implementation of the automated KuSA return IF service, customers will be able to schedule either a SSA return IF service or a KuSA/KaSA 225 MHz return IF service, but not simultaneously. The flow of the SSA, KuSA, and KaSA return IF service signals from the SGLTs through the appropriate IF switches to customer equipment is shown in Figure 3-2. MA/SMA forward and return services and SSA, KuSA, and KaSA forward services are not automated and require the use of the 370 MHz IF ports located in each of the SGLTs, as shown in Figure 3-2. Any special purpose customer equipment used

Revision 9

3-16

450-SNUG

for processing data at the return IF ports and the unmodulated IF forward ports will require manual configuration. Any Doppler compensation required for acquisition and tracking of the customer signal or the forward link will be provided by the customer equipment. 3.6.8 GRGT Constraints The GRGT WSGT interface is through a system called the Guam Data Interface System (GDIS), with the communications connection provided via NISN. While the GDIS is capable of transporting a total composite data rate of up to 45 Mbps, the GRGT to WSGT connection is currently limited in bandwidth to a 26 Mbps composite for all customer traffic. New customers intending to use GRGT services should consult with GSFC Code 450 regarding GRGT to WSGT bandwidth utilization. In case of a break in communications between GRGT and WSGT during a customer return service, there is no provision to record data at GRGT.

Revision 9

3-17

450-SNUG

This page intentionally left blank.

Revision 9

3-18

450-SNUG

Section 4. Obtaining SN Services

4.1 Overview The information in this section describes the process for obtaining SN services, which is termed the Customer Commitment Process. The process is described in the Code 450.1 Customer Commitment Process, 450-PG-1310.1.1. The objective of the Customer Commitment Process is to ensure that customer requirements are documented, and that services are provided to meet customer objectives at the lowest life cycle cost. This process incorporates the following principles: a. Establish contact between the Networks Integration Management Office (NIMO) (Code 450.1) and potential customers as early in the planning phase as possible to assure those mission concepts are developed with full information about Code 450 services. b. Proactively support customers in capturing requirements by progressively refining these requirements as their concepts evolve. c. Maintain flexibility in working with potential customers to analyze alternative flight/ground system concepts, innovative approaches, and cost trades. Code 450 is responsible for overall commitment of services and facilities to support NASA and non-NASA customers. The Network Integration Managers (NIMs) ensure that all requirements and commitments are integrated, and that RF, loading and coverage analyses are performed to ensure services are feasible. 4.2 Authorities and Responsibilities Authority and responsibility for managing the SN, including the Customer Commitment Process is the responsibility of the Code 450 Program at GSFC. The NIMO is responsible for coordinating and providing customer services. The Space Network Project (Code 452) is responsible for the management and operations of the TDRSS and the SN ground terminal. The Space Network Program Plan also describes these efforts. 4.3 Procedures for Obtaining SN Support Initially the customer must contact the NIMO and provide adequate information for RF engineering analyses, loading analyses, and coverage analyses. Then SN loading studies and preliminary analysis of the capability of the SN to provide services are completed. A determination is made as to whether the customer requires any modifications to the SN in order to meet their requirements. After these determinations are made, proper documentation is prepared, testing is conducted, and services provided. Should modifications to the SN be required for customer services, then additional documentation is prepared and funding supplied by the customer.

Revision 9

4-1

450-SNUG

4.4 System Reviews NIMO conducts Network Requirements Reviews (NRRs) to confirm requirements and Mission Operations Readiness Reviews (MORRs) to confirm SN readiness to provide services. The MORR also includes FDF and NISN readiness, if they are providing customer services. 4.5 SN Services and Mission Support Documentation

4.5.1 General The NASA documentation system for providing space-communication services to customers recognizes basic required documents, as follows: a. Project Service Level Agreement (PSLA): A formal agreement between NASA and the customer for services, at a specific cost, within a specific time frame. b. Network Requirements Documents (NRD): Documents the customer's detailed SN requirements. c. Radio Frequency (RF) Interface Control Document (ICD): Describes the specific radio frequency interface details. The RF ICD is a required document intended to be developed early in the design phase to drive the spacecraft RF telecommunications design. Example RF ICDs can be found in the Code 400 Library on the GSFC Centralized Configuration Management System (CCMS) at http://gdms.gsfc.nasa.gov. d. Network Operations Support Plan (NOSP): Provides operational procedures and configurations information required by the SN. e. Other documents include the Compatibility Test Plan and Test Report; the Customer Integration Test Pan and Test Report; and, the Lessons Learned Report. 4.5.2 Space Transportation System (STS) Documentation Support requirements for the STS and payloads embedded within the STS are published by JSC and KSC. Because of the nature of the STS hardware and procedural interfaces, the STS launch phase ground system utilization is characterized by both standardized and optional space-to-ground and ground-to-ground services. These services are negotiated and documented between the STS customer and JSC and KSC, directly, via the Payload Integration Plan (PIP) documentation system. The purpose of the PIP is to: a. Define responsibilities of the customer and the Space Shuttle Program. b. Define the technical baseline for implementation. c. Establish guidelines and constraints for integration and planning. d. Define integration task to be accomplished. e. Establish interface verification requirements. f. Establish operational services requirements. g. Establish controlling schedules for all major integration activities.

Revision 9

4-2

450-SNUG

h. Identify Space Shuttle Program flight and ground safety requirements. i. Establish the basis for Space Shuttle Program definition and pricing of optional services. JSC and KSC, in turn, formally negotiate with Code 450 on behalf of the manifested STS customer (or customers) for each STS flight. This process is carried out by using the Program Requirements Document (PRD) and the associated methodology for integrating Orbiter and composite payload requirements for SN and ground system services before submitting these requirements for implementation by Code 450. 4.5.3 Configuration Management Configuration control over the SN service and customer services documentation is maintained through the Code 450.1 Configuration Control Board (CCB). The Configuration Change Request (CCR) form is obtained from the Code 450.1 Configuration Management Office (CMO).

Revision 9

4-3

450-SNUG

This page intentionally left blank.

Revision 9

4-4

450-SNUG

Section 5. MA Telecommunications Services

5.1 General

5.1.1 Available Services TDRSS MA services include forward and return telecommunications services, and tracking services. Tracking services are discussed in Section 9. This section focuses on the RF interface between the TDRS and the customer platform. This interface is characterized by the technical requirements imposed and the operational capabilities provided by the TDRSS. The operational interfaces are described in further detail in Section 10. Data interfaces between the customer MOC and the SN are described in paragraph 3.6. The SN Demand Access System (DAS) allows expansion of the TDRSS F1-F7 MAR Data Group 1 (DG1) mode 2 services to be scheduled for extended duration or in a near real time manner. This section will discuss the general MAR service capabilities; however, Appendix H should be referenced for any specific capabilities or limitations of DAS. NOTE: Unless denoted by the TDRS fleet, the term MA is used throughout this document to denote MA services through TDRS F1-F7 and TDRS F8-F10. If the term SMA is used, these capabilities are specific to TDRS F8-F10. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessible via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. GSFC Code 450 uses the NAM as a means of letting customers know of any performance constraints associated with the TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452PLAN-0002. 5.1.2 Interface Definition The RF interface between the TDRS and a customer platform is defined in terms of signal parameters, RF characteristics, and field of view. a. The RF interface for forward service represents the transmission by a TDRS of an appropriately modulated signal at or greater than a minimum specified signal EIRP in the direction of the desired customer platform. MA forward (MAF) service is discussed in paragraph 5.2.

Revision 9

5-1

450-SNUG

b. The RF interface for return service defines a minimum received power (Prec) at the TDRS antenna input for a specified data quality at the SN ground terminal receiver output. MA return (MAR) service is discussed in paragraph 5.3. 5.1.3 Customer Acquisition Requirements Acquisition and reacquisition by the customer platform of the TDRS transmitted signal requires prediction by the customer MOC of the customer platform receive frequency over various projected time periods. Similarly, acquisition and reacquisition by the SN ground terminal of the customer platform signal requires prediction by the customer MOC of the customer platform transmitter frequency over various projected time periods. The frequency predictions are ultimately incorporated in the Schedule Order (SHO) as customer platform frequencies for the specific service support periods. Refer to Section 9 for additional information on TDRSS tracking services that can assist customers in predicting their local oscillator frequencies. 5.1.4 TDRSS Acquisition Support to Customers For each scheduled TDRSS service support period, the customer requirements for signal acquisition/reacquisition and the TDRSS capabilities to aid acquisition/ reacquisition are as follows: a. Customer Epoch Uncertainty. The maximum epoch uncertainty of the customer platform ephemeris supplied to the TDRSS should be +9 seconds for the MA LEO Field of View (LEOFOV) and the Primary Field Of View (PFOV) as defined in Table 5-2 for MAF and for MAR services. b. Customer Frequency Uncertainty. The customer MOC must know the operating frequency of the customer platform to within +700 Hz. c. Forward Frequency Sweep. After the start of the forward link service, the TDRSS has a forward service frequency sweep capability of +3 kHz. d. Noncoherent Return Expanded Frequency Search. After the start of the noncoherent return link service, the TDRSS has a return service expanded frequency search capability to accommodate a customer platforms operating frequency uncertainty of up to +3 kHz for MAR DG1, SMAR DG1, and SMAR SQPSK DG2 services. Similarly, the TDRSS has a return service expanded frequency search capability to accommodate a customer platforms operating frequency uncertainty of up to +35 kHz for the SMAR BPSK and non-staggered QPSK DG2 services. 5.2 MA Forward Services

5.2.1 General The characteristics of the data provided to the SN ground terminal interface and the RF signals provided by the TDRS to the customer platform during TDRSS MA forward services are outlined in paragraphs 5.2.2 through 5.2.5. This discussion assumes that an appropriate forward service has been scheduled and a data signal is present at the SN ground terminal interface.

Revision 9

5-2

450-SNUG

5.2.2 Signal Parameters The TDRSS MA forward service signal parameters are defined in Table 5-1. The center frequency (fo) of the customer platform receiver must be defined by the customer MOC in its service specification code for TDRSS MA forward service (refer to Section 10, paragraph 10.2.2). A description of the features inherent in the QPSK and BPSK signal parameters listed in Table 5-1 are discussed in paragraph 5.2.2.1. 5.2.2.1 QPSK Signal Parameters a. Unbalanced QPSK Modulation. The I channel is used to transmit the customer command data and is referred to as the command channel. The Q channel transmits a range signal and is referred to as the range channel. The command channel/range channel power ratio for QPSK forward service signals is +10 dB. This unbalanced QPSK modulation minimizes the power in the range channel to a level adequate for customer platform range channel acquisition and tracking. This feature increases the power in the command channel by 2.6 dB over that for balanced QPSK modulation without increasing customer platform receiver complexity, increasing customer platform command channel acquisition time, or decreasing TDRSS range tracking accuracy. b. Spread Spectrum. TDRSS MA forward services with data rates equal to and below 300 kbps must incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed upon the TDRSS forward services by the NTIA. This modulation scheme includes separate but simultaneous command and range channels. The command channel includes a rapidly acquirable PN code and contains the forward service data. The range channel is acquired separately and contains a PN code which satisfies the range ambiguity resolution requirements. The length of the command channel PN code is 210-1, where the length of the range channel PN code is 256 times the command channel PN code length. The customer platform command channel acquisition can precede customer platform range channel acquisition; this feature permits rapid acquisition of the range channel by limiting the range channel PN code search to only 256 chip positions while the range channel PN code itself contains 261,888 chips. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward range and command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments.

Revision 9

5-3

450-SNUG

Table 5-1. TDRSS MA Forward PSK Service Signal Parameters

Parameter TDRS transmit carrier frequency (Hz) Carrier frequency arriving at customer platform (Hz) (note 1) Carrier frequency sweep (note 3) Carrier frequency sweep duration (note 3) QPSK (PN modulation enabled)
Command channel radiated power Range channel radiated power

Definition F FR +3 kHz 120 seconds +10 dB

QPSK Command Channel Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Transmit carrier frequency (F) Phase Shift Key (PSK), + /2 radians 30 dB minimum 2 1 Refer to 451-PN CODE-SNIP Gold codes
31 221 96 F
10

Data modulation Data format (note 2) Data rate restrictions (note 2) QPSK Range Channel Carrier PN code modulation Carrier suppression PN code chip rate PN code length PN code epoch reference PN code family

Modulo-2 added asynchronously to PN code Not Applicable 0.1 - 300 kbps Command channel carrier frequency delayed /2 radians PSK, + /2 radians 30 dB minimum Synchronized to command channel PN code chip rate (210 - 1) x 256 All 1's condition synchronized to the command channel PN code epoch Truncated 18-stage shift register sequences

Revision 9

5-4

450-SNUG

Table 5-1. TDRSS MA Forward PSK Service Signal Parameters (contd)

BPSK (PN modulation enabled; also referred to as Spread Spectrum BPSK (SS-BPSK)) (note 4) Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Transmit carrier frequency (F) Phase Shift Key (PSK), + /2 radians 30 dB minimum 2 1 Refer to 451-PN CODE-SNIP Gold codes
31 221 96 F
10

Data modulation Data format (note 2) Data rate restrictions (note 2)

Modulo-2 added asynchronously to PN code Not Applicable 0.1 - 300 kbps

Notes: 1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. The SN ground terminal will round-off the customer receive frequency contained in the SHO to the nearest multiple of 221 Hz. & Doppler compensation will be available for R <12 km/sec. During periods of Doppler compensation, FR = fo +E Hz; where fo = multiple of 221 nearest the nominal center frequency of && customer platform receiver as defined by the customer MOC and E = e x fo x R /c + C; e < +9 && && sec is the customer epoch uncertainty, R <15 m/sec2 (MA), R <50 m/sec2 (SMA), c is the free space speed of light in m/sec, and C = 400 Hz. If Doppler compensation is inhibited after the start of the forward service, a transition profile will be initiated to slowly change the frequency from the compensate profile to this integer multiple of 221 Hz. Forward service Doppler compensation will not increase the effective frequency rate of change seen at the customer receiver more than 28 Hz/sec relative to the frequency for a Doppler-free carrier. 2. The forward data rate in this table is the baud rate that will be transmitted by the TDRSS (includes all coding and symbol formatting). For non-WDISC customers, forward data conditioning is transparent to the SN. These transparent operations should be performed by the customer prior to transmission to the SN data interface. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. 3. After the start of the MA forward service, if a customer MOC is unable to accurately define fo (the nominal center frequency of the customer platform receiver), the forward service carrier frequency can be swept. The MA forward service frequency sweep will be initiated by the SN ground terminal at fo-3 kHz and linearly swept to fo+3 kHz in 120 seconds and held at fo+3 kHz thereafter. The MA forward service frequency sweep does not impact simultaneous SN ground terminal Doppler compensation of the MA forward service carrier and PN code rate (if applicable). 4. Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required.

Revision 9

5-5

450-SNUG

c.

Asynchronous Data Modulation. For data rates < 300 kbps, the forward service data received at the SN ground terminal from the NISN data transport system is directly modulo-2 added by the SN ground terminal to the command channel PN code sequence. The forward service data will be asynchronous with the carrier and the PN code. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is the command channel PN code sequence.

d. Functional Configurations: A further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.2.2. e. Doppler Compensation. The TDRSS MA forward service carrier frequency (F) and the PN chip rate transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 5-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS MA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency MA forward service carrier and PN code chip rate. 5.2.2.2 BPSK Signal Parameters a. BPSK Modulation (PN Modulation Enabled). The I channel is used to transmit the customer command data and is referred to as the command channel. TDRSS MA forward services with data rates equal to and below 300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed on the TDRSS forward services by the NTIA. The command channel includes a rapidly acquirable PN code and contains the forward service data. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments.

Revision 9

5-6

450-SNUG

NOTE: Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required. b. Asynchronous Data Modulation. The forward service data will be asynchronous with the carrier. c. Functional Configurations. A further description of the functional configurations and data polarity ambiguity is found in Appendix B, paragraph B.2.2. d. Doppler Compensation. The TDRSS MA forward service carrier frequency (F) transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 5-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS MA forward service signal. Customers are encouraged to utilize GT Doppler compensation unless the customer is relying on measuring the Doppler onboard for tracking data. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency MA forward service carrier. 5.2.3 Communications Services The TDRSS MA forward services available are listed in Table 5-2. Table 5-3 lists their salient characteristics. The definitions for the parameters listed in Table 5-3 are contained in Appendix E. 5.2.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRS MA forward service during a scheduled service support period are usually initiated by a Ground Control Message Request (GCMR) from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for the GCMRs is provided in Section 10. Table 5-4 lists the MA forward service real-time configuration changes and their effects on the forward service signal.

Revision 9

5-7

450-SNUG

Table 5-2. TDRSS MA Forward Service

Parameter Field of view (each TDRS) Customer Ephemeris Uncertainty TDRS antenna polarization TDRS antenna axial ratio (maximum) TDRS signal EIRP (minimum) SMAF via TDRS F8-F10 (note 2) MAF via TDRS F1-F7 Transmit frequency (nominal) (refer to note 1) RF bandwidth (3 dB minimum) Duty factor Description Primary (PFOV) +13 degrees conical < + 9 sec Left-hand Circular (LHC) 1.5 dB over 3-dB formed beamwidth Primary (PFOV) +40 dBW +34 dBW LEOFOV +42 dBW +34 dBW
240

LEO (LEOFOV) +10.5 degrees conical < + 9 sec

[2287.5 0.1] 221 MHz

6 MHz 100 percent

Notes: 1. The customer MOC must include the best estimate of the customer platform receiver center frequency at the start time of each scheduled service support period in its service specification code (refer to Section 10, paragraph 10.2.2). The TDRSS MA forward service carrier frequency is then implemented by the SN ground terminal to the accuracy of the SN ground terminal frequency standard except during Doppler compensation. 2. F8 is unavailable for normal customer scheduling.

Revision 9

5-8

450-SNUG

Table 5-3. Salient Characteristics for TDRSS MA Forward Services

Parameter (Note 1)
Command channel radiated power (QPSK only) Range channel radiated power

Description (Note 1) +10 + 0.5 dB

Modulator phase imbalance (peak) Modulator gain imbalance (peak) Relative phase between command and range channels (QPSK only) Data asymmetry (peak) (Note 2) Data rise time (90 percent of initial state to 90 percent of final state) (Note 2) Phase nonlinearity (peak) Gain flatness (peak) Gain slope (peak) AM/PM PN chip jitter (rms) (including effects of Doppler compensation) Data bit jitter (peak) (Note 2) Spurious PM (rms) In-band spurious outputs Incidental AM (peak) Phase noise (rms): 1 Hz - 10 Hz 10 Hz - 32 Hz 32 Hz - 1 kHz 1 kHz - 3 MHz Command/range channel PN chip skew (peak) (QPSK only) PN chip asymmetry (peak) PN chip rate (peak) relative to absolute coherence with carrier rate

+3 degrees (for each BPSK channel) +0.25 dB 90 +3 degrees +3 percent <5 percent of data bit duration +0.12 radian over +2.1 MHz +1.2 dB over +2.1 MHz +0.1 dB/MHz <13 degrees/dB <1 degree <1 percent <1 degree >27 dBc <2 percent <1.5 degrees <1.5 degrees <4.0 degrees <2.0 degrees <0.01 chip <0.01 chip <0.01 chips/sec at PN code chip rate

Notes: 1. The definitions and descriptions of the salient characteristics are provided in Appendix E. 2. These values are the TDRSS contributions for data asymmetry, data transition time, and bit jitter, assuming perfect forward service data is provided to the SN ground terminal. The actual contributions by the NISN data transport system are negligible compared to those contributed by the TDRSS, since the SN ground terminal reclocks the data before it is processed by the SN ground terminal into the forward service signal.

Revision 9

5-9

450-SNUG

Table 5-4. MA Forward Service Real-Time Configuration Changes

Real-Time Configuration Changes Customer Receiver Center Frequency Doppler Compensation Inhibit Doppler Compensation Reinitiation Forward Service Reacquisition (note) Forward Service Sweep Request (refer to Table 5-1 note 3) Data Rate GCMR 98/04 98/08 98/04 98/03 98/05 98/04 OPM OPM 03 OPM 11 OPM 03 OPM 02 OPM 04 OPM 03 Forward Service Signal Interruption Yes No No Yes Yes No

Note: Forward service reacquisition is a TDRSS reinitiation of forward link service by applying a 1 MHz frequency offset for 3 seconds to the predicted customer receive frequency specified in the customers service specification code (refer to Section 10, paragraph 10.2.2).

5.2.5 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS MA forward service signal acquisition by the customer platform and do not include operational procedures related to acquisition: a. The TDRSS MA forward service signal does not depend on a customer platform return service. b. Prior to the start of the spatially formed TDRS MA forward service, the TDRSS MA antenna beam will be open-loop pointed in the direction of the customer platform. c. At the start of the TDRSS MA forward service as defined by the SHO, the TDRS will radiate, in the direction of the customer platform, a signal compatible with the TDRSS MA forward service signal parameters listed in Table 5-1. The TDRS signal will be transmitted at the scheduled EIRP consistent with the values listed in Table 5-2. The signal transmitted towards the customer platform is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 5-2. d. The customer platform receiving system will search for and acquire the command channel PN code and carrier. Normally, a customer MOC will not be transmitting forward service data to the NISN data transport system until the forward service signal has been acquired by the customer platform and the acquisition verified by the customer MOC from the customer platform return service telemetry. If the NASA fourth generation standard transponder is used, its design implementation requires that there be no data transitions during the signal acquisition process, while others may merely result in longer acquisition times.

Revision 9

5-10

450-SNUG

e. The customer platform receiving system will search for and acquire the range channel PN code upon acquisition of the command channel PN code and carrier. f. Depending upon customer platform receiving system design, upon completion of forward link acquisition and subsequent customer platform transition to signal tracking, the customer platform transmitting system may either switch to a coherent mode or remain in a noncoherent mode until commanded by the customer MOC to switch. g. The SN ground terminal will continue Doppler compensation of the TDRSS MA forward service signal unless requested by the customer MOC to inhibit the Doppler compensation. h. Tacq in the customer platform receiver is a function of the customer platform receiver design and signal-to-noise density ratio. For the purpose of an example, Table 5-5 provides the acquisition characteristics for the fourth generation transponder when receiving an MA QPSK signal. The Tacq values listed in Table 5-5 are contingent on the customer MOC defining the customer platform receiver center frequency, fo, to an accuracy of +700 Hz in each service support schedule add request (SAR). The customer platform forward service acquisition time must be considered in determining the overall return service acquisition time for customer platform with a coherent mode of operation. i. Appendix A provides example link calculations for the TDRSS MA forward service.

Table 5-5. MA Forward Service Example Acquisition Times for the Fourth Generation NASA Standard Transponder
S/N0 (notes 1,3) 34 dB-Hz > 37 dB-Hz Command Channel PN Code (note 2) < 20 sec < 7 sec Carrier (note 2) < 5 sec < 5 sec Range Channel PN Code (note 2) < 10 sec < 10 sec Total (note 2) < 35 sec < 22 sec

Notes: 1. S/N0 is the signal to noise density ratio (dB-Hz) at the customer platform transponder input. 2. With a probability > 90%. Carrier acquisition starts after the command channel PN code has been acquired. Range channel PN code acquisition starts after the carrier has been acquired. 3. For further specific information on the Fourth Generation user transponder, reference should be made to 531-RSD-IVGXPDR.

Revision 9

5-11

450-SNUG

5.3

MA Return Services

5.3.1 General The RF signals provided by the customer platform to the TDRS and the characteristics of data provided at the SN ground terminal interface are defined in paragraphs 5.3.2 through 5.3.5. This discussion assumes that an appropriate return service has been scheduled and a data signal is present at the TDRS interface. NOTE: The F8 spacecraft has some SMA return G/T performance variations due to an MA element array and sunshield proximity problem. The F8 G/T varies based upon the normal daily TDRS diurnal cycle. This section documents the required Prec values for both the F8 hot and cold conditions. The hot periods can be predicted and will occur at regular intervals with a total hot period of less than 12 hours/day. Note that F8 is unavailable for normal customer scheduling. 5.3.2 Signal Parameters The TDRSS MA return service signal parameters are listed in Table 5-6. The services are divided into 2 major groups, Data Group 1 (DG1) and Data Group 2 (DG2). DG1 services utilize spread spectrum modulation while DG2 services are non-spread. A description of the features inherent in the DG1 and DG2 services is discussed in 5.3.2.2 and 5.3.2.3, respectively. Within each data group, there are several types of modulation. Additionally, both data groups support coherent and noncoherent modes. A description of these general characteristics is provided in 5.3.2.1.

Revision 9

5-12

450-SNUG

Table 5-6. TDRSS MA Return Service Signal Parameters

Parameter (Note 6) DG1 (note 1) Transmit carrier frequency (Hz) (note 5) Carrier (F1) reference (Hz) DG1 mode 1 DG1 mode 2 PN code modulation DG1 modes 1 and 2 DG1 mode 3, I channel (SMA via F8-F10) PN code chip rate (chips/sec) PN code length (chips) DG1 modes 1 and 3 DG1 mode 2 PN code epoch reference DG1 mode 1 I channel Epoch (all 1's condition) synchronized to epoch (all 1's condition) of received forward service range channel PN code Epoch delayed x + 1/2 PN code chips relative to I channel PN code epoch Not Applicable Same as DG1 mode 1 (I channel) Truncated 18-stage shift register sequences Gold codes Modulo-2 added asynchronously to PN code Modulo-2 added asynchronously to PN code PSK +/2 radians (2 - 1) x 256 2 1
11 10

Definition (Note 6) F1

240 FR 221

Customer platform transmitter oscillator SQPN, BPSK (refer to Appendix B and Table 5-7) PSK +/2 radians
31 F1 [240 96]

Q channel (note 3) DG1 mode 2 DG1 mode 3, I channel PN code family DG1 mode 1 DG1 mode 2 Data modulation: DG1 modes 1 and 2 DG1 mode 3: (SMA via F8-F10) I channel Q channel

Revision 9

5-13

450-SNUG

Table 5-6. TDRSS MA Return Service Signal Parameters (contd)

Parameter (Note 6) DG1 (note 1) Periodic convolutional interleaving (note 4) Data Format Symbol Format DG1 mode 1 data rate restrictions (rate 1/2 convolutional encoded) Total (note 1) I channel Q channel DG1 mode 2 data rate restrictions (rate 1/2 convolutional encoded) Total (note 1) I channel Q channel DG1 mode 3 data rate restrictions (rate 1/2 convolutional encoded) (SMA via F8-F10) Total (note 1) I channel Q channel DG1
Q channel power I channel power

Definition (Note 6) Recommended for baud rates > 300 kbps NRZ-L, NRZ-M, NRZ-S NRZ

0.1 - 300 kbps 0.1 - 150 kbps 0.1 - 150 kbps

1 - 300 kbps 1 - 150 kbps 1 - 150 kbps

I (max) + Q (max) 0.1 - 150 kbps 1 kbps 1.5 Mbps restrictions (note 2) 1:1 1:1 to 4:1 NA 1:1 to 4:1 F2

Single data source-alternate I/Q bits (SMA via F8-F10) Single data source-identical data Single data source-single data channel Dual data sources DG2 (SMAR via F8-F10) (note 1) Transmit carrier frequency (note 5) Carrier (F2) reference (Hz) DG2 Coherent DG2 Noncoherent Data modulation (note 1)

240 FR 221

Customer platform oscillator BPSK, SQPSK, or QPSK (refer to Appendix B and Table 5-7)

Revision 9

5-14

450-SNUG

Table 5-6. TDRSS MA Return Service Signal Parameters (contd)

Parameter (Note 6) DG2 (SMAR via F8-F10) (note 1) Periodic convolutional interleaving (note 4) Symbol format Data format Data rate restrictions (rate 1/2 convolutional encoded) Total (note 1) I channel Q channel DG2
I channel power restrictions Q channel power

Definition (Note 6) Recommended for baud rates > 300 kbps NRZ, Bi-L NRZ-L, NRZ-M, NRZ-S

I (max) + Q (max) 1 kbps 1.5 Mbps 1 kbps 1.5 Mbps

Single data source-alternate I/Q bits Single data source-alternate I/Q encoded symbols Single data source-single data channel Dual data sources 1.

1:1 1:1 NA 1:1 or 4:1

2.

3. 4.

5. 6.

Notes: Customer platform data configurations, including specific data rate restrictions for coding and formatting, are defined in Table 5-7 for TDRSS MA return service (refer also to Appendix B). Unless otherwise stated, the data rate restrictions given in this table assume rate 1/2 convolutional encoding and NRZ formatting. For DG1, the Q/I power parameter range can vary from 1:1 to 4:1 continuously during specification of applicable parameter values in the NCCDS scheduling database and during real-time service reconfiguration. However if this parameter is respecified in schedule requests to the NCCDS (refer to paragraph 10.2.2), it is expressed as the ratio of two single-digit integers. The Q channel PN code sequence must be identical to the I channel PN code sequence, but offset by x + 1/2 PN chips, where x >20,000. The value of x is defined by the PN code assignment for a particular customer platform (refer to 451-PN CODE-SNIP). Periodic convolutional interleaving (PCI) is recommended on S-band return services for channel baud rates > 300 kbps. Biphase symbol formats are not allowed with PCI. When interleaving is not employed for channel baud rates > 300 kbps, S-band return performance may not be guaranteed. The center frequency, fo, of the customer platform transmitter must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. Unless otherwise noted, all data rate values are to be interpreted as data bit rates, and not as data symbol rates.

Revision 9

5-15

450-SNUG

Revision 9 5-16 450-SNUG

Table 5-7. MA/SMA Return Service Configurations

Return Service Configuration10 Source Data Rate Restrictions and Availability9 DG1 Mode DG2 Mode (SMA only) 11 and 21,4,8 32 (SMA only) Coherent3 and Noncoherent3,4 Data format Data rate Data format Data rate Data format Data rate NRZ <150 kbps1 NRZ 1 kbps 1.5 Mbps5 NRZ with biphase symbols NRZ NRZ with biphase symbols
7

Single Data Source

BPSK

Rate 1/2 coded

1 kbps 0.75 Mbps5,6 1 kbps 1 Mbps5 1 kbps 0.5 Mbps5,6

7

Rate 1/3 coded Uncoded Identical I & Q channel data

SQPN

Rate 1/2 coded

NRZ

<150 kbps -

SQPSK SQPN1 or SQPSK3

Dual Data Sources (data rates are for each source separately)

SQPN1, QPSK2,3 or SQPSK3

Uncoded Rate 1/2 coded alternate I/Q encoded symbols Individually rate Alternating I/Q 1/2 coded data Individually rate 1/3 coded Uncoded Rate 1/2 coded

NRZ 7

<300 kbps (SMA only) 7

NRZ

I: 0.1-150 kbps Q: 1 kbps 1.5 Mbps Q: 1 kbps 1Mbps

7

NRZ NRZ NRZ

7

1 300 kbps 1 kbps 3 Mbps5 1 kbps 2 Mbps5

7

NRZ

<150 kbps

NRZ NRZ with biphase symbols NRZ NRZ with biphase symbols
7

Rate 1/3 coded Uncoded

NRZ

1 kbps 1.5 Mbps5,11 1 kbps 0.75 Mbps5,6,11 1 kbps 1 Mbps5,11 1 kbps 0.5 Mbps5,6,11
7,11

Table 5-7. MA/SMA Return Service Configurations (contd)

Revision 9 5-17 450-SNUG
Configuration supported Notes: Configuration not supported For DG1 mode 1 and 2 configurations, where the minimum source data rates are 0.1 kbps for DG1 mode 1 and 1 kbps for DG1 mode 2: a. Data on a single I or Q channel, but not both channels: BPSK modulation is used where the data is modulo-2 added to the PN code. b. Data on both the I and Q channels: SQPN modulation is used and the SN supports I:Q power ratios of 1:1 to 1:4 for all the configurations, except the alternating I and Q data bit configuration, which requires a balanced I:Q power ratio. c. The alternating I/Q data bit configuration: the SN requires the I channel lead the Q channel by a half symbol. Similarly, the SN requires the I and Q channels be independently differentially formatted (-M,-S). For DG1 mode 3 configurations: a. The modulation is QPSK, where the I channel data is modulo-2 added to the PN code, and the Q channel data directly modulates the carrier at +/2 radians. b. The SN supports I:Q power ratios of 1:1 to 1:4. c. Rate 1/3 coding is supported for the Q channel only. (Rate 1/2 coding is supported on both the I and Q channels.) For DG2 configurations: a. Single data source configurations with data on one channel: BPSK modulation is used. b. Single data source configurations with data on both channels: SQPSK modulation and an I:Q power ratio of 1:1 is used. For the alternate I/Q bit configuration, the SN requires the I and Q channels be independently differentially formatted (-M,-S). c. Dual data source configurations: SQPSK must be used when there are identical baud rates on the I and Q channels (see paragraph 5.3.2.1.b); QPSK is used for all other configurations; for both SQPSK and QPSK, either an I:Q power ratio of 1:1 or 4:1 is supported. For unbalanced QPSK, the I channel must contain the higher data rate and when the data rate on the I channel exceeds 70 percent of the maximum allowable data rate, the Q channel data rate must not exceed 40 percent of the maximum allowable data rate on that Q channel. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 700 Hz. If a customer cannot accurately define their transmit frequency to within + 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 3 kHz for DG1 and SQPSK DG2 configurations and + 35 kHz for BPSK and QPSK DG2 configurations after the start of service. Periodic convolutional interleaving (PCI) is recommended on S-band return service for channel baud rates > 300 kbps. When interleaving is not employed for channel baud rates > 300 kbps, S-band performance may not be guaranteed. Biphase symbol formats are not allowed with PCI. Use of biphase symbol formats on S-band services at baud rates > 300 kbps should be coordinated with GSFC Code 450. For all configurations and modes, the SN is capable of providing SMA support of uncoded links; however, performance is not guaranteed in RFI and must be coordinated with GSFC Code 450. The SN Demand Access System (DAS) allows expansion of the TDRS F1-F7 MAR Data Group 1 (DG1) mode 2 services to be scheduled for extended duration or in a near real time manner. Refer to Appendix H for further information. Unless otherwise noted, all data rates are to be interpreted as data bit rates, and not as data symbol rates. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. Appendix B describes the functional configurations and associated I-Q channel and data polarity ambiguities. Additionally, Figure B-10 depicts the SN supported convolutional coding schemes. For S-band DG2, dual data channel, balanced power configurations, the minimum total (I+Q) data rate must be 60 kbps or greater.

1.

2.

3.

4. 5. 6. 7. 8. 9. 10. 11.

5.3.2.1 General Modulation and Coherent/Noncoherent Description a. SQPN Modulation. SQPN modulation is used to prevent simultaneous transitions of the I and Q PN sequences. For SQPN modulation, the PN chips of the I and Q channels are staggered by a 1/2 chip. For data configurations that use two PN spread channels, SQPN modulation must be used. b. SQPSK Modulation. SQPSK modulation staggers one channel with respect to the other to prevent synchronous transitions. For non-spread signal configurations with identical I and Q symbol rates that are NRZ symbol formatted, SQPSK modulation should be used. The symbols of the Q channel are delayed 1/2 symbol relative to the I channel. For non-spread signal configurations that use biphase symbol formatting on either channel and the baud rate of the two channels are identical, SQPSK modulation should be used and the transitions of one channel occur at the mid-point of adjacent transitions of the other channel. c. QPSK Modulation. QPSK modulation is available when there is no relation between the I and Q channel transitions. For dual data source configurations, in which one or both channels are not spread and SQPSK is not required, QPSK modulation is used. d. BPSK Modulation. BPSK modulation is available for single data source configurations that use only one channel of the link. NOTE: For SQPN and SQPSK modulation, the spectral characteristics of a customer platform saturated power amplifier will, to a great degree, retain the spectral characteristics of the band-limited input signal to that amplifier. This should result in better control of out-of-band emissions, which, in turn, provides more efficient communications and less interference to the customer platform using adjacent frequency channels on the TDRS links. e. Coherent Mode. For coherent modes, the customer platform transmitted return link carrier frequency and PN code clock frequency (if applicable) are derived from the customer platform received forward link carrier frequency. For coherent PN spread return links, the return PN code length is identical to the length of the received forward service range channel PN code. The customer return I channel PN code epoch is synchronized with the epoch of the received forward service range channel PN code. Two-way Doppler measurements and range measurements (if PN spread) are available. f. Noncoherent Mode. For noncoherent modes, the customer platform transmitted return link carrier frequency and PN code clock frequency (if applicable) are derived from an on-board local oscillator. The customer

Revision 9

5-18

450-SNUG

platform transmit frequency for noncoherent service must be defined by the customer MOC to an accuracy of +700 Hz in its configuration code when requesting TDRSS MA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search capability is available after service start. g. Asynchronous Data Modulation. The data modulation is asynchronous to the carrier and the channel PN code (if applicable). This prevents Doppler variations of the forward service carrier and PN code frequencies from affecting the return service data rate. 5.3.2.2 DG1 Signal Parameters. DG1 signal parameters are subdivided into three modes of operation, DG1 modes 1, 2, and 3. For all DG1 modes, the PN code clock must be coherently related to the transmitted carrier frequency. This feature permits the customer platform transmitter to use a common source for generating the carrier and the PN code clock frequencies. 451-PN CODE-SNIP defines all the salient characteristics for the DG1 PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. The three DG1 modes are distinguished as follows: a. DG1 Mode 1. DG1 mode 1 must be used when range and two-way Doppler measurements (coherent transponder operations) are required concurrently with return service low-rate data transmission. Return service signal acquisition by the SN ground terminal for DG1 mode 1 is possible only when the scheduled TDRSS (MA or SSA) forward service signal is acquired by the customer platform and the PN code and carrier transmitted by the customer platform are coherently related to the forward service signal from the TDRS. If the TDRSS forward service signal becomes unavailable to the customer platform (the forward service is time-shared with other customer platforms), the customer platform transmitter must switch to noncoherent transmitter operation (DG1 mode 2) (refer to paragraph 5.3.5.c.2). In order to reacquire the DG1 mode 2 signal, the return service must be reconfigured. The I and Q channel PN codes are generated from a single code generator. For DG1 mode 1 operation, the I and Q channel PN codes are identical but are offset by at least 20,000 chips. This separation is adequate for TDRSS to identify each data channel unambiguously without requiring a unique PN code for each channel. b. DG1 Mode 2. DG1 mode 2 will be used when SN ground terminal return service signal acquisition is necessary without the requirement for prior customer platform signal acquisition of the TDRSS (MA or SSA) forward service (noncoherent transponder operation). The customer platform transmit frequency for DG1 mode 2 service must be defined by the customer MOC to an accuracy of +700 Hz in its configuration code when requesting TDRSS MA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search

Revision 9

5-19

450-SNUG

capability of +3 kHz is available. For DG1 mode 2, the I and Q channel PN codes are unique 211-1 Gold Codes. NOTE: The SN Demand Access System (DAS) allows expansion of the TDRSS F1-F7 MAR DG1 mode 2 services to be scheduled for extended duration or in a near real time manner. Refer to Appendix H for further information. c. DG1 Mode 3 (SMA via F8-F10). DG1 mode 3 can be used when range and two-way Doppler measurements (coherent transponder operations) are required concurrently with return service high-rate data transmission. Restrictions on DG1 mode 3 signal acquisition are identical to those for DG1 mode 1. In DG1 mode 3, the Q channel must contain only data and no PN code. d. Functional Configurations. Table 5-7 lists the DG1 MA return service functional configurations and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.3.2.

5.3.2.3 DG2 Signal Parameters DG2 signal parameters are subdivided into two modes of operation, DG2 coherent and noncoherent. DG2 must be used when the return service data rate equipment exceeds the capability of DG1 operations. DG2 operations cannot provide TDRSS range tracking because PN code modulation is not used. The two DG2 modes are distinguished as follows: a. DG2 Coherent (SMA via F8-F10). Return service signal acquisition by the SN ground terminal for DG2 coherent is possible only when the scheduled TDRSS (SSA or MA) forward service signal is acquired by the customer platform and the carrier transmitted by the customer platform are coherently related to the forward service signal from the TDRS. TDRSS two-way Doppler tracking can be provided when the DG2 carrier is coherently related to the TDRSS (SSA or MA) forward service carrier frequency. b. DG2 Noncoherent (SMA via F8-F10). The DG2 carrier is independent of the TDRSS (SSA or MA) forward service carrier frequency. The customer platform transmit frequency for DG2 noncoherent service must be defined by the customer MOC to an accuracy of +700 Hz in its service specification code when requesting TDRSS SMA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search capability of +3 kHz for SQPSK DG2 services and +35 kHz for BPSK and QPSK DG2 services is available after start of the return service. c. Functional Configurations. Table 5-7 lists the DG2 SMA return service functional configurations and a further description of the functional

Revision 9

5-20

450-SNUG

configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in paragraph B.3.3. 5.3.3 Communication Services To obtain TDRSS MA return service performance defined in this paragraph, the customer platform transmitted signal must meet the requirements found in Table 5-8 and signal characteristics specified in Table 5-11. The TDRSS MA return service performance defined in this paragraph also assumes return service operation in an Additive White Gaussian Noise (AWGN) environment. Appendix G discusses performance degradations to the TDRSS MA return service due to RFI. Example link calculations are provided in Appendix A. TDRSS MAR supports customers with an ephemeris uncertainty as defined in Table 5-8 and dynamics, described as non-powered flight and powered flight (SMAR only), as defined in Table 5-9. 5.3.3.1 Acquisition The MAR service supports acquisition for customer platforms operating under non-powered flight dynamics as defined in Table 5-9. MAR acquisition will be protected against false SN ground terminal lock to: interfering customer platform PN codes, customer platform PN code sidelobes, and carrier recovery. The MAR total channel acquisition times (Tacq) are given in Table 5-8 and are the sum of the following: a. PN (DG1 only) and carrier acquisition time b. Symbol/Decoder synchronization time or Symbol/Deinterleaver/Decoder synchronization time (if deinterleaving is applicable). Tacq assumes that the customer platform return service signal is present at the SN ground terminal at the start time of the scheduled return service support period and the process is described below. a. PN code (if applicable) and carrier acquisition will commence upon the start of the scheduled return service support period. b. After PN code (if applicable) and carrier acquisition is achieved, TDRSS tracking services data is available. c. Symbol/Decoder and Symbol/Deinterleaver/Decoder synchronization times will be measured from the time when the carrier acquisition is achieved to the time when the decoder synchronization is achieved. Decoder synchronization is achieved when the Viterbi decoder has selected and implemented the correct blocking of the input symbols (into groups of (G1,G2) symbol pairs for rate 1/2 codes, or (G1,G2,G3) symbol triplets for rate 1/3 codes).

Revision 9

5-21

450-SNUG

Table 5-8. TDRSS MA Return Service

Parameter (Note 7) Field of view F(OV) (each TDRS) Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization TDRS antenna axial ratio (maximum) Receive frequency (nominal) (see paragraph 5.3.3.5.b) RF bandwidth (3dB, minimum) 10 Bit Error Rate (notes 1, 2, 7) Orbital Dynamics Minimum Required Prec for Rate 1/2 convolutional coding: DG1 modes 1 and 2: F1-F7 F8 (cold), F9, F10 (note 6) F8 (hot) (note 6) DG1 mode 3 (SMAR only via F8-F10) I channel (F8 cold, F9, F10) (note 6) I channel (F8 hot) (note 6) Q channel (F8 cold, F9, F10) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps Q channel (F8 hot) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps DG2 (SMAR only via F8 cold, F9, F10) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps -222.8 + 10log10(dr) -222.1 + 10log10(dr) -224.1 + 10log10(dr) -223.4 + 10log10(dr) -219.4 + 10log10(dr) -218.7 + 10log10(dr) -220.8 + 10log10(dr) -220.1 + 10log10(dr) -222.8 + 10log10(dr) -222.1 + 10log10(dr) -224.1 + 10log10(dr) -223.4 + 10log10(dr) -222.4 + 10log10(dr) -219.0 + 10log10(dr) -223.7 + 10log10(dr) -220.4 + 10log10(dr) -220.9 + 10log10(dr) -222.4 + 10log10(dr) -219.0 + 10log10(dr) -221.8 + 10log10(dr) -223.7 + 10log10(dr) -220.4 + 10log10(dr) Powered (SMAR only) and non-powered flight dynamics (defined in Table 5-9) All Prec values are in dBW; dr is data rate in bps PFOV LEOFOV
-5

Description (Note 7) Primary (PFOV) +13 degrees conical < + 9 sec LHC 1.5 dB over 3-dB formed beamwidth 2287.5 +0.1 MHz 6 MHz LEO (LEOFOV) +10.5 degrees conical < + 9 sec

Revision 9

5-22

450-SNUG

Table 5-8. TDRSS MA Return Service (contd)

Parameter (Note 7) 10-5 Bit Error Rate (notes 1, 2, 7) (contd) Minimum Required Prec for Rate 1/2 convolutional coding (contd): DG2 (SMAR only via F8 hot) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps Minimum Required Prec for Rate 1/3 convolutional coding: DG1 mode 3, Q channel (SMAR only via F8 cold, F9, F10) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps DG1 mode 3, Q channel (SMAR only via F8 hot) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps DG2 (SMAR only via F8 cold, F9, F10) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps DG2 (SMAR only via F8 hot) (note 6) Data rate < 1 Mbps Data rate > 1 Mbps Acquisition (note 3): Orbital dynamics Total Channel Acquisition Time (assumes the customer return service signal is present at the SN ground terminal at the start time of the return service support period) free-flight dynamics only (defined in Table 5-9) Sum of the following: 1. PN (DG1 only) and carrier acquisition time 2. Symbol/Decoder synchronization time or Symbol/Deinterleaver/Decoder synchronization time (if deinterleaving is applicable) -219.7 + 10log10(dr) -219.1 + 10log10(dr) -222.1 + 10log10(dr) -220.5 + 10log10(dr) -223.1 + 10log10(dr) -222.5 + 10log10(dr) -224.4 + 10log10(dr) -223.8 + 10log10(dr) -219.7 + 10log10(dr) -219.1 + 10log10(dr) -222.1 + 10log10(dr) -220.5 + 10log10(dr) -219.4 + 10log10(dr) -218.7 + 10log10(dr) -220.8 + 10log10(dr) -220.1 + 10log10(dr) All Prec values are in dBW; dr is data rate in bps Description (Note 7)

All Prec values are in dBW; dr is data rate in bps PFOV -223.1 + 10log10(dr) -222.5 + 10log10(dr) LEOFOV -224.4 + 10log10(dr) -223.8 + 10log10(dr)

Revision 9

5-23

450-SNUG

Table 5-8. TDRSS MA Return Service (contd)

Parameter (Note 7) Acquisition (note 3) (contd): PN Code (if applicable) and Carrier Acquisition Prec F1-F7 Primary FOV >-192.2 dBW or consistent with the Prec for BER, whichever is greater >-193.7 dBW or consistent with the Prec for BER, whichever is greater >-190.3 dBW or consistent with the Prec for BER, whichever is greater LEOFOV >-193.1 dBW or consistent with the Prec for BER, whichever is greater >-195.0 dBW or consistent with the Prec for BER, whichever is greater >-191.7 dBW or consistent with the Prec for BER, whichever is greater Description (Note 7)

F8 cold, F9, F10 (note 6)

F8 hot (note 6)

Acquisition Time (Pacq > 90%) Coherent operations Noncoherent operations with frequency uncertainty (note 4): < + 700 Hz < + 3 kHz < + 35 kHz Channel Decoder/Symbol Synchronization Acquisition (note 5): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) Acquisition time (in seconds) with > 99% probability: Biphase NRZ < 1100/(Channel Data Rate in bps) < 6500/(Channel Data Rate in bps) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER < 1 sec < 3 sec < 3 sec < 1 sec

Revision 9

5-24

450-SNUG

Table 5-8. TDRSS MA Return Service (contd)

Parameter (Note 7) Acquisition (note 3) (contd): Channel Symbol/Deinterleaver(PCI)/Decoder Synchronization Acquisition (note 5): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) Acquisition time (in seconds) with >99% probability: Rate 1/2 coding Rate 1/3 coding Signal Tracking Orbital dynamics During Free Flight refer to paragraph 5.3.3.3 a During Powered Flight (SMAR only) refer to paragraph 5.3.3.3.b Reacquisition (powered (SMAR only) and non-powered flight) Duty factor refer to paragraph 5.3.3.4 100 percent Average: < 36000/(Channel Data Rate in bps) Maximum: < 66000/(Channel Data Rate in bps) Average: < 26000/(Channel Data Rate in bps) Maximum: < 46000/(Channel Data Rate in bps) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER Description (note 7)

Notes: 1. The BER is for a customer platform transmitting a signal on an AWGN channel which complies with the constraints defined in Table 5-11. Refer to Appendix G for a discussion of the additional degradation potentially applicable to TDRSS MA return performance service due to S-band RFI. 2. The required customer Prec must meet the Prec for BER or signal acquisition, whichever is greater. Paragraph 5.3.3.2.b provides the required Prec description for each possible MAR data configuration. Refer to Appendix A, paragraph A.4, for a definition of Prec. The minimum required Prec equations for BER produce the minimum Prec for a given data rate for all possible signal characteristics. CLASS analysis will produce a more accurate performance projection based upon desired customer signal characteristics, such as data rate, data type, and jitter values. The Prec equations for BER include 2 dB for self and mutual interference degradation. Appendix O provides an assessment of self and mutual interference in the TDRSS MA environment at 2287.5 MHz. The amount of self and mutual interference included in a customers MAR/SMAR link budget should be negotiated with GSFC Code 450. SN support may be possible for customers whose Prec is less than the required Prec for 10-5 BER performance as long as the customer is willing to accept support on a best-effort basis and less than 100 percent coverage. Any customer interested in receiving this marginal SN coverage shall be required to negotiate all support with GSFC Code 450. In general, customer platforms should be designed to the most limiting TDRS to ensure SN support can be provided.

Revision 9

5-25

450-SNUG

Table 5-8. TDRSS MA Return Service (contd)

Notes (Contd): 3. For PN code (if applicable) and carrier acquisition, the minimum Prec value listed applies to the total (I+Q)Prec. For carrier acquisition of SMAR SQPSK DG2 and noncoherent +35 kHz expanded frequency uncertainty DG2 configurations, the total (I+Q)Prec must be > -183.0 dBW for LEOFOV or > -181.7 dBW for Primary FOV when operating with F8(cold), F9, F10. Similarly, when operating with F8 (hot) the total (I+Q)Prec must be > -179.7 dBW for LEOFOV or > -178.3 dBW for Primary FOV during carrier acquisition of SMAR SQPSK DG2 and noncoherent +35 kHz expanded frequency uncertainty DG2 configurations. In all cases, acquisition requires the Prec to also be consistent with the Prec required for BER. 4. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 700 Hz. If a customer cannot accurately define their transmit frequency to within + 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 3 kHz for DG1 and SQPSK DG2 configurations and + 35 kHz for BPSK and non-staggered QPSK DG2 configurations after the start of service. 5. For symbol/decoder synchronization and symbol/deinterleaver/decoder synchronization, the minimum symbol transition density and consecutive symbols without a transition must meet the specifications defined in Table 5-11. It is recommended that customers use G2 inversion to increase symbol transition density. Additionally, biphase symbol formatting increases symbol transition density. 6. The F8 spacecraft has some SMA return G/T performance variations due to an MA element array and sunshield proximity problem. The G/T varies based upon the normal daily TDRS diurnal cycle. The hot periods can be predicted and will occur at regular intervals with a total hot period of less than 12 hours/day. Note that F8 is unavailable for normal customer scheduling. 7. All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates.

Table 5-9. Customer Dynamics Supported through TDRSS MAR Service

Parameter Non-powered Flight Dynamics (MAR and SMAR) < 12 km/sec < 15 m/sec2 < 0.02 m/sec3 Powered Flight Dynamics (SMAR only) < 15 km/sec < 50 m/sec2 < 2 m/sec3

& R && R &&& R

Revision 9

5-26

450-SNUG

d. After symbol/decoder and symbol/deinterleaver/decoder synchronization is achieved, MA return service channel data is available at the SN ground terminal interface. e. To minimize return data loss, it is recommended that the customer platform transmit idle pattern on its data channels until after it has observed (via the UPD data) that the SN ground terminal has completed all of its data channel signal acquisition processes. f. Requirements for bit error probability and symbol slipping take effect at the time decoder synchronization is achieved. NOTE: Acquisition times will be reduced when data and symbol transition density values are higher than the minimum required. 5.3.3.2 Bit Error Rate (BER) Table 5-8 provides Prec equations that will result in a customer achieving a BER of 10-5 for TDRSS compatible signals. The BER Prec equations are applicable for either powered (SMAR only) or non-powered flight dynamics and the following conditions: a. Data Encoding. Convolutional encoding (rate 1/2 or rate 1/3 (SMAR only)) should be used for all customer platform MA transmissions both to minimize Prec and as an RFI mitigation technique. Detailed coding design is described in Appendix B. Reed-Solomon decoding is available to WDISC customers; typical performance is given in Appendix K. NOTE: For all configurations and modes, the SN is capable of providing SMAR support of uncoded links; however, performance is not guaranteed in RFI and must be coordinated with GSFC Code 450. b. Received Power. Prec is in units of dBW. The customer project, in determining its design requirements for minimum customer spacecraft EIRP, must take into account customer platform transmit antenna pointing losses, the space loss between the customer platform and the TDRS, and the polarization loss incurred between the customer platform transmit antenna and the TDRS receive antenna. The maximum TDRS receive antenna axial ratio is given in Table 5-8 (also refer to Appendix A). For DG1 and DG2 services, the following conditions apply: 1. Balanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2 only). For a customer platform synchronously transmitting identical data on the I and Q channels (single data source identical data) with a balanced I and Q channel power

Revision 9

5-27

450-SNUG

c.

division, the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 5-8, where dr is the single data source data rate. Refer to Appendix B for further information on this data configuration. 2. Balanced Power Single Data Source-Alternate I/Q Bits (SMAR DG1 mode 1 and 2 and DG2). For a customer platform transmitting alternate I and Q data bits from a data source (single data source-alternate I/Q bits), the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 5-8, where dr is the single data source data rate prior to separation into the I and Q channels. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 3. Balanced Power Single Data Source-Alternate I/Q Encoded Symbols (SMAR DG2 only). For a customer platform transmitting alternate I and Q encoded symbols from a data source (single data source-alternate I/Q encoded symbols), the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 5-8, where dr is the single data source data rate prior to the rate 1/2 encoder. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 4. Unbalanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2). For a customer platform synchronously transmitting identical data on the I and Q channels (single data source-identical data) having unbalanced I and Q channel power division, the stronger power channel Prec must be consistent with the Prec for a 10-5 BER listed in Table 5-8 , where dr is the single data source data rate. The weaker power channel Prec need not be consistent with the Prec for a 10-5 BER listed in Table 5-8. The Q/I (power) must not exceed 4:1. Refer to Appendix B for further information on this data configuration. 5. Dual Data Sources (DG1 and SMAR DG2). For a customer platform transmitting independent data on the I and Q channels (dual data sources), each channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 5-8, where dr is that channels data rate. Refer to Appendix B for further information on this data configuration. 6. Single Data Source with Single Data Channel (DG1 modes 1 and 2 and SMAR DG2). For a customer platform transmitting one channel the Prec must be consistent with the Prec for a 10-5 BER listed in Table 5-8, where dr is the channel data rate. Refer to Appendix B for further information on this data configuration. Customer Degradations. Further reductions in the TDRSS MA return service performance identified in Table 5-8 can occur. The TDRSS MA return service will also be degraded due to RFI (refer to Appendix G). The TDRSS MA return services and tracking services will be provided without degradation for user customer platform transmitted signal characteristics within the constraints specified in Table 5-11. Customer platform parameters exceeding these constraints can also degrade TDRSS MA return service performance. Refer to

Revision 9

5-28

450-SNUG

Section 3, paragraph 3.5 for guidelines if the constraints in this paragraph cannot be met. Definitions of user customer platform constraints are given in Appendix E. d. Multipath. The SN ground terminal will provide lockup and interference protection from multipath signals reflected from the Earth. e. Periodic Convolutional Interleaving. At baud rates above 300 kbps, symbol interleaving of the customer platform transmission is recommended for DG1 mode 3 and DG2 signals. Biphase symbol formats are not allowed with PCI. When interleaving is not employed at baud rates above 300 kbps, S-band performance may not be guaranteed. Deinterleaving is not supported for baud The functional description of the (30,116) periodic rates < 300 kbps. convolutional interleaving of either rate 1/2 or rate 1/3 convolutional encoder symbols, which will be used when identified in the SHO, is defined in Appendix F. 5.3.3.3 Signal Tracking TDRSS provides MA return signal tracking (carrier, PN, symbol synchronization, convolutional deinterleaver synchronization, Viterbi decoder synchronization) for both powered (SMAR only) and non-powered flight dynamics. During a customer MA return service support period, loss-of-lock (carrier, symbol synchronization, and Viterbi decoder) indications appear in the periodically updated User Performance Data (UPD) (every 5 seconds). a. Non-powered Flight Dynamics. For all valid return service signals operating under non-powered flight dynamics, the MA return service shall maintain signal tracking for the following conditions: 1. Cycle Slips. The mean-time-between-cycle slip in the SN ground terminal carrier tracking loop for each TDRSS MA return service is 90 minutes, minimum. This value applies at carrier tracking threshold, which is 3 dB less than the minimum Prec required for BER, and increases exponentially as a function of linear dB increases in Prec. Cycle slips may result in channel and/or data polarity reversal. The SN ground terminal can correct for these reversals under the same conditions as the SN ground terminal can resolve channel and/or data polarity ambiguity as discussed in Appendix B. The time for the SN ground terminal to recover from a cycle slip will be consistent with the time required for the SN ground terminal receiver to detect and automatically reacquire the signal. 2. Bit Slippage. For each TDRSS MA return service operating with a minimum Prec required consistent with the Prec for BER and data transition densities greater than 40% for NRZ symbols or any transition density for biphase symbols, the minimum mean time between slips caused by a cycle slip in the SN ground terminal symbol clock recovery loop is either 90 minutes or 1010 symbol periods, whichever is greater. For an MA return service operating with 1 dB more than the minimum Prec required for

Revision 9

5-29

450-SNUG

BER, and NRZ symbol transition densities between 25% and 40%, the minimum mean time between slips is either 90 minutes or 1010 symbol periods, whichever is greater. 3. Loss of Symbol Synchronization. For each TDRSS MA return service with data transition densities greater than 40% for NRZ symbols and any transition density for biphase symbols, the SN ground terminal symbol synchronization loop will not unlock for a Prec that is 3 dB less than the minimum Prec required for BER. For NRZ symbol transition densities between 25% and 40%, the SN ground terminal symbol synchronizer loop will not unlock for a Prec that is 2 dB less than the minimum Prec required for BER. In both cases, BER performance will be degraded when the Prec is less than the minimum Prec required for BER. b. Powered Flight Dynamics (SMAR only). TDRSS will provide signal tracking with a probability of more than 0.99 over 90 minutes for a customer with powered flight dynamics and an ephemeris uncertainty as defined in Table 5-8. This value applies at the carrier tracking threshold. For F8 (cold), F9, F10, the carrier tracking threshold for DG1 signals is a minimum Prec of -193.5 dBW for LEOFOV, -192.2 dBW for PFOV, or the minimum Prec for BER, whichever is greater. For F8 (hot), the carrier tracking threshold for DG1 signals is a minimum Prec of 190.2 dBW for LEOFOV, -188.8 dBW for PFOV, or the minimum Prec for BER, whichever is greater. For F8 (cold), F9, F10, the carrier tracking threshold for DG2 signals is a minimum Prec of 187.4 dBW for LEOFOV, -186.1 dBW for PFOV, or the minimum Prec for BER, whichever is greater. For F8 (hot), the carrier tracking threshold for DG2 signals is a minimum Prec of 184.1 dBW for LEOFOV, -182.7 dBW for PFOV, or the minimum Prec for BER, whichever is greater. NOTE: The F8 spacecraft has some SMA return G/T performance variations due to an MA element array and sunshield proximity problem. The G/T varies based upon the normal daily TDRS diurnal cycle. The hot periods can be predicted and will occur at regular intervals with a total hot period of less than 12 hours/day. Note that F8 is unavailable for normal customer scheduling.

Revision 9

5-30

450-SNUG

5.3.3.4 Reacquisition While in the PN/carrier tracking state, a loss of lock condition induced by a cycle slip will be automatically detected and a reacquisition will be automatically initiated. For a customer platform that continues to transmit the minimum Prec for acquisition and maintains an ephemeris uncertainty as defined in Table 5-8, the normal total channel reacquisition time for either powered or non-powered flight dynamics will be less than or equal to that for the initial total channel acquisition for non-powered flight dynamics, with a probability of at least 0.99. If lock is not achieved within 10 seconds of loss of lock, an acquisition failure notification will be sent to the MOC and the SN ground terminal will reinitiate the initial service acquisition process. TDRSS MA return service does not support acquisition of customers with powered flight dynamics. Upon receipt of the loss-of-lock indications in the UPD, the customer MOC may request a TDRSS MA return service reacquisition GCMR (refer to Section 10). It is recommended that the customer MOC delay initiation of the GCMR for at least 35 seconds after initial receipt of the loss-of-lock indications in the UPD. 5.3.3.5 Additional Service Restrictions a. Sun Interference. The TDRSS MA return service performance will not be guaranteed when the center of the sun is within 3 degrees (MAR) or 4 degrees (SMAR) of the TDRS MA receiving antenna boresight; however, this sun interference checking is a customer MOC responsibility. Additionally, the TDRSS MA return service performance will not be guaranteed when the center of the sun is within 1 degree of the boresight of the SN ground terminal receiving antenna supporting the TDRS. b. Frequency and Polarization. The TDRSS MA return service requires a customer platform to transmit at 2287.5 MHz with LHC polarization (refer to Appendix D for power level restrictions into the 2290-2300 MHz band and NASA/GSFC Recommended Filtering). 5.3.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS MA return service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning the SN ground terminal response times for GCMRs is provided in Section 10. Table 5-10 lists the MA return service real-time configuration changes and their effects on the return service.

Revision 9

5-31

450-SNUG

Table 5-10. MA Return Service Real-Time Configuration Changes

Real-Time Configuration Changes GCMR OPM Return Service Interruption Yes No No Yes Yes No Yes No No Yes Yes Yes No Yes Yes No No No No No

Return Service Reacquisition Noncoherent Expanded User Spacecraft Frequency Uncertainty Channel Data Rate Noncoherent Transmit Frequency Redefinition of minimum customer EIRP Redefinition of maximum customer EIRP I/Q Power Ratio Channel Data Format Channel Data Bit Jitter DG1 Mode Data Group (SMAR only) DG2 Coherency (coherent or noncoherent) (SMAR only) Periodic Convolutional Interleaving (SMAR only) DG2 Carrier Modulation (SMAR only) Data Source/Channel Configuration G2 inversion Frame Length Frame Sync Word Length Frame Sync Word Bit Pattern Sync Strategy Parameters

98/03 98/07 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04

OPM 03 OPM 07 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03

Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Additionally, any reconfigurations to the forward service that cause forward link interruption will also cause return interruption for coherent return links. Any other reconfigurations of the SN ground terminals may momentarily affect signal tracking.

Revision 9

5-32

450-SNUG

5.3.5 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS MA return service signal acquisition by the SN ground terminal and do not include operational procedures related to acquisition. Acquisition is dependent upon the customer providing an ephemeris with a maximum uncertainty as defined in Table 5-8. a. Coherent Modes (DG1 Mode 1, DG1 Mode 3 (SMAR only), and DG2 Coherent (SMAR only)) 1. For optimal TDRSS performance, all coherent services should have the TDRSS forward and return services starting at the same time. If operational considerations require starting the TDRSS forward service before the return service, no reconfigurations of the forward service can be sent within 30 seconds of the start of the return service. A forward link sweep request OPM cannot be sent within 150 seconds of the start of the return service. 2. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS MA return service signal parameters listed in Table 5-8. 3. The SN ground terminal will adaptively point the spatially formed TDRSS MA antenna beam in the direction of the customer platform. 4. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted range and Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by SN ground terminals is either one-way return (Forward Doppler compensation enabled) or two-way (Forward Doppler compensation inhibited). For coherent operation, the Doppler correction is based upon the forward service frequency. 5. After the forward service has been acquired, the SN ground terminal will acquire the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time listed in Table 5-8. Return service will be achieved at the SN ground terminal receiver output within the total channel acquisition time limits listed in Table 5-8, which includes the SN ground terminal symbol, deinterleaver (if applicable), and Viterbi decoder synchronization. b. Noncoherent (DG1 Mode 2 and DG2 Noncoherent (SMAR only)) 1. This mode of customer platform operation does not require that a TDRSS (MA or SSA) forward service signal be received by the customer platform. However, the customer platform transmitter must be commanded to turn on when noncoherent transmissions are desired, either by stored

Revision 9

5-33

450-SNUG

c.

commands, on-board configuration settings, or direct commands from its customer MOC. 2. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS MA return service signal parameters listed in Table 5-8. 3. The SN ground terminal will adaptively point the spatially formed TDRS MA antenna beam in the direction of the customer platform. 4. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by SN ground terminals is one-way return and based on the customer platform transmission frequency stated in the SHO and any subsequent OPMs. 5. The SN ground terminal will acquire the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time limits listed in Table 5-8. Return service will be achieved at the SN ground terminals receiver output within the total acquisition time limits listed in Table 5-8, which includes the SN ground terminal symbol and Viterbi decoder synchronization. DG1 Mode Transitions. 1. DG1 Mode 2 to DG1 Mode 1 Transition. A TDRSS (MA or SSA) forward service must be scheduled to be established prior to customer MOC transmission of the GCMR to reconfigure the TDRSS for DG1 mode 1 operations (refer to paragraph 5.3.5.a (1)). 2. DG1 Mode 1 to DG1 Mode 2 Transitions. When the customer platform switches to the noncoherent mode (DG1 mode 2), customer platform return service signal parameters (e.g., carrier and channel PN codes) are changed causing the SN ground terminal to drop TDRSS MA return service signal lock. Customer platform transponders designed to automatically switch from a coherent transponder mode to a noncoherent mode when the TDRSS SSA/MA forward service signal is lost will result in SN ground terminal loss of MA return service signal lock. Reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in the SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data.

Revision 9

5-34

450-SNUG

d. DG2 Mode Transitions. 1. DG2 noncoherent to DG2 coherent Transitions. A TDRSS (MA or SSA) forward service must be scheduled to be established prior to customer MOC transmission of the GCMR to reconfigure the TDRSS for DG2 coherent operations (refer to paragraph 5.3.5.a.(1)). 2. DG2 coherent to DG2 noncoherent Transitions. When the customer platform switches to the noncoherent mode, the resulting customer transmit frequency offset will probably cause the SN ground terminal to drop TDRSS MA return service signal lock when the switch is made. If return service signal lock is lost, reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in the SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data.

Revision 9

5-35

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints

Parameters (Notes 1 and 2) Minimum channel data bit transition density (required for acquisition/reacquisition) Consecutive channel data bits without a bit transition (required for acquisition/reacquisition) Minimum channel symbol transition density (Note 3) Description (Notes 1 and 2) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 >128 randomly distributed symbol transitions within any sequence of 512 symbols < 64 symbols < + 3 percent < 0.1 percent < + 5 degrees < + 5 degrees < + 3 degrees

Consecutive channel symbols without a symbol transition Symbol asymmetry (peak) Symbol jitter and jitter rate Phase imbalance DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 (applicable to SMA only) BPSK Baud rate < 1.024 Msps Baud rate > 1.024 Msps QPSK Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain imbalance DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 (applicable to SMA only) BPSK Baud rate < 1.024 Msps Baud rate > 1.024 Msps QPSK Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps

< + 9 degrees < + 3 degrees < + 5 degrees < + 3 degrees < + 0.50 dB < + 0.50 dB < + 0.25 dB

< + 1.0 dB < + 0.25 dB < + 0.50 dB < + 0.25 dB

Revision 9

5-36

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) Phase nonlinearity (applies for all types of phase nonlinearities) (peak) DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 (applicable to SMA only) Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain flatness (peak) DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 (applicable to SMA only) Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain slope (peak) DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 (applicable to SMA only) Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps AM/PM DG1 modes 1 and 2 DG1 mode 3 (applicable to SMA only) Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps < 15 degrees/dB < 12 degrees/dB < 15 degrees/dB Not specified < 0.1 dB/MHz over +2.1 MHz Not specified < 0.1 dB/MHz over +2.1 MHz Not specified < 0.4 dB over +1.0 MHz < 0.3 dB over +2.1 MHz < 0.4 dB over +2.1 MHz < 0.3 dB over +2.1 MHz < 0.4 dB over +2.1 MHz < 4 degrees over +1.0 MHz < 3 degrees over +2.1 MHz < 4 degrees over +2.1 MHz < 3 degrees over +2.1 MHz < 4 degrees over +2.1 MHz Description (Notes 1 and 2)

Revision 9

5-37

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) AM/PM (contd): DG2 (applicable to SMA only) Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Noncoherent frequency stability (peak) (Notes 4, 5, 10) +700 Hz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time + 3 kHz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time + 35 kHz customer oscillator frequency uncertainty 1-sec average time Baud rate per channel < 12.5 ksps Baud rate per channel > 12.5 ksps 5-hr observation time 48-hr observation time Incidental AM (peak): At frequencies >10 Hz for data rates <1 kbps; at frequencies >100 Hz for data rates 1 kbps Spurious PM (rms) DG1 DG2 (applicable to SMA only) BPSK QPSK I/Q = 4:1 I/Q = 1:1 < 2 degrees < 1 degree < 2 degrees < 2 degrees < 5 percent < 7.37 x 10 < 26 x 10
-9 -6 -6 -9 -9 -7 -7

Description (Notes 1 and 2)

< 15 degrees/dB < 12 degrees/dB

< 3 x 10 < 1 x 10 < 3 x 10

3 x 10-9 4.3 x 10-7 1.29 x 10-6

< 3.77 x 10 < 11.3 x 10

Revision 9

5-38

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) Minimum 3-dB bandwidth prior to power amplifier DG1 DG2 (applicable to SMA only) Phase noise (rms) (Note 6) DG1 Mode 1 Doppler Tracking Required (Note 9) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz Doppler Tracking NOT Required (Note 7) Channel baud rate < 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz Channel baud rate > 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz DG1 Mode 2 Doppler Tracking Required (Notes 9, 10) All baud rates 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz 2.0 rms 1.0 rms 1.0 rms 2.0 rms 25.0 rms 2.5 rms 2.0 rms 1.8 rms 1.5 rms 1.5 rms 1.0 rms 1.0 rms 1.5 rms > 4.5 MHz or two times maximum baud rate, whichever is larger > 2 times maximum channel baud rate Description (Notes 1 and 2)

Revision 9

5-39

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) Phase noise (rms) (Note 6) DG1 Mode 2 (contd) Doppler Tracking NOT Required (Note 7) Channel baud rate < 18.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz Channel baud rate > 18.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz DG1 Mode 3 (applicable to SMA only) Doppler Tracking Required (Note 9) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Doppler Tracking NOT Required (Note 7) Channel baud rate < 222.5 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Channel baud rate > 222.5 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz DG2 Coherent (applicable to SMA only) Doppler Tracking Required (Note 9) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz 1.0 rms 1.0 rms 2.0 rms 22.0 rms 2.2 rms 1.4 rms 1.4 rms 3.8 rms 1.8 rms 1.4 rms 1.4 rms Description (Notes 1 and 2)

1.0 rms 1.0 rms 1.5 rms

4.0 rms 2.8 rms 1.4 rms 50.0 rms 5.5 rms 1.8 rms

Revision 9

5-40

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) Phase noise (rms) (Note 6) (contd) DG2 Coherent (applicable to SMA only) (contd) Doppler Tracking NOT Required (Note 7) Channel baud rate < 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz 18 kbps < Channel baud rate < 1.024 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz Channel baud rate > 1.024 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 3 MHz DG2 Noncoherent (applicable to SMA only) Doppler Tracking Required (Notes 9, 10) All baud rates 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz Doppler Tracking NOT Required (Note 7) Channel baud rate < 12.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz 12.5 ksps < Channel baud rate < 1.024 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz 3.8 rms 2.3 rms 2.0 rms Description (Notes 1 and 2)

25.0 rms 2.5 rms 2.0 rms 5.0 rms 1.0 rms 0.5 rms

2.0 rms 1.0 rms 1.0 rms 2.0 rms

5.0 rms 1.0 rms 1.0 rms 2.0 rms

50.0 rms 5.5 rms 2.4 rms 2.4 rms

Revision 9

5-41

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Parameters (Notes 1 and 2) Phase noise (rms) (Note 6) (contd) DG2 Noncoherent (applicable to SMA only) (contd) Doppler Tracking NOT Required (Note 7) Channel baud rate > 1.024 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 3 MHz In-band spurious outputs, where in-band is twice the maximum channel baud rate DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Out-of-band emissions Description (Notes 1 and 2)

10.0 rms 1.5 rms 0.5 rms 0.5 rms

> 23 dBc > 23 dBc > 30 dBc > 23 dBc > 30 dBc See Appendix D for NASA/GSFC Recommended Filtering in the 2290-2300 MHz band and allowable limits on out-ofband emissions, including spurs < 3 percent < 0.01 chip < 0.01 chips/sec at PN code chip rate < 0.3 dB < 3 dB < 10 degrees < +0.1 percent < +0.4 dB <12 dB <10 dB/sec

I/Q symbol skew (relative to requirements of I/Q data synchronization where appropriate) (peak) I/Q PN chip skew (relative to 0.5 chip) PN chip rate (peak), DG1 mode 2 (relative to absolute coherence with carrier rate) PN power suppression (noncoherent and coherent) Customer Antenna-Induced AM Customer Antenna-Induced PM Data rate tolerance I/Q power ratio tolerance Permissible Prec variation without reconfiguration GCMR from customer MOC) (Note 8) Permissible rate of Prec variation Maximum Prec For support through F1-F7 For support through F8-F10

-161.2 dBW -149 dBW

Revision 9

5-42

450-SNUG

Table 5-11. TDRSS MA Return Service Customer Platform Signal Constraints (contd)
Notes: 1. The definitions and descriptions of the customer constraints are provided in Appendix E. 2. When a constraint value is listed for a baud rate range and data is transmitted on both channels, the maximum baud rate of the 2 channels should be used to determine the constraint value applicable. 3. It is recommended that customers use G2 inversion to increase symbol transition density. Additionally, biphase symbol formatting increases symbol transition density. CCSDS randomization is recommended to aid in compliance with the data randomness requirements. 4. The frequency stability requirements are valid at any constant temperature (0.5 C) in the range expected during the mission. At a minimum, a temperature range of -10 C to +55 C shall be considered. 5. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 700 Hz. If a customer cannot accurately define their transmit frequency to within + 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 3 kHz for DG1 and SQPSK DG2 configurations and + 35 kHz for BPSK and QPSK DG2 configurations after the start of service. 6. Derivation of the phase noise requirements involved making assumptions about the distribution of the phase noise power in each frequency region. Since no phase noise PSD will exactly match the phase noise power distribution assumed for this derivation, phase noise PSDs which are close to violating the phase noise limits or phase noise PSDs which violate the phase noise limits should be evaluated on a case-by-case basis to determine their acceptability. 7. Applicable for customers that have no Doppler tracking requirement or can tolerate a total Doppler tracking error (system + customer) greater than 0.2 rad/sec (1, channel data rate > 1 kbps) or 0.4 rad/sec (1, channel data rate 1 kbps) assuming an averaging time of 1 second. 8. The minimum SHO EIRP should reflect the minimum Prec expected over the service period, where the Prec can exceed this minimum by no more than 12 dB. An actual customer Prec value that is 12 dB greater than the minimum may cause false PN lock or nonacquisition. 9. Will yield a total Doppler tracking error (system + customer) of ~0.2 rad/sec (1, channel data rate > 1 kbps) or 0.4 rad/sec (1, channel data rate 1 kbps) assuming an averaging time of 1 second. 10. If one-way Doppler tracking is required for orbit determination during customer launch and early orbit, contact NASA/GSFC Flight Dynamics (Code 595) for additional information and guidance about oscillator uncertainty.

Revision 9

5-43

450-SNUG

This page intentionally left blank.

Revision 9

5-44

450-SNUG

Section 6. SSA Telecommunications Services

6.1 General

6.1.1 Available Services TDRSS SSA services include forward and return telecommunications services, and tracking services. SSA return service includes service through the SN receive equipment and an automated IF service, where SN IF services are available to customers on a case-by-case basis, IF service requires the customer to provide the receiver equipment and the SN only provides the signal at the IF. Tracking services are discussed in Section 9. This section focuses on the RF interface between the TDRS and the customer platform. This interface is characterized by the technical requirements imposed and the operational capabilities provided by the TDRSS. The operational interfaces are described in further detail in Section 10. Data interfaces between the customer MOC and the SN are described in Section 3, paragraph 3.6. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessible via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. The GSFC Code 450 uses the NAMs as a means of letting customers know of any performance constraints associated with the TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452PLAN-0002. 6.1.2 Interface Definition The RF interface between the TDRS and a customer platform is defined in terms of signal parameters, RF characteristics, and field of view. a. The RF interface for forward service represents the transmission by a TDRS of an appropriately modulated signal at or greater than a minimum signal EIRP in the direction of the desired customer platform. SSA forward (SSAF) service is discussed in paragraph 6.2. b. The RF interface for return service defines a minimum received power (Prec) at the TDRS antenna input for a specified data quality at the SN ground terminal receiver output. SSA return (SSAR) service is discussed in paragraph 6.3. NOTE: The SSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna.
Revision 9 6-1 450-SNUG

6.1.3 Customer Acquisition Requirements Acquisition and reacquisition by the customer platform of the TDRS transmitted signal requires prediction by the customer MOC of the customer platform receive frequency over various projected time periods. Similarly, acquisition and reacquisition by the SN ground terminal of the customer platform signal requires prediction by the customer MOC of the customer platform transmitter frequency over various projected time periods. The frequency predictions are ultimately incorporated in the Schedule Order (SHO) as customer platform frequencies for the specific service support periods. Refer to Section 9 for additional information on TDRSS tracking services that can assist customers in predicting their local oscillator frequencies. 6.1.4 TDRSS Acquisition Support to Customers For each scheduled TDRSS service support period, the customer requirements for signal acquisition/reacquisition and the TDRSS capabilities to aid acquisition/reacquisition are as follows: a. Customer Epoch Uncertainty. The maximum epoch uncertainty of the customer platform ephemeris supplied to the TDRSS should be +9 seconds for the SSA primary field of view (PFOV) and +7.8 seconds for the SSA F8-F10 extended elliptical field of view (EEFOV) as defined in Table 6-3 for SSA forward (SSAF) and Table 6-9 for SSA return (SSAR) services. b. Customer Frequency Uncertainty. The customer MOC must know the operating frequency of the customer platform to within +700 Hz. c. Forward Frequency Sweep. After the start of the forward link service, the TDRSS has a forward service frequency sweep capability of +3 kHz for the phase-shift key (PSK) modulation services and a sweep capability of up to +600 kHz for the phase modulation (PM) services. d. Noncoherent Return Expanded Frequency Search. After the start of the noncoherent return link service, the TDRSS has a return service expanded frequency search capability to accommodate a customer platforms operating frequency uncertainty of up to +3 kHz for the DG1 and SQPSK DG2 services and up to +35 kHz for the BPSK and non-staggered QPSK DG2 services. 6.2 SSA Forward Services

6.2.1 General The characteristics of the data provided to the SN ground terminal interface and the RF signals provided by the TDRS to the customer platform during TDRSS SSA forward services are described in paragraphs 6.2.2 through 6.2.6. This discussion assumes that an appropriate forward service has been scheduled and a data signal is present at the SN ground terminal interface. For SSA, this document refers to two general modulation categories as follows: a. PSK modulation: refer to paragraph 6.2.2 for specific signal parameters b. Phase modulation (PM): refer to paragraph 6.2.3 for specific signal parameters

Revision 9

6-2

450-SNUG

6.2.2 PSK Signal Parameters The TDRSS SSA forward PSK signal parameters are defined in Table 6-1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code for TDRSS SSA forward service (refer to Section 10, paragraph 10.2.2). A description of the features inherent in the QPSK and BPSK signal parameters listed in Table 6-1 are discussed in paragraphs 6.2.2.1 and 6.2.2.2, respectively. 6.2.2.1 QPSK Signal Parameters a. Unbalanced QPSK Modulation. The I channel is used to transmit the customer command data and is referred to as the command channel. The Q channel transmits a range signal and is referred to as the range channel. The command channel/range channel power ratio for QPSK forward service signals is +10 dB. This unbalanced QPSK modulation minimizes the power in the range channel to a level adequate for customer platform range channel acquisition and tracking. This feature increases the power in the command channel by 2.6 dB over that for balanced QPSK modulation without increasing customer platform receiver complexity, increasing customer platform command channel acquisition time, or decreasing TDRSS range tracking accuracy. b. Spread Spectrum. TDRSS SSA forward services with data rates equal to and below 300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed on the TDRSS forward services by the NTIA. This modulation scheme includes separate but simultaneous command and range channels. The command channel includes a rapidly acquirable PN code and contains the forward service data. The range channel is acquired separately and contains a PN code which satisfies the range ambiguity resolution requirements. The length of the command channel PN code is 210-1, where the length of the range channel PN code is 256 times the command channel PN code length. The customer platform command channel acquisition can precede customer platform range channel acquisition; this feature permits rapid acquisition of the range channel by limiting the range channel PN code search to only 256 chip positions while the range channel PN code itself contains 261,888 chips. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward range and command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments.

Revision 9

6-3

450-SNUG

Table 6-1. TDRSS SSA Forward PSK Service Signal Parameters

Parameter TDRS transmit carrier frequency (Hz) Carrier frequency arriving at customer platform (Hz) (note 1) Carrier frequency sweep (note 4) Carrier frequency sweep duration (note 4) QPSK (PN modulation enabled)
Command channel radiated power Range channel radiated power

Description F FR +3 kHz 120 seconds +10 dB

QPSK Command Channel Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Transmit carrier frequency (F) PSK, +/2 radians 30 dB minimum 2 1 Refer to 451-PN CODE-SNIP Gold codes
10

31 F 221 96 Modulo-2 added asynchronously to PN code Not Applicable 0.1 - 300 kbps Command channel carrier frequency delayed /2 radians PSK + /2 radians 30 dB minimum Synchronized to command channel PN code chip rate (2 - 1) x 256 All 1's condition synchronized to the command channel PN code epoch. Truncated 18-state shift register sequences
10

Data modulation Data format (note 2) Data rate restrictions (note 2) QPSK Range Channel Carrier PN code modulation Carrier suppression PN code chip rate PN code length (chips) PN code epoch reference PN code family

Revision 9

6-4

450-SNUG

Table 6-1. TDRSS SSA Forward PSK Service Signal Parameters (contd)
Parameter Description

BPSK (PN modulation enabled; also referred to as Spread Spectrum BPSK (SS-BPSK)) (note 5) Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Data modulation Data format (note 2) Data rate restrictions (note 2) BPSK (PN modulation disabled) Carrier frequency (Hz) Data modulation Carrier suppression Data format (note 2) Data rate restrictions (notes 2, 3) Transmit carrier frequency (F) PSK, +/2 radians 30 dB minimum Not Applicable 300 kbps - 7 Mbps Transmit carrier frequency (F) PSK, +/2 radians 30 dB minimum 2 1 Refer to 451-PN CODE-SNIP Gold codes 31 F 221 96 Modulo-2 added asynchronously to PN code Not Applicable 0.1 - 300 kbps
10

Notes: 1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. The SN ground terminal will round-off the customer receive frequency contained in the SHO to the nearest multiple of & 221 Hz. Doppler compensation will be available for R 12 km/sec. During periods of Doppler compensation, FR = fo +E Hz, where fo = multiple of 221 nearest the nominal center frequency of && customer platform receiver as defined by the customer MOC and E = e x fo x R /c C; e < 9 && sec is the customer epoch uncertainty, R 50 m/sec2, c is the free space speed of light in m/sec,

and C = 400 Hz. If Doppler compensation is inhibited after the start of the forward service, a transition profile will be initiated to slowly change the frequency from the compensate profile to this integer multiple of 221 Hz. Forward service Doppler compensation will not increase the effective frequency rate of change seen at the customer receiver more than 28 Hz/sec relative to the frequency for a Doppler-free carrier. 2. For PSK customers, the forward data rate in this table is the baud rate that will be transmitted by the TDRSS (includes all coding and symbol formatting). For non-WDISC customers, forward data conditioning is transparent to the SN. These transparent operations should be performed by the customer prior to transmission to the SN data interface. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities.

Revision 9

6-5

450-SNUG

Table 6-1. TDRSS SSA Forward PSK Service Signal Parameters (contd)
Notes (contd): 3. The SN is capable of supporting BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. 4. After the start of the SSA forward PSK service, if a customer MOC is unable to accurately define fo (the nominal center frequency of the customer platform receiver), the forward service carrier frequency can be swept. The SSA forward service frequency sweep will be initiated by the SN ground terminal at fo -3 kHz and linearly swept to fo +3 kHz in 120 seconds and held at fo +3 kHz thereafter. The SSA forward service frequency sweep does not impact simultaneous SN ground terminal Doppler compensation of the SSA forward service carrier and PN code rate (if applicable). 5. Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required.

c. Asynchronous Data Modulation. For data rates < 300 kbps, the forward service data received at the SN ground terminal from the NISN data transport system is directly modulo-2 added by the SN ground terminal to the command channel PN code sequence. The forward service data will be asynchronous with the carrier and the PN code. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is the command channel PN code sequence. Functional Configurations. A further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Section B.2.2. e. Doppler Compensation. The TDRSS SSA forward service carrier frequency (F) and the PN chip rate transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 6-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS SSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency SSA forward service carrier and PN code chip rate. 6.2.2.2 BPSK Signal Parameters a. BPSK Modulation (PN Modulation Enabled). The I channel is used to transmit the customer command data and is referred to as the command channel. TDRSS SSA forward services with data rates equal to and below 300 kbps d.

Revision 9

6-6

450-SNUG

should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed on the TDRSS forward services by the NTIA. The command channel includes a rapidly acquirable PN code and contains the forward service data. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. NOTE: Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required. b. BPSK Modulation (PN Modulation Disabled). For data rates greater than 300 kbps, there is no PN code modulation and the customer data directly BPSK modulates the carrier by +/2 radians. NOTE: The SN is capable of supporting non-spread BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. c. Asynchronous Data Modulation. The forward service data will be asynchronous with the carrier. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is carrier only. d. Functional Configurations. A further description of the functional configurations and data polarity ambiguity is found in Appendix B, paragraph B.2.2. e. Doppler Compensation. The TDRSS SSA forward service carrier frequency (F) transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 6-1. This feature minimizes the Doppler resolution

Revision 9

6-7

450-SNUG

requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS SSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency SSA forward service carrier. 6.2.3 Phase Modulation (PM) Signal Parameters The SN is capable of supporting SSA forward phase modulated signals; however, its use will be controlled and must be coordinated with GSFC Code 450. The TDRSS SSA forward residual carrier phase modulation signal parameters are defined in Table 6-2. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code for TDRSS SSA forward service (refer to Section 10, paragraph 10.2.2). The features inherent in the signal parameters listed in Table 6-2 are as follows: a. Direct Phase Modulation. The forward service data received at the SN ground terminal from the NISN data transport system directly phase modulates the carrier. The forward service data is asynchronous with the carrier. NOTE: For the direct data phase modulation scheme, the modulation index can be /2 radians. When the command channel does not contain any actual forward service data, the forward service command channel signal is carrier only unless the customer is utilizing the SN ground terminal idle pattern feature. b. PSK Subcarrier Phase Modulation. The forward service data received at the SN ground terminal from the NISN data transport system PSK modulates either a sinewave or squarewave subcarrier, which, in turn, phase modulates the carrier. The forward service data rate is synchronous with the subcarrier frequency. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is an unmodulated subcarrier and residual carrier unless the customer is utilizing the SN ground terminal idle pattern feature. c. Functional Configurations. A further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.2.3.

Revision 9

6-8

450-SNUG

Table 6-2. TDRSS SSA Forward Phase Modulation Service Signal Parameters
Parameter Description

TDRS transmit carrier frequency (Hz) Carrier frequency arriving at customer platform (Hz) (note 1) Carrier Frequency Sweep (note 5) Carrier Frequency Sweep Duration (note 5) Direct Phase Modulation (note 3) Carrier frequency (Hz) Modulation index Data modulation (note 4) Data format (note 2) Data rate restrictions (note 2) PSK Subcarrier Phase Modulation (note 3) Carrier frequency (Hz) Data modulation (note 4) Subcarrier Type Subcarrier Frequency Carrier modulation Carrier Modulation index Data format (note 2) Data rate restrictions (note 2 and subject to subcarrier to data rate ratio restrictions below) Subcarrier to Data Rate Ratio (R)

F FR +10 Hz to +600 kHz 1 to 120 seconds Transmit carrier frequency (F) 0.2 to 1.5 radians, or /2 radians Data directly phase modulates the carrier NRZ-L, -M, -S 0.125 kbps - 1 Mbps Biphase-L, -M, -S 0.125 kbps - 500 kbps

Transmit carrier frequency (F) Data PSK modulates a subcarrier Squarewave or Sinusoidal 2, 4, 8, or 16 kHz Linearly phase modulated by the subcarrier 0.2 to 1.8 radians NRZ-L, -M, -S 0.125 kbps - 8 kbps Biphase-L, -M, -S 0.125 kbps - 4 kbps

R=2n, where n=1, 7

R=2n, where n=2, 7

Notes: 1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. The SN ground terminal will round-off the customer receive frequency contained in the SHO to the nearest multiple of & 221 Hz. Doppler compensation will be available for R <12 km/sec. During periods of Doppler compensation, FR = fo +E Hz, where fo = multiple of 221 nearest the nominal center frequency of && customer platform receiver as defined by the customer MOC and E = e x fo x x R /c + C; e < && +9 sec is the customer epoch uncertainty, R 50 m/sec2, c is the free space speed of light in

m/sec, and C = 400 Hz. Forward service Doppler compensation will not increase the effective frequency rate of change seen at the customer receiver more than 28 Hz/sec relative to the frequency for a Doppler-free carrier.

Revision 9

6-9

450-SNUG

Table 6-2. TDRSS SSA Forward Phase Modulation Service Signal Parameters (contd)
Notes (contd): 2. For PM customers, the forward data rate in this table is the uncoded data rate that will be transmitted by the TDRSS, where the baud rate transmitted by TDRSS is equal to the data rate for uncoded NRZ formatted signals and two times the data rate for uncoded Biphase formatted signals. The SN supports data conditioning for WDISC and forward link PM customers; these customer signal characteristics should be discussed with GSFC Code 450 prior to service to determine if the data conditioning will be done at the user MOC or at the SN. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. 3. The SN is capable of supporting SSA forward PM signals; however, its use will be controlled and must be coordinated with GSFC Code 450. 4. The SN ground terminal can optionally provide idle pattern. 5. After the start of an SSAF PM service, the carrier frequency will sweep plus and minus the Sweep Range (SR) around the center frequency (CF) in a triangle-wave pattern, sweeping from CF to either extreme in Sweep Duration (SD). At sweep start, all modulation (including subcarrier, when applicable) will be removed. The carrier will sweep from CF to (CF SR) in SD seconds. The sweep will reverse, sweeping from (CF SR) to CF in SD seconds; then continue sweeping from CF to (CF + SR), again in SD seconds. The sweep will continue in alternating directions (triangle-wave pattern) until a termination request is received. Upon receipt of the termination request, the sweep will continue until its next arrival at CF and the frequency profile will continue to follow the Doppler compensated frequency profile (if enabled). At sweep termination, modulation will be applied. The SSAF PM service frequency sweep does not impact simultaneous SN ground terminal Doppler compensation of the SSAF service carrier. Figure 6-1 depicts an example PM frequency sweep.

Frequency Sweep Profile, with Doppler Compensation

100 Relative Frequency, kHz 80 60 40 20 0 -20 0 -40 -60 -80 seconds 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 Doppler Compensated Forward Frequency Forward Frequency with Sweep Sweep Stop Command Received Sweep Parameters: Sweep Range +/- 60 kHz Sweep Duration 30 sec

Figure 6-1. Example SSA Forward Phase Modulation Service Frequency Sweep Profile

Revision 9

6-10

450-SNUG

d. Doppler Compensation. The TDRSS SSA forward service carrier frequency (F) transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 6-2. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS SSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency SSA forward service carrier. 6.2.4 Communications Services The TDRSS SSA forward service parameters are listed in Table 6-3. Table 6-4 lists their salient characteristics. The definitions for the parameters listed in Table 6-4 are contained in Appendix E. 6.2.5 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS SSA forward service during a scheduled service support period are usually initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the request at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for the GCMRs is provided in Section 10. Table 6-5 lists the SSA forward service real-time configuration changes and their effects on the forward service signal. 6.2.6 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS SSA forward service signal acquisition by the customer platform and do not include operational procedures related to acquisition: a. The TDRSS SSA forward service signal does not depend on a customer platform return service. b. Prior to the start of the TDRSS SSA forward service, the TDRSS SSA antenna will be open-loop pointed in the direction of the customer platform. c. At the start of the TDRSS SSA forward service as defined by the SHO, the TDRS will radiate, in the direction of the customer platform, a signal compatible with the TDRSS SSA forward service signal parameters listed in Table 6-1 (PSK) or Table 6-2 (PM) whichever is applicable. The signal will be transmitted at the scheduled EIRP consistent with the values listed in Table 6-3. The EIRP directed towards the customer platform is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 6-3. The use of TDRSS SSA forward service high-power operation is restricted and must be coordinated with GSFC Code 450.

Revision 9

6-11

450-SNUG

Table 6-3. TDRSS SSA Forward Service

Parameter Description

Field of view (FOV) (each TDRS) Primary +22 degrees east-west +28 degrees north-south (rectangular)

Extended Elliptical (F8-F10) 24.0 degrees inboard east-west 76.8 degrees outboard east-west +30.5 degrees north-south < + 7.8 sec

Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 1) TDRS antenna axial ratio (maximum) Normal or high-power mode TDRS signal EIRP (minimum) Normal power mode High power mode (note 3) Transmit frequency (nominal) (note 2)

< + 9 sec Selectable RHC or LHC 1.5 dB over 3 dB beamwidth +43.6 dBW +46.3 dBW (F1-F7) +48.5 dBW (F8-F10)

Selectable receiver frequency 2025.8 MHz to 2117.9 MHz [based on 221 (2200 to 2300) MHz] 240

RF bandwidth (3 dB, minimum) Duty factor

20 MHz 100 percent

Notes: 1. Operational considerations may limit choice of TDRS antenna polarization. The SSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 2. The customer MOC must include the best estimate of the customer platform receiver center frequency at the start time of each scheduled service support period in its service specification code (refer to Section 10, paragraph 10.2.2). The TDRSS SSA forward service carrier frequency is then implemented by the SN ground terminal to the accuracy of the SN ground terminal frequency standard except during Doppler compensation. 3. The SSAF high power mode can be requested via coordination with GSFC Code 450. TDRS F1-F7 may have SSAF EIRP capabilities in excess of 46.3 dBW, but those values may not be guaranteed. The available F1-F7 SSAF EIRP is TDRS specific and is subject to change.

Revision 9

6-12

450-SNUG

Table 6-4. Salient Characteristics for TDRSS SSA Forward Service

Parameter (Note 1)
Command channel radiated power Range channel radiated power

PSK Modulation (Note 1)

PM Modulation (Note 1)

QPSK +10 +0.5 dB NA

BPSK NA NA

Modulation index accuracy

+10% of the modulation index Direct Data PSK Subcarrier +0.5 Hz Transitions occur at subcarrier zero crossings within +1 degree NA

Subcarrier frequency accuracy

NA

NA

Data transition and subcarrier coherency

NA

NA

Modulator phase imbalance (peak) Modulator gain imbalance (peak) Relative phase between command and range channels Data asymmetry (peak) (Note 2) Data rise time (90 percent of initial state to 90 percent of final state) (Note 2)

+3 degrees (for each BPSK channel) +0.25 dB QPSK 90 +3 degrees +3 percent <5 percent of data bit duration BPSK NA

NA +0.25 dB NA +3 percent

<5 percent of data bit duration Direct Data PSK Subcarrier +0.05 radians over +90 kHz NA

Phase nonlinearity (peak) For baud rates < 128 kbps +0.15 radian over +7 MHz +0.05 radians over +90 kHz +0.25 radians over +1.5 MHz

For baud rates > 128 kbps

+0.15 radian over +7 MHz

Revision 9

6-13

450-SNUG

Table 6-4. Salient Characteristics for TDRSS SSA Forward Service (contd)
Parameter (Note 1) PSK Modulation (Note 1) PM Modulation (Note 1)

Gain flatness (peak) For baud rates < 128 kbps +0.8 dB over +7 MHz +0.8 dB over +90 kHz +0.8 dB over +1.5 MHz +0.005 dB/ kHz over +90 kHz +0.75 dB/MHz over +1.5 MHz +0.8 dB over +90 kHz NA

For baud rates > 128 kbps Gain slope (peak) For baud rates < 128 kbps

+0.8 dB over +7 MHz

+0.1 dB/MHz

+0.005 dB/kHz over +90 kHz NA

For baud rates > 128 kbps AM/PM PN chip jitter (rms) (including effects of Doppler compensation) Data bit jitter (peak) (Note 2) Spurious PM (rms) In-band spurious outputs Incidental AM (peak) Phase Noise (rms) 1 Hz - 10 Hz 10 Hz - 32 Hz 32 Hz - 1 kHz 1 kHz - 6 MHz

+0.1 dB/MHz <10 degrees/dB QPSK/SS-BPSK <1 degree <1 percent <1 degree >27 dBc <2 percent <1.5 degrees <1.5 degrees <4 degrees <2 degrees QPSK/SS-BPSK BPSK NA NA BPSK NA

<10 degrees/dB NA <1 percent <1 degree >27 dBc <2 percent <1.5 degrees <1.5 degrees <4 degrees <2 degrees

Command/range channel PN chip skew (peak) PN chip asymmetry (peak)

<0.01 chip / NA <0.01 chip

NA NA

Revision 9

6-14

450-SNUG

Table 6-4. Salient Characteristics for TDRSS SSA Forward Service (contd)
Parameter (Note 1) PSK Modulation (Note 1) PM Modulation (Note 1)

QPSK/SS-BPSK PN chip rate (peak) relative to absolute coherent with carrier rate <0.01 chips/sec at PN code chip rate

BPSK NA NA

Notes: 1. The definitions and descriptions of the salient characteristics are provided in Appendix E. 2. These values are the TDRSS contributions for data asymmetry, data transition time, and data bit jitter, assuming perfect forward service data is provided to the SN ground terminal. The actual contributions by the NISN data transport system are negligible compared to those contributed by the TDRSS, since the SN ground terminal reclocks the data before it is processed by the SN ground terminal into the forward service signal.

Table 6-5. SSA Forward Service Real-Time Configuration Changes

Real-Time Configuration Changes GCMR OPM Forward Service Signal Interruption Yes

Customer Receiver Center Frequency Doppler Compensation Inhibit Doppler Compensation Reinitiation Forward Service Reacquisition (note 1) Forward PSK Service Sweep Request (refer to Table 6-1 note 5) Forward PM Service Sweep Request (refer to Table 6-2 note 5) Data Rate Polarization Initiation or termination of the command channel PN code (note 2) Forward Service Normal/High Power Mode EIRP Change

98/04 98/08 98/04 98/03 98/05 98/05 98/04 98/04 98/04 98/06

OPM 03 OPM 11 OPM 03 OPM 02 OPM 04 OPM 04 OPM 03 OPM 03 OPM 03 OPM 06

No No Yes Yes No No Yes No No

Notes: 1. Forward service reacquisition is a TDRSS reinitiation of forward link service by applying a 1 MHz frequency offset for 3 seconds to the predicted customer receive frequency specified in the customers service specification code (refer to Section 10, paragraph 10.2.2). 2. Initiation or termination of the command channel PN code enables or disables all forward link PN modulation (including the command and range channel, if applicable), respectively.

Revision 9

6-15

450-SNUG

d. The customer platform receiving system will search for and acquire the command channel PN code (if applicable) and carrier. Normally, a customer MOC will not be transmitting forward service data to the NISN data transport system until the forward service signal has been acquired by the customer platform and the acquisition verified by the customer MOC from customer platform return service telemetry. If the NASA fourth generation standard transponder is used, its design implementation requires that there be no data transitions during the signal acquisition process, while others may merely result in longer acquisition times. Data transmission is inhibited by the SN ground terminal during PM carrier frequency sweep. e. For QPSK modulation, the customer platform receiving system will search for and acquire the range channel PN code upon acquisition of the command channel PN code and carrier. f. Depending upon the customer platform receiving system design, upon completion of forward link acquisition and subsequent customer platform transition to signal tracking, the customer platform transmitting system may either switch to a coherent mode or remain in a noncoherent mode until commanded by the customer MOC to switch. g. The SN ground terminal will continue Doppler compensation of the TDRSS SSA forward service signal unless requested by the customer MOC to inhibit the Doppler compensation. h. Tacq in the customer platform receiver is a function of the customer platform receiver design and signal-to-noise density ratio. For the purpose of an example, Table 6-6 provides the acquisition characteristics for the fourth generation transponder when receiving an SSA QPSK signal. The Tacq values listed in Table 6-6 are contingent on the customer MOC defining the customer platform receiver center frequency, fo, to an accuracy of +700 Hz in each service support schedule add request (SAR). The customer platform forward service acquisition time must be considered in determining the overall return service acquisition time for customer platform with a coherent mode of operation. i. Appendix A provides example link calculations for the TDRSS SSA forward service. 6.3 SSA Return Services

6.3.1 General The RF signals provided by the customer platform to the TDRS and the characteristics of data provided at the SN ground terminal interface are defined in paragraphs 6.3.2 through 6.3.6. This discussion assumes that an appropriate return service has been scheduled and a data signal is present at the TDRS interface. The SSA return service supports data services using the SN ground terminal receivers and an automated IF service.

Revision 9

6-16

450-SNUG

Table 6-6. SSA Forward Service Example Acquisition Times for the Fourth Generation NASA Standard Transponder
S/N0 (notes 1, 3) Command Channel PN Code (note 2) Carrier (note 2) Range Channel PN Code (note 2) Total (note 2)

34 dB-Hz > 37 dB-Hz

< 20 sec < 7 sec

< 5 sec < 5 sec

< 10 sec < 10 sec

< 35 sec < 22 sec

Notes: 1. S/N0 is the signal to noise density ratio (dB-Hz) at the customer platform transponder input. 2. With a probability > 90%. Carrier acquisition starts after the command channel PN code has been acquired. Range channel PN code acquisition starts after the carrier has been acquired. 3. For further specific information on the Fourth Generation user transponder, reference should be made to 531-RSD-IVGXPDR.

6.3.2 Signal Parameters The TDRSS SSA return service signal parameters are listed in Table 6-7. Refer to 6.3.6 for SSA return IF service signal parameter characteristics and recommendations. The services are divided into 2 major groups, Data Group 1 (DG1) and Data Group 2 (DG2). DG1 services utilize spread spectrum modulation while DG2 services are non-spread. A description of the features inherent in the DG1 and DG2 services is discussed in paragraphs 6.3.2.2 and 6.3.2.3, respectively. Within each data group, there are several types of modulation. Additionally, both data groups support coherent and noncoherent modes. A description of these general characteristics is provided in paragraph 6.3.2.1. 6.3.2.1 General Modulation and Coherent/Noncoherent Description a. SQPN Modulation. SQPN modulation is used to prevent simultaneous transitions of the I and Q PN sequences. For SQPN modulation, the PN chips of the I and Q channel are staggered by a 1/2 chip. For data configurations that use two PN spread channels, SQPN modulation must be used. b. SQPSK Modulation. SQPSK modulation staggers one channel with respect to the other to prevent synchronous transitions. For non-spread signal configurations with identical I and Q symbol rates that are NRZ symbol formatted, SQPSK modulation must be used. The symbols of the Q channel are delayed 1/2 symbol relative to the I channel. For non-spread signal configurations that use biphase symbol formatting on either channel and the baud rate of the two channels are identical, SQPSK modulation is used and the transitions of one channel occur at the mid-point of adjacent transitions of the other channel.

Revision 9

6-17

450-SNUG

Table 6-7. TDRSS SSA Return Service Signal Parameters

Parameter (Note 6) Description (Note 6)

DG1 (note 1) Transmit carrier frequency (Hz) (note 5) Carrier (F1) reference (Hz) DG1 modes 1 and 3 F1

240 FR 221 Customer platform transmitter oscillator SQPN, BPSK (see Appendix B and Table 6-8) PSK +/2 radians
31 F1 [240 96]
10

DG1 mode 2 PN code modulation DG1 modes 1 and 2 DG1 mode 3, I channel PN code chip rate (chips/sec) PN code length (chips) DG1 modes 1 and 3 DG1 mode 2 PN code epoch reference DG1 mode 1 I channel

(2 - 1) x 256 2 1
11

Epoch (all 1's condition) synchronized to epoch (all 1's condition) of received forward service range channel PN code Epoch delayed x + 1/2 PN code chips relative to I channel PN code epoch Not Applicable Same as DG1 mode 1 (I channel) Truncated 18-stage shift register sequences Gold codes Modulo-2 added asynchronously to PN code Modulo-2 added asynchronously to PN code PSK +/2 radians

Q channel (note 3) DG1 mode 2 DG1 mode 3, I channel PN code family DG1 modes 1 and 3 DG1 mode 2 Data modulation: DG1 modes 1 and 2 DG1 mode 3: I channel Q channel

Revision 9

6-18

450-SNUG

Table 6-7. TDRSS SSA Return Service Signal Parameters (contd)

Parameter (Note 6) Description (Note 6)

DG1 (note 1) (Contd) Periodic convolutional interleaving (note 4) Data format Symbol format DG1 mode 1 data rate restrictions Total (note 1) I channel Q channel DG1 mode 2 data rate restrictions Total (note 1) I channel Q channel DG1 mode 3 data rate restrictions Total (note 1) I channel Q channel DG1
Q channel power I channel power

Recommended for baud rates > 300 kbps NRZ-L, NRZ-M, NRZ-S NRZ 0.1 - 300 kbps 0.1 - 150 kbps 0.1 - 150 kbps 1 - 300 kbps 1 - 150 kbps 1 - 150 kbps I (max) + Q (max) 0.1 - 150 kbps 1 kbps - 3 Mbps

restrictions (note 2) 1:1 1:1 to 4:1 NA 1:1 to 4:1 F2

Single data source-alternate I/Q bits Single data source-identical data Single data source-single data channel Dual data sources DG2 (note 1) Transmit carrier frequency (note 5) Carrier (F2) reference (Hz) DG2 Coherent DG2 Noncoherent Data modulation (note 1)

240 FR 221 Customer platform oscillator BPSK SQPSK, or QPSK (refer to Appendix B and Table 6-8)

Revision 9

6-19

450-SNUG

Table 6-7. TDRSS SSA Return Service Signal Parameters (contd)

Parameter (Note 6) Description (Note 6)

DG2 (note 1) (contd) Periodic convolutional interleaving (note 4) Symbol format Data format Data rate restrictions Total (note 1) I channel Q channel DG2
I channel power restrictions Q channel power

Recommended for baud rates > 300 kbps NRZ, Bi0-L / NRZ-L, NRZ-M, NRZ-S I (max) + Q (max) 1 kbps - 3 Mbps 1 kbps - 3 Mbps

Single data source-alternate I/Q bits Single data source-alternate I/Q encoded symbols Single data source-single data channel Dual data sources 1.

1:1 1:1 NA 1:1 or 4:1

2.

3. 4.

5. 6.

Notes: Customer platform data configurations, including specific data rate restrictions for coding and formatting, are defined in Table 6-8 for TDRSS SSA return service (refer also to Appendix B). Unless otherwise stated, the data rate restrictions given in this table assume rate 1/2 convolutional encoding and NRZ formatting. For DG1, the Q/I power parameter range can vary from 1:1 to 4:1 continuously during specification of applicable parameter values in the NCCDS scheduling database and during realtime service reconfiguration. However if this parameter is respecified in schedule requests to the NCCDS (refer to Section 10, paragraph 10.2.2), it is expressed as the ratio of two single-digit integers. The Q channel PN code sequence must be identical to the I channel PN code sequence, but offset by x + 1/2 PN code chips, where x 20,000. The value of x is defined by the PN code assignment for a particular customer platform (refer to 451-PN CODE-SNIP). Periodic convolutional interleaving (PCI) recommended on S-band return services for channel baud rates > 300 kbps. Biphase symbol formats are not allowed with PCI. When interleaving is not employed for channel baud rates > 300 kbps, S-band return performance may not be guaranteed. The center frequency, fo, of the customer platform transmitter must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. Unless otherwise noted, all data rate values are to be interpreted as data bit rates, and not as data symbol rates. Data rates and modulation schemes are based upon support through the SSAR SN ground terminal receivers. Other data rates and modulation schemes are possible through the SSA return automated IF service, which is available on a case-by-case basis. Please refer to paragraph 6.3.6 and contact GSFC Code 450 for further information.

Revision 9

6-20

450-SNUG

c.

QPSK Modulation. QPSK modulation is available when there is no relation between the I and Q channel transitions. For dual data source configurations, in which one or both channels are not spread and SQPSK is not required, QPSK modulation is used. d. BPSK Modulation. BPSK modulation is available for single data source configurations that use only one channel of the link. NOTES: For SQPN and SQPSK modulation, the spectral characteristics of a customer platform saturated power amplifier will, to a great degree, retain the spectral characteristics of the band-limited input signal to that amplifier. This should result in better control of out-of-band emissions, which, in turn, provides more efficient communications and less interference to the customer platform using adjacent frequency channels on the TDRS links. For non-spread SSA services, PSK subcarrier phase modulation (PCM/PSK/PM) and direct phase modulation (PCM/PM) may also be supported by the SN. However, its use and customer specific supporting characteristics must be coordinated with GSFC Code 450. e. Coherent Mode. For coherent modes, the customer platform transmitted return link carrier frequency and PN code clock frequency (if applicable) are derived from the customer platform received forward link carrier frequency. For coherent PN spread return links, the return PN code length is identical to the length of the received forward service range channel PN code. The customer return I channel PN code epoch is synchronized with the epoch of the received forward service range channel PN code. Two-way Doppler measurements and range measurements (if PN spread) are available. For noncoherent modes, the customer platform f. Noncoherent Mode. transmitted return link carrier frequency and PN code clock frequency (if applicable) are derived from an on-board local oscillator. The customer platform transmit frequency for noncoherent service must be defined by the customer MOC to an accuracy of +700 Hz in its service specification code when requesting TDRSS SSA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search capability is available after service start. g. Asynchronous Data Modulation. The data modulation is asynchronous to the carrier and the channel PN code (if applicable). This prevents Doppler variations of the forward service carrier and PN code frequencies from affecting the return service data rate.

Revision 9

6-21

450-SNUG

6.3.2.2 DG1 Signal Parameters DG1 signal parameters are subdivided into three modes of operation, DG1 modes 1, 2, and 3. For all DG1 modes, the PN code clock must be coherently related to the transmitted carrier frequency. This feature permits the customer platform transmitter to use a common source for generating the carrier and the PN code clock frequencies. 451-PN CODE-SNIP defines all the salient characteristics for the DG1 PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. The three DG1 modes are distinguished as follows: a. DG1 Mode 1. DG1 mode 1 must be used when range and two-way Doppler measurement (coherent transponder operations) are required concurrently with return service low-rate data transmission. Return service signal acquisition by the SN ground terminal for DG1 mode 1 is possible only when the scheduled TDRSS (SSA or MA) forward service signal is acquired by the customer platform and the PN code and carrier transmitted by the customer platform are coherently related to the forward service signal from the TDRS. If the TDRSS forward service signal becomes unavailable to the customer platform, the platform transmitter must switch to noncoherent transmitter operation (DG1 mode 2) (refer to paragraph 6.3.5.c.2). In order to reacquire the DG1 mode 2 signal, the return service must be reconfigured. The I and Q channel PN codes are generated from a single code generator. For DG1 mode 1 operation, the I and Q channel PN codes are identical but are offset by at least 20,000 chips. This separation is adequate for TDRSS to identify each data channel unambiguously without requiring a unique PN code for each channel. b. DG1 Mode 2. DG1 mode 2 can be used when SN ground terminal return service signal acquisition is necessary without the requirement for prior customer platform signal acquisition of the TDRSS (SSA or MA) forward service (noncoherent transponder operation). The customer platform transmit frequency for DG1 mode 2 service must be defined by the customer MOC to an accuracy of +700 Hz in its service specification code when requesting TDRSS SSA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search capability of +3 kHz is available after the start of the return service. For DG1 mode 2, the I and Q channel PN codes are unique 211-1 Gold Codes. c. DG1 Mode 3. DG1 mode 3 can be used when range and two-way Doppler measurements (coherent transponder operations) are required concurrently with return service high-rate data transmission. Restrictions on DG1 mode 3 signal acquisition are identical to those for DG1 mode 1. In DG1 mode 3, the Q channel must contain only data and no PN code. d. Functional Configurations. Table 6-8 lists the DG1 SSA return service functional configurations and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.3.2.

Revision 9

6-22

450-SNUG

Table 6-8. SSA Return Service Configurations

Source Data Rate Restrictions and Availability8,9,12 Return Service Configuration10 Data format Single Source Data BPSK Rate 1/2 coded NRZ DG1 Mode 11 and 21,4 Data rate <150 kbps1 Data format 32 Data rate NRZ NRZ with biphase symbols NRZ NRZ with biphase symbols Uncoded SQPN Identical I & Q channel data Rate 1/2 coded
7 7

Revision 9 6-23
Dual Data Sources (data rates are for each source separately)

DG2 Mode Coherent3 and Noncoherent3,4 Data format Data rate 1 kbps 3 Mbps5 1 kbps 1.5 Mbps5,6 1 kbps 2 Mbps5 1 kbps 1 Mbps5,6
7

Rate 1/3 coded

NRZ

<150 kbps -

Uncoded SQPSK SQPN1 SQPSK3 or Rate 1/2 coded encoded symbols Alternating data I/Q alternate I/Q

NRZ

I: 0.1-150 kbps Q: 1 kbps 3 Mbps Q: 1 kbps 2 Mbps

7

NRZ NRZ NRZ

7

1 300 kbps 1 kbps 6 Mbps5 1 kbps 4 Mbps5

7

NRZ 7

<300 kbps 7

Individually rate 1/2 coded Individually rate 1/3 coded Uncoded

SQPN , QPSK2,3 SQPSK3

1

or

Rate 1/2 coded

NRZ

<150 kbps

NRZ NRZ with biphase symbols NRZ NRZ with biphase symbols
7

1 kbps 3 Mbps5,11 1 kbps 1.5 Mbps5,6,11 1 kbps 2 Mbps5,11 1 kbps 1 Mbps5,6,11

7,11

Rate 1/3 coded

NRZ

Uncoded

450-SNUG

Table 6-8. SSA Return Service Configurations (contd)

Configuration supported NOTES: Configuration not supported 1. For DG1 mode 1 and 2 configurations, where the minimum source data rates are 0.1 kbps for DG1 mode 1 and 1 kbps for DG1 mode 2: a. Data on a single I or Q channel, but not both channels: BPSK modulation is used where the data is modulo-2 added to the PN code. b. Data on both the I and Q channels: SQPN modulation is used and the SN supports I:Q power ratios of 1:1 to 1:4 for all the configurations, except the alternating I and Q data bit configuration, which requires a balanced I:Q power ratio. c. The alternating I/Q data bit configuration: the SN requires the I channel lead the Q channel by a half symbol. Similarly, the SN requires the I and Q channels be independently differentially formatted (-M,-S). 2. For DG1 mode 3 configurations: a. The modulation is QPSK, where the I channel data is modulo-2 added to the PN code, and the Q channel data directly modulates the carrier at +/2 radians. b. The SN supports I:Q power ratios of 1:1 to 1:4. c. Rate 1/3 coding is supported for the Q channel only. (Rate 1/2 coding is supported on both the I and Q channels.) 3. For DG2 configurations: a. Single data source configurations with data on one channel: BPSK modulation is used. b. Single data source configurations with data on both channels: SQPSK modulation and an I:Q power ratio of 1:1 is used. For the alternate I/Q bit configuration, the SN requires the I and Q channels be independently differentially formatted (-M,-S). c. Dual data source configurations: SQPSK must be used when there are identical baud rates on the I and Q channels (see paragraph 6.3.2.1.b); QPSK is used for all other configurations; for both SQPSK and QPSK, either an I:Q power ratio of 1:1 or 4:1 is supported. For unbalanced QPSK, the I channel must contain the higher data rate and when the data rate on the I channel exceeds 70 percent of the maximum allowable data rate, the Q channel data rate must not exceed 40 percent of the maximum allowable data rate on that Q channel. 4. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 700 Hz. If a customer cannot accurately define their transmit frequency to within + 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 3 kHz for DG1 and SQPSK DG2 configurations and + 35 kHz for BPSK and QPSK DG2 configurations after the start of service. 5. Periodic convolutional interleaving (PCI) recommended on S-band return service for channel baud rates > 300 kbps. When interleaving is not employed for channel baud rates > 300 kbps, S-band performance may not be guaranteed. 6. Biphase symbol formats are not allowed with PCI. Use of biphase symbol formats on S-band services at baud rates > 300 kbps should be coordinated with GSFC Code 450. 7. For all configurations and modes, the SN is capable of providing SSA support of uncoded links; however, performance is not guaranteed in RFI and must be coordinated with GSFC Code 450. 8. TDRSS may be capable of supporting other return signal configurations, such as residual carrier Phase Modulation signals; however, performance will have to be handled on a case-by-case basis with GSFC Code 450. 9. Unless otherwise noted, all data rates are to be interpreted as data bit rates, and not as data symbol rates. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. 10. Appendix B describes the functional configurations and associated I-Q channel and data polarity ambiguities. Additionally, Figure B-10 depicts the SN supported convolutional coding schemes. 11. For S-band DG2, dual data channel, balanced power configurations, the minimum total (I+Q) data rate must be 60 kbps or greater. 12. Data rates and modulation schemes are based upon support through the SSAR SN ground terminal receivers. Other data rates and modulation schemes are possible through the SSA return automated IF services,. which is available on a case-by-case basis Please refer to paragraph 6.3.6 and contact GSFC code 450 for further information.

Revision 9 6-24 450-SNUG

6.3.2.3 DG2 Signal Parameters DG2 signal parameters are subdivided into two modes of operation, DG2 coherent and noncoherent. DG2 must be used when the return service data rate equipment exceeds the capability of DG1 operations. DG2 operations cannot provide TDRSS range tracking because PN code modulation is not used. The two DG2 modes are distinguished as follows: a. DG2 Coherent. Return service signal acquisition by the SN ground terminal for DG2 coherent is possible only when the scheduled TDRSS (SSA or MA) forward service signal is acquired by the customer platform and the carrier transmitted by the customer platform is coherently related to the forward service signal from the TDRS. TDRSS two-way Doppler tracking can be provided when the DG2 carrier is coherently related to the TDRSS (SSA or MA) forward service carrier frequency. b. DG2 Noncoherent. The DG2 carrier is independent of the TDRSS (SSA or MA) forward service carrier frequency. The customer platform transmit frequency for DG2 noncoherent service must be defined by the customer MOC to an accuracy of +700 Hz in its service specification code when requesting TDRSS SSA return service (refer to Section 10, paragraph 10.2.2). For customers whose frequency uncertainty is greater than +700 Hz, an expanded frequency search capability of +3 kHz for SQPSK DG2 services and +35 kHz for BPSK and QPSK DG2 services is available after the start of the return service. NOTE: For non-spread SSA services, PSK subcarrier phase modulation (PCM/PSK/PM) and direct phase modulation (PCM/PM) may also be supported by the SN. For PCM/PSK/PM, the SN will acquire and demodulate data on either the upper or lower subcarrier. For this scenario, the minimum required Prec is the minimum required channel Prec and should be compared against the predicted channel Prec after data loss due to the modulation index and a 3 dB loss due to demodulating only the upper or lower subcarrier. The use of these modulation schemes and customer specific supporting characteristics must be coordinated with GSFC Code 450. c. Functional Configurations. Table 6-8 lists the DG2 SSA return service functional configurations through the SN ground terminal receiver and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.3.3. Refer to paragraph 6.3.6 for the SSAR IF service functional configurations.

6.3.3 Communications Services To obtain TDRSS SSA return service performance defined in this paragraph, the customer platform transmitted signal must meet the requirements found in Table 6-9

Revision 9

6-25

450-SNUG

and signal characteristics specified in Table 6-12. The TDRSS SSA return service performance defined in this paragraph also assumes return service operation in an AWGN environment. Appendix G discusses performance degradations to the TDRSS SSA return service due to RFI. Example link calculations are provided in Appendix A. TDRSS SSAR supports customers with an ephemeris uncertainty as defined in Table 6-9 and dynamics, described as non-powered flight and powered flight, as defined in Table 6-10. 6.3.3.1 Acquisition The SSAR service supports acquisition for customer platforms operating under non-powered flight dynamics as defined in Table 6-10. SSAR acquisition will be protected against false SN ground terminal lock to: interfering customer platform PN codes, customer platform PN code sidelobes, and carrier recovery. The SSAR total channel acquisition times (Tacq) are given in Table 6-9 and are the sum of the following: a. PN (DG1 only) and carrier acquisition time b. Symbol/Decoder synchronization time or Symbol/Deinterleaver/Decoder synchronization time (if deinterleaving is applicable). Tacq assumes that the customer platform return service signal is present at the SN ground terminal at the start time of the scheduled return service support period and the process is described below. a. PN code (if applicable) and carrier acquisition will commence upon the start of the scheduled return service support period. b. After PN code (if applicable) and carrier acquisition is achieved, TDRSS tracking services data is available. c. Symbol/Decoder and Symbol/Deinterleaver/Decoder synchronization times will be measured from the time when the carrier acquisition is achieved to the time when the decoder synchronization is achieved. Decoder synchronization is achieved when the Viterbi decoder has selected and implemented the correct blocking of the input symbols (into groups of (G1,G2) symbol pairs for rate 1/2 codes, or (G1,G2,G3) symbol triplets for rate 1/3 codes). d. After symbol/decoder and symbol/deinterleaver/decoder synchronization is achieved, SSA return service channel data is available at the SN ground terminal interface. e. To minimize return data loss, it is recommended that the customer platform transmit idle pattern on its data channels until after it has observed (via the UPD data) that the SN ground terminal has completed all of its data channel signal acquisition processes. f. Requirements for bit error probability and symbol slipping take effect at the time decoder synchronization is achieved.

Revision 9

6-26

450-SNUG

Table 6-9. TDRSS SSA Return Service

Parameter (Note 7) Description (Note 7)

Field of View (FOV) (each TDRS) Primary +22 degrees east-west +28 degrees north-south (rectangular)

Extended Elliptical (F8-F10) 24.0 degrees inboard east-west 76.8 degrees outboard east-west +30.5 degrees north-south < + 7.8 sec

Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 4) TDRS antenna axial ratio (maximum) Receive frequency band (see paragraph 6.3.3.5.b) RF bandwidth (3dB, minimum) 10 Bit Error Rate (notes 1, 2, 3, 8): Orbital Dynamics Minimum Required Prec for Rate 1/2 convolutional coding: DG1 modes 1 and 2 DG1 mode 3 I channel Q channel Data rate < 1 Mbps Data rate > 1 Mbps DG2 Data rate < 1 Mbps Data rate > 1 Mbps Minimum Required Prec for Rate 1/3 convolutional coding: DG1 mode 3, Q channel Data rate < 1 Mbps Data rate > 1 Mbps
-5

< + 9 sec RHC or LHC selectable 1.5 dB over 3 dB beamwidth 2200 MHz to 2300 MHz 10 MHz

Powered and non-powered flight dynamics (defined in Table 6-10) All Prec values are in dBW -231.6 + 10log10(data rate in bps) -231.6 + 10log10(data rate in bps) -232.1 + 10log10(data rate in bps) -231.2 + 10log10(data rate in bps) -232.1 + 10log10(data rate in bps) -231.2 + 10log10(data rate in bps) All Prec values are in dBW

-232.4 + 10log10(data rate in bps) -231.6 + 10log10(data rate in bps)

Revision 9

6-27

450-SNUG

Table 6-9. TDRSS SSA Return Service (contd)

Parameter (Note 7) Description (Note 7)

10-5 Bit Error Rate (notes 1, 2, 3, 8) (contd): Minimum Required Prec for Rate 1/3 convolutional coding (contd): DG2 Data rate < 1 Mbps Data rate > 1 Mbps Acquisition (notes 3, 8): Orbital dynamics Total Channel Acquisition Time (assumes the customer return service signal is present at the SN ground terminal at the start time of the return service support period) Free-flight dynamics only (defined in Table 6-10) Sum of the following: 1. PN (DG1 only) and carrier acquisition time 2. Symbol/Decoder synchronization time or Symbol/Deinterleaver/Decoder synchronization time (if deinterleaving is applicable) -232.4 + 10log10(data rate in bps) -231.6 + 10log10(data rate in bps)

PN Code (if applicable) and Carrier Acquisition: Prec Acquisition Time (Pacq > 90%): Coherent operations Noncoherent operations with frequency uncertainty (note 5): < + 700 Hz < + 3 kHz < + 35 kHz Channel Decoder/Symbol Synchronization Acquisition (note 6): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER < 1 sec < 3 sec < 3 sec < 1 sec > -202.9 dBW or consistent with the Prec for BER, whichever is greater

Revision 9

6-28

450-SNUG

Table 6-9. TDRSS SSA Return Service (contd)

Parameter (Note 7) Description (Note 7)

Acquisition (notes 3, 8) (contd): Channel Decoder/Symbol Synchronization Acquisition (note 6) (contd): Acquisition time (in seconds) with >99% probability: Biphase NRZ Channel Symbol/Deinterleaver (PCI)/ Decoder Synchronization Acquisition (note 6): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) Acquisition time (in seconds) with >99% probability: Rate 1/2 coding Rate 1/3 coding Signal Tracking Orbital dynamics Reacquisition flight) Duty Factor (powered and non-powered During Free Flight refer to paragraph 6.3.3.3.a During Powered Flight refer to paragraph 6.3.3.3.b refer to paragraph 6.3.3.4 100% Average: < 36000/(Channel Data Rate in bps) Maximum: < 66000/(Channel Data Rate in bps) Average: < 26000/(Channel Data Rate in bps) Maximum: < 46000/(Channel Data Rate in bps) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER < 1100/(Channel Data Rate in bps) < 6500/(Channel Data Rate in bps)

Notes: 1. The BER is for a customer platform transmitting a signal on an AWGN channel which complies with the constraints defined in Table 6-12. Refer to Appendix G for a discussion of the additional degradation applicable to TDRSS SSA return service performance due to S-band RFI.

Revision 9

6-29

450-SNUG

Table 6-9. TDRSS SSA Return Service (contd)

Notes (contd): 2. The required customer Prec must meet the Prec for BER or signal acquisition, whichever is greater. Paragraph 6.3.3.2.b provides the required Prec description for each possible SSAR data configuration. Refer to Appendix A, paragraph A.4, for a definition of Prec. The minimum required Prec equations for BER produce the minimum Prec for a given data rate for all possible signal characteristics. CLASS analysis will produce a more accurate performance projection based upon desired customer signal characteristics, such as data rate, data type, and jitter values. SN support may be possible for customers whose Prec is less than the required Prec for 10-5 BER performance as long as the customer is willing to accept support on a best-effort basis and less than 100 percent coverage. Any customer interested in receiving this marginal SN coverage shall be required to negotiate all support with GSFC Code 450. 3. For PN code (if applicable) and carrier acquisition, the total (I+Q)Prec must be > -202.9 dBW for all configurations, except SQPSK DG2 and noncoherent +35 kHz expanded frequency uncertainty DG2 configurations which require the total (I+Q)Prec to be > -190.9 dBW. However, acquisition requires the Prec to also be consistent with the Prec required for BER. 4. Operational considerations may limit the choice of TDRS antenna polarization. The SSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 5. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 700 Hz. If a customer cannot accurately define their transmit frequency to within + 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 3 kHz for DG1 and SQPSK DG2 configurations and + 35 kHz for BPSK and non-staggered QPSK DG2 configurations after the start of service. 6. For symbol/decoder synchronization and symbol/deinterleaver/decoder synchronization, the minimum symbol transition density and consecutive symbols without a transition must meet the specifications defined in Table 6-12. It is recommended that customers use G2 inversion to increase symbol transition density. Additionally, biphase symbol formatting increases symbol transition density. 7. All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates. 8. SSAR performance characteristics are through the SN ground terminal receivers. An automated SSAR IF service is available on a case-by-case basis. Please refer to paragraph 6.3.6 and contact GSFC Code 450 for further information.

Table 6-10. Customer Dynamics Supported through TDRSS SSAR Service

Parameter Non-powered Flight Dynamics Powered Flight Dynamics

& R && R &&& R

< 12 km/sec < 15 m/sec2 < 0.02 m/sec3

< 15 km/sec < 50 m/sec2 < 2 m/sec3

Revision 9

6-30

450-SNUG

NOTE: Data and symbol transition density values higher than the minimums required will reduce these acquisition times. 6.3.3.2 Bit Error Rate (BER) Table 6-9 provides Prec equations that will result in a customer achieving a BER of 10-5 for TDRSS compatible signals. The IF service BER depends on the customer receiver characteristics. Refer to paragraph 6.3.6 for more information on the IF service. The BER Prec equations are applicable for either powered or non-powered flight dynamics and the following conditions: a. Data Encoding. Convolutional encoding (rate 1/2 or rate 1/3) should be used for all customer platform SSA transmissions both to minimize Prec and as an RFI mitigation technique. Detailed coding design is described in Appendix B. Reed-Solomon decoding is available to WDISC customers; typical performance is given in Appendix K. NOTE: For all configurations and modes, the SN is capable of providing SSAR support of uncoded links; however, performance is not guaranteed in RFI and must be coordinated with GSFC Code 450. b. Received Power. Prec is in units of dBW. The customer project, in determining its design requirements for minimum customer platform EIRP, must take into account customer platform transmit antenna pointing losses, the space loss between the customer platform and the TDRS, and the polarization loss incurred between the customer platform transmit antenna and the TDRS receive antenna. The maximum TDRS receive antenna axial ratio is given in Table 6-9 (also refer to Appendix A). For DG1 and DG2 services, the following conditions apply: 1. Balanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2 only). For a customer platform synchronously transmitting identical data on the I and Q channels (single data source-identical data) with a balanced I and Q channel power division, the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 6-9, where data rate is the single data source data rate. Refer to Appendix B for further information on this data configuration. 2. Balanced Power Single Data Source-Alternate I/Q Bits (DG1 mode 1 and 2 and DG2). For a customer platform transmitting alternate I and Q data bits from a data source (single data source-alternate I/Q bits), the total(I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 6-9, where data rate is the single data source data rate prior to separation into the I and Q channels. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration.
Revision 9 6-31 450-SNUG

Balanced Power Single Data Source-Alternate I/Q Encoded Symbols (DG2 only). For a customer platform transmitting alternate I and Q encoded symbols from a data source (single data source-alternate I/Q encoded symbols), the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed Table 6-9, where data rate is the single data source data rate prior to the rate 1/2 encoder. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 4. Unbalanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2). For a customer platform synchronously transmitting identical data on the I and Q channels (single data source-identical data) having unbalanced I and Q channel power division, the stronger power channel Prec must be consistent with Prec for a 10-5 BER listed in Table 6-9, where data rate is the single data source data rate. The weaker power channel Prec need not be consistent with the Prec for a 10-5 BER listed in Table 6-9. The Q/I (power) must not exceed 4:1. Refer to Appendix B for further information on this data configuration. 5. Dual Data Sources (DG1 and DG2). For a customer platform transmitting independent data on the I and Q channels (dual data sources), each channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 6-9, where data rate is that channels data rate. Refer to Appendix B for further information on this data configuration. 6. Single Data Source with Single Data Channel (DG1 modes 1 and 2 and DG2). For a customer platform transmitting one channel, the channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 6-9, where data rate is the channel data rate. Refer to Appendix B for further information on this data configuration. c. Customer Degradations. Further reductions in the TDRSS SSA return service performance identified in Table 6-9 can occur. The TDRSS SSA return service will also be degraded due to RFI (refer to Appendix G). The TDRSS SSA return services and tracking services will be provided without degradation for user customer platform transmitted signal characteristics within the constraints specified in Table 6-12. Customer platform parameters exceeding these constraints can also degrade TDRSS SSA return service performance. Refer to Section 3, paragraph 3.5 for guidelines if the constraints in this paragraph cannot be met. Definitions of user customer platform constraints are given in Appendix E. d. Multipath. The SN ground terminal will provide lockup and interference protection from multipath signals reflected from the Earth. e. Periodic Convolutional Interleaving. At baud rates above 300 kbps, symbol interleaving of the customer platform transmission is recommended for DG1 mode 3 and DG2 signals. Biphase symbol formats are not allowed with PCI. When interleaving is not employed at baud rates above 300 kbps, S-band performance may not be guaranteed. Deinterleaving is not supported for baud rates < 300 kbps. The functional description of the (30,116) periodic

3.

Revision 9

6-32

450-SNUG

convolutional interleaving of either rate 1/2 or rate 1/3 convolutional encoder symbols is defined in Appendix F. 6.3.3.3 Signal Tracking TDRSS provides SSA return signal tracking (carrier, PN, symbol synchronization, convolutional deinterleaver synchronization, Viterbi decoder synchronization) for both powered and non-powered flight dynamics. During a customer SSA return service support period, loss-of-lock (carrier, symbol synchronization, and Viterbi decoder) indications appear in the periodically updated User Performance Data (UPD) (every 5 seconds). a. Non-powered Flight Dynamics. For all valid return service signals operating under non-powered flight dynamics, the SSA return service shall maintain signal tracking for the following conditions: 1. Cycle Slips. The mean time-between-cycle slip in the SN ground terminal carrier tracking loop for each TDRSS SSA return service will be 90 minutes minimum. This value applies at the carrier tracking threshold, which is 3 dB less than the minimum Prec for BER, and increases exponentially as a function of linear dB increases in Prec. Cycle slips may result in channel and/or data polarity reversal. The SN ground terminal can correct for these reversals under the same conditions as the SN ground terminal can resolve channel and/or data polarity ambiguity as discussed in Appendix B. The time for the SN ground terminal to recover from a cycle slip will be consistent with the time required for the SN ground terminal receiver to detect and automatically reacquire the signal. 2. Bit Slippage. For each TDRSS SSA return service operating with a minimum Prec required consistent with the Prec for BER and data transition densities greater than 40% for NRZ symbols or any transition density for biphase symbols, the minimum mean time between slips caused by a cycle slip in the SN ground terminal symbol clock recovery loop is either 90 minutes or 1010 symbol periods, whichever is greater. For an SSA return service operating with 1 dB more than the minimum Prec required for BER, and NRZ symbol transition densities between 25% and 40%, the minimum mean time between slips is either 90 minutes or 1010 symbol periods, whichever is greater. 3. Loss of Symbol Synchronization. For each TDRSS SSA return service with either rate 1/2 or rate 1/3 convolutional encoding and data transition densities greater than 40% for NRZ symbols and any transition density for biphase symbols, the SN ground terminal symbol synchronization loop will not unlock for a Prec that is 3 dB less than the minimum Prec required for BER. For NRZ symbol transition densities between 25% and 40%, the SN ground terminal symbol synchronizer loop will not unlock for a Prec that is 2 dB less than the minimum Prec required for BER. In both cases, the BER performance will be degraded when the Prec is less than the minimum required for BER. b. Powered Flight Dynamics. TDRSS will provide signal tracking with a probability of more than 0.99 over 90 minutes for a customer with powered flight dynamics
Revision 9 6-33 450-SNUG

and an ephemeris uncertainty as defined in Table 6-9. This value applies at the carrier tracking threshold. The carrier tracking threshold for DG1 signals is a minimum Prec of -201.4 dBW or the minimum Prec for BER, whichever is greater. The carrier tracking threshold for DG2 signals is a minimum Prec of -195.3 dBW or the minimum Prec for BER, whichever is greater. 6.3.3.4 Reacquisition While in the PN/carrier tracking state, a loss of lock condition induced by a cycle slip will be automatically detected and a reacquisition will be automatically initiated. For a customer platform that continues to transmit the minimum Prec for acquisition and maintains with an ephemeris uncertainty as defined in Table 6-9, the normal total channel reacquisition time for either powered or non-powered flight dynamics will be less than or equal to that for the initial total channel acquisition for non-powered flight dynamics, with a probability of at least 0.99. If lock is not achieved within 10 seconds of loss of lock, an acquisition failure notification will be sent to the MOC and the SN ground terminal will reinitiate the initial service acquisition process. TDRSS SSA return service does not support acquisition of customers with powered flight dynamics. Upon receipt of the loss-of-lock indications in the UPD, the customer MOC may request a TDRSS SSA return service reacquisition GCMR (refer to section 10). It is recommended that the customer MOC delay initiation of the GCMR for at least 35 seconds after initial receipt of the loss-of-lock indications in the UPD. 6.3.3.5 Additional Service Restrictions a. Sun Interference. The TDRSS SSA return service performance will not be guaranteed when the center of the sun is within 4 degrees of the TDRS SSA receiving antenna boresight; however, this sun interference checking is a customer MOC responsibility. Additionally, the TDRSS SSA return service performance will not be guaranteed when the center of the sun is within 1 degree of the boresight of the SN ground terminal receiving antenna supporting the TDRS. b. Frequency and Polarization. The TDRSS SSA return service can support the customer platform with assigned frequencies anywhere within the 2200 to 2300 MHz band with either RHC or LHC polarization. The following restrictions apply: 1. The BER relationships of Table 6-9 are satisfied for center frequencies from 2205 to 2295 MHz (refer to Appendix D for power level restrictions into the 2290-2300 MHz band and NASA/GSFC Recommended Filtering). For customer center frequencies below 2205 MHz or center frequencies above 2295 MHz, acceptable data service may be achieved when the customers spectrum does not spill over the edges of the 2200 to 2300 MHz band. 2. The customer platform spectrum should be constrained so that the first null of the spectrum falls within the 2200 to 2300 MHz band. 3. In addition, the customer platform should consider employing selectable polarization capability.

Revision 9

6-34

450-SNUG

c.

To avoid interference with MA return customers, the SN may restrict support to SSA only customers that operate LHC polarization at frequencies above 2280 MHz. 5. The SSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. Mutual Interference. It is possible for the mutual interference between SSA customer platforms operating on the same polarization to become significant. The SN can provide tools to assist customers in interference prediction and interference mitigation. NOTE: Frequency assignment and polarization selection for TDRSS SSA return service customers is performed during the mission planning phase.

4.

6.3.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS SSA return service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in Section 10. Table 6-11 lists the SSA return service real-time configuration changes and their effects on the return service. 6.3.5 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS SSA return service signal acquisition by the SN ground terminal and do not include operational procedures related to acquisition. Acquisition is dependent upon the customer providing an ephemeris with a maximum uncertainty as defined in Table 6-9: a. Coherent Modes (DG1 Modes 1 or 3 and DG2 Coherent) 1. For optimal TDRSS performance, all coherent services should have the TDRSS forward and return services starting at the same time. If operational considerations require starting the TDRSS forward service before the return service, no reconfigurations of the forward service can be sent within 30 seconds of the start of the return service. A forward link sweep request OPM cannot be sent within 150 seconds of the start of the return service.

Revision 9

6-35

450-SNUG

Table 6-11. SSA Return Service Real-Time Configuration Changes

Real-Time Configuration Changes GCMR OPM Return Service Interruption

Return Service Reacquisition Noncoherent Expanded User Spacecraft Frequency Uncertainty Channel Data Rate Noncoherent Transmit Frequency Redefinition of customer minimum EIRP Redefinition of customer maximum EIRP I/Q Power Ratio Channel Data Format Channel Data Bit Jitter DG1 Mode Polarization Data Group DG2 Coherency (coherent or noncoherent) Periodic Convolutional Interleaving DG2 Carrier Modulation Data Source/Channel Configuration G2 inversion Frame Length Frame Sync Word Length Frame Sync Word Bit Pattern Sync Strategy Parameters

98/03 98/07 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04

OPM 03 OPM 07 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03

Yes No No Yes Yes No Yes No No Yes No Yes Yes No Yes Yes No No No No No

Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Additionally, any reconfigurations to the forward service that cause forward link interruption will also cause return interruption for coherent return links. Any other reconfigurations of the SN ground terminals may momentarily affect signal tracking.

2.

3. 4.

The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS SSA return service signal parameters listed in Table 6-9. The SN ground terminal will open-loop point the TDRS SSA antenna in the direction of the customer platform. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted
6-36 450-SNUG

Revision 9

range and Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by the SN ground terminal is either one-way return (Forward Doppler compensation enabled) or two-way (Forward Doppler compensation inhibited). For coherent operation, the Doppler correction is based upon the forward service frequency. 5. After the forward service has been acquired, the SN ground terminal will acquire the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time limits listed in Table 6-9. Return service will be achieved at the SN ground terminal receiver output within the total channel acquisition time limits listed in Table 6-9, which includes SN ground terminal symbol, deinterleaver (if applicable), and Viterbi decoder synchronization. b. Noncoherent (DG1 Mode 2 and DG2 Noncoherent) 1. This mode of customer platform operation does not require a TDRSS (MA or SSA) forward service signal to be received by the customer platform. However, the customer platform transmitter must be commanded to turn on when noncoherent transmissions are desired, either by stored commands, on-board configuration settings, or direct commands from its customer MOC. 2. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS SSA return service signal parameters listed in Table 6-9 . 3. The SN ground terminal will open-loop point the TDRSS SSA antenna in the direction of the customer platform. 4. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by the SN ground terminal is one-way return and based on the customer platform transmission frequency stated in the SHO and any subsequent OPMs. 5. The SN ground terminal will acquire the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time limits listed in Table 6-9. Return service will be achieved at the SN ground terminal receiver output within the total acquisition time limits listed in Table 6-9, which includes SN ground terminal symbol and Viterbi decoder synchronization. c. DG1 Mode Transitions 1. DG1 Mode 2 to DG1 Mode 1 (or 3) Transitions. A TDRSS (MA or SSA) forward service must be scheduled to be established prior to customer
6-37 450-SNUG

Revision 9

2.

MOC transmission of the GCMR to reconfigure the TDRSS for DG1 mode 1 (or 3) operations (refer to paragraph 6.3.5.a.(1)). DG1 Mode 1 (or 3) to DG1 Mode 2 Transitions. When the customer platform switches to the noncoherent mode (DG1 mode 2), customer platform return service signal parameters (e.g., carrier and channel PN codes) are changed causing the SN ground terminal to drop TDRSS SSA return service signal lock. Customer platform transponders designed to automatically switch from a coherent transponder mode to a noncoherent mode when the TDRSS SSA/MA forward service signal is lost will result in SN ground terminal loss of SSA return service signal lock. Reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data.

d. DG2 Mode Transitions 1. DG2 noncoherent to DG2 coherent Transitions. A TDRSS (MA or SSA) forward service must be scheduled to be established prior to customer MOC transmission of the GCMR to reconfigure the TDRSS for DG2 coherent operations (refer to paragraph 6.3.5.a.(1)). 2. DG2 coherent to DG2 noncoherent Transitions. When the customer platform switches to the noncoherent mode, the resulting customer transmit frequency offset will probably cause the SN ground terminal to drop TDRSS SSA return service signal lock when the switch is made. If return service signal lock is lost, reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data.

Revision 9

6-38

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Minimum channel data bit transition density (required for acquisition/reacquisition) Consecutive channel data bits without a bit transition (required for acquisition/reacquisition) Minimum channel symbol transition density (Note 3) Consecutive channel symbols without a symbol transition Symbol asymmetry (peak) Symbol jitter and jitter rate (note 4) Phase imbalance DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 BPSK Baud rate < 1.024 Msps Baud rate > 1.024 Msps QPSK Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain Imbalance DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 BPSK Baud rate < 1.024 Msps Baud rate > 1.024 Msps QPSK Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps

> 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 >128 randomly distributed symbol transitions within any sequence of 512 symbols <64 symbols < +3 percent < 0.1 percent < + 5 degrees < + 5 degrees < + 3 degrees

< + 9 degrees < + 3 degrees < + 5 degrees < + 3 degrees < + 0.50 dB < + 0.50 dB < + 0.25 dB

< + 1.0 dB < + 0.25 dB < + 0.50 dB < + 0.25 dB

Revision 9

6-39

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Phase nonlinearity (applies for all types of phase nonlinearities) (peak) DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain flatness (peak) DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Gain slope (peak) DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps AM/PM DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps < 15 degrees/dB < 12 degrees/dB < 15 degrees/dB Not specified < 0.1 dB/MHz over +3.5 MHz Not specified < 0.1 dB/MHz over +3.5 MHz Not specified < 0.4 dB over +1.0 MHz < 0.3 dB over +3.5 MHz < 0.4 dB over +2.1 MHz < 0.3 dB over +3.5 MHz < 0.4 dB over +2.1 MHz < 4 degrees over +1.0 MHz < 3 degrees over +3.5 MHz < 4 degrees over +2.1 MHz < 3 degrees over +3.5 MHz < 4 degrees over +2.1 MHz

Revision 9

6-40

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

AM/PM (contd) DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Noncoherent frequency stability (peak) (Notes 5, 6, 11) +700 Hz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time + 3 kHz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time + 35 kHz customer oscillator frequency uncertainty 1-sec average time Baud rate per channel < 12.5 ksps Baud rate per channel > 12.5 ksps 5-hr observation time 48-hr observation time Incidental AM (peak) At frequencies >10 Hz for data rates <1 kbps; At frequencies >100 Hz for data rates 1 kbps Spurious PM (rms) DG1 DG2 BPSK QPSK I/Q = 4:1 I/Q = 1:1 < 2 degrees < 1 degree < 2 degrees < 2 degrees <5 percent < 7.37 x 10 < 26 x 10
-9 -6 -6 -9 -9 -7 -7

< 15 degrees/dB < 12 degrees/dB

< 3 x 10 < 1 x 10 < 3 x 10

3 x 10-9 4.3 x 10-7 1.29 x 10-6

< 3.77 x 10 < 11.3 x 10

Revision 9

6-41

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Minimum 3-dB bandwidth prior to power amplifier DG1 DG2 Phase noise (rms) (Note 7) DG1 Mode 1 Doppler Tracking Required (Note 10) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Channel baud rate > 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz DG1 Mode 2 Doppler Tracking Required (Notes 10, 11) All baud rates 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz 2.0 rms 1.0 rms 1.0 rms 1.5 rms 25.0 rms 2.2 rms 2.0 rms 1.0 rms 1.0 rms 1.5 rms 1.0 rms 1.0 rms 1.5 rms >4.5 MHz or two times maximum baud rate, whichever is larger >2 times maximum channel baud rate

Revision 9

6-42

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Phase noise (rms) (Note 7) (contd) DG1 Mode 2 (contd) Doppler Tracking NOT Required (Note 8) Channel baud rate < 40 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz Channel baud rate > 40 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz DG1 Mode 3 Doppler Tracking Required (Note 10) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 222.5 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Channel baud rate > 222.5 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz DG2 Coherent Doppler Tracking Required (Note 10) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz 50.0 rms 5.5 rms 2.5 rms 2.5 rms 7.5 rms 2.0 rms 1.5 rms 1.5 rms

1.0 rms 1.0 rms 1.5 rms

4.0 rms 2.8 rms 1.4 rms 50.0 rms 5.5 rms 1.8 rms

1.0 rms 1.0 rms 2.0 rms

Revision 9

6-43

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Phase noise (rms) (Note 7) (contd) DG2 Coherent (contd) Doppler Tracking NOT Required (Note 8) Channel baud rate < 18 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz 18 ksps < Channel baud rate < 1.024 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz Channel baud rate > 1.024 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 6 MHz DG2 Noncoherent Doppler Tracking Required (Notes 10, 11) All baud rates 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 12.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz 12.5 ksps < Channel baud rate < 1.024 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz 50.0 rms 5.5 rms 2.4 rms 2.4 rms 5.0 rms 1.0 rms 1.0 rms 2.0 rms 3.8 rms 2.3 rms 2.0 rms 25.0 rms 2.5 rms 2.0 rms 5.0 rms 1.0 rms 0.5 rms

2.0 rms 1.0 rms 1.0 rms 2.0 rms

Revision 9

6-44

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Description (Notes 1 and 2)

Phase noise (rms) (Note 7) (contd) DG2 Noncoherent (contd) Doppler Tracking NOT Required (Note 8) Channel baud rate > 1.024 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 6 MHz In-band spurious outputs, where in-band is twice the maximum channel baud rate DG1 modes 1 and 2 DG1 mode 3 Q channel baud rate < 1.024 Msps Q channel baud rate > 1.024 Msps DG2 Baud rate per channel < 1.024 Msps Baud rate per channel > 1.024 Msps Out-of-band emissions > 23 dBc > 30 dBc See Appendix D for NASA/GSFC Recommended Filtering in the 2290-2300 MHz band and allowable limits on out-ofband emissions, including spurs <3 percent <0.01 chip <0.01 chips/sec at PN code chip rate <0.3 dB <3 dB <10 degrees <+0.1 percent <+0.4 dB <12 dB <10 dB/sec -149.7 dBW -157.7 dBW (SSA cross-support: DG1 mode 3) > 23 dBc > 30 dBc

10.0 rms 1.5 rms 0.5 rms 0.5 rms

> 23 dBc

I/Q symbol skew (relative to requirements for I/Q data synchronization where appropriate) (peak) I/Q PN chip skew (relative to 0.5 chip) PN chip rate (peak), DG1 mode 2 (relative to absolute coherence with carrier rate) PN power suppression (noncoherent and coherent) Customer Antenna-Induced AM Customer Antenna-Induced PM Data rate tolerance I/Q power ratio tolerance Permissible Prec variation (without reconfiguration GCMR from customer MOC) (Note 9) Permissible rate of Prec variation Maximum Prec

Revision 9

6-45

450-SNUG

Table 6-12. TDRSS SSA Return Service Customer Platform Signal Constraints (contd)
Notes: 1. The definitions and descriptions of the customer constraints are provided in Appendix E. 2. When a constraint value is listed for a baud rate range and data is transmitted on both channels, the maximum baud rate of the 2 channels should be used to determine the constraint value applicable. 3. It is recommended that customers use G2 inversion to increase symbol transition density. Additionally, biphase symbol formatting increases symbol transition density. CCSDS randomization is recommended to aid in compliance with the data randomness requirements. 4. The symbol jitter and jitter rate are defined as the customer transmitted signal peak clock frequency jitter and peak clock jitter rate (sinusoidal or 3 random) as a percent of the symbol clock rate. 5. The frequency stability requirements are valid at any constant temperature (0.5 C) in the range expected during the mission. At a minimum, a temperature range of -10 C to +55 C shall be considered. 6. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of 700 Hz. If a customer cannot accurately define their transmit frequency to within 700 Hz, a customer can request a reconfiguration which would expand the oscillator frequency search to 3 kHz for DG1 and SQPSK DG2 configurations and 35 kHz for BPSK and QPSK DG2 configurations after the start of service. 7. Derivation of the phase noise requirements involved making assumptions about the distribution of the phase noise power in each frequency region. Since no phase noise PSD will exactly match the phase noise power distribution assumed for this derivation, phase noise PSDs which are close to violating the phase noise limits or phase noise PSDs which violate the phase noise limits should be evaluated on a case-by-case basis to determine their acceptability. 8. Applicable for customers that have no Doppler tracking requirement or can tolerate a total Doppler tracking error (system + customer) greater than 0.2 rad/sec (1, channel data rate > 1 kbps) or 0.4 rad/sec (1, channel data rate 1 kbps) assuming an averaging time of 1 second. 9. The minimum SHO EIRP should reflect the minimum Prec expected over the service period, where the Prec can exceed this minimum by no more than 12 dB. An actual customer Prec value that is 12 dB greater than the minimum may cause false PN lock or nonacquisition. 10. Will yield a total Doppler tracking error (system + customer) of ~0.2 rad/sec (1, channel data rate > 1 kbps) or 0.4 rad/sec (1, channel data rate 1 kbps) assuming an averaging time of 1 second. 11. If one-way Doppler tracking is required for orbit determination during customer launch and early orbit, contact NASA/GSFC Flight Dynamics (Code 595) for additional information and guidance about oscillator uncertainty.

6.3.6 Automated IF Service This section specifies characteristics and recommendations for the SSAR automated IF service. SN IF services are available to customers on a case-by-case basis. The IF service is supported through TDRS F1-F7 and TDRS F8-F10 via the SN ground terminal infrastructure, where the customer provides the receiver equipment and the SN only provides the signal at the IF with the characteristics described in this section. Paragraph 6.3.6.1 describes the aggregate channel characteristics of the TDRS spacecraft and SN ground segment for understanding the IF interface. The performance of the customer link greatly depends on the customer signal characteristics and the receiver used. Paragraph 6.3.6.2 describes potential signal characteristics and expected performance through the TDRS spacecraft and SN ground

Revision 9

6-46

450-SNUG

segment. The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with Code 450 to achieve desired performance. Changes to the operating conditions or configuration of a TDRSS SSAR IF service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in Section 10. Table 6-13 lists the SSA IF return service real-time configuration changes and their effects on the return service. Table 6-13. SSA Return IF Service Real-Time Configuration Changes
Real-Time Configuration Changes GCMR OPM Return Service Interruption

98/04 OPM 03 Yes Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Any other reconfigurations of the SN ground terminal may momentarily affect signal tracking.

Polarization

6.3.6.1 Channel Characteristics As discussed above, this is not an end-to-end service so a set of customer platform signal constraints is not available due to the dependencies on the exact customer signal characteristics as well as receiver capabilities. The IF service provides a SSAR signal through the TDRS spacecraft and SN ground segment, including IF output channel characteristics as specified in Table 6-14. This will allow customers to be able to understand the signal distortions that are outside of their control. For additional characteristics applicable to the SSAR IF service, refer to Table 6-9.

Revision 9

6-47

450-SNUG

Table 6-14. TDRS SSAR IF Service Spacecraft and Ground Segment Channel Characteristics
Parameter Description

TDRS S-band Receive Center Frequencies (note 1) 3-dB RF bandwidth (note 3) Gain Flatness (peak) (note 2) Gain Slope (note 2) Phase nonlinearity (applies for all
types of phase nonlinearities) (peak) (note 2)

2200 MHz to 2300 MHz 17 MHz 0.74 dB over 3.5 MHz 0.14 dB/MHz over 3.5 MHz 16.1 over 3.5 MHz > 0.57 dB/dB 6.5/dB 2.24 rms

AM/AM (note 2) AM/PM (note 2) Spurious PM (note 2) In-band spurious outputs (note 2)
Total Individual

27 dBc 40 dBc 1% (within 3-dB RF bandwidth) 2.3 rms 2.9 rms 4.6 rms 2.0 rms

Incidental AM (peak) (note 2) Phase noise (note 2) 1 Hz to 10 Hz 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 6 MHz Additional TDRS Ground Segment IF Characteristics: IF center frequency Output level Output VSWR

370 MHz -15 dBm 3 dB 1.3:1 into 50 load, 3 MHz from center frequency

Revision 9

6-48

450-SNUG

Table 6-14. TDRS SSAR IF Service Spacecraft and Ground Segment Channel Characteristics (contd)
Notes: 1. The customer receive center frequency that is scheduled for SN support will be translated to the center of the IF bandwidth. The signal and carrier frequency will be constrained such that the first null of the spectrum falls between 2200 and 2300 MHz. The SSAR IF service only supports noncoherent frequencies. The SSAR IF service supports only one S-band frequency through 1 TDRS at a time. These frequencies do not include the effects of Doppler shift. The SSAR IF service is not required to provide a Doppler-corrected IF output signal. The customer provided receiver needs to handle Doppler. 2. Constraint parameters are contributions from the TDRS spacecraft and the SN ground segment to the IF interface. Not included in these aggregate distortion amounts are TDRS spacecraft gain flatness linear and parabolic allowances and phase nonlinearity parabolic and cubic allowances as described in 405-TDRS-RP-SY-001, WU-02-01, and SY1-89E. Customer and receiver signal characteristics need to be considered to determine the end-to-end performance. Please contact GSFC Code 450 for further information. 3. The 3 dB RF bandwidth is larger than the specified 10 MHz bandwidth value specified in Table 6-9. This value has validated through spacecraft and ground terminal measurements, but may not be applicable to future TDRS.

Potential Signal Parameters and Signal Performance for IF Service As discussed earlier, this is not an end-to-end service so a set of well defined customer signal parameters is not available. This section describes example signal characteristics and expected performance through the TDRS spacecraft and SN ground segment. SN IF services are available to customers on a case-by-case basis. Customers should contact Code 450 if they are interested in this service to determine expected performance for their specific signal characteristics and receiver. The performance of the IF link is greatly dependent on the customer provided receiver. Typically, the SNUG specifies performance at BER of 10-5; BERs better than 10-5 may be possible for the automated IF service. NOTE: The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with GSFC Code 450 to achieve desired BER. All values in this section assume using a receiver with reasonable implementation loss. Table 6-15 provides expected required Eb/No values for example data rates and modulation schemes for a 10-5 BER. Additionally, Table 6-15 also provides the theoretical Eb/No and implementation loss values for those modulation and coding schemes at 10-5 BER over a simple AWGN channel. Table 6-15 also provides a potential minimum required Prec (dBW) equation for the example data rates, coding and modulation schemes through the IF service assuming these expected required Eb/No values, which were based upon simulation results and have not been verified by testing.
Revision 9 6-49 450-SNUG

6.3.6.2

Table 6-15. Example SSAR IF Service Implementation Loss Amounts and Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques Return IF Service Configuration (note 2) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 2)
2.9 dB Notes: 1. Unless otherwise noted, all values are based upon a customer transmitter power amplifier operating point of 1 dB OBO, i.e., AM/PM = 12/dB and AM/AM = 0.47 dB/dB. Values assume baseband equalization used. Values do not include margin. All values are given for a receiver with reasonable loss. Better performance may be achievable with better power amplifier and/or filters, etc. 2. These service configurations and data rates were based upon simulation results only and have not been verified by testing. Other data rates and modulation schemes may be possible. Please contact GSFC Code 450 for further information.

Revision 9 6-50 450-SNUG

Theoretical Required Eb/No (note 1)

1.7 dB

Implementation Required Prec (K) at Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 2) BER (LEO Program Track) (note 2)
1.2 dB -236.0 + 10 log (dr)

BPSK/QPSK/ SQPSK (unspread)

(1024, LDPCC

2048)

AR4A

< 1 Mbps

Section 7. KuSA Telecommunications Services

7.1 General

7.1.1 Available Services TDRSS KuSA services include forward and return telecommunications services, and tracking services. KuSA return service includes service through the SN receive equipment and an IF service, where the KuSA return IF service is not currently automated; however, automation of this service is being considered for implementation. Additionally, SN IF services are available to customers on a case-by-case basis, IF service requires the customer to provide the receiver equipment and the SN only provides the signal at the IF. Tracking services are discussed in Section 9. This section focuses on the RF interface between the TDRS and the customer platform. This interface is characterized by the technical requirements imposed and the operational capabilities provided by the TDRSS. The operational interfaces are described in further detail in Section 10. Data interfaces between the customer MOC and the SN are described in Section 3, paragraph 3.6. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessible via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. The GSFC Code 450 uses the NAM as a means of letting customers know of any performance constraints associated with the TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452PLAN-0002. 7.1.2 Interface Definition The RF interface between the TDRS and a customer platform is defined in terms of signal parameters, RF characteristics, and field of view. a. The RF interface for forward service represents the transmission by a TDRS of an appropriately modulated signal at or greater than a minimum specified signal EIRP in the direction of the desired customer platform. KuSA forward (KuSAF) service is discussed in paragraph 7.2. b. The RF interface for return service defines a minimum received power (Prec) at the TDRS antenna input for a specified data quality at the SN ground terminal receiver output. KuSA return (KuSAR) service is discussed in paragraph 7.3.

Revision 9

7-1

450-SNUG

NOTE: The KuSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 7.1.3 Customer Acquisition Requirements Acquisition and reacquisition by the customer platform of the TDRS transmitted signal requires prediction by the customer MOC of the customer platform receive frequency over various projected time periods. Similarly, acquisition and reacquisition by the SN ground terminal of the customer platform signal requires prediction by the customer MOC of the customer platform transmitter frequency over various projected time periods. The frequency predictions are ultimately incorporated in the Schedule Order (SHO) as customer platform frequencies for the specific service support periods. Refer to Section 9 for additional information on TDRSS tracking services that can assist customers in predicting their local oscillator frequencies. 7.1.4 TDRSS Acquisition Support to Customers For each scheduled TDRSS service support period, the customer requirements for signal acquisition/reacquisition, and the TDRSS capabilities to aid acquisition/ reacquisition, are as follows: a. Customer Epoch Uncertainty 1. Autotrack. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be +4.5 seconds and +3.2 seconds for customer platform operations requiring the TDRSS KuSA return service autotrack process within the TDRSS Primary FOV and Extended Elliptical FOV, respectively. Similarly, the maximum epoch time uncertainty of the customer platform ephemeris shall be 1.5 seconds for the TDRSS KuSA return service autotrack process within the TDRSS LEOFOV. NOTE: KuSA forward and return autotrack service for the Extended Elliptical FOV will be supported on a best-effort basis. Autotrack service is not available through the Ku-band return IF service. 2. Program track. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be +4.5 seconds and +3.2 seconds for customer platform operations using TDRSS KuSA open-loop pointing within the TDRSS Primary FOV and Extended Elliptical FOV, respectively. LEO Program track. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be

3.

Revision 9

7-2

450-SNUG

+1.5 seconds for customer platform operations requiring the TDRSS KuSA open-loop pointing for customers within the TDRSS LEOFOV. The customer MOC must know the b. Customer Frequency Uncertainty. operating frequency of the customer platform to within +5 kHz. c. Frequency Sweep on the Forward Link. After the start of the forward link service, the TDRSS has a forward service frequency sweep capability of +30 kHz. d. Noncoherent Return Expanded Frequency Search. After the start of the return link service, the TDRSS has a return service expanded frequency search capability of +20 kHz. 7.2 KuSA Forward Services

7.2.1 General The characteristics of the data provided to the SN ground terminal interface and the RF signals provided by the TDRS to the customer platform during TDRSS KuSA forward services are described in paragraphs 7.2.2 through 7.2.5. This discussion assumes that an appropriate forward service has been scheduled and a data signal is present at the SN ground terminal interface. 7.2.2 Signal Parameters The TDRSS KuSA forward service signal parameters are defined in Table 7-1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code for TDRSS KuSA forward service (refer to Section 10, paragraph 10.2.2). A description of the features inherent in the QPSK and BPSK signal parameters listed in Table 7-1 are discussed in paragraphs 7.2.2.1 and 7.2.2.2, respectively. 7.2.2.1 QPSK Signal Parameters a. Unbalanced QPSK Modulation. The I channel is used to transmit the customer command data and is referred to as the command channel. The Q channel transmits a range signal and is referred to as the range channel. The command channel/range channel power ratio for QPSK forward service signals is +10 dB. This unbalanced QPSK modulation minimizes the power in the range channel to a level adequate for customer platform range channel acquisition and tracking. This feature increases the power in the command channel by 2.6 dB over that for balanced QPSK modulation without increasing customer platform receiver complexity, increasing customer platform command channel acquisition time, or decreasing TDRSS range tracking accuracy. b. Spread Spectrum. All TDRSS KuSA forward services with data rates <300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed upon TDRSS forward services by the NTIA. This modulation scheme includes separate but simultaneous command and range channels. The command channel includes a rapidly acquirable PN code

Revision 9

7-3

450-SNUG

c.

and contains the forward service data. The range channel is acquired separately and contains a PN code which satisfies the range ambiguity resolution requirements. The length of the command channel PN code is 210-1, where the length of the range channel PN code is 256 times the command channel PN code length. The customer platform command channel acquisition can precede customer platform range channel acquisition; this feature permits rapid acquisition of the range channel by limiting the range channel PN code search to only 256 chip positions while the range channel PN code itself contains 261,888 chips. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward range and command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. Asynchronous Data Modulation. For data rates < 300 kbps, the forward service data received at the SN ground terminal from the NISN data transport system is directly modulo-2 added by the SN ground terminal to the command channel PN code sequence. The forward service data will be asynchronous with the carrier and the PN code. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is the command channel PN code sequence.

d. Functional Configurations. A further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in section B.2.2. e. Doppler Compensation. The TDRSS KuSA forward service carrier frequency (F) and the PN chip rate transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 7-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS KuSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency KuSA forward service carrier and PN code chip rate.

Revision 9

7-4

450-SNUG

Table 7-1. TDRSS KuSA Forward Service Signal Parameters

Parameter TDRS transmit carrier frequency (Hz) Carrier frequency arriving at customer platform (note 1) Carrier frequency sweep (note 4) Carrier frequency sweep duration (note 4) QPSK (PN modulation enabled)
Command channel radiated power Range channel radiated power

Description F FR +30 kHz 120 seconds +10 dB

QPSK Command Channel Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Data modulation Data format (note 2) Data rate restrictions (note 2) QPSK Range Channel Carrier PN code modulation Carrier suppression PN code chip rate PN code length (chips) PN code epoch reference PN code family Command channel carrier frequency delayed /2 radians PSK, + /2 radians 30 dB minimum Synchronized to command channel PN code chip rate (2 - 1) x 256 All 1's condition synchronized to the command channel PN code epoch. Truncated 18-stage shift register sequences
10

Transmit carrier frequency (F) PSK, + /2 radians 30 dB minimum 2 -1 Refer to 451-PN CODE-SNIP Gold codes
31 F 1469 96
10

Modulo-2 added asynchronously to PN code Not applicable 1 kbps - 300 kbps

Revision 9

7-5

450-SNUG

Table 7-1. TDRSS KuSA Forward Service Signal Parameters (contd)

Parameter BPSK (PN modulation enabled; also referred to as Spread Spectrum BPSK (SS-BPSK)) (note 5) Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) Data modulation Data format (note 2) Data rate restrictions (note 2) BPSK (PN modulation disabled) Carrier frequency (Hz) Data modulation Carrier suppression Data format (note 2) Data rate restrictions (notes 2, 3) Transmit carrier frequency (F) PSK, +/2 radians 30 dB minimum Not Applicable 300 kbps - 25 Mbps Transmit carrier frequency (F) PSK, + /2 radians 30 dB minimum 2 -1 Refer to 451-PN CODE-SNIP Gold codes
31 F 1469 96
10

Description

Modulo-2 added asynchronously to PN code Not applicable 1 kbps - 300 kbps

Notes: 1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. The SN ground terminal will round-off the customer receive frequency contained in the SHO to the nearest multiple of & 1469 Hz. Doppler compensation will be available for R <12 km/sec. During periods of Doppler compensation, FR = fo + E Hz, where fo = multiple of 1469 nearest the nominal center frequency && of customer platform receiver as defined by the customer MOC and E = e x fo x R /c + C; e < && +4.5 sec is the customer epoch uncertainty, R < 15 m/sec2, c is the free space speed of light in m/sec, and C = 1900 Hz. If Doppler compensation is inhibited after the start of the forward service, a transition profile will be initiated to slowly change the frequency from the compensate profile to this integer multiple of 1469 Hz. Forward service Doppler compensation will not increase the effective frequency rate of change seen at the customer receiver more than 330 Hz/sec relative to the frequency for a Doppler free carrier. 2. The forward data rate in this table is the baud rate that will be transmitted by the TDRSS (includes all coding and symbol formatting). For non-WDISC customers, forward data conditioning is transparent to the SN. These transparent operations should be performed by the customer prior to transmission to the SN data interface. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. Currently, the SN ground terminal data interface supports up to 7 Mbps; however, upgrades to support up to 25 Mbps are planned.

Revision 9

7-6

450-SNUG

Table 7-1. TDRSS KuSA Forward Service Signal Parameters (contd)

Notes (contd): 3. The SN is capable of supporting BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. 4. After the start of the KuSA forward service, if a customer MOC is unable to accurately define fo (the nominal center frequency of the customer platform receiver), the forward service carrier frequency can be swept. The KuSA forward service frequency sweep will be initiated by the SN ground terminal at fo-30 kHz and linearly swept to fo+30 kHz in 120 seconds and held at fo+30 kHz thereafter. The KuSA forward service frequency sweep does not impact simultaneous SN ground terminal Doppler compensation of the KuSA forward service carrier and PN code rate (if applicable). 5. Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required.

7.2.2.2 BPSK Signal Parameters a. BPSK Modulation (PN Modulation Enabled). The I channel is used to transmit the customer command data and is referred to as the command channel. TDRSS KuSA forward services with data rates equal to and below 300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed on the TDRSS forward services by the NTIA. The command channel includes a rapidly acquirable PN code and contains the forward service data. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. NOTE: Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to a UQPSK mode. Contact Code 450 if additional flexibility is required. b. BPSK Modulation (PN Modulation Disabled). For data rates greater than 300 kbps, there is no PN code modulation and the customer data directly BPSK modulates the carrier by /2 radians.

Revision 9

7-7

450-SNUG

NOTE: The SN is capable of supporting non-spread BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. c. Asynchronous Data Modulation. The forward service data will be asynchronous with the carrier. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is carrier only. d. Functional Configurations. A further description of the functional configurations and data polarity ambiguity is found in section B.2.2. e. Doppler Compensation. The TDRSS KuSA forward service carrier frequency (F) transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 7-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS KuSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed frequency KuSA forward service carrier. 7.2.3 Communications Services The TDRSS KuSA forward services available are listed in Table 7-2. Table 7-3 lists their salient characteristics. The definitions for the parameters listed in Table 7-3 are contained in Appendix E. 7.2.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS KuSA forward service during a scheduled service support period are usually initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for the GCMRs is provided in Section 10. Table 7-4 lists the KuSA forward service real-time configuration changes and their effects on the forward service signal.

Revision 9

7-8

450-SNUG

7.2.5 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS KuSA forward service signal acquisition by the customer platform and do not include operational procedures related to acquisition: a. KuSAF Program Track and LEO Program Track Scenarios: 1. The TDRSS KuSA forward service signal does not depend on a customer platform return service. 2. Prior to the start of the TDRSS KuSA forward service, the TDRSS KuSA antenna will be open-loop pointed in the direction of the customer platform. 3. At the start of the TDRSS KuSA forward service as defined by the SHO, the TDRS will radiate, in the direction of the customer platform, a signal compatible with the TDRSS KuSA forward service signal parameters listed in Table 7-1. The EIRP directed towards the customer platform is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 7-2. 4. The customer platform receiving system will search for and acquire the command channel PN code (if applicable) and carrier. Normally, a customer MOC will not be transmitting forward service data to the NISN data transport system until the forward service signal has been acquired by the customer platform and the acquisition verified by the customer MOC from customer platform return service telemetry. Some customer platforms may require that there be no data transitions during the signal acquisition process, while others may merely result in longer acquisition times. 5. For QPSK modulation, the customer platform receiving system will search for and acquire the range channel PN code upon acquisition of the command channel PN code and carrier. 6. Depending upon the customer platform receiving system design, upon completion of forward link acquisition and subsequent customer platform transition to signal tracking, the customer platform transmitting system may either switch to a coherent mode or remain in a noncoherent mode until commanded by the customer MOC to switch. 7. The SN ground terminal will continue Doppler compensation of the TDRSS KuSA forward service signal unless requested by the customer MOC to inhibit the Doppler compensation. 8. Acquisition times (Tacq) in the customer platform receiver is a function of the customer platform receiver design and signal-to-noise density ratio. The customer platform forward service acquisition time must be considered in determining the overall return service acquisition time for customer platform with a coherent mode of operation.

Revision 9

7-9

450-SNUG

Appendix A provides example link calculations for the TDRSS KuSA forward service. b. KuSAF Acquisition Scenario with Return Autotrack Services: 1. Prior to return autotrack acquisition, the TDRSS forward service EIRP will be the program or LEO program track high-power values, whichever is applicable based upon customer characteristics (see paragraph 7.2.5.a for a description of the program and LEO program track acquisition scenarios). The EIRP directed towards the customer platform is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 7-2. The appropriate TDRS KuSA autotrack normal-power or high-power mode signal EIRP listed in Table 7-2 will be provided after return service autotrack acquisition is achieved. Table 7-2. TDRSS KuSA Forward Service
Parameter Field of view (FOV) (each TDRS) Primary (PFOV) +22 degrees east-west +28 degrees north-south (rectangular) Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 1) < + 4.5 sec Description LEO (LEOFOV) +10.5 degree conical Extended Elliptical (EEFOV) (F8-F10) 24.0 degrees inboard east-west 76.8 degrees outboard east-west +30.5 degrees north-south < + 3.2 sec

9.

< + 1.5 sec

RHC or LHC selectable Autotrack (PFOV, LEOFOV, and EEFOV) (notes 3, 5) LEO Program Track (LEOFOV) Program Track (PFOV and EEFOV)

TDRS antenna axial ratio (maximum) Normal or high-power mode TDRS signal EIRP (minimum) (note 4) Normal power mode High power mode Transmit frequency (nominal) (note 2) RF bandwidth (3dB, minimum) Duty factor +46.5 dBW +48.5 dBW 13.775 GHz +0.7 MHz 50 MHz 100 percent (normal and high power) 44 dBW 46 dBW 40.5 dBW 42.5 dBW 1 dB over 3-dB beamwidth 1 dB over 3-dB beamwidth 1.5 dB

Revision 9

7-10

450-SNUG

Table 7-2. TDRSS KuSA Forward Service (contd)

Notes: 1. Operational considerations may limit choice of TDRS antenna polarization. The KuSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 2. The customer MOC must include the best estimate of the customer platform receiver center frequency at the time of startup of each scheduled service support period in its service specification code (refer to Section 10, paragraph 10.2.2). The TDRSS KuSA forward service carrier frequency is then implemented by the SN ground terminals to the accuracy of the SN ground terminal frequency standard except during Doppler compensation. 3. EIRP values are for a TDRSS forward service with a TDRSS return autotrack service acquired. Forward service EIRP will default to high power program track values when: 1) a simultaneous return service with autotrack enabled is ongoing AND 2) TDRSS is in the autotrack acquisition process. Return service autotrack acquisition will be achieved within 10 seconds of KuSA return service Prec consistent with the BER or autotrack acquisition, whichever is larger. Following return autotrack acquisition, the forward EIRP power mode reverts to the normal or high power mode specified in the SHO. Autotrack service is not available through the Ku-band return IF service. 4. The autotrack EIRP will be transmitted towards a customer meeting the required ephemeris uncertainties for the Primary FOV, LEOFOV, or the Extended Elliptical FOV. The program track EIRP will be transmitted towards a customer meeting the required ephemeris uncertainties for the Primary FOV or the Extended Elliptical FOV. The LEO program track EIRP will be transmitted towards a customer meeting the required LEO ephemeris uncertainties for the LEOFOV. Customers may experience better performance through the KuSA program track and LEO program track services than listed in this document. Performance improvements particular to each customer should be discussed with GSFC Code 450. 5. KuSA forward autotrack service for the Extended Elliptical FOV will be supported on a best-effort basis.

Revision 9

7-11

450-SNUG

Table 7-3. Salient Characteristics for TDRSS KuSA Forward Services

Parameter (Note 1) Value (Note 1) QPSK +10 +0.5 dB BPSK NA

Command channel radiated power Range channel radiated power

Modulator phase imbalance (peak) Modulator gain imbalance (peak) Relative phase between command and range channels Data asymmetry (peak) (Note 2) Data rise time (90 percent of initial state to 90 percent of final state) (Note 2) Phase nonlinearity (peak) Gain flatness (peak) Gain slope (peak) AM/PM PN chip jitter (rms) (including effects of Doppler compensation) Data bit jitter (peak) (Note 2) Spurious PM (rms) In-band spurious outputs Incidental AM (peak) Phase noise (rms) 1 Hz - 10 Hz 10 Hz - 32 Hz 32 Hz - 1 kHz 1 kHz - 25 MHz Command/range channel PN chip skew (peak) PN chip asymmetry (peak) PN chip rate (peak) (relative to absolute coherence with carrier rate)

+3 degrees (for each BPSK channel) +0.25 dB QPSK 90 +3 degrees +3 percent <5 percent of bit duration +0.15 radian over +17.5 MHz +0.8 dB over +17.5 MHz +0.1 dB/MHz <7 degrees/dB QPSK/SS-BPSK <1 degree <1 percent <1 degree >27 dBc <2 percent <1.5 degrees <1.5 degrees <4 degrees <2 degrees QPSK/SS-BPSK <0.01 chip / NA <0.01 chip <0.01 chips/sec at PN code chip rate BPSK NA NA NA BPSK NA BPSK NA

Notes: 1. The definitions and descriptions of the salient characteristics are provided in Appendix E. 2. These values are the TDRSS contributions for data asymmetry, data transition time, and bit jitter, assuming perfect forward service data is provided to the SN ground terminal. The actual contributions by the NISN data transport system are negligible compared to those contributed by the TDRSS, since the SN ground terminal reclocks the data before it is processed by the SN ground terminal into the forward service signal.

Revision 9

7-12

450-SNUG

Table 7-4. KuSA Forward Service Real-Time Configuration Changes

Real-Time Configuration Changes Customer Receiver Center Frequency Doppler Compensation Inhibit Doppler Compensation Reinitiation Forward Service Reacquisition (note 1) Forward Service Sweep Request (refer to Table 7-1) Data Rate Polarization Initiation or termination of the command channel PN code (note 2) Forward Service Normal/High Power Mode EIRP Change GCMR 98/04 98/08 98/04 98/03 98/05 98/04 98/04 98/04 98/06 OPM OPM 03 OPM 11 OPM 03 OPM 02 OPM 04 OPM 03 OPM 03 OPM 03 OPM 06 Forward Service Signal Interruption Yes No No Yes Yes No Yes No No

Notes: 1. Forward service reacquisition is a TDRSS reinitiation of forward link service by applying a 1 MHz frequency offset for 3 seconds to the predicted customer receive frequency specified in the customers service specification code (refer to Section 10, paragraph 10.2.2). 2. Initiation or termination of the command channel PN code enables or disables all forward link PN modulation (including the command and range channel, if applicable), respectively.

7.3

KuSA Return Services

7.3.1 General The RF signals provided by the customer platform to the TDRS and the characteristics of data provided at the SN ground terminal interface are defined in paragraphs 7.3.2 through 7.3.6. This discussion assumes that an appropriate return service has been scheduled and a data signal is present at the TDRS interface. The KuSA return service supports data services using the SN ground terminal receivers and an IF service, where automation of this service is currently being considered for implementation. Contact Code 450 for availability. 7.3.2 Signal Parameters The TDRSS KuSA return service signal parameters are listed in Table 7-5. Refer to paragraph 7.3.6 for KuSA return IF service signal parameter characteristics and recommendations. The services are divided into 2 major groups, Data Group 1 (DG1) and Data Group 2 (DG2). DG1 services utilize spread spectrum modulation while DG2 services are non-spread. A description of the features inherent in the DG1 and DG2 services is discussed in paragraphs 7.3.2.2 and 7.3.2.3, respectively. Within each data group, there are several types of modulation. Additionally, both data groups support coherent and noncoherent modes. A description of these general characteristics is provided in paragraph 7.3.2.1.

Revision 9

7-13

450-SNUG

Table 7-5. TDRSS KuSA Return Service Signal Parameters

Parameter (Note 5) DG1 (notes 1, 6) Transmit carrier frequency (Hz) (note 4) Carrier (F1) reference (Hz) DG1 modes 1 and 3
1600 1469 F R

Description (Note 5) F1

DG1 mode 2 PN code modulation DG1 modes 1 and 2 DG1 mode 3 I channel PN code chip rate (chips/sec)

Customer platform transmitter oscillator SQPN, or BPSK (see Appendix B and Table 7-6) PSK +/2 radians
31 F 1600 x 96 1

PN code length (chips) DG1 modes 1 and 3 DG1 mode 2 PN code epoch reference DG1 mode 1 I channel Epoch (all 1's condition) synchronized to epoch (all 1's condition) of received forward service range channel PN code Epoch delayed x + 1/2 PN code chips relative to I channel PN code epoch Not Applicable Same as DG1 mode 1, I channel (2 -1) x 256 2 -1
11 10

Q channel (note 3) DG1 mode 2 DG1 mode 3, I channel

Revision 9

7-14

450-SNUG

Table 7-5. TDRSS KuSA Return Service Signal Parameters (contd)

Parameter (Note 5) DG1 (notes 1, 6)(cont) PN code family DG1 modes 1 and 3 DG1 mode 2 Data modulation (notes 1, 6) DG1 modes 1 and 2 DG1 mode 3 I channel Q channel Data format Without convolutional encoding With convolutional encoding DG1 mode 1 data rate restrictions (uncoded) Total I channel Q channel DG1 mode 2 data rate restrictions (uncoded) Total I channel Q channel DG1 mode 3 data rate restrictions (uncoded) Total I channel Q channel DG1
Q channel power I channel power

Description (Note 5)

Truncated 18-stage shift register sequences Gold codes Modulo-2 added asynchronously to PN code Modulo-2 added asynchronously to PN code PSK +/2 radians NRZ-L, NRZ-M, NRZ-S NRZ-L, NRZ-M, NRZ-S 1 - 600 kbps 1 - 300 kbps 1 - 300 kbps 1 - 600 kbps 1 - 300 kbps 1 - 300 kbps I+Q 1 - 300 kbps 1 kbps - 6 Mbps

restrictions (note 2) 1:1 to 4:1 NA 1:1 to 4:1

Single data source-identical data Single data source-single data channel Dual data sources

Revision 9

7-15

450-SNUG

Table 7-5. TDRSS KuSA Return Service Signal Parameters (contd)

Parameter (Note 5) DG2 (notes 1, 6) Transmit carrier frequency (Hz) (note 4) Carrier (F2) reference (Hz) DG2 Coherent
1600 xFR 1469

Description (Note 5) F2

DG2 Noncoherent Data modulation (notes 1, 6) Data format Without convolutional encoding With Rate 1/2 convolutional encoding Data rate restrictions (uncoded) Total (note 1) I channel Q channel DG2
I channel power restrictions Q channel power

Customer platform oscillator BPSK, SQPSK, or QPSK (refer to Appendix B and Table 7-6) NRZ-L, NRZ-M, NRZ-S NRZ-L, NRZ-M, NRZ-S 1 kbps - 300 Mbps 1 kbps - 150 Mbps 1 kbps - 150 Mbps

Single data source-alternate I/Q bits Single data source-alternate I/Q encoded symbols Single data source-single data channel Dual data sources 1.

1:1 1:1 NA 1:1

2.

3. 4. 5. 6.

Notes: Customer platform data configurations, including specific data rate restrictions for coding and formatting, are defined in Table 7-6 for TDRSS KuSA return service (refer also to Appendix B). Unless otherwise stated, the data rate restrictions given in this table assume uncoded and NRZ formatted signals. For DG1, the Q/I power parameter range can vary from 1:1 to 4:1 continuously during specification of applicable parameter values in the NCCDS scheduling database and during realtime service reconfiguration. However if this parameter is respecified in schedule requests to the NCCDS (refer to paragraph 10.2.2), it is expressed as the ratio of two single-digit integers. The Q channel PN code sequence must be identical to the I channel PN code sequence, but offset by x + 1/2 PN code chips, where x >20,000. The value of x is defined by the PN code assignment for a particular customer platform (refer to 451-PN CODE-SNIP). The center frequency, fo, of the customer platform transmitter must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. Unless otherwise noted, all data rate values are to be interpreted as data bit rates, and not as data symbol rates. Data rates and modulation schemes are based upon support through the KuSAR 225 MHz SN ground terminal receivers. Other data rates and modulation schemes are possible through the Ku-band return IF service, which is currently not automated but is being considered for implementation. Please refer to paragraph 7.3.6 and contact GSFC Code 450 for further information.

Revision 9

7-16

450-SNUG

7.3.2.1 General Modulation and Coherent/Noncoherent Description a. SQPN Modulation. SQPN modulation is used to prevent simultaneous transitions of the I and Q PN sequences. For SQPN modulation, the PN chips of the I and Q channel are staggered by a 1/2 chip. For data configurations that use two PN spread channels, SQPN modulation must be used. b. SQPSK Modulation. SQPSK modulation staggers one channel with respect to the other to prevent synchronous transitions. For non-spread signal configurations with identical I and Q symbol rates that are NRZ symbol formatted, SQPSK modulation must be used. The symbols of the Q channel are delayed 1/2 symbol relative to the I channel. c. QPSK Modulation. QPSK modulation is available when there is no relation between the I and Q channel transitions. For dual data source configurations, in which one or both channels are not spread and SQPSK is not required, QPSK modulation is used. d. BPSK Modulation. BPSK modulation is available for single data source configurations that use only one channel of the link. NOTE: For SQPN and SQPSK modulation, the spectral characteristics of a customer platform saturated power amplifier will, to a great degree, retain the spectral characteristics of the band-limited input signal to that amplifier. This should result in better control of out-of-band emissions, which, in turn, provides more efficient communications and less interference to the customer platform using adjacent frequency channels on the TDRS links. e. Coherent Mode. For coherent modes, the customer platform transmitted return link carrier frequency and PN code clock frequency (if applicable) are derived from the customer platform received forward link carrier frequency. For coherent PN spread return links, the customer return PN code length is identical to the length of the received forward service range channel PN code. The customer return I channel PN code epoch is synchronized with the epoch of the received forward service range channel PN code. For coherent operations, two-way Doppler measurements and range measurements (if PN spread) are available. f. Noncoherent Mode. For noncoherent modes, the customer platform transmit return link carrier frequency and PN code clock frequency (if applicable) are derived from an on-board local oscillator. The customer platform transmit frequency for noncoherent service must be defined by the customer MOC to an accuracy of +5 kHz in its service specification code when requesting TDRSS

Revision 9

7-17

450-SNUG

KuSA return service. For customers whose frequency uncertainty is greater than +5 kHz, an expanded frequency search capability is available. g. Asynchronous Data Modulation. The data modulation is asynchronous to the carrier and the channel PN code (if applicable). This prevents Doppler variations of the forward service frequency from affecting the return service data rate. 7.3.2.2 DG1 Signal Parameters DG1 signal parameters are subdivided into three modes of operation, DG1 modes 1, 2, and 3. For all DG1 modes, the PN code clock must be coherently related to the transmitted carrier frequency. This feature permits the customer platform transmitter to use a common source for generating the carrier and the PN code clock frequencies. 451-PN CODE-SNIP defines all the salient characteristics for the DG1 PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments. These three DG1 modes which are distinguished as follows: a. DG1 Mode 1. DG1 mode 1 must be used when TDRSS range and two-way Doppler measurements (coherent transponder operations) are required concurrently with return service low-rate data transmission. Return service signal acquisition by the SN ground terminal for DG1 mode 1 is possible only when the scheduled TDRSS KuSA forward service signal is acquired by the customer platform and the PN code and carrier transmitted by the customer platform are coherently related to the forward service signal from the TDRS. If the TDRSS forward service signal becomes unavailable to the customer platform, the customer platform transmitter must switch to noncoherent transmitter operation (DG1 mode 2) (refer to paragraph 7.3.5.d.(2)). In order to reacquire the DG1 mode 2 signal, the return service must be reconfigured. The I and Q channel PN codes are generated from a single code generator. For DG1 mode 1 operation, the I and Q channel PN codes are identical but are offset by at least 20,000 chips. This separation is adequate for TDRSS to identify each data channel unambiguously without requiring a unique PN code for each channel. b. DG1 Mode 2. DG1 mode 2 can be used when the SN ground terminal return service signal acquisition is necessary without the requirement for prior customer platform signal acquisition of the TDRSS KuSA forward service (noncoherent transponder operation). The customer platform transmit frequency for DG1 mode 2 service must be defined by the customer MOC to an accuracy of +5 kHz in its service specification code when requesting TDRSS KuSA return service. For customers whose frequency uncertainty is greater than +5 kHz, an expanded frequency search capability of +20 kHz is available after start of the return service. For DG1 mode 2, the I and Q channel PN codes are unique 211-1 Gold Codes.

Revision 9

7-18

450-SNUG

c.

DG1 Mode 3. DG1 mode 3 can be used when range and two-way Doppler measurements (coherent transponder operations) are required concurrently with return service high-rate data transmission. Restrictions on DG1 mode 3 signal acquisition are identical to those for DG1 mode 1. In Mode 3, the Q channel must contain only data and no PN code. d. Functional Configurations. Table 7-6 lists the DG1 KuSA return service functional configurations and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in section B.3.2.

7.3.2.3 DG2 Signal Parameters DG2 signal parameters are subdivided into two modes of operation, DG2 coherent and noncoherent. DG2 must be used when the return service data rate equipment exceeds the capability of DG1 operations. DG2 operations cannot provide TDRSS range tracking because PN code modulation is not used. The two DG2 modes are distinguished as follows: a. DG2 Coherent. Return service signal acquisition by the SN ground terminal for DG2 coherent is possible only when the scheduled KuSA TDRSS forward service signal is acquired by the customer platform and the carrier transmitted by the customer platform are coherently related to the forward service signal from the TDRS. TDRSS two-way Doppler tracking can be provided when the DG2 carrier is coherently related to the TDRSS KuSA forward service carrier frequency. b. DG2 Noncoherent. The DG2 carrier is independent of the TDRSS KuSA forward service carrier frequency. The customer platform transmit frequency for DG2 noncoherent service must be defined by the customer MOC to an accuracy of +5 kHz in its service specification code when requesting TDRSS KuSA return service. For customers whose frequency uncertainty is greater than +5 kHz, an expanded frequency search capability of +20 kHz is available after start of the return service. c. Functional Configurations. Table 7-6 lists the DG2 KuSA return service functional configurations through the SN ground terminal receiver and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.3.3. Refer to paragraph 7.3.6 for the KuSAR IF service functional configurations.

Revision 9

7-19

450-SNUG

Revision 9
Return Service Configuration6 Single Source Data BPSK Rate 1/2 coded Rate 1/3 coded Uncoded SQPN Identical I & Q channel data

Table 7-6. KuSA Return Service Configurations

Source Data Rate Restrictions and Availability5 DG1 Mode 11 and 21,4 Data format NRZ Data rate 1 - 150 kbps1 NRZ Rate 1/2 coded NRZ 1 - 300 kbps 1 - 150 kbps Uncoded SQPSK SQPSK3 Rate 1/2 coded encoded symbols Alternating data I/Q alternate I/Q NRZ 1 - 300 kbps 1

DG2 Mode 32 Coherent3 and Noncoherent3,4 Data rate NRZ 1 kbps 150 Mbps Data format NRZ Data rate 1 kbps 75 Mbps

Data format

7-20
450-SNUG

NRZ NRZ NRZ

1 kbps 10 Mbps >10 150 Mbps 1 kbps 300 Mbps

Individually rate 1/2 coded Individually rate 1/3 coded Uncoded

Table 7-6. KuSA Return Service Configurations (contd)

Source Data Rate Restrictions and Availability5,6 Return Service Configuration6 Data format Dual Data Sources (data rates are for each source separately) SQPN1, QPSK2,3 SQPSK3 Rate 1/2 coded or NRZ DG1 Mode 11 and 21,4 Data rate 1 - 150 kbps Data format NRZ 32 Data rate I: 1 - 150 kbps Q: 1 kbps 3 Mbps I: 1 - 300 kbps Q: 1 kbps 6 Mbps DG2 Mode Coherent3 and Noncoherent3,4 Data format NRZ Data rate 1 kbps 75 Mbps

Revision 9
1. 2. 3.

Rate 1/3 coded Uncoded

NRZ

1 - 300 kbps

NRZ

NRZ

1 kbps 150 Mbps

Configuration supported Notes: Configuration not supported For DG1 mode 1 and 2 configurations: a. Data on a single I or Q channel, but not both channels: BPSK modulation is used where the data is modulo-2 added to the PN code. b. Data on both the I and Q channels: SQPN modulation is used and the SN supports I:Q power ratios of 1:1 to 1:4. For DG1 mode 3 configurations: a. The modulation is QPSK, where the I channel data is modulo-2 added to the PN code, and the Q channel data directly modulates the carrier at +/2 radians. b. The SN supports I:Q power ratios of 1:1 to 1:4. For DG2 configurations: a. Single data source configurations with data on one channel: BPSK modulation is used. b. Single data source configurations with data on both channels: SQPSK modulation and an I:Q power ratio of 1:1 is used. For the alternate I/Q bit configuration, the SN requires the I and Q channels be independently differentially formatted (-M,-S). c. Dual data source configurations: SQPSK must be used when there are identical baud rates on the I and Q channels (see paragraph 7.3.2.1.b); QPSK is used for all other configurations; for both SQPSK and QPSK, an I:Q power ratio of 1:1 is supported. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 5 kHz. If a customer cannot accurately define their transmit frequency to within + 5 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 20 kHz after the start of service. Unless otherwise noted, all data rates are to be interpreted as data bit rates, and not as data symbol rates. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. Appendix B describes the functional configurations and associated I-Q channel and data polarity ambiguities. Additionally, Figure B-10 depicts the SN supported convolutional coding schemes. For a channel with rate 1/2 coding and data rates greater than 10 Mbps, the customer transmitter must be configured to use an N-parallel encoder, where N is the number of branch rate 1/2 encoders for the channel. N = channel data rate in bps/1x107, where N is rounded to the next higher integer if N is not an integer. Data rates and modulation schemes are based upon support through the KuSAR SN ground terminal receivers. Other data rates and modulation schemes are possible through the Ku-band IF services, where the KuSA return IF service is not currently automated; however, automation of this service is being considered for implementation. Please refer to paragraph 7.3.6 and contact GSFC code 450 for further information.

7-21
450-SNUG

4. 5. 6. 7.

7.3.3 Communications Services To obtain TDRSS KuSA return service performance defined in this paragraph, the customer platform transmitted signal must meet the requirements found in Table 7-7 and signal characteristics specified in Table 7-9. The TDRSS KuSA return service performance defined in this paragraph also assumes return service operation in an AWGN environment. Appendix G discusses performance degradations to the TDRSS KuSA return service due to RFI. Example link calculations are provided in Appendix A. & TDRSS KuSAR supports only supports non-powered flight customer dynamics ( R < 2 3 && R 12 km/sec, R < 15 m/sec , and &&& < 0.02 m/sec ). 7.3.3.1 Acquisition The KuSAR service supports acquisition for customer platforms operating under non-powered flight dynamics as defined in paragraph 7.3.3. KuSAR acquisition will be protected against false SN ground terminal lock due to: interfering customer platform PN codes, customer platform PN code sidelobes, and carrier recovery. The KuSAR service total channel Tacq will be less than or equal to the sum of the following, which are given in Table 7-7: a. Autotrack acquisition time (when the TDRSS KuSA return service autotrack mode is enabled) b. PN (DG1 only) and carrier acquisition time c. Symbol/Decoder synchronization time (for coded data) or Symbol synchronization time (for uncoded data). Tacq assumes that the customer platform return service signal is present at the SN ground terminal at the start time of the scheduled return service support period. The total acquisition process consists of the following acquisition sub-processes: a. If autotrack is enabled, autotrack acquisition will commence upon the start of the scheduled return service support period or at the instant at which user signal energy is present at the KuSAR autotrack signal processing input, whichever occurs last, and will occur within the time given in Table 7-7 for Prec greater than or equal to the values in Table 7-7. b. PN code (if applicable) and carrier acquisition will occur within the time given in Table 7-7. The PN code and carrier acquisition may not commence until the Prec is greater than or equal to the value commensurate with the applicable minimum Program Track Prec under the applicable Program Track scenario. If autotrack is disabled, the time allowed for PN code and carrier acquisition will commence at the start of scheduled return service support period or when the minimum Prec is achieved, whichever occurs last. If autotrack is enabled, PN code and carrier acquisition may commence at any time after the start of scheduled return service support period, but the time allowed will not commence until the minimum Prec is achieved. If autotrack is enabled and required to achieve this minimum Prec, the total time allowed to achieve PN

Revision 9

7-22

450-SNUG

code and carrier acquisition will be the sum of the time allowed for autotrack acquisition and PN code and carrier acquisition. c. After PN code (if applicable) and carrier acquisition is achieved, TDRSS tracking services data is available. d. Symbol/Decoder and Symbol synchronization times will be measured from the time carrier acquisition is achieved to the time either symbol synchronization is achieved for uncoded channels or decoder synchronization is achieved for rate 1/2 coded channels. Decoder synchronization is achieved when the Viterbi decoder has selected and implemented the correct blocking of the input symbols (into groups of (G1, G2) symbol pairs) for rate 1/2 codes. e. After symbol/decoder and symbol synchronization is achieved, KuSA return service channel data is available at the SN ground terminal interface. f. To minimize return data loss, it is recommended that the customer platform transmit idle pattern on its data channels until after it has observed (via the UPD data) that the SN ground terminal has completed all of its data channel signal acquisition processes. g. Requirements for bit error probability and symbol slipping take effect at the time decoder synchronization is achieved for convolutional encoded data and at the time symbol synchronization is achieved for uncoded data. NOTE: Data and symbol transition density values higher than the minimums required will reduce these acquisition times.

Revision 9

7-23

450-SNUG

Table 7-7. TDRSS KuSA Return Service

Parameter (Note 4) Field of view (FOV) (each TDRS) Primary (PFOV) + 22 degrees east-west + 28 degrees north-south (rectangular) Description (Note 4) LEO (LEOFOV) +10.5 degree conical Extended Elliptical (EEFOV) (F8-F10) (note 10) 24.0 degrees inboard east-west 76.8 degrees outboard east-west +30.5 degrees north-south < + 3.2 sec

Revision 9

Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 1) TDRS antenna axial ratio (maximum)

< + 4.5 sec RHC or LHC selectable After Autotrack Acquisition (PFOV, LEOFOV, and EEFOV) (notes 10, 12) 1 dB over 3 dB beamwidth

< + 1.5 sec

LEO Program Track (LEOFOV) 1 dB over 3-dB beamwidth

Program Track (PFOV and EEFOV) 1.5 dB

7-24
Receive frequency (nominal) RF bandwidth (3dB, minimum) 10 Bit Error Rate (notes 2, 3, 4, 8, 12) Orbital Dynamics (free flight) Minimum Required Prec (dBW) for uncoded channels (note 9): DG1, modes 1 and 2 DG1, mode 3
-5

1600 13.775 GHz 0.7 MHz 1469

225 MHz All Prec values are in dBW; dr=data rate in bps

& && R 12 km/sec, R 15 m/sec 2 , jerk .02 m/sec 3

Autotrack (PFOV, LEOFOV, and EEFOV) (note 10) -240.0. + 10log10(dr) > -183.3 dBW (note 3) LEO Program Track (LEOFOV) -237.5 + 10log10(dr) > -180.8 dBW (note 3) Program Track (PFOV and EEFOV) -234.0 + 10log10(dr) > -177.3 dBW (note 3)

450-SNUG

I channel

Table 7-7. TDRSS KuSA Return Service (contd)

Parameter (Note 4) 10-5 Bit Error Rate (notes 2, 3, 4, 8, 12) (contd): Minimum Required Prec (dBW) for uncoded channels (contd) (note 9): DG1, mode 3 Q channel Data rate < 6 Mbps DG2 Data rate < 25 Mbps Data rate > 25 Mbps (F1-F7) (note 11) Data rate > 25 Mbps (F8-F10) Minimum Required Prec (dBW) for Rate 1/2 convolutional encoded channels (note 9): DG1, modes 1 and 2 DG1, mode 3 I channel Q channel Data rate < 3 Mbps -246.4 + 10log10(dr) -243.9 + 10log10(dr) -240.4 + 10log10(dr) > -183.3 dBW (note 3) > -180.8 dBW (note 3) > -177.3 dBW (note 3) > -183.3 dBW (note 3) > -180.8 dBW (note 3) > -177.3 dBW (note 3) -240.0 + 10log10(dr) -237.9 + 10log10(dr) -239.0 + 10log10(dr) -237.5 + 10log10(dr) -235.4 + 10log10(dr) -236.5 + 10log10(dr) -234.0 + 10log10(dr) -231.9 + 10log10(dr) -233.0 + 10log10(dr) -240.0 + 10log10(dr) -237.5 + 10log10(dr) -234.0 + 10log10(dr) Autotrack (PFOV, LEOFOV, and EEFOV) (note 10) Description (Note 4) LEO Program Track (LEOFOV) Program Track (PFOV and EEFOV)

Revision 9

7-25
450-SNUG

Table 7-7. TDRSS KuSA Return Service (contd)

Parameter (Note 4) 10-5 Bit Error Rate (notes 2, 3, 4, 8, 12) (contd): Minimum Required Prec (dBW) for Rate 1/2 convolutional encoded channels (note 9) (contd): DG2 Data rate < 10 Mbps Data rate > 10 Mbps Acquisition (notes 5, 8, 12): Orbital dynamics (free flight) Total Channel Acquisition Time (assumes the customer return service signal is present at the SN ground terminal at the start time of the return service support period) -246.4 + 10log10(dr) -245.2 + 10log10(dr) -243.9 + 10log10(dr) -242.7 + 10log10(dr) -240.4 + 10log10(dr) -239.2 + 10log10(dr) Autotrack (PFOV, LEOFOV, and EEFOV) (note 10) Description (Note 4) LEO Program Track (LEOFOV) Program Track (PFOV and EEFOV)

Revision 9

& && R 12 km/sec, R 15 m/sec 2 , jerk .02 m/sec 3

Sum of the following: 1. Autotrack acquisition time (when the TDRSS KuSA return service autotrack mode is enabled) 2. PN (DG1 only) and carrier acquisition time 3. Symbol/Decoder synchronization time (coded channel) or Symbol synchronization time (uncoded channel) PFOV >-183.3 dBW or consistent with the Prec for BER, whichever is greater LEOFOV >-186.8 dBW or consistent with the Prec for BER, whichever is greater EEFOV (note 10) >-183.3 dBW or consistent with the Prec for BER, whichever is greater

7-26
450-SNUG

Autotrack Acquisition (if applicable): Minimum Required Prec with probability > 99% (note 9)

Acquisition Time:

< 10 seconds

Table 7-7. TDRSS KuSA Return Service (contd)

Parameter (Note 4) Acquisition (notes 5, 8, 12) (contd): PN Code (if applicable) and Carrier Acquisition: Minimum Required Prec (note 9) Autotrack (PFOV, LEOFOV, and EEFOV) (note 10) > -183.3 dBW or consistent with the Prec for BER, whichever is greater Acquisition Time (Pacq > 90%) Coherent operations Noncoherent operations with frequency uncertainty (note 6): < + 5 kHz < + 20 kHz Channel Decoder/Symbol Synchronization Acquisition (coded data) (note 7): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) Acquisition time (in seconds) with >99% probability: NRZ < 6500/(Channel Data Rate in bps) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER < 1 sec < 3 sec < 1 sec LEO Program Track (LEOFOV) > -180.8 dBW or consistent with the Prec for BER, whichever is greater Program Track (PFOV and EEFOV) > -177.3 dBW or consistent with the Prec for BER, whichever is greater Description (Note 4)

Revision 9

7-27
450-SNUG

Table 7-7. TDRSS KuSA Return Service (contd)

Parameter (Note 4) Acquisition (notes 5, 8, 12) (contd): Channel Symbol Synchronization Acquisition (uncoded data) (note 7): Prec (dBW) Synchronization Acquisition time (in seconds) with >99% probability: NRZ Signal Tracking Orbital dynamics (free flight) Reacquisition Orbital dynamics (free flight) Duty Factor < 3000/(Channel Data Rate in bps) refer to paragraph 7.3.3.3 consistent with the Prec for BER Achieved when error rate for next 1000 bits is < 10
-5

Revision 9

Description (Note 4)

& && R 12 km/sec, R 15 m/sec 2 , jerk .02 m/sec 3

refer to paragraph 7.3.3.4

7-28
450-SNUG

& && R 12 km/sec, R 15 m/sec 2 , jerk .02 m/sec 3

100 percent

Notes: 1. Operational considerations may limit choice of TDRS antenna polarization. The KuSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 2. The BER is for a customer platform transmitting a signal on an AWGN channel which complies with the constraints defined in Table 7-9. Refer to Appendix G for a discussion of the additional degradation applicable to the TDRSS KuSA return service performance due to K-band RFI.

Table 7-7. TDRSS KuSA Return Service (contd)

Notes (contd): 3. The required customer Prec must meet the Prec for BER, autotrack acquisition, or signal acquisition, whichever is greatest. Paragraph 7.3.3.2.b provides the required Prec description for each possible KuSAR data configuration. Refer to Appendix A, paragraph A.4, for a definition of Prec. The minimum required Prec equations for BER produce the minimum Prec for a given data rate for all possible signal characteristics. CLASS analysis will produce a more accurate performance projection based upon desired customer signal characteristics, such as data rate, data type, and jitter values. SN support may be possible for customers whose Prec is less than the required Prec for 10-5 BER performance as long as the customer is willing to accept support on a best-effort basis and less than 100 percent coverage. Any customer interested in receiving this marginal SN coverage shall be required to negotiate all support with GSFC Code 450. In general, customer platforms should be designed to the most limiting TDRS to ensure SN support can be provided. 4. All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates. 5. For acquisition, the minimum Prec value listed applies to the total (I+Q)Prec. Acquisition requires the Prec to also be consistent with the Prec required for BER, whichever is greater. Failure to provide the minimum Prec for autotrack acquisition at the start of service may preclude successful TDRSS autotrack pull-in. 6. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 5 kHz. If a customer cannot accurately define their transmit frequency to within + 5 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 20 kHz after the start of service. 7. For symbol synchronization and symbol/decoder synchronization, the minimum symbol transition density and consecutive symbols without a transition must meet the specifications defined in Table 7-9. For encoded channels, it is recommended that customers use G2 inversion to increase symbol transition density. 8. All minimum Prec values include atmospheric and rain attenuation on the link from TDRS to the SN ground terminal; however, service outages may be experienced during periods of heavy rain. 9. The required Prec for autotrack performance is based upon a customer meeting the required ephemeris uncertainties for the Primary FOV, LEOFOV, or the Extended Elliptical FOV. The required Prec for program track performance is based upon a customer meeting the required ephemeris uncertainties for the Primary FOV or the Extended Elliptical FOV. The required Prec for LEO program track performance is based upon a customer meeting the required LEO ephemeris uncertainties for the LEO FOV. Customers may experience better performance through the KuSA program track and LEO program track services than listed in this document. Performance improvements particular to each customer should be discussed with GSFC Code 450. 10. KuSA return autotrack service for the Extended Elliptical FOV will be supported on a best-effort basis. 11. For KuSA DG2 uncoded service, the required Prec values for support through GRGT are only valid up to a total(I+Q) data rate of 150 Mbps. If higher data rates are required through GRGT, contact GSFC Code 450 for detailed calculations and use of dedicated service. 12. KuSAR performance characteristics are through the SN ground terminal receivers. An automated Ku-band IF service is being considered for implementation. Please refer to paragraph 7.3.6 and contact GSFC Code 450 for further information. Autotrack service is not available through the IF service.

Revision 9

7-29
450-SNUG

7.3.3.2 Bit Error Rate (BER) Table 7-7 provides Prec equations that will result in a customer achieving a BER of 10-5 for TDRSS compatible signals. The IF service BER depends on the customer receiver characteristics. Refer to paragraph 7.3.6 for more information on the IF service. The BER Prec equations are applicable for non-powered flight dynamics and the following conditions: a. Data encoding. Customer platform transmission of Rate 1/2 convolutional encoded or uncoded signals are supported for KuSA return services. Detailed rate 1/2 coding design is described in Appendix B. Reed-Solomon decoding is available to WDISC customers; typical performance is given in Appendix K. b. Received Power. Prec is in units of dBW. The customer project, in determining its design requirements for minimum customer platform EIRP, must take into account customer platform transmit antenna pointing losses, the space loss between the customer platform and the TDRS, and the polarization loss incurred between the customer platform transmit antenna and the TDRS receive antenna. The maximum TDRS receive antenna axial ratio is given in Table 7-7 (also refer to Appendix A). For DG1 and DG2 services, the following conditions apply: 1. Balanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2 only). For a customer platform synchronously transmitting identical data on the I and Q channels (single data source-identical data) with a balanced I and Q channel power division, the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 7-7, where dr is the single data source data rate. Refer to Appendix B for further information on this data configuration. 2. Balanced Power Single Data Source-Alternate I/Q Bits (DG2). For a customer platform transmitting alternate I and Q data bits from a data source (single data source-alternate I/Q bits), the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 7-7, where dr is the single data source data rate prior to separation into the I and Q channels. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 3. Balanced Power Single Data Source-Alternate I/Q Encoded Symbols (DG2 only). For a customer platform transmitting alternate I and Q encoded symbols from a data source (single data source-alternate I/Q encoded symbols), the total (I+Q) Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 7-7, where dr is the single data source data rate prior to the rate 1/2 encoder. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 4. Unbalanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2). For a customer platform synchronously transmitting identical data on the I and Q channels (single data

Revision 9

7-30

450-SNUG

source-identical data) having unbalanced I and Q channel power division, the stronger power channel Prec must be consistent with the Prec for a 10-5 BER listed in Table 7-7, where dr is the single data source data rate. The weak channel Prec need not be consistent with the Prec for a 10-5 BER listed in Table 7-7. The Q/I (power) must not exceed 4:1. Refer to Appendix B for further information on this data configuration. 5. Dual Data Sources (DG1 and DG2). For a customer platform transmitting independent data on the I and Q channels (dual data sources), each channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 7-7, where dr is that channels data rate. Refer to Appendix B for further information on this data configuration. 6. Single Data Source with Single Data Channel (DG1 modes 1 and 2 and DG2). For a customer platform transmitting one channel, the channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 7-7, where dr is the channel data rate. Refer to Appendix B for further information on this data configuration. c. Customer Degradations. Further reductions in the TDRSS KuSA return service performance identified in Table 7-7 can occur. The TDRSS KuSA return services and tracking services will be provided without degradation for customer platform transmitted signal characteristics within the constraints specified in Table 7-9. Customer platform parameters exceeding these constraints can also degrade TDRSS KuSA return service performance. Refer to Section 3, paragraph 3.5 for guidelines if the constraints in this paragraph cannot be met. Definitions of customer platform constraints are given in Appendix E. d. Multipath. The SN ground terminal will provide lockup and interference protection from multipath signals reflected from the Earth. 7.3.3.3 Signal Tracking TDRSS provides KuSA return signal tracking (carrier, PN, symbol synchronization, Viterbi decoder synchronization) for non-powered flight dynamics. During a customer KuSA return service support period, loss-of-lock (carrier, symbol synchronization, and Viterbi decoder) indications appear in the periodically updated User Performance Data (UPD) (every 5 seconds). The KuSA return service shall maintain signal tracking for the following conditions: a. Cycle Slips. The mean time-between-cycle slip in the SN ground terminal carrier tracking loop for each TDRSS KuSA return service will be 90 minutes minimum. This value applies at carrier tracking threshold, which is 3 dB less than the minimum Prec for BER listed in Table 7-7, and increases exponentially as a function of linear dB increases in Prec. Cycle slips may result in channel and/or data polarity reversal. The SN ground terminal can correct for these reversals under the same conditions as the SN ground terminal can resolve channel and/or data polarity ambiguity as discussed in Appendix B. The time for the SN ground terminal to recover from a cycle slip will be consistent with

Revision 9

7-31

450-SNUG

the time required for the SN ground terminal receiver to detect and automatically reacquire the signal. b. Bit Slippage. For each TDRSS KuSA return service operating with a minimum Prec required consistent with the Prec for BER of Table 7-7 and data transition densities greater than 40% for NRZ symbols, the minimum mean time between slips caused by a cycle slip in the SN ground terminal symbol clock recovery loop is either 90 minutes or 1010 symbol periods, whichever is greater. For a KuSA return service operating with 1 dB more than the minimum Prec required for the BER, and NRZ symbol transition densities between 25% and 40%, the minimum mean time between slips is either 90 minutes or 1010 symbol periods, whichever is greater. c. Loss of Symbol Synchronization. For each TDRSS KuSA return service with data transition densities greater than 40% for NRZ symbols, the SN ground terminal symbol synchronization loop will not unlock for a Prec that is 3 dB less than the minimum Prec required for BER in Table 7-7 (refer also to note 3 of Table 7-7). For NRZ symbol transition densities between 25% and 40%, the SN ground terminal symbol synchronizer loop will not unlock for a Prec that is 2 dB less than the minimum Prec required for BER. In both cases, the BER performance will be degraded when the Prec is less than the minimum required for BER. d. Loss of Autotrack. Loss of autotrack is detected by the SN ground terminal when either: 1. The autotrack SA antenna azimuth/elevation angles diverge from the program track SA antenna azimuth/elevation angles. The check on angle divergence protects the autotrack system from false tracking an interfering signal. When loss of autotrack is detected due to angle divergence, the SN ground terminal will automatically begin the reautotrack acquisition process. 2. There is a drop in received power that causes the receiver to drop carrier lock. The receiver will maintain carrier lock for a Prec that is 3 dB less than the minimum Prec for BER. (a) When loss of autotrack is detected due to signal fades during TDRS F1-F7 KuSAR support, the SN ground terminal will revert to return program track, transmit a forward link signal towards a customer platform using the high power program track EIRP values listed in Table 7-2 (if forward service is scheduled), and automatically begin the return autotrack reacquisition process. (b) For a maximum of 60 seconds after the first loss of autotrack is detected due to signal fades during TDRS F8-F10 KuSAR support, the TDRS SA antenna will continue to move at the calculated customer platform angular rate. If, within that 60 seconds, the KuSA return service Prec has increased back to or above the minimum level required by the TDRSS KuSA return PN code/carrier acquisition, the

Revision 9

7-32

450-SNUG

process should transfer almost immediately to its fine-track mode as the TDRS SA antenna boresight should still be pointed fairly close to the actual direction of the customer platform position. However, if after 60 seconds the KuSA return service Prec has not increased back to or above the minimum level required by the TDRSS KuSA return service PN code/carrier acquisition, the SN ground terminal reverts to open-loop pointing (program track) the TDRS SA antenna in the calculated direction of the customer platform position. When the SN ground terminal reverts to program track, the TDRSS will transmit a forward link signal towards a customer platform using the high power program track EIRP values listed in Table 7-2 (if forward service is scheduled). The TDRSS KuSA return service autotrack process will not restart until the KuSA return service Prec has increased back to or above the minimum level required by that process. 7.3.3.4 Reacquisition For return service autotrack reacquisition process, refer to paragraph 7.3.3.3.d. While in the PN/carrier tracking state, a loss of lock condition induced by a cycle slip will be automatically detected and a reacquisition will be automatically initiated. For a customer platform that continues to transmit the minimum Prec for acquisition and maintains an ephemeris uncertainty as defined in Table 7-7, the normal total channel reacquisition time for non-powered flight dynamics will be less than or equal to that for the initial total channel acquisition, with a probability of at least 0.99. If lock is not achieved within 10 seconds of loss of lock, an acquisition failure notification message will be sent to the MOC and the SN ground terminal will reinitiate the initial service acquisition process. Upon receipt of the loss-of-lock indications in the UPD, the customer MOC may request a TDRSS KuSA return service reacquisition GCMR (refer to section 10). It is recommended that the customer MOC delay initiation of the GCMR for at least 35 seconds after initial receipt of the loss-of-lock indications in the UPD. 7.3.3.5 Additional Service Restrictions a. Sun Interference. The TDRSS KuSA return service performance will not be guaranteed when the center of the sun is within 1 degree of the TDRS KuSA receiving antenna boresight. Additionally, the TDRSS KuSA return service performance will not be guaranteed when the center of the sun is within 1 degree of the boresight of the SN ground terminal receiving antenna supporting the TDRS. b. Mutual Interference. It is possible for mutual interference to exist between KuSA customer platforms operating with the same polarization. The SN can provide tools to assist customers in interference prediction and interference mitigation.

Revision 9

7-33

450-SNUG

7.3.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS KuSA return service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in section 10. Table 7-8 lists the KuSA return service real-time configuration changes and their effects on the return service. 7.3.5 Autotrack/Signal Acquisition Scenarios The following acquisition scenario identifies only the technical aspects of TDRSS KuSA return service autotrack (if enabled) and signal acquisition by the SN ground terminal and does not include operational procedures related to acquisition. Acquisition is dependent upon the customer providing an ephemeris with a maximum epoch uncertainty as defined in Table 7-7: a. TDRS SA Antenna Pointing: 1. KuSA Autotrack Description. The TDRSS KuSA return service autotrack process (if enabled) will acquire and track a customer platform KuSA return service signal providing an improved pointing of the TDRS SA antenna in the direction of the customer platform. This decreases the required Prec at the input to the TDRS antenna. TDRSS KuSA return autotrack service is independent of whether the return signal is coherent or noncoherent relative to a TDRSS KuSA forward service signal or whether a TDRS forward service signal is concurrently scheduled.

Revision 9

7-34

450-SNUG

Table 7-8. KuSA Return Service Real-Time Configuration Changes

Real-Time Configuration Changes Return Service Reacquisition Noncoherent Expanded Customer Spacecraft Frequency Uncertainty Channel Data Rate Noncoherent Transmit Frequency Redefinition of minimum customer EIRP Redefinition of maximum customer EIRP I/Q Power Ratio Channel Data Format Channel Data Bit Jitter DG1 Mode Polarization Data Group DG2 Coherency DG2 Carrier Modulation TDRSS Autotrack Mode Data Source/Channel Configuration G2 inversion Frame Length Frame Sync Word Length Frame Sync Word Bit Pattern Sync Strategy Parameters GCMR 98/03 98/07 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 OPM OPM 03 OPM 07 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 Return Service Interruption Yes No No Yes Yes No Yes No No Yes No Yes Yes Yes No Yes No No No No No

Note: 1. Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Additionally, any reconfigurations to the forward service that cause forward link interruption will also cause return interruption for coherent return links. Any other reconfigurations of the SN ground terminal may momentarily affect signal tracking.

Revision 9

7-35

450-SNUG

2.

3.

4.

5.

6.

Autotrack Power Requirement. For the TDRSS KuSA return service autotrack process to acquire a customer platform signal, the KuSA return service Prec must be consistent with either the Prec required for autotrack acquisition or the Prec required for BER, whichever is greater (refer to Table 7-7). Program track Operational Process. The SN ground terminal open-loop points the TDRS SA antenna in the calculated direction of the customer platform. The acquisition process begins with PN/carrier acquisition as described below for coherent or noncoherent operations as applicable. Autotrack Operational Process. The SN ground terminal initially open-loop points the TDRS SA antenna in the calculated direction of the customer platform. If the TDRSS KuSA return service autotrack process is initiated (or reinitiated), the SN ground terminal then processes error signals derived from the received customer platform KuSA return service signal to correct for small error build-ups in moving the TDRS antenna at the calculated angular rate of the customer platform. After the time when the signal is first present at the TDRS with adequate KuSA return service Prec [see paragraph 2 above], autotrack acquisition will be achieved within the autotrack acquisition time listed in Table 7-7. The acquisition process continues with PN/carrier acquisition as described below for coherent or noncoherent operations as applicable. TDRS Forward EIRP Level. If the TDRSS KuSA return service autotrack process is enabled, the forward service EIRP will default to the high power program track values listed in Table 7-2 during autotrack acquisition. Following the completion of return autotrack acquisition, the forward EIRP will be consistent with the autotrack normal or high power values listed in Table 7-2. If the return autotrack service experiences a reacquisition, the forward EIRP values may decrease to the high power program track values. If the TDRSS KuSA return service autotrack process is inhibited, the forward EIRP will be consistent with the normal power or high power program track values listed in Table 7-2, where either LEO program track or program track values depend upon customer platform orbital characteristics. Interference Mitigation to S-band Customers. An instantaneous Prec increase in the TDRSS KuSA return service channel being supported via the TDRS composite downlink Traveling Wave Tube Amplifier (TWTA) can potentially cause BER degradations to TDRSS SSA return services being concurrently supported via that same TDRS. For a customer platform KuSA return service signal that results in a Prec greater than -159.2 dBW, it is recommended that the customer MOC plan to use the following operational procedure to minimize return service performance degradations to other ongoing customer platform missions due to an instantaneous increase in Ku-band Prec level caused either by its customer platform signal being present at, or prior to, TR (the time the return service

Revision 9

7-36

450-SNUG

begins) or by its customer platform turning on its transmitting system at, or subsequent to, TR: (a) Prior to TR: The Prec (resulting from the customer platform KuSA return service signal level) must be less than -159.2 dBW. The instantaneous rate of change of Prec need not be less than or equal to 10 dB/sec. (b) At, or subsequent to TR: During the time period from TR to the time that the Prec (resulting from the customer platform KuSA return service signal level) reaches its scheduled initial value, the instantaneous rate of change of Prec from TR to that time should be less than or equal to 10 dB/sec (e.g., by initially causing the customer platform KuSA antenna to be off-pointed from the calculated direction of the TDRS at TR and then slewing it at an appropriate rate, starting at TR, to where it is pointing in the calculated direction of the TDRS). b. Coherent Signal Acquisition Scenarios (DG1 Modes 1 or 3 and DG2 Coherent): 1. For optimal TDRSS performance, all coherent services should have the TDRSS forward and return services starting at the same time. If operational considerations require starting the TDRSS forward service before the return service, no reconfigurations of the forward service can be sent within 30 seconds of the start of the return service. A forward link sweep request OPM cannot be sent within 150 seconds of the start of the return service. 2. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS KuSA return service signal parameters listed in Table 7-5. 3. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted range and Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for the SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by the SN ground terminal is either one-way return (Forward Doppler compensation enabled) or two-way (Forward Doppler compensation inhibited). For coherent operation, the Doppler correction is based upon the forward service frequency. 4. After the forward service has been acquired and the Prec is consistent with minimum Prec required for BER, the SN ground terminal will begin PN/carrier acquisition. PN/carrier acquisition may occur prior to completion of autotrack acquisition (if enabled). The SN ground terminal will acquire the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time limits listed in Table 7-7. Return service

Revision 9

7-37

450-SNUG

will be achieved at the SN ground terminal receiver output within the total channel acquisition time limits listed in Table 7-7, which includes SN ground terminal symbol and Viterbi decoder (if applicable) synchronization. c. Noncoherent (DG1 Mode 2 and DG2 Noncoherent): 1. This mode of customer platform operation does not require a TDRSS forward service signal to be received by the customer platform. However, the customer platform transmitter must be commanded to turn on when noncoherent transmissions are desired, either by stored commands, on-board configuration settings, or direct commands from its customer MOC. 2. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS KuSA return service signal parameters listed in Table 7-5. 3. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by the SN ground terminal is one-way return and based on the customer platform transmission frequency stated in the SHO and any subsequent OPMs. 4. The SN ground terminal will begin PN/carrier acquisition when the Prec meets the minimum required value for this acquisition process. PN/carrier acquisition may occur prior to completion of autotrack acquisition (if enabled). The SN ground terminal will complete acquisition of the customer platform signal (PN code (applicable to DG1 only) and carrier) within the time limits listed in Table 7-7. Return service will be achieved at the SN ground terminal receiver output within the total acquisition time limits listed in Table 7-7, which includes SN ground terminal symbol and Viterbi decoder synchronization. d. DG1 Mode Transitions: 1. DG1 Mode 2 to DG1 Mode 1 (or 3) Transitions. A TDRSS KuSA forward service must be scheduled to be established prior to customer MOC transmission of the GCMR to reconfigure the TDRSS for DG1 mode 1 (or 3) operations (refer to paragraph 7.3.5.b.(1)). 2. DG1 Mode 1 (or 3) to DG1 Mode 2 Transitions. When the customer platform switches to the noncoherent mode (DG1 mode 2), customer platform return service signal parameters (e.g., carrier and channel PN codes) are changed causing the SN ground terminal to drop TDRSS KuSA return service signal lock. Customer platform transponders designed to automatically switch from a coherent transponder mode to a noncoherent mode when the TDRSS KuSA forward service signal is lost

Revision 9

7-38

450-SNUG

will result in SN ground terminal loss of KuSA return service signal lock. Reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data. e. DG2 Mode Transitions: 1. DG2 noncoherent to DG2 coherent Transitions. A TDRSS KuSA forward service must be scheduled to be established prior to customer MOC transmission of the GCMR to reconfigure the TDRSS for DG2 coherent operations (refer to paragraph 7.3.5.b.(1)). 2. DG2 coherent to DG2 noncoherent Transitions. When the customer platform switches to the noncoherent mode, the resulting customer transmit frequency offset will probably cause the SN ground terminal to drop TDRSS KuSA return service signal lock when the switch is made. If return service signal lock is lost, reconfiguration and reacquisition by the SN ground terminal is required and must be initiated by a GCMR from the customer MOC. NOTE: Failure to observe these conventions may result in SN ground terminal rejection of reconfiguration messages, excessive acquisition times, and unnecessary loss of customer platform return service data.

Revision 9

7-39

450-SNUG

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints
Parameter (Notes 1 and 2) Minimum channel data bit transition density (required for acquisition/reacquisition) Consecutive channel data bits without a bit transition (required for acquisition/reacquisition) Minimum channel symbol (bit) transition density (Note 3) Consecutive channel symbols (data bits) without a symbol (data bit) transition (Note 3) Data asymmetry (peak) (Note 3) Symbol (data) bit jitter and jitter rate (Note 3) Phase imbalance DG1 modes 1 and 2 DG1 mode 3 DG2 Gain imbalance DG1 modes 1 and 2 DG1 mode 3 DG2 Phase nonlinearity (applies for all types of phase nonlinearities) (peak) DG1 modes 1 and 2 DG1 mode 3 DG2 Gain flatness (peak) DG1 modes 1 and 2 DG1 mode 3 DG2 Gain slope DG1 modes 1 and 2 DG1 mode 3 DG2 AM/PM DG1 modes 1 and 2 DG1 mode 3 DG2 < + 5 degrees < + 3 degrees < + 3 degrees < + 0.50 dB < + 0.25 dB < + 0.25 dB Description (Notes 1 and 2) > 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 >128 randomly distributed symbols (bit) transitions within any sequence of 512 symbols (bits) <64 symbols (data bits) < + 3 percent < 0.1 percent (see Appendix E)

< 4 degrees over +2.1 MHz < 3 degrees over +4.2 MHz < 3 degrees over +80 MHz <0.4 dB over +2.1 MHz <0.3 dB over +4.2 MHz <0.3 dB over +80 MHz Not Specified <0.1 dB/MHz over +4.2 MHz <0.1 dB/MHz over +80 MHz <15 deg/dB <12 deg/dB <12 deg/dB

Revision 9

7-40

450-SNUG

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Noncoherent frequency stability (peak) (Notes 4, 5, 11) +5 kHz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time +20 kHz customer oscillator frequency uncertainty 1-sec average time 5-hr observation time 48-hr observation time Incidental AM (peak) For open-loop pointing At frequencies >100 Hz For autotrack performance At frequencies: 10 Hz-10 kHz At frequencies: 10 Hz-2 kHz Spurious PM Minimum 3-dB bandwidth prior to power amplifier DG1 DG2 Phase noise (rms) (Note 7) DG1 Mode 1 Doppler Tracking Required (Note 10) All Baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz 3.0 rms 3.0 rms 1.4 rms >4.5 MHz or two times maximum baud rate, whichever is larger >2 times maximum channel baud rate <3 percent <0.6 percent (Note 6) <2 degrees <5 percent 3 x 10-9 4 x 10-7 1.2 x 10-6 <3 x 10-9 <1 x 10-7 <3 x 10-7 Description (Notes 1 and 2)

Revision 9

7-41

450-SNUG

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Phase noise (rms) (Note 7) (contd) DG1 Mode 1 (contd) Doppler Tracking NOT Required (Note 8) Channel baud rate < 16 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 16 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz DG1 Mode 2 Doppler Tracking Required (Notes 10, 11) Channel baud rate < 16 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 16 ksps 1 Hz 10 Hz 10 Hz 1 kHz 100 Hz 1 kHz 1 kHz 150 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 16 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 16 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz 25.0 rms 4.0 rms 2.0 rms 2.0 rms 4.0 rms 3.0 rms 1.8 rms 1.4 rms 15.0 rms 4.0 rms 2.0 rms 2.0 rms 4.0 rms 3.0 rms 1.8 rms 1.4 rms 25.0 rms 3.0 rms 2.0 rms 4.0 rms 3.0 rms 1.4 rms Description (Notes 1 and 2)

Revision 9

7-42

450-SNUG

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Phase noise (rms) (Note 7) (contd) DG1 Mode 3 Doppler Tracking Required (Note 10) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 16 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 16 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz DG2 Coherent Doppler Tracking Required (Note 10) All baud rates 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 434 ksps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz 434 ksps < Channel baud rate < 6 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 6 Msps 1 Hz 10 Hz 10 Hz 1 kHz 1 kHz 150 MHz 3.0 rms 1.8 rms 1.0 rms Description (Notes 1 and 2)

3.0 rms 2.6 rms 1.2 rms

3.5 rms 2.6 rms 1.2 rms 25.0 rms 3.0 rms 2.0 rms

3.6 rms 1.8 rms 1.0 rms 50.0 rms 6.0 rms 2.4 rms 50.0 rms 5.5 rms 1.1 rms

Revision 9

7-43

450-SNU

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) Phase noise (rms) (Note 7) (contd) DG2 Noncoherent Doppler Tracking Required (Notes 10, 11) Channel baud rate < 108.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 108.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Doppler Tracking NOT Required (Note 8) Channel baud rate < 108.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz 108.5 ksps < Channel baud rate < 6 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 6 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz In-band spurious outputs, where in-band is twice the maximum channel baud rate DG1 modes 1 and 2 DG1 mode 3 DG2 Out-of-band emissions Description (Notes 1 and 2)

4.0 rms 2.5 rms 1.4 rms 1.4 rms 15.0 rms 5.5 rms 2.0 rms 2.0 rms

4.0 rms 2.5 rms 1.4 rms 1.4 rms

50.0 rms 5.5 rms 2.4 rms 2.4 rms 50.0 rms 10.0 rms 2.0 rms 2.0 rms

> 23 dBc > 30 dBc > 30 dBc See Appendix D for allowable limits on out-of-band emissions, including spurs

Revision 9

7-44

450-SNU

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1 and 2) I/Q data skew (relative to requirements for I/Q data synchronization where appropriate) (peak) (Note 3) I/Q PN chip skew (relative to 0.5 chip) PN chip rate (peak) DG1 mode 2 (relative to absolute coherence with carrier rate) PN power suppression (noncoherent and coherent) Axial ratio for autotrack Data rate tolerance I/Q power ratio tolerance Permissible Prec variation (without reconfiguration GCMR from customer MOC) (Note 9) Permissible rate of Prec Variation Maximum Prec Description (Notes 1 and 2) <3 percent <0.01 chip <0.01 chips/sec at PN code chip rate <0.3 dB <3 dB <+0.1 percent <+0.4 dB <12 dB <10 dB/sec -149.2 dBW

Notes: 1. The definitions and descriptions of the customer constraints are provided in Appendix E. 2. When a constraint value is listed for a baud rate range and data is transmitted on both channels, the maximum baud rate of the 2 channels should be used to determine the constraint value applicable. 3. When the data is Rate 1/2 convolutionally encoded, these data bit parameters should be interpreted as symbol parameters. For encoded channels, it is recommended that customers use G2 inversion to increase symbol transition density. Additionally, bi-phase symbol formatting increases symbol transition density. CCSDS randomization is recommended to aid in compliance with the data randomness requirements. 4. The frequency stability requirements are valid at any constant temperature (0.5 C) in the range expected during the mission. At a minimum, a temperature range of -10 C to +55 C shall be considered. 5. Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of 5 kHz. If a customer cannot accurately define their transmit frequency to within 5 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to 20 kHz after the start of service. 6. The TDRSS design implementation may not provide the stated TDRSS KuSA return service autotrack performance when Prec = Prec (minimum) and the Incidental AM (peak), at frequencies 2 kHz, is close to or at 0.6 percent. For TDRSS KuSA return service autotrack performance, either Prec must be increased above Prec (minimum), or the Incidental AM (peak), at frequencies 2 kHz, must be more tightly controlled. 7. Derivation of the phase noise requirements involved making assumptions about the distribution of the phase noise power in each frequency region. Since no phase noise PSD will exactly match the phase noise power distribution assumed for this derivation, phase noise PSDs which are close to violating the phase noise limits or phase noise PSDs which do violate the phase noise limits should be evaluated on a case-by-case basis to determine their acceptability.

Revision 9

7-45

450-SNUG

Table 7-9. TDRSS KuSA Return Service Customer Platform Signal Constraints (contd)
Notes (contd): 8. Applicable for customers that have no Doppler tracking requirement or can tolerate a total Doppler tracking error (system + customer) greater than 0.2 rad/sec (1) assuming an averaging time of 1 second. 9. The minimum SHO EIRP should reflect the minimum Prec expected over the service period, where the Prec can exceed this minimum by no more than 12 dB. An actual customer Prec value that is 12 dB greater than the minimum may cause false PN lock or nonacquisition. 10. Will yield a total Doppler tracking error (system + customer) of ~0.2 rad/sec (1) assuming an averaging time of 1 second. 11. If one-way Doppler tracking is required for orbit determination during customer launch and early orbit, contact NASA/GSFC Flight Dynamics (Code 595) for additional information and guidance about oscillator uncertainty.

7.3.6 225 MHz IF Service This section specifies characteristics and recommendations for the KuSAR IF service, which is currently being considered for automation. SN IF services are available to customers on a case-by-case basis. The IF service is supported through TDRS F1-F7 and TDRS F8-F10 via the SN ground terminal infrastructure, where the customer provides the receiver equipment and the SN only provides the signal at the IF with the characteristics described in this section. Paragraph 7.3.6.1 describes the aggregate channel characteristics of the TDRS spacecraft and SN ground segment for understanding the IF interface. The performance of the customer link greatly depends on the customer signal characteristics and the receiver used. Paragraph 7.3.6.2 describes potential signal characteristics and expected performance through the TDRS spacecraft and SN ground segment. The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with Code 450 to achieve desired performance. NOTE: Autotracking is not provided for the IF service. Changes to the operating conditions or configuration of a TDRSS KuSAR IF service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in Section 10. Table 7-10 lists the KuSA IF return service real-time configuration changes and their effects on the return service.

Revision 9

7-46

450-SNUG

Table 7-10. KuSA Return IF Service Real-Time Configuration Changes

Real-Time Configuration Changes Polarization GCMR 98/04 OPM OPM 03 Return Service Interruption Yes

Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Any other reconfigurations of the SN ground terminal may momentarily affect signal tracking.

7.3.6.1 Channel Characteristics As discussed above, this is not an end-to-end service so a set of customer platform signal constraints is not available due to the dependencies on the exact customer signal characteristics as well as receiver capabilities. The IF service provides a KuSAR signal through the TDRS spacecraft and SN ground segment, including IF output channel characteristics as specified in Table 7-11. This will allow customers to be able to understand the signal distortions that are outside of their control. For additional characteristics applicable to the KuSAR IF service, refer to Table 7-7. 7.3.6.2 Potential Signal Parameters for IF Service As discussed earlier, this is not an end-to-end service so a set of well defined customer signal parameters is not available. This section describes potential signal characteristics and expected performance through the TDRS spacecraft and SN ground segment. The KuSA return IF service is not currently automated; however, automation of this service is being considered for implementation. SN IF services are available to customers on a case-by-case basis. Customers should contact Code 450 if they are interested in this service to determine expected performance for their specific signal characteristics and receiver. Potential TDRS KuSA return service signal configurations are provided in Table 7-12.

Revision 9

7-47

450-SNUG

Table 7-11. TDRS KuSAR IF Service Spacecraft and Ground Segment Channel Characteristics
Parameter TDRS Ku-band Receive Center Frequencies (note 1) 3-dB RF bandwidth (note 3) Gain Flatness (peak) (note 2) Gain Slope (note 2) Phase nonlinearity (applies for all
types of phase nonlinearities) (peak) (note 2)

Description 15.0034 GHz 240 MHz 0.8 dB over 80 MHz 0.14 dB/MHz over 80 MHz 16.5 over 80 MHz > 0.57 dB/dB 7/dB 2.24 rms

AM/AM (note 2) AM/PM (note 2) Spurious PM (note 2) In-band spurious outputs (note 2)
Total Individual

27 dBc 40 dBc 1% (within 3-dB RF bandwidth) 3.8 rms 3.6 rms 4.3 rms 2.7 rms NA

Incidental AM (peak) (note 2) Phase noise (note 2) 1 Hz to 10 Hz 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 150 MHz 1 kHz to 400 MHz Additional TDRS Ground Segment IF Characteristics: IF center frequency Output level Output VSWR

370 MHz -15 dBm 3 dB 1.3:1 into 50 load, 80 MHz from center frequency

Revision 9

7-48

450-SNUG

Table 7-11. TDRS KuSAR IF Service Spacecraft and Ground Segment Channel Characteristics (contd)
Notes: 1. The customer should schedule the TDRS receive center frequency to the KuSAR TDRS receive center frequency, where the TDRS receive center frequency will be translated to the center of the IF bandwidth. The signal and carrier frequency will be constrained such that the first null of the spectrum falls between 14.8834 and 15.1234 GHz. The KuSAR IF service only supports noncoherent frequencies. The KuSAR IF service supports only one Ku frequency through one TDRS at a time. These frequencies do not include the effects of Doppler shift. The KuSAR IF service is not required to provide a Doppler-corrected IF output signal. The customer provided receiver needs to handle Doppler. 2. Constraint parameters are contributions from the TDRS spacecraft and the SN ground segment to the IF interface. Not included in these aggregate distortion amounts are TDRS spacecraft gain flatness, linear and parabolic allowances, and phase nonlinearity parabolic and cubic allowances as described in 405-TDRS-RP-SY-001, WU-02-01, and SY1-89E. Customer and receiver signal characteristics need to be considered to determine the end-to-end performance. Please contact GSFC Code 450 for further information. 3. The 3 dB RF bandwidth is larger than the specified 225 MHz bandwidth value specified in Table 7-7. This value has validated through spacecraft and ground terminal measurements, but may not be applicable to future TDRS.

Table 7-12. Potential TDRSS KuSA IF Return Service Configurations (Customer interfaces with the SN at a 370 MHz IF and Customer provides the Receiver)
Return IF Service Configuration (notes 1, 2) BPSK Rate 1/2 convolutional coded Uncoded Rate 1/2 convolutional coded QPSK / SQPSK Uncoded (128,120)x(128,120) TPC (8176,7136) LDPCC (1024,2048) LDPCC (128,120)x(128,120) TPC 8PSK (8176,7136) LDPCC Uncoded Notes: 1. All data rates assume NRZ data format. 2. These service configurations and maximum data rates were based upon simulation results only and have not been verified by testing. Other data rates and modulation schemes may be possible. Please contact GSFC Code 450 for further information. 3. For the IF service, data rates up to 410 Mbps may be possible for QPSK/SQPSK modulation with either TPC or (8176,7136) LDPCC. For the 225 MHz IF service, data rates up to 625 Mbps may be possible for 8PSK with either TPC or (8176,7136) LDPCC. Please contact GSFC Code 450 for further information. Potential Maximum Data Rates (IF Service) See Table 7-6 See Table 7-6 See Table 7-6 See Table 7-6 400 Mbps 400 Mbps 200 Mbps 600 Mbps 600 Mbps 450 Mbps

Revision 9

7-49

450-SNUG

7.3.6.3 Potential Signal Performance for IF Service The performance of the IF link is greatly dependent on the customer provided receiver. Typically, the SNUG specifies performance at BER of 10-5; BERs better than 10-5 may be possible for the IF service. NOTE: The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with GSFC Code 450 to achieve desired BER. All values in this section assume using a receiver with reasonable implementation loss. Table 7-13 provides expected, required Eb/No values for various data rates and modulation schemes for a 10-5 BER. Additionally, Table 7-13 also provides the theoretical Eb/No and implementation loss values for those modulation and coding schemes at 10-5 BER over a simple AWGN channel. Table 7-13 also provides a potential minimum required Prec (dBW) equation for various data rates, coding and modulation schemes through the IF service assuming these expected required Eb/No values, which were based upon simulation results and have not been verified by testing. NOTE: Autotracking is not provided for the IF service.

Revision 9

7-50

450-SNUG

Table 7-13. Potential KuSAR IF Service Implementation Loss Amounts and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques Return IF Service Configuration (notes 2, 3) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 2)
7.9 dB 6.6 dB 6.1 dB 8.4 dB 7.3 dB 6.4 dB 4.0 dB 3.6 dB 1.7 dB 4.4 dB 3.9 dB

Revision 9

Theoretical Required Eb/No (note 1)

Implementation Required Prec (K) at Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 2) BER (LEO Program Track) (note 2)
4.0 dB 2.7 dB 2.2 dB 4.0 dB 2.9 dB 2.0 dB 2.3 dB 1.9 dB -241.5 + 10 log (dr) -243.5 + 10 log (dr) -244.3 + 10 log (dr) -240.7 + 10 log (dr) -242.6 + 10 log (dr) -244.0 + 10 log (dr) -246.6 + 10 log (dr) -247.1 + 10 log (dr)

QPSK/ SQPSK (note 5)

(128,120)x(128,120) TPC (note 4)

400 Mbps 300 Mbps < 200 Mbps

(8176,7136) LDPCC (note 4)

400 Mbps 300 Mbps < 200 Mbps

(1024,2048) LDPCC

200 Mbps < 150 Mbps

7-51
450-SNUG

Table 7-13. Potential KuSAR IF Service Implementation Loss Amounts and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques (contd) Return IF Service Configuration (notes 2, 3) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 2)
10.5 dB 9.4 dB 8.8 dB 11.5 dB 10 dB 9.5 dB 17.3 dB Notes: 1. Unless otherwise noted, all values are based upon a customer transmitter power amplifier operating point of 1 dB OBO, i.e., AM/PM = 12/dB and AM/AM = 0.47 dB/dB. Values assume baseband equalization used. Values do not include margin. All values are given for a receiver with reasonable loss. Better performance may be achievable with better power amplifier and/or filters, etc. 2. These service configurations and maximum data rates were based upon simulation results only and have not been verified by testing. Other data rates and modulation schemes may be possible. Please contact GSFC Code 450 for further information. 3. For BPSK, QPSK, SQPSK with uncoded or rate convolutional coded through the 225 MHz bandwidth, see Table 7-7 for expected performance. 4. For the 225 MHz IF service, data rates up to 410 Mbps may be possible for QPSK/SQPSK modulation with either TPC or (8176,7136) LDPCC. For the 225 MHz IF service, data rates up to 625 Mbps may be possible for 8PSK with either TPC or (8176,7136) LDPCC. Please contact GSFC Code 450 for further information. 5. For the QPSK/SQPSK configurations, the required Prec was determined for support through KuSAR composite downlink to the GRGT IF interface point. For the 8PSK configurations, the required Prec was determined for support through the KuSAR composite downlink to the WSC IF interface point, except for the 8PSK uncoded service, which assumes a dedicated downlink to the WSC IF interface point. 13.1 dB 7.3 dB 6.9 dB

Revision 9

Theoretical Required Eb/No (note 1)

Implementation Required Prec (K) at Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 2) BER (LEO Program Track) (note 2)
3.6 dB 2.5 dB 1.9 dB 4.2 dB 2.7 dB 2.2 dB 4.2 dB -238.4 + 10 log (dr -240.3 + 10 log (dr) -241.3 + 10 log (dr) -236.7 + 10 log (dr) -239.5 + 10 log (dr) -240.5 + 10 log (dr) -231.1 + 10 log (dr)

8PSK (note 5)

(128,120)x(128,120) TPC (note 4)

600 Mbps 500 Mbps < 400 Mbps

(8176,7136) LDPCC (note 4)

600 Mbps 500 Mbps < 400 Mbps

Uncoded

< 450 Mbps

7-52
450-SNUG

Section 8. KaSA Telecommunications Services

8.1 General

8.1.1 Available Services TDRSS KaSA services include forward and return telecommunications services. KaSA Return service includes 225 MHz service through the SN receive equipment and IF service for the KaSA 225 MHz and KaSA 650 MHz channels, where the 225 MHz IF is not automated, but is being considered for automation and the 650 MHz service has been automated. Additionally, SN IF services are available to customers on a case-bycase basis, IF service requires the customer to provide the receiver equipment and the SN only provides the signal at the IF. Tracking services are not provided via KaSA. This section focuses on the RF interface between the TDRS and the customer platform. This interface is characterized by the technical requirements imposed and the operational capabilities provided by the TDRSS. The operational interfaces are described in further detail in Section 10. Data interfaces between the customer MOC and the SN are described in Section 3, paragraph 3.6. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessible via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. GSFC Code 450 uses the NAMs as a means of letting customers know of any performance constraints associated with TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452-PLAN-0002. 8.1.2 Interface Definition The RF interface between the TDRS and a customer platform is defined in terms of signal parameters, RF characteristics, and field of view. a. The RF interface for forward service represents the transmission by a TDRS of an appropriately modulated signal at or greater than a minimum specified signal EIRP in the direction of the desired customer platform. KaSA forward (KaSAF) service is discussed in paragraph 8.2. b. The RF interface for return service defines a minimum received power (Prec) at the TDRS antenna input for a specified data quality at the SN ground terminal receiver output. KaSA return (KaSAR) service is discussed in paragraph 8.3.

Revision 9

8-1

450-SNUG

NOTE: The KaSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. 8.1.3 Customer Acquisition Requirements Acquisition and reacquisition by the customer platform of the TDRS transmitted signal requires prediction by the customer MOC of the customer platform receive frequency over various projected time periods. Similarly, acquisition and reacquisition by the SN ground terminal of the customer platform signal requires prediction by the customer MOC of the customer platform transmitter frequency over various projected time periods. The frequency predictions are ultimately incorporated into the Schedule Order (SHO) as customer platform frequencies for the specific service support periods. 8.1.4 TDRSS Acquisition Support to Customers For each scheduled TDRSS service support period, the customer requirements for signal acquisition/reacquisition, and the TDRSS capabilities to aid acquisition/reacquisition, are as follows: a. Customer Epoch Uncertainty 1. Autotrack. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be +2.0 seconds for customer platform operations requiring the TDRSS KaSA return service autotrack process within the TDRSS Primary FOV and Extended Elliptical FOV. Similarly, the maximum epoch time uncertainty of the customer platform ephemeris shall be 1.5 seconds for the KaSA return service autotrack process within the TDRSS LEOFOV. NOTE: KaSA return autotrack service for the Extended Elliptical FOV will be supported on a best effort basis. Autotrack service is not available through the Ka-band 225 MHz and 650 MHz bandwidth IF service. Program track. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be +2.0 seconds for customer platform operations using TDRSS KaSA open-loop pointing within the TDRSS Primary FOV. 3. LEO Program track. The maximum epoch time uncertainty of the applicable customer platform ephemeris supplied to the TDRSS shall be +1.5 seconds for customer platform operations requiring the TDRSS KaSA open-loop pointing for customers within the TDRSS LEOFOV. b. Customer Frequency Uncertainty. The customer MOC must know the operating frequency of the customer platform to within +6 kHz. 2.

Revision 9

8-2

450-SNUG

c.

Frequency Sweep on the Forward Link. After the start of the forward link service, the TDRSS has a forward service frequency sweep capability of +30 kHz. d. Noncoherent Return Expanded Frequency Search. After the start of the return link service, the TDRSS has a return service expanded frequency search capability of +21 kHz. 8.2 KaSA Forward Services

8.2.1 General The characteristics of the data provided to the SN ground terminal interface and the RF signals provided by the TDRS to the customer platform during TDRSS KaSA forward services are described in paragraphs 8.2.2 through 8.2.5. This discussion assumes that an appropriate forward service has been scheduled and a data signal is present at the SN ground terminal interface. 8.2.2 Signal Parameters The TDRSS KaSA forward service signal parameters are defined in Table 8-1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code for TDRSS KaSA forward service (refer to Section 10, paragraph 10.2.2). A description of the features inherent in the QPSK and BPSK signal parameters listed in Table 8-1 are discussed in paragraphs 8.2.2.1 and 8.2.2.2, respectively. 8.2.2.1 QPSK Signal Parameters a. Unbalanced QPSK Modulation. The I channel is used to transmit the customer command data and is referred to as the command channel. The Q channel transmits a range signal and is referred to as the range channel. The command channel/range channel power ratio for QPSK forward service signals is +10 dB. This unbalanced QPSK modulation minimizes the power in the range channel to a level adequate for customer platform range channel acquisition and tracking. This feature increases the power in the command channel by 2.6 dB over that for balanced QPSK modulation without increasing customer platform receiver complexity, increasing customer platform command channel acquisition time, or decreasing TDRSS range tracking accuracy. NOTE: Tracking services are not provided via KaSA. b. Spread Spectrum. All TDRSS KaSA forward services with data rates <300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed upon TDRSS forward services by the NTIA.

Revision 9

8-3

450-SNUG

Table 8-1. TDRSS KaSA Forward Service Signal Parameters

Parameter TDRS transmit carrier frequency (Hz) Carrier frequency arriving at customer platform (note 1) Carrier frequency sweep (note 4) Carrier frequency sweep duration (note 4) QPSK (PN modulation enabled)
Command channel radiated power Range channel radiated power

Description F FR +30 kHz 120 seconds +10 dB

QPSK Command Channel Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) (note 5) Transmit carrier frequency (F) PSK, + /2 radians 30 dB minimum 2 -1 Refer to 451-PN CODE-SNIP Gold codes
10

31 1469 96

F 9 - 8.78 - 0.005 K) 10 10 9

Data modulation Data format (note 2) Data rate restrictions (note 2) QPSK Range Channel Carrier PN code modulation Carrier suppression PN code chip rate PN code length (chips) PN code epoch reference PN code family

Modulo-2 added asynchronously to PN code Not applicable 1 kbps - 300 kbps Command channel carrier frequency delayed /2 radians PSK, + /2 radians 30 dB minimum Synchronized to command channel PN code chip rate (2 - 1) x 256 All 1's condition synchronized to the command channel PN code epoch. Truncated 18-stage shift register sequences
10

Revision 9

8-4

450-SNUG

Table 8-1. TDRSS KaSA Forward Service Signal Parameters (contd)

Parameter Description

BPSK (PN modulation enabled) (note 6) Carrier frequency (Hz) PN code modulation Carrier suppression PN code length (chips) PN code epoch reference PN code family PN code chip rate (chips/sec) (note 5) Transmit carrier frequency (F) PSK, + /2 radians 30 dB minimum 2 -1 Refer to 451-PN CODE-SNIP Gold codes 31 1469 96 Data modulation Data format (note 2) Data rate restrictions (note 2) BPSK (PN modulation disabled) Carrier frequency (Hz) Data modulation Carrier suppression Data format (note 2) Data rate restrictions (notes 2, 3) Transmit carrier frequency (F) PSK, +/2 radians 30 dB minimum Not Applicable 300 kbps - 25 Mbps ( F 9 - 8.78 - 0.005 K) 10 10 9
10

Modulo-2 added asynchronously to PN code Not applicable 1 kbps - 300 kbps

Notes: 1. The center frequency, fo, of the customer platform receiver must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz. Doppler compensation will & be available for R <7.9 km/sec. During periods of Doppler compensation, FR = fo + E Hz, where fo = nominal center frequency of customer platform receiver as defined by the customer MOC && && and E = e x fo x R /c + C; e < +2.0 sec is the customer epoch uncertainty, R <11.4 m/sec2, c is the free space speed of light in m/sec, and C = 1900 Hz. If Doppler compensation is inhibited after the start of the forward service, the customer receive frequency will be fixed at the frequency of the Doppler compensation profile at the time of inhibition.

Forward service Doppler compensation will not increase the effective frequency rate of change seen at the customer receiver more than 560 Hz/sec relative to the frequency for a Doppler free carrier.

Revision 9

8-5

450-SNUG

Table 8-1. TDRSS KaSA Forward Service Signal Parameters (contd)

Notes(contd): The forward data rate in this table is the baud rate that will be transmitted by the TDRSS (includes all coding and symbol formatting). For non-WDISC customers, forward data conditioning is transparent to the SN. For all customers, forward convolutional coding is transparent to the SN. These transparent operations should be performed by the customer prior to transmission to the SN data interface. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. Currently, the SN ground terminal data interface supports up to 7 Mbps; however, upgrades to support up to 25 Mbps are planned. The SN is capable of supporting BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. After the start of the KaSA forward service, if a customer MOC is unable to accurately define fo (the nominal center frequency of the customer platform receiver), the forward service carrier frequency can be swept. The KaSA forward service frequency sweep will be initiated by the SN ground terminal at fo-30 kHz and linearly swept to fo+30 kHz in 120 seconds and held at fo+30 kHz thereafter. The KaSA forward service frequency sweep does not impact simultaneous SN ground terminal Doppler compensation of the KaSA forward service carrier and PN code rate (if applicable). fo 22555 6 Rounded to the nearest integer if K integer and 0 < K < 198. K = 10 5 fo is the nominal center frequency in Hz of the customer platform receiver as defined by the customer MOC. Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required.

2.

3. 4.

5.

6.

This modulation scheme includes separate but simultaneous command and range channels. The command channel includes a rapidly acquirable PN code and contains the forward service data. The range channel is acquired separately and contains a PN code which satisfies the range ambiguity resolution requirements. The length of the command channel PN code is 210-1, where the length of the range channel PN code is 256 times the command channel PN code length. The customer platform command channel acquisition can precede customer platform range channel acquisition; this feature permits rapid acquisition of the range channel by limiting the range channel PN code search to only 256 chip positions while the range channel PN code itself contains 261,888 chips. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward range and command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments.
Revision 9 8-6 450-SNUG

c.

Asynchronous Data Modulation. For data rates < 300 kbps, the forward service data received at the SN ground terminal from the NISN data transport system is directly modulo-2 added by the SN ground terminal to the command channel PN code sequence. The forward service data will be asynchronous with the carrier and the PN code. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is the command channel PN code sequence.

d.

Functional Configurations. A further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B, paragraph B.2.2. e. Doppler Compensation. The TDRSS KaSA forward service carrier frequency (F) and the PN chip rate transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 8-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS KaSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed-frequency KaSA forward service carrier and PN code chip rate.

8.2.2.2 BPSK Signal Parameters: a. BPSK Modulation (PN Modulation Enabled). The I channel is used to transmit the customer command data and is referred to as the command channel. TDRSS KaSA forward services with data rates equal to and below 300 kbps should incorporate spread spectrum modulation techniques to satisfy flux density restrictions imposed on the TDRSS forward services by the NTIA. The command channel includes a rapidly acquirable PN code and contains the forward service data. The PN code chip rate is coherently related to the TDRS transmit frequency in all cases. This feature permits the customer platform receiver to use the receiver PN code clock to predict the received carrier frequency, thereby minimizing receiver complexity and reducing acquisition time. 451-PN CODE-SNIP defines all the salient characteristics for the forward command channel PN code libraries. The agency Spectrum Manager responsible for PN code assignments will allocate a customer platform-unique PN code assignment from these libraries. The GSFC Spectrum Manager is responsible for NASA PN code assignments.

Revision 9

8-7

450-SNUG

NOTE: Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required. b. BPSK Modulation (PN Modulation Disabled). For data rates greater than 300 kbps, there is no PN code modulation and the customer data directly BPSK modulates the carrier by +/2 radians. NOTE: The SN is capable of supporting non-spread BPSK signals at data rates less than 300 kbps; however, its use will be controlled and must be coordinated with GSFC Code 450. c. Asynchronous Data Modulation. asynchronous with the carrier. NOTE: When the command channel does not contain any actual forward service data, the forward service command channel signal is carrier only. d. Functional Configurations. A further description of the functional configurations and data polarity ambiguity is found in Appendix B, paragraph B.2.2. e. Doppler Compensation. The TDRSS KaSA forward service carrier frequency (F) transmitted by a TDRS can optionally be compensated by the SN ground terminal for Doppler. When compensated, the carrier, FR, arrives at the customer platform receiving system within a predictable tolerance (E) of fo as defined in Table 8-1. This feature minimizes the Doppler resolution requirements of the customer platform receiver and is available continuously to facilitate reacquisition by the customer platform in the event of loss of lock of the TDRSS KaSA forward service signal. Customers are encouraged to utilize Doppler compensation at all times. Doppler compensation may be inhibited and the TDRSS will transmit a fixed-frequency KaSA forward service carrier. The forward service data will be

8.2.3 Communications Services The TDRSS KaSA forward services available are listed in Table 8-2. Table 8-3 lists their salient characteristics. The definitions for the parameters listed in Table 8-3 are contained in Appendix E.

Revision 9

8-8

450-SNUG

Table 8-2. TDRSS KaSA Forward Service

Parameter Description

Field of view (FOV) (each TDRS) (note 5)

Primary (PFOV) +22 degrees east-west +28 degrees north-south (rectangular)

LEO (LEOFOV) +10.5 degree conical

Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 1)

< + 2.0 sec RHC or LHC selectable Autotrack (PFOV and LEOFOV) (note 3)

< + 1.5 sec

LEO Program Track (LEOFOV) 1.6 dB

Program Track (PFOV)

TDRS antenna axial ratio (maximum)

1.5 dB over 3-dB beamwidth +63.0 dBW

1.7 dB

TDRS signal EIRP (minimum) (note 4) Transmit center frequency (nominal) (note 2) RF bandwidth (3dB, minimum) Duty factor 1. 2.

+59.5 dBW

+56.2 dBW

22.555 to 23.545 GHz +1.28 MHz in 5 MHz steps 50 MHz 100 percent (normal and high power)

3.

4.

5.

Notes: Operational considerations may limit choice of TDRS antenna polarization. The KaSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. The customer MOC must include the best estimate of the customer platform receiver center frequency at the time of startup of each scheduled service support period in its service specification code (refer to Section 10, paragraph 10.2.2). The TDRSS KaSA forward service carrier frequency is then implemented by the SN ground terminal to the accuracy of the SN ground terminal frequency standard except during Doppler compensation. The SNIP and the SFCG recommend that only the following six center frequencies be used for KaSA forward service: 23.205 GHz, 23.265 GHz, 23.325 GHz, 23.385 GHz, 23.445 GHz, 23.505 GHz. The data rate and carrier frequency will be constrained such that the first null of the spectrum falls between 22.55 and 23.55 GHz. EIRP values are for a TDRSS forward service with a TDRSS return autotrack service acquired. Return service autotrack acquisition will be achieved within 10 seconds of KaSA return service Prec consistent with the BER or autotrack acquisition, whichever is larger. Autotrack service is not available through the Ka-band return 225 MHz and 650 MHz bandwidth IF service. The autotrack EIRP will be transmitted towards a customer that meets the required ephemeris uncertainties for the Primary FOV or LEOFOV. The program track EIRP will be transmitted towards a customer that meets the required ephemeris uncertainties for the Primary FOV. The LEO program track EIRP will be transmitted towards a customer that meets the required LEO ephemeris uncertainties for the LEO FOV. Customers may experience better performance through the KaSA program track and LEO program track services than listed in this document. Performance improvements particular to each customer should be discussed with GSFC Code 450. GRGT SGLT 6 is not currently planned to support a TDRS F8-F10 spacecraft. Therefore, KaSA services are not available through GRGT.

Revision 9

8-9

450-SNUG

Table 8-3. Salient Characteristics for TDRSS KaSA Forward Services

Parameter (Note 1) Value (Note 1)

Command channel radiated power Range channel radiated power Modulator phase imbalance (peak) Modulator gain imbalance (peak) Relative phase between command and range channels Data asymmetry (peak) (Note 2) Data rise time (90 percent of initial state to 90 percent of final state) (Note 2) Phase nonlinearity (peak) Gain flatness (peak) Gain slope (peak) AM/PM PN chip jitter (rms) (including effects of Doppler compensation) Data bit jitter (peak) (Note 2) Spurious PM (rms) In-band spurious outputs Incidental AM (peak) Phase noise (rms) 1 Hz - 10 Hz 10 Hz - 32 Hz 32 Hz - 1 kHz 1 kHz - 25 MHz Command/range channel PN chip skew (peak) PN chip asymmetry (peak) PN chip rate (peak) (relative to absolute coherence with carrier rate)
1. 2.

QPSK
+10 +0.5 dB

BPSK
NA

+3 degrees (for each BPSK channel) +0.25 dB QPSK 90 +3 degrees +3 percent <5 percent of bit duration +0.15 radian over +17.5 MHz +0.8 dB over +17.5 MHz +0.1 dB/MHz <7 degrees/dB QPSK/SS-BPSK <1 degree <1 percent <1 degree >27 dBc <2 percent <2.4 degrees <2.5 degrees <5.3 degrees <2.0 degrees QPSK/SS-BPSK <0.01 chip / NA <0.01 chip <0.01 chips/sec at PN code chip rate BPSK NA NA NA BPSK NA BPSK NA

Notes: The definitions and descriptions of the salient characteristics are provided in Appendix E. These values are the TDRSS contributions for data asymmetry, data transition time, and bit jitter, assuming perfect forward service data is provided to the SN ground terminal. The actual contributions by the NISN data transport system are negligible compared to those contributed by the TDRSS, since the SN ground terminal reclocks the data before it is processed by the SN ground terminal into the forward service signal.

Revision 9

8-10

450-SNUG

8.2.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS KaSA forward service during a scheduled service support period are usually initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for the GCMRs is provided in Section 10. Table 8-4 lists the KaSA forward service real-time configuration changes and their effects on the forward service signal. Table 8-4. KaSA Forward Service Real-Time Configuration Changes
Real-Time Configuration Changes GCMR OPM Forward Service Signal Interruption Yes

Customer Receiver Center Frequency Doppler Compensation Inhibit Doppler Compensation Reinitiation Forward Service Reacquisition (note 1) Forward Service Sweep Request (refer to Table 8-1) Data Rate Polarization Initiation or termination of the command channel PN code (note 2)

98/04 98/08 98/04 98/03 98/05 98/04 98/04 98/04

OPM 03 OPM 11 OPM 03 OPM 02 OPM 04 OPM 03 OPM 03 OPM 03

No No Yes Yes No Yes No

Notes: 1. Forward service reacquisition is a TDRSS reinitiation of forward link service by applying a 1 MHz frequency offset for 3 seconds to the predicted customer receive frequency specified in the customers service specification code (refer to Section 10, paragraph 10.2.2). 2. Initiation or termination of the command channel PN code enables or disables all forward link PN modulation (including the command and range channel, if applicable), respectively.

8.2.5 Acquisition Scenarios The following acquisition scenarios identify only the technical aspects of TDRSS KaSA forward service signal acquisition by the customer platform and do not include operational procedures related to acquisition: a. KaSAF Program Track and LEO Program Track Scenarios: 1. The TDRSS KaSA forward service signal does not depend on a customer platform return service. 2. Prior to the start of the TDRSS KaSA forward service, the TDRSS KaSA antenna will be open-loop pointed in the direction of the customer platform. 3. At the start of the TDRSS KaSA forward service as defined by the SHO, the TDRS will radiate, in the direction of the customer platform, a signal
Revision 9 8-11 450-SNUG

compatible with the TDRSS KaSA forward service signal parameters listed in Table 8-1. The EIRP directed towards the customer platform is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 8-2. 4. The customer platform receiving system will search for and acquire the command channel PN code (if applicable) and carrier. Normally, a customer MOC will not be transmitting forward service data to the NISN data transport system until the forward service signal has been acquired by the customer platform and the acquisition verified by the customer MOC from customer platform return service telemetry. Some customer platforms may require that there be no data transitions during the signal acquisition process, while others may merely result in longer acquisition times. 5. For QPSK modulation, the customer platform receiving system will search for and acquire the range channel PN code upon acquisition of the command channel PN code and carrier. 6. Upon completion of forward link acquisition and subsequent customer platform transition to signal tracking, the customer platform transmitting system must remain in a noncoherent mode as coherent operation is not supported through KaSA service. 7. The SN ground terminal will continue Doppler compensation of the TDRSS KaSA forward service signal unless requested by the customer MOC to inhibit the Doppler compensation. 8. Tacq in the customer platform receiver is a function of the customer platform receiver design and signal-to-noise density ratio. 9. Appendix A provides example link calculations for the TDRSS KaSA forward service. b. KaSAF Acquisition Scenario with Return Autotrack Services: 1. Prior to return autotrack acquisition, the TDRSS forward service EIRP will be the program or LEO program track values, whichever is applicable based upon customer characteristics (see paragraph 8.2.5.a for a description of the program and LEO program track acquisition scenarios). The EIRP directed towards the customer platform prior to return autotrack acquisition is dependent upon the customer providing an ephemeris uncertainty within the values defined in Table 8-2. The TDRS KaSA autotrack signal EIRP listed in Table 8-2 will be provided after return service autotrack acquisition is achieved. 8.3 KaSA Return Services

8.3.1 General The RF signals provided by the customer platform to the TDRS and the characteristics of data provided at the SN ground terminal interface are defined in paragraphs 8.3.2 through 8.3.6. This discussion assumes that an appropriate return service has been

Revision 9

8-12

450-SNUG

scheduled and a data signal is present at the TDRS interface. The KaSA return service supports data services through the 225 MHz channel and IF services through both the 225 MHz and 650 MHz channels, where automation of the 225 MHz IF service is currently being considered for implementation and the 650 MHz IF has been automated. 8.3.2 Signal Parameters The TDRSS 225 MHz KaSA return service signal parameters are listed in Table 8-5. Refer to paragraph 8.3.6 for 225 MHz and 650 MHz KaSA return IF service signal parameter characteristics and recommendations. The KaSA return supports only noncoherent, non-spread (Data Group 2 (DG2)) service. Within DG2, there are several types of modulation and a description of these general characteristics is provided in paragraph 8.3.2.1. A description of the features inherent in the DG2 noncoherent services is discussed in paragraph 8.3.2.2. 8.3.2.1 General Modulation and Noncoherent Description a. SQPSK Modulation. SQPSK modulation staggers one channel with respect to the other to prevent synchronous transitions. For signal configurations with identical I and Q symbol rates that are NRZ symbol formatted, SQPSK modulation must be used. The symbols of the Q channel are delayed 1/2 symbol relative to the I channel. b. QPSK Modulation. QPSK modulation is available when there is no relation between the I and Q channel transitions. For dual data source configurations, in which SQPSK is not required, QPSK modulation is used. c. BPSK Modulation. BPSK modulation is available for single data source configurations that use only one channel of the link. NOTE: For SQPSK modulation, the spectral characteristics of a customer platform saturated power amplifier will, to a great degree, retain the spectral characteristics of the band-limited input signal to that amplifier. This should result in better control of out-of-band emissions, which, in turn, provides more efficient communications and less interference to customer platform using adjacent frequency channels on the TDRS links.

Revision 9

8-13

450-SNUG

Table 8-5. TDRSS KaSA Return 225 MHz Service Signal Parameters
Parameter (Note 2) Description (Note 2)

DG2 (notes 1, 3) Transmit carrier frequency (Hz) (note 4) Carrier (F2) reference (Hz) DG2 Noncoherent Data modulation (notes 1, 3) Data format Without convolutional encoding With Rate 1/2 convolutional encoding Data rate restrictions Total (notes 1, 2) I channel Q channel DG2
I channel power restrictions Q channel power

F2 Customer platform oscillator BPSK, SQPSK, or QPSK (refer to Appendix B and Table 8-6) NRZ-L, NRZ-M, NRZ-S NRZ-L, NRZ-M, NRZ-S 1 kbps - 300 Mbps 1 kbps - 150 Mbps 1 kbps - 150 Mbps

Single data source-alternate I/Q bits Single data source-alternate I/Q encoded symbols Single data source-single data channel Dual data sources

1:1 1:1 NA 1:1

Notes: 1. Customer platform data configurations, including specific data rate restrictions for coding and formatting, are defined in Table 8-6 for TDRSS KaSA return service (refer also to Appendix B). Unless otherwise stated, the data rate restrictions given in this table assume uncoded and NRZ formatted signals. 2. Unless otherwise noted, all data rate values are to be interpreted as data bit rates, and not as data symbol rates. 3. Data rates and modulation schemes are based upon support through the KaSAR 225 MHz SN ground terminal receivers. Other data rates and modulation schemes are possible through the Ka-band 225 MHz and 650 MHz bandwidth IF services, where the 225 MHz IF service is currently being considered for automation and the 650 MHz IF service is automated. Please refer to paragraph 8.3.6 and contact GSFC Code 450 for further information. 4. The center frequency, fo, of the customer platform transmitter must be defined by the customer MOC in its service specification code to an integral multiple of 10 Hz.

Revision 9

8-14

450-SNUG

d. Noncoherent Mode. For noncoherent modes, the customer platform transmitted return link carrier frequency is derived from an on-board local oscillator. The customer platform transmit frequency for noncoherent service must be defined by the customer MOC to an accuracy of +6 kHz in its service specification code when requesting TDRSS KaSA return service. For customers whose frequency uncertainty is greater than +6 kHz, an expanded frequency search capability is available. e. Asynchronous Data Modulation. The data modulation is asynchronous to the carrier. 8.3.2.2 DG2 Signal Parameters KaSA DG2 signal parameters are discussed for noncoherent operation only. Tracking services are not provided via KaSA operations. a. DG2 Noncoherent. The DG2 carrier is independent of the TDRSS KaSA forward service carrier frequency. The customer platform transmit frequency for DG2 noncoherent service must be defined by the customer MOC to an accuracy of +6 kHz in its service specification code when requesting TDRSS KaSA return service. For customers whose frequency uncertainty is greater than +6 kHz, an expanded frequency search capability of +21 kHz is available after start of the return service. b. Functional Configurations. Table 8-6 lists the DG2 KaSA return service functional configurations for 225 MHz return service through the SN ground terminal receiver and a further description of the functional configurations, the I-Q channel ambiguity, and data polarity ambiguity is found in Appendix B.3.3. Refer to paragraph 8.3.6 for the 225 MHz and 650 MHz IF service functional configurations. 8.3.3 Communications Services To obtain TDRSS KaSA return service performance defined in this paragraph, the customer platform transmit signal must meet the requirements found in Table 8-7 and signal characteristics specified in Table 8-9. The TDRSS KaSA return service performance defined in this paragraph also assumes return service operation in an AWGN environment. Appendix G discusses performance degradations to the TDRSS KaSA return service due to RFI. Example link calculations are provided in Appendix A. TDRSS KaSAR supports only supports non-powered flight customer dynamics & && R ( R < 7.9 km/sec, R < 11.4 m/sec2, and &&& < 0.013 m/sec3). 8.3.3.1 Acquisition The KaSAR service supports acquisition for customer platforms operating under non-powered flight dynamics as defined in Table 8-7. The KaSAR service total channel Tacq will be less than or equal to the sum of the following, which are given in Table 8-7: a. Autotrack acquisition time (when the TDRSS KaSA return service autotrack mode is enabled)

Revision 9

8-15

450-SNUG

Table 8-6. KaSA Return 225 MHz Service Configurations

Return Service Configuration5 Source Data Rate Restrictions and Availability3,4 DG1 Mode 1, 2, 3 and DG2 Coherent Data format Single Source Data BPSK Rate 1/2 coded Rate 1/3 coded Uncoded SQPN Identical I & Q channel data Rate 1/2 coded Uncoded Data rate DG2 Noncoherent1,2 Data format NRZ NRZ NRZ NRZ NRZ NRZ NRZ Data rate 1 kbps 75 Mbps 1 kbps 150 Mbps 1 kbps 10 Mbps >10 150 Mbps 1 kbps 300 Mbps 1 kbps 75 Mbps 1 kbps 150 Mbps Configuration supported Notes: 1. - Configuration not supported For DG2 configurations: a. Single data source configurations with data on one channel: BPSK modulation is used. b. Single data source configurations with data on both channels: SQPSK modulation and an I:Q power ratio of 1:1 is used. For the alternate I/Q bit configuration, the SN requires the I and Q channels be independently and differentially formatted (-M,-S). c. Dual data source configurations: SQPSK must be used when there are identical baud rates on the I and Q channels (see paragraph 8.3.2.1.a); QPSK is used for all other configurations; for both SQPSK and QPSK, an I:Q power ratio of 1:1 is supported. Noncoherent configurations require a customer transmit frequency uncertainty of + 6 kHz. If a customer cannot accurately define their transmit frequency to within + 6 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 21 kHz after the start of service. Data rates and modulation schemes are based upon support through the KaSAR 225 MHz SN ground terminal receivers. Other data rates and modulation schemes are possible through the Ka-band 225 MHz and 650 MHz bandwidth IF services, where the 225 MHz IF service is currently being considered for automation and the 650 MHz IF service is automated. Please refer to paragraph 8.3.6 and contact GSFC code 450 for further information. Unless otherwise noted, all data rates are to be interpreted as data bit rates, and not as data symbol rates. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. Appendix B describes the functional configurations and associated I-Q channel and data polarity ambiguities. Additionally, Figure B-10 depicts the SN supported convolutional coding schemes. For a channel with rate 1/2 coding and data rates greater than 10 Mbps, the customer transmitter must be configured to use an N-parallel encoder, where N is the number of branch rate 1/2 encoders for the channel. N = channel data rate in bps/1x107, where N is rounded to the next higher integer if N is not an integer.

SQPSK SQPSK3

Rate 1/2 coded alternate I/Q encoded symbols Alternating data I/Q Individually rate 1/2 coded Individually rate 1/3 coded Uncoded

Dual Data Sources (data rates are for each source separately)

QPSK1 or SQPSK1

Rate 1/2 coded Rate 1/3 coded Uncoded

2. 3.

4. 5.

Revision 9

8-16

450-SNUG

Revision 9

Table 8-7. TDRSS KaSA Return Service

Parameter (Note 4) Description (Note 4)

Field of view (FOV) (each TDRS)

Primary (PFOV) + 22 degrees east-west + 28 degrees north-south (rectangular)

LEO (LEOFOV) +10.5 degree conical

Extended Elliptical (EEFOV) (F8-F10) (note 12) 24.0 degrees inboard east-west 76.8 degrees outboard east-west +30.5 degrees north-south < + 2.0 sec

Customer Ephemeris Uncertainty (along the customer orbital track) TDRS antenna polarization (note 1) TDRS antenna axial ratio (maximum)

< + 2.0 sec RHC or LHC selectable After Autotrack Acquisition (PFOV, LEOFOV, and EEFOV) (notes 12, 13) 1.8 dB over beamwidth 3 dB

< + 1.5 sec

LEO Program Track (LEOFOV)

Program Track (PFOV)

8-17
Receive frequency (nominal) 225 MHz Bandwidth Service 650 MHz Bandwidth Service RF channel bandwidth (3 dB, minimum) 10 Bit Error Rate (notes 2, 3, 4) Orbital Dynamics (free flight)
-5

2.4 dB (225 MHz service) 1.0 dB (650 MHz IF service)

2.7 dB (225 MHz service) 1.0 dB (650 MHz IF service)

25.25 to 27.50 GHz (note 9) 25.2534 to 27.4784 GHz + 1.28 MHz in 25 MHz steps SNIP/SFCG Recommended Center Frequencies: 25.60 GHz, 25.85 GHz, 26.10 GHz, 26.35 GHz, 26.60 GHz, 26.85 GHz, 27.10 GHz, 27.35 GHz + 1.28 MHz 25.545 to 27.195 GHz + 1.28 MHz in 25 MHz steps 225 MHz or 650 MHz (note 10) All Prec values are in dBW; dr=data rate in bps

& && R 7.9 km/sec, R 11.4 m/sec 2 , jerk .013 m/sec 3

450-SNUG

Revision 9
DG2 DG2

Table 8-7. TDRSS KaSA Return Service (contd)

Parameter (Note 4) Description (Note 4)

10-5 Bit Error Rate (notes 2, 3, 4) (contd) Minimum Required Prec (dBW) for 225 MHz service uncoded channels (note 11):

All Prec values are in dBW; dr=data rate in bps Autotrack (PFOV, LEOFOV, and EEFOV) (note 12) -242.6 + 10log10(dr) -241.1 + 10log10(dr) LEO Program Track (LEOFOV) Program Track (PFOV)

Data rate < 25 Mbps Data rate > 25 Mbps Minimum Required Prec (dBW) for 225 MHz service Rate 1/2 convolutional encoded channels (note 11):

-239.1 + 10log10(dr) -237.6 + 10log10(dr)

-235.2 + 10log10(dr) -233.7 + 10log10(dr)

8-18
450-SNUG

Data rate < 10 Mbps Data rate > 10 Mbps Acquisition (notes 5, 8): Orbital dynamics (free flight) Total Channel Acquisition Time (assumes the customer return service signal is present at the SN ground terminal at the start time of the return service support period) (225 MHz service)

-248.5 + 10log10(dr) -247.6 + 10log10(dr)

-245.0 + 10log10(dr) -244.1 + 10log10(dr)

-241.1 + 10log10(dr) -240.2 + 10log10(dr)

& && R 7.9 km/sec, R 11.4 m/sec 2 , jerk .013 m/sec 3

Sum of the following: 1. Autotrack acquisition time (when the TDRSS KaSA return service autotrack mode is enabled) 2. Carrier acquisition time 3. Symbol/Decoder synchronization time (coded channel) or Symbol synchronization time (uncoded channel)

Revision 9

Table 8-7. TDRSS KaSA Return Service (contd)

Parameter (Note 4) Description (Note 4)

Acquisition (notes 5, 8): Autotrack Acquisition (if applicable) for 225 MHz service: Minimum Required Prec with probability > 99% (note 11) PFOV >-184.1 dBW or consistent with the Prec for BER, whichever is greater Acquisition Time : Carrier Acquisition for 225 MHz service: < 10 seconds Autotrack (PFOV, LEOFOV, and EEFOV) (note 12) > -185.5 dBW or consistent with the Prec for BER, whichever is greater Acquisition Time (Pacq > 90%) Noncoherent operations with frequency uncertainty (note 6): < + 6 kHz < + 21 kHz < 1 sec < 3 sec LEO Program Track (LEOFOV) > -182.0 dBW or consistent with the Prec for BER, whichever is greater Program Track (PFOV) LEOFOV >-188.0 dBW or consistent with the Prec for BER, whichever is greater EEFOV (note 12) >-184.1 dBW or consistent with the Prec for BER, whichever is greater

8-19
450-SNUG

Minimum Required Prec (note 11)

> -178.1 dBW or consistent with the Prec for BER, whichever is greater

Revision 9

Table 8-7. TDRSS KaSA Return Service (contd)

Parameter (Note 4) Description (Note 4)

Acquisition (notes 5, 8): Channel Decoder/Symbol Synchronization Acquisition for 225 MHz service (coded data) (note 7): Minimum data bit transition density Number of consecutive data bits without a transition Prec (dBW) Acquisition time (in seconds) with >99% probability: NRZ Channel Symbol Synchronization Acquisition for 225 MHz service (uncoded data) (note 7): Prec (dBW) Synchronization Channel Symbol Synchronization Acquisition for 225 MHz service (uncoded data) (note 7) (contd): Acquisition time (in seconds) with >99% probability: NRZ Signal Tracking Orbital dynamics (free flight) < 3000/(Channel Data Rate in bps) refer to paragraph 8.3.3.3 consistent with the Prec for BER Achieved when error rate for next 1000 bits is < 10
-5

> 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 consistent with the Prec for BER

< 6500/(Channel Data Rate in bps)

8-20
450-SNUG

& && R 7.9 km/sec, R 11.4 m/sec 2 , jerk .013 m/sec 3

Table 8-7. TDRSS KaSA Return Service (contd)

Parameter (Note 4) Description (Note 4)

Revision 9

Reacquisition Orbital dynamics (free flight) Duty Factor 1. 2. 3.

refer to paragraph 8.3.3.4

& && R 7.9 km/sec, R 11.4 m/sec 2 , jerk .013 m/sec 3

100 percent

4. 5.

Notes: Operational considerations may limit choice of TDRS antenna polarization. The KaSA forward and return polarization must be the same in order to obtain simultaneous forward and return services through the same TDRS SA antenna. The BER is for a customer platform transmitting a signal on an AWGN channel which complies with the constraints defined in Table 8-9. Refer to Appendix G for a discussion of the additional degradation applicable to the TDRSS KaSA return service performance due to Ka-band RFI. The required customer Prec must meet the Prec for BER, autotrack acquisition, or signal acquisition, whichever is greatest. Paragraph 8.3.3.2.b provides the required Prec description for each possible KaSAR data configuration. Refer to Appendix A, paragraph A.4, for a definition of Prec. The minimum required Prec equations for BER produce the minimum Prec for a given data rate for all possible signal characteristics. CLASS analysis will produce a more accurate performance projection based upon desired customer signal characteristics, such as data rate, data type, and jitter values. SN support may be possible for customers whose Prec is less than the required Prec for 10-5 BER performance as long as the customer is willing to accept support on a best-effort basis and less than 100 percent coverage. Any customer interested in receiving this marginal SN coverage shall be required to negotiate all support with GSFC Code 450. All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates. For acquisition, the minimum Prec value listed applies to the total (I+Q)Prec. Acquisition requires the Prec to also be consistent with the Prec required for BER, whichever is greater. Failure to provide the minimum Prec for autotrack acquisition at the start of service

8-21
450-SNUG

may preclude successful TDRSS autotrack pull-in.

Table 8-7. TDRSS KaSA Return Service (contd)

Notes (contd): Noncoherent configurations (DG1 mode 2 and DG2 noncoherent) require a customer transmit frequency uncertainty of + 6 kHz. If a customer cannot accurately define their transmit frequency to within + 6 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 21 kHz after the start of service. For symbol synchronization and symbol/decoder synchronization, the minimum symbol transition density and consecutive symbols without a transition must meet the specifications defined in Table 8-9. For encoded channels, it is recommended that customers use G2 inversion to increase symbol transition density. All minimum Prec values include atmospheric and rain attenuation on the link from TDRS to the SN ground terminal; however, service outages may be experienced during periods of heavy rain. The data rate and carrier frequency will be constrained such that the first null of the spectrum falls between 25.25 and 27.50 GHz. The SN ground terminal receivers support KaSAR service for the 225 MHz. An automated Ka-band IF service capable of supporting the 650 MHz bandwidth is currently available and operates at a center frequency of 1.2 GHz. An automated 225 MHz bandwidth Ka-band IF service is being considered for development. Please refer to paragraph 8.3.6 and contact GSFC Code 450 for further information. The required Prec for autotrack performance is based upon a customer that meets the required ephemeris uncertainties for the Primary FOV, LEOFOV, or the Extended Elliptical FOV. The required Prec for program track performance is based upon a customer that meets the required ephemeris uncertainties for the Primary FOV. The required Prec for LEO program track performance is based upon a customer that meets the required LEO ephemeris uncertainties for the LEOFOV. Customers may experience better performance through the KaSA program track and LEO program track services than listed in this document. Performance improvements particular to each customer should be discussed with GSFC Code 450. KaSA return autotrack service for the Extended Elliptical FOV will be supported on a best effort basis. Autotrack service is not available through the Ka-band 225 MHz and 650 MHz bandwidth IF services.

Revision 9

6. 7.

8. 9. 10.

11.

8-22
12. 13.

450-SNUG

b. Carrier acquisition time c. Symbol/Decoder synchronization time (for coded data) or Symbol synchronization time (for uncoded data). Tacq assumes that the customer platform return service signal is present at the SN ground terminal at the start time of the scheduled return service support period. The total acquisition process consists of the following acquisition sub-processes: a. If autotrack is enabled, autotrack acquisition will commence upon the start of the scheduled return service support period or at the instant at which user signal energy is present at the KaSAR autotrack signal processing input, whichever occurs last, and will occur within the time given in Table 8-7 for Prec greater than or equal to the values in Table 8-7. b. Carrier acquisition will occur within the time given in Table 8-7. Carrier acquisition may not commence until the Prec is greater than or equal to the value commensurate with the applicable minimum Program Track Prec under the applicable Program Track scenario. If autotrack is disabled, the time allowed for PN code and carrier acquisition will commence at the start of scheduled return service support period or when the minimum Prec is achieved, whichever occurs last. If autotrack is enabled, PN code and carrier acquisition may commence at any time after the start of scheduled return service support period, but the time allowed will not commence until the minimum Prec is achieved. If autotrack is enabled and required to achieve this minimum Prec, the total time allowed to achieve PN code and carrier acquisition will be the sum of the time allowed for autotrack acquisition and PN code and carrier acquisition. c. Symbol/Decoder and Symbol synchronization times will be measured from the time carrier acquisition is achieved to the time either symbol synchronization is achieved for uncoded channels or decoder synchronization is achieved for rate 1/2 coded channels. Decoder synchronization is achieved when the Viterbi decoder has selected and implemented the correct blocking of the input symbols (into groups of (G1, G2) symbol pairs) for rate 1/2 codes. d. After symbol/decoder and symbol synchronization is achieved, KaSA return service channel data is available at the SN ground terminal interface. e. To minimize return data loss, it is recommended that the customer platform transmit an idle pattern on its data channels until after it has observed (via the UPD data) that the SN ground terminal has completed all of its data channel signal acquisition processes. f. Requirements for bit error probability and symbol slipping take effect at the time decoder synchronization is achieved for convolutional encoded data and at the time symbol synchronization is achieved for uncoded data. NOTE: Data and symbol transition density values higher than the minimums required will reduce these acquisition times.

Revision 9

8-23

450-SNUG

8.3.3.2 Bit Error Rate (BER) Table 8-7 provides Prec equations that will result in a customer achieving a BER of 10-5 for TDRSS compatible signals. The 225 MHz and 650 MHz IF service BER depends on the customer receiver characteristics. Refer to paragraph 8.3.6 for more information on the 225 MHz and 650 MHz IF services. The BER Prec equations are applicable for non-powered flight dynamics and the following conditions: a. Data encoding. Customer platform transmission of Rate 1/2 convolutional encoded or uncoded signals are supported for KaSA return services. Detailed rate 1/2 coding design is described in Appendix B. Reed-Solomon decoding is available to WDISC customers; typical performance is given in Appendix K. b. Received Power. Prec is in units of dBW. The customer project, in determining its design requirements for minimum customer platform EIRP, must take into account customer platform transmit antenna pointing losses, the space loss between the customer platform and the TDRS, and the polarization loss incurred between the customer platform transmit antenna and the TDRS receive antenna. The maximum TDRS receive antenna axial ratio is given in Table 8-7 (also refer to Appendix A). For DG2 services, the following conditions apply: 1. Balanced Power Single Data Source-Alternate I/Q Bits. For a customer platform transmitting alternate I and Q data bits from a data source (single data source-alternate I/Q bits), the total (I+Q)Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 8-7, where dr is the single data source data rate prior to separation into the I and Q channels. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 2. Balanced Power Single Data Source-Alternate I/Q Encoded Symbols. For a customer platform transmitting alternate I and Q encoded symbols from a data source (single data source-alternate I/Q encoded symbols), the total (I+Q)Prec must be consistent with the minimum Prec for a 10-5 BER listed in Table 8-7, where dr is the single data source data rate prior to the rate 1/2 encoder. The Q/I (power) must be equal to 1:1. Refer to Appendix B for further information on this data configuration. 3. Dual Data Sources. For a customer platform transmitting independent data on the I and Q channels (dual data sources), each channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 8-7, where dr is that channels data rate. Refer to Appendix B for further information on this data configuration. 4. Single Data Source with Single Data Channel. For a customer platform transmitting one channel, the channels Prec must be consistent with the Prec for a 10-5 BER listed in Table 8-7, where dr is the channel data rate. Refer to Appendix B for further information on this data configuration. c. Customer Degradations. Further reductions in the TDRSS KaSA return service performance identified in Table 8-7 can occur. The TDRSS KaSA return
Revision 9 8-24 450-SNUG

services and tracking services will be provided without degradation for user customer platform transmitted signal characteristics within the constraints specified in Table 8-9. Customer platform parameters exceeding these constraints can also degrade TDRSS KaSA return service performance. Refer to Section 3, paragraph 3.5 for guidelines if the constraints in this paragraph cannot be met. Definitions of user customer platform constraints are given in Appendix E. d. Multipath. The SN ground terminal will provide lockup and interference protection from multipath signals reflected from the Earth. 8.3.3.3 Signal Tracking TDRSS provides KaSA 225 MHz return signal tracking (carrier, symbol synchronization, Viterbi decoder synchronization) for non-powered flight dynamics. During a customer KaSA return service support period, loss-of-lock (carrier, symbol synchronization, and Viterbi decoder) indications appear in the periodically updated User Performance Data (UPD) (every 5 seconds). The KaSA return service shall maintain signal tracking for the following conditions: a. Cycle Slips. The mean time-between-cycle slip in the SN ground terminal carrier tracking loop for each TDRSS KaSA return service will be 90 minutes minimum. This value applies at carrier tracking threshold, which is 3 dB less than the minimum Prec for BER listed in Table 8-7, and increases exponentially as a function of linear dB increases in Prec. Cycle slips may result in channel and/or data polarity reversal. The SN ground terminal can correct for these reversals under the same conditions as the SN ground terminal can resolve channel and/or data polarity ambiguity as discussed in Appendix B. The time for the SN ground terminal to recover from a cycle slip will be consistent with the time required for the SN ground terminal receiver to detect and automatically reacquire the signal. b. Bit Slippage. For each TDRSS KaSA return service operating with a minimum Prec required consistent with the Prec for BER of Table 8-7 and data transition densities greater than 40% for NRZ symbols, the minimum mean time between slips caused by a cycle slip in the SN ground terminal symbol clock recovery loop is either 90 minutes or 1010 symbol periods, whichever is greater. For a KaSA return service operating with 1 dB more than the minimum Prec required for the BER, and NRZ symbol transition densities between 25% and 40%, the minimum mean time between slips is either 90 minutes or 1010 symbol periods, whichever is greater. c. Loss of Symbol Synchronization. For each TDRSS KaSA return service with data transition densities greater than 40% for NRZ symbols, the SN ground terminal symbol synchronization loop will not unlock for a Prec that is 3 dB less than the minimum Prec required for BER in Table 8-7 (refer also to note 3 of Table 8-7). For NRZ symbol transition densities between 25% and 40%, the SN ground terminal symbol synchronizer loop will not unlock for a Prec that is

Revision 9

8-25

450-SNUG

2 dB less than the minimum Prec required for the BER. In both cases, the BER performance will be degraded when the Prec is less than the minimum required for BER. d. Loss of Autotrack. Loss of autotrack is detected by the SN ground terminal when either: 1. The autotrack SA antenna azimuth/elevation angles diverge from the program track SA antenna azimuth/elevation angles. The check on angle divergence protects the autotrack system from false tracking an interfering signal. When loss of autotrack is detected due to angle divergence, the SN ground terminal will automatically begin the autotrack reacquisition process. 2. There is a drop in received power that causes the receiver to drop carrier lock. The receiver will maintain carrier lock for a Prec that is 3 dB less than the minimum Prec for BER. (a) When loss of autotrack is detected due to signal fades during TDRS F1-F7 KaSAR support, the SN ground terminal will revert to return program track, transmit a forward link signal towards a customer who is using the program track EIRP values listed in Table 8-2 (if forward service is scheduled), and automatically begin the return autotrack reacquisition process. For a maximum of 60 seconds after the first loss of autotrack is detected due to signal fades during TDRS F8-F10 KaSAR support, the TDRS SA antenna will continue to move at the calculated customer platform angular rate. If, within that 60 seconds, the KaSA return service Prec has increased back to or above the minimum level required by the TDRSS KaSA return carrier acquisition, the process should transfer almost immediately to its fine-track mode as the TDRS SA antenna boresight should still be pointed fairly close to the actual direction of the customer platform position. However, if after 60 seconds the KaSA return service Prec has not increased back to or above the minimum level required by the TDRSS KaSA return service carrier acquisition, the SN ground terminal reverts to open-loop pointing (program track) the TDRS SA antenna in the calculated direction of the customer platform position. When the SN ground terminal reverts to program track, the TDRSS will transmit a forward link signal towards a customer who is using the program track EIRP values listed in Table 8-2 (if forward service is scheduled). The TDRSS KaSA return service autotrack process will not restart until the KaSA return service Prec has increased back to or above the minimum level required by that process.

(b)

8.3.3.4 Reacquisition For return service autotrack reacquisition process, refer to paragraph 8.3.3.3.d. While in the carrier tracking state, a loss of lock condition induced by a cycle slip will be
Revision 9 8-26 450-SNUG

automatically detected and a reacquisition will be automatically initiated. For a customer platform that continues to transmit the minimum Prec for acquisition and maintains an ephemeris uncertainty as defined in Table 8-7, the normal total channel reacquisition time for non-powered flight dynamics will be less than or equal to that for the initial total channel acquisition, with a probability of at least 0.99. If lock is not achieved within 10 seconds of loss of lock, an acquisition failure notification message will be sent to the MOC and the SN ground terminal will reinitiate the initial service acquisition process. Upon receipt of the loss-of-lock indications in the UPD, the customer MOC may request a TDRSS KaSA return service reacquisition GCMR (refer to Section 10). It is recommended that the customer MOC delay initiation of the GCMR for at least 35 seconds after initial receipt of the loss-of-lock indications in the UPD. 8.3.3.5 Additional Service Restrictions a. Sun Interference. The TDRSS KaSA return service performance will not be guaranteed when the center of the sun is within 0.5 degrees of the TDRS KaSA receiving antenna boresight. Additionally, the TDRSS KaSA return service performance will not be guaranteed when the center of the sun is within 1 degree of the boresight of the SN ground terminal receiving antenna supporting the TDRS. b. Mutual Interference. It is possible for mutual interference to exist between KaSA customer platforms operating with the same polarization and frequency. The SN can provide tools to assist customers in interference prediction and interference mitigation. 8.3.4 Real-Time Configuration Changes Changes to the operating conditions or configuration of a TDRSS KaSA return service during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in Section 10. Table 8-8 lists the KaSA return service real-time configuration changes and their effects on the return service. 8.3.5 Autotrack/Signal Acquisition Scenarios The following acquisition scenario identifies only the technical aspects of TDRSS KaSA return service autotrack (if enabled) and signal acquisition by the SN ground terminal and does not include operational procedures related to acquisition. Acquisition is dependent upon the customer providing an ephemeris with a maximum epoch uncertainty as defined in Table 8-7:

Revision 9

8-27

450-SNUG

Table 8-8. KaSA Return Service Real-Time Configuration Changes

Real-Time Configuration Changes GCMR OPM Return Service Interruption

Return Service Reacquisition Noncoherent Expanded Customer Spacecraft Frequency Uncertainty Channel Data Rate Noncoherent Transmit Frequency Redefinition of customer minimum EIRP Redefinition of customer maximum EIRP Channel Data Format Channel Data Bit Jitter Polarization DG2 Carrier Modulation TDRSS Autotrack Mode Data Source/Channel Configuration G2 inversion Frame Length Frame Sync Word Length Frame Sync Word Bit Pattern Sync Strategy Parameters

98/03 98/07 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04 98/04

OPM 03 OPM 07 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03 OPM 03

Yes No No Yes Yes No No No No Yes No Yes No No No No

98/04 OPM 03 No Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Any other reconfigurations of the SN ground terminal may momentarily affect signal tracking.

Revision 9

8-28

450-SNUG

a. TDRS SA Antenna Pointing: 1. KaSA Autotrack Description. The TDRSS KaSA return service autotrack process (if enabled) will acquire and track a customer platform KaSA return service signal providing improved pointing of the TDRS SA antenna in the direction of the customer platform. This decreases the required Prec at the input to the TDRS antenna. TDRSS KaSA return autotrack service is independent of whether a TDRS forward service signal is concurrently scheduled. 2. Autotrack Power Requirement. For the TDRSS KaSA return service autotrack process to acquire a customer platform signal, the KaSA return service Prec must be consistent with either the Prec required for autotrack acquisition or the Prec required for BER, whichever is greater (please refer to Table 8-7). 3. Program track Operational Process. The SN ground terminal open-loop points the TDRS SA antenna in the calculated direction of the customer platform. The acquisition process begins with carrier acquisition as described below for coherent or noncoherent operations as applicable. 4. Autotrack Operational Process. The SN ground terminal initially open-loop points the TDRS SA antenna in the calculated direction of the customer platform. If the TDRSS KaSA return service autotrack process is initiated (or reinitiated), the SN ground terminal then processes error signals derived from the received customer platform KaSA return service signal to correct for small error build-ups in moving the TDRS antenna at the calculated angular rate of the customer platform. After the time when the signal is first present at the TDRS with adequate KaSA return service Prec [refer to paragraph 2 above], autotrack acquisition will be achieved within the autotrack acquisition time listed in Table 8-7. The acquisition process continues with carrier acquisition as described below for coherent or noncoherent operations as applicable. 5. TDRS Forward EIRP Level. If the TDRSS KaSA return service autotrack process is enabled, the forward service EIRP will default to program track values listed in Table 8-2 during autotrack acquisition. Following the completion of return autotrack acquisition, the forward EIRP will be consistent with the autotrack values listed in Table 8-2. If the return autotrack service experiences a reacquisition, the forward EIRP values may decrease to the program track values. If the TDRSS KaSA return service autotrack process is inhibited, the forward EIRP will be consistent with the program track values listed in Table 8-2, where either LEO program track or program track values depend upon customer platform orbital characteristics. b. Noncoherent Signal Acquisition Scenario: 1. This mode of customer platform operation does not require a TDRSS forward service signal to be received by the customer platform. However, the customer platform transmitter must be commanded to turn on when

Revision 9

8-29

450-SNUG

2.

3.

4.

noncoherent transmissions are desired, either by stored commands, on-board configuration settings, or direct commands from its customer MOC. The customer platform Prec must be compatible with the minimum Prec required for BER and the other TDRSS KaSA return service signal parameters listed in Table 8-5. At the service start time specified by the SHO, the SN ground terminal will begin the search for the customer platform signal based upon predicted Doppler. The SN ground terminal corrects the received customer platform signal for Doppler to allow for SN ground terminal implementation of receivers with narrow acquisition and tracking bandwidths. The Doppler correction used by SN ground terminal is one-way and based on the customer platform transmission frequency stated in the SHO and any subsequent OPMs. The SN ground terminal will begin carrier acquisition when the Prec meets the minimum required value for this acquisition process. Carrier acquisition may occur prior to completion of autotrack acquisition (if enabled). The SN ground terminal will complete acquisition of the customer platform signal (carrier) within the time limits listed in Table 8-7. Return service will be achieved at the SN ground terminal receiver output within the total acquisition time limits listed in Table 8-7, which includes SN ground terminal symbol and Viterbi decoder synchronization.

8.3.6 225 MHz and 650 MHz IF Service This section specifies characteristics and recommendations for the KaSA 225 MHz and KaSA 650 MHz IF services, where the 225 MHz IF service is currently being considered for automation and the 650 MHz IF service is automated. SN IF services are available to customers on a case-by-case basis. The IF service is supported through TDRS F8F10 via the SN ground terminal infrastructure, where the customer provides the receiver equipment and the SN only provides the signal at the IF with the characteristics described in this section. Paragraph 8.3.6.1 describes the aggregate channel characteristics of the TDRS F8-F10 spacecraft and SN ground segment for understanding the IF interface. The performance of the customer link greatly depends on the customer signal characteristics and the receiver used. Paragraph 8.3.6.2 describes potential signal characteristics and expected performance through the TDRS F8-F10 spacecraft and SN ground segment. The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with Code 450 to achieve desired performance.

Revision 9

8-30

450-SNUG

Table 8-9. TDRSS KaSA Return 225 MHz Service Customer Platform Signal Constraints
Parameter (Notes 1, 2, and 3) Description (Notes 1, 2, and 3)

Minimum channel data bit transition density (required for acquisition only) Consecutive channel data bits without a bit transition (required for acquisition only) Minimum channel symbol (bit) transition density (Note 4) Consecutive channel symbols (data bits) without a symbol (data bit) transition (Note 4) Data asymmetry (peak) (Note 4) Symbol (data) bit jitter and jitter rate (Note 4) Phase imbalance Gain imbalance Phase nonlinearity (applies for all types of phase nonlinearities) (peak) Gain flatness (peak) Gain slope AM/PM Noncoherent frequency stability (peak) (Notes 5, 6) +6 kHz customer oscillator frequency uncertainty 1-sec observation time 5-hr observation time 48-hr observation time +21 kHz customer oscillator frequency uncertainty 1-sec observation time 5-hr observation time 48-hr observation time Incidental AM (peak) For open-loop pointing At frequencies >100 Hz For autotrack performance At frequencies: 10 Hz-10 kHz At frequencies: 10 Hz-2 kHz

> 64 randomly distributed data bit transitions within any sequence of 512 data bits < 64 >128 randomly distributed symbol (bit) transitions within any sequence of 512 symbols (bits) <64 symbols (data bits) < + 3 percent < 0.1 percent (see Appendix E) < + 3 degrees < + 0.25 dB <3 degrees over +80 MHz <0.3 dB over +80 MHz <0.1 dB/MHz over +80 MHz <12 deg/dB (for the 225 MHz service)

<3 x 10-9 <7.2 x 10-8 <2.18 x 10-7

<3 x 10-9 <2.54 x 10-7 <7.64 x 10-7

<5 percent <3 percent <0.6 percent (Note 7)

Revision 9

8-31

450-SNUG

Table 8-9. TDRSS KaSA Return 225 MHz Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1, 2, and 3) Description (Notes 1, 2, and 3)

Spurious PM Minimum 3-dB bandwidth prior to power amplifier Phase noise (rms) (Note 8) DG2 Noncoherent Doppler Tracking NOT Required (Note 9) Channel baud rate < 108.5 ksps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz 108.5 ksps < Channel baud rate < 6 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz Channel baud rate > 6 Msps 1 Hz 10 Hz 10 Hz 100 Hz 100 Hz 1 kHz 1 kHz 150 MHz In-band spurious outputs, where in-band is twice the maximum channel baud rate Out-of-band emissions I/Q data skew (relative to requirements for I/Q data synchronization where appropriate) (peak) (Note 4) Axial ratio for autotrack Data rate tolerance I/Q power ratio tolerance Permissible Prec variation (without reconfiguration GCMR from customer MOC) (Note 10)

<2 degrees >2 times maximum channel baud rate

4.0 rms 2.5 rms 1.4 rms 1.4 rms

50.0 rms 5.5 rms 2.4 rms 2.4 rms 50.0 rms 10.0 rms 2.0 rms 2.0 rms
>30 dBc See Appendix D for allowable limits on out-ofband emissions, including spurs <3 percent <1 dB <+0.1 percent <+0.4 dB <12 dB

Revision 9

8-32

450-SNUG

Table 8-9. TDRSS KaSA Return 225 MHz Service Customer Platform Signal Constraints (contd)
Parameter (Notes 1, 2, and 3) Description (Notes 1, 2, and 3)

Permissible rate of Prec Variation Maximum Prec

<10 dB/sec -143.0 dBW

Notes: 1. The definitions and descriptions of the customer constraints are provided in Appendix E. 2. When a constraint value is listed for a baud rate range and data is transmitted on both channels, the maximum baud rate of the 2 channels should be used to determine the constraint value applicable. 3. These signal constraints apply to the KaSAR 225 MHz through the SN ground terminal receivers. Refer to paragraph 8.3.6 and contact GSFC Code 450 for signal constraints pertaining to the KaSAR 225 MHz and 650 MHz IF service. 4. When the data is Rate 1/2 convolutionally encoded, these data bit parameters should be interpreted as symbol parameters. For encoded channels, it is recommended that customers use G2 inversion to increase symbol transition density. CCSDS randomization is recommended to aid in compliance with the data randomness requirements. 5. The frequency stability requirements are valid at any constant temperature (0.5 C) in the range expected during the mission. At a minimum, a temperature range of -10 C to +55 C shall be considered. 6. Noncoherent configurations require a customer transmit frequency uncertainty of + 6 kHz. If a customer cannot accurately define their transmit frequency to within + 6 kHz, a customer can request a reconfiguration which would expand the oscillator frequency search to + 21 kHz after the start of service. 7. The TDRSS design implementation may not provide the stated TDRSS KaSA return service autotrack performance when Prec = Prec (minimum) and the Incidental AM (peak), at frequencies

2 kHz, must be more tightly controlled. 8. Derivation of the phase noise requirements involved making assumptions about the distribution of the phase noise power in each frequency region. Since no phase noise PSD will exactly match the phase noise power distribution assumed for this derivation, phase noise PSDs which are close to violating the phase noise limits or phase noise PSDs which do violate the phase noise limits should be evaluated on a case-by-case basis to determine their acceptability. 9. KaSA service does not support Doppler tracking. 10. The minimum SHO EIRP should reflect the minimum P expected over the service period, where
the P 12 dB greater than the minimum may cause false PN lock or nonacquisition.
rec

2 kHz, is close to or at 0.6 percent. For TDRSS KaSA return service autotrack performance, either P must be increased above Prec (minimum), or the Incidental AM (peak), at frequencies
rec

can exceed this minimum by no more than 12 dB. An actual customer P

rec

rec

value that is

Revision 9

8-33

450-SNUG

NOTE: Autotracking is not provided for the 225 MHz and 650 MHz IF services. Changes to the operating conditions or configuration of a TDRSS KaSA 225 MHz or 650 MHz return IF services during a scheduled service support period are initiated by a GCMR from the customer MOC. The requested changes will be implemented within 35 seconds of receipt of the GCMR at the SN ground terminal. The MOC will be notified upon initiation of the requested changes via GCM. Additional information concerning SN ground terminal response times for GCMRs is provided in Section 10. Table 8-10 lists the KaSA IF return service real-time configuration changes and their effects on the return service. Table 8-10. KaSA Return IF Service Real-Time Configuration Changes
Real-Time Configuration Changes GCMR OPM Return Service Interruption

Polarization

98/04 OPM 03 Yes Note: Items that are indicated to cause return service interruption will cause the SN ground terminal receiver to discontinue signal tracking and attempt to reacquire the return service signal after the appropriate reconfiguration. Any other reconfigurations of the SN ground terminal may momentarily affect signal tracking.

8.3.6.1 Channel Characteristics As discussed above, this is not an end-to-end service so a set of customer platform signal constraints is not available due to the dependencies on the exact customer signal characteristics as well as receiver capabilities. The 225 MHz (expected to be operational in mid 2008) and 650 MHz IF services provide a KaSAR signal through the TDRS F8-F10 spacecraft and SN ground segment, including IF output channel characteristics as specified in Table 8-11. This will allow customers to be able to understand the signal distortions that are outside of their control. For additional characteristics applicable to the KaSA 225 MHz and 650 MHz IF service, refer to Table 8-7.

Revision 9

8-34

450-SNUG

Table 8-11. TDRS KaSAR 225 MHz and 650 MHz IF Service Spacecraft and Ground Segment Channel Characteristics
Parameter 225 MHz Description (expected
operational in mid 2008)

650 MHz Description

TDRS Ka-band Receive Center Frequencies (note 1)

25.2534 - 27.4784 GHz in 25 MHz 25.545 27.195 GHz in 25 MHz steps steps SNIP/SFCG Recommended Center Frequencies: 25.60 GHz, 25.85 GHz, 26.10 GHz, 26.35 GHz, 26.60 GHz, 26.85 GHz, 27.10 GHz, 27.35 GHz

3-dB RF bandwidth Gain Flatness (peak) (note 2) Gain Slope (note 2) Phase nonlinearity (applies for all
types of phase nonlinearities) (peak) (note 2)

240 MHz (note 3) 0.8 dB over 80 MHz 0.14 dB/MHz over 80 MHz 16.5 over 80 MHz
> 0.57 dB/dB

650 MHz 0.8 dB over 230 MHz 0.14 dB/MHz over 230 MHz 16.5 over 230 MHz
> 0.57 dB/dB

AM/AM (note 2) AM/PM (note 2) Spurious PM (note 2) In-band spurious outputs (note 2)
Total Individual

7/dB 2.24 rms

7/dB (for data rates > 300 Mbps) 2.24 rms

27 dBc 40 dBc 1% (within 3-dB RF bandwidth)

27 dBc 40 dBc 1% (within bandwidth) 4.3 rms 4.6 rms 3.4 rms NA 2.0 rms 3-dB RF

Incidental AM (peak) (note 2) Phase noise (note 2) 1 Hz to 10 Hz 10 Hz to 100 Hz 100 Hz to 1 kHz 1 kHz to 150 MHz 1 kHz to 400 MHz Additional TDRS Ground Segment IF Characteristics: IF center frequency Output level Output VSWR

4.3 rms 4.6 rms 4.6 rms 2.1 rms NA

370 MHz -15 dBm 3 dB

1.2 GHz -15 dBm 3 dB

1.3:1 into 50 load, 80 MHz 1.3:1 into 50 load, 230 MHz from center frequency from center frequency

Revision 9

8-35

450-SNUG

Table 8-11. TDRS KaSAR 225 MHz and 650 MHz IF Service Spacecraft and Ground Segment Channel Characteristics (contd)
Notes: 1. The customer should schedule the TDRS receive center frequency setting closest to the customer transmit frequency, where the TDRS receive center frequency will be translated to the center of the IF bandwidth. The signal and carrier frequency will be constrained such that the first null of the spectrum falls between 25.25 and 27.50 GHz. The KaSAR only supports non-coherent frequencies. The KaSAR IF service supports only one Ka frequency through one TDRS at a time. These frequencies do not include the effects of frequency uncertainty and Doppler shift. The KaSAR IF service is not required to provide a Doppler-corrected IF output signal. The customer provided receiver needs to handle frequency uncertainty and Doppler. 2. Constraint parameters are contributions from the TDRS F8-F10 spacecraft and the SN ground segment to the IF interface. Not included in these aggregate distortion amounts are TDRS F8-F10 spacecraft gain flatness, linear and parabolic allowances, and phase nonlinearity parabolic and cubic allowances as described in 405-TDRS-RP-SY-001. Customer and receiver signal characteristics need to be considered to determine the end-to-end performance. Please contact GSFC Code 450 for further information. 3. The 3 dB RF bandwidth is larger than the specified 225 MHz bandwidth value specified in Table 8-7. This value has validated through spacecraft and ground terminal measurements, but may not be applicable to future TDRS.

8.3.6.2 Potential Signal Parameters for IF Service As discussed earlier, this is not an end-to-end service so a set of well defined customer signal parameters is not available. This section describes potential signal characteristics and expected performance through the TDRS F8-F10 spacecraft and SN ground segment. The KaSA 225 MHz return IF service is not currently automated; however, automation of this service is being considered for implementation. The KaSA 650 MHz return IF service is automated. SN IF services are available to customers on a case-by-case basis. Customers should contact Code 450 if they are interested in this service to determine expected performance for their specific signal characteristics and receiver. Potential TDRS 225 MHz and 650 MHz KaSA return service signal configurations are provided in Table 8-12. 8.3.6.3 Potential Signal Performance for IF Service The performance of the IF link is greatly dependent on the customer provided receiver. Typically, the SNUG specifies performance at BER of 10-5; BERs better than 10-5 may be possible for the IF service. NOTE: The expected performance is based upon simulation results only and has not been verified by testing. Data rates and coding techniques should be carefully considered and coordinated with GSFC Code 450 to achieve desired BER.

Revision 9

8-36

450-SNUG

Table 8-12. Potential TDRSS KaSA 225 MHz and 650 MHz IF Return Service Configurations (Customer interfaces with the SN at a 370 MHz IF for 225 MHz and 1.2 GHz IF for 650 MHz and Customer provides the Receiver)
Return IF Service Configuration (notes 1, 2) Potential Maximum Data Rates (225 MHz IF Service; expected operational in mid 2008) Potential Maximum Data Rates (650 MHz IF Service)

BPSK

Rate 1/2 convolutional coded Uncoded Rate 1/2 convolutional coded Uncoded (128,120)x(128,120) TPC (8176,7136) LDPCC (1024,2048) LDPCC (128,120)x(128,120) TPC

See Table 8-6 See Table 8-6 See Table 8-6 See Table 8-6 400 Mbps (note 4) 400 Mbps (note 4) 200 Mbps 600 Mbps (note 4) 600 Mbps (note 4) 450 Mbps
Notes:

300 Mbps 400 Mbps 600 Mbps 800 Mbps 1.0 Gbps (note 3) 1.0 Gbps (note 3) Not Available 1.5 Gbps 1.5 Gbps 600 Mbps (note 5)

QPSK / SQPSK

8PSK

(8176,7136) LDPCC Uncoded

1. 2.

3. 4.

5.

All data rates assume NRZ data format. These service configurations and maximum data rates were based upon simulation results only and have not been verified by testing. Other data rates and modulation schemes may be possible. Please contact GSFC Code 450 for further information. For the 650 MHz IF service, data rates up to 1.2 Gbps may be possible for QPSK/SQPSK modulation with either TPC or LDPCC. Please contact GSFC Code 450 for further information. For the 225 MHz IF service, data rates up to 410 Mbps may be possible for QPSK/SQPSK modulation with either TPC or (8176,7136) LDPCC. For the 225 MHz IF service, data rates up to 625 Mbps may be possible for 8PSK with either TPC or (8176,7136) LDPCC. Please contact GSFC Code 450 for further information. The data rate is limited by SGL downlink strength, not the TDRS channel.

All values in this section assume using a receiver with reasonable implementation loss. Table 8-13 provides expected, required Eb/No values for various data rates and modulation schemes for a 10-5 BER. Additionally, Table 8-13 also provides the theoretical Eb/No and implementation loss values for those modulation and coding schemes at 10-5 BER over a simple AWGN channel. Table 8-13 also provides a potential minimum required Prec (dBW) equation for various data rates, coding and modulation schemes through the IF service assuming these expected, required Eb/No values, which were based upon simulation results and have not been verified by testing. NOTE: Autotracking is not provided for the IF service.

Revision 9

8-37

450-SNUG

Table 8-13. Potential KaSAR IF Service Implementation Loss and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques Return IF Service Configuration (note 4) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 4)
9.0 dB 16.9 dB 9.0 dB 7.5 dB 16.9 dB 15.4 dB 14.0 dB 7.9 dB 7.0 dB 6.4 dB 8.3 dB 7.4 dB 6.8 dB 4.4 dB 3.9 dB 9.9 dB (note 2)

Revision 9

Theoretical Required Eb/No (note 1)

4.5 dB (note 2) 9.9 dB (note 2) 4.5 dB (note 2)

Implementation Required P (K) at rec Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 4) BER (LEO Program Track) (note 4)
4.5 dB 7.0 dB 4.5 dB 3 dB 7.0 dB 5.5 dB 4.1 dB 4.0 dB 3.1 dB 2.5 dB 3.9 dB 3.0 dB 2.4 dB -242.9 + 10 log (dr) -233.7 + 10 log (dr) -242.7 + 10 log (dr) -244.4+ 10 log (dr) -231.5 + 10 log (dr) -235.1 + 10 log (dr) -237.3 + 10 log (dr) -243.8 + 10 log (dr) -244.9 + 10 log (dr) -245.5 + 10 log (dr) -243.3 + 10 log (dr) -244.4 + 10 log (dr) -245.1 + 10 log (dr)

BPSK (650 MHz IF service; note 5) QPSK/ SQPSK MHz service) (650 IF

Rate 1/2 coded Uncoded Rate 1/2 coded Uncoded

convolutional

300 Mbps 400 Mbps

convolutional

600 Mbps < 450 Mbps 800 Mbps 600 Mbps

8-38
(128,120)x(128,120) TPC (note 3) (8176,7136) LDPCC (note 3)

< 450 Mbps 1.0 Gbps 800 Mbps < 600 Mbps 1.0 Gbps 800 Mbps < 600 Mbps

450-SNUG

Revision 9

Table 8-13. Potential KaSAR IF Service Implementation Loss and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques (contd) Return IF Service Configuration (note 4) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 4)
10.8 dB 10.1 dB 9.4 dB 12.0 dB 11.1 dB 10.0 dB 18.0 dB 7.9 dB 6.6 dB 6.1 dB 8.4 dB 7.3 dB 6.4 dB 4.0 dB 3.6 dB 1.7 dB 4.4 dB 3.9 dB 13.1 dB 7.3 dB 6.9 dB

Theoretical Required Eb/No (note 1)

Implementation Required P (K) at rec Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 4) BER (LEO Program Track) (note 4)
3.9 dB 3.2 dB 2.5 dB 4.7 dB 3.8 dB 2.7 dB 4.9 dB 4.0 dB 2.7 dB 2.2 dB 4.0 dB 2.9 dB 2.0 dB 2.3 dB 1.9 dB -240.0 + 10 log (dr) -241.1 + 10 log (dr) -242.1 + 10 log (dr) -238.2 + 10 log (dr) -239.9 + 10 log (dr) -241.4 + 10 log (dr) -230.6 + 10 log (dr) -243.9 + 10 log (dr) -245.3 + 10 log (dr) -245.9 + 10 log (dr) -243.3 + 10 log (dr) -244.6 + 10 log (dr) -245.6 + 10 log (dr) -248.0 + 10 log (dr) -248.4 + 10 log (dr)

8PSK MHz service)

(650 IF

(128,120)x(128,120) TPC

1.5 Gbps 1.2 Gbps < 1 Gbps

(8176,7136) LDPCC

1.5 Gbps 1.2 Gbps < 1 Gbps

Uncoded (650 MHz IF service) QPSK/ SQPSK (225 MHz IF service; expected to be operational in mid 2008) (128,120)x(128,120) TPC (note 6)

< 600 Mbps 400 Mbps 300 Mbps < 200 Mbps

8-39
450-SNUG

(8176,7136) LDPCC (note 6)

400 Mbps 300 Mbps < 200 Mbps

(1024,2048) LDPCC

200 Mbps < 150 Mbps

Revision 9

Table 8-13. Potential KaSAR IF Service Implementation Loss and LEO Program Track Required Prec Equations for Various Data Rates Using Different Modulation and Coding Techniques (contd) Return IF Service Configuration (note 4) Data Rates Required Eb/No at input to receiver for 10-5 BER (notes 1, 4)
10.5 dB 9.4 dB 8.8 dB 11.5 dB 10 dB 9.5 dB 17.3 dB Notes: 1. Unless otherwise noted, all values are based upon a customer transmitter power amplifier operating point of 1 dB OBO, i.e., AM/PM = 12/dB and AM/AM = 0.47 dB/dB. Values assume baseband equalization used. Values do not include margin. All values are given for a receiver with reasonable loss. Better performance may be achievable with a better power amplifier and/or filters, etc. 2. Includes effects of NRZ-M or NRZ-S coding. 3. For the 650 MHz IF service, data rates up to 1.2 Gbps may be possible for QPSK/SQPSK modulation with either TPC or (8176,7136) LDPCC. Please contact GSFC Code 450 for further information. 4. These service configurations and maximum data rates were based upon simulation results only and have not been verified by testing. Other data rates and modulation schemes may be possible. Please contact GSFC Code 450 for further information. 5. For BPSK, QPSK, SQPSK with uncoded or rate convolutional coded through the 225 MHz bandwidth, see Table 8-7 for expected performance. 6. For the 225 MHz IF service, data rates up to 410 Mbps may be possible for QPSK/SQPSK modulation with either TPC or (8176,7136) LDPCC. For the 225 MHz IF service, data rates up to 625 Mbps may be possible for 8PSK with either TPC or (8176,7136) LDPCC. Please contact GSFC Code 450 for further information. 7. For the 650 MHz, the required P was determined for support through the KaSAR dedicated downlink to the WSC IF interface point. For the 225 MHz, the required P
rec

Theoretical Required Eb/No (note 1)

Implementation Required P (K) at rec Loss Amounts TDRS (dBW) for a 10-5 (notes 1, 4) BER (LEO Program Track) (note 4)
3.6 dB -240.7 + 10 log (dr) -242.1 + 10 log (dr) -242.9 + 10 log (dr) -239.4 + 10 log (dr) -241.4 + 10 log (dr) -242.1 + 10 log (dr) -230.1 + 10 log (dr) 2.5 dB 1.9 dB 4.2 dB

8PSK (225 MHz IF service; expected to be operational in mid 2008)

(128,120)x(128,120) TPC (note 6)

600 Mbps 500 Mbps < 400 Mbps

6.9 dB

(8176,7136) LDPCC (note 6)

600 Mbps 500 Mbps < 400 Mbps

7.3 dB

2.7 dB 2.2 dB

Uncoded

< 450 Mbps

13.1 dB

4.2 dB

8-40
450-SNUG

was determined for support through the KaSAR composite downlink to the WSC IF interface point.

rec

Section 9. Tracking and Clock Calibration Services

9.1

General

The SN can provide customer platform tracking and clock calibration services for MA, SSA (including cross-support), and KuSA telecommunications services. The SN does not provide tracking or clock calibration services for KaSA customers or DAS customers. NOTE: For tracking services, the related forward and/or return services must be scheduled for the entire duration of the tracking service and must be described in the same SHO. Tracking data is delivered in Tracking Data Messages (TDMs) from the SN ground terminal to the FDF, the format of which is provided in the Interface Control Document (ICD) Between the Network Control Center (NCC)/Flight Dynamics Facility (FDF) and the White Sands Complex (WSC), 530ICD-NCC-FDF/WSC. The SN provides measurements that help customers: Track their platform (range and Doppler) Calibrate their platforms clock (time transfer and return channel time delay)

Each of the measurements is briefly described below: a. Range The ground terminal measures range during DG1 mode 1 and 3 operations by counting the time elapsed between the transmission of a PN code epoch on the forward link and the reception of the turned-around PN code epoch on the return link. Only two-way range measurements are provided. b. Doppler GT measured Doppler is the frequency difference between the carrier and a reference frequency. One-way forward Doppler is the frequency difference between the fixed frequency forward link carrier as defined in the SHO, where Doppler compensation must be disabled, and a reference frequency on the customer platform. The customer platform is required to perform onboard compensation for Doppler to acquire the signal. For a return link with coherent operations and two-way Doppler measurement required, the reference frequency is the forward link customer platform receiver frequency provided to WSC in the SHO; for one-way return Doppler, it is the return link customer platform transmit frequency defined in the SHO. The Doppler count

Revision 9

9-1

450-SNUG

at the ground terminal accumulates non-destructivelythat is, the counter is not reset during the service. c. Time transfer Time transfer measurements are used by MOCs to calibrate their platforms clock. These measurements provide the customer MOC the ability to determine the time difference between the on-board platform clock and the UTC. Only two-way time transfer measurements are provided by the ground terminal, and only with coherent services. The customer platform must also provide a time receipt of the PN epoch onboard.

d. Return channel time delay (RCTD) RCTD measurements, in conjunction with other data delays, enable the MOCs to calculate the time onboard their platform. RCTD measures the time delay from the ground terminal antenna input to the ground terminal baseband output (at the point of time tagging within the data transport) for each I and Q channel in the return link. Unlike time transfer, RCTD can be measured with either a coherent or noncoherent service. Table 9-1 describes the tracking services available for each return link data group and mode. NOTE: Cross-support service consists of either MA forward with SSA return, or SSA forward with MA return. Table 9-1. Tracking Services by Data Group and Mode
Data Group and Mode (note 4) Mode 1 DG1 Mode 2 Mode 3 (note 3) DG2 (note 3) 1. 2. 3. 4. 5. 6. Coherent Noncoherent Doppler Measurement 1-Way Return 1-Way Forward (note 6) 2-Way (note 1) Range Measurement (note 2) Time Transfer Measurement (note 2) Return Channel Time Delay (note 5)

Notes: Requires that the customer transponder coherently turns around the received forward service carrier. Requires that the customer transponder coherently turns around the PN code epoch received in the forward service range channel. MAR DG1 mode 3 and DG2 services are only available through TDRSs F8-F10. Tracking services are not available for KaSA service. Return channel time delay is available for symbol rates 6 Msps for NRZ and 3 Msps for biphase formats (S-band DG2 only) per I or Q channel. Requires customer receiver capability to measure Doppler on forward carrier. Additionally, Doppler compensation must be disabled.

Revision 9

9-2

450-SNUG

9.2

Range Measurement a. General. Range measurement is available when the customer platform transmits a PN code on the return link with the epoch synchronized to the received forward link PN code epoch of the range channel transmitted from the ground terminal (i.e., DG1 mode 1 or DG1 mode 3 service configurations). The TDRSS tracking service will be capable of providing accurate and independent (sample-to-sample) range data as indicated in paragraphs b through i with customer platform signal Doppler frequencies and Doppler rates within the ranges listed in Table 9-2. Table 9-2. Signal Doppler Maxima
Service MA SSA KuSA Doppler Frequency 230 kHz 230 kHz 1.6 MHz Doppler Rate 1.5 kHz/sec 1.5 kHz/sec 10.5 kHz/sec

b. Range Measurement Random Error. The random error contribution to range measurement resulting from the TDRSS will not exceed the values listed in Table 9-3 for Prec values consistent with the minimum Prec for BER for the particular service. Table 9-3. TDRSS Tracking Service Range Measurement Error
Data Rate < 1000 bps 1000 bps Maximum Range Error 20 nsec (rms) 10 nsec (rms)

Note: All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates.

c.

Range Measurement Systematic Error. The systematic range error contribution from a TDRS will be less than +35 nsec based on pre-launch measurement and predicted on-orbit performance. The systematic range error contribution from the ground terminal will be less than +30 nsec.

d. Range Granularity. The range granularity, which is the smallest discrete output of the ground terminal receiver, is 1 nsec.

Revision 9

9-3

450-SNUG

e. Range Ambiguity Interval. The minimum unambiguous range measurement is equal to the period (nominally 85 msec or 25,500 km which is obtained by multiplying the code period, 85 msec, by the speed of light, ~300,000 km/sec) of the TDRSS forward service range channel PN code. f. TDRSS Delay Compensation. The ground terminal ranging system will compensate the range measurement for the known absolute delays internal to the TDRSS (WSC/GRGT and TDRS).

g. Data Sampling. Range measurement data is sampled on-time to within +1 sec of the ground terminal epoch times. "On-time" refers to that portion (leading or trailing edge) of the timing signal that is synchronized with UTC at the output of the ground terminal timing system and is used for sampling the measurement data. h. Timing Accuracy. The ground terminal epoch times for range measurement will have a systematic error of less than +5 sec of UTC. The ground terminal epoch times will be traceable to within +100 nsec of UTC time. i. Sample Intervals. The sample intervals between range measurement data can be selectable at intervals of 1, 5, 10, 60, and 300 sec/sample. Doppler Measurement a. General. The Doppler frequency is the difference between the recovered carrier frequency and the reference frequency. Two-way Doppler measurement is available when the customer platform transmits a return link carrier frequency that is coherently related to the received forward link carrier frequency (i.e., DG1 mode 1, DG1 mode 3, or DG2 coherent service configurations). One-way return Doppler measurement is available for signals with a noncoherent return link carrier frequency. The TDRSS tracking service will be capable of providing Doppler information with the accuracy and characteristics specified in paragraphs b through g for customer platform signal Doppler frequencies and Doppler rates within the ranges listed in Table 9-2. The Doppler signal is biased and processed so that a signal of 240. MHz + M fd is obtained, where M=100 for Ku-band, M=1000 for S-band, and fd is the Doppler. The Doppler count at the ground terminal is non-destructive with a ground terminal capability of maintaining a continuous count for a minimum of 50 minutes at maximum Doppler rate. The counter is set to 0 at least 1 second before the start of the tracking service and will not be reset during a service. One-way forward Doppler can be measured onboard the customer platform from any forward link carrier (coherent or noncoherent). The characteristics of the observation depend on the customer implementation.

9.3

Revision 9

9-4

450-SNUG

NOTE: The definition of 240. MHz is 240.0000 MHz, where the magnitude of the fraction portion is the accuracy of the ground terminal frequency standard. b. One-way Forward Doppler. One way Doppler data can be measured on any uncompensated forward link communications signal from the Space Network; a scheduled tracking service is not necessary for this data type. The measurement is valid in any: mode (coherent or non-coherent), data modulation (i.e., spread spectrum or unspread), and for any frequency forward link. The only requirement is that the SN forward communication service must be scheduled with Doppler Compensation Inhibited (DCI) for the entire service and the user is responsible for compensating for the expected Doppler of the signal for initial onboard acquisition. In order to measure the Doppler, a user spacecraft needs the software in the user receiver to measure the frequency offset of the incoming receive signal, the basis for which is nominally found in the carrier tracking loop of the receiver. The stability of the reference oscillator for the receiver is one factor in determining the accuracy of the orbital state estimated using the one-way forward Doppler data. Generally, a Temperature Compensated Crystal Oscillator (TCXO) reference with stability of 10-6 over 1-10 seconds can, at a minimum, provide a state solution accurate enough to be used for signal acquisition and some science missions. An Oven Controlled Oscillator (OCXO) reference with stability of 1-10 over 1-10 seconds can provide a state solution that is accurate to the 5 to 40 meter level (RSS, 3-sigma). Please contact NASA/GSFC Flight Dynamics (Code 595) for additional information. c. Two-way and One-Way Return Doppler Measurement rms Phase Noise. The rms phase noise contribution to Doppler tracking, resulting from the TDRSS, will not exceed the values given in Table 9-4 for Prec values consistent with the minimum Prec for BER for the particular service.

Revision 9

9-5

450-SNUG

Table 9-4. TDRSS Tracking Service Doppler Measurement rms Phase Noise
ADR (note 1) (bps) 500 > 500 1000 > 1000 Maximum Phase Noise (note 2) (radians, rms) 0.4 0.3 0.3 0.2

Notes: 1. All data rate values (and notes which modify these values, based upon specific signal format and encoding restrictions) are to be interpreted as data bit rates, and not as data symbol rates. 2. The error values are in addition to the uncertainty introduced to the Doppler frequency measurement by the allowed 25 nsec uncertainty of the 1second measurement time reference.

d. Reference Frequency. 1. For two-way Doppler measurements, the reference frequency for the ground terminal Doppler extraction process is coherently related to the forward service transmit frequency consistent with the appropriate frequency turnaround ratio (240/221 for MA and SSA or 1600/1469 for KuSA), not accounting for the relative motion between the TDRS and the ground terminals. The TDRS forward transmit frequency defined in the SHO is an integral multiple of 10 Hz. During Doppler compensation inhibit, the TDRS forward service transmit frequency is an integral multiple of 221 for S-band services or 146.9 for Ku-band services. The reference frequency is therefore given by:
240 for MA and SSA f ref = f T 221 1600 for KuSA f ref = f T 1469 where fT is the TDRS forward service transmit frequency. Two-way Doppler measurements can be provided when Doppler compensation is enabled (DCE) or Doppler compensation is inhibited (DCI). When Doppler compensation is enabled, the forward carrier frequency and PN chip rate are adjusted at ground terminal so that the customer platform receives its nominal frequency and chip rate. When Doppler compensation is inhibited (accomplished by the ground terminal only when a Doppler compensation inhibit request is received via an OPM from the NCCDS or if Doppler inhibit is scheduled by the SHO), the TDRS forward service transmit frequency is held constant.

Revision 9

9-6

450-SNUG

2.

For one-way return Doppler measurements, the reference frequency for the ground terminal Doppler extractor will be the customer platform transmit frequency as defined in the SHO to the accuracy of the ground terminal frequency standard. For one-way forward Doppler measurements, the reference frequency for the spacecraft Doppler determination will be the ground terminal forward transmit frequency as defined in the customer platform SHO.

3.

e. Two-way and One-Way Return Doppler Granularity. Doppler granularities of 1 -2 x 10-3 cycles for MA and SSA or 1 x 10 cycles for KuSA cycle are provided. f. Two-way and One-Way Return Data Sampling. Doppler measurement data is sampled on-time to within +25 nsec of the ground terminal epoch times. "On-time" refers to that portion (leading or trailing edge) of the timing signal that is synchronized with UTC at the output of the ground terminal timing system and is used for sampling the measurement data.

g. Two-way and One-Way Return Timing Accuracy. The ground terminal epoch times for Doppler measurement will have a systematic error of less than +5 sec of UTC. The ground terminal epoch times will be traceable to within +100 nsec of UTC time. h. Two-way and One-Way Return Sample Intervals. The sample intervals between Doppler measurement data can be selectable at intervals of 1, 5, 10, 60, and 300 sec/sample. 9.4 Time Transfer Measurement a. General. Time transfer measurements can be used by MOCs to calibrate their platforms clock. Time transfer measurement is available when the customer platform transmits a PN code on the return link with the epoch synchronized to the received forward link PN code epoch of the range channel (i.e., DG1 mode 1 or DG1 mode 3 service configurations). The TDRSS two-way tracking service will be capable of providing time transfer data as indicated in paragraphs b through g with customer platform signal Doppler frequencies and Doppler rates within the ranges listed in Table 9-2. Each time transfer measurement consists of two elapsed times 1. The time elapsed between a reference 1 second time mark and the first forward PN epoch occurring after that reference time. 2. The time elapsed between that same reference time mark and the first return PN epoch received after the first forward PN epoch after that same reference time mark. and two corrections that account for the transit times through the SGLT. These corrections are estimates of the following times:

Revision 9

9-7

450-SNUG

1. Delay from generation of the forward PN epoch until it departs the ground terminal antenna. 2. Time delay between when a return PN epoch arrives at the ground terminal antenna and it reaches the point where a time tag is applied. Time transfer measurements are requested in the SHO. After the scheduled service ends, the NCCDS provides the measurements to the customer MOC. NOTE: Time transfer measurements can be used by customer MOCs for customer platform clock calibration. GSFC Code 450 has developed the User Spacecraft Clock Calibration System (USCCS) Users Guide (http://scp.gsfc.nasa.gov/tdrss/usccs.pdf) and will provide assistance, as necessary. This method can provide improved accuracy over RCTD measurements. USCCS support is not currently available from the GRGT. b. Time Transfer Measurement rms Error. The jitter in the TDRSS time transfer measurement will be within +25 nsec. c. Time Transfer Measurement Systematic Error. Systematic two-way time transfer error contributions will be less than +35 nsec from a TDRS and less than +30 nsec from the SN ground terminal.

d. Time Transfer Measurement Granularity. The elapsed time between the reference time epoch and the next outgoing forward link PN epoch pulse will have a granularity of 200 nsec. The elapsed time between the reference time epoch and the next arrival of the return link PN epoch pulse will have a granularity of 200 nsec. e. TDRSS Delay Compensation. The WSC time transfer system provides delay information internal to the TDRSS (WSC/GRGT and TDRS) that enables the MOC to compensate for those delays in the time transfer measurements. f. Timing Accuracy. The ground terminal epoch times for time transfer measurement will have a systematic error of less than +5 sec of UTC. The ground terminal epoch times will be traceable to within +100 nsec of UTC time. The interval between time transfer measurements is

g. Sample Interval. 1 second. 9.5

Return Channel Time Delay (RCTD) Measurement a. General. RCTD measurements are available to any customer platform that transmits a return link signal, coherent or noncoherent. The WSC measures RCTD for each I and Q channel in the return link. The reported value is the

Revision 9

9-8

450-SNUG

time delay from the range-to-zero set reference point in the WSC antenna input to the WSC baseband output reference point, where a UTC time tag is placed on the data stream. RCTD measurements are not currently available from the GRGT. NOTE: RCTD measurements are available for 4800-bit data block customers. For non-4800-bit data block customers, RCTD measurements are currently not available. RCTD, in conjunction with other data delays, allows the customer MOC to calculate the time onboard their platform to within about 30 msec, typically. NOTE: For details on how RCTD measurements can be used by customer MOCs to calculate the time onboard their platform, see Return Data Delay at http://scp.gsfc.nasa.gov/tdrss/return_data_delay.htm. RCTD measurements are requested in the SHO. After the scheduled service ends, the NCCDS provides the measurements to the customer MOC. b. Measurement Times. The WSC measures RCTD at the following times: 1. Immediately before the scheduled service begins. 2. Whenever equipment or services are reconfigured during the service period. Multiple measurements will be made if there are multiple reconfigurations. 3. Immediately after the scheduled service ends. c. Maximum Symbol Rate. Measurements are provided for symbol rates 6 Msps for NRZ and 3 Msps for biphase formats (S-band DG2 only) per I or Q channel. Data rates < 250 kbps: 25% of the data bit period. Data rates 250 kbps: 1 sec. (The maximum symbol rate is defined in c above.) e. Measurement Resolution. microseconds. RCTD measurements are provided in units of

d. Measurement Accuracy. RCTD measurements have the following accuracies:

Revision 9

9-9

450-SNUG

This page intentionally left blank.

Revision 9

9-10

450-SNUG

Section 10. SN Operations for TDRSS Services

10.1 10.1.1

Purpose and Scope Purpose

This Section provides a general description of scheduling capabilities, performance monitoring capabilities, and operations interfaces available to SN customers; and discusses how a customer must interface with the SN to obtain TDRSS support. All SN elements have particular roles to fulfill in support of SN operations (refer to Section 2, paragraph 2.3 for an SN element description). The most basic of these responsibilities rest with the customer MOCs, NCCDS, the GTs, and FDF. Although the MOCs and FDF are not part of the SN, the SN's interactions with the MOCs and FDF are an integral part of SN operations. Table 10-1 presents the basic responsibilities and functions provided by the MOC, NCCDS, the GTs, and FDF. NOTE: The NCCDS issues Network Advisory Messages (NAMs) to provide up-to-date information on network conditions and constraints. These messages are accessable via the NCCDS active NAM web site at https://cds02.gsfc.nasa.gov/. GSFC Code 450 uses the NAMs as a means of letting customers know of any performance constraints associated with TDRS spacecraft. Additionally, TDRS constellation information can be found in the TDRS Constellation Management Plan, 452-PLAN0002. 10.1.2 Scope

Information covered in this section includes: a. Scheduling operations (see paragraph 10.2). b. Real-time operations (see paragraph 10.3). c. 10.1.3 Customer platform emergency operations (see paragraph 10.4). SN Message Terminology

Different terminology is used to describe the messages exchanged between the NCCDS and the TDRSS ground terminals (GT) than is used to describe the equivalent messages exchanged between the NCCDS and the MOC. Table 10-2 provides an overview of some of the SN message terminology used throughout this section.

Revision 9

10-1

450-SNUG

Revision 9 10-2 450-SNUG

Table 10-1. MOC, NCCDS and TDRSS Ground Terminals Responsibilities and Functions
MOC (note 1) Focal point for customer platform on orbit operations Provide interface for experiment operations requirements Support experiment scientific data analysis and planning Customer platform evaluation and operations Project operations planning, analysis, and scheduling Health and status maintenance of customer platform and experiments Coordinate computing support Coordinate support requiring multiple customer ground facilities Customer platform command generation Customer platform telemetry processing Customer platform attitude data handling Payload operations and control Experiment sensory analysis and control NCCDS (note 1) Allocate and regulate SN resources Control SN/customer interface Support scheduling SN testing and simulation SN performance monitoring Performance data distribution SN status monitoring Distribution of scheduling and acquisition data Documentation control SN planning Acquisition and tracking control support Data base management Service accountability SN fault isolation Ground Terminals (note 1) Allocate and control TDRSS services and equipment Provide customer platform telemetry to customer specified destinations (MOC, Data Processing Facility, etc.) via NISN Provide customer platform tracking data to FDF (note 2) Accept customer spacecraft command data from the MOC via NISN Coordinate administrative operations TDRSS performance monitoring Maintain TDRS-to-customer platform communications TDRS health and status operations SN schedule data processing TDRS TT&C operations End-to-End test services FDF (note 1) Maintain BRTS system Process BRTS data Generate ground trace predictions Process customer tracking data Generate and transmit real-time state vectors Generate customer orbit and ephemeris data Generate TDRS orbit and ephemeris data from BRTS data Receive and process Tracking Data Messages (TDMs) from the GT Perform trajectory support ELVs, STS, and ISS Perform mission and trajectory design, and orbit maneuver planning Evaluate, calibrate, and validate tracking data for the SN, GN, and other satellites supported by FDF Maintain NASA Directory of Station Locations and environmental files for operational use by FDF and supported users Notes: 1. 2. There is no horizontal correlation among these lists of MOC, NCCDS, GT, and FDF responsibilities and functions. The four lists are independent. In general, raw tracking data is not provided to the customer specified destinations.

Table 10-2. Overview of SN Message Terminology

Purpose Transmit a schedule message Message Name User Schedule Message (USM) Schedule Order (SHO) Ground Control Message Request (GCMR) Operations Message (OPM) Operations Message (OPM) Ground Control Message (GCM) Operations Data Message (ODM) User Performance Data (UPD) From NCCDS NCCDS MOC NCCDS GTs NCCDS GTs NCCDS To MOC GTs NCCDS GTs NCCDS MOC NCCDS MOC

Real-time service reconfiguration request

Real-time service reconfiguration disposition/status

Real-time performance data

10.2 10.2.1

SN Scheduling Operations General

Scheduling operations are the step-by-step interactions of MOCs and particular SN elements that collectively result in the instructions and information required to direct the SN. This interaction enables the SN to produce the communications and data processing support necessary to conduct real-time customer platform operations. 10.2.2 10.2.2.1 Database Setup General

The initial step of the scheduling process occurs during the mission planning phase (see paragraph 10.2.3.2). The prospective customer projects supply the NCCDS with information needed to fulfill mission support requirements. The customer information is maintained in the NCCDS database. The NCCDS is the system that schedules SN support. Customer-specific information in the NCCDS database includes:

Revision 9

10-3

450-SNUG

a. Customer Platform Parameters. b. Service types. c. Service Parameter Records. d. NISN Parameters. e. Schedule Distribution List. f. Support Identification (SUPIDEN) and TDRS. g. Customer Authorization. h. Data Quality Monitoring (DQM) Setup Parameters. i. j. Service Specification Codes (SSCs). Prototype Events. Customer Platform Parameters

10.2.2.2

For each customer, the customer platform parameters must be specified before any other data can be specified. The customer platform parameters include the customers Support Identification Code (SIC), Vehicle Identification Code (VIC), Vehicle Identification (VID), and Pseudo-Noise (PN) codes. 10.2.2.3 Service Types

For each customer, the types of service that can be scheduled for that customer must be identified. The service types must be determined before the Service Parameter Records can be specified. Service types include MAF (via F1-F7), SMAF (via F8-F10), SSAF, KuSAF, KaSAF (via F8-F10), MAR (via F1-F7), SMAR (via F8-10), SSAR, KuSAR, KaSAR (via F8-F10), tracking, and end-to-end test services. 10.2.2.4 Service Parameter Records

For each service type for each customer, the Service Parameter Records define how each schedulable parameter is to be validated as the SSCs for that service type and customer are entered into the NCCDS database. The Service Parameter Records comprise similar parameters as the SSC definitions described in Appendix A of the Interface Control Document Between the Space Network and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC). Appendix A shows the range, or set, of values that is generally valid in terms of the NCCDS/GT interface. In contrast, the Service Parameter Records can be customized to specify ranges, or sets, of values unique to each customer. 10.2.2.5 NISN Parameters

For each customer, the NISN parameters specify the settings of certain parameters used in the schedules transmitted to the GTs. These parameters are used for purposes

Revision 9

10-4

450-SNUG

such as configuring the MDM system and do not appear in the User Scheduling Messages (USMs). 10.2.2.6 Schedule Distribution List

For each customer, the Schedule Distribution List specifies the destinations to which the NCCDS will transmit fixed USMs. One of these destinations will also be specified as the customers primary logical destination and will receive Schedule Result Messages (SRMs) transmitted in response to schedule requests. Any or all of these destinations may also be specified to receive flexible USMs. 10.2.2.7 SUPIDEN and TDRS

For each customer, the NCCDS database contains a list of valid SUPIDENs. For each valid SUPIDEN, the NCCDS database contains a list of valid TDRSs. 10.2.2.8 Customer Authorization

For each customer, the NCCDS database contains a list of valid customer IDs and associated passwords. 10.2.2.9 DQM Setup Parameters

For a combination of SIC, return service Data Stream ID and data rate, the NCCDS database may contain a set of DQM Setup Parameters. The NCCDS uses the DQM Setup Parameters in the construction of SHOs transmitted to the GT. They do not appear in USMs. 10.2.2.10 Service Specification Codes

The format of the customer data that is contained in a SSC is described in Appendix A of the Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC). For each service type to be scheduled, each customer must have at least one SSC specified in the NCCDS database. For each customer, each SSC specifies a set of initial parameter values for the applicable service type. When SSCs are entered into the database, they are validated according to the Service Parameters Records. 10.2.2.11 Prototype Events

After the SSCs have been established for a customer, it is then possible to define prototype events for that customer. Each prototype event specifies a set of SSCs with associated service durations, service start time offsets, and service-level flexibility parameters. Prototype events are optional. It is possible to schedule SN events without the use of prototype events. However, prototype events can simplify scheduling for customers that repeatedly schedule events with the same structure (i.e., the same set of services with the same durations, relative start times, and flexibility options).

Revision 9

10-5

450-SNUG

10.2.3 10.2.3.1

NCCDS Scheduling General

The NCCDS is responsible for operations management and scheduling SN resources. Scheduling activities consist of the mission planning phase, event scheduling, forecast scheduling, active schedules, scheduling conflicts, and support scheduling. 10.2.3.2 Mission Planning Phase

During the mission planning phase, SN and MOC personnel acquaint each other with the kind of data the MOC must transfer between the SN and the customer platform and with the services the NCCDS can make available to the MOC. During this period, the TDRSS service configurations needed to meet the various customer data transfer requirements are defined. Each of these configurations is identified by an SSC used in scheduling SN service. 10.2.3.3 Event Scheduling

a. All customer platform operations supported by the SN are scheduled through the NCCDS. The NCCDS-generated events schedule is constructed from specific schedule requests submitted by the MOCs. These requests may be either event additions, deletions or replacements. Refer to Table 10-3 for a description of the schedule request types. b. If the request is for a schedule addition, its addition to the schedule is contingent upon the availability of the SN equipment required to support it. A MOC is responsible for ensuring its own customer platform-to-TDRS visibility prior to adding a schedule event. The MOC may do this directly by submitting schedule requests with start time tolerances that comply with customer platform-to-TDRS visibility requirements or indirectly by submitting TDRSS Scheduling Windows (TSWs) to the NCCDS and then submitting schedule requests that specify that they are to fit within these TSWs. Use of TSWs makes it feasible to submit schedule requests that specify TDRS flexibility and with start time tolerances that exceed a single TDRS view. Refer to paragraph 10.2.4.3 for more information on TSWs. c. There are several ways MOCs can increase the schedulability of their submitted requests. SARs submitted to the NCCDS by SN customers may specify time and/or resource flexibility (refer to Table 10-4). Use of scheduling flexibility increases the probability of successfully scheduling a request, and allows for more efficient use of SN resources.

Revision 9

10-6

450-SNUG

Table 10-3. Schedule Request Descriptions

Schedule Request Type Schedule Add Request (SAR) (message type 99, message class 10) Description Specifies an event to be added to the schedule in terms of: 1. Specific event start and stop times 2. Either a prototype event ID or one or more SSC IDs together with service-level timerelated information Alternate SAR (message type 99, message class 21) Schedule Delete Request (message type 99, message class 11) Schedule Replace Request (message type 99, message class 12) References either a SAR or another Alternate SAR to form a chain of requests. Specifies an event to be added to the schedule. Identifies an event to be deleted and does not include information such as SSCs Identifies an event to be deleted, and includes all of the information needed to add a new event

d. Event scheduling in the NCCDS complies with the SN scheduling ground rules as specified in paragraphs 2.2.2 and 2.2.3 of the Interface Control Document (ICD) Between the Network Control Center (NCC)/Flight Dynamics Facility (FDF) and the White Sands Complex (WSC), 530-ICD-NCC-FDF/WSC. Compliance with these ground rules ensures that the schedules generated by the NCCDS can be supported by the TDRSS. In particular, these ground rules ensure adequate time to configure a resource prior to its use. The actual time required to configure a service within an event varies depending on the resources allocated to the service. In general, the time scheduled by the NCCDS to configure a service is the longest time needed to configure any one of the resources allocated to the service. Additional rules also apply to event scheduling. Table 10-5 summarizes the SN scheduling ground rules with an emphasis on the ground rules that apply to time relationships. In general, individual schedule requests submitted by customers must comply with rules that apply to individual events or services while rules that apply to the relationships between events are beyond the control of individual customers. e. Event scheduling in the NCCDS is performed when processing modifications (add, replace and delete requests) to the active schedule and when generating the next forecast schedule. The NCCDS Scheduling Operator (SO) is responsible for monitoring and coordinating all scheduling activities within the active period. The NCCDS Forecast Analyst (FA), who is chiefly responsible for coordinating future scheduling requirements (forecast periods), assists the NCCDS SO in monitoring schedule-related database information, analyzing schedule resource problems, and coordinating alternative support solutions with MOCs.

Revision 9

10-7

450-SNUG

Revision 9

Table 10-4. Scheduling Flexibility Options

Scheduling Flexibility 1. The NCCDS scheduling engine will apply scheduling flexibility in the following order when attempting to schedule a SAR: Resource flexibility (if any) as specified by the SAR. This may include TDRS flexibility, SA antenna flexibility, and User Interface Channel flexibility. (note 1) Start time flexibility (if any) as specified by the SAR. This may include event start time flexibility and/or service start time flexibility. (note 2) Service duration flexibility (if any) as specified by the SAR. (note 3)

2. If a SAR cannot be scheduled after application of all of above flexibility, the NCCDS scheduling engine will attempt to schedule an Alternate SAR if the customer has submitted one that references the original SAR. An Alternate SAR has nearly the same format as a SAR, and can specify flexibility in the same way. Alternate SARs can reference SARs or other Alternate SARs. This feature can be used to form a chain of requests which will be processed in sequence until one of the requests is successfully scheduled or until all have been declined.

10-8 450-SNUG

3.

If a SAR and all linked Alternate SARs (if any) are declined and the SAR specified Wait List type processing, the SAR and all of its alternates will be placed on the Wait List. The customer may also submit a Wait List Request after receiving notice that the SAR was declined. (note 4) Notes:

1. Flexibility always applies to the NCCDSs selection of MAR and SMAR links. The customer does not have the option of specifying a particular MAR or SMAR link. 2. Allows specification of plus and minus tolerances on event and/or service start time. 3. Allows reduction of service duration within specified limits; however, duration will never be less than the minimum requested. 4. The Wait List is processed every time the Active Schedule is modified.

Table 10-5. SN Scheduling Event Time Ground Rules

Applicable Event, Service or Resource Event Duration cannot be more than 24 hours All services in an event are scheduled on the same TDRS and the TDRS must be used continuously from the beginning of the event to the end of the event. There can be no time period within the event in which a service is not scheduled. Except for SSAR combining services, all SA services in an event are scheduled on the same SA antenna SSAR combining services actually use both SA antennas, but message formats will show that SA1 is used. All other SA services in an event containing a SSAR combining services must use SA1. A minimum of 90 seconds is required between consecutive uses of the SA antenna (F1 F7) in different events (note 1) A minimum of 120 seconds is required between consecutive uses of the SA antenna (F8 F10) in different events (note 2) A minimum of 30 seconds is required between consecutive uses of the SA antenna within the same event A minimum of 30 seconds is required between MAF services on the same TDRS (F1 F7) but in different events A minimum of 30 seconds is required between SMAF services on the same TDRS (F8 F10) but in different events A minimum of 30 seconds is required between uses of the same MAR link on the same TDRS (F1 F7) but in different events A minimum of 30 seconds is required between uses of same SMAR link on the same TDRS (F8 F10) but in different events A minimum of 3 minutes and 30 seconds is required between uses of S-band EET for the same TDRS A minimum of 3 minutes and 30 seconds is required between uses of Ku-band EET for the same TDRS A minimum of 20 seconds is required between uses of the same user interface channel (note 4, note 5) A minimum of 15 seconds is required between services of the same type within an event Ground Rules (note 8) Duration cannot be less than one minute

Revision 9 10-9 450-SNUG

Single Access (SA) services and event SA Antenna

MAF or SMAF service

MAR or SMAR Link

EET equipment

User Interface Channels Any service

Table 10-5. SN Scheduling Event Time Ground Rules (contd)

Applicable Event, Service or Resource Ku band and Ka band services Customer SA and MA/SMA resources Coherent pair of forward and return services (note 7) Ground Rules (note 8) A minimum of 20 seconds is required between Ku and Ka band services in the same event (note 3) The gap between two consecutive events for the same customer must be no less than the gap specified by that customer in the NCCDS database. (note 6) Any return service configured in coherent mode must be associated with a forward service The forward and return services should start at the same time for optimal performance If operational considerations require starting the forward service before the return service, no reconfigurations of the forward service (i.e., OPMs 02, 03, and 11) shall be sent within 30 seconds of the start of return service Forward link sweep requests (OPM 04) shall not be sent within 150 seconds of the start of the return service Must be associated with an S-band or Ku-band return service Must be associated with a pair of S-band forward and return services or a pair of Ku-band forward and return services Notes: 1. 120 seconds will be applied to F1-F7. 2. Longer times are needed for extended field of view support. This is handled through operations procedures. 3. Not implemented in NCCDS scheduling. 4. A user interface channel is a connection between the GTs and the customer facility. In most cases, these connections are via NISN circuits. 5. For many customers, this constraint precludes overlapping events even if the events are scheduled on different TDRSs. However, customers with a sufficiently large set of user interface channels may be able to schedule overlapping events for the same customer platform. 6. Customer-specified gaps are used to prevent scheduling flexibility from positioning two consecutive events for the same customer too close together to be supported by the MOC. Use of customer-specified gaps is optional. 7. These messages will not be rejected, but could cause inaccuracies in subsequently scheduled tracking data.

Revision 9 10-10 450-SNUG

One-way tracking service Two-way tracking service

8. Services are defined as MAF (via F1-F7), SMAF (via F8-F10), SSAF, KuSAF, KaSAF (via F8-F10), MAR (via F1-F7), SMAR (via F810), SSAR, KuSAR, KaSAR (via F8-F10), tracking, and end-to-end test.

10.2.3.4

Forecast Scheduling

Generation of the forecast schedule is a weekly occurrence in the NCCDS. The forecast schedule, which contains events resulting from FA actions and specific MOC requests, consists of 7 days (0000Z Monday through 2359Z Sunday) of SN support commitments. As illustrated in Figure 10-1, MOCs can start requesting support up to 21 days prior to the start of the event. a. On Monday of each week, the NCCDS FA accepts customer SARs for the forecast week beginning 14 days from the current Monday. b. The forecast schedule is generated by and totally under the control of NCCDS Scheduling. All requests for support for the forecast that are received by 1200Z Monday will be scheduled by priority. Any requests received after this time will be scheduled around the currently scheduled events. The NCCDS SO or FA will verbally coordinate the action necessary to resolve any conflicts within the schedule (see paragraph 10.2.3.6). The SO or FA continues the conflict resolution process until a conflict-free forecast schedule is produced satisfying as many requests as possible. c. The forecast scheduling process culminates in the forecast schedule being issued to MOCs on Monday, 7 days prior to the beginning of the week covered by that forecast schedule. The transmission of this confirmed schedule to the customer MOCs automatically transfers the responsibilities for that time period to the NCCDS SO, and this now becomes the active schedule. The list of declined requests which did not make it into the schedule is also sent to the MOCs automatically. Active Schedules

10.2.3.5

a. The active schedule begins at the current time and covers the next 7 to 14 days into the future. Figure 10-1 shows how activation of the forecast schedule extends the active period by 7 days. On the first day of each week (immediately following activation of the forecast schedule), the active schedule is 14 days in length. The length of the active schedule continually decreases until (by the end of the week (Sunday)) the active schedule is 7 days in length. This cycle is then repeated each week with the activation of subsequent forecast schedules. b. The NCCDS transmits an active schedule to the GTs, NISN, and other SN facilities on a daily basis. These schedules are used by appropriate SN elements to reserve the equipment required to meet daily support commitments. The GT schedule contains the support requirements for the operational TDRSs as well as associated requirements for the SGLTs and data distribution/processing services. The NISN schedule, which consists of all NISN data transport requirements into and out of the GTs in support of SN activities, is used by NISN to monitor utilization of those NISN resources

Revision 9

10-11

450-SNUG

FORECASTING SCHEDULING PERIOD

Revision 9 10-12 450-SNUG

ACTIVE SCHEDULING PERIOD T

D-21

D-14

-13 -12 -11 -10 -9

-8

D-7

-6

-5

-4

-3

-2

-1

D+1

+2 +3 +4 +5 +6

D+7

+8

M T W T

S S M T W T

S S M T W T

S S M T W T

S S

SCHEDULE REQUESTS RECEIVED AND PROCESSED IN PRIORITY ORDER

TYPICAL EVENT START TIME

WEEK COVERED BY FORECAST SCHEDULE

ACTIVE SCHEDULING PERIOD DATA BASE MAINTAINED ACTIVE SCHEDULE (UPDATES) ISSUED

SCHEDULE REQUESTS ACCEPTED AND PROCESSED IMMEDIATELY

SCHEDULING PROCESS BEGINS

FORECAST SCHEDULE ISSUED TO CUSTOMERS ACTIVE SCHEDULING PROCESS BEGINS

Figure 10-1. SN Event Schedule Process

which have been committed to the SN. Additionally, the NCCDS will transmit recorder/playback requirements to the GTs. c. The active schedule is constantly being changed as a result of additions or deletions of specific schedule events, operator actions as a result of SN equipment status changes, and other actions. In addition, scheduled support may be affected by customer platform emergencies and/or priority requests by MOCs for additional service. Any changes to the active schedule results in the transmission of active schedule updates to the affected facilities, if schedule information for that time frame had already been transmitted to them. Additionally, the Wait List is processed. Scheduling Conflicts

10.2.3.6

a. Occasionally a direct conflict occurs between two requested events during the forecast scheduling process. In case of scheduling conflicts that cannot be automatically resolved by use of the resource and time flexibility specified in the schedule requests, the NCCDS SO may assist in the analysis of conflicts. Conflict analysis includes the use of priorities provided by NASA, and negotiations between the NCCDS SO or FA and impacted MOCs on an individual basis. Conflict analysis is not performed for specific schedule requests applicable to the active schedule unless NCCDS SO assistance is verbally requested by the MOC. b. The NCCDS has two systems available to customers in predicting possible radio frequency interference (RFI). The Automated Conflict Resolution System (ACRS) predicts mutual interference (MI) between two or more customer platforms scheduled on the same TDRS at the same time. MOCs receive ACRS output and may alter their schedules based upon the interference mitigation techniques provided by ACRS. The TDRS Look Angle System (TLAS) plots the TDRS look angles as it tracks the customer platform and predicts periods of ground based RFI and earth multipath. Both systems use TDRS and customer orbital data as well as customer schedules received directly at the NCCDS. ACRS predicts forward and return link mutual interference. For additional information, refer to the CLASS ACRS/TLAS Operators Manual and Reference, NCC 98. 10.2.3.7 Support Scheduling

Whenever feasible, SN customers should use the forecast scheduling process to schedule SN events. However, a MOC may submit routine specific schedule requests to the NCCDS up to 10 minutes prior to the event start time. A Periodic SHO is transmitted from the NCCDS to the GTs for event start times that are greater than 2 hours and less than 48 hours from the time of SHO receipt at the GTs. The NCCDS transmits a Routine SHO to the GTs for event start times between 10 minutes and 2 hours from the time of SHO receipt at the GTs (see paragraph 10.4 for a discussion on customer platform emergency operations).

Revision 9

10-13

450-SNUG

10.2.4 10.2.4.1

MOC/NCCDS Interfaces General

a. The User Planning System (UPS) was the first scheduling interface developed for MOC/NCCDS interactions. Some customer unique systems have been developed with capabilities equivalent to the UPS. The UPS, or the equivalent customer unique system, serves as a communications focal point and MOC mission planning tool. However, the NCCDS SO can enter schedule requests for any customer at any time. A customer with only limited SN support requirements will not necessarily need a UPS, or equivalent system, and could depend on the NCCDS SO for entry of all schedule requests. b. The SN Web Services Interface (SWSI) is a standards-based, cross-platform compatible customer interface for performing TDRS scheduling and real-time service monitoring and control. Using the SWSI, SN customers can perform scheduling, real-time functions, and state vector storage with only a desktop computer or workstation, a web browser, and a Java Virtual Machine (JVM). The SWSI is designed to be accessed from the NISN Closed IONet or Open IONet. NISN's Open IONet allows access from the NASA Science Internet and the public Internet, thus allowing cooperation with NASA's university, enterprise, and inter/intra-agency partners. A detailed description of SWSI is provided in Appendix P. NOTES: The SN is in the process of developing the SN Access System (SNAS) as a replacement for both UPS and SWSI. SNAS, like SWSI, will provide customers with a secure, network-based interface to the NCCDS or to the DAS, or to both for the purpose of planning, scheduling, monitoring and controlling SN services. SNAS will provide a single, flexible tool to the customer that combines the features and functionality of both the UPS and the SWSI. SN customers will be able to schedule SN support just prior to the requested period and also have access to support tools for ease in scheduling for long-term planning. Customers will also be able to monitor and control events in real-time using either NCCDS or DAS.

Revision 9

10-14

450-SNUG

c.

Scheduling messages may be exchanged between the NCCDS and any MOC at any time. Figure 10-2 lists the messages exchanged via this interface. Descriptions of these messages are contained in paragraphs 10.2.4.2 through 10.2.4.6. Additional MOC/NCCDS message traffic occurs during SN real-time operations (refer to paragraph 10.3). All messages exchanged between the NCCDS and the MOCs must comply with the formats, protocols, and security provisions specified by the Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC).

Specific Schedule Request Wait List Request TDRS Scheduling Window

MOC

Schedule Results Request User Schedule Message Schedule Results Message Schedule Delete Notification *(baseline only)

NCCDS

Figure 10-2. MOC UPS/NCCDS Scheduling Message Exchange

d. The NCCDS supports two classes of customers. They are referred to as baseline customers and full support customers. Refer to Table 10-6 for more information on the difference in available message types for each class of customer. 10.2.4.2 Specific Schedule Request

The Specific Schedule Request message is used to add, delete or replace scheduled events for SN resources. The following NCCDS constraints apply: a. All related services (e.g., forward, return, tracking and end-to-end test) for one SUPIDEN, for one TDRS, and for one continuous period are generally contained in the same request. However, two independent events for the same SUPIDEN can be scheduled at the same time whenever this does not result in resource conflicts.

Revision 9

10-15

450-SNUG

Table 10-6. NCCDS Customer Types and Available Message Types

NCCDS Customer Types Baseline Support provided using all message formats in place prior to NCCDS 1998. Full Support Customers capable of using the full set of NCCDS 1998 message formats and any (or all) of the new schedule features such as service duration flexibility. Specifically: 1. A Schedule Delete Notification is used to notify customers of event deletions. 2. A Schedule Result message will identify events through the use of an Event ID

Specifically: 1. A Schedule Delete Notification is used to notify customers of event deletions. 2. A Schedule Result message will identify events through the combination of the SUPIDEN, TDRS, and Event Start Time parameters (not the Event ID). 3. A Schedule Delete Request message from the customer will identify events through the combination of the SUPIDEN, TDRS, and Event Start Time parameters (not the Event ID). 4. A Schedule Add Request (SAR) message format does not include parameters applicable to service-level flexibility.

3. A Schedule Delete Request message will identify an event using an Event ID.

4. A Schedule Add Request (SAR) message format includes parameters applicable to service-level flexibility. Message types available with NCCDS 1998: Schedule Coordination Messages: 1. Schedule Replace Request (99/12) 2. Alternate Schedule Add Request (99/21) 3. Wait List Request (99/24) 4. TDRS Scheduling Window (99/25) 5. Schedule Result Request (99/28) * User Schedule Messages: 1. Normal Support, Flexible Schedule (94/04) 2. Simulation Support, Flexible Schedule (94/05)

* A Schedule Result Request message is required by all customers whether they are baseline or full support. All MOCs using the TCP/IP protocol must send a Schedule Result Request message even if they are not full support customers. For MOCs which still use the NISN 4800-bit block protocol, the NPG will generate a Schedule Result Request message for them.

Revision 9

10-16

450-SNUG

b. Deletion of a scheduled event may be accomplished only by the MOC that has scheduling authority, the NCCDS SO, or the GT (with NCCDS approval or direction). If the GT deletes an event, this will not result in automatic generation of messages announcing the deletion. c. Configuration changes to scheduled events, prior to the scheduled event start time, require the entire event to be replaced by submitting a Schedule Replace Request (message type 99, message class 12). Alternatively, the event can be deleted by submitting a Schedule Delete Request (message type 99, message class 11) and then a new Schedule Add Request (message type 99, message class 10) can be transmitted. Ordinarily these two methods will achieve equivalent results; however, use of the Schedule Replace Request ensures that the resources allocated to the original event are available to be used to schedule the replacement. Use of the Schedule Replace Request also leaves the original event on the schedule if the replacement cannot be scheduled.

d. For add requests, the configuration of services for the event may be specified either by reference to a set of SSCs or by reference to a prototype event which then references a predetermined set of SSCs stored in the NCCDS database. e. Each SSC represents a single service over one continuous period and designates a predefined set of initial parameter values. In addition, maximum data rate values are specified. SN data rate bandwidth allocation is based on these maximum values rather than on the initial values. The NCCDS will not allow data rate reconfigurations to exceed the specified maximum data rates. f. Some SSC parameter values (e.g., initial data rate) may be replaced by values specified in the MOC specific schedule request. These are called respecifiable parameters.

g. For a specific request using SSCs, the MOC is required to order the SSCs in the same order the services will be output in the USM (i.e., forward, return, tracking). (Refer to Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC). h. The continuous period covered by an event may range from a minimum of 1 minute to a maximum of 24 hours. 10.2.4.3 TDRS Scheduling Windows

a. TDRS Scheduling Windows (TSWs) are transmitted to the NCCDS by the MOC in TSW messages (message type 99, message class 25). Each TSW message contains TSWs applicable to a specified time period for a single customerdefined TSW set for a single TDRS. The TSWs may be transmitted before, after, or at the same time as the schedule requests that depend on the TSWs. However, if a schedule request requires TSWs from a particular TSW set for a

Revision 9

10-17

450-SNUG

particular TDRS during a certain time period, it cannot be processed if applicable TSWs have not been received. b. Each TSW set contains the TSWs applicable to a particular combination of customer visibility constraints based on factors such as antenna type, power, and frequency. Each customer may define as many TSW sets as needed, and may define new TSW sets at any time without negotiation with the NCCDS. c. Each SSC either specifies the TSW set applicable to the scheduling of the service specified by that SSC, or specifies that TSWs are not applicable. A TSW set is a respecifiable parameter. User Schedule Message

10.2.4.4

a. SN schedules are transmitted to the MOCs via USMs. A USM consists of a message header followed by one or more service descriptions. The Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC), provides a detailed description and explanation of the USM and of all other messages exchanged between the NCCDS and the MOC. b. A service description contains all service parameter values needed to initially configure a service. Each service description includes the values of the fixed parameters and the initial values of the reconfigurable parameters required for that service. If more than one service description of the same type is required, they are placed in order as stipulated in the MOC request. c. The following constraints apply to USMs: 1. Each USM describes a single event which is for one SUPIDEN, for one TDRS, and for one continuous time period. All of the services within the event are described by the USM. At least one service must be active at all times during the event. A single USM can include dissimilar services if they occur during the contiguous time period. For cross-support, the services for all related TDRSS elements are contained in the same USM for cross-correlation. The constraints for using cross-support services are discussed more thoroughly in Space Network Operations Policy, STDN No. 119.

2. 3. 4.

d. The NCCDS transmits the forecast schedule to the MOCs on a weekly basis when it is activated. Subsequent modifications to the active schedule result in schedule messages being immediately transmitted to the appropriate MOCs.

Revision 9

10-18

450-SNUG

10.2.4.5

Schedule Result Message

a. Schedule Result Messages (SRMs) are sent from the NCCDS to the MOC to report the disposition of schedule requests submitted by the MOC. The SRMs report all actions taken by the NCCDS, including both automatic processing performed by the NCCDS and manual actions performed by the NCCDS SO. In many cases, a single request will result in multiple SRMs. b. SRMs are also used to report that an event has been deleted. For backwards compatibility, the NCCDS will transmit a Schedule Deletion Notification to baseline MOCs that require this in lieu of the SRM. 10.2.4.6 TDRSS Unscheduled Time

Each MOC receives only those USMs directly relevant to it. USMs do not provide the MOCs with an overview of the SN schedule, and are of little use in attempting to formulate additional schedule requests that will not conflict with other customers' events. To overcome this limitation of the USMs, the NCCDS publishes TDRSS Unscheduled Time (TUT) reports on a Web page. These reports are updated periodically and allow the customer to identify time periods during which specific critical SN resources are not in use. Instructions for accessing the TUT Web page are contained in the Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM (formerly 451-ICD-NCCDS/MOC). NOTE: TUT reports are not transmitted via formatted messages. However, if a MOC is unable to access TUT reports via the web page, the NCCDS can provide TUT reports via e-mail. 10.2.5 10.2.5.1 NCCDS/FDF Scheduling Interface General

The NCCDS/FDF SN scheduling interface is as shown in Figure 10-3. The scheduling information transferred across this interface consists of scheduling aids, acquisition data, and BRTS scheduling data.

Revision 9

10-19

450-SNUG

Spacecraft State Vectors

FDF

BRTS Scheduling Data Ground Trace Predictions (via WWW)

NCCDS

Figure 10-3. NCCDS/FDF Scheduling Information Exchange 10.2.5.2 Scheduling Aids

The scheduling aids for the SN are ground trace predictions generated by the FDF. These ground trace predictions contain one week of customer platform view periods, sun interference, and other information used by both the NCCDS and the MOCs to effectively schedule support. The prediction accuracy of these ground traces will be 1-minute epoch time deterioration of the FDF's best estimated orbit. The FDF provides these scheduling aids via a web server rather than via formatted messages. These scheduling aids can be found on the Flight Dynamics Facility Product Center web page, http://fdf.gsfc.nasa.gov/prod_center/pc_frame_page.htm. 10.2.5.3 Acquisition Data

Acquisition data messages transmitted by the FDF consist of customer platform state vectors in the Improved Interrange Vector (IIRV) format. The format for IIRVs is provided in section 9.5 of the Interface Control Document Between the Space Network (SN) and Customers for Service Management, 452-ICD-SN/CSM. State vectors are transmitted to the NCCDS on a regular basis with vector epochs spaced at FDF determined intervals. A 2-day projection for each customer is supplied daily. The IIRVs are updated by the FDF in order to maintain the prediction accuracy required for S-band and Ku-band services, while Ka-band tracking services are not available. The FDF also supplies IIRVs for the TDRSs, and for permanent Earth stations. NOTE: MOCs can provide the NCCDS with the IIRVs for their customer platforms rather than having the FDF perform this function for them.

Revision 9

10-20

450-SNUG

NOTE: The NCCDS has the capability to receive IIRVs sent via File Transfer Protocol (FTP) in addition to the capability to receive IIRVs sent via formatted message. 10.2.5.4 BRTS Scheduling

Generic scheduling of the BRTSs is performed by the NCCDS with the resultant schedule transmitted to the FDF. The FDF plans for, and requests scheduling of, BRTS calibrations and special TDRSS test events. 10.2.6 10.2.6.1 GT/NCCDS Scheduling Interface General

The types of data exchanged between the NCCDS and the GTs are shown in Figure 10-4. The data transfers relevant to the scheduling process are discussed in paragraphs 10.2.6.2 through 10.2.6.4. Operations Messages (OPMs), TDRSS Service Level Reports (SLRs), and Operations Data Messages (ODMs) are discussed in paragraph 10.3. Refer to Table 10-12 for further information on the real-time message flow between the NCCDS and GT.

Scheduling Data (SHO) Operations Messages (OPM)

NCCDS

TDRSS Service Level Report (SLR) Operations Data Messages (ODM)

GT

Figure 10-4. NCCDS/GT Data Exchange 10.2.6.2 NCCDS/GT Messages

Two message types are transferred between the NCCDS and the GTs that are a direct result of the SN scheduling process: the SHO and the SHO Status Message (OPM, Class 51).

Revision 9

10-21

450-SNUG

10.2.6.3

SHO Messages

The NCCDS transmits a SHO to the GTs to schedule TDRSS services as part of SN support. Two types of electronic SHO messages are used by the NCCDS. a. A Periodic SHO message is used by the NCCDS to transmit schedules for customer services whose event start times are equal to or greater than 2 hours and less than 48 hours from the time of SHO receipt at the GTs. b. A Routine SHO message is used by the NCCDS to transmit schedules for services whose event start times are equal to or greater than 10 minutes and less than 2 hours from the time of SHO receipt at the GTs. Each SHO is assigned a unique SHO ID number. The SHO contains the fixed and reconfigurable parameters for each TDRSS service (forward, return, tracking and end-to-end test). The SHO completely specifies the service type, subtype, the TDRS to be used, start/stop times, and the initial parameter values to be employed by the TDRSS in establishing the scheduled support services. SHOs will also contain requests for rate-buffering and data quality monitoring. One SHO may contain up to 16 services. The GT uses SHOs to allocate TDRSS resources in support of the scheduled events. There are many ground rules that govern the structure and transmission of SHOs. A complete listing of these ground rules can be found in paragraphs 2.2.2 and 2.2.3 of the Interface Control Document (ICD) Between the Network Control Center (NCC)/Flight Dynamics Facility (FDF) and the White Sands Complex (WSC), 530-ICD-NCC-FDF/WSC. 10.2.6.4 SHO Status Messages

The SHO Status Message is an OPM (Class 51) transmitted to the NCCDS by the GT in response to received SHOs. It is used to inform the NCCDS of the condition (accepted or rejected) of each SHO. If the SHO has been rejected or has been accepted, but some problems exist, a problem code explaining the reason is included in the SHO Status Message. The SHO Status OPM is also used to inform the NCCDS when a SHO terminates or is canceled. 10.2.7 10.2.7.1 NCCDS/NEST Scheduling Interface General

a. The NCCDS provides the NISN/NASA Event Scheduling Terminal (NEST) with schedules applicable to the utilization of NISN resources. Messages sent by the NCCDS to the NEST specify the NISN support required at particular times in terms of data rates, data types, data stream ID, sources, and destination. The individual communications service elements of these requests are referred to as data streams. b. The schedule provided by the NCCDS allows NISN personnel to use the NEST to monitor utilization of those NISN resources committed to the SN and to

Revision 9

10-22

450-SNUG

troubleshoot anomalies. The NISN equipment and circuits are primarily datadriven, and do not normally require explicit configuration in response to the schedule; therefore, the NEST does not play a direct role in the configuration or activation of NISN resources. However, under unusual circumstances some NISN equipment requires manual configuration in response to the schedule. c. The messages that are relevant to scheduling operations and are exchanged between the NCCDS and the NEST are listed on Figure 10-5 and are described in paragraphs 10.2.7.2 through 10.2.7.5.

NASCOM Event Schedule (NES) NASCOM Event Cancel (NEC)

NCCDS

NASCOM Reconfiguration Request (NRR) NASCOM Reconfiguration Request Accept

NISN/NASA Event Scheduling Terminal (NEST)

Figure 10-5. NCCDS/NEST Scheduling Data Exchange 10.2.7.2 NASCOM Event Schedule (NES) Message

At least once daily the NCCDS transmits an active schedule to the NEST consisting of no more than 24 hours of support approximately 24 hours in advance of the first event. Each event in this transmission is specified by an individual NES notifying NISN of all scheduled data streams required within the event. 10.2.7.3 NASCOM Event Cancel (NEC) Message

This message is used to notify the NEST of the cancellation of an event previously scheduled by the NES Message. The NEC Message may be transmitted at any time prior to or during an event. 10.2.7.4 NASCOM Reconfiguration Request (NRR)

Nascom Reconfiguration Requests (NRRs) are sent by the NCCDS to notify the NEST that an active event has been reconfigured. The only parameter reconfigurations reported in this message are data stream ID and data rate. Refer to Table 10-13 for real-time message flow between the NCCDS and the NEST.

Revision 9

10-23

450-SNUG

10.2.7.5

NASCOM Reconfiguration Request Accept Message

After receipt of an NRR message, the NEST replies with an NRR Accept message. 10.3 10.3.1 SN Real-Time Operations General

The real-time operations period is the time frame in which the MOC and the SN elements (e.g., NCCDS and GTs) perform the necessary activities to support the command, telemetry, and tracking operations of a customer platform. Real-time activities are initiated in a chronological sequence, as specified by the USMs. 10.3.2 Real-Time Operations Functional Overview

Routine SN real-time operations in support of a customer MOC involve the major SN systems (TDRSS and the NCCDS) and the two major non-SN NASA elements that support SN operations (NISN and FDF). Table 10-7 provides an overview of real-time operational responsibilities and activities for the NCCDS. An overview of the MOCs real-time operational activities is provided in Table 10-8. The real-time operational responsibilities and activities of the FDF and NISN are shown in Table 10-9. GT operations can be categorized as those occurring just prior to the scheduled support start time, those occurring during the real-time support period, and those occurring post-support. Table 10-10 provides an overview of GT real-time operational activities. 10.3.3 Real-Time Operations Messages

Instructions, information, and responses between SN elements, non-SN elements that support SN operations, and the customer MOC during SN real-time operations are primarily accomplished by message exchange. These messages are designated by the combination of a two-digit type code together with a two-digit class code (e.g., 03/10). Table 10-11 describes the real-time message flow between the NCCDS and the MOC, Table 10-12 describes the real-time message flow between the NCCDS and GT, and Table 10-13 describes real-time message flow between the NCCDS and NISN. Information in these tables provides an overview of why a message is sent and the actions that occur when it reaches its destination. 10.3.4 10.3.4.1 MOC Real Time Interfaces SWSI

SWSI provides a user interface for real-time events. SWSI receives messages sent out from the NCCDS and DAS, filters the messages based on SIC, and displays the content of the messages in panels on its graphical user interface (GUI). SWSI also provides support for control messages that the user can send to the NCCDS and DAS. A detailed description of SWSI is provided in Appendix P.

Revision 9

10-24

450-SNUG

Table 10-7. Real-time Operations Activities Overview for NCCDS

System Element NCCDS Functional Responsibility Administrative management and coordination of SN Monitoring SN System performance Activity Description 1. Initiating SN real-time operations 2. Forwarding Acquisition Failure Notification messages received from GTs to the MOC 3. Monitoring SN performance via GT DQM data in ODMs. When requested, sending UPDs to a MOC 4. Verifying GCMRs from MOCs and generating and transmitting the requested OPMs to the GT. If necessary, coordinating SN reconfigurations verbally with MOCs and SN resources 5. Processing OPMs from the GTs, coordinating with the MOC if needed, and initiating the proper transactions required by the OPMs 6. Monitoring the implementation status of the OPM by examination of the OPM Status Message (OPM 62) from the GTs 7. Transmitting nominal state vectors received from the FDF to the GT 8. Canceling an ongoing event when requested by a MOC 9. Directing data quality monitoring during a customer real-time operation, if necessary Applicable Timeline 1. Ten minutes prior to the start time of the service support period 2. Whenever received from the GT during a return service 3. The NCCDS receives ODMs from the GT every 5 seconds during the total real-time support duration 4. Any time during the scheduled SHO duration

5. Any time during the scheduled SHO duration

6. Right after OPM transmission

7. During the scheduled service support period if state vector real-time update is required 8. During the scheduled event support period, as requested by a MOC 9. Upon customer request or when the SN fails to provide the required quality service to a customer

Revision 9

10-25

450-SNUG

Table 10-7. Real-time Operations Activities Overview for NCCDS (contd)

System Element NCCDS Functional Responsibility Activity Description 10. Receiving from GTs and transmitting to the MOC return channel time delay measurements 11. Receiving from GTs and transmitting to the MOC time transfer measurements Applicable Timeline 10. Measured at start, stop, and reconfigurations of return service for transmission after the scheduled support period 11. Measured a specified number of times during tracking service for transmission after the scheduled support period 12. After completion of scheduled service

12. Conducting post support debriefing of support elements

Table 10-8. Real-time Operations Activities Overview for MOC

System Element MOC Functional Responsibility Management of customer platform operations Activity Description 1. Receiving Acquisition Failure Notification messages from the NCCDS 2. Initiating of GCM requests 3. Monitoring customer platform performance data (UPD) and identifying customer platform emergency situations 4. Receiving return channel time delay measurement data from the NCCDS 5. Receiving time transfer data from the NCCDS 6. Generating post-event reports informing the NCCDS of the service quality provided to the MOC Applicable Timeline 1. Shortly after scheduled start of return service, but may also occur anytime during return service 2. Any time during scheduled support period as required 3. Continuously during scheduled service support duration

Monitoring of customer platform performance

4. After completion of return service 5. After completion of tracking service 6. After completion of event

Revision 9

10-26

450-SNUG

Table 10-9. Real-time Operations Activities Overview for FDF and NISN
System Element FDF Functional Responsibility Processing of tracking data Activity Description 1. Receiving and processing real-time TDMs from GTs 2. Generating and transmitting real-time state vectors Applicable Timeline 1. During the scheduled tracking period 2. When the transmitted state vectors have epoch time deterioration which exceed the S-band and Ku-band service required values 1. During the duration of customer real-time operations

Generating orbit and ephemeris data

NISN

Routing data/messages

1. Performing data-driven configuration and reconfiguration of the communications channels as needed

Table 10-10. Real-time Operations Activities Overview for GTs

System Element GTs Functional Responsibility Providing TDRSS forward, return, and tracking services to customers Interfacing a TDRS with customer platform based upon specified RF characteristics Responding to NCCDS's administrative command and coordination Activity Description Prior to the Real-Time Service: 1. Processing the received SHOs from the NCCDS, including: a. Performing syntax checking b. Reserving the required equipment 2. Performing Pre Service Test 2. Up to three minutes prior to service start. 3. Prior to start of service 4. At about 6 minutes prior to service start time 5. At about 1-2 minutes prior to service start time 6. Two to 5 minutes prior to the service start time in an SA service SHO 1. Any time from 10 minutes to 48 hours before service start time Applicable Timeline

3. Processing of the NCCDSsupplied state vectors 4. Generating the TDRS antenna pointing angles (i.e., look angles) and range dynamics data 5. Generating commands to configure the ground equipment and the TDRS 6. Acquiring TDRS antenna: positioning the scheduled TDRS SA antenna boresight toward the scheduled customer platform

Revision 9

10-27

450-SNUG

Table 10-10. Real-time Operations Activities Overview for GTs (contd)

System Element GTs Functional Responsibility Activity Description During the Real-Time service: 7. Initiating Forward, Return, and Tracking services 8. Acquiring a customer platform return service signal: a. Link acquisition sequence for MA return services: (1) PN code acquisition (2) Carrier acquisition (3) Bit synch/Viterbi decoder synch acquisition (4) Data phase ambiguity resolution, if required, after establishment of carrier lock b. Link acquisition sequence for SMA/SSA return services: (1) PN code acquisition, if applicable (2) Carrier acquisition (3) Bit synch/Viterbi decoder synch acquisition (4) Deinterleaver acquisition, if required (5) Data phase and data channel ambiguity resolution and baseband switching, if required, after the establishment of carrier lock 7. At the start of the scheduled support period 8. At the beginning of a service (for forward services, the customer platform performs a similar process for the TDRS forward service signal) Applicable Timeline

Revision 9

10-28

450-SNUG

Table 10-10. Real-time Operations Activities Overview for GTs (contd)

System Element GTs Functional Responsibility Activity Description c. Link acquisition sequence for KuSA/KaSA return services: (1) Antenna autotrack pull-in, if applicable (2) PN code acquisition, if applicable (3) Carrier acquisition (4) Bit synch/Viterbi decoder (if applicable) synch acquisition (5) Data phase and data channel ambiguity resolution, and baseband switching, if required, after the establishment of carrier lock Note: An acquisition failure message (OPM-63) would be sent to the NCCDS and forwarded to the MOC if the GTs did not acquire a customer platform signal within the allocated time duration. 9. Notifying the NCCDS of entrance and exit into Real-Time Mode (OPM 64) 10. Processing real-time vectors (type 2, 4, 5, 6, and 7) 11. Determining GT RCTD, when required. Note: RCTD measurements are not provided for services scheduled through GRGT. 12. Controlling TDRS antenna operations 13. Reacquiring a customer platform return service signal if initial acquisition failure or loss of lock occurs 9. At start and end of real-time maneuver sequence 10. During the scheduled support periods as required 11. At the start and stop of a service and at service reconfigurations; for RCTD transmission after the service. 12. As needed 13. Reacquisition activated automatically by the GTs or by a reacquisition OPM from the MOC via the NCCDS Applicable Timeline

Revision 9

10-29

450-SNUG

Table 10-10. Real-time Operations Activities Overview for GTs (contd)

System Element GTs Functional Responsibility Activity Description Note: An acquisition failure message would be sent to the NCCDS and forwarded to the MOC if the GT did not acquire a customer platform signal within the allocated time duration 14. Transmitting ODMs to the NCCDS 14. ODMs transmitted every 5 seconds containing all the active services supported by the TDRSS 15. During the scheduled support period Applicable Timeline

15. Processing OPMs, including reconfiguration OPMs, sent from the NCCDS and initiating proper transactions 16. Transmitting the required OPMs (except OPM 52) to the NCCDS 17. Performing forward channel data presence monitoring (DPM) and return channel data quality monitoring (DQM) as directed by the NCCDS 18. Providing rate buffered recording for High Data Rate Service data rates (see Table 3-4) with playback rates of < 48 Mbps 19. Providing line outage recording capability to support data recording Note: Line outage recording is provided automatically for the majority of data interfaces, but is not available for some types of data interface (see Table 3-4) 20. Transmitting SLRs to the NCCDS

16. During the scheduled support period 17. During the scheduled support period

18. During the scheduled support period

19. During the scheduled support period

20. After detection of equipment failures or upon verbal request.

Revision 9

10-30

450-SNUG

Table 10-10. Real-time Operations Activities Overview for GTs (contd)

System Element GTs Functional Responsibility Activity Description 21. Transmitting Tracking Data Messages to the FDF 22. Transmitting time transfer message, OPM 66, to the NCCDS, when required 23. Terminating a service or a SHO as scheduled or canceling a SHO as requested by the NCCDS Applicable Timeline 21. Every 5 seconds when requested. 22. Within 1 minute of tracking service termination for which time transfer was requested 23. At the end of a SHO or at any time during the scheduled SHO duration as requested by a Cancel SHO OPM from the NCCDS 24. After service is complete.

After the Real-Time Service: 24. Transmitting RCTD, OPM 52, to the NCCDS Note: RCTD measurements are not provided for services scheduled through GRGT. 25. Participating in post event debriefing 26. Transmitting playback of high rate customer return data; transmitting line outage recording data (see Table 3-4) 25. After event is complete 26. As scheduled; as required

Revision 9

10-31

450-SNUG

Revision 9 10-32 450-SNUG

Table 10-11. Real-time Message Flow Between the NCCDS and MOCs
Message Category Message Type/ Class Message ID Message Generation Frequency Message Generation Conditions Destination System Response

Messages from the NCCDS to the MOCs User Schedule Messages Note: User schedule messages are normally used during scheduling operations, but may also be used during real-time emergency operations 94/01 Normal Support Fixed Schedule Premium Support Fixed Schedule Forecast schedule or routine active period update-- event is fixed Schedule add with a lead time of 10 to 45 minutes of event start time event is fixed Forecast schedule or routine active period update event is fixed Forecast schedule or routine active period update event retains flexibility Forecast schedule or routine active period update event retains flexibility Event deleted during active period Note: Applicable only for baseline customers NCCDS reports disposition of MOC submitted schedule request Update schedule database

94/02

Update schedule database

94/03

Simulation Support Fixed Schedule Normal Support Flexible Schedule

Update schedule database

94/04

Update schedule database

94/05

Simulation Support Flexible Schedule

Update schedule database

99/01

Schedule Delete Notification

Update schedule database

99/02

Schedule Result Message

Update schedule database. Declined request may be changed and resubmitted by MOC

Real-time GCMs

98/01

GCM status

GCMR rejected by either the NCCDS or the GT, or accepted by the GT GT GCM receipt acknowledgment received by NCCDS

98/02

GCM disposition

Table 10-11. Real-time Message Flow Between the NCCDS and MOCs (contd)
Message Category Message Type/ Class Message ID Message Generation Frequency Message Generation Conditions Destination System Response

Revision 9 10-33 450-SNUG

Messages from the NCCDS to the MOCs (contd) Operations Performance 91/01 UPD One every 5 seconds during event, when requested TDRSS customer performance data requested by MOC RCTD requested in SHO transmitted to the NCCDS by the GT. Data transmitted by the GT to the NCCDS after termination of scheduled service or when equipment reconfiguration occurs and is sent on to the MOC Note: Return Channel Time Delay (RCTD) measurements are not provided for services scheduled through GRGT. 92/63 Acquisition Failure Notification GT has not achieved initial acquisition or reacquisition of the customer platform return service signal within the predetermined time Upon termination of a tracking service for which time transfer was requested MOC may send reacquisition request GCMR (98/03) to the NCCDS

92/62

Return Channel Time-Delay Measurement

92/66

Time Transfer

Table 10-11. Real-time Message Flow Between the NCCDS and MOCs (contd)
Message Category Message Type/ Class Message ID Message Generation Frequency Message Generation Conditions Destination System Response (Note: Descriptions in this column apply to all GCMRs listed on this page)

Revision 9 10-34 450-SNUG

Messages from MOCs to the NCCDS (contd) Real-time GCMRs 98/03 98/04 Reacquisition Request Reconfiguration Request Forward Link Sweep Request Forward Link EIRP Reconfiguration Request Expanded User Frequency Uncertainty Request Doppler Compensation Inhibit Request Performance Data Request MOC request NCCDS routes GT ODMs to the appropriate MOC every 5 seconds during event MOC real-time service request NCCDS verifies customer platform eligibility and service availability If valid, the NCCDS transmits an OPM to the GT. NCCDS sends GCM Disposition to MOC when GT acknowledges OPM receipt GCM status message is sent to the MOC, if GCMR/OPM is rejected by either NCCDS/GT. GCM status message indicating accept is sent if OPM is accepted by the GT

98/05

98/06

98/07

98/08

Operations Performance

92/04

Table 10-11. Real-time Message Flow Between the NCCDS and MOCs (contd)
Message Category Message Type/ Class Message ID Message Generation Frequency Message Generation Conditions Destination System Response

Revision 9 10-35 450-SNUG

Messages from MOCs to the NCCDS (contd) Specific Schedule Requests Note: User schedule messages are normally used during scheduling operations, but may also be used during real-time emergency operations 99/10 Specific Schedule Add Request Specific Schedule Delete Request Specific Schedule Replace Request Specific Schedule Alternate Add Request Spedific Schedule Wait List Request Schedule Result Request TDRS Scheduling Windows MOC Scheduling Operator request for normal, simulation, or premium event MOC Scheduling Operator request to delete active event, or queued request MOC Scheduling Operator request to replace active event, or queued request MOC Scheduling Operator request to link alternate request to a previously queued request MOC Scheduling Operator request to put referenced request on the wait list MOC using TCP/IP sends 99/28 to define communications path for receipt of 99/02 and 94/xx MOC sends to NCCDS to specify customer platform to TDRS visibility 99/02 sent to report disposition and 94/xx sent if event is added 99/02 sent to report disposition, 99/01 also sent to baseline customers 99/02 sent to report disposition, 94/xx sent if event is added 99/02 sent to report disposition, 94/xx sent if event is added 99/02 sent to report disposition

99/11

99/12

99/21

99/24

99/28

99/02 and 94/xx sent on communications path defined by 99/28 NCCDS saves in database, and applies to scheduling

TDRS Windows

Scheduling

99/25

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-36 450-SNUG

Messages from the NCCDS to the GTs OPM 01 Special Instruction or Request 03/01 Used in message exchange between controllers Not used in automatic processing/control OPM 02 Reacquisition Request 03/02 Real-time control message Initial link acquisition failure NCCDS reformats and validates the MOC GCMR (98/03) GT response time is up to 20 seconds (forward) and 10 seconds (return) of OPM receipt and acceptance for all services GT sends an OPM 63 (Acquisition Failure Notification) to the NCCDS if the acquisition process fails GT verifies and validates the OPM and initiates the reacquisition process. It should be noted for coherent service mode, a forward reacquisition will cause both forward and return services to be reacquired GT sends an OPM status message (OPM 62) upon successful reacquisition completion This message is used to send free-form alphanumeric text from the NCCDS to GTs No processing required

GT prints this message and displays it on a TOCC console

Link unlocked

Link acquisition failure during a customer platform real-time configuration

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-37 450-SNUG

Messages from the NCCDS to the GTs (contd) OPM 03 Customer Reconfiguration Request 03/03 Real-time control message A MOC transmits a TDRSS reconfiguration request to the GT, via a GCMR to the NCCDS, if there is a need to reconfigure the GT and TDRS equipment supporting its customer platform NCCDS reformats and validates the MOC reconfiguration request (98/04) and transmits an OPM (03/03) to GT The GT response time is up to 35 seconds of OPM receipt and acceptance for all services

NCCDS responds to a GCM from a MOC with GCM status (98/01) and GCM disposition (98/02) messages The GT verifies and validates the OPM and processes and implements the OPM if legal OPM 04 Forward Link Sweep Request 03/04 Real-time control message Used as an acquisition aid when customer platform receiver acquisition failure is suspected because customer platform receiver frequency differs from expected values. Used in both initial and reacquisition situations. OPM04 is also used for nominal Preventive Maintenance (PM) mode sweep initiation and termination. NCCDS reformats and validates the MOC-generated forward link sweep request (98/05) and transmits an OPM (03/04) to the GT

The GT will respond to the OPM 03 with an OPM 62 after successful completion of the reconfiguration or a message rejection if the message is incomplete or invalid

The GT initiates the forward link sweep within 10 seconds of OPM receipt and acceptance

The GT verifies and validates the OPM and initiates the forward link sweep process

The GT will respond to the OPM 04 with an OPM 62 confirming that the sweep has started or a message is incomplete or invalid

Table 10-12. Real-time Message Flow Between the NCCDS and the GTS (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-38 450-SNUG

Messages from the NCCDS to the GTs (contd) OPM 06 Forward Service EIRP Reconfiguration Request 03/06 Real-time control message This OPM is used to set the TDRS SSA and KaSA/KuSA EIRP to normal or high power as the situation requires NCCDS reformats and validates the MOCgenerated forward link EIRP reconfiguration request (98/06) and transmits an OPM (03/06) to the GT. The GT validates, processes, and implements the OPM by changing the TDRS onboard power mode The GT response time is up to 10 seconds of OPM receipt and acceptance for all services

The GT will respond to the OPM 06 with an OPM 62 acknowledging receipt of an OPM without detecting errors or a message rejection if the message is incomplete or invalid

OPM 07 Expanded Customer Frequency Uncertainty Request 03/07 Real-time control message This message is generated when the MOC cannot accurately predict the customer platform transmit frequency for DG1 mode 2 and DG2 (non-coherent) operation NCCDS reformats and validates the MOC-generated expanded customer platform transmit frequency uncertainty request (98/07) and transmits an OPM (03/07) to GT The GT validates and processes the OPM and initiates the expansion of the return service frequency area examined The GT response time is up to 5 seconds of PM acceptance for all services. The GT will respond to the OPM 07 with an OPM 62 acceptance status upon frequency expansion initiation or an OPM 62 reject if the message is incomplete or invalid

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-39 450-SNUG

Messages from the NCCDS to the GTs (contd) OPM 10 or 15 Spacecraft State Vector 03/10 or 15 Real-time or non real-time message Daily or more often, if necessary, for each customer platform This message is used to transmit customer platform state vector data to GT prior to the scheduled service support period start time The data contents of the message are generated by FDF The message originates at FDF and is transmitted to the NCCDS for retransmission to the GT The GT will respond to the OPM 10 message with an OPM 61 state vector rejection message if the vector is found to be unusable OPM 64 will be sent upon entrance and exit of the real-time mode. OPM 64 will be provided for type 2, 4, 5, 6, 7 state vectors received within 6 minutes prior to service or during service with epochs to be applied before service termination OPM 11 Doppler Compensation Inhibit Request 03/11 Real-time control message Prior to the beginning of a twoway tracking service NCCDS reformats and verifies the MOC-originated Doppler compensation inhibit request (98/08) and transmits an OPM (03/11) to the GT The GT will initiate Doppler Compensation Inhibit within 10 seconds of receipt of OPM 11 and fix the forward carrier frequency within 20 seconds after receipt of OPM 11.

The GT validates and processes the OPM and initiates inhibition of the Doppler compensation on the referenced forward service

The GT sends an OPM status message (OPM 62) after successful initiation of the Doppler Inhibit

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-40 450-SNUG

Messages from the NCCDS to the GTs (contd) OPM 12 Cancel SHO Request 03/12 Real-time or non real-time message When it is necessary for the NCCDS to request cancellation of either an on-going or an upcoming SHO NCCDS transmits a Cancel SHO OPM (03/12) to the GT. The GT validates the message and cancels the specified SHO OPM 13 TDRS Maneuver Approval OPM 18 t Adjustment 03/18 Real-time or non real-time message NCCDS uses this message to adjust the epoch time parameter within stationary state vectors (launch holds) Not used for orbit correction NCCDS formats and transmits the message to the GT prior to epoch reference time The GT system response time is up to 30 seconds of OPM receipt and acceptance or at the new epoch reference time, whichever is later The GT will respond to the NCCDS with an OPM 65, t adjustment rejection to a state vector rejection message, if appropriate The Gt may send OPM 64 real-time mode entry/exit, as appropriate 03/13 Non real-time message As required NCCDS transmits approval/ disapproval in response to a TDRS Maneuver Request, OPM 59, from the GT Manual operationally thisis handled via e-mail The GT may initiate TDRS maneuver upon receipt of approval from NCCDS The GT sends an OPM status Message (OPM 62) upon acceptance of the Cancel SHO OPM The GT sends and OPM 51 indicating referenced SHO was successfully deleted from the GT database

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-41 450-SNUG

Messages from the GTs to the NCCDS OPM 51 SHO Status 03/51 Real-time or non real-time message Daily at SHO transmissions if status changes Used by the GTs to inform the NCCDS of the status of a SHO NCCDS processes the message, alerts the operators if problems exist Problems handled by operators

OPM 52 Return Channel Time Delay 03/52 Real-time data message (not a control message) MOC initiated request. Not a re-configurable parameter When a SHO includes a request for return service time delay data, the return channel time delay data will be obtained at the start and stop of the return service and at service reconfigurations. An OPM (03/52) is used to send NCCDS the data after termination of the return service This message will be used to send free-form alpha-numeric text from the GTs to the NCCDS NCCDS receives and reformats the message and sends it to the appropriate MOC

OPM 53 Preventive Maintenance Request 03/53 1 week in advance of the preventive maintenance date NCCDS receives and verifies the message

NCCDS alerts the NCCDS operator The NCCDS operator will block the affected resources to keep them from being scheduled for customer support

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-42 450-SNUG

Messages from the GTs to the NCCDS (contd) OPM 54 Special Request or Information 03/54 Used in message exchange between controllers This message will be used to send free-form alpha-numeric text from the GTs to the NCCDS Operationally, an OPM 54 is used to request preventative maintenance NCCDS receives and verifies the message

Not used in automatic processing/control OPM 57 Service Termination 03/57 Real-time report message This message is sent from the GTs to the NCCDS for notification of the termination of a service

NCCDS alerts the NCCDS operator

NCCDS logs the data

OPM 59 TDRS Maneuver Request 03/59 When the GT desires to perform a TDRS maneuver which might have an impact on providing service, advance approval is requested from the NCCDS NCCDS receives and validates the OPM Operationally this is handled via e-mail. NCCDS responds to the GTs with an OPM 13, TDRS maneuver approval message, which will either grant or deny the GTs permission for the TDRS maneuver

NCCDS alerts the NCCDS operator NCCDS operator processes the request and attempts to resolve any possible impact during the requested maneuver duration

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-43 450-SNUG

Messages from the GTs to the NCCDS (contd) OPM 61 Spacecraft State Vector Rejection 03/61 Near real-time or non-realtime message reporting the rejection of an OPM 10 or 15 message Before propagating the ephemeris data from a received state vector, the GT performs the required validity checks. If any of these NCCDS-GT messages fail validity checks, this rejection message is sent from the GT to the NCCDS Receives and validates the OPM NCCDS operator may respond to the GT with a new OPM 10, or 15 message

NCCDS alerts the NCCDS operator OPM 62 OPM Status 03/62 Real-time or non-real-time message One for each OPM OPMs received by the GT from NCCDS will be checked for validity. This message is then used by the GT to inform the NCCDS that either the OPM has been accepted, or rejected as a result of the validity checks detecting an erroneous OPM If an OPM is rejected, OPM 62 will be sent immediately. If accepted, OPM 62 will be sent acknowledging receipt for OPMs 6 and 12 and OPM 62 will be sent upon OPM implementation for OPMs 2, 3, 4, 7, and 11. The NCCDS receives and validates the OPM and notifies the NCCDS operator if the NCCDS OPM has been rejected For an NCCDS OPM that has been rejected, the NCCDS or the impacted MOC corrects the error and the NCCDS retransmits the corrected OPM to the GT

For an NCCDS OPM that has been rejected, the NCCDS initiates the required handling to correct the problem code error

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-44 450-SNUG

Messages from the GTs to the NCCDS (contd) OPM 64 Real-Time Mode Notification 03/64 Enter Real-Time Mode upon receipt of any of the following messages less than 6 minutes prior to the start of service or during service: a. Delta-T message b. Type 1 or 8 vector with an epoch prior to the end of service c. Type 2, 4, 5, 6, or 7 vector as part of a maneuver sequence and with an epoch time in the future prior to the end of service. The GT must have at least 2 maneuver vectors with future epoch times OPM 65 t Adjustment Rejection 03/65 Near real-time or nonreal time message reporting the rejection of an OPM 18 message The GT uses this message to advise the NCCDS that a requested t adjustment has not been implemented NCCDS alerts the NCCDS operator NCCDS may retransmit the corrected t adjustment (03/18) to the GTs This message is used by the GT to inform the NCCDS that the GT has entered or exited the Real-Time Mode The NCCDS receives and validates the OPM and notifies the NCCDS operator Upon receipt of message indicating entry into real-time mode, the NCCDS refrains from initiating transmission of other data that could require real-time mode processing until the GT responds with a message indicating that it has exited from real-time mode

NCCDS operator initiates processing to handle the problem

Table 10-12. Real-time Message Flow Between the NCCDS and the GTs (contd)
Message ID Message Type/ Class Message Length and Operational Characteristics Message Generation Frequency Message Generation Conditions Required Processing Destination System Response

Revision 9 10-45 450-SNUG

Messages from the GTs to the NCCDS (contd) OPM 66 Time Transfer Data 03/66 Variable length dependent on number, n, of time transfer samples Transmitted to NCCDS within 1 minute of tracking service termination for which time transfer was requested in the SHO Upon verbal request from the NCCDS or upon change in any reported parameter within 15 minutes of change SLR information is also sent via e-mail NCCDS receives and reformats the message and sends it to the appropriate MOC

Service Level Requests (SLRs)

04/NA (note)

SLRs with ID numbers 1 to 4,999,999 to 1 are a result of equipment status change. SLRs with ID numbers 5,000,000 to 9,999,999 to 5,000,000 are sent in response to NCCDS request One every 5 seconds during active event

For resources reported as unavailable, the NCCDS operator will block the affected resources to keep them from being scheduled for user support ODMs are reformatted as UPD messages and routed to appropriate MOC when requested Route TDRSS customer performance data message to appropriate MOC

Operations Data Messages (ODMs)

Separate ODMs are sent for SA/SMAR, MA/SMAF, and end-to-end test services for each TDRS whenever service is ongoing

SA/SMAR

05/NA (note) 06/NA (note) 07/NA (note)

Real-time operations report

MA/SMAF

End-to-End Test

Note: Message class information not applicable to SLRs and ODMs

Table 10-13. Real-time Message Flow Between the NCCDS and NISN
Message ID Message Type/ Class Message Length Message Generation Conditions Messages between the NCCDS and NEST NASCOM Event Schedule NASCOM Event Cancel NASCOM Event Schedule Update NASCOM Event Emergency Schedule NASCOM Reconfiguration Request NASCOM Reconfiguration Request Accept 90/01 90/02 90/04 90/05 90/06 90/07 1 to 6 blocks 1 block 1 to 6 blocks 1 to 6 blocks 1 to 2 blocks 1 blocks Daily schedule transmission To cancel an accepted support event One message per event as needed Event added to daily schedule after normal transmission Event added with a lead time of 5 to 45 minutes of event start time Change to requirements for ongoing event NEST always responds to 90/06 with Accept Information used by NISN to monitor resource utilization Information used by NISN to monitor resource utilization Information used by NISN to monitor resource utilization Information used by NISN to monitor resource utilization Information used by NISN to monitor resource utilization Absence of this message will cause alert to NCCDS operator. Message Destination System Response

Revision 9 10-46 450-SNUG

10.4 10.4.1

Customer Platform Emergency Operations General

SN support to customer platform emergency operations can be divided into two portions: customer platform emergency requests, processing, and implementation; and real-time emergency operations. A thorough description of emergency scheduling and real-time emergency operations is given in paragraphs 10.4.2 and 10.4.3. The SN capabilities available to support the MOC in customer platform emergency operations consist of the use of SHO schedule requests, OPMs, and the use of the GT manual commands per NCCDS direction, as the situation requires. These capabilities may be used alone or in various combinations to support and resolve a specific operational emergency situation of a customer. 10.4.2 10.4.2.1 Emergency Scheduling Customer Platform Emergency Requests for SN Support

a. Emergency scheduling spans the period from the point a MOC declares a customer platform emergency to the NCCDS to implementation of the SHO by the GT. A Routine SHO message is transmitted if the required event start time is less than 2 hours from the time of SHO receipt at the GTs. b. The MOC requests emergency support by notifying the NCCDS of the nature of the declared emergency, desired start time, services required, and expected duration of the support. Customer platform emergency requests for SN support are submitted as Schedule Add Requests with the customer priority set to 1 to indicate that the request is for emergency support. If the start time is less than 10 minutes away, manual intervention by the NCCDS operator will be necessary. 10.4.2.2 NCCDS Processing of a Customer Platform Emergency

a. The procedure for processing the customer platform emergency request is similar to the regular scheduling process except for any unresolvable scheduling conflict. The NCCDS SO receives an alert from the NCCDS when the request is either successfully processed or rejected. If the scheduling request is rejected, the message from the NCCDS notifies the NCCDS SO of the details of the conflict. The NCCDS SO attempts to resolve the conflict by individual discussions with each impacted MOC to determine if its scheduled service support period can be terminated or delayed. If these conflict resolution discussions are not successful, the NCCDS makes the scheduling decisions. When necessary, the NCCDS SO deletes conflicting events. This results in Schedule Result Messages being transmitted (refer to paragraph 10.2.4.5) to each impacted MOC to notify them of the deletions. The NCCDS SO also

Revision 9

10-47

450-SNUG

informs the MOC initiating the customer platform emergency request of appropriate details of the conflict resolution. Based upon the information supplied to that MOC by the NCCDS SO, it prepares and transmits a new Schedule Add Request to the NCCDS for processing. However if the changes needed to the original request are relatively simple, the NCCDS SO may edit the request rather than requiring the MOC to submit a new request. b. If the scheduling request causes no conflict, the NCCDS automatically approves it, generates a SHO, and transmits that SHO to the GT. The NCCDS also generates and transmits a Schedule Result Message to the MOC and the schedules to other affected SN elements. c. The NCCDS tests for conflicts in allocating services and, if a conflict exists, works with the MOC to resolve the conflict. The following procedures apply: 1. 2. The NCCDS automatically attempts to resolve the conflict by shifting events within MOC prescribed tolerances. If the conflict resolution attempt is unsuccessful, the NCCDS sends a Schedule Result Message to the requesting MOC advising that the request has been declined. After evaluating the Schedule Result Message, the customer MOC may contact the NCCDS SO for further assistance. The NCCDS scheduling operators perform the necessary conflict analysis. If the NCCDS SO approves the request, he deletes all conflicting events. If the request is denied, the original schedule remains unaffected. The requester and all those affected are notified of the NCCDS's final decision via either a schedule update, verbal communications, or a Schedule Result Message as appropriate at the time the decision is made. All schedule requests, including customer platform emergency requests, must specify an event start time. The resulting schedule messages are sent immediately to NISN, the GT, and the impacted MOCs. GT Processing of the Customer Platform Emergency SHO

3.

4. 5. 6.

7.

10.4.2.3

Once the customer platform emergency SHO arrives at the GT, the following GT processing takes place within 5 minutes of receipt of the SHO: a. Start times for all services called out by the SHO are generated. Checks are made that service durations are at least 60 seconds but not greater than 24 hours. b. A resource check is made and the equipment required is reserved. If the SHO is accepted, a SHO Status OPM is transmitted to the NCCDS indicating acceptance of the SHO. If the SHO is rejected, a SHO Status OPM is transmitted to the NCCDS indicating rejection of the SHO. This message

Revision 9

10-48

450-SNUG

contains an error code giving the reason for rejection. It is expected that there will be only minimal instances in which the GT rejects the SHO. Based upon the specific error code, the NCCDS scheduling operator will continue attempts to obtain support. 10.4.3 Real-Time Customer Platform Emergency Operations

As far as the GTs and the NCCDS are concerned, the use and processing of the MOC reconfiguration GCMRs is the same for both normal and emergency real-time operations. During a customer platform emergency operation, the MOC may send a series of command messages to its customer platform to perform the troubleshooting and procedures necessary to correct the emergency condition. These messages could include channel data rate changes and may require corresponding changes within the TDRSS channel configurations. A MOC can issue a GCMR to the NCCDS requesting a TDRSS real-time reconfiguration to support such unplanned channel data rate changes. After receipt of the corresponding OPM from the NCCDS, the GTs will nominally respond and complete the requested reconfiguration in less than 35 seconds, (refer to Table 10-12 under "Messages from the NCCDS to the GTs" for additional constraints). An OPM 62 status will be sent by the GT upon reconfiguration GCM completion.

Revision 9

10-49

450-SNUG

This page intentionally left blank

Revision 9

10-50

450-SNUG

Appendix A. Example Link Calculations

A.1

General

This appendix contains example link calculations for forward and return services. All link calculations are based on the TDRSS telecommunications services defined in Sections 5 (MA), 6 (SSA), 7 (KuSA), and 8 (KaSA). NOTE: The calculations in this appendix are provided for example only, and no data should be extracted from them for specific use. For specifics on preparing necessary RF ICD's, contact GSFC Code 450. A.2 Customer Platform-to-TDRS-Range

All forward and return service link calculations are based upon example customer platform-to-TDRS ranges of 42,510 km for S-band and 45,890 km for K-band (Ku and Ka). Figure A-1 illustrates the example communications range positions for a 2000-km customer platform orbit. The maximum communications ranges for particular customer platforms can differ from these values as a result of the actual orbit, Power Flux Density (PFD) constraints (refer to Appendix D), or other customer mission requirements and constraints. A.3 Forward Service Link Calculations

A.3.1 Forward service performance is expressed in terms of having a sufficient data Bit Energy to Noise Spectral Density Ratio (Eb/No) at the customer platform receiving system for the desired link operating point (e.g., command data channel BER of 10-5). Forward service performance is determined by calculating a predicted (Eb/No) and comparing it against the required (Eb/No).

Revision 9

A-1

450-SNUG

X
Earth

45,890-km range used for Ku-band and Ka-band link calculations 42,510-km range used for S-band link calculations

2000-km circular orbit

Range = 47,200 km f (MHz) 2106.4 2287.5 13,775.0 15,003.4 23000.0 27000.0

Ls (dB) for Example Link Calculations -191.5 -192.2 -208.5 -209.2 -212.9 -214.3

TDRS

Figure A-1. Geometry Depicting Nominal Ranges Used for Example Link Calculations

Revision 9

A-2

450-SNUG

A.3.2 Forward service link calculations are based on the TDRS EIRPs and the transmitting antenna axial ratios shown in Tables 5-2 (MA), 6-3 (SSA), 7-2 (KuSA), and 8-2 (KaSA), the customer platform receiving system characteristics, the link operating frequency, and the customer platform-to-TDRS range. The following procedure may be used to determine the performance of the forward service command channel: Equation A-1
P rec =EIRP+L +L +L + (G/T )10log(k ) s p N o

where: EIRP = The total TDRS EIRP in the direction of the customer platform (fixed by TDRS performance specification). The EIRP in the data channel is a function of the modulation type and the modulation index. The EIRP in the data channel is: EIRPdata (dBW) = EIRP 0.4 (UQPSK when the baud rate 300 kbps) EIRPdata (dBW) = EIRP (BPSK and when baud rate > 300 kbps) EIRPdata (dBW) = EIRP -20log10(sin(mi)) (SSA direct PM)
EIRP (dBW) = EIRP - 20log 10 ( 2 * J1(mi)) data (SSA PSK sine - wave subcarrier PM) EIRPcarrier (dBW) = EIRP -20log10(cos(mi)) (SSA direct PM) EIRPcarrier (dBW) = EIRP -20log10(J0(mi)) (SSA PSK subcarrier PM) where mi is the modulation index, J1 is the first order Bessel function, J0 is the zero order Bessel function.

Ls R f Lp

= space loss (in dB) = -[32.45 + 20 log10 (R) + 20 log10 (f)], (Ls < 0 dB). = maximum range (in km) between the TDRS and the customer platform over which communications will occur. = TDRS transmission frequency (in MHz). = polarization loss (in dB) due to the mismatch of the TDRS radiated polarization and that of the customer platform receiving antenna (Lp 0 dB). = pointing loss (in dB) in the customer platform received signal due to inability of the customer platform to point its receiving antenna directly at the TDRS (L 0 dB).

Revision 9

A-3

450-SNUG

G/T

= customer platform receiving antenna gain to system thermal noise temperature ratio (in dB/K).

10 log (k) = -228.6 dBW/Hz-K (k is Boltzmanns constant). Equation A-2 (Eb/No) predicted = Prec/No - 10 log Rd + where: Rd = data rate in bps = sum of customer platform receiving system and TDRSS forward service degradation factors (in dB), accounting for non-ideal degradations such as PN loss, demodulator degradation, bit sync loss, interference and multipath degradations, and distortion losses ( 0 dB).

Equation A-3 M = (Eb/No) predicted - (Eb/No) required where: M = customer performance margin (in dB) to allow for customer platform performance degradation throughout its operational lifetime (M 0 dB).

(Eb/No)required = the bit energy to noise spectral density ratio in (dB) theoretically required for the command data BER (e.g., 9.9 dB for a 10-5 BER with coherent differential PSK). The forward service performance curves in Figure A-2 through Figure A-7 are for example only and show Achievable Data Rate (ADR) versus customer platform G/T for the command data channel. The ADR equation is derived by solving Equation A-1, Equation A-2 and Equation A-3 for 10 log Rd and using the values of the equation parameters defined in the appropriate figure, and the following assumptions: a. The margin (M) is assumed constant at 3 dB the amount of margin is a customer decision that should be coordinated with GSFC Code 450 and should consider long-term degradations in the customer platform.

Revision 9

A-4

450-SNUG

20
MA/SMA Forward Service EIRP EIRP EIRP Data/Total Power Loss BER Customer Perfomance Margin Space Loss Polarization Loss Pointing Loss Other Losses () Required Eb/No FOR EXAMPLE ONLY 34.0 dBW (Primary FOV and LEO FOV for F1-F7) 40.0 dBW (Primary FOV for F8-F10) 42.0 dBW (LEO FOV for F8-F10) -0.4 dB (UQPSK assumed F1-F7 for data rates < 300 kbps) 10-5 3.0 dB -191.5 dB -0.5 dB 0 dB -2.5 dB 9.9 dB F8-F10, Primary FOV

10

0 User Spacecraft G /T (dB/K)

-10

F8-F10, LEOFOV

-20

-30

Max Data Rate 300 kbps

-40

-50 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-2. MA/SMA Forward ADR versus G/T

Revision 9

A-5

450-SNUG

20
SSA Forward Service FOR EXAMPLE ONLY Normal Power EIRP (Normal Power Mode) 43.6 dBW EIRP (F1-F7 High Power Mode) 46.3 dBW EIRP (F8-F10 High Power Mode) 48.5 dBW Data/Total Power Loss -0.4 dB (UQPSK assumed for data rates < 300 kbps) BER Customer Perfomance Margin Space Loss Polarization Loss Pointing Loss Other Losses () Required Eb/No 10-5 3 dB -191.5 dB -0.5 dB 0 dB -2.5 dB 9.9 dB

10

High Power, F1-F7 High Power, F8-F10

User Spacecraft G /T (dB/K)

-10

-20

-30

Max Data Rate 7 Mbps

-40

-50

300 kbps

-60 100

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-3. SSA Forward ADR versus G/T for F1-F10

Revision 9

A-6

450-SNUG

50

KuSAForward Service Autotrack EIRP (Normal Power Mode) EIRP (High Power Mode) Data/Total Power Loss BER Customer Perfomance Margin Space Loss Polarization Loss Pointing Loss Other Losses () Required Eb/No 46.5 dBW 48.5 dBW -0.4 dB for data rates <300 kbps 10 -5 3 dB -208.5 dB -0.5 dB 0 dB -2.5 dB 9.9 dB

FOR EXAMPLE ONLY

40

30

Normal Power Mode

User Spacecraft G/T (dB/K)

20

10

High Power Mode

-10

Max Data Rate 25 Mbps

-20 300 kbps

-30

-40 1000

10000

100000

1000000

10000000

100000000

Achievable Data Rate (bps)

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-4. KuSA Forward ADR versus G/T (Autotrack for F1-F10)

Revision 9

A-7

450-SNUG

50

40

KuSAForward Service LEO Program Track EIRP (Normal Power Mode) EIRP (High Power Mode) Data/Total Power Loss

FOR EXAMPLE ONLY 44.0 dBW 46.0 dBW -0.4 dB for data rates <300 kbps

30

User Spacecraft G/T (dB/K)

20

10

-5 BER 10 Customer Perfomance Margin 3 dB Space Loss -208.5 dB Polarization Loss -0.5 dB Pointing Loss 0 dB Other Losses () -2.5 dB Required Eb/No 9.9 dB

Normal Power Mode

High Power Mode 0

-10

Max Data Rate 25 Mbps

-20 300 kbps -30

-40 1000

10000

100000

1000000

10000000

100000000

Achievable Data Rate (bps)

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-5. KuSA Forward ADR versus G/T (LEO Program Track for F1-F10)

Revision 9

A-8

450-SNUG

50 KuSAForward Service Program Track 40 EIRP (Normal Power Mode) EIRP (High Power Mode) Data/Total Power Loss FOR EXAMPLE ONLY

40.5 dBW 42.5 dBW -0.4 dB for data rates < 300 kbps

30

User Spacecraft G/T (dB/K)

20

-5 BER 10 Customer Perfomance Margin 3 dB Space Loss -208.5 dB Polarization Loss -0.5 dB Pointing Loss 0 dB Other Losses () -2.5 dB Required Eb/No 9.9 dB

Normal Power Mode

10 High Power Mode

0 Max Data Rate 25 Mbps -10 300 kbps -20

-30 1000

10000

100000

1000000

10000000

100000000

Achievable Data Rate (bps)

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-6. KuSA Forward ADR versus G/T (Program Track for F1-F10)

Revision 9

A-9

450-SNUG

20

KaSA Forward Service EIRP (Autotrack) EIRP (LEO Program Track) EIRP (Program Track) Data/Total Power Loss

FOR EXAMPLE ONLY

10

User Spacecraft G /T (dB/K)

63.0 dBW 59.5 dBW 56.2 dBW -0.4 dB (UQPSK assumed for data rates < 300 kbps) BER 10-5 Customer Perfomance Margin 3.0 dB Program Space Loss -212.9 dB Track Polarization Loss -0.5 dB Pointing Loss 0 dB Other Losses () -2.5 dB LEO Program Track Required Eb/No 9.9 dB

-10

Autotrack

-20

Max Data Rate 25 Mbps

-30

300 kbps

-40 1000

10000

100000

1000000

10000000

100000000

Achievable Data Rate (bps)

Note: Data/Total Power Loss assumes UQPSK for data rates 300 kbps Figure A-7. KaSA Forward ADR versus G/T (F8-F10)

Revision 9

A-10

450-SNUG

b. Required Eb/No is 9.9 dB (BER of 10-5). The SSA and KuSA forward services are provided both with normal mode and high mode EIRP. Customer platform/TDRSS incompatibility and RFI degradation (see paragraph A.3.3 below) is 0 dB. A.3.3 CLASS is used to determine if any incompatibility or RFI degradation exists between the customer platform's receiving system terminal and the TDRSS. Detailed characteristics of the customer platform receiving system and the salient characteristics of the TDRSS forward services determine the magnitude of any compatibility loss. When applicable, these degradation factors, as determined by CLASS, must be included as loss terms on the right side of Equation A-1. A.4 Return Service Link Calculations

A.4.1 Return service performance is expressed in terms of having sufficient received power (Prec) at the TDRS to achieve a specific data rate (referred to as ADR) for a return service data channel BER of 10-5. The received power (Prec) at the TDRS is defined as the "Unity" Power Received at the Input to TDRS (i.e., with a TDRS gain of 0 dBi). Customers do not need to understand the details of the TDRS, TDRS-to-ground terminal link, and the ground terminal specifics for link margin performance. Return service performance is determined by calculating the predicted required Prec at a TDRS (accounting for all system losses), and comparing it to the ideal required Prec at the TDRS for a given data rate. A.4.2 The ideal required Prec is determined as follows: Equation A-4 Ideal required Prec = 10 log10 Rd + K where: K is a constant depending on the service, type of tracking and/or field of view, coding, data rate, and mode. These relationships are as shown in Tables 5-8 (MA), 6-9 (SSA), 7-7 (KuSA), and 8-7 (KaSA). A.4.3 The predicted required Prec is determined by the following equation:

Revision 9

A-11

450-SNUG

Equation A-5 Predicted Required Prec = Ideal Required Prec - L - Lp - LI - Lnc where: L = pointing loss (in dB) due to the inability of the customer platform to point its antenna directly at the TDRS (L 0 dB). Lp = polarization loss (in dB) due to mismatch of the customer platform radiated polarization and that of the TDRS receiving antenna (LP 0 dB). RFI and customer platform incompatibility factors (in dB) as determined by CLASS (refer to paragraph 3.5.2) (LI 0 dB, Lnc 0 dB).

LI, Lnc

A.4.4 By extension, the minimum customer platform EIRP, (EIRP)min, required to produce the predicted required Prec is as follows: Equation A-6 (EIRP)min = Predicted Required Prec - Ls where: Ls is space loss as defined in paragraph A.3.2. A.4.5 The return service performance margin M (in dB) is a customer decision that should be coordinated with GSFC Code 450 and should consider long-term performance degradation of the customer platform throughout its operational lifetime. M is defined as follows: Equation A-7 M = EIRP - (EIRP)min (M > 0 dB)

A.4.6 The return service performance curves in Figure A-8 through Figure A-42 show ideal required (Prec) versus ADR for selected services, type of tracking and/or field of view, codings, modes, data rates and channels. Figure A-43 shows an example ADR versus customer platform EIRP for a hypothetical customer platform, for an assumed performance margin, M, as illustrated in Equation A-7. The service, coding, mode, and channel in Figure A-43 are assumed to be those given in Figure A-15, so as to illustrate how the predicted required Prec is realized, (or alternatively, how the ideal required Prec plus performance margin is realized).

Revision 9

A-12

450-SNUG

-150

MAR: DG1, Mode 1,2 Rate 1/2 Convol. Encoding F1-F7 Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

-180

Upper limit for DG1, mode 1,2 300 kbps

-190

Signal Acquisition Threshold: -192.2 dBWi

-200 100

Lower limit for DG1 mode 2

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-8. MA DG1 Modes 1, 2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F1-F7)

Revision 9

A-13

450-SNUG

-150

SMAR: DG1, Modes 1,2,3I Rate 1/2 Convol. Encoding F8 (hot) Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Upper limit for DG1, mode 1,2 300 kbps

-180

Signal Acquisition Threshold: -190.3 dBWi

Upper limit for DG1 mode 3I 150 kbps

-190 Lower limit for DG1 mode 2

-200 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-9. SMA DG1 Modes 1, 2, 3I (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))

Revision 9

A-14

450-SNUG

-150

SMAR: DG1, Modes 1,2,3I Rate 1/2 Convol. Encoding F8 (cold),F9,F10 Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Upper limit for DG1, mode 1,2 300 kbps

-180

Signal Acquisition Threshold: -193.7 dBWi

Upper limit for DG1 mode 3I 150 kbps

-190 Lower limit for DG1 mode 2

-200 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-10. SMA DG1 Modes 1, 2, 3I (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10)

Revision 9

A-15

450-SNUG

-150
FOR EXAMPLE ONLY

SMAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding F8(hot) Primary FOV
-160
Upper limit for DG2 3 Mbps

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -178.3 dBWi

Upper limit for DG1 mode 3Q 1.5 Mbps

-180
Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-190

Signal Acquisition Threshold: -190.3 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-11. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))

Revision 9

A-16

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding F8(cold),F9,F10 Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170
Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -181.7 dBWi

Upper limit for DG2 3 Mbps

-180

Upper limit for DG1 mode 3Q 1.5 Mbps

-190

Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

Signal Acquisition Threshold: -193.7 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-12. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10)

Revision 9

A-17

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/3 Convol. Encoding F8(hot) Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -178.3 dBWi Upper limit for DG1 mode 3Q 1 Mbps Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

Upper limit for DG2 2 Mbps

-180

-190

Signal Acquisition Threshold: -190.3 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-13. SMA DG1 Mode 3Q and DG2 (Rate1/3) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (hot))

Revision 9

A-18

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/3 Convol. Encoding F8(cold),F9,F10 Primary FOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170
Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -181.7 dBWi

Upper limit for DG2 2 Mbps Upper limit for DG1 mode 3Q 1 Mbps

-180

-190

Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

Signal Acquisition Threshold: -193.7 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-14. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (Primary FOV for F8 (cold), F9, F10)

Revision 9

A-19

450-SNUG

-150 FOR EXAMPLE ONLY

-160

MAR: DG1, Modes 1,2 Rate 1/2 Convol. Encoding F1-F7 LEOFOV

Ideal Required Prec (dBWi)

-170

-180

Signal Acquisition Threshold: -193.1 dBWi

-190 Lower limit for DG1 mode 2 -200 100

Upper limit for DG1, mode 1,2 300 kbps

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-15. MA DG1 Modes 1, 2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F1-F7)

Revision 9

A-20

450-SNUG

-150

SMAR: DG1, Modes 1,2,3I Rate 1/2 Convol. Encoding F8 (hot) LEOFOV
-160

FOR EXAMPLE

Ideal Required Prec (dBWi)

-170

Upper limit for DG1, mode 1,2 300 kbps

-180

Signal Acquisition Threshold: -191.7 dBWi

Upper limit for DG1 mode 3I 150 kbps

-190 Lower limit for DG1 mode 2

-200 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-16. SMA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot))

Revision 9

A-21

450-SNUG

-150

SMAR: DG1, Modes 1,2,3I Rate 1/2 Convol. Encoding F8 (cold),F9,F10 LEOFOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Upper limit for DG1, mode 1,2 300 kbps

-180

Signal Acquisition Threshold: -195.0 dBWi

Upper limit for DG1 mode 3I 150 kbps

-190

Lower limit for DG1 mode 2 -200 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-17. SMA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10)

Revision 9

A-22

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding F8(hot) LEOFOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -179.7 dBWi

Upper limit for DG2 3 Mbps Upper limit for DG1 mode 3Q 1.5 Mbps

-180
Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-190

Signal Acquisition Threshold: -191.7 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-18. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot))

Revision 9

A-23

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding F8(cold),F9,F10 LEOFOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170
Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -183 dBWi

Upper limit for DG2 3 Mbps Upper limit for DG1 mode 3Q 1.5 Mbps

-180
Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-190

Signal Acquisition Threshold: -195.0 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-19. SMA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10)

Revision 9

A-24

450-SNUG

-150

SMAR: DG1 Mode 3Q, DG2 Rate 1/3 Convol. Encoding F8(hot) LEOFOV
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -179.7 dBWi

Upper limit for DG2 2 Mbps Upper limit for DG1 mode 3Q 1 Mbps

-180
Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-190

Signal Acquisition Threshold: -191.7 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-20. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (hot))

Revision 9

A-25

450-SNUG

-150
FOR EXAMPLE ONLY

SMAR: DG1 Mode 3Q, DG2 Rate 1/3 Convol. Encoding F8(cold),F9,F10 LEOFOV
-160

Ideal Required Prec (dBWi)

-170
Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -183 dBWi

Upper limit for DG2 2 Mbps Upper limit for DG1 mode 3Q 1 Mbps

-180

-190

Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

Signal Acquisition Threshold: -195.0 dBWi

-200 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-21. SMA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec) (LEOFOV for F8 (cold), F9, F10)

Revision 9

A-26

450-SNUG

-160

SSAR: DG1, Modes 1,2,3I Rate 1/2 Convol. Encoding

-170

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-180

-190

Signal Acquisition Threshold: -202.9 dBWi

-200
Upper limit for DG1 mode 3I 150 kbps Lower limit for DG1 mode 2

Upper limit for DG1, mode 1,2 300 kbps

-210 100

1000

10000 Achievable Data Rate (bps)

100000

1000000

Figure A-22. SSA DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-27

450-SNUG

-150

SSAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170
Upper limit for DG2 6 Mbps Upper limit for DG1 mode 3Q 3 Mbps

-180

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -190.9 dBWi

-190

-200

Signal Acquisition Threshold: -202.9 dBWi

Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-210 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-23. SSA DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-28

450-SNUG

-150

SSAR: DG1 Mode 3Q, DG2 Rate 1/3 Convol. Encoding

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170
Upper limit for DG2 4 Mbps Upper limit for DG1 mode 3Q 2 Mbps

-180

Signal Acquisition Threshold for SQPSK DG2 and noncoherent + 35 kHz expanded frequency uncertainty DG2 configurations Prec floor: -190.9 dBWi

-190

-200

Signal Acquisition Threshold: -202.9 dBWi

Lower limit for DG2, Dual Channel, 1:1 Power Ratio (total I+Q = 60 kbps)

-210 1000

10000

100000 Achievable Data Rate (bps)

1000000

10000000

Figure A-24. SSA DG1 Mode 3Q and DG2 (Rate 1/3) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-29

450-SNUG

-150

KuSAR: DG1 Modes 1,2,3I Uncoded Autotrack

-160 Ideal Required Prec (dBWi)

FOR EXAMPLE ONLY

-170

-180

Signal Acquisition Threshold: -183.3 dBWi

Upper limit for DG1, mode 1, 2 600 kbps

Lower limit for DG1 modes 1,2 3I -190 100

Upper limit for DG1, mode 3I 300 kbps

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-25. KuSA Autotrack DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-30

450-SNUG

-140
FOR EXAMPLE ONLY

KuSAR: DG1 Mode 3Q, DG2 Uncoded Autotrack

-150

Ideal Required Prec (dBWi)

F1-F7

-160

F8-F10

-170

Upper limit for DG2 300 Mbps

-180
Upper limit for DG1 mode 3Q 6 Mbps

Autotrack/Signal Acquisition Threshold: -183.3 dBWi

-190 1 10 100

1000

10000

100000

1000000

Achievable Data Rate (kbps)

Figure A-26. KuSA Autotrack DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-31

450-SNUG

-150

-160 Ideal Required Prec (dBWi)

KuSAR: DG1 Modes 1,2,3I Rate 1/2 Convol. Encoding AutotracK

FOR EXAMPLE ONLY

-170

-180

Autotrack/Signal Acquisition Threshold: -183.3 dBWi

Upper limit for DG1, modes 1,2 300 kbps

Upper limit for Lower limit for DG1 modes 1,2,3I DG1 mode 3I 150 kbps -190 100

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-27. KuSA Autotrack DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-32

450-SNUG

-150

KuSAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding Autotrack
-160 Ideal Required Prec (dBWi)

FOR EXAMPLE ONLY

-170

Upper limit for DG2 150 Mbps

-180

Autotrack/Signal Acquisition Threshold: -183.3 dBWi

-190 1 10 100 1000

Upper limit for DG1 mode 3Q 3 Mbps

10000

100000

1000000

Achievable Data Rate (kbps)

Figure A-28. KuSA Autotrack DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-33

450-SNUG

-150

KuSAR: DG1 Modes 1,2,3I Uncoded LEO Program Track

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold: -180.8 dBWi

-180 Upper limit for DG1, modes 3I 300 kbps -190 100

Upper limit for DG1 modes 1,2 600 kbps

Lower limit for Rate DG1, mode 1,2,3I

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-29. KuSA LEO Program Track DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-34

450-SNUG

-140

KuSAR: DG1 Mode 3Q, DG2 Uncoded LEO Program Track

-150

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

F1-F7

-160
F8-F10

-170

Upper limit for DG2 300 Mbps

-180

Signal Acquisition Threshold: -180.8 dBWi

Upper limit for DG1 mode 3Q 6 Mbps

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-30. KuSA LEO Program Track DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-35

450-SNUG

-150

KuSAR: DG1 Modes 1,2,3I Rate 1/2 Convol. Encoding LEO Program Track
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold: -180.8 dBWi

-180 Upper limit for DG1 mode 3I 150 kbps Upper limit for DG1 modes 1,2 300kbps

Lower limit for DG1mode 1,2,3I -190 100

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-31. KuSA LEO Program Track DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-36

450-SNUG

-150

KuSAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding LEO Program Track
-160 Ideal Required Prec (dBWi)

FOR EXAMPLE ONLY

-170

Upper limit for DG2 150 Mbps

-180

Signal Acquisition Threshold: -180.8 dBWi

Upper limit for DG1 mode 3Q 3 Mbps

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-32. KuSA LEO Program Track DG1 Mode 3Q and DG2 (Rate1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-37

450-SNUG

-150

KuSAR: DG1 Modes 1,2,3I Uncoded Program Track (Primary FOV and EEFOV)
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold: -177.3 dBWi

-180

Upper limit for DG1 mode 3I 300 kbps Lower limit for Rate DG1, mode 1,2, 3I

Upper limit for DG1, mode 1,2 600 kbps

-190 100

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-33. KuSA Program Track DG1 Modes 1, 2, 3I (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-38

450-SNUG

-140
FOR EXAMPLE ONLY

KuSAR: DG1 Mode 3Q, DG2 Uncoded Program Track

-150
F1-F7

Ideal Required Prec (dBWi)

-160

F8-F10

-170

Upper limit for DG2 300 Mbps

-180

Signal Acquisition Threshold: -177.3 dBWi

Upper limit for DG1 mode 3Q 6 Mbps

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-34. KuSA Program Track DG1 Mode 3Q and DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-39

450-SNUG

-150

KuSAR: DG1 Mode 1,2,3I Rate 1/2 Convol. Encoding Program Track (Primary FOV and EEFOV)
-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

Signal Acquisition Threshold: -177.3 dBWi

Upper limit for DG1, modes 1,2 300 kbps

-180 Lower limit for Rate DG1, modes 1,2, 3I Upper limit for DG1 mode 3I 150 kbps

-190 100

1000

10000

100000

1000000

10000000

Achievable Data Rate (bps)

Figure A-35. KuSA Program Track DG1 Modes 1, 2, 3I (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-40

450-SNUG

-150

KuSAR: DG1 Mode 3Q, DG2 Rate 1/2 Convol. Encoding Program Track
-160 Ideal Required Prec (dBWi)

FOR EXAMPLE ONLY

-170
Upper limit for DG2 150 Mbps

-180

Signal Acquisition Threshold: -177.3 dBWi

Upper limit for DG1 mode 3Q 3 Mbps

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-36. KuSA Program Track DG1 Mode 3Q and DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-41

450-SNUG

-150

KaSAR: DG2 Uncoded Autotrack

-160 Ideal Required Prec (dBWi)

FOR EXAMPLE ONLY

-170

-180

Upper limit for DG2 300 Mbps

Autotrack/Signal Acquisition Threshold: -184.1 dBWi

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-37. KaSA Autotrack DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-42

450-SNUG

-150

KaSAR: DG2 Rate 1/2 Convol. Encoding Autotrack

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

-180

Autotrack/Signal Acquisition Threshold: -184.1 dBWi

-190 1 10 100 1000

Upper limit for DG2 150 Mbps

10000

100000

1000000

Achievable Data Rate (kbps)

Figure A-38. KaSA Autotrack DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-43

450-SNUG

-150

KaSAR: DG2 Uncoded LEO Program Track

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

-180

Upper limit for DG2 300 Mbps

Signal Acquisition Threshold: -182.0 dBWi

-190 1 10 100 1000 Achievable Data Rate (kbps) 10000 100000 1000000

Figure A-39. KaSA LEO Program Track DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-44

450-SNUG

-150

KaSAR: DG2 Rate 1/2 Convol. Encoding LEO Program Track

-160

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-170

-180

Upper limit for DG2 150 Mbps

Signal Acquisition Threshold: -182.0 dBWi

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-40. KaSA LEO Program Track DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-45

450-SNUG

-140

KaSAR: DG2 Uncoded Program Track (Primary FOV)

-150

FOR EXAMPLE ONLY

Ideal Required Prec (dBWi)

-160

-170

Upper limit for DG2 300 Mbps -180

Signal Acquisition Threshold: -178.1 dBWi

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-41. KaSA Program Track DG2 (Uncoded) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-46

450-SNUG

-150

KaSAR: DG2 Rate 1/2 Convol. Encoding Program Track (Primary FOV)

FOR EXAMPLE ONLY

-160

Ideal Required Prec (dBWi)

-170

-180

Upper limit for DG2 150 Mbps

Signal Acquisition Threshold: -178.1 dBWi

-190 1 10 100 1000 10000 100000 1000000 Achievable Data Rate (kbps)

Figure A-42. KaSA Program Track DG2 (Rate 1/2) Return ADR versus Required Received Power at the TDRS (Prec)

Revision 9

A-47

450-SNUG

1000000

100000 Achievable Data Rate (bps)

MAR: DG1 Mode 1 Rate 1/2 Convol. Encoding LEOFOV for F1-F7

10000
FOR EXAMPLE ONLY
BER 1E-5 Customer PlatformEIRP M argin 3.0 dB Space Loss -192.2 dB Polarization Loss -0.5 dB RFI Degradation -0.5 dB Noncompliance Degradation 0.0 dB Customer PlatformAntenna Pointing Loss 0.0 dB

1000

100 0 5 10 15 Custom PlatformEIRP (dBW er i) 20 25 30

Figure A-43. MAR DG1 Modes 1 (Rate 1/2) ADR versus EIRP (LEOFOV for F1-F7)

Revision 9

A-48

450-SNUG

Appendix B. Functional Configurations for TDRSS Forward and Return Services (with Emphasis on Resolving Customers Data Polarity and I-Q Channel Ambiguities)

B.1 B.1.1

General Purpose

The purpose of this Appendix is to describe the transmitter data communication functional configurations for TDRSS forward services and return services. Additionally, for each configuration, this Appendix identifies the conditions under which either data polarity ambiguity or I-Q channel ambiguity may exist at the SN/customer data interface. B.1.2 Data Polarity Ambiguity and I-Q Channel Ambiguity

When data polarity ambiguity exists at the SN/customer data interface, the logical sense of the data may be either true or inverted. When I-Q channel ambiguity exists at the SN/customer data interface for the dual-source configurations, received I-channel or Q-channel data may appear on the designated interface port for the I-channel data, and received Q-channel or I-channel data may appear on the designated interface port for the Q-channel data. Data polarity ambiguity and I-Q channel ambiguity are addressed in paragraph B.2 for forward service and paragraph B.3 for return service. B.1.3 Definitions

In this Appendix, data format refers to the format of the source data either prior to transmission (uncoded operation) or prior to convolutional encoding (coded operation). Symbol format refers to the format of the channel data that is modulated onto the carrier. Figure B-1 depicts the definition of the various NRZ and Biphase formats. B.2 B.2.1 Forward Service General

The customer/SN end-to-end system functional configuration for forward service is shown in Figure B-2. Forward service data generated in the customer MOC is transmitted to the SN data interface. Refer to Section 3, paragraph 3.6, for information concerning data interface capabilities and restrictions. The NISN, WSC, GRGT and TDRS are transparent to the data format and coding scheme of the forward link data originating in the customer MOC, except for WDISC and SSA PM customers. The SN supports forward data conditioning operations for WDISC and SSA PM forward link customers.

Revision 9

B-1

450-SNUG

Revision 9 B-2 450-SNUG

DATA

Sequence of binary symbols (bits, chips) "1" and "0"

H NRZ-L L

Non-Return-to-Zero-Level "1" is represented by a high (H) level during the symbol period "0" is represented by a low (L) level during the symbol period

H NRZ-M L

Non-Return-to-Zero-Mark "1" is represented by a change in level "0" is represented by no change in level

H NRZ-S L

Non-Return-to-Zero-Space "1" is represented by no change in level "0" is represented by a change in level

H BI-L L

Bi-phase-L (Manchester II) A transition occurs at the middle of every symbol period "1" is represented by a midperiod transition from H to L "0" is represented by a midperiod transition from L to H

H BI-M L

Bi-phase-Mark A transition occurs at the beginning of every symbol period "1" is represented by a midperiod transition "0" is represented by no midperiod transition

H BI-S L

Bi-phase-Space A transition occurs at the beginning of every symbol period "1" is represented by no midperiod transition

Symbol period T (Symbol rate R = 1/T)

"0" is represented by a midperiod transition

Figure B-1. Digital Signal Formats

SN Data Interface TDRSS

WDISC MDM

SN RF Interface

Customer MOC

Local Interface IF

SN Ground Terminal

TDRS

Customer Platform

Figure B-2. Forward Service End-to-End System Functional Configuration These data-conditioning operations include forward link rate 1/2 convolutional coding, BCH encoding and data format conversion for WDISC customers, and data format conversion for SSA PM customers. The SN supports two modulation categories referred to as PSK and PM. The PSK category is supported for MA, SSA, KuSA, and KaSA forward services. The PM category is supported for only SSA forward service. Table B-1 lists the data rate restrictions and the modulation types that are supported for each SN forward service. The TDRS spacecraft is capable of bent-pipe operation to support customer-defined (non-TDRSS) signal formats. Non-TDRSS signal formats may require the addition of SN ground terminal modulation/demodulation equipment. Precise performance and SN support of these customer-defined signals will have to be handled on a case-by-case basis. B.2.2 PSK Services Figure B-3 depicts the functional configuration for the TDRSS for MA, SSA, KuSA and KaSA forward PSK modulation services, which are BPSK, SS-BPSK and QPSK. For QPSK modulation, the I channel contains the command data and is modulo-2 added to a 3 Mcps PN code and the Q channel is a 3 Mcps PN code, which is used for ranging. For BPSK modulation, the I channel contains the command data and directly PSK modulates the carrier. Forward data formatting, rate 1/2 convolutional, and BCH encoding are available for WDISC customers and should be discussed with GSFC Code 450. Otherwise, the TDRSS does not perform any type of data conditioning on the forward service data.

Revision 9

B-3

450-SNUG

Table B-1. Forward Service Modulation and Data Rate Restrictions

Modulation Category PSK Modulation Scheme (note 1) QPSK (note 2) SS-BPSK (note 8) BPSK (note 7) PM Direct PM (note 6) PSK Subcarrier PM (note 6) Service and Data Rate Restrictions (note 5) MA/SMA 0.1 300 kbps 0.1 300 kbps Not available Not available Not available 0.1 300 kbps 0.1 300 kbps 300 kbps < data rate < 7 Mbps 0.125 kbps -1 Mbps 0.125 kbps 8 kbps (note 4) Notes: 1. The TDRSS spacecraft is capable of bent-pipe operation to support customer defined (non-TDRSS) signal formats. Non-TDRSS signal formats may require the addition of SN ground terminal modulation/demodulation equipment. Precise performance and the SN support of these customer-defined signals will have to be handled on a case-by-case basis. SSA KuSA 1 300 kbps 1 300 kbps 300 kbps < data rate < 25 Mbps (note 3) Not available Not available KaSA 1 300 kbps 1 300 kbps 300 kbps < data rate < 25 Mbps (note 3) Not available Not available

Revision 9 B-4 450-SNUG

2. The I channel contains the command data and is modulo-2 added to a 3 Mcps PN code and the Q channel is a 3 Mcps PN code. 3. The current WSC data interface supports up to 7 Mbps; however, upgrades to support up to 25 Mbps are planned. 4. 5. The command data is used to BPSK modulate a sinusoidal or square-wave subcarrier, which will linearly phase modulate the carrier. Subcarrier frequency/bit rate ratio = 2n, where n=1...7 for NRZ formats and n=27 for Biphase formats, where subcarrier frequencies supported are 2, 4, 8, or 16 kHz. For PSK customers, the forward data rate in this table is the baud rate that will be transmitted by the TDRSS (includes all coding and symbol formatting). For PM customers, the data rate restrictions given in this table assume an uncoded signal that is NRZ formatted. The SN supports forward data conditioning operations for WDISC and SSA PM forward link customers. These data conditioning operations include forward link rate 1/2 convolutional coding, BCH encoding, and data format conversion for WDISC customers and data format conversion for SSA PM customers. For all other SN customers, forward link data conditioning is transparent to the SN and, if used, should be performed by the customer prior to transmission to the SN data interface. Refer to Section 3, paragraph 3.6 for a description of SN data interfaces, associated constraints, and WDISC capabilities. The PM modulation index can be: 1) 0.2 to 1.5 radians or /2 radians for Direct PM and PSK Squarewave Subcarrier PM and 2) 0.2 to 1.8 radians for PSK Sinewave Subcarrier PM. For BPSK modulation, the I channel contains the command data and directly PSK modulates the carrier. The SN is capable of supporting BPSK signals at data rates < 300 kbps; however, its use will be constrained and must be coordinated with GSFC Code 450. Customers who operate in a SS-BPSK mode for one service cannot reconfigure any of their Forward Services (i.e., MAF, SMAF, SSAF, KuSAF, or KaSAF) to an UQPSK mode. Contact Code 450 if additional flexibility is required.

6. 7. 8.

SN Ground Terminal
Data rates < 300 kbps

Data rates > 300 kbps

Revision 9 B-5 450-SNUG

Modulo-2 Adder

BPSK Modulator

TDRS

PN Code Generator (Command Channel)

Doppler Compensator

Inhibit Initiate

To Customer Platform

Epoch

Code Clock

Frequency Synthesizer

Stable Frequency Source

90 Phase Delay

For SS-BPSK (data rates < 300 kbps) and BPSK (data rates > 300 kbps)

For QPSK (data rates < 300 kbps)

PN Code Generator (Ranging Channel)

BPSK Modulator 10 dB attenuator Notes:

1. Data conditioning operations are available to WDISC customers. Otherwise, the TDRSS is transparent to the data format and the particular data format to be used will be established in the customer MOC. Data polarity ambiguity is resolved on the customer platform. 2. The resulting signal to a customer platform must not violate flux density considerations. Operational restrictions must be observed. 3. For data rates > 300 kbps, PN modulation is never used. 4. The SN is capable of supporting BPSK signals at data rates less than 300 kbps; however, its use will be constrained and must be coordinated with GSFC Code 450.

Figure B-3. TDRSS Functional Configuration for PSK Forward Services

B.2.2.1 PSK I-Q Channel Ambiguity When two channels are used on the forward link (i.e., QPSK modulation), the I-Q channel ambiguity is resolved by the PN code and power ratio separation between the command and range channels. When there is a single data channel on the forward link (i.e., SS-BPSK and BPSK modulation), there is no I-Q channel ambiguity for these modulation types. B.2.2.2 PSK Data Polarity Ambiguity If NRZ-M, NRZ-S, Biphase-M, or Biphase-S data formats are used, the customer platform can resolve the data polarity ambiguity by differential decoding of the data; i.e., -M or -S to -L format conversion. If NRZ-L or Biphase-L data format is used, data polarity ambiguity will exist and it is the customers responsibility to utilize other techniques, such as frame synchronization to an a priori data (sync) word or its complement, to resolve the data polarity ambiguity. B.2.3 PM Forward Services (SSA Only) Figure B-4 depicts the functional configuration for the TDRSS SSA PM services. For a Direct PM scheme, the command data directly phase modulates the data with a modulation index of 0.2 to 1.5 radians or /2 radians. For a PSK subcarrier PM scheme, the command data BPSK modulates either a sinusoidal or square-wave subcarrier, which linearly phase modulates the carrier. The SN can perform data formatting operations; these customer signal characteristics should be discussed with GSFC Code 450 prior to service to determine if the formatting will be performed by the customer MOC prior to the SN interface or at the SN. B.2.3.1 PM I-Q Channel Ambiguity There is no I-Q channel ambiguity for these modulation types as they use a single data channel. B.2.3.2 PM Data Polarity Ambiguity If NRZ-M, NRZ-S, Biphase-M, or Biphase-S data formats are used, the customer platform can resolve the data polarity ambiguity by differential decoding of the data; i.e., -M or -S to -L format conversion. If NRZ-L or Biphase-L data format is used, data polarity ambiguity will exist and it is the customers responsibility to utilize other techniques, such as frame synchronization to an a priori data (sync) word or its complement, to resolve the data polarity ambiguity.

Revision 9

B-6

450-SNUG

Revision 9 B-7
1. 2. 3.

SN Ground Terminal
Data Formatting (note 1)

Data rates 0.125 kbps -1 Mbps Residual Carrier Direct Data Phase Modulation

Data rates 0.125 kbps 8 kbps Residual Carrier with Subcarrier PSK Modulation

Subcarrier Modulator (modulation index = /2 radians)

Phase Modulator (for modulation index values see note 3)

TDRS

Square/Sine Wave Subcarrier

Doppler Compensation

Inhibit Initiate To Customer Platform

Stable Frequency Source at 2, 4, 8, or 16 kHz

Frequency Synthesizer

Stable Frequency Source

Notes:
The TDRSS may be transparent to the data format; however, the SN can perform symbol/data formatting operations and these customer signal characteristics should be discussed with GSFC Code 450 prior to service. Data phase ambiguity is resolved on the customer platform. The resulting signal to a customer platform must not violate flux density considerations. Operational restrictions must be observed. The PM modulation index can be: 1) 0.2 to 1.5 radians or /2 radians for direct data phase modulation and PSK squarewave subcarrier PM and 2) 0.2 to 1.8 radians for PSK sinewave subcarrier phase modulation. The SN supports subcarrier frequency/bit rate ratio = 2n, where n=1...7 for NRZ formats and n=27 for Biphase formats.

450-SNUG

4.

Figure B-4. TDRSS Functional Configuration for PM Forward Services

B.3

Return Service

B.3.1 General The customer/SN end-to-end system functional configuration for return service is shown in Figure B-5. Return data generated in the customer platform undergoes various baseband data conditioning operations (i.e., data format conversion, data demultiplexing for alternate bits on the I and Q channels, convolutional encoding, symbol format conversion, and symbol interleaving) and RF signal processing (spectrum spreading, modulation, I/Q-channel power weighting, and frequency upconversion) prior to transmission to the TDRSS. At the WSC, the inverse RF signal processing (frequency downconversion, despreading, and demodulation) and baseband signal processing (symbol synchronization, symbol format conversion, symbol deinterleaving, Viterbi decoding, data format conversion, and data interleaving of the Iand Q-channel data bits) are performed. The return service data at the WSC/SN data interface will always be treated as NRZ-L. For example, if NRZ-M data formatting is scheduled, the SN will perform NRZ-M to NRZ-L data format conversion. If SN customers would like their data format to be unaltered by the SN (i.e., in the example just given, they would like to receive NRZ-M data rather than NRZ-L data at the SN data interface), then customers need to schedule through the SN as if their data format is NRZ-L; then the SN will not perform any data format conversion. Refer to Section 3, paragraph 3.6, for information concerning data interface capabilities and restrictions.

SN RF Interface
Customer Platform Data Conditioning Operations TDRSS

SN Data Interface

Data Sources

Transponder Configuration

TDRS

WDISC DAS MDM SN Ground Local Terminal Interface IF High Data Rate

Customer MOC

NRZ or Bi

Figure B-5. Return Service End-to-End System Functional Configuration

Revision 9

B-8

450-SNUG

The SN return services are divided into 2 major groups, Data Group 1 (DG1) and Data Group 2 (DG2). DG1 services utilize spread spectrum modulation while DG2 services are non-spread. Figure B-6 depicts the customer platform data communication functional configurations for DG1 and DG2 return services, where the data conditioning operations are shown in Figure B-7 through Figure B-9 for the specific Data Group and mode configuration. NOTE: KaSA return does not support DG1 services. B.3.2 DG1 Services Within each data group, there are several types of modulation. DG1 services are subdivided into three modes of operation, DG1 modes 1, 2, and 3. DG1 services support several types of modulation and configurations, which are described in paragraph B.3.2.1. Paragraphs B.3.2.2 and B.3.2.3 describe DG1 I-Q channel ambiguity and data polarity ambiguity, respectively. B.3.2.1 DG1 Configurations

a. Balanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2 only). I and Q channels consist of identical data that is synchronous and identically formatted, and rate 1/2 convolutionally coded (if applicable). The signal is transmitted using balanced (I/Q power ratio is 1:1) SQPN modulation. Table B-2 lists the service configuration constraints, where the I channel data rate = Q channel data rate = source data rate. The data conditioning operations supported are shown in Figure B-7 for this configuration, where the channel data source represents the single data source with identical data conditioning operations performed on both the I and Q channels. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN. b. Balanced Power Single Data Source-Alternate I/Q Bits (SMAR and SSAR DG1 mode 1 and 2). I and Q channels consist of alternate bits of the same data source and each channel will be identically but independently and differentially formatted and rate 1/2 convolutionally encoded. The Q channel encoder output symbol will be delayed by a half symbol period relative to the I channel encoder output symbol. The signal is transmitted using balanced (I/Q power ratio is 1:1) SQPN modulation. Table B-2 lists the service configuration constraints, where the I channel data rate = Q channel data rate = 1/2 source data rate. The data conditioning operations supported are shown in Figure B-7 for this configuration, where the channel data source represents the I and Q channels after decommutation from the single data source and the I and Q channels are identically but independently data conditioned. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN.

Revision 9

B-9

450-SNUG

DG2 Data Source Data Conditioner a, bI, cI (see Figures B-7, bQ B-8, and B-9) I Channel

I:Q Power Ratio DG1: 1:1 to 1:4

Mode 2

Mode 1

Revision 9 B-10 450-SNUG

+
DG1 Modes 1 and 3 Long PN Code Generator Coherent Clock: S-band: Modes 1 and 3 (240/221)FR Ku-band: (1600/1469)FR Noncoherent Clock: Spacecraft Local Oscillator

Carrier Frequency Generator BPSK

To TDRS

Mode 2
Key: Modulo 2 Adder BPSK Modulator FR = Customer Received Frequency

Short PN Code Generator

Mode 2

+
Delay 1/2 Chip Mode 2 1/2 Symbol Delay (note 2) Q Channel Delay 1/2 Chip (note 3) Mode 1 90 Phase Delay

Data Source

Data Conditioner (see Figures B-7 and B-8)

bQ

DG1 Modes 1 and 2

cQ

DG1 Mode 3 and DG2 Notes:

I:Q Power Ratio DG2: 1:1 or 4:1

1. a, b, c denote the output of the data conditioner, where: a = Single data source with data on single data channel (BPSK) b = Single data source with data on both the I channel (bI) and Q channel (bQ), which can be configured as either: 1) Identical data on I and Q channels (DG1 Modes 1 and 2); 2) Alternate I/Q data bits (DG1 Modes 1 and 2 for SSA and SMA and DG2) with 1:1 I:Q power ratio; 3) Alternate I/Q encoded symbols (DG2) with 1:1 I:Q power ratio c = Dual data sources with data on both the I channel (cI) and Q channel (cQ) 2. Delay is required for DG1 and DG2 alternate I/Q data bit configuration, DG2 alternate symbol configuration, and DG2 dual data source SQPSK configuration. 3. Q channel PN code sequence is identical to the I channel PN Code sequence, but delayed by X + 1/2 chip, where X is dependent upon the unique customer PN code assignment.

Figure B-6. Customer Platform Functional Configuration for DG1 and DG2

Revision 9
From channel data source (see Figure B-6) NRZ-L NRZ-L, Data Format -M, or -S Converter

Uncoded (KuSA only)

To channel modulator (a, bI, bQ, c in Figure B-6)

Normal G1, G2, G1,... Rate 1/2 Data Encoder (see Figure B-10) Inverted
G1, G2, G1,...

Data format

Symbol format

Where channel data source is as follows for each possible configuration: a. Single data source with single data channel (BPSK): I channel data stream = channel data source b. Single data source with data on both the I channel and Q channel, which can be configured as either: 1) Identical data on I and Q channels: channel data source = I channel data source = Q channel data source [identical data conditioning operations on I and Q channels (i.e., data/symbol format/coding and synchronous data (time aligned)] 2) Alternate data bits on I and Q channels (SSA and SMA only): I and Q channel data streams are alternate data bits of the same single data source [identical but independent data conditioning operations on I and Q channels (i.e., identical formatting and coding)] Rd/2 I channel data stream = channel data source into this data conditioner Single data source Q channel data stream = channel data source into this data conditioner Rd R = 1/Tb Rd/2 Switch is at each position for Td seconds, where Td=1/Rd c. Dual Data Sources: channel data source represents I and Q channel data sources separately [independent data conditioning operations]; channel data source = I Channel of DG1 mode 3 Notes: 1. For the single data source alternate I/Q data-bit configuration, NRZ-M or NRZ-S data format conversion is required to resolve the data polarity ambiguity and to reconstruct the single data channel at the SN ground terminal. 2. If the data format is NRZ-L, the SN ground terminal does not resolve the data polarity ambiguity. If the data format is NRZ-M or NRZ-S, the SN ground terminal resolves the data polarity ambiguity.

B-11 450-SNUG

Figure B-7. Data Conditioning Operations for DG1 Modes 1 and 2 (I and Q Channels) and DG1 Mode 3 I Channel

Revision 9 B-12 450-SNUG

Uncoded (KuSA and KaSA)

From channel data source (see Figure B-6) NRZ-L

NRZ-L, -M, or Data Format -S Converter

Normal N parallel Rate 1/2 G1, G2, G1,... Data Encoders (N = 1 for data Inverted rates < 10 Mbps) (see Figure B-10) G1, G2, G1,...

Symbol Format Converter

Bi (DG2 S-band only)

Data format Rate 1/3 Data Encoder (SMA and SSA only) (see Figure B-10) Symbol Format Converter

Interleaver S-band baud (PCI) Bi (DG2 S-band only)

rates > 300 kbps

To channel modulator (a, bI, bQ, c in Figure B-6)

Symbol rates > 300 kbps format Where channel data source is as follows for each possible configuration: a. Single data source with single data channel (BPSK): I channel data stream = channel data source b. Single data source with data on both the I channel and Q channel, which can be configured as: 1) Alternate data bits on I and Q channels: I and Q channel data streams are alternate data bits of the same single data source [identical but independent data conditioning operations on I and Q channels (i.e., identical formatting and coding)] Rd/2 I channel data stream = channel data source into this data conditioner Single data source Q channel data stream = channel data source into this data conditioner Rd Rd/2 Switch is at each position for Td seconds, where Td=1/Rd c. Dual Data Sources: channel data source represents I and Q channel data sources separately [independent data conditioning operations]; channel data source = Q Channel of DG1 mode 3 Notes: 1. For the SQPSK alternate I/Q data-bit configuration, NRZ to Bi conversion is not allowed. However, NRZ-M or NRZ-S data format conversion is required to resolve the data polarity ambiguity and to reconstruct the single data channel at the SN ground terminal. This configuration is supported for KuSAR and KaSAR single data sources > 10 Mbps. 2. If the data format is NRZ-L or Biphase-L, the SN ground terminal does not resolve the data polarity ambiguity. If the data format is NRZ-M, NRZ-S, Biphase-M, or Biphase-S, the SN ground terminal resolves the data polarity ambiguity. 3. Biphase symbol formatting is only allowed for S-band DG2 BPSK or QPSK modes.

G1, G2, G3, G1, G2, G3, G1,

Interleaver (PCI) S-band baud

Figure B-8. Data Conditioning Operations for DG1 Mode 3 Q Channel and DG2 (except SQPSK with Alternate I/Q Encoded Symbols)

Revision 9
G1, G1, G1,

From single data source < 10 Mbps for KuSA or KaSA (see Figure B-6) Data Format < 300 kbps for SMA or SSA Converter NRZ-L, -M, or -S NRZ-L

To I-channel modulator (bI in Figure B-6)

Rate 1/2 Encoder (see Figure B-10) Normal

G2, G2, G2, ...

Inverted

G2, G2, G2, ...

To Q-channel modulator (bQ in Figure B-6)

B-13 450-SNUG

Data format

Symbol format

Notes: 1. If the data format is NRZ-L, the SN ground terminal does not resolve the data polarity ambiguity. 2. If the data format is NRZ-M or NRZ-S, the SN ground terminal resolves the data polarity ambiguity.

Figure B-9. Data Conditioning Operations for DG2 SQPSK with Alternate I/Q Encoded Symbols

Table B-2. Data Configuration Constraints for DG1 Modes 1 and 2, Single Data Source
Revision 9 B-14 450-SNUG
Coding (note 4) Rate 1/2 NRZ Data Format Source Data Rate Restrictions and Availability (note 1) Configuration Single Data Channel (BPSK) Identical Data on I and Q channels Alternate I and Q bits Rate 1/3 Uncoded NRZ NRZ NA Single Data Channel (BPSK) Identical Data on I and Q channels NA Note 3 1 kbps - 300 kbps NA < 150 kbps NA NA < 150 kbps < 300 kbps NA 1 kbps - 150 kbps NA NA NA NA NA MA (note 2) SMA and SSA (note 2) KuSA KaSA

Notes: NA: Not Available 1. The channel data rate restrictions are as follows: a. For single data source configurations with identical data on both I and Q channels: channel data rate = source data rate b. For single data source configuration with alternate bits on the I and Q channels: channel data rate = I channel data rate = Q channel data rate = 1/2 the source data rate. The I/Q (power) must be 1:1. c. For a BPSK signal configuration: channel data rate restriction is maximum data rate for the channel 2. Minimum data rate for MA, SMA, and SSA services: DG1 Mode 1: 0.1 kbps DG1 Mode 2: 1 kbps 3. The SN is capable of supporting SMA and SSA uncoded return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 4. Figure B-10 describes the convolutional encoders supported by the SN.

G1

Revision 9 B-15 450-SNUG

Normal
G1, G2, G1, ...

Encoder G2 Inverted Inverter

G1, G2, G1, ...

Encoder

G1 G2 G3

G1, G2, G3, G1, G2, G3, G1,

Inverter

Rate 1/2 Data Encoder

Rd Rd Rd Commutators: Rs/2 Rs

Key:
Rs

Rate 1/3 Data Encoder

Decommutator: Rs/2 Rs Switches are at each position for TS seconds where TS=1 /RS= symbol duration

Rs/2 Rs/2 Encoders: convolutional, nonsystematic, transparent Rate 1/2: Generator Functions: G1 = 1111001; G2 = 1011011 Symbols generated from G1 must precede symbols generated from G2 relative to the data bit period. The SN can support symbols generated from G2 that are either true or complemented. However, G2 symbol inversion provides an increased symbol transition density for a convolutional encoder input data signal with low transition density, which aids the SN ground terminal clock (symbol) synchronization. Rate 1/3: Generator Functions: G1 = 1111001; G2 = 1011011; G3 = 1110101 The symbol sequence must be generated from G1, G2, and G3 successively relative to the data bit period. Alternate symbols generated from the convolutional encoding must be complemented. Normal n=1 Rate 1/2 Data G1, G2, G1, ... Encoders Inverted
G1, G2, G1, ...

Key: Parallel Encoders

Decommutator: n=1
G1,G1,G1,G2,G2,G1, or G1,G1,G1,G2,G2,G1,...

Rd

n=1 R /N d

NRZ Only

Normal Rate 1/2 Data Encoders n=N

Rd 1 x 10
7

G1, G2, G1, ...

n=N

Inverted
G1, G2, G1, ...

n=N Rd/N Switch is at each position for Td seconds where Td=1 /Rd= bit duration Commutator: Rs/N n=1 Rs Rs/N n=N Switch is at each position for TS seconds where TS=1 /RS= symbol duration; RS= 2 Rd

N Parallel Rate 1/2 Data Encoders

N= Rounded to the next highest integer if N Integer

N = Number of parallel code 1 data encoders for the channel Rd = Channel data rate (bps)

Figure B-10. Data Encoders

c.

Unbalanced Power Single Data Source-Identical Data on the I and Q Channels (DG1 mode 1 and 2 only). I and Q channels consist of identical data that is synchronous and identically formatted, and rate 1/2 convolutionally coded (if applicable). The signal is transmitted using unbalanced (I/Q power ratio can be weighted up to a maximum of 1:4) SQPN modulation. Table B-2 lists the service configuration constraints, where the I channel data rate = Q channel data rate = source data rate. The data conditioning operations supported are shown in Figure B-7 for this configuration, where the channel data source represents the single data source with identical data conditioning operations performed on both the I and Q channels. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN.

d. Single Data Source with Single Data Channel (DG1 modes 1 and 2 only). Either the I or Q channel consists of data that has been formatted and rate 1/2 convolutionally encoded (if applicable). The channel is modulo-2 added asynchronously to the channel PN code. The signal is transmitted using BPSK modulation. Table B-2 lists the service configuration constraints. The data conditioning operations supported are shown in Figure B-7 for this configuration. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN. e. Balanced Power Dual Data Sources. The I and Q channels consist of independent data that is independently formatted, convolutionally coded (if applicable), and symbol interleaved (if applicable on the Q channel only). For DG1 modes 1 and 2, the signal is transmitted using balanced (I/Q power ratio is 1:1) SQPN modulation. For DG1 mode 3, the I channel is modulo-2 added asynchronously to the channel PN code and the Q channel directly PSK modulates the carrier. The signal is transmitted using balanced (I/Q power ratio is 1:1) power. Table B-3 lists the service configuration constraints for DG1 modes 1 and 2, where the source data rate constraints apply to each channel separately. Table B-4 lists the service configuration constraints for DG1 mode 3, where the source data rate constraints apply to each channel separately. The data conditioning operations supported for this configuration are shown in Figure B-7 for DG1 modes 1, 2, and 3 I channel, where the channel data source represents each of the I and Q channel sources separately for independent data conditioning operations. Figure B-8 presents the data conditioning operations for DG1 mode 3 Q channel. Figure B-10 describes the convolutional encoders supported by the SN. f. Unbalanced Power Dual Data Sources. The I and Q channels consist of independent data that is independently formatted, convolutionally coded (if applicable), and symbol interleaved (if applicable on the Q channel only). For DG1 modes 1 and 2, the signal is transmitted using unbalanced (I/Q power ratio can be weighted up to a maximum of 1:4) SQPN modulation. For DG1 mode 3, the I channel is modulo-2 added asynchronously to the channel PN code and

Revision 9

B-16

450-SNUG

Revision 9 B-17 450-SNUG

Table B-3. Data Configuration Constraints for DG1 Modes 1 and 2, Dual Data Sources
Channel Coding (note 4) Rate 1/2 Rate 1/3 Uncoded Data Format NRZ NRZ NRZ Source Data Rate Restrictions and Availability (note 1) MA and SMA (note 2) < 150 kbps NA Note 3 SSA (note 2) < 150 kbps NA Note 3 KuSA 1 kbps - 150 kbps NA 1 kbps - 300 kbps KaSA NA NA NA

Notes: NA: Not Available 1. For dual data source configurations, the channel data rate restrictions are equivalent to the source data rate and apply to each channel separately. 2. Minimum data rate for MA, SMA, and SSA services: DG1 Mode 1: 0.1 kbps DG1 Mode 2: 1 kbps 3. The SN is capable of supporting uncoded SSA and SMA return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 4. Figure B-10 describes the convolutional encoders supported by the SN.

Revision 9 B-18 450-SNUG

Table B-4. Data Configuration Constraints for DG1, Mode 3

I Channel Data Rate and Availability Coding (note 4) Data Format NRZ SMA 0.1 kbps 150 kbps NA SSA 0.1 kbps 150 kbps NA KuSA 1 kbps 150 kbps NA MA and KaSA NA Q Channel Data Rate and Availability SMA 1 kbps 1.5 Mbps (note 1) 1 kbps 1 Mbps (note 1) SSA 1 kbps 3 Mbps (note 1) 1 kbps 2 Mbps (note 1) KuSA 1 kbps 3 Mbps NA MA and KaSA NA

Rate 1/2

Rate 1/3 Uncoded

NRZ

NA

NA

1 kbps NA Note 2 Note 2 1 kbps NA 300 kbps 6 Mbps Notes: NA: Not Available 1. Periodic convolutional interleaving (PCI) recommended on SMA and SSA return service for baud rates > 300 kbps. When interleaving is not employed for baud rates > 300 kbps, SSA and SMA performance may not be guaranteed. 2. The SN is capable of supporting SMA and SSA uncoded return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 3. Figure B-10 describes the convolutional encoders supported by the SN.

NRZ

Note 2

Note 2

the Q channel directly PSK modulates the carrier. The signal is transmitted using unbalanced (I/Q power ratio can be weighted up to a maximum of 1:4) power. Table B-3 lists the service configuration constraints for DG1 modes 1 and 2, where the source data rate constraints apply to each channel separately. Table B-4 lists the service configuration constraints for DG1 mode 3, where the source data rate constraints apply to each channel separately. The data conditioning operations supported for this configuration are shown in Figure B-7 for DG1 modes 1, 2, and 3 I channel, where the channel data source represents each of the I and Q channel sources separately for independent data conditioning operations. Figure B-8 presents the data conditioning operations for DG1 mode 3 Q channel. Figure B-10 describes the convolutional encoders supported by the SN. B.3.2.2 DG1 I-Q Channel Ambiguity

For DG1 modes 1 and 2 operation, there is no I-Q channel ambiguity because the PN codes on the I and Q channels are different. For DG1 mode 3 operation, there is no I-Q channel ambiguity since the WSC resolves the I and Q channels by PN correlation and knowledge of the I/Q power ratio. B.3.2.3 DG1 Data Polarity Ambiguity For NRZ-M or NRZ-S customer data formats, the WSC resolves the data polarity ambiguity by differentially decoding the return service data to NRZ-L. For NRZ-L customer data formats, data polarity ambiguity will exist at the WSC/SN data interface and it is the customers responsibility to utilize other techniques, such as frame synchronization to an a priori data (sync) word or its complement, to resolve the data polarity ambiguity. NOTE: The DG1 modes 1 and 2 single data source configuration with alternate I/Q data bits requires that the I and Q channels be differentially encoded to either NRZ-M or NRZ-S in order to recover the single data source, as well as, resolve data polarity ambiguity. Without differential encoding, the single data source may have the alternate bits inverted. B.3.3 DG2 Services DG2 services support several types of modulation and configurations, which are described in paragraph B.3.3.1. Paragraphs B.3.3.2 and B.3.3.3 describe DG2 I-Q channel ambiguity and data polarity ambiguity, respectively.

Revision 9

B-19

450-SNUG

NOTE: MA return does not support DG2 services. B.3.3.1 DG2 Configurations

a. Balanced Power Single Data Source-Alternate I/Q Bits. I and Q channels consist of alternate bits of the same data source and each channel will be identically but independently and differentially formatted, and rate 1/2 convolutionally encoded (if applicable). The Q channel symbol will be delayed by a half symbol period relative to the I channel symbol. The signal is transmitted using balanced (I/Q power ratio is 1:1) SQPSK modulation. Table B-5 lists the service configuration constraints, where the I channel data rate = Q channel data rate = 1/2 source data rate. The data conditioning operations supported are shown in Figure B-8 for this configuration, where the channel data source represents the I and Q channels after decommutation from the single data source and the I and Q channels are identically but independently data conditioned. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN. b. Balanced Power Single Data Source-Alternate I/Q Encoded Symbols. I and Q channels consist of the two concurrent output symbols of a rate 1/2 convolutional encoder, where the G1 output of the encoder is on the I channel and the G2 output of the encoder is on the Q channel. The Q channel will be delayed by a half symbol period relative to the I channel. The channels are transmitted using balanced (I/Q power ratio is 1:1) SQPSK modulation. Table B-5 lists the service configuration constraints, where the I channel data rate = Q channel data rate = 1/2 source data rate. The data conditioning operations supported are shown in Figure B-9 for this configuration. Figure B-10 describes the rate 1/2 convolutional encoder supported by the SN. c. Single Data Source with Single Data Channel. The source data, that has been formatted and convolutionally encoded (if applicable), directly BPSK modulates the carrier. Table B-6 lists the service configuration constraints. The data conditioning operations supported are shown in Figure B-8 for this configuration. Figure B-10 describes the convolutional encoders supported by the SN.

d. Balanced Power Dual Data Sources. The I and Q channels consist of independent data that is independently formatted, convolutionally coded (if applicable), and symbol interleaved (if applicable). The signal is transmitted using balanced (I/Q power ratio is 1:1) QPSK or SQPSK modulation. Table B-7 lists the service configuration constraints, where the source data rate constraints apply to each channel separately. The data conditioning operations supported are shown in Figure B-8 for this configuration, where the channel

Revision 9

B-20

450-SNUG

Table B-5. Data Configuration Constraints for DG2, Single Data Source (SQPSK)
Source Data Rate Restrictions and Availability (note 1) Configuration KuSA and MA SMA SSA KaSA 1 kbps 1 kbps >10 Mbps Alternate I and Q NA 3 Mbps 6 Mbps 75 Mbps bits (note 2) Rate 1/2 NRZ (note 3) (note 3) (note 6) 1 kbps 1 kbps Alternate I and Q 1 kbps symbols 300 kbps 300 kbps 10 Mbps 1 kbps 1 kbps Alternate I and Q Rate 1/3 NRZ NA 2 Mbps 2 Mbps NA bits (note 2) (note 3) (note 3) Alternate I and Q 1 kbps Uncoded NRZ NA Note 4 Note 4 bits (note 2) 300 Mbps Notes: 1. For SQPSK modulation, the I/Q (power) = 1:1 and the I channel data rate = Q channel data rate = 1/2 the source data rate. 2. For the alternate I and Q bit configuration, the data format must be NRZ-L. On each channel, the data bits are identically but independently and differentially encoded and then convolutionally encoded (if desired) prior to transmission. 3. Periodic convolutional interleaving (PCI) recommended on SMA and SSA return service for baud rates > 300 kbps. When interleaving is not employed for baud rates > 300 kbps, SSA and SMA performance may not be guaranteed. 4. The SN is capable of supporting SMA and SSA uncoded return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 5. Figure B-10 describes the convolutional encoders supported by the SN. 6. For rate 1/2 coding and source data rates greater than 20 Mbps (i.e., channel data rates greater than 10 Mbps), the customer transmitter must be configured to use N-parallel encoders, where N is the number of branch rate 1/2 encoders for each of the I and Q 7 channels. N = channel data rate in bps/1x10 , where N is rounded to the next higher integer if N is not an integer. Coding (note 5) Data Format

data source represents each of the I and Q channel sources separately for independent data conditioning operations. Figure B-10 describes the convolutional encoders supported by the SN. e. Unbalanced Power Dual Data Sources (SMA or SSA only). The I and Q channels consist of independent data that is independently formatted, convolutionally coded (if applicable), and symbol interleaved (if applicable). The signal is transmitted using unbalanced (I/Q power ratio is 4:1) QPSK or SQPSK modulation. Table B-7 lists the service configuration constraints, where the source data rate constraints apply to each channel separately. The data conditioning operations supported are shown in Figure B-8 for this configuration, where the channel data source represents each of the I and Q channel sources separately for independent data conditioning operations. Figure B-10 describes the convolutional encoders supported by the SN.

Revision 9

B-21

450-SNUG

Table B-6. Data Configuration Constraints for DG2, BPSK

Source Data Rate Restrictions and Availability KuSA and MA SMA SSA KaSA 1 kbps 1 kbps 1 kbps NRZ NA 1.5 Mbps 3 Mbps 75 Mbps (note 1) (note 1) (notes 4, 6) Rate 1/2 1 kbps 1 kbps NRZ with Bi NA NA 0.75 Mbps 1.5 Mbps symbols (notes 1, 2) (notes 1,2) NA Note 3 Note 3 NA Bi 1 kbps Uncoded NRZ NA Note 3 Note 3 150 Mbps (note 4) 1 kbps 1 kbps NRZ NA NA 1 Mbps 2 Mbps (note 1) (note 1) Rate 1/3 1 kbps 1 kbps NRZ with Bi NA NA 0.5 Mbps 1 Mbps symbols (notes 1, 2) (notes 1,2) Notes: NA: Not Available 1. Periodic convolutional interleaving (PCI) recommended on SMA and SSA return service for baud rates > 300 kbps. When interleaving is not employed for baud rates > 300 kbps, SSA and SMA performance may not be guaranteed. 2. Bi symbol formats are not allowed with PCI. 3. The SN is capable of supporting SMA and SSA uncoded return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 4. Higher KaSA return link data rates are possible through the automated Ka-band 650 MHz bandwidth IF service. Please contact GSFC Code 450 for further information. 5. Figure B-10 describes the convolutional encoders supported by the SN. 6. For a channel with rate 1/2 coding and data rates greater than 10 Mbps, the customer transmitter must be configured to use an N-parallel encoder, where N is the number of branch rate 1/2 encoders for the channel. N = channel data rate in bps/1x107, where N is rounded to the next higher integer if N is not an integer. Coding (note 5) Data Format

B.3.3.2 DG2 I-Q Channel Ambiguity For the DG2 single data source SQPSK configurations (i.e., alternate I/Q data bit and alternate I/Q encoded symbols), I-Q channel ambiguity is resolved by the stagger between the I and Q channels. For a DG2 single data source BPSK configuration, I-Q channel ambiguity does not exist because there is no quadrature component of the customer platform transmitted carrier signal.

Revision 9

B-22

450-SNUG

Table B-7. Data Configuration Constraints for DG2, Dual Data Sources (QPSK, SQPSK)
Source Data Rate Restrictions and Availability (note 5) (data rates are for each channel separately) SMA SSA KuSA and MA (notes 6, 9) (notes 6, 9) KaSA 1 kbps 1 kbps 1 kbps NRZ NA 1.5 Mbps 3 Mbps 75 Mbps Rate 1/2 (note 1) (note 1) (notes 4, 8) (Either 1 kbps 1 kbps Channel) NRZ with NA NA 0.75 Mbps 1.5 Mbps Bi symbols (notes 1, 2) (notes 1, 2) 1 kbps 1 kbps NRZ NA NA 1 Mbps 2 Mbps Rate 1/3 (note 1) (note 1) (Either 1 kbps 1 kbps Channel) NRZ with NA NA 0.5 Mbps 1 Mbps Bi symbols (notes 1, 2) (notes 1,2) 1 kbps Uncoded NRZ NA Note 3 Note 3 150 Mbps (Either (note 4) Channel) NA Note 3 Note 3 NA Bi Notes: NA: Not Available 1. Periodic convolutional interleaving (PCI) recommended on SMA and SSA return service for baud rates > 300 kbps. When interleaving is not employed for baud rates > 300 kbps, SSA and SMA performance may not be guaranteed. 2. Bi symbol formats are not allowed with PCI. 3. The SN is capable of supporting SMA and SSA uncoded return link signals; however, its use will be constrained and must be coordinated with GSFC Code 450. 4. Higher KaSA return link data rates are possible through the automated Ka-band 650 MHz bandwidth IF service. Please contact GSFC Code 450 for further information. 5. For DG2 dual sources with identical symbol rates that are NRZ formatted on the I and Q channels, the I and Q channels must be offset relative to one another by one half symbol period (i.e., SQPSK modulation). Additionally, for DG2 dual sources that use biphase symbol formatting (S-band only) on either channel and the baud rate of the two channels are identical, SQPSK modulation is used and the transition of one channel occurs at the mid-point of adjacent transitions of the other channel. 6. For unbalanced QPSK (SMA and SSA only), the I channel must contain the higher data rate and when the data rate on the I channel exceeds 70 percent of the maximum allowable data rate, the Q channel data rate must not exceed 40 percent of the maximum allowable data rate on that Q channel. 7. Figure B-10 describes the convolutional encoders supported by the SN. 8. For a channel with rate 1/2 coding and data rates greater than 10 Mbps, the customer transmitter must be configured to use an N-parallel encoder, where N is the number of branch rate 1/2 encoders for the channel. N = channel data rate in bps/1x107, where N is rounded to the next higher integer if N is not an integer. 9. For S-band DG2, dual data channel, balanced power configurations, the minimum total (I+Q) data rate must be 60 kbps or greater. Coding (note 7) Data Format

Revision 9

B-23

450-SNUG

For the DG2 dual data source QPSK configuration, the WSC can resolve the I-Q channel ambiguity if at least one of the following conditions are met: a. I/Q power ratio is 4:1 (SMA and SSA operation only). b. One data channel is coded, the other channel is uncoded. c. One channel is rate-1/3 coded and the other channel is rate-1/2 coded (SMA and SSA operation only).

d. One channel symbol rate differs by more than 25 percent from the other channel symbol rate and from a harmonic of that symbol rate. For the DG2 dual data source SQPSK configuration, I-Q channel ambiguity is resolved when the I:Q power is 4:1 (SMA and SSA operation only). For this configuration with an I:Q power of 1:1, the I-Q ambiguity will exist at the WSC/SN data interface and it is the customers responsibility to resolve this ambiguity. B.3.3.3 DG2 Data Polarity Ambiguity For NRZ-M, NRZ-S, Biphase-M (S-band only), or Biphase-S (S-band only) customer data formats, the WSC resolves the data polarity ambiguity by differentially decoding the return service data to NRZ-L. For NRZ-L or Biphase-L (S-band only) customer data formats, data polarity ambiguity will exist at the WSC/SN data interface and it is the customers responsibility to utilize other techniques, such as frame synchronization to an a priori data (sync) word or its complement, to resolve the data polarity ambiguity. For a DG2 single data channel configuration with alternate I/Q encoded symbols (Rate 1/2), the Viterbi decoder in the WSC resolves the carrier phase ambiguity and provides a single output data signal. For a single data channel configuration with alternate I/Q data bits, convolutionally coded or uncoded, and independent differential encoding on the I and Q channel symbols, the independent differential decoding of the symbols received on the I and Q channel in the WSC prior to multiplexing of these data signals into a single data channel signal resolves the data polarity ambiguity. NOTE: The DG2 single data channel configuration with alternate I/Q data bits requires that the I and Q channels be differentially encoded to either NRZ-M or NRZ-S in order to recover the single data source, as well as resolve data polarity ambiguity. Without differential encoding, the single data source may have the alternate bits inverted.

Revision 9

B-24

450-SNUG

Appendix C. Operational Aspects of Signal and Autotrack Acquisition

C.1

General

C.1.1 This Appendix details the operational aspects associated with acquisition. A detailed description of both customer and TDRSS operations during acquisition is presented. NOTE: "Customer" is used in this Appendix as the general term. "Customer platform" or "customer MOC" is used where specificity is required. C.1.2 The intent is to provide an understanding of the many processes that occur during acquisition. This will then indicate the operations which must be performed by the customer MOC and/or customer platform to acquire the scheduled TDRSS services. C.1.3 Up to five distinct acquisition processes may be required by the combination of the customer MOC, the TDRSS, and the customer platform in acquiring a forward or return service signal. These are as follows: a. Antenna acquisition 1. 2. c. Open-loop antenna pointing (MA, SSA, SSA cross-support, KuSA with autotrack inhibited, KaSA with autotrack inhibited). Autotracking (KuSA and KaSA).

b. PN code acquisition. Carrier acquisition. d. Symbol synchronization. e. Deinterleaver (applicable only to certain SMA and SSA return service signals) and Viterbi decoder synchronization.

Revision 9

C-1

450-SNUG

NOTE: Not all of the above functions are required of every service, data group, or mode. The detailed acquisition sequences to be presented discuss how and when these operations are accomplished in establishing the appropriate forward and/or return service. C.1.4 Paragraph C.2 highlights the various parameters that impact the acquisition event sequence and/or the time to acquire (Tacq). Using a detailed timeline, paragraph C.3 describes the event sequence associated with acquisition. Paragraph C.4 concludes by addressing various issues related to reacquisition. C.2 C.2.1 Key Parameters which Impact Acquisition Sequences and Times Customer MOC Controllable Parameters

C.2.1.1 General Table C-1 summarizes the parameters which impact acquisition and which the customer MOC can either schedule prior to (refer to Section 10, paragraph 10.2) or initiate during (please see Section 10, paragraph 10.3) the scheduled service support period. The parameters are described in more detail in Sections 5 (MA), 6 (SSA), 7 (KuSA), and 8 (KaSA). Paragraphs C.2.1.2 through C.2.1.5 expand on certain aspects of these parameters. C.2.1.2 Doppler Compensation To aid in customer platform acquisition of both the forward service command and range channel PN codes and the forward service carrier, Doppler compensation should be scheduled or accommodated on the customer platform. If Doppler compensation is not scheduled, the WSC will transmit the carrier frequency and the derived PN code chip rate as specified in the SHO. If no accommodations are made on the customer platform, this fixed frequency forward service transmission may not allow acquisition and, therefore, it is recommended that the customer MOC schedule or accommodate Doppler compensation at all times so that the forward service PN code clocks and the carrier are continuously compensated to account for changing customer platform dynamics. The MOC may choose to disable Doppler compensation during ground tracking services; however, valid tracking service data is available with or without Doppler compensation enabled.

Revision 9

C-2

450-SNUG

C.2.1.3 Start of Forward Service Data It is recommended that the customer MOC not initiate forward service data transmission to the NISN data transport system until sufficient time has elapsed after the scheduled service support period start time for the customer platform to have acquired the forward service PN codes (command and range channels) and the carrier, or until forward service lock is verified by return service data. This procedure will enhance the forward service Tacq and help to prevent false carrier lock. The specific acquisition events outlined in paragraph C.3 assume that commands are not sent by the customer MOC to its customer platform unless their receipt and/or implementation by that customer platform can be confirmed by the customer MOC via telemetry. For coherent turnaround services (i.e., return services using DG1 modes 1 or 3 or DG2 [coherent operations]), this implies that the start of forward service data transmission (by the customer MOC to the NISN data transport system) should not start until the return service acquisition process is complete. C.2.1.4 Start of Return Service (Relative to the Start of the Corresponding Forward Service)

The start time of the scheduled return service support period, TR, initiates the WSC return service acquisition sequence. For a customer platform in a coherent turnaround mode of operation, it is recommended that the forward service start time precede the return service start time by sufficient time to allow the customer platform acquire the forward service and provide the coherent return signal. Typically, the forward service start time precedes the return service start time by 30 seconds for coherent services. C.2.1.5 Start of Return Service Data Transmission

a. The customer platform should be scheduled/commanded to initiate return service data transmission of desired customer platform data only after the WSC has completed all of its signal acquisition processes. This procedure helps prevent loss of desired customer platform data during this segment of the WSC acquisition process. b. After ground terminal PN code and carrier lock has occurred, the next ground terminal processes involve symbol synchronizers, and (where applicable) Viterbi decoders and a deinterleaver. The number of symbols which must be processed by each of these devices for each to achieve lock depends on the Prec and the symbol transition density of the individual customer spacecraft data channel. To avoid loss of data during these processes, it is advisable for the customer platform to transmit a preamble (e.g., a sequence of psuedo-random bits) before "real" data is sent. This may also reduce the synchronization time of this part of the return service acquisition process due to the high (50 percent) symbol transition density of such a preamble sequence.

Revision 9

C-3

450-SNUG

Revision 9 C-4 450-SNUG

Table C-1. Customer MOC Controllable Parameters Which Impact Acquisition

Parameter Initiated or Scheduled by
Customer MOC

Customer Services Affected

All forward services

Impact on Tacq

Impact on Acquisition Sequence

None

Comments

Doppler Compensation

Decreased Tacq

Recommended. Not required if customer platform has capability to resolve Doppler by onboard processing. Crucial in establishing forward service and noncoherent return service OPM allows fo reconfiguration if SHO fo is outside of both the acquisition bandwidth of the receiver and the forward frequency sweep range (forward services) or the expanded frequency uncertainty range (noncoherent) return service.

Predicted Local Oscillator (LO) Frequency (fo) (in SHO or reconfiguration OPM [Class 3])

Customer MOC

All forward services or noncoherent return services

Acquisition cannot be achieved unless the uncertainty of the predicted frequency and the unresolved Doppler are within the acquisition bandwidth of the receiver

Subsequent steps cannot be achieved

Forward Service Frequency Sweep

Customer MOC

All forward services

Increased Tacq

Sweep is scheduled and implemented

Employed when the customer MOC cannot define fo accurately Independent of Doppler compensation

Expanded Frequency Uncertainty

Customer MOC

Return service noncoherent operation: DG1 mode 2 DG2 (noncoherent)

Increased Tacq

None

Employed when the customer MOC cannot define fo accurately

Revision 9 C-5 450-SNUG

Table C-1. Customer MOC Controllable Parameters Which Impact Acquisition (contd)
Parameter Initiated or Scheduled by
Customer MOC/NCCDS Customer MOC

Customer Services Affected

All forward and/or return services All forward services

Impact on Tacq

Impact on Acquisition Sequence

None

Comments

Start of Service

Enhances Tacq

Scheduling to minimize impact of customer platform LO frequency uncertainties Enhances forward service Tacq and helps prevent false carrier lock by customer platform

Start of Forward Service Data (relative to start of forward service) Start of Return Signal Transmission (relative to start of return service)

Enhances Tacq

Customer MOC initially sends no data until PN codes and carrier are acquired by customer platform Customer platform transmits coherent carrier and PN codes prior to scheduled start of return service

Customer MOC/NCCDS

All return services

Enhances Tacq

Minimizes ground terminal PN code (if applicable) and carrier acquisition times For coherent operations, customer should allow time for forward service acquisition before starting return service. Typically start of return service equals start of forward service plus 30 seconds. May prevent a potential ground terminal false lock condition and minimize ground terminal loss of data during acquisition

Start of Return Service Data (relative to start to return service) TDRS High Power Mode

Customer MOC

All return services

Enhances Tacq

Customer platform may initially transmit data preamble (pseudo-random bits recommended) None

Customer MOC

SSA and KuSA forward services

Decreases Tacq with power mode

Table C-2. Additional Items and Parameters Which Impact Acquisition

Item Customer Platform Receive G/T Customer Platform EIRP KuSA Return Service Start-up for High Power Customer Platform Customer Services Affected All forward services Impact on Tacq Tacq varies inversely with customer spacecraft G/T Tacq varies inversely with customer Platform EIRP May increase Tacq Impact on Acquisition Sequence None

All return services KuSA return service for Prec values >-159.2 dBW

None Acquisition process must limit instantaneous rate of change of Prec <10 dB/sec

C.2.2

Other Key Parameters

Table C-2 summarizes other key parameters which can impact the acquisition process, but which are a result of basic customer platform design decisions (e.g., G/T, EIRP) or are constrained by TDRSS characteristics. C.3 Acquisition Events

C.3.1 This paragraph presents a detailed description of both customers and TDRSS operations during acquisition. Included are an acquisition timeline and table which are intended to present an accurate description of the many processes which must occur to establish service. Due to the large number of TDRSS services, only a normal support configuration has been included. C.3.2 Table C-3 provides a step-by-step account from the customers point of view of the key events which must occur in establishing various services. The table assumes the TDRSS return service autotrack mode is enabled. If this mode is disabled, the table assumes that the customer platform orbital parameters, available to the TDRSS/ground terminal, are sufficiently accurate that program-track pointing of the TDRS SA antenna will provide the customer with satisfactory TDRSS KuSA/KaSA return service performance. Wherever possible, specific Tacq values have been included to provide an estimate for the amount of acquisition overhead to be expected during scheduled service. However, these Tacq values are only estimates or predictions and should not be regarded as operational specifications.

Revision 9

C-6

450-SNUG

Revision 9 C-7 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return)
Event Service parameters defined by customer MOC Time Up to 21 days prior to TF or TR depending on start time of first service, but at least TF - 10 min or TR 10 min depending on start time of first service Not applicable Equipment Status Customer Platform TDRS/Ground Terminal Not applicable TF is the scheduled start of forward service. TR is the scheduled start of return service. For coherent services TF must occur simultaneously with TR or before TR, i.e., TR = TF + , 0 (typically =30 sec for coherent services). For noncoherent services, TF and TR are independent. Refer to paragraph C.2.1 for customer MOC controllable parameters applicable to acquisition. TDRS and ground terminal configures for services TF-5 min to TF, TR-5 min to TR [SA], or TF-15 sec to TF[MA] Idle TDRS SA antenna slewed towards platform under WSC control; WSC GCE initialized; TDRS configured Up to 5 minutes are required for slewing TDRS SA antenna; ground terminal commands TDRS configuration as required by SHO frequency, pin diodes, MA phase shifters, etc. Remarks

Ground terminal performs preservice testing if applicable

TF - 3 min to TF 15 sec and TR - 3 min to TR 15 sec

Not applicable

WSC performs pre-service testing

Revision 9 C-8 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event Customer platform configured for forward service (note 1) TF - Time Equipment Status Customer Platform Receiver configured; receiving antenna open-loop pointed toward TDRS; forward signal acquisition process enabled; autotrack process enabled (if applicable). TDRS/Ground Terminal Continuing as above Customer platform configured units of time prior to scheduled service start time (or prior to end of previous service support period); SHO must define customer platform receiver frequency to within 700 Hz for S-band, and within 5 kHz for Ku-band, and 6 kHz (Ka-band). Recommended that customer MOC not transmit forward service data until sufficient time has elapsed for customer platform acquisition of command channel PN code, carrier, and range channel PN code, or until return service data stream, if available, indicates customer platform receiver carrier lock; recommended that Doppler compensation (carrier, PN code clocks) be scheduled during forward service signal acquisition (not automatic, must be in SHO). No command channel PN code modulation for forward service data rates >300 kbps. Remarks

Forward service begins

TF

Continuing as above

Ground terminal GCE activated; ground terminal transmits forward service signal

Revision 9 C-9 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event Customer platform receives forward service signal Time T1 = TF + d Equipment Status Customer Platform Command channel PN code acquisition process starts; carrier acquisition process enabled. Autotrack acquisition process starts for Ku-band or Ka-band customers with autotrack enabled. TDRS/Ground Terminal Continuing as above d reflects estimated propagation delay (approximately 240 msec): ground terminal TDRS customer platform For Ku-band and Ka-band customer platform and TR = TF, the customer platform autotrack process after TR shall be at a rate which results in an instantaneous rate of change of Prec 10 dB/sec; the customer platform autotrack of forward service signal is not necessary if the customer platform antenna can be openloop pointed with sufficient accuracy to meet KuSA or KaSA forward and return service requirements Continuing as above cmd 20 sec (example value for NASA 4th generation transponder); cmd represents the time required for the customer receiver to acquire the command channel PN code. Command channel is PN modulated only if data rate 300 kbps. Remarks

Command channel PN code acquired

T2 = T1 + cmd

Command channel PN code despreader synchronized; carrier acquisition process starts

Revision 9 C-10 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event Carrier acquired Time T3 = T2 + car Equipment Status Customer Platform Carrier tracking loop locked; range channel PN code acquisition process enabled; command channel symbol synchronizer process enabled Range channel PN code despreader synchronized; return service carrier locked to forward service carrier; return service PN code generator locked (clock rate and PN code epoch) to range channel PN code TDRS/Ground Terminal Continuing as above car 5 sec (example value for NASA 4th generation transponder); car represents the time required for the customer receiver to acquire the carrier rng 10 sec (example value for NASA 4th generation transponder); m 1 sec; rng represents the time required for the customer receiver to acquire the range channel. m represents the time required for the customer transponder to transition from noncoherent to coherent mode; a data preamble sequence may be desirable on each customer platform data channel during ground terminal return service signal acquisition to prevent real data (i.e., telemetry, scientific) loss and to aid in WSC symbol synchronization and Viterbi decoder acquisition (refer to paragraph C.2.1) Autotrack acquisition may be complete before forward service signal is fully acquired or vice versa Remarks

Range channel PN code acquired; coherent turnaround return service signal transmitted

T4 = T3 + rng+ m

Continuing as above

Customer platform autotrack acquisition complete, high accuracy tracking begins (if applicable and enabled)

T5 = T1 + auto

Autotrack locked; symbol synchronizer acquisition in progress; onboard computer searching for frame synch word in forward service data stream normal operation

Continuing as above

Revision 9 C-11 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event Customer Platform configured for return service (note 1) Time TR - Equipment Status Customer Platform Transmitter configured; coherent or noncoherent mode enabled; transmitting antenna open-loop pointed toward TDRS Continuing as above TDRS/Ground Terminal Continuing as above Customer platform configured units of time prior to scheduled service start time (or prior to end of previous service support period) For coherent services, R is the start time of return service. R is equal to the maximum of TR or TF + , where is approximately 2d + cmd + car + rng + m For noncoherent services R is independent of the TF start time and if the local oscillator is not within the required values of 700 Hz (S-band), 5 kHz (Ku-band), 6 kHz (Kaband), then OPM 07 (Expanded User Frequency Uncertainty Request) must be sent after TR; A data preamble sequence may be desirable on each customer platform data channel during WSC return service signal acquisition to prevent real (i.e., telemetry, science) data loss and to aid in ground terminal symbol synchronization and decoder acquisition. Remarks

Return service begins

Ground terminal PN code and/or carrier acquisition process starts; symbol, Viterbi decoder, and deinterleaving synchronization and autotrack acquisition process enabled (as required)

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event PN code (DG1 only) and carrier acquired Time T5 = R + acq Equipment Status Customer Platform Continuing as above TDRS/Ground Terminal PN code despreader and carrier acquired; symbol synchronizer and Viterbi decoder processes start For coherent service, acq 1 sec For noncoherent service, acq 1 sec if customer platform transmitter frequency uncertainty is 700 Hz (Sband), 5 kHz (Ku-band), 6 kHz (Ka-band) and acq 3 sec if customer platform transmitter frequency uncertainty is 3 kHz (Sband), 35 kHz (S-band), 20 kHz (Ku-band), 21 kHz (Kaband) syn (seconds) 1100 / (channel data rate in bps) for biphase symbols (S-band DG2 only); syn (seconds) 6500 / (channel data rate in bps) for NRZ symbols; For dual data channels, symbol and decoder synchronization must be achieved on each channel For DG2 services requiring channel ambiguity resolution by the ground terminal, additional time is required for the ground terminal to resolve the ambiguity. Remarks

Revision 9 C-12 450-SNUG

Symbol and Viterbi decoder Synchronizers acquired; return service(s) established

T7 = T5 + syn

Continuing as above

Symbol and Viterbi decoder, and deinterleaver synchronizers (if applicable) locked

Revision 9 C-13 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event TDRSS autotrack acquisition complete, high accuracy tracking begins; return service(s) established; return service channel data stream(s) transferred from the ground terminal to NISN Customer MOC receives return service data stream(s), begins forward service data transmission (e.g., preamble followed by commands) Time T8 = R + tauto Continuing as above Equipment Status Customer Platform TDRS/Ground Terminal Autotrack (if enabled) locked. Return service(s) established here Signal acquisition will be completed before TDRSS autotrack (if enabled) acquisition is completed tauto 10 Remarks

T9 = T8 + has

Continuing as above

Normal operation

For has; this acquisition sequence assumes that forward service data is sent by the customer MOC only after the return service acquisition is confirmed by the customer MOC via return service data (i.e., no forward return service data until successful return service acquisition); typical preamble consists of 128-bit alternating sequence followed by frame synchronization word to enable customer platform command processing

Revision 9 C-14 450-SNUG

Table C-3. Acquisition Events for TDRSS Services (Normal Forward and Return) (contd)
Event Forward service symbol synchronization achieved and frame synch word identified; forward service established; customer platform begins forward service data processing Time T10 = T9 + bit Equipment Status Customer Platform Symbol synchronizer locked and frame synch word recognized; command processing enabled TDRS/Ground Terminal Continuing as above bit is approximately 128 bit times (i.e., 128 bits after customer platform receives data modulated forward service signal Remarks

Note: 1. This can be achieved at the end of the previous forward service support period or by stored on-board commands. If coherent return service operations are scheduled later in this same service support period, the transponder can be set to permit automatic transition to coherent turnaround mode at, or prior to, the scheduled start of the coherent return service operations. This can also be achieved either via stored on-board commands or via commands imbedded in the forward service data once the forward service is established.

C.4 C.4.1

Reacquisition Introduction

C.4.1.1 Once a service has been established, there are a number of conditions or events that can cause the service to be degraded or to be interrupted, in which case the service may need to be reestablished. Reacquisition refers to that part of reestablishing service which includes the following: a. Reinitiating the customer platform initial acquisition process if it is a forward service reacquisition; recalculating new settings for the current circumstances and initializing acquisition circuits if it is a return service. b. Executing the acquisition events (please see paragraph C.3 above) as indicated for initial acquisition. C.4.1.2 Reacquisition may also be required whenever there is a failure to establish service initially. In some cases of service interruption, additional ground terminal processing may be needed prior to initiation of the reacquisition process. This may include the need for the WSC to reconfigure the Ground Control Equipment (GCE) and/or the TDRS and to calculate and implement new setup values. These two operations are referred to as TDRSS hardware reconfiguration and software resetup. C.4.1.3 The events or conditions that initially trigger the need for a reacquisition may be categorized as arising from the customer MOC/NCCDS or from the TDRSS as follows: a. Customer MOC/NCCDS Initiates Reacquisition. This may result indirectly from a customer MOC request to the NCCDS to reconfigure a service parameter (resulting in a reconfiguration OPM [Class 03] from the NCCDS to the WSC) or as a result of the customer MOC/NCCDS directly requesting reacquisition via an OPM [Class 02]. b. TDRSS Initiates Reacquisition. Conditions that may cause the ground terminal to initiate reacquisition include a loss of carrier lock, service alarms, and hardware or software failures. Detailed and precise scenarios in this regard are beyond the scope of the current discussion. However, some general concepts are presented in paragraphs C.4.2 and C.4.3 to provide some additional insight into the reacquisition process. C.4.1.4 The primary focus here will be on reacquisition initiated by the customer MOC/NCCDS.

Revision 9

C-15

450-SNUG

C.4.2

Customer MOC/NCCDS Initiated Reacquisition

C.4.2.1 Table C-4 and Table C-5 summarize the parameters controlled by the customer MOC which may lead to service interruption for the forward and return services, respectively. The tables indicate the consequence of requesting each parameter in regard to both reacquisition and TDRSS reconfiguration. C.4.2.2 As indicated in Table C-4 and Table C-5, the customer MOC may request, via the NCCDS, a service reacquisition. Normally this request is initiated only after the customer MOC detects a problem and only if no TDRSS problems exist as indicated in the information conveyed from the WSC to the NCCDS via an ODM 1 . In this case, the customer MOC may instead choose to simply terminate service or to change some operating condition or parameter as cited in paragraph C.4.1. C.4.2.3 As seen in the tables, the customer MOC has the option to select forward and return service reacquisitions independently. However, for coherent turnaround operations, a forward service reacquisition will lead to a return service interruption and the WSC will automatically initiate return reacquisition after forward reacquisition. For noncoherent operations, forward and return service reacquisitions are independent so that the corresponding customer MOC-initiated reacquisition requests may also be invoked independently. C.4.2.4 Figure C-1 and Figure C-2 provide an overview of some of the key elements that lead to the requirement for reacquisition of the forward and return service signals, respectively. Also included is some of the logic associated with the ground terminal regarding reacquisition. Normally, the customer MOC will detect a service fault whenever problems are detected by the ground terminal (please see paragraph C.4.3 below). In this case, the ground terminal may automatically take the appropriate action, thereby perhaps alleviating the need for the customer MOC to request reacquisition. C.4.2.5 The ground terminal monitors and reports on numerous elements of the ground terminal GCE and the TDRS, including performance data (such as loss of lock conditions) and equipment status (such as hardware faults). In addition, in some cases, the ground terminal automatically initiates reacquisition of the appropriate service. Consequently, with reference to the customer MOC, acquisition contingencies need be developed

1 Transmission of ODMs from the NCCDS to the customer MOC must be requested (in advance) by the customer MOC. They are not automatically transmitted to the customer MOC by the NCCDS.

Revision 9

C-16

450-SNUG

Table C-4. Parameters Which Impact Forward Service

Forward Service Parameter or Operating Condition Forward Service Reacquisition Change in Customer Platform Receive Frequency Doppler Compensation Inhibit (PN Codes and Carrier) Reinitiation of Forward Service Doppler Compensation (PN Codes and Carrier) Forward Service Frequency Sweep (note 1) Change in Customer Platform Receive Antenna Polarization Initiation or Termination of the Command Channel PN Code Forward Service EIRP (Normal and High Power) Change in Command Channel Data Rate X MA X X X X SSA X X X X KuSA/ KaSA X X X X Customer Platform Reacquisition Required X X Note 4 Note 5 X Note 4 X TDRSS Reconfiguration or Resetup Required

X X X X X

X X X X X

X X X Note 2 Note 3

X X X X X

Notes: 1. This request is normally used as an aid in customer platform acquisition of the TDRSS forward service signal. 2. Reacquisition by the customer platform of the forward service signal may or may not be required (usually depends on whether there is a loss of lock condition within the customer platform receiver as a result of the step change in received TDRSS forward service signal energy). 3. If the initial and final data rate are <300 kbps, MOC only customer platform symbol resynchronization and frame synchronization searches are required. 4. The ground terminal does not interrupt the TDRSS forward service signal if a Doppler compensation inhibit request OPM (Class 11) is used. 5. The ground terminal will minimize service interruptions due to Customer Reconfiguration OPMs. Customer platform reacquisition may be required.

Revision 9

C-17

450-SNUG

Table C-5. Parameters Which Impact Return Service

Return Service Parameter or Operating Condition MA SSA KuSA/KaSA Ground Terminal Reconfiguration and Reacquisition Required X X X X X X X X X X X X X

Return Service Reacquisition Expanded Customer Platform Frequency Uncertainty (note 1) Change in I and/or Q Channel Data Rate Change in Customer Platform Transmit Frequency Redefinition of Maximum or Minimum Customer Platform EIRP Change in I/Q (Power) Change the I and/or Q Channel Data Bit Jitter Change in DG1 Mode (1,2,3) Change in I and/or Q Channel Data Format Change in Customer Platform Antenna Polarization Change Between DG1 and DG2 Change in DG2 Type (coherent/noncoherent) G2 Inversion (I and/or Q Channel)

X X X X X X X X X

X X X X X X X X X X X X

X X X X X X X X (note 2) X X X (note 2) X (note 2) X

Notes: 1. This request is normally used as an aid in acquisition. 2. Not valid for KaSA service.

Revision 9

C-18

450-SNUG

Customer MOC/NCCDS Forward service equipment changes operating alarms at the conditions or configuration ground terminal Do changes automatically Yes cause TDRSS reconfiguration? No Is there a service interruption? Yes Yes

Customer MOC/NCCDS requests reacquisition

Are there TDRSS faults indicated by the ground terminal equipment alarms? No

Reconfigure/resetup TDRSS forward service equipment

No PN code resetup; Doppler compensation resetup

Reacquisition

Continue Operation

Acquisition initiated

Figure C-1. Reacquisition Initiation Logic: Forward Service

primarily for those situations in which the ground terminal does not initiate reacquisition. Furthermore, these contingency procedures essentially consist of only those parameters listed in Table C-4 and Table C-5. The events which lead to customer MOC-initiated contingencies fall into four general classifications. These and possible customer MOC responses are as follows: a. Initial acquisition not achieved (forward service). 1. 2. 3. 4. Forward service reacquisition. Forward service frequency sweep. TDRS high power mode. Reconfiguration of forward service parameters (please see Table C-4 above).

Revision 9

C-19

450-SNUG

Revision 9 C-20 450-SNUG

Customer MOC/NCCDS changes operating conditions or configuration

Loss of carrier lock detected by the ground terminal

Customer MOC/NCCDS requests return service reacquisition

Forward service interrupted (detected by Customer MOC from customer platform telemetry)

Do changes automatically cause TDRSS reconfiguration?

Are there TDRSS faults indicated by the ground terminal equipment alarms? Yes Yes

No

Yes Is it coherent operation?

No Reconfigure/resetup TDRSS return service equipment

No

Continue operation (see figure C-1) Continue operation PN code resetup; carrier acquisition reinitialized

Acquisition reinitiated

Figure C-2. Reacquisition Initiation Logic: Return Service

b. Initial acquisition not achieved (return service). 1. 2. 3. Return service reacquisition. Expanded frequency uncertainty. Reconfiguration of forward and/or return service parameters please see Table C-4 and Table C-5 above). NOTE: If in coherent turnaround operations, forward service reacquisition may be advised. c. Loss or degradation of forward service. 1. 2. 3. 1. 2. 3. C.4.3 Forward service reacquisition. Reconfiguration of forward service parameters. Terminate forward service. Return service reacquisition (forward service reacquisition also if coherent turnaround). Reconfiguration of forward and/or return service parameters. Terminate return service. WSC/GRGT Initiated Reacquisition

d. Loss or degradation of return service.

As indicated earlier, there are a number of conditions whereby the ground terminal automatically initiates reacquisition. An exhaustive accounting of all conditions that lead to a ground terminal -initiated reacquisition is beyond the scope of this Appendix. Upon detection of a service degradation or interruption, the customer MOC should monitor the TDRSS status as conveyed from the NCCDS via an ODM. Based on this information the customer MOC can infer whether the ground terminal has automatically initiated reacquisition. If the ground terminal has automatically initiated reacquisition, the ground terminal will not accept any OPMs applicable to this specific customer service during this reacquisition period. Finally, the customer MOC needs to decide if a customer MOC-initiated reacquisition request to the ground terminal by the NCCDS is necessary or desirable.

Revision 9

C-21

450-SNUG

This page intentionally left blank.

Revision 9

C-22

450-SNUG

Appendix D. Spectrum Considerations

D.1

Introduction

The radio frequency spectrum is a national and international resource, and, as such, its use is governed by statutory requirements and treaty obligations. There are also NASA and NASA/GSFC policies and procedures governing the use of the radio frequency spectrum. This Appendix describes some of the applicable national and international obligations on its use to support space missions utilizing the Space Network. Additionally, the GSFC Spectrum Allocation and Management Site (GSAMS) http://classwww.gsfc.nasa.gov/GSAMS/ web site provides regulatory background information and technical guidance for GSFC organizations involved in licensing RF equipment. In the event of a conflict between the GSAMS website and this appendix, please contact the GSFC Spectrum Manager for clarification. The National Telecommunications Information Agency (NTIA) Manual of Regulations & Procedures for Federal Radio Frequency Management defines the regulations and policies pertaining to United States (U.S.) Government agency use of RF spectrum in the United States and its possessions. (This manual is hereafter referred to as the NTIA manual.) The NTIA regulations are available from the following website: http://www.ntia.doc.gov/osmhome/osmhome.html. The International Telecommunications Union (ITU) Radiocommunication Sector (ITU-R) provides an international forum to revise the technical and regulatory provisions affecting the use of the RF spectrum. The ITU-R regulations are contained in the Radio Regulations (RR), which, when ratified by the U.S. Senate, imposes treaty obligations on the United States. Selected portions of the Radio Regulations are available from the GSAMS website with a user ID and password (See the GSAMS website). Paragraph D.2 briefly provides guidance to projects that need to initiate RF equipment licensing. Paragraph D.3 describes the PFD limits, how they are calculated, and some of the operational implications to projects. Paragraph D.4 describes the limits for unwanted emissions. Paragraph D.5 describes the standards for frequency tolerance. Paragraph D.6 describes the regulations concerning cessation of emissions. Paragraph D.7 describes the protection afforded deep space Earth stations. Paragraph D.8 describes the preferred frequencies for launch vehicles. Paragraph D.9 provides additional ITU-R recommendations applicable to space-to-space links. D.2 RF Equipment Licensing

All U.S. space missions, including commercial space systems that use the TDRSS system, must register frequency usage with the NTIA and are subject to all the NTIA regulations and procedures. Non-U.S. missions must register their frequency usage internationally through their appropriate spectrum management agencies.

Revision 9

D-1

450-SNUG

Early in the mission planning cycle, NASA projects should contact the appropriate center spectrum manager to get NTIA authorization to transmit. The NASA Center Spectrum Managers are responsible for management of the RF equipment licensing process, and are the final authority on the selection of the appropriate frequencies for all NASA RF equipment. Amongst other duties, these center managers will facilitate the licensing of RF equipment by coordinating with national and international organizations in: 1) making frequency selections, 2) evaluating RF equipment against applicable national and international RF standards, 3) performing RF analyses, and 4) completing frequency authorization applications to the NTIA. The Goddard Procedural Requirements (GPR) Policy 2570.1A provides GSFC missions with the requirements for Radio Frequency (RF) equipment licensing in accordance with NASA Policy Directive NPD 2570.5C. D.3 Power Flux Density (PFD) Considerations

PFD limits on the surface of the Earth are the primary means to prevent harmful interference to terrestrial systems operating in bands shared with the TDRSS Space Network. In those bands which are shared on a primary basis between the space and terrestrial services, the PFD limits are incorporated into the Radio Regulations. PFD levels should be calculated early, preferably during the mission planning and system design phase, in order to determine whether or not the PFD limits would impose any unsatisfactory system requirements or operational constraints. For example, many missions with high gain antennas opt to delay the start of transmissions until some period of time after the TDRS comes in view over the horizon in order to satisfy the PFD limits. Additionally, mission planners are strongly urged to consider that satellite subsystems and components often exceed specifications and this can result in PFD levels being exceeded. The applicable PFD limits for the TDRSS S-Band, Ku-band, and Ka-band links are provided in Paragraph D.3.1. Paragraph D.3.2 describes the impact of exceeding the PFD limits. Paragraph D.3.3 provides the equations used to determine PFD levels. Paragraph D.3.4 provides an example application. D.3.1 PFD Limits

Power Flux Density limits are imposed on NASA missions by both the NTIA and the ITU. Although largely similar, there are a number of differences in the requirements, which can result in a mission meeting one requirement but not the other. The consequences of failure to meet NTIA and ITU PFD limits are outlined in paragraph D.3.2. This section lists the NTIA and ITU PFD limits in the TDRSS forward and return link bands. For most Space Network users, the applicable ITU and NTIA PFD limits for the TDRSS S-Band, Ku-band, and Ka-band links are shown in Table D-1. The international PFD

Revision 9

D-2

450-SNUG

Table D-1. International and National PFD Limits Applicable to TDRSS Links
TDRSS Service SSAF MAF SSAR MAR Frequency Band 2025 2110 MHz (note 1) 2200 2290 MHz 4 kHz Reference Bandwidth Angle of Arrival 0 to 5 5 to 25 25 to 90 KuSAF 13.4 14.05 GHz 4 kHz 0 to 90 0 to 5 KuSAR 14.5 15.35 GHz 1 MHz 5 to 25 25 to 90 KaSAF KaSAR 22.55 23.55 GHz 25.25 27.5 GHz 1 MHz 0 to 5 5 to 25 25 to 90 ITU-R RR PFD Limit (dBW/m2) -154 NTIA PFD Limit (dBW/m2) -154

-154 + -144

5
2

-154 + -144 -152 -124 -124 + -114 -115

5
2

Not Applicable Not Applicable Not Applicable Not Applicable -115

5
2

-115 + -105

5
2

-115 + -105

5
2

Note: 1. Nationally, the NTIA PFD limits can be exceeded by up to 3 dB in the 2025 2110 MHz band.

limits were extracted from the ITU-R Radio Regulations Article 21, Table 21-4. The national PFD limits were extracted from NTIA manual Table 8.2.36. In both cases, the PFD limit is defined at the Earth's surface as a function of the angle of arrival above the local horizontal plane, , for all conditions and for all methods of modulation. The limits relate to the PFD that would be obtained under assumed free-space propagation conditions. For S-band and Ku-band links, the requirements are given in a 4 kHz reference bandwidth. The NTIA may on a case-by-case basis permit space-to-space links to exceed the PFD limits in the 2200-2290 MHz band within the United States and its territories and possessions. The PFD limits can in some instances be more easily met with the 1 MHz reference bandwidth given in Recommendation ITU-R SA.1273 than with the 4 kHz reference bandwidth given in the ITU RRs and NTIA manual. The PFD limits given in ITU-R SA.1273 are provided in Table D-2.

Revision 9

D-3

450-SNUG

Table D-2. S-Band Space-to-Space PFD Limits Given in ITU-R SA.1273

TDRSS Service SSAF MAF Frequency Band Reference Bandwidth 1 MHz Angle of Arrival 0 to 5 2025 2110 MHz 5 to 25 25 to 90 0 to 5 SSAR MAR 2200 2290 MHz 1 MHz 5 to 25 25 to 90 PFD Limit (dBW/m2) -130 -130 + -120 -127 -127 + -117

5
2

5
2

Note that in Table D-1, there are no PFD limits in the ITU-R RR for the Ku-band links. Because the ITU-R RR only considers PFD limits for space stations in those bands for which the space services operate on a primary, co-equal basis with the fixed and mobile services, it includes no requirements for PFD limits for the TDRS Ku-band links, which operate on a secondary basis (see explanation below). However, PFD limits applicable for the KuSAF and KuSAR services are contained in Recommendation ITU-R SA.510, which are shown in Table D-3. Table D-3. Ku-Band Space Research PFD Limits Given in ITU-R SA.510
TDRSS Service KuSAF KuSAR Frequency Band Reference Bandwidth 4 kHz Angle of Arrival 0 to 5 13.4 14.05 GHz, 14.6 15.35 GHz 5 to 25 25 to 90 PFD Limit (dBW/m2) -148 -148 + -138

5
2

NOTE: These ITU-R recommended limits are equivalent to the U.S. limits for user return transmissions (KuSAR) for emission bandwidths of 1 MHz or greater, but they are not as restrictive as the U.S. limits for the TDRS forward link, KuSAF. A primary allocation to a service allows systems of that service to operate in a band with full protection from interference from other systems of the same service and from

Revision 9

D-4

450-SNUG

systems of other services which are also allocated on a primary basis. New systems cannot be introduced into that frequency band if they will result in interference to a system operating with a primary allocation. A secondary allocation to a service allows systems to operate in a band on the condition that it does not cause interference to, nor claims protection from, systems operating on a primary basis. However, systems operating on a secondary basis can claim protection from interference from other systems operating on a secondary basis. D.3.2 Consequences of Exceeding PFD Limits

If the PFD levels do not meet the PFD limits given in the NTIA manual, the NTIA will not grant frequency authorization except as noted in paragraph D.3.1. If the PFD levels do not meet the PFD limits given in the ITU-R RR, then the mission is subject to the conditions given in Article 4.4. Article 4.4 states Administrations of the Member States shall not assign to a station any frequency in derogation of either the Table of Frequency Allocations in this Chapter or the other provisions of these Regulations, except on the express condition that such a station, when using such a frequency assignment, shall not cause harmful interference to, and shall not claim protection from harmful interference caused by, a station operating in accordance with the provisions of the Constitution, the Convention and these Regulations. D.3.3 Calculation of PFD Levels

The calculation of PFD levels requires the following data for the customer platform: a. Maximum transmitter power contained in the reference bandwidth (i.e., 4 kHz or 1 MHz), under all conditions and modes of modulation measured at the antenna input. Please see paragraph D.3.3.1 below. b. Transmitting antenna gain pattern. c. Transmitting antenna mainbeam pointing characteristics, including any intentional or unintentional antenna mispointing.

d. Orbital altitude (nominally circular orbits are assumed for this analysis). The PFD at an angle of arrival, , is calculated as shown in Equation D-1 with R() found using Equation D-2 and Equation D-3. The geometry is shown in Figure D-1: Equation D-1:
G ( ) P tB PFD ( ) = 10 log t 4R 2 ( )

where:

Revision 9

D-5

450-SNUG

PFD () =

maximum power flux density in dBW/m2 in the reference bandwidth at the surface of the Earth for an angle of arrival "" above the local horizontal plane. platform transmitting antenna gain relative to an isotrope in the direction of the point on the Earths surface corresponding to an angle of arrival . = 0 refers to the antenna boresight direction. maximum transmitter power in Watts in the reference bandwidth (i.e., 4 kHz or 1 MHz) measured under all conditions and modes of modulation. slant range in meters from the customer platform to the earth for angles of arrival " (R is greater than or equal to the orbital altitude, depending on "").

Gt() =

PtB =

R() =

Equation D-2:
R ( ) = r s + r e 2 r s r e cos[ ( )]
2 2

where Equation D-3:

( ) = 90 o

r cos( ) sin 1 e rs

Spacecraft

rs = re + altitude re = 6378.14 km

R rs

re TDRS

Figure D-1. Geometry for Determining PFD Conformance

Revision 9

D-6

450-SNUG

As shown in Equation D-1, the calculation of PFD levels requires knowledge of the transmitting antenna gain pattern. A transmitting antenna gain pattern based on measured data may not be available. In this case, the antenna pattern given in Recommendation ITU-R S.672 (which is referred to in Recommendation ITU-R SA.1414) may be used to model platform high gain antennas. If measured data is available, the gain pattern of interest is an envelope containing at least 90 percent of the sidelobe peaks, which decreases monotonically with increasing off-axis angle. The antenna pattern from Recommendation ITU-R S.672 is shown in Figure D-2. Paragraph D.3.3.1 describes a procedure to calculate the maximum transmitter power in the reference bandwidth, PtB. Paragraph D.3.3.2 describes an operational method to ensure that Space-to-Space links with high gain transmitting antennas can meet PFD limits if transmissions are limited to times when the TDRS spacecraft appears sufficiently above the Earths limb. D.3.3.1 Calculation of PtB

The maximum transmitter power in the reference bandwidth, PtB, depends on the number of data channels, the data formats, and the modulation method. The standard TDRSS return links use suppressed carrier BPSK modulation, balanced or unbalanced QPSK modulation, balanced or unbalanced SQPSK modulation, or SQPN links. Channels are either in NRZ or Biphase format. For each channel, the transmitter Power Spectral Density (PSD) (W/Hz) as a function of frequency offset from the carrier, f, is: Equation D-4:
PSD (

f ) = PT

sin2 ( x ) x2

, where x = f T for NRZ and PN spread links

Equation D-5:
PSD (

f ) = PT

sin 4 ( x) , where x = f T / 2 x2

for Biphase formatted links

where: P = total power (measured in Watts) for the channel. P represents the total power delivered to the transmitting antenna, taking into account transmitter-to-antenna line losses and the I/Q channel ratio, where applicable. T = 1/Rs = channel symbol duration (seconds). Rs = symbol rate (symbols/second). The symbol rate includes PN spreading and convolutional encoding as appropriate, but excludes biphase encoding. PN spread links have a symbol rate of 3.08 Mcps. The symbol rate for a non-spread BPSK link is equal to the data rate times the coding rate (if applicable). For example, a 256 kbps link with rate convolutional coding and BPSK modulation has a symbol rate of 512 ksps.

Revision 9

D-7

450-SNUG

Radiation Pattern Envelope Functions

0 -5

Gain relative to max gain (dB)

-10 -15 Ls=-20 dB -20 -25 -30 -35 -40 1.0 10.0 Relative off-axis angle (/o) 100.0 Ls=-25 dB Ls=-30 dB

G() = Gm 3 (/0)2 G() = Gm + LS G() = Gm + LS + 20 25 log (/0) G() = 0

dBi dBi dBi dBi

for for for for

0 < < a 0 a 0 < < b 0 b 0 < < 1 1 <

(I) (II) (III) (IV)

Where: G(): Gain at angle () from the axis (dBi) Gm: Maximum gain in the main lobe (dBi) 0: One-half the 3 dB beamwidth in the plane of interest (3 dB below Gm) (degrees) Value of () when G() in equation (III) is equal to 0 dBi 1: LS: The required near-in-side-lobe level (dB) relative to peak gain a, b: Numeric values are given below LS -20 -25 -30 a 2.58 2.88 3.16 b 6.32 6.32 6.32

Figure D-2. ITU-R S.672 Antenna Pattern Recommendation

Revision 9

D-8

450-SNUG

For signals with two channels, the total PSD(f) is found by summing the PSD(f) from both channels. The maximum PSD(f) is not affected by whether or not the Q channel is delayed with respect to the I channel. Most TDRSS links operate with a symbol rate much greater than the reference bandwidth. In this case, the PSD(f) for a given channel is seen to be relatively constant over the reference bandwidth. The resulting PtB for NRZ and PN spread signals is given by Equation D-6. The resulting PtB for biphase formatted signals is given by Equation D-7: Equation D-6:
PtB (dBW/Bref) = 10 LOG10(P Bref /Rs) for NRZ signals with Rs>>Bref

Equation D-7:
PtB (dBW/Bref) = 10 LOG10(P Bref /Rs) 2.8 dB for Biphase signals with Rs>>Bref

where:
Bref = reference bandwidth in Hz (4000 or 1000000)

D.3.3.2

Special Case: Satisfying PFD Limits for High Gain Space-to-Space Links by Ceasing Transmissions as the TDRS Spacecraft is Near the Horizon

In many cases, the PFD limits are difficult to meet when a customer platform high gain antenna is pointed towards the Earths horizon (i.e. when the TDRS is just entering or leaving the platform field of view.) In this case, many missions opt to delay the start of transmissions until the high gain antenna is pointed sufficiently above the Earths horizon. Similarly, the missions cease transmissions a few minutes prior to the time that the TDRS goes below the horizon. This section describes a procedure to calculate the minimum angle between the line-of-sight (LOS) vector to TDRS and the pointing vector to the horizon that is just sufficient to ensure that the PFD limits are met for all angles of arrival, . The geometry is shown in Figure D-3. The minimum angle between the line of sight vector to TDRS and the horizon, m, is found at each value of by calculating: a. () and R() found from Equation D-2 and Equation D-3. b. qm(), the angle between horizon vector and the Earths surface for a given , from Equation D-8.

Revision 9

D-9

450-SNUG

Spacecraft

qm

h R rs = re + altitude re = 6378.14 km

re horizon

TDRS

Figure D-3. Geometry for the Minimum Angle Between the Pointing Vectors Towards the Horizon and the TDRS Equation D-8:
r qm () = sin 1 e r s r cos() sin 1 e rs

c.

the maximum gain at the offpointing angle, , which is just sufficient to ensure that the PFD limit is met. This is accomplished by setting the PFD() in Equation D-1 to the PFD limit at and solving for G().

d. the minimum offpointing angle, , that yields the G() found in step C. (Use the platform transmitting antenna gain pattern, if available.) e. m by subtracting qm from . (m is the minimum angle between the LOS vector to TDRS and the pointing vector to the horizon that satisfies the NTIA PFD threshold at the Earths surface for a given angle of arrival, .) The minimum angle between the LOS vector to TDRS and the pointing vector to the horizon needed to satisfy the PFD limits is simply the largest value of m taken over all values of . This angle is denoted as MAX[m()]. A geometrical analysis can be used to bound the time required for a platform to travel from the point where m = 0 to the point where m = MAX[m()]. This bound represents

Revision 9

D-10

450-SNUG

a bound on the time period for which the transmission should be ceased to meet PFD limits as the platform comes around the limb of the horizon. D.3.4 An Example Application

The minimum angle between the LOS vector to TDRS and the pointing vector to the horizon was calculated for a representative platform. The link is an uncoded 50 Mbps data stream that is BPSK/NRZ modulated onto the carrier. The peak transmitter power is 12.6 Watts. The peak transmitter power in the 4 kHz reference bandwidth is found to be 30 dBW using Equation D-4. The calculations, which are shown in Figure D-4, indicate that the minimum angle between the LOS vector to TDRS and the pointing vector to the horizon is 5.4. A geometrical analysis indicates that with an altitude of 400 km and an inclination of 51.6, m will exceed 5.4 approximately 2.5 minutes after the TDRS is visible above the horizon. D.4 Unwanted Emissions

This section describes the regulations and recommendations concerning unwanted emissions. The Radio Regulations define unwanted emissions as all emissions outside the necessary bandwidth and includes both emissions resulting from the modulation process and spurious emissions. The necessary bandwidth is a two-sided bandwidth and is defined as follows for a given class of emission: the width of the frequency band which is just sufficient to ensure the transmission of information at the rate and with the quality required under specified conditions. For space telecommunication links, GSFC missions generally record the necessary bandwidth as the bandwidth that is just sufficient to contain the mainlobe of the signal spectrum. For TDRSS links, the necessary bandwidth is twice the highest baud rate on either channel. Paragraph D.4.1 describes the unwanted emission regulations given in the NTIA manual. Paragraph D.4.2 provides examples for the calculation of NTIA emission masks. Paragraph D.4.3 describes the ITU-R recommendations on unwanted emissions. D.4.1 NTIA Emission Mask

Figure D-5 shows the unwanted emission mask given in Section 5.6 of the NTIA Manual. This emission mask is applicable for all Earth and space stations operating above 470 MHz. The NTIA emission mask applies to the continuous spectrum and all discrete spectral lines, including spurious outputs and harmonics. The NTIA mask is interpreted as follows: dBsd is dB attenuation in a 4 kHz bandwidth, relative to the maximum power in any 4 kHz band within the necessary bandwidth. For frequencies offset from the assigned frequency less than the 50% of the necessary bandwidth (Bn), no attenuation is required.

Revision 9

D-11

450-SNUG

Revision 9 D-12 450-SNUG

flux = PtGt/4piR^2 Spacecraft Altitude Narrowband RF Transmit Power Narrowband RF Transmit Power

400 km 12.60 Watts maximum 11.00 dBW max

Carrier Symbol Rate Peak PSD PSD in 4kHz Bandwidth Spacecraft Cable Loss

5.00E+07 bps -65.99 dBW -29.99 dBW/Hz 0 dB Power Flux Density at Earth's Surface Peak Received PSD on Earth Margin to PFD Minimum Antenna Spacecraft (assuming 0 dBi Limit = Max Offpointing Angle Spacecraft Range Antenna Gain Antenna Gain) PFD Limit Antenna Gain Needed [km] [dB] [dBW/m^2/4 kHz] [dBW/m^2/4 kHz] [dB] 2293.74 0 -168.17 -152.00 16.17 4.80 1804.52 0 -166.08 -152.00 14.08 6.00 1440.36 0 -164.13 -149.50 14.63 5.80 1175.06 0 -162.36 -147.00 15.36 5.40 984.18 0 -160.82 -144.50 16.32 5.00 844.02 0 -159.48 -142.00 17.48 4.50 739.37 0 -158.33 -142.00 16.33 5.10 659.75 0 -157.35 -142.00 15.35 5.60 598.17 0 -156.49 -142.00 14.49 6.00 549.90 0 -155.76 -142.00 13.76 6.40 511.74 0 -155.14 -142.00 13.14 6.80 481.44 0 -154.61 -142.00 12.61 7.20 457.42 0 -154.16 -142.00 12.16 7.40 438.55 0 -153.80 -142.00 11.80 7.80 424.02 0 -153.51 -142.00 11.51 8.00 413.24 0 -153.28 -142.00 11.28 8.20 405.80 0 -153.12 -142.00 11.12 8.20 401.44 0 -153.03 -142.00 11.03 8.30 400.00 0 -153.00 -142.00 11.00 8.30 Minimum Antenna Offpointing 4.80 5.40 3.50 0.54 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 5.40

RGT Elevation Angle [degrees] 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 50.00 55.00 60.00 65.00 70.00 75.00 80.00 85.00 90.00

Spacecraft Look Angle [degrees] 70.22 69.62 67.92 65.36 62.16 58.52 54.58 50.43 46.12 41.71 37.22 32.67 28.07 23.43 18.77 14.10 9.40 4.70 0.00

Earth Central Angle [degrees] 19.78 15.38 12.08 9.64 7.84 6.48 5.42 4.57 3.88 3.29 2.78 2.33 1.93 1.57 1.23 0.90 0.60 0.30 0.00

Thetaqm 0.00 0.60 2.30 4.86 8.06 11.70 15.64 19.79 24.09 28.51 33.00 37.55 42.15 46.78 51.44 56.12 60.81 65.51 70.22 MaxAngle

Figure D-4. Calculation of the Minimum Antenna Angle Between the Pointing Vector to the Horizon and the Pointing Vector to TDRS

Figure D-5. NTIA OOB Emission Mask for Space Services

At a frequency offset equal to 50% of the necessary bandwidth, an attenuation of at least 8 dB is required. Frequencies offset more than 50% of the necessary bandwidth should be attenuated by the following mask:

2 | f | d + 8 (dBsd) 40 log B n
where fd is the frequency displaced from the center of the emission bandwidth.

For cases of very narrow-band emissions where the necessary bandwidth is less than the minimum bandwidth (BL) given in Table D-4, BL shall be used in place of Bn.

Revision 9

D-13

450-SNUG

Table D-4.

Minimum Bandwidth as Defined for NTIA OOB Emission Mask

Operating Frequency Range (fc) 470 MHz < fc < 1 GHz 1 GHz < fc < 10 GHz 10 GHz < fc <15 GHz 15 GHz < fc < 26 GHz fc > 26 GHz Minimum Bandwidht (BL) 25 kHz 100 kHz 300 kHz 500 KHz 1 MHz

For Carrier Frequencies above 15 GHz, a 1 MHz bandwidth may be used. Attenuation in this sense refers to the reduction in level relative to the reference, 0 dBsd, unless otherwise specified. The NTIA unwanted emission mask rolls off at 40 dB per decade to a maximum attenuation of 60 dBsd, at which point it continues on both sides of the carrier for all frequencies beyond this point. For any narrowband or single frequency unwanted emission which is not spread by the modulation process, the required attenuation shall be at least 60 dBc, where dBc is attenuation below the mean transmit power, rather than the dBsd value determined above. In practice, NTIA evaluates spectral emissions by plotting a line intersecting the measured 3 dB, 20 dB, and 60 dB attenuation points (provided by the project) on the log scale PSD plots. The plotted line is then compared with the NTIA mask for compliance. Missions that do not meet this standard fall subject to Section 5.1.2 of the NTIA Manual. This section states, In any instance of harmful interference caused by nonconformance with the provisions of this chapter, the responsibility for eliminating the harmful interference normally shall rest with the agency operating in nonconformance. The NTIA mask applies for all unwanted emissions; the NTIA does not define separate regions for out-of-band emissions and spurious emissions. D.4.2 NTIA Emissions Mask Example

This section presents an example of a test of conformance with the NTIA emissions mask, using an ideal unfiltered and a filtered 3 Mbps BPSK signal. In Figure D-6, the spectra are plotted versus percentage of necessary bandwidth (%). From Figure D-6, it can be seen that the Filtered BPSK spectral emissions from the -3, 20, and -60 dB points meet the requirements of the NTIA mask over the applicable frequency range. However, the unfiltered BPSK exceeds the mask by a significant amount.

Revision 9

D-14

450-SNUG

0.00 Unfilered BPSK -10.00 NTIA Emissions Mask Filtered BPSK -3, -20, and -60 dB Points Attenuation (dBs/Reference Bandwidth) -20.00 Line Connecting -3, -20, -60 dB Points for Filtered BPSK

-30.00

-40.00

-50.00

-60.00

-70.00
0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 1000

Percentage of Necessary Bandwidth (%)

Figure D-6. Example of Unfiltered and Filtered BPSK PSDs and NTIA Mask

D.4.3

ITU Unwanted Emission Limits

This section provides information on the ITU-R unwanted emission limits. Satisfying the NTIA unwanted emissions mask is generally both a necessary and sufficient condition for satisfying the ITU-R requirements. The ITU-R defines unwanted emissions in two separate regions. The region just outside the necessary bandwidth is the out-of-band region; the region farther out is the region of spurious emissions. Recommendation ITU-R SM.1539-1 defines the boundary region. In general, the boundary between the out-of band emissions and the spurious emissions is 250% of the necessary bandwidth, but there are some exceptions. ITU Radio Regulation RR No. 3.8 states that, in regards to out-of-band emissions, transmitting stations should, to the maximum extent possible, satisfy the most recent ITU-R Recommendation, which in this case is Recommendation ITU-R SM.1541-1. The out-of-band emission mask for space services is defined in Annex 5 of Recommendation ITU-R SM.1541. However, there is currently no ITU mask applicable for space services operating space-to-space links in the out-of-band region. ITU Radio Regulation RR No. 3.7 states that transmitting stations shall conform to the maximum permitted spurious emission power levels specified in ITU RR Appendix 3. Table II of Appendix 3 shows that for space services, the peak attenuation in the

Revision 9

D-15

450-SNUG

spurious emission region is 43 + 10 log P, or 60 dBc, whichever is less stringent. P is defined to be the power (in Watts) supplied to the antenna transmission line. D.5 Frequency Tolerance

Section 5.2.1 of the NTIA manual indicates that the frequency tolerance for space services is 20 parts per million (ppm). Missions that do not meet this standard fall subject to Section 5.1.2 of the NTIA Manual. This section states, In any instance of harmful interference caused by nonconformance with the provisions of this chapter, the responsibility for eliminating the harmful interference normally shall rest with the agency operating in nonconformance. D.6 Cessation Of Transmissions

Article 22.1 of the ITU Radio Regulations states that, space stations shall be fitted with devices to ensure immediate cessation of their radio emissions by telecommand, whenever such cessation is required under the provisions of the ITU Regulations. The NTIA has a similar requirement. Section 8.2.32 of the NTIA manual indicates that the use of space stations will be authorized only in those cases where such stations are equipped so as to ensure the ability to turn on, or to provide immediate cessation of emissions by telecommand. D.7 Protection Of Deep Space Earth Stations

TDRSS S-band links operating in the upper portion of the 2200 2290 MHz band have the potential to cause unacceptable interference to deep space missions operating in the 2290 2300 MHz band. Recommendation ITU-R SA.1157 defines protection criteria for deep space operations in the 2 GHz band. This recommendation indicates that the protection criterion for deep space Earth stations operating near 2 GHz is that the interference at the input to the deep space earth station receiver should not exceed -222 dBW/Hz and current NASA policy is that this criterion must be met 100% of the time. This protection criterion is measured at the deep space Earth station after accounting for the receiving antenna gain. Platforms operating in the upper portion of the 2200 2290 MHz band need very stringent filtering to meet the deep space protection criteria. In particular, a platform using the 2287.5 MHz TDRSS return links with a necessary bandwidth of 5 MHz or higher will easily violate the deep space protection criteria when it transmits sufficiently close to the beam of a DSN 70 meter or 34 meter antenna. Mitigation techniques such as filtering out sideband emissions have been very successful to meet the deep space protection criterion. In particular, the NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier minimizes the interference in the DSN band with a reasonable implementation loss. Figure D-7 shows the output spectral plot of the NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier. Figure D-8 shows an example of the spectral output of an unfiltered BPSK signal vs. a signal filtered by the NASA/GSFC

Revision 9

D-16

450-SNUG

0 -10 Attenuation (dB) -20 -30 -40 -50 -60 -70 2286 NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier

2288

2290

2292

2294

2296

2298

2300

Frequency (MHz)

Figure D-7. Spectral Output for NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier
-180 -190 -200 -210 -220 -230 -240 -250 -260 -270 -280 -290 2287.5

Center Frequency of Signal: 2287.5 MHz Modulation: 3.078 Mcps PN Code EIRP towards DSN: 0 dB Slant Range to DSN: 400 km DSN Antenna Gain: 32 dBi (at 1 deg from boresite)

PSD (dBW/Hz)

2289.5

2291.5

2293.5 2295.5 Frequency (MHz)

2297.5

2299.5

Spectrum with 'NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier' Unfiltered Spectrum DSN Protection Criteria

Figure D-8. Example of Unfiltered and Filtered 3 Mcps Code with DSN Protection Criteria

Revision 9

D-17

450-SNUG

Recommended Filtering Referenced to the Output of the Power Amplifier and compares them to the DSN protection criterion. The use of filtering with performance consistent or better than the NASA/GSFC Recommended Filtering Referenced to the Output of the Power Amplifier is strongly encouraged due to the considerable benefits that this provides. For example:

The DSN coordination angle, which is defined as the angle off of the DSN mainbeam gain where the SN 2287.5 MHz customer meets the DSN protection criterion, is reduced by a factor of three and six in the 1st and 2nd sidelobes, respectively, for a mission with this filter as compared to a mission without this filter. This reduction in coordination angle results in filtered missions exceeding this coordination angle approximately one-tenth of the time that a mission without a filter exceeds the coordination angle.

NASA/GSFC has reached certain informal agreements with NASA/JPL that will substantially reduce the amount of spacecraft turn-off for any TDRS user that implements the NASA/GSFC recommended filtering, and that exempts such missions from having to do the complex orbital conjunction analyses to predict spacecraft turn-off times. To determine the best solution to protect the DSN Space Network, the mission Project Office should contact its corresponding Center Spectrum Manager. The three NASA deep space Earth stations are located at Goldstone, CA; Madrid, Spain; and Canberra, Australia. Additional information on the deep space Earth stations can be found in the CCSDS 411.0-G Green Handbook on RF Frequency and Modulation Systems, Part 1, Earth Stations. This handbook is available at the following website: http://public.ccsds.org/publications/archive/401x0b09s.pdf. Information on the DSN is also available at http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/. D.8 Preferred Frequencies for Launch Vehicles

NASA has agreements with other administrations to use the following preferred frequencies to support launch vehicles: a. 2211 MHz +/- 4 MHz b. 2215 MHz +/- 4 MHz c. 2272.5 MHz +/- 2 MHz d. 2285 2300 MHz Frequencies outside the preferred frequencies are acceptable, but frequency coordination may be more difficult. D.9 Additional Applicable Recommendations

The following ITU-R Recommendations are of particular interest to missions utilizing the Space Network.

Revision 9

D-18

450-SNUG

a. SA.1154 Provisions to protect the space research (SR), space operations (SO) and Earth-exploration satellite services (EES) and to facilitate sharing with the mobile service in the 2025-2110 and 2200-2290 MHz bands. b. SA.1155 Protection criteria related to the operation of data relay satellite systems. c. SA.1414 Characteristics of Data Relay Satellite Systems. d. S.672 Satellite Antenna Radiation Pattern for use as a Design Objective in the Fixed-Satellite Service Employing Geostationary Satellites.

Revision 9

D-19

450-SNUG

This page intentionally left blank.

Revision 9

D-20

450-SNUG

Appendix E. Customer Platform and TDRS Signal Parameter Definitions

E.1

General

This Appendix defines the salient characteristics of the TDRSS forward service to a customer platform and the parameters which constrain the customer platform transmitted signal. The specifications of these parameters are given in Tables 5-3 (MAF), 6-4 (SSAF), 7-3 (KuSAF), 8-3 (KaSAF), 5-11 (MAR), 6-12 (SSAR), 7-9 (KuSAR), and 8-9 (KaSAR), respectively. E.2 Symbol (Data) Asymmetry a. For the NRZ signal format, symbol (data) asymmetry is defined as follows:
length of long symbol - length of short symbol 100% length of long symbol + length of short symbol

b. For the Biphase format signal (S-band DG2 only), data asymmetry applies to both the entire symbol and to each half-symbol pulse. Therefore, for Biphase, symbol (data) asymmetry is defined as follows: 1. For the entire symbol:
length of long symbol - length of short symbol 100% length of long symbol + length of short symbol

2.

For the half-symbol pulse:

length of long half symbol pulse - length of short half symbol pulse 100% length of long half symbol pulse + length of short half symbol pulse

E.3

Symbol (Data) Rise Time

Symbol (data) rise time is the time required to switch from 90 percent of the initial data state to 90 percent of the final data state as a percentage of symbol duration. Symbol (data) rise time is illustrated in Figure E-1.

Revision 9

E-1

450-SNUG

FINAL STEADY STATE 1 .9

-.9 -1 INITIAL STEADY STATE DATA TRANSITIO N TIM E

Figure E-1. Symbol (Data) Rise Time E.4 Symbol (Data Bit) Jitter and Jitter Rate

Symbol (data bit) jitter is defined as the peak frequency deviation from the desired symbol clock frequency expressed as a percentage of the symbol clock frequency. A mathematical description of this definition follows. A symbol clock with symbol jitter can be expressed as follows:
c (t ) = sgn [cos( 2f s t + (t )]

where
f s = desired symbol rate

(t ) = symbol clock phase jitter

2f s t + (t ) = (t ) = symbol clock phase in radians

The frequency of the symbol clock is as follows:

fc = d (t ) 1 d (t ) 1 = fs + dt 2 dt 2

Hz

It can be seen that the clock frequency is comprised of a constant component and a time-varying component. Symbol jitter is defined as the peak absolute value of the time-varying portion of the symbol clock frequency:

d (t ) 1 f = max abs dt 2

= symbol jitter in Hz

Symbol jitter expressed as a percentage of the symbol clock rate can be computed as follows:

Revision 9

E-2

450-SNUG

 1 d (t ) 1 100% = max abs f dt 2 s symbol clock rate f

1 100% = symbol jitter as a % of the f s

If the jitter is random, the 3 value of the symbol clock frequency jitter may be used in the above expression. The symbol jitter rate is defined as the maximum frequency component, fm, in the symbol clock frequency jitter power spectral density (i.e., the symbol clock frequency jitter spectral distribution is from 0 to fm Hz). For KuSAR special constraints apply. These constraints are as follows: a. The WSC will be provided with scheduling parameters from the NCCDS which categorizes the input jitter for each channel into one of six ranges: None, 0.01%, 0.1%, 0.5%, 1.0%, and 2.0%. The last three of these are valid only for the Shuttle. The constraints governing each of the first three cases are detailed below: 1. Jitter = None (Coded or Uncoded Data). When the scheduled jitter parameter for a data channel is "None" and the data is either coded or uncoded, then f = fm = 0. Jitter = 0.01% (Coded or Uncoded Data). When the scheduled jitter parameter for a data channel is "0.01%" and the data is either coded or uncoded, f and fm will lie as shown in Figure E-2 for all symbol rates up to and including 150 Msps.

2.

f/R s
0.1% 0.01%

0.01%

0.1%

fm /R s

Figure E-2. Coded and Uncoded Data at 0.01% Jitter 3. Jitter = 0.1% (Coded or Uncoded Data). When the scheduled jitter parameter for a data channel is "0.1%" and the data is uncoded, f and fm will lie as shown in Figure E-3 through Figure E-6, as appropriate, depending on symbol rate. When the data is coded, f and fm will lie as shown in Figure E-6, independent of symbol rate.

Revision 9

E-3

450-SNUG

f/R s
0.1% 0.01%

0.01%

0.1%

fm /R s

Figure E-3. Uncoded Data at 0.1% Jitter for Rs < 20 MSPS

f/R s
0.1% 0.01%
(0.08, 0.1) (0.1, 0.03)

0.01%

0.1%

fm /R s

Figure E-4. Uncoded Data at 0.1% Jitter for (20 < Rs < 40) MSPS

f/R s
0.1% 0.01%
(0.01, 0.1) (0.058, 0.017) (0.1, 0.03)

0.01%

0.1%

fm /R s

Figure E-5. Uncoded Data at 0.1% Jitter for (40 < Rs < 75) MSPS

f/R s
0.1% 0.01%
(0.0026, 0.1) (0.03, 0.009) (0.1, 0.03)

0.01%

0.1%

fm /R s

Figure E-6. Uncoded Data at 0.1% Jitter for (75 < Rs < 150) MSPS Coded Data at 0.1% Jitter for (Rs < 150) MSPS

Revision 9

E-4

450-SNUG

E.5 E.5.1 E.5.1.1

Phase Imbalance Suppressed Carrier BPSK

BPSK phase imbalance is defined as, = 180 - , where is the phase imbalance and is the value of the phase angle between the two BPSK signal vectors; as shown in Figure E-7.

Figure E-7. BPSK Phase Imbalance E.5.1.2 QPSK

QPSK phase imbalance is defined as = max |i - ideal| where is the phase imbalance and the four actual phase angles {i} are as shown in Figure E-8.

Figure E-8. QPSK Phase Imbalance

Revision 9

E-5

450-SNUG

ideal is the value of each illustrated phase under distortion-free conditions and, for example, is given by: ideal = 90 degrees; Q/I (power) = 0 dB = 126.87 degrees or 53.13 degrees; Q/I (power) = 6 dB E.5.2 Residual Carrier

For residual carrier modes of operation, a phase imbalance constraint is not specified because the modulation index tolerance constraint supersedes this constraint. E.6 E.6.1 Gain Imbalance Suppressed Carrier

Gain imbalance, G, is defined by the following relationship: G = 20 log10 [max (Ri/Rj)] at customer platform HPA output where Ri and Rj are the magnitudes of the signal modulation vectors at the customer platform high power amplifier (HPA) output in the absence of incidental AM and varying modulation. Figure E-9 and Figure E-10 show BPSK and QPSK gain imbalance, respectively.

R2 R1

Figure E-9. BPSK Gain Imbalance

Revision 9

E-6

450-SNUG

R1 R2 2

4 R3

R4

Figure E-10. QPSK Gain Imbalance E.6.2 Residual Carrier

For residual carrier cases, gain imbalance is defined as follows: G = 20 log10 [max (Rideal/(Rmax or Rmin))] Gain imbalance is illustrated in Figure E-11.
Q Rideal I

Rmax

Figure E-11. Residual Carrier Gain Imbalance

Revision 9

E-7

450-SNUG

E.7

Phase Nonlinearity

Phase nonlinearity is defined as the peak deviation of the phase from the best linear fit to the phase response over the bandwidth of interest, as illustrated in Figure E-12.
PHASE

ACTUAL PHASE LINEAR FIT

0 (M / AXIM ) UM

BANDW IDTH O F INTEREST

FREQ UENCY

Figure E-12. Phase Nonlinearity E.8 Gain Flatness

Gain flatness is defined as the peak deviation of the gain from the best horizontal fit to the gain response over the bandwidth of interest, as illustrated in Figure E-13.
G AIN

G AIN (M AXIM ) UM SLO = 0 PE

ACTUAL G AIN

FREQ UENCY BANDW IDTH O INTEREST F

Figure E-13. Gain Flatness

Revision 9

E-8

450-SNUG

E.9

Gain Slope

Gain slope is defined as the peak absolute value of the derivative of the gain response (relative to the frequency) over the bandwidth of interest, as illustrated in Figure E-14.
G AIN

SLO PE

FREQ UENCY BANDW IDTH O INTEREST F

Figure E-14. Gain Slope E.10 AM/PM

AM/PM is defined as the peak absolute value of the derivative of the amplifier output phase (relative to the input power) over the operating range of the RF output stages, as described by the following equation and as illustrated in Figure E-15. AM/PM = worst-case
d out over the range of operating points dPin
AM / PM DEFINITIO N

/ UT OO

/ UT d OO d PIN PIN

Figure E-15. AM/PM Definition For forward service: Pin = RF power input in dBW to cascaded WSC/GRGT and TDRS HPAs. out = RF phase output in degrees from cascaded WSC/GRGT and TDRS HPAs.

Revision 9

E-9

450-SNUG

For return service: Pin = RF power input in dBW to user transmitter HPA. out = RF phase output in degrees from user transmitter HPA. E.11 Frequency Stability

Frequency stability is the peak instantaneous carrier frequency deviation from the nominal carrier frequency normalized by the nominal carrier frequency as observed over the specified time interval of interest. This includes frequency deviation due to all sources including deviations induced by environmental changes. (This parameter only applies to the noncoherent return mode of operation). E.12 Incidental AM

Incidental AM is the undesired amplitude modulation superimposed on the carrier and present at the HPA output. This parameter is expressed as a modulation percentage relative to the carrier amplitude. This distortion can be shown mathematically on a continuous wave signal as follows:
A [1 + m i cos ( t + i)] cos [c t + ] i i

where mi represents the amplitude of the ith AM component, i represents the frequency of the ith component, i represents the phase of the ith component, c represents the carrier frequency, and represents the arbitrary phase of the carrier. The power of the 1 ith component is mi2 . 2 The incidental AM (peak) is defined by:

mi x 100 percent
i

E.13

Spurious PM

Spurious PM is the residual or unwanted phase modulation at the HPA output, in the absence of data modulation, that is characterized by a discrete spectrum. This distortion can be shown mathematically on a continuous wave signal as follows:
A cos c t + +

a
i

cos (c + i)t + Di

]]

where c represents the carrier frequency, represents the arbitrary phase of the carrier, ai represents the amplitude of the ith component, i represents the frequency of

Revision 9

E-10

450-SNUG

the ith component, and Di represents the phase of the ith component. The power of the 1 ith component is ai2 . 2 Spurious PM is generally specified as a limit on total spurious PM power (in degrees rms). Total spurious PM can be computed as follows:
= 180 1 a 2 deg rms D 2i i
E.14 Phase Noise Phase noise is residual or unwanted phase modulation that is characterized by a continuous spectrum. This distortion can be shown mathematically on a continuous wave signal as follows:
A cos [c t + + n (t)]

where c represents the carrier frequency, represents the arbitrary phase of the carrier, and n(t) is the undesired phase modulation having a one-sided continuous spectrum, Sn(t) rad2. Phase noise is generally specified as a collection of phase noise limits (in degrees rms) over various frequency ranges offset from the carrier frequency. Phase noise in the frequency range fa to fb (offset from the carrier frequency) can be computed as follows:
n = 180

fb fa

(f ) df deg rms

For the coherent turnaround mode, constraint values assume no phase noise on the signal received by the customer platform; it, therefore, represents the phase noise added by the customer platform, including a contribution due to forward link carrier recovery. Values indicated for the coherent mode represent total output phase noise of the customer platform.
E.15 In-band Spurious Outputs

In-band spurious outputs is the sum of the power of all in-band spurs measured relative to the total signal power (dBc indicates dB below total signal power); where in-band is defined as 2x the maximum channel baud rate.
E.16 Out-of-Band Emissions

Out-of-band emissions are defined as emissions outside of the allocated band of operation. See Appendix D for a further description of out-of-band emissions.

Revision 9

E-11

450-SNUG

E.17

I/Q Symbol (Data) Skew

For QPSK, the ideal time delay between the symbol (data) transitions on the I channel and the symbol (data) transitions on the Q channel is zero. For SQPSK, the ideal time delay between the symbol (data) transitions on the I channel and the symbol (data) transitions on the Q channel is 0.5Ts (where Ts is the channel symbol duration). I/Q symbol (data) skew is the deviation from this ideal relative time delay measured as a percent of the symbol (bit) time. I/Q symbol (data) skew is defined mathematically as follows: I/Q symbol (data) skew =

Ts

100%

Where is as defined in Figure E-16 for the QPSK case. For SQPSK, is relative to the ideal 0.5Ts interval between symbol (data) transitions on the I and Q channels.

Data Level

I Channel

Q Channel

Ts

2Ts

3Ts

4Ts

5Ts

6Ts

7Ts

8Ts

9Ts

10Ts

11Ts 12Ts

Time

Figure E-16. Description of I/Q Data Skew Assuming QPSK Modulation E.18 PN Chip Skew

PN chip skew is the deviation of the chip transitions between the I (or command channel for forward) and the Q (or range channel for return) from the ideal time delay.

Revision 9

E-12

450-SNUG

E.18.1

Return I/Q PN Chip Skew

The ideal time delay between the chip transitions on the I channel and the chip transitions on the Q channel is 0.5Tc (where Tc is the PN code chip duration). I/Q chip skew is the deviation from this ideal time delay. I/Q PN chip skew is defined in Figure E-17.

Data Level I Channel

Q Channel

0.5T c

1T c 1.5T c

2T c 2.5T c 3T c 3.5T c 4T c 4.5T c 5T c 5.5T c 6T c 6.5Tc

7T c 7.5T c 8T c

Time

Figure E-17. Definition of I/Q PN Code Chip Skew E.18.2 Command/Range Channel PN Chip Skew

The ideal time delay between the chip transitions on the command channel and the chip transitions on the range channel is zero. The command/range channel PN chip skew is the deviation from this ideal time delay.
E.19 PN Chip Asymmetry

PN chip asymmetry is defined as follows:

length of long chip - length of short chip 100% length of long chip + length of short chip

E.20 PN Chip Jitter PN code chip jitter is defined as the unwanted phase variations of the PN code chip clock measured in degrees rms. A PN code chip clock with PN code chip jitter can be expressed as follows:
c(t ) = sgn cos( 2f pn t + (t )

Revision 9

E-13

450-SNUG

where
f pn = desired PN code chip rate in Hz

(t ) = PN code chip clock phase jitter in radians

The PN code chip jitter is the rms value of (t ) expressed in degrees.
E.21 PN Chip Rate

PN code chip rate is defined as the peak deviation of the actual PN chip rate from the desired PN chip rate (where the desired PN chip rate is defined as the PN chip rate which results in absolute coherence with the carrier rate).
E.22 Noncoherent and Coherent Turnaround PN Power Suppression

PN power suppression is the effective reduction in despread signal power due to the presence of timing imperfections (asymmetry and jitter) in the customer platform transmitter PN clock. Under noncoherent conditions, jitter will be solely due to the transmitter's oscillator. Under coherent turnaround conditions, it will also reflect forward link PN tracking in the absence of PN jitter on the signal received by the customer platform.
E.23 Antenna-Induced AM

Antenna-induced AM is amplitude modulation inadvertently induced on the transmit signal by the antenna. This distortion is generally caused by the slight, unavoidable movements of the antenna during transmission.
E.24 Antenna-Induced PM

Antenna-induced PM is phase modulation inadvertently induced on the transmit signal by the antenna.
E.25 Axial Ratio

For circularly polarized antennas, the electrical field vector usually produced describes an ellipse instead of a circle. The axial ratio is a measure of ellipticity of the customer platform transmitting antenna and is the ratio of the major axis of the ellipse to the minor axis.
E.26 Data Rate Tolerance

Data rate tolerance is the allowable difference between the actual data rate and the desired data rate measured as a percentage of the desired data rate.
E.27 Power Ratio Tolerance

Power ratio tolerance is the ratio of the actual I/Q channel power ratio to the desired I/Q channel power ratio.

Revision 9

E-14

450-SNUG

E.28

Permissible EIRP Variation

Permissible EIRP variation is the range over which the customer platform EIRP, measured along the customer platform/TDRS line-of-sight, may vary without requiring customer platform reconfiguration. Performance is determined from customer platform transmitter power variation, transmit antenna pattern, worst case customer platform orientation, and maximum variation in range between the customer platform and the TDRS over the duration of a pass.
E.29 Rate of EIRP Variation

Rate of EIRP variation is the time derivative of the customer platform EIRP.
E.30 Maximum User EIRP

Maximum user EIRP is the maximum allowable user EIRP transmitted toward a TDRS.
E.31 Modulation Index Accuracy

Modulation index accuracy is the peak deviation of the modulation index from the desired modulation index as a percentage of the desired modulation index. Modulation index accuracy is defined as follows:
peak deviation from the desired mod index 100% desired mod index

E.32

Subcarrier Frequency Accuracy

Subcarrier frequency accuracy is the maximum deviation of the subcarrier frequency from the desired subcarrier frequency.
E.33 Data Transition and Subcarrier Coherency

Coherency between the data transition and the subcarrier zero-crossing is measured in degrees of the subcarrier cycle.
E.34 Subcarrier Phase Noise

Subcarrier phase noise is unwanted phase modulation to the subcarrier. paragraph E.14 for a general description of phase noise.
E.35 Maximum Frequency Error of 8.5 MHz Subcarrier

See

The maximum frequency error of 8.5 MHz Subcarrier is the peak instantaneous subcarrier frequency deviation from the nominal subcarrier frequency normalized by the nominal subcarrier frequency.

Revision 9

E-15

450-SNUG

E.36

Minimum EIRP for TDRSS Ku-Band Autotrack

This is the minimum EIRP required to ensure nominal autotrack acquisition and performance.
E.37 Short Term EIRP Stability

This is the peak variation in user EIRP over a time duration as described by the specification.
E.38 Minimum 3 dB Bandwidth Prior to the Power Amplifier

This is the double-sided 3 dB bandwidth introduced by the transmitters channel filtering, including any modulator effects, prior to the power amplifier.

Revision 9

E-16

450-SNUG

Appendix F. Periodic Convolutional Interleaving with a Cover Sequence for Synchronization

F.1

General

This Appendix describes (n, m) Periodic Convolutional Interleaving (PCI) which, when used with the appropriate periodic convolutional deinterleaving, guarantees separation of any two symbols within n of each other in the interleaved symbol sequence to be at least nm/(n-1) symbols between each other in the deinterleaved sequence. PCI is recommended on S-band DG1 mode 3 and DG2 return services for channel baud rates > 300 kbps. At these higher data rates, any single RFI pulse affects multiple adjacent transmitted symbols. The effectiveness of the ground terminal Viterbi decoding process decreases as the number of adjacent symbols overlapped increases. The purpose of the periodic convolutional interleaving (and associated ground terminal deinterleaving) is to break up or spread out these corrupted symbols so that they appear at the Viterbi decoder input to be random in their occurrence just as if they arose from a channel without memory. When interleaving is not employed for DG1 mode 3 and DG2 channel baud rates > 300 kbps, S-band return performance may not be guaranteed. Deinterleaving is not supported for baud rates < 300 kbps. Additionally, biphase symbol formats are not allowed with PCI. Use of biphase symbol formats on DG2 S-band services at baud rates > 300 kbps should be coordinated with GSFC Code 450. F.2 F.2.1 (30,116) Periodic Convolutional Interleaving Interleaving

The encoded symbol sequence interleaving is shown in Figure F-1 as commutated delay elements. The input and output commutators are slaved, advanced for each encoded symbol, and recycled every 30 symbols. The input to the zero delay element of the interleaver is always a G1 encoder symbol modulo-2 added to the initial cover sequence state (please see paragraph F.2.2). F.2.2 Cover Sequence

The cover sequence is modulo-2 added bit-by-bit to the preinterleaved symbols to provide for perfect deinterleaving synchronization. The cover sequence is:
first bit last bit 000001110010001010111101101001

where the first bit is for the zero delay element and the last bit is for the 116 delay element of the interleaving.

Revision 9

F-1

450-SNUG

F.2.3 F.2.3.1

Synchronization Cover Sequence

The cover sequence is synchronized with the interleaving delay selection so that the first bit occurs during the zero delay selection by the interleaving commutation (commutator positions as shown in Figure F-1). F.2.3.2 Convolutional Encoding

The convolutional encoding is synchronized with the interleaving delay selection so that the symbol from the G1 generator of the convolutional encoding occurs during the zero delay selection by the interleaving commutation (commutator positions as shown in Figure F-1). F.2.3.3 Timing Synchronization

The encoding, cover sequence generation, modulo-2 addition, and interleaving (commutation and delay) will be time synchronous.

Revision 9

F-2

450-SNUG

Revision 9
ENCODER SYMBOLS COVER SEQUENCE

G1 INPUT

4D

8D

12D

28

112D

29

F-3 450-SNUG

116D

Note D = Delay element

Figure F-1. Periodic Convolutional Interleaving

This page intentionally left blank.

Revision 9

F-4

450-SNUG

Appendix G. Predicted Performance Degradations Due to RFI

G.1

General

G.1.1 Certain portions of the RF spectrum used by TDRSS are also occupied by independent ground-based transmitters, which may introduce RFI. Although RFI may be present at S-, Ku-, and Ka-band frequencies, current indications and performance evaluations suggest that only S-band RFI warrants concern at this time. The interference environment and any associated RFI model is constantly changing and RFI should be dealt with on a case-by-case basis for each customer. The customer community will, however, be kept abreast of significant changes if they occur. Please contact GSFC Code 450 for further information. G.1.2 Both forward and return service performance may be affected by RFI, with the return service impact of most potential significance. The RFI impact on forward service performance is heavily dependent on the customer platform orbit and varies rapidly with time; therefore, forward service RFI must be treated on a customer-unique basis. On the other hand, the effects of return service RFI change much more gradually with time and an assessment may be developed which has broad applicability to virtually all TDRSS customers. G.1.3 The major RFI problem to which this Appendix is devoted concerns S-band RFI emitters, which are expected to degrade the performances of the SSA and MA return service. These degradations are treated as increased required Prec or, equivalently, as additional customer platform EIRP required above the value which would suffice in an RFI-free environment. As will be described, there are many variables and uncertainties associated with these degradation estimates, so that customers are urged to include additional margins in their customer platform EIRP specifications within: economic constraints, the maximum Prec restrictions of Section 5 (MA) and Section 6 (SSA), and the allowable excess margin. The Final Acts of the World Administrative Radio Conference-92 (WARC-92) re-allocated portions of S-band frequencies to fixed service users. As more fixed service users move into this band, this re-allocation may have an RFI impact on SN operations in S-band. Each customer should coordinate with GSFC Code 450 to determine the RFI levels and mitigation techniques for their specific mission.

Revision 9

G-1

450-SNUG

Two systems are available to customers for predicting possible interference. The Automated Conflict Resolution System (ACRS) predicts mutual interference between two or more customer platforms scheduled on the same TDRS at the same time. Customer MOCs receive ACRS output and may alter their schedules based upon the interference mitigation techniques provided by ACRS. The TDRS Look Angle System (TLAS) plots the TDRS look angles as it tracks the customer platform and predicts periods of ground based RFI and earth multipath. Both systems use TDRS and customer orbital data as inputs as well as customer schedules received directly at the NCCDS. G.2 Factors Influencing Degradation

G.2.1 A number of factors or parameters determine the degree of performance degradation from RFI on any particular service. Different RFI environments are expected at the TDRSs (such as more RFI for TDRS-East than for TDRS-West). Intentional offpointing of the TDRS SA antenna away from the geographic zone containing the RFI emitters will serve as a direct means of RFI mitigation. Customer platform signal parameters are significant, particularly the return service used (MA or SSA), the convolutional code rate (rate 1/3 is optional for some SSA and SMA applications), and the degree of compliance with the signal quality customer platform constraints. G.2.2 The largest element of uncertainty in determining RFI degradation estimates concerns the RFI environment itself. The environment is constantly changing and GSFC Code 450 will be kept informed of the changes in the environments in which the SN operates. G.3 Need For Channel Coding and Periodic Convolutional Interleaving

G.3.1 Forward error control coding not only provides a performance improvement against thermal noise, but it also makes the service performance less sensitive to RFI degradations. Clearly, even very occasional bursts of interference drive the BER up to an unacceptable value on an uncoded system. These same errors on the encoded symbols of a coded system are unlikely to result in output errors after the decoding process. For this reason, convolutional encoding should be used on all MA and SSA return services, using the code formats and rates given in Appendix B. G.3.2 At SSA return service data rates in which the encoded baud rate exceeds 300,000 symbols per second, the use of periodic convolutional interleaving (PCI) is required for the current estimated RFI environments. At these higher data rates, any single RFI pulse affects multiple adjacent transmitted symbols. The effectiveness of the ground

Revision 9

G-2

450-SNUG

terminal Viterbi decoding process decreases as the number of adjacent symbols overlapped increases. The purpose of the periodic convolutional interleaving (and associated WSC deinterleaving) is to break up or spread out these corrupted symbols so that they appear at the Viterbi decoder input to be random in their occurrence just as if they arose from a channel without memory. G.3.3 If the RFI environment becomes more severe in the future than currently estimated, return service periodic convolutional interleaving may be necessary below 300,000 symbols per second. This will be ascertained during the mission planning and RF ICD development activities between the customer project and GSFC Code 450. G.4 SSA RFI Degradation Estimates

G.4.1 Prior to the fixed service re-allocation into the S-band, a detailed evaluation of the SSA return service RFI impact has been performed. This evaluation involved a rigorous BER analysis based on the use of analytical models of the customer platform communications terminal, the TDRSS channel, the RFI environment (both noiselike and sinusoidal pulses), and the ground terminal Viterbi decoding process. Corresponding RFI degradation results for the SSA maximum data rate (the worst case) and for the appropriate convolutional code rate and/or data group are shown in Table G-1. Assumptions used in determining these values are that all customer platform constraints are met and the EIRP offers no margin to offset RFI degradation. RFI degradation estimates for 0 offpointing (i.e., the TDRS SSA antenna beam is pointing directly at the location of the RFI sources) for TDRS-East are not included in the table due to the severe RFI degradation incurred (>5 dB) and the impracticality of operating under such conditions. G.4.2 When an SSA customer has refined his return service communications system design sufficiently, the Communications Link Analysis and Simulation System (CLASS) is used to predict return service performance. During the RF ICD process, the RFI degradation to SSA return service performance will be determined for each customer platform return service based on the customer platform transmit signal parameters (including code and data rates) and characteristics (customer platform constraints), operating frequency, and orbital parameters. These results also include the effect of any interaction between the RFI and the customer platform design partial compliance with the customer platform constraints. This degradation will then be incorporated into RF ICD link calculations.

Revision 9

G-3

450-SNUG

Table G-1. Estimates of RFI Degradations on SSA Return Services

Customer Platform EIRP Increase to Offset RFI (dB) (notes 1 & 3) Conditions (note 2) TDRS-East 1.5-degree Offpointing 4-degree Offpointing TDRS-West 0-degree Offpointing 1.5-degree Offpointing 4-degree Offpointing 2.3 1.0 0.5 2.6 1.2 0.5 1.0 0.6 0.5 2.7 1.0 3.3 1.2 1.5 0.5 Rate 1/2 Convolutional Encoding DG1 DG2 Rate 1/3 Convolutional Encoding DG2

Notes: 1. EIRP increase is determined for the maximum data rate applicable to the particular data group and code rate. 2. Offpointing is the number of degrees the TDRS SA antenna is pointed away from the location of the ground-based RFI sources. 3. RFI degradations are worst-case estimates based upon maximum data rate and will be determined during the customer platform RF ICD process. Link calculations will consider the customers characteristics to determine the RFI degradation.

G.5

MA RFI Degradation Estimates

G.5.1 Prior to the fixed service re-allocation into the S-band, a detailed evaluation of the MA return service RFI impact has been performed as described in paragraph G.4. Using the estimate of the RFI environment in the MA return service band as seen by TDRS-East, the estimate of RFI degradation is <0.5 dB for all data rates between 1 and 300 kbps. The analysis assumes no MA antenna beam offpointing, that all customer platform constraints are met, and that the EIRP offers no margin to offset RFI degradation. Contact GSFC Code 450 for MA RFI degradation values for data rates greater than 300 kbps (SMA only). During the RF ICD process, the RFI degradation to MA return service performance will be determined and incorporated into the RF ICD link calculations. G.5.2 CLASS is also used to predict MA return service performance as described for the SSA customer platform in paragraph G.4.

Revision 9

G-4

450-SNUG

G.6

SSA and MA Forward Service RFI Degradation

As briefly indicated in paragraph G.1, the RFI impact on forward service operation is extremely sensitive to customer platform orbit and is a rapidly varying function of time. Accordingly, forward service RFI considerations are treated on a customer-unique basis.

Revision 9

G-5

450-SNUG

This page intentionally left blank.

Revision 9

G-6

450-SNUG

Appendix H. Demand Access System (DAS)

H.1 H.1.1

Overview and Purpose Overview

The F1-F7 TDRSs provide communication services to customers by using groundbased electronics to process signals emanating from customer emitters that are relayed by the F1-F7 TDRS MA on-board phased array antenna systems (refer to SNUG Section 3, paragraph 3.2.1, MA Service Overview). The Demand Access System (DAS) allows the TDRSS F1-F7 MAR capability to be scheduled for extended durations or in a near real time manner. DAS provides DG1 mode 2 return services only. DAS is operated as a part of the SN using the first-generation satellites (F1-F7) only. DAS is not capable of operations with the second-generation satellites (F8-F10). Please contact GSFC Code 450 or check the DAS web site at http://stelwscpo.gsfc.nasa.gov/Das/index_ie.htm for additional information. NOTE: DAS does not provide tracking services.

H.1.2

Purpose

The purpose of DAS is to: a. Provide a capability to support continuous or intermittent, conflict-free, MAR link services 24 hours per day, 7 days per week upon demand from customers. b. Provide an automated capability to transition customer services between TDRSs/SGLTs. c. Provide a capability to support multiple, DAS MA return links per TDRS/SGLT/Ground Station.

d. Provide equivalent or better communications performance and capabilities for the TDRS F1-F7 MAR DG1 Mode 2 link services (please see MAR telecommunications services in Section 5) with the exceptions of no DAS tracking (i.e. no one-way return Doppler) and the functions not possible due to the lack of tie-ins with the MA forward link (coherent turnaround support, cross support, two-way ranging, and two-way Doppler).

Revision 9

H-1

450-SNUG

NOTE: Early testing showed that acquisition times for a Customer platform operating at < 2 Kbps could be worse than acquisition time performance specified in Table 5-8. The test results for the same system operating at 2 Kbps were within the performance specified in Table 5-8. Contact Code 450 for additional information. e. Provide both QPSK and BPSK demodulation for PN spread signals. Return Channel Time Delay or any other measuring service is not available from DAS since signal delay is variable (output from DAS to NISN to the Customer is Transmission Control Protocol (TCP)/Internet Protocol (IP)) depending on loading and the extent of DAS processing desired. f. Provide beamforming, demodulating, data distributing and short term storage capabilities for each service.

g. Provide automated operation of all DAS resources. h. Provide resource allocation accounting. i. Provide Commercial Off-The-Shelf (COTS) data and control interfaces for DAS customers with the flexibility of accommodating non-standard/customer-unique telemetry interfaces (e.g. use of dedicated T1s and/or fiber). Provide simple, modular beamforming, demodulating, routing and storage expansion functions, which can be modularly expanded to add DAS return link channels as needs change. Provide customers with the capability of obtaining dedicated DAS services. DAS Customer Categories

j.

k. H.1.3

DAS supports two classes of customers: dedicated and non-dedicated. Dedicated Customers are guaranteed requested support from the shared set of DAS resources. Non-Dedicated Customers receive first come, first served support from shared resources that remain after allocations have been made for the dedicated customers. A non-dedicated customer may be preempted by a dedicated customer when both services require the same resources. A customer that requires continuous (24x7) global coverage is a dedicated DAS customer. A dedicated customer may use DAS as a communications link to notify controllers of a spacecraft emergency (an SOS or 911 call), or to notify ground systems in real-time that some sort of science event occurred such as a gamma ray burst. DAS may be used to support multiple spacecraft flying in a single formation. DAS could form a beam that covers an entire group of spacecraft and multiple DAS receivers could

Revision 9

H-2

450-SNUG

be configured to relay the data from all of the emitters simultaneously with an independent stream for each emitter. For multiple emitters that are not in a single formation, DAS could be used to support polling of the emitters in a time-sequenced fashion. These types of customers could be supported by DAS as dedicated or non-dedicated customers. Some customers may wish to start a service at a specific time or upon demand (ASAP). DAS can accommodate these types of customers on a non-dedicated basis. H.1.4 DAS Service Modes

There are three DAS modes: Any-TDRS, All-TDRS, and Specific-TDRS. Each mode provides MAR services, but with slight differences in service performance and customer responsibilities. Details on how the customer interacts with GSFC Code 450 and the SN Web Services Interface (SWSI) to obtain DAS services are given in paragraph H.2, below. H.1.4.1 Any-TDRS Mode

The Any-TDRS mode is defined as near-continuous global service coverage via three or more designated TDRSs with up to 15 second service gaps during TDRS-to-TDRS transitions. It is intended to support an orbiting spacecraft with an antenna system that can be directly controlled and pointed at a specified TDRS by MOC commands. The spacecraft antenna pattern(s) should have no antenna pointing restrictions in the direction of the target TDRS. Figure H-1 is a high level depiction of this mode.

Revision 9

H-3

450-SNUG

TDRS-Z

TDRS-W

TDRS-E

Customer Platform

Only one of

may be in use at one time

GRGT

WSC

MOC

Figure H-1. DAS Any-TDRS Mode The Customer MOC initiates the service by submitting one schedule request (Resource Allocation Request - RAR), via the SWSI interface, designating the "Any" service preference for the duration of the Project's mission support. No further schedule requests should be required. The DAS automatically selects which TDRS(s) will support the customers request for service and schedules the necessary resources. Scheduling information is created by DAS and passed back to the customers MOC via the SWSI. If the customer platform requires commanding to acquire the selected TDRS(s), it is the customers responsibility to send those commands to the platform coincident with the DAS scheduled TDRSs. This mode requires only one TCP/IP NISN IONet connection for each I and Q channel telemetry feed to the MOC, but encounters service interruptions during handovers. H.1.4.2 All-TDRS Mode

The All-TDRS mode is defined as near-continuous, simultaneous support using all in-view DAS-designated TDRSs. It is primarily intended for an orbiting spacecraft that has autonomous spacecraft antenna switching control in the direction of the DAS designated TDRSs. The customer spacecraft antenna pattern(s) should have no antenna pointing restrictions. The customer spacecraft antenna switching may not be

Revision 9

H-4

450-SNUG

under direct MOC control at all times because of unpredictable occurrences such as a science event or a spacecraft emergency. This support mode of DAS MAR service scheduling minimizes the need for direct customer MOC command management of their onboard antenna switching. Figure H-2 is a high-level diagram of this mode.

TDRS-Z

TDRS-W

TDRS-E

Customer Platform

All of

may be in use at one time

GRGT

WSC

MOC

Figure H-2. DAS All-TDRS Mode For orbiting global coverage, the Customer MOC would submit a schedule request for each TDRS via the SWSI interface. Each individual request could be for the duration of the Projects mission support. DAS provides service through each scheduled TDRS that is in view of the customer spacecraft based on line of sight as determined by DAS using customer provided state vectors. Overlapping (or simultaneous) TDRS support coverage will occur for this mode. The Customer MOC determines scheduled event times by viewing the SWSI Schedule Request Summary window after issuing a Planned Events Request message. The All-TDRS mode of scheduling requires the Customer MOC to have two (or more) IONet interfaces for each TCP/IP telemetry data stream (I or Q Channel), even though their spacecraft may be transmitting to only one TDRS at a time. The Customer MOC is responsible for selecting data from whichever TDRS(s) are receiving the telemetry data. Typically, a customer would specify different IP Ports to differentiate between TDRSs.

Revision 9

H-5

450-SNUG

H.1.4.3

Specific-TDRS Mode

The Specific-TDRS mode is defined as the scheduling support through a specific TDRS at a specific time. Specific scheduling may be entirely customer driven or in part performed by the scheduling automation within DAS. This service mode of operation is primarily intended for a stationary, continuous use customer such as a ground base or a balloon. It also provides service to an orbiting or ground based customer that desires only occasional (or periodic) use of DAS. An orbiting customer with significant antenna pointing restrictions or obscurations that limit useable views to a single TDRS could use this mode effectively. A limited use customer should know their spacecraft antenna pattern characteristics and blockages, and also have a priori knowledge of their spacecraft attitude to efficiently schedule DAS services. Figure H-3 shows a high level diagram illustrating this mode. A customer may schedule a specific TDRS over an extended period of time, regardless of the number of visibility periods within the scheduling period. DAS will automatically determine the event segments based on line of sight to the specified TDRS, and schedule efficient use of the DAS resources. The customer MOC may also choose to determine their own visibility period estimates, for example, by using STK or by issuing a TDRS Visibility Request to DAS via the SWSI. DAS will respond to a TDRS Visibility Request with a list of available time windows based on customer supplied vectors and customer specified constraints. The customer MOC can use this information to schedule the time frames of desired service.

TDRS

Only one channel is assigned

Customer Platform

WSC

MOC

Figure H-3. DAS Specific-TDRS Mode

Revision 9

H-6

450-SNUG

This mode of DAS scheduling is similar to scheduling of other SN customer service support in that the customer specifically schedules a required service through a specific TDRS during a period that DAS has identified as being useable through the TDRS Visibility Response. DAS and SWSI do not have the capability of using customer defined TDRS Support Windows (TSWs) that are used when scheduling other SN nonDAS customer data services via the User Planning System (UPS). The Specific-TDRS events scheduled may require the customer MOC to have one or more IONet interfaces for each TCP/IP telemetry data stream (I or Q Channel). The Customer MOC will be responsible for selecting data from whichever TDRS is receiving the telemetry data. H.1.5 Customer Considerations When Selecting DAS Mode

Customers are encouraged to read the DAS Ground Rules for further details concerning the DAS modes. Also included in the DAS Ground Rules is information concerning scheduling, recording and playback, and customer responsibilities. Familiarity with Section 10 and Appendix C of this document will help customers choose the mode that best supports their missions. These considerations also drive requirements for fill data at the beginning of an event to prevent loss of valid data. Some specific issues customers should consider are: H.1.5.1 Acquisition Transmission interruptions Transmission delays Acquisition

The acquisition process will occur at the beginning of each event for all DAS service modes. Additional acquisition processes will occur at each handover during an event. The effect of these acquisitions on customer operations will depend on which DAS mode is being used, as well as on the customer configuration. DAS provides MAR DG1 Mode 2 service as described in Section 5 and Appendix C of this document. The length of the acquisition process is dependent on several factors, including the frequency uncertainty of the customers transmitter, the data rate, and the modulation format. Acquisition by DAS does not include customer platform antenna pointing, data flow time to the platform transmitter, or any other preparation for the DAS event. All customer acquisition processes such as antenna pointing must have been completed prior to the start of signal acquisition by the DAS. For DAS itself, the Total Service Acquisition time requirement is a combination of PN/Carrier Acquisition and Symbol/Decoder Synchronization. This acquisition process is complete when the DAS has selected and implemented the correct blocking of input symbols in the received data stream.

Revision 9

H-7

450-SNUG

For DAS signal acquisition, the required customer Prec must meet the Prec for 10-5 BER or signal acquisition, whichever is greater (refer to Table 5-8). The DAS total channel acquisition times (Tacq) are given in Table 5-8 and are the sum of the following: a. PN (DG1 only) and carrier acquisition time (probability of acquisition (Pacq) > 90%) < 1 second for customer platform carrier frequency uncertainties of less than +/- 700 Hz < 3 seconds for customer platform carrier frequency uncertainties of less than +/- 3 kHz < 6500/(Channel Data Rate in bps)

b. Symbol/Decoder synchronization time (Pacq > 99%)

NOTE: Early testing showed that acquisition times for a Customer platform operating at < 2 Kbps could be worse than acquisition time performance specified in Table 5-8. The test results for the same system operating at 2 Kbps were within the performance specified in Table 5-8. Contact Code 450 for additional information. Tacq assumes that the customer platform return service signal is present at the ground terminal. In the Any-Service mode and the All-Service mode, events involve multiple TDRSs over extended periods of time. The events are subdivided into segments during which the customer platform communicates through one TDRS. There are periods during which the customer platform is receiving coverage from two or more TDRSs. DAS schedules a handoff from one TDRS to an upcoming TDRS when the calculated angle from the Customer zenith of the upcoming TDRS is less than or equal to the angle from the Customer zenith of the current TDRS as viewed from the DAS Customer satellites center of mass. A satellite handover during an Any-TDRS Mode event requires that the acquisition process be repeated. The maximum time for a handover between TDRSs is specified at 15 seconds. Additional delays may be caused by the customer platform, for example, the time required to repoint the customer platform antenna could delay the start of acquisition.

Revision 9

H-8

450-SNUG

Satellite handovers in the All-TDRS Mode are affected by the customer platforms capability and orbit. If the platform is capable of communicating with two or more TDRSs simultaneously, and its orbit keeps it in view of more than one of the DASassigned TDRSs, it is possible for acquisition on the upcoming TDRS to proceed while data is still being transferred on the existing link. This can reduce the interruption at handover to the process of selecting which telemetry data stream is selected by the customer MOC. If the customer platform cannot communicate with more than one TDRS at a time, or if its orbit takes it out of areas covered by DAS-assigned TDRSs, the acquisition process proceeds as at the beginning of an event. Satellite handovers do not occur with the Specific-TDRS Mode. H.1.5.2 Transmission Interruptions

Equipment failures can lead to service interruptions. For the Any-TDRS Mode and the Specific-TDRS Mode, the length of the interruption will depend on what equipment failed. The DAS has redundant equipment in hot standby, but delays ranging from the equipment switchover time to signal re-acquisition time are possible. Customers using the All-TDRS Mode may be able to minimize the interruption by selecting a different telemetry channel received at the MOC. In addition, replanning by the DAS can force a reacquisition. DAS maintains a committed 96 hour (4 day) schedule of planned events. This schedule is affected by updates to the TDRS vectors and to the customer platform vectors. As long as the vector updates do not indicate any drastic change in the expected position and/or orbit of either a TDRS or a customer platform, DAS accumulates the changes and incorporates them the next time it issues a schedule. DAS updates the committed schedule every day at 0000Z (midnight Greenwich Mean Time (GMT)) by advancing to the next 24 hour period, appending a new 24 hour period to the end of the schedule and making all necessary schedule changes due to TDRS and Customer platform updates. A new committed 96 hour schedule is issued after all of these changes have been made, Immediate replanning of the committed schedule is required when a new TDRS state vector indicates that the TDRSs position has changed by more than 180 km from the expected position or when a new customer state vector indicates that the customer platforms orbit has changed by more than 920 km from the expected orbit. These changes affect pointing angles and transition times and could result in degradation or even loss of service. In these cases, DAS immediately replans all events in the current 96 hour committed schedule for affected customer platforms and issues an alert(s) via SWSI to any affected Customer MOC(s). These alerts do not tell customers what changes were made to the schedule. The Customer MOC must use SWSI to get the revised schedules so that appropriate responses can be planned and executed.

Revision 9

H-9

450-SNUG

H.1.5.3

Transmission Delays

The overall transmission time from the customer data source to the customer MOC is determined by a series of delay components. These include transmission of sampled data from the TDRS MA array antenna, processing of the sample to produce a signal that can be demodulated, demodulation and decoding of the data, formatting the data for transmission to the MOC, and transmission of the formatted data to the MOC. This section discusses delay components associated with processing by DAS. Figure H-4 illustrates a simplified DAS signal flow. Factors a customer may consider are the delays inherent in format processing at the TDRSS ground terminal, the transmission delays possible in the IONet, and delays due to forward error correction processing. Although TDRS specifies the FEC scheme, the delay is dependent on the data rate.

SN Ground Terminal/DAS
SGLT Antenna/ EMC
NISN

Beamformer

DMU

PTP
Local

Figure H-4. Simplified DAS Signal Flow H.1.5.3.1 Beamformer The DAS Beamformer receives data samples from the 30 elements of the MA antenna array and creates a beam using a process of phase-shifting, summing, and filtering. The Beamformer then passes the resulting signal to a DAS Demodulator Unit (DMU). H.1.5.3.2 DAS DMU The DAS DMU demodulation process performs signal acquisition, which includes PN code and carrier acquisition, symbol synchronization and decoding. Acquisition, which is described above in paragraph H.1.5.1, begins when the received signal achieves sufficient C/N0. The acquisition and symbol/decoder synchronization processes must be restarted every time there is a disruption in the signal as described in paragraph H.1.5.2. The recovered data are formatted in TCP/IP packets and transmitted by the Programmable Telemetry Processor (PTP).

Revision 9

H-10

450-SNUG

H.1.5.3.3 PTP The PTP is responsible for distributing customer data as TCP/IP packets over the Closed IONet or a Customer provided local interface (LI), for storing a copy of the data, and for retrieving the data from storage upon request. The real-time PTP output rate is always configured to clock the IP packets out at the scheduled data rate. The transmitted telemetry packet data is also simultaneously archived on a DAS Redundant Array of Independent Disks (RAID) Array storage device and can be played back as needed. The PTP manages the fixed bandwidth allocated to it by NISN. As long as the aggregate demand for bandwidth does not exceed the bandwidth allocated by NISN, the PTP transmits all data streams at their nominal data rate. If the total demand exceeds the bandwidth available, the PTP reduces or throttles the data rate for all streams proportionally to keep the aggregate transmitted bandwidth within the available allocated bandwidth. This will result in some additional delay. By default, customer data is transmitted without any Consultative Committee for Space Data Systems (CCSDS) processing or encapsulation in any structured header other than the normal TCP/IP transmission structures. The PTP can provide three additional services upon Customer request, if the Customer data stream is properly structured. These services result in additional delays for PTP processing. The PTP can frame synchronize a telemetry data stream using the frame length, sync pattern, and sync mask supplied by the Customer in the user service request. The PTP can additionally provide CCSDS Virtual Channel Processing, if requested. The request must identify the byte location of the Cyclic Redundancy Check (CRC) in the data stream. The Customer may optionally specify Reed-Solomon decoding along with the interleaving depth and the location and virtual fill of the RS codeword. The PTP can also provide ground transport encapsulation for transmission over the NISN Closed IONet. The supported encapsulation headers include CCSDS Standard Formatted Data Units (SFDU), CCSDS fixed-length Virtual Channel Data Units (VCDU), CCSDS fixed-length transfer frames used by the Advanced Composition Explorer (ACE) spacecraft, the Low Earth Orbiting-Terminal (LEO-T) Telemetry Frame Data Header (TFDH), and the NASA Internet Protocol Data Unit (IPDU) developed by Landsat 7. NOTE: For delays associated with PTP processing, please contact Code 450.

Revision 9

H-11

450-SNUG

H.1.6 H.1.6.1

Nominal Operations Customer Responsibilities

The Customer MOC is responsible for the following in a DAS nominal operational scenario: Requesting DAS services through SWSI nominally any time prior to two minutes before the start of services. DAS may support services requested up to 30 seconds prior to service initiation, if necessary. Receiving service request responses from DAS through SWSI indicating that DAS resources are available and line-of-sight visibility with requested TDRS(s) has been confirmed. Establishing a TCP socket connection with the appropriate DAS Programmable Telemetry Processor (PTP) at the addresses indicated, using a mission-specific data port number. Receiving either MAR data or playback service data throughout the scheduled support period. Disconnecting the TCP socket connection when all service data has been received from the PTP. DAS Event Timeline

H.1.6.2

Figure H-5 illustrates the process by which DAS provides service to its customers. The customer and DAS must work together for successful communications. Their actions are coordinated by the current Active/Committed Schedule, which DAS updates and distributes every 24 hours (D0). This schedule is based on service requests submitted by DAS Customers (C0) and the visibility windows computed from state vectors submitted by those customers (C1). DAS customers may submit as many service requests and modifications to service requests as necessary to define the service that they need. The customers must keep their state vectors fresh. DAS uses these vectors to determine communications windows, form a beam that points toward the customers platform, and schedule TDRS to TDRS handoffs. Two minutes prior to a scheduled event, DAS issues an alert to the customer (D1) and begins preparations for the event. At about the same time, the customer needs to have its platform begin the process of establishing a communications link with the target TDRS (C3). The customer also needs to set up its ground equipment and its link to the DAS PTP so that it can receive the data relayed down to the SGLT. Just prior to the event the DAS controller issues commands (D2) to configure the PTP and demodulator and cause the beam to be formed. The customers RF signal is picked up by the elements of the TDRS phased array antenna and relayed to the SGLT (D4). Within the SGLT the signal elements are

Revision 9

H-12

450-SNUG

combined and processed by a beam forming unit where the signal is acquired and symbol and frame synchronization are performed. Once the symbol and frame synchronization have been successfully completed, the signal is passed to a demodulator (D6) which produces a stream of baseband data bits for the PTP (D7). The PTP processes the data bits into data packets and either transmits the packets to the customer (D8) or archives them, or both, as directed by the customers service request. H.2 Obtaining DAS Services

Potential customer service requirements will be subjected to a system loading analysis and an RF compatibility analysis prior to approval to use DAS. In this process, the support identification codes (SIC) will be established. Key information including spacecraft mass, cross-sectional area, drag co-efficient, and solar reflectivity parameters will be collected. These platform-specific values are needed for accurate orbit modeling which allows DAS to determine visibility and service schedules up to five days into the future. In the event these values are not provided, baseline values will be substituted which will impact orbit modeling accuracy, especially for platforms with orbits less than 750 km in altitude. DAS Customers with orbit altitudes below 750 km should update the mass value whenever it varies more than 10% from the previously submitted value in order to maintain accuracy of their DAS 5-day orbit predictions. Initial service specification codes (SSC), which will be the basis for allocating resources and setting up the RF links between the Customer Platform and the TDRSs, will be established and the required equipment allocation for each SSC will be calculated. NISN and GDIS access capacity will be determined. If this analysis indicates that there are insufficient resources to support additional customers, GSFC Code 450 will determine if additional resources must be procured. A Project Service Level Agreement (PSLA) will be negotiated with the customer. DAS, NISN, and SWSI accounts will be established. The Planning activities shown in Table H-1 ideally take place a minimum of 18 months prior to commencement of services. H.3 H.3.1 Customer Interface with the DAS General

Communications between DAS and a MOC Customer involve two different classes of information. The first type is service data or telemetry, which is the data received from the Customer Platform and forwarded to the Customer MOC. The other type is a combination of planning and scheduling information, status information, real-time control information, and other miscellaneous administrative information. DAS uses SWSI for all types of communications except the telemetry. The SWSI interface with DAS allows the customer insight into available resources, allows the customer to submit requests for DAS services, and permits monitoring DAS service performance.

Revision 9

H-13

450-SNUG

Revision 9
Customer
Note1

DAS Event Timeline

C0: Submits Service Request. C1: Updates State Vectors C2: Receives event alert. C3: Initiates communication process. C4: Points platform antenna. C5: Radiates RF signal. C6: Transmits telemetry data.
Note2

Cx: Customer action Dx: DAS action

C7: MOC receives telemetry data.

H-14
DAS
Note3

D8: PTP feeds Customer data to IONet D7: Demodulator feeds baseband data to PTP. D6: IF signal passed to the demodulator. D5: Successful signal acquisition and symbol/frame synchronization. D4: Customer signal arrives at TDRS and is relayed to SGLT. D3: Beam is formed. D2: DAS Controller configures ground processing elements. D1: Issues event alert to customer and checks customer platform ephemeris. D0: Releases new committed schedule every 24 hours. Note:
1) C0 occurs at least once and may occur frequently. 2) C1 state vector updates normally occur daily. 3) D0 schedule release occurs daily.

...

...

450-SNUG

Figure H-5. Generic DAS Acquisition and Transmission Timeline

Table H-1. Planning Sequence

1 to 2 Years Prior to Operations Identification of DAS as Service Provider RF Compatibility Analysis Loading Analyses Identification of Additional DAS equipment (if needed) PSLA generation Procure additional equipment (if needed) Non-Dedicated Customers 2. Available resources configured for support Customer Operations Begin Dedicated Customers 1. DAS configured for support

Table H-2. DAS/Customer Interaction via SWSI

DAS will receive the following information from the customer: Resource Requests: Customer location and identification TDRS ID Type of Service Period of Service Signal Characteristics (to set up demodulation and other DAS components) Archive Requests Data routing Emitter ephemeris data: a. b. c. d. Emitter type Epoch Time Emitter Position (X, Y, Z at epoch in meters) Emitter Velocity (X, Y, Z at epoch in meters/seconds) e. Mass of Satellite f. Average Cross-sectional Area of Platform g. Drag Coefficient h. Solar Reflectivity Coefficient Reconfiguration Requests Reacquisition Requests Status Requests DAS will provide the following information to the customer: Acknowledgement and status of requests Resource allocation assignments Resource availability Emitter visibility information Real-time service status and performance

Revision 9

H-15

450-SNUG

Table H-2 lists information exchanged between DAS and the customer via SWSI. Please refer to Section 10, paragraph 10.2.4, or Appendix P of this document, or the web site at: http://scp.gsfc.nasa.gov/swsi/ for further information on SWSI. H.3.2 H.3.2.1 Communications Interface Physical Communications Links Between DAS and DAS Customers

The following interfaces comprise the DAS to DAS Customer communications interfaces: DAS to NISN Closed IONet Interface and DAS Local Interface (LI) to selected Customers

DAS will use the NISN Closed IONet to deliver service data to Customers through the NISN secure gateway to their MOC unless the Customers provide LI connections at WSGT or GRGT. The Closed IONet supports the transport of real-time and archived service data from DAS to the Customer and also supports the transport of TCP control and status requests from the Customer to DAS. Representative MOC locations may be located off of the NISN Closed IONet, NISN Open IONet, Earth Observation System (EOS) Backbone Network (EBNet), NASA Internet, the Internet, or a University Local Area Network (LAN) on the Internet. For the DAS to NISN interface, DAS complies with the provisions of the IONet Access Protection Policy and Requirements Document, 290-004, and implements appropriate security protocols to ensure compliance with the Security of Information Technology, NPR 2810.1. TCP/IP client/server relationships are established on a Customer-by-Customer basis by DAS. The preferred method is to configure the DAS PTP as the TCP client so that the PTP initiates the socket connection at the time that the Customer return data services are scheduled to begin. The Customer side of the TCP/IP connection is expected to be ready to receive return data from the PTP based on the IP address and TCP port number provided to DAS in the Service Specification Code (SSC) parameters associated with the Customer service request. H.3.2.2 Service Data Processing

DAS transmits all formatted and unformatted service data over the NISN Closed IONet or customer supplied LIs in standard TCP/IP protocol packets. One TCP/IP socket connection will be provided for each return telemetry data stream or playback service requested by the Customer. Consultative Committee for Space Data Systems (CCSDS) header formats and optional ground transport header formats are supported by the DAS PTPs. The means for data entry through SWSI Customer terminal screens is specified in the ICD between the DAS and the SWSI, 452-ICD-DAS/SWSI and described in the SWSI Client Software Users Guide, 452-UG-SWSI. DAS PTPs are compatible with specific CCSDS data formats and other ground transport headers are optional for space link communications. The ground transport
Revision 9 H-16 450-SNUG

headers supported are the Standard Formatted Data Unit (SFDU), Advanced X-ray Astrophysics Facility Imagery (AXAF-I), Advanced Composition Explorer (ACE), Low Earth OrbitTerminal (LEO-T), and the IP Data Unit (IPDU). DAS transmits Customer service data, both real-time and playback, as asynchronous data streams encapsulated in TCP/IP without any CCSDS processing or encapsulation unless otherwise specified by the Customer in a service request. In this case, the PTP is used to simply archive the data and to stream it as TCP/IP packets for delivery. With TCP/IP reliability, this method provides the highest assurance that the data received by the Customer MOC is exactly the same as the data received by the DAS demodulator. DAS provides telemetry data with the least manipulation for Customers with their own PTPs. H.3.3 Customer Interactions with DAS

The Customer can interact with DAS in two time frames: Planning/Scheduling prior to an event or events, and during an event. During the planning/scheduling phase, the Customer schedules resources for service by interacting with DAS through SWSI. During an event, the Customer can monitor the status of communications from the Customer platform and, if necessary, modify parameters that control the communications during the event. H.3.3.1 The Planning/Scheduling Phase

DAS service support begins with planning sequences. Planning sequences include interaction between DAS and the Customer to set up a resource allocation request within the context of the available DAS MAR resource times and the resource utilization objectives. This customer interaction provides DAS with the time window(s) in which the Customer requests DAS resources. DAS in turn provides the Customer with the available service time(s) and the associated TDRS(s) available for the support within the specified time window. The customer can then vary parameters of their request derived from this information. NOTE: If a dedicated customer preempts a non-dedicated customer, DAS will attempt to reschedule the non-dedicated customers preempted support at another time within the requested window. The customer sends a request via SWSI for the resources desired, including customer identification and location (ephemeris), identification of the TDRS(s) requested, parameters of resources requested, period of the request, demodulator parameters, archive and retrieval requests, and data forwarding requirements. DAS will interact with the Customer via SWSI to establish and confirm a customer request.

Revision 9

H-17

450-SNUG

Upon receipt of a specific request for resources, DAS will examine the parameters required to set up the request and determine if they are feasible. If DAS determines that the request is not within the capability of the system, DAS will notify the customer to this effect. Upon determining that the request is feasible, DAS will allocate and reserve appropriate resources. If there are no resources available for allocation during the time frame requested, DAS will notify the customer. DAS will notify the customer via SWSI if updated ephemeris data for the service is needed. H.3.3.2 Real-Time Monitor and Control

The customer is notified via a SWSI alert that the requested service has commenced. DAS commands archive and routing equipment for telemetry data capture before the service begins. DAS beamforming and demodulating elements are commanded before the signal acquisition sequence is to commence. During the service, the Customer will be allowed to modify some parameters of the service. Regular status will be reported to the customer while the service is ongoing, upon request. Data will be archived and routed in accordance with the customer request. In general, the Customers emitter transmits telemetry data to the designated TDRS as specified in the DAS Customer service request input through SWSI. The TDRS downlinks the Customer data through an SN ground terminal SGLT Antenna and the Element Multiplexer Correlator (EMC). After beamforming of the signal, a DAS PTP receives the data from a DAS receiver/demodulator(s), frame-syncs the data, and performs processing on the data. The data is archived and, if requested, sent in realtime to the Customer MOC via a TCP/IP connection. H.3.3.3 Archived Data Retrieval

Data that has been archived will be made available for retrieval upon request by the customer. Data that has been archived will be retained for up to 30 days. The customer can request via SWSI that DAS retrieve and route this data to the customer for use. This request must include the identification of the data to be retrieved, the parameters for routing, and the time retrieval and routing is to occur. H.3.3.4 Alerts

The alert messages advise the DAS Customer of time-critical events. Types of alert messages include: service status (granted or pending), service start times, service end times, data storage limits, signal loss, notification of Customer State Vectors (SVs) requiring updates, and others. Alert messages also support a free-text format to allow flexibility in advising DAS Customers of time-dependent or critical events.

Revision 9

H-18

450-SNUG

Appendix I. NASA Integrated Services Network (NISN) Services

I.1

General

This appendix describes the NASA Integrated Services Network (NISN). NISN provides several facilities of networked data services. This Appendix discusses only those services that pertain to the direct utilization of the SN. Please note, NASAs current policy is that commanding spacecraft over Internet segments or domains is not permitted. I.2 Services Available

In conformance with Agency direction, the Internet Protocol (IP) has been adopted as the standard for NISNs routed data services. The legacy SN interface was built on a serial clock and data interface using the 4800 bit block format (please see paragraph I.2.5). However, the data service has been transitioned to an IP routed data service requiring the use of conversion devices. New SN projects should design their interfaces to be consistent with IP interfaces without serial interfaces and 4800 bit block formats. For further information, please contact the Systems Management Division, NASA/GSFC Code 730 and/or refer to the NASA Integrated Services Network (NISN) Services Document, (NISN/001-001). I.2.1 IP Routed Data Services

The NISN provides Wide Area Network (WAN) voice and data communications services between the Space Network and Space Network customers using the Mission Critical and Real-Time Critical IP routed Data Service. NISN has implemented a WAN to support operational data transfer between hosts and external projects called the IP Operational Network (IONet). IONet supports missions on a 24-hour basis transferring real-time data (attitude, orbit, ephemeris, telemetry, state vectors), as well as non-real-time data (data products, quick-look image data, and other data sets associated with small Explorer projects). The Network is monitored electronically 24 hours per day, 7 days per week. All project connections to the IOnet must be authorized via an application process defined in the Internet Protocol Operational Network (IONet) Access Protection Policy and Requirements, 290-004. I.2.1.1 Types of IONet

The IONet is divided into three types: the more secure Closed segment (Closed IONet), the less secure Restricted IONet, and the least secure Open Segment (Open IONet). Access between the Closed IONet and either of the other domains is strictly controlled via the IONet Secure Gateway at GSFC. The Restricted IONet network is outside of the

Revision 9

I-1

450-SNUG

Secure Gateway, and supports mission-critical real-time flows for projects which have requirements for connections to other networks. The most prevalent example for the Restricted IONet is mission control centers at Universities. The Restricted IONet projects have a moderate degree of protection due to their perimeter negotiations and access control via the Restricted IONet Firewall, but support real-time mission-critical data. The Open IONet is intended to support the more liberal needs of the science community, but on a 24x7 service level. The Open IONet provides a modest level of protection with the implementation of the Open IONet Firewall that requires all Open IONet customers to register the data flows with external IONet customers. Customers may apply for connection to any of the domains as NISN requirements analysis determine and the IONet Access Protection Policy and Requirements, 290-004, dictate. This document uses the term IONet when referring to all three networks. Otherwise, it specifies whether the material pertains specifically to the Open, Restricted, or Closed IONet. I.2.1.2 Legacy MDM/4800-Bit Block

The legacy interface is targeted for End of Life in the near future and as such, it is not recommended that any new project interfaces be implemented on it. The replacement interface has not been specified at this documents time of publishing. The legacy interface delivers and accepts data via IP multicast packets with 4800 bit block formatted data units. Customers who use this interface must be connected via the IP multicast-enabled part of IONet, which is also the most secured domain of the IONet (see Figure I-1). Project interfaces are rigidly controlled and audited for this service, according to the IONet Access Protection Policy and Requirements. I.2.1.3 WDISC IP

The WDISC IP interface (please see Appendix Q for WDISC information) is supported via Closed IONet interface (see Figure I-2 and the IONet Access Protection Policy and Requirements). Because this interface is Unicast IP, it is possible to interface to it via the IONet Secure Gateway System, from the Open IONet or beyond, as permitted in the IONet Access Protection Policy and Requirements. I.2.1.4 Space Network Web Services Interface (SWSI)

The SWSI (please see Appendix P for detailed SWSI information) is designed to be accessed from the NISN Closed IONet or Open IONet (see Figure I-3). NISN's Open IONet allows access from the NASA Science Internet (Restricted IONet) and the public Internet, thus allowing cooperation with NASA's university, enterprise, and inter/intra-agency partners.

Revision 9

I-2

450-SNUG

Project Project IONet Secure Gateway

Restricted Restricted IONet IONet

Project Open Open IONet IONet

Closed Closed IONet IONet

SWSI Legacy WDISC

SWSI
Serial clock and data

Space Space Network Network

Denotes Legacy flows: UDP multicast

Figure I-1. NISN/SN Legacy Interfaces

Project Project IONet Secure Gateway

Restricted Restricted IONet IONet

Project Open Open IONet IONet

Closed Closed IONet IONet

SWSI Legacy WDISC

SWSI
Serial clock and data

Space Space Network Network

Denotes WDISC TCP flows

Figure I-2. NISN/SN WDISC Interfaces

Revision 9

I-3

450-SNUG

Project IONet Secure Gateway

Project
Restricted Restricted IONet IONet

Project Open Open IONet IONet

Closed Closed IONet IONet

SWSI Legacy WDISC

SWSI
Serial clock and data

Space Space Network Network

Denotes SWSI TCP flows

Figure I-3. NISN/SN SWSI Interfaces

I.2.2

Non-IP Routed Data Services

NISN will continue to support those legacy protocols currently in use until they can be phased out. Requirements entailing the use of protocols other than those associated with the IP protocol suite will be processed on a case-by-case basis. However, the customer is well-advised to be developing or implementing plans for the modification of the supported information system(s) to interface the network using the IP protocol suite. If NISN assistance in this regard is desired, NISN engineering support is available. I.2.2.1 High Rate Data System

The High Rate Data System is a one-way, multi-mode/multi-channel system designed for operation over a full C-band (36 MHz) domestic communications satellite transponder. Specifically, it is used to provide the ground communications path between WSC and customers at JSC (see Figure I-4). This service provides a medium for transport of a TDRSS customers digital baseband return link when the rates are 2 Mbps or higher. The system has an upper limit for the customers data of 48 Mbps. The satellite, when not used for data, may be used for the transmission of video information in a customers TDRSS Ku-band return link from the WSC to JSC.

Revision 9

I-4

450-SNUG

TDRS

DOMSAT

Shuttle ISS Other TDRSS Users

TDRS Ground Station TV Analog STAT MUX Tape

DOMSAT Earth Station

DOMSAT Earth Station STAT MUX WSC MCC at JSC

Figure I-4. Functional Configuration of High Data Rate System Block Format Description

I.2.3

Network Consulting Services

Whether a customers requirement is as small as a simple data link between two points or as complex as a dedicated subnetwork for a specific project, consulting and integration services are available to provide the customer with one-stop shopping for the satisfaction of communication and network requirements. If the requirement is unique or does not easily fall within standard service offerings, consulting NISN staff is offered to work with the customer to provide a tailored solution to the unique needs of a project. Examples of available services include: a. Requirements Analysis b. Subnetwork Engineering & Design c. Implementation Coordination d. Prototyping Activities

Revision 9

I-5

450-SNUG

e. Network Traffic Modeling I.2.4 Dedicated Voice Services

Dedicated Voice Services encompass a wide range of service complexity. At the simplest, it can be a dedicated point-to-point "shout down" circuit with no signaling. The majority of Dedicated Voice Services consist of a system of highly reliable, dedicated four-wire voice circuits working in conjunction with switching and conferencing systems to create Mission-type voice loops. These voice loops interconnect the different voice distribution systems that support the diverse Mission Control Centers within NASA. It should be noted the customer is responsible for the procurement of the unique four-wire end equipment required for their termination and local distribution of the procured fourwire Dedicated Voice Services. I.2.5 Block Format Description

For customers electing the blocked data format option of the MDM data system, the MDM data system will return telemetry data and forward command data in the NISN (legacy NASCOM) TDRSS 4800-bit block format. The option for telemetry and command data may be independently selected. A description of the 4800-bit block is as follows: a. General. The 4800-bit block for TDRSS-relayed telemetry and command data consists of the following elements (please see Figure I-5 for an illustration of the forward command and return telemetry block format): 1. 2. 3. 4. 5. Network header. Customer header. Time. Data. Block error control.

b. Bits 1-48: Network Header. The network header is the first 48 bits in the 4800-bit block format and contains the NISN sync code and information that may be needed by NISN for routing and accounting purposes. In the MDM forward channel application for command data via the TDRSS, its use is confined to block sync code detection. 1. 2. Bits 1-24: NISN Sync. The 24-bit NISN sync code is a fixed code used to determine the beginning of the 4800-bit block (627627 Hex MSB first). Bits 25-32: Spare. For telemetry data, the MDM sets this field to all binary 1's. For command data, the convention is open to the command originator. There is no requirement for the MDM.

Revision 9

I-6

450-SNUG

16 bits FIRST BIT SENT/RECEIVED Network Control Header 1 17 33 49 Customer Header 65 81 S 97 Time Field 113 129 145 82 D 83 F Data Stream ID Fixed Code Message Type 84 MSB NISN Synchronization 24 40 56 72 25 41 57 73 Data length Spare Port Sequence No. Fixed Code Fixed Code 16 32 48 64 80 96 LSB 112 128 144

S = Spare bit D = Datagram bit F = Full block flag

Data Field (4624 Bits)

Polynomial Status Bits 4753 Error Control Field 4769 4785 Spare 4776 F1 F2 4779 4768 4784 4800 Last Bit Sent/Received

Polynomial Remainder

* Data Stream ID

Figure I-5. NISN/TDRSS Forward Channel Command and Return Telemetry Transmission 4800-Bit Block Format

Revision 9

I-7

450-SNUG

3.

Bits 33-40: Data Stream ID. For telemetry data, the project data ID is assigned by the NCCDS in scheduling coordination with the customer. Operationally, it is inserted by the MDM data system for a scheduled data flow event in accordance with the required use of the MDM channel as provided in a schedule furnished to NISN by the NCCDS. For command data, the convention is open to the command originators. There is no requirement for the MDM data system. Bits 41-48: Port Sequence Number. For telemetry, this is an 8-bit binary count incrementing number (sequentially assigned to the block) and is generated by the MDM data system on a port basis at the first transmitting multiplexer. It is used for block accounting. For command data, the convention is open to the command originator. There is no requirement for the MDM data system.

4.

c.

Bits 49-96: Customer Header. The 48-bit customer header is normally reserved for information required by customer ground facilities to route and process the data contained in the block. In the MDM forward channel TDRSS application, its functional use is limited to information necessary for NISN to strip the command data out of the block and maintain a bit-contiguous serial data stream to the WSC. In the TDRSS return channel application, use of the header is similar, but the data stripping function may be performed either in the MDM data system or by the customer ground facility. For return channels, fields other than the data length and full block flags are predetermined in MDM firmware. There are other differences in forward and return channels. Applications are as follows: 1. Bits 49-56: Fixed Code For Telemetry Data. This field contains a fixed code which is the American Standard Code for Information Interchange (ASCII) null character (binary bit pattern 00000001). For command data, the convention is open to the command originator. There is no requirement for the MDM data system. Bits 57-64: Fixed Code. Same as bits 49-56. Bits 65-72: Message Type Code. For telemetry, this field contains a fixed code identifying the block as one which originated at the WSC. The codes are 16(hex) for STGT, 15(hex) for WSGT and 13(hex) for JSC. For command data, the convention is open to the command originator. There is no requirement for the MDM data system. Bits 73-80: Fixed Code. Same as bits 49-56. Bit 81: Spare. This bit is always set to binary 0. Bit 82: Single Block Command Flag. This bit is set to binary 0 when a command message exceeds 4624 bits; i.e., a multiblock command transmission. This bit is set to binary 1 when a command message is

2. 3.

4. 5. 6.

Revision 9

I-8

450-SNUG

contained within a single block. For telemetry data, this bit is always set to binary 0. NOTE: A block with bit 82 set to binary 0 is held in the MDM terminal in the WSC until five blocks have been accumulated, until a block is received with the single block flag set, or after 200 milliseconds have elapsed. 7. Bit 83: Full Block Flag. This bit contains a flag which indicates whether the block contains fill bits in the data field. A binary 1 represents a full block condition. Bits 84-96: Data Length. The last 13 bits of the customer header contain a binary count of the number of bits of data, exclusive of fill, contained in the block. This field is used by the WSC MDM terminal (command data) and by the customer ground facility (telemetry data) to assist in removal of fill data in processing the data block. The binary count equals 4624 (decimal) for the full block condition.

8.

d. Bits 97-144: Time. For telemetry, the 48-bit time field is reserved for a time code which is in UTC having a resolution of 1 sec. The format is NASA PB4. The time in the block represents the time that the WSC MDM terminal received the first data bit in the data field. For command data, the convention is open to the command originator. There is no requirement for the MDM data system. e. Bits 145-4768: Data Field. The 4624-bit data field is used to transmit customer data. When the data field contains fill bits, they follow the customers data and complete the data field. A specific fill data pattern code 311 (octal) is used (binary bit pattern 11001001). f. Bits 4769-4800: Block Error Control. The block error control field is 32 bits in length and is reserved for information used to determine if bit errors have occurred during transmission of the block. For command data, the originator is expected to insert the polynomial computed for the data content of the block at his location using an MDM-compatible algorithm. For telemetry data, this field is computed and inserted by the transmitting MDM terminal, decoded and passed to the customer by the receiving MDM terminal. 1. 2. Bits 4769-4776: Spare. These eight bits are not used and are set to all binary 1's. Bits 4777-4778: F1 and F2 Polynomial Status Flags. These bits are reserved for flags which indicate that a block either passed or failed a polynomial check when it was decoded. These bits are set to binary 1 by the customer ground facility or the NISN MDM terminal originating (encoding) the block. For telemetry data, one of these (bit 4778) is set to

Revision 9

I-9

450-SNUG

binary 0 by the NISN MDM terminal decoder to indicate that the block passed the polynomial check or is left as a binary 1 if an error is detected in the block. The other bit (4777) may be used for a second decode process at the customer ground facility. 3. Bits 4779-4800: Polynomial Remainder: The last 22 bits of the block are reserved for the polynomial remainder which results from the originator or the NISN MDM terminal encoding the entire content of the block (excluding the NISN sync code and block error control fields). The decoding process of the NISN MDM terminal for telemetry data does not remove or alter this field. It is passed on to the customer ground facility where a second decode process may be used [see paragraph 2 above].

Revision 9

I-10

450-SNUG

Appendix J. Customer Constraints for the Expendable Launch Vehicle Class of TDRSS Customers
J.1 General This Appendix contains the customer constraints for the S-band DG2 noncoherent Expendable Launch Vehicle (ELV) class of TDRSS customers. In general, an S-band ELV customer typically uses DG2 noncoherent service (noncoherent, non-PN coded service) with BPSK or QPSK modulation, a baud rate between 12.5 ksps and 1024 ksps per channel, rate 1/2 convolutional coding, and requires 1-way Doppler tracking. Compliance with the customer constraints of this Appendix is expected to ensure the performance described in this Appendix; however, compatibility testing with the SN must still be performed to confirm this performance. J.2 Customer Constraints Table J-1 provides a summary of the customer constraints for the S-band ELV class of TDRSS customers. Table J-1. Customer Constraints for the S-Band ELV Class of TDRSS Customers
Parameter In-band Spurious Outputs Out-of-band Short-Term Stability Frequency Long-Term Stability Stability (peak) Temperature Stability With a Doppler tracking requirement Phase Noise (note 3) 23 dBc 15 dBc (between data bw and 2x channel bw) 30 dBc (outside of 2x channel bw) 26 x 10-9 for a 1 second average time (notes 1 and 2) 3.77 ppm for a 5 hour observation time (notes 1 and 2) 11.3 ppm for a 48 hour observation time (notes 1 and 2) 11.3 ppm over the temperature range expected during the mission (note 3) 1 Hz 10 Hz: 2.0 rms 10 Hz 100 Hz: 1.0 rms 100 Hz 1 kHz: 1.0 rms 1 kHz 3 MHz: 1.0 rms (SMA) 1 kHz 6 MHz: 1.0 rms (SSA) 1 Hz 10 Hz: 50.0 rms 10 Hz 100 Hz: 5.5 rms 100 Hz 1 kHz: 2.5 rms 1 kHz 3 MHz: 2.5 rms (SMA) 1 kHz 6 MHz: 2.5 rms (SSA) 1.0 dB 0.5 dB Specification Value

Without a Doppler tracking requirement (note 5) BPSK QPSK

Gain Imbalance

Revision 9

J-1

450-SNUG

Table J-1. Customer Constraints for the S-Band ELV Class of TDRSS Customers (contd)
Parameter Phase Imbalance BPSK QPSK 9 5 0.4 dB over 0.7 MHz Not specified 4 over 0.7 MHz 2 rms 15/dB Not specified 5% 3% 0.1% 3% 2 x maximum baud rate Specification Value

Gain Flatness Gain Slope Phase Nonlinearity Spurious PM AM/PM AM/AM Incidental AM Symbol Asymmetry Symbol Jitter I/Q Symbol Skew Minimum 3-dB bandwidth prior to power amplifier

Notes: 1. The short-term and long-term frequency stabilities determine the required stability over the time period specified and at any constant temperature (0.5 C) in the range expected during the mission. At a minimum, a mission temperature range of -10 C to +55 C shall be considered. 2. Transmitter oscillator required to be characterized 48 hours prior to the scheduled service and the SHO be updated. Expanded customer frequency uncertainty request required in SHO, which allows a customer oscillator uncertainty of up to +35 kHz for S-band DG2 BPSK and non-staggered QPSK signals. 3. At a minimum, a mission temperature range of -10 C to +55 C shall be considered. 4. Derivation of the phase noise requirements involved making assumptions about the distribution of the phase noise power in each frequency region. Since no phase noise PSD will exactly match the phase noise power distribution assumed for this derivation, phase noise PSDs which are close to violating the phase noise limits or phase noise PSDs which do violate the phase noise limits should be evaluated on a case-by-case basis to determine their acceptability. 5. Or can accept a total Doppler tracking error greater than the 0.2 rad/sec, perhaps as high as 3.79 rad/sec.

Revision 9

J-2

450-SNUG

J.3 Acquisition For S-band DG2 noncoherent return service, the total acquisition time is the sum of the following: a. Carrier acquisition time b. Symbol/Decoder synchronization time or Symbol/Deinterleaver/Decoder synchronization time (if deinterleaving is applicable). The carrier acquisition time is discussed in paragraph J.3.1 (SMA) and paragraph J.3.2 (SSA). The synchronization time and associated requirements are given in Table 5-8 (SMA) and Table 6-9 (SSA). J.3.1 SMA TDRSS will achieve customer carrier acquisition within 3 seconds with a probability of 90% or greater (Pacq 90%) for customers who meet the customer constraints of Table J-1 and provide a total (I+Q)Prec consistent with the required Prec in note 3 of Table 5-8. J.3.2 SSA TDRSS will achieve customer carrier acquisition within 3 seconds with a probability of 90% or greater (Pacq 90%) for customers who meet the customer constraints of Table J-1 and provide a total (I+Q)Prec -190.9 dBW or a Prec consistent with paragraph J.5, whichever is greater. J.4 Signal Tracking

J.4.1 SMA TDRSS will provide SMA return signal tracking (carrier, symbol synchronization, convolutional deinterleaver synchronization, Viterbi decoder synchronization) as given in Section 5, paragraph 5.3.3.3. J.4.2 SSA TDRSS will provide SSA return signal tracking (carrier, symbol synchronization, convolutional deinterleaver synchronization, Viterbi decoder synchronization) as given in Section 6, paragraph 6.3.3.3. J.5 BER Performance TDRSS will provide 10-5 BER service for customers who meet the customer constraints of Table J-1 and the adjusted Prec requirements as defined by Table J-2.

Revision 9

J-3

450-SNUG

Table J-2. Prec Adjustment for TDRSS ELV Customers

ELV Configuration Minimum Customer Bandwidth Nominal Customer Bandwidth (note 3) BPSK QPSK BPSK QPSK
Notes:

Prec Ajustment (notes 1, 2 & 4) SMA/SSA -0.8 dB +0.4 dB -1.4 dB -0.6 dB

1. Prec adjustment relative to the 10-5 BER Prec requirements for DG2 channel data rates < 1 Mbps of Table 5-8 (SMA) and Table 6-9 (SSA). The Prec requirements for DG2 channel data rates < 1 Mbps of Table 5-8 (SMA) and Table 6-9 (SSA) are based upon WSC specified implementation loss amounts of 2.6 dB and the adjustment indicated here effectively reduces the required Prec by the value shown for negative numbers and increases the required Prec by the value shown for positive numbers. 2. The Prec amounts indicated by this table are expected to result in a 0 dB link margin; however, compatibility testing with the SN must be performed to confirm this performance. Customers are expected to take the necessary precautions to ensure an appropriate margin is maintained during the mission. 3. The nominal and minimum bandwidths are the double-sided 3 dB bandwidth introduced by the transmitters filter. Nominal bandwidth is defined as 8x the I or Q channel baud rate, whichever is greater. Minimum bandwidth is defined as 2x the I or Q channel baud rate, whichever is greater. 4. The Prec adjustment values are based upon analysis of the combined effect of all constraint parameters at their maximum values. The Prec adjustment value may be improved for customers operating with constraints at less than the maximum values. Customers should contact GSFC Code 450 for compatibility testing and further analysis.

Revision 9

J-4

450-SNUG

Appendix K. Use of Reed-Solomon Coding in Conjunction with SN User Services

K.1

General

This Appendix describes the use of Reed-Solomon (R-S) coding, both alone and combined with convolutional coding. The SN supports R-S decoding for WDISC customers only; however, the data rates supported by the WDISC are limited (please see Section 3, paragraph 3.6 for further information). Although the SN does not presently support R-S coding for all data rates, the customer MOC may perform R-S decoding for improved performance. The Consultative Committee for Space Data Systems (CCSDS) has recommended the following telemetry coding standards for space communications [1]: a. Rate-1/2 convolutional coding. b. (255, 223) R-S coding. c. Concatenated coding: a rate-1/2 convolutional inner code with a (255, 223) R-S outer code.

d. Turbo coding (not discussed in this Appendix). In the discussion that follows, all operating points (BER vs Eb/No) are based on the theoretical (best-possible) performance of the forward error correction code. Thus, all operating points discussed are illustrated by the theoretical curves in Figure K-1. In practice, the actual Eb/No required for any SN-specified operating point is the theoretical value plus the SNs allowable implementation loss for the service type, configuration, data rate, and channel coding. The Prec values in the main body of this document include this implementation loss. The Prec reduction values given in paragraph K.4 below assume the customer is compliant with all constraint parameters. K.2 Concatenated Coding: A (255, 223) Reed-Solomon Outer Code with a Rate 1/2 Convolutional Inner Code

K.2.1 Throughout the SNUG, the customers Prec has been specified to maintain a 10-5 BER in an AWGN channel. At this BER, rate-1/2 coding allows customers to reduce their required Prec by 5.4 dB relative to an uncoded signal. Concatenated coding the use of R-S coding as an outer code with a rate-1/2 convolutional inner code can further improve BER performance. Customers planning to operate at a BER worse than 10-5 at the output of the ground terminal convolutional decoder are required to negotiate support with GSFC Code 450.

Revision 9

K-1

450-SNUG

THEORETICAL CURVES 1

10 -1

10 -2
IDEAL PSK, NO CODING

10 -3

CONV. CODING (7, 1/2)

R-S CODING (255, 223)

10 -4 Pe
CONV. + R-S (IDEAL INTERLEAVE)

10 -5

CONV. + R-S (NO INTERLEAVE)

10 -6

10 -7

10 -8

10 -9

10 -10 0 1 2 3 4 5 6 8 9 10 11 12 E /N (dB) b o

Figure K-1. Theoretical Performance of Concatenated, R-S, and Convolutional Coding (from [2])

Revision 9

K-2

450-SNUG

NOTE: Throughout this document, the coding gain achieved by using rate 1/2 convolutional coding is already included in the equations for determining the return link minimum required Prec for a 10-5 BER. K.2.2 Figure K-1 shows the theoretical performance of concatenated coding. Customers with an Eb/No of 4.2 dB (referenced to the data rate of the convolutional code) can achieve a BER of 10-5 at the output of the convolutional decoder at the ground terminal, and a BER of 10-10 at the output of the R-S decoder (without interleaving). K.2.3 Although the CCSDS recommendation for telemetry coding does not include periodic convolutional interleaving (PCI) of the convolutional encoder output symbols, PCI is recommended for S-band customers with concatenated coding and channel baud rates > 300 kbps. When interleaving is not employed for channel baud rates > 300 kbps, S-band performance may not be guaranteed. K.3 (255, 223) Reed-Solomon Coding (Without Convolutional Coding)

K.3.1 Since all S-band return services (SSAR, MAR, and SMAR) require convolutional encoding, R-S coding alone (without the convolutional inner code) applies only to the KuSA and KaSA return services. Uncoded signals must maintain an E b/No of 9.6 dB in an AWGN channel in order to achieve a 10-5 BER at the ground terminal. R-S encoding alone, in conjunction with KuSAR or KaSAR service, allows the customer to reduce their Prec by up to 3.0 dB and still achieve a BER better than 10-7 at the output of the R-S decoder. K.3.2 When transmitting at a reduced Prec with an E b/No less than 9.6 dB, the customer will be operating at a BER worse than 10-5 at the input of the R-S decoder. K.4 Summary

K.4.1 The resultant Prec reductions and BER performance with R-S encoding are summarized in Table K-1. R-S decoding is performed either by the SN for WDISC customers or at the customer MOC.

Revision 9

K-3

450-SNUG

Table K-1. Performance of R-S Encoding in Conjunction with SN Services

Reference Point (notes 3 and 4) Coding Scheme Input to R-S Decoder (note 1) Eb/No = 4.2 dB BER = 10-5 Eb/No = 9.6 dB BER = 10-5 Eb/No = 6.6 dB BER worse than 10-5 (note 2) Output of R-S Decoder (ground terminal or MOC) BER ~ 10-10 BER much better than 10-10 BER better than 10-7 Resultant Prec Reduction for BER

Concatenated Coding (note 5)

None; better BER at R-S decoder None; better BER at R-S decoder 3 dB

(255, 223) R-S Coding Only

Notes: 1. Eb prior to R-S decoding is referenced to the customer data rate at the input to the R-S decoder (that is, the information rate multiplied by 255/223). 2. Support for signals with BERs worse than 10-5 must be negotiated with GSFC Code 450. 3. BERs assume ideal R-S performance as well as an ideal communications channel between the ground terminal and the MOC. 4. Customers must also comply with the Prec requirements for signal acquisition and antenna autotrack acquisition, if applicable. 5. This Appendix uses the term concatenated coding to represent a rate-1/2 convolutional inner code with a (255, 223) R-S outer code.

K.4.2 The reduction in Prec applies only to the Prec required for BER performance. Customers must also comply with the Prec requirements for signal acquisition and antenna autotrack acquisition, if applicable. Support for signals with a BER worse than 10-5 must be negotiated with GSFC Code 450. K.4.3 Customers operating in an RFI environment will experience additional losses that have not been characterized at this time. Such customers should coordinate with GSFC Code 450 to determine performance.

Revision 9

K-4

450-SNUG

References 1. Telemetry Channel Coding, Recommendation for Data System Standards, CCSDS 101.0-B-4, Blue Book, Issue 4, Consultative Committee for Space Data Systems, May 1999. 2. Advanced Orbiting Systems, Networks and Data Links: Summary of Concept, Rationale, and Performance, Recommendation CCSDS 700.0-G-3, Green Book, Issue 3, Consultative Committee for Space Data Systems, November 1992.

Revision 9

K-5

450-SNUG

This page intentionally left blank.

Revision 9

K-6

450-SNUG

Appendix L. McMurdo TDRSS Relay System (MTRS)

L.1

General

The MTRS is a TDRS relay ground system within the National Science Foundations (NSF) McMurdo facilities in the Antarctic. The Wallops managed McMurdo Ground Station (MGS) receives S-band and X-band data from orbiting missions. The X-band data can be sent from MGS to the MTRS to provide delivery of near real-time or stored high rate scientific data through TDRS to WSC for delivery to end users. The MTRS can be used to relay data at rates of up to 300 Mbps. Please contact GSFC Code 450 for the latest information and potential support. L.2 Operational Overview

Figure L-1 depicts an overview of the MTRS data flow from orbiting missions to the WSC. The MTRS is located on Ross Island near the MGS and provides approximately 10 hours of daily TDRS view for data relay. The TDRS at 171 west longitude and the TDRS at 174 west longitude are used, but MTRS has much better visibility to TDRS 171 W. The MTRS is interfaced to the MGS system and can be remotely operated at MGS for data transfer via TDRS (171 W/174 W) to WSC. The MTRS transmits the data via the TDRSS KuSA return service at total data rates up to 300 Mbps. Support has been provided to polar missions on a "demonstration capability basis" for high rate relay of data from the MGS thru MTRS to WSC. Currently, MTRS is not considered to be an "operational asset", but may be in the future. Please refer to the Operations Interface Procedures for the McMurdo TDRS Relay System, 532-OIP-NCC/MTRS, for additional information. Additionally, scheduling coordination needs to be performed between all elements to ensure successful relay of data.

Revision 9

L-1

450-SNUG

Revision 9
TDRS 10-m
S-Band CMD

NASA Spacecraft

S-Band TLM

X-Band TLM

RF Subsystem

4.6-m Ku-Band

White Sands, NM RF Equipment Ku-Band Amp

Monitor & Control Subsystem Baseband Subsystem
S-Band CMD S-Band TLM

Building 71 3 mile Fiber Optic Interface

X-Band TLM

L-2 450-SNUG

GSIF X/Ku-Band Upconversion GSFC Fiber Optic Cable (1.5 miles) X-Band Modulator MTRS Monitor & Control Computers 25 x 12 room in Crary Lab RAID

MTRS Interface

MTRS Switch

MTRS Communications Link (Ross Island)

MGS
Tape Shipments

Figure L-1. MTRS Data Flow

Appendix M. South Pole TDRSS Relay (SPTR) and WSC Alternate Relay Terminal (WART)

M.1 M.1.1

General South Pole TDRSS Relay (SPTR)

The SPTR, located at the Amundsen-Scott South Pole Station, Antarctica, provides Internet connectivity, Voice over Internet Protocol (VoIP) telephony, and e-mail services to the South Pole science LAN via TDRSS SSAR and SSAF links, and high rate file transfers via TDRSS KuSAR links. M.1.2 WSC Alternate Relay Terminal (WART)

The WART provides dedicated support to United States Antarctic Program (USAP) operations at the South Pole (primarily to the SPTR that is located at the true South Pole) and for control of the F-1 TDRS. This will be a limited capability in that it will only provide the following functionality: a. TT&C for F1 b. SSA forward/return at 3.088 Mbps c. M.2 KuSA return at 60 Mbps Operational Overview

Figure M-1 depicts an overview of the SPTR/WART data flow. TDRSS service via the SPTR/WART consists of SSAF and SSAR links at a ~3 Mbps rate for full duplex Internet, VoIP, and e-mail communications, and KuSAR links at a 60 Mbps rate for simplex file transfer communications (server-to-server file replication). The SPTR system can only use the highly inclined TDRS F1 spacecraft currently located at 49 West longitude, which provides approximately 5-6 hours of daily communications. WART interfaces with the USAP Network via SPTR for real time South Pole TCP/IP communications. WART has a file server which forwards stored files received from the SPTR to an end server located in Denver, CO. Please refer to the Standard Operating Procedures, CSOC-WSC-SOP-306 for the SPTR System, and the Operations Concept, CSOC-WSC-OC-001310 for the WART system, for additional information.

Revision 9

M-1

450-SNUG

S & Ban Re d t L Fw in d k

Revision 9
Ku nd Ba t Re k Lin
d nd L Ba G u- S Ku RS R TD

Router

Denver, CO

RPSC
45 Mbps T3 Interface (3 Mbps S-band Traffic, 42 Mbps Ku-band Science Data)

Internet

File Server Router

File Server 60 Mbps

60 Mbps

South Pole LAN

3.088 Mbps

3.088 Mbps

Router

South Pole TDRSS Relay

White Sands Complex

WART SPTR

M-2 450-SNUG

SPTR Links
- S-Band Forward and Return @ 3.088 Mbps IP - Ku-Band Return 60 Mbps File Transfer Service

Figure M-1. SPTR/WART Data Flow

Appendix N. Network Test Services

N.1

General

This Appendix presents overview information that supplements existing NASA test documentation regarding NASAs compatibility test methodology and SN systems test methodology. The contents are completed to a level intended to summarize the test methodology, possible configurations, resources, participating organization responsibilities, and test planning activities. N.2 Verification Methods

The following methods of verification can be applied to verify the customer functional, interface, and performance requirements. a. Test b. Evaluation c. N.2.1 Demonstration Test Method of Verification

Test is the method of verification whereby requirements are verified by measurement during or after the controlled application of functional and environmental stimuli. These measurements may require using laboratory equipment, recorded data, procedures, test support items, or services. For all test activities, pass or fail test criteria or acceptance tolerances are specified prior to conducting the test. This method ensures that the actual performance of tested equipment or systems meets or exceeds specification requirements. N.2.2 Evaluation Method of Verification

The evaluation method of verification is used when actual operational conditions cannot be entirely simulated, the test parameters cannot be completely tested at the box level, or it is too costly to use the test method of verification. Evaluation may use the results from limited tests or multiple lower level tests and analyses. The data taken can be compared to the transceiver requirements, but are generally not sufficient to provide verification to the extent of the test method. N.2.3 Demonstration Method of Verification

Demonstration is a method of verification used to imply the properties of an end item or component in which operations or physical characteristics of the end item are observed. This observation may exercise equipment operations, functions, and/or characteristics that are not specified as explicit end item requirements. Demonstration is used with or

Revision 9

N-1

450-SNUG

without special equipment or instrumentation to verify characteristics such as operational performance, human engineering features, maintainability, built-in transportability, and display data. When used as a formal verification activity, the observed demonstrated performance is recorded. N.3 Test Services Description

Test services can be discussed in categories of testing. An example of the typical Phased Test & Verification Chronology is: a. Component Level Testing b. Integrated System Testing c. End-to-End Testing d. Simulations & Training Exercises/Launch Site Testing N.3.1 Component Level Testing

Component level testing is defined as installation and setup of an individual communication element in a stand-alone box test configuration. The objectives are focused on the components functional capabilities in order to determine the units adherence to specifications and operational goals. The testing also includes the installation and setup of the test equipment to ensure proper configuration and test readiness. The testing checks new hardware and software to ensure that it will work in the existing network environment. N.3.2 Integrated System Testing

The integrated system level of testing is performed when the customer communication subsystem is integrated as an operational system and ready for testing. Integration testing confirms hardware connectivity to support systems and that the support software is properly installed and operational. During this testing the overall system capabilities are evaluated. The objectives are focused on the integrated system functional capabilities in order to determine the units adherence to specifications and operational goals. In the integrated configuration the effects of the various avionic equipment are accounted for and compared to the expected overall functionality of the system to meet the necessary operational needs. N.3.3 End-to-End Testing

End-to-end testing (EET) is conducted to verify data flow through the entire end-to-end system (space to ground). The testing ensures that all mission functional support elements perform in a mission configuration. The testing involves the control center, data circuits, and SN interfaces to the customer platform.

Revision 9

N-2

450-SNUG

N.3.4

Simulations & Training Exercises/Launch Site Testing

Pre-launch customer/SN simulation testing can be used to validate SN performance with customer communication equipment prior to the launch of the customer platform. This validation includes operations checkout, end-to-end tests, and fault simulation tests. This simulation testing can be performed at a customer facility or at the customer platform launch site. In addition, training for customer project personnel can be accomplished. The guidelines for this support appear in the STDN No. 403 series document for a particular customer. N.4 N.4.1 Network Test Support Organizations RF Simulation Operations Center (RFSOC)/Simulation Operations Center (SOC)

The RFSOC and SOC, located at GSFC, provide facilities for conducting customer flight project mission simulations for SN customers. They can monitor SN performance during these mission simulations, simulate a mission-unique customer platform, verify SN/customer MOC interfaces, and simulate a customer MOC in support of fault isolation. When coupled with the RFSOC transmitting through the TDRS, the SOC simulators can provide a complete network experience for operations teams and POCCs. Additional information regarding the capabilities of the RFSOC can be found at http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#RFSOC. Additional information regarding the SOC can be found at http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#SOC. Also refer to document 450FDCD-SOC/RFSOC for additional testing service information. N.4.2 Compatibility Test Van (CTV)/Compatibility Test Laboratory (CTL)

Home-based at GSFC, CTV provides the means to test customer platforms at remote locations for RF compatibility with the SN, which includes an end-to-end test after local compatibility testing is completed. The CTV can provide cabled RF interfaces to a customer platform for local RF compatibility testing. The CTV also has a rooftop antenna for TDRSS relay performance tests. Similar in capability to the CTV, the GSFC-based CTL can provide cable RF interfaces to a customer platform for local RF testing and a rooftop antenna for SN performance tests. In this case, the customer brings the platform RF components to the GSFC CTL and these components are set up in an RF-shielded screen room for testing. Additional information regarding the capabilities of the CTV and CTL can be found at http://sce.gsfc.nasa.gov/FACILITIES/index.shtml#CTL_CTV. Refer to the document Space and Ground Networks Compatibility Test Systems Specifications, 450-SPECCTV.

Revision 9

N-3

450-SNUG

N.4.3

TDRSS End-to-End Test Systems

Equipment is available at all three WSC ground terminals (STGT, WSGT, and GRGT) to provide customers with end-to-end system testing capabilities. The TDRSS EET systems provide customer projects the capability of testing the end-to-end SN data communications through a ground-based simulation of the customer platform-to-MOC link via TDRSS, thus eliminating the need for the actual customer platform (please see paragraph N 6.1.2.d). Each EET system can simultaneously provide end-to-end testing of forward, return, and tracking services for one S-band (SSA or MA) and one Ku-band (KuSA) customer. Please note that TDRSS does not provide EET services for Ka-band (KaSA) customers. Also note that since GRGT has no interface to support receiving and transmitting test data with the customer, EET via GRGT is limited to local mode. N.5 Determining Required Testing

Through coordination with the GSFC Code 450 Customer Commitment Manager (CCM) and Code 450 test personnel, the customer project will receive assistance in determining the appropriate testing necessary to confirm SN compatibility and configuration readiness. There are tests that are typically performed at the different levels of customer readiness. For example, a customer preparing for a mission that has proven TDRSS communications components will most likely require testing from the integrated system test perspective. On the other hand, a customer with a first-time TDRSS component may require the whole range of testing. In addition, some testing might be optional (i.e., ship-n-shoot with no launch site testing). N.6 N.6.1 N.6.1.1 Test Planning, Scheduling, and Reporting Test Planning Test Planning Process

Coordination with Code 450 personnel to obtain the necessary resources is essential. Code 450 management and test personnel will schedule WSC, CTL, CTV, SOC, and RFSOC resources accordingly to meet customer mission timeframes. N.6.1.2 Basic Phases of Testing

The basic phases of testing supported by the SN are as follows: a. RF Engineering Lab/Bench Testing. RF Engineering Lab/Bench Testing is performed by network engineering personnel using the TDRSS User RF Test Set (TURFTS) to complete engineering tests not readily supported by the hardware vendor. This testing is optional but, if requested by the project, takes place prior to TDRSS compatibility testing, and involves physical interface checks and an initial checkout of the overall functionality of the stand-alone communications transmitter/receiver. Additional vendor supplemental testing may also be conducted. Additional information regarding the capabilities of the

Revision 9

N-4

450-SNUG

TURFTS can be found in Space and Ground Networks Compatibility Test Systems Specifications, 450-SPEC-CTV. b. TDRSS Compatibility Testing. The purpose of TDRSS compatibility testing is to verify that the communication unit parameters and equipment are compatible with TDRSS. Successful TDRSS compatibility testing is a prerequisite for a SN commitment to support a customer project and is a building block in the progression to certifying mission readiness. The customers RF ICD with the SN is one of the primary documents used to develop the Compatibility Test Plan (CTP). Compatibility testing is performed by the CTV (for testing at remote customer locations) and the CTL (for testing customer systems at GSFC). Information about TDRSS compatibility testing is contained in Space and Ground Networks Compatibility Test Systems Specifications, 450-SPEC-CTV. In general, the CTV and CTL perform the following functions: (1) act as a SN simulator to verify the integrity of the RF link; (2) provide assurance that the SN tracking, telemetry and command parameters, as well as equipment and operational procedures, are adequate to meet the communication requirements; (3) serve as an RF relay between customer equipment and the TDRS; and, (4) serve as a test set for fault isolation. Compatibility tests are performed to analyze the SN command forward link and telemetry return link modes of transmissions to and from the unit. Testing is conducted with pseudorandom data generated from a data transmission test set. A series of preliminary RF engineering tests are selected and conducted in accordance with STDN No. 408.1, the STDN Spacecraft RF Compatibility Test Procedure and Data Sheets document. These compatibility tests check the unit performance parameters and verify the interoperability of the system signals with the SN. These tests are designated by number groups which are categorized by customer platform carrier tests, command signal tests, acquisition and tracking tests, and forward/return link bit error rate (BER) tests. Verification tests are a variety of tests that are performed after engineering tests are complete. This series of tests provide an initial validation of command, telemetry, and tracking data services with the new customer. The testing encompasses verification of scheduling, status, and control functions. These tests emphasize problem resolution and assist a new customer with meeting all SN interface requirements. c. SN Interface Testing. SN Interface Testing is designed to test the end-to-end RF link performance of the unit with an operational TDRS. The test utilizes the CTL and/or the CTV. SN RF Tests operationally verify the following: 1. 2. Forward link service from a TDRS to the unit. Return link BER Performance and link margin for SN services from the unit to a TDRS with simulated antenna assembly gain.

Revision 9

N-5

450-SNUG

3.

Reacquisition of both forward and return services, following a momentary interruption of services.

d. SN Performance Baseline Testing. The SN utilizes the TDRSS EET capability to validate the networks ability to support forward and return link services for a customer unit. This testing verifies the SN configurations required to support the return and forward links, configuration codes, and WSC modifications and configurations independent of the customer by conducting EET simulations. This evaluation confirms the SN configuration required to support customer testing, and provides SN performance evaluation and characterization baseline data. This testing is available for the simulation of SSA, MA, and KuSA services, however, it is not available for KaSA services. Figure N-1 provides a high-level illustration of SN Baseline Characterization.

TDRS

SSAF SSAF

SGL
SSAR

SSAR

EET Simulations

SGLT
PTE
BERTS OOTMS SA

EET

WSC

Figure N-1. SN Baseline Characterization

Revision 9

N-6

450-SNUG

N.6.2

Test Scheduling

The use of all SN test resources must be formally coordinated through the GSFC MSP. These resources include, but are not limited to, the SN, NISN, and other supporting elements. Please refer to paragraph N.6.1 to see the process for test planning. The scheduling of SN test resources is initiated by the Network Operations Manager (NOM), who is located at GSFC. Based on customer coordination with the GSFC Code 450, the NOM submits planning inputs to the SN Forecast Schedule (please see Section 10 for a description of SN event scheduling), which is issued on a weekly basis for planning purposes. Contingency or backup test dates may also be scheduled for tests that require critical or scarce resources. N.6.3 Network Configuration and Briefing Messages

The network configuration is specified in the Briefing Message (BM), which is issued for each TDRS test. Control of the overall network is maintained by WSC, which provides details of specific configurations for specific test dates. A BM is issued three days before the RF-through-TDRS test in order to orient and advise all SN participants and supporting elements. Draft BMs are circulated up to two weeks in advance for review and refinement. The BM is generated by the NOM and contains a test title, the date and time for the test, a test time line, and a description of the element responsibilities for the test. BM coordination and scheduling normally begins four weeks prior to a test. N.6.4 Test Readiness Review

Test personnel may conduct an internal Test Readiness Review (TRR) prior to the start of testing to verify equipment and personnel safety. A TRR may be held no later than 2 days prior to the performance of test events. At this meeting, all test activities and responsibilities are reviewed for completeness. N.6.5 Test Reporting

Test results are documented in reports that cover all phases of testing. a. RF Engineering Report. Test results are logged in an engineering notebook. A memorandum documenting the test results is prepared by test personnel and distributed the following workday after the completion of each days tests. b. CTV Compatibility Test Report. A test result report is produced by compatibility test personnel after detailed analysis of the data taken during the RF link compatibility tests. This report includes performance plots, equipment/setup photographs, and completed data sheets. The report is usually delivered within two months after test conclusion. c. SN Test Report. A series of daily SN Test Reports (TRs) produced by the NOM provides the inputs required to conduct a post-test evaluation and data analysis

Revision 9

N-7

450-SNUG

contained the SN Test Report. The report is usually delivered a few days after test conclusion. d. Quick-Look Report. A quick-look report is a technical performance evaluation provided on the following workday. This report also outlines the test objectives and notes whether all the objectives were met, or if a retest is required. For Compatibility Testing, compatibility test personnel generate a quick-look memo that provides a preliminary look at the results of the test. Responsible test personnel provide quick-look memorandums 1-3 days after the completion of each test. Test procedures and briefing messages detail the information collected from all participants.

Revision 9

N-8

450-SNUG

Appendix O. Self/Mutual Interference Considerations for New Customers at 2287.5 MHz

O.1

Introduction

This Appendix provides an assessment of self/mutual interference in the TDRSS MA environment at 2287.5 MHz, based on the results of an interference analysis performed on the 2287.5 MHz RF environment 1 . Self-interference is the interference incurred from other MAR/SMAR customers. Mutual interference is the interference incurred from SSAR customers operating at 2287.5 MHz. The amount of self and mutual interference included in a customers MAR/SMAR link budget should be negotiated with GSFC Code 450. Improving TDRSS capabilities potentially increase interference on the MAR link due to rising data rates. The F1-F7 series increased its maximum data rate to 150 kbps per channel from 100 kbps. In addition, the TDRS F8-F10 series will expand the MAR capability to a data rate of 1.5 Mbps per channel. Finally, for the DAS, the quantity of customers is not limited by the SN ground infrastructure. Currently 2 dB is built into the MAR/SMAR required Prec equations given in Section 5 for self and mutual interference degradation. In addition, ACRS may be used to mitigate interference. ACRS is a tool that customers can utilize to determine potential future interference periods with other customers. The customers can then try and schedule their services around the times when they would be subject to high interference. GSFC Code 450 may support customers with a self and mutual interference degradation of less than 2 dB; however, this type of support needs to be coordinated with GSFC Code 450. O.2 Interference Study

The MA interference study was conducted to examine the impact of the near-term interference environment, with different TDRSS constellations, on system interference. The current allocation of 2 dB for mutual and self-interference was evaluated on its ability to protect customers from data loss due to interference, as well as its appropriateness for Demand Access type customers. The interference was studied using large Monte Carlo simulations, designating one customer as a victim, and the other customers as interferers. The simulation considered the orbits, antenna patterns, and TDRS link budgets of all the customers. A candidate mission model was developed for 2287.5 MHz customers in 2003. This mission model included: current customers, BRTS, projected unspread high data rate
1

Interference Analysis for Management of the Interference Environment at 2287.5 MHz, Prepared for Badri Younes by ITT Industries under contract S-87070-Y, ETS-450-100028, August 18, 2000.

Revision 9

O-1

450-SNUG

customers, and projected profile of Demand Access customers. Besides identifying customers and their link characteristics, the mission model also determined duty cycles for each link. For further information concerning the mission model, contact GSFC Code 450 to obtain a copy of the full analysis report1. The simulations generated interference statistics for different customers and TDRSS constellation scenarios. Different TDRSS constellation scenarios were investigated to represent the phasing of the F8-F10 satellites, which can support higher customer data rates. The principal output was the percentage of time that a given customer experienced different levels of Eb/N0 degradation due to the interference from other customers. Table O-1 shows the scenarios for which simulation runs were done, including the TDRS satellite locations for each. The simulations accounted for geometric considerations as well as customer duty cycles. The analysis report also presents static analysis results for a worst-case boresight interference, which do not consider geometry or duty cycles. Table O-1. Defined Interference Scenarios
Scenario F1-F7 TDRSS satellites Locations (note 1) 41W, 174W, 275W F8-F10 TDRSS satellite locations (note 1) None Mission Model

2 3

41W, 46W, 171W, 174W, 275W 41W, 46W, 174W, 275W

None 171W

2003 mission model Projected Demand Access profile Same as scenario 1 2003 mission model Projected Demand Access profile High power, high data rate DG2 customers with directional antennas High power, high data rate DG2 customers with omni antenna Same as scenario 3

41W, 174W, 85E

46W, 171W

Note: 1. For all scenarios, customers were randomly assumed to receive support from available TDRS East (41W and 46W) and West (171W and 174W) satellites. Customers were only assumed to receive support from the TDRS ZOE (275W) satellite when no other TDRS was in view.

Revision 9

O-2

450-SNUG

O.3

Conclusions From Interference Study a. For Scenarios 1 and 2, which do not include TDRS F8-F10 spacecraft or highpower TDRS F8-F10 customers, most of the existing MA customers have enough extra EIRP margin to keep the self/mutual interference rate below 5%. 1. 2. 3. Those customers that have only the 2 dB self/mutual interference allocation experience interference rates approaching 10%. This indicates that Prec margin is a strong predictor of performance against self-interference. As expected, the interference rates show a consistent small reduction in scenario 2, due to the presence of 5 TDRS satellites instead of 3.

Several conclusions were drawn from the results of the interference simulations:

b. The results for Scenarios 3 and 4 show somewhat increased interference, as might be expected in the presence of high-power F8-F10 customers, but interference rates still remain below 10% for the most part. c. With roughly 2 dB of margin beyond the SNUG Prec, the percentage of time that service is impacted for a victim by the MA self/mutual interference can be reduced to less than 5%.

d. Even more margin seems to eliminate the effect of self-interference altogether. O.4 Effect of Prec Margin on Interference

The Prec specified in the SNUG already includes a 2 dB allocation for self/mutualinterference. The amount by which an MA customers Prec differs from the SNUG Prec is called the margin. The point at which service is impacted with loss of data is defined as the case when the margin against the Prec has been used up, as well as the self and mutual 2 dB allocation for interference. The results from the simulations were analyzed for the effect of Prec margin on the interference. The plots below show average service impact percentages for different victims, versus the Prec margin above the 2 dB interference allocation. Scenario 3 was not plotted due to its similarity to Scenario 4 for most of the victims. Figure O-1, Figure O-2, and Figure O-3 show results for Scenarios 1, 2, and 4. Certain conclusions can be drawn from this analysis of interference versus Prec margin: a. With roughly 1.5 to 2 dB of margin beyond the SNUG Prec, the percentage of time that service is impacted for a victim by the MA self/mutual interference can be reduced to less than 5%, for Scenarios 1 and 2. b. With no additional margin allocated beyond the SNUG Prec, a victim suffers worse interference on average in Scenario 4. However, additional margin of 2 dB is sufficient to reduce the average interference time to less than 5%.

Revision 9

O-3

450-SNUG

Scenario 1: F1-F7 TDRS at 41W, 174W, 275W

10 9 8 Average Percent of Time Service Impaired 7 6 5 4 3 2 1 0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Prec Margin Above 2 dB Interference Allocation (dB)

> 100 kbps 10 to 100 kbps <= 10 kbps, Omni

Figure O-1. Average Service Impact Versus Prec Margin, Scenario 1

Scenario 2: F1-F7 TDRS at 41W, 46W, 171W, 174W, 275W
10 9 8 Average Percent of Time Service Impaired 7 6 5 4 3 2 1 0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Prec Margin Above 2 dB Interference Allocation (dB)

> 100 kbps 10 to 100 kbps <= 10 kbps, Omni

Figure O-2. Average Service Impact Versus Prec Margin, Scenario 2

Revision 9

O-4

450-SNUG

Scenario 4: F1-F7 TDRS at 41W, 174W, 275W HIJ TDRS at 46W, 171W
25

20 Average Percent of Time Service Impaired

> 100 kbps 10 to 100 kbps <= 10 kbps, Omni

15

10

0 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 Prec Margin Above 2 dB Interference Allocation (dB)

Figure O-3. Average Service Impact Versus Prec Margin, Scenario 4

Revision 9

O-5

450-SNUG

This page intentionally left blank.

Revision 9

O-6

450-SNUG

Appendix P. SN Web Services Interface (SWSI)

P.1 General

The SWSI provides a secure network-based Graphical User Interface (GUI) to the NCCDS and to the DAS to perform SN customer scheduling, real-time service monitoring and control, and state vector storage. It supports access through the Open IONet as well as the Closed IONet. NASAs university, enterprise, and inter/intraagency partners can access SWSI through the Open IONet, which allows access from other networks such as the NASA Science Internet and the public Internet. The SWSI architecture is shown in Figure P-1.

DASCON
NISN Secure Gateway

Firewall

S P S R
N P G

MOC Clients

MOC Clients

T U T

C C S

Internet Internet

MOC Clients

NCCDS

Closed IONet

Firewall

S P S R
N P G

Open IONet
CNE
T U T

C C S

ANCC Application Server (Open Clients) TUT webserver SWSI Open Server (Prime) TUT webserver SWSI Open Server (Backup) Application Server (Open Clients)

Application Server (Closed Clients)

SDIF SNIF

Application Server (Closed Clients)

SDIF SNIF

(ANCC) Isolator (Closed Clients)

SNIF

(ANCC) (NCCDS) Isolator (Closed Clients)

SNIF

(NCCDS) Isolator (Open Clients)

Isolator (Open Clients) Data

SWSI Backend Server (Prime)

SWSI Backend Server (Backup)

Figure P-1. High Level SWSI Architecture

Revision 9

P-1

450-SNUG

P.2 P.2.1

Major System Components Client

The Client consists of two components. The platform is the users desktop workstation, which can be any desktop that supports Sun Microsystems Java Virtual Machine (JVM) 1.4.1. The software component is the Client application, which executes on the users desktop workstation and provides a Graphical User Interface (GUI) for performing SWSI client operations. P.2.2 P.2.2.1 Servers Backend Server

The Backend Server hosts most of the SWSI server applications, manages user login sessions, database storage, and the communications with NCCDS and DAS. P.2.2.2 Open Server

The Open Server is a proxy server to allow users on the Open IONet and the Internet to connect to SWSI and to access TUT. User requests are directed to a Backend Server through the NISN Secure Gateway using a single predefined set of rules. This allows for the addition of new customers and users without the need for adding new Secure Gateway rules. P.2.2.3 Database

The database is the backend data storage that holds all customer configuration and scheduling data and allows access to customer schedules from any Client Workstation for any authorized user. P.2.2.4 Open TUT Server

The Open TUT Server is the web server that mirrors the TUT web service provided by NCCDS on the Closed IONet. The Open TUT Server data is updated hourly. Clients on the Open IONet and the Internet can retrieve this data from the Open Server. P.3 P.3.1 External Interfaces Network Control Center Data System

The SWSI communicates with the NCCDS on behalf of SWSI customers through implementation of the 452-ICD-SN/CSM, Interface Control Document between the Space Network and Customers for Service Management protocol. All communications use Transmission Control Protocol/Internet Protocol (TCP/IP) and are limited to those messages designated for full support customers.

Revision 9

P-2

450-SNUG

P.3.2

Auxiliary Network Control Center (ANCC)

The SWSI interfaces with the ANCC to allow SWSI customers to perform interface testing and user training. P.3.3 Demand Access System

The SWSI communicates with the DAS on behalf of SWSI customers through implementation of the 452-ICD-DAS/SWSI, DAS/SWSI Interface Control Document protocol. All communications use TCP/IP. P.3.4 NISN Secure Gateway

The SWSI channels all message traffic from Open IONet clients and Internet clients through a single communications link between the Open Server and the Backend Server components. This communications path through the NISN Secure Gateway is established with a small static rule set, which means that Secure Gateway changes are not required in response to SWSI customers being added or removed. P.4 P.4.1 SWSI Features and Operations Features

The SWSI supports scheduling and real-time mission control and monitoring for both the NCCDS and the DAS. It supports DAS playback operations. It also supports state vectors and the maintenance of mission parameters and data. P.4.1.1 Client Customization

The SWSI client provides a configuration file to customize operation of the Client for the user. Options for viewing alerts and real-time performance data, and for controlling or reconfiguring ongoing services can be controlled by a menu. P.4.1.2 Vector Processing

The SWSI provides the capability to generate orbiting or stationary state vectors based on user input of geocentric (position & velocity) or geodetic (latitude, longitude, & altitude) coordinates. It also transmits state vectors to the SN. The SWSI provides users with the capabilities of importing or directly entering IIRVs. The SWSI provides users with the capability of selecting any IIRV for an appropriate Support Identification Code (SIC) stored on the Client Workstation and transmitting that IIRV to the NCCDS. P.4.1.3 TUT Access

The SWSI maintains an Open TUT Server that mirrors the TUT web service provided by NCCDS on the Closed IONet. The Open TUT Server data is updated hourly. Operation of the Open TUT web page is the same as when accessed directly through the NCCDS

Revision 9

P-3

450-SNUG

and ANCC TUTs on the Closed IONet, with the exception that the main SWSI Open TUT page allows selection of either Operations or EIF TUT. P.4.1.4 Alert Handling

When SWSI receives a DAS alert, it identifies the user implied by the SIC specified in the alert message and makes the text of the alert message available for review by that user. If the alert message does not apply to a specific user, the SWSI alerts all users and makes the text available for their review. P.4.1.5 Database Management

The SWSI provides a comprehensive database management capability for all SWSI data. It provides all data storage and retrieval capabilities necessary to support the requirements for SN services including the capability to store and retain requests sent to the NCCDS and to the DAS. SWSI administrative personnel have the ability to access the contents of server log files. SWSI client users have the ability to access the contents of the client log files for which they are authorized. P.4.1.6 Logging

The SWSI logs records pertaining to the establishment and termination of communications connections, logon attempts whether successful or rejected, and system and database failures. It also logs incoming and outgoing external messages and alerts sent to SWSI clients. P.4.2 P.4.2.1 Operations Setup

The first step in becoming a SWSI user is to arrange to obtain SN services through the Customer Commitment Process. This process is described in Section 4. The Network Integration Management Office (NIMO), NASA/GSFC Code 451.1, is responsible for arranging service for new missions. Once an agreement has been reached, the mission planning phase is used to establish an NCCDS configuration for the mission. The prospective customer project supplies the NCCDS with information needed to fulfill mission support requirements. Customer information including the SICs, Support Identifiers (SUPIDENs), SSCs and initial service parameter values, and Prototype Event Codes are maintained in the NCCDS database. SWSI client Software and installation instructions are available from the Internet and Open IONet and from the Closed IONet.

Revision 9

P-4

450-SNUG

P.4.2.2

Startup and Login

Login establishes the users identification and right to access the system. Login also allows the user to select either operations or test mode and select which SIC(s) will be used during the current session. P.4.2.3 SWSI Interactions with the NCCDS

P.4.2.3.1 General The SWSI provides SN customers with the capability to interface with the NCCDS to perform scheduling, service reconfiguration, and performance data monitoring. P.4.2.3.2 Scheduling Users can import files containing bulk schedule requests or they can interactively generate schedule requests. They can also create a new schedule request by copying and editing a previous request. All options specified in the 452-ICD-SN/CSM can be used. The SWSI formats and validates messages before transmitting them to the NCCDS. The SWSI retains a copy of all transmitted requests for a period of time established by administrative personnel. Administrative personnel create and maintain all customer data necessary to perform the scheduling function including the SUPIDENs for each SIC and a set of SSCs corresponding to the set of SSCs maintained for the customer in the NCCDS database. Users can review and reference this data. P.4.2.3.3 Service Reconfiguration The SWSI provides the user with the capability of reviewing the configuration of each currently active service to the level of detail provided in USMs. The displayed status reflects either the original level for each parameter or the latest updated level based on any reconfiguration, as appropriate. Users can enter GCMR messages and transmit them to the NCCDS. All options specified in the 452-ICD-SN/CSM can be used. The SWSI formats and validates messages before transmitting them to the NCCDS. The SWSI retains a copy of all transmitted GCMRs for a period of time established by administrative personnel. Upon receipt of a GCM status message or a GCM disposition message, the SWSI notifies the user that the message has been received with an indication of whether the GCMR was accepted or not, updates status information, and allows the user to view the GCM status message.

Revision 9

P-5

450-SNUG

P.4.2.3.4 Performance Data Monitoring When the SWSI receives an AFN message, a Return Channel Time Delay (RCTD) message, a TTM, or a UPD message from the NCCDS, it verifies that the message is applicable to a logged-on user. If the message is applicable, the SWSI takes appropriate action. For AFN messages, the SWSI notifies the user that an AFN has been received. For RCTD and TTM messages, the SWSI notifies the user that a message has been received and stores the message in a file on the Client Workstation for later processing by customer applications. For UPD messages, the SWSI makes the information from the UPD message available for presentation to that user in real time. The SWSI provides the user with a number of options for the presentation of UPD message information. P.4.2.4 SWSI Interactions with the DAS

P.4.2.4.1 General The SWSI provides SN customers with the capability to interface with the DAS to perform service planning, service allocation, real-time operations, service performance monitoring, and data retrieval. Administrative personnel create and maintain all customer data necessary to interact with the DAS including a set of SSCs that define the default service configurations for each SIC. Users can review and reference this data. P.4.2.4.2 Service Planning Users can request a report on the resource allocations available. The SWSI notifies the user when the report has been received and makes it available for review. P.4.2.4.3 Service Allocation Users can request a list of all currently planned events or details of a specified planned event. Users can also request allocation of a specified resource, modification of a pending resource, or deletion of a pending or ongoing resource allocation. The SWSI notifies the user when a response is received and makes the response available for review. P.4.2.4.4 Real-Time Operations Users can request reacquisition of the return service signal or reconfiguration of values of a specified list of parameters for an ongoing service. The SWSI notifies the user when a response is received and makes the response available for review.

Revision 9

P-6

450-SNUG

P.4.2.4.5 Service Performance Monitoring Users can request that DAS user performance data be enabled or disabled. The SWSI notifies the user when a response is received and makes the response available for review. When user performance data is enabled, the SWSI provides the data to the user as it is received from the DAS. P.4.2.4.6 Data Retrieval Users can request a search for archived data within a specified time window and playback of specific archived data. They can also request deletion or modification of previous playback requests. The SWSI notifies the user when a response is received and makes the response available for review. P.5 Performance Characteristics

The SWSI is designed to operate unattended 24 hours per day, 7 days per week under normal conditions. P.5.1 Data Capacity

The SWSI has the capacity to store data for up to 100 customer spacecraft including one set of operational data, and for at least one set of test data, for each spacecraft. P.5.2 Communications Capacity

The SWSI servers can support up to 50 simultaneous connections for any combination of Internet, Open IONet and Closed IONet SWSI clients. P.5.3 Response Times

The SWSI will add up to 10 seconds for the round trip between the SWSI client and the SWSI servers for interactions with the NCCDS or DAS. The SWSI will add up to 10 seconds for the round trip between the SWSI client and the SWSI servers for simple retrievals of data from the SWSI database, for example, retrieval of a single scheduled SN event. P.5.4 Availability

The SWSI servers are designed for an availability of 0.9999. P.5.5 Maintainability

Routine maintenance of the servers and routine system administration can be performed off-line without taking the SWSI out of service. In the event of a failure, the MTTR is less than one hour.

Revision 9

P-7

450-SNUG

P.6 P.6.1

Provisions for Safety and Security Security Protocols

DAS and SWSI implement the security protocols required to ensure compliance with the Security of Information Technology, NPR 2810.1. The DAS-to-SWSI interface complies with the provisions of the 290-004, IONet Access Protection Policy and Requirements Document, and the 290-003, IONet Security Plan. DAS and SWSI use the source IP address to validate all connection requests. Additional information on SWSI can be obtained at http://swsi.gsfc.nasa.gov.

Revision 9

P-8

450-SNUG

Appendix Q. WSC Transmission Control Protocol (TCP)/Internet Protocol (IP) Data Interface Service Capability (WDISC) System

Q.1

General

This appendix describes the capabilities provided by the WDISC system. The WDISC system was delivered into operations on May 1, 1999. It allows Space Network (SN) customers to send command data and receive telemetry data using TCP/IP. Support is provided via the NASA Integrated Services Network (NISN) Closed IP Operational Network (IONet) using a defined set of authorized addresses. WDISC simultaneously supports up to six forward data channels and six return data channels at both STGT and WSGT. WDISC customers who use GRGT are supported by the WDISC located at WSGT. The Customer MOC interfaces with WDISC via the IONet. The WDISC sends real-time, IP-encapsulated telemetry and playback data files to the MOC via the IONet. Q.2 General Requirements Receive encapsulated forward service data from a customer MOC via the Closed IONet, convert data to serial form, and present it to a WSC Local Interface (LI) port. (Please refer to Appendix I for a discussion of Closed versus Open IONet.) Receive serial return service data from a WSC LI port, encapsulate it, and present it to a customer MOC via the Closed IONet. Monitor data, including computing CCSDS statistics, for forward and return data processed. Provide for data recording. Allow data playback. Provide real-time status on forward and return service data at WSC and/or GSFC.

The WDISC Functional Capabilities include the following:

Please see Figure Q-1 for an overview on WDISC.

Revision 9

Q-1

450-SNUG

Cmd/Tlm Processor

Analysis & Display Workstation

WDISC
Router

White Sands Data Interface System Capability

Router

Hub Router

ooooooooooo

MOC

IOnet

Hub
PTP 1

ooooooooooo

PTP 3

PTP 1

PTP 3

PTP 2

PTP 4

PTP 2

PTP 4

Local Interface Net NCCDS DSMC

Forward Services 6 Channels at 50 kbps at each site

STGT STGT

WSGT WSGT

Return Services 6 Channels at 512 kbps at each site

WSC

Figure Q-1. WDISC Overview Q.2.1 IP Routed Data Services

WDISC utilizes a defined set of authorized IP addresses. The TCP/IP protocol used by WDISC allows for reliable delivery of data packets, whereas UDP/IP does not. WDISC is compatible with the Consultative Committee for Space Data Systems (CCSDS) Telemetry and Telecommand services via use of Programmable Telemetry Processors (PTPs). PTPs are a Commercial Off-the-Shelf (COTS) product. The WDISC PTP vendor has interpreted CCSDS recommendations and coded the PTP software to match their interpretation of customer needs. The WDISC PTP software version excludes any CCSDS SLE functionality but does include Type 1 and 2 CCSDS telemetry frame Virtual Channel processing, randomization, and some types of SFDU headers. CCSDS Command CLTU frames (Command Link Transmission Unit frames are the format for command data packets recommended by the CCSDS.) are routinely passed through the computers without manipulation. (Note: CCSDS documents can be found at their website: www.ccsds.org.) WDISC provides CCSDS compatability that is unavailable from the MDM, such as Reed-Solomon (RS) decoding of telemetry data. WDISC also provides customers with some of the CCSDS space link functions, such as frame synchronization, as well as RS decoding.

Revision 9

Q-2

450-SNUG

Q.2.1.1

WDISC Legacy MDM/4800 Bit Block

The legacy interface is targeted for End-of-Life in the near future and, therefore, many new customers will utilize the WDISC. The replacement interface has not been specified at this documents time of publishing. However, the MDMs have already been replaced by a NASCOM IP SCD (Small Conversion Device) network several years ago. WDISC allows customers outside of the NASA Closed IONet to transmit and receive data over the Open IONet. Please see Figure Q-2 and Figure Q-3.

Project Project IONet Secure Gateway

Restricted Restricted IONet IONet

Project Open Open IONet IONet

Closed Closed IONet IONet

SWSI Legacy WDISC

SWSI
Serial clock and data

Space Space Network Network

Denotes Legacy flows

Figure Q-2. NISN/SN Legacy Interfaces

Revision 9

Q-3

450-SNUG

Project Project IONet Secure Gateway

Restricted Restricted IONet IONet

Project Open Open IONet IONet

Closed Closed IONet IONet

SWSI Legacy WDISC

SWSI
Serial clock and data

Space Space Network Network

Denotes WDISC TCP flows

Figure Q-3. NISN/SN WDISC Interfaces

Q.2.1.2

WDISC IP

The WDISC IP interface is supported via Closed IONet interface (see Figure Q-3 and the IONet Access Protection Policy and Requirements). Because this interface is Unicast IP, it is possible to interface to it via the IONet Secure Gateway System from the Restricted IONet, the Open IONet, or a private network. Q.2.2 WDISC and the SN

The WDISC affords TCP/IP customers uniform access to SN services provided by the WSC and Guam ground stations. PTPs provide these capabilities. As with other SN systems, it is scheduled and configured by the NCCDS. In general, to obtain SN services, please refer to the process provided in Section 4 of this document. However, to obtain WDISC services, in particular, a customer would coordinate with the network integration group at GSFC to start the process. In coordination with the network integration group, WSC operations (which include database management, testing, trouble shooting, and scheduling) would update the PTP data, update NCCDS databases, and request NISN gateway updates as needed. After customer/WDISC testing, the customer would use the NCCDS scheduling system to get routine WDISC services.

Revision 9

Q-4

450-SNUG

Based on the WSGT and STGT schedules, the NCCDS controls the PTPs at each ground terminal for events that specify WDISC support. The MOC requests playbacks verbally or via email with WSC operations. For playbacks, a special file name (typically corresponding to a date of recording) is put in a PTP desktop and the desktop is activated manually to connect to the MOC and send data. Customer access to the WDISC is via TCP/IP connection for forward and return services. For forward services, the customer sends data via TCP/IP to the PTP at WSC. The PTP then sends that data to the WSC Local Interface (LI) via one of its PTP boards. The particular LI port to be used is identified by User Interface Channel (UIFC) ID. For return data, the PTP receives the data from the WSC LI via one of its PTP boards. It frame-syncs to the data and performs processing on it, if necessary. The data is then shipped to the customer via a TCP/IP connection. Mission-specific port numbers are assigned to each customer as required for control, as well as for data ports for forward and return services. At the current time, WDISC customers include EO-1, Swift, Fuse, Galex, Gravity ProbeB, Landsat 7, and the Solar Radiation and Climate Experiment (SORCE).

Revision 9

Q-5

450-SNUG

This page intentionally left blank.

Revision 9

Q-6

450-SNUG

Glossary
sec ACRS ADR AFN AM ANCC ASCII ASF AWGN baud rate BER BERTS BCH Bi Bi-L Bi-M Bi-S BL BM bps BPSK BRTS BSR BW microsecond Automated Conflict Resolution System achievable data rate Acquisition Failure Notification amplitude modulation Auxiliary Network Control Center American Standard Code for Information Interchange Alaska Satellite Facility Additive White Gaussian Noise rate at which a characteristic (i.e., phase, frequency, amplitude) of a carrier wave is changed by the modulating signal bit error rate bit error rate test system Bosc Chaudhuri Hocquenghem biphase biphase level biphase mark biphase space loop noise bandwidth Briefing Message bits per second binary phase shift keying Bilateration Ranging Transponder System bit slippage rate bandwidth

Revision 9

GL-1

450-SNUG

increase in the predicted customer frequency uncertainty due to the WSC software rounding off the customer receive frequency contained in the SHO ratio of carrier power-to-noise power (dB) carrier power-to-noise spectral density ratio (dB-Hz) Configuration Control Board Center Customer Commitment Manager Customer Commitment Manager Centralized Configuration Management System Configuration Change Request Communications and Control Segment Consultative Committee for Space Data Systems center frequency link subdivision used for information transfer and/or two-way range measurement 6 MHz for MA, 10 MHz for SSA, 225 MHz for KuSA, 225 MHz or 650 MHz, selectable by ground, for KaSA return links one bit of a PN sequence as opposed to data bits Communications Link Analysis and Simulation System Command Link Transmission Unit command Configuration Management Office forward service data channel commercial off-the-shelf Consolidated Space Operations Contract Customer Service Representative Compatibility Test Laboratory Compatibility Test Plan Compatibility Test Van Deputy Associate Administrator

C/N C/No CCB CCCM CCM CCMS CCR CCS CCSDS CF channel channel BW chip CLASS CLTU CMD CMO command channel COTS CSOC CSR CTL CTP CTV DAA

Revision 9

GL-2

450-SNUG

DAS data BW data channel data rate dB dBc dBi dBmi dBW dBWi DCE DCI DG1 DG2 DIS DOMSAT DQM dr DSMC DSN E

Demand Access System bandwidth in Hz equal to two times the baud rate an independent data signal contained within a link rate of a digital information data signal before convolutional encoding and/or conversion to biphase format decibel dB below total signal power decibels referenced to an isotropic radiator decibels referenced to one milliwatt isotropically received power decibel relative to one watt decibels referenced to one watt isotropically received power Doppler compensation enabled Doppler compensation inhibited Data Group 1 Data Group 2 Data Interface System Domestic Communications Satellite data quality monitoring data rate Data Service Management Center Deep Space Network maximum uncompensated Doppler on the TDRS forward link signal arriving at the customer platform (Hz); East bit energy-to-noise spectral density ratio (dB) Extended Elliptical field of view (degrees) Earth-exploration satellite services End-to-End Test effective isotropic radiated power (dBW)

Eb/No EEFOV EES EET EIRP

Revision 9

GL-3

450-SNUG

ELV ES ESC F f F1 F1, F6, F7, F8 FA fd FDF FEC FM fo forward service FOV FR fref fT FTP G G/T G 1, G2, G3 GCE GCM GCMR GDIS GHz GMT

expendable launch vehicle earth station Exploration and Space Communications transmit carrier frequency (Hz) frequency (Hz) carrier frequency transmitted by the customer platform (Hz) TDRS Flight 1, 6, 7, 8 Forecast Analyst (NCCDS) Doppler frequency Flight Dynamics Facility forward error correction frequency modulation nominal center frequency of customer platform receiver (Hz) link from the WSC through the TDRS to the customer platform field of view (degrees) carrier frequency arriving at user spacecraft (Hz) user spacecraft transmit frequency (Hz) TDRSS forward service transmit frequency after Doppler compensation File Transfer Protocol gain antenna gain-to-noise temperature ratio (dB/K) symbol generation functions ground control equipment Ground Control Message Ground Control Message Request Guam Data Interface System gigahertz Greenwich Mean Time

Revision 9

GL-4

450-SNUG

GN GPR GRGT GRS GSAMS GSFC GT Gu HPA HR HRDS HRS Hz I channel ICD IF IFL IIRV IONet IP IRAC ISS ITU ITU-R jerk JPL

Ground Network Goddard Procedural Requirements Guam Remote Ground Terminal (the WSC ground terminal located in Guam) Guam Remote Station GSFC Spectrum Allocation and Management Site Goddard Space Flight Center Ground Terminal antenna gain of the customer platform (dB) high power amplifier high rate High Rate Data System High Rate Switch Hertz data channel supported by 0 degree and 180 degree phase modulation of the reference carrier Interface Control Document intermediate frequency interfacility link improved interrange vector IP Operational Network internet protocol Interdepartmental Radio Advisory Committee (part of the NTIA) International Space Station International Telecommunications Union International Telecommunications Union Radiocommunication Sector rate of change of range acceleration between TDRS and 3 customer platform (meter/second ) Jet Propulsion Laboratory

Revision 9

GL-5

450-SNUG

JSC JVM k K Ka-band KaSA KaSAF KaSAR K-band kbps kHz km KSC KuSA KuSAF KuSAR LAN LCP LDPCC LEO LEOFOV LHC LI link

Johnson Space Center Java Virtual Machine Boltzmann's constant, -228.6 dBW/Hz-K; constraint length of convolutional code Kelvin, unit of temperature 22.5 to 27.5 GHz Ka-band Single Access Ka-band Single Access Forward Ka-band Single Access Return 13.40 to 15.25 GHz kilobits per second kilohertz kilometer Kennedy Space Center Ku-band Single Access Ku-band Single Access Forward Ku-band Single Access Return local area network left circular polarization Load Density Parity Check Conversion Low Earth Orbit low earth orbit field of view (degrees) left-hand circular local interface Includes either all data and/or range channels provided by a TDRS forward or return service to a customer platform. In the case of SA service, a link is defined relative to a specific antenna on a particular TDRS. In the case of MA service, a link is defined relative to a particular TDRS. line-of-sight

LOS

Revision 9

GL-6

450-SNUG

LR LRS MA MAF MAR Mbps MCC MDM MGS MHz MI MIL MILA MOC MORR MSB msec MSP Msps MTRS N NA NAM NASA NASCOM NCC NCCDS NEC NES

low rate Low Rate Switch Multiple Access Multiple Access Forward Multiple Access Return megabits per second Mission Control Center multiplexer/demultiplexer McMurdo Ground Station megahertz mutual interference Merritt Island Tracking Station Merritt Island Launch Annex Mission Operations Center Mission Operations Readiness Reviews most significant bit millisecond Mission Services Program megasymbols per second McMurdo TDRSS Relay System North not applicable Network Advisory Message National Aeronautics and Space Administration NASA Communications Network Network Control Center NCC Data System NASCOM Event Cancel NASCOM Event Schedule

Revision 9

GL-7

450-SNUG

NEST NIC NIM NIMO NISN NOM NOSP NPAS NPG NRR NRZ NRZ-L NRZ-M NRZ-S nsec NSF NTIA OBO ODM OIP OPM OOTMS OPS OQPSK Pacq PCD PCI PCM

NISN/NASA Event Scheduling Terminal Network Integration Center Network Integration Manager Network Integration Management Office NASA Integrated Services Network Network Operations Manager Network Operations Support Plan Network Planning and Analysis System NCC Protocol Gateway NASCOM Reconfiguration Request; Network Requirements Review nonreturn to zero nonreturn to zero level nonreturn to zero mark nonreturn to zero space nanosecond National Science Foundation National Telecommunications and Information Agency Output Back-Off Operations Data Message (from GTs to NCCDS) Operations Interface Procedures Operations Message On orbit test mode system operations Offset quadriphase shift keying probability of correct acquisition Project Commitment Document periodic convolutional interleaving Pulse code modulated

Revision 9

GL-8

450-SNUG

PDL PFD PFOV PIP PM PN POCC PP PRD Prec Ps PSD PSK PSLA PTE PTP Q channel QPSK
& R
&& R

Ponce de Leon Tracking Station power flux density Primary field of view (degrees) Payload Integration Plan phase modulation pseudorandom noise Payload Operations Control Center peak-to-peak Program Requirements Document signal power received isotropically at a TDRS from a customer platform signal power at antenna output power spectral density phase-shift keying; phase-shift key modulation using differential encoded data Project Service Level Agreement Performance Test Equipment Programmable Telemetry Processor data channel supported by +90 degree phase modulation of the reference carrier quadriphase shift keying range velocity between a TDRS and the customer platform (meter/second) range acceleration between a TDRS and the customer platform (meter/second2) jerk (m/sec3) ratio between data rate and convolutionally encoded symbol rate; range between TDRS and customer platform (meters) forward service channel used for transferring the PN code used for two-way range measurement right circular polarization

K R
R range channel RCP

Revision 9

GL-9

450-SNUG

RCTD Rd return service RF RFI RFSOC RHC rms RR Rs R-S Rx S S/(N+I) S/No SA SAR SATb SATd S-band SD SDIF sec service SFCG SFDU SGL

return channel time delay channel data rate (b/sec) link from the customer platform through the TDRS to the WSC radio frequency radio frequency interference Radio Frequency Simulation Operations Center right-hand circular root mean square Radio Regulations channel symbol rate Reed-Solomon receiver South signal-to-(noise plus interference) ratio signal-to-noise density ratio (dB-Hz) Single Access Synthetic Aperture Radar; Schedule Add Request forward buffering delay for reserialized output data delivery return buffering delay for reserialized output data delivery 2000 to 2300 MHz sweep duration SWSI-DAS Interface second consists of any of the forward, return, tracking, simulation, or verification services Space Frequency Coordination Group Standard Formatted Data Unit Space-Ground Link

Revision 9

GL-10

450-SNUG

SGLT SHO SIC SIEB Signal EIRP

Space-Ground Link Terminal Schedule Order (NCCDS to GTs) Support Identification Code Security Impact Evaluation Board total EIRP + Lp + Lt (dBW) where: Lp = loss resulting from imperfect antenna pointing (dB) (Lp <0 dB) Lt = all tandem link losses including power robbing caused by noise and spurious signals (dB) (Lt <0 dB)

SLE SLR SMA SMAF SMAR SN SNAS SNIF SNIP SNR SO

Space Link Extension Service Level Report S-band Multiple Access S-band Multiple Access Forward S-band Multiple Access Return Space Network Space Network Access System SWSI-NCCDS Interface Space Network Interoperability Program signal-to-noise ratio spurious outputs; Scheduling Operator (NCCDS); space operations

SOC SORCE SPSR SPTR SQPN SQPN modulation

Simulation Operations Center Solar Radiation and Climate Experiment Service Planning Segment Replacement South Pole TDRSS Relay Staggered quadriphase pseudorandom noise a modulation process in which the phase of the PN clock modulating the Q channel is delayed 1/2 chip relative to the phase of the PN clock modulating the I channel

Revision 9

GL-11

450-SNUG

SQPSK SQPSK modulation

staggered quadriphase shift keying a quadriphase process in which the data bits (symbols if convolutionally encoded) of the Q channel are delayed one-half bit period (one-half symbol period if convolutionally encoded) relative to the I channel space research; sweep range Schedule Result Message S-band Single Access S-band Single Access Forward S-band Single Access Return Spread Spectrum binary phase shift keying service specification code statistical multiplexer Spaceflight Tracking and Data Network Second TDRSS Ground Terminal Space Transportation System (Space Shuttle) support identifier SN Web Services Interface rate of the digital information data signal before conversion to biphase format. When convolutional encoding is used, the rate of the digital information data signal out of the convolutional encoder before conversion to biphase format. original information bits appear in output data stream antenna temperature (K) time to acquire transmission control protocol TDRS-East (same as TDRS-E) time division multiplexing; Tracking Data Message Tracking and Data Relay Satellite

SR SRM SSA SSAF SSAR SS-BPSK SSC STAT MUX STDN STGT STS SUPIDEN SWSI symbol rate

systematic Ta Tacq TCP TDE TDM TDRS

Revision 9

GL-12

450-SNUG

TDRS-E TDRSS TDRS-W TDRS-Z Ti TILT TLAS TLM TOCC TPC TR TR transparent

TDRS-East (same as TDE) Tracking and Data Relay Satellite System TDRS-West (same as TDW) TDRS in Zone of Exclusion (same as TDZ) noise temperature contribution due to interference from other multiple access users (K) TDRSS Internet Link Terminal TDRS Look Angle System telemetry TDRSS Operations Control Center Turbo Product Code time return service begins Test Report I(b) the input to the encoder is mapped into T(b) the output of the encoder, then for transparency to exist, the complement of I(b) must be mapped into the complement of T(b) Test Readiness Review receiving system noise temperature (K) referenced to the antenna output terminals TDRSS Scheduling Window tracking, telemetry, and command TDRSS User RF Test Set TDRSS Unscheduled Time Traveling Wave Tube Amplifier transmitter User Datagram Protocol User Performance Data (from NCCDS to MOC) User Planning System unbalanced quadriphase shift keying User Spacecraft Clock Calibration System

TRR Ts TSW TT&C TURFTS TUT TWTA Tx UDP UPD UPS UQPSK USCCS

Revision 9

GL-13

450-SNUG

USM UTC VCDU VIC VID VOIP W WAN WART WDISC WSC WSGT www ZOE

User Schedule Message (from NCCDS to MOC) Universal Time Coordinated Virtual Channel Data Units Vehicle Identification Code Vehicle Identification Voice Over Internet Protocol West wide area network WSC Alternate Relay Terminal WSC Data Interface Service Capability White Sands Complex (consists of WSGT and STGT) White Sands Ground Terminal world wide web zone of exclusion

Revision 9

GL-14

450-SNUG