SECTION 2
COMMUNICATIONS SYSTEM REQUIREMENTS
The mission and roles discussed in Section 1 place certain minimum requirements on the C 4 I
links to and from submarines. This section summarizes these communications requirements, as
referenced in the appropriate Mission Needs Statement (MNS), Operational Requirements
Document (ORD) and joint COMSUBLANT/COMSUBPAC requirements letters. Integrated
submarine C 4 I includes SCSS, JMCIS, CCS, and a platform local area network (LAN).
2.1 SUBMARINE COMMUNICATIONS REQUIREMENTS
OPNAV, USSTRATCOM, CINCSOC, COMSUBLANT and COMSUBPAC have jointly
identified the following requirements for submarine communications:
- Be fully interoperable with and be able to send/receive mission related information
to/from the JTF. [Interoperability]
- Submarine radio rooms must be based on an Open System Architecture (OSA), in step
with the Copernicus architecture and be CSS capable. [Open Systems Radio Room]
- Sufficient throughput for timely transfer of strike and surveillance data, including
imagery. [Throughput]
- Be able to maintain continuous record traffic without mast exposure. [Covert receipt of
record communications]
- Connectivity to Super High Frequency (SHF) link absolutely essential.
- Submarine High Data Rate (HDR) information throughput requirements of 128 kilobits
per second (kbps) in 1995, 256 kbps in 1998, 512 kbps in 2002, and 1.544 megabits
per second (Mbps) (T1) in 2006, are needed to support Task Force operations,
Intelligence gathering, Tomahawk Strikes, and SOF missions.
- SSBNs must possess highly survivable and robust communications capable of
satisfying CJCS Nuclear Technical Performance Criteria.
Submarine requirements for HDR satellite communications (SATCOM) were defined by
COMSUBLANT in a requirement’s letter of 29 November 1994. The Joint
COMSUBPAC/COMSUBLANT requirements letter dated 04 November 1993 identified several
specific requirements, concentrated in two areas: (1) New Antenna Design and Configuration
and (2) Interoperability. Tables 2-1 through 2-5 address these requirements and summarize the
capabilities being fielded by current (FY96) and planned acquisition programs. These
requirement letters may be found in Appendix E.
2.2 SUBMARINE COMMUNICATIONS SUPPORT SYSTEM REQUIREMENTS
One of the immediate tasks delineated by the Navy in “From the Sea” is to continue the full
integration of SSNs into expeditionary task forces. To be effective units of a Naval Task Group
within a joint, Tailored Forward Element (TFE), submarines must be fully interoperable with
both Naval and Joint communication systems. Submarines must be capable of tailoring on-board
capabilities to optimize their support for the Joint Task Force (JTF) and Naval Component
Commanders. The SCSS strategy is to provide a radio room architecture with open system
features that will provide a much improved level of communications flexibility and
interoperability for submarines.
SCSS requirements are evolving and will continue to evolve over time with the Navy’s CSS
requirements and as a subset of the Joint Chiefs of Staff (JCS) “C 4 I for the Warrior” and the
Navy’s Copernicus communication architectures. The Submarine CSS program will implement
an open system, multimedia, circuit sharing architecture which: (1) allows users to share all
communication circuits available; (2) permits easy, cost effective expansion to accommodate
new capabilities; (3) reduces development, production, and support costs by using common
hardware and reusable software; and (4) will be fully interoperable with Navy JMCIS.
2.3 SUBMARINE COMMUNICATIONS SUPPORT SYSTEM COMPATIBILITY WITH
OTHER NAVY SYSTEMS
In addition to operational requirements determined by the submarine force, the SCSS must be
compatible with Navy/Joint and various commercial systems and standards. The major ones are
discussed in the following paragraphs.
2.3.1 Submarine Communications Support System Interface with the Joint Maritime
Command Information System
The SCSS will be interoperable with the Navy JMCIS in three ways. First, for interoperability
with the submarine Command and Control systems (e.g., Joint Operational Tactical System
[JOTS], Navy Tactical Command System - Afloat [NTCS-A]), the SCSS will make use of the
Generic Front End Control Processor (GFCP). The GFCP provides flexible input/output (I/O)
processing and protocol conversion between the SCSS and the submarine CCSs enabling JMCIS
data to be used and displayed. The GFCP replaces the Sensor Interface Unit (SIU) presently
used on-board most submarines. Second, submarines will strive for JMCIS compliance by using
JMCIS/Unified Build software and operating systems whenever feasible in the deployment of
the SCSS C 4 I systems. Finally, items such as the SCSS Integrated Network Manager (INM),
which is part of the Submarine BBS program, will be JMCIS-compliant.
2.3.1.1 Joint Maritime Command Information System Description
JMCIS refers to two things: (1) a “Superset” collection of software modules which can be
customized and configured to build a Command Information System; and (2) a Navy fielded
Command Information System (e.g., a collection of software and actual fielded systems). The
Navy developed JMCIS software is the “software core” around which Office of the Secretary of
Defense (OSD) and DISA are deploying the GCCS. JMCIS will be the Navy’s implementation
of GCCS Afloat.
Submarine JMCIS refers to an open architecture system and a software development
environment that offers a collection of services and already built software modules for Command
Information System components. Figure 2-1 shows a high level architectural view of Integrated
Submarine C 4 I.
It is important to understand the following aspects of JMCIS:
- JMCIS is not the same as Unified Build, NTCS-A, or Operational Support System
(OSS), but each of these have contributed software to the JMCIS superset.
- JMCIS is not a solution for all command and control problems. However, the
number of applications, whether or not related to C 2 , which share common
requirements with JMCIS is large.
- JMCIS is not government modified commercial off-the-shelf (COTS) products.
Commercial software is used whenever practical, but the executable code and data
files are not modified except to customize the COTS products.
- JMCIS is not a deviation from accepted industry standards (e.g., Motif Style Guide).
- JMCIS is not vendor proprietary.
JMCIS is managed Navy-wide by SPAWAR (PD 70 and PMW 171).
The submarine implementation of JMCIS will consist of loading a COMSUBLANT/
COMSUBPAC-approved selection of JMCIS software modules on JMCIS compliant computers
and is the responsibility of Naval Sea Systems Command (NAVSEA).
2.3.2 Submarine Communications Support System Interface with the Defense Messaging
System
The Defense Message System (DMS) is a joint DOD program created to improve DOD’s
electronic messaging and interpersonal electronic mail (e-mail) capabilities, while reducing cost.
The DMS will replace the baseline Automatic Digital Network (AUTODIN) messaging and
Simple Mail Transfer Protocol (SMTP) e-mail with a system based on the International
Telecommunications Union (ITU) recommendations for Automatic Message handling, X.400,
and Directory Services, X.500. The DISA DMS Program management has planned an
evolutionary program in which the DOD DMS architecture will be implemented through a series
of phases over time. Within the Navy, SPAWAR PMW 172 manages the DMS program for
shore and afloat implementation. The two major infrastructure programs that will be used to
incorporate automatic message handling is the Naval Modular Automated Communications
System (NAVMACS) for Surface afloat units and the Naval Communications Processing and
Routing System (NAVCOMPARS) for activities ashore.
The SCSS Exterior Communications System will be fully DMS compliant. In the near-term,
submarine SCSS DMS implementation is planned to provide DMS services while the submarine
is pierside. In this planned architecture, the UNIX-based SMB will host DMS applications
supporting communications front end processing and message routing functions based on
classification (SECRET and below message will be routed via a submarine LAN). Multi-Level
Information System Security Initiative (MISSI) products (FORTEZZA with Assure) will be used
for information security (INFOSEC), and Lotus Notes will be used for message profiling,
storage, and routing to individual users. Messages from the submarine can be transferred into
the Defense Information System Network (DISN) through landline connectivity or by
transferring DMS messages onto a floppy disk for hand delivery to an appropriate shore activity
that provides a DISN interface.
In the long term, as the DMS is incrementally implemented into the fleet for tactical DMS
message delivery while underway, the submarine SCSS ECS architecture will support the receipt
of tactical messages via X.400/X.500 messaging.
2.3.3 Submarine Communications Support System Interface with the Submarine Local
Area Network
Automated distribution of data is required on submarines and will be implemented in accordance
with the Submarine Afloat Information Systems Strategic Plan (CSLNOTE 5230 of 31 Jun 94).
SPAWAR PMW 174 is working with NAVSEA and PMW 173 to field the Standard Non-Tactical
Automated Data Processing Program (SNAP III) LAN on submarines. This element of
the submarine integrated C 4 I is described by the SCSS Security Concept of Operations
(SCONOP).
2.3.4 Submarine Communications Support System Interface with the Submarine Combat
Control System
The SCSS is the ECS through which the CCS sends and receives data to and from the telesphere.
This element of the submarine integrated C 4 I is the responsibility of NAVSEA.
2.4 Polar Coverage Requirements
Submarines require polar communications capability. This requirement is being addressed by
Navy/Joint Systems under direction of the Joint Staff (J61).
