National Academies Press: OpenBook

Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities (2000)

Chapter: 4 Designing a Common Command and Information Infrastructure

« Previous: 3 Integrating Naval Force Elements for Network-Centric Operations -- A Mission-Specific Study
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4
Designing a Common Command and Information Infrastructure

This chapter begins by articulating the concept of a common command and information infrastructure for the naval forces, the Naval Command and Information Infrastructure (NCII). In particular, Section 4.1 notes the general attributes that the NCII should possess, including adaptability in the face of changing needs and new technologies, and the functional capabilities it should provide to support users. The NCII supports all echelons—strategic, operational, and tactical—with a uniform architecture that uses commercial network protocols, a concept that, for tactical networks, runs contrary to the current situation. Section 4.2 develops this important point, and it is further elaborated on in Appendix E. Since an architecture is key to realization of the NCII, Section 4.3 discusses the products and processes the Department of Defense (DOD) and the Department of the Navy currently use for developing architectures and comments on their suitability for developing an NCII architecture. Section 4.4 gives the committee’s recommendations based on the material presented in the preceding three sections.

4.1 THE NAVAL COMMAND AND INFORMATION INFRASTRUCTURE CONCEPT

4.1.1 Definition and Properties

The broad and rapid exchange of information and the ready assimilation and use of this information are at the heart of network-centric operations (NCO). In NCO, the individuals involved have access to information from a wide variety of

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

sources and can operate in an effective, coordinated manner by exchanging information, even if the force elements are widely dispersed. As a consequence, decision making should be more informed than is now the case, collaborative planning among dispersed elements should be more timely and complete, and distributed engagements involving sensors, fire control authority, and weapons at separate locations should be more readily executable.

Underlying this exchange and use of information is the Naval Command and Information Infrastructure, so named to indicate an infrastructure that supports not just the manipulation of information but also the actual functions of command. Such an infrastructure should possess a number of attributes:

  • It should integrate and support operations at all levels of command;

  • It should be responsive and assured, providing a continuously available, secure, high-integrity resource to support all information needs;

  • It should facilitate information management by offering consistent, tailored operational information to specified recipients;

  • It should be dynamic and self-organizing, automatically healing breaches and forming and automatically maintaining high-priority, low-latency broadcast or normal communication channels;

  • It should be independent of location, providing great operational flexibility in the geographical positioning of component units; and

  • It should be easily scaled and evolved, adaptable in size to meet changing needs, and capable of being modernized easily through the use of common, open interface standards and functionally modular design.

The NCII (see Figure 1.6 in Chapter 1) comprises the communication and computing assets necessary to accomplish two things: (1) effect the exchange of information among information repositories, sensors, command elements, forces and weapons, and logistic and support elements and (2) allow this information to be used for both human decision making and automated processes pertaining to command and execution.1 The communications and computing components embedded with sensors, platforms, weapons, and support systems are not considered part of the NCII, but the effective operation of the NCII requires that their interfaces to the NCII satisfy standards established in the overall NCII design. Information repositories are part of the NCII if they are naval assets directly supporting command, but other naval information sources that may be called upon (e.g., personnel databases) are not part of it, although their inter-

1  

The word “infrastructure” as used in this report includes both the underlying communications base and the common support applications that ride atop the base; specific mission applications are not included.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

faces to the NCII must be compatible.2 Joint and intelligence information sources are regarded similarly.

An information infrastructure like the NCII has natural analogs at the operational and strategic levels of warfare (e.g., the Global Command and Control System). The infrastructure also applies at the tactical level since it refers to general means for manipulating and transporting information, although one needs to define its scope at the tactical level carefully. Two cases in point illustrate the issue—tactical digital information links (TADILs) and the cooperative engagement capability (CEC). Because TADILs represent a general information exchange capability, they would fall within the scope of the NCII. The issue here is that the current TADIL implementations would not comply with the architectural standards that will probably be chosen for the NCII (e.g., Internet Protocol (IP) networks). However, over time (see Section 4.2 below), the TADILs could migrate into compliance. The CEC could be a different matter. It is a specialized implementation necessary to meet particularly demanding performance requirements. It is not clear, at least at this time, if the general standards chosen for the NCII would satisfy CEC performance requirements. If they do not, then the CEC would remain outside the NCII, but its interface to the NCII would have to satisfy standards established in the overall NCII design.

4.1.2 Information Use and Design Considerations

The next step in developing the NCII is to characterize more precisely the functions it will perform. That, in turn, requires that the concept for information use be considered.

4.1.2.1 Internet Paradigm

Network-centric operations embody the idea of rapid, ready, and flexible access to information, with the Internet in some sense serving as a model or paradigm. The Internet, as commonly referred to in popular discussion today, has two components: (1) a robust, underlying networked communications base and (2) the applications that make use of the communications base to provide information to a widely dispersed user population. The communications base derives from the ARPANET begun in the early 1960s, while the applications have appeared mostly within the last decade. The ease with which these applications have been able to make use of the underlying communications base has been a critical factor in the rapid growth of the Internet and the effect of the applications on society. The point for NCII design is to view the infrastructure as having two layers, a supporting resource base (e.g., communication) and

2  

The close association of logistics with command and control means, however, that the logistics databases should be part of the NCII.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

applications, which should be easily able to make use of the supporting resource base.

The Internet model has two aspects, top-down and bottom-up, both of them important. On the one hand, some top-down principles and standards are necessary so the applications can easily use the communications base and so users can interact with applications. On the other hand, the applications were developed from the bottom up, i.e., by a diverse developer population. This diversity means there is a broad base for innovation, which has contributed greatly to the widespread popularity and utility of the Internet. The point for the NCII is that it should use a framework of standards that would permit its applications to come from a diverse set of sources.

Further insight can be gained by focusing on the user. The Internet today (and even more so in the future) allows access to an “information marketplace.” Users’ needs are not satisfied with a predefined set of information; rather, they seek widely for the information they need. This behavior has a direct analogy in military operations in the current and anticipated future world environments. In the more prescribed scenarios of the Cold War, one could define the information requirements quite well, but now, uncertainty as to the type and location of future military operations precludes that. Furthermore, different operators may vary in their approach to a situation and hence in their information needs. Certain information requirements can be predicted—e.g., a unit will obviously want to know when it is under attack—but overall, detailed information requirements cannot be predicted in advance and will vary from user to user. From this it follows that the NCII should provide users ready and flexible access to information.

While the NCII should allow widespread dissemination of information, it must also be able to accommodate the need of commanders for some degree of control over dissemination (e.g., for security purposes and bandwidth management). Furthermore, this information dissemination enables greater decentralization of command, but at the same time it allows for the centralized collection of information and hence for greater centralization of authority. There is no single appropriate point on this centralization-decentralization spectrum; it will depend on the nature of the military operation. The NCII must able to support these varying modes of command.

Finally, it is critical to recognize that the manner in which information is used in the NCII will change continually as operational concepts are refined and new technologies introduced. This is the lesson of personal and business use of information technology: One cannot fully anticipate all the myriad ways that it can be used. Rather, one has to work with the technology to explore its uses, and these uses will suggest new technologies to be explored, which will lead to further new uses. Thus, the NCII must be designed to allow this continual evolution in information use and the introduction of new technology.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
4.1.2.2 Decision Focus

The ultimate end use of information in military operations is to support decision making. Since the final measure of any information system is the quality and timeliness of the decisions reached, the decisions should be central in assessing the functionality provided by the NCII.

Figure 4.1 is a highly simplified schematic of the information flow in the decision-making process at all levels of command. It makes clear that there are two aspects to the information support of decisions. First is the information gathering and generation stage, to prepare for and support making a decision. As discussed above, decision makers (or their staffs) should be able to easily find information and draw it to themselves. Second is the command dissemination stage—that is, the decision itself is information that must be conveyed to appropriate elements. The NCII applications should be specifically designed to support this decision-making process.

