CHIPS Articles: Network Warfare Simulation

The Office of the Chief of Naval Operations (OPNAV N61), Navy Modeling and Simulation Management Office (NAVMSMO), has supported Network Warfare Simulation (NETWARS) since its inception. In 1998, the Military Communications-Electronics Board (MCEB) selected NETWARS to be the Department of Defense tool of choice for network communications modeling. The benefit of NETWARS for the Services is that it provides a reusable and interoperable modeling environment to conduct service-specific analysis within a joint framework.

One of the key goals of NETWARS is to combine the communications Modeling and Simulation (M&S) efforts of each of the military Services and establish a common simulation-based assessment and planning architecture that addresses the needs of the Joint Task Force (JTF), as well as the individual Services. To accomplish this objective, the NETWARS program established an Architecture and Standards (A&S) Working Integrated Product Team (WIPT), which is comprised of recognized leaders in communications M&S from each of the Services.

The Space and Naval Warfare Systems Center San Diego (SSC San Diego) is the Navy representative for NETWARS-related efforts, which include A&S WIPT contributions, model development and assessments.

Introduction

The NETWARS program is managed jointly by the Command, Control, Communications, and Computer (C4) Systems Directorate of the Joint Staff (J-6) and the Defense Information Systems Agency (DISA). NETWARS, the network M&S tool, is designed to assess military communications networks. It is used to conduct simulations at the joint task force level, which involve thousands of networked participants with tens of thousands of messages down to the tactical unit level.

The SSC San Diego C4ISR laboratory develops communications models of systems for NETWARS to assess military communications networks and the impact of communications on C4ISR operations. By federating (i.e., combining) NETWARS with other M&S tools we can leverage each tool's strengths. We initiated an effort to integrate the force-on-force M&S tool, Naval Simulation System (NSS), with NETWARS to create a NETWARS-NSS federation.

NETWARS Architecture

NETWARS is a discrete event simulator developed using the Optimized Network Engineering Tool (OPNET) Development Kit (ODK). It is designed to analyze military communications networks through the use of reusable communications device models (CDM), military doctrine and network traffic information in the joint arena. NETWARS consists of five functional elements, which are: (1) Database libraries; (2) Scenario Builder; (3) Capacity Planner; (4) Simulation Domain; and (5) Results Analyzer.

Database Libraries

NETWARS makes use of four primary databases: (1) Communications Device Model Library; (2) Operations Facilities (OPFACs) Library; (3) Organization Library; and (4) Information Exchange Requirement (IER) Library. The simulator uses these libraries to obtain detailed information about the communications systems used during the analysis. The CDM library contains the fundamental building blocks used in NETWARS, and the models that have been developed by the Services to represent the protocols and functionality that are found in physical devices.

Examples of Navy CDMs include radios, patch panels, multiplexers and tactical communications data links. The OPFAC Library is used to represent logical collections of CDMs, such as a tank or a Naval Operations Center (NOC). The Organization Library is built from one or more OPFACs that are connected with various communications links. These include point-to-point, wireless and broadcast links. Information Exchange Requirement Libraries are used to provide the simulation with details about the traffic, such as the type (voice, video or data), the source and destination of the message, its size, and the frequency with which the message is sent.

Scenario Builder

The Scenario builder defines how the OPFACs, Organizations, links and IERs will be used during the simulation. OPFACs and Organizations can be developed, and links can be assigned. Mobility can be given to organizations to represent the real-time movement of units throughout the course of the simulation. IERs are associated with devices, and message attributes are defined here. Periods of failure and recovery of OPFACs are also specified within the Scenario Builder.

Capacity Planner

The Capacity Planner evaluates and optimizes network link capacities. The Capacity Planner evaluates a given scenario to determine the configured network's average utilization, hop count and capacity. It can also optimize a network by using a simulated annealing algorithm that mutates the current solution to create new solutions for choosing an optimum solution. It can determine optimum link capacities and utilizations.

Simulation Domain

The Simulation Domain consists of the Simulation Engine (OPNET Modeler) and a Simulation Conversion Module. The Simulation Conversion Module translates the organizational representation and data flows into discrete events between the sender and receiver of specific communications equipment representations understood by the Simulation Engine.

Results Analyzer

The Results Analyzer allows an analyst to examine the Measures of Performance (MOPs) that are collected during a simulation. These MOPs are grouped into six categories: MOPs for a destination OPFAC; MOPs for a source OPFAC; global MOPs; device-level MOPs; MOPs for inter-OPFAC links; and MOPs for broadcast radio networks.

Model Interoperability Benefifits

The Defense Department employs a wide variety of communication systems and technologies. These include commercial-off-the-shelf (COTS) technologies, such as IP-based devices and government-off-the-shelf (GOTS) technologies, such as Link-16. Each Service acquires different technology families to meet varying mission requirements of the warfighter. NETWARS provides a communications simulation environment that supports assessments of all these technologies. Rather than invest in the development of a communications model library that represents all of the existing and planned communications assets that would be required to support a Joint Task Force, NETWARS leverages a significant amount of model development resources from Service acquisition programs and simulation efforts.

