Volte Huawei Ran - Technical Guideline Final

Ericsson Internal
Instruction 1 (123)
No.23215690
See below for Authors 3/10260-FAF102643 Uen

Approved Checked Date Rev Reference
Remo Agostino 2018-12-12 PA1
Contributors Janaka Pawan Narula &

Sooriyaaratchi Sandeep Singh
(Driver) (Authors)
Review Panel Janaka Syed Shah
Sooriyaaratchi Hussain Qadri
VoLTE Huawei RAN – Technical Guideline
Copyright
© Ericsson AB 2018 – All Rights Reserved
Disclaimer
This Multi-Vendor RAN/Tools Technical Guideline and its content (henceforth, referred to as the
document), is for reference purposes only and may be used by Ericsson Service Engineers. Ericsson
Service Engineers will need to determine the suitability and accuracy of this reference document for
their intended purposes as the content is based upon field experience and not multi-vendor product
knowledge. Furthermore, the multi-vendor product will continue to evolve, which in turn would
require further revisions of this document based upon future field experiences.
No part of this document may be reproduced in any form without the written permission of the
copyright owner. This document is subject to revision without notice due to continued progress in
software releases, software features, tools, methodology, and field experience. Ericsson shall have no
liability for any errors or damages resulting from the use of this document.
Access to this document is controlled and restricted to Ericsson Service Delivery Engineers. As
such, this document shall not be shared with other Ericsson Organizations or Business Units that do
not have a need from a Services Delivery perspective.
This is an Ericsson internal document and cannot be shared in whole or in parts outside the Ericsson
Services Domain (i.e. with other Ericsson organization or customers).
Ericsson Internal
2 (123)
No.23215690

Contents
1 Introduction.............................................................................................
1.1 Service Overview and Scope.....................................................
1.2 Service Entrance Criteria............................................................
1.3 HUAWEI RAN Product and Software.........................................
2 HUAWEI O&M..........................................................................................
2.1 Operation & Maintenance for RAN:............................................
2.2 VOLTE Activation parameters:...................................................
2.3 HUAWEI VOLTE KPIs:...............................................................
2.4 HUAWEI Specific Tools:.............................................................
2.4.1 System Overview U2000............................................................
2.4.2 NIC..............................................................................................
2.4.3 Traces.........................................................................................
2.4.4 BRDLOG.....................................................................................
3 VOLTE RAN AUDIT:................................................................................
3.1 RAN Configuration Audit............................................................
3.2 S-KPI & KPI Assessment...........................................................
3.3 Capacity Audit.............................................................................
3.3.1 VoLTE services and Network Capacity......................................
3.3.2 Factors affecting VoLTE Capacity..............................................
3.3.3 Optimizing PDCCH & PUCCH Capacity.....................................
3.3.4 VoLTE Packet Size.....................................................................
4 VOLTE TUNING/OPTIMIZATION............................................................
4.1 VoLTE Mobility/Layer Management...........................................
4.1.1 Idle Mode Mobility.......................................................................
4.1.2 Service Based HO......................................................................
4.1.3 Connected Mode Mobility...........................................................
4.1.4 VoLTE Layering Strategy...........................................................
4.2 VoLTE Parameters and Features:..............................................
4.2.1 Dynamic DRX: UE Power Consumption Saving.........................
4.2.2 VoIP Semi-persistent Scheduling: Capacity
Improvement for VOLTE Users..................................................
4.2.3 VoLTE Rate Control-Coverage Improvement for
VOLTE users:.............................................................................
4.2.4 Uplink RLC Segmentation Enhancement: Coverage
and Latency Improvement for VOLTE Users..............................
4.2.5 Uplink Compensation Scheduling: Quality
Improvement for VOLTE Users..................................................
4.3 VoLTE RAN Analytics (RCA for drive test and/or
cell trace)....................................................................................
4.4 VoLTE Feature and Parameter Tuning/Optimization
....................................................................................................
4.4.1 VOLTE DCR...............................................................................
4.4.2 VOLTE Voice Quality..................................................................
4.4.3 VOLTE Packet loss....................................................................
Ericsson Internal
3 (123)
No.23215690

4.4.4 SRVCC.......................................................................................
4.4.5 Miscellaneous.............................................................................
5 HUAWEI Projects....................................................................................
5.1 VoLTE Optimizations and Lessons learned.......................................
5.1.1 X2 Abnormal Link.......................................................................
5.1.2 UE Deregister.............................................................................
5.1.3 RTP Packet Loss........................................................................
5.1.4 Call Failure (Analysis from IMS).................................................
5.1.5 PCI Conflict.................................................................................
5.1.6 TAC-SGW & LAC-MSS mapping corrections.............................
5.1.7 SRVCC Execution Failures........................................................
5.1.8 SRVCC Preparation Failures......................................................
6 Revision History.....................................................................................
Ericsson Internal
4 (123)
No.23215690

1 Introduction
1.1 Service Overview and Scope
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 L16A & L17, 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.
1.2 Service Entrance Criteria

The purpose of this document is to enable the engineer with knowledge of HUAWEI specific following:
 RAN features and parameters
 OSS and Performance tools

Ericsson Internal
5 (123)
No.23215690

 Lessons learnt
1.3 HUAWEI RAN Product and Software

This version of the document is applicable to the following software versions:
 eRAN12.1
 eRAN13.1
This version of the document is applicable to the following BTS types:
 DBS3900_LTE  BTS3900_LTE  BTS3900_LTE

 BTS3900L_LTE  BTS3900AL_LTE  DBS3900A_LTE
 DBS3900_LampSite_LTE
2 HUAWEI O&M
2.1 Operation & Maintenance for RAN:

Ericsson Internal
6 (123)
No.23215690


Ericsson Internal
7 (123)
No.23215690


Ericsson Internal
8 (123)
No.23215690


Ericsson Internal
9 (123)
No.23215690


Ericsson Internal
10 (123)
No.23215690

2.2 VOLTE Activation parameters:
Following MML commands including required parameters need to be used for VOLTE activation
during VOLTE Deployment.
MOD ENODEBALGOSWITCH:EUTRANVOIPSUPPORTSWITCH=ON;
MOD GLOBALPROCSWITCH: ProtocolSupportSwitch=SupportS1UeCapMatchMsg-1;
MODENODEBALGOSWITCH:VQMALGOSWITCH=VQM_ALGO_SWITCH_ON,E2EVQIALGOSWITCH=ON
;
MODRLCPDCPPARAGROUP:RLCPDCPPARAGROUPID=0,DISCARDTIMER=DiscardTimer_Infinity;
MODCELLALGOSWITCH:LOCALCELLID=0,DLSCHSWITCH=DlVoipBundlingSwitch-1;
MOD CELLULSCHALGO:LOCALCELLID=0, UlEnhencedVoipSchSw=UlVoipPreAllocationSwtich-1;
MOD CELLHOPARACFG: LocalCellId=0, HoMrDelayTimerQci1=50;
To check whether a UE can perform voice services after the EutranVoipSupportSwitch

switch is turned on, perform the following steps:
Step 1 Run the LST ENODEBALGOSWITCH command to check whether the
EutranVoipSupportSwitch parameter is set to ON(On).
Step 2 Enable a UE to access a cell and perform voice services.
Step 3 View the E-RAB SETUP REQUEST and E-RAB SETUP RESPONSE messages for QCI 5
and QCI 1 in the S1 interface tracing task result on the U2000. Bearers for QCI of 5 and QCI
of 1 are successfully set up, as shown in below figures.
E-RAB SETUP REQUEST (QCI5)

Ericsson Internal
11 (123)
No.23215690

E-RAB SETUP RESPONSE (QCI5)
E-RAB SETUP REQUEST (QCI1)
E-RAB SETUP RESPONSE (QCI1)

Ericsson Internal
12 (123)
No.23215690

Check whether the following counters indicate successful voice service setup
 L.ERAB.SuccEst.QCI.1
Number of successful E-RAB setups initiated by UEs

for services with the QCI of 1 in a cell.
 L.ERAB.SuccEst.QCI.5
Number of successful E-RAB setups initiated by UEs

for services with the QCI of 5 in a cell.
VOLTE activation validation-Layer 3

Ericsson Internal
13 (123)
No.23215690

Initial Combined Attach process for both QCI5 & QCI9
Attached request was captured
This source of information depicts the QCI9 activation.
Under this message we see QCI5 activation

Ericsson Internal
14 (123)
No.23215690

VOLTE CALL iniitation process:
SIP request sent by the UE to Network followed by SIP Request/2.0 Ack
Invite request information that includes both caller and called number
Ericsson Internal
15 (123)
No.23215690

Under this message we see what sort of Codec is supported.
183 session progress is reported as a part of normal VOLTE call setup

Ericsson Internal
16 (123)
No.23215690

AMR-NB codec was selected by default.
Finally QCI1 activation was reported.
180 Ring was reported in the normal VOLTE call procedure.

Ericsson Internal
17 (123)
No.23215690

Finally 200 OK was reported
2.3 HUAWEI VOLTE KPIs:

Ericsson Internal
18 (123)
No.23215690