Not shown in Figure 4.1 but important to realize are the different time scales that can be involved. Generally speaking, there are two such scales. At the operational-strategic time scale, information is gathered, decisions made, and results disseminated in a time span ranging from minutes to hours (or even days). In the tactical time scale, the same process takes place in a matter of seconds or fractions thereof. In highly compressed tactical situations the decision-making function can be short-circuited by passing the information directly from the sensors to the weapons or possibly with automated processes replacing human decision making. Similarly, very rapid iterations in the decision process can be made in response to the changing tactical situation.

FIGURE 4.1 Information flow in decision making.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
4.1.2.3 Summary

The NCII must provide a set of functional capabilities, i.e., a set of system functions to support the user. These capabilities would be partitioned between applications and a supporting resource base. The application layer would contain specific functional capabilities to support the decision-making process. The supporting resource base provides more generic functional capabilities (e.g., communications), although generally speaking, these capabilities support decision making, too.

Specification of functional capabilities is not sufficient for designing an NCII, however. For example, the NCII must be easily configured to meet specific mission needs. This requirement is not satisfied by a functional capability; rather, it refers to a property of the system as a whole and is achieved by applying certain design principles to the overall system. Thus, both the functional capabilities and the system properties must be specified.

There are thus three general classes of requirements for the NCII:

  • Functional capabilities that directly support decision making both in the information gathering and generation stage and in the command dissemination stage,

  • Functional capabilities for the supporting resource base (e.g., communications), and

  • Design practices to achieve system properties (e.g., configurability).

4.1.3 Functional Architecture

The functional architecture shown in Figure 4.2 describes the capabilities that the NCII must provide and shows the interrelationships among these functions. Figure 4.2 follows from Figure 4.1 by inserting specific functions (e.g., collection management) to support the decision-making process, recognizing that these functions ride on top of a supporting resource base. The four functions to the left of the decision box in Figure 4.2 enable information gathering and generation, and the single function to the right of the box supports command dissemination.

The functions for the supporting resource base may be described as follows:

  • Communications and networking. These are the basic services that provide the communication links and form networks from them. Some communications could be point to point and not necessarily part of a network.

  • Information assurance. This function protects the information content from unauthorized disclosure or modification and ensures its delivery to intended users. Protection against both malicious threats and system failure would be considered in realizing this function.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

FIGURE 4.2 NCII functional architecture for information gathering and generation and command dissemination.

  • System resource management. This function furnishes services so that applications use the supporting resource base in an efficient, coordinated manner, in keeping with established priorities. Thus, the function would include services to manage and allocate bandwidth and to provide end-to-end quality of service.

There is more to the supporting resource base than the three functions given. There are also processing and storage functions. However, for the scope of this report, the three functions described were considered to be the ones requiring the most emphasis and assessment.

The functions supporting information gathering and generation and command dissemination may be described as follows:

  • Collection management. This function determines the tasking of sensors to collect data. It should task the sensors based on an integrated view of the sensor assets available and should support cross-cueing between sensors.3

  • Information exploitation and integration. This function extracts basic information from the initial input data and further refines that output by correlating, fusing, and aggregating it.

  • Information request and dissemination management. This function provides information based on user-specified requests for a given type of informa-

3  

Data input parallels collection management by drawing data from stored databases. Standard database retrieval methods are involved. Given the scope of this study, this function does not receive further treatment.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

tion. Its operation is transparent in that users do not have to know the details of where the information is located. This function will also provide information to users based on the directions of any other authorized party.

  • Information presentation and decision support. Information presentation is the graphical display of information to users. Decision support is a set of automated tools that allows users to manipulate information for the purposes of making a decision.

  • Execution management. This function supports delivery of decisions to the intended recipients and allows for dynamic adaptation of those decisions in the light of rapidly changing events. It could have been included under decision support but was believed to be important enough to be singled out.

The logical flow among the functions is easily seen. For example, if a user wanted a certain type of information, he or she would go to a particular display (information presentation) or request it in some generic manner (information request and dissemination management). Either of these functions would then draw on the base of exploited and integrated information, and, if necessary, sensors could be tasked to gather further data.

The set of functions given here seems complete, apart from the omission of the processing and storage functions noted above. The next step in development would be to specify the subfunctions or services that make up each of these functions and then to implement them in software or hardware. Particular attention should be paid to defining the interfaces to each of these functions and subfunctions so that they can interact appropriately. There are existing programs for implementing some of the functionality, although not generally within the context of the integrated view expressed in Figure 4.2. Chapter 6 discusses the status of implementing these functions.

4.1.4 System Properties

As discussed in Section 4.1.2, specifying the NCII also requires giving the system properties that it must satisfy. Such a list could be made quite long, since there are many desirable properties that a system should have, but here the list is held to just those few properties deemed most important (Table 4.1).

Information assurance appears both as a system property and, above, as a functional capability. It is a system property since it is achieved only when all components of the system are secure and protected. But it is so critical in establishing networks, given the vulnerability the networks could introduce, that it is also explicitly singled out in the supporting resource base.

The other properties listed in Table 4.1 are also critical. The lesson of modern information technology use, as demonstrated for example by the Internet, is that new and useful applications are continually arising. The situation should be no different in support of military operations, so flexibility to accommodate

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

TABLE 4.1 Important System Properties Required in the Naval Command and Information Infrastructure

System Property

Desired Attributes

Information assurance: assures continued availability of service despite failure of components and attack

The infrastructure should withstand multiple dependent and independent failures, including loss from physical attack. The infrastructure should continue in the face of successful attacks to provide service for the most critical needs. It should be able to isolate the attacker, reallocate resources, repair the damage, and recover. Backup modes of operation should be available.

Flexibility: accommodates new applications

The time required to test or widely deploy a new application should be short and the effort very little. This will encourage creative thinking and the emergence of applications based on user ideas. In particular, the system should include a “sandbox” for testing new applications.

Modular system design: accommodates new technology and software upgrades

Hardware and software will continuously evolve. New applications may require new or expanded software functionality. It is essential that the architecture allow independent upgrades of software modules.

Fast and easy configuration: meets tailored mission needs

It should be possible to generate system software and hardware configurations using system configuration tools. These tools should be capable of automatically generating configuration modules and simulating and testing the composed configuration, and a variety of graphical interfaces should be provided for different users requiring different levels of detail.

new applications is needed. The pace of information technology change is rapid, so it must be possible to incorporate relevant new technologies with minimum cost and time, which calls for modular system design. Finally, the configuration of deployed forces cannot be specified in advance, especially given the variability of military operations in the current and anticipated world environments, so configuration has to be fast and easy to meet tailored mission needs.

These properties require certain design principles and practices and can also be supported by technological innovations. Realizing the system properties should be one of the key considerations in developing the system architecture for the NCII.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4.1.5 Relationship to Other Information Infrastructures

Several information infrastructures are being discussed currently in DOD-wide and Service contexts. This section relates the NCII to them.

The defense information infrastructure (DII) is quite extensive, being regarded as “… the sum of all information management assets [supporting warfighters] owned by each of the Office of the Secretary of Defense (OSD) Principal Staff Assistants (PSAs), Joint Chiefs of Staff, Combatant Commanders, the individual Military Services, and Defense Agencies.”4 The NCII and the DII are not mutually inconsistent concepts. However, the DII is much broader in scope and has a nearer-term focus (the planning horizon in its master plan is typically 2 years).

The Department of the Navy’s Chief Information Officer (CIO) has led development of the concept of an information technology infrastructure (ITI).5 The ITI articulates the network connectivity and services needed to support all naval systems that produce, use, or exchange information electronically. In one sense it is broader than the NCII since it also applies to business operations. It is narrower in the sense that it focuses on network connectivity and services, which are in the supporting resource base in the NCII definition. The NCII also includes the functions supporting information gathering and generation and command dissemination (see Figure 4.2). The NCII and ITI are not inconsistent; rather, they have different emphases. In fact, one could imagine the ITI evolving to put more emphasis on upper-layer functions as does the NCII.

The Defense Science Board has articulated the integrated information infrastructure (III) concept.6 In general terms, it comprises information transport, distributed computing resources, and information services (service agents and application support agents). The NCII and the III are quite similar in spirit, although the NCII goes into more functional detail in the information services (i.e., the upper layer in Figure 4.2).

