Optimization Guide To VoLTE Voice Quality

Optimization Guide to VoLTE
Voice Quality
Issue 01
Date 2017-02-20
(FOR INTERNAL USE ONLY. DO NOT SEND THIS DOCUMENT OR COMPLETE
CONTENTS IN THE DOCUMENT TO CUSTOMERS)
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2017. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2017-02-20) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Optimization Guide to VoLTE Voice Quality 1 VoLTE MOS Optimization Guide
1 VoLTE MOS Optimization Guide
1.1 Definition
Mean Opinion Score (MOS) is a key performance indicator (KPI) for evaluating the voice
quality of a communication system. Generally, the voice quality is good if the MOS is greater
than or equal to 4, and the voice quality is acceptable if the MOS is greater than or equal to 3.
The MOS defined by China Mobile is a MOS that is obtained from the drive test (DT) and is
calculated using the AMR WB-based POLQA algorithm.
The MOS defined by China Mobile is described as follows:
China Mobile only has a MOS test standard for the voice service, but does not have a
universal MOS test standard for the video service. Therefore, the VoLTE MOS test currently
applies only to the voice service.
In the current scenarios of China Mobile, AMR-WB is used for calls between VoLTE
subscribers to achieve high definition (HD) voice experience, and AMR-NB (same as the
codec used in the CS domain) is used for CS services between VoLTE and 2G/3G subscribers.
Therefore, in a MOS test, calls between VoLTE subscribers are initiated to test the voice
quality when AMR-WB is used as the voice codec.
The MOS defined by China Mobile is a MOS that is obtained from the DT and is calculated
using the P.863 algorithm. China Mobile requires that the MOS test tools be supplied by
DingLi and CDS. In the current phase, HTC M8T is used as the test UE, and Huawei Probe
Assistant (PA) can be used for routine optimization.
1.2 Recommended Value Range and Current Status

 China Mobile requires that the target MOS meet the following requirements in the DT:
The ratio of the MOS greater than 3.0 must exceed 80% at the initial stage and 85% at
the mature stage of commercial use.
 The following table lists the current network status in some cities where HTCM8 is used
as the test UE.
Issue 01 (2017-02-20) Huawei Proprietary and Confidential 1

Local Test IMS DRA PCRF HSS EPC Averag Averag RTP Avera
Networ Equipmen e RSRP e SINR Packe ge
k t (MO) (MO) t Loss MOS
Rate
(%)
(MO)
Beijing CDS Huawe Huawe Nokia Nokia Nokia -89.881 13.862 0.51% 3.631
Huawei i i Siemen Siemens Siemens
s
Beijing CDS Huawe Huawe Nokia Nokia Huawei -88.544 14.353 0.66% 3.606
ZTE i i Siemen Siemens
s
Changsha DingLi ZTE ZTE ZTE ZTE Huawei -89.321 16.728 0.38% 3.85
Huawei
Changsha DingLi ZTE ZTE ZTE ZTE ZTE NA NA 0.27% 3.83
ZTE
Shenzhen CDS Huawe Huawe Huawei Ericsso Ericsso -90.569 13.621 1.14% 3.661
Huawei i i n n
1.3 Traffic Measurement Related to eNodeBs

 VQIs in traffic measurement
On the eRAN 8.1, VQIs can be used to check the cell-level voice quality and analyze the
network-level voice perception of subscribers to judge the cell-level voice subscriber
experience. VQI values are calculated by eNodeBs based on wireless performance and
certain algorithms. To collect VQIs, you need to run the following command to enable
the voice quality tracking algorithm:
MOD ENODEBALGOSWITCH: VQMAlgoSwitch=VQM_ALGO_SWITCH_ON;
Table 1-1 Main VQIs
VQI Description
L.Voice.VQI.UL.Excellent.Times Number of times the uplink voice quality is Excellent
L.Voice.VQI.UL.Good.Times Number of times the uplink voice quality is Good
L.Voice.VQI.UL.Accept.Times Number of times the uplink voice quality is Accept
L.Voice.VQI.UL.Poor.Times Number of times the uplink voice quality is Poor
L.Voice.VQI.UL.Bad.Times Number of times the uplink voice quality is Bad
L.Voice.VQI.DL.Excellent.Times Number of times the downlink voice quality is
Excellent
L.Voice.VQI.DL.Good.Times Number of times the downlink voice quality is Good

VQI Description
L.Voice.VQI.DL.Accept.Times Number of times the downlink voice quality is Accept
L.Voice.VQI.DL.Poor.Times Number of times the downlink voice quality is Poor
L.Voice.VQI.DL.Bad.Times Number of times the downlink voice quality is Bad
L.Voice.E2EVQI.Excellent.Times Number of times E2E VQIs are Excellent
L.Voice.E2EVQI.Good.Times Number of times E2E VQIs are Good
L.Voice.E2EVQI.Accept.Times Number of times E2E VQIs are Accept
L.Voice.E2EVQI.Poor.Times Number of times E2E VQIs are Poor
L.Voice.E2EVQI.Bad.Times Number of times E2E VQIs are Bad
E2E VQIs can be measured if the eRAN version is eRAN11.1 or later.

The following table lists the voice quality intervals.
MOS Interval Corresponding to VQI Values Voice Quality Level
MOS > VQMAlgo.VqiExcellentThd (Default: 4) Excellent

VQMAlgo.VqiGoodThd (Default: 3) < MOS ≤ Good
VQMAlgo.VqiExcellentThd (Default: 4)
VQMAlgo.VqiPoorThd (Default: 2) < MOS ≤ Accept
VQMAlgo.VqiGoodThd (Default: 3)
VQMAlgo.VqiBadThd (Default: 1) < MOS ≤ Poor
VQMAlgo.VqiPoorThd (Default: 2)
MOS ≤ VQMAlgo.VqiBadThd (Default: 1) Bad
 VoLTE uplink packet loss rate

According to 3GPP TS 36.314, the VoLTE uplink packet loss rate is the ratio of the
accumulated number of lost PDCP SDU packets to the total number of received PDCP
SDU packets within a measurement period. A lost packet refers to a PDCP SDU that is
not successfully received on the air interface, and only the user-plane DTCH data is
considered.
KPI Related KPI Calculation Measurement Calculation Formula Explanation to
Formula Used by Period Used by Huawei Calculation
China Mobile Formula Used
by Huawei
VoLT Number of PDCP.NbrPktLossUl. 15 minutes L.Traffic.UL.PktLoss.Lo Total number of
E uplink 1/PDCP.NbrPktUl.1 ss.QCI.1[1526727961]/L uplink PDCP
uplink packets lost x 1000000 .Traffic.UL.PktLoss.Tot. SDU packets of
packet in a cell QCI.1[1526727962] x the DRB service
loss where QCI is 1000000 that are lost in a
1 cell where the

Formula Used by Period Used by Huawei Calculation
China Mobile Formula Used
by Huawei
rate (PDCP.NbrP Total number of
ktLossUl.1) discarded uplink
traffic PDCP
Total number SDUs for DRB
of uplink services in a cell
packets in a with a QCI of 1
cell where in a cell
QCI is 1 [1526727961]/N
(PDCP.NbrP umber of
ktUl.1) expected uplink
PDCP SDUs for
services carried
on DRBs with a
QCI of 1 in a
cell
[1526727962] x
1000000
 VoLTE downlink packet loss rate

According to 3GPP TS 36.314, the VoLTE uplink packet loss rate is the ratio of the
accumulated number of lost PDCP SDU packets to the total number of received PDCP
SDU packets within a measurement period. A lost packet refers to a PDCP SDU that is
not successfully received on the air interface, and only the user-plane DTCH data is
considered.
Formula Used Period Used by Huawei Calculation
by China Formula Used
Mobile by Huawei
VoLTE Number of PDCP.NbrPktLo 15 minutes L.Traffic.DL.PktUuLoss. Total number of
downlin downlink ssDl.1/PDCP.Nb Loss.QCI.1[1526727934] downlink PDCP
k packet packets lost in a rPktDl.1*100000 /(L.PDCP.Tx.Disc.Trf.SD SDU packets of
loss rate cell where QCI 0 U.QCI.1[1526726833]+L the DRB service
is 1 .PDCP.Tx.TotRev.Trf.SD that are lost in a
(PDCP.NbrPkt U.QCI.1[1526727889])*1 cell where the
LossDl.1) 000000 QCI is 1
[1526727934]/(N
Total number umber of
of downlink downlink service
packets in a cell SDUs lost at the
where QCI is 1 PDCP layer in a
(PDCP.NbrPkt cell where the
Dl.1) QCI is 1
[1526726833] +
Number of
downlink PDCP
SDU packets of

the DRB service

in a cell where
the QCI is 1
[1526727889]) x
1000000
1.4 Traffic Measurement Related to the CN

