eRAN15.0 Power Saving (Including DRX) Solution Integration and Optimization Guide

LTE FDD eRAN13.
0 Power Saving
(Including DRX) Solution Integration and
Optimization Guide
Prepared By Yang Xiaosheng (employee ID: 00183640) Date 2016-11-24
Reviewed By Li Tianyi (employee ID: 00284157), Liu Shuai Date 2016-11-24

(employee ID: 00138145), Hou Yanzhuang
(employee ID: 00220993), Wang Geng
(employee ID: 00203914), Yang Xiaosheng
(employee ID: 00183640)
Reviewed By Date
Approved By Date
Huawei Technologies CO., LTD.

All Rights Reserved
LTE FDD eRAN13.0 Power Saving (Including DRX) Solution Integration and
Optimization Guide INTERNAL
Change History
Date Version Description Author
2014-10-30 eRAN8.1-V1.0 Completed the draft. Yang Xiaosheng

(employee ID: 00183640)
2014-11-26 eRAN8.1-V1.0 Added typical cases to sections 7.2.4"The Yang Xiaosheng
RRC Connection Establishment Success Rate (employee ID: 00183640)
Decreases and the Main Control Board CPU
Is Overloaded After DRX Is Enabled" and
7.2.5"Voice Quality Deteriorates After DRX
Is Enabled" for impact descriptions.
2015-11-13 eRAN8.1-V1.0 Supplemented impact of delay variation Yang Xiaosheng
caused by Apple discontinuous reception (employee ID: 00183640)
(DRX) parameter settings on MOS in section
4.2"Feature Activation Risks and
Workarounds." Added cases to section
7.2.6"The MOS Decreases After DRX
Parameters Are Set as Recommended by
Apple."
2016-01-29 eRAN11.1-V1.0  Added the plan that voice users' gap- Yang Xiaosheng
assisted measurement is mutually (employee ID: 00183640)
exclusive to DRX.
 Added the L.Traffic.User.Unsyn.Drx.Avg
counter.
 Added the separate configuration of the
inactivity timer for UEs using QCI 1
bearers in dynamic DRX scenarios. (QCI
is short for QoS class identifier.)
2016-11-24 eRAN12.1-V2.0 Added UE-specific differentiated DRX Liu Shuai (employee ID:
configuration 00387104)
2018-07-30 Update version number only:eRAN15.0
2020-03-07 Huawei confidential. No spreading without permission. Page 2 of 98

Contents
Change History.................................................................................................................................2
1 Feature Application Policies.......................................................................................................5
1.1 DRX................................................................................................................................................................................5
1.1.1 Weak Coverage Scenarios...........................................................................................................................................5
1.1.2 Heavy Traffic Scenarios..............................................................................................................................................5
1.1.3 High-Speed Movement Scenarios (Including Highways, Metros, and Railways)......................................................6
1.1.4 Low-Band Wide-Coverage Scenarios.........................................................................................................................6
1.2 Dynamic DRX................................................................................................................................................................7
1.3 UE-Specific Differentiated DRX...................................................................................................................................8
1.3.1 Introduction.................................................................................................................................................................8
1.3.2 Parameter Configurations............................................................................................................................................9
1.3.3 Effect Evaluation Method............................................................................................................................................9
2 Recommended Parameter Settings for Feature Activation.................................................10

2.1 Recommended Parameter Settings for DRX................................................................................................................10
2.2 Recommended Parameter Settings for Dynamic DRX................................................................................................13
2.3 UE-Specific Differentiated DRX.................................................................................................................................14
2.4 Recommended Non-key Parameter Settings................................................................................................................14
2.5 Parameter Configuration Examples for Feature Activation.........................................................................................25
3 Solutions to Commercial Use Cases on the Live Network..................................................26

3.1 Commercial Use Situations of DRX Enabled in Office W in Country Z.....................................................................26
3.1.1 Scenario on the Live Network...................................................................................................................................26
3.1.2 Parameter Settings on the Live Network...................................................................................................................26
3.1.3 Gains on the Live Network........................................................................................................................................27
3.2 Commercial Use Situations of DRX Enabled in Office BJ in Country Z....................................................................27
3.3 Commercial Use Situations of DRX Enabled in Office F in Country L......................................................................29

3.4 Commercial Use Situations of DRX Disabled in Office V in Country K....................................................................30

4 Known Issues, Feature Activation Risks, and Workarounds.............................................33

4.1 Known Feature Issues...................................................................................................................................................33
4.2 Feature Activation Risks and Workarounds.................................................................................................................42
5 Solution Optimization and Improvement..............................................................................48

6 Precautions for Test Acceptance...............................................................................................49
7 Troubleshooting..........................................................................................................................50
7.1 Principles for Feature Problem Location......................................................................................................................50
7.1.1 Problem Identification...............................................................................................................................................50
7.1.2 Checking External Events and Historical Operations...............................................................................................50
7.1.3 Checking Faults and Alarms......................................................................................................................................50
7.1.4 Checking Known Issues of a Version........................................................................................................................50
7.1.5 Parameter Check........................................................................................................................................................51
7.1.6 Inference and Analysis..............................................................................................................................................53
7.1.7 Specific Methods for Feature Problem Location.......................................................................................................53
7.1.7.1 Data Collection.......................................................................................................................................................53
7.1.7.2 Method for DRX Problem Identification...............................................................................................................53
7.1.7.3 Method of Checking Why UEs Cannot Enter the DRX Mode..............................................................................55
7.1.7.4 Check Method for DRX Measurement...................................................................................................................57
7.1.7.5 Counter-assisted Analysis Method.........................................................................................................................59
1.1.1.2 DRX TTI-level Analysis Method...........................................................................................................................64
7.1.7.6 Analysis of Long Uplink Ping Delays....................................................................................................................70
1.1.1.3 Analysis of DRX Reconfiguration Indicator Changes...........................................................................................73
7.2 Typical Cases................................................................................................................................................................73
7.2.1 Downlink Throughput Decreases After DRX Is Enabled.........................................................................................73
7.2.2 Ping Delays Are Long After DRX Is Enabled...........................................................................................................78
7.2.3 The RRC Connection Reestablishment Success Rate Decreases As the On Duration Is Too Short.........................80
7.2.4 The RRC Connection Establishment Success Rate Decreases and the Main Control Board CPU Is Overloaded
After DRX Is Enabled........................................................................................................................................................84
7.2.5 Voice Quality Deteriorates After DRX Is Enabled....................................................................................................85
7.2.6 The MOS Decreases After DRX Parameters Are Set as Recommended by Apple...................................................88

1 Feature Application Policies
1.1 DRX
To support DRX, UEs must comply with 3GPP Release 8 or later.
It is recommended that DRX be disabled by default. If feature activation is required,
performance-preferred parameter settings are recommended first, and then power saving-
preferred parameter settings are recommended. DRX applies to the following services
where UEs on the network support DRX and focuses on power saving:
 Services insensitive to delay or with sporadic data transmission, such as web
browsing, email, and FTP services
 Services that use a few small packets, such as Presence services
 Periodic transmission of continuous small packets, such as Voice over Internet
Protocol (VoIP) services
1.1.1 Weak Coverage Scenarios

Performance-preferred parameter settings are recommended, thereby preventing DRX from
affecting reference signal received power (RSRP) measurement, channel quality indicator
(CQI) reporting, service drop rate, and handover success rate.
1.1.2 Heavy Traffic Scenarios

Multiple KPIs, such as access and service drop KPIs, may be affected due to flow control
caused by CPU overload of a main control board or a baseband processing board. DRX is
enabled but not manually disabled in heavy traffic scenarios in V100R007C00SPC150 and
eRAN8.0. DRX needs to be manually disabled in heavy traffic scenarios in eRAN6.0.
Restrictions on the number of UEs in the DRX mode are specified in
V100R007C00SPC150 and eRAN8.0, whereas restrictions on CPU load are specified in
eRAN8.1. Therefore, you need to evaluate whether CPU load is high within the range of
restrictions on the number of UEs in the DRX mode based on traffic models and conditions
on the live network. If CPU load is high, you are advised to manually disable DRX. The
definition of DRX in heavy traffic scenarios is affected by various factors, such as
bandwidth, traffic model, parameter setting optimization, UE distribution, interference, and
proportion of small-packet services. In different offices, impacts of these factors on the
definition of DRX in heavy traffic scenarios are different.

1.1.3 High-Speed Movement Scenarios (Including Highways,

Metros, and Railways)
You are not advised to enable DRX. Performance-preferred parameter settings are
recommended when operators do not agree to disable DRX. You need to notify operators of
the impact when operators require only power saving-preferred parameter settings.
If Long DRX Cycle is set to a value greater than 40 ms, the UEs' RSRP measurement
period is five times the value of Long DRX Cycle according to 3GPP specifications. For
example, when Long DRX Cycle is set to 320ms, the RSRP measurement period is 1.6s. In
scenarios where UEs move at a high speed of more than 120 km/h, UEs move out of the
original network coverage areas when RSRP measurement has not been completed, causing
handover failures and service drops. As a result, the handover success rate and service drop
rate are affected.
If Long DRX Cycle is set to 40ms or a value less than 40 ms, the handover delay will
increase although RSRP measurement is less affected. For example, UEs enter the sleep
period before the eNodeB sends the HO Command message, and therefore the handover
delay increases by 40 ms. This may also cause UEs to move out of original network
coverage areas in high-speed movement scenarios, resulting in handover failures and
service drops. As a result, the handover success rate and service drop rate are affected.
Consequently, you are not advised to enable DRX when UEs move at a high speed,
preventing possible performance problems.
It is recommended that thresholds for entering and exiting DRX be set to 0 and 1
respectively when KPIs are not affected by signaling impact during drive tests on high-
speed railways. Full packet injection is performed on UEs for drive tests, and therefore UEs
are not in DRX mode in most cases.
1.1.4 Low-Band Wide-Coverage Scenarios

It is recommended that performance-preferred parameter settings be used if there are a large
number of weak coverage areas, which prevents impacts of DRX on RSRP measurement
and CQI reporting and further prevents deterioration in the service drop rate and handover
success rate. (For impacts on RSRP measurement, see section 1.1.3"High-Speed Movement
Scenarios (Including Highways, Metros, and Railways)." If performance-preferred
parameter settings are used, the long DRX cycle becomes short, and CQIs can be reported
in time.)
It is recommended that scheduling request indicator (SRI) reconfiguration for DRX not be
enabled because the reconfiguration is a function customized by an operator. This function
has no obvious positive impacts on power saving and may have the following negative
impacts:
 Physical uplink control channel (PUCCH) resources may be wasted or adjusted too
early. This impact may further affect L2-related KPIs, for example, increase the
number of used uplink RBs by 0 to 2, reduce the number of available physical uplink
shared channel (PUSCH) RBs by 0 to 2, reduce uplink throughput by 0% to 14%, and
reduce perceived uplink data rates by 0% to 14%.
 The E-RAB setup delay may be prolonged and the E-RAB setup success rate may
decrease.
 In heavy load scenarios, the service drop rate may increase and the RRC connection
reestablishment success rate may decrease.
 The average CPU usage of main control boards and baseband processing units (BBPs)
increase by 0% to 3%.

1.2 Dynamic DRX

To support DRX, UEs must comply with 3GPP Release 8 or later, and the operator has
purchased and activated the license for dynamic DRX.
It is recommended that dynamic DRX be disabled by default. If feature activation is
required, the power saving or signaling reduction mode is recommended as required.
Dynamic DRX applies to the following scenarios:
 Services are performed using a few small packets or heartbeat packets, such as
Microsoft Service Network (MSN) in scenarios where smartphones are the
mainstream.
 Operators focus on UEs' power saving and expect to reduce the UE power
consumption using dynamic DRX.
 Signaling storms occur due to frequent link establishment and link disconnection of
UEs, and operators expect to avoid these signaling storms using dynamic DRX. (It is
recommended that dynamic DRX not be enabled if the number of handovers is greater
than 50% of the number of E-RAB setups or the number of E-RAB setups for a single
UE in peak hours is less than 200.)
Power Saving Mode

 It is recommended that the power saving mode for dynamic DRX not be enabled if the
length of a UE inactivity timer is 35s based on experience from live networks.
 If the length of a UE inactivity timer is less than 35s and dynamic DRX is required,
you need to explain to the operators about impacts of increasing the UE inactivity
timer length first, then increase the length of the UE inactivity timer to 35s, and enable
dynamic DRX, preventing abrupt KPI changes.
Signaling Reduction Mode

If the number of handovers is greater than 50% of the number of E-RAB setups, the
signaling storm is caused by handover-related signaling and therefore dynamic DRX is not
recommended. If the percentage is less than 50% and the number of E-RAB setups for a
single UE in peak hours is greater than 200, dynamic DRX is recommended to reduce UE
access signaling overhead. Gains cannot be ensured if dynamic DRX is enabled in other
scenarios.
The signaling reduction effect is described as follows:
 The signaling reduction effect can be obtained from the L.RRC.ConnReq.Att counter.
The signaling reduction effect caused by decreased RRC connections can be obtained
using the following formula:
Signaling reduction effect = L.RRC.ConnReq.Att x Number of signaling messages in
RRC connections
 The signaling reduction effect caused by decreased paging messages can be obtained
by monitoring the value of the L.Paging.UU.Att counter.
 The signaling reduction effect over the Uu interface can be obtained by monitoring the
value of the L.Signal.Num.Uu counter.
 Total signaling reduction effect over the S1 and Uu interfaces can be obtained using
the following formula:
Total signaling reduction effect over the S1 and Uu interfaces = L.E-RAB.AttEst +
(L.Signal.Num.DRX.Reconfig + L.RRC.StateTrans.Syn2Unsyn)/10

The signaling overhead of 10 RRC Connection Reconfiguration messages is equal to that of one E-
RAB setup procedure (including the service request procedure).
In high-speed movement scenarios, such as highways, metros, and railways, or when UE

power saving is not the main concern in a cell, dynamic DRX is not recommended. If
dynamic DRX is required, set the HighMobiTrigIdleModeSwitch parameter to
ENABLE(Enable) to prevent negative signaling gains caused by too many handovers.
Before dynamic DRX activation, you are advised to change the length of the UE inactivity
timer to 200s and focus on observing KPI changes when the UE inactivity timer is
lengthened for three to seven days, avoiding that the cause of KPI changes cannot be
identified in the subsequent process after dynamic DRX is enabled.
The length of the UE inactivity timer needs to be changed to the recommended value, such
as 200s, and the length of an uplink synchronization timer is changed to that of the UE
inactivity timer not changed before signaling-reduction-based dynamic DRX is enabled,
and then KPI changes are observed. However, increasing the length of the UE inactivity
timer will cause incompatibility problems in iPhones, that is, iPhones will actively enter
RRC_IDLE mode without notifying the eNodeB about 37s later after no data interaction. In
this case, the service drop rate will obviously increase even new KPIs are used on the
eNodeB side. (For details, see section "LOFD-00110501 Dynamic DRX" in DRX and
Signaling Control Feature Parameter Description). Polices for feature activation are listed
as follows:
 Feature activation is normally recommended on networks where fewer iPhones are
located.
 In versions earlier than eRAN8.1, if more iPhones are located on networks, changes of
the service drop KPI need to be observed by removing impact of iPhones actively
entering RRC_IDLE mode without affecting user experience. If operators reject
changes of the service drop KPI, it is recommended that dynamic DRX be disabled.
 In versions later than eRAN8.1, if more iPhones are located on networks, you can
enable the LBFD-081103 Terminal Awareness Differentiation feature to add these
iPhones to a dynamic DRX blacklist, preventing such incompatible UEs from affecting
network KPIs. Deterioration of the service drop rate is caused by the length of the UE
inactivity timer increased before dynamic DRX is enabled, the blacklist takes effect
only after dynamic DRX is enabled, and therefore deterioration of the service drop rate
cannot be prevented during network deployment. You need to explain to operators that
service drops caused before dynamic DRX activation can be resolved after dynamic
DRX is enabled if the blacklist is opened.
Policies for DRX activation are also applicable when dynamic DRX is enabled.
1.3 UE-Specific Differentiated DRX

1.3.1 Introduction
Differentiated DRX parameters can be set for UEs with different type allocation codes
(TACs) specified by the ImseisvTac parameter or UEs with different software version
number (SVN) and TAC combinations specified by the ImeisvSvn and ImeisvTac
parameters.
This function can be enabled when DRX parameters for some UEs need to be different
from those for other UEs in the network. For example, DRX parameters used to decrease

the UE power consumption can be set for UEs with a short battery life. In comparison, a
DRX parameter group used to improve the UE performance can be set for UEs with a long
battery life.
1.3.2 Parameter Configurations

The configuration procedure is as follows:
Step 1 Run the MOD GLOBALPROCSWITCH command to make the UeCompat MO take
effect, enable the eNodeB to obtain the IMEISVs of UEs from MMEs, and enable the
eNodeB performs differentiated handling on specified UEs.
MOD GLOBALPROCSWITCH: S1MmePrivFeatureInd=UeTypeRecogSwitch-1,
UeCompatSwitch=AbnormalUeHandleSwitch-1&MOUeCompatEffectSw-1;
Step 2 Run the ADD UECOMPAT command to create an index and set UE-specific differentiated
DRX parameters.
 For UEs with different TACs, set the UECompat.UeInfoType parameter to
IMEISV_TAC, and set the UECompat.ImeisvTac parameter.
 For UEs with different TAC and SVN combinations, set the UECompat.UeInfoType
parameter to IMEISV_TAC_SVN, and set the UECompat.ImeisvTac and the
UECompat.ImeisvSvn parameters.
Step 3 Set the UECompat.UeDiffDrxSwitch parameter to ON.
 For UEs with different TACs, run the following command:
ADD UECOMPAT: Index=1, UeInfoType=IMEISV_TAC, ImeisvTac=87654321,
UeDiffDrxSwitch=ON;
 For UEs with different TAC and SVN combinations, run the following command:
ADD UECOMPAT: Index=0, UeInfoType=IMEISV_TAC_SVN, ImeisvTac=12345678,
ImeisvSvn=1,UeDiffDrxSwitch=ON;
Step 4 Run the ADD UEDIFFCONFIG commands with the parameters LocalCellId,
UeInfoIndex, Qci, and DrxParaGroupId specified. Among these parameters, the
UeInfoIndex parameter belongs to the UeCompact MO and the value of the
DrxParaGroupId parameter belongs to the DrxParaGroup MO.
ADD UeDiffConfig: LocalCellId=5, UeInfoIndex=0,QCI=9, DrxParaGroupId=3;
ADD UeDiffConfig: LocalCellId=5, UeInfoIndex=1,QCI=9, DrxParaGroupId=4;
After the configuration is completed, the eNodeB will deliver UE-specific DRX
configurations to UEs.
----End
1.3.3 Effect Evaluation Method

If differentiated DRX parameters can be set for different UEs according to the GUI
configuration, this function has taken effect.

2 Recommended Parameter Settings for

Feature Activation
This chapter describes recommended parameter settings. This does not mean that other
parameter settings cannot be used. There are various parameter setting combinations, but it
is impossible that all parameter setting combinations are verified. For details about impact
of parameter setting changes, see sections 7.1.7"Specific Methods for Feature Problem
Location" and 7.1.5"Parameter Check."
2.1 Recommended Parameter Settings for DRX

Parameter setting principles are simply described as follows:
 If services with different QCIs are running on the UE, the following DRX parameter
selection rules are recommended:
− If any QCI is not configured with a DRX parameter group, the eNodeB will not
configure DRX parameters for this UE.
− If each QCI is configured with a DRX parameter group and each DRX parameter
group has a different DrxParaGroup.LongDrxCycle parameter value, the eNodeB
will select the DRX parameter group with the smallest parameter value for this UE.
− If multiple DRX parameter groups have the same DrxParaGroup.LongDrxCycle
value, the eNodeB will select the DRX parameter group for the QCI of services
with the highest allocation/retention priority (ARP) configured on the EPC side
using the following command:
ADD EPSQOSTPL: QOSCLASUID=9, PRILEVEL=1;
If the EPC configures the same ARP for QCIs, the DRX parameter group for the
preferentially established QCI bearer is delivered to the UE, which may not be the
expected parameter setting. In versions later than eRAN11.0, the eNodeB selects
the DRX parameter group for the QCI of services with the priority defined in 3GPP
based on switch control. It is recommended that DrxPolicyMode be set to
3GPPDEFINEDQCIPRIORITY when DRX is enabled again. Operators can also
configure the QCI priority as required and determine the DRX parameter group
based on the QCI priority if the long DRX cycle is the same for multiple QCIs (for
example, DrxPolicyMode is set to QCIPRIORITY).

 When a UE simultaneously has bearers of QCI 1 and QCI 5 as well as a default bearer
