UNCLASSIFIED
NTP 2 SECTION 3 (B)
NAVAL TELECOMMUNICATIONS PROCEDURES NAVY EXTREMELY HIGH FREQUENCY SATELLITE COMMUNICATIONS
NTP 2 SECTION 3 (B) NAVAL SPACE COMMAND 5280 FOURTH STREET DAHLGREN, VA 22448-5300
DISTRIBUTION AUTHORIZED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS (ADMINISTRATIVE OR OPERATIONAL USE): July 2000. OTHER REQUESTS FOR THIS DOCUMENT SHALL BE REFERRED TO COMMANDER, NAVAL SPACE COMMAND, DAHLGREN, VA 22448-5300
MARCH 2001
THIS PUBLICATION CONTAINS U.S. MILITARY INFORMATION AND RELEASE TO OTHER THAN U.S. MILITARY AGENCIES WILL BE ON A NEED-TO-KNOW BASIS.
UNCLASSIFIED
ORIGINAL
NTP 2 SECTION 3 (B) 29 March 2001
FOREWORD
1. Naval Telecommunications Procedures (NTP) 2, Section 3 (B) Navy Extremely High Frequency Satellite Communications is an unclassified procedure publication published 29 March 2001. 2. This NTP may be carried in aircraft. There are no specific requirements for storage or safeguarding of this publication, or accounting for loss or compromise beyond those associated with any official, unclassified naval publication. 3.
Extracts from this NTP are permitted.
4.
This publication contains military information and is furnished for official purposes only.
ORIGINAL II
NTP 2 SECTION 3 (B) DEPARTMENT OF THE NAVY NAVAL SPACE COMMAND 5280 FOURTH STREET DAHLGREN, VA 22448-5300 IN REPLY REFER TO
29 MAR 2001
LETTER OF PROMULGATION 1. This publication is designed to provide information and guidance relative to employment of EHF satellite communications for naval operations. The procedures established herein are applicable for all elements concerned with management, control, utilization, testing, and operation of naval EHF satellite communications resources. 2. NTP 2, Section 3 (B) is an unclassified, non-registered publication. It is EFFECTIVE UPON RECEIPT, and supersedes NTP 2,Section 3 (A). 3. Comments or recommendations concerning this publication should be addressed, via the normal military chain of command, to the Commander, Naval Space Command (Code N52), 5280 Fourth Street, Dahlgren, VA 22448-5300. The last page of this document is a Feedback Report form that may be duplicated and used for providing comments. Feedback reports may also be submitted via electronic mail to the following address:
[email protected]
A. A. EFRAIMSON By direction
ORIGINAL III
NTP 2 SECTION 3 (B) RECORD OF CHANGES AND CORRECTIONS Enter Change or Correction in Appropriate Column
Identification of Change or Correction; Reg. No. (if any) and date of same
Change
Date Entered
By whom entered (Signature; rank; grade or rate; name of command)
Correction
ORIGINAL IV
NTP 2 SECTION 3 (B)
Identification of Change or Correction; Reg. No. (if any) and date of same
Change
Date Entered
By whom entered (Signature; rank; grade or rate; name of command)
Correction
ORIGINAL V
NTP 2 SECTION 3 (B) TABLE OF CONTENTS Title Page ................................................................................................................................
I
Foreword ................................................................................................................................
II
Letter of Promulgation ...........................................................................................................
III
Record of Changes and Corrections .......................................................................................
IV
Table of Contents ...................................................................................................................
VI
CHAPTER CHAPTER 1 101 102 103 104 105 106 CHAPTER 2 201 202 203 204 205 CHAPTER 3 301 302 303 304 CHAPTER 4 401 402
PAGE INTRODUCTION Purpose ............................................................................................... Scope .................................................................................................. Direction ............................................................................................. Background ........................................................................................ Evolving Applications ........................................................................ Related Documents ............................................................................
1-1 1-1 1-1 1-5 1-6 1-8
SYSTEM DESCRIPTION General ............................................................................................... 2-1 EHF Space Segment ............................................................................ 2-1 EHF Earth Segment ............................................................................. 2-15 EHF Baseband Systems........................................................................ 2-28 EHF Communications Enhancements.................................................. 2-35 EHF SATCOM CONTROL General ............................................................................................... Authority ............................................................................................. Responsibilities for Management and Control .................................... System Control ...................................................................................
3-1 3-2 3-2 3-2
EHF SERVICES AND ACCESS General ................................................................................................ EHF MILSATCOM Services ..............................................................
4-1 4-1
ORIGINAL VI
NTP 2 SECTION 3 (B) 403 404 405 406 407 408 CHAPTER 5 501 502 503 504
EHF Initial Terminal Setup and Satellite Acquisition ......................... Establishing EHF Services ................................................................... Priority Structure .................................................................................. Key Management ................................................................................. TRANSEC Key User Procedures ........................................................ EHF Satellite Access Request (SAR) Process .....................................
4-3 4-7 4-12 4-12 4-18 4-22
ADMINISTRATIVE PROCEDURES General ............................................................................................... Requirements Planning ....................................................................... Reporting Requirements ...................................................................... Operational Training ...........................................................................
5-1 5-1 5-4 5-8
ANNEXES
PAGE
ANNEX A ANNEX B
ACRONYMS ..................................................................................... A-1 GLOSSARY ....................................................................................... B-1
FIGURES
PAGE
1-1 EHF SATCOM Command Relationships ..................................................................... 1-2 Pillars of the Copernicus Architecture ...........................................................................
1-2 1-7
2-1 2-2 2-3 2-4 2-5
FEP Antenna Coverage Areas ......................................................................................... 2-3 UFO/E and UFO/EE Antenna Coverage Areas .............................................................. 2-5 Milstar I Satellite Antenna Coverage Areas.................................................................... 2-12 AN/USC-38(V) Terminal Components .......................................................................... 2-17 AN/TSC-154 SMART-T................................................................................................. 2-27
3-1 3-2 3-3 3-4 3-5
UFO/E & UFO/EE Management and Control Organization ......................................... 3-6 UFO Control Segment .................................................................................................... 3-8 EHF Control Functions and Architectures ..................................................................... 3-9 EHF Uplink and SHF Downlink Services....................................................................... 3-13 Milstar Management and Control Organization ............................................................. 3-19
4-1 NESP Terminal Data Flow..............................................................................................
4-6
5-1 SATCOM Requirements Flow .......................................................................................
5-2
ORIGINAL VII
NTP 2 SECTION 3 (B) TABLES 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8
PAGE
Summary of FEP System Capabilities ............................................................................ Summary of UFO/E & UFO/EE System Capabilities..................................................... Summary of Interim PEP System Capabilities................................................................ Summary of Milstar System Capabilities........................................................................ Navy EHF LDR Terminal Comparisons ......................................................................... Summary of EHF Terminal Comparisons....................................................................... Precedence Level Conventions ....................................................................................... Access Control Allowed by Privilege .............................................................................
2-3 2-5 2-7 2-13 2-23 2-25 2-28 2-29
3-1 EHF Payload Operation Commands .............................................................................. 3-11 3-2 UFO/E TT&C Modes ..................................................................................................... 3-13 3-3 UFO Support Commands ............................................................................................... 3-14 4-1 EHF System Comparisons............................................................................................... 4-4 4-2 SATCOM User Priority Structure................................................................................... 4-13
ORIGINAL VIII
NTP 2 SECTION 3 (B) CHAPTER 1 INTRODUCTION
101. PURPOSE The purpose of this section of Naval Telecommunications Procedures 2 (NTP 2) is to promulgate information concerning direction, management, and control of Navy extremely high frequency (EHF) satellite communications (SATCOM) systems. EHF systems support strategiclevel command and control (C2) functions, nuclear forces, and tactical mobile forces. The EHF waveform provides a means for highly robust, highly secure, and survivable communications among fixed-site, mobile, and man-portable terminals. EHF systems offer more terminal mobility, higher antijam (AJ) capability, and low probability of detection (LPD)/low probability of intercept (LPI)/low probability of exploitation (LPE). The higher frequencies utilized by EHF systems enable terminal antenna designs to be small, yet still provide a high gain using a very reasonable amount of radio frequency (RF) power. This section of NTP 2 is applicable to surface ships, submarines, airborne, and ashore subscribers of EHF SATCOM systems. The information presented will provide the user with the planning guidance needed to employ EHF SATCOM resources in the fleet. It is anticipated that modifications to this document will be required based on feedback reports as fleet users continue to gain experience with EHF SATCOM. 102. SCOPE This section of NTP 2 applies to naval staff planners at all echelons and to the supervisors of EHF terminal operators. It is intended to complement existing directives, publications, and other NTPs. EHF SATCOM procedural changes promulgated as Fleet Telecommunications Procedures (FTP) or Communications Information Bulletins (CIB)/Communications Information Advisories (CIA), which modify information contained herein, will be reflected in subsequent revisions to this document as appropriate. Sections 1 and 4 of NTP 2 provide planning information for naval super high frequency (SHF) and commercial SATCOM operations, respectively. Section 2, which described ultra high frequency (UHF) SATCOM operations, has been superseded by the Joint UHF Military Satellite Communications (MILSATCOM) Management Manual promulgated by the U.S. Space Command (USSPACECOM). 103. DIRECTION The EHF SATCOM system is a collective resource of the Department of Defense (DOD), which is managed and operated as a joint asset in accordance with priorities established in Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6250.01. This CJCSI prescribes MILSATCOM systems management responsibilities, provides a source for CJCS MILSATCOM policy, and amplifies the requirement process. The command relationships for EHF SATCOM operations are illustrated in figure 1-1 and described in the remainder of this paragraph.
ORIGINAL 1-1
NTP 2 SECTION 3 (B) A. Chairman of the Joint Chiefs of Staff (CJCS). The CJCS apportions SATCOM resources, including those assets used in military operations, to satisfy national defense requirements and specifies operational procedures and responsibilities for system managers, operators, and users. The CJCS recommends to the Secretary of Defense (SECDEF) those actions required for shared use of SATCOM assets and services, and reviews proposed cooperative agreements between DOD and other agencies or governments relative to shared use. The Joint Staff defines the process for SATCOM requirement documentation, reviews and
NCA PRESIDENT
SECDEF
CJCS
DIR DISA
U&S COMMANDS OTHER U&S
USCINCSPACE
CNO
CMC
CINCs
FLTCINCs and
COMNAVSPACECOM
COMNAVCOMTELCOM
CG, FMFs NAVSOC CO, NCTAMS LEGEND COMMAND COORDINATION
Figure 1-1 EHF SATCOM Command Relationships approves user connectivity requirements for the EHF SATCOM system via the process delineated in CJCSI 6250.01, apportions EHF communications resources to Unified Commanders in Chief (CINC) and other selected users, and approves the positioning and repositioning of EHF satellites. Under the direction of the Joint Staff, the Joint Communications Satellite Center (JCSC) acts as the focal point for monitoring, coordinating, and formulating actions requiring CJCS approval for all SATCOM tactical and contingency operational access. JCSC manages the requirement, validation, and approval process, resolves resource apportionment conflicts among the CINC/agency users, and performs other duties as discussed in CJCSI 6250.01. ORIGINAL 1-2
NTP 2 SECTION 3 (B) B. Defense Information Systems Agency (DISA). This agency is the DOD-designated manager of the Defense Information Systems Network (DISN). DISA designs, engineers, and develops the DISN to satisfy validated requirements. DISA has overall responsibility for planning, developing, and supporting command, control, communications, computers, and intelligence (C4I) systems that serve the needs of the National Command Authorities (NCA). DISA is subject to the direction, authority, and control of the Assistant Secretary of Defense for Command, Control, Communications and Intelligence (ASD[C3I]), but is responsible to the CJCS for operational matters, as well as requirements associated with the joint planning process. For these purposes, the CJCS is authorized to communicate directly with the Director, DISA and may task the Director, DISA to the extent authorized by the ASD(C3I). In support of the Joint Staff, DISA manages the Integrated Communications Database (ICDB), the consolidated requirements database for all SATCOM connectivity. All requirements for EHF resources are validated by the respective theater CINC, approved by the Joint Staff, and documented and maintained in the ICDB. C. Commander in Chief, U.S. Space Command (USCINCSPACE). USCINCSPACE serves as a principal advocate and advisor to the CJCS for SATCOM systems that support CINC operational requirements. USCINCSPACE is a unified commander responsible for identifying and quantifying emergent SATCOM requirements to the DOD Space Architect. USCINCSPACE also serves as the SATCOM Operational Manager (SOM) for the day-to-day management of all operational SATCOM resources DOD-wide. The SOM develops and implements standards, policy, and procedures for all DOD SATCOM systems, as well as designates the SATCOM System Experts (SSE) that provide an integrated staff and SATCOM management support infrastructure. USCINCSPACE executes EHF SATCOM system responsibilities through two of its component commands, the Naval Space Command (NAVSPACECOM) and the Air Force Space Command (AFSPC). Space assessments are also a responsibility of USCINCSPACE in support of the Joint Staff. D. Chief of Naval Operations (CNO). The CNO is the Program Manager for the Navy’s SATCOM program. Acting for Department of the Navy (DON), the CNO approves and directs the implementation of the Navy’s SATCOM programs, including the implementation of the Navy EHF SATCOM Program (NESP). Within CNO, the Director, Space, Information Warfare, Command and Control (N6) has overall responsibility for planning, directing, and sponsoring NESP through the budgetary process. The Director, Information Transfer Division (N61) provides policy for operation, maintenance, and management of the Naval Computer and Telecommunications System (NCTS). CNO N61 sponsors and authorizes development and procurement of general communications equipment, and determines personnel and training requirements for communications systems. The Director, Navy Space Systems Division (N63) is responsible for program coordination and acquisition of space systems. CNO N63 oversees the functions of development, procurement, installation, operation, and logistical support for NESP space and control segments. CNO N63 also assesses future SATCOM concepts, policies, and applications and coordinates NESP system requirements with the Joint Staff, the other military Services, and DISA. ORIGINAL 1-3
NTP 2 SECTION 3 (B) E. Commandant of the Marine Corps (CMC). CMC approves and directs implementation and usage of SATCOM resources assigned to the Marine Corps. Within Headquarters, Marine Corps (HQMC), the Assistant Chief of Staff, Command, Control, Communications, Computers, Intelligence, and Interoperability is tasked with the overall responsibility for management and oversight of Marine Corps SATCOM requirements. 1. The Commanding General, Marine Corps Combat Development Center (CG, MCCDC) approves and submits nonoperational Marine Corps Force requirements (e.g., training, testing, etc.) for SATCOM support to HQMC for further processing. 2. The Commanding General, Marine Corps Systems Command is responsible for the acquisition of Marine Corps SATCOM terminals, including the required logistics support. F. Unified Commanders. These warfighting combatant commanders (COCOM) are assigned either geographic or functional areas of responsibility. They are responsible to the CJCS for the preparation of war plans. These CINCs consolidate and prioritize all SATCOM requirements (including requirements of components and supporting CINCs or commands) that support validated war plans and assigned missions at all levels of conflict within their area or responsibility (AOR). G. Fleet Commanders in Chief (FLTCINC). FLTCINCs define their requirements and submit them via the supported CINC to the CJCS for approval. FLTCINCs manage assigned EHF SATCOM assets and those allocated to other naval users in their assigned area. They exercise operational direction over assigned EHF SATCOM assets through their supporting Naval Computer and Telecommunications Area Master Station (NCTAMS) and prepare EHF SATCOM communications plans (COMMPLAN) in support of CINC and Commander, Joint Task Force (CJTF) operations plans. H. Commander, Marine Corps Forces Atlantic/Pacific (COMARFORLANT/ COMARFORPAC). These commanders define their satellite requirements for operations and submit them to the operational commander for further processing. Nonoperational requirements are submitted to CG, MCCDC for approval and further processing by HQMC and the Joint Staff. I. Commander, Naval Space Command (COMNAVSPACECOM). This commander exercises command authority over subordinate activities as assigned by CNO, and has been designated by USCINCSPACE as the SSE for the Fleet Satellite (FLTSAT) with EHF Package (FEP), UHF Follow-on (UFO) with EHF Package (UFO/E), UFO/E with Enhanced EHF Package (UFO/EE), and Polar EHF Package (PEP) satellite systems. COMNAVSPACECOM coordinates with DISA and Commander, Naval Computer and Telecommunications Command (COMNAVCOMTELCOM) concerning naval SATCOM requirements, present and future, when directed by the CNO. COMNAVSPACECOM is also the Naval component commander under USCINCSPACE.
ORIGINAL 1-4
NTP 2 SECTION 3 (B) J. NAVSOC. As a component of NAVSPACECOM, NAVSOC executes day-to-day satellite control procedures and directs all FEP, UFO/E, UFO/EE, and PEP satellite anomaly resolutions. NAVSOC directs the use of, and operates and maintains, EHF control terminals on Guam, at Schriever AFB, CO, and in Maine, and operates a Transportable Operations Center (TOC) for contingency use in the event of a major control site failure. NAVSOC operates the Navy Terminal Data Node (NTDN), which collects, formats, and distributes satellite adaptation and ephemeris (A&E) data to Navy EHF terminals, as well as to central Army and Air Force EHF terminal data nodes. NAVSOC also acts as the Controlling Authority (CA) for the FEP, UFO/E, UFO/EE, and PEP transmission security (TRANSEC) cryptographic keys that are required by all user EHF terminals, and directs the upload of new key segment variables to satellite TRANSEC devices. K. COMNAVCOMTELCOM. This commander exercises command authority over the Naval Computer and Telecommunications Command. COMNAVCOMTELCOM operates the Earth segment of the NCTS within assigned parameters and in accordance with prescribed procedures. COMNAVCOMTELCOM serves as the administrative commander for the NCTAMS. L. Commanding Officer, NCTAMS. Under the authoritative direction and control of the respective CINC and FLTCINC, each NCTAMS maintains for COMNAVCOMTELCOM the operational direction and management control of assigned NCTS assets. In addition, unified Network Operations Centers (NOC) and Joint Fleet Telecommunications Operations Centers (JFTOC) have been established within the NCTAMS for each region. This supports a streamlined C4I infrastructure since the unified NOC will be responsible for providing seamless telecommunications support to joint/fleet forces. NCTAMS personnel act on behalf of the FLTCINCs to manage allocated EHF SATCOM resources. 104. BACKGROUND From the early 1900s, the Navy relied on high frequency (HF) radio as the principal transmission medium for long-distance communications. This situation began to change in 1963 when the Navy installed and tested SATCOM terminals aboard selected platforms in support of North Atlantic Treaty Organization (NATO) requirements at shore sites and on flagships. The combination of UHF and SHF SATCOM provided the Navy and Marine Corps ashore and afloat with reliable, rapid and increased capacity communications with a limited AJ capability. EHF SATCOM, the latest generation SATCOM system, provides worldwide, jam-resistant, LPI/LPD, and enduring capability. EHF SATCOM provides the Services with interoperable, survivable communications. The system consists of a satellite segment, terminal segment, and control segment. The satellite and control segments combine four satellite systems: FEP (hosted on FLTSATs 7 and 8); UFO/E (hosted on UHF Follow-on [UFO] 4 through 6) and UFO/EE (hosted on UFOs 7 through 10); Interim PEP (carried on a classified-host satellite); and Milstar. The terminal segment includes Navy, Army, and Air Force terminals and associated baseband equipment. These systems use a combination of directional antennas and advanced signal processing techniques to significantly improve AJ and LPI/LPD performance over existing ORIGINAL 1-5
NTP 2 SECTION 3 (B) SATCOM systems. The Navy uses EHF SATCOM systems to supplement, not replace, existing communication systems in providing strategic, tactical, and contingency voice, teletype, and data links for naval operations during peacetime and in wartime. 105. EVOLVING APPLICATIONS The escalating requirement to provide near-real-time information and survivable communications to afloat commanders has necessitated a realignment of the means available to satisfy naval circuit requirements. The Navy EHF program is being refined to meet these needs. A. Copernicus Architecture. The Copernicus Architecture involves a major restructuring of Navy command, control, computers, communications, intelligence, surveillance, and reconnaissance (C4ISR) to put the warfighter at the center of the command and control (C2) universe by providing the supporting information needed, when it is required. The Advanced Automated Tactical Communications strategy (formerly the Joint Maritime Communications Strategy [JMCOMS] program) provides the technical and implementation strategy for the communications portion of Copernicus. Its technical thrusts are designed to introduce systems that facilitate the transfer of voice, video, and data to efficiently disseminate information that is required by joint task force (JTF) and joint task group (JTG) commanders in a format that can readily be used. The major components of Copernicus are the CINC Command Complexes (CCC) ashore, the Tactical Command Centers (TCC) afloat, the Global Information Exchange Systems (GLOBIXS), Tactical Data Information Exchange Systems (TADIXS), and Battle Cube Information Exchange Systems (BCIXS). The Navy SATCOM architecture supports Copernicus by providing the transport medium for the TADIXS and BCIXS networks. The Automated Digital Networking System (ADNS) is the primary Advanced Automated Tactical Communications technical thrust for enhancing and integrating the Navy’s SATCOM assets into the Copernicus Architecture. Figure 1-2 illustrates the major components (pillars) of the Copernicus Architecture. 1. TADIXS. These are not physical nets, but rather virtual nets established at the request of, and in the mix desired by, the tactical commander. This operational flexibility is at the heart of the Copernican philosophy of placing the operator at the center of the information universe. Technologically, this is accomplished by addressing data packets across the GLOBIXS, over the CCC metropolitan/local area network, and onward via the TADIXS to the TCC for assimilation and further dissemination via BCIXS networks as required. The ADNS will provide automated communications media management during this process. 2. ADNS. ADNS is a communications subarchitecture that enhances battle force communications connectivity, flexibility, and survivability through multimedia access and media sharing. An ADNS connection plan will automatically control user interfaces, routing functions, and other resources to permit users to share total network capacity on a priority demand basis. The ADNS connection plan will automatically implement the theater, force, and group COMMPLANs. In addition, automated network monitoring and management capabilities will be
ORIGINAL 1-6
NTP 2 SECTION 3 (B) provided to assist operators in the real-time allocation of communications resources according to selected criteria (e.g., suitability, AJ, priority, etc.). GLOBIXS
BCIXS
TADIXS
TADIL NETS USWC SIGINT USW C2W COMMAND IMAGERY
OTHER SERVICE
NAVY
COMMAND FORCE OPERATIONS
JIC CSG USW BMC C2 CENTER
SHOOTERS
DIRECT TARGETING AMPHIB SUPPORT
CWC SUWC
CCC ASHORE INFORMATION MANAGEMENT
AWC
C2WC STWC
TCC AFLOAT INFORMATION MANAGEMENT
TACTICAL INFORMATION MANAGEMENT
Figure 1-2 Pillars of the Copernicus Architecture B. Milstar Medium Data Rate (MDR). The MDR upgrade to Milstar will provide EHF communications capability for data rates from 4.8 kilobits per second (kbps) to 1.544 megabits per second (Mbps). MDR is a result of a restructured Milstar program in which AJ and survivability features are de-emphasized in favor of enhanced throughput and increased tactical utility. MDR enhancements will provide greatly increased utility for tactical force, core communication requirements through higher data rates; an increased quantity of steerable antennas; and in some cases, new terminal antennas. The following are proposed MDR throughputs that will be supported on Navy platforms: •
Aircraft carriers and flag-configured ships: 256 kbps
•
Other ships: 128 kbps
•
Submarines: 128 kbps
ORIGINAL 1-7
NTP 2 SECTION 3 (B) •
Major shore terminals (i.e., NCTAMS): 1.544 Mbps
•
Other shore terminals: 256 kbps.
MDR capability will be available when the Milstar II satellites become operational. These satellites will be capable of accommodating 600 or more user links, and the full constellation will accommodate at least 2400 user terminals simultaneously. A thorough description of the enhancements provided by Milstar MDR is provided in Chapter 2. C. Information Technology for the 21st Century (IT-21). IT-21 is an initiative that is intended to revolutionize the Navy’s vision for conducting operations in the 21st century. By changing how information technology is used, the Navy will transform how it is staffed, organized, and equipped for future conflicts. As IT-21 is currently envisioned, virtually all information transfer within the Navy will be accomplished using personal computers (PC), which enable users to access video, data, and voice with the simple click of a mouse button. 1. The IT-21 objective is to build to industry standards a system that maximizes the use of COTS technology, is devoid of stovepipe legacy systems, and allows the integration of tactical and nontactical uses. Information systems, including all PCs, software, network technology, and the larger servers that support communications networks, will be implemented to meet this vision. Applications would be connected to a Windows NT-based PC in a client-server environment, using off-the-shelf software, such as MS Office. The only exception would be in those rare instances where there is an overwhelming reason to use a high-end UNIX workstation. 2. IT-21 will move databases ashore and allow afloat users to pull only that information that they need in such a way that it is seamless to the requester. The removal of expensive and burdensome legacy systems will have the added benefit of reducing afloat staffing because many functions will be accomplished electronically or remotely from shore installations. As an example, most ships would no longer be required to deploy with personnel departments because those functions would be performed at a central facility ashore; likewise, logistics support could be lessened as technology allows for greater communication of maintenance problems, and spare parts inventories could be reduced. 3. The connectivity used to tie IT-21 together relies on the maximum use of SATCOM, which will be used to form one large wide-area network (WAN) backbone. Most of the large-scale communications support for this system already exists; it needs only to be reconfigured. The intent is to utilize the existing SATCOM system networks by reconfiguring them from their present stovepipe architectures and making them accept transmission control protocol/internet protocol (TCP/IP) data from a variety of applications. 106. RELATED DOCUMENTS The following documents provide guidance or assistance in the utilization of EHF SATCOM systems: ORIGINAL 1-8
NTP 2 SECTION 3 (B) A. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6250.01 Satellite Systems, (dated 20 October 1998). This instruction updates and supersedes operational policy and procedures previously described in CJCS Memorandum of Policy No. 37 (MOP 37), and provides new guidance on SATCOM systems. This instruction provides high-level operational policy, guidance, and procedures for the planning, management, employment, and use of DOD SATCOM resources. The principal purpose of this instruction is to define the processes necessary to ensure essential SATCOM support for warfighter mission accomplishment. B. Naval EHF Medium Data Rate (MDR) Concept of Operations (CONOPS), (dated 30 December 1999). This HQ NAVSPACECOM CONOPS provides information on how the Navy will use the forthcoming EHF MDR system to satisfy their core warfighting voice, video, and data requirements. C. Memorandum, Joint Chiefs of Staff (MJCS)-170-87, MILSATCOM Deliberate Planning (dated 2 October 1987). This memorandum outlines the process used to capture and validate MILSATCOM requirements, apportion resources, and assign accesses that support a joint commander’s communications requirements. D. MJCS-74-85, Charter for the JCSC (dated 4 March 1985). This memorandum establishes the JCSC and defines its role in the MILSATCOM requirements validation, resource apportionment, and access assignment/adjudication processes. E. CJCS Emergency Action Plan (EAP) Volume VII (TOP SECRET, dated 1 October 1994). This document defines actions that must be taken to support CJCS strategic communications requirements during crisis/contingency operations. F. Interim Polar EHF System Control and Operations Concept (SCOC), (dated March 1997). This SCOC describes the operational concept for Interim Polar EHF system control, defines the operational capacity of the system, and provides system policies and procedures for resource management and user resource employment. It also defines jam-resistant connectivity and LPI/LPD protection features for users operating in the polar region. G. ICDB. This database is administered by DISA under direction of the CJCS. It serves as the central database in the DISA Telecommunications Management System-Classified (TMSC) and is the single source of validated DOD telecommunications requirements supported by SATCOM communications media. Milstar requirements formerly in the Joint Milstar Communications Control and Operations Concept (JMCCOC) Volume I are now in the ICDB. ICDB submissions are addressed in chapter 5. H. Satellite Communications Support Center Concept of Operations (CONOPS), (dated 19 November 1999). This HQ USSPACECOM document outlines the roles and responsibilities of the SATCOM Support Centers (SSC) in the operational management of DOD satellite resources, and describes the key relationships with other elements of the SATCOM ORIGINAL 1-9
NTP 2 SECTION 3 (B) operational management community, such as the unified COCOMs, the USSPACECOM SOM, component command SSEs, et al. It defines specific details regarding SATCOM facilities, locations, manning, training, and management requirements. I. Capstone Requirements Document (CRD). This document was developed by USSPACECOM to provide a consolidated set of SATCOM requirements and to identify the technological options that are available to construct an objective DOD architecture. Doctrine, CONOPS, forces, threats, mission needs statements (MNS)/operations requirements documents (ORD), technology, the ICDB, opportunity, and information infrastructure are considered in the development of the CRD. J. Communication Annexes to CINC/CJTF Operation Orders (OPORD). These annexes document CINC/CJTF communications plans. They identify the communications systems employed, operational procedures, and coordinating instructions to supporting elements. K. Communication Annexes to FLTCINC OPORDs. These documents contain the FLTCINC’s communications plans that support the joint commander’s requirements. They identify the communications systems employed, operational procedures, and coordinating instructions to supporting elements. L. FTPs. These publications are issued by the NCTAMS to promulgate standard telecommunications procedures for use by communications personnel operating in a particular ocean area. They incorporate procedures unique to that area in amplification of information contained in CJCS, CINC/CJTF, and FLTCINC directives. Changes to an FTP may initially be promulgated in CIB/CIAs. M. CIB/CIAs. These bulletins are promulgated by the NCTAMS to provide accurate and readily accessible reference information on specific tactical communications subjects. CIB/CIAs provide operations personnel with procedural information applicable to a specific communications area and normally are promulgated by message. Naval units are required to maintain a complete and current file of CIB/CIAs as a primary source of communications information. Changes in EHF SATCOM operational procedures, for example, may initially be identified via CIB/CIA before incorporation into an FTP or NTP. N. Navy EHF SATCOM Implementation Plan (dated 21 April 1992). The draft plan provides general EHF SATCOM information on the system architecture, system capabilities, program development, system integration and installation, and initial operational capability testing to aid in understanding EHF SATCOM as it evolves. O. NESP EHF Primer, Version 3.0 (dated 29 March 1990). The NESP Primer contains background information on the Milstar, FEP, and UFO/E communications satellite systems. P. Naval EHF SATCOM CONOPS (dated May 1995). This CONOPS describes how EHF SATCOM can be employed to provide protected communications services that satisfy naval ORIGINAL 1-10
NTP 2 SECTION 3 (B) hard core strategic and tactical requirements. It also provides communications planners at the FLTCINC and COMARFORLANT/PAC level and below with information they need to submit requirements via the CJCSI 6250.01 process and to develop EHF COMMPLANs. Q. FEP SCOC (dated March 1995). This document describes the control segment and provides operational control procedures for the FEP packages hosted on FLTSATs 7 and 8. R. Milstar Standard Communications Operations Policies and Procedures (MSCOP&P) (dated 4 January 1994). The MSCOP&P describes the Joint Staff-approved Milstar system operating instructions, policies, and procedures. It applies to all Milstar EHF and UHF planners, managers, and users. It provides a framework for development and documentation of network operating instructions and procedures. S. UFO/E Space Package SCOC, Draft (dated November 1993). This document describes the control segment and provides operational control procedures for the EHF packages hosted on UFOs 4 through 10. T. Joint Users Guide for FEP and UFO/E (dated June 1995). The Joint Users Guide provides a consolidated reference for communications planners and users of FEP and UFO/E. The guide is intended for use by Unified CINCs, component communications planners, and users of Navy-managed EHF SATCOM systems. U. Navy EHF SATCOM System Description. This document provides a basic overview of Navy EHF SATCOM systems and describes their role in fulfilling the warfighter’s requirement for an assured, stealthy means of communicating vital information. V. EE130-AG-HBK-010/156-3 USC-38, SATCOM-General, AN/USC-38 System Users Handbook (dated March 1996). This handbook provides a general overview of the Copernican Architecture described from the battle group operator’s perspective. It provides coverage of the subscriber and resource segments of this architecture as they relate to EHF SATCOM. W. Naval Satellite Communications (SATCOM) Course, (dated 2–3 August 2000). This HQ NAVSPACECOM course of instruction (COI) provides the most current SATCOM information available for Fleet Sailors and Marines who need a well-rounded understanding of DOD SATCOM systems in order to support their warfighting C4I requirements. X. Milstar Communications Planner’s Course. This COI was developed by the LinCom Corporation for the purpose of training communications planners for Milstar operations. The focus of this COI is on the operation, planning, and controlling of communications resources on the Milstar satellite system. Y. Naval EHF MILSATCOM Operator’s Handbook, (dated 11 August 2000). This Operator’s Handbook was developed to provide Navy EHF SATCOM operator’s with a ready ORIGINAL 1-11
NTP 2 SECTION 3 (B) reference guide to assist them in the performance of their duties. It provides descriptions of the most prevalent equipment, systems, services, and access procedures that are used on a routine basis by Navy and Marine Corps EHF equipment operator’s. Z. Milstar Satellite Communications System Control and Operations Concept (SCOC), (dated 10 July 1998). This SCOC defines the operational capability of the Milstar SATCOM system, provides the operational concept for system control, and provides policies and procedures for efficient management and use of Milstar communications resources. AA. Joint EHF MDR CONOPS, (dated 31 March 2000). This CONOPS provides a detailed description of EHF MDR capabilities and features, defines the roles and responsibilities for EHF MDR operations, and describes how each Service/Agency will use EHF MDR communications resources in the field.
ORIGINAL 1-12
NTP 2 SECTION 3 (B) CHAPTER 2 SYSTEM DESCRIPTION
201.
GENERAL
The EHF SATCOM system provides the military Services with an interoperable and survivable SATCOM system that complements the existing UHF/SHF SATCOM systems. EHF was developed to take advantage of the ability of its wide bandwidth to manipulate the signal through a complex sequence of jam-defeating operations, and to provide enhanced data transfer rates (throughput) whenever a reduction in AJ performance is acceptable. The designers of the EHF SATCOM waveform, MIL-STD-1582D, defined a protocol that satisfies all of the Servicedefined system threshold requirements for a SATCOM system, chief of which is the need for robustness in the form of jamming, scintillation, and electromagnetic pulse (EMP) protection. This driving requirement for robustness shaped the early development of the EHF SATCOM program, and by design, traded-off the EHF alternative capacity feature of enhanced bandwidth for high-speed information transfer. Thus the upper limit defined by this protocol, referred to as low data rate (LDR), supports 2400 bits per second (bps) for information transfer. LDR communications resources are available on the FEP, the UFO/E, the UFO/EE, PEP, and Milstar I. In 1991, the Milstar program was restructured to de-emphasize the AJ and survivability features in favor of enhanced throughput and increased tactical utility. Thus the forthcoming emerging MDR capability will be available when the Milstar II satellites become operational, with their enhanced maximum throughput data rate of 1.544 Mbps. All SATCOM systems are composed of three basic segments - space, earth, and control with all three being integrated by a management structure and technical means to provide communications services to the user. Today’s EHF SATCOM system is actually composed of multiple EHF satellite systems; each defined by the satellite with which it is associated. Each of these EHF satellite systems has its own dedicated control subsystem that performs the required functions of maintaining the satellite’s orbit, and monitoring and modifying as necessary the communications payload package to meet changing operational demands. The Earth segment is that portion of the EHF SATCOM system most familiar to U.S. Navy users. There are nearlyidentical production variants of the Navy’s AN/USC-38(V) family of EHF SATCOM terminals that were designed for surface ship, submarine, and shore-based use. The remainder of this chapter will be primarily devoted to providing descriptions of the EHF SATCOM space and Earth segments. The control segment is discussed in chapter 3. 202.
EHF SPACE SEGMENT
The space segment consists of four different types of satellite: FEP, UFO/E and UFO/EE, PEP, and Milstar. These satellites differ by the capacity of services each can support, the number and types of antennas aboard, the throughput data rates, the availability of special features, such as crossbanding (receiving a signal in one portion of the RF spectrum, and retransmitting that signal in another portion of the spectrum) and crosslinking (a Milstar only system feature that permits the direct relay of a communications channel from one satellite to another, without the ORIGINAL 2-1
NTP 2 SECTION 3 (B) use of a ground-based intermediate relay terminal), degree of survivability, as well as other less significant capabilities. The mix of these satellite types will vary with time as new replacement spacecraft are launched and placed in service, and older units reach the end of their useful service life. The final worldwide EHF constellation will consist of five or six Milstar, eight UFO/E and UFO/EE, and three PEP, to be completed sometime after the year 2002. A. FEP. FLTSAT 7 and 8 are geosynchronous satellites which contain FEP capabilities that provide an EHF uplink, SHF downlink, and Satellite Resource Controller (SRC) computer to support communications. FEP provides 26 LDR communications channels which offer a major subset of Milstar capabilities. Each communications channel supports a primary subchannel service (C0), secondary subchannel service (C1), and orderwire service (C2, uplink control, and C3, downlink control). 1. The FEP satellites were developed to test and demonstrate certain key features of the Milstar EHF SATCOM system, and to provide an on-orbit test communication payload for the operational test and evaluation (OT&E) of EHF terminals. FLTSAT 7 was launched in 1986, and it was followed three years later by FLTSAT 8 in 1989; this EHF capability was achieved by incorporating separate and independent EHF packages onboard each of these two host satellites. This initial use of EHF SATCOM demonstrated the technological benefits that had previously been limited to the laboratory test bench. FEP provided a relatively low-cost validation of the performance characteristics that had been calculated to exist with EHF, as well as fulfill the need for an EHF spacecraft with which to conduct OT&E of the EHF full-scale development (FSD) terminals. FEP continues to be used to satisfy both research and development (R&D) and limited operational requirements. 2. The FEP satellites operate at approximately 20 gigahertz (GHz) (SHF) on the downlink, and approximately 44 GHz (EHF) on the uplink. Each satellite has two antenna beams. The spot beam antenna is dual frequency, and it forms a 5o beam that is steerable by ground command; it covers a 2,000 nautical mile (nm) diameter area at the equator, but expands and distorts to an elliptical pattern when directed towards the poles. The spot beam is capable of supporting 13 communications channels. The earth coverage (EC) beam antenna provides a 17.5o view of the Earth as seen by the satellite, and consists of separate horn antennas for SHF transmit and EHF receive functions. The EC beam is capable of supporting 13 communications channels. Figure 2-1 illustrates FEP antenna coverage areas, while table 2-1 provides a summary of FEP system capabilities. 3. The two FEP satellites each contain a SRC computer that performs onboard signal processing. This SRC dynamically processes the uplink signals from all terminals logged on the system, then produces downlink signals for each beam so that the terminals receive the appropriate time-division multiple access (TDMA) communications services in the appropriate time slots. These communication services are allocated in accordance with predefined algorithms. Signaling commands (protocols) between the terminals and the SRC are used to initiate, modify, or terminate communication services, and to perform other housekeeping functions. These signals are exchanged on special orderwire subchannels (uplink control C2, and
ORIGINAL 2-2
NTP 2 SECTION 3 (B)
FEP-7
FEP-8
100W
23W
Note: The pictured satellite coverage assumes minimum 20º elevation angle from the user’s earth terminal to satellite
Figure 2-1. FEP Satellite Antenna Coverage Areas.
Services and Capabilities
FEP-7 & 8
Locations
FEP-7 100oW FEP-8 23oW
Antennas: Earth Coverage Spot Beam Agile Beam Crosslinks Point to Point Call Network CINCNET Broadcast Fleet Satellite Broadcast (FSB) Submarine Reportback (SRB) Channels LDR MDR Primary (C0) Data Rates (bps) Secondary (C1) Data Rates (bps) Uplink Control (C2) Subchannel Downlink Control (C3) Subchannel EHF–UHF Cross-banding (bps)
1(17.5o) 1(5o)/2000nm No No Yes Yes No Yes No Yes * 26 (13 EC; 13 spot) 0 75, 1200, 2400 75, 150, 300 Yes Yes No
Critical Resources
Downlink Hops
* NOTE : FEP supports SRB. However, SRB operational use is not practical since it requires an entire payload reconfiguration, which would then deny support to other EHF users.
Summary of FEP System Capabilities Table 2-1 ORIGINAL 2-3
NTP 2 SECTION 3 (B) downlink control C3) that are separate from the normal communications traffic subchannels (C0 and C1). The satellite also provides the downlink synchronization signals used by terminals to acquire and track the satellite. 4. EHF LDR is capable of supporting several discrete data rates, up to and including 2400 bps; however, each of the EHF SATCOM systems has been designed with a slightly different set of rates that can be accommodated. FEP supports user primary subchannel (C0) data rates of 75, 1200, and 2400 bps, and secondary subchannel (C1) data rates of 75, 150, and 300 bps. B. UFO/E and UFO/EE. The most recent EHF-capable satellites to achieve operational status are those of the UFO constellation. The UFO was designed to replace the FLTSAT and Leased Satellite (LEASAT) constellations with a continuing UHF MILSATCOM capability. Three different satellite configurations comprise the UFO family, and they are defined by the frequency spectrum of their payloads. Block I satellites (2 and 3) have UHF and SHF, and are referred to as UFO. Block II satellites (4 through 6) have UHF, SHF, and EHF. The EHF enhancement is achieved by adding an EHF LDR payload package similar to that of the FEP; these spacecraft are designated the UFO/E. The EHF payloads on Block III satellites (7 through 10) are enhanced to increase capacity and flexibility, and these are designated the UFO/EE. The initial EHF satellite capability (UFO/E satellites 4 through 6) offer AJ capability using a package that supports at least 11 EHF uplink channels, each capable of being downlinked at SHF (20 GHz), UHF, or simultaneously at SHF and UHF. The EHF payloads on UFO/EE satellites have an enhanced capability to include a 20-channel capacity; this upgrade increases those satellites’ operational flexibility and communications capacity for all joint users. Furthermore, the primary commanding uplinks on these satellites use EHF to ensure that control is AJ protected. Figure 22 illustrates the worldwide coverage provided by the UFO constellation, while table 2-2 summarizes the system capabilities of the UFO/E and UFO/EE. 1. The UFO satellite is a three-axis-stabilized spacecraft weighing approximately 2,364 pounds. These satellites are located in geosynchronous orbits, and provide EHF earth coverage between 65o north and 65o south latitudes. The UFO/E satellites contain the same basic LDR-payload capabilities as the FLTSATs with the FEP modifications, but also have the added capability of EHF-to-UHF crossbanding. The UFO/E satellites also contain a SRC computer, as well as one EC antenna and one 5o spot beam antenna to support communications. The EC footprint is approximately 7,000 nm in diameter, while that of the 5o spot beam is 2,000 nm. The UFO/E satellites 4 through 6 have 11 communication channels, 7 assigned to spot beam use and 4 to EC, which are “hard wired” and cannot be modified. Each channel will support a primary service (C0), a secondary service (C1), and orderwire control messages (C2 and C3). UFO/E satellites also have 7 acquisition channels that are used by the EHF terminals to initiate service with the satellite; EHF terminals achieve time and frequency synchronization with the satellite, and obtain an access control slot through this acquisition channel. 2. The UFO/E EHF package provides an EHF uplink EC antenna, an SHF downlink EC antenna, and a single EHF uplink/SHF downlink 5o spot beam antenna. The uplink
ORIGINAL 2-4
NTP 2 SECTION 3 (B)
UFO/EE-7 100W
UFO/E-4 177W
UFO/E-6 105W
UFO/EE-10 72E
UFO/EE-9 22.5W
UFO/E-5 72.5E
UFO/EE-8 172E
Figure 2-2 UFO/E and UFO/EE Antenna Coverage Areas Services and Capabilities Locations Antennas: Earth Coverage Spot Beam Agile Beam Crosslinks Point to Point Call Network CINCNET Broadcast Fleet Satellite Broadcast (FSB) Submarine Reportback (SRB) Channels LDR MDR Primary (C0) Data Rates (bps) Secondary (C1) Data Rates (bps) Uplink Control (C2) Subchannel Downlink Control (C3) Subchannel EHF–UHF Cross-banding (bps) Critical Resources
UFO/E
UFO/EE
UFO/E 4 177o W UFO/E 5 72.5o E UFO/E 6 105o W
UFO/EE 7 100o W UFO/EE 8 172o E UFO/EE 9 22.5o W UFO/EE 10 72o E
Yes 1(5o/2000nm) No No Yes Yes No Yes
Yes 1(5o/2000nm) No No Yes Yes No Yes
Yes
Yes
No 11 0 75, 1200, 2400 75, 150, 300 Yes Yes 75, 1200, 2400, 4800, 9600 broadcast Uplink Channels
No 20 0 75, 1200, 2400 75, 150, 300 Yes Yes 75, 1200, 2400, 4800, 9600 broadcast Balanced U/L & D/L
Summary of UFO/E & UFO/EE System Capabilities Table 2-2. ORIGINAL 2-5
NTP 2 SECTION 3 (B) and downlink EC antennas are typically used to support shore-based terminals, whereas the more robust 5o spot beam antenna is typically used to support mobile terminals that use smaller antennas, such as surface ships and submarines. The uplink EC antenna supports up to four communication channels, each supporting primary (75, 1200, 2400 bps) and secondary (75, 150, 300 bps) voice or data service. However, one of the EC uplink channels must be dedicated to the satellite ground terminal for satellite commanding at 75 or 2400 bps. The 5o spot beam antenna supports 7 communication channels, that provide primary (C0) and secondary (C1) communication services. UFO/E satellites can support 4 differential phase-shift keying (DPSK), 1 frequency-shift keying (FSK) high hop rate (HHR) mode, and 2 FSK low hop rate (LHR) modes. 3. UHF downlink channels 1 through 10 are configurable for EHF-to-UHF crossbanding. One of the EC uplink channels can be used to receive the Fleet Satellite Broadcast (FSB) for payload crossbanding to a UHF downlink channel at a data rate of 75, 1200, or 2400 bps. Individual EHF uplinks may also be crossbanded to UHF. 4. The capabilities of the UFO/EE payloads onboard UFO satellites 7 through 10 have been enhanced to increase capacity and flexibility; its communications channels were increased from 11 to 20, and acquisition channels increased from 7 to 8. Additionally, the channel groups are capable of being switched between EC and the spot beam. These new channels are divided into an 8 channel group (4 communication channels, and 4 acquisition channels) and a 20 channel group (16 communication channels and 4 acquisition channels). Each communication channel supports primary (C0) and secondary (C1) services, as well as orderwire control messages (C2 and C3). UFO/E supports a maximum of 22 communication services and 132 terminals, while UFO/EE supports a maximum of 40 services and 204 terminals. 5. Similar to the case with the FEP, with the UFO/E system the EHF terminal only has one uplink and one downlink signal that is shared by all the users on that terminal. The uplink and downlink signals are broken down into multiple parts in order to allow time for the terminal and the satellite to exchange information (C2 and C3), as well as for primary and secondary communications (C0 and C1). C. Interim PEP. An interim polar EHF system has been fielded to fill the gap in EHF coverage above 65o north latitude until a full polar SATCOM system is fielded. PEP currently consists of a single modified UFO/EE communications payload carried aboard a classified-host satellite in a Molniya orbit. A Molniya elliptical orbit allows the satellite an extended hang time over the northern regions for most of its orbit, then it whips around the south pole and returns to its station over the North Polar Region. This satellite orbits the Earth approximately every 12 hours, at an approximate inclination of 63o. The communications payload downlink (at 1-GHz) is activated approximately 14 hours each day, during which time support is available for the North Polar Region. The uplink signal is in the EHF frequency range and is hopped over the entire operating bandwidth (43.5-GHz to 45.5-GHz). When the payload is reactivated at the beginning of the next operating period, both beams automatically point to their last commanded position. The payload modifications include the addition of a gimbaled 18o EC antenna to enable steering for approximately a 10,000 nm diameter footprint, and a 5o steerable spot beam, with ORIGINAL 2-6
NTP 2 SECTION 3 (B) user-assigned priority pointing over approximately an 2000 nm diameter footprint; however, there is no EHF-to-UHF crossbanding available. Also included are downlink modulation modes with halved hopping bandwidth, and a robust C3 mode supporting disadvantaged users. This payload supports networks and point-to-point (PTP) service, but no crossbanding of the FSB (as on the UFO spacecraft) is available. While PEP resources are joint assets that can be made available to any CINC-validated user upon approval of the Joint Staff, the payload was designed primarily to satisfy emergent CINC requirements for maritime forces operating in the North Polar region. NAVSOC controls the interim polar EHF package, which achieved operational capability in April 1998. Two more PEP satellites are expected to be operationally available, one in 2003 and the other in 2004. Table 2-3 provides a summary of the Interim PEP system capabilities. Services and Capabilities
PEP Classified-Host UFO/EE Satellite Molniya (elliptical)
Locations Orbit (twice a day) Antennas: Earth Coverage Spot Beam Agile Beam Crosslinks Point to Point Call Network CINCNET Broadcast Fleet Satellite Broadcast (FSB) Submarine Reportback (SRB) Channels Primary (C0) Data Rates (bps) Secondary (C1) Data Rates (bps) Uplink Control (C2) Subchannel Downlink Control (C3) Subchannel EHF–UHF Cross-banding (bps)
o
1(18 steerable) 1(5 /2000nm steerable) No No Yes Yes No Yes No No 20 75, 1200, 2400 75,150,300 Yes Yes No o
Summary of Interim PEP System Capabilities Table 2-3 1. The Interim PEP provides communications capable of supporting missionessential C2 requirements above 65o north latitude. The spacecraft hosting the Interim PEP payload is placed in a Molniya orbit, which is characterized (approximately) by the following: •
•
Orbital period is approximately 12 hours (i.e., the satellite orbits the Earth twice a day. To maintain a constant longitude of apogee, the time of apogee precesses approximately two minutes per orbit, or four minutes per day. The inclination is approximately 63.4o.
ORIGINAL 2-7
•
•
NTP 2 SECTION 3 (B) o The minimum perigee is 350 miles over the 63.4 south latitude line. Actual perigee altitude is launch dependent, and varies over the satellite’s life span. The apogee is approximately 24,400 miles above the 63.4o north latitude line. Due to the period of its orbit and the Earth’s rotation, the satellite has two apogees (and perigees) located 180o of longitude from each other. For example, if the satellite has an Atlantic apogee at 0o west longitude (i.e., the satellite is at the highest point in its orbit when the coordinates of the subsatellite point are 0o west longitude and 63.4o north latitude), its Pacific apogee would be at 180o west longitude.
The downlink of the communications payload is activated during the interval of +/3.5 hours centered on the apogee (i.e., about 14 hours per day). These restrictions are due to power conservation measures needed to maintain the satellite’s electrical power systems. The duration of satellite availability is dependent upon where a user is located relative to the satellite’s orbit. 2. The Interim PEP communications payload is virtually identical with that of the enhanced EHF payloads onboard the UFO/EE satellites (UFOs 7 through 10), with the following modifications: •
There is no EHF-to-UHF crossbanding capability.
•
The 18o EC and 5o spot beam gain patterns have been slightly modified to provide increased gain towards the beam’s center at the cost of degraded, but acceptable, edge-of-beam gain performance.
•
The 18o EC is gimbaled so that it can be steered by the payload’s Telemetry and Commanding (T&C) terminal to track a point on the Earth’s surface.
•
The payload’s traveling wave tube (TWT) is enhanced to provide approximately 3 dBW of increased downlink effective isotropic radiated power (EIRP) for both the EC and spot beam users.
•
The downlink hopping bandwidth has been halved. This is transparent to users and does not significantly affect the system’s AJ performance.
•
The most robust C3 mode is commandable from FSK-1 LHR and FSK-2 LHR to provide disadvantaged users with a more robust downlink for acquisition.
•
The payload has been modified to provide a background broadcast of its ephemeris data to both the spot and EC beams whenever C3 queues permit.
•
Additional downlink modulation modes have been implemented so that if members of a service in the same beam require different modulation modes, the most robust mode is used to calculate hop requirements. ORIGINAL 2-8
NTP 2 SECTION 3 (B) •
The spot beam movement algorithm has been modified to incorporate a userassigned priority into each move request. A new user requesting a beam move will also transmit the priority of the move request. If higher than the current priority of the spot beam, the requesting terminal is given control of the beam, the beam move is executed, and the beam priority is then reset to the value of the new user.
3. The Interim PEP system conforms to the MIL-STD-1582D waveform standard. Both the system uplink and downlink are frequency hopped over a wide bandwidth, approximately 2 GHz for the uplink, and 500 MHz (half the normal bandwidth) for the downlink. The TRANSEC devices located with each terminal and onboard the communications payload control this frequency hopping. Terminals must be loaded with the same TRANSEC cryptographic keys as the payload in order to access the satellite. 4. Two satellite beams are available to support user communications, an 18o steerable EC beam, and a 5o steerable spot beam. The motors used for pointing each beam are deactivated at the end of each seven-hour operating period. When the payload is reactivated again at the beginning of the next operating period, both beams automatically point to their last commanded position. a. The 18o EC beam covers an area approximately 10,000 nm diameter footprint. Unlike the EC beams on the equatorial EHF payloads, the EC beam on the Interim PEP system is gimbaled so that it can be steered to a point on the Earth’s surface by the payload’s T&C terminal. As the satellite travels throughout its orbit, the EC beam remains pointed at the center of its ground trace. Terminals within the EC’s 10.6o center will have better link margins (both uplink and downlink) than if they were operating on the edge of the beam. b. The 5o spot beam covers an area approximately 2000 nm diameter footprint, and can be repositioned to any point in the field of view on the Earth’s surface by the user terminal designated as the spot beam controller. As the satellite moves throughout its orbit, the spot beam remains pointed at its assigned location. The spot beam provides increased signal gain for both transmit and receive signals of approximately 6 to 10 dB over that of the EC beam. Terminals operating in the 3.2o center of the spot beam will receive improved link margins on both the uplink and downlink when compared with the link margins at the edge of the beam. c. Spot beam pointing is done on a priority basis. The priority of the spot beam can vary from 0 (lowest) to 7 (highest). When the payload is reactivated after each perigee, the beam priority is reset to zero. A user requesting a beam will also transmit the priority of the move request. If the priority of the move request is higher than the current priority of the spot beam, then the requesting terminal is given control of the beam, the move is executed, and the beam priority is reset to the value of the new user. Once the user has seized the spot beam, they can repoint it using the same priority until another user seizes it. Moving the beam also resets an onboard beam priority timer. When this timer expires, the payload will automatically reset the spot beam’s priority to zero, preventing the spot beam from becoming unavailable if a highpriority user finishes their spot-beam operations without resetting the beam’s priority.
ORIGINAL 2-9
NTP 2 SECTION 3 (B) 5. The uplink signal is in the EHF frequency range, and is hopped over the entire operating bandwidth (43.5 GHz to 45.5 GHz). To receive these signals, the payload has two channel groups which can be switched (via a payload table change) to support either the EC or the spot beam. One channel group has 4 communications channels, and the other has 16. Each beam can be configured via a payload table (uplinked by the T&C terminal) to support either HHR or LHR communications. Uplink channels are designated as HHR or LHR according to the beam they support. For example, if the EC beam is configured as LHR and is supported by the 16-channel group, then all 16 communications channels are also set for LHR. HHR channels can support higher data rates (up to 2.4 kbps) but provide less robust communications than LHR channels. LHR channels provide the most robust communications (i.e., the highest possible link margins and AJ properties), but can only support 75 bps communications. a. HHR. As in other LDR systems, each HHR channel is divided into three subchannels. The C0 subchannel supports user communications at 75, 1200, or 2400 bps and the C1 subchannel supports 75, 150, or 300 bps communications services. A single HHR channel can support two simultaneous communications services, one in the C0 subchannel and one in the C1 subchannel. The C2 subchannel is used for receiving system control messages from the user terminals; these support terminal-to-payload system messages which allow users to perform functions such as activating communications services, repointing spot beams, or requesting ephemeris data updates. The payload’s onboard resource controller determines the specific channel (or subchannel) that a communications service will use. This channel assignment is sent to a terminal by the payload when a service is activated or joined, and is transparent to the user. b. LHR. When a T&C terminal configures a beam as LHR, all of its communications channels are set to support communications only. In this mode, only teletype (TTY) mode acquisitions and communications are permitted. All terminals using a beam which has been so configured, use the Robust Access Channel (RAC) to support their C2 messages. The remaining channels in the beam can support a single 75 bps communications service. 6. The payload’s downlink is a signal in the SHF frequency band, and is frequency hopped over half of the normal EHF bandwidth (20.2-GHz to 21.2 GHz). Each frame of the downlink signal is divided in time into a number of “hops.” Downlink hops are divided into three groups: one for sending timing and synchronization signals to terminals; one which supports satellite-to-terminal (C3) system messages; and one for supporting user communications. Unlike the uplink, the payload’s downlink can support both LHR and HHR modulation modes simultaneously. The number of hops available for LHR and HHR communications is configured via the T&C terminal by defining the LHR/HHR boundary. Once the boundary is set, HHR services do not have access to LHR hops and vice versa. The payload has a classified number of downlink hops available to support user communications. Each beam that supports users on its downlink requires an independent set of hops for a given communications service, since a single downlink hop cannot be transmitted on both beams simultaneously. The number of downlink hops in each set depends on the data rate of the service and its downlink modulation mode for that beam. If members of a service in the same beam require different modulation modes, the most robust is used to calculate the hop requirement.
ORIGINAL 2-10
NTP 2 SECTION 3 (B) D. Milstar. Milstar is a joint, tri-Service SATCOM program, that features interoperable terminals, which provide both voice and data services at multiple data rates from various platforms. Satisfying both core and hard-core communication requirements when fully operational, Milstar will provide a worldwide, secure, jam-resistant, strategic and tactical communications capability for the NCA, CJCS, Unified Commands, and other selected DOD and non-DOD government agencies. The Milstar frequency band, waveforms, and signal processing designs are robust, with survivability, endurance, and terminal interoperability as major considerations. Originally, the Milstar design emphasized strategic operations with the capability to endure the most severe cold-war-threat environment. Its purpose was to support C2 before, during, and after a full-scale nuclear war. As a result, the Milstar block I satellites were optimized to provide a LDR payload that satisfied NCA and CINC hard-core requirements for assured communications during pre-, trans-, and post-strike nuclear environments. In 1991, the DOD directed the Air Force to modify the Milstar program to increase its tactical focus and utility, while reducing life-cycle costs. As a result, the program was restructured to deemphasized the nuclear war fighting features, and led to the creation of Milstar block II satellites. The Milstar II satellites will add a MDR payload in addition to the block I’s LDR capability. Thus the MDR payload reflects a diminished strategic threat and foregoes many of the survivability attributes of LDR in favor of enhanced throughput; it provides greatly increased utility for tactical force, core communication requirements through higher data rates; an increased quantity of steerable antennas; and in some cases, new terminal antennas. The MDR satellites will be capable of accommodating 600 or more user links, and the full constellation will accommodate at least 2400 user terminals simultaneously. The MDR system will also continue to support EHF terminal broadcasting, along with networks, and PTP calls. Figure 2-3 illustrates the Milstar block I constellation antenna beam coverage areas; table 2-4 summarizes the Milstar system capabilities. 1.
Milstar LDR a. The functional components of the Milstar low-inclination, geosynchronous LDR satellite include the antenna array, and the SRC computer that performs onboard signal processing, crossbanding from the received EHF signal to the transmitted SHF or UHF signal, as well as direct line-of-sight crosslinking between neighboring satellites. In 1994, the first flight (FLT) of Milstar satellites was added to the EHF constellation; currently FLT-1 and 2 are operational. To communicate with the satellite, an EHF terminal must be within the antenna coverage of an uplink and downlink beam of the satellite. b. Each Milstar LDR spacecraft has three different types of antennas: a 17.5 EC antenna; three spot beam antennas (Spot A, B, and C), that have dual frequency beams, provide a concentrated beam of energy on the earth within a bounded geographical area, and are steerable so that their location can be controlled by designated ground-command terminals; and o
ORIGINAL 2-11
NTP 2 SECTION 3 (B)
Milstar-1 120W
Milstar-2 4E
Note: The pictured satellite coverage assumes minimum 20º elevation angle from the user’s earth terminal to satellite.
Figure 2-3 Milstar I Satellite Antenna Coverage Areas six agile beam antennas, each of which is an array of fixed beams (i.e., a “honeycomb”of spotbeam areas) which when combined cover the same Earth’s surface area as an EC beam. Five of the agile beam antennas are uplink communication antennas, including LHR tactical, HHR tactical, Acquisition Agile, Reportback Agile, and CINC Agile. The sixth agile beam antenna is a SHF downlink antenna. The agile beams provide coverage through electronic beam-to-beam switching. The Reportback Agile beam is dedicated to tactical submarine reportback (SRB) user functions. There is a separate EC beam that supports UHF TDMA communications, as well as an EHF uplink crossbanded to a UHF downlink to support FSB communications. The Milstar satellites are also designed with the capability of crossbanding EHF, SHF, and UHF signals. c. All Milstar uplink antennas (except the Air Force Satellite Communications (AFSATCOM) UHF antenna) are EHF antennas. In addition, the uplink antennas are partitioned according to hop rate. One receiver is used for each uplink antenna, which permits multiple simultaneous access of uplink signals. Five downlink antennas are SHF, and two are UHF. Downlink capabilities are divided among spot, agile, and EC antennas. The UHF downlinks have dedicated transmitters, but the SHF antennas (all using time division multiplexing (TDM)) share a common transmitter. d. The Milstar satellites are equipped with a SRC computer to perform onboard signal processing. The SRC dynamically processes the uplink signals from all the terminals communicating with the satellite, then produces the downlink signals for each beam so that each terminal receives the appropriate communication service. These communication services are allocated in accordance with uploadable algorithms stored in the SRC. The Milstar satellites have the only EHF payload that provides crosslinking communications, which enables
ORIGINAL 2-12
NTP 2 SECTION 3 (B) SERVICES AND CAPABILITIES Antennas: Earth Coverage (LDR) Spot Beams (LDR) Spot Beams (MDR) Agile Beams (LDR) Crosslinks (LDR & MDR)) Point to Point Call Network CINCNET Broadcast Fleet Satellite Broadcast (FSB) Submarine Reportback (SRB) Channels Primary (C0) Data Rates (bps)
Milstar I
Milstar II
1(17.5o) 3 (A&B 400 nm, C 650 nm) No (0) 6 Yes (2) Yes Yes Yes Yes
1(17.5o) 3 (A&B 400 nm, C 650 nm) 8 (400 nm) 6 Yes (2) Yes Yes Yes Yes
Yes
Yes (LDR only)
Yes
Yes (LDR only)
LDR-144 2.4 kbps channels MDR-No channels
75, 150, 300 Yes Yes
LDR-144 2.4 kbps channels MDR-30 1.5 Mbps channels LDR-75, 150, 300, 600, 1200, 2400 MDR 4.8 to 1544 kbps 75 2400 bps Yes Yes
Yes
Yes (LDR only))
Downlink Hops
Downlink Hops
75, 150, 300, 600, 1200, 2400
Secondary (C1) Data Rates (bps) Uplink Control (C2) Subchannel Downlink Control (C3) Subchannel EHF–UHF Crossbanding (bps) Critical Resources
Summary of Milstar System Capabilities. Table 2-4 worldwide communications network connectivity directly between satellites without the use of ground-relay facilities. Additionally, crosslinking provides downlink synchronization for tracking of the satellite. The number of communication channels on Milstar satellites is classified. Milstar channels are “hard wired” (specific amount assigned to each antenna beam) and cannot be switched between antennas. Downlink resources are related to the downlink hop rates. Milstar satellites support 5 DPSK and 6 FSK HHR modes, and 5 FSK LHR modes. The modes used are assigned based on the robustness required to support the various terminals and services. Milstar LDR supports the same throughput data rates as FEP (75, 150, 300, 1200, and 2400 bps) with an additional 600 bps capability. Since these standard data rates were adopted to conform to baseband equipment interface requirements, they by default correlate with the required communication services operating parameters. e. As was the case with the FEP, UFO/E, and UFO/EE systems, the Milstar LDR uplink and downlink signals are shared by all the users of that terminal. The same timeslot features of the uplink/downlink are applicable to the EHF terminals that access the Milstar LDR satellite system as well.
ORIGINAL 2-13
NTP 2 SECTION 3 (B) 2.
Milstar MDR
a. Milstar MDR is a sophisticated, multi-user system designed for military communications in a hostile environment. The EHF MDR SATCOM waveform protocol is defined by MIL-STD-188-136, with the initial MDR capability being provided on Milstar block II spacecraft. All are referred to as the Milstar II spacecraft, and they will have both MDR and LDR capabilities integrated aboard the communication suites. The MDR protocol supports data rates up to T-1 (1.544 Mbps); however, based on gain calculations which are determined primarily by antenna dimensions, not all terminals will be capable of achieving the full T-1 throughput data rate. The total maximum satellite throughput capacity will be approximately 45 Mbps. The Navy terminal variants have the following maximum aggregate throughput capacities per terminal: flag-configured ships and communication vans-256 kilo bits per second (kbps); all other surface ships-64 kbps; submarines-19.2 kbps; and the NCTAMS-1.544 Mbps. Networks will operate at 4.8, 9.6, 16, 19.2, 32, 64, 128, 256, 512, 1024, or 1544 kbps. The Navy terminals also support the Advance Narrowband Digital Voice Terminal (ANDVT) at 2.4 kbps. b. Similar to the FLT-1 and -2 LDR satellites, the Milstar II MDR spacecraft are satellites placed in low-inclination geosynchronous orbits, and are also equipped with two crosslink antennas that permit direct line-of-sight (LOS) communications connectivity with neighboring Milstar satellites. These satellite crosslinks allow secure, survivable data transmission directly between satellites without reliance on vulnerable, ground-based relay nodes. These crosslinks also permit continental United States (CONUS)-based control nodes to maintain system control without the need for overseas ground-control facilities. c. The LDR payload data rates range from 75 bps up to 2400 bps, while the MDR payload throughput has been increased to operate from 4.8 kbps up to 1.544 Mbps. The payload onboard signal-processing capabilities are designed to ensure successful message transmission through natural interference, as well as operational threats (e.g., scintillation, rain, atmospheric losses, and jamming). These onboard processing and crosslink capabilities will provide worldwide EHF MDR communication coverage. Multiplexed for many simultaneous users, the uplink features 32 frequency division multiple access (FDMA) channels, and up to 70 simultaneous users on each channel, while the downlink consists of a single TDMA signal shared by all users in all beams. MDR uplink modulation is achieved via filtered symmetrical DPSK, and downlink is unfiltered DPSK. Each EHF MDR-capable terminal has a single uplink signal which is frequency hopped over a 2 GHz bandwidth, and is time shared to support multiple circuits. The MDR uplink signal is divided into three segments. The MC0 segment supports user communications, and is divided into 70 accesses; the uplink timing probe (UTP) is required to further refine the timing synchronization between the terminal and the satellite payload; and the MC2 segment serves the same purpose as the LDR’s C2 segment, which is to transmit system control data to the payload. The 70 accesses of the MC0 segment are combined into uplink timeslots to which communication services are assigned. An EHF MDR-capable terminal can support multiple services simultaneously as long as their timeslots do not overlap. MDR services supported include PTP calls (simplex, half duplex, or full duplex); MDR conferencing; MDR broadcast networks (simplex); simultaneous LDR and MDR communications; all at a bit error ratio (BER) of 10 -5.
ORIGINAL 2-14
NTP 2 SECTION 3 (B) d. Milstar II satellites communicate with ground terminals via EC, agile, and spot-beam antennas for LDR access, and via Distributed User Coverage Antennas (DUCAs) and Nulling Spot Beam (NSB) antennas for MDR access. The DUCA and NSB antennas are approximately the same size, with a 1o beam diameter, which equates to about a 400 nm diameter circle on the earth’s surface at the beam’s nadir. Similar to the block I satellites, the block II satellites also use EHF (40 GHz uplink) and SHF (20 GHz downlink) frequencies for communications with user terminals and mission control elements. Block II satellites also use crossbanding to UHF for communications with UHF earth-segment terminals. The LDR payload has ten uplink and six downlink antennas, while the MDR payload uplink includes two EHF/SHF NSB antennas, and six EHF/SHF DUCAs, grouped as two sets of three; the downlink consists of a single downlink, time-shared by the two spots and 6 DUCAs. e. MDR has the capability to reserve satellite resources and ensure access for authorized users. Referred to as MDR Fences, this is accomplished by “building a fence” around the desired resources, which can include uplink channels, crosslink slots, or downlink hops. Each fence is assigned an identification (ID). Thirty-two fence IDs are available on each Milstar II satellite; these IDs are given to the CINCs with their resource apportionment, and the CINCs can use or subapportion them as required. If a user is not assigned a specific fence ID to use by their communications manager, then they use an ID that identifies the service as “unfenced” when activated. Unfenced services will never preempt fenced services that are using resources within their fence, even if the unfenced service has a higher precedence than the fenced one. Conversely, a fenced service can preempt an unfenced service regardless of either precedence if the unfenced service is using resources within the fenced service’s fence. f. While Milstar MDR will not approach the signal robustness found in Milstar LDR, or the code-division multiple access (CDMA) waveform found in some SHF networks, its inherent survivability features will continue to offer greater protection than any other SATCOM medium; some AJ is sacrificed compared to that of Milstar LDR systems, but the MDR system still retains a residual AJ performance significantly better than transponderbased SATCOM systems. For this reason, it is envisioned that Milstar MDR will be used to transmit bandwidth-demanding imagery, Tomahawk Mission Data Update (MDU) files, intelligence database transfers, and other similarly large data files and information transfer requirements deemed critical to the warfighter. 203.
EHF EARTH SEGMENT
The Earth segment of EHF SATCOM consists of both those user terminals developed by the military Services to meet their requirements, and the baseband systems with which they interface to gain access to this medium. The EHF system provides secure communication for a broad spectrum of users, each generating a similarly broad list of terminal-specification requirements. These users operate from ground-based facilities, as well as from surface ships, submarines, aircraft, mobile vehicles, and portable manpack configurations. The responsibility for the development and fielding of terminals to fulfill these many divergent installation categories was assigned by the CJCS, and is along logical lines of Service expertise. The Navy was assigned the responsibility for developing the terminals for ships, submarines, and naval shore installations; the Air Force was assigned the terminals for Air Force and unified CINC ORIGINAL 2-15
NTP 2 SECTION 3 (B) ground sites, and for all aircraft installations; and the Army was assigned the portable manpack terminals that support the Army, Marine Corps, and Navy Sea-Air-Land (SEAL) team requirements. The Navy’s terminals were developed under the NESP by Commander Space and Naval Warfare Systems Command (COMSPAWARSYSCOM). The NESP terminals were initially designed to provide LDR access and interface with the FEP, UFO/E and UFO/EE, PEP, and Milstar systems, while meeting the tactical and strategic C2 operational requirements of the fleet. The variants of the NESP family of terminals were developed and produced by a Raytheon, Rockwell Collins, and Textron/Bell aerospace team. These initial LDR terminals are designated as the AN/USC-38(V)1 for submarine use; the AN/USC-38(V)2 for surface ship use; and the AN/USC-38(V)3 for shore installations, such as the NCTAMSs, and other selected shore sites. The surface ship and ashore terminals have 12 communication ports; the submarine terminals have 6 ports. In addition to the development of these three terminals, the Navy EHF Communication Controller (NECC) was also developed by SPAWARSYSCOM; the NECC is a sophisticated communication server which is used to control the transfer of information between subscribers on ships, submarines, and shore sites. The NECC uses the EHF SATCOM connectivity to support the information exchange subsystem (IXS) network Tactical Data Processors (TDPs). The functionality of the NECC program has been subsumed by the ADNS program, a program designed to replace single-path communication systems with multipath virtual networks. It represents a revolution in communications that will greatly enhance the efficiency of data networks. With the advent of Milstar MDR, terminal modifications are required that will permit the AN/USC-38(V) family of LDR terminals to interoperate with the MDR system. The Navy has been fielding EHF LDR terminals since 1993, and has begun modifications to the AN/USC-38(V) family of terminals for operation with the MDR payloads. Additional ports are being added to all the AN/USC-38(V) variants as part of the MDR upgrade. The AN/USC-38(V) terminal MDR Program includes new terminals (designated as AN/USC-38(V)4 through AN/USC-38(V)8 terminals), as well as upgrade kits for the existing AN/USC-38(V)1 through AN/USC-38(V)3 terminals that will allow these terminals to access the Milstar II satellites for MDR support. A. Terminal Components. Each of the AN/USC-38(V) family of terminals consists of three major component or equipment groups: the communications equipment group (CEG), the high-power amplifier (HPA), and the antenna pedestal group (APG). Except for the APG, which employs antenna components that are tailored to each platform type, the majority of the components in an EHF installation are common to all of the terminals. This high degree of component commonality produces a higher-than-normal readiness level for Navy EHF SATCOM systems because the logistics support consolidation (e.g., operator and maintenance training, repair parts provisioning, etc.) promotes enhanced efficiency. Figure 2-4 illustrates the various Navy terminal components. The NESP Terminal Program Plan provides new terminals and upgrades for existing AN/USC-38(V) terminals that will permit these terminals to access the MDR payload on Milstar II satellites. The new terminals will be installed on ships or at shore locations that do not have ORIGINAL 2-16
NTP 2 SECTION 3 (B) LDR terminals, while the upgrade kits will be used to upgrade those existing LDR terminals that are already operational. The MDR Program Upgrade includes modernization to the terminal’s CEG and antenna segments.
Figure 2-4 AN/USC-38(V) Terminal Components 1. CEG. The OK-618(V)/USC-38(V) CEG consists of the SB-4310/USC-38(V) Power Distribution Unit (PDU), the C-11917/USC-38(V) Terminal Control Unit (TCU), the CP-1870(V)/USC-38(V) Modem/Terminal Control Processor (Modem/TCP), the CV-4056(V)/USC-38(V) Microwave Processor/Antenna Position Control Unit (MWP/APCU), a cabinet spare drawer (for future MDR Program Upgrade use), and the HD-1165/USC-38(V) Heat Exchanger, which are all housed in the electrical cabinet. The general function of the CEG is to convert multiple-user signal inputs from baseband equipment between 6.4 and 7.4 GHz with fast switching (less than 200 nanoseconds) and low spurious noise for application to the HPA. The CEG also provides the down conversion of the dehopped K-band signal from the APG to the baseband equipment. The CEG communication ports support data rates from 75 to 2400 bps. The CEG also provides the system control and monitors the overall system status of the terminal. The CEG cabinet is cooled by a liquid-to-air heat exchanger located at the bottom of the CEG; it is a water-cooled radiator that provides for induction cooling of the CEG. The MDR Program Upgrades to the CEG will include changes to the Modem/TCP, and MWP/APCU. a. The PDU is located at the top of the CEG cabinet, and provides 115 Vac, 3 phase, 60 hertz (Hz) power control and circuit-breaker protection for each CEG chassis. b. The TCU is located just below the PDU, and it consists of a 25-line plasma display and a 20 push-button keypad. This is the operator interface for local control of the terminal and all of the communication functions, to setup and terminate communication ORIGINAL 2-17
NTP 2 SECTION 3 (B) circuits, monitor the terminal and network status, and perform fault isolation. The AN/USC38(V)1 terminal TCU can also be used to enter the 75 bps SRB message as the transmit resource. c. The Modem/TCP is located below the TCU and next to the MWP/APCU; it provides the interface for data, voice, and TTY input/output from the associated baseband equipment. The modem function also provides multiplexing/demultiplexing, coding/decoding, interleaving/deinterleaving of the user control data, and generates the different modulation and demodulation waveforms. The modem also performs the frequency hopping pattern generation (from the KGV-11A) and, for the shore and ship terminals, provides downlink signal tracking. The modem and TCP contain the interfaces to external systems, such as navigation subsystems, cesium standard, 75 bps SRB TTY message input, and auxiliary TTY interface. The TCP function provides network and terminal control, including satellite acquisition and antenna control functions. The main control pathway between the TCP function and other units of the terminal is the system control bus (a 500 kHz serial bus) for monitoring status information, and transmitting control and parameter data. The processor function also performs nuclear event detection, circumvention control, and supervises recovery of terminal operation. The MDR Program Upgrade replaces the LDR modem with a new Open Systems Architecture (OSA) MDR modem that will provide all the existing LDR interfaces along with the new MDR interfaces. The new MDR modem will be located in the spare drawer of the CEG. d. The MWP/APCU is also located below the TCU and next to the Modem/TCP. It contains the 5 MHz rubidium frequency reference (timing and frequency reference), uplink and downlink frequency synthesizers, and the microwave receiver. The synthesizers use a mix of direct digital synthesizer signals to provide nine frequency steps and mix/divide synthesizers implemented at L-band to provide outputs of 6.4 to 7.4 GHz, and 1.325 or 1.361 GHz local oscillator to the HPA, and 6.4 to 6.9 GHz to the APG. It also contains the servo or power amplifiers, control circuits, and antenna position feedback circuitry to support one or two antennas. The MDR Program Upgrade replaces the entire MWP eleven-module unit with a new Versa Module Eurocard (VME) synthesizer card, and three interface cards. Six control and power-supply cards in the APCU will be replaced with two VME cards, and three powersupply cards. 2. HPA. The AM-7364(V)/USC-38(V) HPA unit contains the final frequency conversion to the EHF frequency and amplification elements (250 watts) for the Q-band uplink signal. The MWP output is upconverted to Q-band using one of the two oscillators, thereby increasing the total transmit bandwidth to 2 GHz. The TWT amplifies the Q-band frequency signal to 22dBW (minimum) at the HPA output waveguide flange over a 25 dB dynamic range. The TWT is a periodic permanent magnet type focused with Samarium Cobalt and powered via a high-voltage power supply (HVPS). The maximum operating output voltage standing wave ratio (VSWR) as seen by the HPA looking toward the antenna is less than 1.5:1 with the TWT drive power applied. For higher VSWR levels, the TWT drive power is removed to avoid damage to the HPA. 3. APG. Each antenna was designed for the specific environment in which it operates in order to provide optimum performance. All of the platform configurations use a three axis antenna pedestal for full hemispherical coverage. ORIGINAL 2-18
NTP 2 SECTION 3 (B) a. Surface Ship APG. Each OE-501/USC-38(V) surface ship APG consists of a three-axis antenna pedestal with a 34.5-inch dish, a low noise amplifier (LNA), a down converter, and a radome. Two antenna systems are required to compensate for shipboard obstructions and superstructure masking of the satellite. The antenna pedestals contain redundant gyros to stabilize the antennas, correcting for platform motion due to adverse sea conditions. The LNA and down converters are used to amplify and frequency down convert received RF signals. The radome is a rigid fiberglass structure that protects the antenna from the effects of the environment. A deck hatch provides access through the antenna platform to the antenna enclosed in the radome. Transmission of RF signals rely on the specified type of waveguide used and the length of the waveguide run between the output of the HPA and the antenna pedestal in order to meet EIRP requirements. A waveguide switch is used in the ship terminal to send the HPA output signal to the active antenna. A fast-transfer mechanical switch, operating under full power, decreases the power to one antenna while it increases the power to the other. During signal transmission, RF signals between 43.5 and 45.5 GHz are fed directly from the HPA to one of the two antennas through the antenna waveguide switch. The TCP determines which antenna to select according to the relative orientation of the ship to the satellite. During signal reception, RF signals between 20.2 and 21.2 GHz are received by the antenna and fed to the LNA for amplification. The amplified signals are then frequency down converted to a 7.4 GHz intermediate frequency (IF) by the down converter, and fed to the MWP. For maximum receiver sensitivity, the 20 GHz LNA, which uses low-noise field-effect transistors (FETs), is mounted on the back side of the antenna dish. Selected surface-ship classes (CV/CVN, CG/CGN, DD/DDG, LCC/AGF, LHA/LHD/LPH, LPD/LSD, and MCS) will receive an antenna enhancement as part of the MDR Program Upgrade. A new 4.5-foot antenna system, that incorporates a quartz ratesensor gyro with an integrated accelerometer and uses gimbal scan vice conical scan tracking, will be replacing the original 34.5-inch antenna. This new antenna system uses the same-size antenna foundation, but it will require a new radome foundation. In many cases, this may mean that the foundations will have to be relocated to clear surrounding obstructions. b. Submarine APG. The OE-499/USC-38(V) submarine APG also uses a three-axis configuration, however one with a much smaller 5.5-inch antenna dish, that is housed on top of the Type 8, Mod 3 periscope. Dual-channel rotary joints at 20/40 GHz are used for three-axis mobility. The LNA is the same as that used in the surface ship and shore terminals, and it is also mounted behind the antenna feed. Due to submarine limited space considerations, the down converter is located at the base of the pedestal. Because the submarine antenna has a wider beamwidth than the other EHF terminals, it is pointed open-loop by the TCP using calculations that are based on the platform’s location provided by the Ship Inertial Navigation System (SINS), the Mk-19 gyrocompass, and satellite ephemeris data. A CW-1234/USC-38(V) radome is provided to protect the antenna pedestal from outside environmental conditions. The HPA RF signal to the antenna is obtained via a low-loss circular waveguide in the periscope. An autocoupler, at the base of the periscope, provides the mating connection when the Type 8 scope has been raised to provide a RF transmission line to the APG, which rests on a base plate on top of the scope. The Q-band mode transducer provides the mode transition from the rectangular waveguide run in the Type 8 scope to the circular waveguide run in the APG. The terminal does not transmit until the autocoupler is engaged.
ORIGINAL 2-19
NTP 2 SECTION 3 (B) c. Shore-based APG. The OE-500/USC-38(V) shore APG is very similar to the shipboard unit, differing only in the size of the antenna dish (shore is 6 feet), the size of the associated CW-1233/USC-38(V) radome, the riser base, and the deletion of the accelerometer. Additionally, this antenna dish provides an increase of approximately 10 dBW in EIRP and gain/transmit (G/T) over that of shipboard APG. The shore terminal’s elevation angle is limited to 0o to 90o which permits the use of the surface ship pedestal to support the 6-foot diameter antenna dish. The antenna pedestal is also driven by the same servo-amplifiers that are used in the shipboard APCU arrangement. Additionally, the pedestal waveguides, cables, electronics feed, and subreflector are identical to that of the surface ship system. Similar to the situation with selected surface-ship MDR Program Upgrades, numerous shore installations will also receive a new extended-height EHF antenna for obtaining access to the new Milstar II satellites. The new 10-foot antenna will be replacing the 6-foot originally-installed antennas at the NCTAMSs, and selected alternate-shore sites. This new antenna also incorporates the quartz rate-sensor gyro, as well as the gimbal scan vice the conical-scan tracking. This new antenna system uses the same size antenna foundation, but it will require a new radome. In most cases, this may mean that the tower will have to be reinforced to accommodate the increased weight and size. B. Ancillary Systems. Although the following ancillary equipment are not part of the AN/USC-38(V) family of terminals, they are included with the installation of a terminal, as required to support specific functions and operations. Support systems provide environmental control, antenna waveguide pressurization, ship attitude and position information, as well as timing and electrical interface. 1. Power Distribution System. The AN/USC-38(V) family of terminals requires 440 Vac, three-phase, 60 Hz platform/facility power to support CEG and HPA operation, and 115 Vac, single-phase, 60 Hz power to the antenna heaters (surface ship and shore installations only). Antenna power is received directly from the CEG. Power panels provide power distribution to the required equipment. 2. Chilled Water System. A water cooling system is required to provide heat dissipation to the AN/USC-38(V) family of terminals. In the CEG, chilled water from the cooling system flows through the heat exchanger at the rate of 1.4 gallons per minute; in an emergency, the front exhaust panel can be opened to allow air-to-air cooling. In the HPA, chilled water from the water cooling system is fed into the input coolant port on top of the HPA at the rate of 2 gallons per minute. The water cooling system is provided through either a dedicated distilled water system (varies at each installation) or a platform/facility chilled water system (varies by ship class). 3. Dry Air System. Dry air is supplied at approximately 2 pounds per square inch (psi) to prevent moisture buildup in antenna waveguides for surface ship and shore terminal installations. Nitrogen, pressurized to approximately 5 psi, is similarly used aboard submarines to maintain the required environment inside the periscope and to purge the waveguide run. 4. Cesium Frequency Standard. The O-1695A/U Cesium beam frequency standard is a rugged, small-sized, self-contained frequency reference that can be used by the CEG in lieu ORIGINAL 2-20
NTP 2 SECTION 3 (B) of the MWP internal rubidium frequency standard. Available outputs include 1 and 5 MHz, and 100 kHz. For selected surface ship/shore installations, and all submarines, a Cesium standard also provides a 50 bps time of day (TOD) output and a 1 pulse per second accurate TOD signal. 5. MK-19 Gyrocompass. The MK-19 is a stable reference unit that provides roll, pitch, and heading information. Synchronization signal amplifiers, normally an integral part of this equipment, are used by multiple loads remotely located in other shipboard equipment. The MK-19 can also used as a backup for the SINS. 6. SINS. As the name implies, SINS is an inertial navigation system that provides highly accurate and continuous measurement of shipboard attitude, position, and speed. 7. Submarine Type 8 (B/J versions) Periscope. The Type 8 scope is the primary equipment interface between the CEG (antenna position signals and the receive signal), the HPA (transmit signal), and the submarine’s antenna mounted atop the periscope. The transmit circular waveguide from the HPA connects to the periscope EHF autocoupler assembly near the base of the scope. The autocoupler prevents transmission unless the scope is fully raised. The received IF is passed through to the CEG via a semi-rigid coaxial cable inside the scope, then on to the electronic and electrical adapter, the dip loop, and scope well-junction box. 8. Alarm Panel. An alarm panel is used in most ship and shore installations to provide on-line monitoring of support system performance. This includes dry air pressure and moisture content; HPA and CEG cooling water temperature and flow rate; and external TOD signal status and synchro amplifier signal quality from the ship’s navigation system, that are determined for each installation based upon the support system setup. Various alarm switchboard panels are used for different installations. C. LDR Terminal Configurations. There are many physical similarities shared by the three Navy terminal variants, but an important distinction among them is the number and types of LDR circuits each supports. Every circuit terminates in one of the four terminal input/output (I/O) ports described below: •
Primary Ports. The primary ports have transmit and receive capabilities at data rates of 75, 150, 300, 600, 1200, and 2400 bps. The ports can be configured for full duplex (FDX), half duplex (HDX), receive-over-transmit (ROX), or transmitover-receive (XOR) protocols, and can be used for either network or PTP transmissions. The data terminal equipment (DTE) ports interface synchronously to all peripheral equipment.
•
Secondary Ports. The secondary ports have transmit and receive capabilities at data rates of 75, 150, and 300 bps. These ports can be configured for FDX, HDX, ROX, and XOR protocols, and can be used for either network or PTP transmissions. These ports also interface synchronous to all DTE.
ORIGINAL 2-21
•
•
NTP 2 SECTION 3 (B) Receive-Only Ports. The receive-only ports have a receive capability at data rates of 75, 150, 300, 600, 1200, and 2400 bps. The ports can be used for reception on primary or secondary networks, PTP calls, or on broadcasts. The ports interface synchronously with all DTE. Auxiliary TTY Port. The auxiliary TTY port is used for loading adaptation data, ephemeris data, BLACK keys, and submarine reportback messages into the terminal; it is also used for outputting the dayfile from the terminal to the TTY. The port operates at either 75 or 1200 bps, and supports data formats of either asynchronous American Standard Code for Information Interchange (ASCII) or Baudot.
1. AN/USC-38(V)1 Submarine Terminal. The submarine terminal was designed for installation aboard selected classes of nuclear-powered attack and ballistic missile submarines (SSNs/SSBNs), and consists of a CEG, HPA, and an APG that has a 5.5-inch diameter dish antenna mounted atop the Type 8 periscope mast. Other components of this installation include interfaces with ancillary devices for time and frequency-standard inputs, navigation inputs, and baseband I/O equipment. The AN/USC-38(V)1 terminal has two primary, two secondary, two receive-only ports, and one auxiliary-TTY port. This terminal provides I/O signals for up to 4 ports to transmit/receive and 2 ports to receive-only voice and data communications using standard baseband equipment. All ports that interface with the DTE are BLACK. User equipment includes: the AN/UGC-136CX TTY set that is interconnected via the KG-84A general purpose encryption device to provide secure data; the ANDVT that is interconnected via the C-10315/U remote switching control unit to provide secure voice, and the MK-1, MK-2, BSY-1 and -2 Combat Control System (CCS) for tactical command information. The KGV-11A is used for terminal TRANSEC. 2. AN/USC-38(V)2 Surface Ship Terminal. The surface ship terminal was designed to be installed aboard fleet flagships, aircraft carriers (CV/CVN), cruisers, and destroyers, as well as other selected amphibious and auxiliary platforms. The fleet flagships (e.g., amphibious command ships, miscellaneous command ships (LCC and AGF classes), and the CV/CVN classes) operate with dual APG terminal configurations. The surface ship installations include the same components as those used in the submarine installations, but differ by having one additional APG, and a waveguide switch. The two APG terminal configuration permits switching from one antenna to the other, as required, to reduce the effects of antenna masking caused by the ship’s superstructure. Another advantage of a two-APG installation is that if one APG malfunctions, an installed manual override switch permits the use of the operable antenna until the malfunctioning APG can be repaired; this may however require some ship maneuvering in order to eliminate any antenna masking by the superstructure. Each surface ship APG installation has a 34.5-inch dish antenna mounted on a gimbaled pedestal. A waveguide switch is used to distribute the output signals of the HPA to the active APG. All terminal ports interfacing with the DTE are BLACK. The AN/USC-38(V)2 terminal has four primary, four secondary, four receive-only, and one auxiliary-TTY ports. The auxiliary TTY port is used for entering data (adaptation, ephemera, BLACK keys, etc.) into or receiving data from the terminal memory. This port is capable of either a 75 or 1200 bps data rate, and available formats are Baudot or ASCII. This terminal provides I/O signals for up to 8 ports to transmit/receive, and 4 ORIGINAL 2-22
NTP 2 SECTION 3 (B) ports to receive only voice and data communications using standard baseband equipment. The surface ship installation user equipment includes: the AN/UGC-143A(V) or B(V) teleprinter that is interconnected via the KG-84A crypto device to provide secure data, and the ANDVT that is interconnected via the audio subsystem to provide secure voice. The KGV-11A is used for TRANSEC, and the NECC, TDPs, and KG-84A’s for over-the-horizon targeting (OTH-T) via the IXS networks. 3. AN/USC-38(V)3 Shore Terminal. The shore-based terminal is installed at the various NCTAMSs, and other selected shore sites worldwide, and it is equipped with a 6-ft. diameter dish antenna. The functions performed by the components of the shore terminal are also identical to those of the surface ship terminal, but only one APG and associated control circuitry are used. The number of terminal ports, their functional usage, and capabilities is identical to that of the AN/USC-38(V)2 surface ship terminal. Additionally, the TD-1150/USC multiplexer is used to support the FSB transmission. Table 2-5 provides a summary comparison of Navy EHF LDR terminal components. EHF Terminal Designations
Platform Classes
Equipment Suite
AN/USC-38(V)1
Submarine
CEG, HPA, & single-APG
AN/USC-38(V)2
Surface Ship
CEG, HPA, & dual-APGs
AN/USC-38(V)3
Shore, Fixed
CEG, HPA, & single-APG
User Equipments AN/UGC-136CX TTY via KG-84A for secure data; ANDVT via C-10315/U for secure voice; KGV-11A for TRANSEC; MK-1, MK-2, BSY-1 and –2 CCS for tactical command information. AN/UGC-143A(V) or B(V) teleprinter via KG-84A for secure data; ANDVT via SAS for secure voice; KGV-11A for TRANSEC; and the NECC, TDPs, and KG-84As for OTH-T via the IXS nets. AN/UGC-143A(V) or B(V) teleprinter via KG-84A for secure data; ANDVT via SAS for secure voice; KGV-11A for TRANSEC; and the NECC, TDPs, and KG-84As for OTH-T via the IXS nets; plus the TD1150/USC mux for FSB transmission.
Navy EHF LDR Terminal Comparisons. Table 2-5 D. NESP AN/USC-38(V) Terminal MDR Upgrades. The Navy’s AN/USC-38(V)1 through (V)3 family of legacy EHF terminals will be modified and upgraded as part of the terminal’s MDR Program; these modified and upgraded terminals are designated as AN/USC-38(V)4 through AN/USC-38(V)8. And, in addition to the upgrade kits for the original three existing terminals, there will be a series of brand new terminals designated as AN/USC-38(V)9 through AN/USC-38(V)12 being developed. Coming from the NESP terminal program office, these all-new terminals are referred to as the AN/USC-38(V) Follow-on Terminals (FOT). Existing terminal modifications include installing a package upgrade that consists of a CEG second processor drawer; adding 16 data ports to the existing 12 LDR data ports in surface ship and shore terminals, which includes: one 1.544 Mbps asynchronous port; one 16 kbps four-wireORIGINAL 2-23
NTP 2 SECTION 3 (B) conditioned diphase Digital Secure Voice Terminal (DSVT) port; fourteen ports which support synchronous and balanced MIL-STD 188-114A interfaces, that are capable of communications in full or half duplex at data rates of 4.8 to 1544 kbps; and in some selected cases, installing larger antenna assemblies to ashore sites and surface ship platforms to provide increased gain. The AN/USC-38(V)1 submarine terminal is being upgraded as part of the Submarine High-Data Rate (SUB HDR) program, which includes the provision for a 64 kbps satellite link. This program will enhance the EHF (both LDR and MDR), military SHF, and commercial SHF/Global Broadcast Service (GBS) communications capabilities of SSN/SSBN class submarines. The SUB HDR Program will provide high-capacity (4.8 to 256 kbps) communications in the EHF and SHF bands, with the capability to transmit and receive voice, data, video, and imagery in any one band at a time. Although some AJ capability is sacrificed when compared to EHF LDR, the MDR system still retains AJ performance significantly better than that of other transponder-based SATCOM systems. Even though EHF MDR services are an adjunct to those available with the LDR system, the SRB feature is not supported with MDR, and MDR broadcast service does not include the ability to crossband the FSB to UHF. The implementation of the MDR capability will not degrade the performance of or communications with existing AN/USC-38(V) LDR terminals. Modified terminals will be backward compatible with the FEP, UFO/E and UFO/EE, and Milstar I LDR satellites, and continue to support terminal broadcasting, networks, and PTP calls. The NECC will continue to be a critical component in most networks. A brief summary of major AN/USC-38(V) terminal MDR upgrades for surface ship, submarine (SUB HDR), and shore-based terminals follows, while Table 2-6 provides a summary comparison of all the AN/USC-38(V) family of terminals. 1. NCTAMSs and alternate shore sites: MDR terminal upgrade, and antenna upgrade to 10-foot antenna, which includes terminals at the NCTAMS’s sites that support the CINCs, FLTCINCs, and SUBOPAUTHs. 2. Integrated Undersea Surveillance System (IUSS) shore sites: MDR terminal upgrade, while retaining current 6-foot antenna. 3. Submarine Group Commander (COMSUBGRU) shore sites: MDR terminal upgrade, while retaining current 6-foot antenna. 4.
Other shore sites: No MDR upgrades.
5. CV/CVN, CG/CGN, DD/DDG, LCC/AGF, LHA/LHD/LPH, and LPD/LSD class ships: MDR terminal upgrade, and antenna upgrade to 4.5-foot antenna.
ORIGINAL 2-24
NTP 2 SECTION 3 (B) EHF Terminal Designations
Platform
Antenna Size
LDR/MDR Ports
LDR Port Mix and Data Rates 2 Primary @ 75,150,300,600,1200,2400 bps 2 Secondary @ 75,150,and 300 bps 2 Rec. Only @ 75,150,300,600,1200,2400 bps 1 Aux. TTY @ 75, or 1200 bps 4 Primary @ 75,150,300,600,1200,2400 bps 4 Secondary @ 75,150,and 300 bps 4 Rec. Only @ 75,150,300,600,1200,2400 bps 1 Aux. TTY @ 75, or 1200 bps 4 Primary @ 75,150,300,600,1200,2400 bps 4 Secondary @ 75,150,and 300 bps 4 Rec. Only @ 75,150,300,600,1200,2400 bps 1 Aux. TTY @ 75, or 1200 bps
AN/USC-38(V)1
Submarine
5.5 inch
6/0
AN/USC-38(V)2
Surface Ship
34.5 inch
12/0
AN/USC-38(V)3
Shore, Fixed
6 ft.
12/0
AN/USC-38(V)4
Surface Ship
3 ft.
12/16
Same as AN/USC-38(V)2
AN/USC-38(V)5
Surface Ship
4.5 ft.
12/16
Same as AN/USC-38(V)2
AN/USC-38(V)6
Shore, Fixed
6 ft.
12/16
Same as AN/USC-38(V)3
AN/USC-38(V)7
Shore, Fixed
10 ft.
12/16
Same as AN/USC-38(V)3
AN/USC-38(V)8
Submarine
5.5/16 inch1
6/16
Same as AN/USC-38(V)1
2
AN/USC-38(V)9
Ship
4.5 ft.
14
AN/USC-38(V)10
Shore
10 ft.
142
AN/USC-38(V)11
SSN 688
16 inch3
142
AN/USC-38(V)12
SSN 744
16 inch3
142
AN/USC-38(V)3 with PEP mods
Ashore, Fixed
6 ft.
12/16
AN/TSC-154, SMART-T for USMC
Ashore, Mobile
4.5 ft.
4/12
Same as AN/USC-38(V)3 4 LDR use @ 75, 300, 600, 1200, 2400 bps 4 MDR @ 4.8 – 256 kbps 2 MDR @ 4.8 – 1.544 kbps 2 MDR @ 2.4 – 64 kbps 4 MDR @ 128 – 1024 kbps
Terminals that have 1 – Asynchronous T-1 (1.544 Mbps) port 16 MDR ports are 1 – 16 kbps Digital Secure Voice Terminal (DSVT) port configured as: 14 – MIL-STD-188-114A ports Notes: (1) Six subs equipped with 5.5- and 16-inch antennas (2) These are Virtual Ports that can be used for either LDR or MDR. (3) All (V)11 and (V)12 terminals equipped with 16-inch antennas.
Summary of EHF Terminal Comparisons Table 2-6. 6.
AO/AOE: MDR terminal upgrade, while retaining current 3-foot antenna.
7.
SSN/SSBN: SUB HDR program terminal upgrade, with a 16-inch antenna
upgrade. E. All-New AN/USC-38(V)9 thruogh (V)12 FOTs. FOTs will be LDR/MDR capable, with future potential (contract options) for multiband capabilities (i.e., EHF, SHF, and GBS). These terminals incorporate the functionality of the legacy AN/USC-38(V) terminals, as well as the upgrade MDR Applique into one CEG drawer. The FOT also replaces the legacy terminal’s ORIGINAL 2-25
NTP 2 SECTION 3 (B) HPA (one rack) with a Solid State Amplifier (SSA) located on the antenna pedestal, thus negating the need for electronic cooling water, dry-air system, or waveguide. It uses nondevelopmental item (NDI), commercial off-the-shelf (COTS), and commercial-based technology in an open system architecture (OSA). The FOTs terminal ports are Virtual Ports; they can be used for either LDR or MDR subject to the following restrictions. When being used for LDR and MDR simultaneously, the terminal is limited to four LDR and four MDR ports, or a total of eight ports. When being used for either all LDR only or all MDR only, the number of ports available for use is unlimited (only limited by the wave form) up to the terminal’s maximum number of 14 ports. The NESP FOT nomenclature designations are as follows: • • • •
AN/USC-38(V)9 Ship AN/USC-38(V)10 Shore AN/USC-38(V)11 Submarine, SSN 688 class AN/USC-38(V)12 Submarine, SSN 744 class
F. USMC EHF Secure Mobile AJ Reliable Terminal (SMART-T). Designated the AN/TSC-154, the SMART-T was designed to respond to the communications requirements of ground-based troops, while providing secure, AJ, mobile, and reliable beyond line-of-sight (BLOS) communications with voice-quality recognition and LPI/LPD protection. Requiring only a 30-minute or less setup/tear-down time, this terminal interfaces with FEP, Milstar, UFO/E, and UFO/EE satellites, and it operates at 75 to 2400 bps (low-speed) and 16 kbps to 1.024 Mbps (high-speed) data rates. It has four ports to support MSE digital transmission group data streams (256, 512, 1024, or 4096 kbps full duplex) and eight ports which support EHF transmit/receive data rates of 16, 32, 64, 128, or 256 kbps; two of these eight ports also support 1.544 Mbps. Two of the eight ports support half duplex, while all eight support full duplex. Whether installed in a high-mobility multipurpose wheeled vehicle (HMMWV) or in an existing communications shelter, SMART-T has been designed to support the CINC’s requirements for transportable LDR/MDR EHF communications for special operations (SPECOPS) forces, Marine Corps command elements, and various other tactical units. The Marine Corps Air Ground Task Force (MAGTF) SMART-Ts will be deployed with communications battalions and companies, Marine Air Wing communication squadrons and infantry regiments, and will serve as the primary means of handling high-precedence record and voice traffic. The Marine Corps anticipates procuring a total of 25 SMART-T terminals. Figure 2-5 shows the AN/TSC-154 SMART-T. G. PEP Terminal Modifications and Shore Gateway Placement. While the Navydeveloped AN/USC-38(V) family of EHF terminals was designated to be compatible with the PEP’s communications package, modifications were needed before these terminals could operate with a payload in a Molniya orbit. To operate with PEP, all user terminals, including those used for T&C, had to be modified to accommodate the following: •
Molniya orbital tracking (i.e., ephemeris format changes, spatial tracking, Doppler shift, etc.);
ORIGINAL 2-26
NTP 2 SECTION 3 (B)
Figure 2-5 AN/TSC-154 SMART-T •
Downlink hopping over half the normal EHF bandwidth (500-MHz vice the EHF norm of l-GHz);
•
Screen software changes that implement the additional downlink modulation modes (FSK-2 HHR through FSK-32 HHR, and FSK-2 LHR);
•
Software changes that implement the spot beam priority feature. Those terminals that have not been so modified will still be capable of moving the spot beam, but will do so only at the lowest priority (priority 0);
The primary AN/USC-38(V)3 PEP gateway terminal is located at the Commander, Submarine Group Nine (COMSUBGRU 9) facility in Bangor, WA; the existing EHF terminal at Naval Computer and Telecommunications Station (NCTS) Brunswick, ME, serves as the alternate PEP gateway terminal. These terminals provide communications support for the naval components of the CINCs, CINC U.S. Joint Forces Command (USCINCJFCOM) and CINC, U.S. Pacific Command (USCINCPAC). The primary mission of the Bangor gateway terminal is to provide connectivity between the Submarine Operating Authorities (SUBOPAUTH) at Commander, Submarine Forces Atlantic (COMSUBLANT) Norfolk, VA, and Commander Submarine Forces Pacific (COMSUBPAC) Honolulu, HI, and their respective submarine forces ORIGINAL 2-27
NTP 2 SECTION 3 (B) operating in the North Polar Region. Depending on where the satellite is actually in orbit, this terminal is able to access PEP from 11-14 hours per day with an elevation angle of 20o or higher, or 13-14 hours per day with an elevation angle of 15o or higher. In the event the gateway terminal at Bangor becomes inoperative, restoral connectivity for this terminal can be obtained via the AN/USC-38(V)3 at Brunswick that is modified to operate with PEP. The Brunswick terminal is capable of operating with PEP from 7-12 hours per day with a 20o look angle, or 7-13 hours per day with a 15o look angle. The placement of these terminals was predicated on the requirement to be in the northern-most position possible that also permits easy access to the CONUS-based telecommunications infrastructure. H. EHF Service Precedence and Terminal Privilege Levels. Precedence is an attribute of the particular communication service (network or PTP) that is selected by the user EHF terminal at the time the service is initiated. Precedence is only exercised when spacesegment resources are limited, and no alternative resources are available. When this occurs, the satellite preempts lower-precedence services to satisfy the higher-precedence requirements. Services of equal or higher precedence to that of the requesting service will not be preempted. Table 2-7 lists the EHF SATCOM precedence level conventions for the Navy. NAVY PRECEDENCE LEVELS UFO/E, UFO/EE & Milstar
FEP
0(Highest) 1 2 3
Y Z O P
Precedence Level Conventions Table 2-7 A terminal’s privilege level determines that terminal’s ability to perform access control functions, such as setting up, modifying, and terminating services, as well as moving a spot beam. The terminal’s TRANSEC key is used to determine its privilege level. As an example, the UFO/E and UFO/EE space packages recognize three levels of privilege: high, medium, and low (also referred to as privilege levels 1, 2, and 3 respectively). A low-privilege terminal may only initiate PTP calls, and join (but not modify) existing networks. A mediumprivilege terminal may activate, join, or modify networks; move a spot beam; and initiate PTP calls. A high-privilege terminal is capable of all the features of the medium-privilege terminal, as well as being capable of activating the Telemetry and Commanding Networks. Table 2-8 summarizes the various access control functions allowed by privilege level for all of the EHF SATCOM systems. 204.
EHF BASEBAND SYSTEMS
This section describes the various types of baseband equipment, jointly established as interoperable devices, to be used with EHF MILSATCOM systems. A variety of processors, multiplexers, cryptographic and teleprinter equipment, etc. are used to support the routing,
ORIGINAL 2-28
NTP 2 SECTION 3 (B) PRIVILEGE LEVELS Access Control Function
Applicable EHF Satellites Activate/Deactivate PTP Calls Join Networks in Active Beam Activate/Modify/Terminate Nets Reposition Spot Beam
1
2
3
High Milstar, UFO/E, UFO/EE, PEP Yes Yes
Low Milstar, UFO/E, UFO/EE, PEP, FEP (“unrestricted”) Yes Yes
Null Milstar, UFO/E, UFO/EE, PEP, FEP (“restricted”) Yes (Milstar only) Yes
Yes
Yes
No
Yes Yes No Yes Activate/Modify/Terminate T&C (UFO/E, UFO/EE & No No Nets PEP only) NOTE: Terminal privilege designations for SMART-T terminals are different. (For SMART-Ts, high privilege is designated by a "2", low privilege by a "1" and Null privilege by a "0".)
Access Control Allowed by Privilege Table 2-8 distribution, and controlling of the signal path from the various subscribers to the AN/USC-38(V) family of terminals. A.
Control Devices and Processors
1. NECC. The NECC is a communication server used to control the transfer of information between subscribers on surface ships, submarines, and shore sites. The NECC uses EHF SATCOM connectivity to support tactical data IXS requirements of TDPs. The NECC consists of a VME computer, video-display monitor, and keyboard/trackball. Typically, shipboard platforms/shore sites will be provided with a 19-inch color monitor, keyboard/trackball, NECC chassis, and an uninterrupted power supply (UPS). However, a Tactical Advanced Computer, third or fourth generation (TAC-3, or TAC-4), or other comparable computer system interface, may be used to provide the operator interface. Additionally, a printer is used to maintain a hard copy log. The VME computer consists of a general purpose equipment chassis that can be tailored to individual system requirements through the VME card configuration setup. The VME chassis has one system processor circuit card, one video circuit card, up to 14 circuit card slots that can be populated with the subsystem processor cards (PTI-151A) and ECA circuit cards to provide encryption/decryption of data. The quantity of subsystem processor cards is a function of the IXS traffic requirements. The functionality of the NECC has been subsumed by the ADNS program. 2. Generic Front End Communications Processor (GFCP). The GFCP is a communication processor which allows multiple TDPs to share common ON-143(V)6 tactical data communications on the Officer-in-Tactical Command Information Exchange Subsystem (OTCIXS) and Tactical Data Information Exchange Subsystem (TADIXS) networks. The GFCP also interfaces with interface design specification 8648 TDPs, which includes the Tomahawk ORIGINAL 2-29
NTP 2 SECTION 3 (B) Weapon Control System (TWCS). There are two variants of the GFCP, designated as GFCP I and GFCP II. GFCP I consists of a 5-slot chassis, whereas GFCP II consists of a 12-slot VME bus chassis populated with three, 6U-size, double-high VME boards. The GFCP II can add, modify, and delete interfaces and routes, control data routing to selected systems, control format types on messages that are routed to TDPs, and support KG-84A covered communications. 3. CP-2112/USC-38(V) Submarine Reportback Processor (SRBP). Designated shore-based SRB receptor sites are equipped with the SRBP that consists of the CP-2112/USC38(V) unit, a C-11917/USC-38(V) terminal control unit (TCU), and a Navy Standard Teleprinter Ashore (NSTA). When connected to an AN/USC-38(V)3 terminal CEG receive-only 75 bps data port, the SRBP provides for the receipt and processing of Milstar SRB messages from tactical submarine units back to the SUBOPAUTH ashore. The SRBP also provides for the storage (in nonvolatile memory) of up to 100 SRB messages. The received synchronous data stream includes the originator’s ID, the last block indicator, message data, flush bits, and parity. Display of the SRB message is provided for at the processor, along with printout capabilities at an auxiliary TTY. B.
Multiplexers
1. TD-1150/USC Time Division Multiplexer (TDM). The TD-1150/USC TDM accepts up to fifteen 75 bps data channels. Each input is temporarily stored in a separate memory. The multiplexer then samples the channel memories sequentially, inserting the input information from each teletype into the correct time slot, which it then multiplexes into a single 1200 bps output data stream. The TD-1150/USC TDM is used with the FSB subsystem. 2. AN/FCC-100(V)4 Multiplexer Set. The AN/FCC-100(V)4 is a low-speed timedivision multiplexer (LSTDM), with FDX transmit and receive capabilities. The unit operates at speeds up to 256 bps and provides 16 ports capable of handling synchronous, asynchronous, isochronous (transitional encoded), diphase data transmission and pulse code modulation (PCM), and continuous variable slope delta (CVSD) modulation analog data transmissions. It is capable of both sending and receiving data, voice, and telemetry and signaling information in the form of a single mission bit stream. The single mission bit stream is capable of handling up to 16 separate channels. A TDM principle is employed to place all channels onto a single synchronous mission bit stream. The AN/FCC-100(V)4 is capable of performing multiplexing, timing, control synchronization, framing, monitoring, and alarm reporting. Timing for the AN/FCC-100(V)4 is provided by a highly accurate, internal oscillator or from an external source. The AN/FCC-100(V)4 is configured for use at shore installations to satisfy specific communication system requirements. Downline loading capability permits an operator to configure a remote AN/FCC-100(V)4 from a central unit, thereby eliminating the need for an operator at a remote site during reconfiguration. 3. VERSIMUX. The VERSIMUX is a fiber-optic multiplexer. The digital port cards may be used to provide either a modem link, interface extension or interface conversion, as well as a fiber-optic link. The Channel Access Master (CAM-1) card accepts the transmit data signal from all the port cards, multiplexes the signal together, and transmits the combined signal to the remote unit over the fiber-optic cable. At the remote unit, the combined signal is ORIGINAL 2-30
NTP 2 SECTION 3 (B) demultiplexed and applied to the appropriate port cards. The VERSIMUX may also be used with fiber-optic drop cards to extend the fiber-optic link beyond the VERSIMUX location. The VERSIMUX may be operated at either a high-speed or a low-speed data mode. In the high-speed mode, the maximum number of available ports is 14, and the maximum port data rate is 76.8 kbps. In the low-speed mode, the maximum number of available ports is 30, and the maximum port data rate is 38.4 kbps. 4. STeL 9610/9620 Digital Link Interface (DLI). The DLI enhances the capability of the Secure Telephone Unit, third generation (STU-III) by providing the required interface for both voice and data communications over any synchronous 2400 bps narrowband digital data link, including HF through EHF frequencies. This unit communicates with the STU-III through a RJ11C, 2 wire circuit interface, and it converts STU-III analog phase-shift keying (PSK) format to a standard 2400 bps serial digital data stream. The DLI supports digital voice, clear or secure voice, as well as digital data and facsimile. The unit can also support HDX and FDX communications in support of PTP, mobile-to-gateway, or gateway-to-gateway operations. C.
Teleprinters
1. AN/UGC-143A(V)4 Navy Standard Teleprinter (NST). The NST is a militarized unit, has an automatic send/receive (ASR) configuration, and is normally employed in shipboard applications. The NST consists of an electronic unit, printer unit, keyboard/display unit, and bulk storage unit. The NST’s modular design makes it useable in several different configurations, including receive only (with or without bulk storage), send and receive without bulk storage using the keyboard, or send and receive automatically with bulk storage. It is capable of operation in several different modes, including simplex, HDX, FDX, asynchronous, synchronous, Baudot, and ASCII. The NST throughput is 126 characters per second based on 80-character lines, including single-line advances. It line prints data at nominally 180 characters per second. It can transmit or receive data rates from 45.5 to 2400 bps Baudot and 45.5 to 9600 bps ASCII. The various configurations provide for information preparation, editing, printing, receiving serial data, buffering of information in volatile memory, and information storage (archiving). 2. NSTA. The NSTA is a desktop tactical computer (DTC), with its associated commercial printer, that is normally installed at shore-based sites. The DTC provides 32-bit processing power, while maintaining backward compatibility with older hardware and software. The DTC is equipped with several features, including one high-capacity disk drive, and one dualfloppy-disk drive which contains a 3.5-inch 1.44M/720K drive, and one 5.25-inch 1.2M/360K drive. A local bus ultra video graphics adapter (VGA) video is built into the system board to support high-resolution display modes beyond standard VGA. The software package used to support operations is EHFNOW, a multicircuit package which is capable of interfacing up to four FDX circuits to one DTC. 3. AN/UGC-136CX Teleprinter Set (Bulk Storage). The AN/UGC-136CX is a ruggedized send-and-receive teleprinter, controlled by a microprocessor with an internal solidstate memory, and full-message composition and editing capabilities; it prints data at a nominal 120 characters per second (1200 bps). It can transmit or receive at data rates from 50 to 9600 bps ORIGINAL 2-31
NTP 2 SECTION 3 (B) to or from the message storage memory, and can operate in switch-selectable Baudot or ASCII codes. The storage capacity of 64 messages or 256K random access memory (RAM), permits the short-term storage of received messages while the operator simultaneously composes and stores outgoing messages for transmission. Multiple communication ports also provide a bulk-storage device compatibility. D.
Cryptographic Equipment
1. KG-84A General Purpose Encryption Device. The KG-84A accepts low-level serial plain-text data from various compatible input/output devices or data adapters. These devices may present the data as a continuous bit stream synchronized at various clock frequencies ranging from 50 bps to 64 kbps. Serial asynchronous data in specified formats, such as that from a teletypewriter, and at various stepping rates from 50 to 9600 bps, can be accepted by this unit. The KG-84A is intended for use in network, PTP, and broadcast communication services. It is capable of FDX and HDX operation. Variables are loaded and stored in the unit from a fill device connected to a front panel connector. 2. KYV-5 Communications Security (COMSEC) Module. The KYV-5 is a plugin cryptographic unit which is attached to the front of the CV-3591(P)/U (ANDVT unit). It can be operated in either a network or PTP mode. The KYV-5 provides encryption/decryption of all transmit and receive signals processed by the CV-3591(P)/U. A connector on the front panel of the KYV-5 permits connection of external fill devices. The KYV-5 keys may be loaded via the module’s 6-pin fill connector, or encrypted keys may be loaded using SAVILLE Advanced Remote Keying (SARK) over-the-air (OTA) techniques. 3. KGV-11A. The KGV-11A is a general purpose COMSEC/TRANSEC device designed for integration into tactical and strategic, survivable, TEMPEST-protected host communication systems. The Navy intends to use the KGV-11A only in the TRANSEC application. In the TRANSEC mode, the KGV-11A requires no OTA synchronization to supply a secure stream of bits to drive the controlling host’s terminal AJ algorithm. Other features include: protecting all levels of classification, storage of up to eight RED keys, automatic key rollover at the end of a cryptoperiod, and OTA rekey (OTAR) capability. The KGV-11A has two standby power modes. The device can accept keys in a dynamic standby or it can retain previously loaded keys using minimal power while in the quiescent standby mode. The electronic generator provides TRANSEC functions necessary for frequency hopping, pattern generation, access and network control. The KGV-11A is housed directly on the front panel of the CEG to interface with the modem function. 4. KOI-18 Cryptographic Fill Device. The KOI-18 fill device is a cryptographic multipurpose translator recorder used to enter key stream data into crypto devices (KG-84A, KGV-11A, KYV-5, among others) via a paper tape interface. It is a small, hand-held electromechanical unit that reads eight-level ASCII standard punched tape, and converts the information to a serial output. 5. KYK-13 Cryptographic Fill Device. The KYK-13 is a lightweight, hand-held, battery-operated, digital-storage device that contains six addressable 128-bit storage shift ORIGINAL 2-32
NTP 2 SECTION 3 (B) registers and associated control circuits. Variables can be loaded for long-term storage or transferred out nondestructively upon request; parity indication is provided for each variable loaded or transferred. Connection to the AN/USC-38(V) terminal is accomplished by direct connection, or by a fill cable through the KGV-11A. 6. KW-46 Cryptographic Device. The KW-46 is the standard crypto device used to encrypt the broadcast channels of the Navy’s FSB. The individual KW-46 encrypted data streams are multiplexed with streams from other networks that use the KG-84As configured for broadcast mode operations. This composite, multiplexed signal is then connected to the input of the AN/USC-38(V)3 terminal for uplink to either a UFO/E, UFO/EE, or Milstar satellite, where it is crossbanded to a UHF downlink to Navy surface ships and naval communication vans. 7. CYZ-10 Data Transfer Device (DTD). The DTD is a hand-held personal computer capable of electronically receiving, storing, and transferring keying material (KEYMAT). This equipment can store up to 1000 key segments and through specific software applications, emulate the KOI-18, KYK-13, and the KYX-15A (Net Control Device). The DTD is compatible with present and future cryptographic equipment and is part of the Navy’s Key Management System (NKMS). The DTD has an alphanumeric keyboard for inputing/displaying commands and other operator functions. Security protection and access control to the cryptographic functions of the DTD are provided by a removeable Crypto Ignition Key (CIK). 8. KIV-7 Embeddable KG-84 COMSEC Module. The KIV-7 is a compact, highperformance data COMSEC device that protects classified and sensitive digital data transmissions at data rates up to 1.544 Mbps. Utilizing the National Security Agency’s (NSA) WINDSTER key generator, the KIV-7 is interoperable with the Government standard KG-84, KG-84A, and KG-84C equipment in both the secure data and the OTAR modes of operation. This permits interoperability with large installed communities of users who have a significant sunk cost in the KG-84 family of COMSEC devices. The KIV-7 incorporates enhanced operational capabilities that support a wide range of user applications; protection is available for a broad spectrum of PTP, netted, and broadcast data links. Plain-text header bypass allows initial modem setup prior to secure traffic operation, without the need for system reconfiguration. An integrated remote control interface permits the management of up to 31 remote units by a single KIV-7 via an independent secure link. Advanced key management features support both the current key distribution system, and the emerging Electronic Key Management System (EKMS), while also providing the added flexibility necessary for managing operational keys. The KIV-7 fill interface is compatible with both the DS-101 (AN/CYZ-10 DTD) and the DS-102 (common fill) electronic keying devices, and storage for up to ten traffic encryption keys simplifies multinet communication. A removable CIK prevents unauthorized access, and protects all of the internally-stored keys. 9. Walburn family of Cryptographic Devices. The Walburn family of cryptographic devices consists of the KG-81, KG-94/94A, KG-95, and the KG-194/194A. This family of high-speed, bulk-encryption devices was developed primarily for the encryption of microwave trunks, high-speed landline circuits, video teleconferencing, and T-1 satellite channels for both tactical and nontactical applications.
ORIGINAL 2-33
NTP 2 SECTION 3 (B) a. KG-81. The KG-81 provides full-duplex encryption of digital trunks, and security for all classifications of digital data traffic. The KG-81 is compatible with the KG94/194, KG-94A/194A, and the KG-95. b. KG-94. The KG-94 is a rack-mounted device that provides fullduplex/simplex trunk encryption, and is installed in ground mobile units and/or sheltered environments. Compared to the KG-81, the KG-94 is more reliable, less expensive to produce, easier to build, and consists of plug-in circuit cards that are mounted in a TEMPEST-protective case. The KG-94 is cryptographically compatible with the KG-81, KG-194, KG-94A/194A, and KG-95 in traditional key modes at respective data rates. The second production of KG-94 equipment was designated the KG-194. c. KG-94A. The KG-94A is an environmentally repackaged, ruggedized version of the KG-94, which was designed for tactical trunk encryption applications. Second production equipment of the KG-94A was designated the KG-194A. The KG-94A can be mounted in a 19-inch rack, stack- or ground-mounted. d. KG-194. The KG-194 has emerged as the second-generation model of the KG-94. It is less costly, has remote keying capability, and implements FIREFLY COMSEC technology. KG-194s are used in Navy shore applications for wideband encryption of multichannel digital trunks, high-speed landline circuits, T-1 SATCOM channels, and loop groups in support of DISA microwave trunks. The KG-194 is compatible with the KG-81, KG94/94A/194A, and the KG-95 equipments, and provides cryptographic security for all classification levels. e. KG-194A. The KG-194A is the second-generation variant of the KG94A. It is the tactical, ruggedized version of the KG-194 providing trunk encryption for the USMC’s unit level circuit switch (ULCS) (SB-3865), as well as other Tri-Service Tactical Communications (TRI-TAC) system equipment. It is less costly to produce, has remote keying capability, and implements the FIREFLY COMSEC technology. The KG-194As are also part of the Navy’s shipboard cryptographics requirements to support wideband applications aboard major combatants to include amphibious and flag platforms. The KG-194A is compatible with the KG-81, KG-94/94A/194, and KG-95 in traditional key modes at respective data rates, and provides cryptographic security for all classification levels. E.
Secure Voice Devices
1. AN/USC-43(V)1 ANDVT Set. The ANDVT, with field change 1 installed (ECP-60 and EHF strapping modification), is a self-contained secure voice equipment system that performs the functions of a modem, a timing control unit, a multiplexer, and a cryptographic device. It has been designed for HDX operation, but FDX can be achieved by using a pair of terminals at each end of the communication path. The ANDVT is composed of two basic units, a CV-3591(P)/U Signal Data Converter-Modem, and an associated KYV-5 plug-in COMSEC module, that provides two modes of operation, network and PTP. When the network mode is used, terminals in the system resynchronize with each transmission; when using PTP, synchronization between terminals is achieved initially by exchanging full preambles. When ORIGINAL 2-34
NTP 2 SECTION 3 (B) using either voice feature, the equipment accepts analog voice inputs from a handset, telephone set, Intercommunications System, or digital voice frames at 2400 bps from an external linear predictive coding (LPC) voice processor. The analog voice signal is converted to a 2400 bps digital-data stream during transmission; during reception, the incoming voice data stream is converted to an analog signal. When the Navy’s AN/USC-38(V) terminal has been modified for MDR operation, the ANDVT will able to operate on 14 of the MDR ports that can support MIL-STD 118-114A interface devices. The terminal will use bit-stuffing techniques (adding “dummy” bits to the data stream) that will allow this 2.4 kbps device to operate on a 4.8 kbps EHF MDR service (the lowest data rate supported by MDR). The ANDVT has the advantage over the DVST in MDR operations in that it can support half-duplex netted communications without the need for additional switching equipment or interface conversion devices. 2. STU-III. The STU-III was designed to transmit and receive both secure and clear voice, and secure data; in the clear voice mode, it acts just like any conventional telephone. The initiating STU-III automatically determines the capabilities of the receiving unit, and establishes a secure link at the highest possible communication rate and security level, based upon the capabilities of both STU-IIIs. In the secure voice mode, it can communicate with other STU-III units in either the HDX or FDX mode, through a handset or speaker phone. Secure voice transmissions are normally conducted at a 2400 bps data rate, but automatically shift to the highest data rate compatible between the two STU-III units. HDX operation is provided for extremely poor line conditions, also at 2400 bps. In the secure data operations, the STU-III can communicate with other STU-III units at 2400, 4800, and 9600 bps, using either synchronous or asynchronous modes. It supports FDX at all of these data rates, and HDX synchronous communications at the 2400 bps data rate. Asynchronous operation is not available at the 2400 bps HDX mode. As a secure data terminal, the STU-III can operate in both attended and unattended modes. 3. DSVT. The DVST, which operates at 16 kbps, is the approved equipment for secure voice interoperability on EHF MDR. This is a full-duplex device, with PTP cryptographic synchronization. Conference networks can be supported provided that user-supplied equipment, such as conferencing switches, is furnished. The DVST will support unified CINC and JTF-level secure voice networks, and any other networks that may require interoperability with the Army, Air Force, or Marine Corps. One of the additional 16 ports of the Navy AN/USC-38(V) terminals being modified for MDR will be specially configured to support a DVST. Without this dedicated DVST port, Navy terminals would require a separate interface device to connect the DVST to the EHF terminal. 205.
EHF COMMUNICATIONS ENHANCEMENTS
A. Advanced EHF (AEHF) Communications. The Air Force’s AEHF Communications System is the U.S. Military’s planned next-generation strategic C2 satellite program. The Advanced EHF System will be the successor to the current Milstar satellite system. It is envisioned that this new system will consist of four orbiting satellites, plus one spare, that are slated for launch beginning in 2006. Additionally this system will utilize modified ORIGINAL 2-35
NTP 2 SECTION 3 (B) versions of commercial communication satellites that are launched on intermediate-class rockets vice the current practice of launching the Milstar spacecraft via the Titan 4 rockets, which are the largest and most expensive in the Air Force’s inventory. The development of a new communications processor is key to this new series of EHF satellites, that are being designed to have 10 times the capacity of their predecessors, despite the requirement to be far smaller and lighter. The processor will process, prioritize, and route all communications traffic through this next generation of EHF spacecraft; the processor development will be the most important and challenging aspect to this new program. AEHF will combine the functionality of the Milstar LDR and MDR payloads into a much smaller integrated EHF communications package. The system will take advantage of the processing and antenna technology improvements developed by the AEHF Technology Program and the AEHF Engineering Model Program to produce an EHF package small and light enough to be hosted on a modified commercial spacecraft. Compared to the Milstar, the AEHF system program improvements include higher data rates (8.192 Mbps), an upgraded terminal segment, additional nuller antennas, increased throughput, additional uplink and downlink channels with interoperable, protected, AJ, LPI/LPD communications.
ORIGINAL 2-36
NTP 2 SECTION 3 (B) CHAPTER 3 EHF SATCOM CONTROL 301. GENERAL Each of the EHF SATCOM payloads (FEP, UFO/E & UFO/EE, PEP, and Milstar) requires its own control segment and associated management procedures; each has a dedicated control subsystem that performs the functions of maintaining the satellite’s orbit, and monitoring and modifying as necessary the payload package to meet changing operational demands. The control subsystem is transparent to the users of the system, but users must be aware of the control processes to understand some of the factors that limit their use of the EHF SATCOM system. This chapter discusses the three categories of EHF SATCOM control that include spacecraft, payload, and network. It is through these control mechanisms that near-real-time allocation of EHF satellite resources, proper antenna orientation, and terminal monitoring to ensure efficient use of each terminal and spacecraft asset is achieved. The control elements consist of hardware distributed among the control centers, the satellites, the earth terminals, and the software required to evaluate the system status. Spacecraft control is the process of keeping the satellites in their assigned orbital location, maintaining attitude control, and supporting routine day-to-day housekeeping functions needed to ensure optimum operating efficiency and user service. The satellite’s payload is its communications electronics package; payload control is exercised via secure telemetry and command functions for the control of critical payload functions. Payload commands to the satellites are transmitted by the secure telemetry, tracking, & commanding (TT&C) system operating in the same frequency band as the communications services. Network control provides user access to the satellite, as well as the semiautomatic management of the satellite’s RF power and bandwidth. It also manages access to the ground-based resources to ensure that the operational communications network is in agreement with the needs of the operational commander. The network control systems provide the information, alarms, and analysis necessary to allow the satellite network control personnel to most efficiently use the spacesegment capacity. The space segments of all SATCOM systems are controlled as joint assets to meet CJCSapproved requirements. The CNO is the Program Manager for FEP, UFO/E & UFO/EE. COMNAVSPACECOM was designated as a SSE by USCINCSPACE, and performs responsibilities associated with day-to-day system operations of the FEP, UFO/E and UFO/EE, and PEP communications systems. NAVSOC HQ Point Mugu, CA, is responsible for the health and status of the FLTSAT, UFO/E & UFO/EE payloads, and reports to COMNAVSPACECOM. NAVSOC executes control of the spacecraft and communications payload under NAVSPACECOM direction. NAVSOC is also responsible for controlling the PEP communications payload. Spacecraft control for PEP is provided through the host satellite’s ground station. Milstar operational control and management responsibilities are exercised by the Air Force through the AFSPC, the designated Milstar SSE, via the Milstar Mission Control Segment (MCS), and the System Operational Management Office (SOMO).
ORIGINAL 3-1
NTP 2 SECTION 3 (B) 302. AUTHORITY The authority for controlling EHF SATCOM operations is based upon CJCSI 6250.01, which reflects the top-level operational policy governing all SATCOM systems. CJCSI 6250.01 assigns responsibilities for systems level operational management of SATCOM resources. Individual Service directives and SCOCs normally supplement CJCSI 6250.01. 303. RESPONSIBILITIES FOR MANAGEMENT AND CONTROL As described earlier in chapter 1, various organizations have responsibilities regarding the management and control of EHF SATCOM capabilities. EHF SATCOM assets are managed and operated as joint assets, prioritized by the CJCS in accordance with CJCSI 6250.01. A summary of the organizational responsibilities for managing these assets as delineated in CJCSI 6250.01 can be found in chapter 1 of this document. 304. SYSTEM CONTROL The ability of EHF SATCOM systems to support users depends heavily on the control segment, which must operate together with the space and Earth segments. It must adapt to changing demands during all situations, or the integrity of the system and the support of its users will be compromised. The control segment, including space- and ground-segment control, performs the functions of spacecraft, communication payload, and network control. The space component includes onboard hardware and software, which monitor and control the spacecraft and its payloads. When used for TT&C management, the EHF payload is considered part of the control element. Likewise, when used for commanding, the SHF uplink is considered part of the control segment. The ground component consists of elements of the Navy Satellite Control Network (NSCN) and the Air Force Satellite Control Network (AFSCN). The NSCN uses EHF terminals to provide links for telemetry, tracking, timing management, and AJ commanding, under the operational management of NAVSOC. The AFSCN includes worldwide Remote Ground Facility (RGF) which use S-band terminals to link the satellites with the Satellite Operations Center 31 (SOC-31), located at Schriever AFB, CO. NAVSOC operates the terminal and communication systems which monitor and control the UFO satellites and their payloads under the operational management of NAVSPACECOM. The NSCN is comprised of several facilities and remote detachments including NAVSOC HQ at Point Mugu, CA; NAVSOC Det ALFA at Prospect Harbor, ME; Det CHARLIE at Finegayan, Guam; Det DELTA at Schriever AFB, CO; two Navy Satellite Control Stations (NSCS); control terminals at two of the three NCTAMS, and at NCTS Guam; and the Massachusetts Institute of Technology/Lincoln Laboratory (MIT/LL), at Bedford, MA. NAVSOC conducts on-orbit management of FLTSAT and UFO satellites, and the PEP communications payload. NAVSOC performs the commanding functions of the FLTSATs via the Air Force’s AFSCN; FLTSAT, UFO, and PEP telemetry collection via the NAVSOC Dets, the AFSCN, and the PEP host satellite’s mission ground station (MGS); and FEP telemetry collection and commanding via the FEP Operations Centers (FEPOC). NAVSOC Det ALFA performs telemetry collection for FLTSAT, UFO, and PEP, and provides EHF commanding for ORIGINAL 3-2
NTP 2 SECTION 3 (B) UFO. Det ALFA performs the FEP telemetry collection and commanding via the FEPOC, and also provides a UFO AJ commanding uplink at SHF (8 GHz) via one of the NSCSs collocated at Prospect Harbor. NAVSOC Det DELTA provides backup to NAVSOC Point Mugu for control of FLTSAT and UFO. The MIT/LL controlled FEPOC is capable of performing telemetry collection and commanding for both FEPs. A. FEP Control Segment. The FEP control segment provides the C2 capability to respond to new or changing user requirements. COMNAVSPACECOM has designated NAVSOC as the operational element of NAVSPACECOM to manage the FEPs aboard FLTSATs 7 and 8 as well as the EHF packages on the UFO constellation to ensure communications are sustained. Control of the FEPs in orbit is separate from control of the host FLTSAT satellites, with the latter being provided via the AFSCN by the SOC-31 personnel at Schriever AFB. The C2 activities of the FEP control segment are concentrated at the FEPOC, MIT/LL Bedford, MA. The FEPOC provides for the transfer of command, telemetry, timing, and related FEP control information necessary for communications. A secondary transportable FEPOC (TFEPOC) has also been constructed by MIT/LL, and it is located at NAVSOC Det ALFA. Each FEPOC is capable of commanding and monitoring the FEP on FLTSAT 7 or 8. The two FEPOCs are identical in the way they are used. Normally, NAVSOC Det ALFA conducts most of the FEP operations, and provides operational direction to the FEPOC at MIT/LL. The primary command and telemetry path between the FEP and the FEPOC are via EHF. Backup paths through SOC-31 and the host FLTSAT are available using S-band (1-2 GHz) terminals for FEP turn-on, initialization, and anomaly recovery. 1. Spacecraft Control. This type of control involves those TT&C functions that provide for keeping FLTSATs 7 and 8 in their assigned orbital positions (stationkeeping), maintaining the proper orientation, and performing those other activities necessary to achieve optimal spacecraft operational performance. SOC-31 uplinks commands and receives telemetry information using the AFSCN’s RGFs via the Space-Ground Link Subsystem (SGLS) and the Sband uplink and downlink frequencies. The SGLS supports full TT&C operations during all phases of orbital operations. 2. Payload Control. The EHF payload control process involves those functions that control and configure the FEP TOD adjustments, antenna pointing, TRANSEC rekey, etc. Primary control of the EHF payload is performed by NAVSOC Det ALFA through the two FEPOCs via telemetry and command links. In those situations where FEPOC backup is required, SOC-31 may control the FEPs via the RGFs. Navy operational control of the FEP spot beam assets assigned to a FLTCINC is delegated to the designated Navy Network Control Station (NECOS). However, the FEPOCs maintain ultimate spot beam pointing control. 3. Network Control. Network control is accomplished by the communications protocols established between the FEPs and the EHF ground-based terminals. The protocols support discrimination among users of different privilege and precedence levels. Table 2-8 in chapter 2 summarizes the various privilege level access control functions, while the four precedence levels are summarized in table 2-7 of that same chapter.
ORIGINAL 3-3
NTP 2 SECTION 3 (B) a. NECOS. A NECOS is a 24-hour per-day management entity assigned to control an EHF network. The NECOS monitors overall service quality of assigned networks, and maintains the networks within the overall resource allocation. The NECOS will normally be collocated with the NECOS terminal, which has the appropriate protocols to implement management direction regarding network activation, operation (to include network modification and beam management), and deactivation. FEP networks must have a designated NECOS; each NECOS may control more than one network. The NECOS supervises member terminals for all assigned networks, may be located either ashore or afloat, and will usually be so designated in the governing COMMPLAN. There are many situations in which the NECOS may be required to modify a network. Unless authorized, modifications made by the NECOS must not exceed the resources originally allocated. The NECOS may modify the network to satisfy members that cannot meet their required link margins. For example, when a disadvantaged terminal must enter a network, the NECOS may modify the beam downlink modulation mode for greater robustness. Or, if a member terminal (for example, a ship in a battle group) is at the edge of the spot beam and experiences signal degradation due to heavy rain, the NECOS may have to increase robustness. In the event of jamming or scintillation effects, the NECOS may increase the network interleaver size if the delays can be tolerated. An alternate NECOS is also normally designated, and will assume the NECOS functions whenever the designated NECOS is unable to perform as such. 4. System Performance. FEP system performance is measured by the ability to provide continuous and reliable communications service to its users during every level of conflict or contingency. To evaluate and optimize system performance, the operation of each satellite, mission control, and terminal segments is continuously monitored; problem-reporting mechanisms have been instituted, and problem resolution procedures established. The following paragraphs describe how these system performance mechanisms apply to the FEP system. a. Monitoring. System performance monitoring is conducted by communications managers to ensure that continuous, reliable communications services are provided, to aid in problem identification and resolution, and to support the identification of apportionment/allocation violations within a near-real-time period, or during after-the-fact trend analysis. Performance is monitored by collecting and analyzing data received from the FEP space and control segments, and from the user terminal segment. Data collected includes satellite health and status information, terminal performance, and resource utilization information. Observed performance data is compared to baseline performance data obtained during initial satellite and ground station calibrations. As a result, baseline data is augmented continuously, and updated with current performance measurements and subsequent calibrations. 1 Health and Status. Data are collected from the FEP spacecraft (FLTSAT 7 and 8) by the FEPOCs. While some analysis is performed at these operations centers, NAVSOC and COMNAVSPACECOM conduct the bulk of FEP performance analysis. Evaluation reports impacting payload performance are distributed to the CINC and user communications managers. 2 Resource Utilization. Categories of resource usage include service type (broadcast, network, PTP calls) in effect, users (CINC, component commander, etc.), ORIGINAL 3-4
NTP 2 SECTION 3 (B) service (collection of user IDs), terminal network membership, and antenna pointing data. Normally the CINCs, component commanders, and terminating NECOSs use FEP communications management tools to monitor static resource utilization. As the EHF SATCOM system software tools mature, more dynamic utilization monitoring is expected to become available to communications managers. 3 Terminal Performance. All terminal operators collect operation data from their EHF terminals to support trend analysis. In general, the NECOS consolidates these terminal operation reports received from the individual user terminals, and forwards the resulting data to the individual Service EHF Terminal Program Offices, and to the Joint Terminal Program Office (JTPO) as required. b. Trend Analysis. NAVSOC performs trend analysis processing to identify existing system inefficiencies, and to predict likely space segment failures or degradation that could adversely impact user communications services. NAVSOC performs statistical analysis on reported problems to identify existing system shortcomings, and to predict long-term system trends. System failure and degradation trends identified through this process are corrected by NAVSOC as part of the problem resolution function. c. Problem Resolution. Although in general the resolution philosophy is to resolve problems at the lowest possible level, situations do arise where the only way a problem can be resolved is through the coordination and interaction of higher authority. FEP systemlevel problems that cannot be resolved at the user level are resolved through the coordinated actions of the CINC, COMNAVSPACECOM, and the various Service EHF Terminal Program Offices. NAVSOC Point Mugu, operating under the direction of COMNAVSPACECOM, normally takes the lead in problem resolution efforts regarding communications outages caused by satellite anomalies, or current ephemeris data. Problems related to terminal interoperability issues are directed to the JTPO by the Air Force Material Command, Electronics Systems Center (ESC), for Air Force terminals; COMSPAWARSYSCOM for Navy terminals; and Program Manager (PM) Milstar (Army)/SFAE-CM-MSA Fort Monmouth, NJ, for Army Terminals. COMNAVSPACECOM/NAVSOC provides support to the CINC communications managers or the JCSC during problem resolution efforts that involve adjustments to FEP resource use. B. UFO/E & UFO/EE Control Segment. As indicated above, NAVSOC has also been designated as the principal operational management activity of NAVSPACECOM for the UFO constellation and its configuration; NAVSOC maintains day-to-day satellite control and directs all UFO satellite anomaly procedures. NAVSOC operates and maintains EHF control terminals in Guam, and Prospect Harbor, ME, as well as a T&C TOC. The TOC assures the continuity of operations in the event of a major failure of an EHF control site. NAVSOC directs the on-orbit operations of the UFO satellites, and collects and archives spacecraft telemetry. NAVSOC operates the NTDN which collects, formats, and distributes adaptation and satellite ephemeris data to Navy EHF terminals, and to central Army and Air Force EHF terminal data nodes. NAVSOC acts as controlling authority (CA) for the UFO/E & UFO/EE TRANSEC cryptographic KEYMAT required by all EHF user terminals, and directs the upload of new key segment variables, as required, to the on-board TRANSEC device. NAVSOC personnel also operate the EHF control terminals at the two NSCS sites, NAVSOC Det CHARLIE and ORIGINAL 3-5
NTP 2 SECTION 3 (B) NAVSOC Det ALFA. Figure 3-1 illustrates the management and control organization. The UFO Control Segment includes ground-based and satellite-based components. Figure 3-2 shows these components, which are described in the following subparagraphs.
SECRETARY OF DEFENSE CHAIRMAN OF THE JOINT CHIEFS OF STAFF
DIRECTOR, DISA (MILSATCOM ARCHITECT)
UNIFIED CINCs
UNCINCSPACE (SOM)
CHIEF OF NAVAL OPERATIONS
AFSPC
COMNAVSPACECOM (SSE)
NTDN
AF ARMY
NAVSOC PT. MUGU, CA
NAVSOC DET “D”
SOC-31
SCHRIEVER AFB, CO
TOC (BACKUP)
FLTCINCs RGFs NAVSOC DET “A” PROSPECT HARBOR, ME (NSCS)
TEL (2) TR (1) CMD (3)
EHF
NAVSOC DET “C” GUAM (NSCS)
EHF
EHF
UFO/E SPACECRAFT
LEGEND DIRECT TASK OR CONTROL TECHNICAL COORDINATION OPERATIONAL COORDINATION
TR TEL CMD -
TRACKING TELEMETRY COMMAND
(1) - PRIMARY (2) - SECONDARY (3) - TERTIARY
Figure 3-1 UFO/E & UFO/EE Management and Control Organization 1. UFO Ground-Based Component. The UFO ground component consists of two major subcomponents: the NSCN and the AFSCN. a. NSCN Support. The NSCSs, which are a part of the NSCN, provide EHF support at NAVSOC Det ALFA and NAVSOC Det CHARLIE. The T&C TOC is available to ORIGINAL 3-6
NTP 2 SECTION 3 (B) support either Det, and is maintained in its transportable configuration at the NAVSOC HQ, Point Mugu. b. EHF Control Terminal. The EHF control terminals are Navy AN/USC-38(V)3 shore-based terminals that have been modified to perform UFO/E T&C functions. These terminals provide the EHF AJ commanding uplink, SHF (20 GHz) telemetry downlink, and time offset (Delta-T) measurement capability. The EHF control terminals are not used for spacecraft tracking or for user communications. c. NSCS Interface Unit (NIU). The NIU accepts data from the NSCS EHF terminals, and translates it to a usable format for the AFSCN. It formats data from the AFSCN for uplink by the NSCS EHF terminals. In addition to telemetry, commanding, and Delta-T, the NIU provides Telemetry and Commanding Network (T&C NET) service status to the AFSCN, and formats the EHF telemetry data. d. AFSCN. The RGF is the only component of the AFSCN that supports UFO. The RGFs use the S-band SGLS for TT&C. The RGFs also support all preoperational missions, including the launch and ascent, the orbit transfer, and spacecraft initialization phases. The RGF and NSCS sites interface with SOC-31 at Schriever AFB, CO. e. NAVSOC Support. NAVSOC, as the operational element of NAVSPACECOM, performs the day-to-day management functions for the UFO constellation and maintains its configuration to ensure user communication services are adequately supported. NAVSOC personnel perform mission planning, contact support, and mission operations evaluation for the UFO satellite system. This includes station keeping maneuvers, satellite and payload state of health evaluations, and anomaly analysis and resolution. NAVSOC collects and archives spacecraft telemetry for use in anomaly resolution. NAVSOC personnel operate the EHF control terminals at the two NSCS sites, NAVSOC Det ALFA and NAVSOC Det CHARLIE. 2. EHF Control Functions. In addition to maintaining and reporting spacecraft health and status conditions, the UFO control segment must also perform several EHF-unique control functions to support EHF communications. These EHF control functions and architectures are as illustrated in figure 3-3, and are described in the following subparagraphs. a. UFO Commanding Requirements. For UFO/E & UFO/EE satellites (spacecraft 4 through 10), EHF ground mission unique software (MUS) works in conjunction with the baseline common user software (CUS). Personnel use MUS to prepare and format EHF payload commands. MUS functions include: •
Generating user ephemeris messages for use by ground terminals.
•
Generating spot beam ephemeris data for the UFO/E & UFO/EE Spacecraft Control Processor (SCP) for accurate spot beam pointing.
ORIGINAL 3-7
NTP 2 SECTION 3 (B)
SGLS
AFSCN
RGF
C
RGF
C
TLM
C
ALT CMD STC C
ALT TLM
BCST T
EHF
COMM
TRACK SOC- 31
C RGF
C
S-Band (SGLS)
EHF Data
RGF
SGLS
CMD
C
C T MD-942A/DR BCST
T Dual Channel
TLM / DELTA-T ALT CMD C
BCN
NIU
Satellite Storage
NAVSOC
Prime CMD / DELTA-T Prime TLM
TLM / DELTA-T NESP CMD
Terminal AN/USC-38
NSCS
T EHF Guam, Prospect Harbor
C - COMSEC T - TRANSEC
Figure 3-2 UFO Control Segment •
Updating EHF payload TOD based on Delta-T (the time difference between the satellite clock and a ground reference clock) using various time maintenance commands.
•
Correcting frequency errors in the spacecraft’s master oscillator group (MOG) using frequency maintenance commands.
•
Generating spacecraft TRANSEC rekey messages from a NSA-provided KEYMAT.
ORIGINAL 3-8
NTP 2 SECTION 3 (B) CMD (75, 1200 or 2400)
CDU
EHF Processor
KI-23 UFO
CMD (75, 1200 or 2400)
TLM (1000) TEU KG-46
TLM (1200)
= MIL-STD-1582D
CMD (75, 1200 or 2400) TLM (1200)
CDU: CMD Decoder Unit TEU: TLM Encryption Unit
NSCS (NAVSOC Det ALFA or NAVSOC Det CHARLIE)
NIU
1/Sec
MUS
Net Status 1/Sec DELTA - T
TLM (1000)
CUS MDM
TLM (1200) EHF AN/USC-38
CMD (75, 1200, or 2400)
CMD (75, 1200, or 2400)
KI-23
Cesium
Figure 3-3 EHF Control Functions and Architectures In addition to these MUS functions, CUS database files include commands to modify payload parameters. These commands include the following: •
Acquisition-slot parameter modifications.
•
Beam hop-rate changes.
•
Spot-beam antenna move commands.
•
Set downlink hop boundary.
•
Memory upload and download.
•
UHF downlink channel select.
•
Set satellite ID.
•
OTAR upload.
•
Set rekeyer destination ID.
ORIGINAL 3-9
NTP 2 SECTION 3 (B) Commands that change the beam hop rate, set the downlink hop boundary, and select channels are directed by the SOM via NAVSOC based upon the payload resources apportionment. The SOM also tasks NAVSOC to make acquisition slot modifications and OTAR commands (if implemented) based on the needs of the expected terminal population. NAVSOC makes memory upload and download commands for anomaly analysis and resolution. The satellite’s ID is set prior to its operational use. Spot beam antenna moves are normally executed by the CINC-assigned operational user. In anomalous or emergency situations, NAVSOC may execute spot-beam-move commands as tasked by the SOM. b. Telemetry Requirements. The UFO telemetry encoder unit (TEU) collects telemetry data from the spacecraft subsystems; this data includes command authentication/ execution/feedback, and payload and bus health-status information. This data is encrypted by the TEU using the SGLS-compatible KG-46. For SHF (20 GHz) telemetry, the data is sent to the EHF payload in a 1000 bps SGLS format for downlink transmission to the NSCS sites. To fit within the data rate constraints of the MIL-STD-1582D waveform (1000 bps is not a standard data rate), the EHF payload buffers the telemetry up to 1200 bps. This 1200 bps telemetry is transmitted by the EHF payload and received by the EHF control terminal at the NSCS sites. At the NSCS sites, the NIU performs the telemetry compression function, reducing the data rate to 1000 bps. This 1000 bps format is then passed on for decryption, analysis, and archiving. Telemetry is also transmitted, as needed, to NAVSOC for anomaly resolution analysis. UFO/E satellites have the capability to downlink telemetry via SHF (20 GHz) and S-band simultaneously. c. Time Offset (Delta-T). The UFO/E system requires maintenance of the spacecraft clock to within 50 microseconds of EHF system time. Since all clocks drift at different rates, it must be periodically updated to maintain the required accuracy. The EHF system time is maintained by the EHF control terminals at the NSCS sites using a cesium beam timing reference. During contact with the EHF payload, the EHF control terminal measures the offset between the spacecraft clock and EHF system time, or Delta-T. This measurement is then used to maintain the correct TOD on the EHF payload. The Delta-T value is sent to NAVSOC during contacts to determine which, if any, clock updates are required. Time adjustment commands are sent via the command link. 3. System Operation Control Functions. After each UFO satellite successfully completes on-orbit testing, the CNO informs the Joint Staff that the satellite is ready to assume operations. When a satellite is designated as ready for operations, NAVSOC commences monitoring the performance of the UFO payload and transmits control commands, as required, to configure and maintain the payload. These operational commands are as listed in table 3-1. NAVSOC also analyzes the telemetry received to detect the early identification of any payload anomalies. The SOM provides additional feedback in this role as the primary point of contact for user-reported problems. 4. UFO Space-Based Control Component. Space-based components of the UFO Control Segment include the SGLS subsystem, portions of the SHF subsystem, and support hardware for TT&C functions.
ORIGINAL 3-10
NTP 2 SECTION 3 (B) COMMAND
SUPPORT REQUIREMENT
PURPOSE
Once per day per satellite Once per crypto period
None
Upload new user ephemeris for up to six UFO satellites for download to user terminals.
Once every 10 days per ephemeris set
None
Support accurate spot beam pointing
Once every 10 days
None
Partition the SHF (20 GHz) hop boundary into segments of LHR and HHR hops Establish the hop rate of an entire beam
As needed
Maximizes HHR hops Spot - HHR EC - HHR
TOD Adjustment
Maintain spacecraft clock
TRANSEC Rekey
Upload TRANSEC keys to EHF payload
User Ephemeris Upload Spot Beam Ephemeris Upload Set Downlink Hop Boundary Set Uplink Hop Rate
Change values in the EHF payload RAM. Can be used to reprogram the EHF payload software. Independently makes UHF channels 1-10 available for EHF-to-UHF crossbanding
Memory Upload/ Download UHF Channel Set
Required for key distribution to user 1 terminals Swap channel groups between EC and spot beam (UFO/EE only)
OTAR Upload Beam-Channel Group Switch Note:
1
DEFAULT
As needed As needed
As needed
As needed As needed
None
None No UHF channels are available for crossbanding Not applicable None
No OTAR ground control segment has been defined.
EHF Payload Operation Commands Table 3-1 a. SHF Control Subsystem. The SHF subsystem provides AJ commanding, and transmits pseudonoise (PN) code data via the SHF beacon downlink to provide the primary on-orbit ranging function. The SHF subsystem primarily commands during normal operations, and there are two modes of operation with SHF commanding: •
AJ Mode - Jam resistant commands are received at SHF, processed, and routed to the command decoder unit.
•
Bypass Mode - In this mode, the MD942A/DR processor is bypassed for reception of non-AJ protected command signals.
b. SGLS Control Subsystem. The SGLS subsystem is used for TT&C during the transfer orbit, initialization, and postoperational phases. The SGLS subsystem is used for telemetry, and as a backup to the SHF control subsystem for commanding during the characterization and operational orbit phases. There are both encrypted and bypass (unencrypted) modes for command and telemetry in the SGLS subsystem. The SGLS subsystem consists of two SGLS transponders, two diplexers, two low-pass filters, input and output test ORIGINAL 3-11
NTP 2 SECTION 3 (B) couplers, and an input C-switch. One of the transponders operates at SGLS channel 11, and the other at SGLS channel 13. The input C-switch allows cross strapping of the forward and aft omnidirectional antennas with the transponders. The antennas receive commanding and ranging signals, which are demodulated in the receiver portion of the SGLS transponder. The baseband commands are provided to the command decoder unit (CDU) via the receiver portion of the SGLS transponder. The TEU provides telemetry data at baseband to the transmitter portion of the SGLS transponders, where it is modulated onto a subcarrier and transmitted at S-band along with the ranging signals. c. EHF Control Subsystem. The EHF subsystem provides AJ commanding and telemetry capabilities, and time maintenance functions for the EHF payload. Baseband commands are sent to the CDU and TEU to provide telemetry data at baseband to the EHF payload for transmission on the SHF (20 GHz) downlink. Commanding and telemetry services are supported by the available pool of EHF uplink and downlink communication resources. 5. TT&C. Only 1 of the 11 EHF C0 channels on UFO/E (4-6) and 1 of 20 for UFO/EE (7-10) satellites may be assigned as the command channel; a command service is never assigned to channel 0, because it may be unexpectedly configured for RAC. A command service uses a single channel on one of the uplink antennas and requires no downlink hops. The EHF command uplink operates at a data rate of either 75, 1200, or 2400 bps. A maximum of one downlink service may be assigned as the spacecraft telemetry service. A telemetry service consumes no uplink channels, and requires no downlink hop set. The telemetry channel operates at a data rate of 1200 bps. Figure 3-4 illustrates a typical allocation for EHF uplink and SHF downlink services (independent of EHF-to-UHF crossbanding). As shown in the figure, the EHF payload for UFO-4 through 6 accommodates up to 23 total services at a time, including command (service 1) and telemetry (service 23). Table 3-2 lists the primary, secondary, and tertiary means of TT&C for the UFO/E block II satellites. a. Telemetry. The UFO TEU collects telemetry data from the spacecraft subsystems. This data includes command authentication/execution/feedback, and payload and bus health-status information. This data is encrypted by the TEU using the KG-46, and is transmitted on the SGLS or EHF downlink for reception by the RGF or EHF control terminals, respectively. The TEU collects telemetry in a predetermined order, and assembles it into serially transmitted 8-bit words. Each of the two data streams can be commanded into either of two modes. A “normal” mode data stream makes general samples of spacecraft data and a “dwell” mode accelerates sampling of selected telemetry words. b. Tracking. The following parameters can be determined from SGLS downlink signals, and used for spacecraft orbit computations: •
Range - Based on the time shift of the pseudorandom noise range code,
•
Range Rate - Based on coherent carrier Doppler shift, and
•
Azimuth and Elevation - Based on the direction of the received RF signal transmitted from the spacecraft. ORIGINAL 3-12
NTP 2 SECTION 3 (B)
CDU EHF (44 GHz) UPLINK
1 (Command)
EC BEAM: 2 1 3 4 5 (Command) 6 7 8 SPOT BEAM: 9 11 13 15 17 19 21
10 12 14 16 18 20 22
T O
SHF (20 GHz) Downlink
EHF Processor
D O W N L I N K
EC and / or Spot Beam 2 3 4 5 6 7
22
23 (Telemetry)
Service Type Qty Communications 21 Command 1 Telemetry 1 Total 23
23 (Telemetry)
CDU = Command Decoder Unit TEU = Telemetry Encoder Unit
...
TEU
Figure 3-4 EHF Uplink and SHF Downlink Services UFO/E (BLOCK II - SATELLITES 4-10) TT&C PATHS Tracking
Telemetry
Command
SHF
Secondary
Not Available
Secondary
S-Band
Primary
Secondary
Tertiary
EHF
Not Available
Primary
Primary
UFO/E TT&C Modes Table 3-2 Two modes are available for tracking the spacecraft: the narrowband phaselock mode and the wideband mode. Range and range rate may be calculated using the first mode. Range rate information is unavailable in the latter mode. c. Commanding. A variety of commands maintain the spacecraft orbit, and environmental status. The UFO support commands are summarized in table 3-3. All commands are executed by NAVSOC. ORIGINAL 3-13
NTP 2 SECTION 3 (B) SUPPORT PURPOSE
CYCLE
State of Health
3 per day
Thruster Counter Reset
1 per year
SCP Clock Set
1 per year
Preparation for Eclipse Season
2 per year
Preparation for Solstice Season
2 per year
Battery Cell Data Collection
2 per year
Battery Cell Pressure Update
2 per year
North Panel Heater On (Block I only)
1 per year
North Panel Heater Off (Block I only)
1 per year
South Panel Heater On (Block I only)
1 per year
South Panel Heater Off (Block I only)
1 per year
RAM Dump
As required
Gyro Heater On
1 per maneuver
Delta Velocity Maneuver
≈ Every 2 months
Delta Inclination Maneuver
≈ Every 6 months
Post Maneuver Track
1 per maneuver
RHM Checkout
1 every 3 months
UFO Support Commands Table 3-3 d. T&C NET Services. T&C NETs allow ground control terminals to receive specific payload information and to transmit commands to the satellite. T&C NETs are established through system-unique access control protocols. One command and one telemetry service can be active at any one time. 6. Network Control. Similar to the FEPs on FLTSAT 7 and 8, UFO/E network control is accomplished by the communications protocols established between the satellites and the ground-based AN/USC-38 terminals. These protocols support discrimination among users with different privilege levels, and services with different precedence levels. Table 2-8 in chapter 2 summarizes the various access control functions allowed by privilege level, while table 2-7 in that same chapter lists the precedence level conventions for the Navy. a. NECOS. As was the case with FEP, a NECOS is also a required management element for the UFO/E & UFO/EE networks. The NECOS monitors the overall EHF quality of service for assigned networks, and maintains the networks within the overall ORIGINAL 3-14
NTP 2 SECTION 3 (B) resource allocation. The NECOS is supported by the NECOS terminal, which has all the protocols to implement management direction regarding network activation, operations, and termination (tear down) of services. Each network must have a NECOS, and a NECOS may control more than one network. The NECOS terminal may be fixed, transportable, or mobile, and is normally designated in the governing COMMPLAN. A supervising NECOS (an intermediate management function) may also be designated when multiple NECOS create spanof-control concerns; additionally, an alternate NECOS is routinely assigned to perform the functions of the NECOS when so required. There are numerous potential situations wherein the NECOS may be required to modify or alter a network to ensure satisfactory user service. A NECOS must ensure that a network does not exceed the resources originally allocated unless authorized in advance by the JCSC, CINC, NAVSOC, or supervising NECOS. 7. System Performance. UFO/E & UFO/EE system performance is measured by the ability to provide continuous and reliable communications service to its users during every level of conflict or contingency. To evaluate and optimize system performance, the operation of each satellite, mission control, and terminal segments is continuously monitored; problem-reporting mechanisms have been instituted, and problem resolution procedures established. The following paragraphs describe how these system performance mechanisms apply. a. Monitoring. System performance monitoring is conducted by communications managers to ensure that continuous, reliable communications services are provided, to aid in problem identification and resolution, and to support the identification of apportionment/allocation violations within a near-real-time period, or during after-the-fact trend analysis. Performance is monitored by collecting and analyzing data received from the space and control segments, and from the user terminal segment. Data collected includes satellite health and status information, terminal performance, and resource utilization information. Observed performance data is compared to baseline performance data obtained during initial satellite and ground station calibrations. As a result, baseline data is augmented continuously, and updated with current performance measurements and subsequent calibrations. 1 Health and Status. NAVSOC and NAVSPACECOM personnel conduct UFO/E and UFO/EE performance analysis, after NAVSOC personnel collect the data from the spacecraft. Evaluation reports impacting payload performance are distributed to the CINC and user communications managers. 2 Resource Utilization. Categories of resource usage include service type (broadcast, network, PTP calls) in effect, users (CINC, component commander, etc.), service (collection of user IDs), terminal network membership, and antenna pointing data. Normally the CINCs, component commanders, and terminating NECOS use UFO/E & UFO/EE communications management tools to monitor static resource utilization. As the EHF SATCOM system software tools mature, more dynamic utilization monitoring is expected to become available to communications managers.
ORIGINAL 3-15
NTP 2 SECTION 3 (B) 3 Terminal Performance. All terminal operators collect operation data from their EHF terminals to support trend analysis. In general, the NECOS consolidates these terminal operation reports received from the individual user terminals, and forwards the resulting data to the individual Service EHF Terminal Program Offices, and to the JTPO as required. b. Trend Analysis. NAVSOC performs trend analysis processing to identify existing system inefficiencies, and to predict likely space segment failures or degradation that could adversely impact user communications services. NAVSOC performs statistical analysis on reported problems to identify existing system shortcomings, and to predict long-term system trends. System failure and degradation trends identified through this process are corrected by NAVSOC as part of the problem resolution function. c. Problem Resolution. Although in general the resolution philosophy is to resolve problems at the lowest possible level, situations do arise where the only way a problem can be resolved is through the coordination and interaction of higher authority. UFO/E & UFO/EE system-level problems that cannot be resolved at the user level are resolved through the coordinated actions of the CINC, COMNAVSPACECOM, and the various Service EHF Terminal Program Offices. NAVSOC Point Mugu, operating under the direction of COMNAVSPACECOM, normally takes the lead in problem resolution efforts regarding communications outages caused by satellite anomalies, or current ephemeris data. Problems related to terminal interoperability issues are directed to the JTPO by the Air Force Material Command, ESC, for Air Force terminals; SPAWARSYSCEN San Diego for Navy terminals; and PM Milstar (Army)/SFAE-CM-MSA Fort Monmouth, for Army Terminals. COMNAVSPACECOM/NAVSOC provides support to the CINC communications managers or the JCSC during problem resolution efforts that involve adjustments to UFO/E & UFO/EE resource use. C. PEP Control Segment. The control segment for the PEP system consists of equipment operated and maintained by the host-satellite ground station for the TT&C of the host spacecraft and equipment operated and maintained by NAVSOC, NAVSOC Det ALFA, and MIT/LL for T&C of the communications payload. The T&C resources are, for the most part, the same as those used to provide T&C for the equatorial UFO/E & UFO/EE constellation and FLTSAT FEPs. Modifications will be made to this equipment (as appropriate) to adapt it for use with PEP. NAVSOC was selected to control the polar EHF package because of the significant cost advantage derived from using the command’s state-of-the-art spacecraft control system. The payload structure permits either NAVSOC HQ or Det ALFA to serve as the primary operations site. The host satellite’s MGS provides limited commanding and monitors the payload to verify activation, and to assure the health and status of the spacecraft. NAVSOC monitors the payload using telemetry received from either the MGS or the EHF T&C terminal at Det ALFA. 1. Telemetry Collection. The primary method of gathering payload telemetry data is via the T&C terminal at Prospect Harbor, ME. This data is received via EHF and sent to NAVSOC for analysis and trending. EHF telemetry collection is done via the downlink; after the T&C terminal acquires the payload, it does not have to activate a command ORIGINAL 3-16
NTP 2 SECTION 3 (B) service to receive telemetry information. If payload telemetry cannot be collected via EHF, the data can also be obtained from the host satellite’s MGS, which routinely receives payload telemetry data from the satellite. The MGS will pass 1-kbps decommuted payload telemetry to NAVSOC via NAVSOC Det D facility as needed. 2. Payload Commanding. Payload commands include a number of different functions, such as changing a payload table, switching payload elements to a backup system, or repointing the EC beam. Normally, requirements for payload commands are coordinated at NAVSOC, who executes them via the terminal at Prospect Harbor. Commands that affect the payload or impact users will be directed by NAVSPACECOM and executed by NAVSOC. If commanding cannot be accomplished via EHF, the host satellite MGS has the capability to uplink payload commands and various data files to the payload via the spacecraft’s TT&C system. Similarly, the host satellite MGS will uplink payload commands and data necessary to “cold start” the EHF payload to a point where the T&C functions can be accomplished via EHF. When necessary, NAVSOC will request host satellite MGS commanding of the payload by specifying the command, or group of commands, to be updated; this is referred to as the “host pass plan.” Some components of the payload will be powered off and on as a routine recourse to conserve electrical power during each orbit. These commands are originated by NAVSOC and will only be uplinked to the payload via the spacecraft’s TT&C link using the “host pass plan.” At the beginning of each EHF communications period (approximately 3.5 hours before apogee), an activation command will be sent to the payload. At the end of the EHF communications period (approximately 3.5 hours after apogee), selected payload components will be commanded off to prepare for perigee. In addition to daily power management considerations, the host satellite MGS can deactivate the entire payload if necessary to ensure the safety of the host satellite. 3. Ephemeris Data Generation and Distribution. Satellite tracking data is collected by the host satellite MGS and converted into ephemeris data (which describes the satellite’s location in space). Once per revolution (twice a day) the host satellite MGS sends updated ephemeris data to NAVSOC. NAVSOC converts this data into the formats necessary for further distribution. These include Spot Beam Ephemeris, the User Ephemeris Message (UEM), and the Milstar format in both ASCII and Baudot. This data is then loaded into the NESP Adaptation and Ephemeris Distribution Support System (NAEDSS) and the NTDN sends Spot Beam and UEM-formatted ephemeris to the T&C terminal at Prospect Harbor for uplinking to the PEP. Likewise, ephemeris data for midlatitude UFO/Es & UFO/EEs will be stored in the polar payload so users can receive fresh ephemeris data for those satellites as they transition back into the midlatitudes. The NTDN will send weekly ephemeris messages (via the Defense Message System [DMS]) to all authorized users of the PEP system. These messages will be in either the Baudot (submarines) or ASCII (all other terminals) format. Users can manually enter this data into terminals if their current ephemeris data is too old to allow satellite acquisition. D. Milstar MCS. The Milstar MCS provides for system C2, mission planning, and anomaly resolution. The Milstar MCS conducts satellite and payload operations using fixed and
ORIGINAL 3-17
NTP 2 SECTION 3 (B) mobile ground stations, which are equipped to monitor and control the satellite constellation, and to provide overall system and resource management. The Milstar control functions include: •
Mission planning, contingency planning, and system coordination,
•
Satellite constellation configuration management,
•
Satellite orbital positioning and control,
•
Satellite status monitoring, anomaly detection, and resolution,
•
Spacecraft and communications payload configuration management,
•
Satellite antenna assignment to specific missions,
•
System performance analysis,
•
Database support,
•
Software maintenance, and
•
Cryptographic key maintenance.
1. Milstar Management Hierarchy. AFSPC, as the Milstar SSE, implements management, policies, and procedures to accomplish the Milstar mission; and, as the Operating Command for the Milstar satellite constellation and the Milstar MCS, is responsible for satellite control operations and communications payload management. The Milstar MCS includes the Satellite Mission Control Subsystem (SMCS), the Mission Support Element (MSE), Milstar Communications Planning Tool (MCPT), and the Mission Development Element (MDE). AFSPC supports the Milstar mission by providing manpower, equipment, training, and facilities. The Milstar support facilities include the Satellite Operations Center (SOC-42), the Milstar System Operations Center (MSOC), formerly known as the Milstar Operations Center (MOC), and the Constellation Control Stations (CCS). The MSOC is part of AFSPC’s 50th Space Wing’s (50 SW) 4th Space Operations Squadron (4SOPS) at Schriever AFB, CO. AFSPC implements SSE responsibilities through the Milstar SOMO. Figure 3-5 illustrates the Milstar management and control organization. a. SOMO. The SOMO is the AFSPC designated manager for the Milstar system. The SOMO is responsible for Milstar communications resource management. The SOMO develops and implements system policy guidance and system level planning to ensure communications management meets the users needs. The SOMO has delegated the day-to-day operations and management responsibility to the MSOC. b. SMCS. The SMCS provides the hardware and software, within a survivable satellite control architecture, to manage the Milstar space segment, and perform realORIGINAL 3-18
NTP 2 SECTION 3 (B) time system C2. The MSOC is responsible for the Milstar system’s day-to-day satellite control operations and communications management. Located at Schriever AFB, MSOC personnel
CJCS JOINT STAFF JSP/JCSC COMBATANT COMMAND
USSPACECOM (SOM)
CINC/USERS
OPERATIONAL MANAGER
COMMUNICATIONS STAFFS
MILSTAR SOMO (AFSPC) COORDINATION 50 SW 4SOPS
NECOS SOC-42
MCS
MSOC
TERMINAL
CCS
Figure 3-5 Milstar Management and Control Organization provide around-the-clock technical and planning assistance to CINCs and agencies, maintaining a complete set of apportionment data, distributing information, and coordinating management actions. The MSOC controls the satellite constellation, assesses satellite health and status, and keeps the satellites on station. In addition to the MSOC, which is a fixed site, there are also two transportable sites that are capable of providing Milstar satellite control. Referred to as Mobile Operations Command Centers (MOCC), they may be required to deploy outside CONUS to allow commanding of satellites outside the continental field of view. In such a scenario, a unified CINC would be designated to provide theater support to the MOCC as required. From the MSOC at Schriever AFB, the SMCS employs a specially designed workstation connected to a GNDCP terminal to communicate with the Milstar spacecraft. This combined workstation/ terminal is referred to as a CCS, and it provides direct access to and control of the Milstar constellation. Under MSOC direction, the primary functions of the geographically dispersed CCS are to maintain the spacecraft on orbit and to receive telemetry from the satellites to assess their health and status. Using the crosslink feature of the space segment, the CCSs can control any satellite in the Milstar constellation by issuing commands and communicating via the satellite crosslinks.
ORIGINAL 3-19
NTP 2 SECTION 3 (B) c. MSE. The MSE, also located at Schriever AFB, is responsible for resolution of those unanticipated failures that lack preplanned resolution procedures. The MSE is also responsible for satellite constellation control functions, and supports C2 during satellite launch, early-orbit checkout, and deployment. The MSE operates at S-band via the SGLS, and is compatible with the existing AFSCN system. d. MCPT. The MCPT serves as the primary Milstar communications planning tool for resource management agencies and the user community. It provides users with the capability to plan for their network requirements, and generate the relevant terminal data. Prior to the forthcoming Automated Communications Management System (ACMS) becoming available in approximately 2002, Milstar MCS personnel and CINC planners will continue to perform communications planning using the MCPT at the MSOC, and the Milstar Communications Support Tool (MCST) at CINC locations. They provide the necessary functionality to perform communication network planning and terminal data management prior to the implementation of the ACMS. e. MDE. The MDE, also located at Schriever AFB, provides the capability to accomplish software development, database maintenance, and system simulation. The MDE is responsible for the configuration control of software and databases, and provides translation and file-building tools for SMCS and AFSCN databases; it also provides SMCS display and procedure-building tools. The system simulator simulates the Milstar satellites and constellation, LDR and MDR terminals, the SMCS, software, databases, and various procedures. It provides tools for verifying software, procedures, and displays and serves as a resource to support operator training activities. 2. System Configuration. Milstar system configuration includes selecting appropriate constellation, payload, service, and terminal parameters to satisfy the operational requirements of the CINC and user community. Milstar system configuration responsibilities are distributed among different management and system control entities; however, it is the MSOC that generates and maintains the majority of the Milstar system configuration information. The MSOC has the primary responsibility for constellation, payload, selected service, and selected terminal configuration parameters. Milstar system configuration changes are implemented to satisfy Joint Staff priorities, and optimally support CINC and user requirements. a. Constellation Configuration. The Milstar constellation configuration is managed to provide optimum support to the CINCs and user community. The constellation configuration functions include satellite placement, crosslink configuration, and constellation buildup. The Joint Staff is the approval authority for all Milstar constellation configuration changes. Milstar constellation configuration analysis is the responsibility of the SOMO. The MSOC maintains current and planned communications support requirements to support configuration analysis. Real-time operational requirements from the CINCs and users, combined with the current system performance or limitations, are used in constellation planning and analysis based on Joint Staff and USSPACECOM guidance. Once approved, the MSOC implements the Milstar constellation configuration. Following an appropriate period for initial check out, the MSOC ensures CINC and user notification of communication systems initialization and changes. In those instances where the approved, nominal constellation ORIGINAL 3-20
NTP 2 SECTION 3 (B) configuration cannot support communication requirements, due to either a major change in requirements or the occurrence of a space segment failure, the JCSC may task the MSOC to recommend an alternate constellation configuration. If a constellation configuration change affects a Milstar terminal’s ability to communicate on the system, the MSOC provides updated terminal operations data to the affected CINCs and users. b. Payload Configuration. Milstar satellite communications payloads must be configured to provide maximum support to the user community. Configuring a Milstar satellite payload includes specification of parameters, such as uplink antenna-to-channel group mapping, access control channel privilege levels and cycle lengths, and acquisition channel access contention group sizes. Modifications to payload configurations are usually performed in response to space segment failures or system degradation, changed mission priorities, or changes in the terminal population. MSOC personnel identify and define Milstar satellite payload configuration modifications, and a Satellite Control CCS (SCCCS) or SOC-42 implements them. The MSOC has the authority, within Joint Staff, USSPACECOM, and AFSPC guidelines, to direct necessary payload reconfigurations to maintain the health of the payload. The MSOC may also direct payload reconfigurations that do not impact CINC and user apportionment. Satellite payload reconfigurations that do affect the distribution of Milstar resources defined by the apportionment process must be submitted to the SOMO/Joint Staff for approval processing prior to implementation. The MSOC optimizes the configuration of each Milstar communications payload to ensure communication requirements are supported. The MSOC application programs consider factors, such as expected terminal loading on each uplink beam, and expected HHR and LHR downlink hop requirements, to generate an optimal payload configuration for each satellite. A Milstar payload configuration specifies all parameter values found in the Milstar payload upload table. Examples include choosing acquisition access contention group sizes, C2 demodulator privilege levels, and uplink antenna-to-channel group mapping. Once the optimal payload configurations are identified, the MSOC (operational changes) or the Milstar Auxiliary Support Center (MASC) (hardware changes) generates the payload upload tables needed to implement the payload configurations. The MSOC may occasionally modify the existing payload configurations to adapt satellite payloads to support changed user requirements, space segment failures, or operational contingencies. Changes to the payload upload tables normally fall into one of two distinct categories: changes impacting the current apportionment (changing the uplink antenna-tochannel group mapping), or changes that do not affect the existing apportionment (changing an acquisition access contention group size). In cases where payload reconfiguration entails a change to the existing apportionment, the MSOC forwards the candidate reconfiguration, along with the recommended revised apportionment, to the SOMO/Joint Staff for approval. In cases where a payload reconfiguration does not affect the existing apportionment, the MSOC can implement the reconfiguration without first seeking Joint Staff authorization. New payload configurations are accompanied by new terminal configuration data for all affected terminals. c. Terminal Configuration. To access a Milstar satellite and participate in communication services, Milstar terminals need four categories of data, including ephemeris, ORIGINAL 3-21
NTP 2 SECTION 3 (B) cryptographic, terminal setup, and terminal operations. Satellite ephemeris data from the MSOC provides the terminal with satellite position data that allows the terminal to access the satellite’s payload. The MSOC provides ephemeris information for cold start, emergency, or planned satellite reconfigurations. After the terminal has logged onto the system, it can receive ephemeris update messages directly from an in-view satellite via the downlink access control channel. The MSOC generates Milstar acquisition parameters, which are considered terminal operations data. Navy terminal parameters are passed to appropriate Navy elements responsible for disseminating configuration parameters to Navy terminals. SPAWARSYSCEN San Diego is tasked with the development of NAEDSS, which supports the configuration of Navy EHF terminals. The COMSEC and TRANSEC keys obtained from the local COMSEC Material System (CMS) provide cryptographic data. Terminal setup provided by the terminal program offices, engineering agencies, and terminal installers adapts the terminal to a specific platform and set of baseband equipment. Terminal operations data includes any data required by the terminal for communications planning and operations; it is provided by the MSOC and CINC/component communications planning staffs. d. Service Configuration. Although the MSOC does not have a primary role in the configuration of resource-partitioned (virtual satellite) service parameters, it does provide technical assistance to the CINCs and users upon request. Once resource-partitioned service configurations are established, the CINCs and users pass the data to the MSOC; the MSOC records the reported service configurations for use in the adjudication process, or for later assistance to the CINCs and users. This information is also used in the monitoring process. e. Satellite Control Access. Each active CCS has direct satellite control access to assigned satellites through a collocated Milstar terminal. Geographically dispersed CCS control and maintain assigned satellites as directed by the MSOC. The CCS are not directly involved in Milstar communications management, but do perform certain satellite payload functions, such as uploading payload configuration tables which can impact CINC and user communications. 3. Network Control. Network control is accomplished by the communications protocols established between the Milstar satellites and the ground-based EHF terminals. Like FEP, UFO/E & UFO/EE, and PEP, the Milstar system also supports privilege discrimination and resource preemption by precedence. Table 2-8 in chapter 2 summarizes the various access control functions permitted by privilege level, while the Milstar convention for precedence levels is summarized in table 2-7 also of chapter 2. a. NECOS. A NECOS is also required for all Milstar networks, and is responsible for the initial establishment, configuration, and management of allocated Milstar communication services. The NECOS monitors the overall service quality of assigned networks and maintains the networks within the assigned resource allocation. The NECOS is normally collocated with a NECOS terminal, which has all the appropriate protocols to implement management direction regarding network activation, operation (to include network modification and beam management), as well as network deactivation. Additionally, the CINC may have a theater-wide supervising NECOS terminal that is staffed on a 24-hour basis and is responsible to
ORIGINAL 3-22
NTP 2 SECTION 3 (B) the CINC for the entire theater. NECOS terminals also perform network planning and management functions, providing input to the user communications staffs as required. Once EHF service has been initiated, the NECOS EHF terminal will establish the network. After the other network members have joined, NECOS responsibilities may be relinquished to another terminal, if necessary. Any terminals that join the network later will acquire the satellite, log on, and initiate protocols to join the network after ensuring that terminal ports and baseband equipment are properly configured. With the Milstar system, a “keep service alive” (KSA) protocol for each activated network is automatically scheduled every 12 hours. If two consecutive KSAs are missed on the network, an automatic 24-hour time-out will occur, during which the satellite disestablishes the network. It is the NECOS’ responsibility to ensure that the KSA response is sent for each established network. If the NECOS terminal will not be operating in a network for a full 12-hour period (e.g., because of repositioning to a location that falls outside the beam coverage area), the NECOS duties must be turned over to another terminal. With the exception of the KSA 24-hour time-out, only the NECOS can deliberately disestablish a network. To do so, the NECOS terminal operator initiates the appropriate protocols to the satellite, which terminates service to all active members of that network. This action does not affect other networks for which the NECOS may be responsible. 4. System Performance. System performance activities ensure that the Milstar system functions optimally to support user requirements. Milstar system performance includes the collection and dissemination of system status changes, and the correction of problems that affect user communications services. The MSOC ensures Milstar effectively supports CINC and user communications requirements. The MSOC periodically collects data from a number of sources, such as CINC and user problem reports, or satellite and payload health and status data, to monitor the operational state of the Milstar system. Monitoring is designed to identify system problems with the potential to adversely affect user communications. The MSOC also performs trend analysis to identify projected system problems that could also adversely affect user communications. To the maximum extent possible, the MSOC directs actions to correct problems detected through the monitoring and trend analysis processes. The MSOC keeps the Milstar community informed of the payload trend status through the Milstar communications management hierarchy. MSOC system performance responsibilities are organized under the categories of monitoring, trend analysis, and problem resolution. a. Monitoring. The MSOC analyzes information collected from Milstar Service/Deficiency Reports (SDR) forwarded by the CINCs and users, and by directly accessing the space segment in the performance monitoring process. The MSOC’s monitoring responsibilities include: 1 Health and Status Monitoring. The MSOC processes the downlink full-frame telemetry stream to identify any out-of-limit measurements, indicating anomalies or failures that could impact user communications. The MSOC collects and processes the summary telemetry stream sent over the MCE master network, and processes C3 Transparent Message (TM) anomaly report messages downlinked by the satellites. The MSOC also analyzes user reports to identify possible space segment failure/degradation events that have not been captured via telemetry or C3 TM processing. ORIGINAL 3-23
NTP 2 SECTION 3 (B) 2 Communications Service/Deficiency Monitoring. The MSOC receives and processes SDRs to identify deficiencies in the communications segment. The MSOC addresses reported deficiencies as part of the problem resolution process. 3 Satellite Resource Use Monitoring. The MSOC monitors satellite communications payload resource usage to capture information on Milstar capacity and identify unauthorized resource use. Operating under Joint Staff policy guidelines, the MSOC compares each user’s reported resource usage data with their current apportionment to identify unauthorized resource usage. If the comparison indicates a user has exceeded his apportionment, the MSOC informs that user of the detected discrepancy. The MSOC also periodically accesses the space segment directly to obtain information regarding resource usage. The MSOC has the capability to extract information from the space segment to determine which services are active on the constellation, and the communications payload resources employed by each active service. b. Trend Analysis. The MSOC performs trend analysis processing to identify existing system inefficiencies, and to predict likely space segment failures or degradation that could adversely impact user communication services. The MSOC performs statistical analyses on reported problems to identify existing system shortcomings, and to predict long-term system trends. System failure and degradation trends identified through the trend analysis process are corrected by the MSOC as part of the problem resolution function. c. Problem Resolution. To the extent possible, the MSOC corrects system performance problems discovered during the monitoring and trend analysis processes. Problems identified from health and status telemetry monitoring and anomaly messages that affect communication services are potentially the most serious and time critical problems. USSPACECOM is authorized by the Joint Staff to take corrective action, including actions affecting the current apportionment, when a satellite is at risk. In all other cases, corrective actions that could impact the current apportionment must be approved by the SOMO and the Joint Staff prior to MSOC implementation. Problems identified from user problem reports are not always time critical. The MSOC analyzes these reports and develops a problem resolution response for implementation. When a problem involves the space segment, the MSOC develops the necessary command sequence to correct the problem, and provides the information to the SCCCS, which uploads the command sequence to the satellite. As required, the MSOC generates appropriate terminal configuration data for all affected terminals, and distributes the information to designated organizations. Additionally, the MSOC identifies resource-use problems, such as user apportionment violations, and reports them to the offending user, and as appropriate, reports the violation to the JCSC.
ORIGINAL 3-24
NTP 2 SECTION 3 (B) CHAPTER 4 EHF SERVICES AND ACCESS
401. GENERAL This chapter discusses the EHF SATCOM system services that are provided by FEP, UFO/E & UFO/EE, PEP, and Milstar, as well as the procedures for accessing these services. EHF SATCOM services and networks are unlike any other SATCOM capabilities; because of their complexities, additional time to acquire the satellite and establish the service is required. EHF communications services include PTP calls, networks, broadcasts, and in the case of Milstar and FEP (limited), SRB. 402. EHF SATCOM SERVICES EHF satellites differ in the capacity of services that each can support; the number and types of antennas aboard; the throughput data rates supported; and the availability of special features, such as crossbanding and crosslinking, degree of survivability, and other less significant capabilities. The services (networks, PTP calls, broadcasts, and SRB) that the EHF SATCOM system supports are described in the following paragraphs. A. Network Service. A network has a minimum of three participating terminals, with each member terminal separately configured to either transmit only, to receive only, or to transmit and receive. EHF networks are established as either directed or nondirected networks. Directed networks are employed within a unified CINC’s AOR in support of the NCA and CINC-specific missions. Nondirected networks are established using resources allocated to supporting subunified and/or component commanders. Typically, EHF networks fall into three categories: tactical intratask unit networks, tactical intertask unit networks, and for Milstar, CINCNETs. 1. Intratask Unit Network. An intratask unit network is a voice or data multipoint network in which all of the task unit terminals are either in the same agile, spot, or EC beam. Since all participating terminals are in the same antenna beam, the network can be configured as a same-beam, same-timeslot network; therefore, satellite reconfiguration is not required. 2. Intertask Unit Network. An intertask unit network extends a network to include participating terminals in two different antenna beam coverage areas. This may include a fixed terminal operating in an EC beam communicating with deployed terminals operating in an agile or spot beam. The intertask unit network may be used for coordination between deployed task units, or for a C2 link to a commander’s headquarters terminal ashore. 3. CINCNET. CINCNET service is a worldwide JCS-sponsored EHF capability among the unified CINCs and the NCA that is only available with Milstar. CINCNET members may be located anywhere in the world that has Milstar coverage. The establishment of CINCNET service requires a higher terminal privilege than that of a typical EHF network; a terminal must have the highest of the three possible Milstar privilege levels in order to set up and ORIGINAL 4-1
NTP 2 SECTION 3 (B) activate a CINCNET. FEP, UFO/E, and PEP satellites do not have the protocols to support CINCNET service. B. PTP Service. A PTP call is usually an ad hoc service (secure voice, TTY, facsimile, or data) between two EHF terminals. This service is not necessarily preplanned, and terminates after the call is completed. The terminal initiating the call and the terminal being called must have compatible COMSEC and baseband equipment; with Milstar, both terminals are not required to be in the same EHF satellite coverage area (footprint), as is the case for FEP, UFO/E & UFO/EE, or PEP service, because Milstar service is available worldwide using crosslinks between satellites. PTP calls can be either HDX or FDX. With an HDX PTP call, only one terminal transmits at a time, in contrast to an FDX PTP call, which allows simultaneous transmit and receive, and thus requires more satellite resources. FDX operations, including the use of the STU-III on PTP calls, are possible; however, because of the satellite resources required to do so, some theater CINCs have placed restrictions on the use of FDX STU-III in their AOR. C. Broadcast Service. A broadcast service is one in which a single terminal has exclusive transmit privilege, and all other participating terminals are in a receive-only mode. 1. EHF Broadcast Service. EHF broadcast service, in which a single terminal has exclusive transmit privileges, and all the other participating terminals are in a receive-only mode, is available with FEP, UFO/E & UFO/EE, PEP, and Milstar. With an EHF broadcast, traffic can be transmitted by satellite to the receiving terminals on any EC, spot, or agile (Milstar only) antenna downlink. Since only one user terminal transmits on the uplink, no protocols between uplink transmissions (including satellite configuration) are required. 2. EHF-to-UHF Crossband Broadcast. The process of using an EHF-uplink channel and a UHF-downlink channel is known as EHF-to-UHF crossbanding. Crossbanded UHF supports up to 10 downlinks, operating at 75, 1200, 2400, 4800, or 9600 bps. Consisting of an EHF uplink and a UHF downlink (with an optional SHF [20-GHz] downlink), the Navy EHF FSB uplink can be supported by either a UFO/E, UFO/EE, or Milstar LDR satellite antenna; the Milstar II MDR antennas do not support EHF-UHF crossbanding of the FSB. The EHF uplink (from the single transmit antenna) is crossbanded to UHF in the satellite payload, and then downlinked on the FSB antenna to provide wide-area broadcast coverage. This broadcast may also be crosslinked to all Milstar satellites in the constellation to provide worldwide coverage if desired. The data rate of this broadcast is limited to 1200 bps due to baseband equipment limitations. D. Submarine Reportback (SRB). LPD/LPI communications are crucial to maintaining submarine covertness. The time required to come to communications depth, acquire the satellite, and then transmit a reportback message must be kept short, and require minimal uplink power. SRB is a one-way transmission from the submarine to SRB receptors using a special FEP or Milstar reportback protocol. SRB messages can be received by airborne command posts (ABNCP), CINC command posts, mobile command centers, and numerous shore-based receptors including submarine type commanders and submarine operating authorities (SUBOPAUTH).
ORIGINAL 4-2
NTP 2 SECTION 3 (B) The SRB feature was installed in the FEP primarily for R&D, as well as EHF terminal and concept testing. FEP reportback is accomplished using a spot beam antenna and the C2/C3 links; FEP reportback is not a dedicated service like that of Milstar. SRB via FEP is initiated by the submarine when its AN/USC-38(V)1 terminal transmits the SRB message via the uplink C2 subchannel on a spot beam to the satellite, which sends an acknowledgment back to the submarine via the spot beam C3 link. The SRB message is downlinked on the EC C3 link to the reportback receptors. Because the submarine’s EHF terminal does not have the capability to manipulate the spot beam in order to transmit the reportback message, this function must be executed by an ashore T&C terminal, which requires substantial coordination. Because FEP SRB requires this extraordinary effort, it is not normally employed on a routine basis. With Milstar, the SRB is also a one-way transmission of short (50 bit) or long (500 bit) reportback messages from the submarine (while located within a Milstar uplink agile beam) to the SRB receptors using a special Milstar SRB protocol. Each spacecraft’s payload formats its own received uplink reportback data, along with all other reportback messages received over the crosslinks, to form a single 75 bps downlink data stream for the SRB receptors. Downlinked SRB messages from the Milstar satellites are repeated up to 10 times to ensure receipt. This same process will apply when the additional Milstar constellation block II satellites become operational, except that the receiving satellite will automatically transmit the SRB message to the databases in the other satellites via their crosslinks. Milstar satellite’s SRB acknowledgment back to the submarine is also accomplished to minimize the submarine’s exposure at communications depth. E. Summary of EHF Services and Capabilities. All of the available EHF communications services (PTP, network, broadcast, and SRB) and capabilities are summarized in Table 4-1; this summary provides the differentiating features of each type of service by EHF satellite, as well as some of the other major characteristics of each EHF system. 403. EHF INITIAL TERMINAL SETUP AND SATELLITE ACQUISITION Initial EHF SATCOM user terminal operations require the input of setup and configuration parameters, which must be accomplished via the Time Standard Module (in the case of Air Force terminals) or the terminal keypad and the auxiliary TTY port (paper tape or floppy disk media for Navy terminals). These terminal setup and configuration parameter inputs must be performed after terminal power up and prior to any attempt to acquire the satellite, and consist of A&E data, operations data, and TRANSEC keys. In establishing and accessing a network, uplink and downlink signals from the satellite must be acquired. The terminal must maintain the correct time, frequency, and spatial position of the satellite. The satellite, as the master timekeeper, supplies synchronization hops to the user’s terminal. The ability to acquire individual EHF satellites is based upon ephemeris data, TRANSEC requirements for the satellite, and the antenna being acquired. Initially, the terminal orients its antenna according to ephemeris data that has been loaded into the terminal by its operator. For Milstar, the ephemeris data for the MDR payload is the same as that for the LDR payload. After the antenna is properly oriented, the terminal and satellite payload exchange a number of synchronizing timing probes. The EHF terminal must acquire the downlink signal first, then continue to track that signal to
ORIGINAL 4-3
NTP 2 SECTION 3 (B) Services and Capabilities Antennas: Earth Coverage Spot Beam Agile Beam Crosslinks Point to Point Call Network CINCNET Fleet Satellite Broadcast (FSB) Submarine Reportback (SRB) Channels
FEP
UFO/E
UFO/EE
PEP
Milstar I & II
Yes o 1(5 )/2K nm No No Yes Yes No
Yes o 1(5 )/2K nm No No Yes Yes No
Yes o 1(5 )/2K nm No No Yes Yes No
Yes o 1(5 )/2K nm No No Yes Yes No
Yes LDR 3, MDR 8 5UL, 1DL LDR only Yes(2) Yes Yes Yes
No
Yes
Yes
No
Yes (LDR only)
Yes
No
No
No
Yes (LDR only)
26
11
20
20
Primary (C0) Data Rates (bps)
75,1200 2400
75,1200 2400
75,1200 2400
75,1200 2400
Secondary (C1) Data Rates (bps)
75,150,300
75,150,300
75,150,300
75,150,300
LDR-144 2.4 kbps channels; MDR-30 1.5 Mbps channels. LDR-75,150,300 600,1200,2400; MDR- 4.8 to 1544 kbps 75,150,300bpsLDR 75-2400 bps MDR
Downlink Uplink Balanced Balanced Downlink Hops Hops Channels UL & DL UL & DL NOTE: FEP does support SRB. However, operational use of this capability is not practical since it requires an entire reconfiguration of the payload, which would then deny support to other EHF users. Critical Resources
EHF System Comparisons. Table 4-1 maintain the link. The operator has the option to select automatic terminal acquisition of the downlink, or it may be selected manually. When the manual acquisition method is selected, the operator must supply the terminal with satellite position information, elevation angle, and azimuth data in order to aim the terminal’s antenna toward the satellite. The platform’s own position information required by the terminal (latitude, longitude, unit speed, heading, etc.) may be input automatically from onboard sensors if available. In selecting the desired antenna beam of the satellite being acquired, the operator has access to look-up tables within the terminal that specify the acquisition protocol required for the selected beam and type of acquisition. A. Terminal Data Flow. EHF terminals require several kinds of data to communicate with EHF MILSATCOM systems. This data comes from a variety of sources that vary by satellite accessed, terminal type, and Service. The method used to enter this data into the terminal is also unique to each Service. This data consists of ephemeris (satellite position data), payload (acquisition information allowing the terminal to access the payload), terminal set-up (antenna blockage patterns, or any other unique considerations), network operation parameters (CINC/User operational considerations/limitations), and TRANSEC cryptographic keys. The process of obtaining, generating, and distributing this data to the EHF terminals is referred to as
ORIGINAL 4-4
NTP 2 SECTION 3 (B) terminal data flow. The Army, Navy, and Air Force have each implemented terminal data flow procedures that are structured to support their terminals. Each Service maintains its required terminal data by designating one or more Terminal Data Nodes (TDN). The NESP terminal data flow node is the NTDN located at NAVSOC, Point Mugu, CA; an alternate NTDN has also been established at NAVSOC Det ALFA, Prospect Harbor, ME. B. Terminal Loading. The Navy AN/USC-38(V) EHF terminal variants are loaded with data in virtually the same manner; each requires two sets of data to operate. The first set is loaded through the auxiliary TTY port, while the second set is provided by the terminal operator in response to screen prompts. The Navy-developed software program called NAEDSS is used to format installation, acquisition, and satellite position information for terminal entry via the auxiliary TTY port. The Navy terminal processes only BLACK data and, therefore, cannot accept terminal data that is classified. With the exception of ephemeris, NAEDSS data is considered static; it will not normally need to be loaded/reloaded on a periodic basis. The NAEDSS is located at NAVSOC along with the NTDN and supports all Navy AN/USC-38(V) terminals. During normal operations, an EHF terminal automatically receives ephemeris updates from the satellite. All other data required by the Navy terminals is entered by the terminal operator in response to screen prompts. This data is considered volatile and can be changed by the terminal operator when required. NESP terminal data flow is as illustrated in figure 4-1. All data entered through the auxiliary TTY port of the Navy AN/USC-38(V) terminals flows through the NTDN. This includes satellite position information, as well as Milstar acquisition parameters established by MSOC; FEP, UFO/E & UFO/EE, and PEP parameters established by NAVSPACECOM; and configuration information provided by the Navy In-Service Engineering Agency (ISEA). The NTDN verifies this data, formats it properly for entry into the auxiliary TTY port using NAEDSS, and distributes it on a 3.5-inch floppy disk to the terminals. It is entered into the terminals via an NST (shipboard terminals), UGC-136C TTY (submarine terminals), or PC (shore-based terminals). The NTDN is required to maintain configuration control of all data sets it generates. To support AN/USC-38(V) terminal acquisition of EHF satellite payloads, the NTDN also produces and distributes ephemeris updates. These are provided via message every two weeks and when an EHF satellite position has changed. If a manual ephemeris update is required, this data can be loaded via floppy disk. The communications network parameters are usually created by the CINC communication planners using the MCST, or other planning aids, and are identified in a COMMPLAN. TRANSEC keys are obtained from the CMS custodian. The terminal operator initializes the terminal and acquires the satellite. The network parameters are entered by the operator via the terminal’s keypad in response to normal screen prompts, and the desired networks are activated according to the requirements of the COMMPLAN. When necessary, the terminal operator may change the network information in response to screen prompts. With respect to the Marine Corps use of the SMART-T terminal, the communications planner receives the data load for the terminal into its ACMS workstation via the SIPRNET. The communications planner loads the data from the ACMS workstation into a DTD via a direct
ORIGINAL 4-5
NTP 2 SECTION 3 (B)
NAVSPACECOM (FEP, UFO/E, PEP SSE)
CINC/User
MCST
Apportionment, Acquisition Parameters
MSOC
NAVSOC Milstar Ephemeris, and Acquisition Parameters NAEDSS DATA
Network Parameters
FEP, UFO/E, & PEP Payload Parameters
FEP, UFO/E, and PEP Ephemeris Data
Navy Terminal Data Node (NTDN) Component COMM Planner Activation/ Deactivation Schedules
Network Parameters
Terminal Setup Parameters
CMS Custodian EHF TRANSEC Keys
Adaptation and Ephemeris (A&E) Distribution NAEDSS DATA
ISEA
Net Control Navy EHF Terminal
Operational Direction
Figure 4-1 NESP Terminal Data Flow physical connection. The DTD is then hand carried to the operational unit for connection to the EHF terminal and transfer of the data set. C. Other Terminal Considerations. In establishing service on FEP, UFO/E, UFO/EE, or PEP, the terminal operator must also be cognizant of other basic considerations that pertain to terminal configuration based upon the particular satellite’s capability. •
The uplink on FEP, UFO/E & UFO/EE, and PEP for their secondary ports is limited for any given terminal to a maximum of 600 bps aggregate, as compared with 1200 bps aggregate on the Milstar satellite.
•
The network establishment on FEP, UFO/E & UFO/EE, and PEP for fixed-shore terminals will uplink and downlink using the EC beam, while surface ships, submarines, manportable, and disadvantaged terminals will employ spot beams. This differs considerably from the Milstar satellites in which the fixed-shore terminals uplink on the EC beam, and normally receive the downlink from the SHF agile beam, while surface ships, submarines, manportables, and
ORIGINAL 4-6
NTP 2 SECTION 3 (B) disadvantaged terminals employ either narrow or wide-beam spots, and/or agile beams for uplink and downlink access. When establishing service on Milstar, the terminal operator must be aware of the limitation that the uplink on secondary ports is limited to a maximum of 300 bps per port (1200 bps aggregate). There are two ways that a terminal can acquire a Milstar MDR payload. If the terminal is already in one of the MDR spot beams, the terminal operator can acquire the MDR payload directly. If not already in one of the MDR antenna beam coverage areas, the terminal operator must acquire the LDR payload (via an EC or agile beam) and then request coverage by an MDR spot beam so it can complete the MDR acquisition process. After the terminal has acquired the MDR payload, the terminal operator logs on (similar to the log on process that a desktop computer operator conducts when logging on to a local area network [LAN]). That terminal is then added to the payload’s database of on-line users. The payload then knows where to find that terminal in order to route communications traffic, or to complete a PTP call connection. During the log on process, the terminal is also assigned system level resources, such as an MC2 timeslot assignment for sending system messages to the payload. Communicating with the Milstar MDR system is somewhat different than with a transponder-based system. In order to communicate on an LDR transponder-based SATCOM system, the users must coordinate with a higher level communications resource manager (a person) to obtain the resources that are needed to bring up the required services. With the EHF MDR system, the resource manager is a computer on board the spacecraft itself. Like the human resource manager for the LDR transponder-based system, the MDR on-board resource controller assigns uplink channels, crosslink slots, and downlink hops to communication services according to a precedence level that determines the order in which the services will be assigned resources. If, for example, the resource controller receives a request to activate a service and the resources are not available, it will automatically attempt to make the needed resources available by preempting other lower precedence services. 404. ESTABLISHING EHF SERVICES When establishing an EHF service, the communications planners and managers must be cognizant of the fact that Navy service and network management are controlled through terminal, payload, and network attributes; terminal network controller status; terminal privilege level; and network precedence. The purpose of multiple privilege levels is to restrict some terminals from having the ability to perform powerful network control protocols. These protocols provide the network controller with the capability to efficiently manage the EHF service. Navy terminals are able to control network and PTP service. Each terminal is given a privilege level that is assigned through the uplink TRANSEC keys and via adaptation data. Precedence is only exercised by the satellite when space segment resources are either needed to satisfy a request for service, or to make required additions and changes to an existing service and sufficient resources are not available. If these conditions occur, then the satellite will preempt lower precedence service(s) as required to satisfy the higher precedence requirement(s). The three privilege levels and how they are exercised with respect to Milstar, UFO/E & UFO/EE, PEP, and FEP are found in table 2-8 of chapter 2.
ORIGINAL 4-7
NTP 2 SECTION 3 (B) Networks, PTP calls, SRB, and the EHF FSB are activated in slightly different ways; the following paragraphs discuss the process for each. A. Establishing Networks. In the process of establishing a network, the terminal operator must be mindful of several factors that pertain to the terminal’s configuration in satisfying the network’s communication requirements. 1. The communications planner must carefully assign terminal ports, being aware of the finite number of ports available to support users. Each terminal has a complement of Primary transmit-and-receive, Secondary transmit-and-receive, and receive-only type ports. With these limitations in mind, broadcast-type networks (receive only) should be assigned to the receive-only ports and not to transmit-and-receive ports. The terminal operator should review the COMMPLAN for network requirements, review the network parameters, and make terminal port assignments that best utilize that terminal’s available capabilities. 2. Each service requires a different number of system resources and will also require a particular type of baseband equipment, including cryptographic device, to be attached to the terminal ports. Of the four previously identified basic EHF services (PTP calls, networks, broadcasts, and reportback), networks and PTP can be either data or voice. 3. The terminal operator must be sensitive to the requirements of the terminal users. Terminal users (i.e., those commands that use the services provided by the terminal) can be categorized as TTY operators, tactical data processors, and secure telephone subscribers. The terminal operator’s responsibility and ability to satisfy user requirements depends upon the command he is supporting, any unique platform configurations, and the complexity of the COMMPLAN in force. 4. Establishing an EHF network requires that the network be defined in the network definition file established on the authority of the CJCS; that an EHF terminal be designated as a network controller with all the necessary protocols, privileges, and capabilities to fulfill that responsibility; and that a NECOS be designated (normally in the COMMPLAN) as responsible for the initial establishment, configuration, management, and deactivation of the allocated EHF communication services. The NECOS is normally collocated with the network controller terminal (or NECOS terminal). The network definition file documents each net that a terminal may join as a member. Network parameters entered in the network definition file are defined in the TMS-C User Requirement Request Form instructions and are also normally contained in the supported COMMPLAN. Parameters include net ID, net name, precedence, time slot (forced or unforced), equipment configuration, data rate, port type, network type, and interleaver type. The NECOS monitors the overall service quality of assigned networks and maintains the networks within the assigned resource allocation; the NECOS may be located either afloat or ashore. An alternate NECOS is also routinely assigned to assume these functions whenever the NECOS is unable to perform because of equipment limitations or malfunctions, or because the NECOS has to depart the immediate geographical area. 5. Once EHF service has been initiated, the NECOS terminal will establish the network. After the other network members have joined, the NECOS responsibilities may be ORIGINAL 4-8
NTP 2 SECTION 3 (B) relinquished to another terminal, if necessary. Any terminals that join the network later will acquire the satellite, log on, and initiate protocols to join the network after ensuring that their terminal ports and baseband equipment are properly configured, thus bringing their terminal into compliance with the network. With the Milstar system, a KSA protocol for each activated network is automatically scheduled every 12 hours. If two consecutive KSAs are missed on a network, an automatic 24-hour time-out will occur, during which time the satellite disestablishes the network. It is the NECOS’ responsibility to ensure that the KSA response is sent for each established network. If the NECOS terminal will not be operating in a network for a full 12-hour period, the NECOS duties must be turned over to another terminal. With the exception of the Milstar KSA 24-hour time-out, only the NECOS can deliberately disestablish an EHF network. To do so, the NECOS terminal operator initiates the appropriate protocols to the satellite, which terminates service to all active members of that network. This action does not affect any other networks for which the NECOS may be responsible. 6. To activate a Milstar MDR network, a user enters the configuration information for the required service into their terminal, and sends a request for resources to the satellite’s MDR payload. The configuration items include such data as the network ID and precedence level (which are both assigned to the network during the communications planning process), the service data rate, which antenna beams will be assigned, the uplink time slot needed in each beam, and the downlink modulation mode for each beam. If the desired resources are available on the payload to activate the network, the satellite’s on-board resource controller assigns those resources at the requested precedence level. Information on the resources which are assigned (uplink channel, downlink hops, etc.) is sent to the terminal and is transparent to the user. If resources are not available, the on-board resource controller will attempt to free up the necessary resources by preempting lower precedence services; if preemption will not release the needed resources, then the request to activate the network is denied. 7. There are numerous instances where an LDR network may have to be altered or modified, but unless previously authorized, these modifications will not exceed the resources originally allocated. Some typical situations requiring the NECOS to modify an LDR network include adding a disadvantaged terminal to a network, which may require the NECOS to change the downlink modulation for greater robustness; changing the robustness level for a member at the edge of a spot beam; or increasing robustness to accommodate members experiencing signal degradation from heavy precipitation, jamming, or scintillation, which may require an increase of the interleaver size. Interleaver changes will only be implemented in situations where the delays created by this corrective action can be tolerated. 8. With a Milstar Block II satellite MDR network, only those terminals designated as the communications controller (CC) for a network can modify or alter that MDR network. Unlike the NECOS function in the LDR EHF system, the CC function in MDR networks is tracked and enforced by the spacecraft payload. The terminal that activates an MDR network is recognized by the payload as the CC for that network. Other terminals cannot modify or alter a network unless the CC functional role has been passed to it by the current CC or by a privilege terminal. Passing the CC role is done by the current CC terminal sending a system (MC2) message to the payload with the new CC’s terminal ID. When a CC terminal does modify an MDR network, the CC will send the necessary reconfiguration requests to the payload, such as ORIGINAL 4-9
NTP 2 SECTION 3 (B) adding a beam to the service or changing the downlink modulation mode of a particular beam. The payload executes the reconfiguration request if the resources are available or can be made available via preemption. If the needed resources are not available, then the request is denied by the payload. 9. To depart from an existing LDR network, the network member invokes the exit procedures from his/her terminal screen. Networks are exited after identifying the appropriate port and network combination. When executed, the procedures result in the terminal ceasing to participate in the network; however, this action does not disestablish the rest of the network. Only the NECOS can disestablish an entire LDR network by invoking the on-screen procedures of the NECOS terminal. The NECOS operator enters the port number of the LDR network to be deactivated, and executes the screen. Only those ports which have an active net for which the terminal is the net controller can be selected. For UFO/E, UFO/EE, and PEP network deactivation, it is imperative that the standard procedures promulgated in NAVSPACECOM message 201230Z MAR 93 be followed. An improper/incomplete tear-down of a UFO/E, UFO/EE, or PEP network may result in subsequent acquisition access limitations for terminals attempting to establish services on the affected EHF package. With a Milstar MDR network, only the terminal designated as the CC can deactivate that network. B. Establishing PTP Calls. Establishing a PTP call is very much like making a routine phone call. PTP calls are processed using setup and tear-down procedures prompted by the EHF terminal operator screens, which initiate the protocols for establishment of the PTP call. Each terminal has a unique ID which provides terminal ID data to the satellite resource controller; the caller’s terminal ID is input automatically. The user wishing to make the call (the “caller”) enters some basic information into their terminal, such as data rate, uplink timeslot and downlink modulation mode, port selected for the PTP call, HDX or FDX operation, precedence level, interleaver type, and the terminal ID of the user they are attempting to call (the “callee”). After the request is sent to the satellite, the system’s payload searches its database to determine if the callee is logged on. If so, the payload will assign the resources needed to connect the call (including Milstar crosslink slots if the callee is logged onto a different satellite than the caller), and then attempt to put the call through to the callee. With the Navy AN/USC-38(V) terminals, users have the capability to configure their ports to allow automatic connection of PTP calls coming through in a specified configuration. An example of such a configuration would be STU-III Multimedia Terminal (MMT) connectivity that would permit a terminal to act as a Defense Switched Network (DSN) gateway with little or no operator intervention. If the receiving terminal does not have a port properly configured, the callee gets a message on their terminal notifying them of the attempted call. After the callee has properly configured one of their ports, they can activate the “return call” feature to complete the connection. If the callee is not logged onto any EHF system payload, then the caller gets a system message notifying them of this fact. To terminate PTP service, the originating EHF terminal operator initiates the teardown and terminate protocol from his terminal screen and enters the port ID for which the PTP service is to be deleted. As the port is selected, an action message is generated that provides the details to the operator of the service being deleted. C. Implementing EHF SATCOM Reportback. The implementation of the reportback capability is quite different for FEP and the MILSTAR systems. ORIGINAL 4-10
NTP 2 SECTION 3 (B) 1. Reportback via FEP. The submarine’s EHF terminal operator enters the reportback message by either composing, editing, or transmitting on an AN/UGC-136CX TTY interfaced to the auxiliary TTY port, or alternately, performing a manual input using the TCU keypad. The terminal is capable of storing only one such reportback message at a time. The AN/USC-38(V)1 submarine terminal then transmits the message via the uplink (C2) subchannel on a FEP spot beam to the satellite, and the payload subsequently retransmits the message back to earth via the downlink (C3) subchannel to all SRB receptors. With the FEP system, the submarine does not have the capability to manipulate the spot beam in order to transmit the reportback message; this function must be executed by a shore-based T&C terminal. The FEP does have the capability to provide an acknowledgment of the SRB message back to the originating submarine. 2. Reportback via Milstar. With Milstar, the terminal operator follows the same basic process to initiate an SRB message that was used with the FEP system. Transmission of the message, however, is via a Milstar agile antenna beam, and the satellite payload acknowledges, stores, and transmits the message to the intended recipient’s receptor via an established net on the downlink of the EC or spot beams. Preferably, the message should be transmitted using a closed-loop mode in which the sending submarine’s terminal receives a confirmation message that the message packets have been received correctly. In order to accomplish this, the sending terminal must acquire the Milstar downlink to receive the acknowledgment from the satellite. Usually, transmit power is limited to the lowest power level that offers a chance of successful message receipt, then raised to medium-power level if the first attempt was unsuccessful, and finally raised to full-power level if the second try was also unsuccessful. If submarine operating conditions are such that the submarine must minimize its vulnerability to detection, or it was unable to acquire the satellite’s downlink, then the SRB message can be transmitted using the open-loop mode; in this mode, the transmission is at the full-power level without acquiring the downlink, and there is no satellite acknowledgment back to the submarine. 3. Submarine Reportback Processor (SRBP). Designated shore-based SRB receptor sites are equipped with the SRBP that consists of the CP-2112/USC-38(V) SRBP unit, a C-11917/USC-38(V) TCU, and an NSTA. This capability provides the means for the receipt, processing, and storage of up to 100 SRB messages. The SRBP receives all such messages at a 75 bps data rate from one of the four receive-only ports of an AN/USC-38(V)3 shore-based terminal. The received synchronous data stream includes the originator’s ID, the last block indicator, message data, flush bits, and parity. D. Establishing the EHF FSB. This broadcast is established using an EHF uplink and a UHF downlink. The broadcast uplink can be transmitted on any EHF uplink antenna to the UFO/E, UFO/EE, or Milstar satellites. At the satellite, the EHF uplink (from the single transmit terminal) is crossbanded to the UHF payload and downlinked on UHF to provide wide-area coverage. The broadcast data rate via the UFO/E & UFO/EE systems can be at 2400 bps (9600 bps with specially modified terminals); however, due to baseband equipment limitations, 1200 bps is the maximum throughput data rate. Similiarly, the data rate via Milstar LDR can not exceed 1200 bps. Terminals with a medium or high privilege level may uplink a broadcast. Any
ORIGINAL 4-11
NTP 2 SECTION 3 (B) user with the appropriate UHF receive and COMSEC equipment may receive this broadcast. Broadcast equipment consists of a TTY transmit source (Naval Communications Processing and Routing System [NAVCOMPARS]), KWT-46 and KG-84 encryption devices, a TD-1150/USC or similar TDM, and the AN/USC-38(V)3 shore-based NESP terminal. The broadcast receiver equipment includes the AS-2815 receive antennas, MD-900/SSR-1 combiner demodulator, TD-1063/SSR-1A demultiplexer, and KWR-46 and KG-84 decryption devices. 405. PRIORITY STRUCTURE Table 4-2, extracted from CJCSI 6250.01, lists in descending order the eight categories of SATCOM prioritization. The guidelines for the prioritization and allocation of all DOD SATCOM system resources are contained in CJCSI 6250.01. The Joint Staff assigns potential SATCOM users a relative priority for each network based on these guidelines. Allocation of SATCOM assets is based on the assigned user priority and the current operational situation. The priority assigned to each access is based on the importance to national security of the information to be exchanged; the time sensitivity of that information; the availability of alternative means of communication; the impact on other users; and technical and operational employment considerations, including satellite loading and survivability. 406. KEY MANAGEMENT The COMSEC Material Control System (CMCS) has been established to distribute, safeguard, and manage cryptographic material, which includes cryptographic KEYMAT. The CMCS consists of production facilities, Central Offices of Record (COR), distribution and MILSATCOM User Priority Assignments storage facilities (depots), and COMSEC accounts which are managed in accordance with national and military Service CMCS directives. Communications managers interface with the CMCS at a number of levels for planning and KEYMAT distribution and at the user and control terminal level for implementation. FEP, UFO/E & UFO/EE, PEP, and Milstar systems have specific TRANSEC and COMSEC parameters, KEYMAT, and databases; the remainder of this paragraph discusses the management considerations regarding the cryptographic KEYMAT essential for FEP, UFO/E & UFO/EE, PEP, and Milstar operations. Included are descriptions of the COMSEC structure in general, key types, key usage, identification and distribution, handling, and compromise recovery. A.
Management Responsibilities
1. Controlling Authorities (CA). The CAs are responsible for managing keys used with particular satellite services. CA functions include determining user key requirements, validating and approving all requests for keys, and directing supersession of keys (e.g., due to a compromise). The CA for FEP, UFO/E & UFO/EE, and PEP TRANSEC and T&C COMSEC keys is NAVSOC HQ. The CA for Milstar EHF TRANSEC, T&C COMSEC, and KGV-11A COMSEC keys is USCINCSPACE (delegated to AFSPC during peacetime). The CAs for baseband equipment COMSEC keys depend on the network involved, but in general are the
ORIGINAL 4-12
NTP 2 SECTION 3 (B) PRIORITY 0
1
2
3
4
5
6
7
USER CATEGORY Assigned only by NCA/CJCS for emergent critical contingency support STRATEGIC ORDER (essential to national survival) A. System Control/Orderwire B. NCA 1B1- Presidential Support 1B2- SECDEF Support 1B3- Envoy and Emissary Support C. Strategic and Threat Warning/Intelligence D. SIOP/Force Direction Requirements WARFIGHTING REQUIREMENTS A. Department of State Diplomatic Negotiations B. CJCS Support C. CINC Operations D. JTF or CTF Operations E. Component Operations (Theater Forces) F. Tactical Warning and Intelligence G. CJCS-sponsored Select Exercises H. Counternarcotics Operations ESSENTIAL NONWARFIGHTING OPERATIONAL SUPPORT A. Humanitarian Support B. Intelligence and Weather C. Logistics D. Electromagnetic Interference (EMI) Resolution E. Diplomatic Post Support F. Space Vehicle Support G. Other Service Support TRAINING A. CJCS Sponsored B. CINC Sponsored C. MAJCOM, MACOM, Echelon 2 Sponsored D. Unit Sponsored VIP SUPPORT A. Service Secretaries B. Service Chiefs C. CINC Travel D. Other Travel RDT&E and General A. DOD-Sponsored Testing B. DOD-Sponsored Demonstrations C. DOD-Administrative Support D. DOD Quality of Life Initiatives MISCELLANEOUS A. DOD Support to Law Enforcement B. Other Non-DOD Support C. Non-US Support as approved by the authorized organization D. Other
NOTE: CINCs and other users rank order within a category when multiple accesses are assigned within the same priority.
SATCOM User Priority Structure Table 4-2
ORIGINAL 4-13
NTP 2 SECTION 3 (B) FLTCINCs for the Navy. Since FEP, UFO/E & UFO/EE, PEP, and Milstar are managed as joint assets, all users, regardless of Service, require CA authorization to receive TRANSEC keys via standard distribution or OTAR methods. COMSEC keys for baseband networks are held in reserve on board (ROB), or procedures for OTAR are in place for most systems. Ad hoc networks may also employ any baseband COMSEC keys held by all net members, as long as the keys are cleared for the security level of the material on the network. 2. Communications Managers. Communications managers are responsible for ensuring that day-to-day requirements for all cryptographic material can be met through the editions of KEYMAT held on board. Communications managers are also responsible for cryptographic planning when contingency plans are being developed. The CAs will order keys from NSA for approved network members to support the approved COMMPLAN. For Milstar, this information is forwarded to the MSOC for inclusion in the EHF terminal operations database, which is used in forming the terminal image. The MSOC builds Milstar Terminal COMSEC reports, which detail each terminal’s authorized KGV-11A TRANSEC keys. Navy communications managers receive this report from the Milstar CA via the chain-of-command and coordinate any additional key requests with the MSOC. The MSOC analyzes requests and recommends approval/disapproval to USSPACECOM. Once the requests are approved, the MSOC incorporates them into the Milstar Terminal COMSEC reports. COMSEC custodians manage the distribution of keys for the terminals and baseband equipment in their CMS account inventory. In those instances where the keys are not already held, the custodians will request approval from the appropriate CA. Additionally, custodians for the satellite control and rekey facilities must also be supplied with keys for ground-based cryptodevices and upload to the satellites to maintain secure T&C and communications links with the FEP, UFO/E & UFO/EE, PEP, and Milstar satellites and for OTAR. 3. KEYMAT Distribution. NSA is responsible for providing security guidance regarding cryptographic equipment/devices and KEYMAT to the Services in support of FEP, UFO/E & UFO/EE, PEP, and Milstar satellite operations. NSA produces the KEYMAT to fill Service requirements, and transfers it to Service CMCS distribution and storage depots for further distribution to CMS accounts. Service depots/CORs are the COMSEC Material Issuing Office (CMIO), Norfolk, VA, for the Navy and Marine Corps; the Air Force Cryptologic Support Center (AFCSC), San Antonio, TX, for the Air Force; and the Lexington Bluegrass Army Depot (LBAD) for the Army. In cases of compromise or suspected compromise, NSA gives guidance to CAs, as well as produces emergency KEYMAT if required. B. Cryptographic System Structure. In order to support EHF SATCOM operations, crypto keys are required for the EHF payload on the satellites, user terminals, satellite control terminals, and the user baseband cryptographic equipment. To support the MIL-STD-1582D frequency-hopping AJ waveform, the Service component users’ keys take the form of TRANSEC keys (TSK) for their respective EHF terminals, in addition to baseband COMSEC keys. The KGV-11A is the common TRANSEC device employed by all the military Services for their EHF terminals; it is compatible with the FEP KGV-15 and the UFO/E & UFO/EE, PEP, and Milstar KI-37 TRANSEC devices installed in the satellites. The primary baseband cryptodevices used with the FEP, UFO/E, PEP, and Milstar are the KG-84A and Walburn family (KG-81, KG-94/194, KG-94A/194A, KG-95-1, -2, -R) for COMSEC encryption/decryption of ORIGINAL 4-14
NTP 2 SECTION 3 (B) data traffic, and the KYV-5 (the plug-in COMSEC device for ANDVT) for secure voice traffic. The management of COMSEC KEYMAT used with the KG-84A, Walburn family, and KYV-5 devices is in accordance with individual military Service instructions and is independent of the EHF medium in use. C. Key Types. The EHF terminal and its associated KGV-11A cryptographic device require different types of keys for certain functions. These keys are functionally categorized as TSKs, traffic encryption keys (TEK), and key encryption keys (KEK). Each FEP, UFO/E & UFO/EE, PEP, and Milstar satellite has unique requirements for TSKs and KEKs. The TSK and KEK requirements for the Service’s user terminals will be similar due to the common use of the KGV-11A. Keys uploaded to the satellites are in encrypted form, while user terminals receive keys in both encrypted and unencrypted forms. Regardless of the form of the keys, all cryptographic keys are afforded the proper protection commensurate with their classification and the individual military Service directives. 1.
TSKs
a. FEP, UFO/E & UFO/EE, and PEP. These uplink communication channels, uplink access control (C2) subchannel, and downlink communication/access control channel (C3) are processed using different bit streams and therefore use different TSKs. These TSKs are specified as uplink, downlink, and cover keys respectively. UFO/E, UFO/EE, and PEP have three levels of C2 cover: C2H which gives the terminal “high” privilege; C2M which gives the terminal “medium” privilege; and “null” cover, for the lowest level of privilege. FEP has only two privilege levels: C2M for a “medium” privilege level (or Unrestricted) and “null” cover (or Restricted). The uplink, downlink, C2H, and C2M keys are generated by NSA and require distribution. The “null” cover is a terminal default key consisting of all zeros; it does not require external generation or distribution of key. 1 FEP. The TRANSEC devices used with the FEP on FLTSAT 7 and 8 are the KGV-15 within the satellite’s payload used to decrypt commands, encrypt telemetry, and produce key streams for the pseudorandom EHF waveform functions which provide frequency hopping; and the KGV-11As installed with the AN/USC-38(V) EHF control terminals at the FEPOCs and the EHF communications terminals located at the various fixed and mobile user sites. NAVSOC, as the CA for FEP KGV-15 and terminal KGV-11A keys, sends all validated requests for keys to NSA. All operational FEP keys are generated at NSA in either paper tape form and stored in canisters or in electronic format (floppy diskettes). The keys remain within the canisters until their effective period or until they are superseded. Just prior to their effective date, the unencrypted paper tape keys may be loaded by using KOI-18 (general-purpose tape reader) directly into the KGV-11A, or into a KYK-13 (electronic transfer device), or KYX15/15A (net control device) for future loading into the cryptographic equipment or the EHF terminal. Electronic key floppy disks can be loaded into a DTD using a PC, and then loaded into the KGV-11A. Encrypted keys must be loaded into the terminal through an auxiliary port. Once loaded, the terminal controls the loading of encrypted keys into the KGV-11A. The normal distribution of keys to the FEPs, FEPOCs, and EHF user terminal sites is as follows:
ORIGINAL 4-15
NTP 2 SECTION 3 (B) •
FEPs and FEPOCs. The keys for the FEPs are generated by NSA and distributed to the FEPOCs via the CMIO. The FEPOC then creates rekey commands which are uplinked to the FEP payload. Although both FEPOCs can upload keys to either FEP, each FEPOC will normally upload keys to only one FEP. The FEPs use the rekey commands to rekey the KGV-15s. In contingency situations where EHF cannot be used to upload keys, the FEPOCs may send keys to AFSPC to upload via SGLS. The keys for the FEPOCs EHF control terminals are also generated by NSA and distributed to the FEPOCs via the CMIO.
•
User Terminal Sites. TSKs in user EHF terminals and their respective KGV-11A must be compatible with those in the FEP’s KGV-15. All Service users of the FEP system must get approval from NAVSOC to receive TSKs which will enable participation in FEP services. As requested by NAVSOC, FEP keys are generated by NSA and transferred to the appropriate CMS depots (CMIO, AFCSC, or LBAD) for further distribution to the various user-terminal CMS accounts.
2 UFO/E, UFO/EE, and PEP. The cryptographic devices associated with UFO/E, UFO/EE, and PEP are the KI-37s onboard the satellites themselves that are used to produce keystreams for uplink and downlink TRANSEC, and the KGV-11As installed with the AN/USC-38(V) EHF control terminals at selected NSCS sites, and the EHF user terminals located at various fixed and mobile user sites worldwide. The keys for the satellite KI-37s are generated by NSA and loaded onto magnetic tape. Similar to the process for FEP keys, all operational UFO/E & UFO/EE and PEP keys for user terminals are generated by NSA in paper tape format and stored in canisters, or in electronic format (floppy diskette). The paper tape key is kept in the canisters until the effective period, or until superseded. Once the keys are effective, they may be loaded directly into the KGV-11A by using a KOI-18, or they may be stored in a KYK-13 or KYX-15/15A for future loading into the cryptographic equipment or the EHF terminal. Again, as was the case with the FEP keys, electronic key on floppy disks can be loaded into a DTD using a PC, and then loaded into the KGV-11A. Encrypted keys must be loaded into the terminal through an auxiliary port. Once loaded, the terminal controls the loading of encrypted keys into the KGV-11A. The normal distribution of UFO/E, UFO/EE, and PEP KEYMAT to the satellites, the control terminal sites, and the EHF user-terminal sites is as follows: •
Satellite Keys. The keys for the satellite’s KI-37s are generated by NSA, placed on magnetic tape, and then transferred by NSA (via AFCSC) to AFSCN SOC-31 located at Schriever AFB, CO. SOC-31 creates rekey commands which are then uplinked by the NSCS at EHF or by the AFSCN’s RGFs as a backup. The satellites use the rekey commands to rekey the KI-37s. Each magnetic tape contains six cryptoperiods of encrypted TRANSEC keys and KEKs for one satellite. Prior to and during the effective 6-month period, the operator selects subsets of these keys, using a computer interface, for upload to the appropriate satellites. The keys are decrypted and stored within the satellites after upload. KI-23 and KG-46 cryptodevices are used on board the satellites to provide command decryption and telemetry encryption, respectively. Keys for these devices are resident in programmable read only memory (PROM) installed during ORIGINAL 4-16
NTP 2 SECTION 3 (B) manufacturing. It is not possible to upload keys to the satellite’s KI-23 or KG-46. However, a number of different keys exist in these devices’ respective PROMs. In the unlikely event of a compromise, NAVSOC would instruct SOC-31 personnel to command the satellite to switch to a different key in the PROM. SOC-31 would also switch to compatible keys for use with the KG-61 and KGR-62. The KG-61 and KGR-62 are the ground-based functional counterparts to the satellite’s KI-23 and KG-46. The KG-61 encrypts satellite commands and the KGR-62 decrypts telemetry. Keys for the KG-61 and the KGR-62 are provided to SOC-31 on PROM. •
NSCS Control Terminals. These NSCS UFO/E & UFO/EE control terminals are used as the primary means of transmitting UFO/E, UFO/EE, and PEP commanding data, and for receiving telemetry. Each terminal contains a KGV11A cryptodevice; keys for these control terminals are also generated by NSA, provided on hard copy media (paper tape or floppy disk), and distributed via the CMIO.
•
User Terminal Sites. TRANSEC keys in user terminals must also be compatible with those in the UFO/E, UFO/EE, or PEP satellite’s KI-37. All Service users of the UFO/E, UFO/EE, and PEP systems must get the approval of NAVSOC for the distribution of TSKs. These user terminal keys are generated by NSA and transferred to the appropriate military Service CMS support depot (LBAD, AFCSC, and CMIO Norfolk) for further distribution to user-terminal CMS accounts.
b. Milstar LDR. EHF TRANSEC devices used for Milstar are the KI-37s on board all the Milstar satellites; and the KGV-11As installed with the Air Force’s EHF control terminals at the CCS and with the military Service’s EHF user terminals located at various fixed and mobile platforms. The Milstar LDR system uses six functionally independent TSKs for each satellite. The EHF payload’s EC, spot, and agile beam antennas providing uplink communications (C0 and C1 traffic) are divided into three groups, each covered by an independent uplink key. These keys are called uplink strategic (STRAT), uplink tactical 1 (TAC1), and uplink tactical 2 (TAC2). By contrast, the TDM downlink for each Milstar satellite uses only one downlink TSK, that is common to all downlink-capable antennas. Two TSKs are used with the uplink access control (C2) portion of the Milstar EHF uplink waveform. These are the cover-high and the cover-low TSKs that allow multiple levels of satellite access privilege. Normal distribution of KEYMAT for the EHF user-terminal sites is as follows: •
User Terminal Sites. Milstar user terminal keys are generated and distributed by two different means. Unencrypted “cold start” keys are generated by NSA and transferred to each Service CMS support depot (LBAD, AFCSC, and CMIO, Norfolk) for distribution to individual user-terminal CMS accounts. Encrypted keys are generated by the SCCCS and distributed to user terminals via a secure Milstar satellite link (OTAR) for immediate or future loading into the KGV-11A.
ORIGINAL 4-17
NTP 2 SECTION 3 (B) 2. TEKs. TEKs are required to generate the appropriate baseband COMSEC key streams. The Navy is not planning to use the KGV-11A for COMSEC and will not be distributing KGV-11A TEKs; the Air Force does use the EHF terminal KGV-11A for some encryption of baseband data. Army and Marine Corps use of the KGV-11A for COMSEC has yet to be determined. Keys for the KG-84A, Walburn family, and KYV-5 baseband cryptos are either generated by NSA and distributed to CMS accounts via the appropriate cryptographic/cryptologic support depots, or generated in the field using key generation devices (e.g., KG-83) for SARK over-the-air distribution (OTAD) to users in accordance with Service regulations. SARK techniques, which are unrelated to EHF terminal OTAR, may be performed using Milstar resources. 3. KEKs. For security reasons, the distribution of TSKs and TEKs in an unencrypted form is undesirable. KEKs are used during the key generation process to encrypt TSKs and TEKs, protecting them during the distribution to and storage at the final destination CMS account. KEKs identical to those used during the key generation process are loaded into the EHF terminal’s KGV-11A to decrypt the keys for operational use. The KEKs may be either terminal unique (TU) (generated for individual terminals) or group unique (GU) (generated for a group of terminals). A group is normally determined by mission and geographic location. Terminals authorized to receive a common set of TSKs and TEKs are candidates for grouping. The Navy has no plans to implement GU KEKs, although the capability is available. The Marine Corps implementation of GU KEKs has yet to be determined. 407. TRANSEC KEY USER PROCEDURES A. Key Loading. The method of loading key into the KGV-11A varies according to the format of the keys. 1. Unencrypted Key. Unencrypted (RED) key is loaded directly into the KGV-11A via its standard 6-pin fill connector using a common fill device (CFD), such as the KOI-18 (if paper tape media), or the KYK-13 or CYZ-10 DTD (if in electronic media format). The terminal supplies the software and menus to facilitate loading the key into the correct KGV-11A storage registers. Normal terminal operations, including all communications, must be suspended temporarily when loading unencrypted key via the KGV-11A fill port. 2. Encrypted Key. Encrypted (BLACK) key is loaded into each terminal’s nonvolatile random access memory (NVRAM) through the terminal’s auxiliary port using a punched paper tape reader or, for magnetic media, by a method that depends on the particular terminal type. Tagging within the encrypted key format indicates the key type; the terminal operator does not need to enter any additional information about the key via the terminal keypad. Milstar supports OTAR, which is the primary means of encrypted key distribution to user terminals. In the OTAR process, keys are uploaded to the satellite via the satellite command channel, downlinked to the user terminals via C3 messages, and stored in the EHF terminal’s NVRAM. The UFO/E space segment also supports OTAR; however, a ground segment to support this process has not been put in place.
ORIGINAL 4-18
NTP 2 SECTION 3 (B) B. Rollover. At the end of each cryptoperiod, the EHF terminal needs new KGV-11A TRANSEC keys to match the corresponding change of keys in the EHF satellite. The terminal loads the encrypted keys into the KGV-11A for decryption and use at the appropriate changeover time (COT). This process is referred to as “rollover.” The two types of rollover are normal and compromise. The effective period of FEP, UFO/E & UFO/EE, PEP, and Milstar TRANSEC KEYMAT is 1 month. At the end of the month, or “cryptomidnight,” the terminal will rollover to use the next set of KEYMAT. If that next set of KEYMAT has not been loaded when the cryptomidnight occurs, communications will cease because the variables are not available to generate key streams used for frequency hopping. A COT also may be entered into the terminal for compromise rekey; it does not need to be at a cryptomidnight boundary. The keys to be used for compromise rekey and the specific COT are determined by the CA. 1. RED Key Mode of Operation. When a terminal is in the RED key mode of operation, only one set of keys for a single satellite may be used. The KGV-11A contains registers for 2 months (current and future) of TRANSEC keys. If the future keys have already been loaded as unencrypted keys via the KGV-11A fill port, the KGV-11A will rollover automatically to these keys at the cryptomidnight. The keys then become current, meaning they are now used for the bit stream generation for TRANSEC. If the future set of keys is not loaded before cryptomidnight, then communications will cease. A significant disadvantage to operating in the RED key mode is that the terminal must be forced into the idle mode to allow a new RED TSK load before a communication service using an uplink antenna with a different TSK can be established. This constraint also applies if access to a different EHF satellite is required to provide the desired communications service. 2. BLACK Key Mode of Operation. In the BLACK key mode of operation, the current RED TU or GU KEK is loaded into the KGV-11A. BLACK TSKs for the current and future cryptoperiod for all authorized satellites and satellite antennas are loaded into the EHF terminal’s NVRAM. The future (following month’s) BLACK KEK, included in the BLACK key load, is decrypted by the current KEK just prior to rollover at cryptomidnight. The resulting RED KEK is used in turn to decrypt the new month’s TSKs without having to manually load a RED KEK into the KGV-11A, which necessitates temporarily taking the EHF terminal out of the operating mode. This procedure of rolling over into a new cryptoperiod without performing a RED key load is called “chaining.” Unless a terminal is powered down, the chaining process allows a terminal to operate for as long as 6 months without being forced into the idle mode to facilitate a RED TU or GU KEK load. As in the RED key mode, changeover to future keys does not have to occur at a cryptomidnight boundary. In the case of an emergency rekey due to a compromise, a COT may be entered into the terminal. In the BLACK key mode of operation, once an operator selects a satellite and uplink antenna and initiates the acquisition process, the appropriate keys stored in the terminal’s NVRAM are loaded automatically into the KGV-11A. If another set of TSKs is subsequently required to enable a communications service on another uplink antenna, or via a different EHF satellite, the appropriate keys are loaded automatically into the KGV-11A from the terminal’s memory. 3. Breaking the Chain. When TU KEKs are linked from one month to the next, a compromise during any given month poses a security threat to future keys. In order to limit the extent of keying material affected by an undetected compromise of a terminal or its keys, the ORIGINAL 4-19
NTP 2 SECTION 3 (B) terminal/KGV-11A must be reinitialized every 6 months with a set of RED keys that has no relationship to previous keys. This procedure is referred to as “breaking the chain.” C. KEYMAT Identification and Distribution. All the military Service users of the EHF SATCOM systems require the approval of the CA to receive the necessary TRANSEC keys. HQ USSPACECOM is the CA for Milstar TRANSEC and selected COMSEC keys. During peacetime and periods of limited conflict, the CA responsibility is delegated to AFSPC; the actual execution of routine Milstar system CA functions is carried out by the MSOC. For FEP, UFO/E & UFO/EE, and PEP systems, NAVSOC HQ performs the functions of the CA. 1. Identification. The MSOC is responsible for identifying the KGV-11A TSKs (for all terminals) and the TEKs (for Air Force terminals) needed by each Milstar terminal. Once the required keys are identified, the MSOC manages the hard copy and OTAD of these keys by maintaining the COMSEC/TRANSEC database. NAVSOC performs a similar function for FEP, UFO/E & UFO/EE, and PEP. Database information is provided to the appropriate cryptologic support agencies for subsequent hard copy key production, storage, and distribution. For Milstar, it is also provided to the Milstar CCS via removable transportable memory modules (RTMM) to support OTAR. Periodically, AFSPC will consolidate lists of user terminal accounts that are to be issued Milstar keys, and submit the list to the MSOC for further definition of key requirements and distribution. Service cryptologic/cryptographic depots and NSA are notified of changes to key authorizations. The unified CINCs are responsible for identifying and reporting to the CA (with information copies to the SOMO and the MSOC as appropriate) any discrepancies between the output from the MSOC (Milstar Terminal COMSEC Report) or NAVSOC databases and the approved network KGV-11A COMSEC/TRANSEC keys needed for EHF terminals operating in the CINC’s AOR. The CA and MSOC (for Milstar) evaluate discrepancies and take appropriate action to make corrections. The unified CINCs initiate requests to correct terminal key-related deficiencies or to make changes to operational terminal key requirements for mission support. 2. Generation. Taking into account the ROB requirements of the individual users, the CA requests that keys be produced by NSA and/or Milstar CCS. NSA produces hard copy cold start key sets, which consist of one KEK, one uplink key, one downlink key, and one cover key (as required) for a given satellite. NSA also produces hard copy keying material on punched-paper tape, and floppy diskettes in sufficient quantity to satisfy the requirements of terminals that are not OTAR capable. Milstar CCS use a KOK-13 key generation device to generate encrypted keys for OTAR of user terminals, normally on a scheduled basis. 3. Distribution. KGV-11A hard copy and cold start key sets are generated by NSA and transferred to each of the Service CMS support depots for further distribution to the authorized Army, Navy, Air Force, and Marine Corps user CMS accounts. Individual Navy activity user COMSEC custodians request and receive their KEYMAT from CMIO Norfolk. Activities with terminals that are not OTAR-capable also receive all their authorized KEYMAT from the CMIO.
ORIGINAL 4-20
NTP 2 SECTION 3 (B) D.
Handling
1. Source Documentation. NSA doctrine and policy govern the handling of KGV-11A KEYMAT, as implemented by the procedures specified in the various Service CMS management manuals. These manuals describe the procedures for the proper storing, accounting, distribution, and destruction of CMS material. 2. KEYMAT Destruction. KEYMAT requires routine destruction as a result of regular supersession once the effective period of the material has expired, or because of an irregular supersession prior to this time for a known or suspected compromise; irregular supersessions are normally directed by the CA. Superseded KEYMAT on paper tape is destroyed in accordance with standing procedures, whereas superseded BLACK KEYMAT on floppy disk will remain on the magnetic media during the entire cryptoperiod. Once the effective cryptoperiod of the magnetic media (6 months) has expired, the disk destruction may be accomplished by either burning or melting. Instructions for reporting COMSEC/TRANSEC destruction are detailed in Service CMS systems management manuals. E. Compromise Recovery. Reported incidents regarding known or suspected KEYMAT compromise are evaluated by the CA who will determine the best course of action for compromise recovery. The most likely candidates subject to compromise include individual key segments, a canister or floppy disk containing key segments, or a terminal with keys resident in the NVRAM. 1. Compromise Reports and Rekey Notification Messages. Once a supersession decision is made, the CA will notify all affected EHF users and the unified CINC, the Director COMSEC Material System (DCMS), and NSA of the material to be superseded, the replacement KEYMAT, and the anticipated COT for the replacement key(s) via a Compromise Rekey Notification Message; it will also indicate the OTAR schedule for the new key(s) as applicable. In the event that a supersession or compromise rekey will jeopardize in-progress or near-term operations, the unified CINC will provide feedback to the CA. Coordination of postcompromise key management activities is provided by the MSOC for Milstar, and by the NAVSOC HQ for FEP, UFO/E & UFO/EE, and PEP. 2. Rekey Terminal Operations. All terminals holding a Milstar key listed in a compromise rekey notification message should log on to a Milstar satellite prior to the scheduled OTAR time in order to receive the emergency key. When directed by the MSOC to perform the rekey, the Designated CCS (DCCS) directs the SCCCS to transmit the new keys to all OTARcapable terminals that are logged on to the satellite, or are in the “rekey regardless” category, and are authorized to hold the affected key(s). The SCCCS attempts the rekey, keeps the status of rekey progress, and reports the status to the DCCS. The COT, which specifies the effective time that the emergency keys will become operational, must also be distributed to the user terminals. The MSOC provides the criteria for establishing a COT to the DCCS, such as a percentage of logged-on terminals, and/or a subset of terminal IDs that must have received the rekey. Once the COT criteria are satisfied, the DCCS distributes the COT to the SCCCS for OTAD to all affected user terminals, and the satellites. After the COT has been distributed, those terminals that did not receive the emergency key are considered stragglers, and they are serviced by SCCCS ORIGINAL 4-21
NTP 2 SECTION 3 (B) accordingly. After servicing all the stragglers, the SCCCS then distribute a new future key in accordance with standard procedure. For FEP, UFO/E & UFO/EE, PEP, and Navy terminals that are not capable of Milstar OTAR, the emergency keys selected by the CA may be drawn from the local CMS custodian. In the event that keys are not available locally, the naval command involved will report the impact of the loss of communications when the supersession is invoked via the operational chain of command and attempt to draw the new keys from the CMIO. 408. EHF SATELLITE ACCESS REQUEST (SAR) PROCESS EHF SARs are used to obtain access to EHF satellite resources that provide coverage in ones’ operating area. The same procedures are employed regardless of which EHF resource (FEP, UFO/E & UFO/EE, PEP, or Milstar) one is attempting to gain access to. EHF SATCOM requirements that have successfully completed the CINC-validation and CJCS-approval process, as documented in the ICDB, are not automatically guaranteed access to EHF resources. Requirement approval does not constitute entitlement to these resources; it only defines those requirements that are “eligible to compete” for EHF SATCOM resources because there are more approved requirements than there is resource capacity. Access is selectively granted in accordance with situational demands. A. EHF Resource Apportionment and Allocation. Unified CINCs and DOD agencies receive their authorization to access EHF SATCOM assets in the form of Joint Staff-approved apportionments. The apportionment may include channels, uplink demodulators, downlink hops, crossbanded UHF channels, or spot beam control. The CINCs and agencies may schedule the use of their apportioned communications resources, or allocate them to supporting commands for their use and management. Each supporting command determines which communications services to activate with the allocated resources assigned to them. Each user is responsible for operating their networks within their current allocation and assigned precedence level. B. Access Requests by Operational Commands. CINCs and agencies publish procedures for their supporting commands to follow when requesting the use of EHF SATCOM resources, or managing allocated resources. SARs are submitted to the owning CINC or agency using the procedures and format required by that CINC or agency. Communication services requiring an EHF payload reconfiguration must also be coordinated with that system’s SSE. If the request for access is for a recurring requirement for which an ICDB number has been issued, the SAR will be submitted to the appropriate component commander stating that ICDB number, short name for the network, baseband and COMSEC equipment to be employed, as well as network membership and anticipated duration of use. If a formal requirement has not yet been submitted and ICDB number assigned, the SAR should so stipulate this fact, stating that this is a new emerging requirement for which an access is being requested, and that a requirements submission is being prepared for processing. If the SAR is from a subunified commander, a CJTF, or an element in direct support of a Unified CINC, then the SAR is submitted directly to the CINC rather than to a component commander. The message below provides a sample of the types of information provided in a typical EHF SAR.
ORIGINAL 4-22
NTP 2 SECTION 3 (B) PRECEDENCE/DATE-TIME GROUP FM (ORIGINATING UNIT) TO (APPROPRIATE COMPONENT OR SUBUNIFIED COMMANDER) (APPROPRIATE UNIFIED CINC J6) INFO (APPROPRIATE CHAIN OF COMMAND) JOINT STAFF WASHINGTON DC//J6Z/J6S// HQ USSPACECOM PETERSON AFB CO//J6S/J60// COMNAVSPACECOM DAHLGREN VA//N33// HQ AFSPC PETERSON AFB CO//SCZ// NCTAMS (APPROPRIATE AREA)//N3// MILSTAR SATELLITE OPERATIONS CENTER SCHRIEVER AFB CO//MSOC// (CLASSIFICATION)//N02050// MSGID/GENADMIN/ORIGINATOR// SUBJ/EHF SATELLITE ACCESS REQUEST (U)// REF/A/GENADMIN/(CINC EHF SAR PROCEDURE MESSAGE)/(DTG)// AMPN/REF A IS EHF POLICIES AND PROCEDURES FOR(CINC/THEATER)// POC/(DSN XXX-XXXX, 24-HOUR CONTACT NUMBER)// RMKS/1. IAW REF A, REQUEST EHF ACCESS AS FOLLOWS: A. COMMAND ORIGINATING REQUEST. B. MISSION (EXERCISE, TRAINING, OPERATIONS, ETC.). C. TIMEFRAME REQUIRED (BEGINNING AND ENDING TIMES). D. PRIORITY (IAW CJCSI 6250.01 SATCOM PRIORITY TABLE). E. ICDB NUMBER (REQUESTING UNIT PROVIDE. VALIDATING COMMAND PROVIDE IF NOT INCLUDED). F. NETWORK DEFINITION: (1) TYPE (VOICE OR DATA) AND NET NAME (AS LISTED IN ICDB) (2) DATA RATE AND TRANSMISSION MODE (E.G., 2400 FDX) (3) CRYPTO/BASEBAND EQUIPMENT (4) KEYMAT (SHORT TITLE) G. NETWORK MEMBERS (ONE LINE PER TERMINAL) TERMINAL ID PLATFORM NECOS TERMINAL TYPE USC-38(V)2 23XX USS SHIP PRI USC-38(V)2 23XX USS SHIP ALT USC-38(V)1 24XX USS SUB NO ORIGINAL 4-23
NTP 2 SECTION 3 (B) USC-38(V)3 23XX SHORE CMD NO H. NECOS POC (24-HOUR POC, WITH PHONE NUMBERS) I. REMARKS (LIST ADDITIONAL POCS; SPECIAL REQUESTS, SUCH AS USE OF A SPOT BEAM; SPOT BEAM CONTROLLER ID; CROSSLINKS; RESOURCES (UPLINK HOPS/DOWNLINK DEMODS) REQUIRED; OR ACCESS TO A SPECIFIC SATELLITE). 2. GEOLOCATION INFORMATION. A. FOR NAVY UNITS: INCLUDE POSITION & INTENDED MOVEMENT (PIM) INFORMATION AND CHOP POINTS/TIMES IF APPLICABLE. B. FOR GROUND UNITS: INCLUDE GEOGRAPHIC BOUNDARIES FOR AREA OF OPERATIONS// DECL/XXXX// BT C. SAR Processing. An EHF SATCOM SAR from a unit/user subordinate will either be approved and the available resources allocated by the component or JTF commander, or it will be disapproved. If the SAR is approved but EHF resources are not available, then the component or JTF commander will attempt to borrow the needed resources from another component or JTF commander within their CINC’s AOR. If efforts to borrow resources from within the AOR prove unsuccessful, the request will be forwarded on to the owning-CINC for resource adjudication. The CINC can attempt to satisfy immediate operational requirements with existing apportioned resources by modifying network configurations, ensuring coordination with the affected system’s SSE. Similarly, component and JTF commanders should consider modification to their respective network configurations in an effort to resolve resource shortages at the lowest level of command. If the CINC can identify unused resources in other theaters, those CINCs or users can be contacted directly. Alternatively, in the case of required Milstar assets, the CINC may provide a description of needed resources to the MSOC, which will then develop a list of candidate CINCs and users with apportioned resources that could satisfy the communications requirement. Using this MSOC-developed list, the CINC can then identify those needed resources and attempt to negotiate their temporary use directly with the owning CINC or user. If the CINC is unsuccessful in borrowing the needed resources, then the requirement is submitted to the Joint Staff for adjudication in accordance with the process described in CJCSI 6250.01.
ORIGINAL 4-24
NTP 2 SECTION 3 (B) CHAPTER 5 ADMINISTRATIVE PROCEDURES 501. GENERAL To support the preparation of operationally responsive EHF SATCOM management and control procedures that optimize the allocation of communications resources, EHF SATCOM users are required to provide documentation justifying their need for access and to submit reports describing the results of their use of EHF SATCOM assets. This documentation provides data used to support the effective planning and allocation of EHF SATCOM resources, render budget and acquisition program decisions, and develop current and future SATCOM architectures. The paragraphs which follow define the administrative procedures that support the EHF SATCOM requirements definition and usage reporting processes. This section also contains information on EHF SATCOM outage reporting and identifies potential sources of training for EHF users. 502. REQUIREMENTS PLANNING The role of EHF SATCOM in military applications is increasing rapidly. Demand is being driven by a rapid expansion of both the need for enhanced information transfer (IT) service at all echelons and the availability of EHF SATCOM terminals. The procedures defined in this section are used to capture the requirements around which DOD SATCOM architectures are defined and to determine ICDB number assignments for validated requirements. A. DOD SATCOM Architecture Definition. The DOD Space Architect gathers inputs on CINC and Service IT requirements and identifies technology options that are available to construct a SATCOM architecture that meets these requirements. Consolidated requirements, technology trades, and an updated objective architecture are published by USSPACECOM in the CRD. The Space Architect uses the CRD as a reference and considers doctrine, CONOPS, force structure, threat, MNS/ORDs, technology, ICDB inputs, opportunity, information infrastructure, and cost when updating the objective SATCOM architecture. Users impact the definition of objective DOD SATCOM architectures by generating and submitting current and future IT requirements as shown in figure 5-1. B. Telecommunications Management System-Classified (TMS-C). This system provides the means to validate communications requirements leading to the utilization of EHF SATCOM resources. TMS-C replaced the Integrated MILSATCOM Management Information System (IMMIS) and features the ICDB, which contains all validated DOD telecommunications requirements supported by all communications media, as its central database. Validation of a requirement and the subsequent granting of an ICDB number do not automatically ensure actual access to an EHF SATCOM resource. Implementation of EHF SATCOM access is authorized by apportioned users (i.e., CINCs) following assignment of resources by the Joint Staff.
ORIGINAL 5-1
NTP 2 SECTION 3 (B)
CINCs CJTF/ CJTG
Joint Staff SATCOM Requirements (ICDB input)
Navy Air Force Component Component Army Component
SATCOM Requirements (ICDB)
Consolidated Joint SATCOM Requirements
Space Architect
CINCSPACE
Marine Component Service SATCOM Architectures
CSAF CMC SATCOM Requirements (Future)
Objective SATCOM Architecture
CNO
CSA
Component Space Commands
Figure 5-1 SATCOM Requirements Flow ICDB submissions are normally required prior to access and serve as the basis for CJCS validation of approved requirements. C. ICDB Requirement Submissions. ICDB submissions can originate from several sources: a Service Chief, a CINC, or a component commander or a JTF commander via their CINC. The Joint Staff (J6Z)/JCSC manages the ICDB process and develops policy guidance that is published in CJCSI 6250.01. The Director, DISA administers the ICDB for the CJCS. Normally, the Joint SATCOM Panel (JSP) (formerly the Joint MILSATCOM Panel [JMP]), consisting of Service, JCSC, and DISA representatives, meets at least once a month to review ICDB submissions and make recommendations regarding final approval or disapproval. The JCSC then initiates a joint action to validate the requirements. Validated requirements are assigned a number and entered into the ICDB. The numbers are then provided to the originator of the request along with the assigned priority. Disapproved requests are returned, with comments, to the user. 1. The CJCS, CINCs, Services, and Defense Agencies are the advocates for all telecommunications requirements. The CINCs are the advocates for their respective AOR/area ORIGINAL 5-2
NTP 2 SECTION 3 (B) of operations (AOO). Requirements are originated by the Service component units and supporting agencies as required to fulfill assigned roles and missions. SATCOM requirements are forwarded to a Service component communications manager (e.g., CINCLANTFLT N6), who consolidates and submits them to the CINC for validation. Each CINC consolidates, validates, and prioritizes all requests for telecommunications service supported by all communications media within their AOR/AOO. Services validate and submit, through appropriate channels, communications requirements. CINCs and Services carefully review each requirement and the associated performance characteristics and attributes identified to ensure that each requirement: •
Is valid;
•
Has a mission and clear operational concept;
•
Directly supports operation plans, operation orders, contingency plans, and implementation directives; and,
•
Provides a mission impact if not satisfied.
2. Requirements that are ongoing/continuing do not require an ICDB submission each time forces deploy. Access under previously approved requirements is achieved as described in chapter 4 of this document. 3. Once validated by the CINC, requirements are submitted to the Joint Staff for consideration by the JSP. When a routine requirement is received by the Joint SATCOM Panel Administrator (JSPA) (formerly the Joint MILSATCOM Panel Administrator [JMPA]), it will be distributed to the appropriate system managers and DISA; system managers and DISA will prepare technical assessments within 6 weeks. Technical assessments that discuss the capability of current programmed systems to satisfy the requirement will be forwarded to the JSPA. Requirements that cannot be satisfied by current or programmed systems or that will only be partially satisfied will be indicated as such. The JSPA reviews SATCOM requirements using the technical assessments and makes a recommendation for approval or disapproval to the Joint Staff (J6). When the Joint Staff renders a decision, the JSPA enters all approved SATCOM requirements into the ICDB and provides timely notification to users whether requirements were approved or disapproved. The JCSC will initiate a review of all SATCOM requirements in the ICDB every two years to ensure all ICDB requirements are current and accurately stated. 4. Urgent ICDB requirements are submitted by the CINCs or components directly to the Joint Staff (J6Z)/JCSC, with information copies to the respective chain of command and the JSPA. The submission must contain adequate justification for the urgency. The Joint Staff will initiate validation action as appropriate; technical assessment by system managers and DISA will be expeditiously prepared and forwarded and the Joint Staff, with input from the JSPA, will approve or disapprove the request. 5. The TMS-C SATCOM Toolkit supports requirements generation, electronic submission of requirements, and local analysis and reporting of the SATCOM requirements in ORIGINAL 5-3
NTP 2 SECTION 3 (B) the ICDB. All SATCOM requirements submission, validation, and processing procedures prescribed in CJCSI 6250.01 are supported using the TMS-C SATCOM Toolkit. Guidelines for using this toolkit can be found in the DISA TMS-C User’s Manual. 503. REPORTING REQUIREMENTS The reporting procedures established for direction and control of tactical communications for shore, fleet units, and research and development activities are based upon Joint reporting system requirements defined in Naval Warfare Publication (NWP) 10-1-13 (SUPP 1). The paragraphs that follow contain additional/amplifying reporting requirements which are designed to enhance effective management, control, and use of EHF SATCOM resources. A. EHF Communications Outage Reporting. Regardless of the EHF payload accessed, user outage/problem reporting is critical to the timely recognition of problems and the subsequent implementation of restoral plans, including the provision of alternative connectivity and the commencement of formal problem resolution efforts. EHF SATCOM is a complex communications medium and every report of an outage or problem is essential in determining whether an outage is related to a site-specific problem, terminal problem, or satellite anomaly. To aid EHF management entities in their problem resolution efforts, users must report EHF problems in a timely manner. At minimum, the NECOS must inform the MSOC (for Milstar) or NAVSPACECOM (for FEP, UFO/E & UFO/EE, and PEP) of any service problem which results in the loss of communications in excess of 30 minutes; units that lose the capability to conduct EHF communications, even if not a member of an active net, must also report this loss of capability within 30 minutes of problem determination. CINCs may implement more stringent reporting requirements at their discretion. Initial notification may be verbal, but must be followed by a Communications Spot Report (COMSPOT) message addressed to MSOC/NAVSPACECOM and the appropriate chain of command, information to the Joint Staff and USSPACECOM. Initial COMSPOT reports shall be followed by periodic updates until either the local problem is resolved or MSOC/NAVSPACECOM sends a message detailing a satellite or system-wide anomaly. Units that serve multiple CINCs must ensure that all CINCs are included in the message traffic. The following is an example of an EHF COMSPOT. PRECEDENCE (NORMALLY IMMEDIATE) DATE-TIME GROUP FM (ORIGINATOR) TO (APPROPRIATE CHAIN OF COMMAND) SERVICING COMMUNICATIONS CENTER INFO JOINT STAFF WASHINGTON DC//J6Z/J6S/J6U// COMNAVSPACECOM DAHLGREN VA//N33// (for all COMSPOTS) MILSTAR SYSTEM OPERATIONS CENTER SCHRIEVER AFB CO//MSOC// (for Milstar) HQ USSPACECOM PETERSON AFB CO//J6S// BT CONFIDENTIAL//N02308// (THIS SAMPLE FORMAT IS CLASSIFIED FOR ILLUSTRATIVE PURPOSES ONLY) MSGID/COMSPOT/ORIGINATOR// REF/A/COMSPOT/ORIGINATOR OF COMSPOT/DATE-TIME GROUP// ORIGINAL 5-4
NTP 2 SECTION 3 (B) COMEV/(EVENT)/(START TIME)/(END TIME)/(SYSTEM)// AMPN/(FREE TEXT)// RMKS/(FREE TEXT)// DECL/XXXX// BT B. EHF Quicklook Reports. EHF Quicklook Reports are used to document both EHF operational use and connectivity problems experienced with EHF equipment, configuration, satellite access and tracking, communications networks, and resource allocations. While EHF Quicklook Reports support EHF trend analysis and provide excellent insight into EHF operations, they are not submitted in lieu of the aforementioned EHF COMSPOT outage reports. The specific addressees, format, and periodicity of the SATCOM Quicklook Report have been standardized for all active units operating in any AOR. A weekly submission (long form) to the Numbered Fleet Commander and appropriate NCTAMS is required at a minimum for all units active on EHF; it is intended to give the overall big picture of a units termination(s). The daily submission (short form) is intended to give the required ship’s position to network managers, provide notification of changes to termination configuration, and report outages or difficulties encountered during the radio day (RADAY). The first example message below is that of the weekly (long form), while the second is a daily (short form). Units need only complete those paragraphs that pertain to their platform; if a paragraph is not applicable, denote it with a “N/A.” 1.
A sample weekly (long form) SATCOM Quicklook Report message follows.
FM (ORIGINATING UNIT) TO (NUMBERED FLEET COMMANDER) (EMBARKED STAFFS) (SUPPORTING NCTAMS) INFO JOINT STAFF WASHINGTON DC//J6Z// CNO WASHINGTON DC//N61/N612// (FLTCINC) (SUPPORTED CINC) COMSPAWARSYSCOM SAN DIEGO CA//PMW176/PMW176-4/ PMW176-5// COMNAVSPACECOM DAHLGREN VA//N3/N5// SPAWARSYSCEN SAN DIEGO CA//D221/D621/D622/D834// SPAWARSYSCEN CHARLESTON SC//542/543/50// COMNAVCOMTELCOM WASHINGTON DC//N3// NAVUNSEAWARCEN DET NEW LONDON CT//3412// (EHF ONLY) MILSTAR SATELLITE OPERATIONS CENTER SCHRIEVER AFB CO//MSOC//(EHF ONLY) DSCS NETWORK MANAGER WASHINGTON DC (SHF DSCS ONLY) DISA WASHINGTON DC//D3/D333/D3333// (SHF DSCS ONLY) DISAGNOSC WASHINGTON DC//D331// (SHF DSCS ONLY) DISA PAC WHEELER AAF HI//PC321/ROSC// (SHF DSCS ONLY) DISA EUR VAIHINGEN GE//EU31/ROSC// (SHF DSCS ONLY) (AREA DSCS OPERATIONS CENTER) (SHF DSCS ONLY) (OTHER STAFFS AS APPROPRIATE) (TYPE COMMANDER) ORIGINAL 5-5
NTP 2 SECTION 3 (B) (ALTERNATE NCTAMS//N3//) FTSCLANT NORFOLK VA//4232// FTSCPAC SAN DIEGO CA//200// BT CLASSIFICATION//N02300// MSGID/GENADMIN/(ORIGINATING COMMAND)// SUBJ/WEEKLY SATCOM QUICKLOOK REPORT// REF/A/COMNAVSPACECOM/(DTG)// AMPN/REF A IS QUICKLOOK REPORTING GUIDANCE// POC/(AS APPROPRIATE)// RMKS/1. PER REF A, THE FOLLOWING PROVIDES SATCOM QUICKLOOK REPORT FOR THE WEEK OF DAY/MON/YR-DAY/MON/YR. 2. SHIPS POSITION: (1) CURRENT:(INCLUDE CURRENT LAT/LONG AND OCEAN AREA) (2) PROJECTED NEXT 72 HOURS: 3. SHF DSCS SATCOM TERMINATION: A. SHIPS CONFIGURATION: (1) TERMINAL TYPE (2) ANTENNA TYPE (3) MODEM TYPE (4) MULTIPLEXER TYPE (5) ANTENNA DIPLEXER FREQUENCY RANGE B. DSCS ASSIGNMENT: (1) DSCS SATELLITE AND CHANNEL ASSIGNED (2) AGGREGATE DATA RATE OF TERMINATION C. TERMINATION DATA: (1) PRIMARY TECHNICAL CONTROL (2) DATE/TIME OF TERMINATION ACTIVATION D. TERMINATION/CIRCUIT STATUS: SLOT CIRCUIT DATA RATE STATUS PATH 4. CHALLENGE ATHENA TERMINATION: A. SHIPS CONFIGURATION: (1) TERMINAL TYPE (2) ANTENNA TYPE (3) MODEM TYPE (4) MULTIPLEXER TYPE B. SATELLITE ASSIGNMENT: (1) SATELLITE ASSIGNED (2) AGGREGATE DATA RATE OF TERMINATION C. TERMINATION DATA: (1) EARTH STATION/PRIMARY TECH CONTROL (2) DATE/TIME OF TERMINATION ACTIVATION D. TERMINATION/CIRCUIT STATUS SLOT CIRCUIT DATA RATE STATUS PATH 5. EHF TERMINATION: A. CURRENT NET CONFIGURATION: AN/USC-38(V)2 NUMBER 1 SATELLITE/BEAM ACQUIRED:FLT2, SPT C PORT/PREC/SVC ID/CKT NAME/MODULATION MODE 1/P2/700/BG CMD NET/DPSK-54 2/P1/701/MDU DIS/DPSK-108 ORIGINAL 5-6
NTP 2 SECTION 3 (B) AN/USC-38(V)2 NUMBER 2 SATELLITE/BEAM ACQUIRED:UFO-7, EC PORT/PREC/SVC ID/CKT NAME/MODULATION MODE 1/P2/180/ATO DATA/DPSK-54 2/P1/181/OTCIXS/DPSK-54 3/P1/182/BGIXS/DPSK-54 B. NETS ACTIVATED/DEACTIVATED DURING WEEK: ACTIVATED/DEACTIVATED/PREC/SVC ID/CKT NAME (DTG)/-/P3/7XX/BG TEST -/(DTG)/P2/7XX/BG CMD NET (DTG)/(DTG)/P3/90/PTP CALL TO XXXX (CALL ACTIVATED AND DEACTIVATED AT DTGS) C. NAVY EHF COMMUNICATIONS CONTROLLER (NECC): (1) COMM CONFIG UTILIZED: GREYSHIP_GRS_MDU (2) NUMBER OF SACS ACTIVE:2 (3) NECC REBOOTS:2 D. MDU TRANSMISSIONS: (1) MDUS RELAYED TO BG VIA EHF: UNIT DATE TOTAL MISSIONS USS AFLOAT 05AUG99 38 DIRECT (2) MDUS RECEIVED VIA EHF: CMSALANT O4AUG99 35 NECC 6. INMARSAT B HSD TERMINATION: A. DUAL OR SINGLE TERMINAL/MANUFACTURER NOMENCLATURE B. TERMINATION: (1) SATELLITE ACCESS: (A). TERMINAL NUMBER 1 SATELLITE/FREQUENCY (B). TERMINAL NUMBER 2 SATELLITE FREQUENCY (OMIT IF SINGLE TERMINAL) (2) TERMINATING NCTAMS: C. CIRCUIT STATUS: (1) TERMINAL 1: FCC-100(V)9 PORT CIRCUIT DATA RATE STATUS NUMBER REMARKS 01 ADNS 38.4K ACTIVE XXX-XXXX 09 IDSN 9.6K ACTIVE XXX-XXXX 10 IDSN 9.6K ACTIVE XXX-XXXX 15 IDSN 9.6K INACTIVE XXX-XXXX NOTE 1 16 IDSN 9.6K DOWN XXX-XXXX NOTE 2 (2) TERMINAL 2: (OMIT IF A SINGLE TERMINAL) DATA RATE STATUS REMARKS 64K ACTIVE D. NOTES: (1) CONFIGURED PORT UNUSED IN ORDER TO INCREASE DATA RATE FOR ADNS. (2) UNABLE TO GET DIAL TONE. COMSPOT DTG REFERS. 7. GBS TERMINATION:(GBS SPECIFICS NOT YET FINALIZED) 8. DIFFICULTIES/OUTAGES:(NOT TO BE USED IN LIEU OF COMSPOT REPORTING) A. SHF DSCS:TIME OUT/TIME IN/RFO B. CHALLENGE ATHENA:TIME OUT/TIME/IN/RFO ORIGINAL 5-7
NTP 2 SECTION 3 (B) C. EHF:TIME OUT/TIME IN/RFO D. INMARSAT B HSD:TIME OUT/TIME IN/RFO E. GBS:TIME OUT/TIME IN/RFO F.MISCELLANEOUS ISSUES: DECL/XXXX// BT 2. A sample daily (short form) SATCOM Quicklook Report message follows. PRIORITY PRECEDENCE FM (ORIGINATING UNIT) TO (SAME ADDEES AS WEEKLY LONG FORM MESSAGE) INFO JOINT STAFF WASHINGTON DC//J6Z/J6S/J6U// BT CLASSIFICATION//N02300// MSGID/GENADMIN/(ORIGINATING COMMAND)// SUBJ/DAILY SATCOM QUICKLOOK REPORT// REF/A/COMNAVSPACECOM/(DTG)// AMPN/REF A IS QUICKLOOK REPORTING GUIDANCE// POC/(AS APPROPRIATE)// RMKS/1. PER REF A, THE FOLLOWING PROVIDES SATCOM QUICKLOOK REPORT FOR RADAY XXX DAY/MONTH/YR. A. SHIPS POSITION: (1) CURRENT: (2) PROJECTED NEXT 72 HOURS: 2. TERMINAL/CONFIGURATION CHANGES: 3. DIFFICULTIES/OUTAGES:(NOT TO BE USED IN LIEU OF COMSPOT REPORTING) A. SHF DSCS: B. CHALLENGE ATHENA: C. EHF: D. INMARSAT B HSD: E. GBS: 4. MISCELLANEOUS REMARKS: DECL/XXXX// BT 504. OPERATIONAL TRAINING Due to the complexity of EHF systems and the requirement for centralized coordination, extensive training of operator and maintenance personnel is required. Navy EHF SATCOM systems are designed for continuous operation monitored by communications watchstanders. Terminal operators establish operating modes, switch equipment configuration, monitor system performance, and coordinate actions via orderwire or voice networks with other operators. Activities are encouraged to anticipate training needs and to take advantage of on-the-job, personnel qualification standards (PQS), and formal schoolhouse training to ensure requirements for qualified watchstanders are met.
ORIGINAL 5-8
NTP 2 SECTION 3 (B) A. Personnel Qualification Standards (PQS). Although PQS for EHF SATCOM systems has not been developed, the requirement to develop PQS locally and produce PQS-type manuals (Job Qualification Requirements) is outlined in OPNAVINST 3500.34. Sources of training material that can be adapted to local training programs include ISEA-developed on-thejob training manuals, type commander instructions, and AN/USC-38(V) technical manuals which provide detailed instructions on terminal operations. B. Navy EHF SATCOM Training. Formal training courses for Navy EHF SATCOM are conducted at Fleet Training Center (FTC) Norfolk, Virginia; FTC San Diego, CA; and Naval Submarine School (NAVSUBSCOL), New London, CT. 1. Transmission Systems Technician (TST) Course (A-260-0253). This course provides training in the use of end to end transmission frequencies, including all SATCOM frequencies and system interfaces. It includes the information taught in the EHF SATCOM AN/USC-38(V) Navy Satellite Terminal Operator (A-260-0066) course and has replaced that course at FTC Norfolk as of 1 October 1997. Course is dual sited at FTC Norfolk and San Diego Local Training Authority (LTA). 2. EHF SATCOM AN/USC-38(V) Navy Satellite Terminal Operator Course (A-260-0066). This course provides 16 weeks of hands-on instruction on the operation of the AN/USC-38(V)2 and (V)3 ship/shore EHF SATCOM terminal. Training includes all operational aspects of the system, such as terminal capabilities, cold start, set up/acquisition procedures, establishing communications, terminal configuration, net activation/deactivation, PTP communications, shutdown, and performance scenarios. This course is single-sited at FTC San Diego. 3. EHF SATCOM AN/USC-38(V) Navy Satellite Terminal Maintenance Course (A-101-0269). This course provides 5 weeks of instruction on troubleshooting and repair of Navy EHF SATCOM AN/USC-38(V)2 and (V)3 ship and shore terminals. It is offered at both FTC Norfolk and FTC San Diego. Plans are in progress for a TST Maintainer course that will combine this course and various other SHF and UHF SATCOM terminal maintenance courses. 4. EHF SATCOM AN/USC-38(V) Navy Satellite Terminal Operation/ Maintenance Course (A-101-0243). This course provides 6 weeks of hands-on instruction for the operation, troubleshooting, and repair of the AN/USC-38(V)1 submarine terminal. It is offered at the NAVSUBSCOL, New London. 5. EHF Basic Maintenance Course (A-101-0285). This course provides the skills and knowledge required to perform casualty/degraded/abnormal/not-fully-mission capable operational tasks requiring advanced analysis, preventive maintenance, and documented fault isolation and repair, without going into detailed logic, circuit analysis, individual program flow diagrams, or detailed mechanical component breakdown of the AN/USC-38(V) Navy terminal. This course is 33 weeks in duration, and is taught at NAVSUBSCOL New London.
ORIGINAL 5-9
ANNEX A NTP 2 SECTION 3 (B) ANNEX A ACRONYMS
A&E ABNCP ACMS ADNS AEHF AFB AFCSC AFSATCOM AFSCN AFSPC AJ ANDVT AOO AOR APCU APG ASCII ASD(C3I) ASR AWC
adaptation and ephemeris Airborne Command Post Automated Communications Management System Automated Digital Networking System Advanced EHF Air Force Base Air Force Cryptologic Support Center Air Force Satellite Communications Air Force Satellite Control Network Air Force Space Command antijam Advanced Narrowband Digital Voice Terminal area of operations area of responsibility antenna position control unit antenna pedestal group American Standard Code for Information Interchange Assistant Secretary of Defense (C3I) automatic send/receive Air Warfare Commander
BCIXS BER BLK BLOS BMC bps
Battle Cube Information Exchange System bit error ratio block (Milstar) beyond line-of-sight Battle Management Center bits per second
C0 C1 C2 C2H C2M
primary subchannel communications service secondary subchannel communications service command and control, or uplink control subchannel uplink cover key, high privilege level (UFO/E) uplink cover key, medium privilege level (FEP, UFO/E) Command and Control Warfare C2W Commander command, control, and communications, or downlink control subchannel command, control, communications, and intelligence command, control, communications, computers, and
C2W C2WC C3 C3I C4I
ORIGINAL A-1
ANNEX A NTP 2 SECTION 3 (B) C4ISR CA CAM CC CCC CCS CDMA CDU CEG CFD CG CIB/CIA CIK CINC CINCLANTFLT CINCNET CJCS CJCSI CJTF CMC CMCS CMIO CMS CNO COCOM COI COMARFORLANT/PAC COMMPLAN COMNAVCOMTELCOM COMNAVSPACECOM COMSEC COMSPAWARSYSCOM COMSPOT COMSUBGRU COMSUBLANT COMSUBPAC CONOPS CONUS COR
intelligence C4I, surveillance, and reconnaissance controlling authority (COMSEC) channel access master (VERSIMUX card) communications controller CINC Command Complex Combat Control System (submarine), or Constellation Control Station code-division multiple access command decoder unit communications equipment group common fill device Commanding General Communications Information Bulletin/Communications Information Advisory crypto ignition key Commander in Chief Commander in Chief, U.S. Atlantic Fleet CINC Network Chairman of the Joint Chiefs of Staff CJCS Instruction Commander Joint Task Force Commandant of the Marine Corps COMSEC Material Control System COMSEC Material Issuing Office COMSEC Material System Chief of Naval Operations Combatant Commander course of instruction Commander Marine Corps Forces Atlantic/Pacific communications plan Commander, Naval Computer and Telecommunications Command Commander, Naval Space Command communications security Commander Space and Naval Warfare Systems Command Communications Spot Report Commander Submarine Group Commander, Submarine Forces Atlantic Commander, Submarine Forces Pacific concept of operations continental United States Central Office of Record ORIGINAL A-2
ANNEX A NTP 2 SECTION 3 (B) COT COTS CRD CSA CSAF CSG CUS CVSD CWC
changeover time commercial off-the-shelf Capstone Requirements Document Chief of Staff, U.S. Army Chief of Staff, U.S. Air Force cryptologic support group common user software continuously variable slope delta Composit Warfare Commander
DAMA DCCS DCMS Delta-T Det DISA DISN DL DLI DMS DOD DON DPSK DSN DSVT DTC DTD DTE DUCA
demand assigned multiple access Designated CCS Director COMSEC Material System time offset detachment Defense Information Systems Agency Defense Information Systems Network downlink digital link interface Defense Message System Department of Defense Department of the Navy differential phase-shift keying Defense Switched Network Digital Secure Voice Terminal desktop tactical computer data transfer device data terminal equipment Distributed User Coverage Antenna
EAP EC EHF EIRP EKMS EMI EMP ESC ET
emergency action plan Earth coverage extremely high frequency effective isotropic radiated power Electronic Key Management System electromagnetic interference electromagnetic pulse Electronic Systems Center Earth terminal
14 AF 50 SW FDMA FDX
14th Air Force 50th Space Wing frequency-division multiple access full-duplex ORIGINAL A-3
ANNEX A NTP 2 SECTION 3 (B) FEP FEPOC FET FLT FLTCINC FLTSAT FOT FSB FSD FSK FTC FTP
FLTSAT EHF Package FEP Operations Center field-effect transistor flight (Milstar) Fleet Commander in Chief Fleet Satellite Follow-on Terminal Fleet Satellite Broadcast full-scale development frequency-shift keying Fleet Training Center Fleet Telecommunications Procedures
GBS GFCP GHz GLOBIXS GNDCP G/T GU
Global Broadcast Service Generic Front-end Communications Processor gigahertz Global Information Exchange System Ground-based, Fixed Command Post gain/transmit group unique (KEK)
HDX HEMP HF HHR HMMWV HPA HQMC HVPS Hz
half-duplex high-altitude electromagnetic pulse high frequency high hop rate high-mobility multipurpose wheeled vehicle high-power amplifier Headquarters, Marine Corps high-voltage power supply hertz
ICDB ID IF IMMIS
Integrated Communications Database identification intermediate frequency Integrated MILSATCOM Management Information System input/output initial operational capability In-Service Engineering Agency information transfer Information Technology for the 21st Century Integrated Undersea Surveillance System information exchange subsystem
I/O IOC ISEA IT IT-21 IUSS IXS
ORIGINAL A-4
ANNEX A NTP 2 SECTION 3 (B) JCS JCSC JCSI JFTOC JIC JMCCOC JMCOMS JMP JMPA JSP JTF JTG JTPO
Joint Chiefs of Staff Joint Communications Satellite Center Joint Chiefs of Staff Instruction Joint Fleet Telecommunications Operations Center Joint Intelligence Center Joint Milstar Communications Control and Operations Concept Joint Maritime Communications Strategy Joint MILSATCOM Panel Joint MILSATCOM Panel Administrator Joint SATCOM Panel joint task force joint task group Joint Terminal Program Office
kbps KEK KEYMAT kHz KSA
kilobits per second key encryption key keying material kilohertz keep service alive
LAN LBAD LDR LEASAT LHR LNA LOS LPC LPD/LPI LPE LSTDM LTA
local area network Lexington Bluegrass Army Depot low data rate Leased Satellite low hop rate low noise amplifier line-of-sight linear predictive coding low probability of detection /low probability of intercept low probability of exploitation low-speed time-division multiplexer local training authority
MACOM MAGTF MAJCOM MASC Mbps MBS MCCDC MCPT MCS
major command (U.S. Army) Marine Corps Air Ground Task Force major command (U.S. Air Force) Milstar Auxiliary Support Center megabits per second mission bit stream Marine Corps Combat Development Center Milstar Communications Planning Tool mission control segment (Milstar) ORIGINAL A-5
ANNEX A NTP 2 SECTION 3 (B) MCST MDE MDR MDU MGS MHz MILSATCOM MIL-STD MIT/LL MJCS MMT MNS MOC MOCC MOG MOP MS MSCOP&P MSE MSOC MUS MWP NAEDSS NATO NAVCOMMSTA NAVCOMPARS NAVSOC NAVSPACECOM NAVSUBSCOL NCA NCTAMS NCTS NDI NECC NECOS NESP NIU NKMS
Milstar Communications Support Tool Mission Development Element medium data rate Mission Data Update (Tomahawk) mission ground station megahertz military satellite communications military standard Massachusetts Institute of Technology/Lincoln Laboratory Memorandum, Joint Chiefs of Staff multimedia terminal mission needs statement Milstar Operations Center Mobile Operations Command Center master oscillator group Memorandum of Policy Microsoft Milstar Standard Communications Operations Policies and Procedures Mobile Subscriber Equipment, or Mission Support Element Milstar System Operations Center (formerly the MOC) mission unique software microwave processor NESP Adaptation and Ephemeris Data Support System North Atlantic Treaty Organization Naval Communication Station Naval Communications Processing and Routing System Naval Satellite Operations Center Naval Space Command Naval Submarine School National Command Authorities Naval Computer and Telecommunications Area Master Station Naval Computer and Telecommunications System, or Station nondevelopmental item Navy EHF Communications Controller Network Control Station Navy EHF SATCOM Program NSCS Interface Unit Navy Key Management System ORIGINAL A-6
ANNEX A NTP 2 SECTION 3 (B) nm NOC NSA NSB NSCN NSCS NST NSTA NT NTDN NTP NVRAM NWP
nautical mile Network Operations Center National Security Agency Nulling Spot Beam Navy Satellite Control Network Navy Satellite Control Station Navy Standard Teleprinter Naval Standard Teleprinter Ashore new technology Navy Terminal Data Node Naval Telecommunications Procedures nonvolatile RAM Naval Warfare Publication
OPORD ORD OSA OT&E OTA OTAD OTAR OTAT OTCIXS OTH-T
operations order operations requirements document open systems architecture operational test and evaluation over-the-air over-the-air distribution over-the-air rekey over-the-air transfer Officer-in-Tactical Command Information Exchange Subsystem over-the-horizon targeting
PC PCM PDU PEP PM PN POC PQS PROM psi PSK PTP
personal computer pulse code modulation power distribution unit Polar EHF Package Program Manager pseudonoise point of contact personnel qualification standards programmable read-only memory pounds per square inch phase-shift keying point-to-point
R&D RAC RADAY RAM RDT&E
research and development robust access control radio day random access memory research, development, test, and evaluation ORIGINAL A-7
ANNEX A NTP 2 SECTION 3 (B) RF RGF ROB ROX RTMM
radio frequency Remote Ground Facility reserve on board receive-over-transmit removable transportable memory modules
SAR SARK SAS SATCOM SCAMP SCCCS SCOC SCP SCT SDR SEAL SECDEF SGLS SHF SINS SIOP SIPRNET SMART-T SMCS SOC SOM SOMO SOPS SPAWARSYSCEN SPAWARSYSCOM SPECOPS SRB SRBP SRC SSA SSC SSE STRAT STU-III STW STWC SUB HDR SUBOPAUTH
satellite access request SAVILLE Advanced Remote Keying Single Audio System satellite communications Several Channel Advanced Manportable Satellite Control CCS system control and operations concept Spacecraft Control Processor Single Channel Transponder Service/Deficiency Report Sea-Air-Land (Navy) Secretary of Defense Space-Ground Link Subsystem super high frequency Ship Inertial Navigation System Single Integrated Operations Plan Secret Internet Protocol Router Network Secure Mobile Antijam Reliable Tactical Terminal Satellite Mission Control Subsystem Satellite Operations Center SATCOM Operational Manager System Operational Management Office Space Operations Squadron Space and Naval Warfare Systems Center Space and Naval Warfare Systems Command special operations submarine reportback SRB processor Satellite Resource Controller solid-state amplifier SATCOM Support Center SATCOM System Expert uplink strategic cover key (Milstar) Secure Telephone Unit, third generation Strike Warfare STW Commander submarine high data rate Submarine Operating Authority ORIGINAL A-8
ANNEX A NTP 2 SECTION 3 (B) SUW SUWC
Surface Warfare SUW Commander
T&C T&C NET TT&C TAC1 TAC2 TAC-3 or 4 TACAMO TADIXS TCC TCF TCP TCP/IP TCU TDM TDMA TDN TDP TEK TEU TFEPOC TM TMS-C TOC TOD TRANSEC TRI-TAC TSK TST TTY TU TWCS TWT
telemetry and commanding T&C Network telemetry, tracking, and commanding uplink tactical 1 cover key (Milstar) uplink tactical 2 cover key (Milstar) Tactical Advanced Computer, third or fourth generation Take Charge and Move Out Tactical Data Information Exchange System/Subsystem tactical command center technical control facility terminal control processor transmission control protocol/internet protocol terminal control unit time division multiplex, or time division multiplexer time-division multiple access terminal data node tactical data processor traffic encryption key telemetry encoder unit transportable FEPOC transparent message Telecommunications Management System-Classified Transportable Operations Center time of day transmission security Tri-Service Tactical Communications TRANSEC key Transmission Systems Technician teletype terminal unique (KEK) Tomahawk Weapon Control System traveling wave tube
U&S UEM UFO UFO/E UFO/EE UHF UL ULCS
Unified and Specified User Ephemeris Message UHF Follow-on UFO, with EHF Package UFO/E Enhanced ultra high frequency uplink unit level circuit switch ORIGINAL A-9
ANNEX A NTP 2 SECTION 3 (B) UPS USCINCJFCOM USCINCPAC USCINCSPACE USSPACECOM USW USWC UTP
uninterruptible power supply Commander in Chief, U.S. Joint Forces Command Commander in Chief, U.S. Pacific Command Commander in Chief, U.S. Space Command U.S. Space Command Undersea Warfare USW Commander uplink timing probe
VGA VIP VME VSWR
video graphics adapter very important person Versa Module Eurocard voltage standing wave ratio
WAN
wide-area network
XOR
transmit-over-receive
ORIGINAL A-10
ANNEX B TO NTP 2 SECTION 3 (B) ANNEX B GLOSSARY
Access - The ability and means necessary to store data, retrieve data, or communicate with a system. Adaptation Data - Parameters in the terminal program database which identify the terminal type to be initialized, configuration of the terminal platform, and antenna blockage profiles. Agile Beam - A type of antenna, used on Milstar satellites, through which areas are illuminated with multiple beams in a time division multiplex (TDM) fashion to provide an Earth field of view. Algorithm - A step-by-step mathematical procedure for repeating an operation or solving a problem. Antijam (AJ) - Measures to ensure that intended transmitted information can be received despite deliberate jamming attempts. Asynchronous Transmission - Data transmission in which the instant that each character, or block or characters, starts is arbitrary; once started, the time of occurrence of each symbol representing a bit within a character, or block, has the same relationship to significant instants of a fixed time frame (e.g., teletypewriter signals). Azimuth - An angular measurement of direction in degrees from a known reference (e.g., true North). Bandwidth - The range of frequencies over which an amplifier or receiver will respond and provide a useful output. Baseband - The band of frequencies occupied by the aggregate of the transmitted signals used to modulate a carrier, before they combine with a carrier in the modulation process. Bit - Abbreviation for binary digit (1 and 0). Bit Error Ratio (BER) - The total number of erroneous binary (bit) values divided by the total number of binary values transmitter, received, or processed over a circuit or system during a specified time period (e.g., 1 x 10-5 BER). Bit Interleaving - The process of mixing the order in which the bits of baseband traffic are transmitted. This is done to counter the effects of short outages caused by scintillation, fading, and antenna blockages.
ORIGINAL B-1
ANNEX B TO NTP 2 SECTION 3 (B) Broadcast - A form of communications in which a single terminal is designated as the transmitter and all other terminals are receive only. Cesium Standard - A primary frequency standard in which electronic transitions between the two hyperfine ground states of cesium-133 atoms is used to control the output frequency. Commander in Chief Network (CINCNET) - A network established on the Milstar system for use by the National Command Authorities (NCA) and Unified Commanders in Chief (CINC). Communications Security (COMSEC) - Measures and controls taken to deny unauthorized persons information derived from telecommunications and ensure the authenticity of such telecommunications. Crossband - The use of frequencies in different allocated bands for the uplink and downlink. Crosslink - A transmission link carrying information from one Milstar satellite to another. Demand Assigned Multiple Access (DAMA) - An access scheme in which access to a channel by geographically separated communications terminals is allocated on user demand. Differential Phase-Shift Keying (DPSK) - A method of encoding each element of a signal for transmission as a change in the phase of the carrier with respect to its previous phase angle. Digital Interface - A common connection for sharing information in a binary form. Down-converter - A device which translates frequencies so that the output frequencies are lower than the input frequencies. Downlink - A transmission link carrying information from a satellite to a terrestrial terminal. Drift - The slow undesired movement of a satellite from its intended position. Duplex Circuit - A communications circuit that allows each end-user to simultaneously transmit and receive information. Earth Coverage - That portion of the Earth seen by the satellite. Earth Terminal (ET) - The Earth portion of a satellite link that receives, processes, and transmits satellite communications. ETs may be mobile, fixed, airborne, or waterborne. Effective Isotropic Radiated Power (EIRP) - The arithmetic product of the power supplied to an antenna and its gain.
ORIGINAL B-2
ANNEX B TO NTP 2 SECTION 3 (B) Electromagnetic Pulse (EMP) Hardening - The physical protection of electrical/electronic equipment against the broadband, high intensity effects of electromagnetic energy characteristic of a nuclear explosion. Elevation - An angular measurement in a vertical plane measured in degrees from the horizon. The height to which something is elevated above a point of reference, such as the ground. Ephemeris - Data that defines the position of a satellite or spacecraft in space with respect to time. Extremely High Frequency (EHF) Band - The frequency band extending from 30 to 300 GHz. Firmware - Software that is embedded in a hardware device that allows reading and executing the software, but does not allow modification, e.g., writing or deleting data by an end user. Frequency-Division Multiple Access (FDMA) - The use of frequency division to provide multiple and simultaneous transmissions to a single transponder. Frequency Hopping - A method of automatically and rapidly shifting the transmitter frequency during transmission to assist in AJ protection. Frequency Permutating - A process of pseudorandomly spreading out the tones of an uplink channel over the entire bandwidth of the associated satellite receiver. The process defeats certain types of jammers. Frequency-Shift Keying (FSK) - A frequency modulation technique in which the modulating wave shifts the output frequency between predetermined vales. The Navy standard shift is 170 Hz between center frequencies. Full-duplex (FDX) - That mode of operation in which communications between two terminals occurs in either direction simultaneously . Geosynchronous (Geostationary) Satellite - An Earth satellite whose period of revolution is equal to the period of rotation of the Earth about its axis. In that the satellite position is relatively stationary to a point on the Earth’s surface, such a satellite may also be known as geostationary. Guard Band - The unused frequency band between two satellite transponder channels which provides a margin of safety against mutual interference. Half-duplex (HDX) - That mode of operation in which communication between two terminals occurs in either direction, but in only one direction at a time. Hardware - The built-in physical components of a system that are mechanical, magnetic, electrical, or electronic devices. ORIGINAL B-3
ANNEX B TO NTP 2 SECTION 3 (B) High-Altitude Electromagnetic Pulse (HEMP) - An electromagnetic pulse produced as a result of a nuclear explosion at an altitude approximately 120 kilometers above the Earth’s surface. Hop Rate - The rate at which the transmitter frequency changes. In EHF SATCOM systems, there are two hop rates, referred to as high hop rate (HHR) and low hop rate (LHR). Jamming (or jamming signals) - The deliberate radiation, reradiation, or reflection of electromagnetic energy for the purpose of disrupting enemy use of electronic devices, equipment, or systems. Ka-band - The frequency band between 17.7 and 21.2 GHz. Ku-band - The frequency band between 10.95 and 14.50 GHz. L-band - The frequency band between 390 to 1550 MHz. Limiter - A device in which some characteristic of the output is automatically prevented from exceeding a predetermined value (e.g., an amplifier in which the output amplitude is substantially linear, with regard to the input) and is substantially constant thereafter. Look Angle - The angle relative to the earth surface at which a satellite antenna is pointing at the satellite. Mission Bit Stream (MBS) - The information transmission rate less any overhead generated in any fixed time interval of a bit stream transmission. Modulation - The process, or result of the process, of varying a characteristic of a carrier in accordance with an information-bearing signal. Multiple Access - In satellite communications, the capability of a communications satellite to function as a portion of a communications link between more than one pair of satellite terminals concurrently. Multiplexing - The combining of two or more information channels onto a common transmission medium. Network - An interconnection of three or more communicating entities. Node - A terminal of any branch of a network or a terminal common to two or more branches of a network. Orderwire - A voice or data circuit used by technical control and maintenance personnel for coordination and control actions relative to activation, deactivation, change, rerouting, reporting, and maintenance of communications systems and services. ORIGINAL B-4
ANNEX B TO NTP 2 SECTION 3 (B) Over-the-Air Rekey (OTAR) - A means of electronically distributing keying material to users via RF medium (e.g., SATCOM). Payload - The spacecraft communications package. Phase-Shift Keying (PSK) - A method of angle modulation in which the phase of the carrier is discreetly varied in relation to either a reference phase or the phase of the immediately preceding signal element. Point-to-Point (PTP) Call - A full or half-duplex means to exchange data, facsimile, teletype, or voice communications between two terminals only. Polarization - Of an electromagnetic wave, the property that describes the orientation of, i.e., time-varying direction and amplitude, of the electronic field vector. Precedence - A designated level of service used to determine the priority in which satellite payload resources are allocated. Primary Channel - The channel that is designated as a prime transmission channel and is used as the first choice in restoring priority circuits. Privilege - The ability of a terminal to perform functions (e.g., activate or modify service, move spot beams, activate or modify PTP calls) which affect other terminals. Protocol - A formal set of conventions governing the format and control of interaction among communicating function units. For EHF this entails an exchange of control messages between the terminal and the satellite to accomplish a particular function (e.g., activating a network). Pulse-code Modulation (PCM) - The form of modulation which sequentially samples, quantizes, and digitizes a modulated signal into a binary form for transmission over a digital link. Q Band - A band of frequencies extending from 36 to 46 GHz. Random Noise - Noise consisting of a large number of transient disturbances with a statistically random time distribution. Satellite Constellation - The satellites in a common orbit used by a SATCOM system. Secondary Channel - The channel that is designated as a secondary transmission channel and is used as an alternate choice in restoring priority circuits. Sidelobe - A portion of the beam from an antenna other than the main lobe. It is usually much smaller and in any direction other than that of the main lobe.
ORIGINAL B-5
ANNEX B TO NTP 2 SECTION 3 (B) Software - The programs, routines, codes, and other written information for use with digital computers. Solar Array - A group of interconnected solar cells that convert solar energy directly into electrical energy. Spot Beam - A narrow antenna beam of approximately 5° beamwidth or less used to illuminate selected terrestrial areas. A type of antenna used on EHF satellites which is steerable so that the aim point can be controlled by command. Spread Spectrum Modulation - A communication and modulation technique that makes use of sequential noise-like signals to spread the normal narrowband information over a relatively wide band of frequencies to protect against jamming. Station Keeping - The process of keeping a satellite in its assigned orbital location. Symbol Hop Redundancy - The process of transmitting the same information on multiple hops combining the energy of those hops at the receiver to effectively increase the signal level. Synchronous Data Network - A data network in which synchronism is achieved and maintained between data terminal equipment (DTE) and data communications equipment (DCE), and between DCEs. The data signaling rates are controlled by timing equipment within the network. Super High Frequency (SHF) Band - The frequency band extending from 3 to 30 GHz. Technical Control Facility (TCF) - A facility where the satellite system and the terrestrial communications system are interfaced. Telecommunications Service - A specified set of user-information transfer capabilities provided to a group of users by a telecommunications system. Telemetry - The process of use telecommunications to automatically read and record satellite status information. Telemetry and Commanding (T&C) - The recording, processing, transmission, or interpretation of data obtained by automatic remote sensors through the use of a control signal. Telemetry, Tracking, and Commanding (TT&C) - TT&C is the method of determining the operational status of a satellite, maintaining the satellite on station, and controlling the configuration and operating levels of the satellite. Time-Division Multiple Access (TDMA) - The use of time division to provide multiple and simultaneous transmission to a single transponder.
ORIGINAL B-6
ANNEX B TO NTP 2 SECTION 3 (B) Time-Division Multiplexing (TDM) - A method of deriving two or more apparently simultaneous channels from a given frequency spectrum of a transmission medium connecting two or more points by assigning discrete time intervals in sequence to each of the individual channels. During a given time interval the entire available frequency spectrum can be used by the channel to which it is assigned. Tracking - The process of maintaining the position and range information of a satellite to aid in sustaining the satellite’s orbital position. Transmission Security (TRANSEC) - That component of communications security which consists of all measures designed to protect radio transmissions from interception and exploitation by means other than cryptoanalysis. Transponder - A device that automatically receives, amplifies, and retransmits a signal on a different frequency. Ultra High Frequency (UHF) Band - The frequency band extending from 300 to 3,000 MHz (or 3 GHz). Navy UHF SATCOM utilizes 225 to 400 MHz, the upper portion of the very high frequency (VHF) band and the lower portion of the UHF band. Up-converter - A device which translates frequencies so that the output frequencies are higher than the input frequencies. Uplink - The transmitted link carrying information from an Earth terminal to a satellite. X-band - The radio frequency band between 5.2 and 10.9 GHz.
ORIGINAL B-7
NTP 2 SECTION 3 (B) LIST OF EFFECTIVE PAGES
Subject Matter
Page Numbers
Change in Effect
Title Page
I
Original
Foreword
II
Original
Letter of Promulgation dated 29 March 2001
III
Original
Record of Changes and Corrections
IV to V
Original
Table of Contents
VI to VIII
Original
TEXT
Original
Chapter 1
1-1 to 1-12
Original
Chapter 2
2-1 to 2-36
Original
Chapter 3
3-1 to 3-24
Original
Chapter 4
4-1 to 4-24
Original
Chapter 5
5-1 to 5-9
Original
Annex A
A-1 to A-10
Original
Annex B
B-1 to B-7
Original
List of Effective Pages
LEP-1
Original
Feedback Report
Unnumbered
Original
ORIGINAL LEP-1
COMMUNICATIONS PROCEDURES FEEDBACK REPORT ____ Date From:
______________________________________________ ______________________________________________ ______________________________________________
To:
Commander, Naval Space Command (Code N52) 5280 Fourth Street Dahlgren, VA 22248-5300
Subj.:
Communications Procedures Feedback Report
Publication:
_________________________________________
Paragraph No.:
_________________________________________
Other:
_________________________________________ _________________________________________ _________________________________________
Problem Area:
Comments:
_______
Typographical
_______
General
_______
New Procedures
_______
Other
_______
Obsolete
_______
Inadequate
_______
Conflicting
______________________________________________________________ ______________________________________________________________ ______________________________________________________________
