1) Soft Handover Overhead is high

Soft Handover Overhead is higher than 45% in RNC, the value cant meet KPI request, customer ask to
optimize SHO overhead.

Check cell coverage for improving overshooting and reducing SHO overhead with iNastar, we find some
cells coverage to larger, and then ask to customer to down antenna tilt of those cells.

some value of parameters are different HWs recommend value, particularly TrigTime1A (1A Time to
trigger) still using NSNs setting, after swap NSN network 2 years.

After changing TrigTime1A = D320 on Oct. 9

th

2) PS CDR reduced due to inactivity timer opt.

PS DCR was improved after 10/11 due to change PS inactive timer (10sec -> 5sec))

SET UPSINACTTIMER

PsInactTmrForCon
PsInactTmrForStr
PsInactTmrForInt
PsInactTmrForBac
Meaning: When detecting that the Ps' User had no data to transfer for a long time which longer
than this timer, the PDCP layer would request the RRC layer to release this Radio Access
Bear. So the number of normal release will increase which will result in decreasing the PS CDR
= Abnormal Release / Abnormal Release + Normal Release

1) External Interference
We found the KPI for Our site is not good, and the RTWP for all cells are very
High. We check the RTWP for Site New Sites GHB968:

We make a trace for RF Frequency Scaning by which we are confermed that there is some

Interference

External

After This we conferm that there is some External Interference in our Network, so we just inform to
our coustomer to make it clear.
Always check the results for surrounding sites , if you are suspecting Interference.

1) Optimize PS RB Setup timer

PS Drops are very high at RNC
After investigations we found a lot of Ps Drops due to coverage, SRB, TRB Resets and UU No Reply
RbSetup Wait RB setup
RspTmr response timer

Meaning: A timer to RNC wait for the RB setup response from UE in the RB procedure. Refer to the N
RB reconfiguration message may retransmit three times when the timer expires.The parameter modific
has no impact on the equipment.
GUI Value Range: 300~300000
Unit: ms
Actual Value Range: 300~300000
MML Default Value: None
Recommended Value: 5000
Parameter Relationship: None
Service Interrupted After Modification : No (No impact on the UE in idle mode)
Impact on Network Performance: None

So what's recommended is as below:

3) High RTWP Due to Micro Wave Interference

New 3G NodeB has completed integration, RTWP was very high. This site was 2G and 3G
collocation site,before GSM is 1800M band, now UMTS is 2100M
From M2000 we got the RTWP value, the top sector 2 RTWP value was -80, sector 1 and
sector 3 were more than -100, it was serious problem. We did some work for this site below:
1. We exchanged the feeder and jumper, the RTWP didn't change with jumper and feeder ;
2. We replaced the all WRFU and WBBP board, the high RTWP not disappeared;
3. We blocked GSM all TRX in the morning during idle hour, but no any improvement.
4. After we monitor several days KPI,we found that the RTWP can reach the normal level on
sometime , we doubted that it was interference cause RTWP.so we check the installation, we
saw one antenna very near the Huawei antenna.

Negotiated with the other customer regarding reducing their MW power, after they reduce
the power ,the RTWP can reach normal value.

1) DL power congestion solved by admission

control and CPICH power optimization
Cells suffer from high DL power congestion affecting accessibility KPIs (RRC, CS RAB & PS RAB %)
We took two actions:
Optimize CPICH power by decreasing it in both carriers
MOD UCELL:CellId=40483, PCPICHPower=340;
MOD UCELL:CellId=40488, PCPICHPower=340;
optimize the DL load threshold by controlling the admission control (CAC) of conversational
AMR service, conversational non-AMR service, and handover scenarios thresholds, where
they decide when to accept the call only if the load after admitting it is less than above four
thresholds depending on type (default values: 80, 80, 85, 75%)
MML Commands
MODUCELLCAC:CellId=40483,DlConvAMRThd=92,DlConvNonAMRThd=92,DlOtherThd=90,
DlHOThd=93, DlCellTotalThd=95;
MODUCELLCAC:CellId=40488,DlConvAMRThd=92,DlConvNonAMRThd=92,DlOtherThd=90,
DlHOThd=93, DlCellTotalThd=95;

40483: DL power congestion released and accessibility KPIs improved

40488: DL power congestion released and accessibility KPIs improved

1) PS Data traffic Increases drastically & HSDPA

traffic Decreases Simultaneously due to

changing thresholds
Suddenly There is an Increases in PS data traffic & decreases in HSDPA traffic