2.4 HUAWEI Specific Tools:
Fo ru mu las /Co u n te rs
OS S KPIs
Cate g o ry
S .No .
VoLTE Ca ll S e t up
1 Ac c e s s ibility 100 * (L.E-RAB.S uc c Es t.QCI.1 / L.E-RAB.AttEs t.QCI.1)
S uc c e s s Ra te
100*(( L.E-RAB.AbnormRe l.QCI.1+ L.E-RAB.AbnormRe l.MME.VoIP)
/
VoLTE Drop Ca ll
2 Re ta ina bility (L.E-RAB.AbnormRe l.e NBTot.QCI.1]+[L.E- RAB.AbnormRe l.MMETot.VoIP+L.E-
Ra te
RAB.NormRe l.QCI.1+L.IRATHO.S RVCC.E2W.Exe c S uc c Out+L.IRATHO.S RVCC.E2G.Exe
c S uc c Out))
('L.Tra ffic .DL.PktUuLos s .Los s .QCI.1 (pa c ke t)/ 'L.Tra ffic .DL.PktUuLos s .Tot.QCI.1
3 Re ta ina bility Pa c ke t Los s (DL)
(pa c ke t))*100
('L.Tra ffic .UL.PktLos s .Los s .QCI.1 (pa c ke t)/'L.Tra ffic .UL.PktLos s .Tot.QCI.1
4 Re ta ina bility Pa c ke t Los s (UL)
(pa c ke t))*100
((L.Tra ffic .UL.S CH.QPS K.ErrTB.Ible r.QCI.1+L.Tra ffic .UL.S CH.16QAM.ErrTB.Ible r.QCI.1+
5 Qua lity BLER_UL L.Tra ffic .UL.S CH.64QAM.ErrTB.Ible r.QCI.1)/(L.Tra ffic .UL.S CH.QPS K.TB.QCI.1+L.Tra ffi
c .UL.S CH.16QAM.TB.QCI.1+L.Tra ffic .UL.S CH.64QAM.TB.QCI.1))*100
((L.Tra ffic .DL.S CH.QPS K.ErrTB.Ible r.QCI.1+L.Tra ffic .DL.S CH.16QAM.ErrTB.Ible r.QCI.1+
L.Tra ffic .DL.S CH.64QAM.ErrTB.Ible r.QCI.1+L.Tra ffic .DL.S CH.256QAM.ErrTB.Ible r.QCI.1
6 Qua lity BLER_DL
)/(L.Tra ffic .DL.S CH.QPS K.TB.QCI.1+L.Tra ffic .DL.S CH.16QAM.TB.QCI.1+L.Tra ffic .DL.S
CH.64QAM.TB.QCI.1+L.Tra ffic .DL.S CH.256QAM.TB.QCI.1))*100
VoLTE Intra -LTE ((L.HHO.Intra e NB.Intra Fre q.Exe c S uc c Out.VoIP +
8 Mobility Ha ndove r S uc c e s s L.HHO.Inte re NB.Intra Fre q.Exe c S uc c Out.VoIP)/(L.HHO.Intra e NB.Intra Fre q.Exe c AttOut.V
Ra tio oIP + L.HHO.Inte re NB.Intra Fre q.Exe c AttOut.VoIP))*100
((L.HHO.Intra e NB.Inte rFre q.Exe c S uc c Out.VoIP +
VoLTE Inte r- L.HHO.Inte re NB.Inte rFre q.Exe c S uc c Out.VoIP+L.HHO.Intra e NB.Inte rFddTdd.Exe c S uc c O
Fre que nc y ut.VoIP+L.HHO.Inte re NB.Inte rFddTdd.Exe c S uc c Out.VoIP)/(L.HHO.Intra e NB.Inte rFre q.Ex
9 Mobility
Ha ndove r S uc c e s s e c AttOut.VoIP +
Ra tio L.HHO.Inte re NB.Inte rFre q.Exe c AttOut.VoIP+L.HHO.Intra e NB.Inte rFddTdd.Exe c AttOut.V
oIP+L.HHO.Inte re NB.Inte rFddTdd.Exe c AttOut.VoIP))
VoLTE S RVCC
11 Mobility Ha ndove r S uc c e s s
Ra te ([L.IRATHO.S RVCC.E2W.Exe c S uc c Out/[L.IRATHO.S RVCC.E2W.Exe c AttOut])*{100}
VoLTE S RVCC (L.IRATHO.S RVCC.E2W.Exe c AttOut + L.IRATHO.S RVCC.E2G.Exe c AttOut) / L.E-
12 Mobility
IRAT Pe r c a l ra te RAB.AttEs t.QCI.1 x 100%
Ericsson Internal
19 (123)
No.23215690

2.4.1 System Overview U2000

First of all, we have to check the alarms site. If there is any active alarm that can affect the
service, we have to request to Wireless Team to solve it.
Import the attached query (.xml) to obtain the necessary counters for the troubleshooting.
Ericsson Internal
20 (123)
No.23215690

Select the cells of the site that you are checking.
Select the period of time.

Ericsson Internal
21 (123)
No.23215690

2.4.2 NIC
NIC webpage: https://ip_U2000_server/nic
Ericsson Internal
22 (123)
No.23215690

NIC webpage: introduce the same user/password than U2000 Server.
2.4.2.1 NIC-CHR
CHR: create/modify a CHR task
Ericsson Internal
23 (123)
No.23215690

CHR: select the period
CHR: select the eNodeB/s

Ericsson Internal
24 (123)
No.23215690

CHR: Check that “Call log collection” is selected.
CHR: keep everything blank.

Ericsson Internal
25 (123)
No.23215690

CHR: Click on “Finish”
CHR: Once the task is completed, download it

Ericsson Internal
26 (123)
No.23215690

2.4.2.2 XML:create/modifyaXMLtask
XML:selecttheperiod
Ericsson Internal
27 (123)
No.23215690

XML:selecttheeNodeB/s
XML:Checkthat“eNodeBconfigurationxmonly”isselected.
Ericsson Internal
28 (123)
No.23215690

XML:keepeverythingblank.
XML:Clickon“Finish”
Once the task is completed, download it

Ericsson Internal
29 (123)
No.23215690

2.4.3 Traces
2.4.3.1 S1 Interface Trace
With the help of S1 interface tracing we can analysis the signalling between ENB and MME, it helps
to track the abnormal release cases due to MME
S1 Interface Trace: New

Ericsson Internal
30 (123)
No.23215690

With the help of S1 interface tracing we can analysis the signalling between ENB and MME, it helps to
track the abnormal release cases due to MME
S1 Interface Trace: Select the eNodeBs and schedule the trace (start/stop). Next.
S1 Interface Trace: De-select S1AP_PAGING. Finish.

Ericsson Internal
31 (123)
No.23215690

2.4.3.2 X2 Interface Trace
X2 Interface Trace: New & Select the eNodeBs and schedule the trace (start/stop).
X2 interface links the 2 ENBs and play vital role to maintain the running call continuity.
Tracing the X2 interface will help to resolve poor handover cases causing drop calls.
Ericsson Internal
Instruction 32 (123)
Prepared (Subject resp) No.

Approved (Document resp) Checked Date Rev Reference
X2 Interface Trace: Finish.
2.4.3.3 Uu Interface Trace: New & Select the eNodeBs and schedule the trace
(start/stop). Next.
With the help of Uu trace, we can decode the ongoing signaling between UE <> Network to further drill down the main
cause of drop call i.e. poor coverage or quality
Ericsson Internal

Uu Interface Trace: De-select S1AP_PAGING. Finish.
2.4.4 BRDLOG
BRDLOG: Software -> Software Browser
It enables the recovery of the Board logs to be shared further with the Wireless domain for deep dive
investigation or we can process with NPMaster or PCHR analysis tools.
BRDLOG: Select BRDLOG -> Transfer -> From NE to OSS Client

Ericsson Internal

BRDLOG: Select the eNodeB.
Select Files -> ALL

Set Parameters -> Source File Type-> DRDLOG (Copositive Log)
Compression Flag->COMPRESSED (Compressed)
Local path: introduce the path to download the BRDLOG.
BRDLOG: Continue? -> Yes

Ericsson Internal

BRDLOG: Download Completed.

Ericsson Internal

3 VOLTE RAN AUDIT:
3.1 RAN Configuration Audit
3.2 S-KPI & KPI Assessment

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:
• 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.
• 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.
Correlation Between S-KPI & R-KPI

S-KPIs
Target
Status
Sr.No.
RAN
1 CALL SETUP SUCCESS RATE (V-2-V=TAS) >99% KPI
CSSR Anova
E/// Rec
<3s*
CALL SETUP TIME (UL Post dial delay) Bharti Anova
Rec <2.5
2 s CSSR
3 CALL SETUP TIME (DL Post dial delay) CSSR Anova
4 RRC CONNECTION SUCCESS RATE* >99 % RRC SR OSS
5 RAB SETUP SUCCESS RATE* >99% RAB SR OSS
6 ATTACH FAILURE RATIO* ( 21:00 hrs) <1% Attach SR Anova
7 RRC CONNECTION TIME <50 ms call setup time from Radio-Drive test Not Avl in Anova & OSS
8 ATTACH SETUP TIME ( 21:00 hrs) <400 ms attach Setup time from Radio-Drive test Anova
EPS BEARER SETUP TIME ( 21:00 hrs) Anova

9 <100ms E RAB setup time from radio-Drive test
10 SIP REGISTRATION / SESSION SETUP TIME <1 s Session setup time excluding Radio Anova
11 QUALITY [MOS] >3.5 DL Latency per QCI 1 Anova
E/// Rec
<225ms*
MOUTH TO EAR DELAY ( Taken avg of cell wise ) Bharti Anova
Rec
12 <160ms DL Latency per QCI 1
LATENCY / DELAY <40ms Anova

13 avg_rtt_dl DL Latency per QCI 1
14 PACKET LOSS RATE*UL <0.5% DL / UL Packet Loss Rate per QCI 1 Anova
15 PACKET LOSS RATE*DL <0.5% DL / UL Packet Loss Rate per QCI 1 Anova
16 JITTER_UL <40ms DL / UL Packet Loss Rate per QCI 1 Anova
17 JITTER_DL <40ms DL / UL Packet Loss Rate per QCI 1 Anova
18 ERAB ABNORMAL RELEASES* <0.5% E-RAB Retainability QCI 1 OSS
Ericsson Internal

19 HOSR(Intra LTE HOSR QCI1) >97% HOSR OSS

20 SRVCC(Inter RAT) >97% SRVCC SR OSS
21 one way audio <0.5% DL / UL Packet Loss Rate per QCI 1 Anova
22 Media Gap_5sec combined <2% DL / UL Packet Loss Rate per QCI 1 Anova
23 %_a.5sec_ul_media_gap_calls <2% DL / UL Packet Loss Rate per QCI 1 Anova
E/// Rec
>98%*
Call Completion Rate Bharti Anova
Rec
24 >99.5 E-RAB Retainability QCI 1
Media Gap File Extract Crunching

Ericsson Internal

Media Gap File extraction Process
3.3 Capacity Audit
3.3.1 VoLTE services and Network Capacity
Physical Channels Capacity:
• PDCCH
• PUCCH
• Paging
• PDSCH
• PUSCH
Increasing load in Physical Channels
Maximum number of VoLTE users within a cell
Based on previous table, PDCCH is limiting the capacity for all channel bandwidths. For 1.4MHz PUSCH channel
can also limit the VoLTE capacity.
Ericsson Internal

3.3.2 Factors affecting VoLTE Capacity
License for number of simultaneous bearers
VoLTE dedicated bearer license
VoLTE capable handsets will add default IMS bearers (QCI5) and once VoLTE call is setup dedicated (QCI1)
bearers are created as well and thus, license capacity needs to be proactively monitored and upgraded before
capacity is exceeded.
3.3.3 Optimizing PDCCH & PUCCH Capacity
In order to be able to support higher number of users it is necessary to upgrade and optimise the PDCCH & PUCCH
channel so it does not become a bottleneck. Possible actions include:
Activate usage based PDCCH & PUCCH Adaptation
Decrease PDCCH& PUCCH load
Optimise via parameters the PDCCH aggregation level for different types of resource allocation ( system information,
paging, random access, user plane resources)
Optimise via parameters the PDCCH & PUCCH outer loop link adaptation, the allocation share between uplink and
downlink resource allocations or using a scaling factor for PDCCH & PUCCH load
3.3.4 VoLTE Packet Size
It depends on a lot of variables, including the voice coder choices, the RF conditions in the cell, the Huawei eNB’s
scheduler algorithm, the 3GPP protocol releases options, and so on. To keep this discussion at manageable levels,
let’s concentrate on one particular aspect of VoLTE capacity: how many Physical Resource Blocks (PRBs) are needed
to deliver the traffic for one VoLTE call over a typical LTE Uu air interface? Let’s assume for the moment that the
operator has deployed channel bandwidth of 10 MHz LTE radio channels(Which is most operators are deploying their
LTE services at phase 1 stage). This is fairly typical to provides 50 PRBs per millisecond on the downlink (somehow it
will be lesser than 50 PRBs resources on the uplink, due to the PUCCH configuration & limitations).
Let’s further presume that VoLTE is configured to use the Adaptive Multi-Rate Wideband (AMR-WB) 12.65 coder, and
that Robust Header Compression (RoHC) is enabled over the air interface which to reduce the overhead consumption
over the LTE air interface. Huawei VoLTE scheduling are based on 20ms per Time-Transmission-Interval,
TTI( Huawei Proprietary), and the AMR-WB 12.65 coder generates 253 bits of coded speech every 20 ms (a net data
rate of 12.65 kbps). In order to deliver each voice services to the UE, additional protocol headers are needed, such as
an RTP header (typically 12 bytes), a UDP header (8 bytes), and an IPv6 header (40 bytes). This brings the total
packet length up to some 733 bits every 20 ms.
Ericsson Internal

RoHC (Robust Overhead Compression), however, will replace with RTP, UDP and IP headers with a much smaller
RoHC header before the packet is actually transmitted over the air. The length of the RoHC header will vary
depending on the particular circumstances, but it will average around 3 bytes, or 24 bits. The RLC and MAC layers will
add their own overhead, so the end result is that the air interface will have to transport roughly 300 bits of data for
every VoLTE packet scheduled to one User. VoLTE vs. PRBs Now we need to relate the above data size back into
our LTE Air Interface resources. A single PRB has 12 subcarriers and 14 symbols over the course of 1 ms, or 12 x 14
= 168 resource elements (REs). Some of those REs are occupied by the PDCCH (Assuming max 3 symbols are used
for PDCCH) and the downlink reference signals RS, leaving about 120 REs per PRB to carry data on the downlink.
Each RE carries 2, 4 or 6 coded bits, depending on the modulation scheme in effect (QPSK, 16QAM or 64QAM,
respectively), but some of those bits will be data bits, and some will be error protection bits. So how many data bits will
fit in a single PRB? That depends on the specific RF conditions in the cell which will be feedback by the User on the
uplink, that will be Channel Quality Indicator, CQI table below.
Ericsson Internal

Let’s see what happens under good (CQI = 15), average (CQI = 7) and poor (CQI = 1) situations.  CQI 15
transmissions use 64QAM modulation and a 948/1024 = 0.926 effective coding rate, which means that each RE holds
6 x 0.926 = 5.55 data bits on average. A single PRB can then carry 120 x 5.55 = 666 data bits, or the equivalent of two
VoLTE voice samples. LTE can’t allocate less than one PRB per user, though, so we’ll count this as one PRB per
VoLTE call.  CQI 7 transmissions use 16QAM modulation and a 378/1024 = 0.369 coding rate, resulting in 4 x 0.369
x 120 = 177 data bits. In other words, two PRBs are needed to carry a single VoLTE voice sample.  CQI 1
transmissions use QPSK modulation and a 78/1024 = 0.076 coding rate, supporting 2 x 0.076 x 120 = 18 data bits per
PRB. This means that a single VoLTE packet requires about 16 PRBs.
Ericsson Internal

VoLTE by the Numbers So how many VoLTE calls can we squeeze into a 10 MHz LTE channel? Voice samples are
generated every 20 ms, so if everything lines up exactly right (and no retransmissions are needed), then twenty
VoLTE calls can share the same set of PRBs, one after the other. The maximum number of VoLTE calls that can be
carried is then determined by: ((Number of Available PRBs) / (Number of PRBs per VoLTE Call)) x 20 Here are the
results, per CQI:
Thus, how realistic are these numbers? There are many presumptions built in to this calculation, most of which
wouldn’t hold true out in the real world:  All users in a cell would not report exactly the same CQI value, and a cell
where every UE reports CQI value 1 is basically unusable.  VoLTE packet arrivals would not be perfectly distributed
across the 20 ms coding intervals.  Most packets would require at least one HARQ retransmission, especially at
lower CQI values, which consumes additional PRBs.  Some capacity needs to be reserved for non-VoLTE (data)
subscribers.  The uplink has a lower capacity than the downlink, in terms of the number of PRBs available and the
efficiency of the transmissions.
4 VOLTE TUNING/OPTIMIZATION
Tuning vs Optimization
Tuning is pre-launch drive test/friendly user-based activities to prepare VoLTE for commercial launch. VoLTE
Optimization has greater emphasis on OSS based activities with greater reliance on sufficient VoLTE subscriber base
in order to optimize network performance and resolve dominant failure or performance issues.
Ericsson Internal

4.1 VoLTE Mobility/Layer Management
The layering strategy for the initial VoLTE deployments globally is depending on country regulations, network topology
and available spectrum
However, VoLTE traffic steering with proper layering management could be beneficial in order to improve network
efficiency and end user experience for both VoLTE and data services.
• Steering VoLTE traffic to dedicated layer free up control and data channel resources for non-VoLTE
users and thus, average throughput of data users might increase.
• Target VoLTE layer may have a better continuous coverage and therefore, VoLTE speech quality is
improved due to less frequent IFHO/SRVCC handovers, i.e. less voice interruptions during HO
measurement and execution phase.
• VoLTE calls can be steered to the preferred frequency layer using either service based handover upon
QCI1 bearer establishment or coverage/load based handovers.
On the other hand, traffic steering is also increasing inter-frequency handovers in the network which might lead drop
calls unless mobility parameters are properly optimized.
4.1.1 Idle Mode Mobility
General strategy
The general strategy is to use idle mode reselection based on absolute priorities, i.e. UEs are pushed to the highest
priority LTE layer (e.g. carrier with largest bandwidth) and UEs only move away from the highest priority layer when
coverage becomes poor.
• Higher Priority Reselection: UE always searches for higher priority layers

Ericsson Internal

• Lower Priority Reselection: UE only searches for lower priority when source layer falls below a
certain threshold
Note that VoLTE users cannot be steered differently from data users in idle mode, i.e. existing strategy applies also
after VoLTE deployment.
4.1.2 Service Based HO
Considerations for SBHO parameterization
Service based handover is recommended to offload VoLTE users to preferred frequency layers from non-VoLTE
layers.
However, the target VoLTE layer should be set as a lower priority layer for idle mode cell reselection otherwise non-
VoLTE users can camp VoLTE preferred layer and establish PS data call
Ericsson Internal

4.1.3 Connected Mode Mobility
General strategy for VoLTE
The general strategy for VoLTE deployment is to initially enable voice service on all carriers in the network in order to
ensure maximum coverage and accessibility.
Once VoLTE traffic is increasing the strategy should be reviewed and possible layering options studied to gain
understanding of the impact of network capacity and coverage on both VoLTE and data services.
VoLTE preferred frequencies can be chosen based on the following factors:
• Coverage: Contiguous coverage to avoid risk of dropped calls due to IFHO or SRVCC handovers.
Alternatively, low frequency band operation for higher cell range is beneficial to minimize the number
of handovers as well as to provide a good indoor coverage.
• Capacity: Frequency band with highest capacity (i.e. large bandwidth) can serve more VoLTE users and
on the other hand, data users might have improved throughputs on non-VoLTE layers due to more
scheduling occasions without VoLTE traffic.
Ericsson Internal

4.1.4 VoLTE Layering Strategy
Considerations for IFHO parameterization
LTE inter-frequency measurement can be triggered at the same conditions (threshold2InterFreqQci1 =

threshold2InterFreq) for both VoLTE and non-VoLTE users but measurements should not be configured too early
before better cell (A3) criteria can be met because there is no data transmission during measurement gaps which may
lead to user throughput and speech quality deterioration.
The better cell (A3) inter-frequency handover from co-sited low frequency band to high frequency band layer is
advisable to be disabled for both VoLTE and data service and use idle mode selection instead to avoid frequent
IFHOs.
Note also that frequent IFHO attempts might increase the probability of VoLTE call drops in case IFHO handover is in
progress while EPC requests to modify/release QCI1 bearer and therefore, eNB may reject ‘parallel’ EPC request
(36.413 - chapter 8.2) causing failure from MME/PGW perspective.
GBR E-RAB modification can occur when core network supports services which may require a change in the GBR
bitrate, e.g. answering machine and conference call.
VoLTE Layering Strategy for SRVCC
SRVCC Tuning/Optimization
The following types of SRVCC triggers are possible on Huawei RAN product:
For mandatory handovers, for example, coverage-based and UL-quality-based handovers, SRVCC can be triggered
when SRVCC is configured in the inter-RAT handover policy groups for QCI 5 and QCI1.
For optional handovers, for example, load-based, service-based, and CSFB-based handovers, SRVCC can be
triggered when SRVCC is configured in the inter-RAT handover policy groups for all QCIs.
Coverage-based SRVCC: Coverage Based SRVCC is based on the Coverage threshold-B1 threshold i.e.
RSCP(UTRAN) and Rx level (GERAN). Trigger in EUTRAN cell edge with B1 event.
Service-based SRVCC: During a service-based handover for SRVCC, the eNodeB can transfer a UE to an appropriate
RAT system based on the services that are running on the UE. Totally 3 modes can be configured by MOD
ServiceIrHoCfgGroup.InterRatHoState for each QCI: NO_HO, PERMIT_HO, MUST_HO. If QCI1 is configured to
MUST_HO, eNB will trigger SRVCC procedure once UE setup QCI1.
Distance-based SRVCC: In a distance-based inter-RAT handover, the deviation in the estimated distance between the
UE and eNodeB is about 100 meters to 150 meters. Distance-based inter-RAT handover can reduce the probability of
the UEs being handed over to an inter-RAT cell with which the E-UTRAN cell does not have neighbor relationships,
but both the cells overlap in coverage. When a distance-based inter-RAT handover is triggered, and the UE is running
a VoIP service, the eNodeB may trigger an SRVCC procedure according to the measurement result reported by the
UE.
Uplink-quality-based SRVCC: When the eNodeB detects that the uplink signal quality is poor and the UE is running a
VoIP service, the eNodeB may trigger an SRVCC procedure based on the measurement result reported by the UE.
Ericsson Internal

Load-based SRVCC: EUTRAN is high load, and UTRAN & GERAN neighbour cell is low load.
SPID-based SRVCC: In an SPID-based handover, a UE can be handed over from the visited PLMN to its HPLMN
when it moves back to the home E-UTRAN. In this scenario, the eNodeB may trigger an SRVCC procedure when the
UE is running a VoIP service. For details about the algorithm of SPID-based handover back to the HPLMN.
LCS(Location Services) based SRVCC: LCS-based SRVCC is controlled by LcsSrvccSwitch under the
ENodeBAlgoSwitch.HoModeSwitch parameter. It also depends on the UTRAN LCS capability, which is controlled by
the CSFallBackBlindHoCfg.UtranLcsCap parameter.LCS-based SRVCC is used when a UE triggers LCS in an LCS-
incapable LTE network.The procedure for LCS-based SRVCC is the same as that for CSFB to UTRAN, and LCS-
based SRVCC is controlled by the parameters for CSFB
SRVCC to UTRAN is possible for the following options:
VoIP PS handover: To trigger CS+PS SRVCC, you must perform the following operations:
Select the UtranSrvccSwitch option of the ENodeBAlgoSwitch.HoModeSwitchparameter.
Select the UtranPsHoSwitch option of the ENodeBAlgoSwitch.HoModeSwitchparameter.
Enable UTRAN cell CS and PS handover indication, which is controlled by the

UtranExternalCell.CsPsHOInd parameter. If this parameter is set toBOOLEAN_FALSE(False), the external UTRAN
cell does not support SRVCC for concurrent CS and PS services. If this parameter is set to BOOLEAN_TRUE(True),
the external UTRAN cell supports SRVCC for concurrent CS and PS services.
For macro and LampSite eNodeBs, when triggering SRVCC for CS+PS services, the eNodeB decides whether to
check CS and PS handover indication of the external UTRAN cell based on the
CnOperatorHoCfg.SrvccWithPsBasedCellCapSw parameter.
When this parameter is set to ON, the eNodeB does not check the CsPsHOInd parameter of external UTRAN cells.
When this parameter is set to OFF, the eNodeB checks the CsPsHOInd parameter of external UTRAN cells.
For micro eNodeBs, when triggering SRVCC for CS and PS services, the eNodeB does not support the
CnOperatorHoCfg.SrvccWithPsBasedCellCapSw parameter and checks CS and PS handover indication of the
external UTRAN cell directly.
CS-only SRVCC: To trigger CS-only SRVCC, you must perform the following operations:
Select the UtranSrvccSwitch option of the ENodeBAlgoSwitch.HoModeSwitch
parameter.
SRVCC to GERAN is possible for the following options:
CS+PS SRVCC: To trigger CS+PS SRVCC, you must perform the following operations:Select the GeranSrvccSwitch
option of the ENodeBAlgoSwitch.HoModeSwitch parameter.l Select the GeranPsHoSwitch option of the
ENodeBAlgoSwitch.HoModeSwitch parameter.
CS-only SRVCC: To trigger CS-only SRVCC, you must perform the following operations:
Select the GeranSrvccSwitch option of the ENodeBAlgoSwitch.HoModeSwitch parameter.
Ericsson Internal

4.2 VoLTE Parameters and Features:
4.2.1 Dynamic DRX: UE Power Consumption Saving
The Huawei feature LOFD-00110501 Dynamic DRX allows UEs to enter power saving or reduced signaling mode
based on UE power consumption and network load. When UEs in connected mode are moving at high speeds,
frequent handovers occur. ... DRX is a technology in which a UE can switch between active and sleep states.
Note:
Different DRX parameters are configured for different types of UEs, such as smartphones, Voice and packet service
( USB dongles, customer premises equipment (CPE)). Different types of services vary in packet transmission times
and must be configured with different DRX parameters. DRX configuration is differentiated based on UE types and
service types to achieve a minimum consumption of power.
Ericsson Internal

For VoIP services, a set of special DRX parameter settings are available for reducing UE power consumption while
maintaining VoIP capacity
DRX parameters for various scenarios:
DRX Parameters for Common UEs

DRX Parameters for Special UEs
VoIP Services Non-VoIP Services
LongDrxCycle LongDrxCycle LongDrxCycleSpecial
Ericsson Internal

SupportShortDrx SupportShortDrx SupportShortDrxSpecial

N/A ShortDrxCycle ShortDrxCycleSpecial
N/A DRXShortCycleTimer DrxShortCycleTimerSpecial
OnDurationTimer OnDurationTimer OnDurationTimerSpecial
DrxInactivityTimer DrxInactivityTimer DRXInactivityTimerSpecial
DRXReTxTimer DRXReTxTimer DRXReTxTimer
Impact on the Network:
 A over-small value of the OnDurationTimer parameter results in lower VoIP capacity.
 A over-large value of the LongDrxCycle parameter prolongs the SRS reporting period and therefore
deteriorates UL synchronization performance.
 A large value of the LongDrxCycle parameter prolongs the CQI reporting period and therefore a decrease in
the throughput under functions such as scheduling and multiple-input multiple-output (MIMO).
 A short sleep time in DRX has a negative impact on ANR measurements.
Key Parameters:
Parameter
MML Command Configured Parameter Recommended Value Technology
Name
LST
VOLTE
CELLDRXPARA
Local cell ID LocalCellId None
MOD
CELLDRXPARA
MOD
VOLTE
FDD enter CELLDRXPARA
FddEnterDrxThd 300
DRX threshold LST
CELLDRXPARA
MOD
VOLTE
FDD exit DRX CELLDRXPARA
FddExitDrxThd 800
threshold LST
CELLDRXPARA
MOD
Data amount CELLDRXPARA
DataAmountStatTimer 30
Statistic timer LST
CELLDRXPARA
ADD
DRXPARAGROU
P
LST
DRXPARAGROU
P
Local cell ID LocalCellId None
MOD
DRXPARAGROU
P
RMV
DRXPARAGROU
P
Ericsson Internal

ADD
DRXPARAGROU
P
LST
DRXPARAGROU
DRX
P
parameter DrxParaGroupId None
MOD
group ID
DRXPARAGROU
P
RMV
DRXPARAGROU
P
ADD
DRXPARAGROU QCI 1: ON(On) VOLTE
P
MOD
DRXPARAGROU QCI 2: OFF(Off)
P
LST
Enter DRX DRXPARAGROU QCI 3: OFF(Off)
EnterDrxSwitch
Switch P
QCI 4: ON(On)
QCI 5: OFF(Off)
QCI 6: ON(On)
QCI 7: OFF(Off)
QCI 8: ON(On)
QCI 9: ON(On)
ADD
QCI 1- PSF10(10
DRXPARAGROU VOLTE
subframes)
P
MOD
QCI 4-FDD: PSF2(2
DRXPARAGROU
subframes)
P
On Duration
LST OnDurationTimer
Timer QCI 6-FDD: PSF2(2
DRXPARAGROU
subframes)
P
QCI 8-FDD: PSF2(2
subframes)
QCI 9-FDD: PSF2(2
subframes)
DRX Inactivity ADD DrxInactivityTimer
QCI 1- PSF3(3
Timer DRXPARAGROU VOLTE
subframes)
P
MOD
QCI 4-FDD: PSF4(4
DRXPARAGROU
subframes)
P
LST
QCI 6-FDD: PSF3(3
DRXPARAGROU
subframes)
P
QCI 8-FDD: PSF3(3
subframes)
Ericsson Internal

QCI 9-FDD: PSF3(3

subframes)
ADD
QCI 1: sf8(8
DRXPARAGROU VOLTE
subframes)
P
MOD
QCI 4: sf8(8
DRXPARAGROU
subframes)
DRX P
Retransmissio LST DrxReTxTimer
QCI 6: sf8(8
n Timer DRXPARAGROU
subframes)
P
QCI 8: sf8(8
subframes)
QCI 9: sf8(8
subframes)
ADD
QCI 1: SF20(20
DRXPARAGROU VOLTE
subframes)
P
MOD
QCI 4: SF20(20
DRXPARAGROU
subframes)
P
Long DRX
LST LongDrxCycle
Cycle QCI 6: SF40(40
DRXPARAGROU
subframes)
P
QCI 8: SF40(40
subframes)
QCI 9: SF40(40
subframes)
ADD QCI 1:
DRXPARAGROU UU_DISABLE(Disabl VOLTE
P e)
MOD QCI 4:
DRXPARAGROU UU_ENABLE(Enable
P )
Short-cycle
LST QCI 6:
DRX
DRXPARAGROU SupportShortDrx UU_ENABLE(Enable
supported
P )
indication
QCI 8:
UU_ENABLE(Enable
)
QCI 9:
UU_ENABLE(Enable
)
Short DRX ADD ShortDrxCycle
QCI 4: SF5(5
Cycle DRXPARAGROU VOLTE
subframes)
P
MOD
QCI 6: SF5(5
DRXPARAGROU
subframes)
P
LST QCI 8: SF5(5
DRXPARAGROU subframes)
Ericsson Internal

P
QCI 9: SF5(5
subframes)
ADD
DRXPARAGROU QCI 4: 2 VOLTE
P
MOD
DRX Short DRXPARAGROU QCI 6: 8
DrxShortCycleTimer
Cycle Timer P
LST
DRXPARAGROU QCI 8: 8
P
QCI 9: 8
MOD DRX
DRX switch DrxAlgSwitch OFF(Off)
LST DRX
Short-cycle MOD DRX VOLTE
ShortDrxSwitch ON(On)
DRX switch LST DRX
Special long MOD DRX VOLTE
LongDrxCycleSpecial SF10(10 subframes)
DRX cycle LST DRX
Special On MOD DRX
OnDurationTimerSpecial PSF4(4 subframes)
Duration timer LST DRX
Special short MOD DRX VOLTE
ShortDrxCycleSpecial SF10(10 subframes)
DRX cycle LST DRX
Special DRX MOD DRX VOLTE
DrxShortCycleTimerSpeci
short cycle 1
LST DRX al
timer
DRX practical benefits after change implementation:

Ericsson Internal

Another set of improvement in KPIs
Pre and post of UE power value.

Ericsson Internal

4.2.2 VoIP Semi-persistent Scheduling: Capacity Improvement for VOLTE Users
The concept of semi-persistent scheduling is very straight forward: perform persistent scheduling for the initial voice
PDU transmission and dynamic scheduling for SID PDUs and HARQ transmission. The aim of semi-persistent
scheduling is to schedule voice PDUs less frequently, while maintaining the same allocation over an extended period
of time. For each individual voice call, persistent scheduling is valid for the entire active period of a talk spurt. In this
case PDCCH resources are required only when a call enters the active state, thus saving a considerable amount of
PDCCH resources which can be utilized for other calls (hence increasing system call capacity).
Huawei introduces the VoIP semi-persistent scheduling feature for small-packet services that are periodically
transmitted such as VoLTE. Before entering talk spurts, the eNodeB allocates fixed resources to UEs through the
PDCCH message. Before exiting talk spurts or releasing resources, the UEs do not need to apply for resource
allocation from the PDCCH again, thereby saving PDCCH resources.
After the PDCCH message is sent, voice packets are sent at the intervals specified by CellUlschAlgo.UlSpsInterval
and CellDlschAlgo.DlSpsInterval. If the semi-persistent scheduling intervals are small, the scheduling delay of voice
packets is small, which means that VoLTE users can enjoy higher voice quality.
Capacity & Error free Enhancement
SPS is a feature that significantly reduces control channel overhead for applications that require persistent radio
resource allocations such as VoIP.
When the capacity is low due to high PDCCH overheads, these features can be used to reduce PDCCH overheads
and therefore increase the maximum number of VoLTE users or the throughput of data services (provided that the
number of VoLTE users remains unchanged).
MOD CELLALGOSWITCH:LOCALCELLID=0,RacAlgoSwitch=VoltePrefAdmissionSwitch-1&VoltePreemptionSwitch-
1,QciParaEffectFlag=ON,UEINACTIVETIMERQCI1SWITCH=ON,UlSchExtSwitch=UlVoipRbRsvSwitch-1;
MODCELLULSCHALGO:LOCALCELLID=0,ULDELAYSCHSTRATEGY=VOIP_DELAYSCH,ULENHENCEDVOIPSCH
SW=UlVoLTEDataSizeEstSwitch-1&UlVoipSchOptSwitch-1&UlVoipServStateEnhancedSw-
1&UlCallMuteRecoverSwitch-
1,ULCOMPENSCHPERIODINSPURT=INTERVAL_ADAPTIVE,ULCOMPENSCHPERIODINSILENCE=INTERVAL_80,
SinrAdjTargetIblerforVoLTE=3,ULVOIPRSVRBSTART=10, UlVOIPRSVRBNUM=N20;
MOD CELLDRXPARA: LocalCellId=0, DRXSTOPSRPENDINGSW=ON;MOD CELLRACTHD: LocalCellId=0,
VolteReservedNumber=30, VoltePrefAdmissionTimer=5;
Ericsson Internal

As expected a slight reduction of the PDCCH error rate can be observed
Another set of improvement in KPIs:
 Improvement Observed in DL & UL Packet Loss Rate.

 Improvement Observed in BLER DL Rate.
Ericsson Internal

4.2.3 VoLTE Rate Control-Coverage Improvement for VOLTE users:
VoLTE Rate Control adjusts the AMR-NB/AMR-WB rate for uplink voice services depending
on the uplink channel quality and voice quality.
When the uplink channel quality and voice quality are favorable, a high voice coding
rate is used to further improve voice quality.
When the uplink channel quality and voice quality are poor, a low voice coding rate is
used to reduce the uplink packet loss rate and improve uplink voice coverage.
In scenarios where downlink coverage is limited prior to uplink coverage (for example, in
the coverage area of a micro or LampSite base station), UEs' uplink channel quality and
voice quality may not meet the conditions for using low voice coding rates. In such scenarios, it is difficult to trigger the
decrease of voice coding rates.
When the VoLTE user code rate=23.85, and the ul packet loss rate >3%(6*0.005)
in two continuous 2.5 second period, and the channel quality< Threshold1
(Compute according RsnThldForDecreasingAmr), the code rate will decrease to 12.65.
When the VoLTE user code rate=12.65, and the ul packet loss rate<1%(2*0.005) ) in two continuous 2.5 second
period, and the channel quality> Threshold2
(Compute according RsnThldForIncreasingAmr), the code rate will increase to 23.85.
Local AmrGr HigherAmrC LowerAmrC PlrThldForDec PlrThldForInc RsnThldForDe RsnThldForInc

