FORCEnet Implementation Strategy (2005)

Because FORCEnet has no fixed end state but is subject to continual innovation, it is not possible to establish a fixed set of science and technology (S&T) investments required to enable successful implementation of the FnII. Figure 4.2 in Chapter 4 of this report depicts the view of the CFFC,¹ of this innovation process, showing Sea Trial as the center of a process in which warfare challenges lead to new concepts. These concepts drive both materiel and nonmateriel innovations that are tested in Sea Trial, iteratively refined, and, when implemented, lead to new operational capabilities.

In Figure 6.1, the committee places this construct in a larger context. (The processes added by the committee are identified by the shaded boxes and the dotted lines in Figure 6.1.) The chart closes a loop to account for the Network-Centric Operations Capability Vision, including evolving threats and new warfare challenges being affected by capability gaps and indicates that technology gap analysis can motivate science and technology programs that will lead to technology that can help close the gaps in operational capabilities. A path for spiral experimentation has also been added. This path connects the “New Operational Capability” box in Figure 6.1 with the “NCO Capability Vision and Evolving Threats” box. In this way, the new operational capabilities can use spiral experimentation to determine how well they perform with respect to the evolving

FIGURE 6.1 Recommended augmented process for identifying technology gaps in operational capabilities. Adapted from ADM Robert J. Natter, USN, 2003, “Sea Power 21 Series, Part VIII: Sea Trial: Enabler for a Transformed Fleet,” U.S. Naval Institute Proceedings, November, p. 62.

threats indicated by the Director of Naval Intelligence, the intelligence community, and the combatant commanders.

The committee had access to the following material: gap analyses of operational capabilities performed by N704, a translation of these gaps to S&T needs performed by N706,² and parallel but not entirely consistent requirements generations and S&T shortfall lists produced by NETWARCOM and its OAG. The committee also had access to work by ONR identifying critical enabling technologies and to SPAWAR’s Technology Framework for FORCEnet.³ The committee also studied aspirations of the ASD(NII) for the GIG, and made its own assessment of the technical challenges facing naval implementation of FnII while leveraging GIG capabilities (discussed in Chapter 3, Section 3.6) and complying with GIG requirements.

To deal with evolving statements of desired operational capabilities, and recognizing the evolutionary process of FORCEnet implementation, the committee abandoned the attempt to set hard performance goals for FnII technology. Instead, it integrated the ONR taxonomy⁴ and its own analysis of GIG challenges into a list of eight FnII critical technologies (see below). Subsequent sections in this chapter describe the challenges in each, but the establishment of metrics that must be met at a particular date need to await agreement on the operational capabilities desired for that date and for better modeling and simulation tools to accurately assess the effect of FORCEnet performance on the warfare effectiveness of the Navy.

The committee examined several documents, as mentioned, and from those documents it identified eight critical FnII functional capabilities, listed below. These capabilities, used as the organizing basis for discussion in this chapter to highlight potential capability gaps and associated S&T shortfalls, are as follows:

• Reliable wideband mobile communications;

• Information management (including COP);

• Situational awareness and understanding;

• Information assurance;

• Modeling and simulation;

• Dynamic composability and collaboration;

• Support of disadvantaged user-personnel, platform, or sensor; and

• Persistent intelligence, surveillance, and reconnaissance.

In today’s naval forces, communications with moving platforms and personnel are characterized by intermittent connectivity and low data rates. Today, most ships have only satellite capability and achieve data rates of less than 100 kb/s, whereas larger ships, such as carriers, can achieve data rates of multimegabits. Satellite connectivity for small ships is often in the area of 80 percent. The primary limiting factor appears to be antenna blockage, but other possibilities could be electromagnetic interference (EMI) and tracking problems during dynamic maneuvers. Submarines, which must put an antenna on or above the sur-

face, and dismounted troops have more serious data rate and connectivity problems. Operations in the future network-centric environment of FORCEnet (see Figure 6.2) will require much higher data rates (fleet representatives have estimated requirements to be as high as 50 Mb/s per large-deck ship) and more-robust connectivity. Simultaneous connectivity to satellites, sensor nodes, airborne relays, and other ships will drive antenna requirements. Furthermore, maintaining an Internet type (e.g., IP-based) network while nodes and users are moving is a significant technological challenge.

The following subsections discuss key communications technology challenges that must be addressed if FORCEnet is to achieve the vision of full network-centric operations.

Communications Links and Apertures. The difficult shipboard environment for radio-frequency (RF) apertures makes it a high-priority area for future improvement. An example of the antenna layout on a typical ship today is shown in Figure 6.3. The figure illustrates the many trade-offs that need to be considered in planning communications antennas on a ship. The larger the antenna, the greater its throughput, but larger antennas also have larger cross-sections and so their detectability is larger. Also, pointing accuracy and the amount of topside space required increases with the growth in antenna size.

FIGURE 6.2 Notional future FORCEnet nodes and links.

Typical improvements addressed are (1) the sharing of apertures among different functions (radar, communications, and so on) and frequencies and (2) multiple simultaneous (or agile) beams to allow communications with multiple, independent nodes. Operating at higher frequencies (Ka band and above) provides improved performance for a given transmitting and receiving aperture size. This, however, increases the pointing and tracking challenge owing to the reduced beam widths. Optical frequencies should be investigated for communications from UAV relays or satellites to ships in order to provide the increased bandwidth when allowed by the atmospheric environment. While deformable mirrors are potential technology solutions for ameliorating the distortion caused by the atmosphere, serious issues related to atmospheric scattering in the marine environment remain, without clear means of being overcome.

As the Navy moves toward the distributed nature of a network-centric FORCEnet capability, ships will need to be able to track multiple signal nodes simultaneously. An example, taken from the LCS concepts of operations, is shown in Figure 6.4. The need for multiple agile beams indicates a phased array

FIGURE 6.4 Concepts of operations overview for the Littoral Combat Ship and its distributed off-board systems. SOURCE: Navy Warfare Development Command. 2003. Littoral Combat Ship, Concept of Operations Development, Newport, R.I., February.

as one possible solution. Several programs supported by ONR are addressing these antenna issues.

Automated, intelligent management of link characteristics, including beam pointing and tracking, jamming, spectrum usage, and atmospheric environmental effects such as rain attenuation and fading, would be needed to maintain the robustness of link performance. Note that Figure 6.4 points out the need to consider alternatives to satellite relays, such as unmanned air vehicle relays. These alternatives are required because of possible shortages of satellite capacity, owing either to congestion or to adversary action, and to blockages of the line of sight from a shipborne antenna to a satellite.

Network Quality of Service and Resource Management in a Military Context. In today’s commercial Internet, there is little or no capability for allocating QoS among various classes of traffic. The result is that all messages have the same priority, and when there is a heavy demand on the network, all users experience the same degradation. In a military context, high-priority traffic needs to take precedence over low-priority traffic; otherwise a heavy demand of low-priority traffic could preempt the higher-priority information. The transition to IPv6 from IPv4 will provide a tool, but more work will be needed in order to enable reconfiguration of the network infrastructure in response to varying military missions. Monitoring and control of the infrastructure from the network level and down to the link level will be required for enabling response to the time-varying needs. The monitoring and control should be automated to the extent possible, especially when latency is a critical requirement. Although several programs address monitoring and control, the committee finds no comprehensive systems-level effort directed at the total problem.

Automated Networking in a Dynamic, Mobile Environment. The ability of moving personnel and platforms to continuously maintain the data rate and connectivity necessary for the achievement of their assigned missions is a significant technological challenge. The standard protocols used in the commercial Internet work well in the fixed infrastructure, but when the users and, in particular, the nodes and hosts are moving, special protocols are required.

