(Huawei) WCDMA Radio Parameters Optimization Cases

10/31/15
WCDMA Radio Parameters

Optimization Cases
For internal use

1
Nokia Siemens Networks
Charles / 2009-05-05
Parameters Optimization Flow Chart

Parameters
Optimization
start
Configuration
data
collection
Signaling
trace data
collection
Drive test data

collection
KPI is
OK?
Statistics data
collection
NO
Parameters tuning
Data analysis and

optimization
YES
Parameters
optimization
ends.
For internal use
2
Charles / 2009-05-05
Page 2
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 use

3
Charles / 2009-05-05
Page 3
The coverage parameters being tuned

frequently
Coverage Parameters:
No
.
1
2
3
4
5
6
Parameters
Name
RLMaxDLPwr
RLMinDLPwr
MaxTxPower
PCPICHPower
MaxPCPICHPowe
r
MinPCPICHPower
RADIUS
For internal use

4
Charles / 2009-05-05
Description
Default value
RL Max DL TX power[0.1dB]
RL Min DL TX power[0.1dB]
Max transmit power of cell[0.1dBm]
PCPICH transmit power[0.1dBm]
Max transmit power of PCPICH[0.1dBm]
0 for AMR
-150(-15dB) for AMR
430 (43dBm)
330 (33dBm)
346 (34.6dBm)
Min transmit power of PCPICH[0.1dBm]

Local Cell Radius(m). This is a parameter in
NodeB.
313 (31.3dBm)
30000 (30km)
Page 4

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
For internal use

5
Charles / 2009-05-05
Page 5
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
For internal use

6
Charles / 2009-05-05
Suggest a
new site
Page 6
Increase the PCPICH Power to improve the

coverage
RSCP Before increasing

Pcpich Power
RSCP after Increasing

Pcpich Power 3dB
EcIo Before increasing

Pcpich Power
EcIo 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;
For internal use

7
Charles / 2009-05-05
Page 7

Case 2: Increase DL maximum power of AMR to improve call drop

rate
For internal use

8
Charles / 2009-05-05
Page 8
Increase DL maximum power of AMR to improve call

drop rate
Call drop
increasing
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.
For internal use

9
Charles / 2009-05-05
Page 9

drop rate
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.
The maximum DL DCH power of S AMR service is 36dBm as following table.
For internal use

10
Charles / 2009-05-05
Page 10

drop rate
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;
Mod Power for AMR
CS12.2 CS64
PS32 PS64
PS144 PS256 PS384
Default 0
value
+3
-4
-2
+0
+2
+4
HK
+1
-4
+2
+2
+3
UAE
-3
+3
-4
-2
+2
+4
NL
-3
+1
-4
+1
+2
+3
For internal use

11
Charles / 2009-05-05
Page 11


For internal use

12
Charles / 2009-05-05
Page 12
Increase FACH power to improve RRC setup success

rate
From KPI in last few months, there were some RRC setup failures. It was mainly caused during reselection and
registration.
Signaling for RRC Setup
RRC Setup Failure Distribution

UE
40000
35000
30000
25000
20000
15000
10000
5000
0
NodeB
RNC
100%
98%
96%
1. CCCH:
RRC CONNECTION REQUEST
RRC
RRC
94%
2 . Allocate parameters
Such as RNTI, L1,L2
92%
90%
88%
86%
Orignating
Terminating
RRC Setup Failure
NBAP
3. RADIO LINK SETUP REQUEST

NBAP
NBAP
4. RADIO LINK SETUP RESPONSE

NBAP
Reselection Registration
RRC Setup Success Rate
5. ALCAP
Setup and Synchronization
6.CCCH RRC CONNECTION SETUP

RRC
RRC
7.DCCH
RRC CONNECTION SETUP COMPLETE
RRC
RRC
RRC setup failure for poor coverage

RNC 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 use
13
Charles / 2009-05-05
Page 13
Increase FACH power to improve RRC setup success

rate
1.
Optimize MAXFACHPOWER.
The value is maximum transmit power of FACH,
and its -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 itll influence
DCH: 0.25*(10^ ((34-43)/10)-10^ ((3243)/10)) =1.16%
This impact is acceptant because live
network is limited by coverage.
RRC Setup statistics

