Navy Radio Traffic Handling, Circuits, and Message Processing

Afloat Communications Systems - 1972 Radioman A School Training Material
   - See More Training Material Here

(from "Fleet Multi-channel Broadcast Traffic Intensity Study" by LCDR Harlan Daryl Oelmann, June 1972 - 8MB pdf)


The Naval Communications System is composed of 27 Naval Communications Stations (NAVCOMMSTAs ) , 4 Naval Communications Units (NAVCOMMUs) and several Naval Radio Stations (NAVRADSTAs). These stations are located throughout the world and are organized into several Naval Communications Areas (NAVCOMMAREAs) . The primary purpose of these stations is to relay messages to and from ships of the fleet andshore establishments within their area of responsibility.

The stations within a NAVCOMMAREA are organized under one NAVCOMMSTA which is designated as the Naval Communications Area Master Station (NAVCAMS) while the other stations are designated as Naval Communications Area Local Stations (NAVCALS) . Although the communication means which each of these stations use take several forms, such as teletype, voice and CW, etc. , this study is concerned only with teletype communications and the fleet broadcast system. Therefore discussion will consider only those areas.


It is assumed that to most readers, teletype communications is a familiar means of communication which does not require detailed explanation, except to note that when messages are handled physically within a station they are handled in teletype tape or chad tape form. Hence in further discussion when we speak of messages being handled in a station it is implicitly meant that such messages are in tape form unless otherwise stated.

1. World Wide Teletype Communications

The Defense Department World Wide telecommunications system controlled by the Defense Communication Agency provides for long-haul and point-to-point telecommunications between communications stations of the Armed Forces which include the NAVCOMMSTAs and other stations within the NAVCOMMAREAs . This system is known as the AUTODIN network which is a digital high speed message transmission system.

2. Local Teletype Communications

The primary means of communications between a NAVCOMMSTA and the ships at sea is a teletype system which operates at the rate of 100 words-per-minute (wpm), where one teletype word is equivalent to 5 teletype characters.

There are essentially three methods of teletype communication between the ships at sea and the shore based NAVCOMMSTA.

The fleet broadcast system is composed of several different types of broadcasts. These are the fleet multichannel broadcast, on which this study is based, a single channel broadcast for ships that are not equipped to copy the multi-channel broadcast, the submarine broadcast and a merchant ship broadcast. In some NAVCOMMAREAs these broadcasts are all operated by one NAVCOMMSTA or Broadcast Control Station (BCS) while in other NAVCOMMAREAs these separate broadcasts are operated by two or more NAVCOMMSTAs . Also if the capability of flexibility exists, a separate additional broadcast may be created within a NAVCOMMAREA to handle special traffic load situation. Sometimes a NAVCAMS may shift a broadcast to a NAVCALS in an emergency or to maintain proficiency among the capable NAVCALS in operating the broadcast.


Naval communications messages are assigned one of four precedences. Each message precedence has a Speed of Service Criteria, which is a time standard for a message to take in transmission from the origination of the message to the receipt of the message by the addressee. These criteria are shown in Table XVI below. The letter in parenthesis is the designator of the precedence.


Precedence  Average Speed
of Service
Flash (Z) As fast as
humanly possible
Immediate (O) 30 minutes 30 minutes-1 hour
Priority (P) 3 hours 1-6 hours
Routine (R) 6 hours 3 hours-to the start of 
the next business day


There are normally five fleet multi-channel broadcasts operated in the Naval Communications System. Each broadcast which serves a particular ocean area is operated by a designated NAVCOMMSTA or Broadcast Control Station. These broadcasts have designations of NMUL, EMUL, KMUL, FMUL and GMUL, where FMUL serves the Eastern and Mid-Pacific Ocean area and is normally operated by NAVCOMMSTA San Francisco [10].


The fleet multi-channel broadcast is a multiplex system which has 8 separate 100 wpm teletype traffic channels which are transmitted on a single carrier frequency. The alignment of the traffic channels is such that the overall broadcast traffic load to the fleet is segregated on the basis of ship type where each subscriber is served by two traffic channels, a primary channel and a secondary channel. An example of the overall broadcast channel alignment, channel designations and uses of each channel is shown in Table XVII below.


