Ericsson Internal

GUIDELINE 1 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

VoLTE Optimization: Technical Guideline

1 Introduction...................................................................................................5
2 Service Overview..........................................................................................5
3 Service Entry Criteria...................................................................................6
3.1 Meeting Minimum Service Criteria.....................................................................6
3.2 VoLTE Troubleshooting......................................................................................8
4 VoLTE S-KPI Benchmarking (Network Measurements)............................9
4.1 Overview...............................................................................................................9
4.2 VoLTE Performance Monitoring.......................................................................10
4.2.1 VoLTE Accessibility KPIs............................................................................................ 10
4.2.2 VoLTE Retainability KPIs............................................................................................ 11
4.2.3 VoLTE Integrity KPIs.................................................................................................. 11
4.2.4 Mobility KPIs............................................................................................................... 12
4.2.5 Capacity KPIs............................................................................................................. 14
4.3 Aligning R-KPIs to S-KPIs.................................................................................14
4.3.1 Identify Required Data................................................................................................ 16
4.3.2 Parse Collected Data.................................................................................................. 16
4.3.3 KPI Formula Definition................................................................................................ 16
4.3.4 Data Correlation.......................................................................................................... 17
4.3.5 Quantitatively Map R-KPI to S-KPI.............................................................................17
4.4 Metrics for KPI Acceptance..............................................................................18
5 Radio Coverage Optimization....................................................................19
5.1 Overview.............................................................................................................19
5.2 Coverage optimization process........................................................................20
5.3 VoLTE coverage requirements.........................................................................20
5.4 Usage of Ericsson Cell Optimizer (ECO) and RAN Analyzer (ERA)..............21
5.4.1 Cell-Traffic Recording (CTR) collection requirements.................................................22
5.4.2 Building the OSS database (operdb) with ODG..........................................................22
5.4.3 Building an ECO project............................................................................................. 25
5.4.4 Importing the operdb into the ECO project.................................................................28
5.4.5 Propagation information in Cell Optimizer..................................................................32
5.4.6 OSS-based scaling..................................................................................................... 32
5.4.7 Geolocated information............................................................................................... 36
 Ericsson Internal
GUIDELINE 2 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

5.4.8 RF assessment with ECO...........................................................................................42

5.4.9 Generic rasters........................................................................................................... 45
5.4.10 Additional weighting mechanism................................................................................47
5.4.11 Physical recommendations......................................................................................... 47
5.4.11.1 VoLTE coverage holes (OPTIONAL).................................................................54
6 Mobility Optimization..................................................................................56
6.1 Overview.............................................................................................................56
6.2 VoLTE intra-Frequency and inter-frequency optimization............................56
6.2.1 Optimization Trial Examples.......................................................................................56
6.2.1.1 Automated mobility optimization........................................................................57
6.2.1.2 Inter-frequency HO trigger A5 to A3 and RSRQ filter coefficient optimization...60
6.3 SRVCC Optimization..........................................................................................64
6.3.1 Option 1 – Improve SRVCC performance...................................................................64
6.3.2 Option 2 - Maintain Voice on VoLTE...........................................................................65
6.3.3 Optimization Trial Examples.......................................................................................67
6.3.3.1 Drop Call Rate Optimization During SRVCC Handovers...................................68
6.3.3.2 SRVCC and intra-frequency idle and connected mode Mobility Optimization...68
7 VoLTE and MBB Optimization...................................................................72
7.1 Overview.............................................................................................................72
7.2 VoLTE Key Feature Optimization.....................................................................72
7.2.1 TTI bundling................................................................................................................ 72
7.2.1.1 Optimizing TTI bundling thresholds...................................................................73
7.2.1.2 Optimizing TTI bundling thresholds from performance measurements.............75
7.2.1.3 Targeting mid cell coverage holes.....................................................................75
7.2.2 Robust header compression.......................................................................................76
7.2.3 Delay based scheduling & semi-persistent scheduling...............................................77
7.2.4 Enhanced PDCCH link adaptation..............................................................................78
7.2.5 PDCCH power boost.................................................................................................. 80
7.3 Sleep Timer Optimization..................................................................................82
7.3.1 Optimization of longDrxCycle.....................................................................................83
7.3.2 Optimization of shortDrxCycle....................................................................................84
7.4 Additional Parameter Optimization..................................................................86
7.5 VoLTE and MBB Optimization Trial Examples................................................87
7.5.1 Optimization of crsGain and pdschTypeBGain...........................................................87
7.5.2 UL FSS (with and without SRS) optimization..............................................................91
7.5.3 Tx/Rx reference point optimization.............................................................................94
7.5.4 DRX optimization and UL FSS / SRVCC activation....................................................95
8 VoLTE Root Cause Analyzer (VoLTE RCA)..............................................97
8.1 Overview.............................................................................................................97
8.2 Ericsson RAN Analyzer (ERA)..........................................................................97
8.2.1 System Requirements................................................................................................ 98
8.2.1.1 Hardware Requirements...................................................................................98
 Ericsson Internal
GUIDELINE 3 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.2.1.2 Software Requirements.....................................................................................98

8.2.2 OSS Data Gateway (ODG).........................................................................................99
8.2.2.1 Installation......................................................................................................... 99
8.2.2.2 Outputs.............................................................................................................. 99
8.2.2.3 SQL Memory Management.............................................................................100
8.2.3 Trace Processing Server (TPS)................................................................................101
8.2.3.1 Installation....................................................................................................... 102
8.2.3.2 TPS Customization for RCA............................................................................102
8.2.4 Requirements........................................................................................................... 104
8.2.4.1 LTE CTR Events for RCA................................................................................104
8.2.4.2 UE Fraction..................................................................................................... 105
8.2.5 Inputs........................................................................................................................ 105
8.2.6 Advanced & VoLTE RCA..........................................................................................106
8.2.7 Output....................................................................................................................... 106
8.2.7.1 Market Level Analysis.....................................................................................107
8.2.7.2 Call Level Analysis.......................................................................................... 108
8.2.7.3 Worst Offenders.............................................................................................. 120
8.2.7.4 Mobility Worst Offenders.................................................................................121
8.3 Analytics with Tableau....................................................................................122
8.3.1.1 Connecting files to tableau..............................................................................123
8.3.1.2 Limitations....................................................................................................... 123
8.4 Ways of Working..............................................................................................124
8.4.1 Market Level KPIs analysis.......................................................................................124
8.4.2 Market Level VoLTE RCA output Analysis...............................................................125
8.4.3 Filtered Scattered Plots............................................................................................ 128
8.4.4 Worst Offenders KPIs............................................................................................... 130
8.4.5 Worst Offenders correlation with VoLTE RCA output...............................................130
8.4.6 Parameter Analysis for Worst Offenders and/or Market level...................................131
8.5 Field References..............................................................................................132
8.5.1 AT&T Reference....................................................................................................... 132
9 VoLTE Audio Gap Optimization...............................................................136
9.1 Overview...........................................................................................................136
9.2 Root Cause for Audio Gaps............................................................................136
9.3 Audio Gap Counters and KPI Definition........................................................138
9.3.1 Audio gap Counter Overview....................................................................................138
9.3.2 Audio Gap Counter Limitations.................................................................................140
9.3.3 Counter Correlations................................................................................................. 142
9.3.4 Silent Experience KPI Definition...............................................................................144
9.4 VoLTE Audio Gap Optimization Trial Examples...........................................144
9.4.1 RLC Retransmission Optimization............................................................................145
9.4.2 QCI1 UL BLER Optimization....................................................................................147
9.4.3 Enhanced PDCCH Link Adaptation BLER for QCI1 Optimization............................149
9.4.4 Introduction of Uplink FSS for QCI1 and QCI5.........................................................151
 Ericsson Internal
GUIDELINE 4 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

9.4.5 RLF Timer Optimization............................................................................................154

9.4.6 CFI Setting Optimization during Handovers..............................................................157
10 Acronyms.................................................................................................. 158
11 References................................................................................................ 159
12 Revision History....................................................................................... 161
 Ericsson Internal
GUIDELINE 5 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

1 Introduction
This document is the technical guideline for the VoLTE Optimization service. It describes
the overall process, service components and inputs and outputs for this service. The LTE
RAN detail is based on the L15B release, however, the technical concepts can be used for
later releases. Specific detail to both LTE FDD and LTE TDD are considered.

The primary scope of this service is the LTE RAN and RAN transport networks. However,
the benchmarking (VoLTE Assessment), VoLTE and MBB optimization modules, and
especially the E2E troubleshooting and root cause analysis (RCA) considers VoLTE from
an end-to-end perspective. The complete services for VoLTE are shown in Figure 1.

Lastly, it should be noted that there are common activities between Tuning and
Optimization. For the most part Tuning is based upon Drive test data with some volume of
friendly user traffic for PM and CTR data. Whereas, Optimization is a post launch activity
with greater focus on user traffic to generate sufficient activity for PM, CTR analysis and
Feature/Parameter trials. Optimization is also augmented with drive testing as necessary
for specific e2e troubleshooting and assessing S-KPIs should probe and analytic platforms
be unavailable. Note that not all the modules under Optimization may be applicable
depending upon the maturity of the VoLTE network and reported issues, one needs to
assess which modules will provide benefits/value.

Figure 1: Overview of VoLTE services

2 Service Overview
The aim of the VoLTE optimization service is to use actual user experience information
collected through OSS and probe based data to achieve high performance of the VoLTE
network after launch. While Initial Tuning is based on a single user experience (drive-
testing), optimization services allow for the use of all users’ experience (network statistics)
to improve overall VoLTE performance as shown in Figure 2.
 Ericsson Internal
GUIDELINE 6 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 2: Impact of VoLTE services on the VoLTE performance

The outputs of the VoLTE Optimization service will be a well-functioning VoLTE network
assessed by network side statistics and cell trace data. Some degradation in MBB
performance may occur if the existing network configuration is strongly biased to MBB
performance. Therefore, prior to starting this service, the operator’s VoLTE and MBB
strategies should be consulted.

3 Service Entry Criteria

3.1 Meeting Minimum Service Criteria

VoLTE is an E2E solution and the end user experience can be impacted by many issues
from multiple domains. Prior to performing an optimization service, it is critical to ensure
that the VoLTE functionality has been tested and verified to be fault free. Typically, this is
conducted during the VoLTE Initial Tuning service as illustrated in Figure 3. A set of S-
KPIs are measured to ensure that the VoLTE solution is functioning correctly.

Prerequisites Optimization modules

VoLTE Troubleshootin VoLTE SKPI
Benchmarking g (if service Benchmarking Mobility Radio Coverage VoLTE & MBB
(drive-test criteria not (network Optimization Optimization Optimization
based) met) based)

Figure 3: Entry criteria for optimization modules

If degradations in VoLTE S-KPIs are seen at the start of this service then prior to
conducting any of service modules, VoLTE Troubleshooting as described in the VoLTE
Performance Troubleshooting section of the VoLTE Initial Tuning Technical Guideline [25]
should be performed. The VoLTE optimization service should not be started until the
issues have been rectified. VoLTE Troubleshooting involves complex service delivery and
therefore if required should be included in to the scope of the VoLTE Optimization service
prior to start.

In order to measure VoLTE service performance in a customer’s networks, it is necessary

to define a set of end-to-end service performance indicators, detailing the formulas to use
to measure the network performance from an end user perspective.
 Ericsson Internal
GUIDELINE 7 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The minimum service entry criteria for entry in to the VoLTE Optimization services is
based on the following service performance indicators (S-KPIs) being met in a typical
cluster as measured by drive-testing.

 Call Setup Success Ratio

 Call Completion Success Ratio

 Call Setup Time

 Voice Quality (MOS-LQOSWB and Speech Path Delay)

 Handover / SRVCC Handover Interruption Time

Refer to [19] [20] on the test conditions, methodology, call flows, triggers points and
formulas for measuring the above S-KPIs.

It is essential that the targets for the minimum criteria be agreed with the customer before
starting this service. The guidelines and details on these S-KPIs targets are documented
in [20]. These guidelines must be referenced for discussions and negotiations with the
customer before the S-KPIs targets are finalized. Table 1 lists the suggested targets from
[20]:

S-KPI Target
Call Setup Success Ratio The CSSR shall under normal operating network conditions be equal to
or better than 99%.

Call Completion Success Ratio The CCR shall under normal operating network conditions be equal to or
better than 98%

Call Setup Time VoLTE Call Setup Time shall under normal operating radio network
conditions, in 95% of the cases be:
- < 2,5 sec for VoLTE-VoLTE call where both UEs are in ECM
CONNECTED state.
- < 4 sec for VoLTE-VoLTE call where both UEs are initially in ECM IDLE
state
- < 2 sec for VoLTE – Break-out call where VoLTE UEs is initially in ECM
CONNECTED state (KPI on LTE half call, that is from the VoLTE UE to
the breakout function)
- < 3.3 sec for VoLTE – Break out call where VoLTE UEs is initially in
ECM IDLE state (KPI on LTE half call, that is from the VoLTE UE to the
breakout function)
Voice Quality (MOS-LQOSWB Frame Erasure (Error) Rate (FER)
and Speech Path Delay) - Very good speech quality
the used Speech Codec shall be AMR-WB 12.65 and corresponding
Measured using Frame Error FER shall be <1% for the 95th percentile
rate or RTP packet loss rate, - Good speech quality
speech path delay.
the used Speech Codec shall ne AMR-NB 12.2 and corresponding FER
shall be <1% for the 95th percentile
- Acceptable speech quality
the used Speech Codec shall be AMR-NB 5.9 and corresponding FER
 Ericsson Internal
GUIDELINE 8 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

shall be <1% for the 95th percentile

RTP Packet Loss Rate
Speech Path Delay
The 5th percentile of the speech path delay shall for a
- VoLTE<->VoLTE call be <225 ms
- VoLTE<->Break-in/out call be <125 ms (Note: only for the LTE half call)
SRVCC Handover Interruption The SRVCC HOIT shall under normal operating network conditions be <
Time 300 ms as 95th percentile

Table 1: Suggested S-KPI Targets as pre-requisites to starting VoLTE Optimization service

As not all of the KPIs in Table 1 can be measured through network performance statistics
it is, it is recommended that these S-KPIs should have been met at least at a single cluster
using drive-testing. Typically, these KPI levels should be achieved pre-launch.

3.2 VoLTE Troubleshooting

In the event that the set S-KPI targets are not met at a cluster level or a single site S-KPI
are degraded, it is essential to validate and understand the reason for the degradation.
The VoLTE Optimization modules should not be initiated until the underlying root causes
have been rectified. Figure 4 illustrates the end-to-end root-cause analysis approach.

Figure 4: End-to-end root cause analysis through correlation of VoLTE R- and S-KPIs

Troubleshooting VoLTE performance issues requires co-relating information from the

domains of:

 Device (UE)

 IMS Core

 IP Transport

 RAN
 Ericsson Internal
GUIDELINE 9 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The VoLTE Performance Troubleshooting section of the VoLTE Initial Tuning Technical
Guideline [25] describes the methodology and the steps to follow in order to isolate and
eliminate issues that could be resulting in low overall performance. This will ensure that
performance issues are removed prior to optimization.

4 VoLTE S-KPI Benchmarking (Network Measurements)

4.1 Overview

Description:

The objective of the VoLTE S-KPI Benchmarking (network measurements) module is to

benchmark VoLTE Service KPIs (S-KPIs) to Resource KPIs (R-KPIs) as well as
benchmark the network performance and capacity against global standards. The service
also includes aligning the R-KPIs to S-KPIs in order to better understand the impact of the
RAN domain on S-KPIs. The result is a VoLTE performance and capacity monitoring
report that provides a detailed understanding of VoLTE performance from the network
side.

Inputs:

 VoLTE Initial Tuning service output (or VoLTE benchmarking drive-test)

 OSS Data – Configuration Management (CM): OSS data containing all RAN OSS
configuration data (parameters)

 OSS Data – Performance Management (PM): OSS data containing all performance
management data (counters) for KPI analysis

Outputs:

 VoLTE monitoring report (with S-KPIs mapped to R-KPIs)

 Report on impact of RAN on S-KPI performance

Tools:

 Performance monitoring tool: ITK / ESPA / KPI monitoring tool from customer

 If VoLTE Initial Tuning drive-test results are not available, drive-testing may be
required.

o Drive-testing: Anite Nemo (Backup: TEMS investigation)

o Post processing: Anite Nemo (Backup: TIPP L, Actix)

Note – For the aligning R-KPIs to S-KPIs activity, this document provides an example for
understanding the RAN domain KPIs. However, if the operator requires, a similar exercise
 Ericsson Internal
GUIDELINE 10 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

can be performed to align core network R-KPIs with S-KPIs. Scope of this module should
be discussed with customer prior to starting the service.

4.2 VoLTE Performance Monitoring

Prior to starting VoLTE Optimization, it is required to setup VoLTE

performance and capacity monitoring from the network side. This allows to
benchmark VoLTE performance and to quantify any improvements from the
VoLTE optimization service.

The KPIs for VoLTE can be categorized into Accessibility, Retainability,

Integrity, Mobility and Capacity. The R-KPIs associated with each of these
categories is summarized below. The formula’s given below are example
only, refer to CPI for updated formula’s based on SW release.

4.2.1 VoLTE Accessibility KPIs

Accessibility KPIs measures the ability of end users to access the wireless
service by establishing the Evolved-Radio Access Bearer (E-RAB).

The E-RABs associated with VoLTE are: 1) QCI5 (SIP Signaling) and QCI1
(Voice Media) and for ViLTE QCI2 (Video Media). Video media can also be
QCI6 or QCI7.

The accessibility formulas for these QCIs are provided below:

Accessibility for SIP (QCI5):

