Skip to Content
[CAIDA - Center for Applied Internet Data Analysis logo]
Center for Applied Internet Data Analysis > funding : nms : sim : OSC_Input_Standards.xml
Wireless Scenario for Online Simulation and Control
This section presents input data for a first wireless scenario, including documentation on the file formats.
|   OSC Input Standards    JTIDS/TACINTEL scenario    Static 64 node scenario   |

Online Simulation & Control Standard Input Files


files and documentation:

The Online Simulation and Control project is providing scenarios for network simulation in files in standard formats. Different aspects of the scenario come in different files. There are several formats that the OSC project uses internally to specify scenarios. For distribution to the NM&S community, we are currently using a subset of that set of standards. This is done for simplicity and for incremental implementation. Once the community participants interested in using these scenarios have implemented these standards we can add other details to enable various uses for the scenarios.

To describe the entities and their mobility, we use a part of the SEAMLSS SDF format. To describe the traffic between the entities, we use a simple flow description format designed for this program. The flow description format is also an output format for online simulation and control. These data are supplied separately, because for many scenarios there are many different traffic loads that can be applied to the entities. We have, typically, in excess of a dozen different loads for a scenario.

The description being provided to NM&S is currently focussed on wireless third generation networks, which means that the scenario does not specify any links among the radios. Data also does not specify attributes of the radios; those are expected, for now, to be added using whatever radio model the modeler want to use. We have used four different radios.

The scenario description file defines a 64 node stationary simulation with simulated operational traffic. Online Simulation & Control (OSC) application was used to meter the Transport Layer of a simulation engine to create the output file "tpSendFlow.txt". A brief description of the files follows.

64node.sdf:The SDF file

Scenario Description Files (SDF) defines a scenario and are described as ASCII flat files in a grammar defined from the NetWars program. The grammar allows division of the file into sections. In each section there is a set of simple and complex attributes that may be defined.

Table 1 summarizes the meanings and usage of the keywords in the files. The section start/end keywords in the SDF take no arguments. The others keywords are followed by a sequence of arguments that contain the data that specifies the attributed information.


Table 1. Summary of keywords




Start of simulation section


End of simulation section


Start of platform section


End of platform section


Array of complex attributes follows


Simple, scalar attribute instance


Entity state


The "ar:" keyword allows dynamic definition of an array of simple or complex attributes. It indicates that a specific number of instances of a particular keyword follow.

  • ar: <array name>: <array length>

The "at:" keyword is for defining simple attributes attached to a section of the SDF.

  • at: <attribute name>: <value>:<data type >

The "st:" keyword is for specifying the motion and status of the platforms.

  • st:<time>:<latitude>:<longitude>:<altitude>:<psi>:<theta>:<phi>:<mission>:

An SDF contains an overall simulation definition section "si:" and a platform instance "pi:" section for each platform instance in the scenario. Each "pi:" section in the SDF is primarily used to assign unique IDs to a platform instance. The sections start and end keywords in the SDF take no arguments. Others keywords are followed by a sequence of arguments that contain the meta-data which specifies the attribute information.

si/es Section:

The "si:-es:" keywords denote the start and end of a simulation summary section in the SDF. This must be the first section in the SDF, however it may be proeceeded by comments. This section includes the following:

1. Global scenario descriptors and simulation controls specified by "at:" keywords

2. Default "at:" settings for entities, which may be overridden for individual entities.

Table 2 shows the current set of "at:" attributes that are expected in the si/es section.


Table 2. "at:" Attributes in simulation initialization, "si" section

Attribute Name

Attribute Definition

data type

Global Scenario Descriptors and Simulation Controls


Version of the SDF file format to use.



A name for this particular execution of a simulation of the scenario.



The name of the wargaming scenario.



Time within scenario at which the communication simulation starts, in seconds.



Time within scenario at which the communication simulation ends, in seconds.



Time to run simulation before starting the scenario to let the devices set up in seconds.



Time to run simulation after the scenario to let the threads finish in seconds.



Random number seed for the simulation.



IP address of the HPOpenview receiving SNMP outputs. If not given, then no SNMP outputs should be made from the models.



Name of the simulator engine.



IP address of the simulator engine.



Name of the default "comms_device"carried by entities.



Source of communications traffic ("internal" or "external")



Indicator of source of mobility (None, Random, Trajectory, HLA)



Flag indicating on/off.



SDF_Ver specifies the version of the SDF specification in which the SDF file is written.