If only the hosts (e.g., users with laptop computers) are moving and the routers are static, the situation is easily handled by the Mobile IP without placing significant burden or design changes on existing routing protocols, such as Open Shortest Path First. A more challenging situation arises when the routers are also moving, as would be expected in a dynamic battlefield situation involving ships, troops, and UAVs. Without new routing protocol designs, the system would lose track of the user locations (i.e., which router they are using), connections would time-out, and connectivity would be lost. This type of network is referred to as a Mobile Ad-Hoc Network (MANET).

The MANET Working Group of the Internet Engineering Task Force has been working on developing standard routing protocols for MANETs. Today,

there are several MANET protocols operating at the IP layer—for example, Ad hoc On-demand Distance Vector (AODV) and Optimized Link State Routing (OLSR)—but they are still classified as experimental. The working group has not come up with a single solution, because it was thought that too many unknowns exist and the solution may be situation-dependent.

Some protocol designs keep constant track of the locations of all users, so that if one wishes to communicate with another, the path is already known. Such solutions, known as proactive (such as OLSR), have high overhead but low latency. Other designs, known as reactive (such as AODV), determine a path only when needed, resulting in lower overhead but higher latency. Also, there is some uncertainty on the scalability of these solutions to hundreds of nodes or more. Although some implementations of MANETs exist and some experiments have been done (e.g., the Army’s FCS program), insufficient information is available today to allow systems engineering trade-offs.

Another challenging problem area arises when some or all of the links of the network are not constantly connected, but suffer dropouts for varying periods of time. With today’s protocol designs, such behavior causes large numbers of repeated transmissions of packets and possible crashing of the network. The Delay-Tolerant Networking (DTN) Research Group (of the Internet Research Task Force) has been addressing this area for some time, but, as is the case with MANET, solutions are immature. The Defense Advanced Research Projects Agency (DARPA) has initiated a new program, Disruption-Tolerant Networking, to address this area.

Overlaying the issues of routing protocols for mobile and disruptive networks is the issue of resistance to adversarial attack—that is, information assurance specific to the network. A robust network must not be susceptible to data corruption, corruption of routing, or saturation of the network with garbage traffic (denial of service). It must also be resistant to traffic analysis (i.e., to revealing who is sending information to whom). Of course the way to protect such information is to encrypt it, but if the headers containing the protocols are encrypted, they must be decrypted at each router if the routers are to take action based on them. Thus, there appears to be a trade-off between security and performance in a dynamic network, especially within the concept of a “black core,” that is, the part of the network with the highest security.

The future FORCEnet will have the characteristics of both MANETs and DTN; emphasis should be placed on continued research in both of these areas. On top of this will be the need for a level of network information assurance. A multidimensional trade-off will be needed between potentially conflicting requirements, with solutions being dependent on the specific missions, architectures, and systems designs. Today there is not enough knowledge of these areas and their interrelationships to be able to do these trade-offs. More modeling and simulation and experiments are needed to explore the solution space. Solutions for one type of mission may be different from those for other types, perhaps

indicating the need for different solutions for different enclaves of users. Perhaps focusing on the LCS program would be a useful place to start.

A considerable number of efforts are ongoing under ONR sponsorship in the area of RF antenna technology. Some work is ongoing in the optical regime, but not enough to really assess its adequacy for the future FORCEnet environment.

The committee is not aware of any efforts to support a comprehensive design of an automated monitoring and control system for FORCEnet links and networks.

The ONR, DARPA, and the Army have a number of efforts supporting MANET; DARPA is initiating an effort on DTN. As yet, these efforts are not sufficiently mature to provide performance results for dynamic networks with specific security requirements under specific missions and scenarios. The National Security Agency is developing a new security protocol, HAIPE, which will help solve some of the security issues previously discussed.

Findings. Currently available technology is not sufficient to support the robust communications infrastructure needed for the long-term FORCEnet network-centric operations vision. In particular, the current technology gaps include the following:

• The capability in link and antenna technologies to provide increased data rates and beam agility;

• Insufficient quality of service and network monitoring, control, and reconfiguration to provide the necessary availability and latency for priority traffic;

• Necessary protocols in standard use to support the mobility, ability to overcome disruption, and information assurance robustness that will be needed in the future FORCEnet;

• Reliable communications technologies to reach underwater vehicles at speed and depth;

• Shared, robust, reliable, multibeam apertures, satellite relay alternatives to support communications on the move, and adaptive networks;

• Reliable high-speed communications, including optical, in the marine layer; and

• Improved antenna aperture technology for use by disadvantaged users: personnel, platforms, and sensors.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Monitor technology availability and, as appropriate, invest to sustain investigations that:

  • Examine the applicability of optical frequencies for high-data-rate communications from satellite or airborne platforms to surface ships. Although the future Transformational Communication System holds promise for achieving as much as 100 Mb/s to ships at Ka band, research into optical communications could provide a hedge against a need for higher data rates in the future.

  • Examine providing automated monitoring and control for FORCEnet links and networks.

  • Explore the solution space for network approaches for FORCEnet mobility, disruption, and security using modeling and simulation and experimental approaches; it should particularly consider applications, such as the Littoral Combat Ship, as points of departure for this effort.

Information management encompasses a spectrum of issues critical to the implementation and effectiveness of FORCEnet. The process of information management includes the generation and manipulation of data or information in support of decision makers. By implication, the process may take different forms, depending on the decision maker’s role or responsibility (e.g., command and control, strike, logistics). The information management process includes all activities related to the collection, accessing, processing, dissemination, and presentation of data or information. The process includes technical means as well as policy, procedural, and doctrinal aspects, with a focus on producing the right information (the content and quality that are needed) at the right time to satisfy mission demands. As implied, information management processes must be adjusted to satisfy specific mission drivers. A high-level summary of the contributing technologies follows:

• Sensor management—enterprise-mediated collection planning to maximize information value from observations of multiple areas and locations of interest by sensors most likely to satisfy mission needs, with appropriate mode, geometry, and timing; adjudication of competing demands for sensing coverage in support of all users in accord with command priorities.

• Sensor processing and data fusion—single and multiple sensor and source fusion to minimize uncertainty; includes temporal alignment, geospatial registration, location, tracking, identification of objects and events, and aggregation into appropriate representation of battlespace objects and events. Such processing is often referred to as Level 1 data fusion processing. In centralized architectures,

Level 1 processes are often applied to sensors and message traffic, reflecting wide area coverage, to form a common operational picture.

• Information services—models, pedigrees, metrics, database services, and so on to support efficient, dynamic management of information.

• Data strategy and information dissemination—consistent mapping of (1) data meaning and significance (classes, properties, relationships) and (2) information content, structure, and latency, to network limitations and technical capability of users.

• User-defined visualization—representation of information in forms appropriate to user roles; decision support to aid human cognition.

In stand-alone (platform-centric) systems, these process issues are assessed and resolved at design time. The technical aspects (e.g., data parameters, processing constraints, and information products) are embedded in the system design and tend to be modified only infrequently over the life of a platform. Typically when new requirements are imposed, needed design updates (or reengineering) are dictated by “interoperability” limitations and prove to be both time-consuming and expensive. Among cooperative platforms, protocols and procedures can be established to assure that information is exchanged within a predetermined structure and used in ways that are appropriate for particular mission goals.

