## 4 Performance Evaluation
### LTE Mode 4
#### 4.1.1 OMNeT++ Simulation Tool  
The open source tool openCV2X [19], based on the discrete event simulator OMNeT++ [22], is used to carry out LTE-V2V mode 4 simulations. In turn, openCV2X is based on the simuLTE [23] tool defined for enabling complex system level performance-evaluation of LTE and LTE Advanced networks.  
Additionally, openCV2X needs other add-ons in order to function properly:  
* INET [24]--an open source framework for OMNeT++ that provides libraries for wired and wireless networks.
* VEINS [25]--an open source framework to generate simulations of vehicular networks.
* SUMO [26]--an open source road traffic simulator.  
OpenCV2X is developed based on the 3 GPP specifications as described in the previous section. First, the vehicles are placed on the road at a given density. A 500 s is considered at the beginning of the simulation in order to reach a stabilization of the scenario before proceeding with the inter-vehicle communications. Then, 12 s simulations are set up taking into account different conditions such as different packet transmission rates, density of vehicles on the road and transmission powers.  
Figure 6 shows a flow chart with the main steps that are followed to obtain the results. In order to prevent all vehicles from transmitting the first message at the same time, a delay varying from 0 to 1000 ms is configured in the first packet. Then, all vehicles transmit and receive alert messages based on the resource selection and congestion control processes defined for mode 4. CAM packets of 190 bytes are sent in multicast mode with different transmission frequencies. To determine the number of RBs to be used to transmit each packet, both the MCS and the packet size are considered. Thus, the TB defines the number of RBs needed to transmit each packet. To this number of packets must be added the 2 RBs needed to transport the SCI (i.e., adjacent PSCCH/PSSCH). To obtain the PSSCH-RSRP, Power Spectral Density (PSD) of the RBs is multiplied by the bandwidth of each Resource Element (RE). Thus, the PSSCH-RSRP is calculated as the average power for each RE assuming that the power is equally distributed over all the REs. On the other hand, for the RSSI calculation, power noise and interference are considered for each RB. Thus, RSSI is equal to the sum of the received power per RB multiplied by the total number of transmitted RBs.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Carrier frequency & 5.9 GHz [21] \\ Channel bandwidth & 10 MHz [21] \\ Packet size & 190 Bytes [21] \\ PSCCH, PSSCH & Adjacent \\ Simulation time & 12 s \\ Vehicle density & 0.06, 0.12 vpm \\ Sensing window & 1000 ms \\ ProbResourceKeep & 0.4 \\ SubChannel size & 14 \\ Num. SubChannels & 2 \\ RSRP threshold & \(-\)128 dBm \\ RSSI threshold & \(-\)92 dBm \\ \hline \hline \end{tabular}
\end{table}
Table 3: Reference parameters for simulations.  
An important consideration to take into account in the simulations is that if an SCI is not properly received, the TBs associated with that SCI must be discarded, since they cannot be decoded correctly, i.e., the corresponding SL information is missing. In this paper, we have considered only PDR as a metric to analyze the reliability of centralized and decentralized modes under different ranges of coverage in diverse scenarios. However, in a future work, we plan to also analyze metrics such as latency and transmission rates in MR-DC scenarios. In these cases, a variation of communication latency is expected due to the use of different radio access technologies and communication interfaces. On the other hand, transmission rates are expected to improve due to the use of simultaneous communications between different technologies.  
After performing several simulations in different scenarios, the data is obtained and then processed using Python.