Models may be added to the NETWARS library, for example, models may be high or low fidelity. All of these different model types may be valid for their original intended use; however, the challenge of promoting interoperability among these models is significant. A common approach for promoting interoperability among disparate models is to develop sets of architecture standards that provide a common model design and development approach for model construction. Standards may apply to different model characteristics such as interfaces, attributes, fidelity and documentation.

NETWARS implements several model development standards and guidelines to promote interoperability among contributed models. However, NETWARS avoids the overuse of standards, which is a common pitfall when using this approach. By establishing too many model development standards, the development environment may become too restrictive and inhibit or even preclude the development of certain types of models.

Development Guidance and Architectures

The primary resource for model development guidance and architectures is the NETWARS Model Development Guide (MDG). Model developers and contributors use these architectures to classify models into common categories. Models within the same category use similar sets of construction architectures, guidelines and requirements that ensure a high level of interoperability for simulations. The model categorization approach may also be used for converting existing OPNET models into a NETWARS-compatible format. Recently we began to contribute many of these models, including Link-11, Link-16 and the Automated Digital Network System (ADNS) into the NETWARS library. Two NETWARS model categorization architectures are provided within the MDG. The first architecture defines a model construction hierarchy. A Navy example of his hierarchy is illustrated in Figure 1.

An example of the use of the Organization model is our modeling of the Network Operations Center that is currently being developed at SSC San Diego. There are four NOCs worldwide; however each NOC has differences. The Pacific Region NOC (PRNOC in Wahiawa, Hawaii) was considered the most generic of the four; so it was used as the template Organization. The template NOC Organization includes three Organizations: the SIPRNET, NIPRNET and ADNS enclaves.

Within each of the three enclaves are several OPFACs representing different network devices such as routers, switches, computers and multiplexers. Several of these OPFACs were created using OPNET model device libraries and had to be slightly modified to fulfill the requirements delineated in the NETWARS MDG. Modifying the template enabled the construction of three other NOCs: the Unified Atlantic Region NOC (UARNOC), the Indian Ocean Region NOC (IORNOC) and the Europe Central Region NOC (ECRNOC).

Another NETWARS model categorization architecture exists at the device model level (within the model construction hierarchy). NETWARS created the device model categorization architecture to provide developers with specific requirements and guidelines for each category of device models. By specifying guidelines and requirements at this level, interoperability can be ensured among new and existing device models of the same category. Device model categories were selected to emulate real-world communications equipment. For example, layer 3 network device models represent real-world layer 3 devices, such as Internet Protocol (IP) routers.

NETWARS also provides many model construction guidelines. These guidelines are not requirements, but promote a common, software development process. The NETWARS model development process is a valuable resource; it provides example code segments that may be reused by developers, and emphasizes model Verification and Validation (V&V) and documentation practices.

Core Component Model Standardization

In a contributed model environment such as NETWARS, a critical interoperability issue is dealing with multiple versions of the same model. For example, the Navy may contribute one variant of an IP model while the Army may contribute another. While most device models that implement the same protocol process models interoperate, device models that include different implementations of the same protocol model rarely interoperate and often may not coexist within the same simulation.

In cases where models are contained within isolated, standalone networks, this is not much of a concern. However in joint, connected Wide Area Network (WAN) systems that implement a variety of commercial communications protocols, this presents an interoperability issue. NETWARS addresses this issue by standardizing on a relatively smaller set of models within its library. This standard set of models includes technologies and protocols such as IP, Ethernet and ATM.

Any device model in NETWARS that implements a model of these technologies or protocols must be constructed using the corresponding NETWARS standard process model. NETWARS only standardizes on robust, high-fidelity, multifunctional models. In general, standard models are based on OPNET models, which have been thoroughly validated by OPNET technologies and employed for several years by the worldwide OPNET user community.

In addition to providing a common approach to the specification of scenario input data, NETWARS also addressed simulation outputs or statistics in a similar fashion. Simulation studies have the ability to examine a wide variety of output statistics. These statistics can be very system-specific, such as a Link-11 net cycle time. However, many communication simulation statistics are similar. These include end-to-end statistics such as message delivery latency and loss performance. To promote the highest level of model and results interoperability, NETWARS defined a core set of simulation output statistics, or Measures of Performance (MOPs), which are often examined in communication system assessments.

NETWARS-NSS Integration

The Naval Simulation System is an object-oriented Monte Carlo, discrete-event modeling and simulation tool originally developed by SPAWAR PD 15 and Metron, Inc., for the Chief of Naval Operations (CNO) N6M. NSS is designed to support operational commanders in developing and analyzing operational courses of action at the mission, group and force levels.