The concept of the battlespace infosphere (BI) developed by the Air Force Scientific Advisory Board7 is not a full infrastructure, but rather a combat information management system. Thus, it is narrower in scope than the NCII

4  

Defense Information Systems Agency. 1998. Defense Information Infrastructure Master Plan, Version 7.0. Department of Defense, Washington, D.C., March 13.

5  

Information Technology Infrastructure Integrated Product Team. 1999. Information Technology Infrastructure Architecture (ITIA), Version 1.0 Proposed, 3 volumes (draft). Chief Information Officer, Department of the Navy, Washington, D.C., March 16.

6  

Defense Science Board Summer Task Force. 1998. Joint Operations Superiority in the 21st Century: Integrating Capabilities Underwriting Joint Vision 2010 and Beyond. Office of the Under Secretary of Defense for Acquisition and Technology, Washington, D.C., October.

7  

United States Air Force Scientific Advisory Board. 1998. Report on Information Management to Support the Warrior, SAB-TR-98-02. Department of the Air Force, Washington, D.C.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

but develops the information management concepts in much more detail than does the NCII (or any of the other information infrastructures noted above).

A major point follows from the above discussion. More important than the differences in emphasis among the infrastructures is the fact that several different organizations looking at the problem from different perspectives have all come up with the need for articulating an information infrastructure to support warfighting operations across all echelons.8 The point for the naval services is to articulate in their planning for network-centric operations a concept such as the NCII. The IT-21 strategy (discussed in Chapter 6) is an excellent start in this regard, although it is not complete. It focuses on connectivity, with less explicit recognition of the upper-layer services depicted in Figure 4.2.

A second important point, made in most of the information infrastructure discussions, is the need for jointness. There are two aspects to this. First, the information infrastructures do not operate in isolation. Rather, information should be shared readily across Service boundaries, as well as across the military-intelligence boundaries. Second, the different information infrastructures should not be developed separately. Given the common need of the Services and the joint community for these infrastructures, there should be cooperative efforts to develop them.

One opportunity for such collaboration has just arisen. The Air Force in its expeditionary force experiments (EFXs) is planning in 2000 to begin exploration and development of the battlespace infosphere and is seeking joint participation.9 Naval participation, and in particular examination of the NCII concept, would seem to be highly beneficial to both the naval services and the Air Force. By participating, the naval services could benefit from the momentum and significant funding already inherent in the EFX series, and the joint nature of both the NCII and BI could be explored.

A third and final major point to recognize is that all the information infrastructures contain shared and common-use assets. For example, long-haul communications used in the NCII will be based in part on SATCOM assets shared with the other Services and joint community. Software in the NCII—e.g., to support the information gathering and generation functions shown in the upper part of Figure 4.2—will be developed in part for use across the Services and joint community. Some of this software might be unique to naval needs (e.g.,

8  

In addition to the information infrastructures noted in the text, mention should also be made of the newly emerging idea of the global information grid (GIG) being articulated by OASD (C3I) and the Joint Staff. Development of the GIG is currently focusing on policy matters, but it is likely that when a technical definition emerges it will in general be consistent with the NCII and the other infrastructures noted here. In fact, it could possibly benefit from some of the concepts being developed for the NCII.

9  

The BI has been renamed the joint BI (JBI), and the EFXs are now called joint EFXs (JEFXs).

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

information extraction pertaining to sea targets), but a significant portion of it would have more general utility.

Thus, the naval services (and similarly in the case of other joint or Service entities) will not “own” the NCII in the sense of a physical asset, just as no one body “owns” the Internet infrastructure. Rather, those charged with developing the NCII should have a concept of its overall capabilities and then see to what extent these capabilities are unique or, as would more generally be the case, shared or for common use. In this latter case, the NCII’s developers would have to interact with the broader community to ensure that developments meet their needs.

It is not possible in this report to indicate which components of the NCII are naval-unique and thus would be developed by the naval services alone and which would be shared or common-use assets developed more broadly. However, the NCII functional architecture (Figure 4.2) does provide a general way for the naval services to proceed. It delineates the necessary functional capabilities, and for each of those capabilities the naval office(s) developing the NCII would address how the capability is realized through naval-unique development or collaborative development for shared or common-use assets.

4.2 TACTICAL NETWORKS10

The committee believes it is feasible and desirable for the NCII to include the Navy’s tactical networks as well as its operational and strategic networks except in very rare special cases. Such an approach could offer the advantages of a uniform architecture and interfaces, resource management, and information assurance mechanisms and would be a great aid to interoperability. Clearly, a common architecture across the levels would greatly facilitate the rapid and widespread exchange of information that is central to network-centric operations.

A uniform architecture is not, however, the same thing as a seamless network. One concept for network-centric operations allows all data to flow seamlessly through any and all parts of the network. The committee does not agree with this concept. On the contrary, it believes, at least for the current state of technology, that the Navy’s tactical networks should be built using a uniform architecture and mechanisms but then deliberately segmented to provide speed-of-service guarantees and some degree of information assurance. Gateways, firewalls, and encryption devices should be interposed between segments.

10  

More detail on this subject is contained in Appendix E, “Tactical Information Networks.”

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4.2.1 Tactical Network Protocols

Network protocols are a key issue in establishing a common architecture. At the operational and strategic level, commercial, Internet-based protocols are being widely used. The question is whether tactical networks must continue to use noncommercial protocols, as is now the case.

In its own architectural diagrams, the Navy and the Assistant Secretary of Defense (ASD) for C3I distinguish those portions of its networked infrastructure based on commercial technology—the Joint Planning Network (JPN)—from the tactical portions of its infrastructure, the Joint Data Network (JDN) and the Joint Composite Tracking Network (JCTN). They provide a rationale for this sharp division: Activities that use the JPN can tolerate delays in information flow, while those using the JDN have tight time constraints and those using the JCTN have very tight time constraints. The argument is then made that commercial technology is incapable of meeting these tight time constraints, and it is concluded that the JDN and JCTN must therefore be military-specific.

This rationale is in some ways sound but it also has a number of weaknesses—details are given in Appendix E. The committee concluded that, on the whole, the disadvantages of noncommercial protocols outweigh their advantages and that tactical information networks should be a uniform part of the NCII architecture.

The committee found two key deficiencies in the Navy’s architectural vision for tactical networks:

  • It merely renames two existing tactical systems (JDN is really JTIDS, and JCTN is really CEC) and ignores the rest. The architecture omits any reference to sensor system links, e.g., for moving-target imaging (MTIm) and synthetic aperture radar (SAR) data, or to weapons control systems, e.g., ultrahigh frequency (UHF) satellite communications (SATCOM) target location updates for Tomahawks.

  • It underestimates commercial technology. The committee believes current and emerging trends in commercial off-the-shelf (COTS) networking technology will allow tactical networks to be a uniform component of the NCII architecture without loss of capability. However, some unique tactical problems still will not be solved by COTS techniques and so must be approached by a blend of COTS and military technology. These problems are described below.

4.2.2 Straw-man Architecture

The committee’s recommended “straw-man” architecture is a layered architecture with standardized interfaces. The standard network services furnish a broad set of services to the architecture; these include a standardized addressing and naming scheme and data transport using the Internet Protocol. The commit-

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

tee proposes that all new types of data transported between sensors, shooters, weapons, forces, and so forth be IP datagrams. This layering cleanly separates the type of data being transported from the type of radios employed, allowing great flexibility in the types of new systems that can be deployed with a single set of radios. Atop the common service layer ride various domain-specific applications. These applications would of course be quite varied in the tactical systems. As in the existing tactical systems, a straw-man architecture generally segregates the various subnetworks into separate radio channels. This allows the requisite low and bounded latency by ensuring that only specified classes of traffic can transit a given radio channel. And it helps with information assurance by segmenting the overall tactical network into compartments with strictly controlled interactions between them. Figure 4.3 illustrates this architecture, showing the tactical compartments and the points of controlled interaction. The latter also include interaction with operational and strategic parts of the NCII.

Segmentation points demarcate organizational as well as technical boundaries. This is an extremely important point and is perhaps best explained by analogy with the commercial telephony system. The public telephony system is

FIGURE 4.3 Straw-man tactical architecture for NCII-compliant and legacy subsystems. Acronyms are defined in Appendix H.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

