David Guyon
email: david.guyon@irisa.fr

Anne-Cécile Orgerie
email: anne-cecile.orgerie@irisa.fr

Christine Morin
email: christine.morin@inria.fr

Deb Agarwal
email: daagarwal@lbl.gov

How Much Energy can Green HPC Cloud Users Save?

Keywords: Cloud computing, green computing, HPC applications

Cloud computing has become an attractive and easyto-use solution for users who want to externalize the run of their applications. However, data centers hosting cloud systems consume enormous amounts of energy. Reducing this consumption becomes an urgent challenge with the rapid growth of cloud utilization. In this paper, we explore a way for energy-aware HPC cloud users to reduce their footprint on cloud infrastructures by reducing the size of the virtual resources they are asking for. We study the influence of green users on the system energy consumption and compare it with the consumption of more aggressive users in terms of resource utilization. We found that larger resources are more energy demanding even if they are faster in executing the applications. But, reducing too much the resources' size is also not beneficial for the energy consumption. A tradeoff lies in between these two options.

I. INTRODUCTION

High Performance Computing (HPC) infrastructures are usually massive buildings that contain hundreds of servers with powerful hardware [START_REF] Insidehpc | What is high performance computing?[END_REF]. These infrastructures run scientific applications requiring tremendous amounts of computing resources to execute. These applications are often organized in workflow structures and each step of the workflow may be a computation that needs important amounts of CPU, memory and storage resources.

Cloud computing has become a cost effective alternative to HPC machines [START_REF] Gupta | The Who, What, Why and How of High Performance Computing Applications in the Cloud[END_REF] and some of the less resource intense HPC applications tend to migrate to clouds [START_REF] Gupta | Evaluation of HPC Applications on Cloud[END_REF]. Cloud computing offers elasticity which allows applications to reduce overand under-provisioning of resources. A user only pays for the resources its application is using and, in some cases, the application execution has an overall lower pricing compared to HPC solutions [START_REF] Gupta | Evaluation of HPC Applications on Cloud[END_REF].

As a consequence of the cloud computing success, the global energy consumed by data centers has increased significantly [START_REF] Forrest | Data centers: How to cut carbon emissions and costs[END_REF], [START_REF] Koomey | Growth in data center electricity use 2005 to 2010[END_REF]. Studies show that cloud computing represented about 0.5% of the worldwide energy consumption in 2008 and is predicted to quadruple by 2020. We are currently facing important climate changes which call for a reduction of the ecological impact of computing. To reduce the electrical consumption of cloud infrastructures, consolidation mechanisms pack the virtual machines (VMs) on the least number of servers, without impacting application performance, in order to turn off the unused servers in case of moderate load.

Idle servers indeed consume extensive amounts of energy [START_REF] Orgerie | A Survey on Techniques for Improving the Energy Efficiency of Large-scale Distributed Systems[END_REF]. However, such consolidation techniques are only efficient if virtual resources are not kept idle by the users for no work. Indeed, if the cloud provider does not over-commit the physical resources, the user that uses only partly the virtual machines resources is wasting the rest. Thus, energy-efficient users need to properly size their VMs. For a given parallel application, several VM sizes are possible, each offering a different tradeoff between the overall energy consumption and the performance (i.e. runtime). This tradeoff is complex to determine: small-sized VMs may be easier to pack into server machines, while larger VMs may end their work faster. While it is logical that well-dimensioned machines are more energy efficient, defining their size is not an easy task for the users.

In a previous work [START_REF] Guyon | Energy-efficient User-oriented Cloud Elasticity for Data-driven Applications[END_REF], we present a cloud system involving users in the energy optimization system. A user who agrees to reduce her impact on the environment can choose a more energy-efficient execution mode, implying a lost in performance, by executing her application on less resources on the infrastructure. The unused resources are free for another application and thus, this approach favors a better consolidation of the whole system. The better the consolidation, the lower the electrical consumption. The proposed system offers three execution modes based on [START_REF] Villebonnet | Big, Medium, Little: Reaching Energy Proportionality with Heterogeneous Computing Scheduler[END_REF]: Big, Medium and Little. An algorithm selects the size of the VMs for executing each task of the workflows depending on the selected execution mode. The Medium mode executes using the user-specified VM resources for each workflow stage. The Little and Big modes respectively decreases or increases the VMs by one size for the whole workflow.

In the present paper, we evaluate the impact of the proportion of users selecting the Big, Medium or Little mode on a data center's energy consumption. Our evaluations have been done using three kinds of scientific workflows, energy consumption measurements for the execution of these workflows on a real platform and traces of jobs submitted to a production HPC center. We evaluated the data center energy consumption for different proportions of users selecting the three available modes. The simulation results show promising energy savings when the amount of users selecting the Big mode is low. It also shows that using the Little mode compared to the Medium mode does not always provide the best performance/energy saving tradeoff.

The paper is organized as follows. Section II presents our methodology. The experimental setup is explained in Section III and the simulations' results detailed in Section IV. Finally, we conclude the paper in Section V.

