# Performance Analysis of Existing ITS Technologies: Evaluation and Coexistence
## 3 Performance Evaluation and Comparision
### Performance Evaluation and Comparision
#### 3.3.3 Comparison of ITS Technologies: LTE-V2X/ITS-G5  
In this subsection, the results obtained previously have been used to determine the most appropriate configuration for each technology according to the different constraints (message size, density, coding). Then, based on these configurations, we compare them under the same conditions to identify their suitability to a given use case and if one technology outperforms the other.  
In the following, we consider the same simulation conditions for the different sizes of messages. Figure 11 shows the optimal configurations for a small message (packet size of 350 bytes) representing a CAM message. The comparison results focus on the range with PRR more than 90% and the update delay for 95% of all received messages. Three parts are identified:  
* The first part considers that the ITS-G5 (with MCS 4 coding) has the best performance (in the areas with densities above 220 veh/km). This result converges with the delay constraint where update delay remains better with the same MCS coding;
* The second part provides the best performance by LTE-V2X (MCS 9) and ITS-G5 (MCS 2). However, the results are pretty close in range and delay for densities around 100 to 200 veh/km;
* LTE-V2X (MCS 6) performs better in low-density areas (less than 100 veh/km) in the third part. Therefore, the coverage is favoured for this area while ensuring that the PRR is higher than 90% and has a low update delay.  
Figure 11: ITS-G5 vs. LTE-V2X comparison for packet size 350 bytes.  
Figure 10: Evaluation for LTE-V2X technology (packet size 1200 bytes).  
Contrary to previous results, the comparison between ITS-G5 and LTE-V2X for a medium packet size of 800 bytes supporting DENM messages shows trade offs between range and update delay. In this context, two approaches have been identified:  
* The first approach is range-oriented, which supports use cases that demand strict performances in high density;
* The second approach is delay-oriented, which minimises the update delay for C-ITS applications with high delay requirements.  
According to the first approach, Figure 12 shows a better performance for ITS-G5 (MCS 2) in terms of range on higher densities (above 200 veh/km), against the superiority of LTE-V2X (MCS 9) for lower densities (below 200 veh/km) which can reach 200 m. On the other hand, these MCSs present high updates delays. However, for a scenario requiring more strict delay requirements, as presented in Figure 12, the second approach reduces the update delay for each technology with MCS 4 for ITS-G5 and MCS 13 for LTE-V2X against considerable attenuations in terms of range.  
The configuration with high MCS increases the channel capacity to support more data. Therefore, ITS-G5 with MCS 4 and LTE with MCS 13 show the best performance for data with a significant message size of 1200 bytes. Figure 13 shows that ITS-G5 overcomes LTE-V2X for high densities (more than 200/250 veh/km) against an update delay favouring LTE-V2X and vice versa for low densities.  
The obtained results allow assessing the behaviour of both technologies under the same conditions. LTE-V2X shows a better range at low density than ITS-G5. Still, ITS-G5  
Figure 12: ITS-G5 vs. LTE-V2X comparison for packet size 800 bytes.  
Figure 13: ITS-G5 vs. LTE-V2X comparison for packet size 1200 bytes.  
offers a very high capacity to support increased traffic load in high-density scenarios while ensuring that the PRR is always above 90%. The update delay is represented for 95% of all received messages, where it increases not only with density but also with packet sizes. Although the ITS-G5 has a high capacity due to the MCS 4 coding, which provides the best update delay, LTE-V2X also performs well for large messages in dense scenarios due to its SPS procedure. According to the obtained results, there is a trade off between technologies depending on the density level.