1.4.1 IMS-Related Traffic Measurement
IMS NEs do not directly measure the MOS of the voice quality. However, the IMS edge node,
P-CSCF, provides KPIs that measure the quality of the IP bearer network between the UE and
P-CSCF.
Measurement unit: ABCF Access Network IP QoS Measurement
 ABCF Access Network IP QoS LosRate Average
 ABCF Access Network IP QoS LosRate Max)
 ABCF Access Network IP QoS LosRate[0%, 1%)
 ABCF Access Network IP QoS LosRate[10%, 100%]
 ABCF Access Network IP QoS RoundTrip Average
 ABCF Access Network IP QoS RoundTrip Max
 ABCF Access Network IP QoS RoundTrip1[0,50)
 ABCF Access Network IP QoS RoundTrip2[50, 100)
 ABCF Access Network IP QoS RoundTrip3[100, 200)
 ABCF Access Network IP QoS RoundTrip4[200, -)
 ABCF Access Network IP QoS Jitter Average
 ABCF Access Network IP QoS Jitter Max
 ABCF Access Network IP QoS Jitter1[0,40)
 ABCF Access Network IP QoS Jitter2[40, 120)
 ABCF Access Network IP QoS Jitter3[120, 200)
 ABCF Access Network IP QoS Jitter4[200, -)
 ABCF Access Network IP QoS Mos Average
 ABCF Access Network IP QoS Mos Min
 ABCF Access Network IP QoS Mos MAX
 ABCF Access Network IP QoS MOS1[0.0, 3.0)
 ABCF Access Network IP QoS Send RTP Packets
 ABCF Access Network IP QoS Rcv RTP Packets
 ABCF Access Network IP QoS Send RTP Packets Bytes

 ABCF Access Network IP QoS Rcv RTP Packets Bytes
This measurement unit helps measure the actual quality of the IP bearer network between the
UE and P-CSCF during a VoLTE session.
1.4.2 EPC-Related Traffic Measurement

138413091 PGW downlink user traffic discarded in packets (APN):
This measurement item refers to the number of downlink user-plane data packets of a specific
APN received by the P-GW in a measurement period.
138413072 PGW incoming downlink user traffic in packets (APN):
136316011 SGW downlink user traffic discarded in packets (APN):
This measurement item refers to the number of downlink data packets of a specific APN that
the S-GW discards in a measurement period.
136316007 SGW incoming downlink user traffic in packets (APN):
APN received by the S-GW in a measurement period.
136316009 SGW uplink user traffic discarded in packets (APN):
This measurement item refers to the number of uplink data packets of a specific APN that the
S-GW discards in a measurement period.
136316001 136316001 SGW incoming uplink user traffic in packets (APN):
This measurement item refers to the number of uplink user-plane data packets of a specific
APN received by the S-GW in a measurement period.
138413089 PGW uplink user traffic discarded in packets (APN):
This measurement item refers to the number of uplink data packets of a specific APN that the
PGW discards in a measurement period.
138413066 PGW incoming uplink user traffic in packets (APN):
This measurement item refers to the number of uplink user-plane data packets of a specific
1.5 Test and Evaluation Methods

1.5.1 Test Specifications
 China Mobile test specifications
− Test equipment
Two test methods are available:
− Manual test equipment (PC connected to an external mobile phone)

− Using the ATU connected to an external mobile phone

Use the manual test equipment or ATU test equipment approved by China Mobile. It
is prohibited to use products not approved by China Mobile.
The test equipment is connected to the external commercial terminal HTC M8T.
− Test settings
Enable the 4G Wi-Fi connection on test mobile phones, and use the default
self-adaptive settings.
Use the mobile phones (terminals) to call each other. Operations, including dialing,
call receiving, and call releasing, are completed in an automatic manner.
Each conversation lasts 180 minutes, and the call interval is 30 seconds. If a call is
not connected or dropped, initiate the next call at the interval of 30 seconds.
− Test scenario
Pay close attention to two scenarios: indoor and outdoor urban areas.
− Data processing
In all tests, use the automatic test platform provided by the Huawei headquarters for
unified data processing.
The platform supports MOS scoring using the AMR WB-based POLQA algorithm.
 Test optimization tool
According to China Mobile's definition, the MOS is the DT MOS evaluated using the
POLQA algorithm. The figure below shows cable connections between the test terminals
and MOS box.
As shown in the preceding figure, two VoLTE terminals are connected to a PC where the
DT software is installed. One MOS box (no model is specified in the China Mobile test
specifications) is connected to the PC.
Huawei provides the following test tools: Probe (DT software), Mate7/HTC M8, and
MOS box.
The Probe license can be applied internally, but the POLQA license used for the MOS
test must be purchased and bound to the PC.
 How to check the MOS in the Probe
Among the terminal DT data, pay close attention to "MOS Average". To check the MOS,
start the Probe, choose View > MOS > Speech Quality Evaluation. To check auxiliary
KPIs, choose LTE > VoLTE Parameters.

1.5.2 CN Tools
1.5.2.1 SmartTestKit
The SmartTestKit is a VoLTE terminal dialing test tool developed by the CN VoLTE
integrated service team.
The SmartTestKit introduction and related product document are available in the following
path at www.support.huawei.com:
Support > Product Support > Core Network Common > Core Network Common > CSI
The figure below shows the voice quality test interface of the SmartTestKit:

The SmartTestKit uses the P.862 algorithm to evaluate the voice quality, and currently does not support
P.863. Therefore, if calls use the AMR WB codec, the voice quality evaluation result may be inaccurate.
The test result is for reference only, and cannot be used for acceptance.
1.5.2.2 CN Nastar
After VoLTE3.2, which passed GA in the first half year of 2016, was released, the CN
NaStar2.0 is released for the CCE product. The CN Nastar collects and summarizes in real
time the call history records (CHRs) generated by NEs in the IMS domain, analyzes CHRs,
and then outputs reports.
For the VoLTE3.2, a CHR records the media plane quality detected on the SBC and the MOS
of each VoLTE session. Based on data in these CHRs, the CN Nastar implements the
following functions:
 Take statistics and analyze MOSs of sessions by location or time segment.
 Query the media plane quality and MOSs recorded in CHRs based on the specified
subscriber number.
For details about the analysis method, see the product documents after a version (CCE
V100R003C30 or later) is released.
Product documents of the CCE are available in the following path at
www.support.huawei.com:
Support > Product Support > Core Network Common > Core Network Common > OSS >
CCE
To use the CN Nastar, the CCE must be deployed and the CN Nastar license is available. The CN Nastar
applies to a site where the CCE is deployed.
1.5.2.3 Tools on the EPC Side

On the EPC side, Discovery PS is recommended for MOS evaluation and analysis. Discovery
PS is an online tool that uses the built-in UFDR data source of the UGW9811. Therefore, this
tool applies only to Huawei S-GW/P-GW. The UGW9811 uses the DPI module to detect SIP
and RTP/RTCP packets and obtain the voice codec type, delay, jitter, and packet loss rate. It
uses the E-Model to calculate the voice MOS and determines whether one-way audio problem
exists based on the packet loss rate, and records the calculated voice quality information and
related QoS parameters in the UFDR.
Discovery PS displays the average MOS and QoS parameters related to the MOS.
KPIs displayed on Discovery PS interface include:
 Average VoLTE voice uplink MOS
 Proportion of abnormal VoLTE voice uplink MOSs (%)
 Average VoLTE voice downlink MOS
 Proportion of abnormal VoLTE voice downlink MOSs (%)
Related QoS parameters include the delay, jitter, and packet loss rate.
The GA phase of Discovery PS was passed in quarter 1 of 2016, and Discovery PS applies to
UGW9811V900R013C00 or a later version.

For details about how to use Discovery PS to analyze the VoLTE voice quality, see the
reference document [1] PS PSS V100R007C00 VoLTE Evaluation and Optimization Guide.
1.5.3 Wireless Network Tools

On the wireless network, VQIs are measured in the traffic measurement. The figure below
shows the measurement result, which can be used as the reference for the cell voice quality.
The OMStar and Nastar support automatic analysis on the VoLTE voice quality problems on
the wireless network side. The OMStar is an offline tool, and the required data must be
imported after users collect the data. The Nastar is an online tool and can automatically
import data after subscription. The two tools are applicable to different scenarios.
The VoLTE voice quality optimization solution of the OMStar can be deployed to calculate
KPIs (such as the number of times uplink/downlink VQIs are poor and packet loss rates),
identify cells with poor voice quality from different dimensions, and analyze the air interface
and resource capacity problems that exist on the network. (In the self-adaptive scenario, users
can customize the KPI calculation formulas.) The table below lists the data that should be
imported to the OMStar.
Mandatory for Data Collection Duration Extraction

