E

Tactical Information Networks

This appendix adds detail to the treatment of tactical information networks in the main body of the report. Considering the general aspects of network design, it shows that there are significant inadequacies in the Navy’s current design for tactical information networks and the planned communications links may not be a good match for the information networking demands placed on them. It points out ways in which commercial networking technology could be used within the Navy’s tactical networks and those areas in which commercial technology will probably need to be augmented with military-specific technology. The committee does not pretend to design the Navy’s tactical information networks. That will require a great deal of architectural design and system engineering work. However, this appendix does show that a comprehensive, unified approach to the design of tactical information networks is missing in the Navy’s planning. Such an approach is a necessary ingredient for network-centric operations.

E.1 CHARACTERISTICS OF TACTICAL TRAFFIC

It is often said that, to a network, “bits are just bits”—but that is not entirely true. Although it is not the job of a network to interpret the contents of the bits that pass through it, the network must provide the services that its traffic requires. In general, each traffic type within a network has somewhat different requirements. In the specific case of tactical networks, the different types of traffic have quite widely varying needs. Hence, different types of traffic must be marked as such and the network must handle each traffic flow according to the rules established for that type of traffic. In the most extreme cases, entirely separate net-



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities E Tactical Information Networks This appendix adds detail to the treatment of tactical information networks in the main body of the report. Considering the general aspects of network design, it shows that there are significant inadequacies in the Navy’s current design for tactical information networks and the planned communications links may not be a good match for the information networking demands placed on them. It points out ways in which commercial networking technology could be used within the Navy’s tactical networks and those areas in which commercial technology will probably need to be augmented with military-specific technology. The committee does not pretend to design the Navy’s tactical information networks. That will require a great deal of architectural design and system engineering work. However, this appendix does show that a comprehensive, unified approach to the design of tactical information networks is missing in the Navy’s planning. Such an approach is a necessary ingredient for network-centric operations. E.1 CHARACTERISTICS OF TACTICAL TRAFFIC It is often said that, to a network, “bits are just bits”—but that is not entirely true. Although it is not the job of a network to interpret the contents of the bits that pass through it, the network must provide the services that its traffic requires. In general, each traffic type within a network has somewhat different requirements. In the specific case of tactical networks, the different types of traffic have quite widely varying needs. Hence, different types of traffic must be marked as such and the network must handle each traffic flow according to the rules established for that type of traffic. In the most extreme cases, entirely separate net-

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities works (“stovepipes”) may need to be set up for some types of traffic to ensure that their service requirements can be met. E.1.1 Varying Types of Tactical Traffic Earlier sections of this report describe current and planned tactical information network use in some detail. This section briefly recapitulates and then proceeds to translate these traffic considerations into more general architectural demands on the tactical network. Sensor feeds. A wide range of sensor data flows into a tactical network. These feeds range from such heavy flows as imagery and synthetic aperture radar (SAR) from airborne platforms, through lesser flows such as moving-target indicators (MTIs), and down to sporadic and light traffic from cues such as unattended ground sensors or underwater sensors. Most types of imagery do not need particularly accurate transmission; they can withstand fairly high bit error rates. But more highly processed information, such as MTI tracks, require quite reliable delivery. Weapons control. Real-time control of weaponry can range from the exceedingly time-critical “in-the-loop” applications, such as shooting down incoming missiles in the cooperative engagement capability (CEC) system, to relatively undemanding “update” applications for tracking a slowly moving target. Traffic delivery deadlines can thus range from milliseconds, in the most demanding cases, to tens of seconds in the least demanding. In either case, however, extremely high reliability is required in the delivery of control commands to an in-flight weapon. Common tactical picture. The common tactical picture is a human-visible representation of the current situation, delivered with the appropriate level of detail so that the operations personnel can understand those aspects of the situation relevant for them and make decisions accordingly. This type of application can be implemented in a number of different ways, and each will impose different types of requirements on the tactical network. As an example, the U.S. Army’s Force XXI Battle Command Brigade and Below (FBCB2) program uses a hierarchical reporting mechanism in which each moving platform reports its position to a server, at a rate depending on how fast it is moving. The entire picture is then periodically distributed to everyone and filtered down to its relevant details at each receiver. This particular implementation imposes a fairly heavy “background hum” of position (and related) information on the network, with short messages and required latencies on the order of 1 s. However, high reliability is not required because messages are constantly being resent. If one is lost, the next will probably get through. Tactical command and control (C2). Many tactical commands will be given by voice. Some fraction, however, will be delivered as data messages.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.1 Notional Summary of Tactical Traffic Requirements Traffic Type Distribution Acceptable Delay Reliability Bandwidth Imagery Few platforms High Moderate High Cooperative engagement capability Few platforms Very low Very high High Weapon control Single weapon Low Very high Low Common tactical picture All/most platforms Moderate Moderate Moderate Command and control Few platforms High High Low These messages may be created and interpreted by people—for example, typed on a keyboard and later printed and read on paper. Alternatively, they may be created and interpreted entirely by machine. For instance, platforms may automatically report fuel consumption to logistics databases. Different types of messages can have radically different kinds of service requirements: some (such as a call for fire) are urgent and must be reliably delivered; others are more routine or could be dropped if necessary. Notional summary of traffic types. Table E.1 is not meant to be precise or encyclopedic, but marshals the requirements sketched above into a tabular format to show the degree to which tactical traffic flows differ. E.1.2 Conclusions Drawn from the Traffic Requirements This section draws some conclusions based on the tactical traffic mix discussed above. These conclusions help guide the critique here of the Navy’s current plans for tactical networks; the committee makes its recommendations in Chapter 4. E.1.2.1 A Mixture of Predictable and Unpredictable The first conclusion is that a significant portion of tactical traffic is unpredictable. It can be very “bursty,” surging one moment and dying away the next, in response to ever-changing and unforeseeable operational needs. CEC radar tracks are, for instance, highly predictable. There will be a known number of CEC-enabled ships within a tactical arena, and once the network has formed, the traffic within the CEC’s Data Distribution System defined below is quite predictable. The presence of incoming missiles is not easy to predict, but the CEC system is designed so that its traffic load does not change much as it transitions from an inactive state to a fully engaged state. The flow of imagery also seems at first relatively predictable. There are only so many sources of imagery and they can only be tasked at such a rate, and so the

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities flow of images seems predictable. This sense of predictability may, however, change as smaller unmanned aerial vehicle (UAV) sensors are introduced. One can imagine that sensors would be deployed at relatively short notice; one day there might be only one or two UAVs capturing imagery and the next day, there might be quite a few. In addition, individual imagery streams might turn on and off abruptly as sensors maneuver over target areas, detect activity, and so forth. Finally, variable efficiency compression (e.g., in a JPEG file) can change the traffic load unpredictably. Distribution of the common tactical picture also seems, initially, to be reasonably predictable. In its simplest form, every platform could report information about itself at regular intervals, and the summary could be redistributed (if necessary) at equally regular intervals. In practice, however, platforms could well adjust the rate at which they sent updates to best match their current mobility, and the number of platforms in an area would be likely to change fairly dramatically over time; indeed the indications of enemy activity would likely change unpredictably. In summary, a noticeable percentage of the traffic flowing through tactical networks is likely to be unpredictable and/or bursty. Such traffic surges, then dwindles, then surges again, changing from moment to moment. Since tactical networks have very finite capacities, this gives strong motivation to design a network that can take advantage of statistical multiplexing—to let one type of traffic surge fill the bandwidth that is momentarily being left unused by another traffic type. E.1.2.2 Delay, Priorities, and Reliability Requirements The next conclusion is that a tactical network must be able to accommodate varying delay requirements, priorities, and reliability requirements. When translated to information-networking mechanisms, these requirements generally devolve into two distinct kinds of priority—delay priority, which measures degrees of time-sensitivity, and reliability, which defines which messages should be accorded extra error correction when transmitted across radio frequency (RF) links and preferentially retained in memory during overload conditions. With such prioritization, it is inevitably the case that there must be some administrative mechanism for deciding on the relative priorities of traffic and establishing these policies. E.1.2.2.1 Delay Priorities Each host is responsible for marking each message, i.e., datagram, with the appropriate delay priority. Each node along the forwarding path must maintain sufficient queuing and forwarding discipline so that it forwards all packets with more stringent requirements before those with less stringent requirements. Pos-

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities sibly datagrams must be marked with expiration times, and routers must delete expired packets from the system; this would help during overload conditions. Possibly the network should implement flow control and not accept packets that it could not deliver in time. Stringent delay requirements will also strongly influence design of radio waveforms. In particular, they affect the way in which the channel is accessed (in multiaccess channels) and the maximum size of a frame that is transmitted in one contiguous piece. In particular, such requirements often lead to waveforms with short frames and bounded-delay channel access schemes. E.1.2.2.2 Reliability Each host is also responsible for marking each datagram with its relative requirements for reliability. This translates into how reliably the datagram must be delivered across an RF link, and hence can alter the error-control strategy (e.g., optional fast Ethernet channel (FEC) and/or automatic retransmission queue (ARQ)) for transmission across that link. It also affects how queues are managed within network nodes (primarily routers) when memory is running low: messages with the lowest priority tags are dropped first. Note that queues often fill up in routers—this is a normal, rather than exceptional, case. The simplest case is when a fast link leads into a router, but a slow link leads out; for example, a flood of traffic arrives very quickly on an Ethernet but must then be forwarded over a slow radio link. Queue overflows, and thus packet discards, are normal and inevitable in such cases. Important traffic can be protected, however, by assigning it a higher reliability than other traffic. Stepping back from this detailed discussion, it is apparent that a rather large administrative burden is looming in the background. If indeed traffic is to be prioritized, someone must make all the administrative decisions as to those priorities. Since this involves deciding whose traffic is more important than whose, such decisions have often proved rather difficult to make and enforce. Such problems will not magically disappear as tactical networks become widespread. E.1.2.3 Future Types of Tactical Traffic The final conclusion that can be drawn is this: There is currently no “strong family resemblance” among the different traffic types in the network, and hence future traffic added to the network will probably look rather different from the traffic types that are well understood today. This should translate to a relatively heavy emphasis on designing a network that is flexible, open ended, and very easy to modify. Unfortunately, this conflicts with the equally admirable goal of efficiency. If the current set of traffic were going to remain unchanged for decades, it would make excellent sense to optimize every detail of the network and RF waveforms to support this traffic mix. But such is not likely to be the

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities case. It is very difficult to predict exactly what new traffic will be flowing through tactical networks in the coming two or three decades, but very easy to predict that there will be something new—and quite a bit of it, most likely. Hence now is not the time to optimize; now is the time to be flexible. E.2 CURRENT PLANS FOR TACTICAL COMMUNICATIONS—“HOW IT IS” The Navy is currently deploying, or planning to deploy, several different types of data communications subsystems on its tactical platforms. This section briefly reviews the most important of these current or planned tactical data links, with an eye to those technical details that make the data links more or less suited to smooth integration into an overall tactical network architecture. It is interesting to note that the Navy’s “canonical view” of the emerging architecture for network-centric warfare is not much more than a relabeling of two of its deployed systems and that a number of other tactically significant naval systems—now being planned or envisioned—simply do not fit into this canonical view.1 E.2.1 The Canonical View The canonical “architecture” for network-centric operations consists of three layers. Two of these, the Joint Composite Tracking Network (JCTN) and the Joint Data Network (JDN), are meant to carry tactical traffic. The third layer, the Joint Planning Network (JPN), is presumed to be too slow to carry tactical traffic, although in some futuristic concepts it does appear as part of the tactical infrastructure, e.g., to perform reachback from forward sensors to a Global Broadcast System (GBS) or even a Global Positioning System (GPS) uplink so that the sensor information can be distributed for tactical purposes by satellite. The Joint Composite Tracking Network is in fact synonymous with the cooperative engagement capability (CEC), and so these terms are used interchangeably here. The CEC is a tightly integrated set of distributed radar systems, each of which is mounted on a different platform. Its internal radio networking system is the data distribution system, which is perhaps best thought of as a specialized set of highly reliable, time-critical protocols that provide a distributed “radar backplane.” The Joint Data Network, similarly, is another name for the Joint Tactical Information Distribution System (JTIDS). JTIDS radios are installed on a range of platforms and organized into “nets.” Every platform within a given net can share data with all other platforms in the same net. Table E.2 1   Mayo, RADM Richard, USN, Office of the Chief of Naval Operations, N6B, “Information Systems Development, Plans, and Programs,” briefing to the committee, January 27, 1999, Washington, D.C.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.2 Data-carrying Characteristics of the Joint Tactical Information Distribution System (JTIDS) and Cooperative Engagement Capability (CEC) Radio Systems   Intended Uses Type Raw Speed Open? JTIDS Force control messages, common tactical picture, and so on Time division multiple access Up to 115 kbps No CEC Data Distribution System Internal distribution of CEC tracks and coordination Special reliable flood Classified No provides a thumbnail sketch of the data-carrying characteristics of these two radio systems. E.2.2 Tactical Links Outside the Canonical View As mentioned above, the “canonical architecture” for networked operations defines exactly two tactical communications subsystems for the Navy, namely CEC and JTIDS. By implication, it would seem these two subsystems are expected to carry all tactical data traffic. In practice, however, several other radio subsystems are also employed, or being seriously considered, and indeed carry rather different types of tactical traffic than those carried via CEC or JTIDS. Table E.3 summarizes each of these noncanonical links. Thumbnail descriptions of some canonical and noncanonical links are given in the following sections. E.2.3 Joint Tactical Information Distribution System The Joint Tactical Information Distribution System, also known by the related but not interchangeable terms Management Information and Data System (MIDS), Link 16, or TADIL-J, is the Navy’s chosen radio subsystem for distributing “force control” messages within the tactical arena. These messages include surveillance tracks, weapons coordination, air control, target information, precise position location and identification, and even digitized voice networks.2 JTIDS 2   All information on JTIDS has been derived from two sources: Welch, LCDR David, USN. 1999. “Overview of Links 4, 11, 16, and 22,” Office of the Chief of Naval Operations, N62G, Washington, D.C., February 17; and Program Executive Office (Air and Missile Defense), U.S. Army and Army Aviation and Missile Command, Life Cycle Software Engineering Center, and Missile Research, Development and Engineering Center, U.S. Army. 1999. Introduction of JTIDS (U). Available online at <http://jtids.redstone.army.mil/JTIDS_101/sld001.htm>.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.3 Summary of Noncanonical Tactical Links Link Intended Uses Type Raw Speed Open? Common data link Imagery and synthetic aperture radar (SAR) collection Point to point 200 kbps up, up to 274 Mbps down Yes Tactical common data link Imagery and SAR collection Point to point 200 kbps up, 10 Mbps down Yes Global Positioning System Weapon target location updates Broadcast Unknown No Vehicular radio communication-99 Command and control, video conferencing for the Marines Multihop network Unknown Yes radios—or their MIDS variants—will be installed on a variety of aircraft, surface ships, and submarines over the next 7 years, as well as in Patriot and theater high-altitude area defense (THAAD) forces. Table E.4 lists JTIDS (Link 16) characteristics. Certain technical characteristics of the JTIDS waveform have important effects on the types of networks that can be built with JTIDS radios, and so such characteristics are briefly described in the following sections. E.2.3.1 Waveform JTIDS operates in the L-band. It divides the spectrum into 51 channels between 969 MHz and 1,209 MHz, with a channel spacing of 3 MHz. Certain portions of this spectrum are also used for identification friend or foe (IFF), tactical air navigation (TACAN), distance measuring equipment (DME), and Mode S, which excludes two subbands and imposes some restrictions on exactly how JTIDS can be used in noncombat situations. In particular, time slot duty cycles for JTIDS must be restricted to no more than 20 percent under “normal” conditions. Exercise conditions do not have duty cycle restrictions, and full combat conditions have no restrictions. JTIDS uses a time division multiple access (TDMA) waveform. Every 24-hour day is divided, in the JTIDS waveform, into 112.5 epochs. Each epoch lasts 12.8 minutes and is subdivided into 64 frames of 12 seconds apiece. Each frame is further subdivided into 1,536 time slots. Each time slot is thus 7.8125 ms long. Time slots within frames are organized into three distinct sets, labeled A, B, and

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.4 JTIDS (Link 16) Characteristics and Those of Other Tactical Digital Information Links (TADILs)   TADIL A Link 11 TADIL C Link 4A TADIL J Link 16 TADIL J Link 22 Anti-jam No No Yes No Crypto secure Yes No Yes Yes Data rate (kbps) 1.3 to 2.25 5.0 28.8 to 115.2 2.4 Message standard M series V/R series J series J series Participants 20 4-8 128+ 40 Critical nodes Yes Yes No No Voice circuits No No 2 No Architecture Radio broadcast Radio point-to-point TDMAa TDMAa Frequencyb HF/UHF UHF UHF/spread HF/UHF spread aTDMA, time division multiple access. bHF, high frequency; UHF, ultrahigh frequency. C. Time slots within a frame are identified as A-0, B-0, C-0, A-1, B-1, C-1, …, A-511, B-511, C-511. A given radio (“terminal”) may have up to 64 blocks of time slots assigned to it. Each time slot block (TSB) is defined by a triplet: set (A, B, or C); index (0 to 511); recurrence rate (0 to 15). Each assignment for a given terminal is designated as transmit, receive, or relay. A JTIDS net is a group of terminals that exchange messages among themselves. In other words, it is a group of terminals whose time slots have been defined so that when one member of a net is transmitting, every other member of the net is receiving. Obviously this requires careful planning to ensure that indeed all the other members are receiving at that time, that only a single radio is granted a “transmit” time slot at a given time, and so forth. The JTIDS architecture allows 127 different nets (numbered 0 through 126) to be active simultaneously within the same RF spectrum. Since JTIDS is a frequency-hopping radio, each net is made mutually exclusive by assigning a unique frequency-hopping pattern for transmissions. E.2.3.2 Access Modes As defined, JTIDS provides three distinct access modes for a terminal that needs to transmit: dedicated access, contention access, and time slot reallocation (TSR) access. Dedicated access is the mode described above. In this mode, the network planners ensure—by preparing the corresponding time slot plan for a given net-

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities work—that a given JTIDS terminal has exclusive use of an assigned TSB. This has the advantage that the terminal is guaranteed access to the network at regular intervals, but it also has the corresponding disadvantage that the time slot goes wasted if the terminal has nothing to say at a given moment. Contention access is quite different. In this mode, a given net provides a pool of time slots available for any terminal’s use. Any terminal that needs to transmit will randomly select a time slot from this pool and transmit in that time slot. This scheme has a number of advantages: it is easy to plan, makes it quite simple for terminals to enter or leave the net while the net is in operation, and provides some of the traffic efficiencies of statistical multiplexing for traffic that is bursty or hard to predict in advance. Its main disadvantage is that multiple terminals may transmit during the same time slot, which can result in lost messages and/or some terminals hearing one transmitter while others hear a different one. Time slot reallocation access is the most complex mode. As with contention access, all terminals share a single pool of time slots. Rather than transmit at will, however, the terminals perform a distributed algorithm to apportion the time slots. Each terminal transmits its bandwidth needs periodically, and every terminal performs identical algorithms to ensure that the pooled time slots are apportioned as per the needs. It is unknown whether this access scheme has been implemented in practice. E.2.3.3 JTIDS Data Rates Each JTIDS time slot has the following components. The time slot begins with a variable start jitter delay, then synchronization and time-refinement patterns, the payload (message header and data), and finally dead time to allow for RF propagation. This discussion concentrates only on the message data portion of a time slot. Each data portion can contain 3, 6, or 12 75-bit words, depending on the exact encoding of the message. Thus each time slot can carry anywhere from 225 to 900 bits of data payload, giving an aggregate data rate for a given JTIDS net of between 28,800 and 115,200 bps. Some of this “raw” capacity is used for housekeeping and so is not available for tactical traffic, but these numbers give a useful yardstick for the approximate capacity of a JTIDS net. By comparison, current commercial phone-line modems run at roughly 53,000 bps in the downstream direction. Thus one JTIDS net has a raw capacity ranging between roughly one-half and two times that of a phone-line modem. Since JTIDS divides its available L-band spectrum up into 51 channels, the extreme upper bound on the number of bits per second that can be transmitted simultaneously from all JTIDS terminals in a tactical arena is thus 51 × 115,200 = 5,875,200 bps. (This assumes that all available spectrum is devoted to JTIDS, that all terminals use the maximum possible data rate, and that all time slots in all channels are used for transmission and ignores the overhead of housekeeping

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities bits.) Working from the previous calculation, JTIDS achieves 5,875,200 bps in 51 × 3 MHz of RF spectrum, for an aggregate spectral efficiency of 0.0384 bps/ Hz. Partly, of course, this is driven by the tactical need for very robust anti-jam features. To a noticeable extent, though, it is driven by the basic short-frame TDMA structure of the JTIDS waveform where rather short payloads are surrounded by the dead times of synchronization patterns and propagation allowances. E.2.4 Common Data Link and Its Variants The common data link (CDL) is a family of radios that provides standardized, wide-band, line-of-sight (LOS) communications between airborne reconnaissance sensors and their users.3 The common data link has been mandated by the Assistant Secretary of Defense (Command, Control, Communications, and Intelligence) (ASN (C3I)) as the data link for all imagery and signals collection systems. The Navy is currently acquiring ship-mounted CDL terminals, under the name common high-bandwidth data link (CHBDL). At the RF level, CDL has both X- and Ku-band options. In the X-band, the command link (up) is 9.750 to 9.950 GHz, and the return link (down) is 10.150 to 10.425 GHz. In the Ku-band, the command link is 15.15 to 15.35 GHz, and the return link is 14.40 to 14.83 GHz. The tuning increment is 5 MHz in both bands. Typical airborne antennas are 7- or 9-inch directional dishes, though some applications use omnidirectional antennas. Typical surface antennas are 1 m or 6 ft dishes. The CDL command link runs at 200 kbps. It employs binary phase shift key modulation, Viterbi convolutional encoding (rate 1/2, constraint length 7), interleaving, and pseudo-noise spreading. The command link uses a 40-bit frame to structure a sync channel, link command and control channel, audio channel, and from 1 to 10 subchannels for Prime Mission Executive Command. The CDL return link runs at a selectable data rate: 10.71 Mbps, 137 Mbps, or 274 Mbps. It employs offset quadrature phase shift key modulation, Viterbi convolutional encoding (rate 1/2, constraint length 7), and interleaving. The return link multiplexes a number of data channels, each running at a fixed rate, onto the overall link. TCDL is a Defense Advanced Research Projects Agency (DARPA) program that will develop multiple qualified sources for a lightweight, low-cost, CDL- 3   All information on CDL and TCDL has been derived from two briefings presented to the committee’s Tactical Networks and Resources Panels on April 20, 1999: Schuh, CDR Paul, “CHBDL: Common High Bandwidth Data Link,” Office of the Chief of Naval Operations (N641), Washington, D.C.; and Preziotti, Gerry, “Common High Bandwidth Data Link—Surface Terminal (CHBDL-ST),” Johns Hopkins University, Applied Physics Laboratory, Laurel, Md.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities tions then go on to note the advantages of using a modern, layered network architecture, and the desirability (where possible) of employing a single, universal bearer protocol such as IP across all the RF links. What would it take to “open up” the Navy’s existing and planned data radios so that they could carry any type of message? The internal details of these radios are not known, and so the committee cannot give a detailed answer to this question. However, the committee has had experience with a similar task for various other kinds of radios, and in general, it has been technically feasible and not extensively costly. It is a question that the Navy should be posing to its contractors. Table E.5 summarizes the committee’s views about opening the Navy’s three major tactical data radios. TABLE E.5 Opening the Navy’s Major Tactical Data Radio Systems   Joint Tactical Information Distribution System Common Data Link, Tactical Common Data Link, etc. Data Distribution System Current use Track distribution Intel sensors (imagery, synthetic aperture radar, …) Cooperative engagement capability “backplane” What is required to make radio open New Internet Protocol message format, standard interface Contractor already has assisted transfer mode, Ethernet interfaces New IP message format, standard interface, very fast/reliable cutover to radar Good points Most widespread data radio (sea, air) High-bandwidth surface/air link; good for relaying communications High-bandwidth link among some ships and planes; excellent anti-jamming Bad points Spectrum issues; Time division multiple access channel access No reliable anti-jamming? Lacks encryption? Development costs? High nonrecurring expense test costs; spectrum issues Should it be opened?a Yes Yes Unclear aResponse summarizes committee’s views.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities E.5.3 Research Opportunities Most of the transition to a tactical network suitable for network-centric operations can be accomplished with a solid network architecture and sound systems engineering, followed by intensive development work on the various communications subsystems. Such work is hard, but it is not rocket science. Some new tactical networking technology is desirable, though, and will require an R&D effort as it will most likely not be developed in the commercial sphere. E.5.3.1 Better Channel Access for JTIDS The JTIDS waveform defines several channel access mechanisms. None is very close to the current commercial practice, e.g., as embodied in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless LAN standard. The 802.11 waveform conducts a transmission via four discrete steps: (1) the transmitter sends a request to send (RTS); (2) the receiver sends a clear to send (CTS); (3) the transmitter sends a variable-length data frame; (4) the receiver sends an acknowledgment. This waveform, together with its associated state transition diagrams, gives a reasonable CSMA/CA channel access protocol that guards against the classic hidden terminal problem. Research and experimentation with similar waveforms could bring significant benefits to the JTIDS waveforms in terms of allowing JTIDS to carry higher levels of bursty traffic than they can now successfully transport. E.5.3.2 Potential Bandwidth Increases Bandwidth is always a scarce commodity in the tactical world, but it is likely that the Navy will encounter quite severe bandwidth shortfalls in the future. There are a number of technical approaches that could help, and research in this area could prove very useful. Current naval plans for tactical networking expect that the data radios will be running at quite high power to ensure that the receiver is within earshot of the transmitter. This is an effective technique but leads to inefficient use of the RF spectrum. In particular, it does not encourage local spatial reuse, i.e., the reuse of the same RF spectrum at geographically separated regions. The Navy’s plans are perhaps most clearly highlighted by contrast with commercial cellular systems, which impose tight power controls on their transmissions in order to reuse the same frequencies multiple times within a metropolitan region. If the cellular systems worked like Navy radios, they would support only a few dozen simultaneous phone calls over an entire city. In addition, JTIDS’ overall capacity as a data hauler is quite low; a different waveform designed for wideband, packetized communications could likely do better and still have the requisite anti-jam properties.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities E.5.3.3 Ad Hoc Networking Ideally, Navy tactical networks would form automatically to include all nodes in a given area. In addition, nodes would automatically begin to act as relays when needed to forward traffic on to further nodes that are outside radio range of the original transmitters. Such networks are termed ad hoc networks or sometimes mobile ad hoc networks (MANETs). There has been little commercial interest in such networks, as commercial service providers can usually arrange to carefully plan their RF base stations, bring wireline connectivity to the base stations, and so forth. This obviates the commercial need for such ad hoc networking technology. DARPA and other military agencies, on the other hand, have been funding research into ad hoc networks for some years, and the first or second generation of workable ad hoc networks is now up and running. These networks include near-term digital radio (NTDR), VRC-99, Global Mobile Information Systems, and others. These networks appear to work reasonably well; indeed, the NTDR has even been adopted for use in the Army’s First Digitized Division. The technology is far from mature, however, and R&D would likely have very useful payoffs. ANNEXES TO APPENDIX E Annex 1 Imagery and SIGINT Dissemination Characteristics This annex presents reference information on direct dissemination from imagery and SIGINT platforms (Table E.A.1) and indirect imagery dissemination systems (Table E.A.2).

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.A.1 Imagery/SIGINT Platform Characteristics (Direct) Platform Sensor Data Link Link Data Rate Mode U-2 SAR CDL 274 Mbps LOS EO/IR CDL 274 Mbps LOS Other CDL 274 Mbps LOS SAR ETP 274 Mbps Sat Global Hawk (HAE UAV) SAR, EO/IR, MTI CDL 274 Mbps LOS   SAR, EO/IR, MTI Ku 50 Mbps Sat F-14 EO (TARPS) CDL 137 Mbps LOS F/A-18 SAR (APG-73) CDL 137 Mbps LOS   EO/IR (ATARS-USMC) CDL 137 Mbps LOS   EO/IR (SHARP-USN) CDL 274 Mbps LOS Predator (MAE UAV) Video (EO/IR) Legacy Analog, ~1.5 Mbps LOS   SAR Legacy 3.0 Mbps LOS   Video (EO/IR) Legacy 3.0 Mbps Sat   SAR Legacy 3.0 Mbps Sat Pioneer (TUAV)—USN EO/IR/Video Legacy Analog, ~512 kbps LOS Pioneer (TUAV)—USMC Video Legacy Analog; currently tape only LOS

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Surface Terminal Data Link Receiver Processor Remarks JSIPS-N/TEG CDL-Navy-ST/TIGDL CIP   JSIPS-N/TEG CDL-Navy-ST/TIGDL CIP BGPHES-ST CDL-Navy-ST/TIGDL BGPHES CONUS Unique   Indirect only via NIS/CA MCE/JSIPS-N/ TEG CDL-Navy-ST/TIGDL CIP GH now limited to 50 Mbps rate Satellite receiver (ashore) TIGDL CIP Satellite relay—actual data rate function of satellite transponder power NAVIS/JSIPS-N CDL-Navy-ST/TIGDL CIP Some TARPS sensors still film based; not all TARPS have data link; TARPS sensor to be replaced by SHARP JSIPS-N/TEG CDL-Navy-ST/TIGDL CIP   JSIPS-N/TEG CDL-Navy-ST/TIGDL CIP Includes medium-altitude electro-optical and low-altitude electro-optical and infrared line scanner sensors JSIPS-N/TEG CDL-Navy-ST/TIGDL CIP CIP upgrade for SHARP planned Legacy Legacy N/A Data link upgrade planned (TCDL) Legacy Legacy OBP Data link upgrade planned (TCDL) Legacy Legacy N/A Data link upgrade planned (TCDL) Legacy Legacy OBP Data link upgrade planned (TCDL) Legacy Legacy N/A Pioneer, a legacy system, to be phased out when VTUAV becomes operational USMC G/S (control link) Legacy N/A Analog 512 kbps data link currently not used; Pioneer, a legacy system, to be phased out when VTUAV becomes operational

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Platform Sensor Data Link Link Data Rate Mode VTUAV Video TCDL 1.5 to 10.71 Mbps LOS P-3/EP-3 Video Legacy Analog, ~256 kbps LOS   SIGINT Legacy   LOS Joint STARS MTI SCDL 41 to 56 kbps LOS   SAR SCDL   LOS Rivet Joint SIGINT TADIL A and J 256 kbps LOS NOTE: Approximately 28 ships (12 carriers, 12 large-deck amphibious assault ships, and 4 command vessels) will be outfitted with JSIPS-N, CDL-Navy, Challenge Athena, and Global Broadcast System (GBS). This is the core of USN imagery afloat, and it supports timely direct and indirect imagery tasks. Additionally, GBS will be used to expand imagery dissemination to the larger fleet with a lower level of imagery functionality and smaller image products. The Annual UAV Report and the Manned Airborne Reconnaissance Plan previously published by Defense Airborne Reconnaissance Office (DARO) are useful sources of unclassified data regarding aircraft and related sensor data. DEFINITIONS: AWACS, Aircraft Warning and Control System BGPHES, Battle Group Passive Horizon Extension System CDL, common data link-Navy; formerly called common high bandwidth data link CDL-Navy-ST, common data link-Navy surface terminal; ~29 terminals funded CGSM, Common Ground Station Module, receives JSTARS data CIP, common imagery processor CTT, commander’s tactical terminal ETP, Extended Tether program HAE UAV, high-altitude endurance unmanned aerial vehicle (UAV) JSIPS, Joint Services Imagery Processing System; USMC and USAF ground station; 1 funded for USMC JSIPS-N, Joint Services Imagery Processing System-Navy; USN surface station; ~29 afloat and 4 ashore funded JTT, joint tactical terminal; replacement for CTT and tactical receive equipment (TRE) Legacy, program-unique systems

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Surface Terminal Data Link Receiver Processor Remarks TCS/JSIPS-N/TEG TCDL N/A Pioneer replacement; under development Legacy Legacy N/A Data link upgrade planned (TCDL) Legacy Legacy N/A   CGSM/afloat SCDL N/A USN planning for JSTARS transitioning SCDL to TCDL CGSM/afloat SCDL N/A   CTT TADIL N/A CTT being replaced by JIT LOS, line of sight MAE UAV, medium-altitude endurance UAV, Predator MCE, mission control element; HAE UAV ground station for advanced concept technology demonstration (ACTD) activities NIS, National input segment OBP, on-board processor SHARP, Shared Reconnaissance Pod; previously Super Hornet Airborne Reconnaissance Pod TARPS, Tactical Airborne Reconnaissance Pod System TCDL, tactical common data link TCS, Tactical Control System; tactical UAV ground station; may merge into both JSIPS-N and TEG in future TEG, Tactical Exploitation Group; USMC ground station; 3 funded TGIF, Tactical Ground Intercept Facility TIGDL, tactical interoperable ground data link TIS, tactical input segment; part of JSIPS-N; TIS = CDL-Navy-ST and CIP and screener workstation and support equipment TUAV, tactical UAV VTOL, vertical takeoff and landing SOURCE: Compiled from data courtesy of National Imagery and Mapping Agency, Bethesda, Md., 1999.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities TABLE E.A.2 Imagery Dissemination Systems (Indirect) Dissemination Architecture Communication System Communications Transport Receiver Type DDS   Shore sites DISN Fiber/SATCOM DE GBS GBS SATCOM GBS MTACS   Ship Fleet SATCOM UHF SATCOM Fleet SATCOM Shore DISN Fiber/SATCOM POS/DSCS/ Tri-band Shore Trojan Spirit II SATCOM TS II JCA   Shore DISN Fiber/SATCOM POS/DSCS/Tri-band Ship CA SATCOM CA Ship GBS SATCOM GBS DCS   Shore DSCS SATCOM DSCS Ship DSCS SATCOM DSCS NOTE: All indirectly disseminated imagery is independent of collection source. Approximately 29 carriers and light amphibious assault ships will be outfitted with JSIPS-N, CDL-Navy-ST, Challenge Athena III, and GBS. This is the core of USN imagery afloat, and it supports timely direct and indirect imagery tasks. Additionally, GBS will be used to expand imagery dissemination to the larger fleet. DEFINITIONS: CA, Challenge Athena; high-bandwidth (for ships) communications system that will support DDS; CA used for more than just imagery DCS, Defense Communications System; part of the DISN; provides defense satellite connectivity to ships and ashore facilities DDS, Defense Dissemination System, National Imagery and Mapping Agency (NIMA) Program Office. NIMA inserts imagery data into specific communication systems to reach specific customer’s receive equipment (DE). DE, dissemination element; receive capability hardware and software within the DDS DISN, Defense Information Systems Network: DISA networked communications infrastructure; includes DATMS, SIPRNET, Intelink, JWICS, and other systems DSCS, Defense Satellite Communications System; one of the long-haul components that make up DISN; may also be used by DDS and Trojan Spirit II on a location-by-location, scenario, and deployment-dependent basis GBS, Global Broadcast System

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Number of Receivers: Current Total Number of Receivers in POM Capability Imagery Use Remarks ~9 ~10 1.5-45 Mbps 1.5-45 Mbps DDS to ships via JCA ~50 ~300 1.5-24 Mbps 0.768-6 Mbps   All ships All ships 64 kbps Small   All fixed and garrison sites All fixed and garrison sites 0.128-45 Mbps 0.128-45 Mbps   3 3 1.5 Mbps 128+ kbps   All fixed and garrison sites All fixed and garrison sites 0.128-45 Mbps 0.128-45 Mbps   16 20 1.5 Mbps 768 kbps Data rate can vary from 384 to 1544 kbps;normally 768 kbps ~50 ~300 1.5-24 Mbps 0.768-6 Mbps   STEP sites STEP sites 768 kbps 128 kbps   13 44 1.544 Mbps Varies CV/CVN, LHA/ LHD, CG, LSD-41, LPD-17 JCA, Joint Services Imagery Processing System-Navy (JSIPS-N) Concentrator Architecture; USN future imagery dissemination “system”; will utilize both GBS and CA II communications system and will replace DDS for the USN. NIMA will send all imagery to USN JCA in Suitland, Maryland; JCA will then disseminate it to individual ships and user sites. MTACS, Maritime Tactical Communications System; Service-maintained, networked communication infrastructure supporting the USMC and interfaces with the USN; provides a user connection to the DISN and a communications link between command component afloat and ground component ashore POM, program objective memorandum POS, point of service; connection between local networks and DISN, could be SATCOM ground terminals like T-MET, Tri-band, or STEP, or fiber-optic land line STEP, standard tactical entry point; provides tactical communications entry into the DISN via the DSCS; to be upgraded to teleport concept, which also will include expanded capacities, protocol interfaces, and commercial connectivity TS II, Trojan Spirit II; U.S. Army deployable SATCOM terminal system; USMC also owns and operates several terminals SOURCE: Compiled from data courtesy of National Imagery and Mapping Agency, Bethesda, Md., 1999.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Annex 2 JPN, JDN, and JCTN Network Components This annex provides a schematic diagram (Figure E.A.1) of the networks composing the Joint Planning Network, the Joint Data Network, and the Joint Composite Tracking Network.

OCR for page 429
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities FIGURE E.A.1 Joint Planning Network, Joint Data Network, and Joint Composite Tracking Network network components. SOURCE: Modified from “Figure 3-1 TAD Communication Networks” in Bragg, Rick, PMW176-2, 1997, AADC Afloat Communications Requirements Analysis, Program Executive Office Theater Air Defense, Space and Naval Warfare Systems Command, San Diego, Calif., May 30, p. 3-2.