# 5G V2X System-Level Architecture of 5 GCAR Project
## 4 Detailed Analysis of Selected Features
### Evolution of Infrastructure-Based Communication for Localised V2X Traffic  
In many V2X use cases (e.g., cooperative manoeuvres, sensor information sharing, video sharing, and intra-platoon communication) the data traffic that is exchanged among vehicles (V2V) has localized significance. This means that the communicating vehicles that participate in the same use case are located in the same geographical region and there is no need to access a remote server, (e.g., V2X Application Server, and ITS cloud server), while multiple transmission modes (unicast, broadcast, and multicast) might be required. For localized V2X communications, either the cellular (Uu) interface or the sidelink (PC5) interface could be used considering the radio conditions and the environment where the V2V use case takes place. Specifically, the NR-Uu interface could provide guaranteed QoS (i.e., high reliability and low latency) especially in the case of, e.g., no line-of-sight among communicating vehicles, poor PC5 radio conditions, or high PC5 interference due to vehicles' high density. Nevertheless, existing cellular solutions, based on the Uu interface, may need some updates for supporting in a more efficient way the challenging performance requirements that localized V2X services have, which include the need for fast and guaranteed transmission of localized data. In the existing 3 GPP procedures, the control plane latency for establishing a new bearer is significantly larger compared to the requirements of many V2X use cases [24] since core network entities are involved in the establishment of bearers, which increases the required communication and processing delay. More than 130 ms (control plane latency) are needed for the establishment of required bearers for a group of vehicles that participate in the same V2X service, when the vehicles are not connected to a BS (Radio Resource Control - RRC IDLE state) [25]. If the vehicles are connected to the same BS (i.e., can directly ask for resources) the control plane latency is higher than 80 ms [25]. Thus, these large control plane latency values are not appropriate for many V2X use cases. The introduction of new state models for the radio access networks, called \"connected inactive\", where both the user equipment and the network maintain context information, enabling the quick and lightweight transition from inactive to active data transmission, could support the fast connection establishment problem [26]. The proposed \"connected inactive\" could contribute to the reduction of the total control plane latency, but it is not enough since the delay for adding new bearers, especially for services, where a group of devices participates, remains high (i.e., more than 80 ms). The formation of local end-to-end (E2E) radio data paths over the Uu interface, could be used to enable the fast and guaranteed transmission of localized data traffic among the involved devices, satisfying their QoS requirements and the features of the V2X services, as initially presented in [27]. The \"end-to-end\" term denotes that the (user plane) radio data paths are established among the involved communicating end devices (i.e., vehicles), while the \"local\" term denotes that the paths are established via the BSs. Instead of using solutions such as local UPFs providing a local UP end-point instead of reaching the UPF within the core, the focus of this TC is that the nodes of the core network do not participate in the user plane transmissions since the data traffic is localized and handled directly among involved BSs. Local e2e paths via the BS can support different communication modes (unicast, multicast, and broadcast) without the need to interact with other entities such as MBMS. Although, according to the proposed solution the data traffic does not pass through core network nodes, online and offline charging methods could be used and specifically with the support of the charging function (CHF) of the 5G system architecture.