II. METHODOLOGY

For evaluating the impact of energy-aware users on a HPC cloud, we conducted an experimental study using a real public workload trace from a production data center. A job in our workload is an execution of one of three different scientific applications. The energy consumption of these applications running with all possible execution modes was measured on a real cloud infrastructure. Each job runs with an execution mode and we varied this distribution of the modes in order to have different profiles of user population. The energy consumption of the data center is calculated with each profile distribution in order to evaluate the impact of the execution mode choices on the data center's electrical consumption.

The nodes of the simulated data center are inspired by the nodes of the Taurus cluster of Grid'5000, a French platform for experimenting distributed systems. Each node of this cluster has 12 Intel Xeon E5-2630 CPU cores, 32GB of memory, 598GB of hard drive and a 10 Gigabit Ethernet connection.

For executing the applications on the hardware we used virtualization based on the KVM technology. A VM has a fixed size in terms of CPU, memory and disk resources. We considered different kinds of VMs with different amounts of CPU, memory and disk resources, called flavors and we selected 5 flavors similar to those offered by the Amazon EC2 cloud [START_REF]Amazon EC2[END_REF]. The list of flavors used in our system is presented in Table I. This table also contains the EC2 instance equivalent and their US East hourly pricing. In our cloud system, incoming jobs are executed directly and cannot be batched for a later execution. Any job submission implies a VM creation for each task of the workflow. A consolidation mechanism creates the VMs on specific servers in order to optimize their resource utilization (Greedy algorithm). If a server does not host any VM, it is powered down in order to reduce the data center's power consumption.

The workload corresponds to the job submission distribution over a day. We took a 2 year long trace from a real production HPC platform located in the Czech republic [START_REF]Parallel Workloads Archive[END_REF]. From this trace we analyzed the daily submission distribution and used a k-mean algorithm to find different distribution profiles. From these profiles we retained one with a submission peak during the working hours.

A job submission is a request to start an application. We selected real scientific applications that execute as a workflow. Workflows are composed of a sequence of sequential and/or parallel tasks with data dependencies. We selected 3 applications from different scientific areas that exhibit different behaviors in terms of resource consumption: disk-intensive, CPU-intensive and memory-intensive. The chosen applications are the following ones: Montage, Blast and Palmtree. They are presented in more detail in Section III-C.

Each job runs according to an execution mode. This mode has an impact on the size of the VMs where the job is running and consequently on the execution time of the job. A probabilistic distribution algorithm takes as input the percentage of jobs in each execution mode. As output, the algorithm fairly distributes the 3 workflows to each job and set each job execution mode following the input.

The electrical consumption of the servers has been measured thanks to the fine-grained wattmeters available on them [START_REF] De Assuncao | The Green Grid5000: Instrumenting and using a Grid with energy sensors[END_REF]. Three measures have been recorded: when the server is powered down, when the server is on but not used (idle) and when it is fully used. The energy consumption of the workflows has also been measured. The execution logs of each workflow in each execution mode contains the run time and the energy consumption of each task. To obtain accurate electrical measures, the servers were loaded at their maximum capacity by duplicating the tasks running on them. Then the dynamic consumption is distributed evenly across the tasks.

A. Assumptions

In this system, we make the following assumptions:

• a user application is a workflow composed of one or more sequential steps, each step having one or more parallel tasks ; • each task of a workflow executes in a separate VM ;

• each task can exploit all the cores available in its VM, whatever the number of cores. It is the users' responsibility to implement tasks that automatically adapt their execution to use all the cores available ; • a VM always has enough disk space and memory for the task to execute, even when the Little execution mode is selected.

B. System

The system architecture is presented in Fig. 1. The user, at the top, sends a request to execute her workflow application. The request contains the workflow structure (number of steps and parallel tasks) and the amount of CPU, memory and disk space required by default by each step. She also indicates the execution mode for the run of her application.

Inspired by the ARM big.LITTLE (which is a heterogeneous processor) V. Villebonnet et al. introduce in [START_REF] Villebonnet | Big, Medium, Little: Reaching Energy Proportionality with Heterogeneous Computing Scheduler[END_REF] the Big, Medium and Little (BML) infrastructure. Their idea consists in reaching energy proportionality by using heterogeneous Fig. 1: The users send their applications description, with for each of them the selected execution mode, to the cloud infrastructure which contains the servers hosting the users' VMs.

processors for variable workloads: if the workload is low, it is executed on the Little processor, while when it is high, it smoothly migrates to the Big processor. Similarly, in our system the VMs' sizes for executing a workflow is chosen according to an energy/performance tradeoff depending on the execution mode selected by the user. This is why in the rest of the paper, we opt for the same terminology which is easier to handle and it highlights the main variable of our system: the VM size 1 .

