Service Aware Adaptive DRX Scheme

Geza Szabo∗, Gergely Pongracz∗, Istvan Godor∗, Rickard Coster∗, Mathias Sintorn∗

∗Ericsson Research, [{geza.szabo, gergely.pongracz, istvan.godor, rickard.coster, mathias.sintorn}@ericsson.com]

Abstract—Discontinuous Reception (DRX) in Long Term Evo-lution (LTE) is used to reduce the energy consumption whenthere is no data transfer for a given user. Current DRX workson a per-UE basis but works with fixed DRX. That is, DRXdoes not take into account that different services and differentterminals have different requirements on Quality of Experience(QoE). We propose an efficient adaptive DRX method that canprovide battery saving without degrading QoE of the services.This method utilizes service and terminal knowledge providedby Deep Packet Inspection (DPI) mechanism and modifies theDRX settings adaptively on the fly. This unique work analysesanonymous traffic data from an operational mobile broadbandnetwork and emulates the effects of various DRX settings uponthis live traffic data. Live traffic has larger variance in thetimescale of DRX than it is assumed by models used in state-of-the-art DRX schemes. Thus the proposed method outperformsexisting solutions and get closer to the theoretically ideal case.

Keywords: adaptive, discontinuous reception, quality of experience

I. INTRODUCTION

A mobile terminal is supposed to monitor the controlsignals continuously to be able to send and receive data. InLong Term Evolution (LTE), these control signals are sent onPhysical Downlink Control Channel (PDCCH). Neverthelessmonitoring PDCCH becomes a waste of radio resources andbattery power particularly if no uplink (UL) or downlink (DL)transmission is scheduled for longer periods. DiscontinuousReception (DRX) is one possible solution to avoid this. Thatis, a user equipment (UE) stays asleep and wakes up only atparticular interval of times to monitor PDCCH for possibledata transfer. During DRX sleep the UE is unable to receiveany packets. This way DRX will increase not only batterylife, but unfortunately delay, as well. This results in a trade-off between increasing battery life and decreasing delay beingour two objectives.

Today’s multitude of different Over The Top (OTT) ser-vices for mobile devices indicates a large variation of trafficpatterns. This variation should be taken into account whensetting the DRX parameters. DRX works on a per-UE basis, itdoes not take into account that different services and differentterminals might have different QoE requirements. However,OTT services cannot utilize radio bearer based differentiation.As a consequence, conservative methods are applied in thenetworks to keep the QoE on a good level independently oftraffic type. However, such methods inherently results in moreenergy usage than theoretically needed in case of dynamicallychanging traffic environment.

Our goal is to create a system capable of improving thecurrently implemented energy saving mechanisms of the state-of-the-art DRX methods while keeping the perceived QoE ofthe users on the same level. Our solution solves these tasks byutilizing service and terminal knowledge gained from Deep

RRC_CONNECTED

RRC_IDLE

Continuous/

Active

Long DRX

Latency

Inactivity

Short DRX

(ECM –IDLE)

RRC_IDLE

Continuous/

Active

Long DRX

Po

wer

co

nsu

mp

tio

n

Activity

DRX cycle P1

Short DRX

T3

T2

DRX cycle P2

DRX cycle P3

Inactivity

Inactivity

sleep

on

duration

sleep

on

duration

DRX = Discontinuous Reception

RRC = Radio Resource Control

PDCCH = Physical DL Control

Channel

T = Time

P = Period

UE monitors paging channel

UE monitors PDCCH T1

T0

T0

Fig. 1. The DRX state machine and timers

Packet Inspection (DPI) mechanism. Based on the gatheredinformation the DRX parameters are changed on the fly, beingadapted to the traffic type in progress. That is, our solutionmaximizes battery saving in UEs, while still delivering packetswithout excessive extra delay degrading QoE.

One of the main contributions of the paper is the evaluationof the DRX systems on real world data that is a kind ofresource that academic research is scarce of. That can be thepossible reason why similar solutions have not been introducedand the evaluation of the state-of-the-art methods have not beendone with real world traffic so far. The evaluation of the fixedtimer based DRX scheme is valuable on its own to let operatorsuse the results for fine-tuning their systems accordingly. Weshow that on the time granularity that DRX works, it is difficultto introduce an adaptive DRX system that does not cause moreharm than good for the users either in terms of QoE or batterysaving. Further, this work clearly shows the trade-off betweenenergy saving and QoE insurance that is neglected by formerpapers focusing on solely one of the aspects.