First we need to check there is increases or decreases in RAB attemts

If we look to HS RAB Attempts then there is an 50 % Decreases hence the HS

traffic decreases.
Analysis

We checked the codes assigned for HS services. But before & after codes assigned is
same there is no change in PS & HS assigned codes. Means for HS it is 7 and
remaining codes is for R99
Then we found a change in parameter below that has been changed from D768 to D64

Parameter Name DL BE traffic threshold on HSDPA

Meaning

Rate threshold for decision to use HS-DSCH to carry DL PS

background/interactive services. When the maximum DL service rate is
higher than or equal to this threshold, the service will be carried on HSDSCH. Otherwise, it will be carried on DCH.

GUI Value Range D8, D16, D32, D64, D128, D144, D256, D384, D512, D768, D1024, D1536,
D1800, D2048, D3600, D7200, D8640, D10100, D13900
Recommended
Value

D64

After returning it back to its original

4) Relief High UL CE congestion by LDR action

site 4092 suffers from high UL CE congestion affected PS RAB SR (Success Rate)%
Load Reshuffling (LDR) is required to reduce the cell load and increase the access success
rate. We enable Cell Credit(CELL_CREDIT_LDR) LDR, NodeB credit(NODEB_CREDIT_LDR ) LDR,
Cell Group Credit (LCG_CREDIT_LDR)
MODUCELLALGOSWITCH:CellId=40926, CELL_CREDIT_LDR-1;
MODUCELLALGOSWITCH:CellId=40927, CELL_CREDIT_LDR-1;
MODUNODEBALGOPARA:NodeBName="C1_0_DEL4092P1(DSK_TE)",NodeBLdcAlgoSwitch=NOD
EB_CREDIT_LDR-1&LCG_CREDIT_LDR-1;
st

nd

as both cells under same node-b

rd

Then I define the 1 , 2 , 3 actions of the LDR to ones that can solve the UL CE problem, as
not all actions in LDR can solve UL CE as inter-freq HO as example
4092 high CE Usage and after LDR action the CE usage decreased

CE Congestion released & PS RAB SR improved

5) Poor PS CSSR due to UL Power congestion

For lot of cells had this problem we took on each cell one or more of below actions:
1) increase UlTotalEquseNum from 160 to 200
As in CAC, UL is admitted if algorithm 2 is applied which is the case if
{{{{{(ENUtotal + ENUnew)/ UlTotalEqUserNum}}}}} <
{{{{{UlNonCtrlThdForHo/AMR/NonAMR/Other}}}}}
2) Activated UL LDR CE/Power and modified UL LDR actions to correspond to UL CE
We enable Cell Credit(CELL_CREDIT_LDR) LDR, NodeB credit(NODEB_CREDIT_LDR ) LDR,
Cell Group Credit (LCG_CREDIT_LDR) and UL_UU_LDR-1;
3) lower UL LDR trigger threshold from 65 to 55

To make LDR work faster

UlLdrTrigThd=55, UlLdrRelThd=45;

Conclusion: Top 3 worst cells UL power Cong recover:

6) IRAT Performance Improvement Actions

Cause CS IRAT and PS IRAT bad bec high physical channel failure at worst cells (which refers to failure due to R
Analysi F problems) + failure due to congestion (found only in CS as PS has no preparation)
s:
After finding out 2 major reasons for CS and PS IRAT failures we investigate further and found bellow men
tioned conclusions
Handli Now we know that route cause of poor IRAT performance was congestion at target 2G cells and poor 2G
ng
coverage at time of IRAT handovers. Capacity augmentation done by 2G team on request for congested
Proces 2G cells on and PS IRAT performance improved after this.
s:
We also done bellow mentioned parameter optimization to further improve IRAT performance as it was
still bellow baseline
1)

3A event:

The estimated quality of the currently used UTRAN frequency is below

a certain threshold and the
estimated quality of the other system is above a certain threshold

QOtherRAT + CIOOtherRAT TOtherRAT + H3a/2

QUsed TUsed - H3a/2

Recommended values of TOtherRAT:

Parameter

Recommended Value

TargetRatCsThd

16, namely -95dBm

TargetRatR99PsThd

16, namely -95dBm

TargetRatHThd

16, namely -95dBm

We changed TargetRatHThd=16 to 26
2)
Also PenaltyTimeForPhyChFail=30 to 60 at worst cells

Parameter ID
Parameter Name

