Modeling methods in OPNET simulations of Tactical Command and ...

Modeling methods in OPNET simulations of Tactical Command and Control
Information Systems
J. Mohorko, M. Fras, Ž. Čučej
Laboratory for Signal Processing and Remote Control
University of Maribor, Faculty of Electrical Engineering and Computer Science
Smetanova ul. 17, SI-2000 Maribor, Slovenia
Phone: +386 2 22071840 Fax: +386 2 2207272 E-mail: mohorko@uni-mb.si
Keywords: MIP, C2IEDM, C2IS, Replication, OPNET, Tactical networks, Traffic modeling, Simulations, WLAN
Abstract - Slovenia is a member of MIP (Multilateral
Interoperability Programme), the task of which is to provide
interpretations of national C2IS systems for successfully
harmonizing joint action by international military
peacekeeping forces. Interpretability within MIP is carriedout
by a unified model based on controlled data replication
between the databases of C2IS systems. Systematic IRIS
Replication Mechanism software (IRM) is used for data
replication. This paper presents methods of measuring and
analyzing traffic that causes IRM. We designed an OPNET
model on the basis of the analyzed results that would be
suitable for the purposes of tactical radio network simulation.
1. INTRODUCTION
Simulations by the modeling and analyzing of
communication system’s characteristics, has become one
of the main challenges when constructing networks, and
the development of network devices and protocols. The
Slovenian army also felt such needs, when it called for a
national research project 1 , the object which was the
optimization of tactical radio communication networks.
This would represent infrastructure for a national Tactical
Command and Control Information System - C2IS
(TISPINK in the Slovene language). Slovenian TISPINK
is a member of the Multilateral Interoperability
Programme (MIP), the mission of which is to ensure the
interpretability of national C2IS systems for harmonizing
the activities of international forces in joint peacekeeping
operations. Connectivity within MIP enables a unified
Command and Control Information Exchange Data Model
(C2IEDM), which is based a controlled replication of data
between the C2IS system’s databases. The software
environment of Slovenian TISPINK is based two products
from the Danish software producer Systematic; these are
Sitaware and IRM (IRIS Repliacation Mechanism).
Sitaware represents graphic interface for: the entry of data
in to the C2IS database, GIS, and the planning and analysis
of tactical operations in the field. IRM enables a controlled
exchange of data between tactical units on the battlefield
[1, 2, 3 ].
OPNET is one of most powerful simulation tools for the
analysis, planning and optimization of communication
networks, devices and protocols. The best known use of
OPNET in the defense area originates through the
NETWARS programme of the US Department of Defense
[5, 6,7].
1 Target research programmes "Science for Peace and Security”:
M2-0140 - Modeling of Command and Control information
systems, financed by Slovenian Ministry for Defense.
This paper presents a segment of the outcome regarding
the research of our project. The goal is to develop methods
for the modeling of data traffic in a tactical network that is
the consequence of the IRIS replication mechanism’s
activity. The 2nd section briefly introduces the OPNET
simulation package and its capabilities for evaluating
telecommunication systems. Section 3 follows, which
describes how to build a laboratorial model of the
TISPINK system, where radio connections are replaced by
Ethernet network. Ethernet traffic, captured by using the
Ethereal network protocol analyzer, was analyzed using an
ACE (Application Characterization Environment) module
of OPNET. In section 4 tests and evaluates some of the
OPNET traffic modeling methods suitable for our case.
The results are summarized in section 5.
2. OPNET OVERWIEW
OPNET is a leading tool for simulating and evaluating
telecommunication systems. It was presented for the first
time to the communication industry in 1986.
Fig. 1: OPNET with Project Editor, Node Editor and C-Source
code Editor.

