Dynamic Energy Savings in Cloud-RAN: AnExperimental Assessment and Implementation

Christian Bluemm, Yi Zhang, Pedro Alvarez, Marco Ruffini and Luiz A. DaSilvaCONNECT Centre, Trinity College Dublin, Ireland

email: {blummc, zhangy8, pinheirp, ruffinm, dasilval}@tcd.ie

Abstract—Cloud Radio Access Network (C-RAN) is one ofthe most promising network architectures for next-generationmobile communication. Integrating multiple Base Band Units(BBUs) for signal processing in centralized BBU pools providesthe opportunity to manage the utilization of processing resourcesmore flexibly and in a more energy-efficient way. This paperdemonstrates two approaches for dynamic energy saving inheterogeneous C-RAN networks by switching BBUs from sleepmode to operational mode, depending on changes in data trafficdemand. To wake up BBUs, Wake-on-LAN (WoL) packets aresent either by the Remote Radio Head (RRH) in the firstapproach or by the controller in a BBU pool in the secondapproach. We implement and compare, in terms of wake-uplatency, experimental prototypes using Software Defined Radio(SDR) for both approaches. Aiming at compliance to current LTEstandards, the design and implementation of these prototypes hasthe potential to be applied to a larger scale C-RAN architecturein next-generation commercial mobile networks, including, butnot limited to, 5G networks.

I. INTRODUCTION

Cloud Radio Access Network (C-RAN) has become apromising mobile network architecture because of its flexibil-ity, scalability, and cost-efficiency. Two key aspects distinguishC-RAN architectures from traditional Radio Access Network(RAN) architectures. Firstly, instead of co-locating both thebaseband unit (BBU) and the Remote Radio Head (RRH) asa stand-alone combination at the cell-site, BBUs are separatedfrom their RRHs and moved to a centralized BBU pool.Secondly, hardware in this BBU pool can be virtualized andallocated dynamically on demand. Thus, baseband processingbecomes in the best case much more efficient than it wouldever be possible in traditional RAN architectures [1].

Radio access networks typically face frequent temporal andspatial fluctuations in mobile traffic load, for example due today-night cycles [2]. Systems which do not address these orother dynamics with adequate measures, i.e. static systems, areinefficient, as their capacity would be either over- or under-dimensioned for most of the time. A better, more energy-efficient solution is to manage the load and allocate processorresources in the BBU pool dynamically by putting BBUs tosleep or waking them up in accordance to the current demand.

In this paper, we demonstrate implementations of twoapproaches for saving energy in C-RAN architectures by se-lectively putting BBUs to sleep. We envisage a heterogeneousnetwork architecture, consisting of macro cells and small cells.We implement two prototypes, both based on SDR technolo-gies and both applying Wake-on-LAN (WoL) technology [3]

to dynamically wake up BBUs. In particular, this includesEthernet transmission of a WoL-specific broadcast frame, theso-called magic packet, which is sent to the sleeping BBU.

In the first approach – which we name Wake-on-RRH – theWoL magic packet is generated by the corresponding RRHsto which a particular BBU is associated. The user detectionand monitoring in this approach is performed by the RRH,which we have implemented on a Field Programmable GateArray (FPGA). Wake-on-RRH is described in section IV. Inthe second approach – which we name Wake-on-BBU – theWoL magic packet is generated by a controller within the BBUpool. For this purpose, the controller detects and monitors userload. Wake-on-BBU is described in section V. We summarizethe pros and cons of both approaches in section VI.

The contribution of this work is the design, the proof-of-concept implementation and the comparison of two C-RAN-based energy saving schemes, which apply WoL technology.

II. RELATED WORK

Sleep mode techniques for green communications have beenbroadly studied for traditional RAN architectures with thegoals of energy efficiency, cost reduction and environmentalawareness [4], [5]. Recently, there has been increasing interestin similar techniques for C-RAN technology. Theoretical workhas been carried out in [6], where the authors analyze thevarious C-RAN hardware components and propose an energysaving scheme by dynamically allocating resources and puttingto sleep BBUs in the BBU pool. That work, however, does notdiscuss potential implementation paths.