100∗ ( pmRrcConnEstabAttMod+ pmRrcConnEstabAttMa−

pmRrcConnEstabSuccMod

Initial ERAB Establish

Equation SR [ % ] =for SIP (QCI5)
1 Accessibility

Accessibility for Voice Bearer (QCI1), Video Bearer (QCI2/6/7):

100∗pmErabEstabSuccAddedQci
Added ERAB Establish SR per QCI [ % ] =
pmErabEstabAttAddedQci

Equation 2 Accessibility for Voice Bearer QCI1, Video bearer (QCI2/6/7)

Drop in accessibility could be caused by a number of reasons including

capacity (overload, admission control, licensing) and faults (sleeping cell will
impact both MBB and VoLTE).
 Ericsson Internal
GUIDELINE 11 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Refer to Troubleshooting Accessibility Issues for details on troubleshooting

common accessibility issues.

4.2.2 VoLTE Retainability KPIs

Retainability measures how many of the VoLTE or ViLTE services provided

are not interrupted or ended prematurely.

The VoLTE Retainability KPIs are as follows:

Retainability for SIP (QCI 5):

100∗pmErabRelAbnormalEnbActQci+ pmEr
ERAB Retainability per QCI [ % ] =
pmErabRelNormallEnbActQci + pmErabRelAbnor
Equation 3 Retainability for SIP (QCI5)

Retainability for Voice Bearer (QCI1), Video Bearer (QCI2/6/7):

ERAB Retainability , QCI

[]
1 100∗pmErabRelAbnormalEnbQci+ pmErabRelAbnormalMm
s
=
pmServiceTimeDrbQci

Equation 4 Retainability for Voice Bearer (QCI1), Video Bearer (QQCI2/6/7)

For retainability related issues, refer to the troubleshooting guide that can be
found at Retainability Troubleshooting Guide.

4.2.3 VoLTE Integrity KPIs

Integrity measures the quality that the VoLTE or ViLTE services were
provided.

The VoLTE integrity KPIs are:

100∗pmVoip QualityUeUlOK
VoIP Integrity [ % ] =
pmVoip QualityUeUlOK + pmVoip QualityUeUlNok
Equation 5

Note: Up to L14A, the counters pmZtemporary3

100∗pmVoip and pmZtemporary5 are used
QualityRbUlOK
VoIP Integrity
in place of [pmVoipQualityRbUlOk
[Cell] % ]= and pmVoipQualityRbUlNok respectively.
pmVoip QualityRbUlOK + pmVoip QualityRbUlNok

100∗pmPdcpPktLostUlQci [1]
UL Packet Loss Ratio=
( pmPdcpPktLostUlQci[1]+ pmPdcpPktReceivedUl [1])
 Ericsson Internal
GUIDELINE 12 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

100∗pmPdcpPktDiscDlPelrUuQci [1]
DL Packet Loss Ratio=
pmPdcpPktDiscDlPelrUuQci [1]+ pmPdcpPktReceivedDlQci [1]

100∗pmPdcpPktPdbUlOkVoip
UL Packet Delay Budget Quality=
pmPdcpPktReceivedUlQci [1]
Refer to Integrity Troubleshooting Guide for issues related to Integrity.

Equation 6 VoLTE Integrity KPIs

Refer to Integrity Troubleshooting Guide for issues related to Integrity.

4.2.4 Mobility KPIs

Mobility KPIs include mobility success ratios of various types of handovers:

 Intra LTE Intra Frequency

 Intra LTE Inter frequency

 SRVCC to UTRAN

 SRVCC to GERAN

Mobility Success Ratio is given by:

Mobility Success Ratio [ % ] =100∗ ( PrepSucc

PrepAtt )∗(
ExeAtt )
ExeSucc

The PrepSucc, PrepAtt, ExeSucc and ExeAtt counters associated with each handover
types are listed in Table 2:

Handover type Counters

Intra-LTE intra-frequency  pmHoExeAttLteIntraF
 pmHoExeSuccLteIntraF
 Ericsson Internal
GUIDELINE 13 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 pmHoPrepAttLteIntraF
 pmHoPrepSuccLteIntraF
Intra-LTE inter-frequency  pmHoExeAttLteInterF
 pmHoExeSuccLteInterF
 pmHoPrepAttLteInterF
 pmHoPrepSuccLteInterF
SRVCC to UTRAN/GERAN  pmHoPrepAtt
 pmHoPrepAttSrvcc
 pmHoPrepSucc
 pmHoPrepSuccSrvcc
 pmHoExeAtt
 pmHoExeSucc
Voice Quality (MOS-LQOSWB Frame Erasure (Error) Rate (FER)
and Speech Path Delay) - Very good speech quality
the used Speech Codec shall be AMR-
Measured using Frame Error WB 12.65 and corresponding FER shall
rate or RTP packet loss rate, be <1% for the 95th percentile
speech path delay. - Good speech quality
the used Speech Codec shall ne AMR-
NB 12.2 and corresponding FER shall
be <1% for the 95th percentile
- Acceptable speech quality
the used Speech Codec shall be AMR-
NB 5.9 and corresponding FER shall be
<1% for the 95th percentile
RTP Packet Loss Rate
Speech Path Delay
The 5th percentile of the speech path
delay shall for a
- VoLTE<->VoLTE call be <225 ms
- VoLTE<->Break-in/out call be <125
ms (Note: only for the LTE half call)
SRVCC Handover Interruption The SRVCC HOIT shall under normal
Time operating network conditions be < 300
ms as 95th percentile

Table 2: Handover counters

Other KPIs could include the SRVCC Handover Interruption Time (control plane) as given
by the equation below:

SRVCC Handover Interruption Time T exe [ ms ]

¿ T Handovercomplete −T MobilityFromEUTRACommand

Refer to [11], section 5.5.2 Inter IRAT Handover in order to see the two messages
HandoverComplete and MobilityFromEUTRACommand are received, so as to calculate
the Handover Interruption Time (HOIT).
 Ericsson Internal
GUIDELINE 14 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Mobility issues could arise due to configuration issues, neighbour cell issues, handover
preparation failures due to resource issues, to name a few. See Mobility Troubleshooting
Guide for troubleshooting mobility issues.

4.2.5 Capacity KPIs

Network side VoLTE RAN Capacity Management can be performed using PM counters on
the eNodeB. Refer to [26] for capacity management metrics and techniques for LTE.

The recommended tool for RAN Capacity management is ENCP. It supports the metrics
outlined in the guideline above.

In addition to the metrics listed in these guidelines, the following metrics in Table 3 should
also be monitored. If the following metrics are not supported in ENCP then a generic PM
tool such as ITK may be used in the short term.

Metric Formula Description

All VoLTE UEs should have RoHC applied to them
so if this metric is significantly different to the
Average RoHC pmRohcCidSum / number of VoLTE (QCI1) erlangs then investigation
Context IDs pmRohcCidSamp is recommended. pmRohcCidSamp may be
replaced with the sampling rate to create the
cumulative sum rather than average across all cells.
100 * pmRohcEstabFailCid / This metric will trigger when there are not enough
RoHC Capacity
(pmErabEstabAttInitQci[1] + BBM resources to configure RoHC. Any non-zero
Failure Rates
pmErabEstabAttAddedQci[1]) instances of this should be investigated.
High levels of TTI bundling Ues will cause an
Average TTI
pmTtiBundlingUeSum / increase in resource usage for these users.
bundling Ues
pmTtiBundlingUeSamp Performing RF optimization can help reduce the
per cell
impact of this feature.
100 * pmVoipQualityUeUlOk / Percentage of Voip users that achieve 99% of UL
Voip User
(pmVoipQualityUeUlOk + packets inside PDB. A degradation in this metric can
Integrity
pmVoipQualityRbUeNok) indicate a capacity issue in the cell
100 * pmVoipQualityRbUlOk / Percentage of Voip calls that achieve 99% of UL
Voip Call
(pmVoipQualityRbUlOk + packets inside PDB. Degradation in this metric can
Integrity
pmVoipQualityRbUlNok) indicate a capacity issue for users in the cell.

Table 3: Capacity related KPIs

4.3 Aligning R-KPIs to S-KPIs

One of the most challenging tasks in dealing with VoLTE is in understanding the impact of
the RAN domain on metrics measuring user experience from the network side.

Examples:
 Ericsson Internal
GUIDELINE 15 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

1. In circuit switched voice networks such as WCDMA and GSM, a radio link failure will
trigger a call release so the user experienced drop rate is simple to estimate from
network side metrics, but in VoLTE, the radio may reconnect before the call is
released by the IMS so a radio drop is triggered but the user does not experience a
drop.

2. Metrics measured by counters in the IMS nodes such as VoLTE call retainability may
not show a granularity down to a cell level so locating cells with high numbers of
VoLTE dropped calls can be difficult.

The following process is intended to identify network side measured RAN metrics and
levels that indicate that the RAN is not causing degradation to VoLTE performance. It is
important to note that the process does not attempt to estimate VoLTE user experience
KPIs from RAN counters. This module is targeted at operators that would like to get a
better understanding of the impact of their RAN coverage and quality on VoLTE user
performance as measured from network metrics.

It is ideally recommended that this module is performed at the end of an Initial Tuning
service to utilize the existing drive testing results.

Figure 5: Data correlation overview

It should be noted that while this section discusses understanding the RAN domain KPIs,
a similar exercise can be performed to align core network R-KPIs with S-KPIs. Scope of
this module should be discussed with customer prior to starting service.
 Ericsson Internal
GUIDELINE 16 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Identify Define KPI Quantitatively

Collect and Define Data
Required and PI map R-KPIs to
Parse Data Correlation
Data Formulas S-KPIs

Figure 6: Data correlation process

4.3.1 Identify Required Data

Inputs:
 Performance Target Definition
Identify the S-KPIs that are required to be monitored and used to determine
acceptable performance. The KPI gateway is the recommended source for
updated information but recommended KPIs included Call Setup Success Ratio,
Call Completion Success Ratio and Handover Success Ratio

Outputs:
 List of Data for collection
This may include PM files from eNB, RBS and RBC, UE Trace or Cell Traces,
Probe interface data, device logs such as Nemo or TEMS and optionally non-RAN
statistics such as MTAS and MME.

4.3.2 Parse Collected Data

Inputs:
 List of Data for collection

Outputs:
 Database Storage of data
PM Statistics can be stored in tools such as ITK or ENIQ-Statistics. Device logs
can be stored in post processing tools such as NEMO Analyze or TIPP-L.
 Ericsson Internal
GUIDELINE 17 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

4.3.3 KPI Formula Definition

Inputs:
 List of Data for collection

Outputs:
 Formula definitions for all KPI metrics to be monitored
Reference documents include:
VoLTE E2E Performance Management - 4/195 83-HSC12034 Uen
Measuring VoLTE/SRVCC/CSFB Service Performance in Customer Networks -
1/192 12-HSC 120 34 Uen
(eNodeB) Key Performance Indicators - 37/1553-HSC 105 50/1-V1 Uen
Recommended Network side RAN metrics include: Initial E-RAB Establishment
Success Rate per QCI, Added E-RAB Establishment Success Rate per QCI, E-
RAB Retainability per QCI, DL and UL Packet Error Loss Rate per QCI, VoIP
Integrity, Mobility Success Rate, HARQ Voip Detection Rates, TTI bundling Ues,
PDCCH (CCE) utilization, Scheduling Entity utilization and Interference Power.

4.3.4 Data Correlation

Inputs:
 KPI Formula Definitions
 Stored Data

Outputs:
 Linking of S-KPI metrics measured from the UE with correlated metrics measured
from the network.
Some basic linking has been created in the CSI VoLTE E2E QOS Service KPI List.
Some examples are listed in Table 4:

S-KPI RAN KPI

Voice Quality DL Latency per QCI 1
Voice Quality DL / UL Packet Loss Rate per QCI 1
Speech Path Delay DL / UL Packet Loss Rate per QCI 1
Speech Path Delay VoIP Integrity
LTE Call Completion Rate E-RAB Retainability QCI 1

Table 4: Correlation between S-KPIs and R-KPIs

Additional linkages should be identified by comparing drive test recorded S-KPIs
with relevant VoLTE specific R-KPIs in the serving cell at the same time. Metrics
that are separated on a QCI level are much easier to map to the drive tester. It is
recommended that this activity is performed early in the life of the VoLTE network
 Ericsson Internal
GUIDELINE 18 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

so that there is minimal impact from commercial VoLTE users in the same cell.
Alternatively, low VoLTE call traffic cells or times could be targeted for drive test
measurements.

4.3.5 Quantitatively Map R-KPI to S-KPI

Inputs:
 KPI Formula Definitions
 Data Correlation Definitions

Outputs:
 Trigger values of relevant R-KPIs indicating unacceptable degradation of S-KPIs
Service Engineers should analyze the drive test logs and identify cell locations and
times when VoLTE performance was unacceptable or close to unacceptable. It is
strongly recommended to have previously performed a VoLTE E2E audit and use
a VoLTE End to End Log Correlation tool (such as E2E Analyzer see [25]) to
ensure that any performance degradation observed is not being caused by issues
outside the radio. During these cell times, the relevant PM counter VoLTE R-KPI
metrics should be measured and noted.
These R-KPI metrics represent RAN performance thresholds that need to be
maintained to ensure acceptable VoLTE performance. They can be used as a cost
effective method to ensure VoLTE performance is adequate over the RAN and can
be used as inputs into other Optimization modules.

4.4 Metrics for KPI Acceptance

The Acceptance Gateway VoLTE E2E Solution Acceptance page [22] lists the
recommended metrics to be used for KPIs and PIs during various stages of acceptance.
For optimization, the key KPIs that can be used for acceptance are listed in Figure 7
below.
 Ericsson Internal
GUIDELINE 19 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

In-service operation
Site acceptance

Golden cluster
environment
Controlled

Cluster
KPI area VoLTE KPI

Accessibility Call Setup Success Ratio VoLTE – VoLTE • • •

Accessibility Call Setup Success Ratio VoLTE – PSTN or CS PLMN • • • • •
Accessibility Call Setup Success Ratio – VoLTE Emergency Call • • •
Accessibility IMS Initial Registration Success Ratio • • • PI
Retainability Call Completion Success Ratio VoLTE – VoLTE • • •
Retainability Call Completion Success Ratio VoLTE – PSTN or CS PLMN • • • • •
Integrity Call Setup Time VoLTE – VoLTE • •
Integrity Call Setup Time VoLTE – PSTN or CS PLMN • •
Integrity Call Setup Time VoLTE – ICS (IMS Centralized Services) • •
Integrity Call Setup Time – VoLTE Emergency Call • •
Integrity IMS Initial Registration Time • •
Integrity Session Modification Success Ratio • • PI
Integrity Session Modification Time • •
Integrity Voice Quality • •
Integrity Video Quality • •
Integrity Conversation Start Delay • •
Mobility Intra-LTE Handover Success Ratio • • • • •
Mobility Intra-LTE Handover Media Interruption Time • •

Figure 7: Correlation between S-KPIs and R-KPIs

Note that depending on the extent of optimization service, it may be required to use data
collected from probes to show the improvements from the services.
 Ericsson Internal
GUIDELINE 20 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

5 Radio Coverage Optimization

5.1 Overview

Description:

The objective of the coverage optimization is to adjust the RF environment to improve

VoLTE performance based on network statistics that reflects the actual user experience.
This is achieved by identifying poor performing areas and providing recommendations
using VoLTE traffic as main driver. The recommendations consist of physical parameters
changes (i.e. tilts and azimuths changes). Ericsson Cell Optimizer (ECO) and RAN
analyzer (ERA) provide the framework required to perform this activity.

Scoping:

If Coverage Audit or Design phases were previously performed, it is very likely that one
ECO project already exists, in such case it is possible to reuse it by updating the physical
network configuration (tilts and azimuth), include new sites (if any) and collect recent OSS
data. Once this has been done, continue the process from 5.4.4.

Inputs:

 OSS configuration (CM) and performance data (PM)

 Cell-Traffic Recording data (CTR)

 Current network physical configuration

o Cell/eNB locations

o Antenna configuration per cell (including electrical, mechanical tilt and

azimuth)

o Maps for elevation and clutter

o Antenna Patterns

Outputs:

 Recommendations of changes for physical parameters – Tilts and Azimuths.

Tools:

 ECO – Ericsson Cell Optimizer

 Ericsson Internal
GUIDELINE 21 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 ERA – Ericsson RAN Analyzer and TPS – Trace Processing Server

 ODG – OSS Data Gateway

5.2 Coverage optimization process

The overview of the optimization process is shown below.

Figure 8 Radio optimization process

For additional information about OSS-based scaling and geolocation as weighting factor,
refer to 5.4.5.

5.3 VoLTE coverage requirements

One should always use the Link Budget as the basis for the required VoLTE
RF Coverage targets to meet the required performance criteria (Retainability,
MOS, etc).

With respect to field measurements observed during L12 software, VoLTE

coverage was considered poor when RSRP < -116dBm and/or RS-SINR < 2
dB (based on 12.65Kbps AMR-WB codec). It has been identified that below
these thresholds the quality perceived by the user degrades (i.e. lower MOS
scores, more frequent RTP gaps, more RRC Reestablishments) even though
this may not result in a dropped call. Re-establishment is usually not
perceived by the user, but may impact MOS or other voice quality metrics.
Therefore, the targets used were as per Table 9.

VoLTE Coverage Targets

SINR > 2 dB
 Ericsson Internal
GUIDELINE 22 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

RSRP > -116 dBm

Table 5: VoLTE Coverage Targets

Note: The above values were observed using L12 software. A number of enhancements
have occurred in the software since then so VoLTE does now perform more reliably in
poorer coverage environments.

Table 6: Revised VoLTE Coverage Targets

Temporary Revised
VoLTE Coverage Targets

SINR > 0 dB

RSRP > -120 dBm

Table 7: Revised VoLTE Coverage Targets

The Temporary Revised VoLTE Coverage Targets listed above have been chosen based
on experience with VoLTE deployments on more recent LRAN software (L16B). Please
note that the VoLTE quality is influenced by many factors including the mobility behavior of
both UEs in degraded RF environments so a single value of SINR and RSRP is likely to be
too simplistic. A more thorough investigation will be performed in early 2017.

5.4 Usage of Ericsson Cell Optimizer (ECO) and RAN Analyzer (ERA)

From a high level perspective ODG acts as the interface between OSS-RC and ECO/ERA.
ODG creates a database containing configuration (CM), performance (PM) and cell trace
recordings data (CTR). This database is later imported into ECO and ERA.

Using this database, ECO generates the required information to perform an exercise of
radio optimization that results in the optimized physical configuration for VoLTE and MBB
services.

TPS processes CTR data, generating geolocated raw information. This information can be
imported into ERA for advanced visualization and troubleshooting. Geolocated propagation
information per cell can be imported into ECO as well.
 Ericsson Internal
GUIDELINE 23 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 9 Solution architecture

A detailed description of this process is developed in the next sections. For proper
dimensioning and support of the HW required, create a request to SDT in SSR.

5.4.1 Cell-Traffic Recording (CTR) collection requirements

Prior to OSS data collection, follow below requirements:

 Activate feature “PM-Initiated UE Measurements”

o Create “PmUeMeasControl” and “ReportConfigEUtraIntraFreqPm” MOs.

o Configure “ReportConfigEUtraIntraFreqPm”:

 measSelectionEUtraPm: 0 (Periodic)

 maxReportCellsPm: 8 (up to 8 cells reported)

 reportAmountPm: 0 (Infinite)

 reportQuantityPm: 1 (both RSRP and RSRQ)

 reportIntervalPm: 5 (5120 ms)

 Activate feature “Enhanced Cell Id in Traces”

Refer to the User Manual for Ericsson RAN Analyzer in CPI portal for the most updated list
of mandatory events to be collected.

5.4.2 Building the OSS database (operdb) with ODG

ODG runs as a Windows service and can be accessed through the administrator portal by
logging into: http://localhost/portal using a web browser (Firefox/Chrome).
 Ericsson Internal
GUIDELINE 24 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 10 ODG interface

Select the corresponding vendor/technology and specify the format and location of the CM
and PM raw data as obtained from OSS-RC.

Important to note the requirement of creating a “ctr_data” folder under the same location of
“cm_data” and “pm_data” folders. ODG will search this folder looking for CTR data
containing Periodic Measurements (.bin.gz).

Figure 11 Location of CM and PM files

Once started, ODG provides the user with a log window to monitor the progress of the
operdb creation process.
 Ericsson Internal
GUIDELINE 25 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 12 ODG Log view

Once ODG finalizes, it is necessary to update the recently created operdb with the location
and azimuth of each cell that is part of the scope. This is accomplished by importing the
“sector location” file. A template of this file can be exported and re-imported once it has
been updated using the corresponding interface of ODG.

Figure 13 Sector Location example

Sector location update is a must for the processing of CTR data with TPS (Geolocation).

Figure 14 Sector Location export/import interface

 Ericsson Internal
GUIDELINE 26 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

5.4.3 Building an ECO project

First step is to import the physical network topology. This information is usually available
as an export of a planning tool or as a plain text file. For a list of supported planning tools,
refer to the User Manual for Ericsson Cell Optimizer in CPI portal.

ECO provides a generic interface to import a .csv file containing the physical database.
Following fields are mandatory:

 Sector ID, Site ID, Latitude, Longitude, Azimuth, Mechanical Tilt, Antenna Name,
Antenna Height, Ground Elevation, ERP(dBm), Band, Technology.

Figure 15 Generic physical importer interface – field mapping tab

After importing physical data, next step is to import antenna patterns.

One antenna model may contain multiple antenna patterns. If the antenna model has
multiple electrical tilts (ET), it is expected to have one pattern for each individual value of
ET.

The field “Antenna Name” (in the physical .csv file) describe the current antenna pattern
configured in every cell. Usually the antenna pattern name contains the ET value.
 Ericsson Internal
GUIDELINE 27 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 16 Interface to import antenna patterns and supported formats

ECO will associate the corresponding antenna pattern of every cell based on the field
“Antenna Name”, for this reason it is recommended that the antenna pattern name and this
field match each other.

In order to be able to optimize ET, it is necessary to import the antenna family mapping.
There will be one antenna family for each antenna model as shown below:

Figure 17 Example of antenna family mapping file and interface to import it

One family contains all the patterns (available ET) of that specific antenna model. At
optimization time, ECO will evaluate among the available patterns for each model
associated to each cell and will determine what is the most appropriate option, given the
constrains configured by the user.

A functionality to visualize antenna information as horizontal and vertical pattern is

available.
 Ericsson Internal
GUIDELINE 28 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 18 Antenna manager

After antenna data, next step is the importation of the clutter and elevation maps.

The resolution of the ECO project is given by the resolution of these maps. The
recommended resolution for these maps ranges from 10 to 30m (Urban) and from 30 to
50m (Suburban areas). The higher the resolution of the maps, the higher the memory
usage and longer computation times.

Figure 19 Interface to import clutter/elevation maps and supported formats

The clutter map defines the morphologies of the area under analysis. Specific coverage
and quality thresholds can be specified for each morphology.
 Ericsson Internal
GUIDELINE 29 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 20 Clutter attributes

It is in “Clutter attributes” where the thresholds recommended in 5.3 should be specified.

Figure 21 Example of clutter and elevation maps imported in ECO

5.4.4 Importing the operdb into the ECO project

To complete the creation of the ECO project is necessary to import the previously created
operdb. This will embed the configuration parameters, performance and cell trace statistics
for each cell in the project.

Figure 22 Operdb importer interface

Upon importation the user must specify:

 Name and location of the operdb

 Aggregation method (in case of multiple operdbs to be imported)

 Dates of PM to be extracted and the busy period for computation of load-dependent

KPIs
 Ericsson Internal
GUIDELINE 30 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Filtering criteria for C/I relations

Figure 23 OSS ECO importer

Once the importation task finalizes, a consistency report is shown. The information
presented is classified in two groups:

 Cells with data available in the operdb but not existing in the project

 Cell existing in the project but not available in the operdb.

The user should act accordingly to harmonize both source of information as corresponds.

Imported information is available at GUI level (under the layer manager) and in OLAP
tables.
 Ericsson Internal
GUIDELINE 31 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 24 ECO GUI interface – multiple layers available in left panel

Periodic measurements reported in the CTR data and previously processed by ODG are
now available in ECO. The information is presented in form of RSRP distribution and C2I
relations on a per cell basis.

Figure 25 RSRP distribution

 Ericsson Internal
GUIDELINE 32 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 26 C/I relations

KPIs relevant for the RF optimization exercise are available as well (i.e. mobility,
throughput performance, DL volume, etc.)

Figure 27 OSS KPIs computed from the operdb by ECO

By double clicking any cell in the GUI, the configuration parameters for that cell are shown
in the “Edit Sector” window.
 Ericsson Internal
GUIDELINE 33 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 28 Edit Sector window

Edit Sector contains multiple tabs extensively used throughout the process:

 Physical: latitude, longitude, azimuth, antenna pattern among others.

 ACP: Optimizable physical parameters, ranges and steps are defined here.

 LTE: physical layer configuration parameters.

5.4.5 Propagation information in Cell Optimizer

In the Optimization phase, the recommended approach is to use the OSS-based scaling
feature available in ECO. This methodology consists of translating the coverage and
overlapping information extracted from CTR, into per cell propagation information. Below
some characteristics/requirements of OSS-base scaling:

 Suitable for different scenarios, ranging from urban to rural morphologies

 Scoping reference: 1000 cells @ 4.5 weeks (1 service engineer fully allocated)

 Data collection requirements:

o PM, min 18h/day (excluding MW)

 Ericsson Internal
GUIDELINE 34 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

o CTR, min 4h in busy periods @ 20% UE fraction, during 5 working days.

During a regular optimization exercise, the proposal of changes will be driven by the
distribution of the VoLTE users (traffic map) and the morphology underlying (clutter map).
If geolocated information is available, this might be used as an additional weighting factor
in the optimizer. See 5.4.7 for information on how to process CTR data with ERA/TPS and
5.4.10 for guidance on how to use this information into ECO.

5.4.6 OSS-based scaling

After building a base project and having imported the operdb, the next step is the
generation of internal propagation data. These generic predictions are modified at a later
stage by including the RSRP distribution and the C2I relations extracted from the CTR
data. The resulting propagation information of this process is called “scaled predictions”
and physical recommendations are proposed based on them.

Figure 29 Generate internal propagation data

Figure 30 Internal default predictions – RSRP

Next step is the generation of a demand grid (traffic map) that represents the distribution of
the VoLTE users across the network. ECO offers a functionality to perform this task.
 Ericsson Internal
GUIDELINE 35 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 31 Traffic map functionality

Selecting “Sector specific traffic” and pointing to a .csv file following the format shown
below, ECO will distribute the traffic in the best server area of each cell considering the
timing advanced (TA) imported from the operdb and the weight assigned by the user to
each morphology in the clutter attributes window (see Figure 20 Clutter attributes).

Figure 32 Example of external file for traffic generation

This functionality allows to create a voice traffic demands based actual VoLTE traffic per
cell.

The demand grid is unitless and acts as a weighting factor for the optimizer. The higher the
value of traffic allocated to one pixel, the more influence that pixel will have in the
optimization cost function.
 Ericsson Internal
GUIDELINE 36 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 33 Example of traffic map generated with ECO

After traffic map creation, it is necessary to generate the VoLTE service profile, this is done
by using the “LTE simulation profile” interface. Its main tabs are:

 UE type: definition of max UE power, number of RX antennas, additional losses

and association of link adaptation mapping table

 Service type: minimum/requested rates and activity factor

 Simulation profile: allocation of traffic map previously created and priority definition
between services (VoLTE and MBB)

Figure 34 Simulation profile

The simulation profile characterization is used by other ECO modules (i.e. montecarlo
simulator). Specifically, for current use case, just the information in tab “Simulation profile”
is relevant, that is the allocation of the voice traffic map to the simulation profile and the
priority definition (weight field) when considering both VoLTE and MBB.
 Ericsson Internal
GUIDELINE 37 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

As previously commented, the scaling process consist of adapting the internal default
predictions by applying the RSRP distribution (adjusting the coverage in best server
areas), C/I interference relations (adjusting overlapping between cells) and the VoLTE
demand grid (where the users are located). To perform this, the user selects “Adjust
coverage” and “Adjust interference” in the window below.

Figure 35 OSS scaling menu

Once the process finishes successfully, the source of propagation information to be used
changes from “Predictions” to “Combined” in the project options window. From this point all
the decisions taken by ECO will be based in the adjusted propagation information.

Figure 36 Project options window

 Ericsson Internal
GUIDELINE 38 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

5.4.7 Geolocated information

As commented previously, geolocated information can be used as an additional weighting

factor in ECO, this requires the previous processing of CTR data with ERA/TPS. Start by
defining the TPS controller and configuring the TPS processors. The controller manages
the requests created by the user and distributes the requests among the available
processors.

Figure 37 Controller configuration

Figure 38 Processor configuration

Define the location of the CTR raw data (.bin.gz). Local folder or FTP services are
available.
 Ericsson Internal
GUIDELINE 39 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 39 Trace provider

Define the connection to the operdb to be used for processing. Remember to have
updated previously the sector location file in ODG interface.

Figure 40 ODG Connection

Define the type of traces to process (CTR) and link to the previous ODG connection
created. This is called network connection and will be required when creating the TPS
request.
 Ericsson Internal
GUIDELINE 40 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 41 Network editor

Define the ECO provider. This is a basic ECO project with just physical and clutter map
(predictions are optional). It provides a correction mechanism for TPS, so the geolocated
samples are slightly relocated based on the morphology of the clutter map. The higher the
weight of the clutter type, the higher the probability of receiving a sample. Usage of this
option avoids geolocated samples in water bodies if their clutter weight is set to 0.

Figure 42 ECO provider

ECO provider gives control over the resolution of geolocated maps. If used, the resulting
maps have the same resolution of the ECO project. Without this option the default
resolution of the maps obtained with TPS is ~70m. Usage of ECO provider increments
significantly the processing time of TPS requests. Refer to the User Manual for Ericsson
RAN Analyzer in CPI portal for detailed information on which maps have upgraded
resolution.
 Ericsson Internal
GUIDELINE 41 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Once the configuration of TPS is completed, it is possible to schedule a request for CTR
processing.

Figure 43 TPS process request

 Servers: define the ODG connection to be used.

 Data sources: define the network connection, trace provider and ECO provider
previously configured.

 Schedule: define the range of dates to be processed and the recurrence of

processing this request.

 Reports: select map-related reports. Refer to the User Manual for Ericsson RAN
Analyzer in CPI portal for more details.

 Options: define request name, priority and dominance threshold window (6dB
recommended for LTE)

After the request is processed by TPS, it can be imported into ERA. First step is to connect
ERA to the TPS controller by pointing to its IP address:
 Ericsson Internal
GUIDELINE 42 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 44 Defining TPS controller in ERA

Create a “Call Traces” project in ERA and import the data processed by TPS.

Figure 45 Creating an ERA project – scheduling importation task

Upon importation, select the TPS request previously processed.

 Ericsson Internal
GUIDELINE 43 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 46 Exporting virtual drive

Once the importation finishes, multiple layers of geolocated information become available.
These can be exported in .csv or MapInfo format by right-clicking in the corresponding
layer.

Figure 47 CQI geolocated map

 Ericsson Internal
GUIDELINE 44 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Refer to section 5.4.10 for guidance on how to import generic geolocated information to be
used as weighting for the optimization.

Figure 48 Bad dominance geolocated map – number of servers reported

5.4.8 RF assessment with ECO

Define a polygon around the area of evaluation. The recommendations proposed will be
based on the performance within this polygon.
 Ericsson Internal
GUIDELINE 45 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 49 Delimiting the area of analysis with polygons

To evaluate what is the level of VoLTE coverage the network may provide with current
configuration, set the recommended thresholds (see 5.3) in the clutter attributes and then
run the statistics report.

Figure 50 Statistic report settings

The results are given as GIS layers and tabular reports (tables). Each table presents the
information as histogram or CDF. The values previously configured are for reporting
purposes only, they define the starting point of the distribution, steps and number of bins.
 Ericsson Internal
GUIDELINE 46 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 51 Tabular statistics reports

ECO evaluates every pixel inside the polygon to determine whether the thresholds
requested in the clutter attributes are met or not. The distributions summarize the results
by showing the % of area or % of traffic below one specific threshold (CDF) or within one
bin (histogram).

Available reports are:

 Run information: global polygon selected and service profile used

 RSRP coverage summary, histogram and CDF

 Dominance coverage summary – number of servers, histogram and CDF

 RSRQ coverage summary, histogram and CDF

 Combined RSRP and RSRQ coverage

 DL/UL Throughput, histogram and CDF

 DL/UL SINR, histogram and CDF

 G-factor, histogram and CDF

 Sector coverage with stats for RSRP coverage at clutter level

Some of the GIS layers from statistics reports are on/off type maps, representing if every
pixel is above or below the specific threshold defined in the clutter attributes.
 Ericsson Internal
GUIDELINE 47 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 52 RSRP coverage

Others contain multiple values (i.e. Dominance and DL SINR)

Figure 53 Dominance
 Ericsson Internal
GUIDELINE 48 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 54 DL SINR

All of the GIS layers can have their color key edited by double clicking on it.

5.4.9 Generic rasters

A “generic raster” is a mechanism to import information at pixel level into ECO and
visualize it in the GUI. The generic rasters have no influence in the optimizer results.
These are layers imported for visualization purposes only. Any information imported, is
binned in order to be rendered in the same resolution than the ECO project.

Figure 55 Generic grid importer

Different aggregation methods are available upon importation. Supported formats are .grd,
vertical mapper (MapInfo) and .csv. Below an example of a .csv file template.
 Ericsson Internal
GUIDELINE 49 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 56 Generic raster – CSV format template

Once imported, the generic grid is available in the layer manager

Figure 57 Example of generic raster

Any generic grid can be exported back, by right clicking on it. The resulting file will contain
the latitude and longitude (binned according to the ECO project resolution) and the value
for each pixel in the layer selected.

Figure 58 Export options generic grid – right click

 Ericsson Internal
GUIDELINE 50 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

This feature is useful to geo-reference under the same resolution (binning) information
coming from different sources (i.e. geolocated layers, drive-test information, thematic maps
shared by the customer, etc.).

5.4.10 Additional weighting mechanism

Apart from clutter weighting and traffic maps, there is an additional mechanism to prioritize
more some areas than others. Any grid imported under this option will affect the result of
the optimizer if the corresponding flag is activated in the optimizer window (scale by
weight).

Figure 59 Weight raster map importer

Supported formats are .grd and .csv files (i.e. generic layers exported back after being
binned, see 5.4.9). The data imported as weighting map cannot have negative values,
ECO provides the option to truncate those pixels to 0 or add an offset to the entire map
equal to the absolute value of the minimum negative detected.

This feature enables the usage of external information as an additional weighting factor for
the optimizer. One example may consist of using UE analytics results to focus the
optimization in specific areas (i.e. geolocated RLF due to coverage as identified by
xTrace). Refer to VoLTE Tuning technical guideline for more information about xTrace
capabilities.

5.4.11 Physical recommendations

After the assessment performed in 5.4.8, the optimizer can be used to improve the VoLTE
coverage the network may offer, this is accomplished by the proposal of tilts and azimuth
changes that maximizes the area and traffic above the coverage criteria previously
defined.

ECO provides a functionality to create groups of cells. The usage of groups facilitates the
filtering of cells in tabular reports, visualization of cells by specific characteristics in the GIS
and the configuration of the parameters to be optimized.
 Ericsson Internal
GUIDELINE 51 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 60 Groups management

One cell may belong only to one “group name” within a given “group class” but may belong
to as many “group classes” as required.

Figure 61 Template for importing groups

The cells are assigned to groups by importing a .csv file with the format shown above or
can be directly allocated in Edit Sector window if the group already exists.

Parameters to be optimized are configured at cell level. Define the min, max and the step
in each of the parameters set as optimizable. Ranges can be defined as “relative” (i.e. in
regard to current value) or “absolute”. The optimizer will evaluate among the different
options available which one minimize the optimization cost function. The associated cost to
each type of change is defined in this window as “$ per change”.
 Ericsson Internal
GUIDELINE 52 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 62 Setting the optimizer at cell level

In the optimizer window, select the additional features applicable to specific parameters (if
necessary). Examples of these features:

 Overshooting rank downtilting – overshooting cells receive additional downtilt.

 Schedule of changes – changes provided in the most cost-efficient way for

selection and implementation. Those providing more gain are rank first in the list of
changes.

Figure 63 Optimizer window – ACP and Objective tabs

 Ericsson Internal
GUIDELINE 53 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

“Objective” tab defines the weight for the different objectives evaluated by ECO. These
objectives are related to thresholds defined in the clutter attributes window:

 Coverage: RSRP threshold

 Quality: RSRQ threshold

 Dominance: Number of servers within the Dominance window

 Traffic quality: DL/UL SINR

This tab contains the scaling options, select among the available mechanisms to weight
the optimization function (any combination of Weight, Clutter and/or Traffic map).

Figure 64 Optimizer window – Advanced settings

Additional settings in other tabs include:

 Number of iterations to run

 Autoweight adjustment: during optimization time, the optimizer automatically

adjusts the weights per objective specified by the user.

 Sampling: recommended highest possible, though ECO will compute the max
possible based on available memory and the polygon size.

Before running the optimizer, create a copy of current configuration. ECO projects are
structured in configurations; each one represents a different RF design. When building the
project initially, the active configuration is “Baseline”. The user may create as many
configurations as required by copying the Baseline configuration.
 Ericsson Internal
GUIDELINE 54 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 65 ECO project structure

Open the new configuration and run the optimizer on it.

Figure 66 Optimization progress

The minimization of the cost function and number of changes proposed are shown in this
window. The optimizer stops after having executed the specified number of iterations or
reaching convergence, whatever occurs first.

If “schedule of changes” was selected while configuring the optimizer, after clicking
“commit changes” ECO will show a ranked list with those changes providing more gain
located at the beginning of the list. Select the cumulative changes to be applied based on
the percentage of gain desired. Recommended values are around 80-90% of “Run total
cost”.
 Ericsson Internal
GUIDELINE 55 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 67 Schedule of changes

The final list of changes is available at OLAP Table > ACP > Optimization Reports.

Figure 68 Optimization reports

Using the process described in 5.4.8, it is possible to evaluate the level of VoLTE service
offered by the “Optimized” configuration. ECO has the functionality of “Delta reports”, this
executes the comparison of spatial views and tabular reports between Baseline and
Optimized configurations. Prerequisite to run delta reports is having run previously
statistics reports in both configurations. Examples of the delta reports are shown below:
 Ericsson Internal
GUIDELINE 56 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 69 Delta report at cell level

Figure 70 Delta report at area level

 Ericsson Internal
GUIDELINE 57 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

5.4.11.1 VoLTE coverage holes (OPTIONAL)

ECO features a functionality to identify areas where VoLTE traffic is being

served poorly. The result is a “heat map” or “search rings” that may be used
as reference for the deployment of new macro eNBs.

To run this functionality is necessary to have an ECO project as describe in

section 5.4.8.

Radius parameter is the expected coverage distance of a new cell if deployed

in the area of analysis. Use as reference 50% of current average intersite
distance of the network topology

Figure 71 Service hole menu

 Based on Traffic map (recommended for VoLTE design – coverage oriented)

Using a sliding window with size of Radius, ECO will look for the unsatisfied traffic
in every pixel. Unsatisfied traffic is the voice traffic in a pixel that do not meet the
coverage criteria (RSRP) requested in the clutter attributes window. The sum of the
unsatisfied traffic is allocated to the pixel where there sliding window is currently
center.

After finalizing the entire area, the value of every pixel represents the unsatisfied
traffic that would be covered if a new eNB is placed in the location of that pixel.

 Based on Utilization map (capacity oriented)

 Ericsson Internal
GUIDELINE 58 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The “Utilization DL” KPI is distributed in the best server area and covered pixels of
each cell, proportionally to the traffic map and inversely to the spectral efficiency.

Using the “Relative utilization load” (user-defined), it is computed the actual

utilization of each cell, and then a sliding window center in every pixel aggregates
the exceeding of utilization that fits inside the Radius.

After finalizing the entire area, the value of every pixel represents the unsatisfied
capacity that requires to be served by adding more capacity to current best server
or deploying new capacity solutions in the area (i.e. small cells).

Below an example of a coverage hole map generated with Traffic map option.
In the north-east and south-west area are observed potential locations to
deploy new eNBs to improve coverage.

Figure 72 Example of coverage hole map

For additional details, refer to User Manual for Ericsson Cell Optimizer in CPI
portal.
 Ericsson Internal
GUIDELINE 59 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

6 Mobility Optimization

6.1 Overview

Description:

The objective of the Mobility Optimization module is to tune VoLTE mobility feature
performance and SRVCC handovers performance. The result of conducting this module is
improved end-user voice quality through reduced HO failures and lower IFHO/IRAT
attempts.

Inputs:
 Mobility design strategy
 VoLTE network performance (output from VoLTE SKPI benchmarking module)
 OSS Data – Configuration Management (CM): OSS data containing all RAN OSS
configuration data (parameters)
 OSS Data – Performance Management (PM): OSS data containing all
performance management data (counters) for KPI analysis.

Outputs:
 VoLTE inter-frequency / intra-frequency handover parameter recommendations
 SRVCC parameter recommendations

Tools:
 Performance monitoring tool: ITK / ESPA / KPI monitoring tool from customer

6.2 VoLTE intra-Frequency and inter-frequency optimization

VoLTE voice quality can be impacted significantly from inappropriate mobility behavior as
the call holding time in VoLTE is typically a lot longer than MBB. Furthermore, typically a
drop call in voice has a bigger impact on end user experience than a drop in a data
session. Therefore, optimization of VoLTE mobility is very important.

6.2.1 Optimization Trial Examples

The following VoLTE mobility activities have been performed in VoLTE networks and
shown to improve the VoLTE performance in some scenarios:

 Automated Mobility Optimization (AMO)

 Ericsson Internal
GUIDELINE 60 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Inter-frequency HO trigger A5 to A3 and RSRQ filter coefficient optimization

 SRVCC and intra-frequency mobility optimization (see section 6.3.3.2)

6.2.1.1 Automated mobility optimization

The optional feature Automated Mobility Optimization allows operators to more efficiently
tune handover parameters on a relation level. While this feature may have been optimized
for MBB LTE, VoLTE traffic profiles are different to MBB and can result in larger numbers
of handovers per call due to the increased call duration.

The following parameters are recommended for optimization when using AMO:

Parameter Description
hoOptStatTime The operational cycle (Statistic Period) of the handover optimization
function. Decreasing this value will speed up the frequency of the
algorithm, increasing the frequency of the parameter changes.
hoOptStatNum The minimum number of handovers that must occur in the operational
cycle for the period to be considered for parameter changes.

hoOptAdjThresholdAbs Minimum number of failed handovers required to trigger parameter

changes. Decreasing this number increases the likelihood that the
automatic optimization function will be triggered.
cioUpperLimitAdjBySo Maximum increase allowed to be imposed on cellIndividualOffsetEUtran
n by the feature.

cioLowerLimitAdjBySo Maximum decrease allowed to be imposed on cellIndividualOffsetEUtran

n by the feature

The following counters can be monitored:

Counter KPI formula Description

Too_Early_HO_INTRA_PC 100 * pmHoTooEarlyIntraF / Percentage of Intra
pmHoExeAttLteIntraF frequency handovers
deemed “Too Early”
Too_Early_HO_INTER_PC 100 * pmHoTooEarlyInterF / Percentage of Inter
pmHoExeAttLteInterF frequency handovers
deemed “Too Early”
Too_Late_HO_INTRA_PC 100 * pmHoTooLateIntraF / Percentage of Intra
pmHoPrepAttLteIntraF frequency handovers
deemed “Too Late”
Too_Late_HO_INTER_PC 100 * pmHoTooLateInterF / Percentage of Inter
pmHoPrepAttLteInterF frequency handovers
deemed “Too Late”
Wrong_Cell_HO_INTRA_PC 100 * pmHoWrongCellIntraF / Percentage of Intra
pmHoExeAttLteIntraF frequency handovers
deemed “Wrong Cell”
Wrong_Cell_HO_INTER_PC 100 * pmHoWrongCellInterF / Percentage of Inter
pmHoExeAttLteInterF frequency handovers
 Ericsson Internal
GUIDELINE 61 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

deemed “Wrong Cell”

Wrong_Cell_REEST_HO_INTRA_P 100 * Percentage of Intra
C pmHoWrongCellReestIntraF / frequency handovers
pmHoExeAttLteIntraF deemed “Wrong Cell Re-
establishment Occurred”
Wrong_Cell_REEST_HO_INTER_P 100 * Percentage of Inter
C pmHoWrongCellReestInterF / frequency handovers
pmHoExeAttLteInterF deemed “Wrong Cell Re-
establishment Occurred”
HO_Osc_INTRA_PC 100 * pmHoOscIntraF / Percentage of Intra
pmHoExeAttLteIntraF frequency handovers
deemed “Oscillating”
HO_Osc_INTER_PC 100 * pmHoOscInterF / Percentage of Inter
pmHoExeAttLteInterF frequency handovers
deemed “Oscillating”.
Oscillating Inter Frequency
handovers are a common
cause of voice quality
degradation in VoLTE and
should be avoided.

Engineers should try to reduce instances of the above KPIs.

Trial parameter setting:

Parameter Description Baseline Trial Trial
value iteration #1 iteration #2
AutomatedMobilityOptimization Automated Mobility Deactivated Activated Activated
Optimization feature.
hoOptStatTime The operational cycle of 24 24 24
the handover optimization
function.
hoOptStatNum The minimal number of 200 32767 200
handovers required by the
handover optimization
function before adjusting
handover parameters.

Trial results:
 The result was a reduction in HO execution success rate
 However, there was a reduction in overall HO execution rate as the too early, too
late and wrong cell HO attempts reduced
 There was no gain in VoLTE DCR but a reduction in unnecessary HO attempts
 Ericsson Internal
GUIDELINE 62 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 73: VoLTE drop call rate

Figure 74: HO execution success rate

Figure 75: Unnecessary HO attempts (too early, too late and wrong cell HO attempts)
 Ericsson Internal
GUIDELINE 63 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

6.2.1.2 Inter-frequency HO trigger A5 to A3 and RSRQ filter coefficient

optimization

There are two objectives for this optimization trial. Firstly, by using the event A3 instead of
A5 for inter-frequency handovers users in poor radio conditions can be handed over to
neighboring cells more dynamically, hence avoiding voice packet loss. A comparison
between the event A3 and A5 is illustrated in Figure 76.

Clearly, even if the target cell’s RSRP / RSRQ is better than the source cell’s RSRP /
RSRQ, the A5 target threshold still needs to be met before the handover is triggered. As a
result, VoLTE users might be kept in poor radio conditions for a longer period of time.
Contrary to this, the inter-frequency handover based on the A3 event is triggered when the
target cell’s radio conditions are better than the one of the serving cell, i.e. meeting the
a3Offset + hysteresisA3 threshold in the search zone. However, there are also some
drawbacks coming along with the A3 event. On the one hand, an increase in inter-
frequency ping-pong handovers might be observed because the feature “UE level HO
Oscillation Minimization” does not support A3 triggered inter-frequency handover. On the
other hand, the traffic balance between different frequency bands could be impacted,
affecting capacity and performance, because more hand-overs can be expected with the
A3 event as shown in Figure 77.

The second objective of this trial is improving the RSRQ based handover triggering by
optimizing the filter coefficient. In this regard, all connected mode UE measurements are
filtered before event evaluation and subsequent measurement reporting. The filter is a
simple exponential filter with a factor of 1/2^(k/4), where k is the filter coefficient.

Figure 76: Comparison between A3 and A5 event

 Ericsson Internal
GUIDELINE 64 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 77: Estimation of HO intensity increase by using the A3 event based on field test data

As an example, a value of k=4 corresponds to a weighting of 1/2^(4/4) = 0.5, that is, the
next filtered value is the average of the new measurement and the last filtered value. This
is also illustrated in Figure 78. By reducing the filter coefficient, HO triggering will be faster
and may lead to improved VoLTE audio gap performance because VoLTE users are not
kept for a long period in poor radio conditions.

Trial parameter setting:

Parameter Baseline Trial value

Description
value
a1a2SearchThresholdRsrq The RSRQ threshold value for events -120 -120
A1Search and A2Search
hysteresisA1A2SearchRsrq The hysteresis value for RSRQ in events 10 10
A1Search and A2Search measurements
a1a2SearchThresholdRsrp The RSRP threshold value for events -118 -118
A1Search and A2Search

hysteresisA1A2SearchRsrp The hysteresis value for RSRP in events 20 20

A1Search and A2Search measurements
a2ThresholdRsrqSecOffset QCI dependent offset for the absolute 30 30
(QCI1) a2ThresholdRsrqSec threshold. If the Mobility
Control at Poor Coverage feature is enabled,
"a1a2SearchThresholdRsrq" replaces
"a1ThresholdRsrqSec"
a2ThresholdRsrpPrimOffse QCI dependent offset for the absolute B1/B8=6, B1/B8=6,
t (QCI1) a2ThresholdRsrpPrim threshold. If the B3=8 B3=8
Mobility Control at Poor Coverage feature is
enabled, "a1a2SearchThresholdRsrp"
replaces "a2ThresholdRsrpPrim"
interFreqMeasType The type of event based measurements on EVENT_A5 EVENT_A3
other LTE frequencies
a3offset Offset value for event A3 10 10

hysteresisA3 Hysteresis value for event A3 10 10

 Ericsson Internal
GUIDELINE 65 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

timeToTriggerA3 Time-to-trigger value for event A3 128ms 128ms

filterCoefficientEUtraRsrq The filtering coefficient for E-UTRA using the 11 4

measured quantity RSRQ. The coefficient
filters measurements before event evaluation

Figure 78: Impact of different filter coefficient values

Trial results:

 Downlink and uplink PDCP packet loss rate decreased, hence less voice packets
are lost in general which improves voice quality
 Number of inter-frequency HOs increased further after implementation of the new
filter coefficient value and downlink PDCP packet loss rate decreased further
 Poor downlink RF samples reduced, i.e. CQI 0-5 rate decreased
 Number of SRVCC handover attempts reduced slightly
 Improvement in silent experience and number of UL audio gaps
 Processor load increased slightly during busy hour for high traffic nodes due to
increased handover attempts
 Number of handover ping-pongs increased significantly because of the more
dynamic handover handling based on the A3 event as well as because currently
feature “UE level HO Oscillation Minimization” does not support A3 triggered inter-
frequency handover
 Traffic balance between the three different LTE frequency bands was slightly
impacted, thus reducing slightly overall capacity. Therefore, further fine-tuning of
inter-frequency handover settings is required
Avg. DL PDCP packet loss

QCI1 [%] Ericsson Internal

GUIDELINE 66 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Wednesday Thursday Friday Monday Tuesday TC

Baseline

0.2 A3 IFHO opt.

Filter coeff. opt.

0.1

Difference in avg. UL
PDCP packet loss

QCI1 [%] 0.0

0%

-20%
-30.02% -29.32%
packet loss QCI1 [%]
Avg. UL PDCP
-40%
-45.13%
-48.64% -49.32%

9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21
Time Time Time Time Time

Figure 79: QCI1 DL PDCP packet loss rate

Wednesday Thursday Friday Monday Tuesday TC

0.15 Baseline
A3 IFHO opt.
0.10 Filter coeff. opt.

Difference in CQI 0.05

0-5 rate [%]
0.00
0%

-9.19%
-10%
CQI 0-5 rate [%]
-18.06% -17.99%
-20% -22.71% -20.69%

9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21
Time Time Time Time Time

Figure 80: QCI1 UL PDCP packet loss rate

Wednesday Thursday Friday Monday Tuesday TC

Baseline
0.10 A3 IFHO opt.
Filter coeff. opt.
0.05

0.00

20%

0%
-9.81% -12.05% -12.00%
-20.90%
-20% -21.61%
9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21
Time Time Time Time Time

Figure 81: CQI 0-5 rate

 Ericsson Internal
per experience
Silent VoLTE user
GUIDELINE 67 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

[ms]
Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Wednesday Thursday Friday Monday Tuesday TC

Baseline
40 A3 IFHO opt.
Filter coeff. opt.
20
Estimated HO ping-pong rate [%]
0

0%
-30.0% -26.2% -29.8%
-33.2%

-50%
-77.6%

9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21 9 12 15 18 21
Time Time Time Time Time

Figure 82: Silent experience per VoLTE user

Band TC
B1 B3 B8 Baseline
20 A3 IFHO opt.
17.15

15
11.57
10

5
2.10
0

Figure 83: Estimated handover ping-pong rate

6.3 SRVCC Optimization

In general, SRVCC optimization can have two main strategies as summarized in the
following sections.

6.3.1 Option 1 – Improve SRVCC performance

This involves pushing VoLTE calls down to 2G/3G earlier to ensure a good user
experience is achieved by minimizing potential drops or packet loss. This is useful if the
LTE layer has a patchy coverage or is congested, particularly if AMR-WB is already
supported on the underlying WCDMA network as illustrated in Figure 84.
 Ericsson Internal
GUIDELINE 68 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 84: Option 1 – Trigger earlier HO to GSM/WCDMA

SRVCC can be optimized by either:

 B2 optimization: Option 1 is achieved by using larger values of
b2Threshold1[RSRP|RSRQ]UtraOffset for QCI=5 and QCI=1. Note that because
active VoLTE calls tend to have a poorer link budget than MBB calls because of
the additional body loss, it may be beneficial to use an offset on QCI=5 to force a
VoLTE capable UE to WCDMA/GSM before making a call rather than have
SRVCC performed at call setup when the additional body loss is added to the link
budget.
 A2 optimization: Another version of Option 1 involves using blind handover to
GSM/WCDMA using the A2 Critical threshold. This technique can be used when
the underlying WCDMA/GSM cell fully covers the LTE cell. The benefit of this
version in addition to Option 2 is that the A2 critical threshold acts as a safety net if
the parameter settings for maintaining a VoLTE call on LTE are a bit too
aggressive for certain environments.

6.3.2 Option 2 - Maintain Voice on VoLTE

Try to maintain VoLTE calls on LTE and minimize SRVCC events. This is useful when you
have a good coverage layer on VoLTE or if the underlying 2G/3G layer is patchy or
congested.

Figure 85: Option 2 – Maintain VoLTE call on LTE

 Ericsson Internal
GUIDELINE 69 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Option 2 is achieved by not using any QCI specific offsets for the B2 event, but may also
require additional activities such as up tilting of antennas as well as the activation and
optimization of VoLTE enabler features such as RLC UM, Robust Header Compression
and TTI bundling.

The Parameters below in Table 8 are used to trigger inter-frequency measurements as

well as initiating IRAT handovers so the Good and Bad Coverage Configuration
parameters (Event A1/A2) apply equally to inter-frequency mobility as well as SRVCC.

Feature Description Parameter

Inter-Frequency HO Good Coverage  ReportConfigA1Prim: a1Threshold[Rsrp|Rsrq]Prim
SRVCC to UTRAN Configuration (A1)  ReportConfigA1Sec: a1Threshold[Rsrp|Rsrq]Sec
SRVCC to GERAN  QciProfilePredefined=qci1: a1Threshold[Rsrp|
Rsrq]PrimOffset
 QciProfilePredefined=qci1: a1Threshold[Rsrp|
Rsrq]SecOffset
Inter-Frequency HO Bad Coverage  ReportConfigEUtraBadCovPrim: a2Threshold[Rsrp|
SRVCC to UTRAN Configuration (A2) Rsrq]Prim
SRVCC to GERAN  ReportConfigEUtraBadCovSec: a2Threshold[Rsrp|
Rsrq]Sec
 ReportConfigEUtraBadCov[Prim|Sec]:
triggerQuantityA2[Prim|Sec]
 QciProfilePredefined=qci1:
a2ThresholdRsrp[Prim/Sec]Offset
SRVCC to UTRAN UTRAN  ReportConfigB2Utra: b2Threshold1[Rsrp|Rsrq]
Measurements (B2)  ReportConfigB2Utra: b2Threshold2[Rscp|EcNo]Utra
 QciProfilePredefined=qci1: b2Threshold1[Rsrp|
Rsrq]UtraOffset
 QciProfilePredefined=qci1: b2Threshold2[Rscp|
Ecno]UtraOffset
SRVCC to GERAN GERAN  ReportConfigB2Geran: b2Threshold1[Rsrp|Rsrq]
Measurements (B2)  ReportConfigB2Geran: b2Threshold2Geran
 QciProfilePredefined=qci1: b2Threshold1[Rsrp|
Rsrq]GeranOffset
 QciProfilePredefined=qci1: b2Threshold2GeranOffset
Table 8: SRVCC optimization parameters

Please note that until release 15B, the Ericsson SBG does not support aSRVCC. This
means that SRVCC during the alerting phase is not supported so SRVCC during call setup
will lead to a call failure. This limitation should be considered when deciding on SRVCC
optimization strategies. Typical impact of this based on field results is 0.15% DCR
increase.
 Ericsson Internal
GUIDELINE 70 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The following KPIs in Table 9 should be monitored during SRVCC optimization:

KPI name Formula Description

Total voice call attempts made
pmUeCtxtRelCsfbWcdma + on LTE. Useful metric to ensure
VoLTE Call Attempts pmErabEstabSuccAddedQci + VoLTE coverage has not been
pmErabEstabSuccInitQci degraded after mobility
optimization
Percentage of SRVCC to
WCDMA handovers that were
100 * pmHoPrepSuccSrvcc / prepared successfully. Note that
SRVCC HO WCDMA SR
pmHoPrepAttSrvcc This success rate does not
include the success of setting up
on the WCDMA network
100*
(pmErabRelAbnormalEnbActQci + Percentage of ERAB call drops
pmErabRelAbnormalMmeActQci) / (set QCI=1). Note the IMS may
ERAB Retainability per QCI (pmErabRelNormallEnbActQci + not release the call after an
pmErabRelAbnormalEnbQci + ERAB call drop.
pmErabRelMmeQci)
Estimate of the total number of
pmErabRelAbnormalEnbQci + radio link failures on a cell (set
Total Radio Link Failures pmRrcConnReestAttQci QCI=1). This number is
expected to rise if SRVCC is
delayed for too long.

(pmHoExeAttWcdma +
pmHoExeAtt) * [(1-
(pmHoExeSuccWcdma +
pmHoExeSucc)/
VoLTE Alerting SRVCC (pmHoExeAttWcdma + VoLTE Drops due to lack of
Failures pmHoExeAtt)) – (1- SRVCC during Alerting
(requires 3G counters) (PMNOINCSIRATHOSUCCESS-
HOVERSUCUTRAN)/( PMNOINCS
IRATHOATT-
HOVERCNTUTRAN))]

Table 9: Useful KPIs for SRVCC optimization

6.3.3 Optimization Trial Examples

The following VoLTE SRVCC activities have been performed in VoLTE networks and
shown to improve the VoLTE performance in some scenarios:

 Drop call rate optimization during SRVCC handovers

 SRVCC and intra-frequency idle and connected mode mobility optimization
 Ericsson Internal
GUIDELINE 71 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

6.3.3.1 Drop Call Rate Optimization During SRVCC Handovers

The objective of this optimization trial was to improve the drop call rate during SRVCC
handovers. The SRVCC optimization activity carried out for an operator in North America
involved multiple iterations of SRVCC parameter optimization.

Trial parameter setting:

Parameter Baseline value Trial value (TC1) Trial value (TC2) Trial value (TC3)
a2ThresholdRsrpPrim -120 -120 -120 -120
b2Threshold1Rsrp -122 -122 -122 -122
a2ThresholdRsrpPrimOffset 0 4 6 2
b2Threshold1RsrpUtraOffset 0 4 6 2
hysteresisA2Prim 10 10 10 10
hysteresisB2 10 10 10 10

Trial results:
 It was concluded to go with final recommended settings (TC3)
 The final settings were verified through drive testing to ensure that SRVCC was
triggering successfully with the set values.

6.3.3.2 SRVCC and intra-frequency idle and connected mode Mobility

Optimization

The objective of this optimization is two-fold: enhancing the SRVCC performance by

means of allowing UEs in poor pathloss conditions to hand over to 3G already at an earlier
stage and aligning intra-frequency idle and connected mode mobility so that unnecessary
handovers are avoided. For the latter case, immediate mobility after an idle to connected
mode transition can be prevented when the sum of a3Offset and hysteresisA3 is equal to
the idle mode qHyst setting as illustrated in Figure 86.

Trial parameter setting:

Parameter Description Baseline value Trial value

b2Threshold1Rsrp RSRP threshold value (for the serving -122dBm -118dBm
cell) for the event B2
timeToTriggerB2 Time-to-trigger value for event B2 80ms 256ms

qHyst Cell reselection parameter that defines the 4dB 3dB

hysteresis value in the cell ranking criteria

a3Offset Offset value for event A3 2dB No change

 Ericsson Internal
GUIDELINE 72 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

hysteresisA3 Hysteresis value for event A3 1dB No change

Figure 86: Idle and connected mode mobility misalignment

Trial results:
 SRVCC handover execution success rate increased
 QCI1 RRC connection re-establishment attempts decreased
 Number of intra-freq. handover attempts and ping-pongs decreased
 QCI1 and QCI9 retainability improved
 Processor load for eNBs with high traffic load reduced slightly during busy hour
due to the reduced number of handover attempts
 Improvement in silent experience and number of UL audio gaps
 No negative impact on traffic balance, UL RSSI, or UL SINR
Avg. SRVCC HO SR

Ericsson Internal
GUIDELINE 73 (169)
[%]
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Monday Tuesday Wednesday TC

100 Baseline
qHyst / SRVCC opt.
90

80

70
pmRrcConnReestAttQci[1] 20% 15.55%

10% 8.85%
5.83%

0%

-10%
4 7 10 13 16 19 22 4 7 10 13 16 19 22 4 7 10 13 16 19 22
Time Time Time

Figure 87: SRVCC handover execution success rate

Monday Tuesday Wednesday TC

1500 Baseline
qHyst / SRVCC opt.

-22.14%
pmHoPrepAttLteIntraF
1000 -11.75%

-14.85%

500

Figure 88: Number of QCI1 RRC connection re-establishment attempts

Monday Tuesday Wednesday TC

8M Baseline
qHyst / SRVCC opt.

6M -9.23%
-22.48%

4M -19.49%

2M

0M

Figure 89: Number of intra-frequency handover attempts

Avg. intra-freq. HO SR

[%] Ericsson Internal

GUIDELINE 74 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Monday Tuesday Wednesday TC

99.5 Baseline
qHyst / SRVCC opt.

99.0

ERAB retainability 98.5

Difference in
QCI1 [%] 0.45%
0.4% 0.36%
0.32%

ERAB retainability 0.2%

QCI1 [%]
0.0%
4 7 10 13 16 19 22 4 7 10 13 16 19 22 4 7 10 13 16 19 22
Time Time Time

Figure 90: Intra-frequency handover success rate

Monday Tuesday Wednesday TC

1.5 Baseline
qHyst / SRVCC opt.
1.0

0.5

0.0

0%

-20% -27.49%

-40% -43.02%
-47.85%
4 7 10 13 16 19 22 4 7 10 13 16 19 22 4 7 10 13 16 19 22
Time Time Time

Figure 91: QCI1 E-RAB retainability

 Ericsson Internal
per VoLTE user [ms]
Silent experience
GUIDELINE 75 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

40 TC
Baseline
30
qHyst / SRVCC opt.
20

10
0

0%

-20%

-40%
-54.40%
800

600

400

200
0
0%

-50%

-84.81%
-100%
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Time

Figure 92: Silent experience per VoLTE user / # of UL audio gaps averaged over all trial days

7 VoLTE and MBB Optimization

7.1 Overview

Description:

The objective of the VoLTE and MBB Optimization module is to tune VoLTE features and
parameters to improve VoLTE performance. The result of conducting this module is
improved end-user VoLTE S-KPIs.

Inputs:

 VoLTE network performance (output from VoLTE S-KPI benchmarking module)

 Ericsson Internal
GUIDELINE 76 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 OSS Data – Configuration Management (CM): OSS data containing all RAN OSS
configuration data (parameters)

 OSS Data – Performance Management (PM): OSS data containing all performance
management data (counters) for KPI analysis.

Outputs:

 Feature and parameter recommendations to improve VoLTE S-KPIs

Tools:

 Performance monitoring tool: ITK / ESPA / KPI monitoring tool from customer

7.2 VoLTE Key Feature Optimization

This module provides improvements to optimize VoLTE features for optimum

performance. Information on troubleshooting any KPI degradation due to key VoLTE
features is also covered in this section.

7.2.1 TTI bundling

The TTI Bundling feature provides improved uplink coverage for VoLTE users. This is
beneficial when a UE is in bad radio conditions and is power limited and therefore may not
be able to transmit single VoIP packets during one TTI.
When a UE is configured to use TTI Bundling it will transmit the same data in four
consecutive TTI's with higher energy per bit. The data transmitted in the four TTI's is
identical but different redundancy versions will be used. Only when the last TTI is received
by the eNB the HARQ feedback is sent. UL transmissions with TTI Bundling are limited to
QPSK modulation and the resource assignment is maximum 3 PRBs.
The number of control signaling messages and the overhead resulting from RLC and MAC
headers as well as CRC is less when TTI Bundling is activated.
However, TTI Bundling is not beneficial when the UE is in good radio conditions because
a UE in good radio conditions can transmit several VoIP packets in one TTI and use a
HARQ retransmission time of 8ms when it is configured for normal HARQ operation. This
is compared to 16ms retransmission time when TTI Bundling is being used. Furthermore,
transmission of several VoIP packets in one TTI allows for more efficient scheduling.
In addition, TTI Bundling activation also impacts the UL throughput. If a UE with a VoIP
bearer satisfies conditions for TTI Bundling, then traffic for all bearers (VoIP and non-
VoIP) will be subject to TTI Bundling. Furthermore, in this mode, the allocation/TTI for
each UE in TTI Bundling is limited to maximum MCS=10 and maximum allocated PRBs=3.

Areas where issues could occur due to TTI Bundling could be UE failing to reconfigure to
TTI bundling mode, MOS quality, the node’s capacity and throughput with the threshold
settings. Further, since the feature multi-target RRC reestablishment is currently not
supported when TTI Bundling is active, this can result in increased drop calls.
 Ericsson Internal
GUIDELINE 77 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Any issues found associated with TTI Bundling feature, refer to TTI Bundling
Troubleshooting Guide.

The following sections outline the internal parameters that can be tuned to find the optimal
value for triggering TTI Bundling mode, such that MOS quality, capacity and throughput
are acceptable.

7.2.1.1 Optimizing TTI bundling thresholds

For this part of the service, the TTI Bundling feature needs to be activated and a large
fraction of the existing VoLTE UEs need to support this feature.
This section involves optimization of system constants. This activity may not be feasible
for all customers. Appropriate internal consultation should be conducted with local KAM
and EP prior to offering this service module.
Transmission of several VoIP packets in one TTI allows for efficient scheduling. Therefore,
the switch between using/not using TTI bundling is important to optimize the networks
capacity/coverage requirements.
Since there are capacity impacts such as reduced UL throughput from triggering TTI
bundling, the triggers for switching to/from TTI Bundling can be optimized for networks
depending on how much degradation in MOS can be tolerated.
The switch points for TTI bundling are controlled by the internal system constants shown
in Table 10: TTI Bundling system constants description. For changes to these parameters
to take effect, the eNB needs to be restarted.

SC Internal parameter name Description Min Max Default Mapping

#
736 ttiBundlingSwitchThreshold SINR threshold for triggering -150 400 90 Divide by
a switch to TTI Bundling [dB]. 10

737 ttiBundlingSwitchHysteresis Hysteresis value for switching 0 100 10 Divide by

to TTI Bundling [dB]. 10

738 ttiBundlingSwitchProhibitTime Time after a switch to/from 0 32767 500 -

TTI Bundling when triggering
of a new switch is prohibited
[ms].
739 ttiBundlingSwitchProhibitMea Number of measurements 0 32767 20 -
sCount (PUSCH transmissions) that
must be received after a
switch to/from TTI Bundling
before triggering of a new
switch is possible.
 Ericsson Internal
GUIDELINE 78 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Table 10: TTI Bundling system constants description. For changes to these parameters to
take effect, the eNB needs to be restarted.

Figure 93: TTI Bundling triggers

The method for optimizing TTI Bundling involves the following steps:
1) Set ttiBundlingSwitchThreshold value: The eNB determines which UEs benefit
from TTI Bundling by measuring the UL channel quality (filtered SINR) per UE. If a
UE's UL channel quality is worse than ttiBundlingSwitchThreshold it will be
configured for TTI Bundling. If a UE's UL channel quality is better than this
threshold it will be configured for normal HARQ operation. During optimization, this
threshold should be tuned to the SINR value at which MOS is starting to degrade.
The “SINR” trigger value should be equivalent to the estimated UL SINR for
normalized full power on 1 PRB not actual UL SINR. If two PRBs are used, the
SINR value should be compensated with 3dB.

