# An Adaptive Scheduling Mechanism Optimized for V2N Communications over Future Cellular Networks
## 3 The Key Features of the SOVANET Algorithm
To achieve this, we introduce the following two steps in our implementation. The first is to separate the UCs into critical and non-critical, and the second is to maximize the performance of critical UCs and at the same time provide a minimal amount of resources for the rest. To evaluate the performance of SOVANET, the PF scheduler is used as the baseline. The PF scheduler is a throughput-fairness compromise-based scheduling algorithm trying to balance two competing interests. The scheduler aims at maximizing throughput for those UEs with the highest channel quality indicator (CQI) value and at the same time allowing all remaining UEs a minimal level of service. In our simulation scenarios, we have used the PF implementation of ns3::NrMacSchedulerNs3 class [22]. The ns3 PF implementation has been extended with steps 5 and 6 (Figure 1) to create the SOVANET scheduler. According to the overall SOVANET scheme a list of active UEs, along with their respective requirements, are initially used to update the UEs map, assigned to specific Logical Channels (LCs) and Logical Groups (LGs). What follows is an update of the Buffer Status Report (BSR) and UL and DL CQI calculations. In our implementation, the novelty introduced is related to the service-specific allocation of resources and the differentiation between the UL and DL resource allocation. A weight factor, denoted as \"alpha\" is introduced, which is defined concerning the network load and is used to provide more resources per service, compared to what is requested, for critical services (e.g., ToD, HDM). Similarly, a weight factor \"beta\", related to the overall network load is used to allocate fewer resources in the case of non-critical BSM services. When both factors are set, the number of bytes per LC is calculated and assigned. Steps 7-10 of the implementation follow the PF scheduler design [23]. The number of bytes per LC for the critical services is calculated using the throughput formulae:  
\[x_{i}=alpha\times load\times(\text{TBS/activeLC}) \tag{1}\]  
where: \(x_{i}\) is the user's throughput, \(alpha\) is the weight factor, \(load\) is the network load, TBS is the Traffic Block Size and activeLC is the active Logical Channel used. The weight factor alpha is expressed as a percentage of the network load and its adaptation according to the network load in the UL and DL sessions can be found in Figure 2. The values selected for this factor have been the result of extensive simulations. For instance, in the UL for an overall network load of 200 Mbps the alpha factor is 5% and in the DL for the same load, the alpha is 0.5%. For the case of a modest network load of 50 Mbps the alpha factor is set at 15% for the UL and 1.5% for the DL. The relation between the alpha factor and the network load can be approximated and expressed as an exponential equation: \(alpha=0.2121\times e^{-0.007\times load}\) for the UL and \(alpha=0.0194\times e^{-0.007\times load}\) for the DL. It can be observed that the alpha factor is reduced as the network load increases; the maximum allocated resources should not exceed the available resources. The beta weight factor is calculated and appointed to all non-critical BSM services in all load scenarios, as the 0.5% of the overall network load, as the requirements for the UL and DL of the BSM UC are particularly low (in the order of 8 kbps).