First Section II presents the optimization problem includingQoE aware metrics and simulation principles. Section III givesa brief overview of existing DRX methods. Section IV presentsthe concept of our proposed system. Section V evaluatesexisting solutions and our proposal including the ideal DRXscheme, as well. Section VI shows some real life consequencesof DRX on battery life and signaling impact in networks.Finally, Section VII concludes the paper.

II. PROBLEM STATEMENT

A. DRX in general

Discontinuous Reception (DRX) [1] is a functional-ity provided in LTE for UE battery saving within theRRC CONNECTED mode. In the DRX mode, the UE does

2

not have to constantly monitor control channels, but onlyduring specific time intervals. Between these intervals, the UEcan save energy and battery by going into energy saving state.

Beyond the normal active state, two cyclical DRX states– Short DRX cycle and Long DRX cycle – are definedaccording to how often the UE should monitor control chan-nels, especially PDCCH. The state machine is illustrated inFigure 1. After a downlink packet is received in Active state,an Inactivity Timer T1 is started. When the inactivity timerT1 expires, the UE switches to Short DRX state. In this state,the UE can only receive packets during the ’on duration’ (T0)time interval in the beginning of every cycle with a periodicityof Short DRX cycle length (P1). If a packet is received, the UEswitches back to Active mode. Otherwise, a Short DRX CycleTimer T2 is started. T2 is practically the multiplication of P1with a system parameter. When T2 expires, the UE switches toLong DRX state. This state works similarly to the Short DRXstate, but with longer periodicity of Long DRX cycle length(P2). If a packet is received, the UE switches back to Activemode. Otherwise, a Long DRX Cycle Timer T3 is started andthe UE can switch down the RRC IDLE state when T3 expires.Uplink data packets always trigger that the UE goes to Activemode if it is not already there.

There are a number of parameters that can be configuredin the DRX state, such as On-duration Timer, Inactivity Timer,length of Short and Long DRX Cycle period, Short CycleTimer, etc. These parameters can be configured for each UEseparately.

B. Ideal adaptive DRX

To create a base line for comparison of the DRX methods,we defined an ideal adaptive DRX method targeting thetheoretical minimum DRX delay. This delay is calculated asthe time elapsed from a packet arriving to the base station tillthe UE returns to active state and the packet can be actuallysent to it. Naturally, the higher the DRX short cycle length(P1) the bigger the expected DRX delay is.

Ideal DRX is calculated with a 100% accurate traffic’predictor’. The calculation takes the inter arrival time (IAT)between two LTE packets and finds the lowest amount ofDRX cycles to cover the IAT with the lowest possible T0timer (1 ms). E.g., if IAT is 56 ms then a 32 ms P1 timer istaken, after its timeout the remaining 24 ms gap is handled byswitching to 16 ms P1 timer, finally the remaining 8 ms witha 8 ms P1 timer (for more examples, see Table I). The natureof this approach is even more theoretical if we consider thatP1 timer should be modified after each Short DRX cycle.

Note that, this way of minimizing delay does not necessar-ily result in the lowest achievable energy consumption sincein all cycles the UE should be in operation during each T0

[ms] sf2

sf5

sf8

sf1

0

sf1

6

sf2

0

sf3

2

...

sf2

56

sf3

20

sf5

12

sf6

40

17 X X X

56 X X X

973 X X X X

TABLE I. EXAMPLE OF P1 TIMER SETTINGS FOR IDEAL ADAPTIVE

DRX CALCULATION

Packet processing in

existing scheduling cycle

and set TSCE += Tsend

Create new ongoing

scheduling cycle and set

TSCS = Tprev

Create new scheduling

cycle in future and set

TSCS = Tnext

Packet in new on-

duration period?

Tpacket � Tprev + Tondur

Packet in existing

scheduling cycle?

Tpacket≤ TSCE

Packet processing in

next scheduling cycle and set

TSCE += Tsend

Packet before

scheduling cycle?

Tpacket < TSCS

Wait for new packet

Yes

NoNo

YesYes

No

1

2

3

4

5

6

7

8

Fig. 2. The flow chart of the emulation of the effects of DRX

periods of time. Nevertheless, Section V will show that eventhe slightest energy saving over this method would introduceextremely high extra delays.

C. Simulation principles

We claim that the traffic mix coming from real worldis important in the evaluation of DRX schemes, since thetraffic model greatly impacts the analysis. That is, ’monomode’standalone traffic models typically enlarge the achievableimprovements of the algorithms available in the literaturecompared to what one can see when testing these algorithmswith traffic coming from live networks.