The size of the VM for a given task is selected according to the specified amount of CPU, memory and disk space required (Section III-C details how the resource amount is defined). The VM flavor with just enough resources is the one selected for the Medium execution mode. The Big execution mode selects the VM flavor one size larger and for the Little mode, it selects the VM flavor one size smaller. For example, an application asking for an amount of resources matching the medium flavor will be assigned the large VM flavor in the Big execution mode and the small VM flavor in the Little execution mode.

A VM placement algorithm creates the VMs on specific servers in order to favor the consolidation of the whole system and reduce the global energy consumed. A simple Greedy algorithm [START_REF] Yue | A simple proof of the inequality FFD (L) 11/9 OPT (L) + 1, L for the FFD bin-packing algorithm[END_REF] implementation is used to solve this complex bin packing problem. The servers are sorted in ascending order of available resources and the first one suitable for the VM creation is selected. This algorithm avoids the fragmentation of VMs across servers.

III. EXPERIMENTAL SETUP

An evaluation of the energy consumed in our cloud system with different user profile distributions has been conducted using simulation. In order to have a simulator as realistic as possible, we took a job arrival trace from an existing HPC center, we selected real scientific applications that we ran on a cloud infrastructure to get execution logs and finally we designed the simulated infrastructure based on the hardware configuration of the real cluster we used. This is described in more detail in the remainder of this section. 1 To avoid confusion between the Medium mode and the medium flavor, the modes always start with a capital letter A. Simulator A cloud simulator has been developed in Python. It reproduces the behavior of a cloud system that takes the users into consideration in order to optimize the energy efficiency of the whole system. This simulator takes the following inputs:

• an arrival trace of request submissions (workload) based on real data in order to have a realistic use case ; • a panel of execution logs of scientific applications measured on a real cloud infrastructure that ran with the three execution modes ; • profile distribution probability represented by a percentage parameter to configure the amount of applications to execute in the different modes ; • information about the servers to use in the simulated data center such as the hardware resources (CPU, disk and memory) and the power consumption of a single node in idle and off states based on real measurements on the machines we used to run the scientific applications. Each job submission in the workload simulates the execution of an application starting at a specific time (date during the day) using the arrival trace and is attributed an execution mode with respect to the profile distribution probability given as parameter.

The output of the simulator is the energy consumed during a whole day by the workload run on the simulated cloud infrastructure. It also generates the complete simulation log details for debugging purpose.

B. Arrival Trace

We used a realistic job submission trace as an input of our simulator. The original trace is 2 years long and comes from the utilization records of the MetaCentrum Czech National Grid [START_REF]The MetaCentrum 2 log[END_REF]. We executed a k-mean algorithm on this archive and retrieved a 24h long trace containing a total of 1506 job submissions. The jobs distribution represents a typical daily use with submission peak during the working hours.

C. Execution Logs

The simulator utilizes execution logs of workflow applications that we ran on a real cloud infrastructure. Three scientific applications from completely different research domains have been carefully selected in order to represent the computations we can find in data centers, such as memory-intensive, dataintensive and CPU-intensive tasks.

1) Montage Workflow: Montage [START_REF]Montage[END_REF] is an engine to build astronomical image mosaics for astronomers. Its workflow structure is composed of 3 parallel tasks that download data and run calculation of it, and then a single ending task that creates the final mosaic thanks to the 3 intermediate data given by the first step. The workflow is mainly IO-intensive and CPU-intensive during the calculation.

The number of hardware resources given to each task has been selected by experimentation in order to have a Medium execution that runs for less than an hour. The tasks of the first step need 2 cores, 2 GB of RAM and 10 GB of disk space. The second step requires 1 core, 4 GB of RAM and 20 GB of disk space. Thus, the VM flavor used for these tasks with the Medium mode is the medium size.

2) Blast Workflow: Blast [START_REF]Blast[END_REF] is a program that compares nucleotide or protein sequences to sequence databases and calculates the statistical significance of matches. The workflow structure is composed of 4 parallel tasks, each searching for a match from a file containing 10 000 nucleotide sequences into the complete nucleotide sequences database of mouse. The execution of the workflow has a cyclic use of the memory and constantly uses the CPUs, making it a memory-intensive and a CPU-intensive application.

Again, the required hardware resources have been selected by experimentation. Each task asks for 4 cores, 2 GB of RAM and 10 GB of disk space and executes for about an hour. The selected VM flavor for the Medium mode is the large size.

3) Palmtree Workflow: Palmtree [START_REF] Lenôtre | A Strategy for Parallel Implementations of Stochastic Lagrangian Simulation[END_REF] is a library for the parallelization of Monte Carlo methods where the challenge is the proper management of the random numbers. The workflow structure is composed of 2 parallel tasks and its execution is CPU-intensive only.

Experimentation on this workflow showed us that assigning 4 cores, 2 GB of RAM and 10 GB of disk space to each task gives a good execution tradeoff. The large VM flavor is used to run the tasks when the Medium mode is selected.

D. Power Consumption Measurement