Increasing FACH
Power 2dB
RRC SETUP
350
300
250
200
150
100
50
0
96%
94%
92%
90%
88%
86%
84%
82%
80%
RRC SETUP FAILURES
RRC SETUP SUCCESS RATE
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.
For internal use

14
Charles / 2009-05-05
Page 14


For internal use

15
Charles / 2009-05-05
Page 15
Optimize the timer T300 to improve RRC success

RRCRate
Failure Rate was 0.79% before the swap, but it increased to 1.32 after swap. The KPI is worse than
before.
Name
Clusters Before Switch
Minimum
Requirement
C1
C2
C3
C4
C5
C6
C7
C8
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
337931
"=< 10%"
0.75%
0.63%
1.01%
0.78%
0.70%
0.75%
0.90%
0.95%
RRC Failure
Rate
- SUM (%)
7992077
0.79%
Clusters After Switch - Weekly KPI HUAWEI
Minimum
Name
Whole City
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
40370612
RRC Connection
Requests - RAB
in the trend
2048127
2398928
1653128
2357844
2749713
2208816
2354256
15707398
RRC Connection
Requests - IRAT
Cell Reselection
in the trend
1386870
1317011
1127359
1013396
1004143
890266
1425679
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 use

16
Charles / 2009-05-05
Page 16
Usually the RRC setup success rate for other services is about 97%~99% in Huawei commercial
Rate
network. But the KPI acceptance is requested for 99.2% in this network.
RRC setup failure mainly is due to RNC doesnt 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 use

17
Charles / 2009-05-05
Page 17
1.
2.

Modified the T300 from 2s to 0.4s on 20th March. And the RRC setup success rate improved from
Rate
98.9% to 99.3%.
RRC setup failure rate is about 0.73% in the acceptance test.
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.
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.
For internal use

18
Charles / 2009-05-05
Page 18

Case 5:
For internal use

19
UE cannot access due to cell radius settings
Charles / 2009-05-05
Page 19
UE cannot access due to cell radius

settingsis -2dB
RSCP is -72dBm,EcIo
Why
does
access
fail
11.3km
cover
the sea.
PSC304
PSC304
RNC didnt 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 use

20
Charles / 2009-05-05
Page 20

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

21
Charles / 2009-05-05
Page 21
The soft handover parameters being tuned

frequentlyDescription
Parameter
Default Setting
Name
IntraRelThdFor1A
Relative thresholds of soft handover for Event

1A (R1a)
IntraRelThdFor1B
Relative thresholds of soft handover for Event
1B (R1b)
Hystfor1A, Hystfor1B, Soft handover hysteresis (H1x)
Hystfor1C, Hystfor1D
CIOOFFSET
Neighboring cell oriented Cell Individual Offset

(CIO)
Soft handover time-to-trigger parameters.
TrigTime1A,TrigTime1
B, 1A (Add a cell in Active Set)
NA
TrigTime1C,TrigTime1
D
New
New
i
FilterCoef
Filter coefficient of L3i intra-frequency
1
10 LogM
CIO
6 , namely 3dB (step 0.5)

12 , namely 6dB (step 0.5)
0dB for H1a, H1b .
8,namely 4dB(step 0.5) for
H1c,H1d.
0
320ms for 1A, 640ms for 1B, 1C,1D
M
(1 W ) 10 LogM
Best ( R1a H 1a / 2)
D3 ,namely 3
W 10 Log
measurement
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.
For internal use

22
Charles / 2009-05-05
Page 22

optimization cases
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
For internal use

23
Charles / 2009-05-05
Page 23
Parameters optimization for corner

effect case
Problem Description:
Call dropped
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 use

24
Charles / 2009-05-05
Page 24
Parameters optimization for corner

effect case
The cell PSC265, the distance is 6.5km, using
the Yagi antenna.
The cell PSC304, the distance is 11km, using the

Yagi antenna.
PSC265
PSC265
PSC304
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.
For internal use

25
Charles / 2009-05-05
Page 25
The coverage comparing of different operator at the

corner
H 3G
SMT 3G
C 3G
For internal use

26
Charles / 2009-05-05
S 3G (Huawei)
Page 26

optimization cases

For internal use