PenaltyTimeForPhyChFail
Inter-RAT HO Physical Channel Failure Penalty Timer
Duration of the penalty for inter-RAT handover failure due to
physical channel failure. The UE is not allowed to make inter-RAT
handover attempts within the penalty time. For details about the
physical channel failure, see 3GPP TS 25.331.

Meaning

Unit

Actual Value
Range

0~65535

Default Value

30

3)
In 3A:

QOtherRAT + CIOOtherRAT TOtherRAT + H3a/2

CIO is composite of CIO(2G) + CIOoffset(3G

2G), so we decreased the CIOoffset to give less priority to

2G to HO to it
4)

Increase timer T309

Parameter ID

T309

Parameter Name Timer 309

Meaning

Unit

T309 is started after the UE is reselected to a cell belonging to

another radio access system in connected mode, or the CELL
CHANGE ORDER FROM UTRAN message is received. It is
stopped after the UE is successfully connected in the new cell. The
UE will continue the connection to UTRAN upon expiry. Protocol
default value is 5.
s

Actual Value
Range

1~8

Default Value

7) different RTWP between F1 and F2 of the same

sector
during normal audits of the network we found that for some sectors there is a diffrence in the RTWP between
F1 and F2 cell of the same sector,

To check we have to verify the following three parts:

1. we had to make sure that the equipment is not faulty

to check the equipment we swapped the sectors between sector1 and sector3
(connected the antenna of sector3 to the RRU and the feaders of sector1 and
antenna of sector1 to the RRU and the feaders of sector3) and when we
did that we
found that the RTWP is the same and didnt move from sector3 to sector
2. we have to make sure that it is no external interference

checked using spectrum annalizer and we found that there is no external interference

3. we have to confirm it is traffic load or not

was the problem, basically the second carrier is used for data traffic, and it was

noticed
that the HSDPA traffic on this cell is relatively high compared with the trend of the first
carrier, Such traffic difference especially in HSDPA and HSUPA can be the reason of the
difference between RTWP of the first and second carrier cells. It is so clear from the below
hourly snap that the RTWP isincreasing and decreasing with the change of the HSDPA
and HSUPA number of users

here is F2 G31377

here is for F1 G31373 and F2 G31377

1) HSDPA low throughput analysis

DT of a cluster we found that the throughput is not high in special areas as per the below snap

Radio conditions was good, CQI of that road was very good (average more than 23) which we verified as per
the below snap

the IUB utlization is normal and there is no congestion as well as the power, below snaps of the IUB utilization at
the test time:

we went deeper to check the number of codes assigned to the UE during the test we found that the number
of codes was very low as per the snap

Reason we found that the NodeB lisence for the number of codes was normal and the feature of the dynamic codes
allocation is activated on the nodeB, but when we checked the average number of users ber hour in a day we found that
the cell is covering alot of users of HSDPA services below snap to show the number of users hourly

8) HSDPA Rate was LOW due to 16QAM not

activated
was swapping vendor and after we swapped the first cluster we found the HSDPA rate is Low comparing
to the value we have before Swap
1- We sent a DT Engineer and started to make a test.
2- Also we checked the IUB BW and the number of HSDPA users configured on the sites and the
number of codes configured for each site.
3- From point 2 we found everything is OK.
4- But from the DT log files we found the following:
5- the DT log files we found the following, We found all the samples under the QPSK and zero samples
at 16 QAM.

we checked the NodeB configuration found the 16QAM switch enabled on all the sites from LST
MACHSPAR
we found one parameter was not exist in our NodeB License: HSDPA RRM license, after activating it 16QAM worked and throughput for the same HSDPA traffic increased

1) Idle Mode 2G-3G optimization to stay more on

3G
To offload traffic over 2G and to make user under 3G coverage more, Change parameter
FDDQMIN from -10 dB to -14 dB on 2G side

SSEARCHRAT from -8 to -9 on 3G side

Inter-RAT measurement:

Squal SsearchRATm

Qqualmeas Qqualmin SsearchRATm

Qqualmeas Qqualmin + SsearchRATm

3G Coverage and traffic increase which can be seen from increase in HSDPA throughput ( more user in 3G for longer
time duration) also face power and CE blocking due to increase in 3G users on those sites which was fixed.

HSDPA UE Mean Cell (increased after change, but reduced again since 20-Oct, probably due

to

increased of power blocking)

Huawei Confidential

1) Low PS traffic on F2 cells due to missing Blind