2) Tune ttiBundlingSwitchHysteresis value: Setting a high value will reduce the

probability of a switch to TTI Bundling in fluctuating SINR conditions. This is
recommended when capacity is important. In summary, transition occurs when
SINR < ttiBundlingSwitchThreshold – ttiBundlingSwitchHysteresis.

As an example, let us assume the ttiBundlingSwitchProhibitTime and ttiBundlingSwitch-

ProhibitMeasCount have expired and default values are used, that is, ttiBundlingSwitch-
Threshold = 9 dB and ttiBundlingSwitchHysteresis = 1dB. This would result in TTI
Bundling being switched ON when the SINR trigger value is below (9 - 1) dB = 8dB. On
the other hand, TTI bundling will be switched OFF when the SINR trigger value is above (9
+ 1) dB = 10dB. If two PRBs are used (typical), this corresponds to TTI Bundling being
activated at UL SINR below 5dB.
 Ericsson Internal
GUIDELINE 79 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

It is not recommended to tune ttiBundlingSwitchProhibitTime and ttiBundlingSwitch-

ProhibitMeasCount values at this time.

7.2.1.2 Optimizing TTI bundling thresholds from performance measurements

Optimization of the TTI Bundling thresholds should be done based on the feedback
received from the following PM counters and KPIs.
PM counters to monitor:

Counter Description
pmTtiBundlingUeSum Sum of all sample values recorded for number
of UEs using TTI Bundling.

pmTtiBundlingUeSamp Counts the number of times the corresponding

pmTtiBundlingUeSum has been incremented.

pmTtiBundlingUeMax Maximum sample value of number of UEs using

TTI Bundling.

KPI to monitor:

KPI Description
VoIP Integrity Integrity impact for VoIP in the RAN.

7.2.1.3 Targeting mid cell coverage holes

Optimization of TTI Bundling thresholds should also take in to account the use of TTI
Bundling feature to prevent unnecessary inter-frequency handovers as shown in Figure
94: Using TTI Bundling to handle mid cell coverage holes
 Ericsson Internal
GUIDELINE 80 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 94: Using TTI Bundling to handle mid cell coverage holes

In mid-cell scenarios where the UL RSSI observed is higher than normal, TTI Bundling
could be activated earlier by reducing the ttiBundlingSwitchThreshold parameter. In these
cases, the A3 and A5 thresholds will need to be optimized as well to prevent the Inter-
Frequency handover mid cell.
Observation of the following counters is required in order to prioritize sites for optimization
of the TTI Bundling thresholds.

Counter Description
pmUeCtxtRelSCEutra Number of UE releases done, where the UE
was redirected to another LTE frequency

7.2.2 Robust header compression

Robust Header Compression (RoHC) feature is used to compress IP packet headers as

specified by the IETF standard. It primarily used for radio bearers carrying VoLTE calls to
increase coverage and capacity. A channel needs to be established between two RoHC
end points and it has a flow classifier responsible for associating IP packets with a context,
such that flows can be multiplexed on the same bearer.

The improvements from RoHC include:

 Improved cell edge performance
 Lower BLER %
 Less UL resources need to be allocated
 Field test results have shown a 1dB cell edge coverage gain
 Ericsson Internal
GUIDELINE 81 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Counters associated with RoHC feature are listed in Table 11.

Counter Description
pmPdcpVolDlHdrQci Total volume of uncompressed PDCP SDU headers that has been received
in the RoHC entity in the downlink direction for each QCI.
pmPdcpVolDlCmpHdrQci Total volume of compressed PDCP SDU headers that has been transmitted
from the RoHC entity in the downlink direction for each QCI.
pmPdcpVolUlHdrQci Total volume of decompressed PDCP SDU headers that has been
transmitted from the RoHC entity in the uplink direction for each QCI.
pmPdcpVolUCmplHdrQci The total volume of compressed PDCP SDU headers that has been received
in the RoHC entity in the uplink direction for each QCI.
pmRohcEstabFailCid Number of setups of the Robust Header Compression feature failed due to
exceeding the baseband capacity limit for RoHC.
pmRohcEstabFailLic Number of Robust Header Compression feature setups failed due to missing
or inoperable license
pmRohcEstabFailUeCap Number of Robust Header Compression feature setups failed due UE
Capabilities
pmRohcCidSum Sum of all sample values recorded for the number of Robust Header
Compression feature context IDs
pmRohcCidSamp Number of times the corresponding sum counter has been incremented

Table 11: RoHC counters

The following KPI measures the RoHC feature performance:

pmPdcpVolDlCmpHdrQci
Compressed Header Ratio DL=
pmPdcpVolDlHdrQci

pmPdcpVolUlCmpHdrQci
Compressed Header Ratio UL=
pmPdcpVolUlHdrQci

pmRohcCidSum
Average RoHC Context IDs=
pmRohcCidSamp

RoHC issues can be identified from the above counters and KPI. Some of the common
issues would be high rates of PDCP packets discards due to RoHC
compress/decompress errors, low header compression rates, RoHC stack compatibility
between UE and network.

See RoHC Troubleshooting Guide for the details on troubleshooting this feature.

7.2.3 Delay based scheduling & semi-persistent scheduling

Delay-Based Scheduling (DBS) operates by applying an age-dependent weight to VoIP

packets, scheduling resources for VoIP services only when this is required to avoid
exceeding the Packet Delay Budget (PDB). When the scheduler determines that the VoIP
packets must be scheduled, their scheduling is prioritized over MBB services. This results
in an efficient scheduling of both voice and MBB services.
 Ericsson Internal
GUIDELINE 82 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Semi Persistent scheduling is a method whereby the eNodeB allocates radio resources to
UE periodically and removes the need for the UE to send scheduling requests during VoIP
TALK. This saves pdcch resources for DL assignments or UL grants and at the same time
reduce the battery consumption by the UE.

VoIP Integrity is a good measure for this feature. Additionally, its impact on the Mobile
Broadband (MBB) throughput should be measured. Note, VoIP Integrity counters may not
work without RLC UM feature.

The simulation results have shown that DBS throughput advantages start to become
visible only at >35 VoLTE users activate in the cell.

For DBS and SPS related issues, refer to DBS & SPS.

7.2.4 Enhanced PDCCH link adaptation

Enhanced PDCCH Link Adaptation is a feature that helps reduce the PDCCH error rate for
VoLTE users which then translates to better voice quality.

Using this feature, the target BLER for PDCCH can be specified for VoLTE bearers. The
specified target BLER can be satisfied by adjusting the estimated SINR to compensate for
CQI estimation errors on the PDCCH and outer loop adjustment. The outer loop
adjustment (an upward step or a downward step) are based on PDCCH success or failure
rate, and whether the PDCCH allocations are aggressive or conservative. The PDCCH
allocation is considered conservative if the number of allocated Control Channel Elements
(CCE) exceeds, within a predefined range, the required number, and it is considered
aggressive in the opposite case.

The available parameters are listed below:

Parameter Description
pdcchTargetBlerVolte PDCCH BLER target for VoLTE ERABs. Increasing the target may
improve VoLTE voice quality or Speech Path Delay, but at a cost of
system capacity
pdcchOuterLoopUpStepVolte PDCCH Outer loop upstep value. This is the delta applied to the SINR
estimation if it can be increased. Increasing this parameter may improve
PDCCH capacity but may increase radio link failures or retransmissions
pdcchOuterLoopInitialAdjVolt Initial outer loop adjustment for that is added to the estimated SINR value
e of VoLTE ERABs. Increasing this parameter may improve PDCCH
capacity but may increase radio link failures or retransmissions

Counters related to Enhanced PDCCH link adaptation for VoLTE are listed below:

Counter Description
pmDlAssigsTransVolte The total number of unicast DL assignments transmitted to
UEs that have any bearer mapped to a QCI with ServiceType
of VOIP. The DL assignments are excluded if this cell is a
secondary cell for those UEs.
pmDlAssigsWithDetectedHarqAckVolte The total number of unicast DL assignments that are
 Ericsson Internal
GUIDELINE 83 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

transmitted to UEs with any bearer mapped to a QCI with

ServiceType of VOIP, for which the reception is confirmed by
detecting a corresponding ACK or NACK for any transport
block. The DL assignments are excluded if this cell is a
secondary cell for those UEs.
pmDlAssigsWithUnknownReceptionVolt The total number of unicast DL assignments that are
e transmitted to UEs with any bearer mapped to a QCI with
ServiceType of VOIP, for which the reception is unknown.
The DL assignments are excluded if this cell is a secondary
cell for those UEs.
pmUlGrantsTransVolte The total number of unicast UL grants transmitted to UEs that
have any bearer mapped to a QCI with ServiceType of VOIP.
pmUlGrantsWithDetectedPuschVolte The total number of unicast UL grants that are transmitted to
UEs with any bearer mapped to a QCI with ServiceType of
VOIP, for which the reception is confirmed by detecting a
corresponding PUSCH transmission.

Evaluation of the parameter changes should be performed with the following metrics:

Metric Formula Description

If the Carrier
VoLTE UL Grant SR 100* The probability that an UL grant for VoLTE is detected.
Aggregation pmUlGrantsWithDetecte Significant degradation in this metric indicates that the
license is dPuschVolte / UE is not responding to UL grants which leads to poor
activated, pmUlGrantsTransVolte voice quality and increased resource usage from
the following rescheduling in the UL. VoLTE link budgets are
generally UL limited so it is expected that this metric
metrics are will degrade before the DL.
the non-
VoLTE DL Assign 100 * The probability that a DL transmission for VoLTE is
VoLTE SR pmDlAssigsWithDetecte detected. Degradation in this metric indicates that the
equivalents dHarqAckVolte / UE did not receive the DL transmission or that the UL
and can be pmDlAssigsTransVolte HARQ response was not received at the base station.
used as a VoLTE DL Assign 100 * The probability that a DL transmission for VoLTE is not
benchmark UR pmDlAssigsWithUnkno detected. This is the reciprocal formula for VoLTE DL
to compare wnReceptionVolte / Assign SR
VoLTE pmDlAssigsTransVolte
detection to non-VoLTE traffic.

Counter Description
UL Grant PCell SR 100* pmUlGrantsWithDetectedPuschPcell / pmUlGrantsTransPcell
DL Assign Pcell SR 100 * pmDlAssigsWithDetectedHarqAckPcell / pmDlAssigsTransPcell
DL Assign Pcell UR 100 * pmDlAssigsWithUnknownReceptionPcell / pmDlAssigsTransPcell

The estimated PDCCH error rate for VoLTE is provided by the equation below:

pmDlAssigsWith DetectedHarqAckVolte + pmUlGrants

Estimated PDCCH error Rate [VoLTE ]=1−
pmDlAssigsTransVolte+ pmUlGrantsTr

The above error rate can be lowered by:

 Ericsson Internal
GUIDELINE 84 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

pmDlAssigsWithUnknownReceptionVoLTE
pmDlAssigsTransVolte+ pmUlGrantsTransVoLTE

It should be noted that in case the Enhanced PDCCH Link Adaptation feature is activated,
a small degradation in retainability may be observed as a tradeoff for the capacity gain.
For guide on troubleshooting this feature, refer to Enhanced Link Adaptation
Troubleshooting Guide. In addition to activating this feature, another change that can be
made is reducing the UL BLER for VoLTE from 10% to 1%. Observed field results of this
change are shown below:

7.2.5 PDCCH power boost

PDCCH Control Channel Element (CCE) and power are key resources of PDCCH
transmission. PDCCH Power Boost feature is used to improve PDCCH cell capacity by
calculating and boosting the power to compensate for the CCE requirement. When the
maximum aggregation level and maximum boost power are allocated, PDCCH cell
coverage is improved.

Parameter pdcchPowerBoostMax is used to set the maximum power boost to apply to

PDCCH that requires more than the maximum CCE aggregation level. The counters
associated with the PDCCH power boost feature are listed in Table 12.