In network-centric operations, the information management process must work across all node components of the network in a fashion that is seamless and adaptive to command direction. This suggests that all nodes must make all their contributing elements of the information management process transparent to network command and control. Further, network environments will be characterized by high volumes of data or information supporting a diverse set of users and mission goals. In such an environment, there is evident need for underlying consistency in the description of information and for automation in the application of tools to enable dynamic and efficient information management. Without such automated tools, the network will become bottlenecked by delays and capacity limitations caused by humans engaged in futile efforts to resolve information conflicts and inconsistencies. This is an issue of information integrity—the requirement that information, as it propagates around the network, be processed and interpreted in ways that are mathematically and logically consistent with source sensing characteristics and intermediate processing updates.

Common problems occurring in today’s battle management environments, which will be dramatically compounded in network-centric environments, are these:

• Trust—lack of metadata about information source, intermediate processing, and quality to inform users;

• Contamination—data corruption due to redundant paths or improper processing (for example, multiple reports of the same target at different locations, or duplicative reports of ambiguous targets causing confusion about actual numbers); and

• Utility—lack of appropriate tools for users to process or exploit received data and information.

GIG-espoused paradigms of TPPU and OHIO carry an implication that a common discipline will be developed and invoked across all network nodes and for all users in order to ensure proper use and interpretation of information. This suggests an “information services” layer to complement the enterprise services defined under the GIG-ES and being developed by DISA in the NCES program. Possible elements of such an information services layer are common enablers, such as these:

• Metrics to qualify the information on some normative scale for consistent and (mathematically) proper usage,

• Pedigrees to identify the source and intermediate processing action (and time) to avoid redundant usage and to support validation and error correction, and

• Models to capture and share knowledge of phenomenology, platforms, sensors, and processes to guide algorithm usage and human interpretation.

The information management issues outlined above deal with the content and quality of the information that flows over the network. The contributing information management technologies identified above are available in varying degrees of maturity, but development is required to make those technologies suitable for network-centric purposes. Similarly, issues associated with defining and implementing information services are receiving scant attention. GIG effort being expended on enterprise core (communications and enterprise services) is not addressing these issues. To achieve the network-centric vision, FORCEnet, in conjunction with other Service activities, will need to develop technology solutions for these information management components and automation, within the communities of interest, in ways that appropriately leverage core enterprise services. Programs that provide an appropriate focus for technology development are being formulated, as in the ONR’s FORCEnet S&T plan for POM-06. Those efforts are geared to COP formation and time-sensitive decision making, with early products available in FY 2008. Greater investment in this area will be needed to realize the information potential of network-centric operations.

Findings. Insufficient information management technology exists for the reliable support of naval warfighting capability—including limited understanding of the information management issues (accessing, processing, dissemination, pre-

sentation) that must be implemented with distributed functionality in network-centric environments. In particular, these current technology gaps include:

• Ontology consistency, to enable automated machine collaboration across communities of interest;

• Information services, to enable management of information content and quality;

• Automated sensor resource management, coupled to dynamic tactical needs and military operational needs;

• Distributed, heterogeneous, real-time Level 1 data fusion;

• User-defined visualization and automation for decision support; and

• Enterprise monitoring and control, to give the user feedback concerning information processes in terms of performance, expected latency, flow, and quality.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Monitor technology availability and, as appropriate, invest to sustain investigations that:

  • Develop technology for distributed real-time processing at heterogeneous fusion;

  • Develop resource allocation driven by current operational situation understanding; and

  • Identify and supplement information services that assure consistent information management processes across the network enterprise.

Automated techniques for achieving situational and threat awareness (often referred to as Level 2 and Level 3 fusion, respectively) are needed to distill the volume of COP-like information expected to become available in network-centric environments for specific user needs. Situational and threat awareness require human reasoning about evidence of battlespace and related activities in order to understand force relationships, interpret activity significance, and anticipate adversary intent. COP-based information is one element of such a reasoning process, but additional contextual information from various subject-matter experts and other knowledge sources is required. Further, machine reasoning about object and events (location, kinematics, identification) in the context of relevant information (e.g., environment, doctrine) is currently infeasible. This is particularly true for battlespace problems of military scale (spatial-temporal dimensions; large numbers of objects, events, activities), and uncertain data. Current capabili-

ties are human-based or very small scale. Available quantitative methods have implicit context and therefore have limited application, particularly in network-centric environments.

As noted above, machine-based capabilities for providing situational or threat awareness are currently not available. Solving this deficiency in automated (or even computationally aided) situational awareness will require machine reasoning capability to aggregate COP-supplied information about the battlespace along with relevant knowledge of adversary forces, to establish relationships among objects, events, and the environment. Such relationships are key to understanding situations (e.g., red force dispositions, blue force vulnerability) and threats (e.g., red force options, path of intended movement).

Contributing technologies deemed necessary for progress in this area include these:

• Inference engines—probabilistic, logical, and so on, for bounded spatial, temporal, abstract properties;

• Knowledge management—knowledge bases, sources, acquisition, authoring, and validation tools, probabilistic and uncertainty representation;

• Large-scale relational and control frameworks;

• Human–machine collaboration—interactive hypothesis management; and

• Cognitive modeling.

Goal capabilities include these:

• Automated consistent understanding of situations,

• Automated consistent understanding of adversary intent and threats,

• Adversary intent analysis,

• Anticipation of possible battlespace futures,

• Data mining,

• Information discovery,

• Automatic (or aided) target recognition,

• Activity pattern recognition, and

• Dynamic “what if” analysis.

Significant advances in S&T will be required to achieve aided, or automated, situational and threat awareness. The technologies deemed relevant are technologically immature, and the commercial resources that might be leveraged have embedded context that is inconsistent with military operations.

Findings. Technology to provide automated situational and threat awareness is currently not available. In particular, these current technology gaps include:

• Contextual reasoning regarding problems having scale and uncertainty of battlespace issues,

• Knowledge bases and tools to capture and represent diverse battlespace expertise,

• Interactive human–machine hypothesis management, and

• Visualization and cognitive interfaces.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Monitor technology availability and, as appropriate, invest to sustain investigations that:

  • Advance inferencing techniques necessary to relate objects and events to their environment and to units, activities, and behaviors,

  • Develop a relational and control framework for managing a broad range of knowledge representations, hypotheses, assertions, and so on,

  • Develop automated techniques for information capture, representation, authoring, and validation, and

  • Integrate human and machine capabilities for hypothesis management—balancing machine capability for handling numerical-scale problems with human ability for intuition.

Information is derived from integrating and interpreting data from multiple sources including sensors as well as software and human agents. Information assurance involves the availability, reliability, security, and trustworthiness of this information. The challenge of quantifying the assurance of information in FORCEnet is particularly challenging, since FORCEnet will be composed of multiple heterogeneous systems, often of independent design and different operational origin.

Information assurance is provided by the communications and the collaboration levels defined in the Technology Architecture for FORCEnet. The communications/network core provides basic transportation for the information as well as having responsibility for ensuring its availability and reliability and for the responsiveness of its delivery. The collaboration level provides for information sharing and must ensure the interoperability of the information sources as well as providing indications of the security and pedigree or trustworthiness of this infor-

mation. The following subsections address information assurance issues with each of these two levels.

Communications/Network Core. While there are mathematical definitions for the long-term availability (i.e., the probability at any instant in time that the resource is usable) and reliability (i.e., the probability that a resource that was usable at time t = 0 is still usable at time t = T), these measures are difficult to apply to complex systems. Often it is difficult to even define when a resource is usable. For example, while we would consider the telephone system unusable if no one could place a call, would the system be considered usable if half of the people could not place a call? What if only one person cannot place a call? Your definition might depend on whether you were that one person. Historically it has been very difficult to even define the conditions that indicate when a complex system is meeting its functionality. This is especially true when the system may be dynamically composed and reconfigured.

