Volte Huawei Ran - Technical Guideline Final
Volte Huawei Ran - Technical Guideline Final
Volte Huawei Ran - Technical Guideline Final
Instruction 1 (123)
No.23215690
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
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.
Lessons learnt
eRAN12.1
eRAN13.1
2 HUAWEI O&M
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;
Check whether the following counters indicate successful voice service setup
L.ERAB.SuccEst.QCI.1
L.ERAB.SuccEst.QCI.5
Invite request information that includes both caller and called number
Ericsson Internal
15 (123)
No.23215690
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
Import the attached query (.xml) to obtain the necessary counters for the troubleshooting.
Ericsson Internal
20 (123)
No.23215690
2.4.2 NIC
NIC webpage: https://ip_U2000_server/nic
Ericsson Internal
22 (123)
No.23215690
2.4.2.1 NIC-CHR
CHR: create/modify a CHR task
Ericsson Internal
23 (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”
2.4.3 Traces
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
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.
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.
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
Instruction 33 (123)
Prepared (Subject resp) No.
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.
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.
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
• PDCCH
• PUCCH
• Paging
• PDSCH
• PUSCH
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
Instruction 39 (123)
Prepared (Subject resp) No.
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.
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:
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
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
Instruction 40 (123)
Prepared (Subject resp) No.
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
Instruction 41 (123)
Prepared (Subject resp) No.
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
Instruction 42 (123)
Prepared (Subject resp) No.
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
Instruction 43 (123)
Prepared (Subject resp) No.
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.
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.
• 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.
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
Instruction 45 (123)
Prepared (Subject resp) No.
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.
• 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
Instruction 46 (123)
Prepared (Subject resp) No.
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.
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
Instruction 47 (123)
Prepared (Subject resp) No.
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
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.
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.
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
Instruction 48 (123)
Prepared (Subject resp) No.
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
Instruction 49 (123)
Prepared (Subject resp) No.
For VoIP services, a set of special DRX parameter settings are available for reducing UE power consumption while
maintaining 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).
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
Instruction 51 (123)
Prepared (Subject resp) No.
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
Instruction 52 (123)
Prepared (Subject resp) No.
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
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.
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
Instruction 56 (123)
Prepared (Subject resp) No.
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.
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;
WB_12_65kbps,LOWAMRCODINGMODE=AMR_WB_6_6kbps,PLRTHDFORDECREASINGAMR=16,PLRTHDFO
RINCREASINGAMR=2,RSNTHDFORDECREASINGAMR=14,RSNTHDFORINCREASINGAMR=5;
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
VOICEAMRCONTROL:LOCALCELLID=0,VOICEAMRCTRLPARAGROUPID=3,HIGHAMRCODINGMODE=AMR_N
B_7_4KBPS, LOWAMRCODINGMODE=AMR_NB_4_75KBPS, PLRTHDFORDECREASINGAMR=10,
PLRTHDFORINCREASINGAMR=2, RSNTHDFORDECREASINGAMR=14, RSNTHDFORINCREASINGAMR=5;
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.
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;
cExceedingInitialSw-1&UlAmrCheckSw-1&VoiceCodingModeMeasSw-1;
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
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
Instruction 60 (123)
Prepared (Subject resp) No.
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).
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
Instruction 65 (123)
Prepared (Subject resp) No.
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.
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
Instruction 66 (123)
Prepared (Subject resp) No.
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
Instruction 67 (123)
Prepared (Subject resp) No.
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:
Possible to find a slight benefit in the UL VQI Excellent & Good Percentage by comparing between 10th and 17th
November OSS KPIs.
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
Instruction 69 (123)
Prepared (Subject resp) No.
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)
CSFB (MS5)
VoLTE: SRVCC
Interference
• RF Conditions then quick degrade and not able to recover – multiple measurement reports
Ericsson Internal
Instruction 71 (123)
Prepared (Subject resp) No.
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
Instruction 76 (123)
Prepared (Subject resp) No.
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
Instruction 77 (123)
Prepared (Subject resp) No.
Solution:
Each TOPN enodeb need to check /Audit , peer IP address (under MOD IPPATH) are included in IPROUTE define
section(ADD IPRT).
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.
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
Instruction 80 (123)
Prepared (Subject resp) No.
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:
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
Instruction 81 (123)
Prepared (Subject resp) No.
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
Instruction 82 (123)
Prepared (Subject resp) No.
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
Instruction 83 (123)
Prepared (Subject resp) No.
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.
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.
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.
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
Instruction 85 (123)
Prepared (Subject resp) No.
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
Instruction 86 (123)
Prepared (Subject resp) No.
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
Instruction 87 (123)
Prepared (Subject resp) No.
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;
#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
Instruction 88 (123)
Prepared (Subject resp) No.
PUSCH RBLER
Soluti
on:
UlVoipServStateEnhancedSw-1, UlCompenSchPeriodinSpurt=INTERVAL_20,
UlCompenSchPeriodinSilence=INTERVAL_160;
4.4.4 SRVCC
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
Instruction 89 (123)
Prepared (Subject resp) No.
Solution:
Optimisation
MO Parameter
value
CELLALGOSWI
AnrFunctionSwitch.INTER_RAT_ANR_SW ON
TCH
ENodeBAlgoSwi
UtranEventAnrSwitch ON
tch
Ericsson Internal
Instruction 90 (123)
Prepared (Subject resp) No.
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
Instruction 91 (123)
Prepared (Subject resp) No.
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
Instruction 92 (123)
Prepared (Subject resp) No.
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.
Problem Statement :
In Few LACs, high degradation in SRVCC Preparation success rate from 10th Jan’17 in MME-3/KKSGSN-3 (ROK).
• High Failure count has been seen in following LACs [3G LAC:34112, 54112,34421, 34118,34422] from 10th
Jan.
Ericsson Internal
Instruction 104 (123)
Prepared (Subject resp) No.
• High failure at MME end is received with cause code “S1 mode SRVCC failure times (MSC cause #1
unspecified)”
Ericsson Internal
Instruction 106 (123)
Prepared (Subject resp) No.
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.
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
Instruction 111 (123)
Prepared (Subject resp) No.
Findings:
• Overall minor drop has been increased which is due to some specific cells.
Ericsson Internal
Instruction 112 (123)
Prepared (Subject resp) No.
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
Instruction 113 (123)
Prepared (Subject resp) No.
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%.
Right from 12’O clock 28th May, 0.8 to 1% improvement can be observed due to these 62 Sites.
Ericsson Internal
Instruction 115 (123)
Prepared (Subject resp) No.
5 HUAWEI Projects
X2 ABNORMAL LINKS
UE DEREGISTER ISSUE
PCI CONFLICTS
X2 Link Corrections
X2 interface creation
Most of the remaining Abnormal X2 links are due to Inter MME blacklisting.
5.1.2 UE Deregister
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
Instruction 119 (123)
Prepared (Subject resp) No.
Once the encryption algorithm was turned off the issue was resolved.
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
Instruction 120 (123)
Prepared (Subject resp) No.
Transmission team has migrated sites from mot to cen. Rectification of field issues(wip)
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.
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
Instruction 121 (123)
Prepared (Subject resp) No.
RNC license for SRVCC was added along with parameter changes in LTE
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
Instruction 123 (123)
Prepared (Subject resp) No.
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
6
Revision History