(for example, of QCI 6 to QCI 9), the configuration rules for the
DrxParaGroup.LongDrxCycle parameter are as follows:
− If the default bearer and QCI 1 bearer have the same
DrxParaGroup.LongDrxCycle value (for example, 40 ms), the QCI 5 bearer must
have a larger DrxParaGroup.LongDrxCycle value (for example, 80 ms) than the
default bearer and QCI 1 bearer.
− If the default bearer has a larger parameter value than QCI 1 bearer, the default and
QCI 5 bearers must have the same DRX parameter group (that is, their
DrxParaGroup MOs must have the same parameter values).
 The OnDurationTimer value should be less than the ShortDrxCycle value.
Otherwise, the short cycle is not configured. The OnDurationTimer value should be
less than the LongDrxCycle value. Otherwise, the DRX parameters are not
configured.
 The LongDrxCycle value should be an integer multiple of the ShortDrxCycle value.
Otherwise, the short DRX cycle is automatically adjusted to a proper value. The
LongDrxCycle and ShortDrxCycle values must be a multiple of ten. Otherwise, the
values are automatically adjusted to a multiple of ten.
 Due to impacts of the sounding reference signal (SRS) reporting period and CQI
reporting period, OnDurationTimer specifies a period in which the SRS and CQI are
reported once at the same time. The valid value of OnDurationTimer, which is
carried in the DRX reconfiguration message over the air interface, is greater than a
configured value. Due to impacts of TA configurations after SRS is enabled, the valid
value of LongDrxCycle, which is carried in the DRX reconfiguration message over
the air interface, may be less than a configured value to ensure synchronization when
TimingAdvCmdOptSwitch is set to OFF.
Table 1.1 Recommended parameter settings for VoIP services carried on the bearer with QCI 1
Parameter ID MML Parameter Description Unit Recommended
Command Value for Power
Saving-Preferred
Parameter Settings
DrxParaGroupId MOD Indicates the ID of the DRX - 1

DRXPARAG parameter group.
ROUP
EnterDrxSwitch Indicates whether bearers to - ON
which the parameter group
applies support DRX. A UE can
enter DRX mode only when all
bearers for the UE support
DRX.
LongDrxCycle Indicates the length of the long Subframe SPS OFF: PSF40
DRX cycle.
SPS ON: PSF20

Parameter ID MML Parameter Description Unit Recommended

Command Value for Power
Saving-Preferred
Parameter Settings
OnDurationTimer Indicates the length of the On Subframe PSF10

Duration timer. Because of the
impact of CQI reporting
intervals and SRS transmission
intervals, the actual value of this
parameter assigned to a UE may
be greater than the configured
value.
DrxInactivityTimer Indicates the length of the DRX Subframe PSF80
inactivity timer.
DrxReTxTimer Indicates the length of the DRX Subframe PSF8
retransmission timer.
SupportShortDrx Indicates whether short DRX - UU_DISABLE
cycles are enabled.
 It is recommended that DRX be disabled when performance-preferred parameter settings are used.
 If DRX is enabled, and the value of the LongDrxCycle parameter for a QCI of 1 is set to a value
greater than 20 ms, the eNodeB does not activate downlink semi-persistent scheduling.
 Default values in command output of MOD DRXPARAGROUP for a QCI of 1 or 5 include:
OnDurationTimer(PSF10)
DrxInactivityTimer(PSF5)
DrxReTxTimer(PSF8)
LongDrxCycle(SF20)
SupportShortDrx(UU_DISABLE)
Table 1.2 Recommended parameter settings for data services carried on the bearer with QCI 5,
QCI 6, QCI 8, or QCI 9
Parameter MML Unit Recommended Value Recommended Value
Command for Performance- for Power Saving-
Preferred Parameter Preferred Parameter
Settings Settings
DrxParaGroupId MOD - 3 3
DRXPARAG
EnterDrxSwitch ROUP - ON ON
LongDrxCycle Subframe SF40 SF320
OnDurationTimer Subframe PSF2 PSF10
DrxInactivityTimer Subframe PSF80 PSF100
DrxReTxTimer Subframe PSF8 PSF8
SupportShortDrx - UU_ENABLE UU_ENABLE

Parameter MML Unit Recommended Value Recommended Value

Command for Performance- for Power Saving-
Preferred Parameter Preferred Parameter
Settings Settings
ShortDrxCycle Subframe SF20 SF80

DrxShortCycleTimer - 1 1
FddEnterDrxThd MOD ‰ 1000 1000
CELLDRXP
FddExitDrxThd ARA ‰ 1000 1000
TimeAlignmentTimer MOD Subframe Greater than or equal to Greater than or equal to

TATIMER SF1920 (SRS enabled) SF10240 (SRS enabled)
No restriction (SRS No restriction (SRS
disabled) disabled)
 Recommended parameter settings for services carried on the bearer with QCI 5 are consistent
with parameter settings for services carried on the default bearer.
 If false SR detection occurs on the live network, it is recommended that PuschDtxSwitch and
UlEnhancedSrSchSwitch be set to ON, decreasing the impact of false SR detection on network
KPIs.
 Default values in output of MML commands for a QCI of 4, 6, 7, 8, or 9 are performance-
preferred parameter settings. Default values in output of MML commands for a QCI of 2 or 3 are
NULL.
2.2 Recommended Parameter Settings for Dynamic DRX

The following table lists recommended parameter settings for dynamic DRX. For details
about information collection before network deployment, see section 9.2 "Required
Information" in DRX and Signaling Control.
Parameter MML Command Unit Recommended Value
DynDrxSwitch MOD CELLALGOSWITCH - OFF

LongDrxCycleUnsync MOD CELLDRXPARA Subframe 1280
OndurationTimerUnsync Subframe 5
DrxInactivityTimerUnsync Subframe 200
UeInactivityTimerDynDrx MOD RRCCONNSTATETIMER s 200(35)
This parameter is set according
to information collection
results, and the signaling
reduction mode is used when
this parameter is set to 200.

Parameter MML Command Unit Recommended Value
UlSynTimerDynDrx s 20(10)
This parameter is set according
to information collection
results, and the signaling
reduction mode is used when
this parameter is set to 20.
2.3 UE-Specific Differentiated DRX

Parameters for performance optimization are not involved. The function parameters are
determined by operators during network planning.
2.4 Recommended Non-key Parameter Settings
Parameters added or modified in eRAN11.1 are marked in green, as shown in the following table.
Parameter ID Recommended Parameter Description Unit Recommendation Reason

Value
DrxStatus Default value: Indicates whether to use None This parameter is used only
FALSE(FALSE) normal or special DRX. If when special DRX
this parameter is set to parameters are applied to
TRUE, ordinary DRX UEs with the SPID.
parameters are applied to
UEs with the SPID. If this
parameter is set to FALSE,
special DRX parameters
are applied to UEs with the
SPID.
QciPriorityForDr Default value: 9 Indicates the QCI-specific None This parameter is configured
x priority for selecting a based on operators'
DRX parameter group. A requirements, which affects
larger value of this the power saving
parameter indicates a lower performance of UEs.
priority. If the bearers for a
UE have multiple QCIs and
the DrxPolicyMode
parameter is set to
QCIPRIORITY(QCI
priority), the eNodeB
selects the DRX parameter
group for the UE based on
the QCI-specific priorities.
The value ranges from 1 to
254.


Value
DrxAlgSwitch OFF(Off) Indicates the DRX switch. None This parameter is set to ON
as required. The cell-level
parameter DrxAlgSwitch in
the CellDrxPara MO is
added in eRAN11.1 to
replace this eNodeB-level
parameter. The configuration
interface in this version
supports synchronization and
delivery of the settings of
both the eNodeB-level and
cell-level parameters. If the
eNodeB-level parameter is
set to ON(On), the setting of
the eNodeB-level parameter
takes effect in all cells served
by the eNodeB. If the
eNodeB-level parameter is
set to OFF(Off), the setting
of the cell-level parameter
takes effect individually in
the cells.
ShortDrxSwitch ON(On) Indicates whether to enable None Short DRX cycles reduce the
short DRX cycles. traffic delay.
VolteGapDrxExc OFF(Off) Indicates whether the None The value ON(On) is
lusiveSwitch eNodeB delivers the intra- recommended in an inter-
RAT gap-assisted RAT or inter-frequency
measurement configuration networking scenario. This is
and DRX configuration to because the speech quality of
a UE performing a voice UEs that are performing
service at the same time. If voice services and start gap-
this parameter is set to assisted measurements
ON(On), the eNodeB should be ensured further in
instructs the UE to perform such scenarios. If this
intra-RAT gap-assisted parameter is set to ON, the
measurements and removes eNodeB removes the DRX
DRX configuration at the configuration that is
same time. If this delivered to a UE performing
parameter is set to a voice service when the
OFF(Off), the eNodeB can eNodeB delivers the gap-
deliver both configurations assisted measurement
to the UE. The configuration to the UE. This
DrxForMeasSwitch and reduces the possibility of
VolteGapDrxExclusiveSw packet loss problems that
itch parameters cannot be may occur due to untimely
set to ON(On) at the same scheduling in the cooperation
time. between gap-assisted
measurement and DRX.
However, this decreases the
power saving performance.


Value
PucchIRCEnhan ON Indicates whether the None Setting this parameter has the
ce eNodeB determines following impacts:
interference strength. The  The number of detected
eNodeB determines false alarms decreases.
interference strength only
when this switch is 1,
 The uplink BLER
which ensures accurate decreases.
adaptive switchover  The detected performance
between maximum ratio deteriorates slightly.
combining (MRC) and  The ping delay is a little
interference rejection prolonged.
combining (IRC). This
parameter takes effect only
when PucchIrcSwitch of
the IrcSwitch parameter is
1.
CellUlschAlgo.U Off Indicates whether to enable None The VoLTE packet delay can
lEnhancedVoipS the estimation of traffic be shortened, the packet loss
chSw- volume dynamically rate can be reduced, and the
UlVoLTEDataSiz scheduled for VoLTE voice service quality can be
eEstSwitch services in the uplink. If improved.
this option is selected, the
eNodeB estimates the
uplink traffic volume that
is dynamically scheduled
for VoLTE services, which
shortens the VoLTE packet
delay, reduces the packet
loss rate, and improves the
voice service quality.
ENBCELLRSV Off Bit 2 of RsvdSwPara3 is None It is recommended that this
DPARA: used to specify whether to option be selected for
RsvdSwPara3=R optimize the periodic CQI- optimization of the decreased
svdSwPara3_bit2 related counters when UEs CQI caused by false alarms.
have entered the DRX
sleep period. When this bit
is set to 1, the eNodeB
optimizes the periodic
CQI-related counters if SR-
based scheduling exists
during the DRX sleep
period and the eNodeB
extends the DRX activation
period. In addition, this bit
is used to determine
whether to enable DRX
modes in CA primary and
secondary carrier cells to
be the same in eRAN11.1.
If this bit is set to 1, DRX
modes in primary and


Value
secondary carrier cells are

the same as much as
possible. If this bit is set to
0, DRX modes in primary
and secondary carrier cells
are separately controlled
without mutual constraints.
SmartPreAllocati ON(On) Indicates whether smart None Preallocation fails when
onSwitch preallocation is enabled or DRX is enabled. Setting this
disabled for a bearer with a parameter to ON can prevent
specified preallocation performance deterioration
parameter group ID when caused by the preallocation
PreAllocationSwitch is set failure.
to ON.
SriFalseDetThdS OFF(Off) Indicates whether to None The basic function of this
witch increase the SRI false parameter is to prevent false
detection threshold for UEs alarms. However,
in the DRX mode. If this verification results show that
parameter is set to ON, the the probability of false alarm
threshold increases and the detection is low, which may
SRI false detection cause SR missing detection.
probability decreases. On the network with
significant SR false alarms,
you can set this parameter to
ON to prevent impacts of the
SR false alarms.
PuschDtxSwitch ON Is a PUSCH DTX detection None DTX occurring on networks
switch and indicates with weak coverage can be
whether the eNodeB uses optimized.
the PUSCH discontinuous
transmission (DTX)
detection result during
uplink scheduling. If this
option is selected for an
LTE FDD cell, the eNodeB
determines whether to
perform adaptive
retransmission based on the
PUSCH DTX detection
result during uplink
scheduling.
PuschDtxSchStra ADAPTIVE_RET Adaptive retransmission is None Adaptive retransmission is
tegy X(ADAPTIVE_R performed when the initial performed when the initial
ETX) PUSCH transmission is PUSCH transmission is
detected as DTX. detected as DTX. Therefore,
the probability of possible
uplink packet loss caused by
false detection of the initial
PUSCH transmission as


Value
DTX decreases, but more

uplink RBs and CCEs are
consumed.
UlEnhancedSrSc ON Uplink re-scheduling is None If uplink traffic is light in the
hSwitch required if the number of cell and DRX is enabled,
HARQ retransmissions for selecting this option
an SR reaches the decreases the uplink initial
maximum value but the block error rate (IBLER) and
scheduling still fails. If this retransmission BLER,
option is selected, uplink increases the RB and
re-scheduling is performed scheduling resource usage,
only when the On Duration reduces interference to
timer for the DRX long neighboring cells, and
cycle starts. increases the cell throughput.
However, uplink SR re-
scheduling is performed only
when the On Duration timer
for the DRX long cycle
starts. If a normal uplink SR-
based scheduling fails, the
ping delay increases.
DrxRcvDtxProS ON(On) Indicates whether to enable None If this parameter is set to
witch UEs with DRX enabled to ON, downlink throughput
enter the DRX sleep period increases. However, the
after two consecutive downlink BLER may
DTXs are detected. deteriorate.
Consider that this
parameter is set to ON and
DRX is enabled for a UE in
common scenarios. After
detecting two consecutive
DTXs, the eNodeB
determines whether to
enable the UE to enter the
DRX sleep period based on
the stop time of the
DRXInactivityTimer
timer instead of promptly
enabling the UE to enter
the DRX sleep period.
DrxBasedSriGap ON Indicates whether to None The probability of service
OptSwitch consider the transmission drops decreases.
of SRIs when configuring
measurement gaps for UEs
in DRX mode. The
eNodeB considers the
collaboration only if this
option is selected, which
decreases the probability of
service drops.


Value
SriPeriodAdaptiv NOQCIADAPTIV Indicates whether to enable None The E-RAB setup success
e E SRI period adaptation. If rate increases.
this parameter is set to
NOQCIADAPTIVE, the
probability of updating the
SR period decreases, the
occurrence probability of
the problem that abnormal
UEs do not send SRIs
occasionally on the live
network decreases, and the
E-RAB setup success rate
increases.
DataAmountStat 30 Indicates the length of the 20ms This parameter is used for
Timer UE traffic measurement length measurement.
period. The traffic volume
of a UE during this period
is measured. Based on the
measurement result, the
DRX algorithm decides
whether the UE should
enter or exit DRX.
CqiMask OFF(Off) Indicates whether the cqi- None If this parameter is set to
Mask IE can be set. ON, the number of CQI,
PMI, RI, and PTI reports sent
on the PUCCH decreases,
and the downlink data
transmission performance
deteriorates in a cell with
DRX enabled. In addition, if
UEs in compliance with
3GPP Release 9 or later do
not support the cqi-Mask IE,
the incompatibility problem
between UEs and the
eNodeB may occur. As a
result, the downlink
throughput decreases in a
cell with DRX enabled.
DrxPolicyMode DEFAULT(Default Indicates the policy for None This parameter is set to
) selecting a DRX parameter QCIPRIORITY only when
group for a UE for which the QCI priority is redefined.
the bearers have multiple In most cases, the QCI
QCIs based on the long priority cannot be redefined.
DRX cycle length, ARP,
and 3GPP-defined priority.
DrxStartOffsetO OFF(Off) Indicates whether to enable None It is recommended that this
ptSwitch optimized random parameter be set to ON when
distribution of SRS resources are not


Value
DrxStartOffset values for allocated for UEs or there is

UEs that are configured a large number of UEs in the
with only SRS resources or cell.
periodic CQI, or neither.
DrxForMeasSwit OFF(Off) Indicates whether to None The sleep period will be long
ch deliver DRX parameters if DrxForMeasSwitch is set
dedicated to measurement to ON, affecting normal
to UEs performing circuit operation of services. In
switched fallback (CSFB)- addition, there are few LTE-
triggered GSM to-GSM application
measurement. scenarios.
LongDrxCycleF Default value: Indicates the length of the Subfra See above.
orMeas SF160 long DRX cycle dedicated me
to GERAN measurement.
OnDurTimerFor Default value: Indicates the length of the Subfra See above.
Meas PSF2 On Duration timer me
dedicated to GERAN
measurement.
DrxInactTimerFo Default value: Indicates the length of the Subfra See above.
rMeas PSF2 DRX inactivity timer me
dedicated to GERAN
measurement.
DrxReTxTimerF Default value: Indicates the length of the Subfra See above.
orMeas PSF4 DRX retransmission timer me
dedicated to GERAN
measurement.
ShortDrxSwFor Default value: Indicates whether to enable None See above.
Meas OFF(Off) the short DRX cycle
dedicated to GERAN
measurement.
ShortDrxCycleF SF20 Indicates the length of the Subfra See above.
orMeas short DRX cycle dedicated me
to GERAN measurement.
ShortCycleTimer 1 Indicates the length of the None See above.
ForMeas DRX short cycle timer
dedicated to GERAN
measurement.
MeasDrxSpecSc Default value: Indicates whether to enable None See above.
hSwitch OFF(Off) special scheduling after the
eNodeB delivers DRX
parameters dedicated to
measurement to the UE.
CovGsmMeasDr Default value: Indicates whether to None See above.
xCfgSwitch OFF(Off) deliver DRX parameters
dedicated to measurement


Value
to UEs performing
coverage-based GSM
measurement.
LongDrxCycleS Default value: Indicates the length of a Subfra The RFSP function is not
pecial SF10 long DRX cycle that is me applicable because UEs
applied only to non-power- support power saving, and
saving UEs of which therefore this parameter is set
subscriber profile ID for to a default value.
RAT/frequency priority
(RFSP) indexes are
contained in the RFSP
index set or to UEs of
which capability
information indicates that
they do not support power
saving.
OnDurationTime Default value: SF5 See above. Subfra See above.
rSpecial me
DrxInactivityTim Default value: See above. Subfra See above.
erSpecial SF10 me
SupportShortDrx Default value: See above. Subfra See above.
Special UU_DISABLE me
ShortDrxCycleS Default value: See above. Subfra See above.
pecial SF10 me
DrxShortCycleTi Default value: 1 See above. Subfra See above.
merSpecial me
LongDrxCycleF SF320 Indicates the long DRX Subfra Set this parameter to the
orAnr cycle for intra-RAT me recommended value.
automatic neighbor relation
(ANR).
LongDRXCyclef LTE- Indicates the long DRX Subfra Set this parameter to the
orIRatAnr >GERAN:SF2560 cycle for inter-RAT ANR. me recommended value.
Other network:
SF1280
DrxInactivityTim PSF200 Indicates the length of the Subfra Set this parameter to the
erForAnr DRX inactivity timer for me recommended value.
ANR.
ReptSyncAvoidI NOT_CFG Indicates whether all None This parameter is set based
nd synchronization procedures on whether UE problems
repeatedly initiated by a need to be prevented on the
UE having incompatibility live network.
problems can trigger the
RRC connection
reconfiguration procedure.


Value
ReptSyncAvoidT 100 Indicates the period during ms See above.