27
Charles / 2009-05-05
Page 27
Parameters optimization for handover area being

small
The sites distribution for Maglev train
The maglev train test

network;
The maximum speed is

431km/h;
Sometimes call drop

due to the handover
area is small.
2.9km
1.0km
4.2km
5.7km
The speed distribution
The call
dropped place
<=100km
/h
0
<=2
m/h
For internal use

28
0k
k
00
3
<= h
m/
Charles / 2009-05-05
<=400km/h
<=431km/h
Page 28

small
The RSCP in the maglev train
The call
dropped
Poor
coverage
For internal use

29
Out of
coverage
Charles / 2009-05-05
The signaling handover between

PSC180 and PSC170
Page 29

small
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);
Cell1
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 tuning

CIO
a)
The call dropped times reduce, but we still find call
N
dropped in this area.

10 LogM New CIONew W 10 Log M i
i 1
b)
At last we use the splitting the sector.
A
For internal use

30
Charles / 2009-05-05
Cell2
(1 W ) 10 LogM Best ( R1a H1a / 2),
Page 30

optimization cases

For internal use

31
Charles / 2009-05-05
Page 31
Ping-Pong handover optimization case
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
How to decrease Ping-Pong handover ?

This can enlarge intra-frequency
measurement coefficient and time to
trigger.
For internal use

32
Charles / 2009-05-05
Page 32
Ping-Pong handover optimization case
The cell SC 56 was deleted from active

set.
The UE reported the 1A event of cell SC

56.
The cell of SC64/66
became so worse in
a short time
Delete the
cell SC56
Report 1A
event of SC56
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)
RF tuning
For internal use
33
Charles / 2009-05-05
Page 33

optimization cases
Case 4: Parameters optimization for handover not in time when taking the
elevator
For internal use

34
Charles / 2009-05-05
Page 34
Handover not in time when taking the

elevator
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.
Elevator and indoor coverage

sketch map
Outdoor Cell B
Elevator
It often call drop when enter or

out elevator in the 1th floor.
Indoor Cell A (13F)
Cell A
(1F)
For internal use

35
Charles / 2009-05-05
Page 35
Handover not in time when taking the

elevator
The EcIo change so fast when the door of elevator is closed or opened.
The red EcIo is covered by indoor cell A,

and green EcIo is covered by outdoor cell
Cell B
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.
Open
The signal of cell A become so worse

the
Close
when the door is closed, and the
door
the
signal of cell B become very strong
door
immediately. If the cell B is not added
into active in time, it will also call
drop.
From the signaling, you can find that

Solutions:
UE has already reported 1A event,
CIO between cell A and cell B change tobut

10(UE
5dB);
call drop before receiving the
Reduce TrigTime1A from 320ms to 0ms;ASU message.
RF tuning, using the indoor coverage system to cover the

elevator.
Cell A
For internal use

36
Charles / 2009-05-05
Page 36

optimization cases
Case 5: Handover Failure due to the improper cell handover radius
For internal use

37
Charles / 2009-05-05
Page 37
Handover Failure due to the improper cell handover

radius
Analysis of call drop point
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.
SC176 Ec/Io
UE transmit
power is
increased before
call drop.
For internal use

38
Call
drop
area
Call
drop
area
SC192 Ec/Io
UE TxPWR
Charles / 2009-05-05
Page 38
Handover Failure due to the improper cell handover

radius Problem troubleshooting
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.
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;
For internal use
39
Charles / 2009-05-05
Page 39

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

40
Charles / 2009-05-05
Page 40

cases
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
For internal use

41
Charles / 2009-05-05
Page 41
The parameters optimization for pingpong InterRAT cell reselection in idle state
UE change to camp in 3G or 2G so frequently in idle state in one building.
RSCP
For internal use

42
Charles / 2009-05-05
EcIo
Page 42
The cell reselection parameters of 3G to 2G is as following:
Qqualmin = -18 (-18dB)

Min Rx level: Qrxlevmin = -58 (-115dBm)
Inter-RAT cell reselection threshold: SsearchRAT = 2
(Qqualmin+2*SsearchRAT=-14dB)
Min quality level :
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.
Solutions:
Increase the FDD_Qmin from -20dB to -10dB. Usually we suggest the value is 7 (12dB).
For internal use
43
Charles / 2009-05-05
Page 43
1.
2.
3.
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.
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.
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
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 use