defined by a uniform set of standards with which all equipment must comply, but this does not imply that the local telephone company owns and operates all equipment within the telephone system. Instead, a business will typically own and operate its own internal telephone system (the PBX and office phones), adding or moving phones and cabling as necessary. The business, however, does connect its PBX to the local telephone company’s service via standard interfaces. Similarly, the committee believes that tactical subsystems should be owned and managed by the appropriate operational subgroups, not a Navy-wide IT department. These subsystems should, however, be implemented in accordance with NCII standards and connect to the rest of the Navy’s networks via NCII standard interfaces.

4.2.3 Challenges

The committee did not find any definitive, Navy-wide list of arguments against using NCII standards and interfaces in tactical networking systems. The challenges of the tactical environment are very real, however. Table 4.2 indicates the most difficult challenges for tactical systems along with the committee’s comments on how they could best be approached within the NCII architecture.

TABLE 4.2 Unique Challenges for Distributed Systems in the Tactical Environment

Challenge

Explanation and Approach to Solution

Low delay

A set of distributed systems must perform a complete end-to-end action with a very stringent time budget.

The major factors in end-to-end system delay are usually overall system design, humans in the loop, and, to a lesser extent, channel access and transmission speeds for the underlying radio channels. Overall system design, which is outside the scope of this study, is probably the most serious issue in practice. The committee’s straw-man architecture segments the overall tactical network into subnetworks. This allows a direct mapping of the straw-man architecture onto the capabilities of the underlying radio channel and in turn enables the low-delay bounds that are required for many types of tactical data transport. Thus, use of the Naval Command and Information Infrastructure network services layer will not have much effect in delay in tactical networks.

High assurance

Many lives are at stake in tactical operations, including those of friendly forces and parties not explicitly targeted. In addition, collateral damage must be held to a minimum. Furthermore, the Navy might actually lose a battle should its tactical systems work poorly. Thus, tactical systems must perform with very high

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

Challenge

Explanation and Approach to Solution

 

reliability. They must be robust in the face both of enemy attempts to disrupt the systems and of collapse or malfunction due to overall system complexity and the chaos of battle. They must also survive enemy infiltration into the active systems and information warfare activities such as planting false information in various databases.

Information assurance poses a very wide range of difficult problems. The Navy must not accept anything less than the current best-practice in these fields. In particular, it should adopt the Secret Internet Protocol Router Network (SIPRNET) model as an appropriate starting point for how to structure a mission-critical network. Firewalls and packet encryptors will aid in compartmentalizing the Navy’s tactical network and ensuring that compromise or denial of one portion has the least possible effect on remaining portions. A number of problems in this area have no known technical solutions. The Navy’s approach, therefore, must be to adopt operational methods to minimize the problems. In addition, the Navy should actively participate in, and fund, R&D programs in information assurance. (See Chapter 5 for a detailed discussion of information assurance.)

Low-bandwidth, intermittent connectivity

The various platforms within the battlespace must communicate via radios, which provide only low-bandwidth, often intermittent connectivity.

These issues, while serious, are generally at the application level and hence with minor exceptions are not affected by adopting the common NCII architecture. The exceptions are transport-related, namely, that Internet Protocol (IP) headers may impose too much overhead for tactical radio channels, and that the Transmission Control Protocol (TCP) will not work well on channels with many dropped packets or highly variable delay. The committee recommends compressing IP headers by standard techniques and not employing TCP on such channels. (See Appendix E for details.)

Ad hoc, self-organizing systems

The group of platforms within a given battlespace is often assembled at short notice, with little or no prior planning for these particular platforms and systems to work together.

Commercial technology currently has relatively little to offer for solving this problem; in general, most commercial distributed systems require a fair amount of painstaking configuration of host computers, routers, firewalls, application programs, and so on, and few embody the principle that one can throw together a number of distributed entities and simply have them work. (Apple’s proprietary network services are a notable exception.) For the time being, at least, this will require manual or at best semiautomated configuration and so will probably continue to be troublesome in practice.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4.2.4 Findings

Based on the discussion of tactical networks above and in Appendix E, the committee arrived at two findings. First the committee found that tactical networks can advantageously conform to the NCII architecture, including the use of IP as a universal bearer. Segmentation, however, will help guarantee quality of service and information integrity.

The advantages of adopting commercial networking protocols include economy in deployment and upgrade and the robustness that results from their use by millions of information systems exchanging many forms of information. However, in this connection the committee also found that the use of standard protocols in tactical information networks creates technological challenges not now faced by other user communities. Meeting these challenges will require defense R&D in wireless networks that addresses such factors as network self-organization in highly variable and degraded environments.

4.3 ARCHITECTURAL GUIDANCE AND DEVELOPMENT PROCESSES

Architecture is defined as “… the structure or components, their relationships, and the principles and guidelines governing their design and evolution over time.”11 The NCII concept, as set forth in Section 4.1, is a high-level concept. An architecture providing general guidance for the NCII developers is necessary to implement this concept. It must be developed to ensure that the required functionality is incorporated, the appropriate systemwide properties realized, and the necessary interconnections enabled.

Development of an NCII architecture is an extensive undertaking, well beyond the scope of this report. The focus here is to assess how the current architectural guidance and development processes in the Department of Defense and the Department of the Navy relate to developing an NCII architecture. There are five organizations that develop architectures or architectural guidance relevant to the NCII: the OASD (C3I), the Defense Information Systems Agency (DISA), the Department of the Navy Chief Information Officer (CIO) and the recently established Chief Engineer (CHENG), and the Space and Naval Warfare Systems Command (SPAWAR). The roles of these organizations and their architectural products are discussed in Section 4.3.1, and the key issues in relating the products and processes of these organizations to an NCII architecture are discussed in Section 4.3.2. Section 4.3.1 is rather lengthy because much background material must be provided. Readers who are familiar with the architec-

11  

Department of Defense. 1999. Joint Technical Architecture, Version 3.0, Appendix F: Glossary. Washington, D.C., November 15. Available online at <http://www-jta.itsi.disa.mil/jta/jtav3final-19991115/jta30_15nov99.pdf>.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

tural products and processes discussed there might want to go directly to the section on issues (Section 4.3.2).

4.3.1 Existing Architectural Products and Processes

4.3.1.1 C4ISR Architecture Framework (OASD (C3I))

OASD (C3I) coordinated the development of the C4ISR Architecture Framework by a working group involving representatives of the Joint Staff, Services, and defense agencies. Version 2.0 of the document was released on December 18, 1997.12 The motivation for development, described in the document, was the statement, “The Defense Science Board and other major studies have concluded that one of the key means for ensuring interoperable and cost effective military systems is to establish comprehensive architectural guidance for all of DOD.” The framework is described at some length here because it forms the basis for most architecture development for large-scale information systems in DOD currently.

The overall nature of the framework is illustrated by the following quotes taken from the document:

The Framework provides the rules, guidance, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures ….

The C4ISR Architecture Framework is intended to ensure that the architecture descriptions developed by the Commands, Services, and Agencies are interrelatable between and among each organization’s operational, systems, and technical architecture views, and are comparable and integratable across Joint and combined organizational boundaries ….

The Framework provides direction on how to describe architectures; the Framework does not provide guidance in how to design or implement a specific architecture or how to develop and acquire systems-of-systems ….

The framework then goes on to indicate that three major perspectives, or views, combine logically to describe an architecture—the operational, systems, and technical views. These views are defined as follows:

  • The operational architecture view is a description of the tasks and activities, operational elements, and information flows required to accomplish or support a military operation;

12  

C4ISR Architecture Working Group. 1997. C4ISR Architecture Framework, Version 2.0. Department of Defense, Washington, D.C. Available online at <http://www.c3i.osd.mil/org/cio/i3/AWG_Digital_Library/pdfdocs/fw.pdf>.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
  • The systems architecture view is a description, including graphics, of systems and interconnections providing for, or supporting, warfighting functions; and

  • The technical architecture view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements, whose purpose is to ensure that a conforming system satisfies a specified set of requirements.

