# Assessing the Cloud-RAN in the Linux Kernel: Sharing Computing and Network Resources
## 5 Assessing Resource Sharing in the Cloud-RAN Architecture
### Mobile Network Scenario  
We consider the mobile network scenario illustrated in Figure 8. This configuration features two vBBUs, denoted as vBBU1 and vBBU2, respectively. Each vBBU, deployed with distinct functional splits, operates between the DU and the CU. While vBBU1 and vBBU2 are the only applications instantiated in the DU, they share computing resources at the CU. Moreover, this network scenario involves a single UE connected to each of the vBBUs. The experimental setup for the deployment of this mobile network is summarized in Appendix A. Based on the LTE-BBU functional split model shown in Figure 2, vBBU1 adopts the functional split 7.1, while vBBU2 adopts the functional split 2. Due to split 7.1 hosting most of the BBU RT functions in the CU, vBBU1 imposes greater demands in terms of latency requirements in the Midhaul and processing capacity at the CU. In contrast, vBBU2 deploys all functions involved in the HARQ loop in the DU, making its data-rate requirements in the Midhaul network similar to those in the Backhaul. Here, latency requirements depend on the user's service. Figure 8: Mobile network scenario based on the Cloud-RAN architecture. Deploying two vBBUs with split 7.1 and split 2, respectively. The mobile transport Xhaul is based on switched Ethernet. \begin{table}
\begin{tabular}{c c c c c c c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Transed**} & \multicolumn{4}{c}{**0-1 (microseconds)**} & \multicolumn{4}{c}{**2-3 (microseconds)**} & \multicolumn{4}{c}{**4-5 (microseconds)**} \\ \cline{2-13}  & \multicolumn{3}{c}{**Shielding**} & \multicolumn{3}{c}{**isolCFU**} & \multicolumn{3}{c}{**Shielding**} & \multicolumn{3}{c}{**isolCFU**} & \multicolumn{3}{c}{**Shielding**} & \multicolumn{3}{c}{**isolCFU**} & \multicolumn{3}{c}{**Shielding**} & \multicolumn{3}{c}{**isolCFU**} \\ \cline{2-13}  & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** & **IA-TA** \\ \hline \hline \multirow{2}{*}{vBBU} & 92.8 & 03.9 & 92 & 93.1 & 0.3 & 0.3 & 0.3 & 0.3 & 0.2 & 0.2 & 0.2 & 0.3 & 6.4 & 5.4 & 7.3 & 6.2 \\ \hline \hline \(\text{b}\)-sothomer & 98.6 & 98.4 & 100 & 98.4 & 0.5 & 0.4 & 0 & 0.4 & 0.2 & 0. Linux containers (LXC) serve as the virtualization environment for deploying both vBBUs at the DU and CU. To assess resource sharing in Cloud-RAN, we introduce an additional service which involves a traffic flow generated by the Anritsu device and aggregated in the Midhaul. The destination for this traffic is a third LXC is deployed at the CU, referred to as A. Designed as a non-RT user-space application sharing computing and network resources with vBBUs at the CU, A consists of the network utility Netcat, which consumes packets from the traffic flow. In a containerized virtualization, the NIC is likely shared among different containers. In this network scenario, all services instantiated at the CU--vBBU1, vBBU2, and A--share the NIC port connecting the CU to the Midhaul network. Similarly, vBBU1 and vBBU2 share the second NIC port connecting the CU to the Backhaul. Using two different NIC ports to access the Midhaul and the Backhaul allows for isolating traffic in the Midhaul with time requirements from traffic in the Backhaul, which does not impose any time requirements. To facilitate NIC sharing among containers, the edge server associated with the CU deploys an SR-IOV-based NIC. This implementation leverages SR-IOV to create multiple virtual functions (VFs) atop the NIC's PCI Express (PCIe) physical function (PF). The NIC's driver supporting SR-IOV registers the corresponding RX/TX Hard-IRQ for that VF. Moreover, a unique MAC address is assigned to each VF. This pair of MAC addresses--RX/TX Hard-IRQ--makes the VF look like an independent NIC itself. Each VF is assigned a unique MAC address and is linked to corresponding RX/TX Hard-IRQ, which together make the VF appear as an independent NIC.