We used live network data for evaluation of both the state-of-the-art methods and our proposed DRX scheme. The trafficwas measured in the busy hour of an LTE network with turned-off DRX in 2013. In order to have a manageable size of datafor simulations, we have worked with the data of 5 thousandanonymized users providing a statistically representative sam-ple. For each user a packet log was recorded containing thetimestamp and the application type recognized with DPI. Inpractice, DPI is usually not a standalone service in the network,but important part of the policy control functionalities (PCF).Moreover, most PCF has service aware extensions, whichdefinitely relies on DPI. Even if the traffic is encrypted, themain application types (e.g., media, gaming and file download)can be identified.

These logs were fed into the simulator and the effects ofthe different DRX settings were analyzed on per user basisaccording to the flowchart given in Figure 2 and can besummarized in the following 8 steps:

1) First we wait for a new packet. Actually there arefour next possibilities to process the data based on itstimestamp Tpacket (detailed in Steps 3, 5, 7 and 8).In general, the packet can be scheduled in schedulingcycles started according to the start of DRX cyclesand ended after the Inactivity Timer T1 expires. Thestarts are denoted by TSCS and the ends are denotedby TSCE (i.e. TSCE = TSCS + T1).

2) If there is no ongoing activity and the packet arrivesbefore an already defined next scheduling cycle, thengo to Step 3, else go to Step 4.

3) Process the packet in the next scheduling cycle andincrease the length of the scheduling cycle with thetime needed to send out a packet (denoted by Tsend).Go to Step 1.

3

4) If the packet fits into the actual scheduling cycle, thengo to Step 5, else go to Step 6.

5) Process the packet in the existing scheduling cycleand increase the length of the scheduling cycle withthe time needed to send out a packet (denoted byTsend). Go to Step 1.

6) If the packet fits into the T0 period of the actual DRXcycle (which cycle is not yet used for scheduling),then go to Step 7, else go to Step 8.

7) Create a new ongoing scheduling cycle started in thebeginning of the T0 period the packet fits in (denotedby Tprev , i.e., pervious DRX cycle compared topacket arrival). Go to Step 5.

8) Create a new scheduling cycle to be started with thenext DRX cycle (denoted by Tnext, i.e., the next DRXcycle compared to the packet arrival). Go to Step 3.

D. QoE aware cost metrics

Our focus in this paper is the perceived Quality of Ex-perience (QoE) and we define a cost function accordingly toevaluate the performance of the DRX methods. Mean OpinionScore (MOS) is applied in many aspects of QoE, however, itsapplicability is limited in our problem. First of all, there isno well-accepted / standardized MOS score for services likegaming and web browsing. Moreover, even the standardizedMOS scores, e.g., for voice or video, require lot of information,e.g., used codec, frame rate, etc. that is difficult to extract frompacket level information [2].

We claim that two main metrics affected by the DRXsettings are the cumulated active time being analogue tothe energy consumption and the download time of requestedpackets being analogue to the delay caused by DRX. Sincedelay has different visible impact on different types of services,we propose to assign cost both to active time and downloadtime. The proposed QoE aware weights for the cost function isillustrated in Table II. That is, the cost function is a weightedsum of energy and delay.

In case of interactive media and Real-Time (RT) media,the users are practically always on, meanwhile the downloadtime is important only if it surpasses the minimum timerequirements of a flawless media transfer. This later is true forthe gaming traffic, as well. Note that MAX means theoreticallyinfinite cost and a bad perceived quality of experience, thus itshould be avoided by all DRX setups.

In all other cases the consumed energy depends on theuser and application activity directly. In case of web servicethe perceived download time is affected by the DRX timer,i.e., when the UE can start to download the content. Onaverage, it will be the half of the DRX timer. The calculatedvalue refers to one webpage download only. Also note that ifDRX sleep is activated during the webpage download – it isquite possible when the user is in TCP slow start – a sum ofthese values should be applied. In case of on-demand medialike YouTube, there is no delay cost for the user, since it canbe played out from the buffer fluently.

Delay unit cost denoted by Cunitdelay and energy unit cost

denoted by Cunitenergy are considered with 1 sec time unit in our

calculations. In Table II limit1 is 100 ms, limit2 is 200 ms,the buffer size is 0.5 sec. The optimization problem of the

Service / terminal info Energy cost Delay cost

Service = gaming Activity * Cunitenergy

If P1 > limit1: MAX

else 0

Service = Interactive media

(e.g. voice or video call)Always on * Cunit

energy

If P1 > limit2: MAX

else 0

Service = RT media (e.g. live

broadcast)Always on * Cunit

energy

If P1 > buffer size:

MAX else 0

Service = web, social Activity * Cunitenergy P1 / 2 * Cunit

delay

Service = on demand media Activity * Cunitenergy 0

Service = peer-to-peer Activity * Cunitenergy 0

TABLE II. QOE AWARE ENERGY AND AND DELAY COST RATIOS

