# 5G V2X System-Level Architecture of 5 GCAR Project
## 4 Detailed Analysis of Selected Features
### Use Case-Aware Multi-RAT, Multi-Link Connectivity  
Given the diversity of use cases, a combination of links and/or RATs that could deliver the requirement of V2X use cases could also be diverse. For example, while cooperative safety is extremely time-sensitive, and the success of cooperative manoeuvre highly depends on persistent coverage, cooperative navigation is in real need of high bandwidth from the network. The selection of the best possible combination of links/RATs is also a changing choice, given the mobility of the vehicles. Use case-aware multi-RAT, multi-link connectivity is a possible solution designed in 5 GCAR to guarantee delivery of use-case specific service requirements (QoS). Due to the high mobility as well as the latency/safety-critical nature of most V2X use-cases, it is very challenging to guarantee QoS delivery for the whole duration of the use-case. Use-case aware, in this context, refers to differences in characteristics and demands of different use-cases. For example, in the class of cooperative safety use-cases, persistent coverage during the time period of the use-case is very important to be guaranteed. While in the class of cooperative perception use cases, providing high data rates might be challenging especially in a highly congested network. The option of having multi-RAT, multi-link connectivity, would provide higher network availability via spanning radio resource pool and exploiting it in two forms multiplexing or diversity gain. Some scenarios are, for instance, simultaneous connection to two BSs (when this type of connection is supported) and sending the same packets (diversity gain) or different packets (multiplexing gain) on both links, or even in case where multi-connectivity is not supported, the possibility of selecting the best link/RAT among all possible options would provide link quality enhancement by exploiting diversity gain. To be able to use this component, we assume the following: (i) vehicles/UEs are capable of simultaneous connection to more than one link either within one RAT or to different RATs; (ii) communication network support of multi-link/RAT connectivity through information exchange and coordination between protocol stacks of different RATs e.g., LTE, NR; and (iii) a coordinator entity, located within the domain of the MNO the UE is attached to and managing available links/RATs, is responsible for determining the type of multi-link/RAT connectivity for the involved vehicles/UEs. To evaluate each combination of links/RATs for each use case, in the first step, the concept of \"action\" should be defined: action is intended as a series of V2X communications with pre-defined QoS requirements to enable successful delivery of the use-case. In this context, \"completion of action\" refers to the successful delivery of the use-case. Therefore, the evaluation should be based on completion of action rather than per-packet analysis of QoS. For instance, a specific type of connection may fail to deliver QoS requirements for some periods of time during the manoeuvre, but it may still be able to provide enough resources for the manoeuvre completion since small periods of service un-availability would not cause a serious problem. The second step is to consider the \"completion time\" of the action. There are two scenarios in this step:  
* The use-case requires V2X communication of a pre-defined period of time. * The completion time of the use-case depends on some parameters such as the current location and speed of vehicles as well as the intended type of multi-link/RAT connectivity. However, there is probably an upper bound limit for the completion time defined by the use-case. If none of the available multi-link/RAT connectivity is able to complete the action before the deadline, the use-case will be declared as unavailable by the coordinator. In the case of the first scenario, the coordinator does not need to compute the time to completion and thus, can proceed to the third step.