OPSIT_Name is a unique name for the simulation execution that represents a combination of the scenario, the doctrine, the device and the purpose of the run. It is used for naming files and as a header for results.

Scenario_Name provides a name for the scenario as specified through the set of platforms, their mobility, their command hierarchy, the events (triggers) and other information.

The Start_Time and End_Time use time-zero matched to the time-zero set by the stimulator. Thus, the simulation starts when the time from the stimulator exceeds the Start_Time and ends when the time from the stimulator exceeds the End_Time.

The Start_Offset provides a time interval at the beginning of the simulation to start up the network before loading it with the scenario traffic.

The End_Offset provides a time interval after the end of the scenario to allow the completion of threads started during the scenario.

The SNMP_IP can be set to to indicate that the SNMP messages are to be sent to the data collector on the same computer node as the simulation. Not needed if SNMP is off.

The Simulator and Simulator_IP fields identify the simulation engine used.

The Message_Source is used to determine whether the simulation is supposed to self-trigger based on the generation rules (internal) or whether it is supposed to wait for trigger events from the HLA federation.

The Mobility specifies the choice of algorithm for moving the entities. The options are:

  • None — do not move entities
  • Trajectory — use trajectories specified in the SDF.
  • Random — Ignore the trajectories and move the entities with a random motion. (default)
  • HLA — Receive the mobility from the HLA interface.

The Comms_Device specifies the default communications device for each platform. It is overridden by the value in the pi/ep section, if specified.

pi/ep Section:

These keywords denote the start and end of a platform section in the SDF. A pi/ep section exists for each instance of a platform in the scenario. The pi/ep keywords bracket a group of simple and complex attribute values for the platform instance.

Figure 3 provides a sample section. It includes identifiers for the attributes and some initial settings. It shows a structure that is convenient, but not necessary. The ar: keywords are now optional.


Each pi/ep section has attributes that identify each platform instance in multiple ways. Following are the various identifiers currently used. They are not all required for all runs. The need depends on the choice of other parameters. The order of their appearance does not need to match the above example.

The platform_name is unique to the instance.

The ip_address field provides an option to match the simulation to a real network.

The entity type is the type of entity as defined in the scenario or wargaming tool.

The comms_entity_type identifies the entity type as related to the use of comms.

The federate provides a default specification identifying the federate in which simulation federate entities are to be simulated.

The comms_device (a.k.a communications element) is the name of the device package used by the platform.



The ttpSendFlow.txt file is an OSC generated file that set to at a desired granularity for a simulation that records the bytes sent between nodes. The interval at which the byte counts are reported is determined at the start of the simulation. Flow files show the relationship between source host (Source Ip) and destination host (Dest Ip). The start and stop times (both reported in seconds) relate the time between the last report (Start) and this report (End). The other values relate the method of transfer (Protocol), the number of bytes sent and the number of packets sent. The "Bytes Sent" and "Pkts Sent" values relate the quantity since the last report (i.e. they are non-cumulative). The additional lines END INTERVAL and END RUN relate the last report for this interval, and the last report for the run of the simulation, respectively. The values in parentheses (i.e. t=5) allows one to keep their simulation clock in sync with clock of the producer.



# UID Start (s) End (s) Source Ip Dest Ip Protocol Bytes Sent Pkts Sent





0 12.0 15.0 UDP 176 1

1 12.0 15.0 UDP 704 4

2 12.0 15.0 UDP 176 1

3 12.0 15.0 UDP 176 1


4 15.0 18.0 UDP 176 1

5 15.0 18.0 UDP 176 1

6 15.0 18.0 UDP 704 4

7 15.0 18.0 UDP 176 1

8 15.0 18.0 UDP 176 1

9 15.0 18.0 UDP 176 1

10 15.0 18.0 UDP 176 1

11 15.0 18.0 UDP 176 1

12 15.0 18.0 UDP 176 1

13 15.0 18.0 UDP 2112 12

14 15.0 18.0 UDP 176 1

15 15.0 18.0 UDP 176 1

16 15.0 18.0 UDP 176 1

17 15.0 18.0 UDP 176 1

18 15.0 18.0 UDP 176 1

19 15.0 18.0 UDP 176 1

20 15.0 18.0 UDP 176 1

21 15.0 18.0 UDP 176 1

22 15.0 18.0 UDP 2112 12

23 15.0 18.0 UDP 1408 8

24 15.0 18.0 UDP 176 1

25 15.0 18.0 UDP 176 1



  Last Modified: Tue Jan-8-2019 13:43:11 PST
  Page URL: