Note: NetSim VANET library is available only in standard and pro versions

Connected vehicle (CV) technologies enable a wide range of transportation applications in safety, mobility, and infotainment. While holding tremendous promise, the success of these CV-enabled applications will rely on the quality of the underlying information flow [1]. NetSim is a simulation tool to model, simulate and analyses this information flow. The vehicular communication architecture in NetSim is based on a combination of the IEEE 1609 standard and IEEE 802.11p standard. The 802.11p standard defines the PHY and MAC layers while IEEE 1609 defines the upper layers.

Graphical user interface, diagram, application Description automatically generated

Figure 1‑1: NetSim-SUMO interfacing for VANET simulation. Top left is a SUMO screen shot while bottom right is a NetSim screen shot.

NetSim’s VANET library features:

  • IEEE 802.11p PHY operating in the 5.9 GHz band with a channel > bandwidth of 10 MHz. 802.11p is an adaptation of the famous IEEE > 802.11a standard previously used in Wi-Fi systems.

  • Radio propagation in the PHY layer covering various pathloss, > shadowing and fading models.

  • IEEE 802.11p MAC layer. Stations communicate directly outside the > context of a BSS.

  • IEEE 1609-2, which defines security services for application > messages and management messages in WAVE. 

  • IEEE 1609-3, which defines connection set up and management of WAVE > compliant devices. 

  • IEEE 1609-4, which enables upper layer operational aspects across > multiple channels without knowledge of PHY layer parameters.

  • DSRC SAE J2735

  • BSM packets that are transmitted using WSMP

  • A spontaneous Adhoc network formation between the VANET nodes; > layer-3 IP routing can be through DSR, AODV, OLSR or ZRP for > non-BSM packets

  • Vehicular mobility using in-built mobility models or by interfacing > with SUMO software

  • Interfacing between SUMO & NetSim via Traffic control interface > (TraCI). Automatic import of road network and vehicle mobility > from SUMO

  • Wide range of output metrics including Delay, Throughput, Error, > Retransmission, etc.

  • Protocol source C code is provided along with NetSim software

    In VANETs, Vehicles and roadside units (RSUs) are the communicating nodes, providing each other with (i) safety information using BSM application and (ii) infotainment applications. Both types of nodes are dedicated short-range communications (DSRC) devices. The RSU is a WAVE device usually fixed along the roadside or in dedicated locations such as at junctions or near parking spaces. In NetSim, users can model network traffic flows:

  • between two or more Vehicles, known as V2V

  • from vehicles to RSUs (infrastructure), known as V2I

  • between two or more RSUs

  • from vehicles or RSUs to remove servers, by connecting RSUs in backhaul to a wired network comprising of switches, routers, and servers for end-to-end simulation.

Simulation GUI#

Create Scenario#

  • Open NetSim and click New Simulation à Vehicular Adhoc Network > (Vanet) as shown Figure 2‑1.

Figure 2‑1: NetSim Home Screen

  • A dialogue box appears as shown below, in that browse the Sumo > Configuration File path. The general format of such file is > “*.Sumo.cfg”.

Figure 2‑2: Sumo Configuration File path

  • NetSim VANET module is designed to interface directly with SUMO.

  • A SUMO configuration file is required as an input to NetSim.

  • Sample SUMO configuration files are available inside > \**\Docs\Sample_Configuration\VANET** > folder.

  • Users can either use a Sumo configuration file which is provided > inside NetSim’s installation directory or use a different user > specified SUMO configuration file. This .cfg file contains the > path of NETWORK file and VEHICLES file.

  • Further help on how to create SUMO configuration files is available > at >

After selecting the Sumo configuration file name, the scenario is opened, with nodes placed at their respective starting positions (tracked from Sumo). Roads and Traffic Lights are also placed exactly as present in SUMO Configuration file.

Devices specific to NetSim VANETs Library#

  • Vehicle (with one OBU): In NetSim, a vehicle is a mobile > communications device. It is assumed to have one (1) on board > unit (OBU) which is a 5-layer device. The OBU can communicate with > other OBUs or with RSUs via an Adhoc link. The OBU is assumed to > have one wireless interface and has its own IP and MAC addresses.

  • Roadside Unit (RSU): In NetSim, an RSU is a fixed communicating > device. RSUs are generally termed as infrastructure. Vehicle > (OBU) to RSU is termed as V2I communication. The RSU is a 5-layer > device that can be connected to a Vehicle or to a Router. RSUs > cannot be directly connected to other RSUs. RSUs have one (1) > wireless interface and one (1) serial interface, and each > interface has its own IP and MAC addresses.

  • Wired node: A Wired node can be an end-node or for a server. It > is a 5-layer device that can be connected to a switch and router. > It supports only 1 Ethernet interface and has its own IP and MAC > Addresses.

  • Wireless Nodes: A Wireless node can be an end-node or a server. > It is a 5-layer wireless device that can be connected to an Access > point. It supports only 1 Wireless interface and has its own IP > and MAC Addresses.

  • L2 Switch: Switch is a layer-2 device that uses the devices’ MAC > address to make forwarding decisions. It does not have an IP > address.

  • Router: Router is a layer-3 device and supports a maximum of 24 > interfaces each of

which has its own IP address.

  • Access point: Access point (AP) is a layer-2 wireless device > working per 802.11 Wi-Fi protocol. It can be connected to wireless > nodes via wireless links and to a router or a switch via a wired > link.

Figure 2‑3: VANET Library Device Palette in GUI

  • Right click on the appropriate node or link and select Properties. > Then modify the parameters according to the requirements.

  • Routing Protocol in Network Layer and all user editable properties > in Data Link Layer few properties are Global or Local, Physical > Layer and Power are Local.

  • In Physical layer standards are acting as Link global.

  • In the General properties, Mobility Model is set to SUMO, and it is > Editable. This signifies that the Node movements will be traced > from SUMO.

  • File name gives the path to Sumo Configuration file that was given > by the user.

  • Step Size is taken from the Sumo Configuration file specified which > tells the amount of time paused in sumo corresponding to single > step of SUMO Simulation.

  • In Interface (wireless) properties, under Physical layer, by default > Standard is set to IEEE 802.11p in case of VANET.

  • The following are the important properties of VANET Wireless Node > (RSU/Vehicle) in Data link and Physical layers.

Figure 2‑4: Vanet > Datalink layer Properties Window

Graphical user interface, application Description automatically generated

Figure 2‑5: Vanet > Physical layer Properties Window

Graphical user interface, application Description automatically generated

Figure 2‑6: Vanet > Physical layer Properties Window > Battery Model

  • Click on the Application icon present on the ribbon and set > properties. Multiple applications can be generated by using add > button in Application properties.

Figure 2‑7: Application icon present on top ribbon

  • Set the values according to requirement and click OK.

    Graphical user interface, application Description automatically generated

Figure 2‑8: Application Configuration window

Detailed information on Application properties is available in section 6 of NetSim User Manual.

Enable Packet Trace, Event Trace & Plots (Optional)#

Click Packet Trace / Event Trace icon in the tool bar and click OK. To get detailed help, please refer sections 8.4 and 8.5 in User Manual. Select Plots icon for enabling Plots and click OK.

Figure 2‑9: Enable Packet Trace, Event Trace & Plots options on top ribbon

Run Simulation#

Click on Run Simulation icon on the top toolbar. Simulation Time is set from the Configuration File of Sumo. The simulation has three options.

  • Record animation - runs Sumo in background. Users can view > animation after completion of Simulation.

Figure 2‑10: Run Simulation option on top ribbon

  • Play & Record animation – opens NetSim GUI and Sumo GUI in > parallel with parameters being continuously passed between the two > Simulators.

  • Don’t play/record animation – runs Sumo in Backend. Animation is > not recorded.

On running the Simulation by selecting Play & Record option, users can view NetSim Packet animation and SUMO simulation simultaneously.

SUMO determines the positions of vehicles with respect to time as per the road conditions. NetSim reads the coordinates of vehicles from SUMO (through pipe) during runtime and uses it as input for vehicles mobility.

Figure 2‑11: Vehicle moments on NetSim Packet animation and SUMO simulation window simultaneously