ime which synchronization
procedures repeatedly
initiated by a UE having
incompatibility problems
do not trigger the RRC
connection reconfiguration
procedure.
GapDrxExclusiv OFF Indicates whether the None The beta test has not been
eSwitch eNodeB delivers the intra- performed on this parameter.
RAT gap-assisted Therefore, you must confirm
measurement configuration gains before setting this
and DRX configuration to parameter to ON.
a UE at the same time. In
eRAN11.1, this parameter
can be set to ON for the
eNodeB to solve the
problem that gap-assisted
measurement configuration
and DRX configuration
cannot be delivered at the
same time for voice and
data services, without
distinguishing the QCI.
This can optimize
inaccurate inter-frequency
measurement, reduce the
number of RRC connection
reestablishments, and
reduce the reestablishment-
access ratio. However,
power generated during the
period cannot be saved.
The reestablishment-access
ratio is calculated using the
following formula:
Reestablishment-access
ratio = Number of RRC
connection reestablishment
requests/(Number of RRC
connection reestablishment
requests + Number of RRC
access requests)
UeInactTimerDy 200 Indicates the length of the s -
nDrxQci1 UE inactivity timer for UEs
that enter the DRX mode
and perform services with a
QCI of 1 when dynamic
DRX is enabled.


Value
DrxStateDuring DRX_ACTIVE_F Indicates the DRX mode None -

UlHarqRetx OR_VOICE(DRX during an uplink HARQ
_ACTIVE_FOR_ retransmission period.
VOICE)
OnDurationUnex OFF(Off) Indicates whether to report None -
tendSwitch at least one periodic CQI
during the period specified
by OnDurationTimer.
ShortDrxCycleS ON(On) Indicates whether to enable None -
witch short DRX cycles.
CellDrxSpecialP None Indicates whether the None -
araValid parameters in the
CellDrxSpecialPara MO
take effect.
FddAnrDrxInacti PSF200(200 Indicates the length of the Subfra -
vityTimer PDCCH DRX Inactivity Timer for me
subframes) LTE FDD ANR.
LongDrxCycleF LTE->UTRAN: Indicates the long DRX Subfra -
orInterRatAnr SF1280(1280 cycle for inter-RAT ANR. me
subframes)
LTE->GERAN:
SF2560(2560
subframes)
LTE->CDMA2000
1xRTT:
SF1280(1280
subframes)
LTE->CDMA2000
HRPD:
SF1280(1280
subframes)
LongDrxCycleF SF320(320 Indicates the long DRX Subfra -
orIntraRatAnr subframes) cycle for intra-RAT ANR. me
ShortDrxCycleS UU_DISABLE(Di Indicates whether to enable None -
witchSpecial sable) short DRX cycles for non-
power-saving UEs of
which RFSP indexes are
contained in the RFSP
index set or to UEs of
which capability
information indicates that
they do not support power
saving.
DrxParaGroupIn None Indicates the index of a None -
dex DRX parameter group.


Value
DrxParaGroupSt ENABLE(Enable) Indicates whether to enable None -

at the DRX parameter group.
UeInactivityTim 200 Indicates the length of the None -
erDynDrxQci UE inactivity timer for UEs
that have entered the DRX
mode and have bearers of
the QCI when dynamic
DRX is enabled.
TddPowerSaving - - - This parameter applies only
ExitDrxThd to LTE TDD.
TddAnrDrxInacti - - - This parameter applies only
vityTimer to LTE TDD.
DrxSrDetectOpt - - - This parameter applies only
Switch to LTE TDD.
DrxStartoffsetAd - - - This parameter applies only
justSW to LTE TDD.
DRX for special UEs in RRC_CONNECTED mode is customized for Deutsche Telekom, and
currently is not configured for other operators. Parameters used for DRX for special UEs in
RRC_CONNECTED mode are set for a certain terminal specified based on the subscriber profile ID
(SPID). This terminal may not support DRX, or whether this terminal supports DRX cannot be
identified, and therefore DRX parameters are set for this terminal according to operators'
requirements. If DRX for special UEs in RRC_CONNECTED mode is configured for other operators,
it is recommended that parameters be set to default values.
2.5 Parameter Configuration Examples for Feature

Activation
This section lists MML configuration script examples of setting main parameters for feature
activation. For details about feature activation and observation, see DRX and Signaling
Control Feature Parameter Description.
Step 5 Run the following command to turn on the DRX switch:
MOD DRX: DrxAlgSwitch=ON, ShortDrxSwitch=ON;
Step 6 Run the following command to bind a DRX parameter group to a QCI for a cell:
MOD CELLSTANDARDQCI: LocalCellId=0, Qci=QCI9, DrxParaGroupId=3;
Step 7 (Optional) If QCI 10 has been configured for a cell, run the following command to bind a
DRX parameter group to QCI 10 for the cell:
MOD CELLEXTENDEDQCI: ExtendedQci=10, LocalCellId=0, DrxParaGroupId=3;

Step 8 If the long cycle is greater than or equal to 80 ms, run the following command to modify
the time alignment timer:
MOD TATIMER: LocalCellId=0, TimeAlignmentTimer=SF10240;
Step 9 Run the following command to reduce RRC connection reconfiguration signaling generated
by UEs frequently entering and exiting DRX mode and prevent UEs from entering and
exiting DRX mode based on traffic statistics:
MOD CELLDRXPARA: LocalCellID=0,FddEnterDrxThd=1000,FddExitDrxThd=1000;
Step 10 Run the MOD DRXPARAGROUP command to turn on the switch of a specified DRX
parameter group and configure DRX parameters.
 Performance-preferred parameters
MOD DRXPARAGROUP: LocalCellId=0, DrxParaGroupId=3, EnterDrxSwitch=ON,
OnDurationTimer=PSF2,DrxInactivityTimer=PSF80, DrxReTxTimer=PSF8,
LongDrxCycle=SF40, SupportShortDrx=UU_ENABLE,ShortDrxCycle=SF20,
DrxShortCycleTimer=1;
 Power saving-preferred parameters

MOD DRXPARAGROUP: LocalCellId=0, DrxParaGroupId=3, EnterDrxSwitch=ON,
OnDurationTimer=PSF10,DrxInactivityTimer=PSF100,DrxReTxTimer=PSF8,
LongDrxCycle=SF320, SupportShortDrx=UU_ENABLE,ShortDrxCycle=SF80,
DrxShortCycleTimer=1;
Step 11 (Optional) To allow the eNodeB to select DRX parameters based on QCI priorities, run the
following commands to specify a DRX parameter selection policy and set DRX priorities
used in DRX parameter selection:
MOD CELLDRXPARA: LocalCellId=0, DrxPolicyMode=QCIPRIORITY;
MOD CELLSTANDARDQCI: LocalCellId=0, Qci=QCI9, QciPriorityForDrx=9;
----End

3 Solutions to Commercial Use Cases on

the Live Network
3.1 Commercial Use Situations of DRX Enabled in Office

W in Country Z
3.1.1 Scenario on the Live Network
DRX is enabled with values of DRX parameters provided by Apple in office W in country
Z, meeting power saving requirements of iPhones.
3.1.2 Parameter Settings on the Live Network

The following table lists recommended values for power saving-preferred parameter
settings.
Parameter Unit Setting Value
EnterDrxSwitch - ON
LongDrxCycle Subframe SF320

OnDurationTimer Subframe PSF10
DrxInactivityTimer Subframe PSF100
DrxReTxTimer Subframe SF8
SupportShortDrx - UU_ENABLE
ShortDrxCycle Subframe SF80

DrxShortCycleTimer - 1
TimeAlignmentTimer Subframe 10240

FddEnterDrxThd ‰ 1000
FddExitDrxThd ‰ 1000

3.1.3 Gains on the Live Network

Main KPIs are normal without fluctuation. The RRC connection reestablishment success
rate deteriorates because recommended parameter settings are not used when DRX is
enabled on the live network. After recommended values for power saving-preferred
parameter settings are set, KPIs restore to normal.

BJ in Country Z
DRX is enabled with values of DRX parameters provided by Apple in office BJ in country
Z, meeting power saving requirements of iPhones.

The following table lists recommended values for performance-preferred parameter
settings.
EnterDrxSwitch - ON





KPIs are normal without obvious fluctuation compared with those before feature activation.
The following figures show changes of some KPIs.


F in Country L
DRX is enabled with values of DRX parameters provided by Apple in office F in country L,
meeting power saving requirements of iPhones.


settings.
EnterDrxSwitch - ON



Main KPIs are normal without fluctuation. Sensitive information cannot be obtained.
3.4 Commercial Use Situations of DRX Disabled in

Office V in Country K
DRX is disabled in office V in country K due to some reasons, and then comparison and
analysis are performed on KPIs. In addition, power saving-preferred parameter settings are
used.


settings.
EnterDrxSwitch - ON



After DRX is disabled, packets are sent more discretely at a longer interval, causing a
decrease of the downlink throughput in a cell based on traffic statistics. The average packet
size is smaller, and the modulation and coding scheme (MCS) indexes for small packets are
smaller. As a result, the average MCS index decreases.

4 Known Issues, Feature Activation Risks,

and Workarounds
4.1 Known Feature Issues