The first goal must be to define metrics for the reliability, availability, and robustness of FORCEnet. These metrics must be measurable with reasonable effort and must not require an omnipresent view of the entire system. The measurements will be composed of predeployment as well as operational assessments. Predeployment assessment is often done via benchmarks. Benchmarks are usually self-contained programs that utilize resources in a synthetically derived manner that mimics real application behavior. Benchmarks are composed of a test to stress a FORCEnet property and a built-in evaluation methodology that reports a quantity that is relatable to the property being exercised. Benchmarks are repeatable, allowing comparisons across systems as well as providing a means to measure improvement in a single system.

Benchmarks exist for performance measuring and specific aspects of software robustness testing. Benchmarks are one way to evaluate COTS components as well as to monitor end-to-end communications and network capabilities. The synthetic workloads that often provide the background stress for benchmarks can also be used to inject workload during operational exercises to see how doctrines work when network resources are strained.

As an example of the new generation of benchmarks, consider Ballista. Since COTS and legacy software will be used in FORCEnet to reduce development time and cost, an automated means for their evaluation is required. COTS software is typically tested only for correct functionality, not for graceful handling of exceptions. Yet studies have indicated that more than half of software defects and system failures may be attributed to problems with the handling of exceptions. Even mission-critical legacy software may not be robust to exceptions that were not expected to occur in the original application (this was a primary cause of the loss of the Ariane 5 rocket’s initial flight in June 1996). The Ballista automated

robustness-testing methodology characterizes the exception-handling effectiveness of software modules by making calls with exceptional parameters and monitoring the results.⁵ Ballista only requires the syntactical definition of the call and a list of each call’s argument types. In one study, each of 15 different operating systems’ robustness was measured automatically by testing up to 233 POSIX functions and system calls with exceptional parameter values.⁶ The study identified repeatable ways to crash these commercially available operating systems with a single call, ways to cause task hangs within operating system code, ways to cause task core dumps within operating system code, failures to implement defined POSIX functionality for exceptional conditions, and false indications of successful completion in response to exceptional input parameter values. While one would expect commercial operating systems to be highly robust, any of these behaviors could be fatal to FORCEnet if the error occurred naturally, and especially if this approach were used in a hostile information attack. Overall in this study, only 55 percent to 76 percent of tests performed were handled robustly, depending on the operating system being tested.

Collaboration. The collaboration level provides for sharing of information in a timely manner. The information will be generated on a variety of platforms, each of which may be protected by different security methods. How should the system reflect the security of the origin of the data that went into composing the information? What level of trust can be placed in that information—that is, what is the pedigree of the information? Assessing the trustworthiness of the software systems will pose major challenges. Coalition software will be globally developed in a distributed manner, software agents will move from platform to platform, and software will be upgraded in the field. How will configuration consistency be managed?

Metrics for security and trustworthiness need to be developed. The measures should allow composing values from components into an end-to-end measure that can be appended to information fragments and that not only can be presented in an intuitive way to the user without distracting the user from the primary data, but also that are not overwhelming the user with this auxiliary information. Benchmarks should be developed to evaluate the security and trustworthiness of components and end-to-end systems composed from components. Monitoring techniques need to be developed to automatically detect intrusions and insider threats. Wherever possible, the response to these threats should be automated. On the basis of these data models for systems should be developed that allow predict-

ability of system behavior and allow for balancing between protection and information sharing. A systematic red team activity could help with “testing the testing.”

In those cases in which the theory is insufficiently developed, it may be necessary to depend on human monitoring of FORCEnet. As an example, the Computer Emergency Response Team Coordination Center (CERT/CC) receives vulnerability reports, verifies and analyze the reports, provides technical advice, coordinates responses to security incidents, works with other security experts to identify solutions, identifies trends in intruder activity, analyzes software vulnerabilities, and disseminates information to the community.

CERT/CC operates in a feedback cycle. It analyzes flaws in Internet systems, measures the exploitation of those flaws, assists in remediation, and studies intruder-developed code that exploits the flaws. During analysis, a catalog of artifacts and analysis is built; on the basis of this catalog, a capability is developed to predict trends in malicious code development and functionality. CERT/CC provides 24-hour emergency incident response to threats and attacks on the Internet infrastructure, to widespread automated attacks against Internet sites, and to new types of attacks or vulnerabilities. In 2002, CERT/CC reported 82,094 incidents and 4,131 vulnerabilities and processed 204,697 e-mail messages.⁷

Findings. Inadequate technology exists to provide the necessary level of information assurance to support the FORCEnet vision. The network need for sharing information must be balanced with traditional information assurance roles involved in protecting information. This challenge is made more difficult under conditions requiring trusted information exchange across multiple independent levels of security and among coalition partners. In particular, the current technology gaps include these:

• Metrics, automated network analysis, and monitoring of network reliability and security that are capable of scaling to network-centric needs and to the demands of multilevel security and failure prediction;

• Dynamic balancing of protection levels, including policy adaptation, with sharing needed to maintain mission effectiveness;

• Trustworthiness of software systems and associated information in network-centric operations; and

• The ability to conduct intrusion detection and identify insider threats.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Assess FORCEnet applicability of information assurance technology and, to the degree required, sustain investigations seeking to develop:

  • Improved metrics for information assurance,

  • Automated, real-time, network-centric systems analysis to identify and predict information systems failures, and

  • Improved techniques to achieve multiple levels of information security.

A clear appeal for help with respect to modeling, simulation, and analysis was heard throughout the course of this study. Some of the requests require a technical solution and some require a political or social solution. The subsections below discuss both, so as to not lose the flavor of the requests for help.

With respect to network-centric warfare itself and, in particular, with reference to lessons learned from OIF, it was often mentioned to the committee that at times the Navy had no analysis capability for checking out networks and network-dependent systems before they became operational or for really checking out whether or not network-centric warfare was a real possibility with the available or future network communications infrastructure. Upon further inquiry, the committee found that there were not enough people, either civilian or military, with modeling, simulation, and analysis backgrounds. There was an apparent lack of properly trained simulationists readily available when needed. This personnel shortage was exacerbated by the lack of appropriate modeling and simulation toolsets.

The committee found that there are many modeling and simulation (M&S) tools for fighting the Cold War, red against blue, but there are few available tools for modeling, simulating, and analyzing the types of warfare being pursued now. This is especially true with regard to modeling and simulation of a large-scale, network-centric environment. Accurate modeling and simulation are also needed to support network-centric operations systems engineering and architectures decisions. These large-scale M&S capabilities will be needed to support network-centric operations testing, evaluation, and validation. Few tools really allow “what if” analysis with the asymmetric threat, and none allow modeling, simulation, and analysis of tightly constrained urban environments with guerilla fighters

intermixed with coalition and native populations. The military Services have many old-style Lanchester-equation types of Cold War simulations and few ready-to-go, agent-based simulations that allow such explorations.

The Navy needs to create a career path for modeling, simulation, and analysis in its officer corps similar to the recently created information professional career path. Billets for such expertise need to be created in the fleet so that expertise is readily available and so that modeling, simulation, and analysis become part of its tactical operations. The Navy needs analysts as well as modeling and simulation technologists in the fleet. The modeling and simulation technologists need to help build the modeling and simulation systems required now and in the future. Just deploying analysts will not fill this gap in capability.