HO neighbors.
-The problem was that After F3 Expansion on one site and during KPIs check for the period before
expansion We found that site had very low PS traffic (very low PS RAB ATT) On F2 cells and it have very
high traffic (very High PS RAB ATT) on F1 cells while the network strategy dont permit for this scenario to
be happened .

We found that the blind HO was not defined from F1

F2 ADD

UINTERFREQNCELL:RNCID=1,CELLID=5022,NCELLRNCID=1,NCELLID=5025,BLINDHOFLAG=TRUE,
NPRIOFLAG=FALSE,INTERNCELLQUALREQFLAG=FALSE;

Start Time
09/15/2012 00:00:00
09/15/2012 00:00:00
09/15/2012 00:00:00
09/15/2012 00:00:00
09/15/2012 00:00:00
09/15/2012 00:00:00
09/16/2012 00:00:00
09/16/2012 00:00:00
09/16/2012 00:00:00
09/16/2012 00:00:00
09/16/2012 00:00:00
09/16/2012 00:00:00
09/17/2012 00:00:00
09/17/2012 00:00:00
09/17/2012 00:00:00
09/17/2012 00:00:00
09/17/2012 00:00:00
09/17/2012 00:00:00
09/18/2012 00:00:00
09/18/2012 00:00:00
09/18/2012 00:00:00
09/18/2012 00:00:00
09/18/2012 00:00:00
09/18/2012 00:00:00
09/19/2012 00:00:00
09/19/2012 00:00:00
09/19/2012 00:00:00
09/19/2012 00:00:00
09/19/2012 00:00:00
09/19/2012 00:00:00
09/20/2012 00:00:00
09/20/2012 00:00:00
09/20/2012 00:00:00
09/20/2012 00:00:00
09/20/2012 00:00:00
09/20/2012 00:00:00
09/21/2012 00:00:00
09/21/2012 00:00:00
09/21/2012 00:00:00
09/21/2012 00:00:00
09/21/2012 00:00:00
09/21/2012 00:00:00
09/22/2012 00:00:00
09/22/2012 00:00:00
09/22/2012 00:00:00
09/22/2012 00:00:00
09/22/2012 00:00:00
09/22/2012 00:00:00
09/23/2012 00:00:00
09/23/2012 00:00:00
09/23/2012 00:00:00
09/23/2012 00:00:00
09/23/2012 00:00:00
09/23/2012 00:00:00

Period
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440

NE Name
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1

Modification
date
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440
1440

TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1
TUBRNC1

BSC6900UCell
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950
Label=GNH089C, CellID=8949
Label=GNH089B, CellID=8948
Label=GNH089A, CellID=8947
Label=GNH089F, CellID=8952
Label=GNH089E, CellID=8951
Label=GNH089D, CellID=8950

Carrier

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

F1

F2

RRC succ
RRC
rate
RRC att succ(RAN
AMR
(RAN12) (RAN12)
12)
RAB SR
(%)
(times)
(times)
(none)
99.936
15830
15820
100
99.908
35884
35851
99.845
99.923
31532
31508
100
0
0
100
0
0
100
0
0
100
99.956
15938
15931
100
99.931
34830
34806
100
99.918
32950
32923
99.881
0
0
100
0
0
100
0
0
100
99.952
16991
16983
100
99.911
30405
30378
100
99.894
34031
33995
100
0
0
100
0
0
100
0
0
100
99.916
15504
15491
100
99.885
34989
34949
99.843
99.915
29601
29576
100
0
0
100
0
0
100
0
0
100
99.92
16372
16359
100
99.897
31101
31069
100
99.941
29261
29244
99.78
100
1
1
100
100
1
1
100
0
0
100
99.907
19448
19430
100
99.951
27057
27044
100
99.565
28324
28201
100
0
0
100
100
1
1
100
100
1
1
100
99.96
17602
17595
99.519
99.94
38351
38328
99.703
99.932
32648
32626
100
0
0
100
0
0
98.496
100
1
1
98.888
99.934
18324
18312
100
99.947
26804
26790
100
99.924
30626
30603
100
0
0
100
0
0
99.152
0
0
98.611
99.942
17461
17451
100
99.928
25335
25317
99.584
99.942
27838
27822
100
0
0
100
0
0
100
0
0
100

AMR
RAB
Attempt
(none)
352
646
662
10
19
6
300
572
847
5
6
9
375
620
626
8
14
9
318
640
705
6
12
15
312
406
455
71
131
115
336
561
609
96
123
131
208
675
574
38
133
90
371
543
679
58
118
72
337
481
447
55
56
86

