## 3 System Model and Assumptions  
In this section, the overall system architecture and the assumptions as well as the system components which make the allocation of computational resources for the incoming requests more efficient are well explored. The 5G Cloud Radio Access Network (CRAN) refers to the virtualization of base station (BS) functionalities by means of cloud computing [17]. In this work, a fully centralized CRAN architecture [4] is assumed where all the baseband functions are assembled in BBUs (base band units) and the signals are centrally processed. The request management and resource allocations of BBUs of macro-cell and small-cell are co-located in the BBU pool. Remote radio heads (RRHs) integrate the radio functionalities where the RRHs and BBU pool communicate over CPRI (Common Public Radio Interface) protocol. We are considering that the overall system supports 2G, 3G, and 4G networks, and is designed for future 5G network. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**State-of-the-Art Works** & **QoS** & **User QoE** & **Profit** & **Resource Utilization** \\ \hline VBS Provisioning [12] & & & (Partially) & \\ VRAN-PAP [13] & & & (Partially) & \\ Fluidnet [16] & & & & \\ RRH Clustering [15] & ✓ & & & \\ QoSM [6] & ✓ & & & \\ NvG [9] & & & ✓ & ✓ \\ QEPRA [Proposed] & ✓ & ✓ & ✓ & ✓ \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparative study among the state-of-the-art works on CRAN. NvG: news vendor game-based resource allocation; QEPRA: Quality-of-Experience and Profit-aware Resource Allocation; QoE: Quality-of-Experience; QoS: Quality-of-Service; QoSM: QoS-aware dynamic BBU-RRH mapping; VBS: virtual base station; VRAN-PAP: Virtual Radio Access Networks Placement and Assignment Problem. In CRAN architecture, the mobile subscribers are directly connected to the RRHs of the mobile operators with heterogeneous service requests and Service Level Agreements (SLA), via supported mobile network communication protocols (e.g., GSM-Global System for Mobile communication, 3 GPP-3 rd Generation Partnership Project, LTE-Long Term Evolution, LTE Advanced, etc.). With the help of BBUs, residing in a BBU pool, the incoming workloads of the RRHs are processed. As a consequence, these computational resource requests are sent from RRHs to a _Request Receiver (RR)_ located in the cloud service provider (CSP)'s side, as shown in Figure 2. The _RR_ receives all the incoming requests with the corresponding service requirements. It then extracts the major attributes (data size, tolerable service delay, signal strength) of the requests from the requirements and sends those to the _Request Prioritizer (RP)_. The _RP_ calculates the weight for each arrived request according to the requirements which denote the priority of each incoming request in a certain scheduling interval. The _RP_ then sends the requests with their weights to the BBU Pool Manager which is responsible for managing the resource allocation process. The optimal mapping of incoming requests to BBUs in a pool is done by the _QoE and Profit-aware Resource Allocator_. With the help of _Pricing Policy Maker_ and _Resource Manager_, the _QoE and Profit-aware Resource Allocator_ allocates BBUs for selected requests from the incoming requests in a scheduling interval in order to maximize the total user QoE and service provider profit. As limited computational resources are available for heterogeneous incoming requests with various requirements, these resources are allocated with the help of several scheduling intervals. The scheduling interval can be defined as in [18]. Here, the _Resource Monitor_ monitors the incoming load and the _Resource Manager_ creates appropriate virtual base stations (VBSs) according to the requirements. In addition, the _Pricing Policy Maker_ provides the per-unit prices according to the work load and priority of incoming service requests. These unit prices are dynamically adjustable, as explained in [19; 20].