CellId oupId odingMode odingMode reasingAmr reasingAmr creasingAmr reasingAmr
0 0 AMR_WB_2 AMR_WB_1 6 2 14 5
3_85kbps 2_65kbps
1 AMR_WB_1 AMR_WB_6 16 2 14 5
2_65kbps _6kbps
2 AMR_NB_12 AMR_NB_7 6 2 14 5
_2KBPS _4KBPS
3 AMR_NB_7_ AMR_NB_4 10 2 14 5
4KBPS _75KBPS
MML Command :
// Turn on the switch to report the counter "packet loss rate of QCI1 for border UE"
// AMR, counter on
MOD
CELLCOUNTERPARAGROUP:LOCALCELLID=0,CELLCOUNTERALGOSWITCH=BasedA3EdgeUserSwitch-1;
// Turn on the cell algorithm switch

MOD
CELLALGOSWITCH:LOCALCELLID=0,ULAMRCMODE=ULAMRC_ENB_CONTROL,AMRCALGOSWITCH=UlAmr
cExceedingInitialSw-1&UlAmrCheckSw-1&VoiceCodingModeMeasSw-1;
// Define the Voice AMR control Parameter Group

ADD
VOICEAMRCONTROL:LOCALCELLID=0,VOICEAMRCTRLPARAGROUPID=0,HIGHAMRCODINGMODE=AMR_
WB_23_85kbps,LOWAMRCODINGMODE=AMR_WB_12_65kbps,PLRTHDFORDECREASINGAMR=6,PLRTHDFO
RINCREASINGAMR=2,RSNTHDFORDECREASINGAMR=14,RSNTHDFORINCREASINGAMR=5;
ADD
Ericsson Internal