Very little literature is available on C-RAN-based sleepmode techniques which include experimental investigationwith real hardware prototypes. An exception is the C-RANframework ”FluidNet” [7]. They implement a WiMAX basedprototype that adaptively shifts between a Distributed AntennaScheme (DAS) and Fractional Frequency Reuse (FFR) schemebased on traffic variations. However, the mechanisms of howBBUs switch from sleep mode to operational mode are notclearly described and the focus is only on a controller basedapproach.

Another practical C-RAN-based sleep mode publicationis [8], where the authors use a game theoretic algorithm tooptimize the power consumption of the C-RAN by poweringoff a subset of RRHs. While this approach puts subsets ofRRHs to sleep, it does not address the issue of sleeping BBUs.

Coverage of Macro Cell

Coverage of Small Cells

RRH M

Coverage of Small Cells

BBU 2

BBU M

BBU 3

BBU 4

BBU 5

BBU 1

BBU Pool Controller

RRH 1 RRH 2

RRH 3

RRH 4RRH 5

Fronthaul

Fig. 1: Envisaged heterogeneous network architecture

The existing literature does not implement the signal pro-cessing functionality needed at the RRH to drive the transitionof some part of the BBU pool from sleep mode into operationalmode. This is the challenge that we address in our paper,and in particular in our implementation of the Wake-on-RRHapproach.

III. SYSTEM MODEL

As illustrated in Fig. 1, we consider a heterogeneous C-RANnetwork scenario, where coexisting macro cells and small cellsare fronthauled over a wired link. BBU M and RRH M denotethe RRH and the BBU for the macro cell, while BBU 1-5and RRH 1-5 denote the ones for small cells. In particular,small cells augment capacity in areas already covered by amacro cell. Each RRH is logically mapped to a BBU withinthe BBU pool in a one-to-one manner. This reflects a typicalC-RAN-based heterogeneous network scenario, where inter-cell interference is prevented by using a Fractional FrequencyReuse (FFR) scheme, i.e. by allocating different spectral sub-bands to edge users in neighboring cells [9].

In this scenario, the macro cell always remains active, whilethe small cells are put to sleep when the network load is low.In this paper, put to sleep includes two cases: the BBU canbe powered off or placed in standby mode. Further details aregiven in section IV and V.

In our approach, the BBU is put to sleep when the numberof users connected to its corresponding RRH drops below apre-defined threshold Toff . Before a BBU is put to sleep, itshould handover the users’ connections (if there are still any)to the macro RRH that stays in operation. Similarly, whenlocal demand in mobile traffic rises and the number of usersexceeds a certain Ton, the BBUs are woken up.

The way in which Ton is monitored is slightly different forthe two approaches that we propose and evaluate in this paper.In Wake-on-RRH, the RRH monitors the number of users thatrequest access to the network within its coverage area andwakes up its corresponding BBU, once it detects more thanTon users. In Wake-on-BBU, the BBU pool controller monitorsthe users attached to the macro cell to wake up the small cells.To know which small cell to wake up, ideally, the controllerwould have user location information. This would allow the

RRHBBU

I/Q or Wake-on-LAN

RF trans-ceiver

DAC

ADC

DUC

I/Q balanc-ing &

scaling

DDC

CHDR Framer /Deframer

Wake-on-LAN pattern

Traffic demand monitor

(PRACH detector)

via GigEth

MUXCHDR

Framer/Deframer

PHY(including

PRACHdetector)

MAC and upper layers

Fig. 2: Block diagram of the Wake-on-RRH approach

controller to keep track of the users that would be covered bythe small cell, if it was powered on. It would wake the cell up,if this counter surpasses Ton. If no user location informationis available at the controller, sub-optimal solutions must beused. Further details on the sleeping and waking up schemesare elaborated in the following two sections.

IV. WAKE-ON-RRH APPROACH