Users can see the movement of vehicles in SUMO and observe equivalent movement in NetSim. Here users can notice an inversion of view in the GUI, since origin (0, 0) in SUMO is at the left bottom, while origin is at the left top in NetSim.

When users select Play and Record animation option, NetSim and SUMO run separately, and users will find that the animation in SUMO is much faster than that of NetSim. This is because, NetSim has to animate the flow of packets between the vehicles in addition to the vehicle movement.

Model Features#

Implementation of the 802.11p in NetSim#

  • The Adhoc Wi-fi MAC allows for STA transmissions of data frames > outside-the-context-of-a-BSS (OCB). Establishing a secure BSS > necessitates announcement, scanning, synchronization, and > association and the time required is extremely undesirable in > vehicular environments [1]. NetSim therefore allows for direct > and instantaneous link setups with no establishment of a BSS. > There is no authentication nor association.

  • Supports a channel bandwidth of 10 MHz in the 5.9 GHz band

  • Supported PHY rates are 3, 4.5, 6, 9, 12, 18, 24 and 27 Mbps. The > rate is auto determined at the sender based on the target packet > error probability at the receiver (target PEP 0.1, 1000 B packets)

  • Transmission type is OFDM with slot time equal to 9 μs and SIFS > equal to 16 μs.

  • Uses a Medium Access Control (MAC) protocol based on the Carrier > Sense Multiple Access Collision Avoidance (CSMA/CA) protocol, > which is explained below.

    • When a node wants to send a message, the channel must be idle for a duration of SIFS. If the channel is idle, it starts transmission.

    • When a node finds the channel busy, it chooses a random backoff time from the interval [0, CW] and transmits only when the backoff timer has elapsed. The variable CW represents the size of the Contention Window.

    • When the SCH is used and a node does not receive an acknowledgement for a message, it concludes that the message has collided and is lost, so the value of CW is doubled, and it will retry transmission.

    • In the CCH however, beacons are broadcast in the channel and no acknowledgments are sent. Therefore, the value of CW is never doubled in the CCH.

DSRC Channels: CCH and SCH#

Vehicles (OBUs) and RSUs can operate in (switch between) multiple channels i.e., in the SCH and CCH as explained below.

  • Control channel (CCH): A radio channel, intended for the > exchange of management information. In NetSim when a BSM (safety) > application is configured, it is transmitted on the CCH.

  • Service channel (SCH): These are radio channels used for > non-safety applications. In NetSim, when non safety application > such as CBR, Voice, Video, FTP etc., are configured, they are > transmitted on the CCH.

  • Guard interval: A time interval at the start of each control > channel (CCH) interval and service channel (SCH) interval during > which devices cannot transmit.

Each synchronization interval SI is split as follows

Diagram Description automatically generated

Figure 3‑1: We see the time divisions in DSRC. Each synchronization period consists of 1 CCH, 1 SCH and 1 guard interval. While the sync period is generally equal to 100 ms. NetSim allows users to modify the CCH and SCH interval, and in turn the total synchronization period.

All devices (Vehicles and RSUs) switch between SCH and CCH and the alternation is based on the time divisions. NetSim allows the user to configure values of CCH interval, SCH interval and Guard interval. NetSim supports 6 service channels (SCH):172 (5860 MHz), 174 (5870MHz), 176 (5880 MHz), 180(5900MHz), 182(5910MHz) and 184 (5920 MHz), and 1 control channel (CCH): 178 (5890 MHz). The default channels used in NetSim are SCH 171 (5.855 GHz) and CCH 178 (5.890 GHz).

BSM Application#

  • DSRC protocol runs with BSM (Basic Safety Message) applications. BSM is a broadcast packet transmitted at a regular interval

  • The BSM Application class sends and receives the IEEE 1609 WAVE (Wireless Access in Vehicular Environments) Basic Safety Messages (BSMs). The BSM is a 20-byte packet that is generally broadcast from every vehicle at a nominal rate of 10 Hz. In NetSim this can be configured as a broadcast or as a unicast application. Note that a broadcast application can only be transmitted over a single hop. NetSim does not transmit broadcast applications over multiple hops.

  • This application does not follow the IP stack. It runs WSMP protocol over IEEE 1609. There is no routing; static routes cannot be set, and packets are sent directly to the destination.