ADD
VOICEAMRCONTROL:LOCALCELLID=0,VOICEAMRCTRLPARAGROUPID=2,HIGHAMRCODINGMODE=AMR_N
B_12_2KBPS, LOWAMRCODINGMODE=AMR_NB_7_4KBPS, PLRTHDFORDECREASINGAMR=6,
PLRTHDFORINCREASINGAMR=2, RSNTHDFORDECREASINGAMR=14, RSNTHDFORINCREASINGAMR=5;
ADD
Application of VOLTE rate control in network:
In commercial network, VoLTE UL Packet Loss is too poor when UE is in poor coverage.
To improve the uplink coverage and MOS for VoLTE service, we can suggest to use VoLTE Rate Control feature in
commercial network.
Customer also want to get a solution how to decrease UL Pkt los
Activation
When the VoLTE user code rate=23.85, and the ul packet loss rate >3%(6*0.005)
in two continuous 2.5 second period, and the channel quality< Threshold1
(Compute according RsnThldForDecreasingAmr), the code rate will decrease to 12.65.
When the VoLTE user code rate=12.65, and the ul packet loss rate<1%(2*0.005) ) in two continuous 2.5 second
period, and the channel quality> Threshold2
(Compute according RsnThldForIncreasingAmr), the code rate will increase to 23.85.
Loca Amr HigherAmr LowerAmr PlrThldForD PlrThldForI RsnThldFor RsnThldForI