Conventional C-RAN architectures reduce the digital pro-cessing functionality of RRHs to a minimum and exchangeraw digitized baseband I/Q data via the BBU-RRH fronthaulinterface [10]. All the functionality left to the RRH is digitalup/down conversion, digital/analog conversion and basic signalconditioning like crest factor reduction or digital predistortion.

The Wake-on-RRH approach slightly changes this func-tional split by adding a user detection block and a WoL magicpacket generator to the RRH. Fig. 2 shows a block diagram ofBBU and RRH functionality, with the traditional processingblocks in grey and the added elements in green.

While the energy saving scheme puts certain BBUs tosleep, their associated RRHs stay operational all the time topermanently monitor the current communication demand. Thisis done via an added user detection block, which preferablycomprises threshold functionality. It detects user connectionrequests to the macro cell and triggers sending the WoLmagic packet when required. This WoL functionality relieson LAN connectivity between RRH and BBU. Since Ethernetis a strong candidate for future fronthauling [11], this is areasonable assumption. For our experiment, we set up theBBU-RRH interface with the Ettus-specific radio transportprotocol CHDR over Ethernet, with similar functionality toCPRI [12].

To implement our Wake-on-RRH scheme, we use LTE asa proof-of-concept. Generally, when an LTE User Equipment(UE) is switched on, it follows an initial access scheme to ini-tiate synchronization with the eNodeB frame timings, identifythe cell and gather all the relevant system information beforeregistering on to it via the random access procedure. In particu-lar, no UE sends out any network access request before receiv-ing system information, which is regularly broadcast by eachoperational eNodeB. This information includes the primarysynchronization signal (PSS), the secondary synchronizationsignal (SSS), as well as master and system information blocks- Master Information Block (MIB) and System InformationBlock 2 (SIB2) [13]. The Physical Random Access Channel(PRACH) preamble is then the uplink response, associated to

this kind of information and, hence, dedicated to the specificeNodeB to which the UE wishes to attach. While PRACH isan LTE concept, user access in future standards like 5G islikely to show strong similarities to this.

For our wake-on-RRH approach, the aforementioned userdetection block, which adds to the RRH, is a PRACH preambledetector. The RRH functionality is covered by an USRP X310,which is a high-performance, scalable SDR platform fromEttus Research with a large user-programmable Xilinx Kintex-7 FPGA [14]. We customized the standard Ettus FPGA designby adding a multiplexer, a magic packet transmitter and aXilinx LTE RACH detector LogiCORE [15].

This IP core decodes the PRACH preamble according tothe 3GPP TS 36.211 specification [13]. The Xilinx PRACHdetector core allows for arbitrary configuration of any in-volved PRACH parameters, such as RACH format, numberof antennas, antenna quantization, LTE bandwidth, etc. Thus,it can be configured according to the parameters of theneighboring eNodeB M (corresponding to the BBU M andRRH M of the macro cell) and monitor in this way all newUE connection establishments with it. In other words, UEresource allocation activity of this neighboring eNodeB M ispermanently eavesdropped on by the new PRACH detector ofthe RRH.

Waking up the BBU then simply means to multiplex be-tween the antenna input and a WoL magic packet source at theRRH receiver flow, as needed. Once the associated BBU wakesup, the LTE software starts to run again, with the specificbroadcast parameters of the small cell. New users can thenreceive this broadcast information and connect to the newlyturned-on cell.

Fig. 3 shows a flow diagram example of the Wake-on-RRHapproach, with two eNodeBs, one with sleeping functionality(eNodeB 1) and one for permanent operation (eNodeB M).Following this flow diagram from top to bottom, three UEsare powered on, one at a time, for initial access. The firstUE, i.e. UE 1, transmits in its initial access procedure aPRACH signal which is configured to match eNodeB M’ssystem information broadcast. Although configured not foreNodeB 1, the RRH of eNodeB 1 is designed to sense, i.e.eavesdrop on, the PRACH signal. In particular, the transmitterfunctionality which handles this sensing is the only functionblock of eNodeB 1 which stays operational even in sleepmode. In order to make use of the absolute number ofPRACH requests to eNodeB M, eNodeB 1 has to apply aresource thresholding scheme of choice (e.g. [4], [16], [17])to detect when eNodeB M cannot serve any more UEs. In theexemplified flow diagram, this happens after UE 1 and UE 2have registered successfully to eNodeB M, making UE 3 thefirst one to register with eNodeB 1.