9) PS RAB Succ Rate Degraded due to DRD

Parameter and Blind HO
st

PS RAB degraded below baseline on 1 Sept 2012. From statistic, it is cause by top worst
nd
2 cells and not related to all cells in RNC level.

No.of
AMR
RAB
failure
(none)
0
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
1
2
0
0
2
1
0
0
0
0
1
1
0
2
0
0
0
0

AMR
RAB
Success
(none)
352
645
662
10
19
6
300
572
846
5
6
9
375
620
626
8
14
9
318
639
705
6
12
15
312
406
454
71
131
115
336
561
609
96
123
131
207
673
574
38
131
89
371
543
679
58
117
71
337
479
447
55
56
86

PS RAB
SR (none)
99.907
99.961
99.966
100
100
100
99.933
99.98
99.982
100
50
100
99.919
99.97
99.962
100
100
100
99.93
99.966
99.98
100
100
100
99.983
99.971
99.99
99.932
99.935
99.913
99.876
99.963
100
99.878
99.984
99.949
99.973
99.917
99.838
99.796
99.909
99.908
100
99.955
99.979
99.789
99.933
99.899
99.974
99.977
100
99.852
99.989
99.915

PS RAB
Setup
Attempt
(none)
16295
36233
32585
4
20
5
16489
35060
33808
13
2
10
17419
30656
34727
8
8
6
15929
35298
30358
8
10
13
6025
14128
11010
10375
16997
18526
1615
5477
3450
16484
19116
21689
3754
4830
4940
5417
16602
10978
3460
4491
4951
7618
12118
11923
3933
4348
1903
6792
9998
11779

was due to is PS RAB UUFail with its sub counter PS RAB PhyChFail and PS RAB UuNoReply.

The reason for this degrade was following two reasons that after setting them right the things
returned normal as seen in above 2 figures
1. Blind HO Flag for Multi carrier cells inter-frequency relation was wrong setting

10) CSSR PS Degraded due to high PS Code

Congestion after swap
PS CSSR was low because after investigating founf Failed due to Code Congestion

Later For soution We decided to change the Algorithm and Open the LDR in Cell Level at 2 sectors
which had code congestion.
The Parameters are
MOD UCELLALGOSWITCH: CellId=10051, NBMLdcAlgoSwitch=CELL_CODE_LDR-1; MOD
UCELLLDR: CellId=10051, DlLdrFirstAction=CodeAdj, DlLdrSecondAction=Berated,
DlLdrBERateReductionRabNum=1, GoldUserLoadControlSwitch=ON;
PS CSSR Improved after Opening the LDR parameters

11) Low CS IRAT Handover Success Rate due to

miss configuration in GSM band
The requested CS IRAT Handover Success Rate target is 95% but these 2 sites (3 sectors each)
could only achieve around 60% during busy hour as shown in picture below

main reason for the CS IRAT HO failure is due to IRATHO.FailOutCS.PhyChFail.

Note that blue counter is sum of the other 2

Next, checking on cell_gcell counter, found that almost all of the failures happened to the cosite GSM as highlighted below

Row Labels
UCELL_GCELL:43017:740:01:14149:19093

Sum of VS.IRATHO.AttOutCS.GCell

Sum of VS.IRATHO.SuccOutCS.GCell

UCELL_GCELL:43017:740:01:14149:19383

UCELL_GCELL:43017:740:01:14149:2812

29

27

UCELL_GCELL:43017:740:01:14149:40492

UCELL_GCELL:43017:740:01:14149:41001

17

UCELL_GCELL:43017:740:01:14149:41002

UCELL_GCELL:43017:740:01:14149:41003

UCELL_GCELL:43018:740:01:14149:19093

UCELL_GCELL:43018:740:01:14149:19383

UCELL_GCELL:43018:740:01:14149:19643

UCELL_GCELL:43018:740:01:14149:2812

11

11

UCELL_GCELL:43018:740:01:14149:40492

UCELL_GCELL:43018:740:01:14149:41001

10

UCELL_GCELL:43018:740:01:14149:41002

24

UCELL_GCELL:43018:740:01:14149:41003

UCELL_GCELL:43019:740:01:14149:19093

UCELL_GCELL:43019:740:01:14149:19383

UCELL_GCELL:43019:740:01:14149:2811