lCellI Grou CodingMo CodingMo ecreasingA ncreasingA DecreasingA ncreasingA
d pId de de mr mr mr mr
0 0 AMR_WB_ AMR_WB_ 6 2 14 5
23_85kbps 12_65kbps
1 AMR_WB_ AMR_WB_ 16 2 14 5
12_65kbps 6_6kbps
2 AMR_NB_ AMR_NB_ 6 2 14 5
12_2KBPS 7_4KBPS
3 AMR_NB_ AMR_NB_ 10 2 14 5
7_4KBPS 4_75KBPS
MML Command:
// Turn on the switch to report the counter "packet loss rate of QCI1 for border UE"
// AMR, counter on
MOD
CELLCOUNTERPARAGROUP:LOCALCELLID=0,CELLCOUNTERALGOSWITCH=BasedA3EdgeUserSwitch-1;
// Turn on the cell algorithm switch

MOD
CELLALGOSWITCH:LOCALCELLID=0,ULAMRCMODE=ULAMRC_ENB_CONTROL,AMRCALGOSWITCH=UlAmr
Ericsson Internal

cExceedingInitialSw-1&UlAmrCheckSw-1&VoiceCodingModeMeasSw-1;
// Define the Voice AMR control Parameter Group

ADD
ADD
ADD
ADD
Deactivation
MML Command:
// Turn off the cell algorithm switch
MOD CELLALGOSWITCH:
LOCALCELLID=0,ULAMRCMODE=ULAMRC_ENB_CONTROL,AMRCALGOSWITCH=UlAmrcExceedingInitialSw-
0&UlAmrCheckSw-0&VoiceCodingModeMeasSw-0;
Counters:
according the below counter judge the VoLTE Rate Control is affected or not.
Index ID Index Name Index Discription
1526741685 L.Voice.UL.AMRNB.Increase.Times Uplink AMR NB increase rate times
1526741686 L.Voice.UL.AMRWB.Increase.Times Uplink AMR WB increase rate times
1526741687 L.Voice.UL.AMRNB.Decrease.Times Uplink AMR NB decrease rate times
1526741688 L.Voice.UL.AMRWB.Decrease.Times Uplink AMR WB decrease rate times
Conclusion:
This feature help VoLTE UL Pkt Loss decrease and Call Drop ratio decrease.
Strongly suggest to apply for this feature in other countries. No any side effect such as KPI decrease and complaint.
edge User’s MOS will be bad than before but it is not huge negative gain. It is very few negative gain than old.
Ericsson Internal

< Cluster #1 UL Pkt Loss >

After applying the feature, we got good KPI of VoLTE UL Pkt Loss Rate like below. Few top cells make bad KPI of
VoLTE UL Pkt Loss Rate instantly and then got good performance soon.
< Cluster #1 VoLTE Call Drop >

After applying the feature, we got good KPI of VoLTE Call Drop Rate like below. Few top cells make bad KPI of
VoLTE Call Drop Rate instantly and then got good performance soon.
< Cluster #1 Basic KPI Info >

Most of basic KPI were smoothly going well. In Yellow column, show the good performance result after modifying
the configuration.
Obviously VoLTE Call Drop Rate and VoLTE Packet Loss Rate were better than before.
Ericsson Internal

< Cluster #1 AMR KPI Info >

We can observe whether the feature is working normally or not based on the below counters.
< Cluster #2 UL Pkt Loss >

After applying the feature, we got good KPI of VoLTE UL Pkt Loss Rate like below. Few top cells make bad KPI of
VoLTE UL Pkt Loss Rate instantly and then got good performance soon.
Ericsson Internal

< Cluster #2 VoLTE Call Drop >

After applying the feature, we got good KPI of VoLTE Call Drop Rate like below. Few top cells make bad KPI of
VoLTE Call Drop Rate instantly and then got good performance soon.
< Cluster #2 Basic KPI Info >

Most of basic KPI were smoothly going well. In Yellow column, show the good performance result after modifying
the configuration.
Obviously, VoLTE Call Drop Rate and VoLTE Pkt Loss Rate were better than before.
Ericsson Internal

< Cluster #2 AMR KPI Info >

We can observe whether the feature is working normally or not based on the below counters.
Another set of improvement seen in KPIs:

Ericsson Internal

4.2.4 Uplink RLC Segmentation Enhancement: Coverage and Latency

Improvement for VOLTE Users
The number of Uplink RLC segments is dependent on the TBS determined by UL scheduling.
The smaller the TBS, the large the number of uplink RLC segments. When channel quality is
poor and UL power is limited, a small TBS results in a large number of uplink RLC segments,
which causes:
l Long delay of voice packets
l Uplink voice packet loss (because voice packets wait in the UE buffer so long that the
packet discard timer expires)
l Large overhead of RLC and MAC headers
l Large consumption of control channel elements (CCEs) and resource blocks (RBs) by
UL dynamic scheduling of VoLTE services
Uplink RLC segmentation enhancement restricts the TBS in UL dynamic scheduling to
control the number of uplink RLC segments for voice packets. This restriction improves voice.
quality when channel quality is poor.
Please note: VOLTE is a delay sensitive service and without this feature voice users will have
degradation of speech Quality (User experience).
MOD CELLULSCHALGO: LocalCellId=0, UlVoipRlcMaxSegNum=20;
Impact on the Network:
Uplink RLC segmentation enhancement can increase the mean opinion score (MOS)of VoLTE users when the
users are in a weak coverage area but not in the TTI bundling state.
Ericsson Internal