44
Charles / 2009-05-05
Page 44

cases
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
For internal use

45
Charles / 2009-05-05
Page 45
Optimization case of Inter-RAT handover not in time into

The cell 54493 cover outer
tunnel
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
Modified
the
80%.
InterRATCSThd2DRSCP
from
Inter-RAT handover
not in time
Inter-RAT
handover area
Tunnel
-95dBm to -85dBm, and UE

will report 2D event in
advance in order to the interRAT 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, InterRAT handover trigger time, inter-RAT
measurement filter coefficient, CIO
and hysteresis.
For internal use

46
Charles / 2009-05-05
CellId
Time(As object
distinct)
VS.IRA
THO.Fa
ilOutCS
IRATH
O.Succ
OutCS
VS.CS.
Call.Dr
op.Cell
RAT
HHO
SUCC
RATE
54493
2006-2-6 to 2-12
62
315
251
80%
Page 46

cases
For internal use

47
Charles / 2009-05-05
Page 47
The case for CS Inter-RAT Preparation handover

failure
From May 25th, the CS Inter-RAT Handover Preparation Success Ratio of RNC 321
decreased greatly, and continued, the Handover Execution Success Ratio also dropped.
The detail information of the

RELOCATION_PREPARATION_FAILURE is as following.
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:
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 use
48
Charles / 2009-05-05
Page 48
The case for CS Inter-RAT Preparation handover

failure
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.
For internal use
49
Charles / 2009-05-05
Page 49

cases
For internal use

50
Charles / 2009-05-05
Page 50
Inter-RAT PS handover Failed due to 2G Cell

Barred
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.
VS.IRATHO.Fai
OutPSUTRAN.
UEFN
Cell
GSMCe
ll
Time(As
day)
37141
16156
2008-10-28
123
123
37141
16159
2008-10-28
55
55
37141
16157
2008-10-28
52
52
VS.IRATHO.FailOutPS VS.IRATHO.AttOutPSU IRATHO.FailOutPSUT

UTRAN.Cell
TRAN
RAN.CfgUnsupp
VS.IRATHO.AttOu VS.IRATHO.Succ
tPSUTRAN.N
OutPSUTRAN.N
IRATHO.FailOutPSUT
RAN.PhyChFail
VS.IRATHO.FailOutPS
UTRAN.Other
230
38
22
24
54
20
2008-10-28
20
28
20
37212
2008-10-28
15
47
10
36889
2008-10-28
10
33
36767
2008-10-28
21
37007
2008-10-28
15
36559
2008-10-28
22
37079
2008-10-28
38
Cell Id
Date
37141
2008-10-28
230
232
36746
2008-10-28
29
36135
2008-10-28
37006
For internal use

51
Charles / 2009-05-05
Page 51
InterRAT PS handover Failed due to 2G Cell

Barred
PS IRAT failure is due to the GSM cell 16156 was

For internal use
52
barred.
Charles / 2009-05-05
Page 52
InterRAT PS handover Failed due to 2G Cell

Barred
The PS inter-RAT handover success rate increased from 78% to 88% after the 2G neighbor cells were deleted.
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;
For internal use
53
Charles / 2009-05-05
Page 53

cases
For internal use

54
Charles / 2009-05-05
Page 54
Inter-RAT PS handover Failed due to DNS settings in

The
following table shows the one day PS inter-RAT attempts and PS service inter-RAT handover success
SGSN
rate in one week, the PS inter-RAT handover success rate is only 85%, it is lower than acceptance target
90%.
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 use
55
Charles / 2009-05-05
Page 55

SGSN
Abnormal Routing area update and attach from 2G side caused the failure of the
PS I-RAT.
For internal use
56
Charles / 2009-05-05
Page 56