UCELL_GCELL:43019:740:01:14149:2812

103

101

UCELL_GCELL:43019:740:01:14149:2813

UCELL_GCELL:43019:740:01:14149:40492

UCELL_GCELL:43019:740:01:14149:41001

UCELL_GCELL:43019:740:01:14149:41002

UCELL_GCELL:43019:740:01:14149:41003

19

UCELL_GCELL:43027:740:01:14150:41011

59

UCELL_GCELL:43027:740:01:14150:41012

UCELL_GCELL:43027:740:01:14150:41013

23

UCELL_GCELL:43027:740:01:16202:19082

85

83

UCELL_GCELL:43027:740:01:16202:19083

UCELL_GCELL:43027:740:01:16202:19261

UCELL_GCELL:43027:740:01:16202:19262

UCELL_GCELL:43028:740:01:14150:41011

UCELL_GCELL:43028:740:01:14150:41012

40

11

UCELL_GCELL:43028:740:01:14150:41013

16

UCELL_GCELL:43028:740:01:16202:19261

UCELL_GCELL:43028:740:01:16202:19262

17

16

UCELL_GCELL:43028:740:01:16202:40071

UCELL_GCELL:43028:740:01:16202:40073

UCELL_GCELL:43029:740:01:14150:41011

16

UCELL_GCELL:43029:740:01:14150:41012

UCELL_GCELL:43029:740:01:14150:41013

78

16

UCELL_GCELL:43029:740:01:16202:19082

UCELL_GCELL:43029:740:01:16202:19083

UCELL_GCELL:43029:740:01:16202:19261

33

31

UCELL_GCELL:43029:740:01:16202:19262

16

15

UCELL_GCELL:43029:740:01:16202:40071

UCELL_GCELL:43029:740:01:16202:40073

Checking from the Ios trace, it is found that after the RNC sends the
RRC_HO_FROM_UTRAN_CMD_GSM to UE, the UE replied an
RRC_HO_FROM_UTRAN_FAIL, and the reason is physicalChannelFailure as shown
below.

Numb

The problem was that the GSM cell when created and configured to be in co-BCCH mode which
the main BCCH is in 850MHz while 1900MHz as below from ADD GCELL

But when GSM is defined as external neighbor to the UMTS, it was defined in a band different
from the actual one
TYPE Freq.
Band

Meaning: This parameter specifies the frequency band of new cells. Each new
cell can be allocated frequencies of only one frequency band. Once the
frequency band is selected, it cannot be changed.
GSM900: The cell supports GSM900 frequency band.
DCS1800: The cell supports DCS1800 frequency band.
GSM900_DCS1800: The cell supports GSM900 and DCS1800 frequency bands.
GSM850: The cell supports GSM850 frequency band.
GSM850_DCS1800: The cell supports GSM850 and DCS1800 frequency bands.
PCS1900: The cell supports PCS1900 frequency band.
GSM850_PCS1900: The cell supports GSM850 and PCS1900 frequency bands.
TGSM810: The cell supports TGSM810 frequency band.
GUI Value Range: GSM900, DCS1800, GSM900_DCS1800, GSM850,
PCS1900, GSM850_1800, GSM850_1900, TGSM810
Unit: None
Actual Value Range: GSM900, DCS1800, GSM900_DCS1800, GSM850,
PCS1900, GSM850_1800, GSM850_1900, TGSM810

MML Default Value: None

Recommended Value: None
Parameter Relationship: None
Service Interrupted After Modification : Not involved
Impact on Network Performance: None

ADD UEXT2GCELL):

BandInd Inter-RAT Cell

Frequency
Band Indicator

Meaning: When the inter-RAT cell frequency number is within the

range 512-810, the parameter indicates whether this frequency
number belongs to the DSC1800 or PCS1900 frequency band.
GUI Value Range: GSM900_DCS1800_BAND_USED(Use
GSM900M or 1800M frequency band), PCS1900_BAND_USED(Use
GSM1900M frequency band)
Unit: None
Actual Value Range: GSM900_DCS1800_BAND_USED,
PCS1900_BAND_USED
MML Default Value: GSM900_DCS1800_BAND_USED
Recommended Value: GSM900_DCS1800_BAND_USED
Parameter Relationship: None
Service Interrupted After Modification : No (No impact on the UE in
idle mode)
Impact on Network Performance: None

So when the UE try to make the handover to GSM PCS1900MHz band, the RNC had instructed
the UE to search for DCS1800 band which caused the failure.