Our experimental proof-of-concept for the wake-on-RRHapproach is shown in Fig. 4. It follows the LTE terminology(eNodeB, UE) and implements all functional blocks fromFig. 2. We have successfully carried out tests with this set-up,where PRACH sequences sent by the UE are detected by theRRH of the sleeping eNodeB, and the magic packet sent from

eNodeB 1BBU

(sleeping) RRH

(in operation)

eNodeB MRRH

(in operation)BBU

(in operation)

PRACH

Ue 3 (inital access)

RRC connection

resource threshold eNodeB M reached

WoL

resource threshold eNodeB M detected

eNodeB 1BBU

(in operation) RRH

(in operation)

PRACH

RRC connection

eNodeB MRRH

(in operation)BBU

(in operation)

Waking up/ Booting

StartingSystem Service:

LTE software

Ts1

Ts2

Wak

e-u

p

Late

ncy

RRC connection

Ue 2 (inital access)

Ue 1 (inital access)

Fig. 3: Flow diagram RACH procedure example

the sleeping eNodeB’s RRH wakes up the BBU. A photographof this set-up is shown in Fig. 5. The eNodeB is placed on thetable on the left, with the laptop serving as the BBU and theX310 USRP as the RRH. At the back of the same table, thereis a small black Ethernet switch, which ensures high enoughpower levels of Ethernet transmission. It adds no functionalityto the fronthaul. The B210 USRP on the table on the rightserves as a UE. In our experiment, it permanently sends outPRACH signals. The laptop next to it hosts the correspondingsoftware part of the SDR. The spectrum analyzer in the backmonitors the PRACH transmission.

While in our particular implementation, any PRACH se-quence detection triggers a WoL magic packet transmission,a possible future extension is to include a detection counter,which relates the number of UE PRACH preambles to theaforementioned Ton threshold. Another possible extensionwould be to disable the PRACH detector once the magicpacket is sent. This is necessary to ensure that the flow of I/Qsamples is not interrupted by other users that try to connectto the macro cell after the BBU is woken up. This extensionwould mean that the BBU would have to re-enable the detectorbefore it goes to sleep.

The FPGA implementation adds only a negligible additionallatency to the total WoL latency of waking up a server, as willbe seen in the next section. The PRACH detector core canbe configured to only 2 clock cycles processing time and theWoL transmitter sends out the magic packet within 216 clockcycles. At an LTE-typical clocking frequency of 184.32 MHz,this stays below 1.2 ms of added latency.

Ubuntu 14.04LTE-like OFDM -

GNUradio

USRP X310

GigEth

RRH (always on)BBU (sleeping) I/Q or

Wake-on-LANUSRP B210

Uplink PRACH transmission

eNodeB 1 UE(initial access)

Fig. 4: Diagram of the experimental Wake-on-RRH set-up

Spectrum Analyzer

RRHBBU

UEeNodeB 1

Fig. 5: Photograph of the experimental Wake-on-RRH set-up

V. WAKE-ON-BBU APPROACH

In C-RAN architectures, the BBU pool is usually controlledby a centralized software controller that has the capability ofmonitoring the individual BBUs. In this section, we describeour solution whereby the controller of the BBU pool isresponsible for dynamically putting to sleep and waking upBBUs; we name this approach Wake-on-BBU. Fig. 1 is againthe baseline network scenario, where the macro cell alwaysstays operational to guarantee coverage and transmit broadcastsignals. The controller of the BBU pool puts BBUs to sleepvia remote access and wakes them up using Ethernet WoLtechnology.

