Model Features

Implementation of the 802.11p in NetSim

  • The Ad hoc 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 5MHz, 10 MHz, 20MHz in the 5.9 GHz band

  • Supported PHY rates are as follows:

  • 1.5, 2.25, 3, 4.5, 6, 9, 12 and 13.5 Mbps for 5MHz

  • 3, 4.5, 6, 9, 12, 18, 24 and 27 Mbps for 10MHz.

  • 6, 9, 12, 18, 24, 36, 48 and 54 Mbps for 20MHz.

  • The PHY rates for IEEE 802.11p in NetSim are determined from the MCS tables of IEEE 802.11-OFDM (provided below). The receiver measures the received power and is assumed to transmit this information to the transmitter instantaneously and out of band. The transmitter compares the received power to the receiver sensitivity and selects the MCS where the received power meets or exceeds the sensitivity.

MCS Index

Receiver Sensitivity (dBm)

Data Rate (Mbps)

Modulation Technique

Coding Rate

1

-88

1.5

BPSK

1/2

2

-87

2.25

BPSK

3/4

3

-85

3

QPSK

1/2

4

-83

4.5

QPSK

3/4

5

-80

6

16_QAM

1/2

6

-76

9

16_QAM

3/4

7

-72

12

64_QAM

2/3

8

-71

13.5

64_QAM

3/4

Table-1: MCS table for 5 MHz bandwidth

MCS Index

Receiver Sensitivity (dBm)

Data Rate (Mbps)

Modulation Technique

Coding Rate

1

-85

3

BPSK

1/2

2

-84

4.5

BPSK

3/4

3

-82

6

QPSK

1/2

4

-80

9

QPSK

3/4

5

-77

12

16_QAM

1/2

6

-73

18

16_QAM

3/4

7

-69

24

64_QAM

2/3

8

-68

27

64_QAM

3/4

Table-2: MCS table for 10 MHz bandwidth

MCS Index

Receiver Sensitivity (dBm)

Data Rate (Mbps)

Modulation Technique

Coding Rate

1

-82

6

BPSK

1/2

2

-81

9

BPSK

3/4

3

-79

12

QPSK

1/2

4

-77

18

QPSK

3/4

5

-74

24

16_QAM

1/2

6

-70

36

16_QAM

3/4

7

-66

48

64_QAM

2/3

8

-65

54

64_QAM

3/4

Table-3: MCS table for 20 MHz bandwidth

  • Transmission type is OFDM

  • with slot time equal to 9 μs and SIFS equal to 16 μs for 20 MHz

  • with slot time equal to 13 μs and SIFS equal to 32 μs for 10 MHz

  • with slot time equal to 21 μs and SIFS equal to 64 μs for 5 MHz

  • 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 application. 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

_images/Figure-111.png

Figure-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. The 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 vehicle 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 a 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 ad hoc/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 randomtrips.py to configure road traffic models

Netedit is a road network editor for the road traffic simulation in SUMO. This utility enables users to efficiently design road networks and generate the corresponding network XML file, which is an essential component of the 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: "https://sumo.dlr.de/docs/Netedit/index.html” for more details on modes of operation.

_images/Figure-210.png

Figure-2: SUMO NetEdit New Network Screen

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

_images/Figure-310.png

Figure-3: SUMO NetEdit Screen

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

_images/Figure-44.png

Figure-4: 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.

_images/Figure-51.png

Figure-5: 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.

_images/Figure-61.png

Figure-6: Adding Traffic Signal to Network

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

_images/Figure-71.png

Figure-7: 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 network.net.xml

_images/Figure-81.png

Figure-8: network.net.xml 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 randomtrips.py utility present in <SUMO_INSTALL_DIRECTORY>/tools directory create trips file with the command.

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

Example Command >" C:\Program Files (x86)\Eclipse\Sumo\tools\randomTrips.py" -n "network.net.xml" -e 5 --route-file "trips.xml"