DRX proposal is to minimize the introduced QoE aware costfunction.

III. RELATED WORK

The DRX mechanism of the Universal Mobile Telecommu-nication System (UMTS) for mobile station energy saving wasinvestigated in [3]. The authors used a simplified DRX methodthat has two parameters: the inactivity timer threshold and theDRX cycle. An analytic analysis and simulation model wereproposed to study the optimal inactivity timer threshold and theDRX cycle selections that maximize the energy saving underthe given mean packet waiting time constraint. The proposedmethod in the paper works by adjusting the timers in tinysteps and examining the effects on the energy saving. Theresults in the paper depend on the applied traffic model. Theauthor presumes stable traffic mixes for approx. 20 minutes.We experienced that the traffic mix in our measurementschanged in the order of seconds thus such a method wouldbe not agile enough to react on the traffic mix changesresulting in less energy saving in practice. [4] extends thiswork by also adaptively modifying On-duration (T0) values.[5] provides an analytical approach with queuing theory toanalyze adaptive DRX schemes. This approach supports manyof our experiments and backs up, e.g., why we decided to usefix On-duration (T0) timer.

[6] proposes single and multi-threshold adaptive config-uration DRX mechanism which considers Channel QualityIndicator (CQI) reports to achieve energy saving comparedto fix DRX and also keep high system utilization or load onthe radio channels. Single threshold DRX scheme achieveshigh system load but no energy saving while multi thresholdDRX scheme achieves an approx. 20% gain in the energyconsumption of user terminals. Our focus is to achieve muchhigher energy saving while neglecting the system utilizationproblem.

[7] proposes a DRX scheme for LTE-A systems. TheDRX parameters are selected at connection establishment ofthe UE and the eNodeB according to the QoE parametersof the requested service. Their simulation resulted in 20-50% battery gain compared to the fixed timer based DRXscheme. We argue that their parameters in the simulation forthe conventional DRX system ensures clear advantage to theirproposed system (see, e.g., Figure 5 about how badly performsP1 = 10ms, T0 = 5ms in terms of energy consumption andhow easy it is to find better parameters). Moreover, real-timeor delay-tolerant packets were randomly generated during eachTTI, which results in an environment hindering the applicationof DRX without considering the delay aspects of the different

4

Service / terminal info Primary objective Secondary objective

Terminal: PC Minimize delay No

Terminal is on charger Minimize delay No

Service: RT media Limit delay (∼ 50 ms) Energy

Service: gaming Limit delay (∼ 50 ms) Energy

Service: web, social Limit delay (∼ 100 ms) Energy

Service: on demand media Energy Delay ≤ buffer length

Default (e.g. P2P, update) Energy No

TABLE III. METHOD FOR CALCULATING ENERGY AND DELAY COSTS

BASED ON TERMINAL TYPE, TERMINAL STATUS AND SERVICE TYPE

DRX settings. Similar approach is proposed in [8] in which theauthors’ DRX scheme exploits the bearer setup mechanism inthe LTE-A systems. Similarly to [7], their scheme can deducethe required QoS of the traffic from the requested bearerproperties. The DRX parameters are configured according tothe requested bearer type.

[9] puts the above methods in a more practical context. Theauthors propose an easy-to-implement adaptive DRX schemecalled Counter-Driven Adaptive DRX (CDA-DRX). It intendsto track the change of user activity and signaling overheadlevel and keep them minimized. Authors used Markov-modelsto evaluate the performance of their proposal. In spite of theartificial traffic model as input to their system, we still thoughtthat their proposal is the most agile for traffic mix changesamong all the above DRX proposals and worth to evaluate withreal word traffic. In Section V-C we evaluated this approachand compared to our proposal later in the paper.

IV. SERVICE AWARE ADAPTIVE DRX (SAA-DRX)

We propose a two-way DRX optimization that could takeinto account the service type and the terminal type or statuswhen deciding on the applied DRX scheme. The basic keyperformance indicator (KPI) selection can be seen in Table III.

The optimization program first checks the terminal typeand the status. If we find that the terminal is either a PCwhere DRX could not gain significant battery life due to high-consuming parts (e.g., big screen, CPU) or it is connected tothe power system no further decision is needed, the terminalcan always be in active mode. If that is not the case theused services have to be investigated. If we find out that theuser have interactive traffic, we can apply more delay-sensitiveDRX settings, like:

• In case of Real-Time (RT) media (e.g., voice, videoconference) it is not very that the terminal will switchto DRX mode due to inactivity, but in some casesit can still happen (e.g. due to codec behavior). AsRT media is a high-value service decreasing qualityof experience must be avoided, so if such a flow isdetected, either the mobile remains in active mode orapply only a small P1.