1.
The direct cause of the PS Inter-RAT failure is no reply from SGSN before the timer expire.
SGSN
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.
VS.IRATHO.SuccO Physical channel
Other reasons (mainly
utPSUNTRAN.Cell. failure Rate in PS HO due to IU release timer Routing Area Update after PS IRAT HO
Rate
Failure reason
expiry ) Rate
LAC
RAC
5636
5536
6036
199
198
111
95.02%
92.02%
79.38%
62.50%
83.53%
28.57%
37.50%
16.47%
71.43%
RAU Accept.
RAU Accept.
RAU Reject due to implicitly detached.
1538
113
89.43%
35.14%
64.86%
1338
204
89.08%
30.77%
69.23%
1138
202
88.55%
51.67%
48.33%
1738
1238
115
203
86.60%
86.19%
78.57%
50.00%
21.43%
50.00%

1038
201
84.94%
31.25%
68.75%
5836
1438
109
112
82.74%
81.42%
39.69%
23.53%
60.31%
76.47%

1838
116
73.33%
17.50%
82.50%
Check the RAC in SGSN, and find some RAN not configured in the DNS table in SGSN.
For internal use
57
Charles / 2009-05-05
Page 57

SGSN
The PS inter-RAT handover success rate improved from 86% to 93% after CN
changed the DNS configuration in SGSN
Change the DNS

configuration in SGSN
For internal use

58
Charles / 2009-05-05
Page 58

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

59
Charles / 2009-05-05
Page 59

Case 1: AMR Call Drop Rate Increase Due to T313 tuning
Case 2: SRB parameters optimization to improve CS call drop rate
For internal use

60
Charles / 2009-05-05
Page 60
AMR Call Drop Rate Increase Due to T313

tuning
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).
T313
changed
0.40%
from 3s to 5s
0.35%
0.30%
0.25%
0.20%
0.15%
0.10%
0.05%
0.00%
Call re-establishment success analysis
AMR call drop rate
0.33%
0.35%
0.35%
0.27%
0.31%
10000
9000
8000
0.29% 7000
6000
5000
4000
3000
2000
1000
0
6000
5000
4000
3000
2000
1000
0
5332
5255
3764
2478
2291
RRC.AttConnReEstab.RFLoss
VS.RAB.Loss.CS.AMR.12.2
1.
VS.CS.AMR.Call.Drop.Cell.Rate
2287
80.00%
75.00%
70.00%
65.00%
60.00%
55.00%
RRC.SuccConnReEstab
ReEst Succ Rate
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.
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 use

61
Charles / 2009-05-05
Page 61
AMR Call Drop Rate Increase Due to T313

1.
2.
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.
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
600
0
500
400
0
300
0
200
0
100
0
0
0
VS.RAB.Loss.CS.RF.ULSync
a)
b)
VS.RAB.Loss.CS.SRBReset
VS.RAB.Loss.CS.RF.UuNoReply
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.
At last, we restored the timer T313 from 5s to 3s.
For internal use

62
Charles / 2009-05-05
Page 62

Case 1: AMR Call Drop Rate Increase Due to T313 tuning
Case 2: SRB parameters optimization to improve CS call drop rate
For internal use

63
Charles / 2009-05-05
Page 63
SRB parameters optimization to improve CS call

drop rate
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
2006-2-6
2006-2-7
2006-2-8
2006-2-9
2006-2-10
2006-2-11
2006-2-12
2006-2-13
2006-2-14
2006-2-15
2006-2-16
For internal use

64
Charles / 2009-05-05
RNC ID
1
1
1
1
1
1
1
1
1
1
1
CS call drop rate

1.61%
1.65%
1.68%
1.60%
1.50%
1.40%
1.40%
1.53%
1.54%
1.54%
1.52%
Page 64

drop rate
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
The AMR call drop decrease from 1.50% to 1.2% after the parameters.
Date
2006-2-6
2006-2-7
2006-2-8
2006-2-9
2006-2-10
2006-2-11
2006-2-12
2006-2-13
2006-2-14
2006-2-15
2006-2-16
For internal use

65
Before Optimization
CS call drop rate
RNC ID
1
1.61%
1
1.65%
1
1.68%
1
1.60%
1
1.50%
1
1.40%
1
1.40%
1
1.53%
1
1.54%
1
1.54%
1
1.52%
Charles / 2009-05-05
Date
2006-2-17
2006-2-18
2006-2-19
2006-2-20
2006-2-21
2006-2-22
2006-2-23
2006-2-24
2006-2-25
2006-2-26
2006-2-27
2006-2-28
2006-3-1
2006-3-2
After Optimization
CS call drop rate
RNC ID
1
1.23%
1
1.13%
1
1.13%
1
1.29%
1
1.33%
1
1.38%
1
1.37%
1
1.23%
1
1.21%
1
1.16%
1
1.36%
1
1.35%
1
1.35%
1
1.21%
Page 65

