# An Adaptive Scheduling Mechanism Optimized for V2N Communications over Future Cellular Networks
## 3 The Key Features of the SOVANET Algorithm  
Network-related requirements for advanced driving UCs can be found in 5 GAA's report [8]. This report analyzes the spectrum needs of UCs for intelligent transport systems (ITS) and advanced driving, as implemented by C-V2X technologies. A list of over 40 UCs is categorized as either \"initial/day-1\" or \"advanced\". According to 5 GAA, LTE-V2X and NR-V2X are the most suitable technologies for the support of day-1 ITS and advanced driving UCs, respectively. However, when investigating advanced autonomous driving services, the requirements become much more challenging even for 5G networks. For the design of SOVANET and its performance analysis we have chosen two demanding autonomous driving services, namely:  
* Teleoperated Driving (ToD): a service that assists, complements, and accelerates semi- and fully automated driving in various scenarios. It is considered a V2N service, as the server for this application will be located at the northbound interface, the edge or even the core network of an operator. This service is delay sensitive with significant throughput requirements on the UL. * High-Definition Mapping and Sharing (HDM): a service where vehicles equipped with LIDAR or other HD sensors collect and share environment information with a high-definition map provider, which then builds high-definition maps and shares them with vehicles. This service is expected to support the development of higher automated driving levels in the future. It is another V2N delay-sensitive service with significant throughput requirements on both the UL and the downlink (DL). These two services are critical as a non-optimum performance would significantly impact the perceived QoS and more importantly road safety. For our analysis, these services have been combined with a generic day 1 non-critical service relying on BSM, which are continuous messages that are typically repetitive and tend to support all types of broadcast communications. The key characteristics for all the above-mentioned UCs can be found in Table 1. For ToD, we have assumed in the UL 2 video streams of 8 Mbps each, while for the case of DL, 400 kbps. Similarly, we considered only sensor-oriented data for the HDM service, which requires 4 Mbps on the UL, and 16 Mbps on the DL. Lastly, for the BSM service, both the communication streams on the UL and DL are modeled as 8 kbps-bitrate flows. All values are taken by [8], where additional information can also be found. This document categorizes ToD and HDM services as delay-sensitive and BSM as non-delay-sensitive. Moreover, in [4] an end-to-end delay of 5 ms for ToD and 10 ms for HDM is identified. BSM end-to-end delay of 100 ms is typical for non-critical applications. In our analysis, the critical ToD UL and HDM DL were implemented using large packet sizes of 10 kbytes and a packet transmission interval of 5 ms.  
As mentioned before, targeting to address the demanding requirements of Table 1, we propose a novel scheduler called SOVANET. In the following paragraphs, we present the scheduler implementation and analyze its performance in four data traffic scenarios \begin{table}
\begin{tabular}{c c c} \hline \hline
**UC** & **Throughput** & **Delay** \\ \hline ToD & 400 kbps (DL) & 5 ms \\ HDM & 16 Mbps (DL) & 10 ms \\ BSM & 4 Mbps (UL) & 100 ms \\ \hline \hline \end{tabular}
\end{table} 
Table 1: UCs requirements. of 10, 25, 40, and 60 vehicles. As the number of vehicles increases, the number of vehicles using critical ToD and HDM UCs is linearly increasing reaching a point where these services are becoming unsupportable. The main idea behind the implementation of our scheduler is to take into account the highly varying overall network load, created by V2N services, and allocate the available resources prioritizing critical services such as ToD and HDM and, respectively, deprioritizing the allocation of resources to non-critical UCs like BSM. Therefore, develop a scheduling mechanism that considers the network load and the services' requirements.