No. Issue Issue Cause Workaround
1 Throughput and packet loss rate UEs' DRX activation period and This issue has been resolved
at the Packet Data Convergence sleep period are not considered in eRAN7.0.
Protocol (PDCP) layer when the priority of the product
deteriorate when DRX is queue is updated using a hash
enabled in a cell in high-load algorithm, greatly increasing the
scenarios (the number of scheduling delay of UEs processing
RRC_CONNECTED UEs is large-packet services. As a result,
greater than 140) in office Y in throughput is affected.
country E.
2 Two consecutive DTXs are UEs are supposed to be in the DRX This issue has been resolved
detected in downlink sleep period if two consecutive in V100R007C00SPC150
scheduling in office H in DTXs are detected in downlink (for details, see section
country C, and the eNodeB scheduling with DRX enabled, and 4.2"Feature Activation Risks
suspends downlink scheduling, therefore scheduling is stopped and and Workarounds"). In a
causing an insufficient number will start again within the next On version earlier than
of downlink scheduling times Duration period, causing a decrease V100R007C00SPC150, you
and a decrease in throughput. in the number of scheduling times can change thresholds for
and throughput. entering and exiting DRX to
300 and 800 respectively in
drive test (DT) scenarios to
temporarily prevent the
impact on throughput.
3 LBBPc boards are configured When DRX is enabled and This is a configuration issue,
on the eNodeB in office N in thresholds for entering and exiting which can be resolved by
country N. If the number of DRX are set to 300 and 800, changing thresholds for
UEs served by a single eNodeB respectively, a large number of entering and exiting DRX to
reaches 400 and the CPU usage RRC Connection Reconfiguration 1000 and 1000, respectively.
of a main control board exceeds messages are generated over the air
60%, the main control board is interface, causing CPU overload on
overloaded when DRX is the main control board. The

enabled. eNodeB delays Msg4 delivery and

starts flow control, resulting in a
large number of RRC connection
setup failures and packet
discarding.
Users repeat the attempts to access
networks, further increasing CPU
signaling load and accelerating flow
control. As a result, a vicious circle
is formed, which will not stop until
UEs fall back to the GSM/UMTS
networks.
4 Mobile terminated (MT) CSFB Compared with the CSFB Detailed descriptions have
calls fail at a certain probability procedure, the handover procedure been supplemented in
after DRX is enabled in office has a higher priority. Therefore, the eRAN8.1 Feature
V. eNodeB will process handover Documentation.
messages preferentially. If the
CSFB procedure is triggered at this
time, it will fail. After handovers
are complete, the MME initiates the
CSFB procedure again. After DRX
is enabled, the handover duration is
prolonged due to the UEs' sleep
period. This will increase the
number of attempts for CSFB
switching. However, the actual
number of CSFB switching
execution success times remains
unchanged, decreasing the CSFB
switching success rate.
5 Terminals located in office O in Terminals are equipped with chips This is a terminal issue.
country S are equipped with not supporting the cqi-Mask IE in Currently, only a few
chips not supporting the cqi- DRX mode. terminals support the cqi-
Mask IE in DRX mode, causing Mask IE, and therefore it is
significant deterioration of recommended that the cqi-
UDP-/TCP-layer throughput in Mask IE be disabled.
the uplink and downlink.
6 Because OnDurationTimer Operators' networks match DRX Use recommended DRX and
and DrxInactivityTimer are parameter settings required by VoLTE parameter settings.
set to 2ms (a short time) in Apple. The BSR detection timer is
office H in country C, the incoordinate with the On Duration
VoLTE service quality is poor timer in DRX mode because
and speech discontinuity OnDurationTimer and
occurs. DrxInactivityTimer are set to 2ms
(a short time), resulting in improper
BSR scheduling. As a result, VoIP
service timeout and packet loss
occur.
7 Traffic is abnormal and This issue is caused by three known This is a terminal issue. It is
declines to the bottom during bugs occurring on the two recommended that such

DTs due to E5375 or E3276 terminals, including uplink error terminals be replaced.
terminal issues in office J in packets, downlink error packets,
country C. and issues when real measurement
policies configured for serving cells
are reported.
8 OnDurationTimer is set to In scenarios where the length of the Set the length of the On
2ms (a short time) in office W On Duration timer is short, RRC Duration timer to the
in country C, decreasing the Connection Release messages are recommended value.
RRC connection sent without scheduling due to
reestablishment success rate. product restrictions.
9 Due to design restrictions of Design restrictions of QualComm There are no workarounds
QualComm chips in office N in chips are described as follows: for design restrictions on
country C, the ping delay If Long DRX Cycle is set to UEs.
increases by tens of 320ms, UEs enter a deep sleep state
milliseconds during tests after when no data needs to be sent
DRX is enabled. during a long time, and more than
50 ms is required when the UEs
recover from the deep sleep state,
causing an increase in the ping
delay.
10 After dynamic DRX is enabled After dynamic DRX is enabled, the Detailed descriptions have
in office F in country L, the timer used to govern the period in been supplemented in
number of state switching which the eNodeB maintains uplink eRAN8.1 Feature
between synchronization and synchronization is set to a value 2s Documentation.
out of synchronization longer than a configuration value
increases due to a DRX based on algorithm design (an
parameter delivery mechanism uplink synchronization protection
in out-of-synchronization mechanism is extended), causing a
mode. In addition, the UEs' decrease in the out of
sleep period is extended, synchronization probability. In
causing an increase in the addition, the probability of false SR
probability of false SR detection increases, causing an
detection and a decrease in CQI increase in CQI detection errors and
reporting without affecting user the proportion of CQIs in 0 to 4
experience. orders and a decrease in the average
CQI value.
11 The RRC connection Without UE PDP context during Optimize weak coverage on
reestablishment success rate connection reestablishment, the the live network.
decreases when power saving RRC connection reestablishment
mode for DRX is enabled in success rate is low. At this time, if
office X in country C. UEs are in DRX mode, the UE
inactivity timer expires in weak-
coverage areas. If RRC Connection
Release messages are initially sent
and resent in DTX mode in the
DRX On Duration period,
subsequent RRC Connection
Release messages cannot be resent
until UE instances on the system
side are released 450 ms after

message scheduling in UEs' next

DRX On Duration period.
Therefore, if Long DRX Cycle is
set to a larger value in weak
coverage scenarios, the number of
times RRC Connection Release
messages are resent in DTX mode
decreases, the probability that UEs
cannot receive RRC Connection
Release message increases, and the
probability of no UE PDP context
during connection reestablishment
increases.
12 In office HG in country C, the CQI decrease and uplink Explain principles to
value of OnDurationTimer is retransmission proportion increase operators according to
changed from 80ms to 10ms, comply with expected algorithm eRAN8.1 Feature
the value of results. When the value of Documentation.
DrxInactivityTimer with a OnDurationTimer is changed
QCI of 8 is changed from from 80ms to 10ms, and the value
100ms to 80ms, the value of of DrxInactivityTimer with a QCI
UeInactiveTimer is changed of 8 is changed from 100ms to
from 20s to 10s, the CQI value 80ms, the UEs' sleep period is
decreases by 0.1, and therefore extended, increasing the probability
the uplink retransmission of false SR detection in the sleep
proportion deteriorates by about period. As a result, the uplink bit
1.5% according to operators' error rate (BER) increases and CQI
calculation formula. fluctuates. Impact of the extended
sleep period on CQI has been
described in eRAN8.1 Feature
Documentation.
13 KPI deterioration situations After DRX is enabled, the eNodeB  Adjust DRX parameter
after DRX is enabled in office delivers UL grant in the case of settings with a QCI of 1,
L in country H are described as false SR detection, but UEs do not and set
follows: respond because they are in the DrxInactivityTimer and
 Downlink packet loss rate sleep period for a long time, OnDurationTimer to
with a QCI of 1 increases causing deterioration of the uplink Huawei-recommended
from 0.018% to 0.382%. RBLER. values.
 Uplink packet loss rate with a False SR detection increases the  Disable DRX configured
QCI of 1 increases from probability that UEs are lost in the for voice services with a
0.077% to 0.357%. uplink. If UEs are lost in the uplink, QCI of 1.
they enter the SR pending state in  Turn on the uplink SR
 Downlink residual block the case of the first false SR
error rate (RBLER) enhancement scheduling
detection. In this case, if data or switch.
increases from 0.014% to voice packets are to be transmitted
0.031%. in the downlink, the eNodeB
 Uplink RBLER increases immediately performs downlink
from 0.103% to 0.177%. scheduling, and the number of
hybrid automatic repeat request
(HARQ) retransmission attempts
reaches its maximum. As a result,
the downlink RBLER and voice

packet loss rate increase.

If UEs are lost in the uplink, the
eNodeB does not schedule the first
SR reported by UEs. In this case, if
two times of SR missing detection
occur, the uplink voice packet loss
rate increases.
14 Technical support engineers After thresholds for entering and Set FddEnterDrxThd to
(TSEs) feed back that the exiting DRX are changed from 1000 and FddExitDrxThd
service drop rate on the entire 1000 and 1000 to 300 and 800, to 1000.
network increases from 0.18% respectively, UEs enter or exit the
to about 2.5% after parameter DRX mode more easily, and the
optimization is performed to number of intra-BBP
improve basic network quality L2\RR\CELLM signaling
and increase throughput in DTs interaction messages increases. The
in office S in country C. number of messages for data
interaction at the MAC layer and
during the RR period increases
(data interaction is implemented
inside the module), and a large
number of RRC Connection
Reconfiguration messages increase
over the air interface, causing an
increase in the boards' CPU load,
and further affecting the service
drop rate.
15 The downlink throughput After DRX is disabled, packets are Explain principles to
decreases by 3 to 4 Mbit/s sent more discretely at a longer operators according to
when DRX is disabled on the interval, causing a decrease of the eRAN8.1 Feature
entire network in VIVA office downlink throughput in a cell based Documentation.
in Kuwait. on traffic statistics.
After DRX is disabled, the average
packet size is smaller, and the MCS
indexes for small packets are
smaller. As a result, the average
MCS index decreases.
16 The E-RAB setup success rate The eNodeB does not receive SRIs  Enable smart preallocation
decreases after DRX is enabled of TopN terminals after sending the to prevent such issue.
in office E and other offices in first reconfiguration message (The smart preallocation
country A. carrying DRX parameter settings, function becomes
causing a decrease in the E-RAB ineffective when the
setup success rate. number of UEs in a cell
exceeds 50. Such UEs
may have the similar
issue.)
 Change thresholds for
entering and exiting DRX
to 300 and 800
respectively to
temporarily prevent such

issue. This method is not

applicable in the heavy-
traffic scenario, which
may increase CPU load.
 Make an optimization
solution to the UEs'
incompatibility issue. For
details, see section
4.2"Feature Activation
Risks and Workarounds."
17 During parameter tests with Operators customize voice DRX Use the recommended DRX
DRX enabled or disabled, parameter settings 6/4/4/40. (6 is parameter settings
operators in office B in country the length of the On Duration timer, 10/80/8/40 with a QCI of 1.
J find that the packet loss rate 4 is the length of the DRX
with a QCI of 1 is high when inactivity timer, 4 is the length of
DRX is enabled. They doubt the DRX retransmission timer, and
that the voice packet loss rate is 40 is the length of the DRX long
affected by DRX. cycle timer.) Due to false SR
detection, BSRs at the cell edge
cannot be received normally by the
eNodeB, causing packet loss.
18 Operators in office T in country Thresholds for entering and exiting Change thresholds for
H find that the average CPU DRX are 0 and 50 respectively, entering and exiting DRX to
usage of a large number of which are too small. As a result, the 1000 and 1000, respectively.
main control boards on the number of reconfiguration
GUL co-MPT base station messages for UEs to enter or exit
exceeds 50% in peak hours, and the DRX mode increases, and CPU
reaches about 90% to the load increases.
maximum. Operators think that
this phenomenon does not
comply with product
specifications.
19 Throughput is lower than non- When IP RAN inter-site carrier This issue has been resolved
CA rate at site 1682 in office X aggregation (CA) is performed in by determining On Duration
in country C. light-traffic small-packet scenarios period in advance by SCC
using the SpeedTest, the secondary during real UE scheduling
component carrier (SCC) load and performing scheduling
activation threshold is small adjustment in the On
(configured in comparison testing Duration period by default in
scenarios), traffic is light at the start eRAN8.1. In versions earlier
phase, OnDurationTimer is set to than eRAN8.1, you can
10ms, and the downlink CA increase the length of the On
preallocation period is set to 10 ms Duration timer to be longer
fixedly. Therefore, when downlink than the downlink
preallocation is performed within preallocation period, such as
the sleep period each time, UEs 20 ms, to resolve this issue.
enter the sleep period for a long
time and cannot be scheduled,
affecting throughput.
20 In office D in country A, the Service drops are caused by TopN For detailed policies to

length of the UE inactivity terminals, including iPhone 5 and resolve the terminal issue,
timer is increased to 200s iPhone 5S, but have nothing to do see chapter 1"Feature
before dynamic DRX is with dynamic DRX. When Application Policies."
enabled, and therefore the UeInactiveTimer is set to 200s,
service drop rate calculated UEs enter RRC_IDLE mode
using a new formula obviously without notifying the network side,
deteriorates, increasing from which will be calculated as the
0% to 1.5%. service drop on the network side.
Because UEs enter RRC_IDLE
mode automatically, UE service
experience is not affected.
21 In office X in country C, This is a known issue. When the For details about issue
because SRS is disabled by number of RRC_CONNECTED resolving, see section
default in eRAN6.0 and UEs on the LBBPc board exceeds 4.2"Feature Activation Risks
eRAN8.0, KPI deterioration on 100 and that on the LBBPd board and Workarounds."
the control plane is caused by exceeds 300 in a single cell, and
occupied resources in uplink DMRS TA and DRX are enabled
synchronization (DMRS TA) simultaneously, the DRX sleep
when the number of period is not considered in DMRS
RRC_CONNECTED UEs in a TA scheduling, causing KPI
single cell exceeds 100. When deterioration on the control plane.
DMRS TA and DRX are
enabled simultaneously, the
DRX sleep period is not
considered in DMRS TA
scheduling, causing KPI
deterioration on the control
plane. (DMRS is short for
demodulation reference signal,
and TA is short for tracking
area.)
22 Operators in office V complain Voice packet scheduling is not Reply to the operators that
that voice packet loss occurs performed in time when DRX- DRX-related parameter
when DRX-related parameter related parameter settings settings recommended by
settings recommended by Apple recommended by Apple are used. Apple have been applied in
are used. V100R007C00SPC230.
23 At 17:50 on February 9 in If ShortDrxCycle and This issue is caused by
office L in province Z, the DRXShortCycleTimer are set to terminals. Change the values
number of inter-frequency SF80(80 subframes) and 1, more of ShortDrxCycle and
handovers (from FDD to TDD) unnecessary signals are measured DRXShortCycleTimer to
increases, and the handover by UEs, such as iPhone 6, iPhone 6 SF40(40 subframes) and 2
success rate decreases, Plus, and Samsung S5, on the live to resolve this issue.
remaining at a level of about network. As a result, the number of
85% after DRX is enabled. handovers from FDD to TDD
increases, and the handover success
rate decreases.
24 After DRX is disabled on high-  Scheduling is stopped after two Explain principles to
quality networks in office D in consecutive DTXs are detected operators.
province J, the RRC connection when DRX is enabled, then
reestablishment rate decreases RRC Connection Release

by more than 1%, whereas the messages cannot be sent

service drop rate increases by successfully, and therefore UEs
0.01%. trigger RRC connection
reestablishment. The number of
RRC connection
reestablishments triggered by
other causes decreases with
DRX disabled, then the number
of RRC connection
reestablishment requests
decreases, and therefore positive
gains are brought for the RRC
connection reestablishment rate,
complying with expected
results.
 With DRX enabled, the
maximum interval for Radio
Link Control (RLC)
retransmission attempts should
be less than 9.9s but greater than
1.6s. With DRX disabled, the
absolute interval for RLC
retransmission attempts is
shortened to 1.6s. This may
result in an increase in the
service drop rate caused by
retransmission attempts of the
RLC PDU for a signaling radio
bearer (SRB) reaching its
maximum. In addition, based on
data analysis on the live
network, the service drop rate
slightly deteriorates with DRX
disabled, which is caused by
faults on the RAN side. Service
drop rates at TopN sites
deteriorate due to retransmission
attempts of the RLC PDU for an
SRB reaching its maximum.
25 In office D in province J, the Whether handovers are required is Explain principles to
intra-frequency handover determined by UEs' RSRP operators.
success rate decreases by measurement results. UEs' RSRP
0.06% after DRX is disabled in measurement period is 200 ms with
V100R007C00SPC170. DRX disabled. When DRX is
enabled, the UEs' RSRP
measurement period is obviously
lengthened according to 3GPP
specifications. If Long DRX Cycle
is set to a value greater than 40 ms,
the UEs' RSRP measurement period
is five times the value of Long
DRX Cycle. UEs' RSRP

measurement period is short when

DRX is disabled. The measurement
duration will be used again for
measurement and handovers cannot
be reported when the RSRP value
not reaching the threshold is
measured once before the
measurement duration of 320 ms is
over. UEs' RSRP measurement
period is long when DRX is
enabled, and therefore the
probability of measuring the RSRP
value not reaching the threshold
becomes small, and handovers can
be reported more easily during the
measurement duration.
26 In office D in country D, A delay variation of 0 to 40 ms is Enable and optimize the
Apple-provided DRX-related introduced in uplink packet sending HARQ pending and data
parameters are used on LTE and in the downlink on all UEs volume estimation and
networks recently based on including iPhone 6s under Apple- optimization function to
pressure from Apple, and it is provided DRX-related parameter increase MOS values.
found in subsequent DTs that settings. If UEs are not subject to
the average Media Object delay variation processing, an end
Server protocol (MOS) values to end (E2E) delay variation of 80
of VoLTE services performed at ms will be introduced, causing
the rate of 23.85 kbit/s on small MOS values.
Samsung S5 UEs decrease from
3.9 to 3.7 in Huawei and
Ericsson network coverage
areas. Operators require
Huawei to provide cause
analysis of MOS decrease on
Huawei networks and a
solution to such type of issues.

4.2 Feature Activation Risks and Workarounds

Preallocation becomes ineffective after DRX is enabled. Therefore, it is recommended that
smart preallocation be enabled.
The probability of false SR detection may increase when DRX is enabled, causing an
increase in the BLER and affecting resource scheduling in the uplink. In this case, you are
advised to set PuschDtxSwitch and UlEnhancedSrSchSwitch (recommended in
V100R006C00SPC260 or later) as well as SriFalseDetThdSwitch under the
CELLULSCHALGO MO (recommended in a version later than eRAN7.0 without
obvious gains and not recommended for VoIP services) to ON. Theoretically, the
probability of false SR detection can decrease by a half by setting SriFalseDetThdSwitch
under the CELLULSCHALGO MO to ON. For negative impact caused by false SR
detection, setting PuschDtxSwitch and UlEnhancedSrSchSwitch to ON can decrease
HARQ retransmissions, saving air-interface resources, and further decreasing uplink
RBLER and IBLER. Theoretically, retransmissions and rescheduling caused by false SR
detection can be prevented by setting PuschDtxSwitch and UlEnhancedSrSchSwitch to
ON. However, gains may decrease due to DTX detection inaccuracy and a certain working
threshold. Gains are significant from the parameter setting effect on live networks. You can
also set PucchIRCEnhance to ON to decrease the probability of false alarm detection, but
the detected performance may slightly deteriorate. (The PucchIRCEnhance parameter
takes effect only when PucchIrcSwitch of the IrcSwitch parameter is selected, and a
license control item is required.)
When thresholds for entering and exiting DRX are set to 300 and 800, respectively, CPU
load increases in heavy-traffic scenarios due to increased reconfiguration messages. This
may cause boards' CPU overload and reduce the RRC setup success rate. Therefore, it is
recommended that thresholds for entering and exiting DRX be set to 1000 and 1000,
respectively. When thresholds for entering and exiting DRX are set to 1000 and 1000,
respectively, preallocation becomes ineffective at the E-RAB setup phase, and certain UEs
do not send SRs occasionally, which causes fluctuation of the E-RAB setup success rate. In
this case, the following workarounds are recommended:
 Change the thresholds (300 and 800) for entering and exiting DRX, and set the SR
period to a fixed value of 10 ms.
 Enable smart preallocation to prevent such UEs' incompatibility issue. However, there
are restrictions on smart preallocation, that is, smart preallocation is not performed
when the number of RRC_CONNECTED UEs in a cell exceeds 50. Therefore, this
workaround becomes ineffective when a large number of UEs exist.
 The active scheduling scheme (SRB probe scheduling) in use can resolve such issue
and has been incorporated into eRAN11.1.
 An optimization solution is provided for the UEs' incompatibility issue:
This solution is controlled by NOQCIADAPTIVE of the SriPeriodAdaptive
parameter in V100R008C10SPC100 or later and RsvdSwPara1_bit26 of the
RsvdSwPara1 parameter in the eNBCellRsvdPara MO in V100R007C00SPC210 or
later.
 For other versions in which the issue cannot be prevented, persuade operators to
perform a version upgrade.
In a version earlier than V100R007C00SPC150, enabling DRX will lead to two DTXs,
which may cause a decrease in the throughput. During DTs, it is recommended that
thresholds for entering and exiting DRX be set to 300 and 800 respectively to prevent the
issue.

In V100R007C00SPC150 or later, you can set RsvdSwPara1_bit7 under the

RsvdSwPara1 parameter to ON in the MOD ENBCELLRSVDPARA command for
optimization.
In a version later than eRAN8.0, you can set DrxRcvDtxProSwitch for optimization, but
this may cause an increase in the BLER.
Traffic declines to the bottom occasionally during DTs due to issues of E3276S or E5375
terminals equipped with HiSilicon chips. You can replace the test terminals or disable DRX
on terminals to prevent such issue. (Use the software for controlling the terminals to modify
terminals' FGI bit values.)
A small length of the PDCP discard timer may cause packet loss for VoIP services with a
QCI of 5. It is recommended that DiscardTimer be set to a value greater than that of
LongDrxCycle.
RLC retransmission attempts reach its maximum and therefore service drops are caused
when the following conditions are met:
 The number of RRC_CONNECTED UEs in a cell exceeds 100.
 The DrxAlgSwitch parameter is set to ON.
 UEs enter the DRX mode and gap-assisted measurement (including ANR enabling and
inter-frequency inter-RAT measurement starting) is performed.
SRI resources allocated by users fall within the gap-assisted measurement period, UEs
cannot send SRIs within the gap-assisted measurement period, and uplink scheduling and
downlink RLC status reports cannot be obtained and reported.
The following table lists workarounds for such issue in a version earlier than
V100R007C00SPC160.
Version Workaround
All V100R008C10 versions later than MOD DRX: DrxAlgSwitch=OFF;

V100R008C10SPC310 MOD ENBRSVDPARA: RsvdSwPara0=RsvdSwPara0_bit19-1;
All V100R009C00 versions MOD DRX: DrxAlgSwitch=OFF;
MOD ENODEBALGOSWITCH:
HoCommOptSwitch=BasedSriGapOptSwitch-1;
Such issue has been resolved in V100R007C00SPC160. You can set RsvdSwPara1_bit17
in the MOD ENBRSVDPARA command to determine whether the workarounds take
effect. You can also set DrxBasedSriGapOptSwitch to resolve such issue in eRAN8.0.
If the number of UEs in a cell and uplink traffic volume exceed product specifications,
BBPs' CPU load will increase when DRX is enabled, causing a decrease in the number of
PRBs occupied by scheduling data in the uplink. Such issue has been resolved in
V100R007C00SPC160. Check whether a UE is in the gap-assisted measurement period or
DRX sleep period when selecting the UE for scheduling. If the UE is in the DRX sleep
period and cannot be scheduled, deselect the UE. If the UE has been selected, remove it
from candidate UEs.
When IP RAN inter-site CA is performed in light-traffic small-packet scenarios using the
SpeedTest, the SCC load activation threshold is small (configured in comparison testing
scenarios), traffic is light at the start phase, OnDurationTimer is set to 10ms, and the
downlink CA preallocation period is set to 10 ms fixedly. Therefore, when downlink

preallocation is performed within the sleep period each time, UEs enter the sleep period for
a long time and cannot be scheduled, affecting throughput. This issue has been resolved by
determining On Duration period in advance by SCC during real UE scheduling and
performing scheduling adjustment in the On Duration period by default in eRAN8.1. In
versions earlier than eRAN8.1, you can increase the length of the On Duration timer to be
longer than the downlink preallocation period, such as 20 ms, to resolve this issue.
Without UE PDP context during connection reestablishment, the RRC connection
reestablishment success rate is low when DRX is enabled. At this time, if UEs are in DRX
mode, the UE inactivity timer expires in weak-coverage areas. If RRC Connection Release
messages are initially sent and resent in DTX mode in the DRX On Duration period,
subsequent RRC Connection Release messages cannot be resent until UE instances on the
system side are released 450 ms after message scheduling in UEs' next DRX On Duration
period. Therefore, if Long DRX Cycle is set to a larger value in weak coverage scenarios,
the number of times RRC Connection Release messages are resent in DTX mode decreases,
the probability that UEs cannot receive RRC Connection Release message increases, and
the probability of no UE PDP context during connection reestablishment increases. Such
issues can be resolved by optimizing weak coverage on the live network.
Disable SRS if the number of RRC_CONNECTED UEs in a cell exceeds 100 with DRX
enabled. This may cause deterioration of the RRC setup success rate, E-RAB setup success
rate, and service drop rate.
With DRX enabled and SRS disabled, the DRX sleep period is not taken into consideration
when candidate UEs for uplink scheduling are to be selected. As a result, UEs which cannot
be scheduled in the DRX sleep period are selected by mistake. When the number of
RRC_CONNECTED UEs in a single cell exceeds 100, the RRC setup success rate, E-RAB
setup success rate, and service drop rate deteriorate.
The workaround is to enable SRS on the eNodeB side. However, MCS index for UEs'
uplink scheduling decreases and UEs' uplink peak throughput decreases after workaround
implementation. The final solution is described as follows:
Perform the following steps in sequence on macro and LampSite eNodeBs:
Step 12 Upgrade eNodeBs to BTS3900 V100R008C00SPC300 or later BTS3900 V100R008C00
versions, or upgrade eNodeBs to BTS3900 V100R009C00SPC150 or later versions.
Step 13 Enable SRS by running the following command:
MOD SRSCFG: LocalCellId=0, SrsCfgInd=BOOLEAN_TRUE;
Step 14 Turn on the SRS adaption switch by running the following command:
 In BTS3900 V100R008C00SPC300 or later BTS3900 V100R008C00 versions
MOD ENBCELLRSVDPARA: LOCALCELLID=0, RSVDSWPARA0=RsvdSwPara0_bit19-1;
 In BTS3900 V100R009C00 or later versions

MOD SRSCFG: LOCALCELLID=0, FDDSRSCFGMODE=ADAPTIVEMODE;
----End
Perform the following steps in sequence on the BTS3202E:

Step 1 Upgrade eNodeBs to BTS3202E V100R008C00SPC320 or later BTS3202E V100R008C00
versions, or upgrade eNodeBs to BTS3202E V100R009C00SPC128 or later versions.

----End
Perform the following steps in sequence on the BTS3203E:

Step 1 Upgrade eNodeBs to BTS3203E LTE V100R006C00SPC120 or later BTS3203E LTE
V100R006C00 versions, or upgrade eNodeBs to BTS3203E LTE V100R009C00SPC020 or
later versions.
----End
VoLTE services are performed on some networks using QCI 1 parameter settings 4/4/40
recommended by Apple, causing voice packet loss. (4 is the length of the On Duration
timer, 4 is the length of the DRX inactivity timer, and 40 is the length of the DRX long
cycle timer.)However, parameter settings 10/80/40 recommended by Huawei are optimal,
ensuring voice quality for VoLTE services first, and then power saving. Sending two voice
packets together by iPhones at an interval of 40 ms is improper, which may easily cause
packet loss. One packet is sent at an interval of 20 ms for other models of mobile phones. If
operators require parameter settings recommended by Apple, perform an upgrade towards
V100R007C00SPC230, in which parameter adaptation is done.
The inactivity timer for UEs with the QCI 1 bearer is independently configured in dynamic
DRX scenarios in eRAN11.0. Assume that dynamic DRX is enabled and the length of the
UE inactivity timer indicated by UeInactTimerDynDrxQci1 in the RrcConnStateTimer
MO is less than the length of the connection release timer configured on the EPC (the
ongoing call is released after the connection release timer expires). In this case, voice
services cannot be set up if the following conditions are met:
 The inactivity timer of a calling UE has expired before the called UE answers a call,
which causes the calling UE to enter the idle mode.
 The calling UE reselects another VoLTE-incapable cell with a higher priority.
UeInactTimerDynDrxQci1 can be set to a larger value so that the calling party can be
paged after the called party answers the call, which prevents a call setup failure.
A delay variation of 0 to 40 ms is introduced in uplink packet sending and in the downlink
on all UEs including iPhone 6s under Apple-provided DRX-related parameter settings with
the QCI of 1. If UEs are not subject to delay variation processing, an end to end (E2E)
delay variation of 80 ms will be introduced, causing small MOS values. Enable HARQ
pending and data volume estimation optimization functions to increase MOS values. In
HARQ pending, the uplink voice BSR scheduling algorithm is optimized, and HARQ-
responded transmission time interval (TTI) for SR-based scheduling within the On Duration
period is used to perform BSR scheduling on UEs after the On Duration period is over. This
function will be incorporated into eRAN11.1. In data volume estimation optimization, the
voice data volume increasing in the buffer area within a period of time is estimated and the
data volume is increased in the next scheduling based on the uplink voice packet receiving
interval and packet size under Apple-provided DRX-related parameter settings. This
function has been incorporated into eRAN8.1.
 Voice data volume estimation-based uplink scheduling optimization is controlled by
UlVoLTEDataSizeEstSwitch under the
CELLULSCHALGO.UlEnhancedVoipSchSw parameter.

 HARQ pending-based scheduling optimization is controlled by the

DrxStateDuringUlHarqRetx parameter being set to DRX_ACTIVE_FOR_VOICE.
The number of inter-frequency handovers (from LTE FDD to LTE TDD and from LTE
FDD to LTE FDD) increases and the handover success rate decreases after DRX is enabled.
If ShortDrxCycle and DRXShortCycleTimer are set to SF80(80 subframes) and 1, more
unnecessary signals are measured by UEs, such as iPhone 6, iPhone 6 Plus, and Samsung
S5, on the live network. As a result, the number of inter-frequency handovers increases, and
the handover success rate decreases. This issue is caused by terminals. Change the values of
ShortDrxCycle and DRXShortCycleTimer to SF40(40 subframes) and 2 to resolve this
issue.
After DRX is enabled, the probability of false SR detection in the sleep period increases,
and the BLER may increase in the uplink and downlink. False SR detection causes the
eNodeB to periodically detect CQIs when UEs have not reported any. As a result, the
eNodeB detects a large number of random CQIs ranging from 0 to 15. This leads to
fluctuations in both the CQI distribution and the average CQI. For example, when most
UEs are at the cell center and the proportion of high-order CQIs 11 to 15 is very high, the
average CQI may decrease. Because these random CQIs are detected in the sleep period
(when the UEs have no data to transmit), these random CQIs have no impact on scheduling.
A solution (MOD ENBCELLRSVDPARA: LocalCellId=0,
RsvdSwPara3=RsvdSwPara3_bit2-1;) was incorporated in V100R008C10SPC160 and
later versions to reduce impacts on CQIs. Bit 2 of RsvdSwPara3 is used to specify whether
to optimize the periodic CQI-related counters when UEs have entered the DRX sleep
period. When this bit is set to 1, the eNodeB optimizes the periodic CQI-related counters if
SR-based scheduling exists during the DRX sleep period and the eNodeB extends the DRX
activation period.
After DRX is enabled, downlink data cannot be sent and is stored in the buffer in the UE's
sleep period, which causes the downlink data's waiting time to increase in the buffer. As a
result, more counters related to the number of UEs are measured during the ms-level
sampling period. The counters are listed as follows:
 L.Traffic.ActiveUser.Avg
 L.Traffic.ActiveUser.Max
 L.Traffic.ActiveUser.DL.Avg
 L.Traffic.ActiveUser.DL.Max
 L.Traffic.ActiveUser.DL.QCI.X.Max
 L.Traffic.ActiveUser.DL.QCI.X
 L.Traffic.User.InSession.Avg
 L.Traffic.User.InSession.Max
 L.Traffic.SUNPT.DL.Avg
 L.Traffic.SUNPT.DL.Max
With DRX enabled, gap-assisted measurement is performed on a UE performing VoLTE
services. If the UE is in gap-assisted measurement (a measurement period which is the same
as six TTIs specified in 3GPP specifications), the interval for scheduling voice packets
increases, and the performance of VoLTE services is affected. The
VolteGapDrxExclusiveSwitch parameter is introduced in eRAN11.1 to solve such
problems. For a UE using a QCI 1 bearer, DRX configurations that have been delivered to
the UE are removed when gap-assisted measurement is performed. The value ON(On) is
recommended in an inter-RAT or inter-frequency networking scenario to ensure speech
quality of UEs that are performing voice services and start gap-assisted measurement.
When VolteGapDrxExclusiveSwitch is set to ON(On), DRX does not take effect if VoLTE

services are performed and gap-assisted measurement starts. This parameter has not been
used on the live network. After VolteGapDrxExclusiveSwitch is set to ON(On), it is
recommended that changes in main KPIs be observed to identify other unknown impacts.
The RRC connection reestablishment rate may increase when DRX is enabled. Therefore,
In eRAN11.1, GapDrxExclusiveSwitch can be set to ON for the eNodeB to solve the
problem that gap-assisted measurement configuration and DRX configuration cannot be
delivered at the same time for voice and data services, without distinguishing the QCI. This
can optimize inaccurate inter-frequency measurement, reduce the number of RRC
connection reestablishments, and reduce the reestablishment-access ratio. However, power
generated during the period cannot be saved.
The reestablishment-access ratio is calculated using the following formula:
Reestablishment-access ratio = Number of RRC connection reestablishment requests/
(Number of RRC connection reestablishment requests + Number of RRC access requests)
This parameter has not been used on the live network. After GapDrxExclusiveSwitch is set
to ON(On), it is recommended that changes in main KPIs be observed to identify other
unknown impacts.

5 Solution Optimization and Improvement
It is recommended that DRX be disabled by default. If feature activation is required,

performance-preferred parameter settings are recommended. The timer length needs to be
set during parameter setting. The sleep period introduced by DRX will cause an impact on
performance, and therefore impact on the performance will be small if the sleep period is
short during timer-related parameter setting. However, the power saving effect will become
poor. Consequently, there are no optimization parameters recommended in special scenarios
for DRX.

6 Precautions for Test Acceptance
 Determine whether UEs support DRX before tests.

 A license supporting dynamic DRX activation is required for its test.
 You are not advised to perform simulation tests on the live network because UEs'
power saving effect is restricted by network conditions and fluctuation of test results.
You are advised to perform tests in the operator's lab, compare test results for multiple
times on the same UE under the same lab environment, and calculate the average
value.
 Perform tests under the recommended parameter settings.
 Evaluate UEs on the live network before conducting the tests and determine whether
there are UEs having multiple problems.
 Do not use the following method to perform ping tests, which may cause a long ping
delay:
Enable Wi-Fi sharing on a mobile phone after the mobile phone accesses the network
and perform ping tests on a PC.

7 Troubleshooting
7.1 Principles for Feature Problem Location

Power saving is the main benefit of the DRX feature. In most cases, DRX can be normally
triggered. Power saving gains differ by scenario, and DRX-related problems covering data
rate, ping delay, handover, and service drop can be handled using the methods described in
X solutions.
This section describes principles for DRX feature problem location based on characteristics
of DRX in combination with the problem location principles described in X solutions.
7.1.1 Problem Identification

Determine whether problems are closely related to DRX with the following measures:
 Identify the problem range.
 Analyze KPI changes.
 Check DRX switch parameter changes.
 Check whether DRX is in normal activation and operation.
 Verify the license for dynamic DRX.
 Query UE capability.
7.1.2 Checking External Events and Historical Operations

Check whether some operations were performed or external events occurred when problems
occur, and determine whether the problems are related to these operations or events. For
details, see sections about check for external events and historical operations in X solutions.
7.1.3 Checking Faults and Alarms

A problem may be closely related to an alarm. Therefore, check whether the alarm affects
related KPIs. For details, see the alarm checklist described in X solutions.

7.1.4 Checking Known Issues of a Version

Further determine whether problems are known issues of a version or whether problem-
related KPI changes comply with theoretical analysis results based on preceding check
items. For details, see sections about check for known issues of a version in X solutions.
7.1.5 Parameter Check

For details about how to perform a parameter check, see X Solutions for Parameter Check
and Optimization on the LTE Network V8.1.1. Focus on whether DRX-related parameter
settings are consistent with recommended performance-preferred and power saving-
preferred parameter settings. If there are parameters which are not set based on
performance-preferred parameter settings or power saving-preferred parameter settings,
focus on analysis of impact brought by these parameter changes. The following table lists
recommended power saving-preferred and performance-preferred parameter settings.
Parameter MML Command Unit Recommended Value Recommended

for Performance- Value for Power
Preferred Parameter Saving-Preferred
Settings Parameter Settings
EnterDrxSwitch MOD - ON ON
DRXPARAGROU
LongDrxCycle P Subframe SF40 SF320
OnDurationTimer Subframe PSF2 PSF10
DrxInactivityTimer Subframe PSF80 PSF100
DrxReTxTimer Subframe SF8 SF8
SupportShortDrx - UU_ENABLE UU_ENABLE
ShortDrxCycle Subframe SF20 SF80

DrxShortCycleTimer - 1 1
FddEnterDrxThd MOD ‰ 1000 1000
CELLDRXPARA
FddExitDrxThd ‰ 1000 1000
TimeAlignmentTimer MOD TATIMER Subframe Greater than or equal to Greater than or equal
SF1920 (SRS enabled) to SF10240 (SRS
No restriction (SRS enabled)
disabled) No restriction (SRS
disabled)
A larger value of LongDrxCycle indicates a longer UE's sleep period and a longer delay. If
the value of LongDrxCycle is too large, the CQI reporting period is lengthened and
therefore the throughput decreases for the scheduling and multiple-input multiple-output
(MIMO) features, the handover success rate decreases, and the service drop rate increases.
If the value of LongDrxCycle is too small, UE power saving is insignificant. If
TimingAdvCmdOptSwitch is set to ON, it is recommended that LongDrxCycle be set to
a value less than or equal to 320ms. Otherwise, TAs may not be sent in time and the uplink
synchronization performance of UEs is affected. For smart terminals with a strict power
consumption requirement, the value SF320(320 subframes) is recommended, and

TimeAlignmentTimer must be set to SF10240(10240 subframes). For VoIP services with

a QCI of 1, if SpsSchSwitch(SpsSchSwitch) under the CellAlgoSwitch.DlSchSwitch
parameter is selected, set this parameter to a value less than or equal to the semi-persistent
scheduling period, that is, 20 ms. Otherwise, downlink semi-persistent scheduling cannot
take effect. The length of the long DRX cycle must be less than that of the PDCP data
discard timer for the corresponding QCI. Otherwise, packet loss occurs during ping
operations or low-traffic services. If different QCIs exist simultaneously, the eNodeB
selects the DRX parameter group with the smallest value of the LongDrxCycle parameter
for UEs. If values of the LongDrxCycle parameter for different QCIs are the same, the
eNodeB selects the DRX parameter group corresponding to the QCI of the service with the
highest priority according to 3GPP specifications for UEs.
A larger value of OnDurationTimer indicates a longer UE's active period, a higher
scheduling probability, and a shorter delay. The short DRX cycle is not configured when the
value of OnDurationTimer is greater than or equal to that of ShortDrxCycle. DRX
parameters are not set when the value of OnDurationTimer is greater than or equal to that
of LongDrxCycle. If LongDrxCycle is set to 320ms, you are advised to set
OnDurationTimer to 10ms. If the value of OnDurationTimer is too small, a long delay
occurs when the number of UEs is large in a cell, and system capacity for VoIP services
decreases. If the value of OnDurationTimer is too large, UE power saving is insignificant.
A larger value of DrxInactivityTimer indicates a longer activation time extended after the
UE receives new data before expiration of the On Duration timer. If LongDrxCycle is set
to 320ms, you are advised to set DrxInactivityTimer to 100ms. If the value of
DrxInactivityTimer is too small, data may not be scheduled for a long time on the UE
side, causing delayed transmission of data packets or packet loss. If the value of
DrxInactivityTimer is too large, UE power saving is insignificant.
If the value of DrxReTxTimer is too large, power saving performance drops. If the value
of DrxReTxTimer is too small, the timer has been expired before the UE receives
retransmitted data.
A larger value of ShortDrxCycle indicates a longer UE's sleep period and a longer delay,
and a smaller value indicates the opposite effects. If LongDrxCycle is set to 320ms, you
are advised to set ShortDrxCycle to 80ms. The LongDrxCycle value should be an integer
multiple of the ShortDrxCycle value. Otherwise, the short DRX cycle is automatically
adjusted to a proper value.
A larger value of DrxShortCycleTimer indicates a longer short DRX cycle for UEs. If
LongDrxCycle is set to 320ms, you are advised to set DrxShortCycleTimer to 1.
A smaller value of FddEnterDrxThd indicates a low probability that the UE enters the
DRX mode, and a larger value indicates the opposite effect. When FddEnterDrxThd is set
to 1000, the eNodeB directly instructs the UE to enter the DRX mode without considering
the data scheduling measurement results. You are advised to set FddEnterDrxThd to 1000
to prevent UEs from entering the DRX mode frequently and decrease signaling overhead.
A smaller value of FddExitDrxThd indicates a high probability that the UE exits the DRX
mode, and a larger value indicates the opposite effect. If both the values of the
FddExitDrxThd and FddEnterDrxThd parameters are small and close to each other, the
UE frequently enters and exits the DRX mode. When FddExitDrxThd is set to 1000, the
eNodeB does not instruct the UE to exit the DRX mode according to the data scheduling
measurement results, and the UE does not exit after entering the DRX mode. You are
advised to set FddExitDrxThd to 1000 to prevent UEs from exiting the DRX mode
frequently and decrease signaling overhead.
When LongDrxCycle is set to 80ms or above, change the value of TimeAlignmentTimer
from 1920ms (a default value) to 10240ms, ensuring no impact on synchronization by the

long DRX cycle. When TimingAdvCmdOptSwitch is set to ON, you are advised to set
TimeAlignmentTimer to sf10240. If TimeAlignmentTimer is set to a smaller value, UEs
in the DRX mode are more likely to enter the out-of-synchronization state in the uplink.
7.1.6 Inference and Analysis

You need to use X solutions to analyze specific problems, such as service drops, handover
failures, long ping delay, and decreased throughput, if problem causes cannot be identified
by simple analysis on check for external events, historical operations, faults and alarms,
known issues of a version, and parameter settings which comply with recommended
parameter settings or not, or problems that the UE cannot enter or exit the DRX mode,
traffic drops to the bottom, and there are a large number of DRX reconfiguration messages
cannot also be identified based on cell-level tracing. For details, see problem processing
sections in corresponding X solutions.
7.1.7 Specific Methods for Feature Problem Location

7.1.7.1 Data Collection
Problem location requires the following data:
 Cell DT tracing results with the tracing item number of 34, 50, 89, or 97 (obtained on
the U2000) or intelligent field test system (IFTS) tracing results with the tracing item
number of 34, 50, 89, 97, or 98
 Configuration information and signaling data traced over the air interface
 BRD logs of baseband processing units (BBPs), which are obtained from the Web
LMT or U2000
 QXDM logs of UEs equipped with QualComm chips and PCs configured with QXDM
 Traffic statistics data
 Call history record (CHR) logs
7.1.7.2 Method for DRX Problem Identification

Identify whether problems are related to DRX, preventing all problems from being
considered to be caused by DRX. Focus on whether time of traffic statistics counter
changes and problem occurrence time are closely related to time of DRX switch or other
parameter changes. Identify main DRX parameters listed in the following table in
combination with operation logs.
Parameter MML Command
DrxAlgSwitch MOD DRX

ShortDrxSwitch
DataAmountStatTimer MOD CELLDRXPARA
FddEnterDrxThd
FddExitDrxThd
Qci MOD CELLSTANDARDQCI

Parameter MML Command
DrxParaGroupId
ExtendedQci MOD CELLEXTENDEDQCI
DrxParaGroupId
DrxParaGroupId MOD DRXPARAGROUP
EnterDrxSwitch
LongDrxCycle
OnDurationTimer
DrxInactivityTimer
DrxReTxTimer
SupportShortDrx
ShortDrxCycle
DrxShortCycleTimer
LongDrxCycleSpecial MOD DRX
OnDurationTimerSpecial
DrxInactivityTimerSpecial
SupportShortDrxSpecial
ShortDrxCycleSpecial
DrxShortCycleTimerSpecial
TimeAlignmentTimer MOD TATIMER
The following figure shows that reconfiguration message sent from the eNodeB to the UE
contains the DRX parameter settings. This indicates that the eNodeB instructs the UE to
enter the DRX mode. As shown in the following figure, the setup field under drx-Config
indicates that a UE is instructed to enter the DRX mode, whereas the release field indicates
that the UE is instructed to exit the DRX mode.

Identify whether UEs support DRX. A UE reports its capability during initial access. Bit 5
in the feature group indicators field of the RRC_UE_CAP_INFO message specifies
whether the UE supports DRX. (Bit 5 indicates that the UE supports a long DRX cycle,
whereas bit 4 indicates that the UE supports a short DRX cycle. The value of bit 4 is
ignored when that of bit 5 is invalid.) Seen from the message parsed in the following figure,
the value of bit 5 is 0, indicating that the UE does not support DRX.
7.1.7.3 Method of Checking Why UEs Cannot Enter the DRX Mode
Step 1 Run LST DRX to query whether the DRX switch is on. If the DRX switch is off, set
DrxAlgSwitch to ON.

Step 2 Check whether UEs support DRX. For details, see section 7.1.7.2"Method for DRX
Problem Identification."
Step 3 Query thresholds for entering and exiting DRX and value of TTI for data transmission of
UEs. If the value of TTI for data transmission is greater than or equal to the threshold for
exiting DRX, UEs do not enter the DRX mode.
The following figure shows DRX measurement-based IFTS 97 tracing data. If the value of
TTI for data transmission is greater than or equal to the threshold for exiting DRX, UEs do
not enter the DRX mode.
Step 4 Check whether a number of bearers with different QCIs are set up for the UE. If yes, check
whether each bearer supports DRX. Run LST CELLSTANDARDQCI to query the DRX
parameter group ID for the QCI in use.

Step 5 Run LST DRXPARAGROUP to query whether DRX is enabled based on the queried
DRX parameter group ID. If DRX is disabled, you need to enable DRX or set up other
bearers of QCIs supporting DRX.
----End
7.1.7.4 Check Method for DRX Measurement

Measurement-related parameters include FddEnterDrxThd, FddExitDrxThd, and
DataAmountStatTimer. During UE access, bearer setup, and handover completion, the
DRX module starts DRX measurement to determine whether to instruct the UE to enter or
exit the DRX mode. Determine the value (calculated by TTI for data transmission in the
uplink and downlink/measurement period) within the set value of DataAmountStatTimer.
If the value is less than the threshold for entering DRX and the UE is not in the DRX mode,
the UE is instructed to enter the DRX mode. If the value is greater than the threshold for
exiting DRX and the UE is in the DRX mode, the UE is instructed to exit the DRX mode.
97 tracing indicates DRX measurement tracing, and is used for locating the following
problems:
 The UE cannot enter the DRX mode.
 The UE cannot exit the DRX mode.
 Traffic drops to the bottom.
 Excessive DRX reconfiguration messages are generated.

One DRX measurement message is recorded each time the DRX measurement timer
expires. When the value of the usSendingTTIRatio field is less than or equal to that of the
usThEnterDrx field, and the value of the ucRptType field is not equal to 1, the ucRptType
= 1 message is reported to instruct the UE to enter the DRX mode. When the value of the
usSendingTTIRatio field is greater than or equal to that of the usThExitDrx field, and the
value of the ucRptType field is not equal to 0, the ucRptType = 0 message is reported to
instruct the UE to exit the DRX mode. The current conditions are maintained in other cases.
Reporting ucRptType = 1 or ucRptType = 0 message does not indicate that the UE enters or
exits the DRX mode immediately. After the DRX parameters are delivered from the
eNodeB to the UE and the UE makes a response that the DRX reconfiguration is
completed, the eNodeB instructs the UE to enter or exit the DRX mode. The following table
lists descriptions of fields in 97 tracing.
Field Name Field Description Remarks
HH:MM:SS eNodeB time None

ulTti TTI count This field is incremented by one per millisecond.
usFrm Frame number This field is aligned with the frame number on the air
interface.
ucSubFrm Subframe number This field is aligned with the subframe number on the
air interface.
ucCellId Cell ID This field indicates a local cell ID.
usCrnti CRNTI of a UE This field indicates a UE identifier.
usMacUeId UEs' MAC ID This field indicates a UE identifier.
usTrffcMeasPrd DRX measurement period The value of this field can be queried by running LST
CELLDRXPARA.
usThEnterDrx Threshold for entering DRX The value of this field can be queried by running LST
CELLDRXPARA.
usThExitDrx Threshold for exiting DRX The value of this field can be queried by running LST
CELLDRXPARA.
ucDrxTriggered Identifier for entering the 0: Indicates that UEs are not in the DRX mode.
DRX mode 1: Indicates that UEs are in the DRX mode.
ucRptType Reporting whether to enter 0: Indicates that UEs exit the DRX mode.
or exit the DRX mode 1: Indicates that UEs enter the DRX mode.
2: Indicates that UEs enter the unsynchronized DRX
mode.
3: Indicates that UEs exit the unsynchronized DRX
mode.
Other values: Indicates invalidity.
usSumSendingTTI Total number of uplink and None
downlink scheduling times
within the last measurement
period

usSendingTTIRatio Ratio of uplink scheduling The value of this field is calculated using the following
times to downlink formula:
scheduling times within the Value of usSendingTTIRatio = Total number of uplink
last measurement period and downlink scheduling times/Measurement period x
1000
7.1.7.5 Counter-assisted Analysis Method

DRX-related counters can be analyzed to determine whether a problem is related to DRX
and its impact as well as gains on signaling and power saving performance. The following
table lists all DRX-related counters.
Counter Description
L.Signal.Num.DRX.Reconfig Measures the number of RRC Connection Reconfiguration messages

sent in a cell to reconfigure DRX. DRX reconfiguration includes
DRX activation, DRX deactivation, or DRX parameter
reconfiguration.
L.Cdrx.Enter.Num Measures the number of times that the UE in RRC_CONNECTED
mode enters DRX.
L.Cdrx.Exit.Num Measures the number of times that the UE in RRC_CONNECTED
mode exits DRX.
L.Cdrx.Active.TtiNum Measures the number of TTIs for UEs in the DRX activation period
within the measurement period of 1s.
L.Cdrx.Sleep.TtiNum Measures the number of TTIs for UEs in the DRX sleep period within
the measurement period of 1s.
L.Traffic.User.Cdrx.Avg Measures the number of UEs (including synchronization and out-of-
synchronization UEs) in the DRX mode in a cell within the
measurement period of 1s, and calculates the average value based on
the traffic statistics period of 15 minutes to 1 hour.
L.E-RAB.Release.Unsyn Measures the number of released E-RABs of UEs in the uplink out-
of-synchronization state in a cell.
L.E-RAB.Num.Syn2Unsyn Measures the total number of E-RABs of UEs when the UEs switch
from the uplink-synchronized state to the uplink out-of-
synchronization state in a cell.
L.E-RAB.StateTrans.Unsyn2Syn.Att Measures the number of E-RAB recovery attempts when UEs switch
from the uplink out-of-synchronization state to the uplink-
synchronized state.
L.E-RAB.StateTrans.Unsyn2Syn.Succ Measures the number of times an E-RAB is recovered successfully
when UEs switch from the uplink out-of-synchronization state to the
uplink-synchronized state.
L.RRC.StateTrans.Syn2Unsyn Measures the number of times a UE switches from the uplink-
synchronized state to the uplink out-of-synchronization state in a cell.
L.RRC.StateTrans.Unsyn2Syn Measures the number of times a UE switches from the uplink out-of-
synchronization state to the uplink-synchronized state in a cell.

Counter Description
L.RRC.StateTrans.Unsyn2Syn.Succ Measures the number of times an RRC connection is recovered

successfully when UEs switch from the uplink out-of-synchronization
state to the uplink-synchronized state.
L.Traffic.User.Unsyn.Drx.Avg Measures the number of UEs in the uplink out-of-synchronization
state with dynamic DRX enabled.
L.Signal.Num.Uu Measures the number of UE level signaling messages including the
non-access stratum (NAS) messages over the Uu interface in a cell.
L.Voip.Cdrx.Active.TtiNum Measures the number of TTIs for UEs in the DRX activation period
while performing VoIP services within the measurement period of 1s.
L.Voip.Cdrx.Sleep.TtiNum Measures the number of TTIs for UEs in the DRX sleep period while
performing VoIP services within the measurement period of 1s.
The following table lists handover-related counters of UEs in DRX mode.
Counter Description
L.HHO.DRX.IntraeNB.IntraFreq.Exec Measures the number of executed intra-eNodeB intra-frequency

AttOut outgoing handovers in the DRX mode.
L.HHO.DRX.IntraeNB.IntraFreq.Exec Measures the number of successful intra-eNodeB intra-frequency
SuccOut outgoing handovers in the DRX mode.
L.HHO.DRX.IntraeNB.InterFreq.Exec Measures the number of executed intra-eNodeB inter-frequency
L.HHO.DRX.IntraeNB.InterFreq.Exec Measures the number of successful intra-eNodeB inter-frequency
L.HHO.DRX.IntereNB.IntraFreq.Exec Measures the number of executed inter-eNodeB intra-frequency
L.HHO.DRX.IntereNB.IntraFreq.Exec Measures the number of successful inter-eNodeB intra-frequency
L.HHO.DRX.IntereNB.InterFreq.Exec Measures the number of executed inter-eNodeB inter-frequency
L.HHO.DRX.IntereNB.InterFreq.Exec Measures the number of successful inter-eNodeB inter-frequency
L.HHO.DRX.IntraeNB.InterFddTdd.E Measures the number of intra-eNodeB inter-duplex-mode handover
xecAttOut executions triggered for UEs in the DRX mode.
L.HHO.DRX.IntraeNB.InterFddTdd.E Measures the number of successful intra-eNodeB inter-duplex-mode
xecSuccOut outgoing handovers triggered for UEs in the DRX mode.
L.HHO.DRX.IntereNB.InterFddTdd.E Measures the number of inter-eNodeB inter-duplex-mode handover
xecAttOut executions triggered for UEs in the DRX mode.
L.HHO.DRX.IntereNB.InterFddTdd.E Measures the number of successful inter-eNodeB inter-duplex-mode
xecSuccOut outgoing handovers triggered for UEs in the DRX mode.

Distribution of packet transmission intervals for UEs in a cell can be taken as a reference to
analyze traffic model changes when DRX is enabled.
Counter Description
L.Traffic.PktInterval.Num.Index0 Measures the number of times the packet transmission interval for
a UE in a cell ranges within index 0.
Distribution of out-of-synchronization durations for UEs in a cell can be analyzed when

dynamic DRX is enabled.
Counter Description
L.User.UL.Unsync.Dur.Index0 Measures the number of times the duration of a UE in the out-of-

synchronization state in a cell ranges within index 0.

Counter Description

 If the L.Traffic.User.Cdrx.Avg, L.Cdrx.Enter.Num, and L.Cdrx.Exit.Num counters

have measurement values, DRX is enabled. Whether DRX is enabled can also be
determined based on handover-related counters.
 The number of DRX reconfiguration messages can be measured using the
L.Signal.Num.DRX.Reconfig counter in scenarios with dynamic DRX disabled, or can
be measured using the following formula:
Number of DRX reconfiguration messages = L.Cdrx.Enter.Num +
L.Cdrx.Exit.Num
The number of dynamic DRX reconfiguration messages is calculated using the
following formula:
Number of dynamic DRX reconfiguration messages = L.Signal.Num.DRX.Reconfig –
L.Cdrx.Enter.Num – L.Cdrx.Exit.Num
Dynamic DRX is enabled if the number of dynamic DRX reconfiguration messages is
greater than 0, that is, the number of dynamic DRX reconfiguration messages for UEs
switching from the out-of-synchronization state to synchronization state or from the
synchronization state to out-of-synchronization state is greater than 0.
 Whether a power saving effect is achieved with DRX enabled can be evaluated
indirectly using either of the following formulas:
− L.Cdrx.Active.TtiNum/L.Voip.Cdrx.Active.TtiNum
− L.Cdrx.Sleep.TtiNum/L.Voip.Cdrx.Sleep.TtiNum
However, an accurate power saving effect can be achieved by tests using the Agile
device.
 Total signaling reduction effect of DRX can be obtained using the following formula:
Total signaling reduction effect of DRX = L.E-RAB.AttEst +
(L.Signal.Num.DRX.Reconfig + L.RRC.StateTrans.Syn2Unsyn)/10
In the formula, the signaling overhead of 10 RRC Connection Reconfiguration
messages is equal to that of one E-RAB setup procedure (including the service request
procedure).
Then, impact of signaling messages on the problem can be analyzed in combination
with changes of the L.Signal.Num.Uu counter.
 Enabling dynamic DRX and increasing length of the UE inactivity timer lead to a
longer duration for UEs to remain in RRC_CONNECTED mode. This may decrease
the number of paging messages. Impact of dynamic DRX on paging messages can be
evaluated based on the L.Paging.UU.Att counter.

 The L.Traffic.User.Unsyn.Drx.Avg counter measures the average number of UEs

configured with out-of-synchronization DRX parameters in a cell with dynamic DRX
enabled. The number of UEs that are in RRC_CONNECTED mode and are configured
with out-of-synchronization DRX parameters in a cell is sampled per second. At the
end of a measurement period, the average of these sampling results is taken as the
L.Traffic.User.Unsyn.Drx.Avg counter value. Impact of dynamic DRX on
performance can be analyzed based on the number of UEs entering the dynamic DRX
mode.
 Counter rectification is performed in certain scenarios.
The following table lists new KPI calculation formulas required in signaling reduction
mode of dynamic DRX. If KPI changes occur after dynamic DRX is enabled, calculate
using the following formulas and identify whether the problems meet the expectation.
Clarify to operators if there is any problem.

Service Drop Calculation L.E-RAB.AbnormRel/(L.E-RAB.AbnormRel + L.E-RAB.NormRel +

Rate (%) Formula L.E-RAB.Num.Syn2Unsyn – L.E-RAB.Release.Unsyn)
Modification The total number of E-RABs of UEs when the UEs switch from the
Point uplink-synchronized state to the uplink out-of-synchronization state is
added in the denominator, and the total number of released E-RABs of
UEs in the uplink out-of-synchronization state, which is repeatedly
calculated, is subtracted.
Modification After the length of the UE inactivity timer is increased, the number of
Cause some normal E-RAB releases is converted into that of E-RABs of UEs in
the uplink out-of-synchronization state. Therefore, the total number of E-
RABs of UEs when the UEs switch from the uplink-synchronized state
to the uplink out-of-synchronization state is added in the denominator.
Service RRC Calculation (L.RRC.ConnReq.Succ.Mt + L.RRC.ConnReq.Succ.MoData +
Connection Formula L.RRC.ConnReq.Succ.EMC + L.RRC.ConnReq.Succ.HighPri +
Succ Rate (%) L.RRC.StateTrans.Unsyn2Syn)/(L.RRC.ConnReq.Att.Mt +
L.RRC.ConnReq.Att.MoData + L.RRC.ConnReq.Att.EMC +
L.RRC.ConnReq.Att.HighPri + L.RRC.StateTrans.Unsyn2Syn)
Modification The number of times a UE switches from the uplink out-of-

Point synchronization state to the uplink-synchronized state is added in
numerator and denominator, respectively.
Modification After the length of the UE inactivity timer is increased, the number of
Cause times a UE switches from RRC_IDLE mode to RRC_CONNECTED
mode is converted into that of times a UE switches from the uplink out-
of-synchronization state to the uplink-synchronized state.
In eRAN7.0, the value of the L.RRC.StateTrans.Unsyn2Syn.Succ
counter is measured to replace that of the L.RRC.StateTrans.Unsyn2Syn
counter in the numerator.
E-RAB Setup Calculation (L.E-RAB.SuccEst + L.RRC.StateTrans.Unsyn2Syn)/(L.E-
Succ Rate (%) Formula RAB.AttEst + L.RRC.StateTrans.Unsyn2Syn)
Modification The value of the L.RRC.StateTrans.Unsyn2Syn counter is added in

Point numerator and denominator, respectively.
Modification The modification cause is the same as that of the RRC setup success rate.
Cause The number of E-RAB setup times may be greater than that of RRC
connection setup times. Therefore, in eRAN7.0, values of the L.E-
RAB.StateTrans.Unsyn2Syn.Att and L.E-
RAB.StateTrans.Unsyn2Syn.Succ counters are added to replace
denominator and numerator in the calculation formula.
There are handover-related counters dedicated to DRX, which can be measured

independently. If values of handover counters for UEs in the DRX mode are less than those
for common UEs, DRX has impact on handover counters.

7.1.7.6 DRX TTI-level Analysis Method

This section describes 89- and 98-tracing-based record contents. A record is made each time
an event is triggered in 89 tracing. Changes of each DRX-related event can be observed
clearly based on 89 tracing. The tracing item number 98 indicates UE-level IFTS tracing
used for tracing data of the first UE that accesses a cell. A record is made at every TTI.
Analysis of 89 Tracing
Cell-level 89 tracing indicates DRX mode tracing, as shown in the following figure.
The ucTracEvent field is recorded once an event is triggered. DRX mode tracing is often
used for DRX problem location. The current DRX mode is determined based on each DRX
event, and problem identification is performed in combination with tracing items, including
cell-level 34 tracing for downlink scheduling, cell-level 50 tracing for uplink scheduling,
cell-level 111 tracing for the TA state, and cell-level 14 tracing for random access. The
following table lists specific descriptions of each field.
HH:MM:SS eNodeB time None

Ticks Tick record None
SN Serial number of a None
message
interface.
ucSubFrm Subframe number This field is aligned with the subframe number on the air
interface.
usCrnti CRNTI of a UE None
usMacUeId UEs' MAC ID None
ucDrxTriggered Identifier for entering the 0: Indicates that UEs are not in the DRX mode.
DRX mode 1: Indicates that UEs are in the DRX mode.
ucRptType Reporting to RR whether 0: Indicates that UEs exit the DRX mode.
to enter or exit the DRX 1: Indicates that UEs enter the DRX mode.
mode
2: Indicates that UEs enter the unsynchronized DRX mode.
3: Indicates that UEs exit the unsynchronized DRX mode.
Other values: Indicates invalidity.

usCurDrxPrd Current DRX period The unit of this field is ms.

ucSleepType Sleep type 0: Indicates that UEs enter the sleep period when the DRX
timer expires.
1: Indicates that the timer is stopped after two consecutive
DTXs are received, and then UEs enter the sleep period.
2: Indicates that the timer is stopped when an MCE
message is delivered, and then UEs enter the sleep period.
ucDrxSleepFlg DRX sleep mode 0: Indicates that DRX is in activation mode.
1: Indicates that DRX is in sleep mode.
ucAnrIsRunning Whether the ANR timer 0: Indicates that the ANR timer stops running.
is running 1: Indicates that the ANR timer is running.
ucDrxMCEflg Whether to deliver 0: Indicates that the DrxMce identifier is not delivered.
DrxMce identifier 1: Indicates that the DrxMce identifier is delivered.
ulStartOndrationTti Moment at which the Determination is performed 1 ms before the OnDuration
OnDuration timer starts timer starts, and therefore the subframe number is 1 ms
greater than the start time during tracing. The timer start
time is for reference only when you view data.
ulActiveTmrEndTti Moment at which the The millisecond at the end moment is also considered as
inactivity timer ends the moment for start of the inactivity timer.
ucSrPending Indication for SR 0: Indicates that an SR is not received.
receiving 1: Indicates that an SR is received.
ucDrxMode DRX mode 0: Indicates a non-DRX mode.
1: Indicates a DRX mode.
2: Indicates a DRX mode during ANR measurement.
3: Indicates an unsynchronized DRX mode.

ucTracEvent Trace event 0-MEAS_ENTER: Indicates that DRX measurement starts.

1-MEAS_EXIT: Indicates that DRX measurement ends.
2-MEAS_MODIFY: Indicates that DRX measurement
parameter settings are changed.
3-MEAS_TMOUT: Indicates that the DRX measurement
timer expires.
4-DRX_ENTER: Indicates that UEs enter the DRX mode.
5-DRX_EXIT: Indicates that UEs exit the DRX mode.
6-OD_ON: Indicates that the OnDuration timer starts.
7-IV_ON: Indicates that the inactivity timer starts.
8-ANR_ON: Indicates that the ANR timer starts.
9-SHORT_CYCLE_ON: Indicates that the short DRX
cycle is configured.
10-SR_PANDING: Indicates that an SR is received.
11-MSG3_PENDING: Indicates that Msg3 sent by the UE
is received.
12-DL_DTX: Indicates that one DTX is received.
13-DRX_MCE: Indicates that MCE is delivered.
14-LINK_ADD: Indicates that UEs are added into the DRX
link table.
15-LINK_RMV: Indicates that UEs are deleted from the
DRX link table.
DL_NDTX: Indicates that two consecutive DTXs are
received, but UEs do not enter the sleep period.
DL_NDTX_STATE_TRANS: Indicates that two
consecutive DTXs are received, and UEs enter the sleep
period.
ucMacActiveFlag UE activation identifier 0: Indicates deactivation.
1: Indicates activation.
ucTaState TA state 0-ERR: Indicates an invalid value.
1-TA_SYN: Indicates the TA synchronization state.
2-SYN_NOTA: Indicates that the TA state is not delivered.
3-TA_UNSYN: Indicates the TA unsynchronization state.
4-RESYNING: Indicates resynchronization.
ulIATmrAvailableEn TTI recorded when the This field is used for records added in DTX scheduling and
dTti inactivity timer expires in optimization.
the last time
Analysis of 98 Tracing
IFTS tracing indicates UE-level tracing and is used for tracing data of the first UE that
accesses a cell. A record is made at every TTI. The data volume is large, and therefore flow

control may be triggered. DRX-based IFTS tracing includes 98 tracing. In addition, 97

tracing and 89 tracing can also be included in IFTS tracing. Based on 98 tracing, the DRX
mode at each TTI can be observed.
98 tracing is used for DRX mode tracing, as shown in the following figure.
HH:MM:SS eNodeB time

interface.
ucSubFrm Subframe number This field is aligned with the subframe number on the
air interface.
usCrnti CRNTI of a UE
usDrxOffset Offset for start of the OnDuration This field is included in the reconfiguration message
timer transmitted over the air interface.
usDrxLongCycle Long DRX cycle (unit: ms) This field is included in the reconfiguration message
transmitted over the air interface.
usDrxShortCycle Short DRX cycle (unit: ms) This field is included in the reconfiguration message
transmitted over the air interface.
usOnDuration Length of the OnDuration timer This field is included in the reconfiguration message
(unit: ms) transmitted over the air interface.
usInavtivityTimer Length of the inactivity timer This field is included in the reconfiguration message
(unit: ms) transmitted over the air interface.
usCurDrxPrd Current DRX period If the current DRX period indicates a long period, the
value of this field is equal to that of the
usDrxLongCycle field; if the current DRX period
indicates a short period, the value of this field is equal
to that of the usDrxShortCycle field.
ucDrxSleepSRFlag Whether an SR is received in the 0: Indicates that an SR is not received in the DRX
DRX sleep period sleep period.
1: Indicates that an SR is received in the DRX sleep
period.
ucDrxTriggered Identifier for entering the DRX 0: Indicates that UEs are not in the DRX mode.
mode 1: Indicates that UEs are in the DRX mode.

ucDrxPrdStatus Current DRX period status 0: Indicates an invalid value.

1: Indicates a short period.
2: Indicates a long period.
ucDtxCounter Number of DTXs consecutively
received
ucDrxMCEflg Whether to deliver DrxMce 0: Indicates that the DrxMce identifier is not
identifier delivered.
1: Indicates that the DrxMce identifier is delivered.
ucSleepStatusFlag Sleep type 0: Indicates that UEs enter the sleep period when the
DRX timer expires.
1: Indicates that the timer is stopped after two
consecutive DTXs are received, and then UEs enter
the sleep period.
2: Indicates that the timer is stopped when an MCE
message is delivered, and then UEs enter the sleep
period.
ucStopTimerDTX Threshold for stopping the timer The value of this field is 2 by default, that is, DRX-
Count when DTXs are received related timers are stopped when two consecutive
DTXs are received, and UEs enter the DRX sleep
period.
ucDrxSleepFlg DRX sleep mode 0: Indicates that DRX is in activation mode.
1: Indicates that DRX is in sleep mode.
ucAnrIsRunning Whether the ANR timer is 0: Indicates that the ANR timer stops running.
running 1: Indicates that the ANR timer is running.
ucDrxMode DRX mode 0: Indicates a non-DRX mode.
1: Indicates a DRX mode.
2: Indicates a DRX mode during ANR measurement.
3: Indicates an unsynchronized DRX mode.
usDrxForAnrTime Length of the ANR timer (unit: After the ANR timer expires, stop OnDuration and
r ms) inactivity timers, and deliver DRX MCE.
ucRetransTimer Length of the retransmission
timer (unit: ms)
ucSriCounter Number of SRs
ucDrxShortCycleT Number of short cycles The length of short DRX cycle is calculated using the
imer following formula:
Length of short DRX cycle = usDrxShortCycle x
ucDrxShortCycleTimer
ucTaSendFlag Marks for TA delivery 0: Indicates that no TA is to be delivered.
1: Indicates that there are TAs to be delivered.
usMacUeId UEs' MAC ID

bitOnDurationTim Running identifier of the 0: Indicates that the OnDuration timer is stopped.
erOn OnDuration timer 1: Indicates that the OnDuration timer is running.
bitInactivityTimer Running identifier of the 0: Indicates that the inactivity timer is stopped.
On inactivity timer 1: Indicates that the inactivity timer is running.
bitSrPending Indication for SR receiving 0: Indicates that an SR is not received.
1: Indicates that an SR is received.
Analysis of CHR Logs and Inter-layer Messages

CHR logs are parsed using the MyLDT tool and saved as files. Open the
L2_CHR_CELL_TYPE_L2STAT20002058 file in .csv format, and therefore impact of DRX
on problems is analyzed in combination with cell-level DRX activation and sleep period
and faulty KPI changes. In addition, IFTS tracing can be performed on inter-layer messages
to identify intra-eNodeB problems, and to identify whether problems occur in interaction
messages among RR, CELLM, RLC, and MAC layers. It is recommended that CHR logs
and inter-layer messages be analyzed by research and development (R&D) personnel after
being captured. The following figure shows contents recorded in CHR logs.
ulCellDrxActiveCnt Activity period of all UEs in the DRX mode in a cell (unit: s)
ulCellDrxSleepCnt Sleep period of all UEs in the DRX mode in a cell (unit: s)
7.1.7.7 Analysis of Long Uplink Ping Delays

The problem of tool long uplink ping delays can be located by taking the ping delay
analysis report as a reference. This section will mainly describe the possible impact of DRX
on ping delays.
1. Check the preallocation switch.

Because preallocation is not performed in DRX mode, the ping delay will increase by
a maximum of 8 ms. Therefore, first run the LST CELLALGOSWITCH command
to check whether the preallocation switch is turned on.
2. Determine the theoretical ping delays.

The procedure is as follows:
(1) If the preallocation switch is on, turn off the preallocation and DRX switches.
Then, send an uplink ping packet and record the packet delay (a ms).
(2) Turn on the DRX switch, send an uplink ping packet, and record the ping delay
(b ms).
(3) Calculate the ping delay:
− For a long DRX cycle, b – a ≤ Long DRX cycle – On Duration
− For a short DRX cycle, b – a ≤ Short DRX cycle – On Duration
If the DRX Inactivity Timer does not expire before the ping reply is sent from the
MAC layer, the ping delay is not affected by the DRX cycle; instead, it is related only
to preallocation and the UE's QualComm chip.
The following figure illustrates the uplink ping delay when the DRX switch is off. If
the SR reporting period is 5 ms, the uplink ping delay is between (8 + x) ms and (17 +
x) ms, where x denotes the transmission delay at the upper layer of MAC, generally in
the range of 1 ms to 2 ms.
The following figure illustrates the uplink ping delay when the DRX switch is on. If
the long DRX cycle is 10 ms, the short DRX cycle is not used, and the length of the

On Duration timer is 2 ms, then the uplink ping delay is between (8 + x) ms and (25 +
x) ms.
If the calculated delay is longer than expected, then:

(1) Check channel quality to see whether the long delay is caused by retransmissions.
(2) If there is NACK, check whether packets sent to the UE are erroneously decoded.
(3) If there is DTX, check whether the eNodeB status is consistent with the UE
status.
On the eNodeB side, use the IFTS tool with the trace extended items 34, 50, 89,
97, and 98 selected, and check the status consistency in each TTI. Then, check
whether new downlink data is scheduled during the sleep period in DRX mode.
3. Analyze the impact of UEs on ping delays.

Ping delays may also be related to UE behavior in DRX mode. You can use different
UEs to check whether ping delays occur only on some types of UEs. If permitted, you

can also obtain UE logs for analysis. For QualComm chips, you can use the QXDM
tool to obtain UE logs and use other tolls such as Wireshark and QCAT to analyze the
ping procedure segment by segment. Pay more attention to the following signaling on
the UE side:
 Signaling generated when the UE enters the sleep state
MSG [09509/02/07]LTE ML1/High/DLM 12:11:08.333 lte_ml1_dlm_cfg.c 03401 DLM: cdrx req
ON->OFF
MSG [09509/02/07]LTE ML1/High/DLM 12:11:08.333 lte_ml1_dlm_rach.c 00355 While

processing CDRX request: min_on_time_subfn_cnt: 65533cdrx_req->action: 0 cdrx_req->inactive_timer:
171155908 wakeup_subfn_cnt: 317
MSG [09509/15] LTE ML1/SleepMGR 12:11:08.340 lte_ml1_sleepmgr_stm.c 09515

[LTE_ML1_SLEEPMGR_STM] ONLINE_SLEEP_WAIT -> SLEEP (Entry Function)
 Signaling generated when the UE attempts to send an SR

MSG [09504/02] LTE MACCTRL/High 12:11:08.351 lte_mac_qos.c 01069 SR request event from
QOS Pending=2,sr_cnt:494
 Signaling generated when the UE is awakened

MSG [09509/02/07]LTE ML1/High/DLM 12:11:08.405 lte_ml1_dlm_cfg.c 03440 DLM: cdrx req
OFF->ON
MSG [09509/02/07]LTE ML1/High/DLM 12:11:08.405 lte_ml1_dlm_rach.c 00355 While processing

CDRX request: min_on_time_subfn_cnt: 4024cdrx_req->action: 1 cdrx_req->inactive_timer: 100
wakeup_subfn_cnt: 245

[LTE_ML1_SLEEPMGR_STM] TTL_WAIT -> ONLINE (Entry Function)
 Signaling generated for confirming successful scheduling based on SR

MSG [09504/02] LTE MACCTRL/High 12:11:08.416 lte_mac_ctrl.c 01124 Got SR cnf from
L1,stat=1 (0-Not sent,1-Sent)
7.1.7.8 Analysis of DRX Reconfiguration Indicator Changes

Changes in DRX reconfiguration indicators can be analyzed from the following aspects:
 Check whether the traffic model changes, and analyze changes in the number of UEs
in DRX mode and thresholds for entering and exiting DRX.
 Check whether the number of handovers changes.
 Check impacts of ANR measurement. If ANR measurement is performed frequently,
DRX configurations for ANR measurement will be delivered, which causes the
number of DRX reconfiguration messages to change.
 Check whether delivered gap-assisted measurement attempts increase due to a feature.
A UE in the gap-assisted measurement period will not be enabled to enter the DRX
mode.
 Check whether the SRS period and CQI reporting period configured at a site remain
unchanged. If these two periods continuously change, the length of a DRX timer may
be adjusted, and a DRX reconfiguration message is delivered.
 Check whether QCI activation or deactivation occurs. If QCI activation or deactivation
occurs, DRX-related parameters will be reconfigured. Focus on QCI 1 activation or
deactivation.

7.2 Typical Cases

7.2.1 Downlink Throughput Decreases After DRX Is Enabled
Problem Description
In office H in country C, the results of drive tests using RCU terminals show that the
downlink throughput significantly decreases after DRX is enabled and restores after DRX is
disabled.
Problem Analysis
4. Identify the problem.
The operation log shows that there are no operations except a DRX operation at the
time point when the throughput changes.

The air interface log shows that DRX parameters are delivered.
The probe log shows that bit 5 is 1, indicating that the UE supports DRX.
5. Check external events and history operations.

The frontline confirms that there are not external events such as large-scale activities,
site reconstruction, and frequency refarming. The operation log shows that there are no
operations related to other functions and features.
6. Check faults and alarms.
The frontline confirms that there are no faults or alarms that affect throughput
according to the query results on the U2000.
7. Check known issues.
The problem in office H is similar to that in Chengdu where the downlink throughput
decreases after two consecutive DTX states are detected and scheduling is stopped.
The version used in this office is V100R007C00SPC128 and the problem is not solved
in this version. To check whether the problems in the two offices are the same, cell DT
tracing needs to be performed and the trace extended items 34, 50, and 89 need to be
selected.
8. Check parameters.
The frontline's test result shows that power-saving-preferred parameter settings are
used, no parameters are set to non-recommended values, and no exceptions are found.

Parameter Name Value
OnDurationTimer PSF10
DRXInactivityTimer PSF100
DRXReTxTimer PSF8
LongDRXCycle SF320
ShortDRXCycle SF80
DRXShortCycleTimer 1
9. Analyze the cell DT tracing result.

E392, E3276, and RCU terminals are used for comparison tests. The test data collected
on the eNodeB side shows that the problems that these terminals experience have the
same reason. The following uses the RCU terminal as an example to describe the
analysis procedure:
(1) As there is no RCU terminal test software, the terminal log is unavailable and the
eNodeB log is used. The log shows that the number of scheduling times
approaches the maximum value when DRX is disabled. That is, the scheduling
requirement of the RCU terminal is fulfilled when DRX is disabled.
(2) When DRX is enabled, the number of RCU terminal scheduling times is far below
1000 per second (the maximum value) though the RCU is scheduled every second.

(3) The time point 9:32:18 (where the number of scheduling times is far below the
maximum value) is selected for further analysis. In frame 33, two consecutive
DTX states are detected and the sleep period starts. Then, there is not downlink
scheduling until the On Duration in frame 63 arrives. The downlink scheduling
interruption time is about (63 – 33) x 10 = 300 ms.
(4) In frame 73, three consecutive DTX states are detected and the sleep period starts.
Then, there is not downlink scheduling until the On Duration in frame 95 arrives.
The downlink scheduling interruption time is about (95 – 73) x 10 = 220 ms.
(5) In frame 105, two consecutive DTX states are detected and the sleep period starts.
Then, there is not downlink scheduling until the On Duration in frame 127 arrives.
The downlink scheduling interruption time is about (127 – 105) x 10 = 220 ms.

(6) The analysis results at other time points are the same as that at 9:32:18. That is,
two or more consecutive DTX states are detected and therefore the sleep period
starts, which affects the number of downlink scheduling times.
10. Conclusion
 The problem in this office is the same as that in Chengdu. The eNodeB detects
two consecutive DTX states, considers the UE to be in the sleep state as there is
no response to downlink scheduling, and stops downlink scheduling. The eNodeB
has to wait for the next On Duration for scheduling and therefore the number of
downlink scheduling times decreases. All E392, E3276, and RCU terminals have
the same problem. For the RCU terminal, there is a higher probability that two
consecutive DTX states are detected and a more obvious decrease in the number
of downlink scheduling times.
 In DRX mode, the eNodeB stops downlink scheduling after detecting two
consecutive DTX states. This mechanism is not rational and will be optimized in
later versions to reduce the impact of two consecutive DTX states on downlink
scheduling.
7.2.2 Ping Delays Are Long After DRX Is Enabled

Problem Description
In office W in country C, the results of tests using Huawei C8817L show that ping delays
increase from about 30 ms to 60 ms to 70 ms after DRX is enabled. This problem occurs on
the networks of multiple operators.
Problem Analysis
1. Check the preallocation switch.
Because preallocation is not performed in DRX mode, the ping delay will increase by
a maximum of 8 ms. However, preallocation is not the only cause of long delays.
There should be other causes.
2. Compare the actual and theoretical ping delays.

The following table lists the key parameter settings for DRX. The DRX Inactivity
Timer value is greater than the actual ping delays, indicating the DRX cycle has no
impact on ping delays.
No Parameter Name Parameter Setting
1 OnDurationTimer 10 ms
2 DrxInactivityTimer 100 ms
3 DrxRetransmissionTimer 8 ms
4 LongDrxCycle 320 ms
5 ShortDrxCycle 20 ms
6 ShortDrxCycleTimer 1

7 TAtimer 10240 ms
3. Analyze the impact of UEs.

When Huawei C8817L terminals (equipped with QualComm chips) are used for
testing, ping delays are long. When Huawei P7 phones equipped with Huawei
Hisilicon chips are used for testing, ping delays remain unchanged after DRX is
enabled. Therefore, it is deduced that terminals with QualComm chips may experience
this problem. The following provides the QXDM log of such a terminal:
(1) A ping packet is sent from the application layer.
(2) The terminal enters the sleep state at the time marked in red.
[LTE_ML1_SLEEPMGR_STM] ONLINE_SLEEP_WAIT -> SLEEP (Entry Function)
(3) The terminal attempts to send an SR.

MSG [09504/02] LTE MACCTRL/High 05:32:03.608 lte_mac_qos.c 01069 SR request event from
QOS Pending=2,sr_cnt:494
(4) It takes 43 ms to waken up the terminal after the SR is sent.

[LTE_ML1_SLEEPMGR_STM] TTL_WAIT -> ONLINE (Entry Function)
(5) The delay on the network side is 1762 – 1741 = 21 ms.
(6) The application layer of the terminal receives the ping reply.
The previous log shows that the terminal enters the sleep state after DRX is enabled.
To send an SR, the terminal needs to transit from the sleep state to the active state. The
transition consumes 43 ms, as shown in the following figure.

When DRX is disabled, the terminal immediately sends an SR after receiving a ping
request from the application software. In this case, the internal processing delay is very
small, as shown in the following figure.
4. Conclusion

The previous analysis shows that long delays and variations are related to DRX. In
DRX mode, the terminal enters the sleep state if there is no data to transmit. When the
terminal needs to originate an uplink ping service, it must be awakened first and then it
can send an SR. As the wakening consumes a long time, the ping delay is long. This
problem is due to the design of QualComm chips.
7.2.3 The RRC Connection Reestablishment Success Rate

Decreases As the On Duration Is Too Short
Problem Description
In office W in country C, after DRX is enabled and the Time Alignment Timer is adjusted
on the whole network, the RRC connection reestablishment success rate decreases from
about 70% to 45%.
Problem Analysis
Only parameters related to DRX are adjusted and the adjustment time is consistent
with the change time shown in the previous figures.
6. Check faults and alarms.

The frontline checks that there are no faults or alarms that affecting KPIs.

7. Check known issues.

The version is BTS3900 V100R008C10SPC240, and there are not similar known
issues.
8. Check parameters.
The following table lists the actual parameter settings and Huawei-recommended
parameter settings.
Parameter Actual Parameter Setting Huawei-Recommended Parameter Setting
EnterDRXSwitch ON ON
LongDRXCycle SF320 SF320
OnDurationTimer PSF2 PSF10
DRXInactivityTimer PSF80 PSF100
DRXReTxTimer SF8 SF8
SupportShortDRX UU_ENABLE UU_ENABLE
ShortDRXCycle SF20 SF80

DRXShortCycleTimer 1 1
TimeAlignmentTimer 10240 10240

FddEnterDRXThd 1000 1000
FddExitDRXThd 1000 1000
The parameters on the live network are adjusted as listed in the previous table, where
the two settings are different from those recommended by Huawei, and the
TimeAlignmentTime value changed from 5120 to 10240. Setting OnDurationTimer
and DrxInactivityTimer to smaller values and LongDrxCycle to a large value will
increase the proportion of the UE staying in the sleep state and reduce UE power
consumption, but increase system latency and reduce scheduling opportunities. In
addition, changing the TimeAlignmentTimer value from 5120 to 10240 leads to
deterioration in uplink timing performance and may result in scheduling issues.
The parameters are adjusted again as recommended by Huawei for power saving.
Then, the RRC connection reestablishment success rate restores to a normal value. The
following figure shows the test result.
9. Analyze the problem.

You can take X Solutions for Access and Paging Performance Optimization in the LTE
Network as a reference for analysis. The following provides the main analysis
procedure.
The traffic statistics show that reestablishment failures are mainly due to no contexts.
The result of Uu tracing on a site from 9:00 to 11:00 shows that reestablishment
failures on this site accounts for a large proportion.
Item Reestablishment on Reestablishment on Total
This Site Other Sites
Number of reestablishment requests 43 12 55

Number of successful reestablishments 3 8 11
The tracing result shows UE 267910 is released due to inactivity after access cell 3. A
UE's reestablishment request is rejected. This UE is UE 267910, according to the PCI
and CRNTI of the cell where the UE camps before reestablishment. After the request
is rejected, the UE sends another reestablishment request, with the same TMSI.
The previous analysis shows that the UE Inactivity Timer expires and the UE does not
receive the RRC connection release command sent by the eNodeB. However, why
does the UE not receive the release command from the eNodeB after the eNodeB
rejects the reestablishment request due to no contexts?

The result of internal message tracing on top three sites shows that six cells are set up
on one LBBPd3. In this case, three scheduling threads each correspond to two cells but
each thread can schedule only one cell in each TTI. Among the 2 ms On Duration, one
millisecond is used for scheduling system information (as the SIB2 broadcasting
period is 160 ms, shorter than the long DRX cycle 320 ms), and the other millisecond
is used for scheduling one cell's DCCH signaling. Therefore, some cells' DCCH
signaling cannot be scheduled in time. The wait time for RRC connection release at L3
is equal to the long DRX cycle plus 450 ms. If the DRX Inactivity Timer does not
start, there are only two to three scheduling chances. As a result, some RRC
connection release commands are not delivered.
For power-saving-preferred parameter settings, the On Duration Timer is set to 10 ms
and the problem will not occur. For performance-preferred parameters, the problem
will also not occur because the long DRX cycle is 40 ms, system information is
scheduled every four long DRX cycles, and two cells can be scheduled in the 2 ms On
Duration.
10. Conclusion
DRX parameters are not set as recommended by Huawei. The On Duration Timer is
too short, and some cells' DCCH signaling cannot be scheduled in time. After the UE
Inactivity Timer expires, some RRC connection release commands of the eNodeB are
not delivered in time and therefore they are not received by the UE. When the UE
sends a reestablishment request, the eNodeB rejects the request due to no contexts.
7.2.4 The RRC Connection Establishment Success Rate

Decreases and the Main Control Board CPU Is Overloaded After
DRX Is Enabled
Problem Description
In office T in country N, after DRX is enabled on the whole network, the RRC connection
establishment success rate decreases and the main control board CPU is overloaded on top
10 heavy-traffic sites. This problem generally appears in peak hours (around 7:00 to 17:00)
and disappears in off-peak hours.
Problem Analysis
After DRX is enabled, the RRC connection establishment success rate decreases, the
average and maximum usage of the main control board CPU increases, and the
maximum number of online users decreases. (The changes in sensitive performance
indicators are not presented.) The problem is closely related to traffic volume, and it
disappears after the traffic volume decreases.
12. Analyze the impact of RRC connection reconfiguration signaling for DRX on the main
control board CPU usage.
With the growth in traffic volume after DRX is enabled, the number of RRC
connection reconfiguration messages for DRX significantly increases and the main
control board CPU usage also increases. These symptoms are indicated by the changes
of the main control board CPU usage and the value of L.Cdrx.Enter.Num. The
changes in sensitive performance indicators are not presented.
Theoretically, if the FddEnterDrxThd parameter is set to 300 and the
FddExitDrxThd parameter is set to 800, an RRC connection reconfiguration message
and a reconfiguration complete message are required each time a UE enters DRX

mode and the CPU usage significantly increases. Under these parameter settings, the
UE starts measurement after accessing the network. In the period defined by the
DataAmountStatTimer parameter, if the percentage of TTIs with data scheduling
exceeds 30%, an RRC connection reconfiguration message is delivered to instruct the
UE to enter DRX mode. As the measurement period is far longer than the access delay,
this message cannot be combined with the reconfiguration message in the access
procedure and must be delivered separately.
After the main control board CPU is overloaded, a large number of RRC connection
establishment failures occur. The reason is that the processing delay is prolonged due
to CPU overload and the Msg4 is probably delivered too late. As a result, the RRC
connection requests are rejected or even discarded in flow control. These symptoms
are indicated by the peak usage of the main control board CPU, the number of RRC
connection establishment failures, and the number of RRC connection requests
discarded in flow control (L.RRC.ConnReq.Msg.disc.FlowCtrl).
A large number of RRC connection establishment failures results in a large number of
Msg3 for attempts. This further increases the main control board CPU usage, triggers
more intensive flow control, and decreases the RRC connection establishment success
rate. This vicious cycle leads to a high CPU usage and a large number of RRC
connection establishment failures during peak hours.
13. Locate root causes.
After the FddEnterDrxThd and FddExitDrxThd parameters are set to the
recommended value 1000, the RRC connection reconfiguration signaling for DRX is
integrated into the first reconfiguration message in the access procedure and will not
consume additional CPU resource. This is confirmed by the air interface signaling
tracing result. The changes in sensitive performance indicators are not presented.
Provided that the traffic volume remains unchanged and the value of
L.Cdrx.Enter.Num is in the same order of magnitude, there is not a significant increase
in the main control board CPU usage after those two parameter values are changed. As
a result, there are not a large number of RRC connection establishment failures or
RRC connection requests discarded in flow control. These symptoms verify that RRC
connection reconfiguration signaling for DRX is the cause of the problem.
The changes in sensitive performance indicators are not presented; these indicators
include the peak usage of the main control board CPU, number of RRC connection
establishment failures, number of RRC connection requests discarded in flow control,
maximum number of online users, and RRC connection establishment success rate.
14. Conclusion
After DRX is enabled, a large number of RRC connection reconfiguration messages
are added on the air interface and the main control board CPU is overloaded. Msg 4 is
delivered too late, and flow control is triggered, leading to a large number of RRC
connection establishment failures and RRC connection requests discarded. Repeat
access attempts after access failures further increase the CPU usage and intensify flow
control until the traffic volume decreases.
The solution is to set the FddEnterDrxThd and FddExitDrxThd parameters to the
recommended value 1000.

7.2.5 Voice Quality Deteriorates After DRX Is Enabled

Problem Description
In site H in country C, VoLTE voice discontinuity occurs on iPhone 6 and voice quality is
not satisfactory. There are obvious packet losses on the air interface in peak hours, as shown
in the following figure. DRX parameters are set as recommended by Apple for lightly
loaded networks:
 OnDurationTimer = 2ms
 DrxInactivityTimer = 2ms
 LongDrxCycle = 40ms
 SupportShortDrx = UU_DISABLE
These parameter settings are never optimized at the system level.
Problem Analysis
15. Simply analyze the problem.
At 21:37:31, fourteen uplink voice packets are lost in TTI 20215215, according to the
eNodeB PDCP tracing result.
The uplink scheduling tracing result shows that the eNodeB performs scheduling
according to the SR of a UE in TTI 20214878 at 21:37:31. After the scheduling, this
UE sends a BSR indicating that the buffer is not empty. However, the eNodeB does
not perform uplink scheduling in time until the UE sends again the SRI 330 ms later,
that is, in TTI 20215208. As the PDCP packet discard timer is set to 100 ms, the
eNodeB detects packet losses in TTI 20215215.
The cause of voice packet losses is that the eNodeB does not promptly perform
scheduling based on BSRs.
16. Analyze the voice problem of the LBBPc.
The eNodeB detects the UE's uplink BSRs every 8 ms (which is defined by the BSR
Check Timer. If a BSR indicates that the buffer is not empty, there is a chance of
scheduling. After DRX is enabled, the eNodeB does not schedule a UE if it detects that

the UE is in the sleep state and the BSR check time does not fall in the On Duration.
The eNodeB schedules the UE until the BSR Check Timer expires and the UE sends
an SR. As the delay is long, the PDCP packet discard timer expires and VoLTE packet
loss occurs.
For the LBBPd and UBBPd, the scheduling algorithm is more complex and accurate.
The BSR Check Timer is set to 2 ms (as shown in the following figure), and the non-
empty buffer status can be detected in the active time. As a result, UEs can be
scheduled more promptly, provided that the number of UEs served by the LBBPd and
UBBPd is the same as that served by the LBBPc.
With the increase in the number of users, the calculation workload will be reduced to
ensure system stability. Specifically, the BSR Check Timer will be automatically
prolonged to reduce the frequency of updating scheduling chances, as shown in the
following table, where N indicates the number of users served by a BBP.
BSR Check Timer LBBPc LBBPd UBBPd
2 ms N < 50 N < 300 N < 300

4 ms 50 ≤ N < 100 300 ≤ N < 450 300 ≤ N < 450
8 ms 100 ≤ N < 200 450 ≤ N < 600 450 ≤ N < 600
16 ms N ≥ 200 N ≥ 600 N ≥ 600
17. Conclusion
On the live network, the On Duration Timer and the DRX Inactivity Timer are set to
small values, leading to concentrated scheduling requirements. As a result, some UEs
cannot be scheduled in time, voice packets are lost, and voice delays are prolonged.
In addition, the parameter settings recommended for the live network only consider
power saving for a single UE without considering performance, delay, and capacity.
The parameter settings should be optimized for the entire system.
To ensure timely scheduling when the buffered data cannot be scheduled at a time,
Huawei recommends that the DRX Inactivity Timer be set to 80 ms. The DRX
parameters are not adjusted during web browsing and data download and therefore
power consumption will not increase. The DRX parameters are adjusted only when the
UE is performing a VoLTE service. In this case, as the active time increases, UE power
consumption will slightly increase. The lab test result shows that Huawei-

recommended DRX parameter settings can effectively reduce the number of VoLTE
packet losses.
7.2.6 The MOS Decreases After DRX Parameters Are Set as

Recommended by Apple
Problem Description
In office D in country D, DRX parameters are recently set as recommended by Apple. The
subsequent drive test result shows that the average VoLTE MOS of Samsung Galaxy S5
(with a coding rate of 23.85 kbit/s) decreases by about 0.2 from 3.9 to 3.7 on both Huawei
and another vendor's networks.
Problem Analysis
11. Identify the problem in the IOT lab.
Based on the parameter settings used on live networks, a test is performed in the IOT
lab to compare the MOSs under Huawei-recommended and Apple-recommended
parameter settings. The test result is as follows:
 For Samsung Galaxy S4, S5, S6, and Note 3 with coding rates of 23.85 bit/s and 12.65
bit/s, the MOSs decrease by 0.1 to 0.3 under Apple-recommended DRX parameter
settings. The decreases at the coding rate of 23.85 bit/s are greater than those at the
coding rate of 12.65 kbit/s.
 For Huawei Mate 7 with a coding rate of 23.85 bit/s, the MOS also decreases by 0.1 to
0.15 under Apple-recommended parameter settings.
 For Apple iPhone 6s with a coding rate of 12.65 bit/s, the MOS does not obviously
decrease under Apple-recommended parameter settings.
UEs Coding Rate Parameter MOS E2E_Delay_AVG (ms)
S6–S6 23.85 huaweiDRX 3.84 146.32

appleDRX 3.57 190.21
Difference 0.27 –43.89
S5–S4 23.85 huaweiDRX 3.98 166.27
appleDRX 3.8 204.44
Note 3–Note 3 23.85 huaweiDRX 3.98 159.57
Note 3–Note 3 12.65 huaweiDRX 3.76 175.53
Mate 7–Mate 7 23.85 huaweiDRX 3.88 213.9

UEs Coding Rate Parameter MOS E2E_Delay_AVG (ms)

iPhone 6s–iPhone 6s 12.65 huaweiDRX 3.32 195.07
12. Analyze the cause of MOS decrease

 Uplink and downlink packet loss rates over the air interface do not increase under
Apple-recommended parameter settings.
UEs Coding Rate Parameter MOS UU_UL_Drop UU_DL_Drop
Rate Rate
S6–S6 23.85 huaweiDRX 3.84 0.00% 0.01%

appleDRX 3.57 0.00% 0.00%
Difference 0.27 0.00% 0.01%
S5–S4 23.85 huaweiDRX 3.98 0.02% 0.01%
appleDRX 3.8 0.02% 0.02%
Difference 0.18 0.01% –0.01%
Note 3–Note 3 23.85 huaweiDRX 3.98 0.00% 0.00%
appleDRX 3.69 0.01% 0.00%
Difference 0.29 –0.01% 0.00%
Note 3–Note 3 12.65 huaweiDRX 3.76 0.00% 0.00%
appleDRX 3.61 0.00% 0.00%
Difference 0.15 0.00% 0.00%
Mate 7–Mate 7 23.85 huaweiDRX 3.88 0.02% 0.00%
appleDRX 3.73 0.02% 0.00%
Difference 0.15 0.01% 0.00%
iPhone 6s–iPhone 6s 12.65 huaweiDRX 3.32 0.00% 0.00%
appleDRX 3.29 0.00% 0.00%
Difference 0.03 0.00% 0.00%
 All terminals experience greater voice packet delay variations under Apple-
recommended parameter settings than under Huawei-recommended parameter settings.

UEs Coding Rate Parameter MOS E2E_Delay_Jitter E2E_Delay_

(ms) AVG (ms)
S6–S6 23.85 huaweiDRX 3.84 15–35 146.32

appleDRX 3.57 0–80 190.21
Difference 0.27 35–80 –43.89
S5–S4 23.85 huaweiDRX 3.98 15–35 166.27
appleDRX 3.8 0–80 204.44
Difference 0.18 35–80 –38.17
Note 3–Note 3 23.85 huaweiDRX 3.98 15–35 159.57
appleDRX 3.69 0–80 212.89
Difference 0.29 35–80 –53.32
Note 3–Note 3 12.65 huaweiDRX 3.76 15–35 175.53
appleDRX 3.61 0–70 205.92
Difference 0.15 35–70 –30.39
Mate 7–Mate 7 23.85 huaweiDRX 3.88 15–35 213.9
appleDRX 3.73 0–80 244.63
Difference 0.15 35–80 –30.73
iPhone 6s–iPhone 6s 12.65 huaweiDRX 3.32 10–30 195.07
appleDRX 3.29 0–40 241.04
Difference 0.03 30–40 –45.97
 The voice packet delay variations for iPhone 6s are in the range of about 0–40 ms
under Apple-recommended parameter settings while those for Samsung terminals are
in the range of 0–80 ms.

 The result of comparison between UEs' TX and RX voice waveforms shows that delay
variations lead to jitter-buffer packet losses and MOS decreases.
Case 1: MOS = 3.4
From 15:33:29 to 15:33:40, both calling and called parties do not experience uplink or
downlink voice packet losses on the air interface.
The waveform analysis result shows that about 886 ms later after the beginning,
additional frames introduced in the jitter buffer lead to a waveform phase shift, which
affects the MOS. The first figure below shows a low-MOS waveform and the second
shows a high-MOS waveform.

The QXDM data shows that a long delay of 80 ms appears in the 44th conversational
frame.
Case 2: MOS = 3.38

From 15:35:18 to 15:35:29, both calling and called parties do not experience uplink or
downlink voice packet losses on the air interface.
The waveform analysis result shows that about 744 ms later after the beginning,
additional frames introduced in the jitter buffer lead to a waveform phase shift, which
affects the MOS. The first figure below shows a low-MOS waveform and the second
shows a high-MOS waveform.
The QXDM data shows that a long delay of 80 ms appears in the 37th conversational
frame. (This delay is equal to 29 ms plus 51 ms, where 29 ms is the delay of the RTCP
packet with a PDU size of 55.)

13. Analyze the cause of delay variation deterioration

Both uplink packet transmissions and downlink packet receptions on UEs experience
delay variation deterioration.
Under Apple-recommended DRX settings, delay variations of 0–40 ms are introduced
in both uplink packet transmissions and downlink packet reception on all terminals
including iPhone 6s. If delay variations are not handled, there will be an end-to-end
delay variation of 80 ms.
 Analyze the cause of uplink transmission delay variations
Under Apple-recommended DRX settings, two voice packets are occasionally sent
together from the same Samsung terminal. The uplink delay variations for about 30%
of voice packets are in the range of 0–40 ms. The reason is that the Apple-
recommended On Duration is too short. All uplink data of a terminal may not be
scheduled according to the SR within an On Duration, for example, when there are a
voice packet and an RTCP packet or when there are two voice packets in the buffer
due to missing SR detection. In this case, the remaining data in the buffer and the
subsequent voice packet from the higher layer of the terminal in the sleep period can
be scheduled only in the next On Duration, that is, 40 ms later.
Case 1: Samsung Galaxy Note 3, coding rate of 23.85 kbit/s, uplink delay variation of
40 ms
Before subframe 8 of frame 368, an RTCP packet (marked in red) and a voice packet
(marked in blue) arrive almost at the same time.
However, only one 103-byte voice packet can be scheduled in subframe 8 of frame
368 according to the uplink grant. The reason is that the SR does not contain any
traffic volume information about the terminal and therefore the uplink scheduler
adaptively determines the to-be-scheduled traffic volume (133) according to the last
scheduled traffic volume (113).

After the scheduling, the UE still has data in the buffer to transmit and therefore sends
a BSR instead of resending an SR. However, the Apple-recommended On Duration is
only 4 ms, and the data can be scheduled only in the first subframe of the next On
Duration. As a result, two voice packets are scheduled 40 ms later.
Case 2: Apple iPhone 6s, coding rate of 12.65 kbit/s

Under Apple-recommended DRX settings, two uplink packets of iPhone 6s are
bundled for scheduling. The delay variations for all voice packets are in the range of
0–40 ms.

 Analyze the cause of downlink reception delay variations

The Apple-recommended On Duration is only 4 ms. If the terminal is in the sleep state
when a voice packet from the core network arrives at the eNodeB, the packet has to
wait for 0–36 ms on the eNodeB before it can be scheduled on the air interface and
sent to the terminal. Therefore, a downlink delay variation of 0–36 ms is introduced
under Apple-recommended parameter settings.
Considering both uplink and downlink delay variations, a total of 0–80 ms variation is
introduced from end to end under Apple-recommended parameter settings.
18. Analyze the average E2E delay of Apple terminals.

According to the previous analysis, a total of 0–80 ms delay variation will be
introduced under Apple-recommended DRX settings without any processing on voice
packets. However, the delay variations of over 99% of voice packets are controlled in
the range of 0–40 ms for Apple terminals under Apple-recommended DRX settings,
while the average E2E delay is 40 ms to 50 ms longer than that for Samsung terminals.
Therefore, it is deduced that Apply ensures the delay variation of 0–40 ms by
sacrificing the average E2E delay. This is why the voice quality of Apple terminals
does not significantly deteriorate.
UE Coding Rate Parameter E2E_Delay_Jitter (ms) E2E_Delay_AVG (ms)
S6 23.85 appleDRX 0–80 190.21

S5 23.85 0–80 204.44
Note 3 23.85 0–80 212.89
Note 3 12.65 0–70 205.92
iPhone 6s 12.65 0–40 241.04

UE Coding Rate Parameter E2E_Delay_Jitter (ms) E2E_Delay_AVG (ms)
Difference 40–80 40
14. Optimization solution analysis and verification

 Optimization solution analysis
According to the previous analysis, MOS decrease is caused by delay variation
increase under Apple-recommended DRX settings. The possible optimization solutions
are as follows:
− Under Apple-recommended DRX settings, optimize the BSR-based scheduling
algorithm for uplink voice service. For voice UEs in DRX mode, the eNodeB
allows the initial transmission in an uplink HARQ retransmission period. This
solution has been incorporated in eRAN11.1.
− Under Apple-recommended DRX settings, enable the eNodeB to evaluate the voice
traffic volume increased in the buffer in a period of time based on the uplink voice
packet interval and size, and to allow the increased volume to be scheduled next
time. This solution has been incorporated in eRAN8.1.
The following provides the corresponding functions and parameters of eRAN11.1 for
these two solutions:
− For solution 1, the function is scheduling optimization in a HARQ retransmission
period, and the DrxStateDuringUlHarqRetx.DRX_ACTIVE_FOR_VOICE
parameter controls this function.
− For solution 2, the function is uplink scheduling optimization based on traffic
volume estimation, and the UlVoLTEDataSizeEstSwitch option of the
CELLULSCHALGO.UlEnhancedVoipSchSw parameter controls this function.
 Optimization solution verification
− Terminals: Samsung Galaxy Note 3 used by both calling and called parties, coding
rate of 23.85 kbit/s
− Parameter settings
(1) appleDRX optimization: off
(2) appleDRX optimization: on
(3) huaweiDRX optimization: on
− Test versions: eRAN11.1
− Optimization measures: Enable both uplink scheduling optimization based on
traffic volume estimation and scheduling optimization in a HARQ retransmission
period.
− Test result: The average MOS increases and the average E2E delay decreases. The
average E2E delay under Apple-recommended parameter settings is slightly higher
than that under Huawei-recommended parameter settings.
Item Average MOS E2E_Delay_AVG (ms)
appleDRX optimization: off 3.74 215.35

appleDRX optimization: on 3.86 204.27
huaweiDRX optimization: on 3.90 183.72

The following figure shows the distribution and of MOSs and the effect after the
optimization.
The following figures compare the delay variations before and after optimization.
Under Apple-recommended DRX settings and Huawei optimization solution, the
uplink delay variations for the local Note 3 decrease from 0–40 ms to 15–25 ms and
the downlink delay variations of 99% of samples for the peer Note 3 are controlled in
the range of 0–40 ms, equivalent to the optimization effect of Apple.

eRAN15.0 Power Saving (Including DRX) Solution Integration and Optimization Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

eRAN15.0 Power Saving (Including DRX) Solution Integration and Optimization Guide

Uploaded by

Copyright:

Available Formats

LTE FDD eRAN13.

Prepared By Yang Xiaosheng (employee ID: 00183640) Date 2016-11-24

Reviewed By Li Tianyi (employee ID: 00284157), Liu Shuai Date 2016-11-24

Huawei Technologies CO., LTD.

Date Version Description Author

2014-10-30 eRAN8.1-V1.0 Completed the draft. Yang Xiaosheng

2020-03-07 Huawei confidential. No spreading without permission. Page 2 of 98

2 Recommended Parameter Settings for Feature Activation.................................................10

3 Solutions to Commercial Use Cases on the Live Network..................................................26

2020-03-07 Huawei confidential. No spreading without permission. Page 3 of 98

3.4 Commercial Use Situations of DRX Disabled in Office V in Country K....................................................................30

4 Known Issues, Feature Activation Risks, and Workarounds.............................................33

5 Solution Optimization and Improvement..............................................................................48

2020-03-07 Huawei confidential. No spreading without permission. Page 4 of 98

1 Feature Application Policies

1.1.1 Weak Coverage Scenarios

1.1.2 Heavy Traffic Scenarios

2020-03-07 Huawei confidential. No spreading without permission. Page 5 of 98

1.1.3 High-Speed Movement Scenarios (Including Highways,

1.1.4 Low-Band Wide-Coverage Scenarios

2020-03-07 Huawei confidential. No spreading without permission. Page 6 of 98

1.2 Dynamic DRX

Power Saving Mode

Signaling Reduction Mode

2020-03-07 Huawei confidential. No spreading without permission. Page 7 of 98

In high-speed movement scenarios, such as highways, metros, and railways, or when UE

1.3 UE-Specific Differentiated DRX

2020-03-07 Huawei confidential. No spreading without permission. Page 8 of 98

1.3.2 Parameter Configurations

1.3.3 Effect Evaluation Method

2020-03-07 Huawei confidential. No spreading without permission. Page 9 of 98

2 Recommended Parameter Settings for

2.1 Recommended Parameter Settings for DRX

2020-03-07 Huawei confidential. No spreading without permission. Page 10 of 98

DrxParaGroupId MOD Indicates the ID of the DRX - 1

2020-03-07 Huawei confidential. No spreading without permission. Page 11 of 98

Parameter ID MML Parameter Description Unit Recommended

OnDurationTimer Indicates the length of the On Subframe PSF10

2020-03-07 Huawei confidential. No spreading without permission. Page 12 of 98

Parameter MML Unit Recommended Value Recommended Value

ShortDrxCycle Subframe SF20 SF80

TimeAlignmentTimer MOD Subframe Greater than or equal to Greater than or equal to

2.2 Recommended Parameter Settings for Dynamic DRX

Parameter MML Command Unit Recommended Value

DynDrxSwitch MOD CELLALGOSWITCH - OFF

2020-03-07 Huawei confidential. No spreading without permission. Page 13 of 98

Parameter MML Command Unit Recommended Value

2.3 UE-Specific Differentiated DRX

2.4 Recommended Non-key Parameter Settings

Parameter ID Recommended Parameter Description Unit Recommendation Reason

2020-03-07 Huawei confidential. No spreading without permission. Page 14 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason

2020-03-07 Huawei confidential. No spreading without permission. Page 15 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason

2020-03-07 Huawei confidential. No spreading without permission. Page 16 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason

secondary carrier cells are

2020-03-07 Huawei confidential. No spreading without permission. Page 17 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason

DTX decreases, but more

2020-03-07 Huawei confidential. No spreading without permission. Page 18 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason

2020-03-07 Huawei confidential. No spreading without permission. Page 19 of 98

Parameter ID Recommended Parameter Description Unit Recommendation Reason