The three applications in our benchmark have been executed on servers equipped with fine-grained wattmeters of the Lyon site of Grid'5000 in order to have the energy consumed by their run in each execution mode. In order to have a fair energy sharing, we loaded as much as possible the servers by duplicating the jobs.

E. Performance versus Cost Tradeoff

A summary of the execution time versus the energy consumption of each workflow in each execution mode is given in Fig. 2. The number of servers required to run the workflows increases when the Big mode is selected which explains the energy consumption increasing. On the other hand, the execution time increases by a factor of 3 and more when the Little mode is selected.

IV. EXPERIMENTAL VALIDATION

Table II presents our simulation results. We simulate a full day and a cluster with 330 servers (minimum number of servers required to be able to respond to the demand in the highest demand case). Each row presents the results for a profile distribution following the percentages given in the 3 first columns. All results are the average of 10 simulations and contain the energy consumption in KWh of the whole cluster, the maximum number of hosts required to execute the workload and the standard deviations.

The gray row corresponds to a simulation on a usual cloud infrastructure without any energy optimization. The unused servers are not powered down and all users select the Big execution mode because it reflects a common behavior when users want results as soon as possible. The last column is the percent of energy saved compared with the scenario of the first row. A scenario with a 50% energy saving means its execution consumes half of the execution with the scenario of the first row.

As we can see in the simulation results, a cloud system that turns off unused servers consumes less than 50% of usual cloud systems. The simulations in which the most energy has been saved are when 100% of the users selected the Medium and the Little execution modes. In these two cases, the energy saving is around 63% in comparison with the consumption of the first row scenario. The simulation costing the most in terms of energy is the scenario where 100% of the users select the Big execution mode, corresponding to an energy saving of 53.68%. It shows we can save important amounts of energy by avoiding the Big mode. Informing users about how much more their application consumes compared to another mode may encourage them to select a more energy-efficient execution mode and thus, motivates the implementation of an incentive mechanism. It also shows that the gap between the Little and Medium modes is very small. Selecting the Little mode is not always the best performance and energy tradeoff. Indeed, the energy may be very similar between the two modes and the execution time much longer in the Little mode compared with the Medium mode.

When 100% of the workload is using the Little mode, we can see that the workload uses a maximum of 143 servers out of the 330 servers available in the simulated cluster. Fewer servers turned on means a lower energy cost on the cooling system of the data center. It also means the cloud provider could buy less servers and thus, fewer ones to recycle after their lifespan. From another point of view, the low server utilization means this system can handle a higher number of users if most of them continue to use the Little mode.

In a realistic situation, they won't be 100% users using the same execution mode but rather a few percent in each of them. For table dimension reasons, Table II does not contain all possible distribution configurations but still reveals a link between the user profiles and the energy consumed. If we sort the table by descending order of Big users, we can see the energy consumption and the number of used hosts decreasing. So, the lower the number of Big users, the lower the consumption. However, for a fixed amount of Big users, the percentage variation of Medium and Little users has a small impact on the energy consumption. Thus, the system does not save much more energy with more Little users than Medium but globally allows the system to run the workload on fewer servers.

V. CONCLUSION

In this paper we present a simulation-based evaluation on how much an energy-aware cloud system could save in energy consumed by involving users in the energy conservation. In this system users can select an execution mode for running their applications. An execution mode controls the size of the application's VMs. The higher the mode, the larger the VMs and vice versa. A consolidation algorithm packs the VMs into a minimum number of servers in order to have a maximum of servers powered down. The smaller the VMs, the better the consolidation and the lower the global energy consumption of the infrastructure.

We simulated a typical daily use of a data center running 3 real scientific applications and varied the amount of applications in each execution mode. The simulation results show a saving of energy of more than 50% whatever the selected mode compared with cloud infrastructures where the servers are not turned off when not used. Scenarios where the most energy is saved are when 100% of users select the Medium and Little execution modes. However, cloud users tend to over-commit their job reservations [START_REF] Ghosh | Biting Off Safely More Than You Can Chew: Predictive Analytics for Resource Over-Commit in IaaS Cloud[END_REF] and they end up selecting the Big mode while the Medium mode is sufficient. The simulator results show the importance of reducing the amount of users using the Big mode and also that selecting the Little mode is not always the best practice because energy savings may be low and the application execution time much higher than with the Medium mode.

Fig. 2 :

 2 Fig. 2: Energy consumption and execution time of each workflow in each execution mode.

TABLE I :

 I Details of the VM flavors used in the system with their Amazon EC2 instance equivalent and their US East hourly pricing.

	Flavor	RAM CPU	Disk EC2 instance equiv.
	tiny	0.5 GB	1	5 GB t2.nano	$0.0065
	small	2 GB	1 20 GB t2.small	$0.026
	medium	4 GB	2 40 GB t2.medium $0.052
	large	8 GB	4 80 GB c4.xlarge	$0.209
	xlarge	16 GB	8 160 GB c4.2xlarge $0.419