Channel  Designation  Use
1 FASW Destroyer force primary traffic channel
2 FSPC 1 hour delayed rebroadcast of channel 1 or overload as necessary
3 FALD Service, Amphibious and Mine force primary traffic channel
4 FUSN 1 hour delayed rebroadcast of channel 3 or overload as necessary
5 FNSC Major warships (carriers, cruisers, large destroyers, including flagships) primary traffic channel
6 FOPI Special traffic channel (NAVSECGRU)
7 FHIC 1 hour delayed rebroadcast of channel 5 or overload as necessary
8 FMET Weather traffic channel


The fleet multi-channel broadcast system for each channel is a guard system. This means that each subscriber copying a particular channel screens each sequentially serial-numbered message sent on that channel to determine whether that particular message is addressed to him or not. If the message is for the ship or for the embarked staff the message is processed. If it is not for that particular ship or embarked staff the message is ignored and filed. Hence a subscriber must perform two necessary actions. He must determine from the message heading (which contains the addressees) whether the ship or embarked staff is an addressee or not. If the message is addressed to the ship then it must be copied without errors from beginning to end. That is the addressee must have a clear enough copy that he is able to obtain all the information transmitted without any doubt as to what the message says.

If a subscriber has missed part or all of the heading such that he cannot determine whether the message was addressed to him or not, or if he has missed part or all of the text then we will refer to such a message as a "missed message."

A message may be missed for various reasons, some of which are: environmental or atmospheric conditions, which cause deterioration of the radio signal, equipment failure on the ship or in some cases error in judgment of the operator monitoring the teletype printer.


If a subscriber copying a particular channel has missed one or more messages he must determine whether the message(s) was addressed to him and if necessary he must obtain a complete copy of the message. He is first encouraged to obtain a copy from another ship copying the same broadcast channel, providing the subscriber has a separate means of communication with the other ship. When the subscriber exhausts all local means of obtaining this information his next action is to originate a message which is called a "service or screen request message." Such a message is usually sent to a NAVCOMMSTA requesting them to verify or screen their copy of the broadcast to determine whether the message (s) in question is for the subscriber. The NAVCOMMSTA will in turn reply by indicating which messages are of no concern to the subscriber and by rerunning on the primary channel those messages which were addressed to the subscriber.

A subscriber which misses only a portion of a message may service only for that portion of the message to which the NAVCOMMSTA must in turn originate a service message in reply giving the subscriber that portion of the message missed.

It is noted that in some NAVCOMMAREAs, the NAVCOMMSTA to which a screen request is sent may not be the Broadcast Control Station. In these cases designated NAVCOMMSTAs in the NAVCOMMAREA also copy the broadcast and serve as stations which handle screen requests for a particular channel of the broadcast. When these NAVCOMMSTAs process a screen request their replies are relayed via AUTODIN to the Broadcast Control Station which in turn sends the reply on the appropriate broadcast channel. We note that these replies are handled in the same manner as first run messages.


Some NAVCOMMSTAs will handle screen requests for more than one broadcast channel or in some cases for more than one type of broadcast system. At each NAVCOMMSTA all such broadcast screen requests are usually handled at one broadcast service desk. The broadcast service desk handles these requests on the highest precedence first and on a first-in first-out basis within precedences.

These service messages are usually referred to as screen requests, since the service desk clerk is required to "screen" the heading of the missed messages in the printed copy form of the broadcast channel log to determine if the message is for the requesting subscriber. Additionally, to clarify terminology, each message looked up is referred to as a "screen." Thus a "screen request" may contain one or more "screens.

After the service desk clerk determines the result of a screen request he then must make teletype tape copies of the messages to be rerun, if necessary, which are forwarded to the appropriate broadcast channel position for transmission.

At some NAVCOMMSTAs, when the service desk clerk has finished the screen and before he prepares the rerun tapes he prepares a short message to the requester indicating which messages are of no concern to the subscriber and additionally states that those messages which are of concern will be rerun later.

Other NAVCOMMSTAs use the procedure where they include this information with the first message rerun and only after the entire screen request has been processed.

It is apparent that this process is a very time consuming task and explains the reason why subscribers are encouraged to seek other sources for verification before asking the NAVCOMMSTA.


