LTE FDD Network Planning & Optimization System-Demo Cluster Area Optimization Report Budi Prasetyo
1 1.1
CS NPO
19:55
Overview Test Purposes
The major purposes of this evaluation are to learn about the present coverage quality and running performance of the network in demo areas. On the basis of the network’s actual conditions, manage to solve the existing network problems and present suggestions for performance optimization especially the coverage and DL throughput performance.
1.2
Test Area
Demo Cluster include 4 sites , it is an urban area.
2 Test Result Comparison 2.1
Test result overview
Table 2-1 test KPI before optimization overview
Table 2-2 test result after optimization overview
2.2
RSRP
RSRP DT result before optimization： Figure 2-1 RSRP DT result at 6-19
RSRP DT result after optimization： Figure 2-2 RSRP DT result at 6-22
Figure 2-3 RSRP Comparison
The RSRP comparison shows that the percent of RSRP poorer than -95 dBm has decrease from 31.79% to 26.20%, the coverage become better.
2.3
SINR
SINR DT result before optimization： Figure 2-4 SINR DT result at 6-19
SINR DT result after optimization：
Figure 2-5 SINR DT result at 6-22
Figure 2-6 SINR Comparison
The SINR comparison shows that the percent of SINR poorer than 5 dB has decrease from 13.32% to 9.84%, the SINR become better.
2.4
MAC DL Throughput
MAC DL Throughput DT result before optimization： Figure 2-7 MAC DL Throughput at 6-19
MAC DL Throughput DT result after optimization： Figure 2-8 MAC DL Throughput at 6-22
Figure 2-9 MAC DL Throughput Comparison
The MAC DL Throughput comparison shows that the percent of MAC DL Throughput less than 20Mbps has decrease from 19.85% to 6.69%, the DL throughput become better.
3
Optimization Case
3.1
Random Access Failure Case Analysis
Analyzing the DT log at 6-19, we found that there are random access failure cases. Figure 3-1 Random access failure case
Checking the PRACH parameters and found that the parameter setting are not reasonable: neaby cells shoud not have the same prachConfigIndex&rootSequenceIndex at the same time, otherwise it will cause cell confusion and result in random access failure. ENBFunctionFDD 5004 5004 5004
EUtranCellFDD 1 2 3
prachConfigIndex 5 5 5
rootSequenceIndex 831 801 831
Optimization suggestion: re-plan prach parameters for relate cells. Table 3-1 parameters optimization1 site ID 5004 5004 5004 5004 5151 5151 5151
3.2
cell ID 1 2 3 1 1 2 3
parameter name prachConfigIndex prachConfigIndex prachConfigIndex rootSequenceIndex rootSequenceIndex rootSequenceIndex rootSequenceIndex
old value 5 5 5 24 125 133 141
new value 9 10 11 618 600 606 612
Call Drop Case Analysis
Analyzing the DT log at 6-19, most the call drop are caused by handover failure. Detail analysis and optimization suggestions please refer to section 3.3
3.3
Handover Failure Case Analysis
3.3.1
Handover failure caused by bad SINR
Here is one of the handover failure case analysis: UE at soruce PCI 43 found PCI 40 stronge enough and send Measurement Report, but UE did not receive handover command(RRC Connection Reconfiguration) and then call drop. Figure 3-2 Handover failure case
The UE send the Measurement Report when serving cell SINR become very bad(-5.6 db).
UE campus on a new PCI 23 after call drop. From these procedures we can consider this handover and call drop are cause by bad SINR.
Optimization suggestion: optimization for SINR.
3.3.2
Handover failure caused by PCI 10 overshooting
UE catch a PCI 10 where is rather far away. PCI 10 is from site SoraviaRoof_SKO5556
UE failure handover to PCI 24 because PCI 10 overshooting and no neighbor relationship for this two PCI.
Another case is similar caused by PCI 10 overshooting: UE catch signal from PCI 10 far away.
Optimization suggestion: Add 2°downtilt for SoraviaRoof_SKO5556_2.
3.3.3
Handover failure caused by PRACH parameter
From section 3.1, we know that 5004_1 and 5004_2 have the same PRACH setting, this can also affect handover. The KPI from EMS show that handover success rate is not good for cell 5004_1 and 5004_2
Some handover also found related with these two sector during DT.
Optimization suggestion: Adjust PARACH parameter as section 3.1
3.4 3.4.1
Coverage Case Analysis Bolnica_SKP5004_3 adjust tilt from 0°to 2°
Downtilt 0°may eaily caused overshooting to other cell, and according to DT result, area close to Bolnica_SKP5004_3 is not good enough, adjust tilt from 0°to 2°can enforce the coverage. Figure 3-3 coverage analysis case2
3.4.2
Divizija_SKO5073_3 adjust tilt from 0°to 3°
According to DT result, Divizija_SKO5073_3 is overshooting to site Bolnica. Figure 3-4 coverage analysis case3
3.5
RS Power Optimization
After tilt change, increase the cell RS power can enforce the coverage. Table 3-2 parameters optimization2
site ID 5004 5004 5004 5073 5073 5073 5169
cell name LTE1800_Bolnica_1 LTE1800_Bolnica_2 LTE1800_Bolnica_3 LTE1800_Divizija_1 LTE1800_Divizija_2 LTE1800_Divizija_3 LTE1800_MVRHQ_3
3.6
parameter name cellReferenceSignalPower cellReferenceSignalPower cellReferenceSignalPower cellReferenceSignalPower cellReferenceSignalPower cellReferenceSignalPower cellReferenceSignalPower
old value 10.6 10.6 10.6 10.6 10.6 10.6 10.6
new value 13.6 13.6 13.6 13.6 13.6 13.6 13.6
Handover Optimization
Comparing the RSRP and SINR, most the road RSRP is better than -95 dBm, UE can easily catch signal from neaby site. Optimize the parameter timeToTrigger from 7(256ms) to 6(160ms) can make the UE fast handover to a stronger neighbor, thus can let the UE stay at the strongest RSRP and SINR cell. Optimization Suggestion: site ID 5004 5073 5151 5169
parameter name timeToTrigger timeToTrigger timeToTrigger timeToTrigger
old value 7 7 7 7
new value 6 6 6 6
comment measCfgIdx=50 measCfgIdx=50 measCfgIdx=50 measCfgIdx=50
FDD-FL-PingPong Issue Analysis Budi Prasetyo
CS NPO
01:22
Incident Description (Incident Phenomena)
1 Overview In one project, customer found that the user experience is not so good. UE can often drop from 4G to 3G and also go back to 4G. It seems there is a 4G/3G Ping-Pong issue.
As discuss with customer, user experience 4G/3G Ping-Pong when the user keeps the smart phone in “idle mode”, so Engineer do the drive test with a smart phone in “idle mode”. Note: here “idle mode” just means the user do not try to do any data service with his smart phone. It is not the idle_mode as defined in protocol.
Problem Cause Analysis
2 Test Analysis 2.1 Coverage Overview We found that UE shift from 4G to 3G several times during the drive test. This figure show the LTE serving cell RSRP, the legend Invalid means that UE lost 4G signal.
At the same time, we check the same log for UE 3G signal, we found that UE catch 3G signal exactly when it lost 4G signal. That means UE shift from 4G to 3G. This figure show the WCDMA best RSCP, the legend Invalid means that UE do not catch 3G signal.
2.2 Lost 4G issue Analysis We analyzed the log and found that UE shift from 4G to 3G after two message:Measurement Report and RRC Connection Release. In Measurement Report, UE report LTE serving cell RSRP=-92 dBm and UMTS neighbor cell RSCP=-72 dBm.
UE received RRC Connection Release, this message command UE redirection from 4G
to 3G at ARFCN 10663.
2.3 Parameters Analysis In LTE radio parameters table UeRATMeasurement for ratMeasCfgIdx=1060, these two parameters：rsrpSrvTrd and rscpSysNbrTrd： rsrpSrvTrd： Absolute Decision Threshold of E-UTRAN Serving Cell for RSRP Measurement (dBm) rscpSysNbrTrd： Absolute Decision Threshold of UTRAN System for RSCP Measurement (dBm) These two parameters means that when LTE serving cell RSRP lower than rsrpSrvTrd and UMTS neighbor cell RSCP is higher than rscpSysNbrTrd, UE will handover (redirection if UE or network does not support handover) from LTE to UMTS. We check BASE LTE network parameters, the value for these two parameters are: rsrpSrvTrd
rscpSysNbrTrd
Absolute Decision Threshold of E-UTRAN Serving Cell for RSRP Measurement (dBm)
Absolute Decision Threshold of UTRAN System for RSCP Measurement (dBm)
long:[-140~-43];default:-115
long:[-120~-24];default:-95
-90
-86
The thresholds make UE easily shift from 4G to 3G; after UE shift to 3G, it may reselect back to 4G after a while because 4G have a higher priority. It causes a 4G/3G Ping-Pong. suggest change rsrpSrvTrd from -90 to -110 and rscpSysNbrTrd change from -86 to -90. Solution
3 Re-test After Parameters Modification After changing parameters in the related sites, we re-test the same road and found that UE stay always in 4G.
UE never shift to 3G in the same log when we re-test the same road.
Summary and Notes
4 Suggestion In order to make UE stay in 4G longer and not so easily shift to 3G,suggest all sites implement the following parameters modification： In LTE radio parameters table UeRATMeasurement for ratMeasCfgIdx=1060, these two parameters：rsrpSrvTrd and rscpSysNbrTrd： suggest change rsrpSrvTrd from -90 to -110 and rscpSysNbrTrd change from -86 to -90