drop rate
Name
Description
Default Value
Physical unit: ms.

A timer to RNC wait for the response to active set update in soft handover
procedure.
RLRSTRTMR Physical unit: ms.
A timer to RNC wait for radio link restoration indication in the radio link
procedure.
T313 is started after the UE detects consecutive N313 "out of sync"
T313
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.
NODISCARD 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
MAXDAT
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
high.
The AMR
call drop channel
decrease is
from
1.20% to 1% after the parameters.
HOASUTMR
Date
2006-2-20
2006-2-21
2006-2-22
2006-2-23
2006-2-24
2006-2-25
2006-2-26
2006-2-27
2006-2-28
2006-3-1
2006-3-2
For internal use
66
Before Optimization
CS call drop rate
RNC ID
1
1.29%
1
1.33%
1
1.38%
1
1.37%
1
1.23%
1
1.21%
1
1.16%
1
1.36%
1
1.35%
1
1.35%
1
1.21%
Charles / 2009-05-05
Date
2006-3-3
2006-3-4
2006-3-5
2006-3-6
2006-3-7
2006-3-8
2006-3-9
2006-3-10
2006-3-11
2006-3-12
Optimization value
5000
9000
5000
9000
30
40
After Optimization
RNC ID
1
1
1
1
1
1
1
1
1
1
The maximum
time for SRB reset
is
NODISCARDMAXD
AT*TIMERPOLL=4
0*200ms=8s.
CS call drop rate
1.00%
0.92%
0.96%
1.03%
1.03%
1.05%
1.03%
1.00%
0.90%
0.91%
Page 66

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

67
Charles / 2009-05-05
Page 67
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.
VS.PS.
RABRel
ease.R
NC
VS.PS.Call.
Drop.RNC.
Rate
RNC
Id
Time
VS.PS.Call.
Drop.RNC
VS.PS.R
ABRelea
se.RNC
VS.PS.Call.Dr
op.RNC.Rate
2008-12-30
67
6505
1.03%
17.69%
2008-12-31
69
8519
0.81%
298
17.45%
2009-01-01
50
7813
0.64%
76
407
18.67%
2009-01-02
54
8852
0.61%
2009-01-03
62
323
19.20%
2009-01-03
67
8375
0.80%
2009-01-04
68
312
21.79%
2009-01-04
61
11091
0.55%
2009-01-05
89
463
19.22%
2009-01-05
46
7931
0.58%
RNC
Id
Time
VS.PS.C
all.Drop.
RNC
2008-12-30
66
303
21.78%
2008-12-31
49
277
2009-01-01
52
2009-01-02
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.
For internal use

68
Charles / 2009-05-05
RNC
Id
VS.PSLoad.ULThruput.RNC
(GBytes)
VS.PSLoad.DLThruput.RNC
(GBytes)
12.76
48.63
8.12
56.18
The PS throughput of the two RNCs is very close.

Why the PS service attempted times has so large discrepancy?
Page 68
High PS Call Drop due to PSInactTimer Improper

The Setting
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.
2.
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.
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 use

69
Charles / 2009-05-05
RNC Id
Time(As hour)
VS.PS.Call.
Drop.RNC
VS.PS.Call.Drop.R
NC.Rate
2009-01-09 13:00
0.66%
2009-01-09 14:00
1.18%
2009-01-09 15:00
1.44%
2009-01-09 16:00
0.18%
2009-01-09 17:00
0.84%
2009-01-09 18:00
1.13%
2009-01-09 19:00
0.61%
2009-01-09 20:00
0.35%
2009-01-09 21:00
0.87%
2009-01-09 22:00
1.42%
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.
Page 69

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

70
Charles / 2009-05-05
Page 70

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
For internal use

71
Charles / 2009-05-05
Page 71
The access failure due to the power

congestion
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 use

72
Charles / 2009-05-05
Page 72

