Simulator usage

This section describes all the simulator parameters and how to interpret output files.

Simulation parameters

The modification of the simulator implements an emergency scenario in which a platoon of vehicles moves in a highway and, at a certain point, brakes down to a complete stop. This permit to analyze the benefits and the impact on the network of a VANET safety application (EEBL). You can customize the scenario by changing some parameters (e.g., disable communications, chane transmission power, etc...) which are:

  • -time: sets the (maximum) duration of the simulation in seconds. In this particular implementation, the simulation terminates when all vehicles have a speed lower than 1 m/s (default 1);
  • -run: sets the run number. This changes the seed of the simulation (default 1);
  • -vn: sets the number of vehicles per lane. Notice that the leader of each lane is automatically inserted, so if you want 50 vehicles you need to set this parameters to 49 (default 9);
  • -maxdecel: enable (1) or disable (0) the LIDM model, which introduces the physical limit of maximum car deceleration (default 0);
  • -decel: set the constant acceleration (in m/s^2) that the leaders of the platoon apply in order to simulate the emergency brake. It must be inserted as a negative acceleration (default -4);
  • -fp: set the file prefix for output files (default "");
  • -d: set the output directory (default "./");
  • -dt: set the time step in seconds of the simulation, i.e. the update time of the position of the vehicles (default 0.1);
  • -randv: if set to 1, uses a random desired speed for each driver (i.e., average speed ± 15%), if set to 0 all drivers will have the same desired speed (default 1);
  • -randt: if set to 1, uses a random time headway for each driver (between 0.1 and 1.1) in order to reproduce different driving styles (default 1);
  • -v: enable (1) / disable (0) verbose output, which can be useful for debugging (default 0);
  • -vel: sets the average desired speed in m/s;
  • -eebl: enable (1) / disable (0) 802.11p-based communications, including beaconing and EEBL protocol (default 0);
  • -cc: enable (1) / disable (0) the CACC, for automatic braking mechanism (default 0);
  • -rebr: enable (1) / disable (0) the EEBLR protocol. Notice that the -eebl option must be enabled and the -aggr must be disabled (default 0);
  • -aggr: enable (1) / disable (0) the EEBLA protocol. Notice that the -eebl option must be enabled and the -rebr must be disabled (default 0);
  • -uneq: enable (1) / disable (0) unequipped vehicles. Clearly this make sense when -eebl option is enabled (default 0);
  • -eqrate: when the -uneq option is enable, specifies the percentage of equipped vehicles (e.g., -eqrate=0.25 sets (randomly) one equipped vehicle every four) (default 0.10);
  • -ln: sets the number of lanes per direction (default 1);
  • -lc: enable (1) / disable (0) the MOBIL lane change model (default 0);
  • -opp: enable (1) / disable (0) the opposite direction (default 0);
  • -txpw: sets the transmission power in dBm (default 20);
  • -tld0, -tld1, -tld2, -tln0, -tln1, -tln2, -tll0: the ThreeLogDistance propagation loss model has been employed in this simulation. These options set the d0, d1, d2, n0, n1, n2 and L0 parameters of the path loss model (see the ns-3.9 documentation for further details) (default 1, 200, 500, 1.9, 3.8, 3.8, 46.6777);
  • -nak: enable (1) / disable (0) the nakagami fading (default 0);
  • -nakm0, -nakm1, -nakm2, -nakd1, -nakd2: if the -nak option is enabled, these options set the m0, m1, m2, d1 and d2 parameters of the nakagami fading model (see the ns-3.9 documentation for further details) (default 1.5, 0.75, 0.75, 80, 200);
  • -cph: if set to 1, mantains the leaders of the forward moving platoon compact together, so that no follower can overtake them (default 1);
  • -testp: enable (1) or disable (0) the test protocol which sends 2 beacons per second. It is incompatible with EEBL protocols, so when TestProtocol is enabled, EEBL protocols MUST BE DISABLED (default 0);
  • -phy: select the wifi PHY implementation to be used: 'y' for the YansWifi implementation already included in ns-3, 'p' for the PhySim implementation (website). Notice that to use the latter you need to download and install the PhySim extension since it is not included in ns-3. By default, the simulator will not compile the PhySim component, assuming you do not have it (so by setting -phy=p the simulator will terminate with an error). If instead you need to use it, just comment the preprocessor directive #define _DISABLE_PHYSIM_ 1 in GenericWifi.h and build the application as described in the downloads section (default 'y');
  • -do: comma-separated list of output statistics (and files) to disable. In particular:
    1. 0: .distances
    2. 1: .decelerations
    3. 2: .crashes
    4. 3: .packets
    5. 4: .crashinfo
    6. 5: .msgcount
    7. 6: .fmsgcount
    8. 7: .dmsgcount
    9. 8: .log
    10. 9: .emsgcount
    The default value is "": no output is disabled.
  • Output files

    The output files briefly described in the Downloads section are text files containing simulation data that can be processed in order to obtain statistics. They contain a set of rows, each of them made by a set of pipe-separated fields, described here.

    .log

    It contains the traces of position, speed and acceleration of each vehicle recorded during the simulation. In particular:

    Field Description
    1 Run number
    2 Time (ms)
    3 Vehicle id
    4 Direction (1 for forward, -1 for reverse)
    5 Lane number (0 based)
    6 Position (m)
    7 Speed (m/s)
    8 Acceleration (m/s^2)

    .distances

    Contains the distances between vehicles at the end of the simulation. This was originally though to analyze benefits in terms of distance between vehicles after an emergency brake. In it are contained the following fields:

    Field Description
    1 Run number
    2...n Distance between two vehicles (m)

    .deceleration

    Contains the maximum deceleration reached by each vehicle. This was originally though to analyze benefits in terms of maximum deceleration after an emergency brake. In it are contained the following fields:

    Field Description
    1 Run number
    2...n Maximum deceleration (in fact, minumum acceleration) of a vehicle (m/s^2)

    .crashes

    Contains the number of pile-ups and the number of vehicles involved in each pile-up. In it are contained the following fields:

    Field Description
    1 Run number
    2 Number of pile-ups (a 2 cars collision is also intended as pile-up)
    3...n Number of vehicles involved in each pile-up

    .crashinfo

    Contains more detailed information about crashes, in particular one line for each vehicle. A row is written for a vehicle even if it has not crashed. In it are contained the following fields:

    Field Description
    1 Run number
    2 Vehicle id
    3 Equipped with 802.11p wireless card (1) or not (0)
    4 Outdated CACC data (1) or not (0). This tells if, at the time of the crash, the CACC was outdated: if the CACC has no "fresh" data to work with, it cannot make any decision, so the crash is not due to it. If the car has not crashed, this field is set to 0
    5 Crashed (1) or not (0)
    6 Collision with front vehicle. This field is set to 1 if the car bumped into its leader, 0 otherwise
    7 Collision with following vehicle. This field is set to 1 if the following car bumped into this vehicle, 0 otherwise. Notice that if this vehicle is inside a pile-up, both fields 6 and 7 could be set to 1

    .packets

    Contains the list of packets sent and received during the whole simulation. In it are contained the following fields:

    Field Description
    1 Run number
    2 Send time (micros). Notice that this field indicates when the protocol passes the message to the MAC layer, so it accounts also for possible backoffs: it is not the actual PHY send time
    3 Packets id
    4 TTL (hops)
    5 Sender vehicle id
    6 Type (0 for beacon, 1 for EEBL, 2 for aggregated EEBLs)
    7 Reception time (micros). Notice that this field indicates when the MAC layer passes the message to the upper protocol, so in the case of a deferred transmission due to contention, receive time minus send time WILL NOT tell you the transmission duration. Moreover this is the time when the first receiver in the receivers list (see field 9) got the packet. BE AWARE of the fact that if this packet has not been received by any node (i.e., the receivers list is empty), this field will be present anyhow, but it MUST be ignored
    8 Transmission duration (micros). This was originally thought to determine the actual send time (receive time - duration) but this is the duration of the PHY transmission and it does not account for additional times such as backoffs or IFS which, from a MAC layer point of view represent channel busy time. This field is present but not used anymore (set to 0)
    9...n Receivers list. Every vehicle that received this packet has its own id in this list. This strategy has been chosen because the output file would have become too large: writing a line for each receive event is somehow "verbose" and having the precise receive time is not needed since the difference is in the order of nanoseconds (i.e., propagation time)

    .*msgcount

    These files contains the sampling of the number of messages received by each vehicle, in particular total (.msgcount), duplicated (.dmsgcount), EEBL (.emsgcount) and from front vehicle (.fmsgcount). Their fields are:

    Field Description
    1 Run number
    2 Sample time (ms). Each sample is taken every one second of the simulation
    3...n Count of messages (cumulative) for each vehicles