Considering now the transmitting side of the broadcast we look at the NAVCOMMSTAs internal handling of messages which are destined for transmission on one or more of the broadcast channels. Messages arrive at the broadcast area in teletype tape form and are, depending on individual NAVCOMMSTA configurations , primarily delivered to each broadcast channel position by two 850 wpm reperforators called "burpees" [Teletype model BRPE]. The traffic delivered by the burpees is traffic which has been received by the NAVCOMMSTA from the AUTODIN network or from 100 wpm teletype circuits which terminate at the NAVCOMMSTA from any number of sources. The burpees are fed from these various sources through a small computer system called the Multiple Address Processing Unit (MAPU).

This system reads the header of a message which contains address codes as to where a message is destined within the NAVCOMMSTA and routes that message to the appropriate relay positions by delivering a teletype tape through the burpees.

In addition to the burpee deliveries some NAVCOMMSTAs hand deliver screen request answers, reruns and other messages to the broadcast position. The screen request answers and reruns are then usually put at the head of the line or queue for transmission.

Messages delivered to the broadcast position are put in a grid (queue) by precedence and in order of arrival within each precedence. The messages are then taken from the grid and put in the channel transmitter distributor (TD), a device which reads the teletype tape for transmission. The order in which the messages are taken from the grid for transmission is on the highest precedence waiting and first in first out (FIFO) within a precedence basis. This process at some NAVCOMMSTAs is done by one man physically performing the queuing process while another man pulls the tapes from the grid and places them into the TDs for transmission. At other NAVCOMMSTAs, properly equipped, this entire process is handled by a small computer system, known as the "tight tape" system.

NAVCOMPARS - "The Naval Communications Processing and Routing System: A Model for Management" 
NPS Thesis - LCDR Michael D. Barker & LCDR William R. Lawrence - 1974 
download pdf
This thesis represents the results of a study of the U. S. Naval Processing and Routing System (NAVCOMPARS). The system's development from preconception to present is described herein as well as a description of its hardware and software components. Additionally, the Local Digital Message Exchange (LDMX) , is likewise described. The purpose of this thesis is to identify bottlenecks in message flow through NAVCOMPARS. In this attempt, the system was simulated in a functional manner by computer and various input distributions were applied. By so doing, the factors, events and situations contributing to bottlenecks in message processing are identified as fully as possible within the constraints of time and information availability.
NAVCOMPARS - "The Naval Communications Processing and Routing System : Analysis of an Automated System"
NPS Thesis - LT Beth M. Hintz - 1976 
download pdf

This thesis is designed to present a detailed description and analysis of the Naval Communications Processing and Routing System (NAVCOMPARS). Discussed are the objectives and principles of the Naval Telecommunications Automation Program (NTAP) , with emphasis placed on delineating the shore components, particularly NAVCOMPARS. The capabilities of NAVCOMPARS are identified by describing the patterns of message flow through the automated system. Also considered are the manpower and training characteristics and  the projected link with the Information Exchange Subsystem (IXS). A model of the central processing unit is presented in order to highlight the sequence of procedures employed by an automated message processing system. The underlying intent of this thesis is to provide a compact document which could be used as introductory material to acquaint non-computer specialists with the characteristics, requirements and potential of the Naval Communications Processing and Routing system.

"Naval Communications Processing and Routing System (NAVCOMPARS): A Model for Broadcast Performance Analysis"
NPS Thesis - LT Gary L. George - 1983 
download pdf

This thesis represents an analysis of the performance of the Naval Telecommunications System's (NTS) multichannel broadcast. It highlights the speed differential between the Naval Communications Processing And Routing System's (NAVCOMPARS) processing subsystems and the multichannel broadcast's transmission lines.
"The Naval Telecommunications System: A Command and Staff Manual"
NPS Thesis - LCDR Robin M. Babb - 1987
download pdf
This thesis provides prospective Naval communications managers, senior officers, and supervisory command and control officers with a basic, non-technical description of the Naval Telecommunications System (NTS). It is suitable as a general primer for the communications manager, for new personnel indoctrination, for command briefings, and for general reference to the NTS. This thesis includes a description of the organic structure, administration, and operation of the NTS, its interaction with various major commands and agencies, the primary systems used within the NTS, and some plans for its future.

Fleet Center Jobs (from 1974 Manpower Study)

Full-period termination operator (FPT) receives messages from ships via either single channel or multi-channel terminations, and oversees the sending of messages to ships terminated with the NavCommSta. Honolulu utilizes the NavComPars to key outgoing traffic addressed to terminated units. When it becomes necessary for the ship/shore operator to talk to the terminated ship, he asks the command VDT operator to hold the appropriate termination LRN, and then the operator talks directly to the ship using a UGC-61 keyboard. At this station, the FPT also enters received traffic into the data speed reader. One operator handles two termination channels, and two data speed readers are operational at Honolulu. Primary Ship-Shore operation is similar but on-demand rather than FPT.