However, uplink RLC segmentation enhancement raises the uplink MCS, IBLER and residual BLER (RBLER).
GOOD RADIO Conditions: Results show that when this feature is ON there is a lower throughput over the air
with no decrease in voice quality
– RLC downlink throughput there was a 600bps decrease
– RLC uplink throughput there was a 500bps decrease
MOS score was the same when Feature is ON and OFF 3.6
POOR RADIO Conditions: Results show that when This feature is is ON there is a lower throughput over the air.
MOS score was the same for when Feature is ON and and OFF 3.3 – 3.5
The test shows that fewer bits over the air is needed for the VoLTE call because of the less bits needed in the RLC
and PDCP headers – with little or no impact to the MOS score.
Conclusion: The RLC retransmission process is too slow to be useful for VoIP. Retransmissions and control
overheads are removed with activation of this feature. VoIP benefits from reduced latency while tolerating the
slightly higher error rate.
4.2.5 Uplink Compensation Scheduling: Quality Improvement for VOLTE Users
When Uplink compensation scheduling is activated, eNodeB to proactively schedule voice packets based on their
scheduling intervals: eNodeB identifies voice users and, for each voice user, measures the duration in which the
user is not scheduled in the uplink. If the duration reaches a threshold, the eNodeB sends a UL Grant to the UE to
ensure that uplink voice packets can be timely transmitted. This way, this feature shortens the waiting time of voice
packets and reduces the number of packets discarded because of the expiry of PDCP Discard Timer.
Ericsson Internal

The feature was enabled running the following script (not disruptive)
- MOD CELLULSCHALGO: LocalCellId=0, UlEnhencedVoipSchSw=UlVoipSchOptSwitch-1;
Sending uplink data is dependent on the scheduling requests (SRs) reported by UEs. If eNodeB experiences missing
SR detection, the eNodeB may not perform scheduling in a timely manner. This may extend the voice packet waiting
delay or cause timeout-triggered packet loss.
Uplink compensation scheduling can reduce the rate of uplink packet losses in heavy traffic scenarios, shorten voice
packet delays, and improve voice quality. However, this feature increases RB and CCE overheads; when there are
many voice users, this feature also reduces cell throughput.
Ericsson Internal

In addition, uplink compensation scheduling decreases the possibility that uplink control information of voice users is
transmitted over PUCCH and increases the possibility that uplink control information of voice users is transmitted over
PUSCH. This affects the possibility that PDSCH ACK/NACK is detected as DTX and slightly increases VoLTE
downlink packet loss rate (indicated by L.Traffic.DL.PktUuLoss.Loss.QCI.1 / L.Traffic.DL.PktUuLoss.Tot.QCI.1)
By comparing the results of the drive tests performed before and after it is possible to look an improvement in Speech
Quality from 4.0 to 4.1 points:
As the samples on AMR WB 23.85 of Pre-DT (93.1%) are not the same as Post-DT (99.5), a deeper analysis was
performed only including the AMR WB 23.85 in order to comparing them. By filtering the Speech Quality from only LTE
samples (MOC and MTC) on before and after tests, it is possible to look that the improvement in the Speech Quality is
not that evident after activating UL Compensation Scheduling.
Average Speech
Date
Quality
11/12/2015 4.072123248
11/17/2015 4.081767169
Percentage (%) 0.23682784
On the other hand, by checking in the OSS KPIs the UL Packet Loss of QCI1 there is an evident improvement after
enabling the feature:
L.Traffic.UL.PktLoss.Tot.Q L.Traffic.UL.PktLoss.Loss.Q UL Packet Loss Rate

iod CI.1 CI.1 QCI1(%)
9th to 15th
Nov 319095805 1684268 0.527825
17th to 23rd
Nov 358714114 324688 0.090514
Percentage [%] -82.8514
Ericsson Internal

UL Packet Loss QCI1
Possible to find a slight benefit in the UL VQI Excellent & Good Percentage by comparing between 10th and 17th
November OSS KPIs.
KPI Before After Percentage [%]

UL Voice Quality refers to the
Proportion of Excellent and Good Calls 97.564093 98.069355 0.517877002
to All Calls(%)
UL VQI Excellent & Good Percentage Comparison between 10th and 17th November.
Conclusions
After the activation of UL Compensation Scheduling, VoLTE UL Packet Loss has improved considerably even if the
previous average value was already good from 0.52% to 0.9% (by comparing 7 days). Even though this improvement
in the VoLTE UL Packet Loss, Speech Quality has improved just slightly by 0.01 points from 4.07 to 4.08.
Need to consider that in live network Smart Pre-allocation is also enable, which is a function that brings a similar
benefit, therefore UL Compensation Scheduling improvements are not so evident as expected.
Ericsson Internal

The rest of main OSS KPIs including VoLTE related KPIs have remained stable after the activation of UL
Compensation Scheduling.
4.3 VoLTE RAN Analytics (RCA for drive test and/or cell trace)
Drive Test Setup (Actix)
VoLTE (MS3)
• VoLTE DCR*: 1.60%
• VoLTE Setup FR: 5.7%
• LTE Handover FR: 0.8%
• LTE to UMTS Continuity FR: 5.6%
CSFB (MS5)
• CS DCR*: 1.2% / CSFB DCR*: 0.62%
• CSFB Setup failure rate : 1.0%
• No Fail Events visible
VoLTE: SRVCC
• Not VoLTE Drop call: SRVCC due to Missing LTE site.
Missing LTE site x, so poor LTE coverage
SRVCC handover completed and normal call clearly

Ericsson Internal

VoLTE Drop Call -1
Interference
• Sudden Interference from other sites due to location
• Hand Over Fails due to fast signal degradation
• Sudden drop of UE RSRP ~ -125dBm and UE CINR collapses to -8dB
• RF Conditions then quick degrade and not able to recover – multiple measurement reports
Ericsson Internal

VoLTE Drop Call–2 (1/3)
Possible Application Layer Issue?
• No RRC Drop or RRC Connection Reestablishment
• RF Conditions are marginal
• Also Deactivate EPS Bearer Context Request following “BYE” message
• Actix states reason was due to a “New Invite” message.
• Also there is SIP_Event_BYE_Fail

Ericsson Internal

No 200 OK message after BYE

Ericsson Internal

Example of Normal Release
VoLTE Setup Fail – 1 SIP Message 503 Service Unavailable

Ericsson Internal

VoLTE Setup Fail – 2
SIP Message 503 Service Unavailable

Ericsson Internal

4.4 VoLTE Feature and Parameter Tuning/Optimization
4.4.1 VOLTE DCR
#1 Incorrect MCS leading to VOLTE DROP.
Analysis
 UE reports MR for HO
 Source ENB responds RRC connection reconfiguration RSRP = -108.2 / SINR = -0.3 dB
 UE misses the RRC connection reconfiguration message. UE assumes that HO is not initiated & sends
multiple MR for HO.
 Tx2Relocoverall timer expires (5 sec) & UE context is released.
 Since the UE context is released, this will always result in VoLTE drop.
 SINR was poor but not the kind of SINR that UE would not be able decode the L3 message.
 Further investigation was performed on such behavior
 Further investigation revealed that target ENB sent the RRC connection reconfiguration with a different MCS
(modulation coding scheme)
 The UE’s used for drive test was Rel-8, MCS coding assigned to UE was in accordance with Rel-10
 Rel-10 UE’s can decode messages with relative higher MCS when compared to Rel-8 device for a specific
SINR
 Hence, higher MCS was assigned RRC reconfiguration message which the Rel-8 UE could not decode
 Suggestions:-
 ENB software was upgraded which fixed this issue.
Ericsson Internal

Post Retain ability trend

ENB Software rollout
#2. VOLTE Call drop caused by HO and TNL Failures.
For TNL call drop reason, eNodeB received GTPU error IND from MME and triggered abnormal release with cause
‘transport-resource-unavailable’.
If we take LanXXX-CMXX50-H as an example, call drop involved on below peer IP address.(172.27.25.252,
172.27.25.247, 172.27.25.250, 172.27.25.244, 172.27.25.246 ).
For HO failure call drop reason, these call drop happened on SRVCC HO scenario mainly. eNodeB has sent HO CMD
to UE, but waited for 20s and didn’t receive UE_CONTEXT_REL_CMD from MME with cause ‘successful-handover’.
So, eNodeB triggered abnormal release with cause ‘TS1RELOCOVERALL_EXPIRY’.
Ericsson Internal


Ericsson Internal

Due to TNL fail TOP SITES:

Ericsson Internal

Due to HO fail TOP sites:
Solution:
Each TOPN enodeb need to check /Audit , peer IP address (under MOD IPPATH) are included in IPROUTE define
section(ADD IPRT).
4.4.2 VOLTE Voice Quality
#1 UL Compensation Scheduling activation Feature:
When Uplink compensation scheduling is activated, eNodeB to proactively schedule voice packets based on their
scheduling intervals: eNodeB identifies voice users and, for each voice user, measures the duration in which the user
is not scheduled in the uplink. If the duration reaches a threshold, the eNodeB sends a UL Grant to the UE to ensure
that uplink voice packets can be timely transmitted. This way, this feature shortens the waiting time of voice packets
and reduces the number of packets discarded because of the expiry of PDCP Discard Timer.
UL Compensation Scheduling functionality
The feature was enabled running the following script (not disruptive)
- MOD CELLULSCHALGO: LocalCellId=0, UlEnhencedVoipSchSw=UlVoipSchOptSwitch-1
Sending uplink data is dependent on the scheduling requests (SRs) reported by UEs. If eNodeB experiences missing
SR detection, the eNodeB may not perform scheduling in a timely manner. This may extend the voice packet waiting
delay or cause timeout-triggered packet loss.
Ericsson Internal

Uplink compensation scheduling can reduce the rate of uplink packet losses in heavy traffic scenarios, shorten voice
packet delays, and improve voice quality. However, this feature increases RB and CCE overheads; when there are
many voice users, this feature also reduces cell throughput
By comparing the results of the drive tests performed before and after it is possible to look an improvement in Speech
Quality from 4.0 to 4.1 points:
4.4.3 VOLTE Packet loss
#1 Packet loss due to bad quality:
According to the KPI trace，it is found that sometimes the Uplink packet loss rate =1.68%;And at the same time the
uplink interference was a little high;
From the BRD log file, this site was at heavy load from 8:00 to 16:00, with about 50 users in average.
Ericsson Internal

The following graph shows the analysis method of Voice packets loss, and the MO&MT uplink and downlink packet
loss can be found from the eNodeB Cell DT trace;
According to UE QXDM RTP packet trace, we can find that MT did not receive the DL voice packets.For example:MT
did not receive the RTP SN 494/495/496/497 4 packets；
Ericsson Internal