In the Wake-on-BBU approach, the controller monitors thesubscribers associated with each operational small cell, puttingthe cell to sleep when the number of users goes below Toff .To wake up sleeping cells, the way users of small cells aremonitored depends on the location information available at thecontroller. If the controller has geo-location information aboutthe users, it is able to map the users of the macro cell to thesmall cells that would serve them and wake up those smallcells. Without location information, the controller has onlysub-optimal options available. One of these options is to turnon all small cells once the number of users in the macrocellreaches a certain Ton threshold. Another is to turn on smallcells one-by-one randomly. Neither of these is ideal.

To illustrate our proposed Wake-on-BBU solution, we im-plemented a prototype of a BBU pool and its controller in anSDR testbed. Fig. 6 illustrates the experimental set-up. Thecontroller and the macro BBU functionality are implemented

Ubuntu 16.04Customized Controller

ProgramLTE BBU software -

srsLTE

Ubuntu 16.04LTE BBU software -

srsLTE

Ethernet Switch

USRP B210

USRP B210

BBU Pool

USB 3.0

USB 3.0

RRH M (always on)

RRH 1 (sleeping)

BBU M (always on) & Controller

BBU 1 (sleeping)

Fig. 6: Diagram of the experimental Wake-on-BBU set-up

in a PC with Intel-i7 general purpose processor (PC 1) usingthe open source software srsLTE [18]. We also implementthe BBU 1 with srsLTE on another PC with Intel-i7 processorwith Wake-on-LAN mode enabled. The srsLTE is an LTEsoftware radio solution, compliant with 3GPP LTE release 8.The RRHs are emulated by B210 USRPs [19], which are fullyintegrated, single-board radio front-ends and SDR platforms,similar to the abovementioned X310 USRPs, but equippedwith less powerful FPGAs.

In this experiment, we investigate two alternatives of puttingBBUs to sleep: completely powering off the BBU or setting itto standby. The WoL magic packet can wake up a BBU fromboth standby or powered off states.

In our experiment, in order to put BBU 1 to sleep (can beeither standby or powered off ), the controller establishes anSSH connection and sends a command to BBU1. For wakingup BBU1, the controller sends a WoL magic packet. ThesrsLTE software then starts to operate on BBU 1 and RRH 1starts to transmit a downlink signal in the Physical DownlinkShared Channel (PDSCH) after waking up. For both cases ofstandby and powered off, we add a operating system serviceto run the LTE software automatically when waking up.

To measure the wake-up times, we synchronize the systemtime of the controller and BBU 1 and measure the wake-up latency by collecting two timestamps at Ts1 (when thecontroller sends out the WoL magic packet) and Ts2 (whenRRH 1 starts transmitting signals). The wake-up latency equalsthe time difference ∆T = Ts2 − Ts1.

TABLE I: Wake-up latency with standby or powered off BBU

Average Min Max StandardDeviation

standby 8.2 s 8 s 9 s 0.41 s

powered off 26.55 s 20 s 35 s 4.27 s

Table I shows the measurement results of the wake-up

latency. As mentioned before, we test two cases in ourexperiments: a) set the PC (BBU) to standby and b) completelypower off the PC (BBU). The power saving is greater whenthe BBU is completely powered off but, as expected, the wake-up latency is larger in this case. The average latency for thecase of setting BBU 1 to standby is around 8 seconds, whilethe average latency for the case of completely powered off isaround 27 seconds. The standard deviation of the latency forthe case of completely powering off the PC (BBU 1) is alsohigher than the one for the other case of setting BBU 1 tostandby.

Putting these latency numbers in the context of radio accesstechnology, it becomes clear that the abovementioned wake-up thresholds, i.e. the metric to decide about waking up ornot, needs to be chosen with care. Enough safety margin isnecessary in order to initiate the wake-up routine early enoughand be operational before the master BBUs run out of capacity.This means the upper threshold Ton needs to be defined lowerthan the capacity of the macro BBU.