Briefly stated, the interrelationship between these views is that the operational architecture defines the information exchange requirements that the systems architecture must then support, with the systems architecture being developed in accordance with technical criteria specified in the technical architecture.

For each of the views, the framework prescribes a set of products that are to be used in realizing it. These architecture products are the graphical, textual, and tabular items that are developed in the course of building a given architecture description and that describe the characteristics pertinent to its purpose. When completed, this set of products is intended to constitute the architecture description. There are two categories of such products:

  • Essential products. These products constitute the minimal set of products required to develop architectures that can be commonly understood and integrated within and across DOD organizational boundaries and between DOD and multinational elements. These products must be developed for all architectures.

  • Supporting products. These products provide data that will be needed depending on the purpose and objectives of a specific architecture effort. Appropriate products from the supporting product set will be developed.

To be more specific, the set of essential products is as follows:

  • All views: overview and summary information, integrated dictionary (definition of terms);

  • Operational view: high-level operational concept graphic, operational node connectivity description (activities at each node and information flows between them), and operational information exchange matrix (includes attributes of exchanged information);

  • Systems view: system interface description; and

  • Technical view: technical architecture profile (extraction of standards that apply to the architecture).

In addition, there are 19 supporting products. The supporting products may be necessary as intermediate steps leading to the essential products.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

The requirement for use of the C4ISR Architecture Framework was stated in a memorandum released on February 23, 1998, and signed by the Under Secretary of Defense (Acquisition and Technology), Acting Assistant Secretary of Defense (C3I), and the Director for C4 Systems, the Joint Staff. In particular, the memorandum states as follows:

We see the C4ISR Architecture Framework as a critical element of the strategic direction in the Department, and accordingly direct that all on-going, and planned C4ISR or related architectures be developed in accordance with Version 2.0. Existing C4ISR architectures will be redescribed in accordance with the Framework during appropriate revision cycles. We also direct all addressees to examine the C4ISR Architecture Framework as a basis for a single architecture framework for all functional areas/domains within [the] Department.

4.3.1.2 Joint Technical Architecture (DISA)

The Department of Defense Joint Technical Architecture (DOD JTA) provides the technical architecture view applicable to all of DOD.13 Development of the DOD JTA is coordinated by DISA under the direction of OASD (C3I) and involves representatives from across DOD as well as the intelligence community. Version 2.0 of the JTA was released on May 26, 1998. It gives the purposes of the JTA as follows:

  • To provide the foundation for interoperability among all tactical, strategic, and combat support systems;

  • To mandate interoperability standards and guidelines for system development and acquisition that will facilitate joint and coalition force operations. These standards are to be applied in concert with DOD standards reform;

  • To communicate to industry the DOD’s intent to consider open systems products and implementations; and

  • To acknowledge the direction of industry’s standards-based development.

In keeping with the last two items, the standards contained in the JTA are predominantly commercial. As a listing of standards, the document is not, strictly speaking, an architecture.

The standards are broken out into five categories: information processing; information transfer; information modeling, metadata, and information exchange; human-computer interface; and information systems security. Little rationale is given for the organization of the standards into these categories or

13  

Department of Defense. 1998. Joint Technical Architecture, Version 2.0, Appendix F: Glossary. Washington, D.C., May 26.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

within the categories.14 For each category, the set of mandated standards is given. Also listed are emerging standards, which are expected to be elevated to mandatory status when their implementations mature.

The JTA has now also added annexes organized by defense domains, and within those domains, by subdomains. These annexes give the mandated and emerging standards and associated descriptive material for the subdomains. There are four domains—C4ISR, weapon systems, modeling and simulation, and combat support—and 21 subdomains. At this time, only five of the subdomains have explicit entries. For example, there are six subdomains under C4ISR, but only one (airborne reconnaissance) has entries.

The requirement to use the JTA standards is indicated by the following extract from a memo issued on November 30, 1998, by the Under Secretary of Defense (Acquisition and Technology), the senior civilian official (OASD (C3I)), and the Director for C4 Systems, the Joint Staff:

Implementation of JTA, that is the use of applicable JTA mandated standards, is required for all emerging, or changes to an existing capability that produces, uses, or exchanges information in any form electronically; crosses a functional or DoD Component boundary; and gives the warfighter or DoD decision maker an operational capability. Use of an applicable JTA mandated standard must consider the cost, schedule, or performance impacts, and if warranted a waiver from use granted as described below…. Each DoD Component and cognizant OSD authority is responsible for implementation to include compliance assurance, programming and budgeting of resources, and scheduling. Only the Component Acquisition Executive, or cognizant OSD authority can grant a wavier from the use of an applicable JTA mandated standard. All waivers shall be submitted to the USD(A&T) and ASD(C3I) (the DOD Chief Information Officer (CIO)) for concurrence ….

4.3.1.3 Chief Information Officer Architecture Products

Development of architecture and standards products by the Department of the Navy Chief Information Officer is in response to recent legislation, including the Clinger-Cohen Act of 1996 (Public Law 104-106), which requires department CIOs to “develop, maintain, and facilitate the implementation of a sound and integrated enterprise architecture and standards” (Section 5125 (b) (2)).15 To provide a focus for these efforts, the Secretary of the Navy mandated

14  

Also, in providing its total set of standards, the JTA does not distinguish between those standards that are most relevant for interoperability and those that pertain most to constructing open systems. Interoperability pertains mainly to the standards between systems, while open systems considerations also involve the standards within systems.

15  

The Clinger-Cohen Act of 1996, formerly the Information Technology Management Reform Act and the Federal Acquisition Reform Act, requires the CIOs of the federal agencies to establish acquisition and management processes for information technology (National Defense Authorization Act for Fiscal Year 1996. U.S. Statutes at Large 110 (1996); 186).

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

that Department of the Navy CIO integrated products teams (IPTs) be the only Department of the Navy authorized entities to develop enterprise information management/information technology architectures and standards. These IPTs report to the Department of the Navy CIO Board of Representatives (BOR), which is chaired by the CIO and formed from representatives of Navy and Marine Corps operating forces, major claimants, and program sponsors.

Two products are being developed: the Department of the Navy Information Technology Infrastructure Architecture (ITIA) and the Department of the Navy Information Technology Standards Guidance (ITSG).16 Volume I of the ITIA, Network Infrastructure and Services Architecture, and Volume II, Enterprise Architecture Framework, were approved by the BOR and released on March 16, 1999. Volume III, Governance, and Volume IV, Requirements Process, have not been released yet. The ITSG was released as version 99-1 on April 5, 1999, along with a cover memo from the Department of the Navy CIO.

Volume I of the ITIA is a systems architecture according to the definition in the C4ISR Architecture Framework. It provides significant detail and discussion of (1) a connectivity architecture based on modern network concepts and (2) the basic network services (e.g., domain name service (DNS), file transfer protocol (FTP), e-mail, public-key infrastructure (PKI), Web hosting, voice, multimedia). This volume should be useful in accomplishing its stated purpose:

This document provides guidance for planning, developing, implementing, and operating all activities associated with DON IT [Information Technology] network infrastructure. It is to be used by DON acquisition programs, organizations, working groups, and Integrated Products Teams (IPTs) to facilitate convergence on a single, comprehensive ITI [Information Technology Infrastructure] architecture. This guidance and associated design templates are not intended to be detailed design and implementation plans, but to serve as frames of reference for design and implementation efforts.

Volume II of the ITIA was developed to provide an overall context for Department of the Navy enterprise architecture modeling efforts. It is based on the C4ISR Architecture Framework, extending the views contained therein. It also introduces a fourth view, the mission view, to identify strategic mission areas and priorities. At this time, Volume II remains a fairly high-level descriptive document.

The ITSG is a technical architecture according to the definitions of the C4ISR Architecture Framework.17 By its own description, the ITSG is complementary to the JTA and provides additional guidance for applying the JTA. It

16  

Chief Information Officer Infrastructure Integrated Product Team. 1999. Information Technology Standards Guidance, Version 99-1. Department of the Navy, Washington, D.C., April 5.

17  

Although, correctly so, it avoids referring to itself as an “architecture,” since it is formed around a compilation of standards.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