MO should have sent the RTP SN 494/495/496/497 4 packets to eNodeB.
But eNodeB PDCP layer did not receive those packets in the uplink UU interface;According to eNodeB PDCP layer
trace, it is found that those 4 voice packets did not exist, then it needs to check eNodeB MAC layer trace to see the
uplink scheduling；
Ericsson Internal

There were also some cases that four continuous HARQ CRC wrong caused packet loss:
The Uplink radio channel quality was poor and it caused the packet loss.
Recommendation: optimize the RF condition to improve the Bad Quality.
Packet losses on Uu Interface:
here are many factors that will affect VoLTEvoice quality MOS, such as speech coding, end to end delay, jitter, packet
lossetc. Since VoLTE going through many network elements, for instance UE, eNodeB,transmission, EPC, IMS etc all
of these might be the issue of bad voicequality. Thus, the first step is to identify which element was the source ofthe
problem.
Identify theproblematic element
In SEQ platform, we can check every VoLTEcall user plane data, including the call time, MO and MT caller number,
uplinkand downlink MOS, uplink and downlink RTP packets / packet loss, uplink anddownlink RTCP packets / packet
loss, and call setup initial cell name and lastvisited cell name.
Below figure shows the flow of RTP packet andRTCP packet.

Ericsson Internal

RTCP:Initiate at UE (between UE and eNodeB) capture total RTP packet count,end-to-end.
RTP:Initiate at S1-U interface (between eNodeB and MME) capture total RTP packetcount.
From RTCPcount and RTP count, we could identify the problem packet loss issue happenbetween UU interface or
core network. In this problem, it is found that bothUplink RTP Packet loss count and RTCP Packet Loss count is the
same for UE_MT.In addition, MT Uplink packet loss is the same with MO Downlink packet losscount, suspect problem
in UE_MT Uplink.
Ericsson Internal

To doubleconfirm, check UU interface packet loss rate in UE_MT eNodeB counter, uplinkpacket loss was high at that
time. (L.Traffic.UL.PktLoss.Loss.QCI.1/ L.Traffic.UL.PktLoss.Tot.QCI.1)
Maximum of LTE user was found <200, socongestion should not be the root cause.
Ericsson Internal

However, the IBLER of this cell is high,especially when the packet loss happen.
In addition,in PS call drop analysis most of the call drop happen was due to uplink weak coverage.Suspect packet loss
in UU interface because of weak coverage.
Ericsson Internal

during the call X2 handover was found. Just 2ms rightafter X2 handover, MME initiate SRVCC to GSM and the reason
was due to uplinkquality.
Checking theconfiguration of the cell, SRVCC only trigger when LTE RSRP <-115dBm. Thus, itcan be concluded that
radio condition was bad at that time. UE might be in badcoverage area and that’s why packet loss happen.
Recommendation:
“INTERRATHOCOMMGROUP:LocalCellId=2, InterRatHoA2ThdRsrp=-96,InterRatHoA2ThdRsrq=-24,
GeranB2Thd1Rsrp=-115, GeranB2Thd1Rsrq=-24;
INTERRATHOGERANGROUP:LocalCellId=2, InterRatHoGeranB1Thd=-90, InterRatHoGeranB1TimeToTrig=640ms,

LdSvBasedHoGeranB1Thd=-98;”
#3.VOLTE Packet loss due to high HARQ Retransmission caused by poor UL quality:
There were some other set of sites, which has high packet loss rate due to HARQ retransmission failure and SR
undetected error.
SR undetected error : If UE want to send data, it will send SR(schedule request) to eNodeB and notify eNodeB that
UE want to send data. If eNodeB does not receive the SR, the UE were unable to send data. If the data can’t be send
for long time (default value is 100ms), the voice data will be discard which cause uplink packet loss.
Ericsson Internal

Main possible reason for above case is poor UL coverage/UL interference.
PUSCH RBLER
Soluti
on:
For UL interference, need to identify interference source.
For HARQ retransmission failure need to optimize these parameters:
MOD CELLALGOSWITCH: LocalCellId=x, UlSchSwitch=UlLast2RetransSchOptSwitch-1;
MOD CELLULSCHALGO: LocalCellId=x, UlEnhencedVoipSchSw=UlVoipRblerControlSwitch-1;
For SR undetected error need to optimize these parameters:
MOD CELLULSCHALGO: LocalCellId=x, UlEnhencedVoipSchSw=UlVoipSchOptSwitch-1&
UlVoipServStateEnhancedSw-1, UlCompenSchPeriodinSpurt=INTERVAL_20,
UlCompenSchPeriodinSilence=INTERVAL_160;
4.4.4 SRVCC
#1 Improper Configuration of eRAN parameters in UTRAN:
Main reason for SRVCC fail is “UEM_UECNT_REL_MME_CMD”(Release due to MME).Release from MME side
mainly because of wrong configuration information about RAN side (RNC ID/LAC for neighbor UMTS sites).
ANR parameters in eRAN side are not properly optimized. Hence UMTS side information not properly updated in
eRAN side.
Ericsson Internal

Solution:
Need to optimized ANR parameters as follows:

When optimizing ANR parameters we have to clearly consider no of sites in Network /inter site distance. It does not
recommended to just use default parameters.
Optimisation
MO Parameter
value
CELLALGOSWI
AnrFunctionSwitch.INTER_RAT_ANR_SW ON
TCH
ENodeBAlgoSwi
UtranEventAnrSwitch ON
tch
Ericsson Internal

ENodeBAlgoSwi
UtranAutoNrtDeleteSwitch ON
tch
NOT_BASED_
ANR UtranEventAnrMode
NCL
ANR NrtDelMode.UTRAN_DELREDUNDANCENCELL ON
ANR StaPeriodForIRatNRTDel 1440
ANR StaNumForIRatNRTDel 50
ANR NrtDelMode.UTRAN_DELERRORNCELL ON
ANR NcellHoStatNum 5
ANR DelCellThd 50
ANR StaPeriodForIRatNRTDel 1440
ANR StaNumForIRatNRTDel 50
ANR UtranNcellHoForNRTDelThd 10
ANR UtranNcellDelPunNum 50
ENodeBAlgoSwi
NCellRankingSwitch.UTRAN_SWITCH ON
tch
ANR PeriodForNCellRanking 10080
EventAnrWithVoipMode.UTRAN_EVENT_ANR_WITH_
ANR OFF
VOIP_MODE
CELLALGOSWI
AnrAlgoSwitch.UTRAN_OVERDISTANCE_SW ON
TCH
NCELLPARACF
RatType UNTRAN
G
5000（inter-
NCELLPARACF site
NCellOdDisThd
G distance<1000
m）
4.4.5 Miscellaneous
Ericsson Internal

4.4.5.1 Mute calls Improvement

CLUSTER/SITE TOWN MO PARAMETER PRE POST IMPLEMENTATION DATE TIME LEVEL SCRIPT
MOD
CELLALGOSWITCH:LOCALCELLID=0,Dl SchSwi tch=
Voi pTbs Ba s edMcs Sel Swi tch/Dl RetxTbs In Voi pTbs Ba s edMcs Sel Swi tch-1;
C58 & CL70 Ba nga l ore CELLALGOSWITCH OFF ON 31-01-2018 19:00 FDD_TDD CELL
dexAdjOptSwi tch MOD
CELLALGOSWITCH:LOCALCELLID=0,CQIADJALGOS
WITCH=Dl RetxTbs IndexAdjOptSwi tch-1;
Following are the observation after Enabling Feature Based parameter switch:
L.Voice.DL.Silent.Num has been seen improved by 4.5% while very slight degradation seen in
L.Voice.UL.Silent.Num.
L.Voice.E2EVQI.Poor.Times & L.Voice.VQI.UL.Poor.Times samples has been seen reduced significantly around
53.69% & 64.76% which improves DL VoLTE Quality and performance.
L.Voice.E2EVQI.Bad.Times & L.Voice.VQI.UL.Bad.Times samples has been seen reduced significantly around
13.35% & 14.88% which improves DL VoLTE Quality and performance.
Significant Improvement seen in DL IBLER from 14.17% to 7.40% around 47.73% improvement.
DL Packet Loss Rate QCI 1 has been seen improved from 0.54% to 0.42% around 21.40% improvement.
Average DL Packet Delay has been reduced by 8.21% which enhanced user performance.
SRVCC IRAT per call rate and SRVCC HO Success Rate has been seen stable.
Call Drop Rate has been seen slightly improved.
All Other Major KPI seems to be stable.
Ericsson Internal


Ericsson Internal

4.4.5.2 SRVCC IRAT per call Improvement(I)
CLUSTER/SITE TOWN MO PARAMETER PRE POST IMPLEMENTATION DATE TIME LEVEL

Whole ROK Clusters ROK Cluster INTERRATHOUTRANGROUP InterRatHoUtranB1ThdEcn0 -32 -28 23-01-2018 22:30 FDD_TDD CELL
Pre- Post Benchmarking for Whole Bangalore Cluster

Following are the finding and enhancement seen in the below KPI.
 VoLTE SRVCC IRAT per Rate has been seen with very good improvement from 4.01% to 2.59% with an
Improvement of around 35.23%
 VoLTE SRVCC HO Success Rate has been seen slightly improved from 96.94% to 97.51% around 0.59%
improvement seen.
 Call Drop Rate (VoIP)% has been seen stable.
 L.Voice.DL.Silent.Num has been seen increased. ( Will improved with UL Enhanced Scheduling Parameter
which will be implemented in coming phase)
 Avg UL Packet Loss QCI1 has been also seen stable.
 All Other Major KPI are seen normal.
Ericsson Internal

4.4.5.3 SRVCC IRAT per call Improvement(II)

Ericsson Internal


Ericsson Internal


Ericsson Internal

4.4.5.4 VOLTE key Parameters &Features:
Sr.No. Name Remarks

1 CELLINDIVIDUALOFFSET Drop Optimization
2 DISCARDTIMER Packet loss Optimization
DlRetxTbsIndexAdjOptSwitch
UlLast2RetransSchOptSwitch
3 Packet loss Optimization
UlVoipSchOptSwitch
VOIPWITHGAPMODE
4 InterRatHoA1ThdRsrp & InterRatHoA2ThdRsrp SRVCC HO Optimization
5 InterRatHoA2ThdRsrp SRVCC HO Optimization
6 InterRatHoUtranB1ThdEcn0 IRAT HO Optimization
7 SINRadjTargetBLERforVOIP BLER Optimization
8 SRVCCPRIORITY/OFFSETFREQ SRVCC HO Optimization
9 ULDELAYSCHSTRATEGY voice quality optimization
10 UlEnhencedVoipSchSw Packet loss Optimization
UlVoLTEDataSizeEstSwitch
11 UlVoipServStateEnhancedSw Packet loss Optimization
UlEdgeActiveSchSwitch
VoipTbsBasedMcsSelSwitch
12 Packet loss Optimization
DlRetxTbsIndexAdjOptSwitch
Packet loss
UlSchSwitch=UlLast2RetransSchOptSwitch optimization(packet loss
13
UlEnhencedVoipSchSw=UlVoipRblerControlSwitch caused by high HARQ
transmission failures)
14 QciPara.UeInactiveTimerForQci Drop Optimization
15 RohcSwitch-1 ROHC Feature
16 RlcMode UM/AM Mode Optimization
UL & DL Congestion
17 Qci1CongThd
Optimizaion
18 UlschStrategy activate the ULSCH strategy
19 DlschStrategy activate the DLSCH strategy
TtiBundlingTriggerStrategy=SERVICE_VOIP(SERVICE_V
20 TTI Bundling for VOLTE
OIP)
Voice rate Control
21 CellAlgoSwitch.UlAmrcMode
Optimization
22 UlCallMuteRecoverSwitch uplink mute call optimization
Admit VOLTE Calls on
23 CellAlgoSwitch.RacAlgoSwitch
preference
24 CellDrxPara.DrxAlgSwitch UE Power saving Optimization
IntraFreqHOGroup.IntraFreqHoA3Hyst
Intra Frequency HO
25 ntraFreqHOGroup.IntraFreqHoA3Offset
Optimization
IntraFreqHOGroup.IntraFreqHoA3TimeToTrig
Ericsson Internal

