ns-3 is free simulation software that’s meant for educational, research and development purposes. It has a number of high quality, tested and validated models, and is backed by a large community of developers and users.
The ns-3 simulator is an open source project meant for educational and development purposes. It is also used to enact discrete-event simulation. Practical implementation or experimental testing of new protocols on real-world networks is not always possible. ns-3 helps to abstract real-world entities and allows to simulate, as well as to compute complex calculations on huge networks of computer systems. It can be treated as a real-time network emulator, as it can simulate scenarios on realistic data. It provides a platform for developers to build simulation models and can comprehend every single step, i.e., the entire workflow of the simulation, from configuration to the collection and analysis of traces.
The ns-3 project includes and supports various real-world protocols and its implementations. It supports various routing protocols, which include OLSR, AODV and many more for IP-based applications on IP networks. It also supports non-IP based network simulation. The ns-3 simulator majorly involves models for Wi-Fi, WiMax and LTE.
Mobility provision in the ns-3 simulator
The ns-3 simulator provides support for mobility in the form of mobility models and helper classes. Mobility models are used to track and perpetuate the current position and speed of an object. Mobility helper classes are used to place nodes and set up mobility models. Users communicate with the mobility system using the mobility helper classes as they integrate a mobility model and position allocator, and can be used along with a node container to install mobility functions on a set of nodes. The ns-3 simulator provides a ns-2 mobility helper class, which allows it to interpret the ns-2 file format of the trace file. The following statements show the ns-2 trace file format:
$node_ (node number) set X_ x $node_ (node number) set Y_ y $node_ (node number) set Z_ z $ns_ at $time $node_ (node number) setdest x2 y2 speed $ns_ at $time $node_ (node number) setdest x3 y3 speed $ns_ at $time $node_ (node number) setdest x4 y4 speed $ns_ at $time $node_ (node number) setdest x5 y5 speed
In the above traces, x and y are initial positions while z specifies the speed in m/s. These are initialised using the set statements. The command setdest is used to define the new position (x2, y2) of the node at the given time ($time), which thus instructs the node to propagate to its new position. If the node reaches its destination, it will pause there; or it may also happen that the simulation ends before. In that case, the node will not be able to reach the destination. Also, sometimes a new destination is set during a course to a location; in that scenario, the node will change course to the new destination in between.
SUMO
Simulation of Urban Mobility (SUMO) is an open source traffic simulation package that includes net-import and demand modelling components. Many research topics, like the route choice and the simulation of vehicular communication or traffic light algorithms, are studied with the help of SUMO. The framework of SUMO serves in various projects like traffic management strategies or to simulate automatic driving. Simulations in SUMO comprise time-discrete and space-continuous vehicle movements, multi-lane highways and streets, traffic lights, Open GL for the graphical interface and fast execution speed. SUMO is edge-based, can operate with other applications at run time, has portability and detector-based outputs.
The flow of the integration of SUMO traces with ns-3 for mobility provisioning is shown in Figure 1.
Constructing a scenario in SUMO
In order to generate traffic with the help of the SUMO simulator, a scenario or network needs to be created. SUMO Street Network consists of nodes (junctions) and edges (streets connecting the junctions). SUMO Simulator requires .nod.xml and .edg.xml to define the junctions and streets joining them.
The nod.xml file contains the location (x and y coordinates) of junctions. An example is given below:
first.nod.xml <nodes> <node id=”1” x=”-300.0” y=”5.0” /> <node id=”2” x=”+300.0” y=”5.0” /> <node id=”3” x=”5.0” y=”-300.0” /> <node id=”4” x=”5.0” y=”+300.0” /> <node id=”5” x=”5.0” y=”5.0” /> </nodes>
To join the above nodes, edges are defined in the edg.xml file using the target node ID and source node ID. An example is given below:
first.edg.xml <edges> <edge from=”1” id=”A” to=”4” /> <edge from=”4” id=”B” to=”2” /> <edge from=”2” id=”C” to=”5” /> <edge from=”5” id=”D” to=”3” /> <edge from=”2” id=”E” to=”3” /> </edges>
To build a network, the above defined node file and edge file are required. And using the netconvert utility, a net.xml file is generated as follows:
$netconvert -n first.nod.xml -e first.edge.xml -o network.net.xml
Vehicles in the traffic are defined with route data in the rou.xml file. For example:
first.rou.xml <routes> <vType id=”BoogyA” length=”5.75” maxSpeed=”90.0” sigma=”0.4” /> <vType id=”BoogyB” length=”7.5” maxSpeed=”60.0” sigma=”0.7” /> <route id=”rou01” edges=”A B C D”/> <route id=”rou02” edges=”A B E”/> <vehicle depart=”0” id=”v0” route=”rou01” type=”BoogyA” color=”1,0,0” /> <vehicle depart=”1” id=”v1” route=”rou02” type=”BoogyA” /> <vehicle depart=”2” id=”v2” route=”rou01” type=”BoogyA” /> <vehicle depart=”3” id=”v3” route=”rou02” type=”BoogyA” /> <vehicle depart=”5” id=”v4” route=”rou01” type=”BoogyA” /> <vehicle depart=”6” id=”v5” route=”rou02” type=”BoogyA” /> <vehicle depart=”7” id=”v6” route=”rou01” type=”BoogyA” /> <vehicle depart=”8” id=”v7” route=”rou02” type=”BoogyA” /> <vehicle depart=”9” id=”v8” route=”rou01” type=”BoogyA” /> <vehicle depart=”11” id=”v9” route=”rou02” type=”BoogyA” /> <vehicle depart=”14” id=”v10” route=”rou01” type=”BoogyA”/> <vehicle depart=”16” id=”v11” route=”rou01” type=”BoogyA”/> <vehicle depart=”17” id=”v12” route=”rou01” type=”BoogyB” color=”1,0,0” /> <vehicle depart=”18” id=”v13” route=”rou02” type=”BoogyB” /> <vehicle depart=”19” id=”v14” route=”rou02” type=”BoogyB” /> <vehicle depart=”21” id=”v15” route=”rou01” type=”BoogyB” /> <vehicle depart=”22” id=”v16” route=”rou01” type=”BoogyB” /> <vehicle depart=”23” id=”v17” route=”rou02” type=”BoogyB” /> <vehicle depart=”24” id=”v18” route=”rou02” type=”BoogyB” /> <vehicle depart=”27” id=”v19” route=”rou02” type=”BoogyB” /> </routes>
Files first.rou.xml and network.net.xml are required to generate configuration files for simulating the traffic on the network. The following configuration file is generated, which is then used to simulate the scenario:
first.sumo.cfg <configuration> <input> <net-file value=”network.net.xml”/> <route-files value=”first.rou.xml”/> </input> <time> <begin value=”0”/> <end value=”150”/> </time> <time-to-teleport value=”-1”/> </configuration>
To simulate the scenario, the following command is required to be fired from the terminal:
$sumo -c first.sumo.cfg
To visualise the simulation in the SUMO GUI, use the following command:
$sumo-gui -c first.sumo.cfg
Generating traces
SUMO trace files can be generated with the help of a .cfg file (configuration file), as follows:
$sumo -c first.sumo.cfg –fcd-output trace.xml
Traces of the vehicles’ position are dumped into the XML file. These SUMO traces can be used to provide mobility to nodes in the ns-3 simulator. The ns-3 simulator provides the ns-2 mobility helper class, which can be used to read the movements of nodes from trace files. To make use of the SUMO traces generated from the SUMO simulator, the XML file needs to be converted to a TCL file, which then is provided to the ns-2 mobility helper. SUMO provides tools like traceExporter.py and traceExporter.jar to convert SUMO trace to different file formats.
$python $SUMO_HOME/tools/traceExporter.py –fcd-input trace.xml –ns2mobility-output mobility.tcl
mobility.tcl generated above contains the position and the velocities of the nodes (vehicles).
Rendering SUMO traces in ns-3
Visualisation through Python Visualizer: The ns-3 simulator provides the ns2-mobility-trace.cc file, which takes mobility.tcl as the argument along with a number of nodes in the scenario and the duration of the simulation. At the end of the simulation, it generates a log file. The command for executing the same is given below:
$./waf --run “ns2-mobility-trace --traceFile=path_to_tracefile/mobility.tcl --nodeNum=18 --duration=200.0 --logFile=ns2-mob.log” --vis
–vis renders the simulation in Python Visualizer.
Visualising the scenario in NetAnim: A NetAnim compatible XML file can be generated by adding the following lines of code in the file ns2-mobility-trace.cc (ns-dev/src/mobility/examples/).
Include the header file:
#include “ns3/netanim-module.h”
And add the following line in the program:
AnimationInterface anim (“ns2mobilityanimation.xml”);
To visualise the scenario, open ns2mobilityanimation.xml in NetAnim.
Generating traces in the form of a file: By executing the ns2-mobility-trace.cc as shown above, the ns2-mob.log file is generated.