Dedicated circuits operator five of the eight dedicated circuits at Honolulu are operated directly on-line with the NavComPars. Two circuits with Australia and one with New Zealand are operated on a torn-tape basis, interfacing termination style circuits with an AUTODIN access terminal. Operation is similar to the full-period termination.

Full Period Termination - FPT Receive
wpe1.gif (31685 bytes)
Data Speed Reader -
FPT Receive > NAVCOMPARS input 
wpe3F.gif (24139 bytes)
FPT Transmit
wpe41.gif (22663 bytes)
Primary Ship-to-Shore
wpe43.gif (36500 bytes)

Allied interchange operator basically handles the duties outlined in description for dedicated circuits operator. Also works full-period terminations with allied ships, and assists in keying the allied broadcast, when activated. The purpose of the Allied/NATO/SEATO circuit is to provide Allied ship-shore service.

CW broadcast operator converts teletype messages into CW format, and places them on proper broadcast schedule (that is, at proper time).

PG Broadcast is similar but RATT, not CW

Allied/NATO/SEATO - Receive
traffi1.gif (29317 bytes)
Allied/NATO/SEATO - Transmit
traffi13.gif (29720 bytes)
CW Broadcast
traffi14.gif (21871 bytes)
Patrol Gunboat Broadcast
traffi15.gif (26579 bytes)

Off-line crypto operator encrypts and decrypts messages from or to commands for which this station has crypto guard. Handles all classified messages which require special handling during his watch.

Router VDT operator processes messages rejected because of format or routing errors Miscellaneous
Offline Encryption
traffi16.gif (14570 bytes)
Offline Decryption
traffi17.gif (19715 bytes)
Router VDT
wpe5D.gif (27279 bytes)
Service Center
wpe5B.gif (26437 bytes)

CIRCUITS - Radio Ship-Shore Communication Circuits

Fleet Multichannel Broadcast System

multcast-01.JPG (34276 bytes)
Fleet multichannel broadcast - Transmit (Shore Station)


multcast-02.JPG (48308 bytes)
Fleet multichannel broadcast - Receive (Shipboard)


Because the requirements for rapid communications from the Department of the Navy to the fleet operational commanders had changed, the CNO authorized the activation of an additional teletypewriter system. This system, known as HICOM, was activated in 1957 and operated parallel to the existing communications channels.

Later, the Commander in Chief, U.S. Pacific Fleet (CINCPACFLT), established an additional parallel circuit known as the "Atomic Strike Coordinator Circuit." It was determined that even more rapid communications would be necessary. Therefore, a new communications net, known as the "Naval Operation Net" was formed in 1959.

from NCTAMS EASTPAC history

High Command Communications Network (HICOM) 

The HICOM network provides a voice link between the Chief of Naval Operations (CNO) and all subordinate commands ashore, afloat, and airborne. CNO is the master control station and each fleet commander in chief has an area network control station. All naval communications stations are members. 

In cases where a fleet unit is suffering communications difficulties with normal channels, HICOM is used on a not-to-interfere basis to restore communications. All naval communications stations are required to guard HICOM for their respective area networks and use this system

from current USN training manual

Golf System

THE%20GOLF%20SYSTEM.jpg (83846 bytes)

Charlie System

CHARLIE%20SYSTEM.jpg (84571 bytes)

Uniform System

UNIFORM%20SYSTEM.jpg (65366 bytes)

November HF System

NOVEMBER%20HF%20SYSTEM.jpg (79659 bytes)

1954 "Shore-Based Communications" manual -  NAVPERS 10891

Fleet broadcast message format
fox-msg-01.JPG (177377 bytes)

1964 Fleet Broadcast Areas
commsta-bcast-64.JPG (268388 bytes)

1957 Naval Communication System TTY Network
usn_network1957_b.jpg (367918 bytes)

1945 NTX System

Interesting messages illustrating  Navy communications operations
- released by NSA relating to 1967 USS Liberty incident - message index here and here

NAVCOMMSTA Morocco daily report of operations -

NAVCOMMSTA Greece message handling

USS Liberty message routing