No detailed power consumption numbers shall be given herefor each of the two cases, because these numbers vary a lotdepending on the computing platforms on which the BBUs andcontrollers are running. Nevertheless, the qualitative relativepower saving analysis holds in general.

VI. COMPARISON OF THE TWO APPROACHES

As mentioned above, the two presented energy savingschemes differ in the way that BBUs are woken up. While bothapproaches (re-)activate sleeping BBUs via WoL magic pack-ets, these packets are transmitted either by a controller withinthe BBU pool (Wake-on-BBU approach) or by a correspondingRRH (Wake-on-RRH approach). From the perspective of thesleeping BBUs, the two approaches do not differ. In particular,there is no significant difference in BBU wake-up latency. Ina system context, however, both approaches have their ownbenefits, which are summarized in table II.

First of all, the type of digital processing platform matters.The Wake-on-BBU approach can cover the additional requiredfunctionality (traffic demand sensing and WoL functionality)by the centralized software controller within the BBU pool,i.e. by software on a general purpose processor. In contrast,the digital processing platform for any RRH must be ahardware solution, such as an Application Specific IntegratedCircuit (ASIC) or an FPGA [20]. This is because of the tightrequirements of C-RAN architectures, which dictate utmostRRH processing efficiency regarding speed and latency. Thiscannot be met by software. Although there are no such tightperformance requirements for the processing blocks which weadd for the Wake-on-RRH approach (i.e. the green blocks ofFig. 2), it is still essential to implement these extra blockstogether with the conventional RRH functionality on the RRHhardware. Only this allows us to keep the RRH receiverchain operational while the attached BBU can be turned offcompletely. An added value of carrying out the added func-tionality on hardware rather than on software comes in termsof reduced energy consumption. Moreover, a huge advantage

TABLE II: Comparison of the two energy-saving approaches

Wake-on-RRH Wake-on-BBU

Digitalprocessing

solution

Hardware - Deterministic,more energy efficient

Software - Less complexitythrough a higherabstraction level

Informationpool

PRACH interpretation only PHY layer & higher layerinformation available to

decide whether to wake upa BBU

Modificationeffort

Need for a second PRACHdetector at the RRH

Software controllers inconventional C-RAN

already access informationabout number of users

Fronthauling Fronthauling must supportEthernet for WoL

functionality

Any kind of fronthaulingworks

Interoperability BBU M and woken upBBUs can be spread across

different BBU pools

BBU controller cancoordinate only BBUs in

the same BBU pool

Infrastructuredependency

Potential enhancement forRRH: Adding system

information broadcast andparametrize it to match

with own PRACH receiver- All BBUs can be put tosleep and no need for a

specific BBU infrastructure

No possibility to makeapproach independent of

BBU controller

Userlocalization

RRH will detect the usersthat are in range

Requires user localizationto be more accurate

of Wake-on-RRH due to its hardware-based implementation isdeterminism: processing latency is known in advance and isfree from jitter. Further, processing performance is not affectedby any other functionality, which runs in parallel on the RRH.

PRACH detection is a pure PHY-layer technique. Relyingonly on this makes the Wake-on-RRH approach blind to upperlayer information. In the Wake-on-BBU approach, in contrast,the centralized controller in the BBU pool also accesses MAC-layer information about currently allocated resource elements,available to the MAC schedulers. Merging PHY- and MAC-layer information can help the Wake-on-BBU approach tocome to better predictions when to ideally wake up otherBBUs.

Wake-on-BBU requires less modification to conventional C-RAN architectures compared to Wake-on-RRH. It demandsonly a software update on the centralized BBU controller toenable the interpretation of already available information. Incontrast, we realize the Wake-on-RRH approach by addingcompletely new processing blocks in hardware (PRACH de-tector & WoL magic packet transmitter).

The fronthauling solution of the Wake-on-RRH approachmust support Ethernet based transmission of I/Q samples toallow for WoL transmission. The Wake-on-BBU approach, onthe other hand, does not set any restrictions here.