NetSim – SUMO interfacing#

NetSim’s VANET module allows users to interface with SUMO which is an open-source road traffic simulation package designed to handle vehicular & road networks. The road traffic simulation is done by SUMO while NetSim does the network simulation along with RF propagation modelling in the physical layer. While SUMO Simulates the road traffic conditions and movements, NetSim Simulates the communication occurring between the Vehicles.

NetSim and SUMO are interfaced using ‘pipes’. A pipe is a section of shared memory that processes use for communication. SUMO process writes information to pipe, then NetSim process reads the information from pipe. On running the Simulation, SUMO determines the positions of vehicles with respect to time as per the road conditions. NetSim reads the coordinates of vehicles from SUMO (through pipes) in runtime and uses it as input for vehicles mobility.

Users will notice an inversion along X axis in the NetSim GUI, since origin (0, 0) in SUMO is at the left bottom, while origin is at the left top in NetSim.

VANET operates in wireless environment and hence RF channel loss occurs. The amount of loss can be configured by users. To modify the Wireless channel characteristics users can right click on the adhoc/wireless link and modify the channel characteristics as per the requirement.

Source code related to interfacing of SUMO and NetSim is available in Sumo_interface.c file inside the mobility folder/project.

How to create a VANET using SUMO and simulate with NetSim#

A SUMO network can be created either manually or using SUMO NetEdit.

Using SUMO NetEdit utility and to configure road traffic models#

Netedit is a Road network editor for the road traffic simulation in SUMO. Using this utility, users can quickly design road networks and obtain Network xml file which is part of SUMO configuration.

Steps to create a simple SUMO network using netedit utility

Step 1: Open netedit from \<SUMO_INSTALL_DIRECTORY>/bin (C:\Program Files (x86)\Eclipse\Sumo\bin) and select File-->New Network

Refer SUMO Documentation: "” for more details on modes of operation.

Figure 3‑2: SUMO NetEdit Screen

Step 2: Select Creating junction and edges option as shown below or click on character "e" in the keyboard.

Step 3: Enable the check boxes "chain”, "two-way" and “Grid” which are present in the right-side corner.

Figure 3‑3: SUMO NetEdit design window

Step 4: Adjust the design area to ensure that the road network lies in the Positive XY quadrant. This will help in avoiding complexities when opening the network scenario in NetSim.

Step 5: Click on grid area to create edges, clicking again will create a new edge which will automatically get connected to the previous edge as shown below.

Figure 3‑4: Creating edges SUMO NetEdit design window

Step 6: Select "(t) Traffic Lights". Select the junctions and click on Create TLS button on the left to add Traffic Signal to it.

Figure 3‑5: Adding Traffic Signal to Network

Step 7: Select "(c) Connect" icon Select the lanes and ensure connectivity between them.

Figure 3‑6: Select the lanes and connectivity between them

Step 8: Create a new folder and save the network file (*.net.xml) over there, say with a name

Figure 3‑7: inside the folder

Step 9: Open command prompt with the current working directory as the folder where you have saved the network file in the previous step.

Step 10: Using utility present in \<SUMO_INSTALL_DIRECTORY>/tools directory create trips file with the command.

COMMAND SYNTAX >" C:\Program Files (x86)\Eclipse\Sumo\tools\" -n " *.net.xml" -e \<NO_OF_TRIPS> --route-file "trips.xml"

Example Command >" C:\Program Files (x86)\Eclipse\Sumo\tools\" -n "" -e 2 --route-file "trips.xml"

Figure 3‑8: Generating route file (trips.xml)

This will create a trips file in your folder along with associated files.

Step 11: Create a SUMO configuration file (*sumo.cfg) which points to the network and trips file, in your folder which contains the network and route file.


Include parameter (To Run in NetSim)

“\<step-length value="0.4"/>"

Following is a sample SUMO Configuration:



\<net-file value=""/>

\<route-files value="trips.trips.xml"/>



\<begin value="0"/>

\<end value="100"/>

\<step-length value="0.4"/>



Note: Save above content as Configuration.sumo.cfg

You can copy the above contents to create a SUMO configuration file in your folder.