_images/Figure-91.png

Figure-9: Generating route file (trips.xml)

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

Step 11: Create a “file-settings.xml” file in your folder which contains the network and route file for improving the visualization of vehicles and their movements in a graphical user interface (GUI).

Following is a “file-settings.xml” file:

<viewsettings>

<scheme name="NetSim_VANET">

<vehicles vehicleQuality="2" vehicle_exaggeration="4.00">

</vehicles>

</scheme>

<delay value="500"/>

</viewsettings>

Step 12: 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.

Refer: http://sumo.dlr.de/wiki/Tutorials/Hello_Sumo

Include parameter (To Run in NetSim)

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

Following is a sample SUMO Configuration:

<configuration>

<input>

<net-file value="network.net.xml"/>

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

<gui-settings-file value="file-settings.xml"/>

</input>

<time>

<begin value="0"/>

<end value="100"/>

<step-length value="0.4"/>

</time>

</configuration>

NOTE: Save above content as Configuration.sumo.cfg

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

_images/Figure-101.png

Figure-10: 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.

_images/Figure-112.png

Figure-11: 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.

_images/Figure-121.png

Figure-12: Importing a sumo network configuration into NetSim

_images/Figure-131.png

Figure-13: 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: https://sumo.dlr.de/wiki/Networks/PlainXML#Node_Descriptions).

_images/Figure-141.png

Figure-14: 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: https://sumo.dlr.de/wiki/Networks/PlainXML#Edge_Descriptions).

_images/Figure-151.png

Figure-15: 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”

_images/Figure-161.png

Figure-16: 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”

_images/Figure-171.png

Figure-17: Generating Network file by using NETCONVERT command

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

_images/Figure-181.png

Figure-18: Direction of the vehicle’s movement

Step 6: Create a sumo configuration 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. NETWORK.net.xml) and route file (i.e. VEHICLES.rou.xml) are present.

_images/Figure-191.png

Figure-19: 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 (RSUs) 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.

_images/Figure-201.png

Figure-20: Importing a sumo network configuration into NetSim

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

_images/Figure-211.png

Figure-21: RSU icon from the ribbon

RSUs should be connected using ad hoc links manually.

_images/Figure-221.png

Figure-22: NetSim Design Window

Traffic can be configured between RSUs and vehicles via Application configuration.

Radio measurement log file and plots

NetSim IEEE 802.11 Radio Measurements log file records pathloss, shadowing loss, fading loss, received power, transmitted power, SNR, and BER. This log can be enabled by clicking on configure reports in top ribbon > Plots > Select IEEE 802.11 Radio Measurements log under Network Logs as shown below

_images/Figure-231.png

Figure-23: Enabling IEEE 802.11 Radio Measurements log for VANETs

The IEEE802.11 Radio Measurements log.csv file will contain the following information:

  • Time in Milliseconds

  • Transmitter Name

  • Receiver Name

  • Distance between the Transmitter and the Receiver in meters

  • Packet ID

  • Packet Type

  • Control Packet Type

  • Transmitter Power in dBm

  • Pathloss in dB

  • Shadowing Loss in dB

  • Fading Loss in dB

  • Total Loss in dB

  • Transmitter Antenna Gain in dB

  • Receiver Antenna Gain in dB

  • Received Power in dBm

  • Interference in dBm

  • SNR in dB

  • SINR in Db

  • NSS (Number of Spatial Streams)

  • BER

  • MCS Index

The log file can be accessed from the Simulations Results Window under the logs as shown below.

_images/Figure-241.png

Figure-24: Opening IEEE 802.11 Radio Measurements log from simulation results window.

_images/Figure-251.png

Figure-25: IEEE 802.11 Radio Measurements log file.

Enabling the plots is explained in the above section. Here is the plot showing the transmit energy vs. time for an DSR scenario with five vehicles.

_images/Figure-261.png

Figure-26: Plot of Transmit Energy vs Time for VANET