TABLE II :

 II The simulation results give the consumption of a whole cluster used during 24h from 2AM to 2AM the next day and the maximum number of hosts used with various profiles of job execution modes.

	Big Medium Little Energy (KWh) Std dev energy Hosts used Std dev hosts Energy saved
	100	0	0	632.489	16.277	282	7.909	0.00 %
	100	0	0	292.941	3.690	292	16.806	53.68 %
	0	100	0	234.122	4.882	168	6.363	62.98 %
	0	0	100	231.921	3.840	143	3.187	63.33 %
	80	0	20	273.205	6.021	236	16.117	56.80 %
	60	0	40	269.969	3.497	208	11.071	57.32 %
	40	0	60	258.138	3.980	190	14.935	59.19 %
	20	0	80	246.996	3.701	170	6.610	60.95 %
	20	20	60	246.590	5.482	167	9.843	61.01 %
	20	60	20	242.464	4.013	171	9.243	61.67 %

ACKNOWLEDGMENT

Experiments presented in this paper were carried out using the Grid'5000 experimental test-bed, being developed under the INRIA ALADDIN development action with support from CNRS, RENATER and several Universities as well as other funding bodies (see https://www.grid5000.fr).


Jialong Duan

Xavier Lagrange

Frédéric Guilloud

Performance Analysis of Several Functional Splits in C-RAN

Keywords: RRH, BBU, functional split, quantization, error vector magnitude (EVM)

Centralized/Cloud Radio Access Network (C-RAN) is a promising future mobile network architecture, which can potentially increase the capacity of mobile network meanwhile reducing operators' cost. In standard C-RAN, frequency shifting is made in Remote Radio Heads (RRHs), which are close to the antennas. Signal processing and upper layers are made in Baseband Unit (BBU) pool for multiple base stations. However, this results in high burden on the optical transport network between RRHs and BBU pool. This paper investigates new functional split architectures between RRH and BBU, to reduce the transmission throughput between RRHs and BBUs. Two new architectures are proposed and modeled for the uplink. We propose to move part of physical layer functions of the BBU to the RRH. For the proposed architectures, the transmission rate between RRHs and BBUs depends on the mobile network load, while that of current architecture is constant. Simulation results illustrate that 30% to 40% bandwidth can be saved when all the radio channel capacity is used, and up to 70% bandwidth when half of the radio channel capacity is used.

I. INTRODUCTION

Mobile data traffic is supposed to increase more than 1000 times from year 2010 to 2020 [START_REF]Enhance mobile networks to deliver 1000 times more capacity by 2020[END_REF]. Meanwhile, the future 5G system is required to support an increase factor of 10 -100 times of the transmission user data rate and devices with delays as low as a few milliseconds [START_REF] Osseiran | Scenarios for 5G mobile and wireless communications: the vision of the METIS project[END_REF]. Operators are facing the challenges to satisfy the explosion of data usage while reducing the cost. A novel mobile network architecture C-RAN has been proposed to address these.

In Long Term Evolution (LTE), eNodeB (eNB) contains two main parts: Baseband Unit (BBU) and Remote Radio Head (RRH). RRHs transform the baseband signals from BBUs to radio frequency and then forward it to User Equipments (UEs) by the antennas in the downlink. The process is adverse in the uplink. Meanwhile, BBUs deal with baseband signal processing. RRH is connected to BBU through optical fibers.

C-RAN remotes BBUs from RRHs and mitigates them to a BBU pool for centralized processing [START_REF] Huang | Recent Progress on C-RAN Centralization and Cloudification[END_REF]. The current widely used interface protocol for Inphase (I) and Quadrature (Q) data transmission between RRHs and BBUs is Common Public Radio Interface (CPRI) [START_REF]Common Public Radio Interface (CPRI); Interface Specification V6[END_REF]. The estimated IQ data throughput exceeds 10 Gbps for a 3 sector Base Station (BS) with 20 MHz 4×4 MIMO. A BBU pool which connects 10-1000 BSs will need vast transmission bandwidth in the fronthaul [START_REF] Checko | Cloud RAN for Mobile Networks -A Technology Overview[END_REF]. This is one of the main issues of C-RAN.

The raw IQ samples transmitted between RRHs and BBUs consume too much bandwidth of the transport network. Thus, an efficient compression scheme is needed for the capacity constrained transport network between RRHs and BBUs. Several solutions have been proposed in [START_REF]C-RAN: The Road Towards Green RAN (white paper)[END_REF], such as reducing signal sampling rate, applying non-linear quantization, frequency sub-carrier compression and IQ data compression. Another envisioned method is to change the current functional split architecture between RRH and BBU [START_REF] Wubben | Benefits and Impact of Cloud Computing on 5G Signal Processing: Flexible centralization through cloud-RAN[END_REF]. This paper investigates on the performance of the last method. Two new functional split architectures are proposed, which move part of the functions in the physical layer of LTE transmission system from BBU to RRH.

