# On the Rollout of Network Slicing in Carrier Networks: A Technology Radar
## 6 RAN Domain
### Radio Resource Allocation
* **Relative Priority Scheduling**, which is an evolution of the previous solution. This evolution is based on enriching DRB profile characterization with additional configurable settings, including scheduling weight and scheme, among others. These settings, listed in Figure 13 with the optional \"(O)\" tag, allow the gNB scheduler to resolve conflicting situations that are beyond the capabilities of 5 QI priority scheduling. One example is when QoS flows from different slices have the same 5 QI, but there is a need for preferential treatment of one of these slices. In such a case, scheduling weight can be used, as elaborated in the top-right corner of Figure 13. \begin{table}
\begin{tabular}{c p{142.3 pt} p{142.3 pt}} \hline \hline
**Topic** & **Priority Scheduling** & **Radio Resource Partitioning** \\ \hline Solution & All slices share resources, and the slice SLA is guaranteed by increasing the scheduling priority of devices that have not reached the minimum guaranteed rate & Reserve dedicated resources and prioritized resources for specific slice(s) to ensure that devices in the slices have sufficient available at any time \\ \hline Guarantee & Best effort SLA guarantee: when the cell is congested, the SLA of some slices may not be guaranteed & Customers get accurate SLA guarantee \\ \hline Isolation & Resource sharing between slices that can only provide limited soft isolation with different priorities & Hard isolation of resources between slices avoids mutual influence across slices and provides an isolation effect similar to that of dedicated frequency \\ \hline Scenario & B2C market slicing & B2B market slicing \\ \hline \hline \end{tabular}
\end{table} 
Table 3: A comparative analysis of RAN slicing mechanisms. These two solutions build up the RAN slicing suite that operators have started to deploy, and may be operationally ready in the short term. However, with sights already set on evolving slicing features in the medium term, operators are also testing other solutions:  
* **Delay controlled Priority Scheduling**. This solution consists of enriching gNB scheduling logic with the adaptive managed latency concept. It allows providing better experience to Rel-16 services, mostly interactive services that require high data rate and low latency communications. The adaptive managed latency concept represents the ability to provide bounded and steady low latency for these services, by coupling gNB scheduler and application in a feedback loop with dynamic rate adaptation signalled by the service application. This coupling can be enforced using either vendor-specific mechanisms or standard frameworks, such as Low Latency, Low Loss, or Scalable Throughput (L4S) [62]. Figure 14 depicts how L4S congestion marking and feedback can be applied for gNB scheduling. Note that this Delay Controlled Priority Scheduling solution (application layer rate adaptation) is complementary to Relative Priority Scheduling (network layer service differentiation), and both can be used simultaneously. * **Hard Radio Resource Partitioning**. This is the first solution from the radio resource partitioning category. For the PRB allocation, this solution assumes that individual slices are only configured with dedicated resources, without prioritized resources. To achieve this, the operator sets the same value for the dedicated minimum slice quota (RRMPolicyDedicatedRatio) and the minimum slice quota (RRMPolicyMinRatio). From the set of flavours tabulated in Table 2, one can note that the RAN slices resulting from this solution are compliant with the \"dedicated slice-profile 1\" settings. This flavor provides isolation and secure resources in high load conditions, at the cost of poor multiplexing gains. The reason is that dedicated resources of a slice cannot be used by others, even though the slice resource usage is below the dedicated minimum slice quota. Figure 13: Priority Scheduling. Finally, in the long run, we can find fully-blown RAN slicing solutions.