• In case of gaming the Round Trip Time (RTT) usuallymust be below 50 ms, meaning that the P1 shouldbe less than that - most probably DRX LONG mustnot be reached in this case at least for a given safetythreshold.

• In case of web browsing and social networks delay isonly important because of the response time, so there

P1 = 200P1 = MIN

Interactive

service?

Delay sensitive

service

P1 = LIMIT

No

YesYes

No

Fig. 3. DRX timer setup algorithm

are no hard requirements, but very long sleep timesshould be avoided (e.g., less than 200 ms).

If no interactive services present, then a more aggressiveDRX timer can be applied.

• In case of on-demand media there is only one limit:the delay must not exceed the buffer length. Sincebuffer length is usually in the order of ten seconds, itshould not be a problem.

• If none of the above is valid, e.g. the mobile is active,but it only runs background downloads (e.g. peer-to-peer or client cache traffic), DRX can be switched tomaximum energy saving mode which means that sleeptime can be increased without limit.

The proposed algorithm taking all the above requirementsinto consideration is given in Figure 3. The algorithm simplymaximizes energy saving by setting up a big DRX value, butif any more interactive traffic is started to be received by theUE, the DRX is altered accordingly to just meet the QoErequirements of the user, thus minimize DRX delay and alsomaximize energy saving.

The value MIN can be different based on user profile. Fortypical users it is the lowest configurable P1 length (2 ms),while for more battery sensitive users it could be higher (5-10 ms). The value LIMIT is the limit defined for the detecteddelay sensitive application. Either it could be a global limit thatis suitable for the most sensitive application, or a table could beused that contains the service type to LIMIT mapping for eachdelay sensitive service. In our experiments we set the value ofLIMIT to 20 ms, which does not limit media delivery speed butstill saves some battery. The value 200 ms is a static upper limitfor P1 keeping the delay below human perception level. At thesame time, this limits the chance that a new delay sensitive orinteractive service should wait too much if it arrives duringthe sleep period upper bounded by P1.

The DPI runs on a per packet basis thus theoretically theDRX setups can be altered on a packet level. The switching be-tween DRX setups induce signaling, thus the above theoreticalalgorithm would introduce huge signaling load on a real worldsystem thus reasonable thinning of the number of switchesis necessary when the algorithm is reduced to practice. Weintroduced a timer for each traffic type that counts the timepassed from the last occurrence of a specific traffic type. Aspecific traffic type is considered active after its last packet tillthe end of the timer. The aggressiveness of signaling can betuned via the timer parameter in this way. For more detailsabout signaling see Section VI-B.

It is important to note that the traffic types that we identifiedhave to be considered together with their related system or

5

0

2000

4000

6000

8000

10000

0 5 10 15 20 25 30 35 40 45 50

transm

itted

packet

[#/m

in]

time [min]

video

VoIP

web browsing

other

(a) Traffic of a user (packets/min)

0

200

400

600

800

1000

1200

1400

15 20 25 30 35 40 45 50

accumulated

delay

due

to

DRX

[sec]

time [min]

ideal

P1=0.002 sec

P1=0.01 sec

P1=0.128 sec

CDA!DRX

SAA!DRX

(b) Accumulated delay due to DRX

0

5

10

15

20

25

30

35

15 20 25 30 35 40 45 50

accumulated

QoE

delay

of

due

to

DRX

[sec]

time [min]

ideal

P1=0.002 sec

P1=0.01 sec

P1=0.128 sec

CDA!DRX

SAA!DRX

(c) Accumulated QoE delay due to DRX

0

100

200

300

400

500

600

15 20 25 30 35 40 45 50

accumulated

active

period

[sec]

time [min]

ideal

P1=0.002 sec

P1=0.01 sec

P1=0.128 sec

CDA!DRX

SAA!DRX

(d) Accumulated active period

Fig. 4. Effect of DRX settings on the traffic of the example user

signaling traffic e.g., an interactive web session is usuallypreceded by some DNS queries, or a VoIP session is precededby SIP messages. If we consider the DNS query or the SIPas background traffic, then it would delay the whole web andVoIP sessions as well.

V. EVALUATION

In this section, we evaluate the fix DRX scheme, the idealDRX scheme, the CDA-DRX selected as reference SOTAsolution and the proposed SAA-DRX scheme.

0

200000

400000

600000

800000

1000000

1200000

0 1000000 2000000 3000000 4000000 5000000

accumulated

delay

[sec]

active period [sec]

P1=[0.002;0.128], T0=0.001, T1=0.005

P1=0.010, T0=[0.002;0.008], T1=0.005