For the downlink, the base station is concerned by the transmission side. The baseband signal is defined in a set of discrete symbols, so developing compression scheme is easy. For the uplink, the BS is concerned by the receiver side. As the signal received is affected by noise, it is fundamentally analog. The analog received signal should be quantized before being transmitted from RRHs to BBUs. The quantization has an impact both on the quality of the reception and on the throughput between RRHs and BBUs. Therefore, we focus on LTE uplink. This paper is organized as follows. In Section II, the Discrete Fourier Transform Spread Orthogonal Frequency-Division Multiplexing (DFTS-OFDM) transmission system in LTE uplink is briefly introduced. The current and proposed functional split architectures between RRH and BBU are modeled and presented in Section III. The algorithms applied and numerical configurations in the simulation are proposed in Section IV. The simulation results are shown in Section V. At last, this paper is concluded in Section VI.

II. OVERVIEW OF DFTS OFDM TRANSMISSION SYSTEM

LTE uplink is based on DFTS-OFDM rather than Orthogonal Frequency-Division Multiplexing Access (OFDMA), which is used for LTE downlink. The Peak to Average Power Ratio (PAPR) of DFTS-OFDM is lower than OFDMA which greatly benefits the User Equipment (UE) in terms of transmit power efficiency and reduced cost of the power amplifier [START_REF] Myung | Single carrier FDMA for uplink wireless transmission[END_REF].

A. Transmitter

Let us consider a transmitter i of a DFTS-OFDM system. It converts input bit stream signal to M i modulated sub-carriers over a total of N sub-carriers, as shown in Figure 1. A set of input data bits is firstly collected and then modulated by using QPSK, 16 QAM or 64 QAM, which results in a complex vector a i = {a i 0 , a i 1 , ..., a i Mi-1 }. After an M i -point unitary Discrete Fourier Transform (DFT), the output A i is obtained.

Then A i is mapped to a group of M i adjacent sub-carriers of X i , whose remaining sub-carriers are allocated with zeros. This is called localized sub-carrier mapping. Next, a DFTS-OFDM symbol x i is generated by performing an N -point unitary inverse DFT to X i .

To combat multi-path fading, a Cyclic Prefix (CP) is added at the beginning of each symbol x i . A CP is created by copying the last L samples of symbol x i . After a parallel-to-serial operation, x i cp is converted to analog signal and modulated to radio frequency, then finally transmitted.

B. White Gaussian Noise Channel Model

We model the transmission channel with noise between Transmitter i and receiver by adding white Gaussian noise (AWGN). The elements of the noise vector n follow a normal distribution with mean µ = 0 and variance given by

σ 2 = E s × 10 -( Es N 0 ) dB /10 (1)
where E s is the average symbol energy defined as:

E s = E(|a i k | 2 ), (2)
and N 0 is the double-sided power spectral density of the white Gaussian noise.

C. Receiver

A block diagram of a DFTS-OFDM receiver for the recovery of signals transmitted from multiple transmitters is illustrated in Figure 2. The signal processing is inverse to that of the aforementioned transmitter. The signal corresponding to Transmitter j, denoted by B j , is selected out by the Subcarrier Demapping block. A frequency-domain-equalization (FDE) can be performed after the Sub-carrier Demapping to combat frequency-selective fading and phase distortion. We do not consider equalization in this work.

III. DIFFERENT FUNCTIONAL SPLITS

A. Current Functional Split Between RRH and BBU

A model of receiver applying typical functional split is shown in Figure 3, which we denote as Method 1. A Q qbits linear quantization is applied to both the real part and the imaginary part of y cp separately before it is transmitted from RRH to BBU. The RRH in Method 1 can't identify which and how many Physical Resource Blocks (PRBs) are occupied, thus it has to transmit all the PRBs even if all of them are vacant. Therefore, the transmission rate between RRHs and BBUs is constant, independent of the mobile network load.

B. Proposed Functional Splits Between RRH and BBU

In LTE transmission, the number of guard sub-carriers is about 40 percent of all the sub-carriers transmitted and the cyclic prefix (CP) also forms 7 to 25 percents of the data transmitted [START_REF] Wubben | Benefits and Impact of Cloud Computing on 5G Signal Processing: Flexible centralization through cloud-RAN[END_REF]. We consider to remove CP and the guard sub-carriers before the transmission from RRH to BBU. Two methods of functional split which move "remove CP" and "FFT" blocks from BBU to RRH are proposed. We denote them Method 2 and 3, and detail them hereafter.

1) Method 2 of Functional Split Between RRH and BBU: The model of Method 2 is shown in Figure 4. The difference between Method 1 and 2 is that we move the "remove CP" block and "N-point-FFT" block from BBU to RRH. The new block "PRB usage state detection" detects which sets of 12 sub-carriers corresponding to one PRB, are occupied in Y.

W k = 11 n=0 |Y 12k+n | 2 (3)
If W k is less than a threshold, we can decide that the 12 subcarriers in PRB k are vacant.