Firstly
congestion
we checked the code, CE and IUB resource, it is available.
1.
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.
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 use

73
Charles / 2009-05-05
Page 73
1.
2.
3.

Usually the power for common channel is 20% in total power in a cell. So it is 2w.
congestion
And the total used power was P= 3.7+4.95+2=10.65(w). And the maximum power
for the cell is 10w.
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.
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 use
74
Charles / 2009-05-05
Page 74

Case 2: CS RAB Assignment failure due not to configure ATM route in IU
interface
For internal use

75
Charles / 2009-05-05
Page 75
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 TYPE
BEST
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)
121:19355
AAL2 FAILURE
06:54:30(68)
121:19355
AAL2 FAILURE
06:54:39(87)
121:19355
AAL2 FAILURE
06:56:25(50)
121:19355
AAL2 FAILURE
06:58:25(72)
121:19355
AAL2 FAILURE
06:58:37(21)
121:19355
AAL2 FAILURE
06:58:46(46)
121:19355
AAL2 FAILURE
For internal use

76
Charles / 2009-05-05
Page 76
CS RAB Assignment failure due not to configure ATM route in IU

interface
From the trace, RNC sent the RAB_ASSIGNMENT_RESP
The transport layer address is
message to CN, and the failure is due to IU transport
connection failed to establish.
0x45000034901706104F0000000000000000000000 in
message RAB_ASSIGNMEN_REQ from CN.
AAL2RT
NSAP
RTX
OWNERSHIP
YES
0x45000034901706101F0000000000000000000000
NO
0x45000034901706102F0000000000000000000000
NO
0x45000034901706501F0000000000000000000000
NO
0x45000034901706502F0000000000000000000000
NO
0x45000034901706503F0000000000000000000000
NO
Charles / 2009-05-05
Check the IU interface of AAL2RT configured in RNC, the ATM

route didnt 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.
ANI
0x45000034901706103F0000000000000000000000
For internal use

77
Page 77

Case 2: CS RAB Assignment failure due not to configure ATM route in IU interface
For internal use

78
Charles / 2009-05-05
Page 78
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.9
192.168.13.2
192.168.13.3
192.168.13.4
192.168.13.5
192.168.13.7
192.168.13.8
192.168.13.1
10.16.9.133
10.16.9.197
10.16.10.5
10.16.8.5
For internal use

79
Charles / 2009-05-05
Page 79

RNC
Here there is an IP Address 192.168.13.6 not configured ,but assigned by SGSN. The IP
address is not configured in RNC
For internal use
80
Charles / 2009-05-05
Page 80

RNC
Action taken:
For internal use

81
Charles / 2009-05-05
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.
Page 81

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

82
Charles / 2009-05-05
Page 82
BLER Optimization for CS

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.
What is the meaning of BLER?
Transport channel parameters for AMR 12.2 kbps from 3GPP
BLER means Block Error Rate and it
defines the ratio of the incorrectly
TS 34.108 V8.1.0 are in the following table.
Higher layer
RLC
MAC
Layer 1
RAB/Signalling RB
Logical channel type
RLC mode
Payload sizes, bit
Max data rate, bps
TrD PDU header, bit
MAC header, bit
MAC multiplexing
TrCH type
TB sizes, bit
TFS TF0, bits
(note TF1, bits
1)
TF2, bits
TTI, ms
Coding type
CRC, bit
Max number of bits/TTI
after channel coding
RM attribute
RAB subflow #1
RAB subflow #3
DCH
0,39,81
1x0 (note 2)
1x39
1x81
20
CC 1/3
12
303
RAB subflow #2
DTCH
TM
103
12 200
0
0
N/A
DCH
103
0x103
1x103
N/A
20
CC 1/3
N/A
333
180 to 220
170 to 210
215 to 256
TM
0,39,81
received transport blocks to the total

number of received transport blocks.
TM
60
DCH
60
0x60
1x60
N/A
20
CC 1/2
N/A
136
Only 1 block is error
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%.
For internal use

83
Charles / 2009-05-05
Page 83
BLER and EcIo distribution in Cluster8 in

Quito
EcIo
BLER
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.
For internal use
84
Charles / 2009-05-05
Page 84
Parameters optimization of BLER