P1=0.010, T0=0.001, T1=[0.010;0.015]

ideal

CDA!DRX

SAA!DRX

P1=0.128

T0=0.008

T1=0.010

0.4302 160.0266

8.7029 354.3881

0.6303 339.7772

per packet

avg delay [ms]

per user active

period [sec]

Fig. 5. Total activity length vs. total delay in case of various DRX setups

A. Fix DRX

Current DRX implementations support that each UE canhave individual DRX settings, but the common solution is toset the same DRX parameters for all users in a network basedon selecting some parameters that work well for all types ofdata traffic and services.

As an example, we demonstrate the effects of DRX settingson the traffic of one selected user in Figure 4. Figure 4(a)shows the number of transmitted packets per minute of theselected user in the function of time. The selected user haslittle web browsing activity in the beginning of its lifetime,later a voice over IP (VoIP) session is initialized, then moreweb browsing and finally video occurs. In most of the casesthere is some background traffic which does not need anyQoE requirements. Figure 4(b) shows the accumulated DRXdelay while Figure 4(c) shows the QoE aware delay. Note thathow the delay cost of VoIP becomes practically zero due tothe fulfilled QoE requirements. The various DRX short timersetups with the fix DRX method is shown with red square,green triangle and violet circle. Increasing the DRX shorttimer clearly increases the accumulated delay. On the otherhand, Figure 4(d) shows that the energy consumption i.e., thetime spent in active mode is significantly higher of the shortDRX setting than the long one. The goal of the different DRXmethods is to address this trade-off.

If we do the DRX emulation for every user in our mea-surements and summarize these values for all the users thenwe get the cumulated DRX delays and active periods for all ofthe users in the measurement. Figure 5 shows the total delaylength in the function of the total active period length in caseof various DRX setups. We experimented with varying the P1short DRX length values (shown with blue squares), varyingthe T0 values (shown with green filled circles), and varyingthe T1 inactivity timer (shown with yellow triangles). The idealcase is shown with black square, the CDA-DRX is shown withviolet filled circle and the SAA-DRX is shown with red filledcircle. The theoretical trend lines for the various DRX setupsshow the trade-off between delay and energy consumption.Note that the values are QoE aware costs, see Section II-D indetails. It is important to emphasize how useful this figure is.As the summarized values represent the effect of the various

6

DRX settings for the whole population with real world traffic,this figure can be used on its own to tune LTE parameters inoperator networks. Analyzing the effects of parameter settingswe found the following.

• Inactivity timeout (T1) (active to DRX state) is bestat a small value, e.g., 5 ms. Increasing it does notdecrease delay cost significantly, but always increasesenergy cost.

• On-duration (T0) (the active period length in DRXmode) is best at the minimum value, 1 ms. Increasingit does not have effect on delay cost, but alwaysincreases energy cost.

• DRX short cycle length (P1) has a main role in bothenergy saving, and delay. Since there is a tradeoff thereis no single value that fits for all users and services.

So two out of the three main timers are not good candidatesfor optimization, leaving only the P1 timer to work furtherwith.

B. Ideal DRX

Figure 4(b) shows that the ideal adaptive DRX case (bluediamond) has the lowest accumulated DRX delay among allthe methods. Figure 4(b) shows that the energy consumptionis also ideal as only the 128 ms fix DRX method has loweraccumulated active period. Figure 5 shows that the ideal adap-tive DRX has low energy and delay for the total population aswell.

C. CDA-DRX

In the CDA-DRX scheme [9], a series of DRX cyclesare configured and sent to the UE by the network via RRCsignaling, based on QoS requirement of the established radiobearers. Switch between these DRX cycles is triggered bytwo counters that track the UE activity level in both UE andeNodeB. One counter counts consecutive active DRX periods.The other counter counts consecutive silent DRX periods.When one of the counters reaches the trigger threshold, theDRX cycle is extended or reduced in the UE and eNodeB.Since the eNodeB and UE have the exactly same knowledgeof data transmission between them, they will extend or reducethe DRX cycle in conformity, with no need of any RRC orMAC signaling. In other word, in the proposed CDA-DRXscheme, DRX cycle reconfigurations via RRC signal are notneeded.

We implemented the CDA-DRX scheme [9] to make itscomparison possible with other methods in our measurements.Our slight modification was that not the DRX cycle wasmodified but the DRX short duration value. Our goal was tomake the method to react on user behavior changes in themost agile way even if this setup results in high variance ofDRX cycles. This modification improves the energy savingefficiency of [9]. The initial DRX short duration was 10 ms,the On-duration (T0) was 1 ms. The following model settingsthat were used throughout in the paper. The active to DRXtimeout (inactivity) T1 is 5 ms, number of short DRX cyclesis 16, the DRX long to idle timeout is 2.56 sec. In Figure 4(d)the blue cross shows that the energy consumption is closest to

