Professional Documents
Culture Documents
Wcdma PDF
Wcdma PDF
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.
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.
Meaning: A timer to RNC wait for the RB setup response from UE in the RB procedure. Refer to the No
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
Negotiated with the other customer regarding reducing their MW power, after they reduce the
power ,the RTWP can reach normal value.
due
to
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
Meaning
Parameter
Recommended Value
TargetRatCsThd
TargetRatR99PsThd
TargetRatHThd
We changed TargetRatHThd=16 to 26
2)
Also PenaltyTimeForPhyChFail=30 to 60 at worst cells
Parameter ID
PenaltyTimeForPhyChFail
Unit
Actual Value
Range
0~65535
Default Value
30
3)
In 3A:
2G to HO to it
4)
Parameter ID
T309
Unit
Actual Value
Range
1~8
Default Value
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 is increasing and decreasing with the
change of the HSDPA and HSUPA number of users
here is F2 G31377
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 utiliz ation 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 feat ure 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
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
Squal 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
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
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
PS RAB
RAB
Setup
Success PS RAB Attempt
(none) SR (none) (none)
352
99.907
16295
645
99.961
36233
662
99.966
32585
10
100
4
19
100
20
6
100
5
300
99.933
16489
572
99.98
35060
846
99.982
33808
5
100
13
6
50
2
9
100
10
375
99.919
17419
620
99.97
30656
626
99.962
34727
8
100
8
14
100
8
9
100
6
318
99.93
15929
639
99.966
35298
705
99.98
30358
6
100
8
12
100
10
15
100
13
312
99.983
6025
406
99.971
14128
454
99.99
11010
71
99.932
10375
131
99.935
16997
115
99.913
18526
336
99.876
1615
561
99.963
5477
609
100
3450
96
99.878
16484
123
99.984
19116
131
99.949
21689
207
99.973
3754
673
99.917
4830
574
99.838
4940
38
99.796
5417
131
99.909
16602
89
99.908
10978
371
100
3460
543
99.955
4491
679
99.979
4951
58
99.789
7618
117
99.933
12118
71
99.899
11923
337
99.974
3933
479
99.977
4348
447
100
1903
55
99.852
6792
56
99.989
9998
86
99.915
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
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
Row Labels
Sum of VS.IRATHO.AttOutCS.GCell
Sum of VS.IRATHO.SuccOutCS.GCell
UCELL_GCELL:43017:740:01:14149:19093
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
ADD UEXT2GCELL):
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:
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
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.
Cause
Analysis:
Handling
Process:
1.
2.
3.
4.
5.
6.
1.
T591B:
T591C:
T6425B:
T6574A:
T5565C:
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 6
(UL 9738 DL 10688) which is 25M apart from 1st freq on site 120031_A_Dahlan_3G for trial
purpose,
After change frequency RTWP normal
So now we know that there is interference on the 1st freq, so we will continue using this 2nd trial freq until
interference is solved in first one, but the problem with 2nd 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 before in 1st freq some UEs performed inter-freq as there was no good intra-freq cell, so if no interfreq 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
4th 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
73423488 VS.TP.UE.1
73423490 VS.TP.UE.2
73423492 VS.TP.UE.3
73423494 VS.TP.UE.4
73423496 VS.TP.UE.5
73423498 VS.TP.UE.6.9
73423510 VS.TP.UE.10.15
73423502 VS.TP.UE.16.25
73423504 VS.TP.UE.26.35
ID
Counter
Description
Propagation Delay of 26~35
73423506 VS.TP.UE.36.55
So as u can see the 2nd freq has more coverage, this comes from the fact that 2nd freq has no
continues coverage as 1st freq, as not commonly used freq by other neighbor sited, so this
resulted in less HO that made coverage is more
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
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)
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.
After investigation of the traces was detected the next problems which is there is big
congestion in code at ZTE RNC, here below is counters for some cells in ZTE RNC
RNCId
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
CellId
25656
25652
25655
14242
28095
28891
28896
45053
27894
62342
24351
62341
14245
62343
25651
53245
3754
25656
43752
CellName
256C5_6
256C5_2
256C5_5
142U4_2
280C9_5
288C9_1
288C9_6
450C5_3
278C9_4
623U4_2
243C5_1
623U4_1
142U4_5
623U4_3
256C5_1
532U4_5
037C5_4
256C5_6
437C5_2
Time(As
day)
2012-07-18
2012-07-18
2012-07-18
2012-07-21
2012-07-18
2012-07-18
2012-07-18
2012-07-18
2012-07-22
2012-07-25
2012-07-18
2012-07-18
2012-07-18
2012-07-25
2012-07-26
2012-07-18
2012-07-18
2012-07-20
2012-07-31
VS.RAC.DCCC.Fail.Code.Cong
3.0000
754.0000
0
822.0000
0
77.0000
0
85.0000
63.0000
808.0000
89.0000
223.0000
0
173.0000
1562.0000
0
0
0
1025.0000
VS.RAB.SFOccupy.Ratio
0.9136
0.9121
0.9107
0.9097
0.9085
0.9080
0.9080
0.9080
0.9072
0.9068
0.9067
0.9066
0.9062
0.9060
0.9059
0.9056
0.9051
0.9051
0.9051
VS.RAB.SFOccupy.MAX
251.0000
256.0000
246.0000
255.0000
240.0000
248.0000
243.0000
253.0000
255.0000
254.0000
255.0000
254.0000
254.0000
255.0000
256.0000
240.0000
255.0000
247.0000
255.0000
VS.RAB.SFOccupy
233.8861
233.5064
233.1368
232.8829
232.5664
232.4595
232.4520
232.4490
232.2551
232.1405
232.1035
232.1025
231.9770
231.9387
231.9010
231.8272
231.7155
231.6953
231.6940
79
79
79
79
79
79
79
79
79
79
79
79
79
79
79
3855
25652
28094
28092
43752
24352
17993
43752
25656
25652
25652
62342
62343
3653
27896
038C5_5
256C5_2
280C9_4
280C9_2
437C5_2
243C5_2
179C9_3
437C5_2
256C5_6
256C5_2
256C5_2
623U4_2
623U4_3
036C5_3
278C9_6
2012-07-18
2012-07-27
2012-07-18
2012-07-18
2012-07-29
2012-07-18
2012-07-23
2012-07-30
2012-07-19
2012-07-23
2012-07-19
2012-07-26
2012-07-26
2012-07-31
2012-07-29
34.0000
109.0000
18.0000
874.0000
906.0000
30.0000
585.0000
871.0000
1.0000
31.0000
200.0000
219.0000
1157.0000
560.0000
1247.0000
0.9049
0.9049
0.9049
0.9049
0.9048
0.9047
0.9047
0.9045
0.9045
0.9044
0.9043
0.9041
0.9041
0.9040
0.9040
256.0000
256.0000
256.0000
248.0000
256.0000
248.0000
255.0000
256.0000
246.0000
255.0000
253.0000
256.0000
256.0000
256.0000
256.0000
231.6653
231.6500
231.6447
231.6443
231.6314
231.6035
231.5929
231.5526
231.5394
231.5190
231.4931
231.4475
231.4468
231.4336
231.4212
So ZTE activated some algorithms on its side and changed some parameters to solve the
problem, which was actually solved as seen below
rehoming of 29 NodeBs to a new RNCon 24May. The following showed the abnormal release (DCR
nom) increased significantly after 24Jul while normal release (DCR denom) remained almost same
level.
Cause
Analysis
1) Missing ncells
2) RNC parameters or switches
3) RNC license
This is a case of post rehoming KPI degradation, thus we, first of all, checked the ncells script
for the rehoming operation. Found to have few missing ncells for Inter RNC neighboring
relations. Complete ncells added on 25Jul night. DCR improved around 60%. Still it was
suspected there is another reason behind the degradation.
Handling
Process
After checking all the KPI again, it was found there is abnormal increase in CS traffic after
rehoming. Thus we started to suspect these increase are related to the DCR degradation.
Then we went into details to check raw counters of every KPIs, and found that the CS IRAT HO
attempts decreased till almost zero value, same went to PS attempts as well. This explained
the reason why DCR increased and CS traffic increased abnormally as the CS calls have been
kept and dragged in 3G till call drops.
3. Based on this assumption, we tried to compare the configuration of RNC Depok and RNC
Depok2. No different in term of parameters and switches configuration.
4. Then we continued the verification on RNC license, found there was missing item called
Coverage Based Inter-RAT Handover Between UMTS and GSM/GPRS=ON in RNC Depok2.
Field test observation we had changed Azimuth of Panneri 1st Sector from 40* to 160* on
that time RTWP suddenly decreased that mean some Unknown frequency generating by
unknown source which is available near to Andheri Station which is same or very close to
RCOM UL Centre Frequency (1961.5MHz) .
change
RNC having high AMR call drop rate
Phenome
non
Descripti
on
1. It is found that AMR call drop is happening after the compress mode is
triggered from NASTAR.
Analysis
there is improvement in AMR call drop rate after the changes done in IRAT 2D 2F
parameter settings.
Cause Analysis
1. Resource Congestion;
2. Improper configuration;
3. RF issue;
4. CN issue;
5. Others
Handling Process:
1. Checked the traffic of the sector B, and the site has high traffic;
2. Check the PS RAB establish congestion on M2000, and the site has significantly high uplink
power congestion;
3. Analyze the coverage on Naster. The analysis result shows that the site can reach a distant area
(TP=20, Distance=4.6km).
4. With the Nastar result, we then check the site on Google earth. It is clear that the site has
overshooting and overlapping issue. Adjusting azimuth or downtilt is suggested.
Adjust the downtilt and azimuth as the red arrow shows, the issue was recovered with the
reduced traffic.
If TCP ratio is very high, it means downlink power congestion. Then we can:
1.
2.
DlLdrSecondAction=InterFreqLDHO,
Then we can monitor the counters as follows to check the effect of LDR action:
VS.LCC.LDR.InterFreq
VS.LCC.LDR.BERateDL
VS.LCC.LDR.BERateUL
Note: usually power congestion will not happen in dual carrier cell. For single carrier
site, if power congestion is serious, expand carrier is recommended.
RNC having normal CSSR but to improve more PSC audit and change should be done
After the PSC change, CSSR improved.
HUAWEI Confidential
HUAWEI Confidential
Action :
Disable UL power CAC for cell with high UL power congestion. For any cell with UL power
congestion still appear although ULTOTALEQUSERNUM has been set to 200 (=maximum value),
we decide to disable UL power CAC by setting NBMUlCacAlgoSelSwitch in UCELLALGOSWITCH
to ALGORITHM_OFF.
HUAWEI Confidential
Solution
According to Coverage Prediction Plot from Atoll we found that there is coverage shrink in the area due
to bad cell environment and so planned to change the cpich power
Downlink SF
-3
-18
128
28 kbps
-2
-17
64
32 kbps
-2
-17
64
56 kbps
-15
32
64 kbps (VP)
-15
32
0 kbps
-2
-17
256
8 kbps
-8
-23
128
32 kbps
-4
-19
64
64 kbps
-2
-17
32
144 kbps
-15
16
256 kbps
-13
384 kbps
-11
Service
CS Domain
PS Domain
Also
1) RRC Rej and RAB Fail and reason are RRC Rej
and RAB Fail due to Code Congetion in WCDMA
KPI Analysis:
Solution:
If HS-PDSCH Reserved Codes value is excessively high, the HSDPA code resource is wasted and the
admission rejection rate of R99 services increases due to code resource.
so we have change this parameter from 12 to 5 .
As I checked the site parameter config. And found Code number for HS-PDSCH is 12. So change it to 5 as per baseline.
After reduce the HS-PDSCH Code problem is solved.
When we implemented the work order of RNC in one region we got the IRAT HO Success Rate
of 24%.
After we executed one work order on 69 sites of One RNC in one region we got so many IRAT
failures.
BSC6900UCell
IRATHO.FailRelocPrepOutCS.UKnowRNC
Label=UBEN077_S1, CellID=20771
Label=UBEN077_S3, CellID=20773
Label=UBEN007_S2, CellID=20072
Label=UBEN077_S2, CellID=20772
Label=UBEN017_S1, CellID=20171
Label=UBEN038_S3, CellID=20383
Label=UBEN070_S1, CellID=20701
Label=UBEN901_S2, CellID=29012
Label=UBEN039_S1, CellID=20391
Label=UBEN901_S3, CellID=29013
Label=UBEN901_S1, CellID=29011
Label=UBEN017_S2, CellID=20172
Label=UBEN070_S2, CellID=20702
Label=UBEN028_S2, CellID=20282
Label=UBEN025_S1, CellID=20251
Label=UBEN032_S2, CellID=20322
3350
1998
1796
940
874
844
631
507
482
388
327
314
308
255
252
218
1. Checked neighbor data from 3G to GSM Handover in RNC, checks each NGSM cell
information, there is no problem in that.
2. Traced singling in RNC using LMT and found many prepare handover failed, the
reason is unknown target RNC. What backed it out is that the counters from
M2000 that counts are
IRATHO.FailOutCS.PhyChFail
IRATHO.FailRelocPrepOutCS.UKnowRNC
3. Based on that we have checked the configured LAC in MSC, checked MSC data and
find LAI is wrong.
After the LAI modifications in the RNC & MSC we have got The IRAT HO success Rate of
97%
Recommended Value
InterRATCSThd2DEcN0
InterRATR99PsThd2DEcN0
InterRATHThd2DEcN0
-15, namely-15dB
InterRATCSThd2DRSCP
InterRATR99PsThd2DRSCP
InterRATHThd2DRSCP
HystFor2D
4, namely 2dB
TimeToTrig2D
- Speed up handover to avoid failure due to poor RF by increased INTERRATR99PSTHD2DRSCP from -110 to -100dBm and
- Adjust parameter INTERRATPHYCHFAILNUM from 3 to 1 to speed up the penalty period after first time physical channel
Parameter ID
Parameter Name
Meaning
InterRatPhyChFailNum
Inter-RAT HO Physical Channel Failure THD
Maximum number of inter-RAT handover failures allowed due to physical channel failu
When the number of inter-RAT handover failures due to physical channel failure excee
threshold, a penalty is given to the UE. During the time specified by
"PenaltyTimeForInterRatPhyChFail", the UE is not allowed to make inter-RAT hando
attempts. For details about the physical channel failure, see 3GPP TS 25.331.
- GSM cells that contribute with high failure that affect IRAT success rate, you can decrease its priority by adjusting targe
(NPRIOFLAG, NPRIO, RATCELLTYPE).
>After implemented the actions according to KPI Improvement plan (page 3) , the
target KPI : PS IRAT HO Success Rate significant improve from about 85.6% to
94.8 %.
From counter analysis, we found per RNC that there are nearly 300 drops on PS R99 drop:
And TOP cell has nearly 30 drops R99 PS drop, other cell has several times R99 PS drop:
At the same time, H2D time begins to increase when activation of 64QAM is made:
Analyzing the RNC configuration, find that HSPA+ service is not allowed to start CM:
This configuration will cause 64QAM user in the bad coverage must turn to DCH from
HSDPA, then the user starts CM. This is more possible to drop.
In the IOS, some user drop after 64QAM UE return to DCH for bad coverage:
Solution
According to the above analysis, HSPA+ service cant support CM, so HSPA+ user in bad
coverage return to DCH that causes R99 PS drop ratio increase.
SET UCMCF: EHSPACMPermissionInd=TRUE
ID
67199740
Counter
Description
This counter provide the bandwidth of common channels for the CRNC on the Iub interface in the
unit of bytes per second.
ID
Counter
Description
73439970
VS.FACH.DCCH.CONG.TIME
Congestion Duration of
DCCHs Carried over FACHs
for Cell
73439971
VS.FACH.DTCH.CONG.TIME
These counters provide the duration for which the DCCHs/DTCHs carried over the FACHs in a
cell are congested. Unit:sec
Solution:
Event 1A triggering threshold is reduced to make the event less likely to occur. Below is
the command:
MOD UCELLINTRAFREQHO: RNCId=XX, CellId=XXXX, IntraRelThdFor1ACSVP=5,
IntraRelThdFor1ACSNVP=5, IntraRelThdFor1APS=5;
t was changed from default value 6. Below is the result after change:
The soft handover overhead and SPU Load reduced after the change. The SPU
load usage reduction more than 10%
In addition, the call drop rate have not changed after the changes
CAUSE ANALYSIS
The problem is shown in Figure 1, where the IU Paging Success Ratio is degraded.
As shown in Figure 2, the RRC successful connection rate stayed almost the same. This indicated that there is nothing wrong wit
h the common part which RRC connection and paging share together, including UU interface, NODEB, IUB, some internal modul
es of RNC.
Figure 3 CPUSALLVS.PAGING.FC.Disc.Num.CPUs
o
o
In addition, from the performance file, there is no PCH congestion found at all, as shown in figure 4, and there is no paging discar
ded too.
It shows that, the paging message should successfully be delivered from IU interface to UU interface. This conclusion together wi
th point 1 indicates the PSR deterioration is not caused by UTRAN.
Figure 4 UCELLALLVS.RRC.Paging1.Loss.PCHCong.Cell
From an hour IU Trace, there is 286 location update failure out of 4042 location update requests in total with the reason shown as Figure 7.All the
failure was received from CN.
From the analysis, we could say that after IU-FLEX, repeated paging mechanism could be altered, which could bring in more useless paging attempts.
As a result, PSR on RNC is degraded.
Label=050076_3G-3, CellID=37836
220
2012-10-16
Label=050076_3G-3, CellID=37836
453
2012-10-17
Label=050076_3G-3, CellID=37836
124
We found when the UL power congest, the traffic is a little high,so we reduce CPICH power 1DB to decreases the cov
erage ,but we found the UL power still congestion after the revision, we doubt that lack of resources is not the root cau
se.
We check the current network parameters, found uplink CAC algorithm switch of the issue cell is set to ALGORITHM_
SECOND(The equivalent user number algorithm).
Algorithm
Content
ALGORITHM_OFF
ALGORITHM_FIRST
If we use ALGORITHM_SECOND,the network performs admission control based on the uplink equivalent number of
users (ENU) of the cell and the predicted ENU caused by admitting new users.
It means according to the different service types, equivalent to different number of users. When the cell equivalent nu
mber of users exceeds the set value(Here is 95), the cell will deny user access.
According the algorithm principle,we use ALGORITHM_OFF to disable uplink call admission control algorithm.
After we monitor several days KPI,we found that the KPI can reach the normal level,and there are no abnormal fluct
uations with other KPIs
For the uplink power congestion,we could analyze from the following two aspects
1.Lack of resources.
a:Check CE adequacy of resources;
b:Adjust the coverage.by modifying the pilot power and the maximum transmission power or by RF optimal adjustme
nt.
2. Lead to the issue of parameter settings.
Adjust cell parameters:as the access control algorithm
Page 1
Cluster
Shown below is the Overall TP distribution for X area Cells. As shown in Map these cells are
facing in open area with no 3G coverage overlap.
Nearly 20.0% of samples lies in >1.5 Km
CS Traffic has increased after swap hence there is no loss of coverage after swap from legacy
Name
Pre-Swap KPI
Post-Swap KPI
33,795
40,479
Page 3
Cause of the problem was attenuation not set and TMA not configured but were physically present on the Site .
On investigation we found that the cell having High RSSI were having TMA before Swap . But were not configured
in the Huawei System afterwards . Also attenuation needs to be set accordingly .
Here is the process and commands to check .
When there is no TMA, the attenuation value is set to 0. When the 12 dB TMA is used, the
attenuation value is set between 4 dB to 11 dB. When the 24 dB TMA is used, the attenuation
value is set between 11 dB and 22 dB. When the 32 dB TMA is used, the attenuation value is set
between 22 dB and 30 dB.
This command takes effects immediately after the execution.
ATTEN Attenuation of RX
Channel(dB)
Detail Analysis:
In Moran RNC on Mosaic project >> PS RAB Success/UL Power congestion noticed
and due to which PS RAB get affected. To improve it >> Cell Loading Reshuffling
parameters UCELL_UU_LDR changed and due to change PS RAB get OK.
Start time
RAB Setup
Success
Rate(PS)
Call Setup
Success
Rate(PS)
Number of Failed PS
RAB Establishments
for Cell (UL Power
Congestion) (none)
Eircom Wicklow_1
11/23/2012 15:00
96.27%
96.12%
95
Eircom Wicklow_1
11/23/2012 16:00
93.45%
92.33%
208
Eircom Wicklow_1
11/23/201217:00
54.76%
54.33%
297
Eircom Wicklow_1
11/23/2012 18:00
74.66%
71.56%
592
Eircom Wicklow_1
11/23/2012 19:00
48.18%
47.55%
653
Eircom Wicklow_1
11/23/2012 20:00
69.51%
69.10%
432
Eircom Wicklow_1
11/23/2012 21:00
89.42%
89.03%
210
Eircom Wicklow_1
11/23/2012 22:00
94.21%
94.11%
117
Cluster Name
But still after changing this parameter, UL Power Congestion problem did not resolve, there was
some improvement but Congestion was there.
DESCRIPTION OF PARAMETER:
Start time
RAB
Setup
Success
Rate(PS)
Call
Setup
Success
Rate(PS)
Number of Failed
PS RAB
Establishments
for Cell (UL Power
Congestion)
(none)
Eircom Wicklow_1
12/08/2012 15:00
99.85%
99.73%
Eircom Wicklow_1
12/08/2012 16:00
99.79%
99.56%
Eircom Wicklow_1
12/08/2012 17:00
100.00%
99.64%
Eircom Wicklow_1
12/08/2012 18:00
99.89%
99.84%
Eircom Wicklow_1
12/08/2012 19:00
99.92%
99.88%
Eircom Wicklow_1
12/08/2012 20:00
99.88%
99.67%
Eircom Wicklow_1
12/08/2012 21:00
100.00%
100.00%
Eircom Wicklow_1
12/08/2012 22:00
99.97%
99.89%
Cluster Name
1.4 UL Power congestion problem get resolved after changing this parameter
Detail Analysis:
In Meteor RNC on Mosaic project PS RAB get degraded on 1 Site,So to improve
UCELL CAC UL UE equivalent parameter changed and due to change PS RAB get
OK.
Start time
RAB
Setup
Success
Rate(CS)
Call
Setup
Success
Rate(CS)
RAB
Setup
Success
Rate(PS)
Call
Setup
Success
Rate(PS)
Number of Failed
PS RAB
Establishments for
Cell (UL Power
Congestion)
(none)
Ashford_MMC_2
12/5/2012 19:00
79.31%
79.31%
92.23%
92.11%
47
Ashford_MMC_2
12/5/2012 19:00
100.00%
100.00%
92.22%
91.79%
100
Ashford_MMC_2
12/5/2012 20:00
86.21%
86.21%
54.76%
54.33%
306
Ashford_MMC_2
12/5/2012 20:00
82.98%
82.98%
54.23%
53.96%
590
Ashford_MMC_2
12/5/2012 21:00
82.61%
82.61%
43.78%
43.68%
574
Ashford_MMC_2
12/5/2012 21:00
87.50%
85.00%
46.31%
46.20%
422
Ashford_MMC_2
12/5/2012 22:00
86.67%
86.67%
86.73%
86.63%
102
Ashford_MMC_2
12/5/2012 22:00
100.00%
100.00%
87.31%
87.31%
168
Cluster Name
DESCRIPTION OF PARAMETER:
Impact on Network Performance: If the value is too high, the system load after
admission may be over large, which impacts system stability and leads to system
congestion. If the value is too low, the possibility of user rejects may increase, resulting
in waste in idle resources.
RAB
Setup
Success
Rate(PS)
Call
Setup
Success
Rate(PS)
Number of Failed
PS RAB
Establishments
for Cell (UL Power
Congestion)
(none)
Start time
RAB Setup
Success
Rate(CS)
Call
Setup
Success
Rate(CS)
Ashford_MMC_2
12/15/2012 19:00
96.77%
96.77%
99.75%
99.62%
Ashford_MMC_2
12/15/2012 19:00
100.00%
100.00%
99.83%
99.28%
Ashford_MMC_2
12/15/2012 20:00
100.00%
100.00%
100.00%
99.75%
Ashford_MMC_2
12/15/2012 20:00
100.00%
100.00%
99.92%
99.82%
Ashford_MMC_2
12/15/2012 21:00
100.00%
93.33%
99.89%
99.78%
Ashford_MMC_2
12/15/2012 21:00
100.00%
100.00%
100.00%
99.58%
Ashford_MMC_2
12/15/2012 22:00
100.00%
90.00%
100.00%
100.00%
Ashford_MMC_2
12/15/2012 22:00
100.00%
100.00%
99.89%
99.55%
Cluster Name
1.4 UL Power congestion problem get resolved after changing this parameter
Detail Analysis:
In Meteor RNC on Mosaic project CS RAB get bad of 1 Site, So to improve
DLALGOWSITCH OFF parameter changed and due to change>> CS RAB get OK.
Cluster Name
Start time
Call
Setup
Success
Rate(CS)
Number of
Failed CS RAB
Establishments
for Cell (DL
Power
Congestion)
(none)
BallyguileHill_MMC_F1_1
11/28/2012 18:00
98.02%
44
BallyguileHill_MMC_F2_1
11/28/2012 19:00
97.17%
BallyguileHill_MMC_F1_1
11/28/2012 19:00
96.37%
17
BallyguileHill_MMC_F2_1
11/28/2012 20:00
97.00%
BallyguileHill_MMC_F1_1
11/28/2012 20:00
96.87%
14
BallyguileHill_MMC_F2_1
11/28/2012 21:00
96.99%
BallyguileHill_MMC_F1_1
11/28/2012 21:00
96.37%
13
BallyguileHill_MMC_F1_1
11/28/2012 22:00
98.00%
BallyguileHill_MMC_F1_1
11/28/2012 23:00
99.48%
DESCRIPTION OF PARAMETER:
1. In OFF condition : DL CAC algorithm is disable.
In Algorithm First condition: The load factor prediction is ON.
If Algorithm first applied than after reaching load factor, new calls are rejected. While if
we disable it than it can take new call. We make it OFF most of the time at the time of
more load on site, while Algorithm First is used when we have more sites nearby and
reaching certain load/threshold, it can transfer calls to near by BTS
1.3 KPI Analysed : KPI analysed after cahnge and Improvement found :
KPI ATTACHED for refernece:
Cluster Name
Start time
Call Setup
Success
Rate(CS)
Number of Failed
CS RAB
Establishments
for Cell (DL
Power
Congestion)
(none)
BallyguileHill_MMC_F1_1
11/30/2012
18:00
99.42%
BallyguileHill_MMC_F1_2
11/30/2012
18:00
100.00%
BallyguileHill_MMC_F1_1
11/30/2012
19:00
99.65%
BallyguileHill_MMC_F1_2
11/30/2012
19:00
100.00%
BallyguileHill_MMC_F1_1
11/30/2012
20:00
99.75%
BallyguileHill_MMC_F1_2
11/30/2012
20:00
100.00%
BallyguileHill_MMC_F1_1
11/30/2012
21:00
99.04%
BallyguileHill_MMC_F1_2
11/30/2012
21:00
100.00%
BallyguileHill_MMC_F1_1
11/30/2012
22:00
99.60%
BallyguileHill_MMC_F1_2
11/30/2012
22:00
100.00%
BallyguileHill_MMC_F1_1
11/30/2012
23:00
99.58%
BallyguileHill_MMC_F1_2
11/30/2012
23:00
100.00%
1.4 DL Power congestion problem get resolved after changing this parameter
Phenomenon Description
Hsupa call drop increase after hsupa cm is permitted:
Cm permission ind on hsupa is changed from limited to permit
list rnc-oriented cmcf algorithm parameters
------------------------------------------cm permission ind on hsdpa = permit
cm permission ind on hsupa = permit
cm permission ind on hspa+ = permit
Alarm Information
none
Cause Analysis
Time
(As hour)
VS.HSUPA. VS.HSUPA.
RAB.
RAB
Release
.AbnormRel.
Rate
VS.HSUPA
.E2F.
Succ
1,02%
2011-04-03 00:00:00
51682
2011-04-03 01:00:00
2011-04-03 02:00:00
47012
1,06%
498
43439
3075
42068
0,54%
228
39714
2126
2011-04-03 03:00:00
39811
0,62%
246
37729
1836
2011-04-03 04:00:00
37147
0,48%
179
35489
1479
2011-04-03 05:00:00
35628
0,46%
165
34323
1140
2011-04-03 06:00:00
35007
0,47%
165
33860
982
2011-04-03 07:00:00
33478
0,48%
161
32371
946
2011-04-03 08:00:00
33488
0,47%
158
32243
1087
2011-04-03 09:00:00
36558
0,59%
216
34963
1379
2011-04-03 10:00:00
43005
0,78%
337
40493
2175
2011-04-03 11:00:00
46745
1,01%
472
43090
3183
2011-04-03 12:00:00
50449
0,92%
466
46371
3612
2011-04-03 13:00:00
53865
1,20%
646
48550
4669
2011-04-03 14:00:00
53655
1,21%
649
48341
4665
2011-04-03 15:00:00
53326
1,20%
640
48418
4266
2011-04-03 16:00:00
53662
1,25%
669
48145
4848
2011-04-03 17:00:00
56492
1,21%
685
50469
5338
2011-04-03 18:00:00
56744
1,32%
749
50089
5905
2011-04-03 19:00:00
59140
1,16%
688
52716
5736
2011-04-03 20:00:00
61355
1,30%
800
54158
6397
2011-04-03 21:00:00
60632
1,27%
771
53661
6198
2011-04-03 22:00:00
61460
1,19%
730
54917
5813
2011-04-03 23:00:00
57151
1,01%
575
51068
5508
2011-04-04 00:00:00
49978
0,83%
413
46046
3519
2011-04-04 01:00:00
45064
0,50%
227
42762
2075
2011-04-04 02:00:00
41767
0,57%
240
40027
1500
2011-04-04 03:00:00
38890
0,41%
161
37628
1101
2011-04-04 04:00:00
38198
0,33%
125
37153
920
2011-04-04 05:00:00
37880
0,30%
115
36891
874
2011-04-04 06:00:00
39438
0,31%
124
38379
935
2011-04-04 07:00:00
49245
0,52%
258
47385
1602
2011-04-04 08:00:00
76818
0,90%
694
72340
3784
2011-04-04 09:00:00
97637
0,81%
790
90664
6183
2011-04-04 10:00:00
101384
1,16%
1172
97995
2217
2011-04-04 11:00:00
102138
1,03%
1054
100975
107
2011-04-04 12:00:00
106681
1,09%
1165
105377
138
2011-04-04 13:00:00
107342
1,08%
1156
106054
130
2011-04-04 14:00:00
103931
1,15%
1194
102660
75
2011-04-04 15:00:00
100534
1,27%
1275
99181
77
2011-04-04 16:00:00
102318
1,22%
1249
100988
79
2011-04-04 17:00:00
103256
1,22%
1257
101918
79
2011-04-04 18:00:00
98919
1,46%
1443
97404
71
2011-04-04 19:00:00
89741
1,48%
1325
88373
43
2011-04-04 20:00:00
75692
1,50%
1138
74528
25
2011-04-04 21:00:00
70472
1,49%
1049
69387
36
2011-04-04 22:00:00
66384
1,50%
997
65327
59
2011-04-04 23:00:00
60195
1,61%
971
59160
62
Phenomenon Description In country R during WCDMA optimization project, at the step of RRC CSSR optimization
RNO team found abnormal distribution of RRC attempts for registration reason. It takes around 50% of total RRC
Attempts. Hardware version is BSC6810V200R011C00SPC100.
Symptoms:
Analyze sequence:
Analyse Procedure: From statistic for RNC 4016 VS.RRC.AttConnEstab.Reg teaks around 50% of
total RRC Attempts Connection Establishment. Attempts are normally distributed among cells.
RNCName
RNC:4016
RNC:4016
RNC:4016
RNC:4016
RNC:4016
2011-08-14
2011-08-13
2011-08-12
2011-08-11
2011-08-10
1000000
800000
600000
400000
2000000
RNC:4016
RNC:4016
RNC:4016
RNC:4016
RNC:4016
VS.RRC.AttConnEstab
VS.RRC.AttConnEstab.
Reg
At the same time for other 2 RNC's no such situation, RRC Attempts with Registration reason are
no more than 15%.
Such results exclude problem of CN because all 3 RNCs of this region share same CN.
So possible reasons of such situation are:
1. Wrong RNC/Cell Level parameter settings.
2. Bad coverage and frequent reselection of 2G <-> 3G networks.
For first reason we use Nastar Configuration Analysis Function to check difference in
parameters setting. No any difference.
For second reason RNO team decide to perform Drive Test to check coverage and UE
behavior. As result found that UE repeat to perform Combined RA/LA update and Location
Update every time failed with reason MSC temporarily not reachable. RA Update is
performed successfully.
2011-08-
2011-08-
2011-08-
2011-08-
2011-08-
2011-08-
2011-08-
2011-08-
VS.RRC.AttConnEstab
2011-08-
1000000
800000
600000
400000
200000
0
VS.RRC.AttConnEstab.R
eg
Suggestion: For RAN performance optimization needs to pay attention at whole network
structure including Transmission and Core Network. Wrong setting of such global parameter like
NMO brings additional UE power, radio resource consumption, additional RNC SPU and CN
signalling loading.