Voice Quality Format Mode
Analysis?
External Mandatory SIG 2 hours a day for 3 days NIC
CHRs consecutively
Internal CHRs Mandatory CHR Including the time NIC
segments for collecting
external CHRs
Traffic Mandatory MRF 24 hours a day and 7 NIC
measurement days a week (Including
data the time segments for
collecting external
CHRs)
XML Mandatory Xml Latest configuration NIC
configuration

Mandatory for Data Collection Duration Extraction

Voice Quality Format Mode
Analysis?
Working Mandatory xls/xlsx Latest working Collected by
parameters parameters field engineers
Alarms Optional CSV Historical and active NIC
alarms
Operation logs Optional Oprlog All operation logs NIC
The OMStar associates internal and external CHRs and traffic measurement data, and output
the evaluation and analysis reports for Top N cells. The evaluation report also contains the
evaluation result of the poor VoLTE voice quality problem, basic auditing result, problem
demarcation result, problem locating resulting, and optimization suggestions.
Table 1-2 Voice quality accurate optimization and analysis
Task Audited Item

KPI evaluation Evaluation result
Basic auditing Basic auditing result
Isolation and demarcation Uplink VQI isolation and demarcation result
Downlink VQI isolation and demarcation result
Root cause analysis Root cause analysis
Optimization suggestion Optimization suggestions
1.6 Overall MOS Optimization Procedure

For the network MOS analysis, first isolate the problem source to determine the problems are
air interface problems or NE problems, and then further analyze and resolve problems.
Isolate and demarcate problems first, and then further analyze problems in the VoLTE MOS
performance problem location and optimization procedures. The procedures are classified into
the following:

Figure 1-1 Network assessment problem analyzing and resolving process of VoLTE voice quality
The SEQ analyzes low-MOS subscribers by CDR, demarcates problems, and then determines where
problems occur:
1. If problems are demarcated as problems below the S1 interface, problems occurs in the cell.
2. If problems are demarcated as EPC problems, problems occur on the gateway.
3. If problems are demarcated as IMS problems, problems occur the SBC.
4. If codec problems are demarcated, demarcate problems on the IMS.
For problem analysis on the RAN side,

the SEQ must provide the cell ID,
Analyze IMS problems. abnormal UE IMSI or S1AP-MME ID
list, exception time point, and problems
Analyze EPC problems. occurring in the uplink or downlink.
Is the CN Nastar No
The problem analysis is deployed?
Does Discovery
the same as that without
PS exist?
the SEQ deployed.
Yes
Yes
Does the SEQ collect and Analyze the SBC according to CN Nastar obtains the CHR and MR data of the corresponding cell
to locate and analyze CDRs indicating poor quality (the capability of Collect external and internal
aggregate CDRs indicating poor Yes Is the CN Nastar deployed? Yes the assessment procedure for using internal CHRs for deep problem location on the RAN side is CHRs, traffic statistics, alarms,
voice quality to a top SBC? the network without the SEQ. Associate the Discovery PS CDRs with provided in 2016 September): and xml and use OMStar to
SEQ CDRs (to be implemented). 1. Exception events (such as, reestablishment, handover failures, demarcate problems and deeply
and frequent handovers) locate problems on the RAN side
2. Packet loss or jitter due to causes above the S1 interface (for details, see the optimization
3. Packet loss due to poor quality over the air interface guide to traffic statistics voice
4. Packet loss due to poor quality inside the base station quality).
No 5. Whether the problem occurs on the top UE
Ask forntline engineers
for help to conduct a
Submit a trouble ticket to the test again and collect
GTAC. CellDT tracing data on
Are the
The SEQ assessment result shows The SEQ assessment result shows that the problems located No sites, and submit the
that the packet loss rate above the packet loss rate above the S1-U interface in and resolved? data to the second line
Existence of exception events problem handling
S1-U interface in the uplink is high. the downlink is high.
engineers to locate
causes for poor-voice-
Based on the SEQ and Discovery PS CDRs, Discovery PS Yes quality cells.
calculates the following: Packet loss due to poor quality over the air interface
a. Total number of packets on the right of the S1-U interface Based on the SEQ and Discovery PS CDRs, Discovery
b. Number of packets lost between the S1-U probe and P- PS calculates the following:
Drill down and analyze the IP
GW a. Total number of packets on the right of the S1-U End
Does the SEQ collect and c. Number of packets lost on the right of the P-GW, including interface
Yes Is the ping operation normal? Yes Is the CN Nastar deployed? Yes address status according to the the P-GW b. Number of packets lost between the S1-U probe and P- Packet loss due to problems inside the base station
aggregate CDRs indicating d. Number of packets lost on the right of the Gm interface
assessment procedure for the GW, including the P-GW
poor voice quality to a top Discovery PS also calculates the range where packet loss c. Number of packets lost on the right of the P-GW
network without the SEQ. occurs.
IP address? b/a > 0.4%: Packet loss occurs between the S1-U interface
b/a > 0.4%: Packet loss occurs between the S1-U
interface and the P-GW, including the S-GW and P-GW.
and the P-GW, including the P-GW. You need to check You need to check packet loss on the S-GW or P-GW.
packet loss on the P-GW. c/(b –a) > 0.4%: Packet loss occurs on the right of the P-
c/(b –a) > 0.4%: Packet loss occurs on the right of the P- Top terminals: Obtain the terminal type and contact the
No No GW, excluding the P-GW. You need to check packet loss
GW, including the S-GW. You need to check packet loss on between the P-GW and S-BC. terminal vendor to further analyze problems.
the S-GW. Demarcation based on the number of lost packets
(c –d)/(b –a) > 0.4%: Packet loss occurs between the P- depends on the SEQ results (time and subscriber range),
GW and Gm interface, including the P-GW. You need to and demarcation based on the packet loss rate also exists
check packet loss on the P-GW. (to be verified).
Demarcation based on the number of lost packets depends
Submit the problem to R&D on the SEQ analysis (time and subscriber range), and
Check the transmission status. demarcation based on the packet loss rate also exists (to be
No engineers. verified).
Currently, the CCE can trace less

than 10 subscribers. Check packet loss Check packet loss
inside the S-GW inside the P-GW
Check packet loss Check packet loss based on traffic based on traffic
inside the S-GW inside the P-GW statistics. statistics.
based on traffic based on traffic
statistics. statistics.
Is the problem a codec Does the SEQ signaling Does the SEQ signaling Is the high transmission
problem? Can the SEQ Yes and tracing data analysis result show Yes and tracing data analysis Yes codec rate function enabled on Enable the high transmission
result show that codec No codec rate function on the UMG
demarcate the problem? that the IM-MGW is involved? conversion is performed the UMG and SBC?
on the SBC or UMG? and SBC.
No No No Yes
Check the uplink codec status Coordinate with the CS side Check whether the codec rate
End in the uplink on the RAN side of engineers to handle the is adjusted downward on the
the peer end. problem. RAN side of the local end.
Figure 1-2 User complaint and DT problem analyzing and resolving procedure of VoLTE voice
quality
Subscriber complaint scenarios (mobile
number, time, and location)
DT KPIs and poor-quality MOS (mobile

number, time, and location) Does the result of problem
demarcation with subscribers' CDRs obtained
Yes on the SEQ show that problems occur below No
the S1 interface?
EPC: Handle the problems based on
the subscriber complaint procedure
Analyze DT logs, and check UE events and
without the SEQ deployed.
air interface status when the MOS is poor.
For details, see the guide to improving the DT No
MOS.
Is there the Gm interface probe?
IMS: Handle the problems based on

Yes the subscriber complaint procedure
cause of poor air interface quality.
If packet loss occurs, exclude the
If the air interface quality is poor,
without the SEQ deployed.

CN Nastar obtains subscribers' combined CDRs of the MR and
CHR to demarcate and analyze the packet loss point:
optimize the quality.
1. Check whether exception events (such as, reestablishment, Does the problem occurs above the
Yes
handover failures, and frequent handovers) exist. Gm interface?
2. Packet loss due to air interface quality
3. Packet loss due to poor quality inside the base station or the
terminal problem
Find out the CHRs based on the