The Navy needs to invest in the R&D required to build next-generation combat modeling systems. At the present time, the Navy cannot simulate the types of wars being conducted. The Navy cannot get simulation and analysis done in such a way that it can properly know how to deploy FORCEnet. The Navy does not have the technology in hand, nor is it imminently attainable. A major investment in the broader scope of next-generation modeling, simulation, and analysis is essential to properly understand FORCEnet and its impact on the future of warfare.

Findings. The present state of modeling and simulation does not scale to FORCEnet needs. In particular, the current technology gaps include these:

• Scaling of models and simulations to large numbers of sensors, platforms, and users;

• Systems engineering, including means to check out large-scale network-centric systems prior to deployment (i.e., the ability to model systems life-cycle design and testing and model validation); and

• Robust “what if?” analysis to support trade-offs among network-centric system configurations as a function of mission or threat environment, performance, and reliability.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Sustain investigation in the following areas in coordination with other relevant R&D activities across the DOD, industry, academia, and the commercial sector:

  • Modeling and simulation to support large-scale systems engineering, and

  • Adversarial analysis models and simulations.

FIGURE 6.5 FORCEnet support of dynamic force composition. SOURCE: Space and Naval Warfare Systems Command. 2003. FORCEnet Government Reference Architecture, Version 1.0, April.

Central to the vision of FORCEnet is the ability to “compose” system-like capabilities from components of the enterprise in order to achieve effective warfighting readiness in response to dynamically changing operational situations. The concept of FORCEnet composability is discussed at some length in the FORCEnet Government Reference Architecture (GRA) Vision, Version 1.0.⁸

The notion of composability has a number of implications for warfighting and warfighting systems, as captured in Figure 6.5, taken from the GRA. The figure also illustrates the potential flexibility that FORCEnet enables in supporting adaptation in the following separate domains:

• Technology—by accessing available services to reconfigure technical functions,

• Organizations—adopting new functions to change organizational roles and relationships, and

• Tactics, training, and procedures—assigning new functionality and relationships to adjust processes and procedures to meet new operational challenges.

To achieve the vision of composability, there is a need for information management technology (as discussed earlier) to meet mission goals, along with an enterprise-wide oversight process to assure that aggregated mission goals satisfy campaign outcomes. The former need supports the composition of assigned assets to satisfy individual mission threads. The latter might be viewed as a campaign-level control function for the dynamic balancing of available resources to mission sets, as a function of costs, risks, and expected value. The GRA recognizes this need for layered functionality and control, and includes discussion of the implications of mission-oriented composability.

For mission composability, it is assumed that the architectural framework, open standards, and protocols that accompany enterprise services (and potentially information services) will provide the characterization needed to enable composability. The issue is illustrated in Figure 6.6, from the GRA. The figure shows a variation of the layered functional view discussed earlier, with each layer partitioned into building blocks that may be logically connected in any number of ways to achieve desired mission capabilities.

Composability issues are being further explored in the SPAWAR Systems Center, San Diego’s “Command Center of the Future,” with experimentation addressing composable engineering issues. Under the slogan “Concept to Capability,” the activity is investigating issues relevant to the FORCEnet composable vision and realization of the capability. It is doing so by illustrating the concept potential in an interactive simulation environment, implementing selected components, and identifying benefits (at least qualitatively), along with enabling technologies (middleware and architectural constructs), and decision-support tools. The use of this facility in continuing experimentation provides a useful venue for gaining significant insight into composability issues that are currently not well understood:

• Identification and characterization of needed building blocks,

• Tagging of data, and

• Automated (composition) process management.

The idea of extending this laboratory to be part of a distributed development capability, called FORCEnet Composable Environment, has apparently been discussed as a project of the Virtual SYSCOM program.

FIGURE 6.6 Requirements for “Composable” C4ISR. NOTES: HCI, human–computer; VTC, video teleconference call; API, application program interface; AI, artificial intelligence; OS, operating system. SOURCE: Space and Naval Warfare Systems Command. 2003. FORCEnet Government Reference Architecture, Version 1.0, April.

Incorporating the notion expressed above, of campaign-level control, into these notions of mission composability will be a difficult challenge. Very little work has been done to address the complexity of managing mission composability in a way which assures that integrated, dynamic mission goals will achieve desired campaign outcomes. An aspect of this issue is real-time feedback to decision makers about the state of enterprise readiness. Given the complexity of a FORCEnet enterprise, how does a force commander know that the “composition of the moment” will satisfy planned objectives? A readiness monitor that confirms the state of the enterprise—core plus communities of interest—must be contemplated.

Findings. Today’s technology does not support dynamic composability “on the fly.” A number of essential elements must be addressed to achieve the FORCEnet vision of mission-composable capability while maintaining campaign-level con-

trol, required for the coordination of forces. In particular, the current technology gaps include:

• The complexity of managing mission composability in a way that assures integrated resource allocation to meet dynamic mission goals and achieve desired campaign outcomes;

• A readiness monitor that confirms the state of the entire FORCEnet enterprise (core plus communities of interest, across all enterprise layers) in any given configuration, for all users;

• Manpower and training programs to teach and utilize composed functionality; and

• Tools to support automated means of facilitating collaboration between people and/or machines and to include planning or replanning functions.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR in concert with the CFFC, NETWARCOM, NWDC, and appropriate laboratory organizations: Commit to a long-term, coevolutionary process, which involves laboratory and field experiments, to evolve the required technical components with naval tactics and procedures and personnel implications. Thus, the committee recommends that:

  • ONR sustain investigation of complex resource management (allocation and coordination) issues.

  • ONR sustain investigation of automated collaboration tools necessary to facilitate interactions and problem solving between humans, between machines, and between humans and machines (the effort should also address issues associated with the variable reliability of the naval communications).

Dismounted troops or those in small vehicles must be provided network connectivity and situational awareness. This needed capability places a premium on the power, weight, and size of the electronic system used by the troops. A particularly challenging problem is providing situational awareness to disadvantaged users while not distracting them from carrying out their primary missions.

Batteries have been a particularly serious problem in Operating Enduring Freedom and OIF. Energy densities need to be increased as well as battery lifetime and rechargeability. Fuel cell technology has made promising advances in the area of powering small personal electronics. Nanotechnology may also pro-

vide new approaches to improve energy density—for example, through the application of carbon nanotubes to battery elements.

Reducing the weight and energy consumption of electronics would also have a high payoff. There is no reason why the weight and consumption of receive-only communications equipment should not be able to be reduced substantially. Nanotechnology approaches may have payoff here, as well as in self-generated power. Nanoelectronics could also help reduce overall power consumption by as much as a factor of 10.

Findings. The state of technology to support disadvantaged users (for example, small boats, dismounted marines) is deficient. Depending on operational conditions, unique needs may exist for communications, information representation, and human–machine interfaces. Beyond issues cited in other sections, the current technology gaps include:

• The human–machine interface—today’s handheld displays are difficult to read and distracting, and head gear is bulky and also distracting;

• Custom representation of information to meet difficult operating conditions;

• The size and weight of antenna apertures too large for routine use by disadvantaged (especially dismounted) users; and

• Power sources too heavy and bulky for rapid mobile use by individuals.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR, in coordination with DARPA and the Army: Sustain investigations that seek to provide:

  • Minimum essential situational awareness for dismounted troops by means of technology that is least distracting for the users, and

  • Lightweight, high-density power sources and improvements in power consumption in coordination with DARPA and the Army.