the ideal and even to the 128 ms fix DRX case. As a trade-off the Figure 4(b) shows that the accumulated DRX delay isnearly as high as in the 128 ms case.

We can learn two lessons from the example. One isthat even if the VoIP part has fix packet sending ratio, theinter-arrival times (IATs) have variance. Even if the adaptivealgorithm setups the DRX short cycle to match with the IATsbest there will be difference and small overestimation of thenext packet results in that the packet can only be scheduled inthe next cycle. The cumulated delay will be inevitably high.Such a simple strategy which constantly setups a shorter DRXthan the minimum IAT during the VoIP session, will not haveDRX delay practically. The other lesson is that letting thealgorithm setup high DRX values results in slow reaction touser behavior changes as it can be seen on Figure 4(b) whenvideo traffic occurs around the 45th min.

Considering the performance of CDA-DRX on the totalpopulation Figure 5 shows that the method has considerableenergy and delay costs as well. Note that this was a generalsetup, we did not optimized all the possible parameters givenin [9], which may provide better results in the long run.

D. SAA-DRX

Figure 4(b) shows that DRX delay of the SAA-DRXmethod is close to the fix DRX method with 10 ms DRXshort cycle and has lower active period (Figure 4(d)) close tothe performance of CDA-DRX. Note that in the QoE delay(Figure 4(c)) metric the SAA-DRX is very close to the 2 msfix DRX and the ideal adaptive DRX cases.

Examining Figure 5 we can see that SAA-DRX is under thetrend line of all achievable delay and activity costs of the fixedDRX setups as it is the closest point in terms of the Euclideandistance to the ideal case on the active period-accumulateddelay plane. From another perspective, SAA-DRX has similarperformance in terms of delay on the total population as thefix method with the low P1 settings but with less energyconsumption.

In summary, our proposed DRX scheme takes serviceand terminal type and state into account to optimize to thecorrect KPI (delay or energy consumption). The calculationcomplexity is low due to the lack of necessity to calculateanything for most use cases. A further advantage is thatthe service aware proposed method can easily extend thefunctionality of any existing method e.g., the CDA-DRX.

VI. REAL LIFE CONSEQUENCES

A. Estimated increase of battery lifetime

In this section we estimate the length of the extendedbattery lifetime of the proposed DRX scheme. The energyconsumption calculation is based on the measured values in[10]. Let’s suppose a scenario in which a web user (includingwatching online video services) downloads a page and readsit for 60 seconds, downloads another, etc. During this activity,the screen is on for 60 sec, consuming 60 x 0.85 Ws.The radio is active for 10 sec in case idle timer is 10 sec,consuming approx. 10 x 1.6 Ws. Thus the share of the radio isapprox. 24%. The maximum theoretical battery lifetime withonly changing the radio would be +31% by reducing radio

7

cost to 0. Our algorithm reduces radio cost to approx. 30%,increasing lifetime by 20%. This would mean that instead of4 hours lifetime would be almost 5 hours without perceivingany delays in web traffic compared to active mode.

In a low-speed background download scenario (e.g., lowerthan best effort services, hello messages), the user would ben-efit much more. The screen is inactive, power is approx. 100%radio power. Thus instead of 4 hours, the lifetime is approx. 6hours. Our algorithm would select long DRX cycle (200 ms),reducing radio power to approx. 10%. Thus instead of 6 hoursthe lifetime would be 60 hours.

In a high-speed download scenario, the user would triggeractive mode in almost all cases, so neither our solution, norany other DRX solution would have too much effect on that.

B. Impact on signalling

In our proposed DRX scheme the current LTE architec-ture and protocols remain intact. This is a clear advantagecomparing to the previous papers that needs modification oneither the bearer setup procedure [7], [8] or in the DRXstate-machine system [9]. On the other hand, there is someadditional signaling that did not occur in previous proposals.

To lower the oscillation between different T1 values weintroduced a timer in our implementation in which, T1 iskept for several seconds after a specific traffic occurred. Thelength of this traffic specific timeout parameter has impacton the necessary DRX signaling frequency. To estimate theimpact of signaling we analyzed the consequences of DRXparameter switching. One metric that shows how frequentlya DRX parameter update is required is the sojourn time ofDRX state on a specific parameter set shown in Figure 6.The four lines represent the sojourn times in 1,3,10,30 sectimeout setups. It can be seen that the sojourn time has a bigvariance (e.g., 3764.3 sec for the 3 sec timeout parameter),but on average (e.g., 12.8 sec for the 3 sec timeout parameter)the signaling update is necessary on the order of 10 seconds.This has minor impact on the nodes, since it is a requirementtowards the industry to support dynamic DRX reconfigurationson far smaller timescales. Further, this kind of signaling doesnot impact battery saving on the client side, since UEs shouldbe notified when they are awaken anyhow. As we stated duringthe comparison discussion on CDA-DRX that we used a 2.56sec ’long DRX to idle time’ parameter (see Section V-C), theservice specific timeout parameter is chosen to fit this and wecalculated with a 3 sec long one through the paper.