The Wake-on-BBU approach can only coordinate BBUsbelonging to the same BBU pool, while the BBU-RRH pairing

of the Wake-on-RRH approach is independent enough toallow its PRACH detection to be parametrized according todistinctive PRACH patterns of neighboring BBU pools. Thismakes the Wake-on-RRH approach less dependent of thespecific RAN infrastructure.

In LTE, the UE does not send out any PRACH pream-ble before receiving system information (PSS/SSS/MIB/SIB2signals), which is regularly broadcast by each operationaleNodeB. The Wake-on-RRH approach does not send out thisinformation itself, but eavesdrops on the response of UEs tobroadcasts of other eNodeBs. A next development step of theWake-on-RRH approach could be to let the RRH send outits own broadcast information while its corresponding BBUis sleeping. This makes the BBU-RRH pairing completelyindependent of any specific RAN architecture. Further, indoing so, BBUs could be put to sleep altogether if not needed.

Finally, the Wake-on-BBU approach requires user locationinformation, to be able to know which RRH to wake up. With-out this, the controller can only make sub-optimal decisions,such as waking up all small cells or waking up small cellsrandomly. Wake-on-RRH, on the other hand, naturally detectsusers that are close to the eavesdropping RRH. Thus, it doesnot need this information.

VII. CONCLUSION AND DISCUSSION

In this paper, we demonstrate and compare two energy sav-ing schemes for heterogeneous C-RAN architectures, namelyWake-on-BBU and Wake-on-RRH. BBUs of small cells areput to sleep when the network capacity of coexisting macrocell suffices for coverage. When traffic demand rises, theseBBUs are reactivated using Wake-on-LAN (WoL) technologyin both approaches. We provide a design and proof-of-conceptby experimental prototyping for both wake-up schemes andmeasure wake-up latency. For the Wake-on-RRH approach,WoL is triggered by the RRH which corresponds to the sleep-ing BBU. For the Wake-on-BBU approach, this is done by acontroller within the same BBU pool. Prototype measurementsyield wake-up latencies of several seconds. This is too high forreal-time signaling in LTE and will similarly apply to futurecommercial networks with WoL technology. A solution arethreshold schemes, which provide enough lead time so thatthe BBU can change from sleep mode to operational modebefore being actually needed. A variant of this is near-futuredemand estimation, as proposed in [8]. This calls for futurework on optimal strategies to determine adequate thresholdschemes.

Apart from wake-up latency, further categories are identi-fied, where Wake-on-BBU and Wake-on-RRH differ more sub-stantially. A comparison does not bring up a clear favorite, butreveals certain strengths and downsides for both approaches,which are mainly platform- and architecture-related. Bothapproaches comply with current LTE standards and can bepotentially applied in larger scale C-RAN architectures in nextgeneration mobile networks, such as 5G networks.

ACKNOWLEDGMENT

This publication has emanated from research conductedwith the financial support of Science Foundation Ireland (SFI)and is co-funded under the European Regional DevelopmentFund under Grant Number 13/RC/2077 (CONNECT), grantno. 14/IA/2527 (O’SHARE) and by the European CommissionHorizon 2020 Programme under grant agreement no. 688941(FUTEBOL). We also thank Xilinx for support on the LTERACH Detector LogiCORE and SRS for support on srsLTE.

REFERENCES

[1] A. Checko, H. L. Christiansen, Y. Yan, L. Scolari, G. Kardaras, M. S.Berger, and L. Dittmann, “Cloud RAN for Mobile Networks - A Tech-nology Overview,” IEEE Communications Surveys Tutorials, vol. 17,no. 1, pp. 405–426, 2015.

[2] L. Suarez, L. Nuaymi, and J. Bonnin, “An overview and classificationof research approaches in green wireless networks,” EURASIP Journalon Wireless Communications and Networking, no. 1, p. 142, 2012.