After the implementation, the CS IRAT Handover Success Rate has improved obviously as below:

12) Abnormal high RTWP due to improper setting

on NodeB
During cluster acceptance O operator swap project, it was found cell W6374B3 and W6229B3 always be
the top worst cells in AMR drops.
AMR drops for the 7days.

PS DCR was also having relatively poor KPIs, which was 5~30% in these 2 cells.

Scanning through for possible reason of drops, it was found both cells having abnormal high RTWP

We checked hardware problems related to parameters as following:

It was found there is improper setting in desensitization intensity (DSP DESENS) in both
problem cells as shown below.

1. After revert, RTWP of both cells back to normal, on level of -105dBm as shown below.

2. PS DCR of these 2 cells (W6229B3 & W6374B3) showed significant improvement to level of 1% as
shown below.

13) Poor PS IRAT Handover SSR due to congestion

issue on adjacent 2G sites
Symptom:

PS IRAT handover SSR of sector B and C degraded significantly at busy time.

Cause
Analysis:

Handling
Process:

1.
2.
3.
4.
5.
6.
1.

Missing neighbouring 2G cells;

Poor coverage;
IRAT configuration (3G or 2G side);
Congestion on adjacent 2G sites;
PS - CN Topology and configurations ( Intra-SGSN or Inter-SGSN handover, Routing Area Update failure
Others
Checked the CS IRAT HO SSR of the site, which is much better than PS IRAT HO SSR and acceptable. So
and coverage should not be the issue; (most probably is congestion as CS prepare channel while PS dont)
2. PS IRAT HO SSR degraded only at busy time, which is most probably caused by congestion issue on adjac
sites. Checked TBF, GPRS and Edge congestion situation of adjacent 2G sites, and there are serious conges
found.

T591B:

T591C:

T6425B:

T6574A:

T5565C:

3. After expansion on adjacent 2G sites, PS IRAT HO SSR was improved significantly.

14) Analysis Report for bad RTWP on one NodeB

caused by External Interference
bad RTWP on one NodeB.

Action Plan:
1st Action: Request FLM team to perform below actions:
Check connectors/combiner.
Replace combiner,
Check WMPT,
And if still issue not clear, then re-commission the site.

After performing all above actions the RTWP issue still exist on this site (3 sectors), suspected
internal/external interference.

2nd Action: Request to change UARFCN from Freq1 band 1 (UL 9613 DL 10563) to Freq Band
st
6 (UL 9738 DL 10688) which is 25M apart from 1 freq on site 120031_A_Dahlan_3G for trial
purpose,
After change frequency RTWP normal

st

nd

So now we know that there is interference on the 1 freq, so we will continue using this 2 trial freq until
nd
interference is solved in first one, but the problem with 2 freq is that the KPIs where not good as seen
below:

CSSR decrease: RRC.FailConnEstab.NoReply bad.

DCR Increase: VS.RAB.AbnormRel.PS.RF.SRBReset/VS.RAB.AbnormRel.PS.RF.ULSync

/VS.RAB.AbnormRel.PS.RF.UuNoReply bad.
Traffic increased.

So we want to find what is the problem

3rd Action: the first thing found wrong on 2nd freq from Audit Parameters is that there is no inter-freq
HO activated as in 1st freq from below parameter,

we found the HOSWITCH_HO_INTER_FREQ_HARD_HO_SWITCH=FALSE which states that there

is no IFHO performed
Note that there is another switch HO_ALGO_LDR_ALLOW_SHO_SWITCH: this switch is to activate the inter-freq HO triggered by LDR and
LDR only, it means whether LDR action inter-freq can trigger inter-freq HO or not, while the previous one is whether inter-freq is activated or not
which is a must as if not activated this parameter will not have any meaning

st

so before in 1 freq some UEs performed inter-freq as there was no good intra-freq cell, so if no inter-freq
the UE will keep work on the current freq that will increase traffic on current freq and also this will result
in more CDR probability

After fix switch: IFHO comes normal, here below KPI of IFHO success rate

there is improvement in all KPIs but still not good, so we need to improve more
th

4 Action: we wanted to enhance the KPIs for the 2nd freq even more, Check propagation delay
distribution for site 120031_A_Dahlan_3G before and after changing the freq: Found site
overshooting after change frequency:
ID

Counter

Description

73423486 VS.TP.UE.0

Number of RRC Connection Establishment Requests with

Propagation Delay of 0