2) Method 3 of Functional Split Between RRH and BBU: The model of Method 3 is shown in Figure 5. The dynamic of the signal y in the frequency domain is higher than Y in the time domain. In method 2, the signal transmitted from RRH to BBU is in frequency domain. We consider to transform it to time domain before the transmission to reduce the dynamic. To realize this, different from method 2, we perform a 12-point unitary IFFT on {Y 12k+nmin , Y 12k+nmin+1 , ..., Y 12k+nmin+11 } in Y in Method 3. Then we obtain a vector {c 12k , c 12k+1 , ..., c 12k+11 }, where k = 0, 1, ..., N RB -1. The total number of PRBs during one LTE time slot is denoted by N RB . Next, the block "PRB usage state detection" decides if this vector will be quantized and transmitted to BBUs.

In BBUs, the serial "12-point FFT" blocks are used to reverse the 12-point unitary IFFT operation in the RRHs.

IV. ALGORITHMS AND NUMERICAL CONFIGURATIONS

This section present the simulation set up of DFT-Spread OFDM in LTE Uplink physical layer of 20 MHz, which includes N = 2048 sub-carriers where 1200 of them are active. The length of CP L = 160. Modulation scheme 16 QAM is adapted, thus m = 4 bits per symbol. "DAC" and "RF" blocks in the transmitter are not considered as well as "ADC" and "RF" in the receiver. Three different methods of functional split between RRH and BBU are applied and the performances will be compared in Section V.

A. Quantization and Frame Arrangement

In order to minimize the quantization error, a digital automatic gain control is applied. A scaling factor F s is determined for each block of N s received IQ samples which is denoted by z = {z 1 , z 2 , ..., z Ns-1 }. Then z is quantized linearly with Q q bits resolution per complex component based on F s . The scaling factor is sent together with z from RRHs to BBUs. In order not to introduce a large extra delay to the transmission system, the value of N s should be a factor of N + L for Method 1, and of the total number of sub-carriers occupied during each LTE time slot for Method 2 and 3.

We define the largest absolute value as

V max = max k=0,...,Ns-1 {| (z k )|, | (z k )|} (4)
where (z k ) and (z k ) denotes the real and imaginary part of z k , respectively. The corresponding scaling factor is determined as

F s = Vmax p for Vmax p ≤ 2 Qs -1 2 Qs -1 for Vmax p > 2 Qs -1 ( 5
)
where p is the quantization step for V max and Q s is the number of bits used to represent F s .

Then the IQ samples are linearly quantized to 2 Qq levels ranging from -F s to F s . The n-th quantization level is given by

q n = -F s p + (n + 1 2 ) • F s p 2 Qq-1 (6)
where n = 0, 1, ..., 2 Qq -1.

Applying the quantization levels obtained, the IQ samples z are linearly quantized as

u I (k) = arg min n |q n -(z k )|, (7)
u Q (k) = arg min n |q n -(z k )| (8)
where k = 0, ..., N s -1.

Inspired by [START_REF] Samardzija | Compressed Transport of Baseband Signals in Radio Access Networks[END_REF], the IQ samples transmitted from RRH to BBU may be organized as a frame given in Figure 6. The first Q s bits are used to represent F s . Moreover, the references of the corresponding occupied PRBs are also represented by Q r bits. This is necessary for Method 2 and 3 to identify which PRBs the samples received belong to. For Method 1, Q r = 0.

Taking into account the transmission of the scaling factor and the references of PRB, the average number of bits used to transport a complex element (I or Q) for Method k is:

Q effk = 2N s k Q q k + Q s + Q r 2N s k (9)
where k = 1, 2, 3, N s k is the number of IQ samples in each frame and Q q k is the number of quantization bits per complex component.

B. Data Transmission Rate From RRH to BBU

In the following, we will present the formula of data transmission rate calculation from RRH to BBU separately.

1) Data Transmission Rate for Method 1: The data transmission rate between RRH and BBU for Method 1 is given by

D 1 = F os • f s • 2 • Q eff1 • 1 R c ( 10
)
where F os is the oversampling factor, f s is the minimum sampling frequency, and Q eff1 is the number of effective quantization bits for each complex element (I or Q) as mentioned in Section IV-A. The factor 2 in Equation 10 results from that both I and Q signals should be transmitted. Due to the Forward Error Correction (FEC) code applied in CPRI, a code rate R c needs to be considered.

In LTE uplink with 20 MHz bandwidth, there are 2048 subcarriers. Therefore, the minimum sampling frequency f s = 2048 × ∆f = 2048 × 15 kHz = 30.72 MHz. Oversampling is doing sampling to a signal with a frequency higher than the Nyquist rate (minimum sampling rate). It is applied to improve the performance of system. The values of the parameters for Method 1 in our simulation are shown in Table I.

2) Data Transmission Rate for Method 2 and 3: The data transmission rate from RRH to BBU for Method 2 is denoted by D 2 , and D 3 for Method 3. The data transmission rate is given by