[3] WireShark Wiki. WakeOnLAN (WOL). Accessed 03/2017. [Online].Available: https://wiki.wireshark.org/WakeOnLAN

[4] J. Wu, Y. Zhang, M. Zukerman, and E. K. N. Yung, “Energy-EfficientBase-Stations Sleep-Mode Techniques in Green Cellular Networks: ASurvey,” IEEE Communications Surveys Tutorials, vol. 17, no. 2, pp.803–826, 2015.

[5] I. Ashraf, F. Boccardi, and L. Ho, “SLEEP mode techniques for smallcell deployments,” IEEE Communications Magazine, vol. 49, no. 8, pp.72–79, August 2011.

[6] M. Khan, R. Alhumaima, and H. Al-Raweshidy, “Reducing energyconsumption by dynamic resource allocation in C-RAN,” in EuropeanConference on Networks and Communications (EuCNC), 2015.

[7] K. Sundaresan, M. Y. Arslan, S. Singh, S. Rangarajan, and S. V.Krishnamurthy, “FluidNet: A Flexible Cloud-Based Radio Access Net-work for Small Cells,” IEEE/ACM Transactions on Networking, vol. 24,no. 2, pp. 915–928, 2016.

[8] N. Saxena, A. Roy, and H. Kim, “Traffic-Aware Cloud RAN: AKey for Green 5G Networks,” IEEE Journal on Selected Areas inCommunications, vol. 34, no. 4, pp. 1010–1021, 2016.

[9] M. Y. Arslan, K. Sundaresan, and S. Rangarajan, “Software-definednetworking in cellular radio access networks: potential and challenges,”IEEE Communications Magazine, vol. 53, no. 1, pp. 150–156, 2015.

[10] D. Wubben, P. Rost, J. S. Bartelt, M. Lalam, V. Savin, M. Gorgoglione,A. Dekorsy, and G. Fettweis, “Benefits and Impact of Cloud Computingon 5G Signal Processing: Flexible centralization through cloud-RAN,”IEEE Signal Processing Magazine, vol. 31, no. 6, pp. 35–44, 2014.

[11] N. J. Gomes, P. Chanclou, P. Turnbull, A. Magee, and V. Jungnickel,“Fronthaul evolution: From CPRI to Ethernet ,” Optical Fiber Technol-ogy, vol. 26, Part A, pp. 50 – 58, 2015.

[12] J. Malsbury and M. Ettus, “Simplifying FPGA Design with a NovelNetwork-on-chip Architecture,” in Proceedings of the Second Workshopon Software Radio Implementation Forum (SRIF). ACM, 2013, pp.45–52.

[13] 3GPP ETSI TS 136.213, “Physical layer procedures,” 3rd GenerationPartnership Project, Tech. Rep. v9.0.0, 2009.

[14] USRP X310, Ettus Research, accessed 03/2017. [Online]. Available:https://kb.ettus.com/X300/X310

[15] “LogiCORE IP LTE RACH Detector,” Xilinx, Product Brief v2.0, 2015.[16] H. Yao, C. Fang, C. Qiu, C. Zhao, and Y. Liu, “A novel energy efficiency

algorithm in green mobile networks with cache,” EURASIP Journal onWireless Communications and Networking, no. 1, p. 139, 2015.

[17] F. G. Debele, N. Li, M. Meo, M. Ricca, and Y. Zhang, “Experiment-ing Resource-on-Demand Strategies for Green WLANs,” SIGMETRICSPerform. Eval. Rev., vol. 42, no. 3, pp. 61–66, 2014.

[18] P. Sutton and I. Gomez. srsLTE: Open source 3GPP LTE library. Ac-cessed 03/2017. [Online]. Available: https://github.com/srsLTE/srsLTE

[19] USRP B210, Ettus Research, accessed 03/2017. [Online]. Available:https://kb.ettus.com/B200/B210/B200mini/B205mini

[20] P. Newson, “The Application of FPGA for Wireless Base-Station Con-nectivity,” Xilinx, White Paper WP450, 2015.