# 5G V2X System-Level Architecture of 5 GCAR Project
## 4 Detailed Analysis of Selected Features
### Multi-Operator Solutions for V2X Communications  
It is a valid assumption that V2X communication is going to be a multi-operator environment since it cannot be guaranteed that only one operator is going to coordinate the vehicular interactions in the overall area. This assumption has been accepted by various organizations [29; 30] and is the working assumption in order to make a V2X system operating, under the considered V2X requirements. Multi-operator V2X has implications in the communication via both PC5 and Uu interfaces, as well as in the use of edge computing. Solutions available in the literature can be based on the use of the already available Uu interface and use of existing data paths, where the data for the two devices attached to different operators need to cross all domains (i.e., access, backhaul, and core) of the two operators, incurring a delay that is not acceptable for most of the cases of V2X communication. On the other hand, the use of SL (i.e., PC5) interface requires coordination among the operators on the use of spectrum resources for ensuring proper reception of the information--without necessarily ensuring high reliability if the communication takes place in an uncoordinated manner (Mode 4 PC5). Other solutions can rely on use of schemes that facilitate the use of both interfaces but require either RAN sharing among the operators or to force the devices to roam from one operator to the other. The first approach which is based on RAN sharing requires agreements in all the coverage areas so as to ensure proper operation of the network whereas the other based on force roaming introduces unacceptable delays for the transition from one operator to the other because of the required attachment procedure. When edge computing is considered the previous problem is even more complex. Multi-operator V2X communication using PC5 may happen using:  
1. Mode 1/3 by applying: \[ \begin{array}{ll}\bigcirc&\text{Shared carriers, which may face synchronization problems (can be handled with global clock such as GLONASS) and resource overlap. Resource overlap can be solved by applying resource split in TDM way. \[\bigcirc&\text{Separate carriers, which do not face resource collision between different PLMNs but require carrier switching (with interruption and delay) or multiple Rx chains (which increases the cost). 2. Mode 2/4 by applying: \[\bigcirc&\text{Shared carriers, which also may face synchronization aspects which can be handled by applying a global clock such as GLONASS. In this case static configuration is used requiring updates in special cases such as the cross-border situations or when the spectrum pools are reconfigured. \[\bigcirc&\text{Separate carriers, which is based on static configuration--updates may be required in cross border cases. Carrier switching, in this case, requires a well (with interruption and delay) or Multiple Rx Chains (costly). \\ \end{array} \]  
The above cases should also include the case of PC5 in an unlicensed or licensed spectrum (which would need agreements among MNOs in case of shared carrier). In any case, the configuration should be static or updates every time a reconfiguration occurs are needed. Also, it has to be stated that the reconfigurations, and the carrier switching come with delays that may hinder meeting the requirements in particular cases. It has to be noted that in case of shared carriers in licensed spectrum agreements between operators are needed. Multi operator V2X communication using Uu may happen using:  
* Typical Uu communication through normal UPF functions (i.e., home routing)
* Local breakout schemes to communicate with vehicles of the other operator. This solution requires implementations with local breakout dependent on the topology (e.g., gNBs in the highway should have access to it) thus increasing the complexity.