1 © Nokia Siemens Networks Charles / 2009-05-05
For internal use
WCDMA Radio Parameters Optimization Cases
23/4/20
For internal use2 © Nokia Siemens Networks Charles / 2009-05-05 Page 2
Parameters Optimization Flow Chart
Parameters Optimization start
Configuration data collection
Signaling trace data collection
Drive test data collection
Statistics data collection
Data analysis and optimization
KPI is OK?
Parameters optimization ends.
Parameters tuning
YES
NO
For internal use3 © Nokia Siemens Networks Charles / 2009-05-05 Page 3
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use4 © Nokia Siemens Networks Charles / 2009-05-05 Page 4
The coverage parameters being tuned frequently
Coverage Parameters:
No.
Parameters Name
Description Default value
1 RLMaxDLPwr RL Max DL TX power[0.1dB] 0 for AMR2 RLMinDLPwr RL Min DL TX power[0.1dB] -150(-15dB) for AMR3 MaxTxPower Max transmit power of cell[0.1dBm] 430 (43dBm)4 PCPICHPower PCPICH transmit power[0.1dBm] 330 (33dBm)5 MaxPCPICHPowe
rMax transmit power of PCPICH[0.1dBm] 346 (34.6dBm)
6 MinPCPICHPower Min transmit power of PCPICH[0.1dBm] 313 (31.3dBm)
7 RADIUSLocal Cell Radius(m). This is a parameter in NodeB.
30000 (30km)
For internal use5 © Nokia Siemens Networks Charles / 2009-05-05 Page 5
Case 1: Increase the PCPICH Power to improve the coverage
Case 2: Increase DL maximum power of AMR to improve call drop rate
Case 3: Increase FACH power to improve RRC setup success rate
Case 4: Optimize the timer T300 to improve RRC success Rate
Case 5: UE cannot access due to cell radius settings
Coverage parameters optimization cases
For internal use6 © Nokia Siemens Networks Charles / 2009-05-05 Page 6
Increase the PCPICH Power to improve the coverage
Problem Description:
• The RSCP is not good;• The EcIo is bad;• Add a new site is very
difficult。
Suggest a new site
For internal use7 © Nokia Siemens Networks Charles / 2009-05-05 Page 7
RSCP Before increasing Pcpich Power
RSCP after Increasing Pcpich Power 3dB
Increase PCPICH Power 3dB to improve the coverage.
1. How to modify the maximum PCPICH power?
MOD PCPICHPWR: CELLID=30141, MAXPCPICHPOWER=360;
MOD CELL: CELLID=30141, PCPICHPOWER=360;
2. How to modify the minimum PCPICH power?
MOD PCPICHPWR: CELLID=13011, MINPCPICHPOWER=300;
MOD CELL: CELLID=13011, PCPICHPOWER=300;
EcIo Before increasing Pcpich Power
EcIo after Increasing Pcpich Power 3dB
Increase the PCPICH Power to improve the coverage
For internal use8 © Nokia Siemens Networks Charles / 2009-05-05 Page 8
Case 1: Increase the PCPICH Power to improve the coverage
Case 2: Increase DL maximum power of AMR to improve call drop
rate
Case 3: Increase FACH power to improve RRC setup success rate
Case 4: Optimize the timer T300 to improve RRC success Rate
Case 5: UE cannot access due to cell radius settings
Coverage parameters optimization cases
For internal use9 © Nokia Siemens Networks Charles / 2009-05-05 Page 9
Increase DL maximum power of AMR to improve call drop rate
CS Drop Rate
0. 37%0. 46%0. 42%0. 40%
0. 53%0. 53%0. 41%
0. 49%0. 46%
0. 63%
0. 93%
0. 55%
0. 89%0. 79%
0. 60%0. 72%
0. 64%0. 58%
0. 87%
1. 36%
0. 98%
0
10000
20000
30000
40000
50000
60000
2007
74
年月
日
2007
75
年月
日
2007
76
年月
日
2007
77
年月
日
2007
78
年月
日
2007
79
年月
日
2007
710
年月
日
2007
711
年月
日
2007
712
年月
日
2007
713
年月
日
2007
714
年月
日
2007
715
年月
日
2007
716
年月
日
2007
717
年月
日
2007
718
年月
日
2007
719
年月
日
2007
720
年月
日
2007
721
年月
日
2007
722
年月
日
2007
723
年月
日
2007
724
年月
日
0. 00%0. 20%0. 40%0. 60%0. 80%1. 00%1. 20%1. 40%1. 60%
VS. RAB. Loss. CS. RF TI . Cal l . Drop. Rate. CS. Req TI . Cal l . Drop. Rate. CS
a)In T network, during the WCDMA network swapping from S to Huawei, CS call drop rate of Cluster 14 rose from 13th July, from 0.45% to more than 0.6%. Before swap the CS drop rate is only 0.48%. The upper figure is the CDR of Cluster 14 from Jul.4 to Jul. 24.
b) Most call drop reason is SRB reset, most times RNC sent ASU to UE but did not receive the response. The signal in drop points is very weak, RSCP is about -110dBm and most drops happened just after connection establishment.
c) This area is near Mediterranean Sea, most coverage is beach and highway. The increasing traffic is due to tourists.
Call drop increasing
For internal use10 © Nokia Siemens Networks Charles / 2009-05-05 Page 10
a) Firstly we check the Huawei power configuration and found the FACH power (34dBm) is high than maximum AMR DCH DL power (33dBm), this explained why in some area in cell edge, the UE can access to network but cannot keep the connection.
b) Then we check the S power configuration. The maximum DL DCH power of S AMR service is 36dBm.
c) So in S network, if UE can setup call, it will not drop due to DL power. That explain why S call setup KPI in worse than Huawei but call drop is better than Huawei.
Increase DL maximum power of AMR to improve call drop rate
The maximum DL DCH power of S AMR service is 36dBm as following table.
For internal use11 © Nokia Siemens Networks Charles / 2009-05-05 Page 11
CS Drop Rate
0. 67%0. 58%
0. 51%
0. 63%0. 55%0. 59%0. 62%
0. 48%0. 43%0. 43%0. 39%
0. 48%
0100002000030000400005000060000700008000090000
100000
2007
725
年月
日
2007
726
年月
日
2007
727
年月
日
2007
728
年月
日
2007
729
年月
日
2007
730
年月
日
2007
731
年月
日
2007
81
年月
日
2007
82
年月
日
2007
83
年月
日
2007
84
年月
日
2007
85
年月
日
0. 00%0. 10%0. 20%0. 30%0. 40%0. 50%0. 60%0. 70%0. 80%
CS_Drop_Ti mes CS_Rel _Ti mes CS_Drop_Rate
Mod Power for AMR
DL DCH maximum power of AMR service was changed from 33dBm to 35dBm in cluster 14 on 2th August, and then the CS drop rate decreased as following figure.
How to modify the maximum power of AMR from 33dBm to 35dBm?
MOD CELLRLPWR:CELLID=0, CNDOMAINID=CS_DOMAIN, MAXBITRATE=12200, RLMAXDLPWR=2, RLMINDLPWR=-130, DLSF=D128;
CS12.2 CS64 PS32 PS64 PS144 PS256 PS384
Default value
0 +3 -4 -2 +0 +2 +4
HK 0 +1 -4 0 +2 +2 +3
UAE -3 +3 -4 -2 0 +2 +4
NL -3 +1 -4 0 +1 +2 +3
Increase DL maximum power of AMR to improve call drop rate
For internal use12 © Nokia Siemens Networks Charles / 2009-05-05 Page 12
Case 1: Increase the PCPICH Power to improve the coverage
Case 2: Increase DL maximum power of AMR to improve call drop rate
Case 3: Increase FACH power to improve RRC setup success rate
Case 4: Optimize the timer T300 to improve RRC success Rate
Case 5: UE cannot access due to cell radius settings
Coverage parameters optimization cases
For internal use13 © Nokia Siemens Networks Charles / 2009-05-05 Page 13
Increase FACH power to improve RRC setup success rateFrom KPI in last few months, there were some RRC setup failures. It was mainly caused during reselection and registration.
RRC Setup Failure Distribution
05000
10000150002000025000300003500040000
Ori gnat i ng Termi nat i ng Resel ect i on Regi st rat i on
86%
88%
90%
92%
94%
96%
98%
100%
RRC Setup Fai l ure RRC Setup Success Rate
Signaling for RRC Setup
UE RNC
NBAP
6.CCCH
NodeB
NBAP
RRCRRC
RRCRRC
1. CCCH: RRC CONNECTION REQUESTRRCRRC
NBAP NBAP
7.DCCH RRC CONNECTION SETUP COMPLETE
3. RADIO LINK SETUP REQUEST
4. RADIO LINK SETUP RESPONSE
2 . Allocate parameters
Such as RNTI, L1,L2
5. ALCAP Setup and Synchronization
RRC CONNECTION SETUP
RRC setup failure for poor coverageRNC send RRC Connection Setup to UE after receiving RRC Connection Request from UE. So UL is ok. But RNC cannot receive RRC Connection Setup Complete from UE. So the cause is DL poor coverage.
For internal use14 © Nokia Siemens Networks Charles / 2009-05-05 Page 14
1. Optimize “MAXFACHPOWER”.
The value is maximum transmit power of FACH, and it’s -1dB in live network. We suggest changing it to 1 dB. It means the FACH power is 34dBm.
2. In live network, NodeB maximum transmit power is 43dBm, and supposing all the other common channels the same as before. We calculate the influence for live network, especially for capacity.
FACH: changed from 32dBm to 34dBm, and active factor is 0.25, then it’ll influence DCH: 0.25*(10^ ((34-43)/10)-10^ ((32-43)/10)) =1.16%
This impact is acceptant because live network is limited by coverage.
RRC SETUP
050
100150200250300350
2005
- 8- 1
1
2005
- 8- 1
2
2005
- 8- 1
3
2005
- 8- 1
4
2005
- 8- 1
5
2005
- 8- 1
6
2005
- 8- 1
7
2005
- 8- 1
8
2005
- 8- 1
9
2005
- 8- 2
0
2005
- 8- 2
1
2005
- 8- 2
2
2005
- 8- 2
3
2005
- 8- 2
4
2005
- 8- 2
5
2005
- 8- 2
6
80%82%84%86%88%90%92%94%96%
RRC SETUP FAI LURES RRC SETUP SUCCESS RATE
RRC Setup statistics
From the figure above, it was shown that RRC setup failures decreased from 288 to 158 and RRC setup success rate increased from 87% to 94%.
If increase FACH power, then it will decrease the RRC setup failure due to UU no reply.
Increase FACH power to improve RRC setup success rate
Increasing FACH Power 2dB
For internal use15 © Nokia Siemens Networks Charles / 2009-05-05 Page 15
Case 1: Increase the PCPICH Power to improve the coverage
Case 2: Increase DL maximum power of AMR to improve call drop rate
Case 3: Increase FACH power to improve RRC setup success rate
Case 4: Optimize the timer T300 to improve RRC success Rate
Case 5: UE cannot access due to cell radius settings
Coverage parameters optimization cases
For internal use16 © Nokia Siemens Networks Charles / 2009-05-05 Page 16
Optimize the timer T300 to improve RRC success Rate
NameMinimum Clusters Before Switch
Requirement C1 C2 C3 C4 C5 C6 C7 C8 Whole City
RRC Connection Requests - SUM
in the trend 4561743 5478662 6165218 5232258 8830561 5000059 6445880 478572 42221482
RRC Connection Requests - RAB
in the trend 1867148 2311263 1574192 2193172 2590867 2084147 1937424 55085 14630080
RRC Connection Requests - IRAT Cell Reselection
in the trend 1496278 1256319 950827 883108 1001577 891959 1169277 3379317992077
RRC Failure Rate - SUM (%)
"=< 10%" 0.75% 0.63% 1.01% 0.78% 0.70% 0.75% 0.90% 0.95%0.79%
RRC Failure Rate was 0.79% before the swap, but it increased to 1.32 % after swap. The KPI is worse than before.
Name
Minimum Clusters After Switch - Weekly KPI ( HUAWEI)
Requirement C1 C2 C3 C4 C5 C6 C7 C8 City Level
RRC Connection Requests - SUM
in the trend 6255259 6380468 5064183 5298305 7093489 4868310 5521603 0 40370612
RRC Connection Requests - RAB
in the trend 2048127 2398928 1653128 2357844 2749713 2208816 2354256 0 15707398
RRC Connection Requests - IRAT Cell Reselection
in the trend 1386870 1317011 1127359 1013396 1004143 890266 1425679 0 8146314
RRC Failure Rate - SUM (%)
"=< 10%" 1.36% 1.08% 1.85% 1.07% 1.25% 1.09% 1.59%0.00%
1.32%
For internal use17 © Nokia Siemens Networks Charles / 2009-05-05 Page 17
Optimize the timer T300 to improve RRC success Rate Usually the RRC setup success rate for other services is about 97%~99% in Huawei commercial
network. But the KPI acceptance is requested for 99.2% in this network.
RRC setup failure mainly is due to RNC doesn’t receive the RRC_CONNECTION_SETUP_CMP from UE through statistics. And most of reason is RRC no reply for register and inter-Rat cell reselect.
1. RRC no reply for register is about 48%, and RRC no reply for inter-Rat cell reselect is 26%.
2. We increased the FACH power offset from 1dB to 1.5dB, the RRC setup failure rate decreased 0.13%.
3. Modified the N300 from 3 to 4, and RRC setup failure rate improved a little.
For internal use18 © Nokia Siemens Networks Charles / 2009-05-05 Page 18
Optimize the timer T300 to improve RRC success Rate
1. Modified the T300 from 2s to 0.4s on 20th March. And the RRC setup success rate improved from 98.9% to 99.3%.
2. RRC setup failure rate is about 0.73% in the acceptance test.
RRC Fai l ure Rate - SUM (%)
0. 0%
0. 2%
0. 4%
0. 6%
0. 8%
1. 0%
1. 2%
13: 00 14: 00 15: 00 16: 00 17: 00 18: 00 19: 00 20: 00
RRC Fai l ure Rate - SUM (%)
1. RNC will repeat to send RRC_CONN_SETUP message to UE 2 times in each TTI in spite of receiving the RRC_CONN_SETUP_CMP message or not for another vendor. Huawei RNC does not support this function. RRC_CONN_SETUP message will repeat to send after T300 expires.
2. Why the RRC setup success rate was improved after the T300 was shortened?
a) It is due to the RRC_CONN_SETUP message is repeated to send to UE in a short time before UE fails to access and reselect to another cell.
b) If the UE fails to access due to poor coverage, it will reselect to another cell and access again. This access is measured another access and the denominator is increased in the KPI formula.
Notes:T300 is started when UE sends the RRC CONNECTION REQUEST message. It is stopped when UE receives the RRC CONNECTION SETUP message. RRC CONNECTION REQUEST will be resent upon the expiry of the timer if V300 is lower than or equal to N300, else enter idle mode. Recommended value: D2000.
For internal use19 © Nokia Siemens Networks Charles / 2009-05-05 Page 19
Case 1: Increase the PCPICH Power to improve the coverage
Case 2: Increase DL maximum power of AMR to improve call drop rate
Case 3: Increase FACH power to improve RRC setup success rate
Case 4: Optimize the timer T300 to improve RRC success Rate
Case 5: UE cannot access due to cell radius settings
Coverage parameters optimization cases
For internal use20 © Nokia Siemens Networks Charles / 2009-05-05 Page 20
UE cannot access due to cell radius settingsUE cannot access due to cell radius settings
RSCP is -72dBm,EcIo is -2dB
PSC304
Why does
access fail ?
PSC304
11.3km cover
the sea.
RNC didn’t receive the RRC Setup Request signaling because the cell radius is set 10KM and UE accessed far from 11.3km.
The command modified the cell radius is as following:
MOD LOCELL: LOCELL=12111, RADIUS=30000
For internal use21 © Nokia Siemens Networks Charles / 2009-05-05 Page 21
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use22 © Nokia Siemens Networks Charles / 2009-05-05 Page 22
Parameter Name
Description Default Setting
IntraRelThdFor1A Relative thresholds of soft handover for Event 1A (R1a)
6 , namely 3dB (step 0.5)
IntraRelThdFor1B Relative thresholds of soft handover for Event 1B (R1b)
12 , namely 6dB (step 0.5)
Hystfor1A, Hystfor1B, Hystfor1C, Hystfor1D
Soft handover hysteresis (H1x) 0dB for H1a, H1b .8,namely 4dB(step 0.5) for H1c,H1d.
CIOOFFSET Neighboring cell oriented Cell Individual Offset (CIO)
0
TrigTime1A,TrigTime1B, TrigTime1C,TrigTime1D
Soft handover time-to-trigger parameters. 320ms for 1A, 640ms for 1B, 1C,1D
FilterCoef Filter coefficient of L3 intra-frequency measurement
D3 ,namely 3
1A (Add a cell in Active Set)
)2/(10)1(1010 111
aaBest
N
iiNewNew HRLogMWMLogWCIOLogM
A
MNew : the measurement result of the cell entering the reporting range.CIONew : the individual cell offset for the cell entering the reporting range.Mi : measurement result of a cell not forbidden to affect reporting range in the active set.NA : the number of cells not forbidden to affect reporting range in the current active set.MBest : the measurement result of the cell not forbidden to affect reporting range in the active set with the highest measurement result, not taking into account any cell individual offset.W : a parameter sent from UTRAN to UE.R1a : the reporting range constant.H1a : the hysteresis parameter for the event 1a.
The soft handover parameters being tuned frequently
For internal use23 © Nokia Siemens Networks Charles / 2009-05-05 Page 23
Case 1: Parameters optimization for corner effect case
Case 2: Parameters optimization for handover area being small
Case 3: Ping-Pong handover optimization case
Case 4: Parameters optimization for handover not in time when taking the elevator
Case 5: Handover Failure due to the improper cell radius
Intra frequency handover parameters optimization cases
For internal use24 © Nokia Siemens Networks Charles / 2009-05-05 Page 24
Parameters optimization for corner effect case Parameters optimization for corner effect case
Call droppedProblem Description:
Call drops often occur at the corner.
At the corner, the service cell signals quickly decrease, the target cell signals quickly increase in a short time, and the UE fails to receive the ASU command, which leads to the call drop.
For internal use25 © Nokia Siemens Networks Charles / 2009-05-05 Page 25
·PSC265
The cell PSC265, the distance is 6.5km, using the Yagi antenna.
PSC304
PSC265
The cell PSC304, the distance is 11km, using the Yagi antenna.
Parameters tuning
① The CIO between PSC265 and PSC304 is modified 10( 5dB);
② The delay of 1A event, modify from 320ms to100ms;③ Increase the PCPICH power of PSC265 and PSC304 3dB, to improve the coverage.
The result
① The call drop reduce after the parameters tuning.
Parameters optimization for corner effect case Parameters optimization for corner effect case
For internal use26 © Nokia Siemens Networks Charles / 2009-05-05 Page 26
The coverage comparing of different operator at the cornerThe coverage comparing of different operator at the corner
H 3G SMT 3G
C 3G S 3G (Huawei)
For internal use27 © Nokia Siemens Networks Charles / 2009-05-05 Page 27
Case 1: Parameters optimization for corner effect case
Case 2: Parameters optimization for handover area being small
Case 3: Ping-Pong handover optimization case
Case 4: Parameters optimization for handover not in time when taking the elevator
Case 5: Handover Failure due to the improper cell radius
Intra frequency handover parameters optimization cases
For internal use28 © Nokia Siemens Networks Charles / 2009-05-05 Page 28
Parameters optimization for handover area being small
2.9km
1.0km
4.2km
5.7km
<=200k
m/h
<=300k
m/h
<=400km/h
<=431km/h
<=100km/h
The call dropped place
The sites distribution for Maglev train
The speed distribution
The maglev train test network;
The maximum speed is 431km/h;
Sometimes call drop due to the handover area is small.
For internal use29 © Nokia Siemens Networks Charles / 2009-05-05 Page 29
Poor coverage
The call dropped
The RSCP in the maglev train
Out of coverage
The signaling handover between PSC180 and PSC170
Parameters optimization for handover area being small
For internal use30 © Nokia Siemens Networks Charles / 2009-05-05 Page 30
Simulation of handover area :① Andrew-UMWD-03319-0DM, gain is 20.6dBi, downtilt is 2 degrees. According to simulation the
handover is only 28m ;② Increase the CIO between Cell1 and Cell2 5dB, the handover area is 98m according to simulation
The speed and handover:Generally the handover delay is about 200 ~ 600ms, UE measurement the neighbor cell need some time, suppose the handover 800ms, so the speed and handover relation is as follows:
UE Speed (km/h) 100 200 300 400
Handover area (m) 22 44 66 88
How to modify the parameters of handover① CIO between PSC180 and PSC170 change to
10( 5dB);② Reduce TrigTime1A from 320ms to 100ms;③ IntraRelThdFor1ACS change from 3dB to 5.5dB;④ IntraRelThdFor1BCS change from 6dB to 8dB;⑤ IntraFreqFilterCoef change from D3 to D2.
Result after the parameters tuninga) The call dropped times reduce, but we still find call
dropped in this area.b) At last we use the splitting the sector.
Cell1 Cell2
CIO
),2/(10)1(1010 111
aaBest
N
iiNewNew HRLogMWMLogWCIOLogM
A
Parameters optimization for handover area being small
For internal use31 © Nokia Siemens Networks Charles / 2009-05-05 Page 31
Case 1: Parameters optimization for corner effect case
Case 2: Parameters optimization for handover area being small
Case 3: Ping-Pong handover optimization case
Case 4: Parameters optimization for handover not in time when taking the elevator
Case 5: Handover Failure due to the improper cell radius
Intra frequency handover parameters optimization cases
For internal use32 © Nokia Siemens Networks Charles / 2009-05-05 Page 32
Ping-Pong handover
The active set cell change frequently between the same cells.
Before call dropped the signal of SC56 is below -
18dB, so the SC56 was deleted from active set, the
active set is left SC64 and SC66, but the two cells
became so worse in a short time. So the call dropped.
SC64/66 signal become so worse in a short time
Ping-Pong handover optimization case
How to decrease Ping-Pong handover ?
This can enlarge intra-frequency measurement coefficient and time to trigger.
For internal use33 © Nokia Siemens Networks Charles / 2009-05-05 Page 33
The cell SC 56 was deleted from active set.
Delete the cell SC56
The cell of SC64/66 became so worse in
a short time
Report 1A event of SC56
The UE reported the 1A event of cell SC 56.
The method of Ping-Pong handover.① Parameters tuning
a) Increase the TrigTime1B from 640ms to 1280ms or 2560ms. b) IntraRelThdFor1BCS change from 6dB to 8dB;c) IntraFreqFilterCoef change from D3 to D4.
② RF tuning
Ping-Pong handover optimization case
For internal use34 © Nokia Siemens Networks Charles / 2009-05-05 Page 34
Case 1: Parameters optimization for corner effect case
Case 2: Parameters optimization for handover area being small
Case 3: Ping-Pong handover optimization case
Case 4: Parameters optimization for handover not in time when taking the
elevator
Case 5: Handover Failure due to the improper cell radius
Intra frequency handover parameters optimization cases
For internal use35 © Nokia Siemens Networks Charles / 2009-05-05 Page 35
Problem description:
① There is a DAS in 13th floor and
1th floor in one building by cell A,
and no coverage for the elevator. So
the elevator is covered by outdoor
cell B.
② It often call drop when enter or out elevator in the 1th floor.
Elevator and indoor coverage sketch map
电梯
Indoor Cell A (13F)
Cell A (1F)
B
Outdoor Cell B
Handover not in time when taking the elevatorHandover not in time when taking the elevator
Elevator
For internal use36 © Nokia Siemens Networks Charles / 2009-05-05 Page 36
The EcIo change so fast when the door of elevator is closed or opened.
Solutions:① CIO between cell A and cell B change to 10( 5dB);② Reduce TrigTime1A from 320ms to 0ms;③ IntraFreqFilterCoef change from D3 to D1.④ RF tuning, using the indoor coverage system to cover the
elevator.
Cell ACell B
Open the
door Close the
door
The red EcIo is covered by indoor cell A, and green EcIo is covered by outdoor cell B. When the door is opened, the signal
of cell A is very strong, so the EcIo of cell B become -20dB immediately in the active set. If the cell A is not added into active in time, it will call drop.
The signal of cell A become so worse when the door is closed, and the signal of cell B become very strong immediately. If the cell B is not added into active in time, it will also call drop.
From the signaling, you can find that UE has already reported 1A event, but UE call drop before receiving the ASU message.
Handover not in time when taking the elevatorHandover not in time when taking the elevator
For internal use37 © Nokia Siemens Networks Charles / 2009-05-05 Page 37
Case 1: Parameters optimization for corner effect case
Case 2: Parameters optimization for handover area being small
Case 3: Ping-Pong handover optimization case
Case 4: Parameters optimization for handover not in time when taking the elevator
Case 5: Handover Failure due to the improper cell handover radius
Intra frequency handover parameters optimization cases
For internal use38 © Nokia Siemens Networks Charles / 2009-05-05 Page 38
Handover Failure due to the improper cell handover radius
Call drop area
Call drop area
At the call drop spot, the radio environment is good. By the drive test, before and after the call drop, both Ec/Io and RSCP are good. The call drop always occurs during each drive test and the call drop spot is similar.
UE transmit power is
increased before call drop.
SC192 Ec/IoSC176 Ec/Io
UE TxPWR
Analysis of call drop point
For internal use39 © Nokia Siemens Networks Charles / 2009-05-05 Page 39
The newly added radio link is not synchronized, and ASU is delivered to delete the scrambles of cell 176 from the active set. The quality of scrambles in cell 192 is bad, so the call drop occurs. The uplink asynchronization may be caused by the following:
Uplink interference --- check the RTWP of cell 176
Parameter setting problem - LST LOCELL
Through the RTWP tracing, the RTWP of the cell is about -105 dBm. Check the cell handover radius and find that the inner diameter of handover radius is 5000m. The configuration is abnormal. It indicates that UE cannot perform the handover within 5000 m. The parameter is set to 0m by default.
Problem troubleshooting
Fixing
Change the handover radius to 0. And the call drop disappears.
Local Cell Inner Handover Radius (m): The inner handover radius of the local cell must not be greater than cell radius.MOD LOCELL: LOCELL=11111, HORAD=0;
Handover Failure due to the improper cell handover radius
For internal use40 © Nokia Siemens Networks Charles / 2009-05-05 Page 40
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use41 © Nokia Siemens Networks Charles / 2009-05-05 Page 41
Case 1: The parameters optimization for pingpong Inter-RAT cell reselection in
idle state
Case 2: Parameters optimization case of Inter-RAT handover not in time into tunnel
Case 3: The case for CS Inter-RAT Preparation handover failure
Case 4: Inter-RAT PS handover Failed due to 2G Cell Barred
Case 5: Inter-RAT PS handover Failed due to DNS settings in SGSN
Inter-RAT handover parameters optimization cases
For internal use42 © Nokia Siemens Networks Charles / 2009-05-05 Page 42
The parameters optimization for pingpong Inter-RAT cell reselection in idle state The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Problem description:
UE change to camp in 3G or 2G so frequently in idle state in one building.
RSCP EcIo
For internal use43 © Nokia Siemens Networks Charles / 2009-05-05 Page 43
The cell reselection parameters of 3G to 2G is as following:① Min quality level : Qqualmin = -18 (-18dB)② Min Rx level: Qrxlevmin = -58 (-115dBm)③ Inter-RAT cell reselection threshold: SsearchRAT = 2
(Qqualmin+2*SsearchRAT=-14dB)
The cell reselection parameters of 2G to 3G is as following:① Inter-RAT measurement start threshold: Qsearch_I = 7 (Always search for 3G cells)
② Cell reselection offset: FDD_Qoffset = 0 (-∞, always select to a cell if acceptable) FDD_Qoffset : 0 = - (always select a cell if acceptable),1 = -28 dB, 2 = -24 dB, … , 8 = 0dB ,
9 = 4 dB, … , 15 = 28 dB.
③ Cell reselection 3G RX level threshold: FDD_Qmin = 0 (-20dB) FDD_Qmin : 0= -20dB, 1= -6dB, 2= -18dB, 3= -8dB, 4= -16dB, 5= -10dB, 6= -14dB, 7= -12dB.
• When the EcIo of 3G is lower than -14dB, UE will start to measure the GSM signal and maybe reselect to 2G.
• UE will always measure the 3G signal in 2G network. And if the EcIo of 3G is higher than -20dB, UE will reselect to 3G in spite of the 2G coverage.
• When the EcIo of 3G changes between -14dB to -20dB, UE will reselect between 3G and 2G frequently.
The parameters optimization for pingpong Inter-RAT cell reselection in idle state The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Solutions:
Increase the FDD_Qmin from -20dB to -10dB. Usually we suggest the value is 7 (-12dB).
For internal use44 © Nokia Siemens Networks Charles / 2009-05-05 Page 44
1. If Sx > Sintrasearch, UE need not perform intra-frequency measurements. If Sx <= Sintrasearch, perform intra-frequency measurements.If Sintrasearch, is not sent for serving cell, perform intra-frequency measurements.
2. If Sx > Sintersearch, UE need not perform inter-frequency measurements.If Sx <= Sintersearch, perform inter-frequency measurements.If Sintersearch, is not sent for serving cell, perform inter-frequency measurements.
3. If Sx > SsearchRAT, UE need not perform measurements on cells of RAT. If Sx <= SsearchRAT, perform measurements on cells of RAT.If SsearchRAT, is not sent for serving cell, perform measurements on cells of RAT.
Sx=Squalmeas - Qqualmin
The parameters optimization for pingpong Inter-RAT cell reselection in idle state The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Qqualmin Minimum required quality level corresponding to the CPICH Ec/No. UE can camp on the cell only when the CPICH Ec/No measured is larger than the value of this parameter. Recommended value: -18(dB).
Qrxlevmin Minimum required RX level corresponding to the CPICH RSCP. UE can camp on the cell only when the measured CPICH RSCP is larger than the value of this parameter. Recommended value: -58.
IdleSintrasearch Threshold for intra-frequency cell reselection in idle mode. When the quality (CPICH Ec/No measured by the UE) of the serving cell is lower than this threshold plus the [Qqualmin] of the cell, the intra-frequency cell reselection procedure will be started.
IdleSintersearch Threshold for inter-frequency cell reselection in idle mode. When the quality (CPICH Ec/No measured by UE) of the serving cell is lower than this threshold plus the [Qqualmin] of the cell, the inter-frequency cell reselection procedure will be started.
Ssearch.RAT Threshold for inter-RAT cell reselection. When the quality (CPICH Ec/No measured by UE) of the serving cell is lower than the threshold plus the minimum required quality ( Qqualmin) of the cell, the inter-RAT cell reselection procedure will be started. It's mandatory When the value of parameter SsearchratInd is TRUE. Recommended value: 2, step is 2dB.
For internal use45 © Nokia Siemens Networks Charles / 2009-05-05 Page 45
Case 1: The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Case 2: Parameters optimization case of Inter-RAT handover not in time into
tunnel
Case 3: The case for CS Inter-RAT Preparation handover failure
Case 4: Inter-RAT PS handover Failed due to 2G Cell Barred
Case 5: Inter-RAT PS handover Failed due to DNS settings in SGSN
Inter-RAT handover parameters optimization cases
For internal use46 © Nokia Siemens Networks Charles / 2009-05-05 Page 46
Optimization case of Inter-RAT handover not in time into tunnelOptimization case of Inter-RAT handover not in time into tunnel
Inter-RAT handover area
Inter-RAT handover not in time
Tunnel
CellIdTime(As object
distinct)
VS.IRATHO.FailOutCS
IRATHO.SuccOutCS
VS.CS.Call.Drop.Cell
RAT HHO SUCC RATE
54493 2006-2-6 to 2-12 62 315 251 80%
Problem description: The cell 54493 cover outer
tunnel and no UMTS coverage in the tunnel.
There are 2G coverage in the tunnel.
The inter-RAT handover success rate is not high from the cell 54493 to 2G.
The inter-RAT handover data is as following table in one week. And the success rate is about 80%.
Modified the InterRATCSThd2DRSCP from -95dBm to -85dBm, and UE will report 2D event in advance in order to the inter-RAT handover is in time.
It is suggested that the InterRATFilterCoef is reduced from the D3 to D2.
The inter-RAT handover parameters optimization include: 2D & 2F Event threshold, GSM RSSI threshold, Inter-RAT handover trigger time, inter-RAT measurement filter coefficient, CIO and hysteresis.
For internal use47 © Nokia Siemens Networks Charles / 2009-05-05 Page 47
Case 1: The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Case 2: Parameters optimization case of Inter-RAT handover not in time into tunnel
Case 3: The case for CS Inter-RAT Preparation handover failure
Case 4: Inter-RAT PS handover Failed due to 2G Cell Barred
Case 5: Inter-RAT PS handover Failed due to DNS settings in SGSN
Inter-RAT handover parameters optimization cases
For internal use48 © Nokia Siemens Networks Charles / 2009-05-05 Page 48
The case for CS Inter-RAT Preparation handover failureThe case for CS Inter-RAT Preparation handover failureFrom May 25th, the CS Inter-RAT Handover Preparation Success Ratio of RNC 321 decreased greatly, and continued, the Handover Execution Success Ratio also dropped.
Do the IOS trace, the failure always happen after the RNC send message RELOCATION_REQUIRED to CN, and the CN return the RELOCATION_PREPARATION_FAILURE, and the failure reason is Semantic error, which is shown below:
The detail information of the RELOCATION_PREPARATION_FAILURE is as following.
According to the 3GPP 25.413, This is a Protocol Cause that means that " The received message included a semantic error." so, the information contained within the message is not valid.
For internal use49 © Nokia Siemens Networks Charles / 2009-05-05 Page 49
0
1000
2000
3000
4000
5000
6000
7000
5-30
1:0
0
5-30
6:0
0
5-30
11:
00
5-30
16:
00
5-30
21:
00
5-31
2:0
0
5-31
7:0
0
5-31
12:
00
5-31
17:
00
5-31
22:
00
6-1
3:00
6-1
8:00
6-1
13:0
0
6-1
18:0
0
6-1
23:0
0
6-2
4:00
6-2
9:00
6-2
14:0
0
6-2
19:0
0
6-3
0:00
6-3
5:00
6-3
10:0
0
6-3
15:0
0
6-3
20:0
0
0.00%
20.00%
40.00%
60.00%
80.00%
100.00%
120.00%
VS. SRELOC. At tPrep. I RHOCS VS. SRELOC. SuccPrep. I RHOCS
VS. SRELOC. SuccPrep. I RHOCS. Rate
0
1000
2000
3000
4000
5000
6000
7000
5-30
1: 0
0
5-30
6: 0
0
5-30
11:
00
5-30
16:
00
5-30
21:
00
5-31
2: 0
0
5-31
7: 0
0
5-31
12:
00
5-31
17:
00
5-31
22:
00
6-1
3:00
6-1
8:00
6-1
13: 0
0
6-1
18: 0
0
6-1
23: 0
0
6-2
4:00
6-2
9:00
6-2
14: 0
0
6-2
19: 0
0
6-3
0:00
6-3
5:00
6-3
10: 0
0
6-3
15: 0
0
6-3
20: 0
0
60.00%
65.00%
70.00%
75.00%
80.00%
85.00%
90.00%
95.00%
100.00%
VS. I RATHO. At tCSOut . RNC VS. I RATHO. SuccCSOut . RNC VS. I RATHO. SuccCSOut . RNC. Rate
From the message analysis, if the parameter is wrong configured, the LAC maybe wrong, check the 2G LAC information, really many inconsistent LAC information, after modified the LAC information, the CS inter RAT preparation handover success rate is normal, which is shown below:
At the same time the CS inter RAT handover success rate is also increase much.
the LAC information should be consistent in RNC, CN and BSC, or else, one of them is insistent, the inter-RAT handover will fail.
The case for CS Inter-RAT Preparation handover failureThe case for CS Inter-RAT Preparation handover failure
For internal use50 © Nokia Siemens Networks Charles / 2009-05-05 Page 50
Case 1: The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Case 2: Parameters optimization case of Inter-RAT handover not in time into tunnel
Case 3: The case for CS Inter-RAT Preparation handover failure
Case 4: Inter-RAT PS handover Failed due to 2G Cell Barred
Case 5: Inter-RAT PS handover Failed due to DNS settings in SGSN
Inter-RAT handover parameters optimization cases
For internal use51 © Nokia Siemens Networks Charles / 2009-05-05 Page 51
The PS inter-RAT handover success rate decreased from 88% to 78% at one day.
The following table shows TOP 10 cells for PS I-RAT handover failure and the reason for one whole day.
Inter-RAT PS handover Failed due to 2G Cell Barred
Cell Id DateVS.IRATHO.FailOutPS
UTRAN.CellVS.IRATHO.AttOutPSU
TRANIRATHO.FailOutPSUT
RAN.CfgUnsuppIRATHO.FailOutPSUT
RAN.PhyChFailVS.IRATHO.FailOutPS
UTRAN.Other
37141 2008-10-28 230 232 0 230 0
36746 2008-10-28 29 38 0 7 22
36135 2008-10-28 24 54 0 20 4
37006 2008-10-28 20 28 0 20 0
37212 2008-10-28 15 47 0 10 5
36889 2008-10-28 10 33 0 1 9
36767 2008-10-28 7 21 0 1 6
37007 2008-10-28 7 15 0 5 2
36559 2008-10-28 6 22 0 6 0
37079 2008-10-28 6 38 0 2 4
CellGSMCe
llTime(As
day)VS.IRATHO.AttOu
tPSUTRAN.NVS.IRATHO.SuccOutPSUTRAN.N
VS.IRATHO.FaiOutPSUTRAN.
UEFN
37141 16156 2008-10-28 123 0 123
37141 16159 2008-10-28 55 0 55
37141 16157 2008-10-28 52 0 52
For internal use52 © Nokia Siemens Networks Charles / 2009-05-05 Page 52
PS IRAT failure is due to the GSM cell 16156 was
barred.
InterRAT PS handover Failed due to 2G Cell Barred
For internal use53 © Nokia Siemens Networks Charles / 2009-05-05 Page 53
The PS inter-RAT handover success rate increased from 78% to 88% after the 2G neighbor cells were deleted.
InterRAT PS handover Failed due to 2G Cell Barred
Because the cell was barred only for GPRS, we should modify the GSM cells type RatCellType from GPRS to GSM, it means these cells not configuration for PS handover to GSM. It had better not delete the CS neighobor cell, otherwise it affects the CS handover.The command modified the GSM type is as following:MOD GSMCELL: GSMCellIndex=16156, RatCellType=GSM, SuppPSHOFlag=FALSE;MOD GSMCELL: GSMCellIndex=16157, RatCellType=GSM, SuppPSHOFlag=FALSE;MOD GSMCELL: GSMCellIndex=16159, RatCellType=GSM, SuppPSHOFlag=FALSE;
For internal use54 © Nokia Siemens Networks Charles / 2009-05-05 Page 54
Case 1: The parameters optimization for pingpong Inter-RAT cell reselection in idle state
Case 2: Parameters optimization case of Inter-RAT handover not in time into tunnel
Case 3: The case for CS Inter-RAT Preparation handover failure
Case 4: Inter-RAT PS handover Failed due to 2G Cell Barred
Case 5: Inter-RAT PS handover Failed due to DNS settings in SGSN
Inter-RAT handover parameters optimization cases
For internal use55 © Nokia Siemens Networks Charles / 2009-05-05 Page 55
The following table shows the one day PS inter-RAT attempts and PS service inter-RAT handover success rate in one week, the PS inter-RAT handover success rate is only 85%, it is lower than acceptance target 90%.
Inter-RAT PS handover Failed due to DNS settings in SGSN
RNCName Time(As day) PS.IRATHO.Attempts.RNC PS.IRATHO.Success rate.RNC Physical Channel Fail PS.IRATHO. Fail No replyRNC:1 2008-10-19 3037 85.61% 272 105RNC:1 2008-10-20 3210 87.35% 249 97RNC:1 2008-10-21 2741 86.72% 214 85RNC:1 2008-10-22 2438 87.33% 209 40RNC:3 2008-10-19 3228 81.66% 268 175RNC:3 2008-10-20 3649 81.97% 278 218RNC:3 2008-10-21 3550 82.54% 278 189
From the signaling, you can find that after RNC decides to handover from 3G to 2G and send Cell_Change_Order_From_UTRAN to UE, others procedures are not related to RNC anymore.And RNC just waits for the IU_Release_Command from SGSN.
For internal use56 © Nokia Siemens Networks Charles / 2009-05-05 Page 56
Abnormal Routing area update and attach from 2G side caused the failure of the
PS I-RAT.
Inter-RAT PS handover Failed due to DNS settings in SGSN
For internal use57 © Nokia Siemens Networks Charles / 2009-05-05 Page 57
LAC RACVS.IRATHO.SuccOutPSUNTRAN.Cell.
Rate
Physical channel failure Rate in PS HO
Failure reason
Other reasons (mainly due to IU release timer
expiry ) RateRouting Area Update after PS IRAT HO
5636 199 95.02% 62.50% 37.50% RAU Accept.
5536 198 92.02% 83.53% 16.47% RAU Accept.
6036 111 79.38% 28.57% 71.43% RAU Reject due to implicitly detached.
1538 113 89.43% 35.14% 64.86% RAU Reject due to implicitly detached.
1338 204 89.08% 30.77% 69.23% RAU Reject due to implicitly detached.
1138 202 88.55% 51.67% 48.33% RAU Reject due to implicitly detached.
1738 115 86.60% 78.57% 21.43% RAU Reject due to implicitly detached.
1238 203 86.19% 50.00% 50.00% RAU Reject due to implicitly detached.
1038 201 84.94% 31.25% 68.75% RAU Reject due to implicitly detached.
5836 109 82.74% 39.69% 60.31% RAU Reject due to implicitly detached.
1438 112 81.42% 23.53% 76.47% RAU Reject due to implicitly detached.
1838 116 73.33% 17.50% 82.50% RAU Reject due to implicitly detached.
Check the RAC in SGSN, and find some RAN not configured in the DNS table in SGSN.
1. The direct cause of the PS Inter-RAT failure is no reply from SGSN before the timer expire.
2. When UE handover to 2G the routing area update request is rejected by CN. The failure of the routing area update from 2G side will delay the SGSN sending the “IU release message” to RNC to confirm the handover is completed. So if RNC does not received this message from SGSN before the timer expire, RNC will count the PS IRAT fail due to no reply from SGSN.
3. From the test, we found many cases that SGSN sends the “IU release Message” to RNC when the routing area update rejected, but the release reason is normal release. In this case RNC will count the handover as a success one. This is the SGSN problem.
Inter-RAT PS handover Failed due to DNS settings in SGSN
For internal use58 © Nokia Siemens Networks Charles / 2009-05-05 Page 58
PS I RAT 3G to 2G Handover Success Rate
75.00%
80.00%
85.00%
90.00%
95.00%
100.00%
2008
-9-1
2008
-9-4
2008
-9-7
2008
-9-1
0
2008
-9-1
3
2008
-9-1
6
2008
-9-1
9
2008
-9-2
2
2008
-9-2
5
2008
-9-2
8
2008
-10-
1
2008
-10-
4
2008
-10-
7
2008
-10-
10
2008
-10-
13
2008
-10-
16
2008
-10-
19
2008
-10-
22
2008
-10-
25
2008
-10-
28
2008
-10-
31
2008
-11-
3
2008
-11-
6
2008
-11-
9
2008
-11-
12
2008
-11-
15
2008
-11-
18
2008
-11-
21
2008
-11-
24
2008
-11-
27
2008
-11-
30
Date
PS
IRA
T H
O S
R
3G & 3G+ to 2G Handover Success Rate - All data Services
Change the DNS configuration in SGSN
The PS inter-RAT handover success rate improved from 86% to 93% after CN changed the DNS configuration in SGSN
Inter-RAT PS handover Failed due to DNS settings in SGSN
For internal use59 © Nokia Siemens Networks Charles / 2009-05-05 Page 59
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use60 © Nokia Siemens Networks Charles / 2009-05-05 Page 60
Case 1: AMR Call Drop Rate Increase Due to T313 tuning
Case 2: SRB parameters optimization to improve CS call drop rate
CS call drop rate optimization cases
For internal use61 © Nokia Siemens Networks Charles / 2009-05-05 Page 61
AMR Call Drop Rate Increase Due to T313 tuningProblem description:
T313 was changed from 3s to 5s to expect to reduce the call drop rate in one commercial network. UEs were expected to report RL failure later to reduce the call drop rate. However, the AMR call drop rate was increased by 0.07%.
It seemed that it was normal fluctuation (modified on April 21 and restored on April 24).AMR call drop rate
0.27%
0.33% 0.35% 0.35%0.31% 0.29%
0.00%0.05%0.10%0.15%0.20%0.25%0.30%0.35%0.40%
April 2
0, 2
008
April 2
1, 2
008
April 2
2, 2
008
April 2
3, 2
008
April 2
4, 2
008
April 2
5, 2
008
010002000300040005000600070008000900010000
VS.RAB.Loss.CS.AMR.12.2 VS.CS.AMR.Call.Drop.Cell.Rate
Call re-establishment success analysis
5255
2478 2291 2287
5332
3764
0100020003000400050006000
April 2
0, 2
008
April 2
1, 2
008
April 2
2, 2
008
April 2
3, 2
008
April 2
4, 2
008
April 2
5, 2
008
55.00%60.00%65.00%70.00%75.00%80.00%
RRC.AttConnReEstab.RFLoss RRC.SuccConnReEstab
ReEst Succ Rate
1. When RL failure were reported later, the call re-establishment procedure was affected since the re-establishment function was enabled (T314=20s). The call re-establishment times and call success ratio of the cells of RNC62 is as upper figure.
2. The call re-establishment times ware reduced to half, which lead to increase of the call drop rate. The success ratio of call re-establishment was decreased after the parameter T313 was modified. It was due to the re-establishment link quality was reduced due to the delay. And the call re-establishment times was greatly reduced.
T313 changed
from 3s to 5s
Notes:
T313 is started after the UE detects consecutive N313 "out of sync" indications from L1. T313 is stopped after the UE detects consecutive N315 "in sync" indications from L1.It indicates Radio Link (RL) failure upon expiry.
For internal use62 © Nokia Siemens Networks Charles / 2009-05-05 Page 62
AMR Call Drop Rate Increase Due to T3131. We analyzed the settings of timers and call drop distribution information. The causes of new call drops were
UU no Replay and lost synchronization of uplink. The procedures before UU No Reply were soft handover procedures.
2. The timer for soft handover was 5s (HOASUTMR=5000). The timer for lost synchronization of uplink was 5s (TRLFAILURE=50). Both of the two timers expired, so the system did not re-establish the call when RL failure messages were received. The call drop was incurred.
AMR Call Drop
0
1000
2000
3000
4000
5000
6000
VS.RAB.Loss.CS.RF.ULSync VS.RAB.Loss.CS.SRBReset VS.RAB.Loss.CS.RF.UuNoReply
a) After T313 was changed from 3s to 5s, because the timer for soft handover was 5s and the timer for lost synchronization of uplink was 5s, the call drop was incurred when one of these timers was triggered (50% of the probability). The call re-establishment was not performed instead.
b) At last, we restored the timer T313 from 5s to 3s.
For internal use63 © Nokia Siemens Networks Charles / 2009-05-05 Page 63
Case 1: AMR Call Drop Rate Increase Due to T313 tuning
Case 2: SRB parameters optimization to improve CS call drop rate
CS call drop rate optimization cases
For internal use64 © Nokia Siemens Networks Charles / 2009-05-05 Page 64
SRB parameters optimization to improve CS call drop rateSRB parameters optimization to improve CS call drop rate
Problem description:
In one commercial network, the CS call drop is about 1.5%. Usually the CS call drop is lower than 1%.
And most of call drop is due to ASU expire. And in all call drop, this reason is about 70%.
Date RNC ID CS call drop rate
2006-2-6 1 1.61%2006-2-7 1 1.65%2006-2-8 1 1.68%2006-2-9 1 1.60%
2006-2-10 1 1.50%2006-2-11 1 1.40%2006-2-12 1 1.40%2006-2-13 1 1.53%2006-2-14 1 1.54%2006-2-15 1 1.54%2006-2-16 1 1.52%
For internal use65 © Nokia Siemens Networks Charles / 2009-05-05 Page 65
Before Optimization After Optimization
Date RNC ID CS call drop rate Date RNC ID CS call drop rate
2006-2-6 1 1.61% 2006-2-17 1 1.23%2006-2-7 1 1.65% 2006-2-18 1 1.13%2006-2-8 1 1.68% 2006-2-19 1 1.13%2006-2-9 1 1.60% 2006-2-20 1 1.29%
2006-2-10 1 1.50% 2006-2-21 1 1.33%2006-2-11 1 1.40% 2006-2-22 1 1.38%2006-2-12 1 1.40% 2006-2-23 1 1.37%2006-2-13 1 1.53% 2006-2-24 1 1.23%2006-2-14 1 1.54% 2006-2-25 1 1.21%2006-2-15 1 1.54% 2006-2-26 1 1.16%2006-2-16 1 1.52% 2006-2-27 1 1.36%
2006-2-28 1 1.35%2006-3-1 1 1.35%2006-3-2 1 1.21%
Name Description Default Value
Optimization value
T313 T313 is started after the UE detects consecutive N313 "out of sync" indications from L1. T313 is stopped after the UE detects consecutive N315 "in sync" indications from L1.It indicates Radio Link (RL) failure upon expiry.
3s 5s
N313 Physical value range: 1, 2, 4, 10, 20, 50, 100, 200.Maximum number of successive "out of sync" indications received from L1.
50 100
SRB parameters optimization to improve CS call drop rateSRB parameters optimization to improve CS call drop rate
The AMR call drop decrease from 1.50% to 1.2% after the parameters.
For internal use66 © Nokia Siemens Networks Charles / 2009-05-05 Page 66
Name Description Default Value Optimization value
HOASUTMR Physical unit: ms. A timer to RNC wait for the response to active set update in soft handover procedure.
5000 9000
RLRSTRTMR Physical unit: ms. A timer to RNC wait for radio link restoration indication in the radio link procedure.
5000 9000
T313 T313 is started after the UE detects consecutive N313 "out of sync" indications from L1. T313 is stopped after the UE detects consecutive N315 "in sync" indications from L1.It indicates Radio Link (RL) failure upon expiry.
5 7
NODISCARDMAXDAT
Maximum number of transmissions of a PDU before an AM RLC entity, whose [AM RLC discard mode selection] is set to NO_DISCARD, is reset When the mode is set to NO_DISCARD, the RLC entity will be directly reset if the number of retransmissions of a PDU reaches the value defined by this parameter. This parameter can be set large, if the target BLER of the transmission channel is high.
30 40The maximum time for SRB reset is NODISCARDMAXDAT*TIMERPOLL=40*200ms=8s.
The AMR call drop decrease from 1.20% to 1% after the parameters.
Before Optimization After OptimizationDate RNC ID CS call drop rate Date RNC ID CS call drop rate
2006-2-20 1 1.29% 2006-3-3 1 1.00%2006-2-21 1 1.33% 2006-3-4 1 0.92%2006-2-22 1 1.38% 2006-3-5 1 0.96%2006-2-23 1 1.37% 2006-3-6 1 1.03%2006-2-24 1 1.23% 2006-3-7 1 1.03%2006-2-25 1 1.21% 2006-3-8 1 1.05%2006-2-26 1 1.16% 2006-3-9 1 1.03%2006-2-27 1 1.36% 2006-3-10 1 1.00%2006-2-28 1 1.35% 2006-3-11 1 0.90%2006-3-1 1 1.35% 2006-3-12 1 0.91%2006-3-2 1 1.21%
SRB parameters optimization to improve CS call drop rateSRB parameters optimization to improve CS call drop rate
For internal use67 © Nokia Siemens Networks Charles / 2009-05-05 Page 67
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use68 © Nokia Siemens Networks Charles / 2009-05-05 Page 68
The Case of High PS Call Drop due to PSInactTimer Improper Setting
Two RNCs’ PS call drop rate are very different. The traffic statistics of last week is as following:
RNC1: 19.4%(462/2381), the PS CDR is very high.
RNC2: 0.7%(414/58907), normal.
The PS call drop times of the 2 RNCs are almost equivalent, but the PS service attempted times are quite different, RNC1 has much less PS service times.
Check the PS throughput of the two RNCs is almost same.
RNC Id
VS.PSLoad.ULThruput.RNC(GBytes)
VS.PSLoad.DLThruput.RNC(GBytes)
1 12.76 48.63
2 8.12 56.18
RNC Id
TimeVS.PS.Call.Drop.
RNC
VS.PS.RABRelease.R
NC
VS.PS.Call.Drop.RNC.
Rate
1 2008-12-30 66 303 21.78%
1 2008-12-31 49 277 17.69%
1 2009-01-01 52 298 17.45%
1 2009-01-02 76 407 18.67%
1 2009-01-03 62 323 19.20%
1 2009-01-04 68 312 21.79%
1 2009-01-05 89 463 19.22%
RNC Id
TimeVS.PS.Call.Drop.RNC
VS.PS.RABRelease.RNC
VS.PS.Call.Drop.RNC.Rate
2 2008-12-30 67 6505 1.03%
2 2008-12-31 69 8519 0.81%
2 2009-01-01 50 7813 0.64%
2 2009-01-02 54 8852 0.61%
2 2009-01-03 67 8375 0.80%
2 2009-01-04 61 11091 0.55%
2 2009-01-05 46 7931 0.58%
The PS throughput of the two RNCs is very close. Why the PS service attempted times has so large discrepancy?
For internal use69 © Nokia Siemens Networks Charles / 2009-05-05 Page 69
High PS Call Drop due to PSInactTimer Improper Setting
After the modification, the PS call drop is normal. When PSInactTimer is set 20s, it only affect the PS service attempted times and the denominator increases, but the call drop does not decrease in fact.
RNC Id Time(As hour)VS.PS.Call.Drop.RNC
VS.PS.Call.Drop.RNC.Rate
1 2009-01-09 13:00 4 0.66%
1 2009-01-09 14:00 6 1.18%
1 2009-01-09 15:00 9 1.44%
1 2009-01-09 16:00 1 0.18%
1 2009-01-09 17:00 4 0.84%
1 2009-01-09 18:00 7 1.13%
1 2009-01-09 19:00 4 0.61%
1 2009-01-09 20:00 2 0.35%
1 2009-01-09 21:00 4 0.87%
1 2009-01-09 22:00 6 1.42%
The PSInactTimer is set as following in RNC2:SET PSINACTTIMER: PsInactTmrForInt=20,
ProtectTmrForInt=20, PsInactTmrForBac=20, ProtectTmrForBac=20, PSInactTmrForImsSig=20, ProtectTmrForImsSig=20;
But the PSInactTimer is set 0 in RNC1 :LST PSINACTTIMER: PsInactTmrForInt=0,
ProtectTmrForInt=0, PsInactTmrForBac=0, ProtectTmrForBac=0, PSInactTmrForImsSig=0, ProtectTmrForImsSig=0;
1. If PsInactTimer=0, that means the PS permanent online function is switched off. If one user establishes the PS service successfully, he will occupy the resources all the time, till normal release or call drop.
2. And if PsInactTimer is not equivalent to 0, that means after a PS service established successfully, when no data traffic after a specified period, the Access Stratum resources will be released, only the PDP Context is retained. Then when the data traffic requirement is appeared, the network will establish the connection again.
3. Thus the PS service attempted times will increase and the call drop rate will decrease, also the network resource is saved.
4. After the modification, the PS call drop is normal.
For internal use70 © Nokia Siemens Networks Charles / 2009-05-05 Page 70
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. CS call drop rate optimization cases
5. PS call drop rate optimization cases
6. Access control parameters optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use71 © Nokia Siemens Networks Charles / 2009-05-05 Page 71
Case 1: The access failure due to the power congestion
Case 2: CS RAB Assignment failure due not to configure ATM route in IU interface
Case 3: PS RAB Setup Failures due not to IP Address configured in RNC
Access control parameters optimization cases
For internal use72 © Nokia Siemens Networks Charles / 2009-05-05 Page 72
The access failure due to the power congestionThe access failure due to the power congestion
Problem description:
There were two UE test for PS384K service in drive test.
One of UEs received RRC Connection Abnormal Release and access failed at 21:01:12 .
From the trace in RNC, RNC sent the RANAP_IU_Release_Request to CN and the cause is Request maximum bit rat for DL not available.
For internal use73 © Nokia Siemens Networks Charles / 2009-05-05 Page 73
1. Firstly we checked the code, CE and IUB resource, it is available.2. Then we checked the power resource.
a) The maximum power of the cell is 10w(40dBm);b) Checked the switch of DCCC, it was closed.
SET CORRMALGOSWITCH:CHSWITCH = DCCC_SWITCH-0;c) Checked the switch of CAC, it was algorithm 1, and the DL threshold of CAC
for PS is 75%. ADD CELLCAC:CELLID = 28, CELLENVTYPE = TU, NONORTHOFACTOR = 400,
DLCONVAMRTHD = 80, DLCONVNONAMRTHD = 80, DLOTHERTHD = 75, DLHOTHD = 85, DLCCHLOADRSRVCOEFF = 0, DLINTERFACTOR = 60, DLTOTALEQUSERNUM = 50;
d) Checked the TCP for downlink in the RNC trace as following.
The access failure due to the power congestionThe access failure due to the power congestion
a) The TCPs for two UE are 38.7dBm(7.4W) and 39.95dBm(9.9W). The offset is 3dB between TCP and the pilot power.
b) The traffic power for UE1 is 38.7-3=35.7dBm(3.7W). And the traffic power for UE2 is 39.95-3=36.95dBm(4.95W) before access failed.
For internal use74 © Nokia Siemens Networks Charles / 2009-05-05 Page 74
1. Usually the power for common channel is 20% in total power in a cell. So it is 2w.2. And the total used power was P= 3.7+4.95+2=10.65(w). And the maximum power
for the cell is 10w.3. So it was power congestion. Usually it is due to the poor coverage and you can
find the RSCP is about -111dBm during the access failure.
The access failure due to the power congestionThe access failure due to the power congestion
RSCP is -111dBm.
Suggestions:a) To enhance the power for this cell from 10w to 20w or more. b) To improve the coverage by RF tuning. c) Set RAB_DOWNSIZING_SWITCH and DCCC_SWITCH to access more users.
For internal use75 © Nokia Siemens Networks Charles / 2009-05-05 Page 75
Case 1: The access failure due to the power congestion
Case 2: CS RAB Assignment failure due not to configure ATM route in IU
interface
Case 3: PS RAB Setup Failures due not to IP Address configured in RNC
Access control parameters optimization cases
For internal use76 © Nokia Siemens Networks Charles / 2009-05-05 Page 76
CS RAB Assignment failure due not to configure ATM route in IU interface
CS RAB assignment success rate decreased in RNC121. Most of reason is due to VS.RAB.FailEst.CS.TNL in the statistics. And this failure was not found in the before and it is occupied 20% in all failure.
The RAB assignment failure of TNL is due to AAL2 setup failure in IU interface from CHR as following table.
CURRENT TIME
FAULT TYPEBEST CELLID
INTERFACE FAULT REASON
DETAILED FAULT REASON
06:54:15(88) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:54:24(92) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:54:30(68) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:54:39(87) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:56:25(50) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:58:25(72) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:58:37(21) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
06:58:46(46) RAB ASSIGNMENT REQ FAULT 121:19355 AAL2 FAILURE IU LOCAL AL SETUP FAIL
For internal use77 © Nokia Siemens Networks Charles / 2009-05-05 Page 77
From the trace, RNC sent the RAB_ASSIGNMENT_RESP message to CN, and the failure is due to IU transport connection failed to establish.
The transport layer address is 0x45000034901706104F0000000000000000000000 in message RAB_ASSIGNMEN_REQ from CN.
AAL2RT
NSAP RTX OWNERSHIP ANI
0x45000034901706103F0000000000000000000000 1 YES 1
0x45000034901706101F0000000000000000000000 2 NO 1
0x45000034901706102F0000000000000000000000 3 NO 1
0x45000034901706501F0000000000000000000000 4 NO 1
0x45000034901706502F0000000000000000000000 5 NO 1
0x45000034901706503F0000000000000000000000 6 NO 1
Check the IU interface of AAL2RT configured in RNC, the ATM route didn’t find. So if the address is assigned by CN in RAB assignment, it will all fail.
We asked the customers, they added a new MGM, but they did not tell us to add a new ATM route. So many RAB assignment failed for CS services.
And, the problem was solved after the address of 0x45000034901706104F0000000000000000000000 is added in RNC.
CS RAB Assignment failure due not to configure ATM route in IU interface
For internal use78 © Nokia Siemens Networks Charles / 2009-05-05 Page 78
Case 1: The access failure due to the power congestion
Case 2: CS RAB Assignment failure due not to configure ATM route in IU interface
Case 3: PS RAB Setup Failures due not to IP Address configured in RNC
Access control parameters optimization cases
For internal use79 © Nokia Siemens Networks Charles / 2009-05-05 Page 79
PS RAB Setup Failures due not to IP Address configured in RNC•In recent 3 days, PS RAB Setup Success rate degraded from about 99.50% to about 95% or less. As most of the PS service are setup on HSDPA service, it cause HSDPA CSSR and HSUPA CSSR worse than before too.
•The main reason of the Rab CSSR degradation is due to the TNL(Transmission Network Layer) problem which means that the RAB CSSR degradation is related to the transmission system of the IUPS between RNC and SGSN.
There are 13 IPPATHs between Huawei RNC and SGSN:192.168.13.9192.168.13.2192.168.13.3192.168.13.4192.168.13.5192.168.13.7192.168.13.8192.168.13.110.16.9.13310.16.9.19710.16.10.510.16.8.5
For internal use80 © Nokia Siemens Networks Charles / 2009-05-05 Page 80
Here there is an IP Address 192.168.13.6 not configured ,but assigned by SGSN. The IP address is not configured in RNC
PS RAB Setup Failures due not to IP Address configured in RNC
For internal use81 © Nokia Siemens Networks Charles / 2009-05-05 Page 81
Action taken:
1. Added IP address 192.168.13.6 at 17:10 on Feb.4th afternoon.
2. PS RAB Setup Success was normal after IP address being added.
PS RAB Setup Failures due not to IP Address configured in RNC
For internal use82 © Nokia Siemens Networks Charles / 2009-05-05 Page 82
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. Access control parameters optimization cases
5. CS call drop rate optimization cases
6. PS call drop rate optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use83 © Nokia Siemens Networks Charles / 2009-05-05 Page 83
BLER Optimization for CS
Higher layer RAB/Signalling RB RAB subflow #1 RAB subflow #2 RAB subflow #3
RLC Logical channel type DTCH
RLC mode TM TM TM
Payload sizes, bit 0,39,81 103 60
Max data rate, bps 12 200
TrD PDU header, bit 0
MAC MAC header, bit 0
MAC multiplexing N/A
Layer 1 TrCH type DCH DCH DCH
TB sizes, bit 0,39,81 103 60
TFS (note 1)
TF0, bits 1x0 (note 2) 0x103 0x60
TF1, bits 1x39 1x103 1x60
TF2, bits 1x81 N/A N/A
TTI, ms 20 20 20
Coding type CC 1/3 CC 1/3 CC 1/2
CRC, bit 12 N/A N/A
Max number of bits/TTI after channel coding
303 333 136
RM attribute 180 to 220 170 to 210 215 to 256
What is the meaning of BLER?BLER means Block Error Rate and it defines the ratio of the incorrectly received transport blocks to the total number of received transport blocks.
Transport channel parameters for AMR 12.2 kbps from 3GPP TS 34.108 V8.1.0 are in the following table.
a) TTI (transmission timing interval) is 20ms for AMR, and the transport format is 81x1. It means 1 block is transported and each block is 81 bits in 20ms. It is at most 50 blocks in 1s. If only 1 block is error in 1s, the BLER is 2%.
b) For the uplink, we get a BLER sample about each 640ms from the RNC. So it is transmitted about 32 blocks in 640ms. If only 1 block is error in 640ms, the BLER is 3.12%.
Only 1 block is error
The BLER target of the AMR (uplink and downlink) <= 2% in 97% samples in one commercial network.And it is very difficult to get the KPI target.
For internal use84 © Nokia Siemens Networks Charles / 2009-05-05 Page 84
BLER and EcIo distribution in Cluster8 in Quito
Checking the BLER error distribution in the Cluster8, you can find that the BLER error in most of cases is due to the poor coverage in the edge of cluster. In the central cluster, it is good coverage, so no BLER is error.
If we improve the coverage, at the same time the BLER will be improved.
EcIo BLER
For internal use85 © Nokia Siemens Networks Charles / 2009-05-05 Page 85
Parameters optimization of BLER Type Parameter Name Default value Optimized
valueComments
AMR SIRADJUSTSTEP 5(0.005dB) 3(0.003dB) Step of target SIR adjustment in outer loop power control algorithm.Video phone SIRADJUSTSTEP 2(0.002dB) 1(0.001dB)
AMR BLERQuality 1% 0.50% It is used by CRNC to decide the target SIR value that influences access and power control. The formula of BLER is the 10*Lg(BLER).
Video phone BLERQuality 0.20% 0.10%
AMR RlMaxDlPwr(dB) 0 1 The maximum and minimum downlink transmit power of radio link. AMR RlMinDlPwr(dB) -15 -14
Video phone RlMaxDlPwr(dB) 3 4 The maximum and minimum downlink transmit power of radio link. Video phone RlMinDlPwr(dB) -12 -11
The test result of BLER in Quito:
A. The BLER is worse in dense urban than in suburban because it is less than pilot pollution in suburban than in dense urban and urban.
B. When the EcIo, Pilot Pollution and coverage are improved the BLER will be improved at the same time.
Type( BLER target 97% )
BLER(Cluster2) BLER(Cluster3) BLER(Cluster6)
BLER(Cluster7)
BLER(Cluster8)
BLER(Cluster9)
AMR BLER (DL) <= 2% 99.44% 98.39% 99.80% 99.32% 99.29% 99.28%
AMR BLER (UL) <= 2% 94.78% 94.76% 92.05% 89.20% 90.25% 93.23%
VPBLER (DL) <= 1% 98.33% 95.08% 97.12% 97.83% 96.20% 96.76%
VP BLER (UL) <= 1% 97.56% 96.95% 97.31% 97.94% 97.52% 97.04%
For internal use86 © Nokia Siemens Networks Charles / 2009-05-05 Page 86
Radio Parameters Optimization Cases
1. Coverage parameters optimization cases
2. Intra frequency handover parameters
optimization cases
3. Inter-RAT handover parameters optimization
cases
4. Access control parameters optimization cases
5. CS call drop rate optimization cases
6. PS call drop rate optimization cases
7. BLER parameters optimization cases
8. Soft handover ratio optimization cases
For internal use87 © Nokia Siemens Networks Charles / 2009-05-05 Page 87
Soft handover ratio mapping for swap network
In one swap commercial network in Europe , the soft handover ratio is less than 15% than before.
We find that the formula to calculate the soft handover ratio is same between the two vendors.
The another vendor is 1001]3[uPALSS]2[uPALSS]1[uPALSS
3]3[uPALSS2]2[uPALSS]1[uPALSS_
RatioSHO
SHO_Ratio = 100*{[VS.SHO.AS.1 + (VS.SHO.AS.2Softer +VS.SHO.AS.2Soft)*2+ (VS.SHO.AS.3Softer+ VS.SHO.AS.3Soft+ VS.SHO.AS.3Soft2Softer)*3)] /( VS.SHO.AS.1 + VS.SHO.AS.2Softer + VS.SHO.AS.2Soft + VS.SHO.AS.3Softer + VS.SHO.AS.3Soft +VS.SHO.AS.3Soft2Softer )-1}
The Huawei formula is
But the counter is different between the two vendors.
The counter for another vendor is based on cell level and radio link is measured in all active set, but for Huawei it is based on RNC level and it does not measure in soft state.
So the RL is measured repeatedly for cell level, and the custom should be modify the formula for soft handover ratio as following.
1001)3/]3[uPALSS2/]2[uPALSS]1[(uPALSS
]3[uPALSS]2[uPALSS]1[uPALSS_
RNC celle
RNC celle
RatioSHO
100%1C1B1A1
3C12B11A1SHR
•Reference Name •Associated Counters •Specification
•A1: NumberOfUEWith1RL VS.SHO.AS.1 Average Number of UEs with One RL
•B1: NumberOfUEWith2RL VS.SHO.AS.2Softer, VS.SHO.AS.2Soft Average Number of UEs with Two RLs Combined or Uncombined.
•C1: NumberOfUEWith3RLVS.SHO.AS.3Soft2Softer Average Number of UEs with Three RLs and Two Combined
VS.SHO.AS.3Soft, VS.SHO.AS.3Softer Average Number of UEs with Three RLs Uncombined or Combined.
For internal use88 © Nokia Siemens Networks Charles / 2009-05-05 Page 88
Many factors impact the soft handover ratio, including the following items:a) Soft handover parameter settings;b) Network topology, site distribution, cell radius;c) The antenna pattern;d) Path loss;
The soft handover parameter settings and site distribution have more impact on the soft handover ratio.
Commercial network
1RL probability
2RL probability
3RL probability
Soft handover ratio(statistics)
Soft handover Ratio(Drive test )
United Arab Emirates
0.68 0.22 0.10 42.38% 32.24%
Brunei 0.59 0.30 0.11 51.85% 40.81%
Hong Kong RNC1 0.56 0.30 0.14 58.09% 43.76%
Hong Kong RNC2 0.56 0.28 0.15 58.97% 43.61%
Hong Kong RNC3 0.54 0.29 0.16 62.20% 45.76%
Hong Kong RNC4 0.62 0.26 0.12 50.18% 38.17%
Quito 0.68 0.24 0.08 40.61% 32.89% (Average)
We check the soft handover ratio in the commercial network of Huawei. It shows the probability of one RL (radio link), two RLs and three RLs in the United Arab Emirates, Brunei, Hong Kong, and Quito.
Soft handover ratio mapping for swap network
Top Related