NSS has been used for Naval operations support including plan development, evaluation, refinement and execution. It is a well-known analysis tool for understanding the capabilities, performance and interactions of forces and C4ISR systems in combat. NSS has been deployed in numerous Navy exercises, including fleet exercises, fleet battle experiments and wargames, including the Navy Global Wargame.

To support multi-warfare scenarios, NSS offers low-to-medium fidelity warfare entity models. Communication systems in NSS are not well developed. Its low-resolution communications models (assured and unassured communications) and mediumresolution models (routed communications) are generically applicable to a variety of operational systems. At the high-resolution level, NSS provides three system-specific communications models, Link-11, Link-16 and TRAP/TRE (TRE Related Applications Program/Tactical Receive Equipment). These three highresolution models are based on 1994 composite warfare model implementations.

NETWARS does not possess any operational support and warfare analysis capabilities, but users can implement new or leverage existing, system-specific communications models of required fidelity. The logical objective is to incorporate the highly developed communications modeling capability of NETWARS into NSS, which is well recognized for its force-on-force engagement simulation and analysis capabilities. To support this objective, we must provide the functionality necessary to allow entities in the NSS simulation domain to interact with entities in the NETWARS simulation domain. The approach we have taken is to federate NSS with NETWARS using a High-Level Architecture Run-Time Infrastructure.

Integration Overview

Figure 2 illustrates the NETWARS-NSS interoperability process. A message originating from a ship to an aircraft is intercepted by the RTI (step 1). The message is transmitted through the RTI to NETWARS. In NETWARS the message transmission is modeled (step 2), and upon receipt of the message, the transmission characteristics are reported to NSS via the RTI (step 3). Finally, in NSS the message arrives at the aircraft (step 4).

The Georgia Institute of Technology Federated-Simulation Development Kit (FDK) is used as the glue to facilitate the movement of information between NSS and NETWARS. The FDK contains a high performance High Level Architecture Run-Time Infrastructure (HLA-RTI), called Detailed RTI (DRTI), which provides the functionality needed for creating federations.

Two main features of the integration architecture are the extension of the Pegasus Federation Object Model (FOM), and the DRTI NETWARS Plug-in. First, since the NSS simulator can use HLA-RTI directly and supports the Pegasus FOM, the most logical approach to facilitate the NETWARS-NSS integration is to extend the Pegasus FOM to include additional interactions between NSS and NETWARS. The extension consists of a pair of interactions: Combat_Transmission_Request to notify NETWARS when to send a message and Combat_Transmission_Receipt to return to NSS the status of the message transmission, and the delay when the transmission is successful.

Secondly, since the NETWARS does not directly utilize RTI services, middleware software is needed to enable a NETWARS simulation to interact with an NSS simulation. The functionality of the DRTI NETWARS Plug-in is divided into three components: (1) DRTI Process Model and Model Modifications; (2) DRTI NETWARS ESA (External Simulation Access) Support Module; and (3) DRTI Management Module. Each component or layer has a specific set of tasks to shuttle information between the NSS domain, the RTI and NETWARS. The DRTI Process Model provides the functionality to directly interact with entities within the NETWARS domain. The DRTI NETWARS ESA Support Module uses OPNET's ESA interface to create a bridge between the DRTI Process Model and the DRTI Manager. The DRTI Manager Module handles initialization of the RTI and all updates and interactions delivered by DRTI. Figure 3 shows the relationship of these components.

Technical Issues and Lessons Learned

There were several technical issues and lessons learned during the course of our study. The following describes two major issues: lookahead and model fidelity.

Lookahead

By definition, if a federate (i.e., member of a federation) has a lookahead L, then it will generate messages at least L time units after the current time. Consequently, events can be safely scheduled at least L time units prior to when they actually occur. In reality, IER interactions are zero-lookahead events. When NSS wishes to fire an IER at time x, the IER must be fi red in NETWARS at time x. With zero lookahead, performance is expected to be poor, essentially turning a distributed simulation into a sequential simulation. To overcome the poor performance an artificial lookahead is added to IER interactions (Combat_Transmission_Request and Combat_Transmission_Receipt interactions) between simulators. We are exploring what are good lookahead values with respect to performance, and the impact this artificial lookahead has on MOPs.

Model Fidelity

In the initial NETWARS-NSS federation, the NETWARS Joint Tactical Information Distribution System (JTIDS) was identified as the major contributor to the slow federation runtimes. Further investigation of this model revealed that it explicitly simulated very detailed JTIDS transmission functions, thus contributing to its slow runtime performance. This high-fidelity model was developed to investigate prototype JTIDS slot access schemes and slot-sharing algorithms. For use in the NETWARS-NSS federation, the JTIDS model was modified to increase simulation runtime performance. This reinforces the notion that simulation runtime remains a key obstacle when modeling communications performance at very high levels of fidelity.