73423488 VS.TP.UE.1

Number of RRC Connection Establishment Requests with

Propagation Delay of 1

73423490 VS.TP.UE.2

Number of RRC Connection Establishment Requests with

Propagation Delay of 2

73423492 VS.TP.UE.3

Number of RRC Connection Establishment Requests with

Propagation Delay of 3

73423494 VS.TP.UE.4

Number of RRC Connection Establishment Requests with

Propagation Delay of 4

73423496 VS.TP.UE.5

Number of RRC Connection Establishment Requests with

Propagation Delay of 5

73423498 VS.TP.UE.6.9

Number of RRC Connection Establishment Requests with

Propagation Delay of 6~9

73423510 VS.TP.UE.10.15

Number of RRC Connection Establishment Requests with

Propagation Delay of 10~15

73423502 VS.TP.UE.16.25

Number of RRC Connection Establishment Requests with

Propagation Delay of 16~25

73423504 VS.TP.UE.26.35

Number of RRC Connection Establishment Requests with

ID

Counter

Description
Propagation Delay of 26~35

73423506 VS.TP.UE.36.55 Number of RRC Connection Establishment Requests with

Propagation Delay of 36~55
73423508 VS.TP.UE.More55 Number of RRC Connection Establishment Requests with
Propagation Delay Greater than 55
Each propagation delay represents three chips. The propagation distance of one chip is 78 m.
Therefore, one propagation delay corresponds to 234 m.
When the propagation delay is 0, it indicates that the UE is 0-234 m away from the base station.
When the propagation delay is 1, it indicates that the UE is 234-468 m away from the base
station.
When the propagation delay is 2, it indicates that the UE is 468-702 m away from the base
station.
......
When the propagation delay is 55, it indicates that the UE is 12870-13104 m away from the base
station

Here is before changing freq for 3 sectors

Here is after changing and RTWP was fixed

nd

nd

So as u can see the 2 freq has more coverage, this comes from the fact that 2 freq has
st
no continues coverage as 1 freq, as not commonly used freq by other neighbor sited, so
this resulted in less HO that made coverage is more

1) Bad Quality (ECIO) for due to high Users/RTWP

There was bad Ec/No as seen below in DT

This is not a permanent issue as found mainly in busy hour as seen below

The problem mainly was due to high traffic as seen below when number of users increase the RTWP increase
up to -92dB which degrade the quality (Ec/No) in UL which is the same in DL

So the problem was due to not external interference but high traffic
So there are number of solutions to solve high traffic

1) SHO failure due to Iur congestion

The main problem in this swap was IuR congestion

Counter

Description

VS.SHO.FailRLRecfgIur
.OM.Tx

Number of failed radio link synchronous reconfigurations by DRNC on Iur interface because of OM intervention
(cause value: OM Intervention)

VS.SHO.FailRLRecfgIur
.CongTx

Number of failed radio link synchronous reconfigurations by DRNC on Iur interface because of insufficient RNC
capability (cause value: Cell not Available, UL Scrambling Code Already in Use, DL Radio Resources not
Available, UL Radio Resources not Available, Combining Resources not Available, Measurement Temporarily
not Available, Cell Reserved for Operator Use, Control Processing Overload, or Not enough User Plane
Processing Resources)

VS.SHO.FailRLRecfgIur
.CfgUTx

Number of failed radio link synchronous reconfigurations by DRNC on Iur interface because of improper
configurations (cause value: UL SF not supported, DL SF not supported, Downlink Shared Channel Type not
supported, Uplink Shared Channel Type not supported, CM not supported, Number of DL codes not supported,
or Number of UL codes not supported)

VS.SHO.FailRLRecfgIur
.HW .Tx

Number of failed radio link synchronous reconfigurations by DRNC on Iur interface because of hardware failure
(cause value: Hardware Failure)

VS.SHO.FailRLRecfgIur
.TransCongRx

Number of failed radio link synchronous reconfigurations by DRNC on Iur interface because of insufficient RNC
transmission capability (cause value: Transport Resource Unavailable)

Note that if the counter is Tx it refers to DRNC while Rx refers to SRNC

According to the RNC statistics, the DRNC (ZTE) shows a big amount of failures
(VS.SHO.FailRLRecfgIur.CongTx, VS.SHO.FailRLAddIur.Cong.Tx and
VS.SHO.FailRLSetupIur.CongTx) than the SRNC(Huawei). Please find below the respective
pictures.