The concept of network-centric operations and its implications for composability require not just access to data from a range of national, theater, and tactical sensors but more complete integration of sensing components into the network framework. For FORCEnet, such integration implies (1) adaptive control (opti-

mization) of ISR operations to satisfy dynamic changes in battlespace priorities and in areas and activities of interest; (2) coordination of sensing functions and geometries with enterprise goals; and (3) robust sensing functionality to provide observations in the appropriate modality over the wide areas of concern, at time rates appropriate to mission functions, and in forms suitable for automated processing and aggregation.

Sensing components in this context refer to the broad set of sensing options ranging from current (or equivalent) sensing capabilities available for national, theater, or tactical operations, to emerging concepts for novel sensing modalities, as well as innovative new concepts for robust distributed and autonomous sensing. In the latter case, studies are being conducted to assess the feasibility and efficacy of large distributed fields of very low cost, self-organizing sensors that are capable of monitoring large areas and of being configured to exfiltrate significant indications and observations to the larger network.

Recognizing that the supply of sensors is unlikely to meet the separate demands for coverage of a multiplicity of users, the network challenge is to manage sensor coverage in a way that best serves command priorities and mission needs. This need to maximize and adjust the value of collected information to the enterprise carries the strong implication that for network-centric operations, the burden of assured sensor coverage—for both offensive and defensive purposes—must shift from a narrowly focused, personnel-intensive, platform-centric perspective to a multimission, multifunction, automated network of sensors capable of providing adaptive coverage for all enterprise users.

Whatever the combination of deployed sensors, the notion of pervasive and persistent ISR implies a network ability to monitor the state of sensing at any given time and to respond dynamically to changing needs in any region of the battlespace volume. Broadly stated, the FORCEnet need for persistent and pervasive ISR includes the following:

• Persistent sensing—refers to the ability to maintain coverage and to update observations at rates suitable to the intelligence, surveillance, reconnaissance, or targeting function required by the mission and driven by the expected target behavior. It is worth emphasizing that observation time and revisit requirements will vary markedly as a function of sensor type, target activity, background conditions, and, most importantly, mission function. Virtual continuous observation is seldom necessary or appropriate for most sensors. Persistence in this sense implies an effective sampling rate that can be adjusted to suit sensor modality, battlespace conditions, and mission needs. This notion of adaptive sensor collec-

tion rhythm to match mission functions suggests that sensing goals might be interleaved in network environments to maximize sensor utility.

• Pervasive sensing—refers to the ability to achieve and maintain observability within the coverage envelope in modalities appropriate to the activity and environment of interest. For difficult targets or background conditions that limit target observability, it is understood that multiple sensors, or new sensing modalities, may be required in order to achieve the required performance in detection, tracking, or identification. It should also be noted that even in circumstances in which the user’s observation needs can be satisfied by a single preferred sensing means, in many cases a combination of sensors, properly deployed and fused, can provide an equivalent answer. This ability of the enterprise to implement alternative satisfaction methods complements the notion, expressed above, of adaptive sensor collection rhythm, and it presents both an opportunity (to reduce the disparity between supply and demand) and a challenge (to perform dynamic reallocation) for network technology.

• Command and control of platforms and sensors to meet dynamic operational and tactical needs—refers to the need in network-centric operations to dynamically reallocate resources in order to meet changes in understanding and priorities of the battlespace situation. In enterprise environments, given constrained resources, a means to continually assess the allocation of resources to organization, mission function, area, activity, and time will be needed.

• Dynamic planning and replanning of sensor modality and coverage—refers to the needs for the automated allocation of sensing resources to tasks and for the automated routing and scheduling of sensor activities, including geometry, time, and mode. In order to be responsive to target behavior, an anticipatory (predictive) strategy will be needed to overcome latencies inherent in replanning and redirection of sensors and platforms. Automation will be essential in order to maintain efficient utilization of sensor assets by the enterprise and to enable coordinated (and often synchronized) use of sensors across the network to achieve desired operational effects.

• Distributed, autonomous sensor networks—has particular relevance to unattended sensors deployed either as autonomous vehicles (e.g., unmanned air or ground vehicles) or distributed in large numbers over large areas or volumes to provide some alerting or monitoring function. In addition to the need for the development of device and packaging technology, such vehicles or distributed fields of sensors will likely require some ability to do the following: self-organize in response to their physical distribution and environment, self-monitor and adapt in response to degradation or loss of sensing elements, and adaptively control processing or communications functionality within predetermined limits in response to detected events or command instructions.

A final comment on the role of humans in persistent and pervasive ISR is appropriate. As suggested above, the implication of network-centric operations is

that a high degree of automation will be required to perform a large number of functions (some relatively low level) now performed by humans (e.g., platform and sensor routing, sensor scheduling, mode control, data tagging, analysis). The dimension envisioned for FORCEnet, together with the requirements for parallel activities, speed of response, and rapid adjudication of needs across multiple nodes and users, suggests that humans will be inappropriate for such roles in a fully evolved network-centric environment. This argument is completely apart from, but consistent with, the trend in current operational and support environments to reduce staffing and subject-matter experts in every area. Humans will need to interact with automated capabilities to provide supervision and confirmation of critical products. The challenge for technology and the coevolutionary process, discussed in Chapter 2, will be to identify the appropriate degree of automation and the appropriate mechanisms to interface automated products with humans in order to achieve human–machine collaboration in network-centric operations.

Findings. For network-centric operations, traditional intelligence, surveillance, and reconnaissance sensing (national and theater, platform-based coverage) will need to be augmented by organic tactical sensors for the responsive coverage of areas that are difficult to monitor, or for which access is denied. In particular, the current technology gaps include these:

• Automation for the coordinated usage of multiple sensors, adaptive sensor control, and more robust sensing modalities;

• Automation to drastically reduce personnel requirements and to reverse the ratio of humans per sensor from a positive number to a fractional number—this will become especially important with the likely proliferation of small sensors for wide-area coverage of difficult areas; and

• Small, networked sensors for wide-area, inexpensive alerting in difficult or denied areas.

Recommendation. Based upon the findings presented above and on the issues described in this section, the committee recommends the following:

• Recommendation for ONR: Monitor technology availability and, as appropriate, invest to sustain investigations in:

  • Networked sensor technology for wide-area alerting of asymmetric targets or activity,

  • Automated sensor management for adjudicating sensing needs across mission goals and for sensing responsiveness to dynamic battlespace needs, and

• Machine-to-machine collaboration for remote operations.

The issues discussed throughout Section 6.3 cover the breadth of technical functionality required to realize a fully functioning FnII capability. The technical challenges to achieving the FORCEnet goal are considerable and will require significant R&D investment and innovation by the naval forces. A summary of the challenges perceived at this time is provided in Table 6.1. The table offers a high-level overview of the most significant S&T issues involved in each of the functional capabilities discussed in this chapter. The table includes a column (“Level of Assessment/Maturity”) that provides the committee’s estimate regarding the degree to which the ONR Future Naval Capabilities (FNC) program (primarily 6.3 (advanced technology development) funding) will address perceived challenges. The challenges cited in Table 6.1 that are properly the focus of 6.1 (basic research) or 6.2 (applied research) effort may be addressed under the ONR’s Discovery and Invention (D&I) program. D&I plans were not available in time for committee consideration.

Table 6.1 serves to emphasize the range and difficulty of the technical challenges facing the development of network-centric capability, along with the varying levels of available technology maturity. Achieving the vision of network-centricity will not be easy.

