[ieee milcom 2008 - 2008 ieee military communications conference (milcom) - san diego, ca, usa...

OPNET and OPNET product names are registered trademarks of OPNET Technologies, Inc.

1 of 7

HIGH-FIDELITY MODELING AND SCALABLE SIMULATION FOR TACTICAL NETWORK

DESIGN

David A. Covington Marcus D. Hanson DISA and OPNET Technologies, Inc. Falls Church, VA Bethesda, MD

ABSTRACT

Tactical networks such as MANETs are designed for rugged battlefield environments, which pose unique challenges to their reliability and performance. To plan for these challenges defense agencies need to realistically model and simulate network deployments. The accuracy of the network model impacts the success of the underlying mission. OPNET® solutions couple high-fidelity protocol, technology, and equipment models with a scalable environment capable of simulating wired or wireless military networks of realistic scale. Joint Communication Simulation System (JCSS; formerly NETWARS) is a software solution based on the OPNET simulation environment. It is the Joint Chiefs of Staff standard for modeling and simulation of military communication systems. The JCSS solution is widely used by defense agencies to test the performance of military tactical edge networks with various backbone technologies and other initiatives. This paper outlines the key use cases of the JCSS solution and underscores the importance of high-fidelity network modeling and simulation in the tactical network arena.

INTRODUCTION OPNET Technologies, Inc. is the world's leading provider of network modeling and simulation software. Defense organizations and systems integrators use OPNET’s Network R&D solutions to accelerate the R&D of network protocols, devices, and architectures crucial to network-centric operations and warfare implementations including MANET protocol development, JTRS/Bowman radio design, and WIN-T/FCS architecture studies. Defense network planners and architects can analyze end-to-end behavior, tune network performance, and develop custom protocols to optimally support the warfighter. JCSS (formerly NETWARS) is the Joint Chiefs of Staff standard for modeling military communication systems.

It is a desktop software application that provides modeling and simulation capabilities for measuring and assessing the information flow through the strategic, operational, and tactical military communications networks. JCSS is now managed by the Defense Systems Information Agency (DISA). The JCSS program was developed to provide an integrated ability to analyze and simulate communication networks with databases and underlying models so that studies can be consistent throughout the Unified Combatant Commands, Services, and other divisions within the Command, Control, Communications, and Computer Systems (C4) community. Results from JCSS simulations and analyses also provide support for prudent acquisition decisions. The JCSS software is developed by OPNET and is based on the OPNET simulation environment. Included with JCSS is a model library which supports a robust set of military communication protocols, devices, and network architectures. These include satellite, radio, voice, VoIP, encryption, multiplexer, circuit switch, circuit emulation, and Performance Enhancing Proxy (PEP). Off-the-shelf models include EPLRS, Link 16, SINCGARS, Promina multiplexers, KG series encryption devices, and AN/TSC devices. JCSS also contains the OPNET standard library of models which include protocol models (TCP, UDP, IP, etc.), vendor device models (routers, switches, etc.), links, and demands. Using this set of models, JCSS allows users to conduct detailed assessments of network and application performance using Discrete Event Simulation (DES) technology. This technology is based on OPNET’s IT Guru® solution. Discrete event simulations simulate all the events associated with a scenario within a user defined time period. The events occurring within the scenario are based on models which use finite-state machines to emulate protocols, devices, links, etc. This enables users to perform very realistic and accurate network studies.

978-1-4244-2677-5/08/$25.00 ©2008 IEEE


2 of 7

JCSS also provides analytical capabilities to evaluate and optimize network performance for a given scenario through its capacity planning capabilities. The Capacity Planning Tool provides a relatively quick-turnaround analytical support to combatant command (COCOM) or service component communications planners who must compare their mission planning documents and information requirements plans against the existing operational environment to identify shortfalls in information support. We will now discuss some terminology associated with JCSS simulations which are essential for a better understanding of the study being addressed. Realistically, the idea behind JCSS is to allow users to easily be able to deploy and study networks in military situations where a communications expert may not always be available. To make this process easier and defense specific, the user should think of the network in military terms. JCSS provides emulates battlefield communications through the use of Organizations, Operational Facilities (OPFACs), and Information Exchange Requirements (IERs). At the highest level, Organizations can be looked at as military organizations (such as DISA, a division, etc.) which are made up of a number of assets. These assets would include common military buildings, vehicles, and communications devices and are modeled using standard OPNET subnets. Organizations are then made up of a number of Operational Facilities, which can be thought of as the assets for the Organization (i.e., buildings, tanks, planes, soldiers, etc.). The OPFACs then hold all of the communication devices which make up that asset. Leveraging this hierarchy, the user determines the capabilities of a particular asset and deploys the necessary equipment. From that point on the user can share the created network topology with other non-technical users who are used to the higher level Organizations and OPFACs. This facilitates the planning and acquisitions processes.

Figure 1: An Example Network in JCSS

The user can then deploy various forms of traffic to interact with these devices through the use of IERs. IERs allow the user to define information about traffic messages (such as interarrival time, classification, start time, end time, size, perishability, etc.) which traverse from a producer OPFAC to a consumer OPFAC. The important concept of IERs is that they allow the user to deploy traffic at a high level (i.e., between a tank and a plane) without having to fully understand the underlying communication devices inside the OFPAC. The user only needs to define that a message of a certain size needs to be delivered at a certain time between two assets. JCSS will automatically pick a device in the OPFAC to realistically route the traffic. This traffic allows the user to speak in military terms. For example, an “attack” command can be realistically modeled as a message going from the command center to the plane. Using the above methodologies, the user can develop a standard workflow to perform studies. The recommended JCSS workflow will be described below using an example study to help support its validity.

NETWORK CREATION Typically, the most important portion of the workflow involves figuring out what needs to be studied and how it needs to be studied. As JCSS is a robust tool, many different network centric questions can be asked and answered. These include “what if” questions such as: what will happen if I add this technology, device, or


3 of 7

link? Or what if this link or interface fails? Other questions involve network performance studies such as delay or utilization. Further questions can include resource allocation, node placement, traffic questions, throughput, and “busiest hour” studies. During July 2007, the Marine Corps Systems Command (MCSC) Modeling and Simulation (M&S) team worked with the Marine Air Ground Task Force Command and Control (MAGTF C2) Transmission team to develop a model in JCSS. The primary objectives of the MAGTF C2 performance analysis using JCSS were to develop a baseline model of a generic Marine Expeditionary Force (MEF) and to determine the impact of the C2 functional areas on currently deployed tactical data networks. To accomplish the tasks of this study (and other studies), the user needs to simulate the network in JCSS. This network can either be experimental (not existing) or a real-world network. To create the network, a user can manually deploy devices through the device palette or import configurations and traffic from real-world devices. This allows the user to have an extremely detailed and accurate model which they can then use for studies. In the case of MAGTF, the main methods of deployment were manually deploying radio models specifically for the study. The MEF model was constructed using Marine Corps Architecture Support Environment as the authoritative source. The MAGTF C2 architecture, in JCSS, was designed considering presently deployed MEF technologies. Using Organizations and OPFAC templates, the MEF and JTF headquarters were connected via a Standardized Tactical Entry Point (STEP) site, which provided connectivity to supporting elements via the Defense Information Systems Network (DISN). The MEF organization used in this study consists of five sub-organizations (OPFACs), which represented the Major Subordinate Commands (MSC), the Command Element (CE), Ground Combat Element (GCE), Air Combat Element (ACE), and Combat Logistic Element (CLE). These OPFACs were then configured with a full mesh network using AN/TRC-170 radios, with an aggregate bandwidth of 4096 Kilo bits per second (Kbps). Using C/C++ coding, the packaged JCSS AN/TRC-170 model was customized to provide a more detailed base model.

Figure 2: Example Operational Facility (OPFAC)

TRAFFIC CREATION

Once the major network topology has been deployed, the necessary traffic can be deployed on top of the scenario. Traffic used in this study was developed using a combination of IERs, standard applications, and ACE® Whiteboard features. OPNET standard applications and ACE Whiteboard allow the user to create customized client-server traffic that can be studied. Messages will be sent to emulate certain types of traffic such as FTP, email, voice, videoconferencing, and customized traffic. The major advantage of these types of traffic is that they provide detailed protocol level messaging and statistics “out-of-the-box.” The MAGTF study utilized the JCSS specific traffic types to model several different military messages including a Common Operation Picture to provide the commander with Situational Awareness (SA) through the use of IERs. Also, the use of Video Teleconferencing (VTC), Voice over Internet Protocol (VoIP) and Chat were deployed using standard OPNET application models. This traffic was created to perform collaborative traffic planning studies. Finally, the development of the Blue Force Tracking (BFT) Information Exchange Requirements (IERs) was performed as part of this study. The information gathered on the BFT traffic in JCSS was then used as the authoritative source of information. In reality, networks must support several applications simultaneously, not just the particular applications being studied or explicitly modeled. How these applications


4 of 7

perform on a given network can be, and in most cases is, quite different when they have to contend for limited network resources. Using the JCSS background utilization feature allowed MAGTF C2 to realistically account for applications that should be linked to real world data captured during an exercise or operation. In this case, that information was not available, so non-MAGTF C2 traffic was accounted for by parametrically loading critical links at 20%, 30%, 40%, and 50%. This extra load can further allow the study to take into account “what if” scenarios.

STATISTICS COLLECTION Once the network topology and traffic are laid out, the user needs to correlate the study questions with the simulated network. To do this, JCSS allows for several different types of statistics including standard and custom statistics which can be used to answer questions. In the study, JCSS allowed MAGTF to configure the statistics collection mechanism utilizing its robust library of global, node, and link statistics. Based on the assessment objectives and the associated scenarios, a custom set of statistics were collected for each simulation. The following statistics were collected for the MAGTF C2 applications: link throughput, application throughput (sent and received), application response time, VTC end-to-end delay, and VoIP jitter.

SCENARIO DEVELOPMENT Once the network has been developed, the traffic deployed, and the statistics collected, different scenarios should be created to emulate all of the different situations the network will experience. Typical situations include failure of nodes/links, addition/removal of new devices/links, and extra traffic load on the network. Scenarios developed for this study were categorized as either baseline scenarios or MAGTF C2 scenarios. While both answer the study questions, the baseline scenarios focus only on ensuring that the applications (e.g., COP and VTC) functioned properly. The MAGTF C2 scenarios were focused on answering specific study questions. In addition, the simulations were set to last only one hour meaning that the traffic definitions were manipulated during the one hour period. The baseline scenarios assumed each application was on its own in the network, not needing to contend with

other applications for network resources. The purpose of these scenarios was to make sure each application performed as expected. The Common Operating Picture (COP) scenario applied traffic to an operational scenario. In this case, the COP IERs began firing immediately and continued throughout the entire hour. The inter-arrival time was set to 30 seconds; meaning the IER fired every 30 seconds. The source OPFAC for the COP IERS was the TOP COP, located at the JTF headquarters. The JTF headquarters had a satellite connection to provide connectivity to other MEF Command Element. The destination OPFACs were the C2PC terminals located inside the MSC Combat Operation Centers (COC). See figure 3 below for a graphic representation of the traffic.

Figure 3: MAGTF COP Traffic

The Blue Force Tracker (BFT) scenario applied the traffic to an operational scenario. BFT IERs began firing immediately and continued throughout the entire hour. The inter-arrival time was also set to 30 seconds; meaning the IER fired every 30 seconds. The number of artificial “users” for this traffic was varied to increase the effect of this traffic on the scenario. See figure 4 below for a graphical representation of the traffic.


5 of 7

Figure 4: MAGTF BFT Traffic

The Collaborative Service scenario applied the traffic to an operational scenario, which was deployed only between the GCE and CE. All three applications were deployed as soon as the simulation began. However, each was assigned a different behavior: the VTC lasted only 30 minutes, the VoIP conversations lasted only five minutes, however they repeated every five minutes for the entire hour. Also, a JCSS LAN model was used to represent the VoIP users and the number of users was set to ten. This enabled the device model to represent ten VoIP users. The chat conversations lasted only five minutes, however they repeated every five minutes for the entire hour. Also, a JCSS LAN model was used to represent the chat users and the number of users was also set to ten. This enabled the device model to represent ten chat users. See figure 5 below for a graphic representation of this traffic.

Figure 5: MAGTF Collaborative Service Traffic

In the MAGTF C2 scenarios all of the applications were run simultaneously, meaning the applications had to compete for the limited network resources. The purpose of these scenarios was to provide insight into how the defined applications affected each other. Additionally, by loading the critical links, the model provided insight into how all the other (non MAGTF C2) applications may affect MAGTF C2 applications.

RESULTS AND ANALYSIS JCSS supports two simulation technologies: Capacity Planner (CP) and Discrete Event Simulation (DES). These were discussed earlier in the paper. Typically, when performing large studies, it is preferred that the user first use Capacity Planner and then move on to Discrete Event Simulation. The reason for this is that CP provides lesser detail than DES but can run much more quickly. It provides the user with several useful statistics including whether all Layer 2 circuits are deployed correctly, whether the traffic was successful, and what was the utilization on various links. The important point here is that the user can use Capacity Planner to perform a quick sanity check on the network. Initial problems such as incorrect configuration or setup and traffic bottlenecks can easily be seen in the web report created by CP. This is much more effective then investing a large amount of time in the more detailed DES run and then later finding the same problems. Once the network has been validated in CP, then the user should use DES to find out the detailed statistics of the study.


6 of 7

Once the simulations have been run, the users can then use the web reports from CP or the vector files from DES to find results. JCSS also has other built-in reports including equipment list reports, IP reports, traffic reports, and scenario briefings. In the MAGTF study, several interesting trends were found using the Discrete Event Simulation (DES) vector files and graphs. The COP IER latency peaked at approximately 145 seconds while the VoIP calls and VTC were executing. Even after the VTC session ended, the COP IER latency was never less than 30 seconds except in the baseline scenario. Because the interarrival time of the IERs was less than 30 seconds, this means the TOP COP application was sending the next IER before its predecessor reached its destination. This is an indication that the architecture could not support all of the defined traffic simultaneously, even without background loading. As this load is a realistic scenario inside the network, changes will need to be made to ensure that this type of traffic can be sustained. This could include revisiting the application itself or making changes to the network. Further JCSS scenarios can be used to answer these “what if” questions. The baseline BFT scenario results also indicated the network was having trouble with passing the BFT IERs. This was primarily due to the collaboration services in the network. For example, figure 6 below shows that only one traffic instance succeeded in this scenario. In a network with heavy load, many of the traffic instances should have at least some packet delay or loss. The graph shown indicates that all traffic but the collaboration services had little or no delay. This type of information shows the user a few things: (i) the packets of several traffic instances are not reaching the destination devices; (ii) the collaborative services traffic is dominating the network even though all of the traffic instances started around the same period of time; and (iii) the collaborative services are imposing a delay on themselves by over-utilizing the network. Again, as these demands are typical of the network, the user will want to re-evaluate the traffic and network. Some of the questions that should be asked include: Which collaborative services are causing the most stress to the network? What transport protocols does this traffic use (TCP or UDP)? Is the TCP back-off functionality being deployed, causing the other traffic instances to fail? JCSS provides the statistics to further examine these questions in additional scenarios.

Figure 6: Example BFT Traffic Statistics

The VTC average end-to-end delay variation (jitter) gradually increased and response times decreased starting with the baseline scenarios. In particular, the maximum latency experienced was 73.16 seconds (as seen in Figure 7 below), which happened while the VoIP calls and VTC services were being provided (Collaborative Services). These results were able to show again that the collaborative services caused the problem. The demand of the VoIP and VTC services on the network obviously has impacted several applications in the network. This is to be expected as VoIP and VTC typically require large amounts of bandwidth on networks. Jitter statistics in the network also show the same trends and were used to validate the latency values. Jitter reached unacceptable levels of 810 ms while both the VoIP and VTC services were being provided. This is much higher than the acceptable 30 ms needed for the UDP based applications.

Figure 7: VTC Response Time Statistics


7 of 7

Chat messages also suffered while the VTC and VoIP traffic was flowing. The average delivery time for these messages peaked at approximately 200 seconds during the 40 and 50 percent background utilization scenarios. After the VTC ended (at 30 minutes) the chat end-to-end delay began to decrease, reaching a minimum of 126.86 seconds during the scenario with no background utilization (only the baseline scenario was lower). This shows consistently that the chat traffic success is dependent upon the VTC and VoIP traffic which again usually requires large amounts of bandwidth. Figure 8 below shows the response time for the chat messages.

Figure 8: Chat Message Response Time Statistics

Essentially, the simulations indicate there is not enough available bandwidth to support the MAGTF C2 applications as defined. Individually (during the baseline scenarios) the applications operated within parameters. However, when the traffic was combined in a single scenario where they had to compete for network resources, many of the traffic instances failed. For example, while the COP IERs consumed less than 8% of the available bandwidth, their performance was severely impacted by the collaborative services and BFT IERs. As shown by the multiple traffic types and scenarios, special care must be taken while determining the collaborative service requirements, as this traffic seems to strongly impact the network and applications. If VoIP is going to be part of those services, such items as the effects of the different voice encoders (vocoders) should be studied as well. Additionally, VTC should be restricted to only locations that are able to support it without affecting other users. It should also be restricted to mission essential operations and when possible to non-peak hours.

CONCLUSION

The workflow described above for using the JCSS software has been found effective in many different studies and situations. Over and over, defense organizations utilize the simulation capabilities of JCSS to perform detailed network performance studies. At the end of the study, the MAGTF team was able to conclude that the designed network was not able to handle all of the expected traffic. As a follow-up study, the team could try to modify the network and re-run the simulations to test new configurations. The point to note here is that the study saved the MAGFT team time and money as the network did not necessarily have to be deployed for this study to be effective. Using the simulated environment, the team was able to get the same results as would have been seen in the real world network. For more information on JCSS, please visit http://www.disa.mil/netwars/index.htm.

REFERENCES

1. Marine Air Ground Task Force Performance Analysis in JCSS. Mike Davis. Information Assurance and Joint Requirements Division. 20 September 2007.

2. JCSS User Manual Version 7.0 Final. OPNET Technologies. November 30, 2007.

3. JCSS DISA Website: www.disa.mil/netwars/index.htm.

4. OPNET website: www.opnet.com.

[ieee milcom 2008 - 2008 ieee military communications conference (milcom) - san diego, ca, usa...

Documents