D k = N Sc • 1 T s • 2 • Q effk • 1 R c • η (11)
where N Sc is the number of active sub-carriers for data transmission, T s is the symbol duration, k = 2, 3, and η is the assumed PRB utilization ratio. The factors 2 and R c in Equation 11 are the same as in Equation 10 for Method 1. The value assignments of the parameters in our simulation for method 2 and 3 are shown in Table II.

C. Error Vector Magnitude

The error vector magnitude (EVM) is used to quantify the performance of aforementioned different methods of receiver. EVM is defined as

EV M = E[|a i k -âi k | 2 ] E[|a i k | 2 ] ( 12
)
where a i k are the 16 QAM modulated symbols to be sent in transmitters as shown in Figure 1, andâi k are the received symbols before 16 QAM demodulation as shown in Figure 2.

We have also considered the cases with AWGN in the transmission channel between transmitters and receivers.

V. SIMULATION RESULTS

The performances of Method 1, 2 and 3 with and without AWGN have been simulated. Using Equation 10 and 11, we can get the data transmission rate from RRH to BBU for the three different methods and quantization resolution Q q .

A. Performance Comparison Between Method 1 and 2. Figure 8 shows the relative transmission data rate between Method 3 and 2 ( D3 D2 ) with respect to the same value of EVM. The number of PRBs allocated to each transmitter is denoted by NUM RB . It can be observed that, compared with Method 2, Method 3 can save 5% to 10% of the bandwidth between RRH and BBU when each transmitter is only allocated with one PRB without AWGN, and 12% to 15% when Es N0 = 6 dB. The more PRBs distributed to each transmitter, the less bandwidth gain Method 3 can obtain compared with Method 2. This is because the more PRBs allocated to one transmitter, the more asymmetrical are the serial 12-point IFFT process in the receiver and the M -point FFT process in the transmitter.

VI. CONCLUSION

This paper introduces two new architectures of functional split between RRH and BBU: Method 2 and 3, which have been modeled and simulated. Digital automatic gain control and linear quantization have been applied. In method 2, FFT and resource usage detection are processed in RRH after removing CP. In method 3, besides the modules in Method 2, a serial 12-point IFFT is made in RRH after FFT and a serial 12-point FFT in BBU. Simulation results illustrate that, Method 2 brings a drop of 30% to 40% of the transmission rate between RRHs and BBUs compared with current functional split architecture (Method 1) when all the PRBs are occupied, and up to 70% when half are occupied. Method 3 can further reduce the transmission rate when UEs are allocated with few PRBs. Applying non-linear quantization algorithms has the potential to further reduce the throughput. Non-linear quantization algorithms are compatible with the different proposed architectures, and will be investigated in a future work.

Fig. 1 .

 1 Fig. 1. Localized DFTS-OFDM transmitter.

Fig. 2 .

 2 Fig. 2. Localized DFTS-OFDM receiver.

Fig. 3 .

 3 Fig. 3. Method 1 of functional split between RRH and BBU (used in CPRI).

Fig. 4 .

 4 Fig. 4. Method 2 of functional split between RRHs and BBUs.

Fig. 5 .

 5 Fig. 5. Method 3 of functional split between RRHs and BBUs.

Fig. 6 .

 6 Fig. 6. Possible frame structure.

Fig. 7 .

 7 Fig. 7. The relative transmission data rate between Method 1 and 2 with respect to the same value of EVM.

Figure 7

 7 Figure 7 shows the relative transmission data rate between Method 2 and 1 ( D2 D1 ) with respect to the same value of EVM. The assumed PRB occupation ratio η = 0.5 and η = 1 are considered in both cases. Scenarios without AWGN, Es N0 = 10 dB and Es N0 = 6 dB are simulated. It can be observed that, similar results are obtained with adding different levels of white Gaussian noise. Compared with Method 1, Method 2 can save 30% to 40% of the bandwidth between RRH and BBU when all the PRBs are occupied, and 55% to 70% when only half of the PRBs are occupied. B. Performance Comparison Between Method 2 and 3.

Fig. 8 .

 8 Fig. 8. The relative transmission data rate between Method 2 and 3 with respect to the same value of EVM.

TABLE I SIMULATION

 I PARAMETERS FOR METHOD 1.

	PAPAMETER	SYMBOL	VALUE
	Oversampling factor	Fos	1
	Minimum sampling frequency	fs	30.72 MHz
	Number of samples for each frame	Ns	138
	Number of bits for scaling factor	Qs	16
	Number of bits for reference of PRB	Qr	0
	Code rate of FEC applied	Rc	8/10

TABLE II SIMULATION

 II PARAMETERS FOR METHOD 2 AND 3.

	PAPAMETER	SYMBOL	VALUE
	Number of active subcarriers	N Sc	1200
	Symbol duration (for normal CP)	Ts	71.43 µs
	Number of samples for each frame	Ns k (k = 2, 3)	12
	Number of bits for scaling factor	Qs	16
	Number of bits for reference of PRB	Qr	7
	Code rate of FEC applied	Rc	8/10
	Assumed PRB utilization ratio	η	0.5or1