Type
Parameter Name
Default value
AMR
Video phone
AMR
Video phone
SIRADJUSTSTEP
SIRADJUSTSTEP
BLERQuality
BLERQuality
5(0.005dB)
2(0.002dB)
1%
0.20%
Optimized
value
3(0.003dB)
1(0.001dB)
0.50%
0.10%
AMR
AMR
Video phone
Video phone
RlMaxDlPwr(dB)
RlMinDlPwr(dB)
RlMaxDlPwr(dB)
RlMinDlPwr(dB)
0
-15
3
-12
1
-14
4
-11
Comments
Step of target SIR adjustment in outer loop power
control algorithm.
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).
The maximum and minimum downlink transmit
power of radio link.
The maximum and minimum downlink transmit
power of radio link.
The test result of BLER in Quito:

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%
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.
For internal use

85
Charles / 2009-05-05
Page 85

1.
2.

optimization cases
3.

cases
4.
5.
6.
7.
8.
For internal use

86
Charles / 2009-05-05
Page 86
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 SHO _ Ratio uPALSS[1] uPALSS[2] 2 uPALSS[3] 3 1 100
uPALSS[1] uPALSS[2] uPALSS[3]
The Huawei
formula is
A11 B1 2 C1 3
1 100%
A1 B1 C1
SHR
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}
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.
uPALSS[1] uPALSS[2] uPALSS[3]
1 100
(uPALSS[1] uPALSS[ 2] / 2 uPALSS[3] / 3)
celle RNC
SHO _ Ratio
celle RNC
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.
VS.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.
C1: NumberOfUEWith3RL
For internal use

87
Charles / 2009-05-05
Page 87
Soft handover ratio mapping for swap

network
Many factors impact the soft handover ratio, including the following items:
a)
b)
c)
d)
The soft
Soft handover parameter settings;

Network topology, site distribution, cell radius;
The antenna pattern;
Path loss;
handover parameter settings and site distribution have more impact on the soft handover rati
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.
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)
For internal use

88
Charles / 2009-05-05
Page 88

(Huawei) WCDMA Radio Parameters Optimization Cases

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

(Huawei) WCDMA Radio Parameters Optimization Cases

Încărcat de

Drepturi de autor:

Formate disponibile

10/31/15

WCDMA Radio Parameters

For internal use

Nokia Siemens Networks

Parameters Optimization Flow Chart

Drive test data

Data analysis and

Radio Parameters Optimization Cases

Coverage parameters optimization cases

Intra frequency handover parameters

Inter-RAT handover parameters optimization

CS call drop rate optimization cases

PS call drop rate optimization cases

Access control parameters optimization cases

BLER parameters optimization cases

Soft handover ratio optimization cases

For internal use

The coverage parameters being tuned

For internal use

Min transmit power of PCPICH[0.1dBm]

Coverage parameters optimization cases

For internal use

Increase the PCPICH Power to improve the

The RSCP is not

The EcIo is bad

Add a new site is very

For internal use

Increase the PCPICH Power to improve the

RSCP Before increasing

RSCP after Increasing

EcIo Before increasing

EcIo after Increasing

Increase PCPICH Power 3dB to improve the coverage.

How to modify the maximum PCPICH power?

How to modify the minimum PCPICH power?

For internal use

Coverage parameters optimization cases

Case 2: Increase DL maximum power of AMR to improve call drop

For internal use

Increase DL maximum power of AMR to improve call

For internal use

Increase DL maximum power of AMR to improve call

For internal use

Increase DL maximum power of AMR to improve call

PS144 PS256 PS384

For internal use

Coverage parameters optimization cases

Case 3: Increase FACH power to improve RRC setup success rate

For internal use

Increase FACH power to improve RRC setup success

Signaling for RRC Setup

RRC Setup Failure Distribution

RRC CONNECTION REQUEST

RRC Setup Failure

3. RADIO LINK SETUP REQUEST

4. RADIO LINK SETUP RESPONSE

Setup and Synchronization

6.CCCH RRC CONNECTION SETUP

RRC CONNECTION SETUP COMPLETE

RRC setup failure for poor coverage

Increase FACH power to improve RRC setup success

In live network, NodeB maximum transmit

FACH: changed from 32dBm to 34dBm,

RRC Setup statistics