No No
calling number and called number
and time.
Packet loss may be The SEQ assessment result shows The SEQ assessment result shows
Yes Poor air caused by problems that the packet loss rate above the that the packet loss rate above the
Exception
interface inside the base S1-U interface in the uplink is high. S1-U interface in the downlink is high.
events
quality station or terminal
problems.
Does the result of
problem demarcation with Based on the SEQ and Discovery PS CDRs,
Analyze problems on Discovery PS calculates the following:
No subscribers' CDRs obtained on the Is the MOS on the CN side of the
the EPC or IMS side. SEQ show that problems occur a. Total number of packets on the right of the S1- Based on the SEQ and Discovery PS CDRs,
below the S1 interface? U interface peer SBC lower than the MOS on the Yes Check the local SBC.
Discovery PS calculates the following: access side of the local SBC?
b. Number of packets lost between the S1-U
probe and P-GW a. Total number of packets on the right of the S1-
c. Number of packets lost on the right of the P- U interface
GW, including the P-GW b. Number of packets lost between the S1-U
Yes d. Number of packets lost on the right of the Gm probe and P-GW, including the P-GW No
interface c. Number of packets lost on the right of the P-
Discovery PS also calculates the range where
packet loss occurs. GW
Collect external and internal CHRs, traffic b/a > 0.4%: Packet loss occurs between the S1-U b/a > 0.4%: Packet loss occurs between the S1-U
statistics, alarms, and xml and use interface and the P-GW, including the S-GW. You interface and the P-GW, including the S-GW and Check the peer SBC.
OMStar to demarcate problems and need to check packet loss on the S-GW. P-GW. You need to check packet loss on the S-
deeply locate problems on the RAN side c/(b –a) > 0.4%: Packet loss occurs on the right GW or P-GW.
of the P-GW, including the P-GW. You need to
(for details, see the optimization guide to check packet loss on the P-GW. c/(b –a) > 0.4%: Packet loss occurs on the right
traffic statistics voice quality). (c –d)/(b –a) > 0.4%: Packet loss occurs of the P-GW, excluding the P-GW. You need to
between the P-GW and Gm interface, including check packet loss between the P-GW and S-BC.
the P-GW. You need to check packet loss on the Obtain the information about the
P-GW.
problematic cell, and conduct a test
on the single-subscriber voice
Is the problem resolved? Yes
quality problem. For details about
Ask forntline engineers for help to conduct
the problem location method, see
a test again and collect CellDT tracing data Based on the single-subscriber quality report,
Are the problems the related guide.
No on sites, and submit the data to the product check the root cause for packet loss inside the
located and resolved?
support engineers to locate causes for S-GW or P-GW through the dialing test.
poor-voice-quality cells.
Yes
Yes
End
End
The method is as follows: Use the test data of the SEQ Analyst and terminal to assess voice
quality and check packet loss, latency, and jitter problems. Problem isolation and demarcation
depend on the SEQ Analyst platform, and further problem location depends on log statistics,
traffic statistics, and tracing data of the IMS, gateway, and eNodeB. If the SEQ Analyst
platform is unavailable, create an eNodeB tracing task to isolate problems.
The SEQ Analyst platform is used to detect subscribers' CDR-level MOS and assess and
present the MOS. The platform also determines whether problems occur above or below an
interface for each interface (such as, S1-U and Gm interfaces) by analyzing RTCP and RTP
packet loss, latency, and jitter. Observe each interface to preliminarily isolate the NE range
where problems occur, as shown in the following figure.

The counter range of the

demarcation solution
includes:
(1) VoLTE –> demarcation
of the uplink MOS and
uplink one-way audio
problems on the LTE side of
the CS, CSFB, or other call
modes
(2) VoLTE –> demarcation
of uplink and downlink MOS
and uplink and downlink
one-way audio problems of
the VoLTE call models
Uplink:
1.6.1 Optimization on the EPC Side

Check the VoLTE QoS parameter statistics, including packet loss that is mainly analyzed at
present, latency, and jitter, provided by the Discovery PS.

Abnormal Uplink MOS

Abnormal uplink voice
MOS
Does the packet No

loss rate exceed the
threshold?
Yes
End
Yes Does the packet No

loss rate between the UE
and P-GW exceed the
threshold?
Does the packet loss

rate of the S-GW or P-GW Yes Does the packet
exceed the threshold based Yes loss rate of the S-GW or
on traffic statistics? P-GW exceed the threshold
based on traffic
statistics?
No
No
Segmented demarcation: Segmented demarcation: Packet Segmented demarcation: Packet loss

Packet loss rate exception loss rate exception of the S-GW or rate exception between the P-GW and
between the UE and S-GW P-GW SBC/UE
Packet loss rate exception Packet loss rate Packet loss rate
between the UE and S-GW exception of the S- exception between the
GW or P-GW P-GW and SBC/UE
Top N analysis: eNodeB Analysis based on the Top N analysis: SBC

RMM count
Does The packet Demarcate and locate the

loss rate on the problem based on the
Yes transmission or SBC.
S1-U interface exceeds
the threshold based on the
IPPM?
No
Segmented Segmented demarcation:

demarcation: Packet Packet loss rate exception
loss rate exception on between the UE and eNodeB
the S1-U interface
Step 1 Parameter demarcation: Check whether the E2E packet loss rate (UL Packet Loss Rate)
exceeds the threshold (the default value is 1%).
 If it does, go to Step 2.
 If it does not, the problem is not located.
Step 2 Check whether the uplink packet loss rate between the UE and P-GW exceeds the threshold.
 If it does, perform operations in "Packet Loss Rate Exception Between the UE and
P-GW, and go to Step 3.
 If it does not, go to Step 4.
Step 3 Obtain the voice service APN used by the carrier and check whether the uplink packet loss
rate of the S-GW or P-GW exceeds the threshold.
 If it does, the packet loss rate of the S-GW or P-GW is abnormal.
 If it does not, the packet loss rate between the UE and S-GW is abnormal, and you need
to perform operations in "Packet Loss Rate Exception Between the UE and S-GW".
The uplink packet loss rate exception is assessed based on the following UGW9811
counters:
− 136316009 SGW uplink user traffic discarded in packets (APN)/136316001 SGW
incoming uplink user traffic in packets (APN)
− 138413089 PGW uplink user traffic discarded in packets (APN)/138413066 PGW
incoming uplink user traffic in packets (APN)
Step 4 Obtain the voice service APN used by the carrier and check whether the uplink packet loss
 If it does, the packet loss rate of the UGW9811 is abnormal, and you need to perform
operations in "Packet Loss Rate Exception of the S-GW or P-GW".
 If it does not, the packet loss rate between the UGW9811 and SBC/UE is abnormal, and
you need to perform operations in "Packet Loss Rate Exception Between the UGW9811
and SBC/UE".
The uplink packet loss rate exception is assessed based on the KPIs in Step 3.
----End
Packet Loss Rate Exception Between the UE and S-GW

For top worst N (the default value is 5) eNodeBs, demarcate the packet loss rate on the S1-U
interface based on the IPPM, and check whether a transmission problem occurs on the S1-U
interface. If it is not a transmission problem, export the information about top worst N
eNodeBs and analyze the problem on the eNodeB side.
For details about the IPPM, see the description about GWFD-111401 IP Performance Monitor
in the UGW9811 GPI documentation. Analyze the packet loss rate based on the counter
"1542455416 Average forward packet loss rate on the IP PM" of the eNodeB. If the packet
loss rate is greater than 1%, the packet loss rate on the S1-U interface is abnormal. If the
packet loss rate is less than or equal to 1%, analyze the problem on the eNodeB side.
NOTE
IPPM applies only to Huawei eNodeBs. If the peer NE is not a Huawei eNodeB, the problem cannot be
demarcated.
Packet Loss Rate Exception Between the UGW9811 and SBC/UE

Query top worst SBCs and demarcate and locate the problem on the transmission or SBC side
with the assistance on the UGW9811 side.

Abnormal Downlink MOS

Abnormal downl ink voice MOS
Does the packet loss No

rate exceed the
threshol d?
Yes
End
Does the packet

Yes loss rate betw een the UE No
and P-GW exceed the
threshol d?
Does the packet loss Yes Yes

rate of the S-GW or P-GW exceed Does the packet loss
the threshold based on traffic rate of the S-GW or P-GW
statistics? exceed the threshold based
on traffic statistics?
No No
Segmented demarcation: Packet l oss rate Segmented demarcation: Segmented demarcation: Packet l oss
excepti on betw een the UE and S-GW Packet l oss rate excepti on rate excepti on betw een the P-GW
of the S-GW or P-GW and SBC/UE
Packet l oss Packet l oss Packet l oss rate

rate excepti on rate excepti on excepti on betw een
between the of the S-GW or the P-GW and
UE and S-GW P-GW SBC/UE
Analysis based on the RMM

Top N analysis: eNodeB Top N analysis: SBC
count
Demarcate and locate the

Does the packet problem based on the
Yes loss rate on the S1- transmission or SBC.
U interface exceeds
the threshold based
on the IPPM?
No
Segmented demarcation: Segmented demarcation:

Packet l oss rate excepti on Packet l oss rate excepti on
on the S1-U interface between the UE and eNodeB
Step 5 Parameter demarcation: Check whether the E2E packet loss rate (DL Packet Loss Rate)
exceeds the threshold (the default value is 1%).
 If it does, go to Step 6.
 If it does not, the problem is not located.
Step 6 Check whether the downlink packet loss rate between the SBC/UE and P-GW exceeds the
threshold.
 If it does, perform operations in "Packet Loss Rate Exception Between the SBC/UE and
P-GW".
 If it does not, go to Step 7.
Step 7 Obtain the voice service APN used by the carrier and check whether the downlink packet loss
 If it does, the packet loss rate of the S-GW or P-GW is abnormal.
 If it does not, the packet loss rate between the S-GW and UE is abnormal, and you need
to perform operations in "Packet Loss Rate Exception Between the S-GW and UE".
The downlink packet loss rate exception is assessed based on the following UGW9811
counters:

− 138413091 PGW downlink user traffic discarded in packets (APN)/138413072 PGW

incoming downlink user traffic in packets (APN)
− 136316011 SGW downlink user traffic discarded in packets (APN)/136316007 SGW
incoming downlink user traffic in packets (APN)
----End
Packet Loss Rate Exception Between the S-GW and UE

For top worst N (the default value is 5) eNodeBs, demarcate the packet loss rate on the S1-U
interface based on the IPPM, and check whether a transmission problem occurs on the S1-U
interface. If it is not a transmission problem, export the information about top worst N
eNodeBs and analyze the problem on the eNodeB side.
For details about the IPPM, see the description about GWFD-111401 IP Performance Monitor
in the UGW9811 GPI documentation. Analyze the packet loss rate based on the counter
"136325014 Average Packets Lost Ratio of Forward Performance Monitoring" of the P-GW.
If the packet loss rate is greater than 1%, the packet loss rate on the S1-U interface is
abnormal. If the packet loss rate is less than or equal to 1%, analyze the problem on the
eNodeB side.
NOTE
IPPM applies only to Huawei eNodeBs. If the peer NE is not a Huawei eNodeB, the problem cannot be
demarcated.
Packet Loss Rate Exception Between the SBC/UE and S-GW

Query top worst SBCs and demarcate and locate the problem on the transmission or SBC side
with the assistance on the UGW9811 side.
1.6.2 Optimization on the IMS Side

For calls between VoLTE subscribers on the IMS side, the NE related to the media plane is
SBC (P-CSCF). The voice codec used for a call on the IMS side and IP bearer quality on the
access network cause the low voice quality MOS.
The following figure shows the analysis method of low MOS on the SBC.

Low MOS of VoLTE voice service
1. Is an alarm related to the media Yes The SBC clears the alarm related
plane generated on the SBC? to the media plane.
You need to coordinate the RAN

2. Is the packet loss rate of the side of the LTE network and
IP QoS on the access network in traffic statistics Yes
on the SBC high? bearer network to analyze the
packet loss rate.
You need to coordinate the

3. Is the IP QoS latency on RAN side of the LTE network
the access network in traffic statistics on the
SBC long? and bearer network to analyze
the bearer latency.
Yes
Y
You need to use CCE to collect

4. Is CN Nastar of CCE deployed No statistics and analyze the voice
on the live network?
quality.
Step 1 Check whether an alarm related to the media plane in section Error! Reference source not
found."Error! Reference source not found." is generated on the SBC.
Step 2 Check whether the average packet loss rate of "ABCF Access Network IP QoS Measurement"
on the SBC is greater than 1%.
If the rate is greater than 1%, you need to coordinate the RAN side and bearer network to
exclude the packet loss cause.
Step 3 Check whether the RTT of "ABCF Access Network IP QoS Measurement" on the SBC is
longer than 100 ms.
If the rate is longer than 100 ms, you need to coordinate the RAN side and bearer network to
exclude the packet loss cause.
Step 4 If the solution mapping for the IMS side on the live network is VoLTE 3.2, and CN Nastar 2.0
of CCE is deployed on the live network, use CCE to identify the locations with low MOS and
coordinate the RAN side to check the air interface quality of the corresponding cell.
----End
1.6.3 Optimization on the RAN Side

Voice quality problems below the S1 interface include the impact of terminals, the air
interface, and eNodeB. The following figure shows the location procedure and check points.

Problems below the S1 interface
Are the problems Test software

test methods and test software Yes commissi oning and
problems? optimization
problems
Test software
statistics problems
Are the problems

terminal problems? Yes Known UE problems
Changi ng the
terminal to check
whether problems
exist
Are the problems air Yes Air interface factor check

interface problems?
Are the problems

eNodeB problems? Yes eNodeB factor check
No
Submit trouble tickets for other

End eNodeB problems and resolve
the problems.
Step 1 Check whether the test software is commissioned and optimized, whether the overall
maximum MOS value is small, and whether the software statistics are normal.
If problems are solved after the DT software is replaced, the DT software causes the problems
that must be resolved by the software vendor.
Step 2 Isolate problems to check whether problems occur on the terminal. Change the test device or
the test area to check whether problems are resolved. If the problems are resolved after the
test device is changed, problems occur on the terminal. For terminal problems, check the
aspects, such as terminal software version and terminal capability. If these aspects cannot be
checked, contact the terminal vendor.
Step 3 Isolate air interface problems and analyze the DT data to check events, such as the RSRP,
SINR, interference, and exception.
If the threshold conditions are not met, optimize the air interface.
Step 4 Check the eNodeB status, fault alarm information, eNodeB version, parameter settings in
scenarios without air interface condition exceptions to check whether problems occur on the
eNodeB.
If problems cannot be resolved after the check for all affecting factors is complete, submit a
trouble ticket to resolve the problems.
----End
 UE side DT data analysis

− Packet loss: Unfold the Message node and choose IP Key Messages to check the
status of RTP packets received and sent by the UE.

Network–>UE indicates the downlink RTP packets received by the UE from the
network. If the downlink sequence number is inconsecutive, packet loss occurs on the
network side. You need to simultaneously check the eNodeB and NEs above the
eNodeB to determine the packet loss position. UE–>Network indicates the uplink
RTP packets received by the network from the UE. If the uplink sequence number is
inconsecutive, problems occur on the UE.
− Latency: The E2E latency is one of the most important factors affecting the quality of
interactive voice communication. A latency may cause a situation that the two parties
speak at the same time because one of them cannot hear the voice of another party in
time. This situation affects user experience, and therefore, the E2E latency must be
limited to a proper range. Experience indicates that when the E2E latency is in the
range of 175 ms to 200 ms, the MOS jitters and decreases severely, and the MOS
jitter and decrease continue as the subsequent latency increases.
− Jitter: is also defined as latency variation. Jitter refers to the difference in the arrival
time of all data packets during an IP call. When sending a data packet, the sender
adds a time stamp to the RTP packet header. The receiver adds another time stamp
upon receiving the data packet. The transmission duration of this packet can be
determined by calculating the two time stamp difference.
 Using the CellDT data to isolate and analyze upstream and downstream eNodeB data
− Packet loss: The TTI tracing (CellDT 138 tracing) of the eNodeB is deployed at the
PDCP layer on the eNodeB side and can detect the downlink packet loss caused by
the CN (S1 link).
In the following figure, the TTI is from 4486447 to 4492787, there are 207 packets
lost in the data received by the eNodeB from the CN (S1 link), and the RTP SN is
from 0x057a to 0x0649.

− Latency: The VoLTE voice service is performed between UE 1 (CRNTI is 7183) and
UE 2 (CRNTI is 6058). The difference between the time when an uplink packet of
UE 1 is sent to the CN and the time when UE 2 receives the packet from the CN to
check the CN latency. In the following figure, the data packet with the RTP SN being
0x88e5 is sent to the CN on the source side with the uplink TTI being 209191805 and
is received on the target side with the downlink TTI being 209191809. The duration
of sending and receiving the packet shows that the CN latency is only 4 ms.
Jitter
Interval
− Jitter: CellDT 138 tracing can also determine whether jitter occurs when the eNodeB
receives packets from the CN (S1 link). For example, the following figure shows that
slight jitter occurs when the eNodeB receives packets from the CN.
1.7 Typical Cases

1.7.1 Voice Quality Affected by Call Re-Initiation Caused by
Missing Adjacent Cell Configuration
[Problem description]