The basis is on object-oriented simulation approach
supported by a series of graphic user interface - editors
(see Fig.1), which rather simplify the process of
communication networks modeling, devices, and
protocols. The project Editor enables the entry of graphic
description of network topology. The Node Editor is used
for describing protocols, and the connections between
them, by using layers of the ISO/OSI model for
communication devices. The Process Editor is an
extension of programming language C. It uses a powerful
finite-state machine (FSM) approach to represent of
different communication algorithms and protocols. The
activity of individual state in FSM is implemented by
programming language C. OPNET incorporates a lot of
already-prepared simulation models of standard
communication equipment and protocols for wired, radio
and optical transmission mediums. [4].
2.1 OPNET module ACE
OPNET is designed modularly. One of modules, used in
this study case, is ACE (Application Characterization
Environment) [4]. ACE is a tool for the visualization,
analysis and prediction of traffic in network applications.
It helps us with the activity analysis of existing, and the
development of new applications. This module allows the
importing of captured traffic by sniffer and analysis for the
following intentions:
• Diagnosing application problems
• Predicting application behavior
2.2 Modeling of network traffic by OPNET
The OPNET modeler allows for two basic methods of
network traffic modeling: explicit traffic and background
traffic. For Explicit traffic, OPNET produces every packet
separately. This method of network traffic generation also
calls packet by packet traffic. In this manner the traffic of
the real system is clearly imitated, however such
simulation is more numerically demanding. These three
methods for modeling explicit traffic:
• Packets generator by which modeling on the
network node determines the streams of packets
exactly.
• Application demands assign traffic between two
network nodes.
• Applications traffic model where traffic is generated
by standard application models.
Background traffic is analytically modeled traffic,
which has an influence on the properties of a system in the
form of additional delay. Background traffic can also be
used in combination with explicit traffic. OPNET allows
the following methods for modeling background traffic:
• Traffic flow describes finite end-to-end traffic from
source node to destination node.
• Baseline loads represent background traffic on one
of the selected links (or from the node).
• Application demands can also be used to represent
background traffic between two nodes.
(representing tactical units), as shown in Figure 2. C2IS
database, Sitaware user interface and IRIS replication
mechanism are installed on every station. All stations are
connected, over hub, in Ethernet network, which replaces
radio network. The network is, on IP level, distributed
over two subnets: broadcast and peer-to-peer. Stations in
subnets are defined using IP addresses, as shown in Table
1. Another computer with installed software Ethereal for
capturing Ethernet traffic (sniffer) was added to this rest
network.
Fig. 2: Block scheme of TISPINK test system.
Unit IP address Peer-topeer
Broadcast
1.Brigade 192.168.1.1 x
20.Battalion 192.168.20.1 x
10.Battalion 192.168.10.1 x x
1. Company 192.168.10.11 x
2. Company 192.168.10.12 x
Table 1: Logical distribution of units in test systems TISPINK
with two subnets Peer-to-peer in Broadcast
Data traffic, between stations in test network, is defined
by contracts which are established by the IRIS replication
mechanism. A contract defines data contents and
destinations, where the data will be transmitted. Data
contents are modeled by data sources (GPS, VoIP, manual
entry, electronic mail, etc), which cause these contents.
Contracts were divide by considering the destinations,
which are addressed on certain unit (peer-to-peer) and
contracts, which are addressed on all units within the same
subnet (broadcast).
3. MEASURING AND ANALYSIS OF TISPINK
TRAFFIC IN OPNET
A test laboratorial model of the TISPINK system was
built. This test network is composed of five workstations
Fig. 3: Measuring of traffic with sniffer Ethereal

Data traffic occurs between individual units, when the
IRM mechanism detects any change in the database. If
there is a contract that refers to changed data, then this data
will be sent to the destination address. With the help of
SITAWARE GIS user-interface, we moved of unit on
fieldwork. The traffic caused by movement is measured
using the Ethernet sniffer, as shown in Figure 3.
Measuring acquires the following information about
network traffic: time of generating packets, size of packets,
type of protocol, inter-arrival time, source IP, and the
destination IP address.
analyses, of captured traffic, we can use mathematical
fitting tools such as EasyFit, as shown in Figure 6.
With the help of the described tools, we can analyze
measured traffic, which was caused by different activity
conditions (broadcast and peer-to-peer) for IRM
application in the tactical test network.
Fig. 6: Tool for choosing the distribution function and its
parameters.
4. SIMULATION RESULTS
Fig. 4: Entry measure (captured) of traffic in the ACE module
Using the OPNET ACE module the impact of different
parameters was analyzed such as, for instance, the
bandwidth on delay in the network. First the captured
traffic in the Ace Module was imported. Then the ACE
module created a hierarchical picture of the network, as
shown in Figure 4, where data connections between
participants in tactical networks can also be seen. Stations
in the network were named by IP addresses. The station in
Figure 4 with the IP number 192.168.10.255 is virtual
station, which introduces the broadcast IP address.
The Data Exchange chart is used for analysis of traffic
and packets of captured traffic, and offers the examination
of time-dependence execution regarding protocol between
participant transmitting stations. In the case of such a
graph with enlarged detail is shown Figure 5.
OPNET allows the modeling of two types of traffic:
explicit traffic and background traffic. In the explicit case,
the traffic is modeled packet by packet. This is opposite to
background traffic, which is analytically described and has
an effect on network performance with additional delays.
The analysis of traffic in the previous section enables the
studying of different possibilities for traffic modeling by
OPNET simulations.
The traffic of application IRM will be modeling using
explicit traffic, because of the demanded reliability. Three
different methods of modeling exist: a traffic generator,
application demands, and an application traffic model.
4.1 Applications traffic model
OPNET contains 16 standard-application traffic models
(as shown in Figure 7), which can be used on the
following node models (stations): WLAN workstation,
MANET workstation and Ethernet workstation.
Fig. 5: More detailed display of one movement of the unit and
generated packets of IRM application
In OPNET we often model traffic, which is defined
statistically with probability distributions for bit rate and
time between packets (inter arrival time). For such
Fig.7: Standard applications in OPNET.