Figure 3‑9: Double click on Configuration.sumo.cfg

Step 12: Open Configuration.sumo.cfg by double clicking or open SUMO using sumo-gui.exe present in \<SUMO_INSTALL_DIRECTORY>/bin. Open scenario in SUMO using Open->Simulation and verify whether the network loads and simulation happens as per the configuration done.

Figure 3‑10: SUMO simulation window

Step 13: Open the SUMO scenario via NetSim VANET by selecting VANET under the New Simulation in the NetSim Home Screen. Browse and locate the SUMO Configuration file present in your directory to load the road traffic network in NetSim GUI. The road network created in SUMO will be automatically replicated in NetSim GUI environment.

Figure 3‑11: Importing a sumo network configuration into NetSim

Figure 3‑12: Network Topology in this experiment

Step 14: Configure traffic between vehicles using the Application icon, enable trace files and plots.

Step 15: Click on Run Simulation button. The Simulation Time is equal to the end time specified in sumo configuration (sumo.cfg) file and Simulation Time option is Non editable.

Creating your own network in SUMO manually#

Step 1: Create a node file using any code editor (like notepad, notepad++ etc.) and the file extension will be.nod.xml. It represents the junctions in the road. Each of these attributes has a certain meaning and value range: node_id means unique name of each junction, x-y is the positions of node and type can be "priority", "traffic_light", "rail_crossing", “rail_ signal”etc.(Refer:

Figure 3‑13: Device Positions in nodes file

Step 2: Create an edge file that describes how the junctions or nodes are connected to each other. The extension of this file is .edg.xml. Each edge is unidirectional and starts at the "from"-node and ends at the "to"-node. For each edge, some further attributes should be supplied, being the number of lanes, the edge has (numLanes), the maximum speed allowed on the edge speed. Furthermore, the priority may be defined optionally. (Refer:

Figure 3‑14: Edge file

Step 3: Open Command Prompt and change the directory to the binary folder of sumo using cd command. “cd C:\Program Files (x86)\Eclipse\Sumo\bin”

Figure 3‑15: Open command prompt in installation directory

Step 4: Generate Network file by using NETCONVERT command. Make a folder named like VANET_Example and place the. nod.xml and .edg.xml files i.e. NODES.nod.xml and EDGE.edg.xml respectively.

netconvert --n “\<path where the.nod.xml file is present>\\<filename>.nod.xml” --e “\<path where the .edg.xml file is present>\\<filename>.edg.xml” --o “\<path where both input files are present>\\<filename>.net.xml”

Figure 3‑16: Generating Network file by using NETCONVERT command

Step 5: Create a .rou.xml file that describes the direction of the vehicle’s movement.

Figure 3‑17: Direction of the vehicle’s movement

Step 6: Create a sumo configuration file file using any code editor (like notepad, notepad++ etc.) and the extension is. sumo.cfg. Place the file inside the same folder where the network file (i.e. and route file (i.e. VEHICLES.rou.xml) are present.

Figure 3‑18: Sumo configuration file

Step 7: Now open “New Simulation à VANET”. Choose the Configuration.sumo.cfg from the specified folder and run simulation using NetSim.

How to include Roadside Units (RSU’s) in a VANET network?#

Upon importing a sumo network configuration into NetSim, roads and vehicles are automatically added in NetSim as per the configuration done in SUMO.

Figure 3‑19: Importing a sumo network configuration into NetSim

Road Side Units can be optionally included in the network by manually clicking and dropping the RSU icon from the ribbon.

Figure 3‑20: RSU icon from the ribbon

RSU’s should be connected using Adhoc links manually.

Figure 3‑21: NetSim Design Window

Traffic can be configured between RSU’s and vehicles via Application configuration.

Reference Documents#

  • IEEE 802.11p 2010. Wireless Access for Vehicular Environments

  • IEEE1609: Standards for Wireless Access in Vehicular Environment > (WAVE)

Latest FAQs#

Up to date FAQs on NetSim’s VANETs library is available at


[1] C. Bhat, "Evaluation of Routing Protocols for Vehicular Ad hoc Networks (VANETs) in Connected Transportation Systems," D-STOP, University of Texas at Austin, Austin, 2018.