VoLTE is deployed on the XX site. A network-wide DT is conducted. The test result indicates
that the number of calls re-initiated by UEs is large and UEs need to be re-connected to the
network after a large number of call re-initiation failures.
[Handling process]
Analyze signaling as follows:
Traced signaling indicates that the UE consistently reports the A3 event, but the eNodeB does
not send a handover command, as shown in the figure below.
The UE initiates a call again. The cell where the call is re-initiated does not have the context.
Therefore, the re-initiated call fails.
After the call re-initiation failure, the UE attempts to access the network again. From
22:00:31.406 when the UE starts to search the system message to 22:00:31.878 when the UE
is finally connected to the cell, there is an interval of 470 ms during which voice packets
cannot be processed.
[Root cause]
Some adjacent cells of the eNodeB are not configured. Consequently, the handover fails and
the call is re-initiated.
The problem of missing adjacent cell configuration does not affect the intra-frequency and
inter-frequency handover success rates in the system. It has minor impacts on KPIs related to
the data service, such as the handover success rate and throughput, but great impacts on KPIs
of VoLTE voice service, such as the delay, jitter, and packet loss rate. The problem of missing
adjacent cell configuration seriously affects the voice quality. About 20% of VoLTE voice
service problems detected in Hangzhou are caused by missing adjacent cell configuration.
[Solution]
The VoLTE voice service raises stricter requirements for the adjacent cell configuration.
Before deploying the VoLTE voice service, check the adjacent cell configuration on the entire
network.
1.7.2 Low MOS Caused by Ping-Pong Handovers

When the network-wide VoLTE DT is conducted on the XX site, ping-pong handovers occur,
resulting in sharp decrease of the MOS.
[Problem analysis]
Analyze the MOSs before and after a handover. Before the handover, the MOS is 3.33. The
UE performs a ping-pong handover between cells 53 and 473. As a result, the MOS drops to
2.12.

If the RSRP is good, the MOS does not decrease significantly when a handover occurs.

Therefore, a handover does not necessarily cause a sharp decrease of the MOS. If a handover
occurs in an area where the RSRP is good, the MOS decreases by 0.1 to 0.5. If a ping-pong
handover occurs, the MOS decreases by 0.5 to 1.5.
[Root cause]
A handover that occurs during the MOS test affects the MOS. A common handover does not
seriously affect the MOS, but a ping-pong handover may cause sharp decrease of the MOS.
[Solution]
1. Adjust RF parameters.
2. Adjust the CIO between two cells.
1.7.3 Low MOS Caused by Super-Distance Coverage

Adjacent cells are not configured on the eNodeB. The UE consistently sends the measurement
report (MR), but the handover cannot be implemented, resulting in a low MOS.
[Problem analysis]
A cell with super-distance coverage does not have any adjacent cell. The UE consistently
sends the MR, but the handover cannot be implemented because no adjacent cell is configured
for this cell. The signal is poor. Therefore, the MOS is low.
The UE is located in the coverage of Shenzhen Jindi D-HLD, but still uses signals of
Shenzhen Shixianan D-HLH, as shown in the figure below.
The impact on the MOS is as follows:

The UE always occupies the cell PCI 380, and is reconnected to the cell PCI 190 until the
RSRP reaches -115 dBm. Shenzhen Shixianan D-HLH has super-distance coverage. After the
RSRP deteriorates, the UE cannot be handed over to an adjacent cell with better signals. As a
result, the bit error rate increases, and the MOS decreases to about 1. The MOS decreases by
0.5 to 1.5.
The UE consistently sends the MR, but the handover cannot be implemented, but the eNodeB
does not send any handover command because no adjacent cell exists.

[Root cause]
The cell with super-distance coverage does not have any adjacent cell. When the wireless
signal of the UE is poor, the UE initiates a call request again, and then is re-connected to the
network.
[Optimization suggestion]
Method 1: Adjust RF parameters to resolve the overshoot coverage problem.
Method 2: If method 1 does not work, reduce the power.
Method 3: If the preceding two methods cannot resolve the problem, it is recommended that
adjacent cells be configured for the overshoot coverage area.
1.7.4 Low MOS Caused by MOD3 Interference

The SINR is low due to MOD3 interference. As a result, the MOS is low.
[Problem analysis]
MOD3 interference exists between PCI 67 of Shenzhen Shazui D-HLH-3 and PCI 400 os
Shenzhen Shazui D-HLH-1. When the RSRP is -90 dBm, the SINR is -2 dB.
The impact on the MOS is as follows:

[Conclusion]
The MOS decreases by 0.4 to 1.0 due to MOD3 interference.
Adjust the PCI to avoid MOD3 interference between cells with the same remainder after the
PCI is divided by 3.
1.7.5 Low MOS Caused by eSRVCC Handover to the 2G Network

After the VoLTE service is deployed on the XX site, the MOS test is conducted. The result
indicates that the MOS is low when an eSRVCC handover to the 2G network is triggered.
[Problem analysis]
The figure below shows the MOSs after eSRVCC handovers to the 2G network.

The POLQA algorithm is used for VoLTE voice quality evaluation, and applies to WB
services. The 2G services are NB services. Therefore, it is inappropriate to use this algorithm
to evaluate the 2G MOS, and the MOS will drop by 1.5 to 2.0 if this algorithm is used.
[Conclusion]
it is inappropriate to use the POLQA algorithm to evaluate the 2G MOS.
1. Optimize the VoLTE coverage, and adjust the eSRVCC threshold.
2. After the UE is handed over to the 2G network due to the weak coverage, an appropriate
MOS evaluation algorithm can be automatically selected.
1.7.6 Low MOS Caused by Leakage of the Indoor Distributed

Base Station
The cells serving the calling and called subscribers are different. The RSRP of the cell serving
the calling subscriber is poor, and the packet error rate is high. The RSRP of the cell serving
the called subscriber is good, and the packet error rate is low. The low MOS is caused by the
poor signal and RSRP of the cell serving the calling subscriber. Therefore, it is necessary to
check why the calling subscriber is not handed over to a serving cell with good signals.

[Problem analysis]
1. The signal is poor. Therefore, the UE sends the MR, and the eNodeB sends the
inter-frequency 37900 measurement control.
The frequency 37900 adopts the A3-based inter-frequency handover, which is triggered when
the sum of offset and HY3 is greater than or equal to 4 dB. The sum of offset and HY3 in the

MR sent by the UE is 3 dB, which is smaller than the threshold 4 dB. Therefore, the UE
cannot be handed over to the frequency 37900.
2. The signal is poor. Therefore, the UE sends the MR, and the eNodeB sends the
inter-frequency 39250 measurement control.
A4-based inter-frequency handover is adopted between the macro base station and indoor
distributed base station. The A4 threshold is -101 dBm. It is easy to meet this condition due to
leakage of the indoor distributed base station. After the UE is handed over to the indoor
distributed base station, the signal remains poor. The threshold for a handover from the indoor
distributed base station to the macro base station is -105 dBm, which is relatively low.
Therefore, it is difficult to trigger a handover of the UE from the indoor distributed base
station to the macro base station. In mobile state, the signal quickly attenuates. When the
basic signal strength is about -120 dBm, the UE is handed over to cell 272.
[Conclusion]
The UE cannot be handed over to an appropriate cell due to leakage of the indoor distributed
base station.
1. Adjust the CIO of the indoor distributed base station so that it is difficult for a UE to be
handed over to a cell of the indoor distributed base station when the UE is located on a road.
2. Adjust the A4 threshold for handover from the macro base station to the indoor distributed
base station. It is recommended that the A4 threshold be set to -95 dBm. In the case of leakage
of the indoor distributed base station, this setting prevents the UE from being handed over to a
cell of the indoor distributed base station when the UE is located on a road.
1.7.7 Low MOS Caused by the Test Software Debugging Problem

In the CDS test of a site, the MOS of each grid is not high.
[Problem analysis]
Analysis on the grid MOSs indicates that the average MOS ranges from 3.1 to 3.6 in the
network-wide CDS test. According to the tests conducted earlier, when the grids do not have
serious air interface problems, the average MOS of the network can reach 3.7 to 3.8. In the
CDS test, the MOS is obviously low.
The figure below shows the MOS distribution of grid 66, where the highest MOS is only
3.960. Generally, the highest MOS can reach 4.1. It is possible that the MOS test equipment is
not properly debugged.
In addition, the RTP packet loss rate is not closely associated with the weak coverage. The
average RTP packet loss rate is 0.42%, which is lower than the protocol requirement of 1%.

35 0
30 -20
25
-40
20
-60
15 CRS SINR
-80 CRS RSRP
10
-100
5
0 -120
0 10 20 30 40 50 60 70
-5 -140
rtp plr(%)
When the MOS audio file of grid 66 is played back, the background electronic noise is
detected. The following attachment is the audio file recorded when the MOS is 3.96.
Key factors affecting the MOS are as follows:

 Loudness of the voice: According to the past experience, the MOS is the best when the