Counters Description
pmPdcchTxAggressive Counts the total number of times where the PDCCH transmissions are
considered to be aggressive, that is, the number of CCEs allocated is much
lower than the number of CCEs required.
pmPdcchTxConservative Counts the total number of times where PDCCH transmissions are
considered to be conservative, that is, (the number of CCEs allocated is
much higher than the number of CCEs required.
pmPdcchCceAggregationDistr This counter indicates the distribution of PDCCH CCE aggregation levels
selected during the PDCCH allocation phase. Counts the number of
samples with corresponding PDCCH CCE aggregration level.
pmPdcchSym0PwrUtil This counter counts the Physical Downlink Control Channel (PDCCH)
symbol 0 power utilization for PDCCHs transmitted on the air interface. It
counts the PDCCH power % utilized in OFDM symbol 0, compared to the
total available PDCCH power in the same symbol, while considering
bandwidth and antenna configuration.
pmPdcchSym1PwrUtil This counter counts the Physical Downlink Control Channel (PDCCH)
symbol 1 power utilization for PDCCHs transmitted on the air interface. It
counts the PDCCH power % utilized in OFDM symbol 1, compared to the
total available PDCCH power in the same symbol, while considering
 Ericsson Internal
GUIDELINE 85 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

bandwidth and antenna configuration.

pmPdcchSym2PwrUtil This counter counts the Physical Downlink Control Channel (PDCCH)
symbol 2 power utilization for PDCCHs transmitted on the air interface. It
counts the PDCCH power % utilized in OFDM symbol 2, compared to the
total available PDCCH power in the same symbol, while considering
bandwidth and antenna configuration.
pmPdcchSym3PwrUti1 This counter counts the Physical Downlink Control Channel (PDCCH)
symbol 3 power utilization for PDCCHs transmitted on the air interface. It
counts the PDCCH power % utilized in OFDM symbol 3, compared to the
total available PDCCH power in the same symbol, while considering
bandwidth and antenna configuration.
pmPdcchCceRequestedDistr This counter indicates the distribution of the requested number of Control
Channel Elements (CCE) for Physical Downlink Control Channel (PDCCH)
during the PDCCH allocation phase. It counts the requested number of
CCEs for PDCCH, as indicated by PDCCH link adaptation when using the
normalized Power Spectral Density (PSD) reference level as the reference
transmit power for PDCCH REs. Note that the requested number of CCEs
have been scaled by 100.

Table 12: PDCCH Power Boost Counters

Please note that in case the PDCCH Power Boost feature is activated, a small
degradation in retainability may be observed as a tradeoff for the capacity gain.

A trial of this feature conducted on 5 clusters found the following impact to VoLTE drop
call rate even though there was a clear improvement for PDCCH usage rate observed.

Feature activated

Figure 95: VoLTE drop call rate

 Ericsson Internal
GUIDELINE 86 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Feature activated

Figure 96: PDCCH usage

It is important to note that this feature is recommended only for sites with high RRC
connected users as well as high CCE utilization rate (sites with high load on control
channel), not for the entire network. For guide on troubleshooting this feature, refer to
PDCCH Power Boost Troubleshooting Guide.

7.3 Sleep Timer Optimization

According to GSMA IR.92 it is required for UE and LTE RAN to support discontinued
Reception (DRX) during an active VoLTE call to save UE battery life. The UE is assigned
a periodic wake (ON) period during which it listens to the network or monitors the PDCCH
and a periodic sleep (OFF) period where it does not and goes to power saving mode.

Discontinuous Reception (DRX) for connected UE is the feature that allows the UE to save
its battery power by having periods where the UE does not need to monitor the PDCCH.
When UEs are connected to the network for MBB traffic, the network configures UEs with
default DRX parameters specific to the transmission characteristics of MBB traffic (eg.
web browsing).

The need for efficient DRX behavior is particularly important for VoLTE since battery
consumption for VoLTE UEs is expected to be higher.

With the feature “Service Specific DRX”, UE terminals with VoLTE calls can be re-
configured with DRX parameters specific to Voice packet transmission characteristics.
This impacts the MBB traffic as well. That is VoLTE UEs are configured with the DRX
parameters when QCI1 bearer is established. At the termination of the Voice calls the
terminals are re-configured back to the default DRX parameters normally specific to MBB
traffic.

DRX parameters that can be tuned and optimized are discussed in this section. Apart from
impact to UE battery usage, potential issues that could arise from this optimization would
be retainability issues or increase in latency – as the ue “sleep” time and “awake” time
may not be balanced. Therefore, these KPIs should be monitored when conducting this
optimization. For guidance on how to troubleshoot issues associated with this feature,
refer to DRX for Connected UE Troubleshooting Guide and DRX and Latency
Troubleshooting Guide.

See Table 13 below for the typical settings (FDD only) for DRX Profile for QCI=1 and
QCI=8/9, assuming eMBMS feature is not used.
 Ericsson Internal
GUIDELINE 87 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Parameter Recommended QCI=1 Profile DRX settings Typical QCI=8/9 Profile DRX
(see VoLTE Assessment service) settings (for MBB traffic)
drxInactivityTimer 3 (PSF4) 15 (PSF 200)
longDrxCycle 3 (SF40) 9 (PSF 320)
shortDrxCycle 7 (SF40) 7 (SF 40)
shortDrxCycleTimer 0 1 or 2
drxRetransmissionTimer 1 (PSF2) 1 (PSF 2)
longDrxCycleOnly 3 (SF40) 9 (PSF 320) or PSF160

Table 13: QCI1 profile DRX settings

As can be observed from the table, there are differences in the typical settings for the
longDrxCycle between the two services. Moreover, it can be observed that recommended
setting for QCI=1 is to not use the shortDRXCycle (shortDrxCycleTimer = 0).

7.3.1 Optimization of longDrxCycle

To extend battery life, the current value of the longDRXCycle can be optimized by making
the following changes shown in Table 14:

Parameter name Description Internal Existing Recommende

MoM value d value
longDrxCycle (for Specifies the consecutive subframes No 3 (SF40) 4 (SF64)
QCI=1 profile) between on-duration phases. The
parameter is applied when the UE
follows the long DRX cycle.
longDrxCycleOnly (for Specifies the consecutive subframes No 3 (SF40) 4 (SF64)
QCI=1 profile) between on-duration phases. The
parameter is applied when the UE does
not support short cycles (FGI 4=0) and
follows the long DRX cycle only.
ulDelayBundlingTime Specify the uplink delay bundling Time Yes – SC 24 40 – 60 (TBC
of DBS # 877 during trial)
dlDelayBundlingTime Specify the downlink delay bundling Yes – SC 24 40 – 60 (TBC
Time of DBS #746 during trial)
Table 14: Parameters for longDrxCycle optimization

Increasing the Delay Bundling Time allows for three packets to be bundled rather than
two. This will provide an opportunity for the longDrxCycle to be increased, allowing the UE
to be inactive for a longer period between sending VoLTE packets.

The impact of this change will be a greater time spent by the UE in DRX sleep state,
resulting in improved battery performance. On the other hand, there will be an increase in
the average packet delay. However, if the other E2E path delays are optimized there
should be no impact to the VoLTE speech path delay.

This behavior will need to be verified during the FOA along with finding the optimal value
for ulDelayBundlingTime and dlDelayBundlingTime
 Ericsson Internal
GUIDELINE 88 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The following will need to be measured during Optimization in order to find the optimal
values for these parameters.
 Total UE inactive time
 Number of HARQ retransmission
 Total speech path delay
Alternatively, some clusters see clear degradation in performance when DRX is enabled.
This is often caused by the UE having less time available to monitor its RF conditions in
its serving cell. In scenarios where it is difficult to resolve the underlying RF issues with
parameter optimization, it may be possible to reduce the period of time that active VoLTE
UEs are using DRX to allow for better RF environment handling. This will have a negative
impact on terminal battery life while the user is having an active VoLTE call but maybe
considered an appropriate trade-off.

Parameter name Description Internal Existing Recommende

MoM value d value
longDrxCycle (for Specifies the consecutive subframes No 3 (SF40) 4 (SF64)
QCI=1 profile) between on-duration phases. The
parameter is applied when the UE
follows the long DRX cycle.
longDrxCycleOnly (for Specifies the consecutive subframes No 3 (SF40) 4 (SF64)
QCI=1 profile) between on-duration phases. The
parameter is applied when the UE does
not support short cycles (FGI 4=0) and
follows the long DRX cycle only.
drxInActivityTimer Specifies the minimum number of No 3 (PSF4)
PDCCH subframes where the UE
receives no grants or allocations before
the UE can enter DRX mode
Table 15: Parameters for longDrxCycle optimization to reduce DRX impacts

7.3.2 Optimization of shortDrxCycle

If the longDrxCycle is optimized for extending battery life as stated above, this would
impact PDCP latency for MBB traffic as well when the UE is in a VoLTE call. Therefore, in
order to more efficiently handle MBB traffic while on a VoLTE call, it is recommended that
the short DRX cycle is used. Currently for QCI=1, the short DRX cycle is disabled.

The following recommendations listed in Table 16 should be made:

Parameter name Description Internal Existing Recommended

MoM value value
shortDrxCycle (for Specifies the consecutive subframes No NA 3 (SF 10)
QCI=1 profile) between on-duration phases, i.e. the or 5 (SF 20)
period of re-occuring on-duration phases.
(TBC during
FOA)
shortDrxCycleTimer Specifies the number of consecutive No 0 1 or 2
(for QCI=1 profile) subframes the UE must follow the short
DRX cycle after the DRX Inactivity Timer (TBC during
has expired. FOA)
 Ericsson Internal
GUIDELINE 89 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Table 16: Parameters for shortDrxCycle optimization

The impact of this change will be a lower latency for MBB traffic during VoLTE call. This is
particularly recommended if the longDrxCycle is optimized.

This behavior has not been tested in a FOA and will need to be verified for the operator
along with finding the optimal value for shortDrxCycle and shortDrxCycleTimer.

Monitoring during optimization phase:

The counters listed in Table 17 will need to be measured during optimization of the DRX
cycle timers in order to confirm the optimal values for these parameters.

Counter Description
pmDrxTotalTime DRX total time in number of subframes for all UE in the cell
pmDrxSleepTime DRX sleep time in number of subframes for all UE in the cell
pmPdcpLatTimeDlDrxSync Aggregated DL latency for a measurement period. The effective DL
Latency time comprises the time from first data entering the send
buffer until the first data has been transmitted to the UE. Samples
that are the first in the target cell during a handover are excluded
since they will show impact of the packet forwarding buffering
although they are not a performance degrading action. The filters are
that DRX is active and the UE has UL synchronization status
"synchronized".
pmPdcpLatPktTransDlDrxSync Number of samples for latency measurements during measurement
period. The filters are that DRX is active and the UE has UL
synchronization status "synchronized".
pmPdcpLatTimeDlNoDrxSync Aggregated DL latency for a measurement period. The effective DL
Latency time comprises the time from first data entering the send
buffer until the first data has been transmitted to the UE. Samples
that are the first in the target cell during a Handover are excluded
since they will show impact of the packet forwarding buffering
although they are not a performance degrading action. The filters are
that DRX is not active and the UE has UL synchronization status
"synchronized".

pmPdcpLatPktTransDlNoDrxSync Number of samples for latency measurements during measurement

period. The filters are that DRX is not active and the UE has UL
synchronization status "synchronized".
Table 17: Efficient DRX/DTX for Connected UE PM Counters

Based on the above counters, latency for non DRX and DRX packets can be determined
by the following equations:

pmPdcpLatTimeDlNoDrxSync
PDCP Latency Non Drx=
pmPdcpLatPktTransDlNoDrxSync

pmPdcpLatPktTimeDlDrxSync + pmPdcpLatPktTimeDlDrxNoSync
PDCP Latency DRX=
pmPdcpLatPktTransDlDrxSync + pmPdcpLatPktTimeDlDrxNoSync

High PDCP non-DRX and DRX latency could indicate high load in cell. The below
equation can be used to measure the QCI specific latency – for voice the latency for
QCI=5 (SIP) and QCI=1 (voice Media) can be used to determine the latency.
 Ericsson Internal
GUIDELINE 90 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

pmPdcpLatTimeDlQci
DL Latency , QCI [ ms ] =
pmPdcpLatPktTransDlQci

When implementing at a cluster level, the following counters and KPI should also be
monitored to ensure no degradation occurs through the implementation of these DRX
changes:
 Retainability
 Accessibility
 Paging Success rate (need to confirm counters)
 VoIP Integrity
 MBB throughput
 Total UE inactive time
 Number of HARQ retransmission
 Total speech path delay

7.4 Additional Parameter Optimization

In addition to feature improvements, specific internal parameters may also improve VoLTE
performance. While it is not recommended that internal parameters are actively optimized,
there may be a need to investigate using these parameters for specific improvements.

In the following, Table 18 lists some suggestions for parameter improvements that could
be trialed in a cluster prior to implementation. It should be noted that parameter trial
improvements may vary based on specific network conditions and radio conditions.
Therefore, it is recommended to implement at cluster or site level to monitor the impact
prior to implementation across the network.

Optimization Parameter / Change Summary

area Feature
Interference / crsGain Set to 0 These parameters control the power boost for typeA
power pdschTypeB and typeB resource elements. This change is expected
optimization Gain to reduce interference, thus improving VoLTE DCR and
potentially improve PDCCH usage rate, DL/UL cell
throughput, VoLTE quality and RACH decoding SR.
Recommended for downtown areas with short inter-site
distances, where DL and UL interference needs to be
properly controlled.
Potential to reduce DL coverage and therefore not
recommended in rural type environments
Interference UL FSS Use feature With UL FSS, the uplink scheduler attempts to maximize
control UL FSS (with the spectral efficiency by allocating each UE into a part
SRS turned of the spectrum where the channel quality is good,
off) according to certain measurements. Improvements
resourceAlloc expected to VoLTE DCR and UL PUSCH SINR and
ationStrategy reduction in UL Packet loss and Handover execution
=Frequency failures. More useful in urban areas. It is not
Selective recommended to enable SRS (Sounding Reference
Signal) together with DRX of Ericsson VOLTE
configuration which has short DRX cycle, as there is
 Ericsson Internal
GUIDELINE 91 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

possibility that SRS resource is not aligned with the

awake periods of DRX and can have a negative impact
on the link adaptation
Power control dlAttenuation Optimize Tx- Improve sites with poor UL PUSCH SINR without any
/ Rx reference negative impact expected.
ulAttenuation point.
Handover adaptiveCfiHo Set to 0 Improves handover success rate. Parameter change will
improvement Prohibit help sites with high mobility. Not expected to have any
(SC1308) without any obvious negative impact to the network.
RLC layer tReorderingDl Set to 60ms The timer is used by the receiving side of an AM RLC
optimization tReorderingUl entity and receiving UM RLC entity in order to detect
loss of RLC PDUs at lower layer. This change will allow
holding on to resources longer. Expected to improve
voice quality but will increase packet delay. Therefore,
e2e latency should be checked.
Interference DL ICIC dlInterference Reduce DL interference by allocating resources
control Management randomly in different frequency bands for in between
Active set to cells. This change will impact capacity and therefore
TRUE system load should be monitored.
dlInterference
Management
Duration set
to 100
Table 18: Parameter tuning recommendations

7.5 VoLTE and MBB Optimization Trial Examples

The following parameter optimizations for VoLTE and MBB have been performed in
VoLTE networks and shown to improve the VoLTE performance in some scenarios:
 Optimization of crsGain and pdschTypeBGain
 UL FSS (with and without SRS) optimization
 Tx/Rx reference point optimization
 DRX optimization and UL FSS / SRVCC activation

7.5.1 Optimization of crsGain and pdschTypeBGain

The objective of this optimization trial is to reduce the inter-cell interference by de-boosting
the signal strength of the reference signals, thus improving the VoLTE drop call rate.
Potential risk is that the downlink coverage will be reduced. In this regard, two trials were
conducted for three clusters consisting of 187 sites in one location and two clusters of 112
sites in another location. Both locations were dense urban type environments.

Trial parameter setting:

Parameter Baseline Trial
Description
value value
crsGain Sets the DL power of the Cell specific Reference 0 300
Signal (CRS) relatively a reference level defined
by the power of the PDSCH type A resource
element.
pdschTypeBGain Sets the DL power of the PDSCH type B resource 0 1
elements relatively the PDSCH type A resource
 Ericsson Internal
GUIDELINE 92 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

element.

Trial results:
 Improved KPIs: VoLTE DCR, MBB DCR, VoLTE quality, RACH decoding SR, UL
power restricted ratio, DL/UL cell throughput, PDCCH usage rate
 Degraded KPIs: HO execution SR, Session Continuity to UMTS

Figure 97: VoLTE drop call rate

Figure 98: VoLTE quality

 Ericsson Internal
GUIDELINE 93 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 99: RACH decoding SR

Figure 100: UL power restricted ratio

Figure 101: DL cell throughput

 Ericsson Internal
GUIDELINE 94 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 102: UL cell throughput

Figure 103: HO execution SR

Figure 104: PDCCH usage rate

 Ericsson Internal
GUIDELINE 95 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 105: MBB drop call rate

Figure 106: Session continuity to WCDMA

7.5.2 UL FSS (with and without SRS) optimization

With UL FSS, the uplink scheduler attempts to maximize the spectral efficiency by
allocating each UE into a part of the spectrum where the channel quality is good,
according to certain measurements. Improvements expected to VoLTE DCR and UL
PUSCH SINR and reduction in UL Packet loss and handover execution failures. It is not
recommended to enable SRS (Sounding Reference Signal) together with DRX of Ericsson
VOLTE configuration which has short DRX cycle, as there is possibility that SRS resource
is not aligned with the awake periods of DRX and can have a negative impact on the link
adaptation. In this regard two trials were conducted, one where UL FSS was activated with
SRS and another one UL FSS was activated but without SRS.

Trial parameter setting:

Parameter Description Baseline value TC1 value TC2 value
 Ericsson Internal
GUIDELINE 96 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

resourceAllocationStrateg Defines the resource Resource fair Frequency Frequency

y (QCI1 / QCI 5) allocation strategy of selective selective
the QoS Class
Identifier (QCI)
srsAllocationStrategy Allow allocation of Deactivated Deactivated Activated
(QCI1 / QCI 5) sounding reference
signals for a UE

Trial results:
 Observations from the trial were that UL FSS with SRS improved VoLTE DCR for
the dense urban areas, while UL FSS without SRS improves VoLTE drop call rate
in suburban areas. UL FSS did not help for some of the rural areas
 Improved KPIs: VoLTE DCR, MBB DCR, VoLTE quality, UL PUSCH SINR, UL
power restricted ratio and UL cell throughput

Figure 107: VoLTE drop call rate

Figure 108: UL power restricted ratio

 Ericsson Internal
GUIDELINE 97 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 109: PUSCH and PUCCH SINR

Figure 110: UL cell throughput

Figure 111: VoLTE quality

 Ericsson Internal
GUIDELINE 98 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 112: MBB drop call rate

7.5.3 Tx/Rx reference point optimization

Changes were made for 28 non-TMA outdoor sites.

Trial results:
 No observed gain for VoLTE DCR
 Clear improvement for UL PUSCH SINR observed

Figure 113: VoLTE drop call rate

Figure 114: PUSCH SINR

 Ericsson Internal
GUIDELINE 99 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

7.5.4 DRX optimization and UL FSS / SRVCC activation

The changes were conducted on 2 areas, each covering 12 clusters.

Trial parameter setting:

Parameter Description Baseline value Trial value
longDrxCycle The value of longDrxCycle is in number of sub- 5 (SF80) (SF40)
frames. If shortDrxCycle is configured, the value
of longDrxCycle shall be a multiple of the
shortDrxCycle value.
longDrxCycleTimer Specifies the number of consecutive subframes 1 (SF20) 3 (SF40)
the UE must follow the long DRX cycle after the
DRX Inactivity Timer has expired.
onDurationTimer Specifies the number of consecutive PDCCH- 3 (PSF4) 10 (PSF40)
subframe(s) at the beginning of a DRX Cycle.
TS36.331 ch. 6.3.2, RRC parameter
onDurationTimer.
shortDrxTimer Specifies the number of consecutive subframes 5 0
the UE must follow the short DRX cycle after the
DRX Inactivity Timer has expired. Value in
multiples of shortDRX-Cycles.

Trial results:
 Voice Quality was observed to be improved after L14B, DRX deactivation, UL FSS
& SRVCC activations
 Ericsson Internal
GUIDELINE 100 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 115: Voice quality for trial area 1

Figure 116: Voice quality for trial area 2

 Ericsson Internal
GUIDELINE 101 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8 VoLTE Root Cause Analyzer (VoLTE RCA)

8.1 Overview

This chapter describes the VoLTE RCA functionality which is part of the
Ericsson RAN Analyzer (ERA) solution and how it can be used for VoLTE
optimization.

8.2 Ericsson RAN Analyzer (ERA)

Ericsson RAN Analyzer is an innovative multi-vendor and multi-technology

Performance Monitoring and Self-Healing solution that allows operators to
streamline their performance engineering processes while at the same time
ensuring the Quality of Service levels and response times that are required to
satisfy a customer base with mounting expectations, with the subsequent
OPEX rationalization, increased customer loyalty and improved EBITDA.

Ericsson Ran Analyzer belongs to the EDOS DP portfolio, as an EDOS DP

module.

Figure 117Overview of the input interfaces of Ericsson RAN Analyzer

There is a variety of functionalities and benefits associated with the ERA

solution; however the focus of this chapter is to cover only the VoLTE RCA.
 Ericsson Internal
GUIDELINE 102 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.2.1 System Requirements

The requirements listed in this document are according to ERA System Adm.
Guide, Release L16B.

8.2.1.1 Hardware Requirements

In Standalone mode, the entire application is installed and run from an

engineer´s computer. The following specifications are the minimum and
recommended ones:

Figure 118Hardware Requirements

8.2.1.2 Software Requirements

Minimum and recommended software requirements to run Ericsson RAN

Analyzer in standalone mode are described below:
 Ericsson Internal
GUIDELINE 103 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 119Software Requirements

The required input data for the troubleshooting analysis consists of:

 CM: Relevant configuration parameters that determine the

performance of the cells.

 PM: Raw counters from the OSS.

 FM: Alarms reported by the network elements

 Call traces (CTRs): Content of the protocol messages exchanged

between the UEs and the network.

8.2.2 OSS Data Gateway (ODG)

Part of the mediation layer and capable of obtaining information of the CM

parameters, PM counters and OSS alarms in a scheduled task with a
recurrence programmed by the administrator.

8.2.2.1 Installation

OSS Data Gateway must be installed (also including PBO Database Server
as required for any other project).

For any further question regarding how to install/deploy ODG, please refer to
CPI library Ericsson RAN Analyzer CPI Technical Library, “User Manual for
OSS Data Gateway”.
 Ericsson Internal
GUIDELINE 104 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.2.2.2 Outputs

VoLTE RCA relies on TPS parsing capabilities. In order to process CTR, TPS
need:

 Operdb (database) already created (only CM is needed)

 Sector location loaded

Both requisites are obtained using OSS Data Gateway (ODG) software

This database has to be available not only when TPS is parsing the traces
but also during VoLTE RCA executions since it runs in the last step of
the TPS CTR processing and it’s when operdb with CM is used.

8.2.2.3 SQL Memory Management

If you are working with large set of data (>500 eNBs) you can face memory
issues when processing the CM and PM information with ODG and SQL.

Some parameters that you can change to be able to process these big data
files:

ODG:

Maximum memory used can be changed in Regedit which can be found by

searching regedit in start menu. Once open, look for the following path and
edit JvmMx within Java settings and Increase the value of the memory used.
 Ericsson Internal
GUIDELINE 105 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 120Memory increase in JvmMx Java settings

Another possibility is to modify the file JVM_MX.properties in the installation

folder of ODG by increasing the number of parallel processes. This can be
done in the installation folder, by default C:\Program Files\Ericsson\OSS Data
Gateway\OSS Data Gateway\configuration\Ericsson4G\input\properties, by
opening the file parallel.properties with a text editor and setting the
parallel.MaxProcessors depending on number of processors of the server and
Increase the parameter Parallel.MaxProcessorHeap64. The ODG service
must by “Stop and Start”.
 Ericsson Internal
GUIDELINE 106 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 121Changing number of maximum processors

8.2.3 Trace Processing Server (TPS)

It is in charge of processing the call traces obtained from the RNCs and
eNodeBs in order to extract fine-grained statistics of every call for advanced
troubleshooting as well as the Geo-location of the different events so that the
user can visualize problematic areas and make a more focused analysis. For
more information about handling Trace Processing Server, please refer to its
corresponding System Administrator Guide (SAG).

8.2.3.1 Installation

Trace Processing Server (TPS) is the Ericsson tool that will be used to
parse the CTR/UETR traces. It must be installed and running (along with PBO
Database Server as required for any other project where TPS is involved).

Note: PBO Database Server is the official name of the OperDB / XSQL.

Detailed information regarding how to install/deploy TPS, please refer to CPI

library Ericsson RAN Analyzer CPI Technical Library, “System
Administrator Guide for Trace Processing Server”.
 Ericsson Internal
GUIDELINE 107 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

For proper dimensioning and support of the HW required, please create a

request to SDT in the following link: SSR

(https://ericoll.internal.ericsson.com/sites/EDOS-DP_Portal/Pages/EDOS-DP-
Sales-Process.aspx)

8.2.3.2 TPS Customization for RCA

LTE CellTrace recordings, once they are activated, are usually stored in files
in the following folder of the OSS:

/var/opt/ericsson/nms_umts_pms_seg/segment1/CELLTRACE.

One file for each eNodeB and every period of 15 minutes will be stored there.
Trace Processing Server could retrieve the corresponding files directly if there
is direct connectivity from TPS to the OSS, otherwise the files should be
transferred to a different ftp server. A list of the events that must be activated
when recording LTE CTR traces from the eNodeBs is shown in

Note 1: Events highlighted in red are optional but recommended.

Table 19 Active events to record LTE CTR traces used for VoLTE RCA
TRACE_EVENTI
TRACE_EVENTNAME
D
3 RRC_RRC_CONNECTION_RE_ESTABLISHMENT_REQUEST
4 RRC_RRC_CONNECTION_RE_ESTABLISHMENT_REJECT
5 RRC_RRC_CONNECTION_RELEASE
7 RRC_MOBILITY_FROM_E_UTRA_COMMAND
8 RRC_RRC_CONNECTION_RECONFIGURATION
11 RRC_MEASUREMENT_REPORT
12 RRC_RRC_CONNECTION_SETUP_COMPLETE
13 RRC_RRC_CONNECTION_RECONFIGURATION_COMPLETE
24 RRC_CONNECTION_RE_ESTABLISHMENT
25 RRC_CONNECTION_RE_ESTABLISHMENT_COMPLETE
1025 S1_DOWNLINK_NAS_TRANSPORT
1027 S1_ERROR_INDICATION
1030 S1_HANDOVER_COMMAND
1034 S1_HANDOVER_REQUEST
1035 S1_HANDOVER_REQUEST_ACKNOWLEDGE
1036 S1_HANDOVER_REQUIRED
1038 S1_INITIAL_CONTEXT_SETUP_REQUEST
1039 S1_INITIAL_CONTEXT_SETUP_RESPONSE
1051 S1_ERAB_RELEASE_COMMAND
1054 S1_ERAB_SETUP_REQUEST
1055 S1_ERAB_SETUP_RESPONSE
 Ericsson Internal
GUIDELINE 108 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

TRACE_EVENTI
TRACE_EVENTNAME
D
1063 S1_UE_CONTEXT_RELEASE_COMMAND
1064 S1_UE_CONTEXT_RELEASE_COMPLETE
1065 S1_UE_CONTEXT_RELEASE_REQUEST
1067 S1_UPLINK_NAS_TRANSPORT
1080 S1_ERAB_RELEASE_INDICATION
2058 X2_HANDOVER_REQUEST
2059 X2_HANDOVER_REQUEST_ACKNOWLEDGE
2061 X2_UE_CONTEXT_RELEASE
3072 INTERNAL_PER_RADIO_UTILIZATION
3075 INTERNAL_PER_RADIO_UE_MEASUREMENT
3076 INTERNAL_PER_UE_TRAFFIC_REP
3077 INTERNAL_PER_UE_RB_TRAFFIC_REP
3079 INTERNAL_PER_CELL_TRAFFIC_REPORT
3081 INTERNAL_PER_RADIO_CELL_MEASUREMENT

3108 INTERNAL_PER_RADIO_UE_MEASUREMENT_TA

4097 INTERNAL_PROC_RRC_CONN_SETUP

4098 INTERNAL_PROC_S1_SIG_CONN_SETUP

4099 INTERNAL_PROC_ERAB_SETUP
4102 INTERNAL_PROC_HO_PREP_S1_OUT
4103 INTERNAL_PROC_HO_PREP_S1_IN
4104 INTERNAL_PROC_HO_EXEC_S1_OUT
4105 INTERNAL_PROC_HO_EXEC_S1_IN
4106 INTERNAL_PROC_INITIAL_CTXT_SETUP
4110 INTERNAL_PROC_HO_PREP_X2_OUT
4111 INTERNAL_PROC_HO_PREP_X2_IN
4112 INTERNAL_PROC_HO_EXEC_X2_OUT
4113 INTERNAL_PROC_HO_EXEC_X2_IN
4114 INTERNAL_PROC_ERAB_RELEASE
4121 INTERNAL_PROC_RRC_CONNECTION_RE_ESTABLISHMENT
4125 INTERNAL_PROC_UE_CTXT_RELEASE
4128 INTERNAL_PROC_UE_CTXT_FETCH
5153 UE_MEAS_INTRAFREQ1
5193 INTERNAL_EVENT_UE_MOBILITY_EVAL

Note 2: In order to verify if all prerequisites for VoLTE RCA are met, it is
recommended to process one ROP file of data after the TPS customization
steps have been completed. In the database generated in the server (output
of TPS processing, database name MPExxx), the following table (
events_eventid_counter) can be found and verified for the events.
 Ericsson Internal
GUIDELINE 109 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 122 List of events in events_eventid_counter

The list of events should match the list provided in section 8.2.4.1 LTE CTR
Events.

Note 3: Geolocation

In order to ensure that geolocation is available, the following query can be

used to quantify the geolocation percentage (calls being geo-located):

select mp.TRACE_START,PERIOD_ID,100*NCALLS_GEOLOCATED/NCALLS
from
xgeomanager_audit.measurement_period_statistics,xgeomanager_control.measu
rement_period mp
where mp.ID = PERIOD_ID

8.2.4 Requirements

8.2.4.1 LTE CTR Events for RCA

In order to guarantee optimum performance of Advanced & VoLTE RCA, all

required events must be activated when recording LTE CTR traces. The list of
the events used by Advanced & VoLTE RCA (A&V RCA) is shown in 8.2.3.2.

If any of those required events is not present, TPS will display a warning
message reporting the Id of the missing events (see Section 23.6).

Note 1: Advanced & VoLTE RCA is available for both CTR and UETR, only for Ericsson
LTE.

Note 2: Periodic measurements (UE_MEAS_INTRAFREQx) are optional

events but recommended. Periodic RF measurements enhance the RCA
output. The optimal configuration should be:

 ReportConfigEUtraIntraFreqPm maxReportCellsPm 8  8 cells reported

 ReportConfigEUtraIntraFreqPm reportAmountPm 0  Infinite

 Ericsson Internal
GUIDELINE 110 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 ReportConfigEUtraIntraFreqPm reportQuantityPm 1  BOTH

 ReportConfigEUtraIntraFreqPm reportIntervalPm 5  5120 ms

 ReportConfigEUtraIntraFreqPm measSelectionEUtraPm 0  Periodic

 ReportConfigEUtraIntraFreqPm triggerQuantityPm  RSRP

8.2.4.2 UE Fraction

UE Fraction represents the percentage of UEs for which the CTRs will be
collected.

8.2.5 Inputs

The following inputs are required in order to produce the VoLTE RCA output
files:

Mandatory:

 Sector Location

 eNodeBs

 Sectors

 Geographical coordinates (latitude, longitude)

 Antenna Azimuth per cell, sector

 Recent CM file

 Ericsson CTR/UETR Cell Traces

 VoLTE RCA events activated (listed in Table 19)

Recommended:

 100% UE Fraction (CTR)

 PM UE Periodic Measurements: Accurate RCA results

 Timing Advance: Geolocation

 Ericsson Internal
GUIDELINE 111 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.2.6 Advanced & VoLTE RCA

This report allows experts to analyze the performance of the cells from
different point of view and with different level of detail depending on whether it
is being used to get an overall idea of the performance or to
optimize/troubleshoot the network. This report is available in LTE Call
Analysis > Network Analysis > Advanced & VoLTE RCA.

Figure 123Advanced & VoLTE RCA Report in ERA

Advanced & VoLTE RCA (AVRCA) analyzes the calls in order to determine
the user-level problems and identify the most relevant issues at cell-level. In
particular, this report is focused on VoLTE calls and MBB connections that have
experienced a drop or a Radio Link Failure (RLF) that has been successfully re-
established by the Multi-Target RRC Connection Re-Establishment RAN feature.
These RLF are also commonly known as VoLTE soft drops or VoLTE Interruption.
To that end, this report is applied to those calls that meet one of the following
conditions:

 It is a VoLTE call.

 It is a MBB dropped connection with duration longer the 1 second and

at least has one measurement report (MR). Note that AVRCA provides
a detailed analysis about the RF conditions, so only those calls that
provide this information are analyzed, otherwise it would add noise in
the global analysis (e.g. lot of RF unknown).

The MBB calls are filtered because these are calls long enough to be
comparable to VoLTE calls so can be used to optimize LTE network when
VoLTE commercial traffic is still inexistent or low.

8.2.7 Output

In ERA, once the “Advanced & VoLTE RCA” opens in a new window, the
output contains a filter in the left and four tabs on the right:

 Market Level Analysis

 Call Level Analysis

 Worst Offenders
 Ericsson Internal
GUIDELINE 112 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Mobility Worst Offenders

Figure 124 shows the tabs and filter options

8.2.7.1 Market Level Analysis

Once the filter options are selected, this tab shows charts with market level
information containing:

 Category

 Category drilldown details

 RF conditions with percentage distribution

 Procedures

 Reestablishments

The charts are possible to export by selecting the option “Export Charts”
button at the bottom of the main window.

Figure 124Advanced & VoLTE RCA – Market Level Analysis (ERA)

 Ericsson Internal
GUIDELINE 113 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.2.7.2 Call Level Analysis

The call level analysis tab provides detailed information about the call flow
and messages exchanges contained in the CTRs.

Figure 125Advanced and VoLTE RCA – Call Level Analysis (ERA)

This is the main VoLTE RCA file used for VoLTE optimization analysis further
described in chapter 8.4.

Figure 125 shows a partial view of the “Call Level Analysis” tab and below is
the description of the fields in contained in this tab. A file also can be exported
from this output in order to be further analyzed.

IMSI

The user’s IMSI owner of the call.

Call (Subnetwork/Period/Call ID)

Name of the subnetwork in OSS/ Day (mm/dd/yy) hour (h:m:s) of the ROP/
Callid from CTR/UETR.

Period

Day (mm/dd/yy) hour (hh:mm:ss) of the ROP.

Latitude

Geographical location of last call event.

Longitude

Geographical Location of last call event.

Serving Cell

This field determines the cell that is serving the user in each moment.

Drop Timestamp

Time Call Ends ((mm/dd/yy) @ hour (hh:mm:ss)).

Termination Status
 Ericsson Internal
GUIDELINE 114 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Cause of Call Termination (e.g. Normal, IRAT, Drop Call, etc.).

Termination Reason

Detail of the call Termination (e.g. RLC Failure SRB, RRC Reconfiguration Timeout,
etc.).

Type

This field determines the type of failure detected by RCA:

 Active MBB Drop: It indicates that a Mobile Broadband connection has

dropped with data in UL/DL buffers at the release.

 Non active MBB Drop: It indicates that a Mobile Broadband connection

has dropped without data in UL/DL buffers at the release.

 VoLTE Drop: It indicates that a VoLTE connection has dropped.

 Active MBB RLF: It indicates that a MBB connection has experienced

a Radio Link Failure with data in UL/DL buffers.

 Non active MBB RLF: It indicates that a MBB connection has

experienced a Radio Link Failure without data in UL/DL buffers.

 VoLTE RLF: It indicates that a VoLTE connection has experienced a

Radio Link Failure.

RF Conditions

This field determines the RF condition of the user at the time of the failure
which is evaluated by means of RSRP and RSRQ. Possible values are:

 Bad Coverage: RSRP of the Serving Cell is low.

 Moderate Coverage: RSRP of the Serving Cell is moderate and RSRQ

of the Serving Cell is not low.

 Good Coverage: Both RSRP and RSRQ of the Serving Cell are high.

 High Interference: RSRQ of the Serving Cell is low.

 Moderate Interference: RSRP of the Serving Cell is high and RSRQ of

the Serving Cell is moderate.

 Lack of DL RF information: when there is no information about RSRP

and RSRQ of the Serving Cell.
 Ericsson Internal
GUIDELINE 115 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Lack of DL RF information - Incoming Handover: There is no

information about RSRP and RSRQ of the Serving Cell because the
call flow does not have the traces from the source cell (due to UE
Fraction or out of cluster) in order to determine the RF measurements
that triggered the HO procedure.

 Lack of DL RF information - Periodic meas disabled: There is no

information about RSRP and RSRQ of the Serving Cell because the
call has disabled the periodic measurement report. Note that this kind
of call has at least one measurement report in its signaling flow due to
mobility procedures.

 Lack of DL RF information - Low UL SINR: There is no information

about RSRP and RSRQ of the Serving Cell and the call drops when
the Serving Cell is activating TTI Bundling mode.

 Lack of DL RF information - Static Call: There is no information about

RSRP and RSRQ of the Serving Cell because there is not any
measurement report in the entire call flow.

 Lack of DL RF information - Right After Call establishment: There is no

information about RSRP and RSRQ of the Serving Cell because the
call drops just after the establishment and before the user can report
RF measurements.

 Lack of DL RF information - Right after Re-establishment: There is no

information about RSRP and RSRQ of the Serving Cell because the
call drops just after the re-establishment and before the user can
report RF measurements.

 Lack of DL RF information - Signaling flow incomplete: when there is

no information about RSRP and RSRQ of the Serving Cell because
the call flow is incomplete.

The default thresholds for Good and Bad Coverage/Interference thresholds

can be modified in the table rca_parameters TPS database
xgeomanager_data in table

Figure 126Modifiable RF thresholds

Procedures
 Ericsson Internal
GUIDELINE 116 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

It indicates the 3GPP procedure that was not completed and interrupted at the
time of the failure. Possible values are:

 RRC Reconfiguration missed: The RRC reconfiguration procedure has

not been completed; this means that the Serving Cell has sent the
RRC Reconfiguration message to the user but the RRC
Reconfiguration Complete has not been received.

 RRC Reconfiguration missed - TTI-Bundling Deactivation: A specific

case of RRC Reconfiguration missed, whose main purpose is to
deactivate TTI Bundling mode.

 RRC Reconfiguration missed - TTI-Bundling Activation: A specific

case of RRC Reconfiguration missed, whose main purpose is to
activate TTI Bundling mode.

 RRC Reconfiguration missed - Right after HO: When the RRC

Reconfiguration procedure initiated just after a successful HO is not
completed.

 RRC Reconfiguration missed - New measurements configuration: A

specific case of RRC Reconfiguration missed, whose main purpose is
to configure new measurements.

 RRC Reconfiguration missed - DRB Release: A specific case of RRC

Reconfiguration missed, whose main purpose is to release the DRB.

 RRC Reconfiguration missed - SCell modification: A specific case of

RRC Reconfiguration missed, whose main purpose is to modify SCell.

 Intrafreq X2 Handover: The intra-frequency handover initiated through

the X2 interface has failed.

 Interfreq X2 Handover: The inter-frequency handover initiated through

the X2 interface has failed.

 Intrafreq S1 Handover: The intra-frequency handover initiated through

the S1 interface has failed.

 Interfreq S1 Handover: The inter-frequency handover initiated through

the S1 interface has failed.

 SRVCC: The Single Radio Voice Call Continuity (SRVCC) procedure

has failed.

 Load Balancing Handover: The handover triggered due to load

balancing reasons has failed.

 No procedure on-going: There is not any on-going procedure.

 Ericsson Internal
GUIDELINE 117 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 No procedure on-going - A2 Active: There is not any on-going

procedure and the condition of A2 event (i.e. Serving becomes worse
than threshold) has been met.

Category

It is the highest level of categorization and it classifies the failure as:

 Mobility: When Procedures is a mobility process (i.e. Intrafreq X2

Handover, Interfreq X2 Handover, Intrafreq S1 Handover, Interfreq S1
Handover, SRVCC or Load Balancing Handover).

 Coverage: When RF Conditions is Bad Coverage or Moderate

Coverage.

 Quality: When RF Conditions is High Interference or Moderate

Interference.

 Good RF: When RF Conditions is Good Coverage.

 Lack of info to categorize: when there is not enough information to

determine the category.

Category drilldown

This field is the medium level of categorization and provides in-depth

information about Category. Thus, this class indicates either the status of the
measurements events (such as A2 search, A2 critical and so on) or the RF
conditions of serving and/or target cells (in case a mobility procedure was
initiated). Possible values are:

 No A2 triggered: The conditions of A2 event (i.e. Serving becomes

worse than threshold) has not been met.

 A2 triggered: The user has sent an event-triggered measurement

report because Event A2 has been met, indicating that Serving Cell
has become worse than threshold.

 Multiple A2 events: The user has sent several event-triggered

measurement report due to Event A2.

 A2 Search: The user has sent an event-triggered measurement report

the Event A2 "Search", indicating that the user entered the search
zone (i.e. RSRP provided by the Serving Cell drops below the
threshold for entering the search zone). This value is related to
Mobility Control at Poor Coverage feature.

 Multiple A2 Search: The user has sent several event-triggered

measurement reports associated with the Event A2 "Search". This
value is related to Mobility Control at Poor Coverage feature.
 Ericsson Internal
GUIDELINE 118 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 A2 Critical: The user has sent an event-triggered measurement report

because Event A2 Critical Coverage conditions has been met,
indicating that the user moved into critical coverage. This value is
related to Mobility Control at Poor Coverage feature.

 Multiple A2 Critical: The user has sent several event-triggered

measurement reports because Event A2 Critical Coverage condition
has been met, indicating that the user moved into critical coverage.
This value is related to Mobility Control at Poor Coverage feature.

 Low Serving RSRP: When Procedures is a mobility process and

RSRP of Serving Cell is worse than threshold.

 Low Target RSRP: When Procedures is a mobility process and RSRP

of Target Cell is worse than threshold.

 Low Serving & Target RSRP: When Procedures is a mobility process

and RSRP of Serving Cell and RSRP of Target Cell are worse than
threshold.

 Low Serving RSRQ: When Procedures is a mobility process and

RSRQ of Serving Cell is worse than threshold.

 Low Target RSRQ: When Procedures is a mobility process and RSRQ

of Target Cell is worse than threshold.

 Low Serving & Target RSRQ: When Procedures is a mobility process

and RSRQ of Serving Cell and RSRQ of Target Cell are worse than
threshold.

 Low Serving RSRP & Target RSRQ: When Procedures is a mobility

process and RSRP of Serving Cell and RSRQ of Target Cell are
worse than threshold.

 Low Serving RSRQ & Target RSRP: When Procedures is a mobility

process and RSRQ of Serving Cell and RSRP of Target Cell are
worse than threshold.

 Serving Good RSRP/RSRQ: When Procedures is SRVCC and both

RSRP and RSRQ of Serving Cell are better than threshold.

 Good RSRP/RSRQ: All available RSRP and RSRQ measurements

are better than Threshold.

Dominance

This field indicates if there is a dominance issue, and in that case, it

determines its type. In particular, it is considered that there is a dominance
issue when at least three cells have been measured with very similar RSRP
values.
 Ericsson Internal
GUIDELINE 119 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Lack of Dominant: It means that the user has measured several cells
with similar RSRP values, but they are all bad values.

 Excessive Overlapping: It means that the user has measured several

cells with similar RSRP values, but in this case, the measured cells
have high values of RSRP, causing an excessive overlapping among
their coverage areas.

TTI bundling

This field indicates the status of TTI Bundling for this user (i.e. ON or OFF).

LTE neighbor observability

This field indicates whether there are LTE cells available and measured by
the user at the moment of the failure and, in that case, it determines the type
of LTE cell (e.g. Intra or Inter). Examples of labels that can be found in this
class are:

 No Suitable Neighbor Found: The user has not reported

measurements of any other LTE cell.

 NB better than serving – HO not triggered: The user has detected at

least one LTE cell and it is better than the serving, but the HO was not
triggered.

 NB measured but weaker than serving: The user has detected at least
one LTE cell, but its signal is weaker than serving signal (in terms of
RSRP).

IRAT neighbor observability

It indicates whether there are iRAT cells available and measured by the user at
the moment of the failure. Examples of labels that can be found in this class are:

 IRAT NB Not Found: The user has not reported measurements of any other
iRAT cell.

 IRAT meas reported but SRVCC Not triggered: The user with a VoLTE call
has reported measurements of other iRAT cells but the SRVCC procedure
was not triggered.

 IRAT meas reported but iRAT Mobility Not triggered: The user has reported
measurements of other iRAT cells but the iRAT Handover was not triggered.

HO preparation
 Ericsson Internal
GUIDELINE 120 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

In case of failure during the preparation phase, this column indicates the
reason of the procedure for HO Preparation cause (INTRA/INTER/SRVCC)
determined by the trace content.

HO execution

In case of failure in the execution phase, this column indicates the reason
procedure for HO Execution cause (INTRA/INTER/SRVCC) determined by
the trace content.

S1 interface

In case of failure in S1 interface, this field indicates its cause:

 S1 interface down

 S1 RESET Procedure launched

 S1 ERROR INDICATION

HO issues

This field determines the cause of the HO issue (if there is any):

 PCI Confusion

 PCI Potential Interferer

 HO to non-best PCI

 HO Ping-Pong

 Cell Range issue

Partial HO

In this column, the value “Partial HO: QCI=1 lost during HO” indicates that the
ERAB of QCI 1 has dropped during the HO.

RSRP

This field indicates if the RSRP of the serving cell is below the threshold.

RSRQ

This field indicates if the RSRQ of the serving cell is below the threshold.

Call HARQ Rate

 Ericsson Internal
GUIDELINE 121 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

This field indicates if the HARQ Error Rate is considered too high either in
downlink (DL), uplink (UL) or both. Possible values are:

 HARQ Error Rate - DL Failed

 HARQ Error Rate - UL Failed

 HARQ Error Rate - UL and DL Failed

Call UL SINR

This field indicates if UL SINR is considered too low either in PUCCH or

PUSCH. Possible values are:

 Low UL SINR PUCCH

 Low UL SINR PUSCH

 Low UL SINR

Cell UL RSSI

This field indicates if UL RSSI in serving cell is considered too high either in
PUCCH or PUSCH. Possible values are:

 High RSSI in PUCCH

 High RSSI in PUSCH

 High RSSI in PUCCH and PUSCH

PDCCH utilization

In this column, the value “High PDCCH Utilization” indicates the PDCCH
utilization in serving cell is high.

PRB utilization

This field indicates if the PRB utilization is considered too high either in
downlink (DL), uplink (UL) or both. Possible values are:

 High DL PRB Utilization

 High UL PRB Utilization

 High DL & UL PRB Utilization

Multitarget Reestab
 Ericsson Internal
GUIDELINE 122 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

This column indicates the result of the “MultiTarget re-establishment. Possible

values are:

 MultiTarget re-establishment REJECTED: It indicates the call

attempted to reestablish its connection after a radio link failure, but it
was rejected. MTRE to same cell: It indicates the call reestablished its
connection after a radio link failure in the same cell where the radio
link failure took place. Note that the Multi-Target RRC Connection Re-
Establishment feature extends the basic feature RRC Connection Re-
Establishment with more cases where RRC Connection Re-
Establishment is supported. Thus, Re-Establishment on the same
source cell is considered a particular subcase of Multi-Target RRC
Connection Re-Establishment.

 MTRE to Unprepared cell: It indicates the call reestablished its

connection after a radio link failure in an unprepared cell.

 MTRE to serving cell in HO: It indicates the call reestablished its

connection in serving cell during ongoing handover.

 MTRE to Target cell in HO: It indicates the call reestablished its

connection in target cell during ongoing handover.

 MTRE to Unprepared cell in HO: It indicates the call reestablished its

connection in unprepared cell during ongoing handover.

Miscellaneous

In this column extra information is provided. In particular, it indicates if there

was a PDCCH UL Sync Failure.

Serving RSRP

This is the RSRP value of the serving.

Serving RSRQ

This is the RSRQ value of the serving.

Distance

The Distance (m) from Serving sector at call release (Last TA Reported).

LTE Target Cell

The Global Cell ID (GCELLID) of the target cell of the unsuccessful HO.

LTE Target PCI

The target cell’s PCI of the unsuccessful HO.

 Ericsson Internal
GUIDELINE 123 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

LTE Target RSRP

The target cell’s RSRP of the unsuccessful Handover.

LTE Target RSRQ

The target cell RSRQ of the unsuccessful HO.

Number of A2

This field indicates the total number of A2 events that were sent before the end
of the connection, distinguishing among A2, A2 search or A2 critical.

SRVCC info

This field provides extra information about the target of the inter-technology mobility
procedure, in addition, depending on the technology of the target cell (i.e. 3G or 2G),
the information is different:

 SRVCC Target 3G RNCid / 2G LAC

 SRVCC Target 3G Carrier / 2G Band

 SRVCC Target 3G Cell/2G Cell

Trigger by

The network element that triggered the release (MME/eNB)

Time elapsed cell

The connection’s time duration in the last serving cell.

Also, doing right click on one of the available messages, a submenu appears
with options to continue the analysis of that call, see Figure 127. It is possible
to copy, export to a csv or excel formats and view call details.

Figure 127 Call Level Analysis – Submenu (ERA)

 Ericsson Internal
GUIDELINE 124 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

The “View Call Details” option shows more information related to the specific
“Call ID” selected as charts and all CTR related messages for that “Call ID”,
by opening another window contained two tabs:

 Charts

 Call Signaling

The tab “Charts” contains charts with timeline for the specific Call ID selected
as shown in Figure 128.

Figure 128Call Level Analysis, Call Details –Charts tab (ERA)

The tab “Call Signaling” contains all the CTR messages related to that
specific call ID selected and other detailed information where is possible to
check into Trace Contents for each message. This is very valuable
information for troubleshooting specific call issues, as shown in Figure 129
Call Level Analysis, Call Details – Call Signaling tab (ERA).
 Ericsson Internal
GUIDELINE 125 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 129 Call Level Analysis, Call Details – Call Signaling tab (ERA)

8.2.7.3 Worst Offenders

The “Worst Offenders” tab contains charts and other information about top
worst offender cells sorted by total number of combined MBB and VoLTE
drops and RLFs.

As shown in Figure 130, for each Serving cell this tab will show charts related
to:

 Number of occurrences per category

 Number of occurrences per Category drilldown

 PDCCH Utilization

 UL SINR

 Dominance

 PRB Utilization

 UL RSSI
 Ericsson Internal
GUIDELINE 126 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 130Advanced and VoLTE RCA – Worst Offenders (ERA)

8.2.7.4 Mobility Worst Offenders

The “Mobility Worst Offenders” tab contains charts and other information
about top worst offender cells sorted by total number of combined MBB and
VoLTE drops and RLFs.

As shown in Figure 131, for each Serving cell this tab will show charts related
to:

 Number of Mobility occurrences per Category Drilldown

 Target mobility – Handover Execution

 Target Mobility – Handover Preparation

 Ericsson Internal
GUIDELINE 127 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 131 Advanced and VoLTE RCA – mobility Worst Offenders (ERA)

8.3 Analytics with Tableau

Analytics applications can be used with the VoLTE RCA output file in order to
maximize the analysis and finding patterns of behavior or issues in the
network.

Tableau is mainly used to perform analyses involving VoLTE RCA output

“Call Level Analysis” tab for the following components explained in details in
chapter 8.4 for the following:

 Market Level VoLTE RCA output Analysis

 Filtered Scattered Plots

 Worst Offenders correlation with VoLTE RCA output

To aid in using the RCA output efficiently and maximize its potential, a
Tableau template has been developed but there are multiple ways to use
VoLTE RCA and Tableau. Projects with different scopes will use UIs
developed for their own specific use cases. Some of the main analysis sheets
are described and shown in this chapter below.
 Ericsson Internal
GUIDELINE 128 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.3.1.1 Connecting files to tableau

The dashboard is set up to update automatically as long as the file format of

RCA is kept the same, especially the headers. There are three main files
that need to be added to tableau.

Export File from ERA report and follow these steps in tableau:

1. Right click on the main drops sheet

Figure 132Tableau data selection

2. Click ‘Edit data source’

Figure 133Tableau spreadsheet option

3. Drag the new sheet over the old sheets, and all tables/dashboards will
update automatically. In the snapshot above, drag the drops file and
the SIP_drops_saved files onto drop_details_Oct21 and
sip_drops_NFL_CTR_daily respectively

8.3.1.2 Limitations

The current dashboard has some limitations. It’s not currently possible to view
the sectors visually on a map within this dashboard and that would still have
to be plotted out in ERA GIS or some other tool. Ideally, we would be able to
view all the sectors on a map and click on them to view the RCA and
neighbors to arrive at a complete solution.
 Ericsson Internal
GUIDELINE 129 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.4 Ways of Working

The Figure 134 Overall VoLTE RCA Process shows the overall process
developed as results of best practices and lessons learned when using the
VoLTE RCA functionality during VoLTE Optimization projects.

Figure 134Overall VoLTE RCA Process

The following steps are recommended when using VoLTE RCA during VoLTE
Optimization Service:

8.4.1 Market Level KPIs analysis

This is a comprehensive analysis of the overall market KPIs with focus on

specific VoLTE related KPIs assessed from the PM files.

Below is a suggested list of KPI categories to analyze with main categories

listed but not limited to those. It is importance to get a perception on how the
overall performance of the market is:

 Retainability (main category)

 Accessibility

 Integrity

 Mobility (main category)

 Availability

 Utilization

For reference, Chapter Error: Reference source not found contains detailed
information for VoLTE related KPIs.
 Ericsson Internal
GUIDELINE 130 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.4.2 Market Level VoLTE RCA output Analysis

This is the analysis of the overall market for utilizing the output from the
VoLTE RCA. Some finding during this phase can be directly correlated with
the finding in the KPI market analysis. Below is a list of the main fields
suggested to be used in the file exported from tab “Call Level Analysis” in
“Advanced & VoLTE RCA” option in ERA.

 Type and RF Conditions

 Procedures

 Category

 Category Drilldown

 Band

Typically, in markets with more than one Band, there is clearly a specific band
that outperforms the other(s) due to issues like Interference, pollution,
coverage, capacity. For each band, these issues should be identified during
this phase of analysis.

Figure 135Market Level RF Conditions per Band (Tableau)

It is also useful to identify main buckets for categories classified as Coverage,

Mobility and/or Quality.
 Ericsson Internal
GUIDELINE 131 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 136 Category vs. RF Conditions (Tableau)

Also, as part of this step it is required to identify the worst performers

“Procedure” that are failing as well as the procedure drilldown analysis for
further background information.

Figure 137 Category vs. Procedure (Tableau)

It is also useful to collect information when TTI Bundling was ON or OFF. This
analysis can provide certain visibility of issues, e.g. when there was a drop
due to coverage and/or high interference but TTI bundling was OFF. Details
about TTI Bundling in poor radio conditions are described in chapter Error:
Reference source not found.

The Figure 138 Procedure Drilldown illustrates the category drilldown per
band and per type (VoLTE RFL or drop).
 Ericsson Internal
GUIDELINE 132 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 138Procedure Drilldown (Tableau)

SRVCC should also be analyzed during this phase in order to identify

potential issues.

Figure 139SRVCC Details (Tableau)

Chapter 8.2.7.2 contains detailed explanation for all the fields in the VoLTE
RCA output.
 Ericsson Internal
GUIDELINE 133 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.4.3 Filtered Scattered Plots

Once the VoLTE RCA market level analysis is complete, further analysis and
investigation can be achieved by utilizing scatter plots. Below is a list of the
main fields suggested to be used in the file exported from tab “Call Level
Analysis” in “Advanced & VoLTE RCA” option in ERA.

 Worst Procedures

 RSRP/RSRQ

 Geolocation

 Band

 Type (Drop / RLF)

 Distance

During this phase, the main issues identified in the market level analysis
chapter 8.4.2, should be further investigated and scatter plots are optimum for
this purpose.

It is recommended during this analysis to “play” with the scatter plots in

Tableau and take advantage of its flexibility. For example, the chart shown in
Figure 140 Scatter plot for Procedure, Category, Band and type can be used
to select and filter different bands, types and categories. It is also useful for
comparison between bands or categories and correlate with RSRP/RSRQ
levels.
 Ericsson Internal
GUIDELINE 134 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 140Scatter plot for Procedure, Category, Band and type (Tableau)

It is also important during this phase to check each category individually since
the scatter charts will be cleaner. It should be able to provide clear
RSRP/RSRQ levels which will provide the background information needed to
isolate certain problem reasons e.g. drops happening during Inter-Frequency
handover mostly in high interference (RSRQ) scenario.

The findings and observations made in this section will be critical for the next
VoLTE RCA step covered in chapter 8.4.5.
 Ericsson Internal
GUIDELINE 135 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 141Scatter Plot (Tableau)

8.4.4 Worst Offenders KPIs

This is the same KPIs contained in chapter 8.4.1 however at cell level and
focusing on the worst offender cells for relevant VoLTE related KPIs.

This is part of the input required to perform the analysis in chapter 8.4.5.

8.4.5 Worst Offenders correlation with VoLTE RCA output

This is a similar analysis of chapter 8.4.2, however using specific charts and
views with the objective of correlating results with the WO KPI identification in
chapter 8.4.4.

Below is a list of the main fields suggested to be used in the file exported from
tab “Call Level Analysis” in “Advanced & VoLTE RCA” option in ERA.

 Geolocation

 Sector Analysis for procedures

 Ericsson Internal
GUIDELINE 136 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Sector Drops vs RLF (VoLTE)

 TTI Bundling

 RSRP / RSRQ

The Figure 142 show a dashboard with a worst offender cell list in the left
sorted by VoLTE drops but it is also possible to select using other criteria.
Upon selecting the VoLTE drops number, all other charts are dynamically
updated. It is possible to look into geolocation by RF conditions, scatter RF
conditions for those VoLTE drops, procedures used by the time of the drop,
TTI bundling (ON/OFF) information, timeline when drops occurred and RF
conditions vs procedure and band.

Figure 142Worst offender Analysis per cell (Tableau)

Chapter explains and details the different possibilities of charts and analysis
that could be achieved from the VoLTE RCA output file.
 Ericsson Internal
GUIDELINE 137 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

8.4.6 Parameter Analysis for Worst Offenders and/or Market level

Once a correlation between WO KPI and WO VoLTE RCA cells can be

established and issues are identified, there is a wide range of possible
outcomes of proposals for optimization depending on the issue found,
customer strategy and standards, optimization strategy to list a list.

 Baseline check

 Deviation from standard

 Parameter changes

 Market Level or localized

There could be optimization proposal are outside of parameter optimization

scope:

 Antenna tilt, azimuth change

 External interference

 Hardware problems

 Configuration issues

8.5 Field References

Below is a field reference in order to support this documentation and usage of

VoLTE RCA.

8.5.1 AT&T Reference

This section will cover an example utilizing ERA with VoLTE RCA and
Tableau in order to perform VoLTE optimization for a market.

In this specific market, the phases explained in the entire chapter 8.4 was
followed in order obtain findings and provide recommendations.

The Figure 143 shows charts of findings related to retainability (VoLTE drops)
and the main reason identified is due to coverage.

VoLTE Drops – Procedures

 IntraFreq HO is triggered by RSRQ. This setting in a coverage limited

scenario may delay IntraFreq HO and make executions to fail due to
high interference
 Ericsson Internal
GUIDELINE 138 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 700 BAND drops in poor coverage when “No procedure on-going”.

This behavior is expected since SRVCC is OFF.

 1900 & 2100 BAND drops in poor coverage when “No procedure on-
going”. This behavior is not expected since IFHO should be performed
to the coverage 700 BAND.

The TTI Bundling can be increased to get over coverage limitations and
prevent some of the drops to happen.

Figure 143Retainability analysis

 Ericsson Internal
GUIDELINE 139 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 144RLF and VoLTE drops per Category

The KPI analysis for retainability is shown in Figure 145

Figure 145WO Retainability

As shown in Figure 146 Top 1 WO , shows for top one offender that most
drops are happening when No procedure on-going in very poor coverage and
IFHO happening mostly with neighbor 700BAND cell instead of co-located
bands.
 Ericsson Internal
GUIDELINE 140 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 146Top 1 WO analysis A

As shown in Figure 147, the parameter check analysis shown that WO

CLL01772_2A_1 seems very up-tilted (RET=1) and recommendation for this
specific case was to down tilt cell from RET 1 to 2 or move VoLTE IFHO
trigger from -118 to -112dBm by changing Service Triggered Mobility
parameters:

 a5Threshold1RsrpOffset from 0 to 6dB

 a5Threshold2RsrpOffset from 0 to 6dB

 Ericsson Internal
GUIDELINE 141 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 147Top 1 WO analysis B

 Ericsson Internal
GUIDELINE 142 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

9 VoLTE Audio Gap Optimization

9.1 Overview

The main objective of the VoLTE Audio Gap Optimization module is to tune VoLTE related
features and parameters in order to eliminate or mitigate effects such as one-way audio
experience or abruptly muted or distorted audio by reducing the length and/or number of
VoLTE silent periods that are created in the RAN domain. As a result of conducting this
module, the voice quality and hence the VoLTE end-user experience is improved. This
module does not cover audio gap optimization caused by issues outside the RAN.

It is strongly recommended to carry out VoLTE initial tuning as well as VoLTE related
fundamental mobility optimization before addressing the audio gap issue.

Inputs:

 VoLTE network performance, in particular VoLTE audio gaps (output from VoLTE
S-KPI benchmarking module)

 OSS Data – Configuration Management (CM): OSS data containing all RAN OSS
configuration data (parameters)

 OSS Data – Performance Management (PM): OSS data containing all performance
management data (counters) for KPI analysis

Outputs:

 Feature and parameter recommendations to improve VoLTE audio gaps

Tools:

 Performance monitoring tool: ITK / EEA / RCA / KPI monitoring tool from customer

9.2 Root Cause for Audio Gaps

Audio gaps occur when there is continuous packet loss either in the downlink and/or
uplink. Although this can be also related to issues at the device or at the core and
transport network, the root cause can often be found in the RAN. This is because fading
dips, high interference, or coverage holes can cause major VoLTE silent periods. In this
regard, one can distinguish the following scenarios:

 Unstable radio conditions (for a short period of time)

 Ericsson Internal
GUIDELINE 143 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

 Unstable radio conditions → Radio link failure → Cell selection → Successful Re-
establishment

 Unstable radio conditions → Radio link failure → Cell selection → Rejected re-
establishment → Successful resume (service request or tracking area update)

An example of a drive test analysis is shown in Figure 148, where high interference (poor
RSRQ) caused a radio link failure, followed by a RRC re-establishment which, however,
failed. As a result, a long silent period of three seconds was detected.

In general, the main contributors to an audio gap are unstable radio conditions, i.e. the
time spent in poor radio conditions until declaring radio link failure, and the cell selection
process duration. After declaring radio link failure, the UE performs cell selection and tries
to re-establish a RRC connection as shown in Figure 149. Please note that the actual
recovery process following a successful cell selection does not take a lot of time compared
to the initial triggering of the radio link failure.

Figure 148: Poor RF (RSRQ) causing RRC re-establishment and audio gap
 Ericsson Internal
GUIDELINE 144 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 149: Poor RF (RSRQ) causing RRC re-establishment and audio gap

9.3 Audio Gap Counters and KPI Definition

9.3.1 Audio gap Counter Overview

In L15B new counters have been introduced which allow observability of the VoLTE voice
quality in terms of measured silent periods occurred during ongoing calls. In this regard,
the PDF counters pmPdcpInactSecDlVolteDistr and pmPdcpInactSecUlVolteDistr for the
downlink and uplink, respectively, provide a distribution of silent periods on the QCI1
bearer with a granularity of one second per cell. An overview of the counters is shown in
Table 20 below.

Counter name Description

Distribution of the number of times there has been greater than 1
second without receiving an SDU at the DL PDCP layer on a QCI1
DRB (cell level PDF MCS counter).
PDF ranges:
[0]: [1...2[ s
pmPdcpInactSecDlVolteDist [1]: [2...3[ s
r [2]: [3...4[ s
[3]: [4...5[ s
[4]: [5...6[ s
[5]: [6...7[ s
[6]: [7...8[ s
[7]: [8...9[ s
[8]: [9...10[ s
[9]: >=10 s
Distribution of the number of times there has been greater than 1
second without receiving an SDU at the DL PDCP layer on a QCI1
DRB (cell level PDF MCS counter).
PDF ranges:
[0]: [1...2[ s
pmPdcpInactSecUlVolteDist [1]: [2...3[ s
r [2]: [3...4[ s
[3]: [4...5[ s
[4]: [5...6[ s
[5]: [6...7[ s
[6]: [7...8[ s
[7]: [8...9[ s
[8]: [9...10[ s
[9]: >=10 s
Total number of normal E-RAB releases per cell per QCI. Bearer
release is initiated by MME with normal release cause via S1
message E-RAB Release Command or UE Context Release
pmErabRelDlInactGapQci Command proceeded by inactivity longer than a configurable
threshold in DL direction.
Note: only QCI1 related releases due to inactivity are pegged in L15B
pmErabRelUlInactGapQci Total number of normal E-RAB releases per cell per QCI. Bearer
release is initiated by MME with normal release cause via S1
message E-RAB Release Command or UE Context Release
Command proceeded by inactivity longer than a configurable
threshold in UL direction.
 Ericsson Internal
GUIDELINE 145 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Note: only QCI1 related releases due to inactivity are pegged in L15B

Table 20: Audio gap counter overview

The PDF counters are stepped when a QCI1 bearer receives a PDCP SDU and more than
one second has passed since the previous PDCP SDU was received on that QCI1 bearer.
Figure 150 illustrates the stepping of the counters.

Figure 150: Audio gap counter stepping

The counter pmPdcpInactSecUlVolteDistr measures audio gaps occurred in the radio

uplink for the corresponding cell as shown in the Figure 151.

The downlink counter pmPdcpInactSecDlVolteDistr is more complex because it only

records gaps in reception of voice packets to be delivered in the downlink direction. This is
because the measurement point is located at the eNB and cannot take into account the
downlink radio impact from its cell. As a result, the counter is actually not measuring audio
gaps in the radio downlink of the corresponding cell which is illustrated in Figure 152, but
instead measuring gaps introduced by the radio environment of the opposite call leg or the
interfacing network backbone. It is therefore recommended to consider only
pmPdcpInactSecUlVolteDistr for the cell-based evaluation of audio gaps caused by the
corresponding radio link.
 Ericsson Internal
GUIDELINE 146 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 151: Uplink audio gap measurement

Figure 152: Downlink audio gap measurement

9.3.2 Audio Gap Counter Limitations

There are certain limitations regarding the audio gap counters as the eNB has no
knowledge of the actual VoLTE call state and its impact on the RTP packet flow. There are
two factors which can negatively influence the stepping of the audio counters: call holding
and alerting. For the latter case, one can distinguish the following two scenarios:

Scenario 1: No RTP packet transmission during alerting

 UE A calls UE B
 UE B is not connected to the network (alerting only)
 UE B hangs up the call

UE A calls UE B and UE B is at the stage of ringing. At this moment, a QCI1 bearer has
already been established for UE B located in cell B. In this case the last bin of the audio
 Ericsson Internal
GUIDELINE 147 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

gap counters is pegged as indicated in Figure 153. This is because the last bins are
always pegged when a QCI1 bearer is established and released without any RTP traffic. In
the example below the UE context is released for UE B without any RTP packet
transmission at the mobile terminating side.

Figure 153: Counter behavior without any RTP packet transmission

Scenario 2: Erroneous terminal behavior during alerting

 UE A calls UE B
 UE B is connected to the network and answers the call (e.g. after 5s)

Different terminal behavior is another factor which can negatively impact the audio gap
counters. It has been observed that some terminals start sending RTP packets at Session
Progress (SDP a=sendrecv) until Session Progress (PEM sendonly) message is received
and then stop sending RTP packets until 200 OK (INVITE) message is received. This gap
causes the UL audio counter to peg. Other terminals, however, start sending continuously
RTP packets after Session Progress (SDP a=sendrecv) or after the 200 OK (INVITE)
message. For these terminals, the UL audio counters will not be pegged as shown in
Figure 154. Figure 155 illustrates the different terminal behavior of the iPhone 6s and
Sony Xperia Z5.

Figure 154: Counter behavior in case of erroneous terminal behavior during alerting
 Ericsson Internal
GUIDELINE 148 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 155: Comparison between iPhone 6s and Xperia Z5 behavior during alerting

Apart from the alerting case, call holding can also influence negatively the stepping of the
audio gap counters. In order to mitigate the impact engineer should filter out bins with
abnormal counts corresponding to the average call holding time.

As an example, for an operator in RNEA the average call holding time was determined to
be approximately between 4-6 seconds. In order to detect abnormal counts corresponding
to call holding, the share of counts corresponding to audio gaps of 4-6 seconds for each
sample of the uplink distribution counter pmPdcpInactSecUlVolteDistr was determined as
follows:

100∗A [ 3 ] + A [4 ]
ULaudio gaps 4 ¿ 6 s rate [ % ] =
A [ 0 ] + A [1]+…+ A [8 ]

A=pmPdcpInactSecUlVolteDistr

Samples of the uplink distribution counter pmPdcpInactSecUlVolteDistr with a 4-6 seconds

count rate exceeding 80% have been filtered out in order to mitigate the effect of abnormal
pegging due to call holding as shown in Figure 156. It is, however, important to note that
this approach is only an estimation (hence might not be accurate) and might not be
applicable to other markets or networks.
 Ericsson Internal
GUIDELINE 149 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 156: Filtering of abnormal counts corresponding to call holding

In summary, the audio gap counters might be influenced by certain alerting scenarios
depending on the terminal type and their penetration in the corresponding network.
Clearly, the above examples showed that the last bin of the audio gap counters,
corresponding to a gap larger than 10 seconds, includes many events that are not related
to audio quality issues and therefore should be excluded from any optimization analysis.

9.3.3 Counter Correlations

For optimization and acceptance purposes it can be useful to demonstrate a strong

correlation between the number of audio gaps (voice quality) and other related R-KPIs.
This can allow optimization and acceptance by demonstrating improvement in other R-KPI
metrics that are easier to measure. As an example, the audio gap counter might fluctuate
highly on cell level in case the number of VoLTE users is relatively small and the
improvement trend might not be clear. In this case, other R-KPIs such as the QCI1 uplink
PDCP packet loss rate could be used to demonstrate the performance improvement.

Due to the limitations outlined in section 9.3.2, the audio gap counters are clearly
impacted by alerting and call holding events. Thus, obtaining clear correlations with other
R-KPIs might not be straightforward. Therefore, a potential methodology of how a
correlation can be observed between certain R-KPIs, such as QCI1 uplink PDCP packet
loss rate, PUSCH SINR, or RRC re-establishment attempts, and audio gaps, is illustrated
in Figure 157 – Figure 159.

Figure 157: Audio gaps decrease with decreasing UL packet loss rate (same # of E-RABs)
 Ericsson Internal
GUIDELINE 150 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 158: Audio gaps decrease with increasing PUSCH SINR (same # of E-RABs)

Figure 159: Audio gaps decrease for decreasing RRC re-establishment attempts (same # of
E-RABs)

9.3.4 Silent Experience KPI Definition

The audio gap counters might fluctuate highly on cell level in case the number of VoLTE
users is relatively small. Therefore, it is recommended to introduce a new KPI which takes
the number of VoLTE users (in the following corresponding to the number of QCI1 E-
RABs) into account in order to evaluate the audio gap performance. This KPI is defined as
the UL silent time per VoLTE user:

1000∗Total silent time [s] 1000∗A [ 0 ]∗1.5 s + A[1]∗2.5 s +

Silent experience per VoLTE user [ ms ] = =
Total QCI 1 ERABs ( pmErabQciLevSum

A=pmPdcpInactSecUlVolteDistr

MO Counter name Description

 Ericsson Internal
GUIDELINE 151 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

EUtranCellFDD pmPdcpInactSecUlVolteDistr Distribution of the number of times there has been

greater than 1 second without receiving an SDU at
the UL PDCP layer on a QCI1 DRB.
EUtranCellFDD pmErabQciLevSum The sum of the number of simultaneous E-RABs
per QCI within the measurement period.

Please note that in the formula above the last bin of the UL audio gap counter is excluded
due to influence of alerting events as discussed in section 9.3.2. Moreover,
pmErabQciLevSum is divided by its sampling rate of 5 seconds in order to obtain the total
number of QCI1 E-RABs.

9.4 VoLTE Audio Gap Optimization Trial Examples

Optimization of VoLTE audio gaps should focus on improving VoLTE coverage and
mitigating inter-cell interference, thus improving signal quality. As a result, radio link
failures can be mitigated and VoLTE packet loss rate in the downlink and/or uplink can be
improved, leading to a reduced number of VoLTE audio gaps.

One important aspect of the optimization approach can be Radio Coverage Optimization in
order to improve coverage and signal quality by means of tuning RF characteristics as
outlined in Chapter Error: Reference source not found. Another important aspect is radio
feature and parameter optimization which is the focus of the of this section.

The following VoLTE Audio Gap Optimization activities have been performed in VoLTE
networks and shown to reduce audio gaps in some scenarios:

 RLC retransmission optimization

 QCI1 uplink BLER optimization
 Enhanced PDCCH link adaptation BLER for QCI1 optimization
 SRVCC and intra-frequency mobility optimization (see section 6.3.3.2)
 Inter-frequency HO trigger A5 to A3 and RSRQ filter coefficient optimization (see
section 6.2.1.2)
 Introduction of uplink FSS for QCI1 and QCI5
 RLF timer optimization

In this regard, the new parameter settings have been first implemented at cluster level in a
dense urban area for all three LTE frequency bands (B1, B3, B8) prior to network-wide
rollout. It should be noted that the parameter trial improvements may vary based on
specific network conditions as well as based on the VoLTE UE penetration. Therefore, it is
recommended to carry out a pre-analysis on potential impacts based on network statistics
followed by a trial in small / medium-sized clusters prior to implementation across the
network.
 Ericsson Internal
GUIDELINE 152 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

9.4.1 RLC Retransmission Optimization

The objective of this optimization is to improve the robustness of SRB (RRC messages)
and QCI5 (IMS signaling) bearer transmissions by increasing the number of uplink and
downlink RLC retransmissions. The QCI1 bearer is not directly affected by this change
because it is transmitted by means of the RLC Unacknowledged Mode (UM). However, in
case the QCI5 or QCI9 bearer drops for any reason during a VoLTE call, the QCI1 bearer
will also be released. Since VoLTE audio gaps are mainly detected during very poor radio
conditions, e.g. at the very cell-edge, handover signaling messages carried by the SRB
can benefit from RLC optimization under those conditions.

Trial parameter setting:

Bearer type Parameter Baseline Trial
Description
value value
Data Radio dlMaxRetxThreshold Maximum number RLC re-transmissions 8 16
Bearer in DL before stopping and indicating to
RRC that the RLC threshold is reached.
Data Radio ulMaxRetxThreshold Maximum number RLC re-transmissions 8 16
Bearer in UL before stopping and indicating to
RRC that the RLC threshold is reached.
Signaling dlMaxRetxThreshold Maximum number RLC re-transmissions 8 16
Radio Bearer in DL before stopping and indicating to
RRC that the RLC threshold is reached.
Signaling ulMaxRetxThreshold Maximum number RLC re-transmissions 8 16
Radio Bearer in UL before stopping and indicating to
RRC that the RLC threshold is reached.

Trial results:
 Improvement in QCI5 / QCI9 retainability. This is important because if a QCI5 or
QCI9 bearer is dropped during a VoLTE call, the QCI1 bearer will be also released
 Improvement in DL/UL PDCP packet loss rate for QCI5
 Silent experience rate as well as the total number of occurred UL audio gaps
reduced significantly
 No impact on downlink or uplink user throughput or PRB utilization by increasing
the number of retransmissions
Difference in total
(excluding
of UL audio gaps# bin)
last

packet
Avg. loss rate
DL PDCP
QCI5 [%] Ericsson Internal
GUIDELINE 153 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino
UL audio last
# of(excluding 2017-01-10 D
gaps
Total

bin) Friday Monday Tuesday TC

0.6 Baseline
RLC opt.
0.4

Difference in silent 0.2

per [%]
VoLTE user
experience
0.0
0%

-20%

-40% -47.88% -45.23%

per VoLTE user [ms]
Silent experience -60% -69.40%
4 6 8 10 12 14 16 18 20 22 4 6 8 10 12 14 16 18 20 22 4 6 8 10 12 14 16 18 20 22
Time Time Time

Figure 160: QCI5 DL PDCP packet loss rate

TC
60 Baseline
RLC opt.
40

20
0

0%

-50% -56.87%

1500

1000

500

20%

0%

-20%

-40% -40.30%
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Time

Figure 161: Silent experience per VoLTE user / # of UL audio gaps averaged over all trial day
retainability QCI5 [%]

Ericsson Internal
Avg. ERAB

GUIDELINE 154 (169)

Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Friday Monday Tuesday TC

Baseline
30
RLC opt.

20

10

0
0%

-20%

-40.15% -38.29%
-40% -43.52%

7 9 11 13 15 17 19 21 7 9 11 13 15 17 19 21 7 9 11 13 15 17 19 21
Time Time Time

Figure 162: QCI5 E-RAB retainability

9.4.2 QCI1 UL BLER Optimization

The objective of this optimization is to improve UL VoLTE specific coverage by means of

decreasing the UL BLER target. As a result, a more robust (lower) MCS is selected which
should lead to a more robust UL transmission hence reducing the UL voice packet loss
rate and improving VoLTE audio gap performance.

Trial parameter setting:

Parameter Description Baseline value Trial value
ulHarqVolteBlerTarget The UL BLER target to be 10% 5%
used for all UEs with a QCI1
bearer

Trial results:
 Improvement in UL packet loss rate for QCI1 users, hence less voice packets are
lost in general which improves voice quality
 Improvement in VoLTE quality based on UL VoLTE packet delay satisfactory rate
 Reduction of number of UL audio gaps and silent experience rate
 No negative impact on QCI1 retainability, UL HARQ BLER (VoLTE users << MBB
users), DL / UL user throughput, or PRB utilization
 packet loss QCI1 [%]
Difference
Avg. UL in total
PDCP
(excluding
of UL
# bin)
last
audio gaps Ericsson Internal
GUIDELINE 155 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

gaps
Total UL audio last
# of(excluding
Thursday Friday Monday Tuesday Wednesday TC
Baseline
UL BLER opt.
bin)
0.15

0.10

0.05
Difference in silent
per[%]
VoLTE user
experience 0.00

0%

-20% -21.34%
-27.56% -25.99%
per VoLTE user [ms] -32.21% -33.83%
Silent experience
08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20
Time Time Time Time Time

Figure 163: QCI1 UL PDCP packet loss rate

30 TC
Baseline
20 UL BLER opt.

10

0%

-20%
-32.28%

200

100

0%

-20%

-40% -44.96%

9 10 11 12 13 14 15 16 17 18 19 20 21 22
Time [hours] (weekly comparison)

Figure 164: Silent experience per VoLTE user / # of UL audio gaps averaged over all trial day
Average VoIP quality
Ericsson Internal
per UE [%]
GUIDELINE 156 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Thursday Friday Monday Tuesday Wednesday TC

100 Baseline
UL BLER opt.

95

90
3% 2.70%

2% 1.74% 1.81%
1.47%
1.23%
1%

0%

08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20
Time Time Time Time Time

Figure 165: VoLTE quality based on UL VoLTE packet delay satisfactory rate

9.4.3 Enhanced PDCCH Link Adaptation BLER for QCI1 Optimization

The objective of this optimization is to improve VoLTE coverage by making the PDCCH
transmission more robust for VoLTE users. This can be achieved by setting a lower target
error rate for the PDCCH link adaptation for QCI1 users, hence reducing the PDCCH
decoding failures. As a result, the downlink voice packet loss rate should decrease,
improving voice quality and VoLTE audio gaps. It should be noted that in general a lower
target BLER for PDCCH link adaptation will increase the probability of allocating more
CCEs (more robust transmission). However, in case the highest aggregation level (8
CCEs) is already used for most of the VoLTE users, decreasing the PDCCH BLER would
have no further effect.

Trial parameter setting:

Parameter Description Baseline value Trial value
pdcchTargetBlerVolte PDCCH target error rate for UEs 22 6
with any bearer mapped to a QCI
with serviceType of VoIP.

Trial results:
 PDCCH error rate for QCI1 users is slightly improved, hence improvement in UL
grant and DL assignment success rate
 Improvement in DL packet loss rate for QCI1, leading to improved voice quality
 Improvement in silent experience rate and number of UL audio gaps observed

 As expected the amount of used CCEs for QCI1 users increased. However, there
was no impact on the avg. PDCCH CCE utilization (VoLTE users <<< MBB users)
 No negative impact on other KPIs such as QCI1 retainability
 Avg. DL PDCP packet
loss QCI1 [%]
Ericsson Internal
GUIDELINE 157 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Difference in total
CCEs used # of
for QCI1

Thursday Friday Monday Tuesday Wednesday TC

Baseline
0.2 ePDCCH LA opt.

0.1
Total # of CCEs used for

0.0
QCI1 20%

0%

-20%
-30.54% -29.67% -29.91%
-38.71%
Avg. PDCCH CCE -40%
utilization [%] -53.56%

08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20
Time Time Time Time Time

Figure 166: QCI1 DL PDCP packet loss rate

Thursday Friday Monday Tuesday Wednesday TC

6 Baseline
ePDCCH LA opt.
4

40M

20M

0M
100% 95.27%
82.40%
66.95% 66.93% 72.12%

50%

0%

-50%
08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20 08 11 14 17 20
Time Time Time Time Time

Figure 167: PDCCH utilization and number of CCEs for QCI1

 Ericsson Internal
per VoLTE user [ms]
Silent experience
GUIDELINE 158 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

30 TC
Baseline
20 ePDCCH LA opt.

10

0
20%

0%

-20%
-33.80%

150

100

50

0%

-20%

-40% -41.11%
9 10 11 12 13 14 15 16 17 18 19 20 21 22
Time [hours] (weekly comparison)

Figure 168: Silent experience per VoLTE user / # of UL audio gaps averaged over all trial day

9.4.4 Introduction of Uplink FSS for QCI1 and QCI5

The objective of this optimization is to avoid high inter-cell interference for VoLTE users by
frequency selective scheduling of VoLTE UEs in different parts of the frequency band
where the inter-cell interference is lower and their channel qualities are better. As a result,
uplink voice packet loss can be mitigated leading to an improvement in VoLTE audio gaps.

A potential drawback of using UL FSS for VoLTE is that the PRB allocation could be
scattered along the frequency domain, rather than consecutively allocated. This is
because of the small data volume required for VoLTE. The impact, generally, might not be
severe as MBB smartphone traffic also often consists of small packet transfers. However,
peak uplink throughput might be impacted, in particular during network performance
benchmarks.

It is important to note that it is not recommended to activate sounding reference signal

(SRS) allocation with VoLTE DRX. This is because DRX prevents a UE from sending SRS
which results in inaccurate SINR measurements, inaccurate power control, inaccurate
MCS allocated as well as inaccurate TTI bundling triggering. Furthermore, it should be
noted that downlink FSS for QCI1 and QCI5 has been also trialled, however, without any
 Ericsson Internal
GUIDELINE 159 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

clear improvements. One reason for that is DL FSS relies on the aperiodic CQI report from
UE on PUSCH. Those CQI reports are requested when the UE has downlink data to be
scheduled. For small VoLTE packet transfers CQI report may not be requested which
limits the effectiveness of DL FSS for VoLTE.

Trial parameter setting:

Parameter Description Baseline value Trial value
resourceAllocationStrategy Defines the resource RESOURCE_FAIR FREQUENCY_SELECTIVE
(QCI1 / QCI 5) allocation strategy of
the QoS Class
Identifier (QCI)
srsAllocationStrategy (QCI1 / Allow allocation of DEACTIVATED DEACTIVATED
QCI 5) sounding reference
signals for a UE

Trial results:
 Improvements in silent experience rate, number of VoLTE audio gaps, uplink
packet loss rate, and VoIP integrity for QCI1, in particular for cells suffering from
narrowband interference
 No negative impact on UL/DL RF related KPIs, QCI1 retainability or uplink /
downlink user throughput

Figure 169: Example of a cell suffering from narrowband interference and the improvement
in UL packet loss by applying UL FSS
 Avg. UL PDCP packet
loss QCI1 [%]
Difference in total
(excluding
of UL
# bin)
last
audio gaps Ericsson Internal
GUIDELINE 160 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

gaps UL audio last

# of(excluding
Monday Tuesday Wednesday Thursday TC
Total
Baseline
bin) 1.5 UL FSS opt.

1.0

0.5
Difference in silent
per [%]
VoLTE user
0.0
experience

50%

0%

per VoLTE user [ms] -50% -68.54%

-83.63% -84.41%
Silent experience
-93.45%
-100%
7 10 13 16 19 22 7 10 13 16 19 22 7 10 13 16 19 22 7 10 13 16 19 22
Time Time Time Time

Figure 170: QCI1 UL packet loss rate for all trial site suffering from high inter-cell
interference

100 TC
Baseline
UL FSS opt.
50

0
50%

0%

-50%
-70.04%

200

100

100%

0%

-67.15%
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Time
 [%]

Avg. VoIP quality Ericsson Internal

per UE [%] GUIDELINE 161 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Figure 171: Silent experience per VoLTE user / # of UL audio gaps averaged over all trial day

Monday Tuesday Wednesday Thursday TC

Baseline
100
UL FSS opt.

80

60
40% 37.06% 36.22%
26.28%
20%
9.31%

0%
7 10 13 16 19 22 7 10 13 16 19 22 7 10 13 16 19 22 7 10 13 16 19 22
Time Time Time Time

Figure 172: Voice quality indicator for all trial site suffering from high inter-cell interference

9.4.5 RLF Timer Optimization

The objective of this optimization is to find the best balance between RLF avoidance and
accelerated RLF recovery. One parameter controlling this balance is the T310 timer. If a
UE detects N310 consecutive out-of-sync indications based on an out-of-sync PDCCH
BLER threshold it will start T310 timer. Furthermore, in case the UE detects N311
consecutive in-sync indications prior to the T310 timer expiring, then the timer is stopped
and the link is treated as being up shown in Figure 173.

Figure 173: RLF T310 timer overview

By shortening the T310 timer the overall RLF recovery process can be accelerated by
attempting a RRC connection re-establishment already at an earlier stage. As a result,
VoLTE audio gap time might be reduced. However, a shorter T310 timer increases the risk
 Ericsson Internal
GUIDELINE 162 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

of declaring a RLF too soon, although there would have been a chance of getting back in-
sync. This, on the other hand might increase the VoLTE audio gap time.

Trial parameter setting:

Parameter Description Baseline value Trial value
t310 Waiting time for radio link 2000ms 1000ms
Difference in total
attempts QCI1# [%]
of re-estab. failure. Used by the UE.

Trial results:
 Number of RRC connection re-establishment attempts for QCI1 increased, and
Total # of re-estab.
attempts QCI1 hence also the QCI1 E-RAB drops
 Long VoLTE silent periods between 4-9s slightly improved, however total number
of VoLTE audio gaps and silent experience rate did not improve
 The trial value for the T310 timer was not recommended for network-wide roll-out
because the balance between RLF declaration and fast recovery did not improve

Wednesday Thursday Friday TC

80 Baseline
T310 opt.
60

40

20
0
200% 157.1%
131.3%
100%
48.7%

0%

10 12 14 16 18 20 10 12 14 16 18 20 10 12 14 16 18 20
Time Time Time

Figure 174: Number of QCI1 RRC connection re-establishment attempts

 Difference in total #
UL audio gaps
ofretainability E2E
Avg. ERAB
QCI1 [%] Ericsson Internal
(4-9s)
GUIDELINE 163 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino
Total # of UL audio 2017-01-10 D
gaps (4-9s)
Wednesday Thursday Friday TC
Baseline
1.0 T310 opt.

Difference in total
(excluding
of UL
# bin)
last
audio gaps 0.5

0.0
107.1%
100% 94.1% 89.4%

50%
gaps
Total UL audio last
# of(excluding
0%

bin) 9 11 13 15 17 19 21 9 11 13 15 17 19 21 9 11 13 15 17 19 21
Time Time Time

Figure 175: QCI1 E-RAB retainability

Wednesday Thursday Friday TC

Baseline
150 T310 opt.

100

50
0
70.6%
60.5%
50% 41.0%

0%

-50%
40
30

20

10
0
50%

0%

-50% -63.6% -61.5%

-75.0%
10 12 14 16 18 20 10 12 14 16 18 20 10 12 14 16 18 20
Time Time Time

Figure 176: Total UL audio gaps

Silent experience per
VoLTE user [ms]

Ericsson Internal
GUIDELINE 164 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

Wednesday Thursday Friday TC

40 Baseline
T310 opt.
30

20

10
0
100% 94.7% 80.7%
57.7%
50%

0%
-39.5% -35.4%
-46.0%
-50%
9 11 13 15 17 19 21 9 11 13 15 17 19 21 9 11 13 15 17 19 21
Time Time Time

Figure 177: Silent experience per VoLTE user

9.4.6 CFI Setting Optimization during Handovers

The objective of this optimization is to improve handover execution success rate which
can also have an impact on voice quality and audio gaps.

The optimization is achieved by forcing CFI 3 when scheduling UEs performing

Handovers. The use of 3 symbols for the PDCCH channel can help mitigate interference
from neighbour cells with high PDCCH usage.

Trial parameter settings:

Parameter Description Baseline value Trial value
EUtranCellFdd. Controls NO_HO_PROHIBIT_CF HO_PROHIBIT_CFI_1 or
AdaptiveCfiHoProhibitMode adaptive I HO_PROHIBIT_CFI_1_AND_2
CFI to
avoid
using The appropriate value will
CFI=1 or depend on the setting of
CFI=1,2 pdcchCfiMode to
when CFI_AUTO_MAXIMUM_2 or
scheduling CFI_AUTO_MAXIMUM_3
UEs that
are in
handover

Trial results:
Average Handover Execution Success Rate improved in the following scenarios
 High PDCCH/CFI utilization neighbor cells
 Low down tilt neighbor cells
 Ericsson Internal
GUIDELINE 165 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

There was no improvement shown between co-sited sectors with high interference

Figure 178: Handover Execution Failure Rate

The chart below shows that there is no noticeable change in CCE utilization from the CFI
change.

Figure 179: PDCCH Utilization

 Ericsson Internal
GUIDELINE 166 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

10 Acronyms
BLER Block Error Rate

DBS Delay Based Scheduling

DCR Drop Call Rate

DRX Discontinuous Reception

FSS Frequency Selective Scheduling

HARQ Hybrid Automatic Repeat Request

HOIT Handover Interruption Time

ISP In Service Performance

ITK ISP Tool Kit

KPI Key Performance Indicator

MCS Modulation and Coding Scheme

PDCCH Physical Downlink Control Channel

QCI QoS Class Identifier

RAN Radio Access Network

RLC Radio Link Control

RoHC Robust Header Compression

RSRP Reference Signal Received Power

RSRQ Reference Signal Received Quality

SPS Semi Persistent Scheduling

SRB Signaling Radio Bearer

SRS Sounding Reference Signal

TTI Transmit Time Interval

UM Unacknowledged Mode

ViLTE Video over LTE

VoLTE Voice over LTE

 Ericsson Internal
GUIDELINE 167 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

11 References
[1] VoLTE Radio and Transport Assessment - Service Delivery Instruction

[2] 6/154 43-HSC12034 Uen, VoLTE E2E Troubleshooting Guide

[3] 5/154 43-HSC12034 Uen, VoLTE IMS Troubleshooting Guide

[4] 9/154 43-HSC12034 Uen, VoLTE Packet Core Troubleshooting Guide

[5] 7/154 43-HSC12034 Uen, VoLTE RAN Troubleshooting Guide

[6] Tool: Moshell 10.0t

[7] Tool: ITK R2.20.1

[8] Tool: FlowFox 3.5.9

[9] Tool: pmAnalyzer 0.8

[10] LTE & MS Troubleshooting Wiki

[11] L14A CPI: Flow Charts for Counters

[12] 3GPP TS 23.401 (Release 9): GPRS enhancements for E-UTRAN Access

[13] L14A CPI: TTI Bundling

[14] L14A CPI: PDCCH Power Boost

[15] L14A CPI: Enhanced PDCCH Link Adaptation

[16] L14A CPI: Delayed Based Scheduling and Grant Estimation

[17] L14A CPI: Robust Header Compression

[18] L14A CPI: Efficient DRX/DTX for Connected UE

[19] L14A Calstore: Measuring VoLTE/SRVCC/CSFB Service Performance in Customer

Networks

[20] L14A Calstore: Performance Acceptance Criteria Guidelines for VoLTE

[21] 22105-FGC 101 2207 Rev A, E2E IP Audit and Optimization

[22] Acceptance Gateway: VoLTE E2E Solution Acceptance

[23] Iperf

[24] Ericsson Device and Application Verification: VoLTE Device Verification Service
 Ericsson Internal
GUIDELINE 168 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

[25] VoLTE Initial Tuning: Technical Guideline

[26] 115/1550-10/FCP1039669 Uen, LRAN Radio Network Load Management Guidelines

 Ericsson Internal
GUIDELINE 169 (169)
Prepared (Subject resp) No.

Tony Stanley, Philipp Frank, Sergio Andres Vanegas 1/10260- FAF102643

Approved (Document resp) Checked Date Rev Reference

BNESJAB/Remo Agostino 2017-01-10 D

12 Revision History

Date Version Description Main updates Author

26/08/2015 Rev. A Initial version EPA/GCD Tony Stanley
24/08/2016 Rev. B VoLTE audio gap  Added Chapter 8 EEM/GCD Philipp Frank
optimization update  Updates on Chapters
5.2.1, 5.3.3, 7.4, 7.5, and
9
 Document re-formatting
 Move trial results to
atoms
11/10/2016 Rev C1 Added VoLTE Jean Claude Kondo,
RCA/xTrace Javier Lopez
Chapter
15/11/2016 Rev C2 VoLTE Audio Gap  Added trial settings back PRS/NDO/PM Remo
& Mobility into doc Agostino
Optimization
Chapters
23/11/2016 Rev C3 Rewrite of Radio Sergio Andres Vanegas
Coverage
Optimization
25/11/2016 Rec. C4 L16B Updates  EPA/GCD Tony Stanley
10/01/2017 Rev D Compiled versions Remo Agostino
C1-C4 into single
TG