CHAPTER 3
INTEROPERABILITY
TOPIC: Joint Tactical Communications (TRI-TAC).
DISCUSSION: Echelons above corps (EAC) communications equipment (TRI-TAC) performed well, but was not available in Force Package 3 units. The communications network consisted of a mixture of several different technologies and architectures, resulting in the largest automatic switched voice and message network in the history of the U.S. Army. The multiplicity of equipment, different architectures and the analog and digital mix found in the operational force structure was bridged through the flexibility and interoperability of TRI-TAC equipment systems. This equipment was totally interoperable with the Improved Army Tactical Area Communications System (IATACS) at division level, Mobile Subscriber Equipment (MSE) at division and corps levels, the TRI-TAC family of equipment found at corps and theater levels and a myriad of strategic systems which linked combined and joint tactical headquarters with all deployed units as well as the National Command Authority. Older generation EAC communications equipment is not nearly as flexible.
EAC Reserve Component (RC) units are not currently scheduled to receive full sets of compatible TRI-TAC equipment. Force Package 3 units that were not equipped with, or trained on, compatible TRI-TAC equipment were deliberately deleted from the force list during Operations DESERT SHIELD and DESERT STORM.
Major components in the EAC TRI-TAC network, such as the AN/TTC-39A Automatic Circuit Switch, are scheduled for modification but funded only for the Active Component (AC). The result of this approach will be that AC and RC capabilities at EAC will become more disparate over time and RC units will not be able to be integrated into the theater network.
Failure to modernize RC units at EAC to the same level as the AC will eliminate the capability to create a robust network and eliminate the assets required to reconstitute the network on the battlefield.
LESSON(S): Continue to field EAC TRI-TAC communications equipment and continue the modification in-service program, striving for interoperability and flexibility, facilitating the development of robust and reconstitutable networks.
Review and adjust the RC Modification Plan to ensure RC units are equipped with TRI-TAC communications systems which are compatible with the active force in planned areas of operations.
TOPIC: Data-link Architecture Critical Nodes.
DISCUSSION: Initial data-link architecture relied very heavily on critical nodes, which, if inoperative, "crashed" the entire interface. Data-link architecture in the initial stages of Operation DESERT SHIELD consisted of a single TADIL-A net which, by design, relied too heavily on certain critical nodes for TADIL conversion and data forwarding in the terrestrial portion of the architecture. This critical node dependence often crashed the entire interface during equipment outages or when communications problems arose. Possible solutions were often discussed at the Interface Coordination Unit (ICU) but were seldom preplanned with interface participants and were, therefore, time-consuming and difficult to implement. The data link should be designed to reduce critical node dependence, especially in the terrestrial data conversion and forwarding network. By breaking the interface into multiple TADIL-A nets with multiple entry points into the terrestrial structure, the interface becomes more manageable and node outages can be worked around. At the very least, when outages occur, the entire interface is not scrapped. Additionally, solutions and contingency plans must be worked well in advance and briefed to all interface participants responsible for data conversion and data forwarding.
LESSON(S): A single TADIL-A net, while desirable under certain circumstances, relies heavily on certain critical nodes for display and dissemination of the air picture. In an architecture on the scale and scope of Operation DESERT SHIELD, and given the environment, it is imperative that critical node dependence be reduced as much as possible.
TOPIC: Data-Link Architecture Flexibility.
DISCUSSION: The initial data-link architecture did not exploit existing capabilities to allow rapid reconfiguration when outages or equipment availability affected operations. Adequate cornmunications paths and sufficient data forwarders from both the USAF and USMC were in place to support various configurations for TADIL conversion and data forwarding; however, initial interface design and contingency planning did not take full advantage of this inherent flexibility. Often, required reconfigurations were spur-of-the-moment unilateral actions, and changes were made in the terrestrial architecture without the full knowledge of other participants. While these changes sometimes worked, the transition would have been much smoother with prior contingency planning and exercising of preplanned options. Additionally, reconfigurations usually have a "ripple effect" throughout the interface and if not directed by, at least they must be approved by, the Interface Control Unit (ICU) prior to implementation. Planners should focus not only on primary conliguration but also on secondary and tertiary options during the data-link architecture design process. Ohce this has been done, the potential options must be briefed to, and understood by, all affected participants. Implementation of any option, primary or otherwise, should only be done at the direction of the ICU.
LESSON(S): Interface architecture design must take nto account the TADIL conversion, forwarding and ommunications capabilities of interface participants vith regard to backup or contrngency planning. While the initial interface was basically sound in theory, it was cumbersome and did not reflect a high degree of built-in flexibility.
TOPIC: Airborne Early Warning and Control System (AWACS) Communications Conversion.
DISCUSSION: There is no conversion of information received at the AWACS via Joint Tactical Information Distribution System (JTIDS) Class I terminals and TADIL-A and vice versa. The AWACS was tasked to participate in both TADIL-A Operations and JTID S Class I operations simultaneously. Any information transmitted to the AWACS via TADIL-A was not transferred to the JTIDS Class I network in which the AWACS was participating. Conversely, any information received by the AWACS via JTID S Class I terminal was not translated to the TADIL-A network and rebroadcast via that medium. Greater versatility with data exchange could be realized if the JTID S information and the TADIL-A information could be exchanged within the AWACS and transmitted via other mediums.
LESSON(S): There is no data conversion and translation between information received via JTID S in the AWACS and translation for transmission on the TADIL-A net. Conversely, information received via TADIL-A in the AWACS is not available for conversion and translation to the JTID S net. The information received by the AWACS must be translated and made available for transmission via different types of medium. Acquisition of this capability would enable the AWACS to share its information from all data-link sources with all other data sources available to it.
TOPIC: Corps Tactical Area Signal Center (CTAS).
DISCUSSION: The CTASC-II fielded in support of a corps was fielded with 9.6kb modems that could not be readily used to communicate to the Defense Data Network (DDN) over the tactical communications systems. The CTASC-II was fielded into theat to communicate to the DDN using a KG-84 (secure device) and a 9.6kb modem. The TRI-TAC communications systems employed by the signal brigade could not transmit data at 9,600 baud through the TD-660s used in the multichannel radio systems.
Although the TD-1069 and TD 1065 combination was available to pass low-speed data through the high-speed data buffer, bypassing the TD-660, the signal brigade was unable to get this equipment to operate reliably.
The CTASC-II was connected to the DDN using KG-84s over the tactical communications system. The KG-84s were set up to communicate a conditioned diphase synchronous signal at 32kb. The KGs were not used for their ability to encrypt data but for their modem which, at 32kb, would bypass the TD-660s and use the TD-1065s in the multichannel systems, thus providing a high-speed path for the Class "B" host to communicate to the DDN gateway. The circuit path goes from the binding posts of the CTASC-II via WF-16 wire to the binding posts of an AN/TRC-I51. The AN/TRC-15I goes to another AN/TRC-I5I at a relay where it goes to an SB-675 Patch Panel via 26-pair cable. From the SB-675 it goes to an AN/TCC-73 via PCM cable. The AN/TRC-138 goes to another AN/TRC-138 where it goes to the AN-TCC-73 over PCM cable and then to an AN/TSQ-84 Tech Control via 26-pair cable where it is strapped over to another AN/TRC- 151 system via 26-pair cable. The AN/TRC- 151 at the DDN Gateway location was cabled via 26-pair to the ISC patch and test facility.
As a note, the binding posts on the C'I"ASC-H had transmit and receive reversed. This seemed to be consistent throughout the entire assemblage. It appeared as if the shelter was designed from the perspective of the transmission system connecting to it as opposed to it connecting to the transmission system.
The CTASC-II requires a synchronous link between the Unisys 5000 and the Cisco Gateway; the KG-84s lost sync when the communications link became marginal or took a a"hit." This "sync loss" stopped data transfer between the host and the gateway and required the KG-84s to be reinitiated by flipping the momentary initiate switch on the front of the KG-84. Because the reinitiation of the KG-84s irequired operator intervention, the decision was made to use Crypto Reset Units (CRUs) to monitor and reinitiate the KG-84s automatically when an out-of-sync condition was detected. The CRUs were obtained out of salvage from Germany through the PM TACMIS office for use in Operation DESERT SHIELD.
LESSON(S): Document and implement a method for connecting the CTASC-II to the Defense Data Network over the tactical communications system. If KG-84s are to be used, Crypto Reset Units should be considered for installation into the CTASC-II to maintain the synchronous link.
TOPIC: Common Hardware/Software.
DISCUSSION: The lack of a standard theater-wide computer hardware and software suite prevented the timely exchange of tactical transmission system, circuit switch, and message switch data bases, reports, and diagrams. The hubs of the TRI-TAC Architecture are the AN/TTC-39 Circuit Switch and the AN/TYC-39 Message Switch. It should be noted that the first message switch was fielded 10 years ago. Tactical transmission systems, circuit switches, and message switches revolve around detailed, and sometrmes lengthy, detailed data bases. It is these detailed data bases that "tell" transnlission or switch hardware and software how to respond to a given set of conditions.
The objective TRI-TAC network planning and management tool is the Communication Systems Control Element (CSCE) which underwent, and successfully passed, a User's Acceptance Test in July 1990. The CSCE supports the Army's three-tier, (node, battalion, brigade) philosophy of TRI-TAC network plauning and management. It accomplishes this by providing a "shared network-wide data base" at each of the three network management echelons. Due to physical size considerations, the Air Force and joint community chose not to adopt the CSCE as their network planning and mangement tool.
The Air Force and joint community have adopted the Tactical Network Analysis and Planning System (TNAPS) as their interim solution to assist in TRI-TAC network planning and management. TNAP S is a computer software applications program which resides on a desktop computer. TNAPS assists in the development of the detailed transmission system and switch data bases. TNAPS is a stand-alone system. The following organizations were responsible for planning and managing their portion of the overall tactical communications switched network:
Each of these organizations used the tools which they felt most comfortable with to assist in data-base development. These tools included, but were not limited to, TNAPS, word-processing software, and, in some instances, "stubby pencils." Had any one of the organizations responsible for network planning and management been forced to delegate their responsibilities to a subordinate organization, it would not have been without considerable difficulty. As it was, little or no network planning and mangement products were exchanged electronically between the various organizations. This lack of timely information exchange resulted in:
LESSON(S): The lack of a shared network-level data base resulted in the tactical communications switched network performing at a marginal level, and provided inadequate subscriber support. The Joint Staff must mandate required data and format an electrical interchange of any tool that will assist in TRI-TAC network planning and management. The capabilities, characteristics, limitations, and applications of this tool must be articulated in JCS Pub 6-05.7 and be included in service-school curriculums.
TOPIC: STU-III Telephone.
DISCUSSION: Common Hardware Software (CHS) data communications over STU-III using the MS-DOS coprocessor and Smartcom III software were successful. CHS data communications over STU-III from the UNIX environment using Kermit software was also successful, but considerable difficulty was experienced configuring the RS-232C port from the UNIX environment. If the RS-232C data ports were first configured from MS-DOS, then data communications over STU-III using UCCP or Kermit were successful. Configuration of the RS-232C port from the UNIX environment to support STU-III data communications remains under investigation.
LESSON(S): STU-III communications were successful.
TOPIC: Corps Tactical Area Signal Center Protocol.
DISCUSSION: The CTASC-II, although designed for subordinate Division Materiel Management Centers (DMMCs) to communicate directly from its Tactical Army Combat Service Support Computer System (TACCS) to the CTASC-1I, was unable to do so because the software (Monitored Asychronous Protocol (MAP)) for the UNISYS 5000 was not available to communicate to the internal dial-up modems of the CTASC-II. Ideally the CTASC-II would have a number of common user telephone circuits terminated to its binding posts on the side of the shelter. These common user phone circuits would be connected to either the 16 rack-mounted V-23 modems, the TA-1035 telephone, the two KY-68 telephones, or the STU-III telephone, the two KY-68 telephones, or the STU-III telephone. From there the phones would be connected physically to the UNISYS 5000 running a UNIX version of the MAP software. The DMMCs and Nondivisional Units would use their TACCS, communicating whether through the 212 Modem over two-wire analog circuits, or a digital telephone, such as a TA- 1035 or KY-68, using the digital interface cable supplied with the TACCS, to the CTASC-II. Using the MAP software at both locations, the Direct Support Units (DSUs) would transfer their requisitions to the Materiel Management Center (MMC) and could also receive status on existing requisitions passed.
With the MAP for the CTACS-II Computer itself not supplied, this method of operation could not be used. In addition, there were other problems with the MAP being used on the TACCS by the DSUs and the failing of the units (MMC and DSUs) to request the communications lines for the CTASC-II and TACCS at their locations. Further investigation revealed that the reasons for not requesting the lines were two fold:
This mindset caused the DSOs to never request phone circuits for their TACCS, and, as a result, they were never included in the signal planning. Those that did request a phone line would often Fmd their phone line connected to an instrument on another desk. Telephone requirements for Logistics support had been pre-empted by "higher priorities."
The solution for this particular situation was to have a TACCS "front end" to the CTASC-II where units would take their magnetic media to the MMC and turn it in to the Logistics Automated System Support Office (LASSO). The LASSO would load the diskettes into a TACCS that was connected to the CTASC-II via fiber optic or RS-232 cable; they would then be loaded into the CTASC-II. This still required the DSUs to take media to the MMC instead of using the available communications system to transfer the data electronically as designed.
LESSON(S): Provide the necessary software for the CTASC-II to communicate, as designed, to TACCS using the process of dialing over the common user phone system into CTASC-II. This procedure will directly support the processing of supply actions.
Table
of Contents
Chapter
2: Communications (C2)
Chapter
3: Interoperability, Part 2
NEWSLETTER
|
Join the GlobalSecurity.org mailing list |
|
|