Parameters can be changed for every model of
application in regard to: size of packets, amount of packets
(data rate), transport protocol, number of repeated sending,
timeouts, retransmissions, failure and recovery, etc. In
addition, to using standard applications we can also model
new 'custom' applications. We modeled a custom
application with the help of the results derived from the
ACE analysis described in the previous section.
4.2 Application demands
Applications demand is a way of traffic modeling, where
the application’s behavior is modeled. Demands
characterize traffic by the sizes and rates of the requests
and responses, between two nodes in both directions.
considered criteria we decided that the traffic of IRM
application would be modeled using traffic generators on a
MANET station. This traffic generator does not have the
possibility of defining statistics for the ON/OFF process,
which is a disadvantage of the traffic generator. This is the
reasons why we were forced to change the interpretation of
a traffic generator’s activity mechanism. In the new
interpretation we treat one packet as one transaction of the
IRIS replication mechanism, where the new size of the
packet is the sum of the transaction’s packets. We interpret
time between packets as time between individual
transactions. Every MANET station enables the
simultaneously activity of arbitrarily number of the traffic
generators. For each of them, we can define destination
address (peer-to-peer or broadcast) and statistical
descriptions of packet size and inter-arrival time.
Fig. 8: Modeling applications demand between station and
server.
4.3 Traffic generator
We can model network traffic by a traffic generator,
where the traffic is described statistically by packet size
and time between packets (inter arrival time). There are
approximately 20 different probability distributions
available.
Traffic generators in OPNET are contained in the
following node models (stations): Ethernet IP station, PPP
IP station, MANET station. In some models (WLAN
station in Figure 9) beside these two parameters, there is
also the possibility of modeling the distribution of
probability for active and none-active states of the node
(ON state and OFF state).
5. CONCLUSION
We modeled traffic of the IRM application in three
different ways. Every method has certain advantages and
disadvantages in its use. By choice, most suitable methods
consider the following criteria: wireless station, mobility,
consideration of terrain in the communication model,
possibility of setting wireless LAN parameters for the
modeling of radio devices, possibility of communication in
broadcast and peer-to-peer protocol. On the basis of the
REFERENCES
Fig. 9: Modeling of traffic by WLAN station
[1] Multilateral Interoperability Programme, http://www.mipsite.org/
[2] Sytematic, "IRIS Replication Mechanism", “White Paper”,
Revision 1.16, December 2006
[3] Sytematic, "SitaWare", “White Paper”, Revision 1.16,
December 2006
[4] OPNET Modeler, OPNET Technologies Inc.,
http://www.opnet.com.
[5] Steve L. Ferenci, C. Alspaugh, Efforts to Enhance
Interoperability for Netwars, MILCOM 2004 - 2004 IEEE
Military Communications Conference
[6] William S. Murphy Jr., Mark A. Flournoy, "Simulating
crises communications", Proceedings of the 2002 Winter
Simulation Conference, 954-959
[7] V. Lakshminarayan, "NETWARS Standards Architecture
and Implementation Issues" NETWARS Standards
Working Group. 1998