notes that if there is a conflict in standards with the JTA, the JTA takes precedence. The ITSG devotes significantly more attention than the JTA to providing an overall structure in which to present the standards and to discussing the standards. In this regard, as well as in discussing aspects of the standards unique to naval use, the ITSG should provide a significant benefit to its users. The requirement for using the ITSG is indicated in the following extract from the DON CIO cover memorandum dated April 7, 1999:

The ITSG applies to all DON systems that produce, use, or exchange information electronically, and is intended for anyone involved in the management, development, acquisition and operation of new or improved systems. It provides the standards, specifications, best practices and operating profiles required to implement and maintain an integrated, enterprise information infrastructure. … Enterprise-wide use of these DON IT standards will enable coordinated communications across dispersed DON organizations …. All commands in the Navy and Marine Corps are required to consider the standards and guidance in the ITSG to maximize interoperability and enable focused information support across the Department. The ITSG Version 99-1 contains no mandatory requirements, and cannot be used as justification for less than full and open competitive acquisition.

It should be noted that the recently established Navy/Marine Corps intranet program has indicated it will use the ITSG.

4.3.1.4 Chief Engineer Responsibilities

The position of the Department of the Navy Chief Engineer was established and its first incumbent named on April 13, 1999. The responsibilities of that position are indicated by the following extracts from a memorandum issued by the Assistant Secretary of the Navy (ASN) (Research, Development and Acquisition (RDA)) on that date:

1. Effective immediately, the Chief Engineer will be the senior technical authority within the acquisition structure for the overall architecture, integration, and interoperability of current and future Combat, Weapons, and C4I Systems used by the Department of the Navy.

2. The position of Chief Engineer is not intended to dilute any of the traditional responsibility for individual program integrity currently assigned to Program Managers and Program Executive Officers. Rather, the Chief Engineer will be responsible for developing and implementing a process within ASN (RDA) which does not now exist: to assure that component systems are engineered and implemented to operate coherently with other systems as part of a larger force.

3. The Chief Engineer will be the technical authority for those functions necessary to satisfy this end. These include: (a) leading the functional design for Combat & C4I system functions with respect to the overall warfare architecture; (b) approval of system level interface specifications for all referenced

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

systems; (c) assessing and approving interface changes that impact interoperability, prior to fleet introduction; (d) assuring that individual programs adhere to the resulting configuration, and (e) recommending investment decision and program priorities to myself and the appropriate service chief concerning fielding systems in balance with their legacy and planned future counterparts.

The Chief Engineer’s responsibilities will be exercised through the involvement of and close coordination with the affected PMs, PEOs, SYSCOMs, and where applicable, the Chief Technology Officer.

4. The primary immediate priorities of the Chief Engineer are the successful integration of the Cooperative Engagement Capability (CEC) system with the targeted weapon systems and tactical data links and the development of Navy Theater Ballistic Missile Defense (TBMD) systems.

The Chief Engineer office has existed only for a short period and currently has no staff other than a deputy. For this reason, no detailed architecture products have been produced yet by the office but may well be produced in the future. While activity is currently focused on combat systems interoperability, as noted in item (4) above, and is carried out in close coordination with the Naval Sea Systems Command (NAVSEA), the responsibilities of the Chief Engineer allow consideration of a much broader range of architectural topics. These topics could pertain to tactical operations in addition to theater air and ballistic missile defense, and to the strategic and operational levels of warfare.

4.3.1.5 SPAWAR Navy C4ISR Architectures

SPAWAR has prepared a number of Navy operational, systems, and technical architectures, some of which are drafts. The operational architectures pertain to C4ISR overall and to individual mission areas—air warfare, amphibious warfare, command and control warfare, mine warfare, strike warfare, surface warfare, and undersea warfare. They are lengthy expositions that largely describe the as-is situation, although some indication of potential future modifications is given. After beginning with some statements of the overall operational concept, the architectures go into a detailed listing of such items as the operational nodes that are involved, the tasks of each of those nodes, and the information exchanges among them. As such, the operational architectures tend to contain many detailed tables, with little intermediate-level expression between the high-level concepts and the detailed tables.

There are two Navy systems architectures, the as-is C4ISR systems architecture and the target (to-be) C4ISR systems architecture. The target architecture presents a detailed methodology for developing all the architecture products (see under “C4ISR Architecture Framework,” Section 4.3.1.1) and relating them to each other. Each of these products, which are typically detailed items, is then developed. A key aspect of the methodology is its emphasis on system func-

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

tions, in contrast to the perspective taken in the C4ISR Architecture Framework. The systems architecture view given in the framework focuses on the physical implementation of systems, as indicated by its definition of systems architecture as “a description, including graphics, of systems and interconnections” and by the fact that the only essential (required) architecture product is the system interface description. This distinction is explicitly noted in the following excerpt from the SPAWAR Naval C4ISR Architecture Primer:18

… in transitioning from an operational to a system architecture the Navy approach and the CISA approach are different [CISA is the OASD(C3I) organization that developed the C4ISR Architecture Framework]. Essentially, the Navy’s approach includes two phases: a functional analysis and a physical analysis. The CISA approach jumps immediately to the physical analysis …. The Navy believes that jumping immediately to the physical analysis is appropriate for “As-Is” architectures, but developing “To-Be” architectures requires a more thorough understanding of systems functions, and therefore the Navy’s approach precedes the physical analysis by a functional analysis. As technology and operational requirements change, the Navy approach would make operational, systems, and technical architectures less costly to implement.

In short, articulation of the system functions is a critical intermediate step in moving from the operational view to the physical implementation of the C4ISR system.

The Navy C4ISR Technical Architecture, currently released as Version 2.0, pertains to the inter-platform and intra-platform C4ISR interfaces necessary to support Navy missions and their subordinate functionality and performance parameters. It also pertains to C4ISR interfaces with other Navy systems, such as weapons, sensors, and combat support. This technical architecture contains a subset of the standards in the JTA and additional standards unique to Navy missions and noncompeting with the JTA. It is patterned after the JTA and as such is largely a listing of standards. It divides standards into the same categories as the JTA (see Section 4.3.1.2 for the five categories), except that it also adds the category “intelligence, surveillance, and reconnaissance.” In addition, it contains a set of appendixes listing the standards unique to Navy mission areas. A separately published appendix, “Migration Strategy,” provides information to aid in the migration from current standards to target standards. The last release of this volume, Version 1.5 dated July 16, 1998, refers to target standards for the year 2000.

18  

Deputy Chief Engineer for Architecture and Standards. 1997. Naval C4ISR Architecture Primer, final draft, SPAWAR 051-2. Space and Electronic Warfare Systems Command, Washington, D.C., January 17, pp. 4-18.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4.3.2 Application to the NCII

When the various DOD and Navy architectural products and processes described above are related to the development of an NCII architecture, several shortcomings in the current products and processes are evident.

4.3.2.1 Operational and Systems Architectures

The discussion in Section 4.1.2 emphasizes that information needs cannot be regarded as fixed. Users will vary in their needs, will evolve with respect to the type of information they want as they explore and use what is available, and will want to tailor the way information is provided and presented to them. Furthermore, the ways in which new information technology can be applied are often not immediately apparent. One has to work with new technologies to explore their uses, and these uses will suggest additional technologies to be explored, which will lead to further new uses. This continual interplay between the exploration of technology and the evolution of operational concepts will lead to ongoing changes in the way information is used. All this requires a rapid, iterative process of technology exploration and refinement of operational concepts (a theme developed in detail in Chapter 2).

This requirement for flexibility and rapid iteration does not seem well supported by the detailed methodology of the C4ISR Architecture Framework. Three points are particularly relevant:

  1. The number and detailed extent of the C4ISR architecture products means they take significant time to develop. This is inconsistent with the rapid iteration necessary in introducing technology and refining operational concepts.

  2. The rapid iterative process requires the close and frequent interaction of system users and developers. If the operational architecture is developed through to its end and the systems architecture is then begun, which seems to be implied by the C4ISR Architecture Framework methodology, then this interaction cannot take place.

  3. Articulation of the system functions is a key intermediate step in moving between operational concept and system realization. As noted in the discussion of systems architectures above, system functions do not play a prominent role in the C4ISR Architecture Framework methodology.