The GIG initiative is addressing some major S&T issues that must be overcome to ensure its success. GIG activities, directed by OSD, provide significant motivation for transformation of the Services to network-centric operations. While the OSD provides guidance, direction, and some investment to the Army, Navy, Air Force, and joint communities, it is understood that realization of the GIG in support of combat capability depends on developments and experimentation within, and across, each of the Services and agencies.

The Navy should examine all S&T programs that are relevant to the GIG and determine if these programs will provide robust solutions for the Navy. For example, the GIG is working to establish high-bandwidth communications for mobile users, but it may not address all of the problems that need to be solved to ensure successful naval operations. The GIG is operated under the assumption that there will be continuous connectivity, which has major impact on integrated topside RF architectures. The Navy must have mobile, adaptive networks to support ships at sea and disadvantaged users afloat and ashore. There are similar

issues with optical communications in the marine layer for surface ships. Underwater vehicles have very restricted reliable communications, especially at speed and depth. Similarly, disadvantaged user-personnel, platforms, and sensors do not have great flexibility with regard to antenna apertures, and they have need for high-density, low-weight power sources. There are issues with low overhead information assurance for the disadvantaged user. Automated collaborative technologies and automated composability do not work well in an unreliable communications environment.

The Navy also needs a comprehensive, shared situation understanding that includes the identification and tracking of surface and subsurface vehicles. Information management is very important, to ensure that small disadvantaged users and platforms receive the proper information in a timely fashion without causing information overload. All of these issues need to be addressed in the Navy S&T to support FORCEnet.

The ONR’s FY 2006 S&T plan, responding to N70’s statement of FORCEnet gaps, explicitly addresses GIG leveraging in a number of places. Specific plans include research to explore naval-unique concerns in communications, apertures, information management, and decision support (community-of-interest technologies), and information assurance. In the area of enterprise services, ongoing efforts have developed Services Oriented Architecture (SOA) capabilities, which are contributing to the DISA’s Network-Centric Capabilities Pilot Program as well as to the Horizontal Fusion effort of the ASD(NII). Planned efforts will continue to explore issues related to SOA technology and utility. A proposed Advanced Concept Technology Demonstration specifically addresses a near-term enterprise services demonstration enabled via NCES eXtensible Tactical C4I Framework (XTCF) technology.

Participation by naval PEOs includes the contribution of the PEO C4I & Space to DISA’s NCES development and to migration of the GCCS (with its centralized architecture) to Joint Command and Control (with its Services-oriented architecture). The open architecture program of the PEO IWS is participating in the ASD(NII)’s Horizontal Fusion demonstration. Within the systems commands, the Office of the Chief Engineer (SPAWAR 05) has partnered with the Air Force’s Electronic Systems Command to evolve enterprise architecture issues common to FORCEnet and to the Air Force Command and Control Enterprise Reference Architecture. Such coordination will help assure consistency as experience with network-centric operations accumulates.

Science and technology relevant to FORCEnet has been addressed by ONR under its Future Naval Capabilities programs, primarily Knowledge Superiority and Assurance and to some extent under Autonomous Operations and Fleet Force Protection. Enabling capabilities as defined through FY 2004 have addressed areas relevant to network-centric operations. The capabilities addressed include these:

• Common, consistent knowledge;

• Distributed, collaborative planning and execution;

• Enterprise-wide integrated information; and

• Dynamically managed, interoperable, high-capacity connectivity, shared apertures, networking, interoperability.

Products of these efforts to date include:

• XTCF—a framework for network-centric information management for naval and joint forces to operate in a GIG-defined environment; this effort will provide an early instantiation of enterprise services capability for NCES;

• Analytical Support Architecture—a tool for the automated intelligence assessment of enemy air defense;

• Environmental Visualization—fused, interpreted, analyzed environmental information disseminated within less than 1 hour of collection;

• Rapid Maritime Identification and Tracking System—near-real-time biometric data for maritime special operations forces, to improve their ability to find people and take action;

• Multinational Virtual Operations Capability—near-real-time joint force and coalition force exchange of tactical and operational information.

During the course of FY 2004, the ONR program was to be restructured around a new description of enabling capabilities more directly related to warfighting gaps identified by OPNAV. The restructuring of enabling capabilities and the determination of technology content are in progress as this report is being written. For FORCEnet, the organization of the program is expected to be consistent with the MCPs defined by the Naval Transformation Roadmap:⁹ Networks, ISR, and Common Operational and Tactical Picture (COTP), plus essential supporting technology primarily in information assurance.

ONR program content is expected to be driven by the following set of shortfalls, identified by N71:¹⁰

• Vulnerable links,

• Saturated links,

• Insufficient communications and network structure,

• Inadequate network defense in depth,

• Limited coalition interoperability,

• Inadequate sensor strategy,

• Limited undersea picture,

• Lack of common maritime picture, and

• Multiple combat identification and BFT solutions.

Technology issues under consideration within each of these areas are summarized below:

• Networks;

  • Multibeam and multiband apertures;

  • High-data-rate communications on the move—including relay, router, quality of service, and network management issues;

  • Undersea and marine layer communications;

  • ISR;

  • Smart sensor networks;

  • Ship’s missile defense;

  • UAV-borne robust surveillance;

  • COTP;

  • COTP integration and dissemination to all users;

  • Near-real-time fusion of intelligence and tactical data;

  • Spatial-temporal registration of multisensor data (imaging and non-imaging);

  • Intelligent and adaptive sensor management;

  • Automated situational and threat awareness; and

  • User-tailorable information feeds and displays.

• Crosscutting/Leveraging;

  • Information assurance;

  • Real-time, multicombatant command, engagement planning and control; and

  • Real-time deconfliction of targeting information.

The ONR program planning effort addresses the FY 2005 to FY 2011 time frame. Trade-offs involving program priorities, resource allocation, and start or delivery timing have not been resolved as of this writing.

Table 6.2 provides a listing of program issues and capabilities under consideration by ONR’s Knowledge Superiority and Assurance FNC as of the second quarter of FY 2004. This FNC represents the principal, but not sole, investment in FORCEnet development for ONR. The table does not reflect probable Discovery and Invention investment relevant to FORCEnet.

Overall program planning at ONR indicates a strong commitment to the development of relevant network-centric technology, with a broad range of the previously identified shortfalls being addressed. The ONR plans do appear to address a substantial subset of the technologies needed for near-term experimentation with network-centric capability. Given the difficulty of the network-centric

challenge, it is not surprising that differing levels of R&D investment (6.1 to 6.3) are required and that not every issue is being addressed with equal attention.

Evolutionary development implies a phased approach to technology development, and ONR efforts have an implicit phasing supportive of an evolutionary development process. Each phase is modulated by feedback from user experience gained through hands-on experimentation and by refined requirements derived from evolving concepts of operation, tactics, and procedures. Toward this end, ONR has engaged in continuing interaction with the units responsible for requirements (N6/N7) and acquisition (PEOs and systems commands), and with fleet representatives (NETWARCOM, NWDC), to guide its planning activities and to establish success criteria for its technology products. While such a phased approach supported by a coevolutionary or experimentation process has not been made explicit, an informal basis has been established.

ONR program personnel have also been active in maintaining awareness of other Service and agency developments so as to leverage progress and to coordinate experimentation wherever possible. In this regard, interaction with the Air Force Research Laboratory, DARPA, and DISA have been particularly notable.