UE volume is set to the second largest volume and the attenuation of the HTC terminal
where the CDS test software is installed is set to 29.
 Packet loss rate: It is affected by abnormal events on the air interface, such as the late
handover, re-establishment, and call drop.
 Voice decoding: Generally, the voice decoding problem occurs because the UE is faulty.
 Background noise: It is generally caused by the equipment connection problems, for
example, the audio cable connector is not reliably connected, the test equipment is not
properly connected to the vehicle-mounted power supply, and the active Hub connection
is used.
Analysis on the MOS test result of grid 66 indicates that the low MOS is not caused by the air
interface. The low MOS may be caused by the test method, which must be verified.
The MOS of grid 66 is tested for the second time. The previous CDS test result indicates that
the packet loss rate of the HL-2 site located in the Yeer Hutong, Dongcheng within this grid is
high. Therefore, the MOS is re-tested on the HL-2 site.

According to the fixed-point test result on the HL-2 site, the average RTP packet loss rate is
0.01%, and the average MOS is 3.976. The MOS is normal.
Log Average Average Coverage Call Average Test Test

RSRP RS-SINR rate Delay MOS Duration Mileag
(dBm) (dB) (RSRP>= (s) (min) e (km)
-110 dBm
and SINR
>= -3 dB)
Summary -87.829 17.967 99.97% 4.072 3.976 10.347 0.035

16–42–59- -87.829 17.967 99.97% 4.072 3.976 10.347 0.035
Dongcheng
Yuer
Hutong
Comparison between the network-wide DT and the second MOS test indicates that the
average MOS in the second MOS test reaches 3.85, the RTP packet loss rate is 0.26%, and the
highest MOS is 4.18. This proves that the test equipment is not properly debugged in the
previous CDS test.
Log
Average RSRP (dBm)
Average RS-SINR (dB)
dBm and SINR >= -3 dB)

Coverage rate (RSRP>= -110
Call Delay (s)
Average MOS
Test Duration (min)
Test Mileage (km)

the LTE System
Number of Calls Initiated in
the LTE System

Number of Successful Calls in
the LTE System

Number of Calls Dropped in
System
Handed Over Within the LTE
Number of Voice Calls
Within the LTE System
Successfully Handed Over
Number of Voice Calls
Grid 66 -89.148 16.459 97.72% 4.379 3.446 64.986 17.597 18 18 0 99 99

Grid 66 -93.514 13.429 92.45% 3.491 3.877 42.293 9.496 15 15 1 97 97

(CDS
route)
Grid 66 -90.08 17.845 97.79% 3.923 3.833 45.235 10.457 16 16 0 54 54
(CDS
route)
[Root cause]
Analysis on the MOSs of grid 66 indicates that the MOS test result is closely associated with
debugging of the test equipment. In the subsequent MOS tests, the recommended CDS
configuration method must be used to prevent the inaccurate MOS test results.
[Solution]
Before the MOS test, debug the test equipment at fixed place to ensure that the highest MOS
reaches 4.1. If the MOS is extremely low, check whether the UE volume and attenuation of
the CDS equipment are inappropriately configured and whether the vehicle-mounted power
supply is not properly connected.
1. Connect the MOS box to the USB Hub connector during the test.
2. Set the volume of the UE receiver to the second largest volume.
3. Connect the HTC UE.
1.7.8 Decrease of the MOS Caused by the Heavy Traffic


In the DT of a site, when HL-4 located in Xintuanjiehu, Chaoyang is occupied, the MOS is 4
and no packet is lost. When HL-6 located in Changhongqiao, Chaoyang is occupied, the MOS
is 1.12 and the packet loss rate is 80%. The MOS and packet loss rate recover only after the
UE is handed over to HL-3 located in Shunfengjiulou, Chaoyang. The problem lasts about 2
minutes, from 10:11:09.161 to 10:13:01.512.
After the UE is handed over from HL-6 to HL-3, the RTP packet loss rate and BER become
normal again.
[Problem analysis]
The eNodeB status and alarms are checked, and no exception is found. KPIs of the cell
indicate that the average number of subscribers in the cell during the day time exceeds 300,
the uplink RBLER is relatively high, and the uplink QCI1 PDCP packet loss rate (20%) is
also high.

The eNodeB data is traced and the uplink scheduling information is analyzed. 41484 indicates
the uplink scheduling failure caused by insufficient CCE resource. The proportion of 41484 is
as high as 12%. It is preliminarily determined that the uplink CCE resource is insufficient due
to the large number of subscribers in the cell. Consequently, uplink scheduling fails.
To further obtain the VoLTE subscriber tracing data, a long call test is conducted in the early
morning. The tracing result indicates that the uplink PDCP SNs of the eNodeB are continuous
and no VoLTE packet is lost.
It can be concluded that the uplink CCE resource of the site is insufficient due to the heavy
traffic. Consequently, the uplink RBLER and VoLTE packet loss rate are high. Upon VoLTE
SR and data service SR, the uplink CCE resource is insufficient. The site does not allocate the
uplink CCE resource preferentially to VoLTE SR. In the eRAN 8.1, VoLTE SR takes
precedence over data service SR, but related configuration parameters are not available on
interface yet. The related MML command is as follows:
MOD eNBCellRsvdPara: LocalCellId=1-6, RsvdSwPara3=RsvdSwPara3_bit1-1;
When a second test is conducted after this command is executed, the QCI1 packet loss rate
becomes normal again.

In addition, more uplink CCEs can be added to resolve the problem of insufficient uplink CE
resource. The following command can be executed to increase the ratio of uplink CCEs to
downlink CCEs:
MOD ENBCELLRSVDPARA:LocalCellId=3,RsvdPara52=10;
This command indicates the ratio of uplink CCEs to downlink CCEs of subframes 3 and 8 is
changed to 10:1 to ensure that CCEs used for uplink scheduling are sufficient.
[Root cause]
The number of subscribers of the site is 200, which is large. Upon VoLTE SR and data service
SR, the uplink CCE resource is insufficient. The site does not allocate the uplink CCE
resource preferentially to VoLTE SR.
[Solution]
This problem affects sites with heavy traffic. Two solutions are available:

 Solution 1
Run the following command on the entire network to adjust the scheduling optimization
parameters, ensuring that the priority of the VoLTE SR is higher than that of the data
service SR:
MOD eNBCellRsvdPara: LocalCellId=1-6, RsvdSwPara3=RsvdSwPara3_bit1-1;
 Solution 2
Run the following command to change the ratio of uplink CCEs to downlink CCEs of
subframes 3 and 8 to 10:1 to ensure that CCEs used for uplink scheduling are sufficient:
MOD ENBCELLRSVDPARA:LocalCellId=3,RsvdPara52=10;
1.7.9 Deterioration of VoIP Voice Quality Caused by Abnormal

Periodic BSR Processing of the UE
According to customer complaints of the XX office, the voice quality of three sites
deteriorates, the downlink voice quality is normal, but the uplink voice quality is often
interrupted and poor. The uplink QCI1 packet loss rate is checked and is found to increase
sharply in some time segments. This symptom matches the theoretical analysis result. That is,
the VoIP voice quality deteriorates because the uplink QCI1 packet loss rate increase sharply.
The figure below shows the statistics of the QCI1 UL/DL packet loss rate of the site 2362 that
is complained. In certain time segments, the packet loss rate is high. The packet loss rate is
normal when it is lower than 1%.
[Problem analysis]
1. The voice quality deteriorates because the uplink packet loss rate increases. Therefore,
check the quality of the air interface. The result indicates that the uplink interference does not
increase and the BER on the air interface is normal. This means that increase of the packet
loss rate is not caused by quality of the air interface.

As shown in the preceding figure, the IBER and RBLER do not increase when the QCI1
packet loss rate increases.
2. Capture and analyze packets on the UGW.
Capture packets to check reception of voice packets.
The single subscriber tracing result on the UGW indicates that the interval at which VoIP
packets are received sequentially from the eNodeB side is not always 20 ms. At some time
points, multiple RTP packets are concurrently received.
In the downlink direction, packets are sent at a regular interval, as shown in the figure below.

3. Trace and analyze L2 packets of a single subscriber.

As the QCI1 packets received in the uplink direction are not stable, further trace and analyze
L2 packets of a single subscriber, and check whether uplink scheduling is normal.
The analysis result indicates that the UE does not send VoIP packets at the interval of 20 ms,
and packets are not sent in a continuous manner, as shown in the figure below.
The UE BSR fluctuates seriously when packets are not sent continuously, or a large BSR is
reported continuously. On the UE side, second scheduling may be abnormal or the BSR may
not be reported properly.
4. Analyze the BSR reporting process.

Theoretically, the UE needs to send an SR to request the bandwidth when the UE is faulty.
Why does the UE not report the SR in time?
According to the 36.321-a80 (R10) protocol, the SR is used to apply for the ULSCH resource
used for new data transmission. The SR is triggered when the UE generates a Regular BSR. A
Regular BSR is generated when the following three conditions are met:
The UE has data that is available for transmission and belongs to a logical channel with
higher priority.
The transmission buffer queue of the UE has new data available for transmission (the status of
the buffer at the RLC layer changes from empty to nonempty).

The BSR retransmission timer (retxBSR-Timer) expires and the UE has data available for
transmission on a certain logical channel.
The retxBSR-Timer helps the UE to jump out of the deadlock. For example, the UE sends 0
BSR and then other BSRs other than 0 BSR, but the sequence in which the eNodeB receives
BSRs may be reversed. That is, sometimes that eNodeB may receive 0 BSR last. Therefore,
the eNodeB determines that the UE does not have data to send and no longer implements UE
scheduling. If the UE always does not have data with higher priority, the UE cannot generate
a regular BSR or send the SR to the eNodeB. Consequently, the UE data always cannot be
sent. In this case, the UE can generate a regular BSR by starting the retxBSR-Timer.
The periodic BSR timer (periodicBSR-Timer) enables the UE to trigger the BSR in time and
helps the eNodeB with scheduling. The priority of the BSR is higher than that of common
subscriber data. Therefore, when the UL Grant is available, the BSR generally can be sent.
BSR triggering conditions are independent of each other. Therefore, multiple triggering
conditions can be met at the same time. Triggering a BSR is not equivalent of generating a
BSR. A BSR is generated upon MAC packet assembly. One MAC PDU can contain at most
one BSR.
Based on the preceding protocol description and data analysis, the following problem
triggering scenario can be inferred:
The uplink resource is not requested in time for RTP3 packets when the following two
operations are performed concurrently: (1) The UE is going to send RTP2 packets to the
eNodeB; (2) RTP3 packets are being added to the buffer queue at the RLC layer.

From the eNodeB point of view, in the preceding low-probability triggering scenario, the RLC
buffer on the UE side changes from empty to nonempty, and theoretically, the regular BSR
should be triggered according to the protocol. However, the UE determines that its buffer still
has data and no data that belongs to a logical channel with higher priority needs to be
transmitted. Therefore, the UE does not generate a regular BSR, and instead generates a
regular BSR after the periodic BSR timer expires. After this regular BSR is generated, the
BSR is not assembled to the MAC PDU of the RTP2 packet due to abnormal internal
processing of the UE. Just in the subsequent period of time, the eNodeB does not have extra
pre-scheduling resource that can be allocated to the UE. Consequently, the BSR cannot be
reported, and the RTP3 packet is dropped because it stays in the RLC buffer queue for more
than 100 ms.
According to the PDCP layer tracing result when No.138 tracing mode is used, some uplink
RTP packets arrive simultaneously at some time points. As shown in the figure below, packets
numbered 483 to 487 arrive at the same time TTI.
BSRs are classified into short BSRs and long BSRs. The following provides the BSR
reporting information.
//Tracing item 9 is a short BSR, where the data0 column is displayed in an accumulative
manner. Tracing item 10 is a long BSR, where the data0 column is displayed in an
overwritten manner.
Information about reporting of the short BSR is as follows:
Frm=1007/SubFrm=2; Frm=1022/SubFrm=2
From "Frm=1007/SubFrm=2" to "Frm=1022/SubFrm=2", there is a period of about 160 ms,
during which the MCE of the short BSR is not received.

Information about reporting of the long BSR is as follows:

Frm=1007/SubFrm = 7; Frm = 1009/SubFrm = 7
From "Frm=1007/SubFrm=7" to "Frm=1009/SubFrm=7", the BSR changes from 0 to 17001.
At this time, the buffer status changes from empty to nonempty, prior to which an SR should
be reported.
From "Frm=1007/SubFrm=7" to "Frm=1009/SubFrm=7", there is a period of about 120 ms,
during which the long BSR of the UE is not received.
//Tracing information of SRI 10 is as follows:

The eNodeB detects that the UE sends the SR at "Frm=1008/SubFrm =7". The eNodeB sends
the UL Grant to the UE at the subframe "Frm=1009/SubFrm=3". The UE sends part of the
data at the subframe "Frm=1009/SubFrm=7", and sends the remaining BSR (a periodic BSR,
the period of which is set to 10 ms by default) in the RLC buffer. Based on the BSR reported
by the UE, the eNodeB sends the UL Grant to the UE at the subframe "Frm=1010/SubFrm=3".
The UE sends the PUSCH data at the subframe "Frm=1010/SubFrm=7". Theoretically, the UE
should send the BSR of the data that is newly added to the RLC buffer and should be
transmitted (at this time, the periodic BSR expires). However, the UE does not generate the
BSR in time due to abnormal processing of the periodic BSR timer on the UE. Therefore, the
BSR record does not exist at the subframe "Frm=1010/SubFrm=7".
At this time, the eNodeB determines that the UE does not have any data for scheduling. The
UE cannot trigger the regular BSR because the BSR is not 0, and determines that the eNodeB
needs to continue scheduling. Consequently, the UE can trigger the BSR only after the
retxBSR-Timer expires. In the preceding example, before the retxBSR-Timer expires, the
uplink resource is generated due to pre-scheduling so that uplink scheduling can continue, and
the uplink data transmission becomes normal again. However, the intermediate period
exceeds the duration of the packet loss timer (100 ms). Therefore, some packets are lost.
[Root cause]

In some scenarios, the UE may fail to report the BSR in time due to abnormal processing of
the periodic BSR. As a result, uplink scheduling cannot be implemented in time, causing loss
of uplink packets. The UE chip supplier, XX, admits that their UEs have bugs in BSR
generation.
[Solution]
To prevent this problem, run the following MML commands to increase the threshold of the
pre-scheduling resource ratio and enable smart pre-scheduling:
MOD CELLULSCHALGO: LOCALCELLID=XXX, PREALLOCATIONBANDWIDTHRATIO=50;
MOD CELLALGOSWITCH: LOCALCELLID=XXX, ULSCHSWITCH =SmartPreAllocationSwitch-1;
MOD CELLULSCHALGO: LOCALCELLID=XXX, SmartPreAllocationDuration=50;


Optimization Guide To VoLTE Voice Quality

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optimization Guide To VoLTE Voice Quality

Hochgeladen von

Copyright:

Verfügbare Formate

Optimization Guide to VoLTE

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2017-02-20) Huawei Proprietary and Confidential i