The C4ISR Architecture Framework would seem to have utility in the development of well-understood systems for which the requirements can be laid out in detail in advance of the development of the system. To accommodate the more flexible, iterative process necessary for constructing the NCII, the following significant changes to the framework methodology appear necessary:

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
  • New high-level products must be developed to describe the operational and systems architectures, intermediate in detail between the current operational concepts given on a single chart and the detailed tabular information now produced in operational and systems architectures. Since such products could be modified relatively quickly, they would support a rapid iterative process and allow the close interaction of operational and systems personnel.19

  • An architectural product must be established to indicate the concept of operations for using information. The current examples of operational architecture all relate to how information supports traditional warfighting tasks, which is obviously required. But there is also a need to consider how the information is treated. For example, is it obtained by push or pull? How does the commander want to promote or limit its distribution? Critical factors such as these need to be recorded for systems to be developed and used properly. For best use, these would be high-level (five-page summary) products. The best course might be to have the operational architecture provide only a general template for this type, with the particular details inserted by individual commanders and their staffs.

  • Greater prominence must be assigned to the role of system functions in the system architecture products. As noted, the system functions are central in the relationship between concepts of operation and system realization. Such a system architecture product could be made essential (i.e., required in all system architecture developments). In addition, an intermediate level of detail would serve the flexibility needed in a rapid, iterative development process.

4.3.2.2 Technical Architecture

A technical architecture, as envisioned in the C4ISR Architecture Framework, serves important purposes: It promotes the use of commercial products, which can mean lower costs and faster technology refresh cycles; it leads to open-architecture designs, which facilitate interoperability; and it aids modular design practices, which can make technology upgrades easier. Standards typically change on longer time scales than do the individual technologies, so developing architecture products that can be modified quickly is less critical for technical architectures.

However, an important concern in technical architecture products is that the set of required standards be kept as small as possible, for two different reasons: to avoid unduly constraining system developers by mandating standardization where it is unnecessary or premature to do so, and to limit the set of choices for

19  

Development of an automated tool to facilitate construction of operational architectures is discussed in Chapter 6, Section 6.2.7.3.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

a given standards area so that different developers do not unnecessarily choose different standards, which can adversely affect interoperability. The JTA claims to be a minimal set of standards, and both the Department of the Navy ITSG and the SPAWAR Technical Architecture claim to further refine the standards selection to suit the Navy’s needs. However, the limited analysis possible for this report did not allow determining if these three technical architectures were appropriately minimal.

Note that most of the standards in the JTA, or refinements of the JTA for naval purposes, would be of two types: commercial standards (e.g., for network services) or DOD-wide standards (e.g., for specific application domains such as intelligence or logistics). Few, if any, of the standards would be naval unique. Thus, the naval offices responsible for determining the standards would, in general, have to choose from broader sets of standards and not develop their own standards. Relatedly, these offices should interact with the broader communities developing the standards to ensure that naval needs are met.

4.3.2.3 Beyond Current Standards-based Architectures

The systems architectures discussed thus far above would all be based on the interfaces, services, and accompanying standards specified in the technical architectures (JTA, ITSG, and the Navy C4ISR Technical Architecture). That is the current state of practice, and much can be said for it. However, there still are shortcomings. For example, given the pace at which technology is advancing, it is not possible to impose common standards on a wide community (consider, as a possible extreme, a community of U.S. forces and coalition forces). Thus, limitations could occur when elements of this wide community need to interoperate with one another. In addition, even if common standards from the JTA (or a similar source) are used, the definitional consistency of the data that are exchanged must also be considered. Again, for practical reasons, it is not possible to impose common data definitions across wide communities. Furthermore, account must be taken of the fact that excessive imposition of standards will limit innovation.

Thus, one needs to look for advances in technology or in design practice that will lead beyond the current technical architectures to address problems such as those just noted. The JTA and similar documents do have sections on emerging standards and are thus anticipating the future to a limited degree. But it is not the function of these technical architectures to be a vehicle for tracking and promoting revolutionary, but potentially highly beneficial, technologies.

Such technologies are now being pursued, including the following:

  • Semantic interoperability. Research in this area is aimed at achieving means for common semantic understanding across components developed with different data representations. One example of research in this area was carried

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

FIGURE 4.4 Schematic of the emerging Control of Agent-based Systems grid architecture, which minimizes integration effort to connect to the grid by adapting the connection mechanisms instead of the client components. SOURCE: Hendler, James, “Control of Agent-based Systems Technical Overview,” a briefing presented to the System Architecture Panel on April 15, 1999, Information Systems Office, DARPA, Arlington, Va. Acronyms: ACL, agent communication language; API, application program(ming) interface; CORBA, common object request broker architecture; OAA, over-the-air activation signal; RMI, remote method invocation; XML, Extensible Markup Language.

out in conjunction with the Defense Advanced Research Projects Agency (DARPA) Dynamic Multiuser Information Fusion (DMIF) program and is now being continued under the Air Force Office of Scientific Research (AFOSR).20

  • Agents. The DARPA Control of Agent-Based Systems (CoABS) program is exploring the use of agents as an interoperability mechanism. Interfaces might be more flexibly defined if the agents could negotiate interactions between system components. Currently under development in the program is a metaframework or grid (see Figure 4.4) that will allow agents operating under different agent communities or interagent languages to communicate. In addition, an effort is about to begin to establish a new agent language intended to

20  

Krikeles, B., and T. Libby. 1999. Achieving Information Superiority: Interoperable Components and Battlespace Representation. ALPHATECH, Inc., Burlington, Mass., March 27.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

progress well beyond current Web languages (HTML, XML) that will provide readable (interoperable) semantics, given a developed ontology.21

  • Publishing internal properties. In this instance the components of a system would make known to the broader system certain aspects of their internal composition. This would permit greater flexibility and tailoring in establishing interfaces with those components. One example of this general idea is the terminal access packet discussed in Chapter 6 (Section 6.2.3.3).

While such work is ongoing in the research community, it needs greater recognition and support at senior Navy Department and DOD levels. Officials at those levels should not believe that the DOD and naval technical architectures as they now exist provide a complete solution to the technology specification for architectures. The capabilities envisioned for the NCII cannot be fully realized with current technical architectures. The necessary flexibility and adaptability will require advances in architecture-related technologies such as those noted above.

4.3.2.4 Organizational Responsibilities

According to the discussions above, three naval organizations are actively involved in architecture and thus could be involved in development of an NCII architecture—the Department of the Navy CIO, Department of the Navy CHENG, and SPAWAR.22 It is thus important to understand what might be the boundaries of responsibility that each organization could have for the NCII architecture. The Department of the Navy CIO would appear to have a significant responsibility given the enterprise-infrastructure architect role assigned it by the Clinger-Cohen legislation. However, the Department of the Navy CHENG would also seem to have significant responsibility according to its charter. And SPAWAR has traditionally been involved with the development of C4ISR architectures. Perhaps the Department of the Navy CIO should be responsible for the general infrastructure aspects, while the Department of the Navy CHENG should oversee the C4ISR specific aspects and interfaces to weapons and other systems, and SPAWAR should develop the detailed C4ISR aspects.

The responsibilities of the Department of the Navy CIO and Department of the Navy CHENG would appear to lie in the systems and technical architecture

21  

Note is also made of the Foundation for Intelligent Physical Agents, which is trying to promote open specification of agent systems to maximize their interoperability. Information is available online at <www.fipa.org>.

22  

The combat systems that NAVSEA and NAVAIR develop are outside the scope of the NCII, but since they must interface with the NCII, broader considerations would include NAVSEA and NAVAIR.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

areas. Of the three organizations, SPAWAR is the only one that has developed operational architectures, although these are primarily as-is architectures. Organizations from the doctrine and experimentation communities might be appropriate for developing the future operational architectures.