VII. CONCLUSION

In this paper we proposed an efficient adaptive DRXmethod. The basis of the method is service-awareness andconsidering QoE. It minimizes the DRX delay that the usermost perceives and maximizes battery saving in other cases.We introduced a QoE aware cost metric for both to delay andenergy consumption thus making evaluation straightforward.The proposed system is evaluated in details by comparing itto state-of-the-art solutions emulated on the real-world trafficof an operational mobile broadband operator. It is proved thatthe method outperforms the state-of-the-art solutions in real-world scenarios.

10�3

10�2

10�1

100

101

102

103

104

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Sojourn time of DRX state on a specific parameter set

cdf

1 sec

3 secs

10 secs

30 secs

Fig. 6. CDF of the sojourn time of DRX state on a specific parameter set[various lines represent the active traffic type timeout parameter]

With our proposed DRX scheme, in case of web browsingthe battery lifetime of a single user is increased from 4 hoursto 5 hours without any perceived any delays. A low-speedbackground download would benefit even more, as the batterylifetime can be 60 hours instead of 6 hours.

REFERENCES

[1] “ETSI TS 136 304 V11.4.0 (2013-07),” retrieved: Sept, 2013.[Online]. Available: http://www.etsi.org/deliver/etsi ts/136300 136399/136304/11.04.00 60/ts 136304v110400p.pdf

[2] M. .Sidibe, H. Koumaras, I. Kofler, A. Mehaoua, A. Kourtis, andC. Timmerer, “A Novel Monitoring Architecture for Media ServicesAdaptation Based on Network QoS to Perceived QoS Mapping,”Journal on Signal, Image and Video Processing, vol. 2, no. 4, pp. 307–320, dec 2008.

[3] S.-R. Yang, “Dynamic Power Saving Mechanism for 3G UMTSSystem,” Mob. Netw. Appl., vol. 12, no. 1, pp. 5–14, Jan. 2007.[Online]. Available: http://dx.doi.org/10.1007/s11036-006-0002-0

[4] L. Liu, X. She, and L. Chen, “Multi-user and Channel DependentScheduling Based Adaptive Power Saving for LTE and Beyond System,”in Communications (APCC), 2010 16th Asia-Pacific Conference on, 312010-Nov. 3, pp. 118–122.

[5] S. Fowler, R. S. Bhamber, and A. Mellouk, “Analysis of Adjustable andFixed DRX Mechanism for Power Saving in LTE/LTE-Advanced,” inCommunications (ICC), 2012 IEEE International Conference on, June,pp. 1964–1969.

[6] S. Gao, H. Tian, J. Zhu, and L. Chen, “A More Power-Efficient AdaptiveDiscontinuous Reception Mechanism in LTE,” in Vehicular Technology

Conference (VTC Fall), 2011 IEEE, Sept., pp. 1–5.

[7] C. Zhong, T. Yang, L. Zhang, and J. Wang, “A New DiscontinuousReception (DRX) Scheme for LTE-Advanced Carrier Aggregation Sys-tems with Multiple Services,” in Vehicular Technology Conference (VTC

Fall), 2011 IEEE, Sept 2011, pp. 1–5.

[8] J. Liang, J. Chen, H. Cheng, and Y. Tseng, “An Energy-Efficient SleepScheduling With QoS Consideration in 3GPP LTE-Advanced Networksfor Internet of Things,” Emerging and Selected Topics in Circuits and

Systems, IEEE Journal on, vol. 3, no. 1, pp. 13–22, March 2013.

[9] E. Liu, J. Zhang, and W. Ren, “Adaptive DRX Scheme for Beyond 3GMobile Handsets,” in Global Telecommunications Conference (GLOBE-

COM 2011), 2011 IEEE, dec. 2011, pp. 1 –5.

[10] J. Huang, F. Qian, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck, “AClose Examination of Performance And Power Characteristics of 4GLTE Networks,” in Proceedings of the 10th international conference on

Mobile systems, applications, and services, ser. MobiSys ’12. NewYork, NY, USA: ACM, 2012, pp. 225–238.