1 VoLTE MOS Optimization Guide

1.2 Recommended Value Range and Current Status

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 1

1.3 Traffic Measurement Related to eNodeBs

Table 1-1 Main VQIs

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 2

E2E VQIs can be measured if the eRAN version is eRAN11.1 or later.

MOS Interval Corresponding to VQI Values Voice Quality Level

MOS > VQMAlgo.VqiExcellentThd (Default: 4) Excellent

MOS ≤ VQMAlgo.VqiBadThd (Default: 1) Bad

 VoLTE uplink packet loss rate

KPI Related KPI Calculation Measurement Calculation Formula Explanation to

 VoLTE downlink packet loss rate

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 4

the DRB service

1.4 Traffic Measurement Related to the CN

 ABCF Access Network IP QoS Send RTP Packets Bytes

1.4.2 EPC-Related Traffic Measurement

1.5 Test and Evaluation Methods

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 6

− Using the ATU connected to an external mobile phone

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 7

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 8

1.5.2.3 Tools on the EPC Side

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 9

1.5.3 Wireless Network Tools

Mandatory for Data Collection Duration Extraction

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 10

Mandatory for Data Collection Duration Extraction

Table 1-2 Voice quality accurate optimization and analysis

Task Audited Item

1.6 Overall MOS Optimization Procedure

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 11

For problem analysis on the RAN side,

Currently, the CCE can trace less

DT KPIs and poor-quality MOS (mobile

IMS: Handle the problems based on

without the SEQ deployed.

Find out the CHRs based on the

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 12

The counter range of the

1.6.1 Optimization on the EPC Side

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 13

Abnormal Uplink MOS

Does the packet No

Yes Does the packet No

Does the packet loss

Segmented demarcation: Segmented demarcation: Packet Segmented demarcation: Packet loss

Top N analysis: eNodeB Analysis based on the Top N analysis: SBC

Does The packet Demarcate and locate the

Segmented Segmented demarcation:

Packet Loss Rate Exception Between the UE and S-GW

Packet Loss Rate Exception Between the UGW9811 and SBC/UE

Issue 01 (2017-02-20) Huawei Proprietary and Confidential 15

Abnormal Downlink MOS

Does the packet loss No

Does the packet

Does the packet loss Yes Yes