Beyond the ONR science and technology program, it is understood that technologies relevant to FORCEnet success are being addressed across the spectrum of DOD, industry, and academic activities. General awareness of these activities resides within the committee, and their potential contribution to FORCEnet capability was factored in to the discussion above. No attempt was made to perform a more complete survey and assessment. As indicated above, ONR program officers and their trusted advisers do attempt to plan S&T activities with awareness of the community state of the art, in order to take advantage of emerging technology, to leverage opportunities, and to avoid redundant effort. The committee suggests that the Navy investigate relevant programs discussed by DARPA at the March 2004 DARPAtech Annual Meeting to determine their applicability to solving Navy FORCEnet capability gaps. Also, it is suggested that the Navy should coordinate with the National Coordination Office for Information Technology Research and Development and its recent publication, Grand Challenges: Science, Engineering, and Societal Advances Requiring Networking and Information Technology Research and Development.¹¹

Section 6.2 in this chapter describes science and technology issues associated with achieving FORCEnet. Eight critical FORCEnet functional capabilities are identified, and findings and recommendations are enumerated. Section 6.3.1 addresses the FORCEnet implications of the GIG identifying several key areas that are major S&T issues for the Navy. Section 6.4 addresses the S&T of the ONR program. The committee studied this information and performed a preliminary analysis of findings to determine a recommended priority for the Navy. This analysis included an assessment for each finding of how critical it was for Navy success in executing FORCEnet, whether it was being addressed by others outside the Navy, what potential it had for enhancing performance, and whether it was needed for near-, mid-, or far-term experimentation to assess naval capability.

In addition to the following prioritized recommendations specific to the needs of the various technology areas described, the ONR will also need to reexamine its process for conducting an overall S&T program that matches the needs of network-centric operations. For ONR to consistently identify S&T gaps, there must be a consolidated set of prioritized FORCEnet capability needs. Regarding process, the committee presents the following findings and recommendations.

• Today, the processes for identifying needed operational capabilities are multiple, independent, and uncoordinated.

• There is need for a systematic and vigorous process for identifying enabling technologies to satisfy network-centric functional needs as defined and prioritized by NETWARCOM.

• There is a generally recognized need for naval science and technology activities to avoid duplicative effort by maintaining awareness of DOD, academia, and industry/commercial developments in fields relevant to network-centric operations.

• There is a need to conduct all naval technology developments with consideration for the variable reliability of the naval communications environment in which those technologies will eventually have to perform.

Based upon the findings presented above and on the issues described in this chapter, the committee recommends the following:

• Recommendation for ONR: Develop a consistent FORCEnet technology roadmap and list of S&T shortfall assessments for guiding naval S&T investment strategy on the basis of a consistent set of FORCEnet capabilities that is recognized across the Navy. It is also recommended that ONR develop a technology roadmap that responds to the FnII capabilities and addresses near-, mid- and far-term capabilities. As the ONR develops this FnII technology roadmap and associated program, it should:

  • Perform sensitivity analyses to evaluate alternatives,

  • Provide cost–benefit analyses,

  • Assess commercial off-the-shelf applicability, and

  • Identify opportunities for leveraging and providing incentives for participation by industry, academia, and other Services.

Section 1.3 in Chapter 1 warns that implementing FORCEnet will involve three challenges: an activity of unprecedented scope, an unprecedented need for robustness, and significant difficulties in execution lie ahead. Chapter 4 deals with management and organizational approaches to the scope and execution of FORCEnet, and Chapter 5 addresses engineering approaches. However, the committee finds not only that current technology is inadequate to provide the needed robustness, but also that execution with existing technology may prevent the full realization of FORCEnet’s potential.

Network-centric warfare is appealing if the Navy can build and deploy a robust communications fabric and use it to link sensors, weapons, and decision making over great distances. However, network-centric warfare could be a disaster if the fabric is not robust and the naval units do not maintain the capability to operate with uninterrupted, high-capacity connectivity. Enterprise architectures, such as those that the NCES would provide, create a temptation to depend on remote parts of the enterprise for essential services. This temptation needs to be resisted unless the communications fabric is truly robust. Similarly, the Navy should be sure that the fabric is robust before it sends into harm’s way ships that have limited organic defensive capabilities and must depend on other units on the network to detect, track, and deal with threats.

In planning naval S&T investments, distinctions should be drawn between challenges on which others are working and those for which the Navy must take responsibility. Four examples of the reasons why naval networks are not robust today are these: (1) blockage of antenna beams by superstructure, (2) dependence on single relays and difficulties in routing through alternative relays, (3) susceptibility to denial-of-service attacks, and (4) the lack of extremely high frequency communications satellite capacity.

The first reason is an example of a problem that naval S&T needs to solve. New technology will be needed for affordable multifunction antennas that can command unobstructed sites atop a ship’s superstructure. The second reason is an example of a problem that affects all Services and is receiving attention from all Services, although the Navy may have to plan the acquisition of relay platforms particularly suitable for maritime operations. The third reason is an example of a problem receiving attention from all Services and from the National Security Agency; this problem will require uniform implementation of solutions across the GIG. The fourth reason is a problem for which the Air Force and the National Reconnaissance Office are developing the technology and the Air Force will acquire the satellites, although the Navy may have to program the acquisition of terminals compatible with the new satellites.

In prioritizing naval S&T investments that respond to the robustness challenge, the highest priority should be given to the issues involved in the first

problem, which are unique to the Naval Services. However, this priority attention should not be to the exclusion of investments directed at issues involved in the second and third type, which deserve attention from all Services.

In addition to the critical needs for technology to assure robustness, there are needs for technologies that will permit the full benefits of FORCEnet to be realized. Many of them lie in the area of information management, described in detail in Section 6.2. Although few of these needs are challenges solely to the Naval Services, naval participation in the exploration and implementation of the requisite technologies will help assure that they are appropriate for maritime and littoral operations.

Table 6.3 distinguishes different types of S&T challenges: those that appear essential for the Naval Services in order to realize the promise of FORCEnet and those that would further enhance FORCEnet capabilities. The table further distinguishes the essential challenges for which ONR must shoulder the burden and the challenges that are receiving attention from others. It is important to understand that the most critical requirement is to pursue the technologies that will yield a robust information infrastructure.

Finally, in formulating an investment portfolio, consideration should be given to dates when technologies are needed. Although there is an appropriate desire to achieve quick results and apply them to developmental systems quickly, some technology investments may take time to bear fruit and should be scheduled sufficiently early to mature by the time the technology is needed for incorporation into FORCEnet components.

Based upon the findings presented above and on the issues described in this chapter, the committee recommends the following:

• Recommendation for ONR: Give high priority to technology exploration and prototyping to assure continuous connection of naval units to the GIG, giving the highest priority to those naval-unique challenges that others are unlikely to address, including the following:

  • Continuing to develop prototypes that demonstrate solutions to the antenna blockage problem shipboard, such as wide-band multibeam arrays, and alternative relays;

  • Aggressively seeking technologies that will permit connecting to submarines at speed and depth.

• Recommendation for ONR: After assessing the contributions of DARPA and other Services, give high priority to the remaining issues in these areas:

  • MANET routing over multiple alternate paths,

  • QoS management and monitoring,

• Network protection and recovery,

• Information assurance,

• Connectivity to dismounted units with smaller size and weight antenna apertures, and

• Small, networked sensors for wide-area, inexpensive alerting in difficult denied areas.

• Recommendation for ONR: Give high priority to information management in the naval context in order to permit full exploitation of network-centric enterprise services, increasing its investments in ontologies of naval operations, information services, distributed Level 2 through Level 4 fusion, and user-defined visualization.

• Recommendation for ONR: Invest, as resources permit, in technologies that would further enhance FORCEnet capabilities after due consideration of alternative sources of technology.