4.4.5.5 VOLTE tools for testing
 wireshark to capture PCAP for rtp,drop, setup failure optimization.
 optis (xcap) ,TEMS support VoLTE with many KPI for the drive test analysis.
 Probe & Assistant-DT Analysis and recommendation for the pre and post drive test optimization.
 U2000,PRS, OMSTAR for Performance monitoring
 PCHR, NPMASTER for deep dive analysis.
Cluster/DT Analysis &Recommendations

Ericsson Internal


Ericsson Internal


Ericsson Internal


Ericsson Internal


Ericsson Internal

4.4.5.6 Case Study : SRVCC Preparation Degradation
Problem Statement :
In Few LACs, high degradation in SRVCC Preparation success rate from 10th Jan’17 in MME-3/KKSGSN-3 (ROK).
First Cut Analysis & Observations:

• High SRVCC preparation failure count has been observed with following LACs [3G LAC:34112, 54112,
34421, 34118, 34422] from 10th Jan’17.
• High failure at MME end is received with cause code “S1 mode SRVCC failure times (MSC cause #1
unspecified)”
• High SRVCC Preparation failure observed from 10th Jan in KK MME3

• In MME1 & MME2, improvement is due to DNS correction activities at PaCo.
• High Failure count has been seen in following LACs [3G LAC:34112, 54112,34421, 34118,34422] from 10th
Jan.
Ericsson Internal


Ericsson Internal

• High failure at MME end is received with cause code “S1 mode SRVCC failure times (MSC cause #1
unspecified)”
Ericsson Internal


Ericsson Internal

KPIs Post Correction

• SRVCC Prep Success Rate in all of the migrated LAC got improved on 16th Jan.
Ericsson Internal

4.4.5.7 Case Study : VoLTE KPIs especially Downlink packet loss and Drop degraded.
Very high packet loss had been observed in more than hundreds of sites of KKMME-2/SGW-2 from 12:00 noon, 16th
May’18, resulting very high mute call complaints in VoLTE.
RCA : BFD flapping on Gn link between WF Cisco to NDR Cisco switches.

Post card reset on MUX end, BFP is stable, and all VoLTE KPIs back to normal.
Ericsson Internal


Ericsson Internal

Trial :KK Highway LMS Changes To Improve VoLTE Customer Perception.
Highway specific LMS
 Based on the feedback from early SRVCC Trial on Bangalore-Hubli HW, same has been implemented on all
KK HW.
 Most sites in all routes having the FDD sites, while very less no of sites having TDD_10.
 Since in Highways dominance of 3G is comparatively quite w.r.t to 4G, So intention was to trigger early
SRVCC to move VoLTE customers to 3G so to keep customer in good RF condition most of the time.
Ericsson Internal

Findings:
• SRVCC Success rate in all H/W either improve or maintained.
• SRVCC Per Call Rate has increased from Avg.3.5 to 10.8%.
• Accessibility & Handover KPIs are maintained
• Overall minor drop has been increased which is due to some specific cells.
Ericsson Internal

4.4.5.8 Case Study : X2 Rate Improvement Trail
X2 Rate = [X2 handover attempts ] / [Total Handover attempts] * {100}
X2 Rate Huawei Formula : (L.HHO.X2.IntraFreq.PrepAttOut.VOIP+L.HHO.X2.InterFreq.PrepAttOut.VOIP)/

(L.HHO.IntereNB.IntraFreq.PrepAttOut.VOIP+L.HHO.IntereNB.InterFreq.PrepAttOut.VOIP) X 100 %
Based on the deep study and cell level analysis action been prepared along with TAC team to improve the X2 Rate of
Bangalore which was not good with respect to other circles.
Also, on BO recommentation few feature has been implemented in the entire KK network.
MOD CELLALGOSWITCH: LocalCellId=x, MFBIAlgoSwitch = MFBIX2HoSwitch -1;
Ericsson Internal


Ericsson Internal

In Bangalore,~6% improvement has been observed in X2 Rate, while 3% in ROKK. Overall all at circle level, 4.6%
improvement observed and X2 Rate reached to 91.1% from 86.5%.
BLR and ROKK X2 Rate
Hourly Trend of X2 Rate of KK Circle
In 62 sites out of 71 sites, X2 link has been configured.

Below is the hour Pre-Post of 61 sites. Rest 9 sites Kundan is following up to get it configured.
62 out of 71 Sites : 28th May’18

X2
Hour RG.VoLTE.X2.Rate.NOM RG.VoLTE.X2.Rate.DENOM
Rate
10:00 0 5310 0.0
11:00 14 5516 0.3
12:00 4590 5882 78.0
13:00 5045 5392 93.6
14:00 4312 4590 93.9
Right from 12’O clock 28th May, 0.8 to 1% improvement can be observed due to these 62 Sites.
Ericsson Internal

But consequently, statistical degradation is observed in “S1 Preparation success Rate”.

In 2nd graph, we can see, the number of S1 attempts reduced due to increase in X2 attempts, but the number of S1
failures at preparation is not reduced with the same extent.
So we concluded degradation is there in S1 Preparation success, but the absolute number of failures are not
increased due to suggested changes for X2 improvement.
Ericsson Internal

5 HUAWEI Projects
5.1 VoLTE Optimizations and Lessons learned
 X2 ABNORMAL LINKS
 UE DEREGISTER ISSUE
 RTP PACKET LOSS
 CALL FAILURE ISSUES
 PCI CONFLICTS
 TAC-SGW & LAC-MSS MAPPING CORRECTIONS
 SRVCC EXECUTION FAILURES
 SRVCC PREPARATION FAILURES

Ericsson Internal

5.1.1 X2 Abnormal Link
X2 Link Corrections
X2 interface creation
IP Route Addition in node
DLD execution for Route advertisement from MOT to CEN
Blacklisting of Inter MME X2 links
Timer settings changes to delete the disabled X2 links
35 Super IP net addition in node and CEN/MOT/SDH.
SCTP port number change.
Next HOP IP correction
Most of the remaining Abnormal X2 links are due to Inter MME blacklisting.
Further Abnormal links will reduce once MME in pool is implemented.

Ericsson Internal

5.1.2 UE Deregister
UE’s were unable to register with IMS
On analysis it was found that the encryption algorithm used in IMS SBC was causing UE to fail registration.
All the issues were attributed to MME4 since SBC2 was found to have the issue
Ericsson Internal

Once the encryption algorithm was turned off the issue was resolved.
5.1.3 RTP Packet Loss
High rtp packet loss observed in sites across clusters
Most of the sites were sharing same pop as 3g sites which was having packet loss issue
Testing done reveled loss even in good radio conditions and drive done during off peak hours showed good
improvements in the packet loss samples.
Ericsson Internal

Transmission team has migrated sites from mot to cen. Rectification of field issues(wip)
5.1.4 Call Failure (Analysis from IMS)
Conference Drop – Observed with Huawei. Intimated and Trace taken at Huawei for analysis by Huawei. //
immediate soln. For B/O we can remove Huawei Node (10.5.51.12 and 10.5.51.4).
B/I Call Wait fail – Issue observed always from 51.12, while intermittently from 51.4. for E/// all successful.
Call Failed – B/O scenario with Huawei, Observed codec negotiation failure from Huawei, only observed with
IPhone, Intimated and Trace taken at Huawei for analysis by Huawei. // immediate soln. For B/O we can remove
Huawei Node (10.5.51.12). Issue resolved by Force codec UMTS AMR 2 was enabled in 10.5.51.12 for BGCF
OFC. This needs to be kept in notice as Huawei has not enabled any force codec for Volte calls.
Break In call Mute/One way speech from Airtel Delhi
5.1.5 PCI Conflict
Failures due to Wrong cell Handover started to appear after PCI change in the network.
On analysis it was found that due to OSS sync issue the North bound interface was not updated with the network
values.
ANR was defining neighbors with old data values resulting in Wrong cell handovers.
OSS sync issue was resolved and ANR deletion and recreation of neighbors done to solve the conflicts.
Ericsson Internal

5.1.6 TAC-SGW & LAC-MSS mapping corrections
5.1.7 SRVCC Execution Failures
82205451 82205452 82203815 82203816

LQW1FRLSRESE LQW1FRLSRESM LQW1SLURESE LQW1SLURESM
SRVCC from SRVCC from
RNC Name RNC Type Fast Return to Fast Return to LTE to UMTS LTE to UMTS
LTE for SRVCC LTE for SRVCC with PS with PS
User (per Erl) User (per kbps) Handover (per Handover (per
Erl) kbps)
KKRBL13 BSC6900 5000 2000000 5000 2000000
MO HUAWEI HUAWEI PARAMETER PRE POST

INTERRATHOUTRANGROUP INTERRATHOUTRANB1THDECNO -16 -32
GLOBALPROCSWITCH QCIPARAEFFECTFLAG ON OFF
CELLSTANDARDQCI DRX PARAGROUPIF(QCI5) 1 3
CELLSTANDARDQCI QCIPRIORITY FOR HO(QCI5) 1 2
Ericsson Internal

SRVCC failures observed due to License missing in the RNC end.
RNC license for SRVCC was added along with parameter changes in LTE
5.1.8 SRVCC Preparation Failures
MCC format was found wrong in node BBL01 which was changed
CN ID was defined wrong in the RNC end which was modified and SRVCC was found to be successful.
Ericsson Internal

Outer RNC Definitions were not present in MGCF Nodes , missing ROK RNCs definitions were added
Wrong MNC Value in KKRMY04 – MNC value was wrongly configured in RNC definition
Few LACs DNS entries was missing in SGSN nodes
6
Revision History
Date Version Description Main updates Author

22nd Nov Rev A First Release Pawan Narula
2018

Volte Huawei Ran - Technical Guideline Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Volte Huawei Ran - Technical Guideline Final

Uploaded by

Copyright:

Available Formats

Ericsson Internal

See below for Authors 3/10260-FAF102643 Uen

Remo Agostino 2018-12-12 PA1

Contributors Janaka Pawan Narula &