Organizational responsibility for the NCII architecture must be assigned before the architecture can be properly developed and implemented. The matter of organizational responsibility for network-centric operations as a whole, including NCII development and operation, is discussed in detail in Chapter 7. One suggested scheme for assigning responsibilities for the NCII in keeping with the discussion above and consistent with the material in Chapter 7, could be as follows:

  • Resource allocation and requirements sponsor: OPNAV N6;

  • Operational architecture: Commander, Operations Information and Space Command, with the support of OPNAV N6;

  • Policy and standards: Department of the Navy Chief Information Officer;

  • Systems and technical architectures (including enforcement): Department of the Navy Chief Engineer;

  • Acquisition and procurement: Program management as designated by the ASN (RDA) (e.g., the PEO-IT); and

  • Operational management: Commander, Operations Information and Space Command.

Included in this list is a new position introduced and recommended in Chapter 7—the Commander, Operations Information and Space Command. This individual would be a functional type commander analogous to existing type commanders (e.g., for air assets) and would be concerned with the information assets of the fleet just as the other type commanders are concerned with the assets in their areas. SPAWAR, NAVSEA, and NAVAIR would also figure in the assignment of responsibilities by providing support to the areas listed.23

4.4 RECOMMENDATIONS

The recommendations presented here are organized according to the three main topics discussed above: establishment of the NCII, tactical networks, and architecture development.

23  

Chapter 7 also recommends double-hatting a Navy SYSCOM commander as a deputy to the ASN (RDA) for integration of network-centric operations. This individual would coordinate in the acquisition and procurement decisions.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

4.4.1 Establishment of the NCII

The NCII offers a comprehensive, unifying concept. In broad terms, the committee recommends that the naval services adopt and apply the NCII as the overarching concept for providing information support to network-centric operations. In more specific terms, it makes three recommendations:

Recommendation: The Department of the Navy should develop and enforce a uniform NCII architecture across the strategic, operational, and tactical levels of naval forces.

This means that, for all levels, (1) the same set of functions will apply (as defined in Figure 4.2),24 (2) interfaces and standards associated with these functions will be the same, and (3) consistent definitions will be used for the data exchanged between the functions. Such an architecture would integrate the system capabilities and facilitate the interoperation of forces. As such, it would promote the widespread and flexible exchange of information necessary for network-centric operations.

Recommendation: The Department of the Navy should give an organization the responsibility and adequate resources for (1) establishing a comprehensive view of capabilities and programs necessary to implement the NCII and (2) seeing that these capabilities are realized.

During its information-gathering efforts, the study committee found numerous naval and joint organizations that were able to provide valuable information on various components of information infrastructures. Yet the committee was continually struck by the fact that no one office or organization had a comprehensive view of the capabilities and programs that would constitute an infrastructure such as the NCII. No organization was found, for example, that had an end-to-end systems view of information-handling capabilities, such as that shown in Figure 4.2.25 Furthermore, many offices provided valuable information on programs relating to individual functional capabilities, but none had an overview of a full set of relevant programs.

Effective realization of the NCII requires that some organization have an overview of its requirements and the programs satisfying those requirements.

24  

The tactical domain will, in addition, have its own unique functions that are particular to warfighting mission areas. These are considered in Chapter 3.

25  

There are excellent end-to-end views of communications and networking capabilities, but as Figure 4.2 makes clear, there is also a significant information-handling component that rides on top of the communications and networking.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

The set of programs is large and comes from diverse sources (Chapter 6 briefly discusses some of these programs). The organization would not control the programs as does a traditional program manager. Indeed, in modern large-scale information systems, no one controls all the pieces; rather, the managing organization understands what pieces are available and how they fit together. Accordingly, the desired organization would identify the relevant developmental activities (both government and commercial) that could support the infrastructure, track their evolution and progress, and indicate which should be applied in implementing the infrastructure. Furthermore, this organization would identify requirements that are not being met through the activities and establish priorities for meeting these shortfalls. Gaining such an overview is a substantial undertaking, so this organization would require significant resources in terms of both staff and funds.

Recommendation: The NCII should be developed in collaboration with the other Services, the joint community, and National agencies to promote interoperability and build on each other’s efforts.

The NCII is presented here as a naval concept, in keeping with the study’s purpose, which is to examine naval network-centric operations; nonetheless, much of what is discussed is of interest and use to joint and other Service operations. In fact, the other Services are developing analogous concepts, and many of the supporting programs come from the joint community (e.g., DARPA and DISA), as well as the intelligence community. Thus, to promote interoperability and avoid unnecessary duplication, the naval organization responsible for implementing the NCII should collaborate with the broader community. As noted in Section 4.1.5, one potentially valuable, immediate opportunity would be participation with the Air Force in its expeditionary force experiments.

4.4.2 Tactical Networks

The committee makes two recommendations pertaining to a transition strategy in particular to ensure that tactical information networks conform to the NCII architecture.

Recommendation: With few, if any, exceptions, new tactical information networks should conform strictly to the NCII goal architecture and should use appropriate gateways, firewalls, and encryption devices to ensure high quality of service.

The term “strictly” is used because at any moment there may be within the NCII legacy systems that do not conform to the goal architecture but that have

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

been grandfathered into an interim standard. New systems must not be allowed to perpetuate the characteristics of the nonconforming systems.

Although the committee recognizes that engineering some difficult future communications links may lead to new waveforms and antenna control schemes for transport, it thinks it may be possible and desirable to implement a standard IP bearer in most or all network terminals and to separate that protocol from message content. In some cases the Navy or the DOD has already thought seriously about this possibility. Summarizing the conclusions of Appendix E on this matter, the committee recommends as follows:

Recommendation: Terminals of the Joint Tactical Information Distribution System (JTIDS) and common data link (CDL) families should be modified to use NCII standard protocols. The pros and cons of so modifying the CEC data distribution system should be studied further.

In addition, a further recommendation pertains to necessary research and development.

Recommendation: The DOD, including the Navy, should sponsor a vigorous research and development program aimed at improving the performance of wireless information networks that can self-organize with high assurance despite limited and highly variable connectivity between pairs of nodes and despite likely loss or degradation of some nodes in the network.

4.4.3 Architecture Development

Current architectural guidance and development processes will have to be significantly modified and enhanced to support the development of the NCII. To that end, the committee recommends the following:

Recommendation: The Department of the Navy should work with the ASD (C3I) and the other Services to make the operational and systems architecture products specified in the C4ISR Architecture Framework suitable for the flexible and rapidly evolving information support that the NCII must provide.

The discussion in Section 4.3.2.1 indicates some of the additions and changes to current architecture products that should be made.

Recommendation: The Department of the Navy should ensure that the naval technical architectures are minimal necessary sets of required standards.

Recommendation: The Department of the Navy should support efforts to advance beyond standards-based architectures (such as the current JTA).

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×

More advanced architectural concepts are needed to realize the flexible, rapidly configurable information support envisioned with the NCII. Examples of research in this area are noted above in Section 4.3.2.3. The important point is that senior Navy and DOD officials recognize and support the need for such research.

Recommendation: The Department of the Navy, in developing an NCII architecture, should clarify the architectural responsibilities across the various naval offices currently involved in architecture development.

Responsibilities must be clearly delineated. A suggested assignment of responsibilities is given in Section 4.3.2.4.

Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 140
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 141
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 142
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 143
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 144
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 145
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 146
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 147
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 148
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 149
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 150
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 151
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 152
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 153
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 154
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 155
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 156
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 157
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 158
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 159
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 160
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 161
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 162
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 163
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 164
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 165
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 166
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 167
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 168
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 169
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 170
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 171
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 172
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 173
Suggested Citation:"4 Designing a Common Command and Information Infrastructure." National Research Council. 2000. Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities. Washington, DC: The National Academies Press. doi: 10.17226/9864.
×
Page 174
Next: 5 Information Assurance -- Securing the Naval Command and Information Infrastructure »
Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities Get This Book
×
Buy Paperback | $140.00 Buy Ebook | $109.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

Network-Centric Naval Forces: A Transition Strategy for Enhancing Operational Capabilities is a study to advise the Department of the Navy regarding its transition strategy to achieve a network-centric naval force through technology application. This report discusses the technical underpinnings needed for a transition to networkcentric forces and capabilities.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    Switch between the Original Pages, where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

    « Back Next »
  6. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  7. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  8. ×

    View our suggested citation for this chapter.

    « Back Next »
  9. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!