1 - Capacity Study (Light + Detailed Version)

ORF Capacity Monitoring Study
- Highlights
Wireless Network Engineering
CTF/W20
Nortel Confidential Information
Agenda
> Introduction
Rational, Traffic Evolution, Call profile, Benchmark
> Capacity Monitoring method
Blocking & Resources Load Characterization

Congestion and Resources Load at network level
Top N most congested cells identification
Bottlenecks identification
Bottlenecks troubleshooting & analysis
> Capacity Monitoring Use case Method application

> Conclusions
3
UTRAN capacity analysis introduction

> Objective:
Networks have been deployed focusing on the service availability at the expense
of capacity
Traffic is growing constantly :
Traffic evolution during last 6 months
200000000
180000000
160000000
140000000
120000000
100000000
80000000
60000000
CS DL traffic KBytes
PS DL Traffic KBytes
15 A pr 06
8 A pr 06
1 A pr 06
2 5 -m a rs -0 6
1 8 -m a rs -0 6
1 1 -m a rs -0 6
0 4 -m a rs -0 6
25 Feb 06
18 F eb 06
11 F eb 06
4 Feb 06
2 8 -ja n v -0 6
2 1 -ja n v -0 6
1 4 -ja n v -0 6
31 Dec 05
24 D ec 05
17 Dec 05
10 Dec 05
3 Dec 05
2 6 -n o v -0 5
1 9 -n o v -0 5
1 2 -n o v -0 5
0 5 -n o v -0 5
2 9 -o c t -0 5
2 2 -o c t -0 5
1 5 -o c t -0 5
0 8 -o c t -0 5
0 1 -o c t -0 5
20000000
0 7 -ja n v -0 6
40000000
total PS + CS
Operators start to experience some congestion in their networks and foresee

further capacity issues.
They expect capacity analysis guidelines in order to be ready for capacity
planning.
> Scope:
This presentation has been prepared in the scope of UA4.1 pointing out also
possible UA4.2 evolutions (when the case)
4

> Study coverage
The capacity assessment is done for a period of two weeks: w10 &
w11
All the cells of the networks were analyzed (5495 cells)
All the RNCs (19 RNCs)
> Software release

Nortel OAM Release OAM5.0
Nortel UTRAN Release UA4.1 (17 RNCs) and UA4.2 (Lyonecul1 &
Lyontrio1)
> Elements of NodeB configuration:

Multi-carrier BTS : only some of the VO sites
X=1
X=2
X=3
X=4
BTS with X CEM
2058
28
BTS with X PCM
2060
29
Call Profile
ORF
Metric name
BHCA
Mean Call Duration
Active Set Update per second
Mean Sector per user
Percentage of softer HO
Inter-RAT cell reselection
SMS
Nb of AO Downsize per PS call
Nb of AO Upsize per call
Nb of AO Release per call
Nb of IRM Sched Downgrade per
call
% of 3G-2G HO per CS call
% of 3G-2G HO per PS call
Number of 2G-3G CS HHO
PS
CS V CS D 384
1,05
95
0.01
108
0,01
636
Operator 1
PS
128
PS
Ps 64 CS V CS D 384
0,06 0,001 0,93

110 452,0 55
0,01
48
0,19
34
PS
128
0,02
34,9
Operator 3
PS
Ps 64 CS V CS D 384
0,01
23
2,04
82
0,06
103
0,26
50
0,12
0,18
0,145
1,71
1,95
1,6
27%
1,36
0,33
2,36
1,88
0,25
35%
1,81
0,27
1,57
0,79
0,68
24%
1,23
0,42
1,75
1,2
0,44
0,07
0,01
0,08
11%
13%
0
23%
14%
0
5%
10%
0
PS
128
0,03
119
Ps 64
N/A
N/A
Significant differences between ORF profile and other operators:

Low number of PS calls/Sub but very long calls (impact on UPlane) >
AON timers settings consequence.
Mean sector per user reasonable value (OK from capacity point of view).
Very low number of AON release per call unnecessary resources usage.
6
Benchmark
Traffic Type & Volume
DedicatedDownlinkKbytesRlc (All traffic & PS only)
RBSetupRequest PS Repartition (%)

60000000
100%
90%
50000000
80%
40000000
70%
KByts
60%
50%
40%
30000000
20000000
30%
10000000
20%
10%
0
Day 1
0%
Day 1
Day 2
ORF PS384
ORF PS128
Day 3
OP1 PS384
Day 4
Op1 PS128
Op2 PS384
Day 5
Op2 PS128
Day 2
Day 3
Day 4
RNC: LYON1 (PS)
RNC: Op1 (PS)
RNC: Op2 (PS)
RNC: LYON1 (All)
RNC: Op1 (All)
RNC: Op2 (All)
Day 5
> Three different operators with three different traffic allocation strategies:
Orange mix of PS128 & PS384 RBs

Operator 1 mainly PS 384 (more than 95%)
> In terms of Volume: The most loaded is Operator 2 followed by Operator 1

which is also the most loaded in terms of PS traffic.
For this benchmark, ORF RNC (Lyonecul1) is the less loaded RNC
in terms of total traffic and PS traffic, but it has an homogeneous
PS traffic mix.
7
Benchmark
High Level Blocking analysis
Blocking rate comparison (RNC Level)
0,80%
Lyn1 Blocking cause = Iub

Op1 Blocking cause = Codes
Op2 Blocking cause = RF Power
0,70%
0,60%
0,50%
0,40%
0,30%
0,20%
0,10%
0,00%
Blocking rate Light % Lyn1
Blocking rate Light % Op1
> A Blocking rate Light taking into account all causes except unspecified is
calculated:
The Unspecified cause is not considered as it concerns only the CEM which is
not managed by the iRM in UA4.1 & UA4.2.
All other causes (Iub, Codes, RF Power) are covered by this metric.
> Operators 1 & 2 are almost not blocked at all (< 0,1%), blocking coming
from Codes (Op1) & RF Power (Op2)
Lyonecul1 is the most blocked RNC, the entire blocking coming

from Iub. For detailed iRM Benchmark information click Here
8
Agenda
> Introduction


> Conclusions
9
Blocking Characterization
> Blocking situation definition : each time the UE requests an UTRAN
resource and is not getting it because the resource is not available.
Call Phase
Blocking Cause
Effect
Monitoring detection
method
Call Admission
Lack of resources at
call setup
Call admission failure
- RB Establishment Unsuccess
Lack of resources to
perform iRM
transitions (AON
Upsize, iRM Sched
Upgrade)
Call is not reconfigured - RL Reconfiguration Unsuccess

(iRM Reconf)
(impact on user
throughput)
- RL Setup Unsuccess (AON)
Call
Reconfiguration
Mobility
- RL Reconfiguration Unsuccess
and Cancel
- AON/iRM Scheduling failure

counters
- RL Setup Unsuccess
No resources
Additional RL not
available for additional added in the Active Set - RL Addition Unsuccess
RL
(risk of call drop)
- RL & RB Reconfiguration
Unssuccess for HSDPA
This study is mainly focused on Blocking during Call Admission phase as it

is the most impacting for call success.
In general, if the call admission blocking is solved, the blocking on other call
phases is also solved (same bottlenecks involved).
10
Resources Load
Main possible bottleneck resources monitored at UTRAN Level:
> BTS Channel Elements - BTS Resource
The load can be monitored at BTS level

Blocking of this resource RB rejection or RL Setup/Addition/Reconfiguration
failures
> Iub ATM
The load can be monitored at BTS level (AAL2&AAL5 traffic)

alternative solution monitor the Traffic load per BTS at RNC level
Blocking of this resource RB rejection
> RF power - BTS Resource
The load can be monitored per cell via BTS or RNC counters
> OVSF Codes - RNC Resource
The load can be monitored per cell via RNC counters

> RNC CPU
11
The load can be monitored at card level through RNC counters

Blocking of this resource Overload mechanism => RB rejection
Congested cells @ Network level

Global Blocking
Blocking Rate at cell BH Distribution
4989
100%
4500
90%
4000
80%
3500
70%
2807
3000
2500
60%
50%
2102
2000
40%
1500
% of cells
Nb of Cells concerned
5000
30%
1083
1000
20%
273
500
37
>7%
>10%
>20%
>30%
0
>=0%
>0%
>0,5%
>2%
>5%
10%
104
0%
Blocking rate > x %

Blocked cells Count
Blocked cells %
> Blocking Rate per cell is computed as a ratio between the RB Blocking at BH and
RB Setup Request at BH for the entire observation period (BH = Busy Hour).
> Main contributor to this high blocking level was a Core CS dimensioning issue
(MSC Trion) which affected almost all Nortel RNCs. The rest is coming from Iub
congestion.
12
Significant amount of blocking (> 2%) observed during w10 &

w11 at Cell BH for 22% of the cells
CEM load @ Network level

CEM Load Distribution (Avg & Max @ BH)
4979
4757
4757
4500
100%
90%
4144
4000
80%
3482
3500
70%
3000
60%
2717
2500
50%
2000
40%
1500
30%
1060
765
1000
500
20%
116
15
279
4
0
>10%
>20%
>30%
% of cells
5000
>40%
>50%
>60%
64
>70%
17
10%
>80%
>90%
0%
>95%
CEMUsed > x %
Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, most part of the CEMs were loaded in average
less than 50% (the attention limit)
> When investigating the Max CEMUsed for the same period, we can see that 64
cells (and the associated CEMs) exceeded the 70% load which represents the
upper blocking limit of PS384.
13
37 BTS (64 cells) are reaching the dangerous zone of the CEM
Iub load @ Network level

Iub real Load Distribution (Max@BH)
100%
4484
4500
90%
4000
80%
3500
70%
3016
3000
60%
2500
50%
2000
40%
1500
% of cells
5000
30%
1074
1000
20%
311
500
112
48
18
>20%
>25%
>30%
>35%
40%
10%
0%
>2%
>5%
>10%
>15%
Iub Load > x %

Max Load Count
Max Load (%)
> As it is based on a BTS counter, the monitored Iub load (@ BH) has to be seen
as the average load per hour. In the graph, the Max of these averages (for the
observation period) is captured.
Iub utilization is very low, not exceeding 35% of the Iub bandwidth.
This is not preventing from having Iub blocking as the admission
criteria is based on the estimated Iub load (at the RNC)
14
DL Power load @ Network level

DL RF Power Distribution (Avg & Max)
49574954
4780
4390
4500
100%
4326
90%
4000
80%
3500
70%
3080
3000
60%
2503
2500
50%
2000
40%
1486
1500
30%
1000
283
500
% of cells
5000
20%
514
83
26
151
12
45
10%
0%
>10%
>20%
>25%
>30%
>35%
>40%
>45%
>50%
>60%
>70%
>80%
DL Pow er Load > x %

Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, most part of the cells were loaded in average less
than 50%
> When investigating the Max load for the same period, we can see that only 1 cell
punctually exceeded 80% (Yellow2Red iRM power threshold).
DL power load is relatively low in the network. The loaded sites

being mostly sites from VO zone (JONAGE_COTTAGE, MEYZIEU_CARREAU,
MEYZIEU_GD_LARGE, MEYZIEU_OUEST) which use PA/2 (due to STSR2)
15
Codes load @ Network level

OVSF Codes Load Distribution (Avg & Max @ BH)
4933
4797
4873
100%
4500
90%
3746
4000
80%
3377
3500
70%
3000
60%
2500
50%
2000
40%
1352
1500
30%
745
1000
20%
459
500
% of cells
5000
93
54
10
12
10%
0%
>5%
>10%
>20%
>30%
>40%
>50%
>60%
>70%
>80%
Codes Load > x %

Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, all the cells were loaded in average less than 50%
> When investigating the Max load for the same period, we can see that only 2 cells
punctually exceeded 70% (Yellow2Red iRM codes threshold).
16
Low codes load => only two cells being able to reach a max load
leading to a red iRM cell color.
RNC CPU load @ Network level

TMU load Avg & Max
100
90
80
TM U Load (%)
70
GRENOBLE1 Avg
60
GRENOBLE1 Max
LYONECUL1 Avg
50
LYONECUL1 Max
MONTPELL1 Avg
40
MONTPELL1 Max
30
20
10
0
13/3/ 13/3/ 13/3/ 13/3/ 14/3/ 14/3/ 14/3/ 14/3/ 15/3/ 15/3/ 15/3/ 15/3/ 16/3/ 16/3/ 16/3/ 16/3/ 17/3/ 17/3/ 17/3/ 17/3/ 18/3/
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00
> Only 3 RNCs are captured in this graph (3 most loaded from TMU point of view)
> For these 3 RNCs, the TMU load is remaining in acceptable limits:
Average < 20%

Max < 35% (the only exception is Montpell1 with some local issues on 15-03-06)
TMU load is far from being a concern for ORF network

17
Agenda
> Introduction


> Conclusions
18

> Counters Granularity: Hour
For each Cell : 4 metrics calculation
RbRejected@BH where BH=Hour[Max(RbSetReq)]
days
RbRejected@BkH where BkH=Hour[Max(RbRejected)]

days
RbRejected
days hour
BHBKRate(%) = RbRejected / RbSetReq (@BH)
Condition1= NbrDays[BHBKRate(%)> 0%]
N.B RbRejected corresponds to counter VS.RadioBearerEstablishmentUnsucces (without screening 0)
RbSetReq corresponds to counter VS.RadioBearerSetupRequest
Method aims to create a list of most representative cells in terms of

blocking by taking into account the amount of rejections at different
periods of the day but also the persistence in time of the issue.
19

CellsRanking
[ RbRejected]
day hour
CellsRanking
[RbRejected@BH]
Cells Filtering
[Condition1>X & Condition2>Y ]
X>Y
CellsRanking
[RbRejected@BkH]
Bottleneck Identification
[RbRejected Screening]
In our Study:
Obs.Period =14 days
X=7
Y=4
20
Final cells List to investigate

Top N most congested cells

identification - Result
Cell
GRE_ALSACE_LORRAINE_U21
DJN_HAVRE_U11
BOURGOIN_EST_U11
BIONNE_TDFT_U31
ST_ETN_GARE_U11
GRE_EUROPOLE_U11
FERREOL_U31
ECHIROLLES_U11
FERREOL_U11
GRE_JEAN_JAURES_U11
HYERES_COUBERTIN_U11
BEAUREGARD_U21
NIMES_MONT_DUPLAN_U21
MARIGNANE_CENTRE_U21
ECHIROLLES_U31
AIX_CARCASSONNE_U21
FONTAINE_CHARM_U21
GRE_EUROPOLE_U21
HAUTS_VOREPPE_TDF_U21
DJN_CFRT_U11
DJN_HAVRE_U21
GRE_JEAN_JAURES_U31
TOULON_VALETTE_SUD_U21
RABATEAU_U31
GRE_AMPERE_DRAC_U11
SALON_SUD_U31
BEAUREGARD_U31
ALLAUCH_U31
ISTRES_LES_COGNETS_U11
VIENNE_PIPET_U11
GARIBALDI_U11
MARSEILLE_PARTY_U21
FONTAINE_OUCHE_U31
TERRON_U21
ST_EGREVE_BONNAIS_U11
GRE_EAUX_CLAIR_U31
MRS_MONTE_CRISTO_TDFT_U21
BIONNE_TDFT_U21
GRE_AMPERE_DRAC_U21
SEYSSINET_NORD_U11
TOUR_PIN_U31
CROLLES_U11
TRAMOYES_U31
CORDERIE_U11
DJN_MARCS_OR_U21
LES_CHARTREUX_U21
ST_GELY_DU_FESC_TDFT_U31
DJN_VICTOR_HUGO_U11
GRE_ABBAYE_U31
MAUGUIO_U31
ST_JEROME_U31
AIGUELONGUE_U11
DJN_HAVRE_U31
21
BK Day
Setup Day
Bk rate day
Bk & BH
Setup & BH
Bk rate BH
Bk & BkH
Setup & BkH
Bk rate BhK
796
515
279
338
504
297
317
245
267
247
279
179
249
172
193
310
144
161
145
161
215
122
145
133
135
97
114
107
101
113
103
99
95
128
98
107
112
122
83
85
84
78
77
140
79
70
99
61
74
69
64
58
58
85
75504
23104
21612
27698
1962
20546
20132
17564
17850
20098
7600
12697
5761
13129
14707
4504
11916
13154
9049
14210
10344
8082
8726
10587
9464
9278
5931
8335
10379
9373
7631
8565
9542
995
6121
7513
8915
10167
7014
8765
6999
5121
5500
3911
3923
8143
3248
8044
8775
6977
4713
3889
5308
3788
1,1%
2,2%
1,3%
1,2%
25,7%
1,4%
1,6%
1,4%
1,5%
1,2%
3,7%
1,4%
4,3%
1,3%
1,3%
6,9%
1,2%
1,2%
1,6%
1,1%
2,1%
1,5%
1,7%
1,3%
1,4%
1,0%
1,9%
1,3%
1,0%
1,2%
1,3%
1,2%
1,0%
12,9%
1,6%
1,4%
1,3%
1,2%
1,2%
1,0%
1,2%
1,5%
1,4%
3,6%
2,0%
0,9%
3,0%
0,8%
0,8%
1,0%
1,4%
1,5%
1,1%
2,2%
230
142
188
124
143
101
81
105
80
86
86
103
76
100
76
70
74
84
59
58
52
73
55
58
48
62
52
52
49
54
60
51
51
43
60
43
41
40
38
44
35
37
47
20
33
35
25
29
32
37
41
29
36
21
6126
2382
2313
2797
370
2483
2054
2036
1949
2213
818
1369
713
1378
1690
739
1393
1524
1034
1457
1101
1029
1035
1107
1118
1056
730
1052
1179
1063
844
998
1506
263
724
1106
971
1191
1023
1040
758
594
644
515
609
959
453
821
993
788
578
547
621
484
3,8%
6,0%
8,1%
4,4%
38,6%
4,1%
3,9%
5,2%
4,1%
3,9%
10,5%
7,5%
10,7%
7,3%
4,5%
9,5%
5,3%
5,5%
5,7%
4,0%
4,7%
7,1%
5,3%
5,2%
4,3%
5,9%
7,1%
4,9%
4,2%
5,1%
7,1%
5,1%
3,4%
16,3%
8,3%
3,9%
4,2%
3,4%
3,7%
4,2%
4,6%
6,2%
7,3%
3,9%
5,4%
3,6%
5,5%
3,5%
3,2%
4,7%
7,1%
5,3%
5,8%
4,3%
516
227
227
224
158
193
192
185
164
151
117
124
129
125
124
112
143
111
107
100
85
92
92
93
94
96
82
81
88
76
76
81
82
72
71
77
67
65
88
58
62
62
53
64
57
62
55
77
54
50
50
61
51
41
4638
2045
1909
2352
314
1782
1507
1559
1519
1740
651
954
539
1124
1265
431
1040
1045
843
1062
897
690
809
838
627
672
532
858
727
804
619
720
747
157
507
633
710
786
572
709
542
394
357
275
430
693
271
514
655
443
433
321
457
334
11,1%
11,1%
11,9%
9,5%
50,3%
10,8%
12,7%
11,9%
10,8%
8,7%
18,0%
13,0%
23,9%
11,1%
9,8%
26,0%
13,8%
10,6%
12,7%
9,4%
9,5%
13,3%
11,4%
11,1%
15,0%
14,3%
15,4%
9,4%
12,1%
9,5%
12,3%
11,3%
11,0%
45,9%
14,0%
12,2%
9,4%
8,3%
15,4%
8,2%
11,4%
15,7%
14,8%
23,3%
13,3%
8,9%
20,3%
15,0%
8,2%
11,3%
11,5%
19,0%
11,2%
12,3%
rank
1
3
6
6
7
9
12
12
16
17
21
22
22
23
25
26
31
31
43
44
52
52
53
55
61
70
74
78
79
81
83
86
87
89
91
92
105
106
115
140
154
159
168
173
177
177
185
189
195
208
211
224
234
272
days with
Bk>2%
4
7
7
5
8
4
4
6
5
5
8
7
8
6
5
11
6
6
5
4
7
6
6
6
7
5
7
7
7
5
7
5
6
11
7
6
6
6
5
6
5
7
7
7
7
6
8
6
4
7
9
6
7
6
days with
Bk>0%
7
8
9
10
8
7
7
7
7
8
8
9
9
9
7
11
7
7
8
7
9
7
7
8
9
7
8
9
7
7
7
8
7
11
7
7
9
7
7
9
7
7
7
7
7
7
8
7
7
7
9
7
7
7
Two filter criteria are

used:
- BK > 2 % for at least 4
days form observation
period
period
The rank is calculated
following Step 1
54 regularly
blocked
cells with
high impact
on user
perception
The different blocking causes to be investigated are identified
through VS.RadioBearerEstablishmentUnsuccess screenings)
Scr. 0: invalid RAB parameters value not to be considered as blocking

cause, thus not taken into account in the blocking rate computation
Scr. 1: unavailable dl code resources Code shortage indication
Scr. 2: unavailable dl power resources DL power shortage indication
Scr. 3: Unspecified covers CEM resources and other possible issues during
call setup (Core Network UP Init. failures...)
Scr. 4: Lack of bandwidth Iux bandwidth allocation shortage (all interfaces:
Iub/Iu/Iur) this screening is replaced by screenings #10, #12 and #14 in
UA04.2
Scr. 5: Lack of CID Iux CIDs allocation shortage (all interfaces: Iub/Iu/Iur)
this screening is replaced by screenings #9, #11 and #13 in UA04.2
Scr. 6: CAC RNC Processing resources TMU resources shortage (overload
situations)
Scr. 9: Lack of CID on the Iu introduced in UA04.2
Scr. 10: Lack of bandwidth on the Iu introduced in UA04.2
Scr. 11: Lack of CID on the Iur introduced in UA04.2
Scr. 12: Lack of bandwidth on the Iur introduced in UA04.2
Scr. 13: Lack of CID on the Iub introduced in UA04.2
Scr. 14: Lack of bandwidth on the Iub introduced in UA04.
22
Bottlenecks identification - Result

Cell
DJN_HAVRE_U11
BOURGOIN_EST_U11
BIONNE_TDFT_U31
ST_ETN_GARE_U11
GRE_EUROPOLE_U11
FERREOL_U31
ECHIROLLES_U11
FERREOL_U11
GRE_JEAN_JAURES_U11
BEAUREGARD_U21
ECHIROLLES_U31
AIX_CARCASSONNE_U21
FONTAINE_CHARM_U21
GRE_EUROPOLE_U21
DJN_CFRT_U11
DJN_HAVRE_U21
GRE_JEAN_JAURES_U31
RABATEAU_U31
GRE_AMPERE_DRAC_U11
SALON_SUD_U31
BEAUREGARD_U31
ALLAUCH_U31
VIENNE_PIPET_U11
GARIBALDI_U11
MARSEILLE_PARTY_U21
FONTAINE_OUCHE_U31
TERRON_U21
GRE_EAUX_CLAIR_U31
BIONNE_TDFT_U21
GRE_AMPERE_DRAC_U21
SEYSSINET_NORD_U11
TOUR_PIN_U31
CROLLES_U11
TRAMOYES_U31
CORDERIE_U11
DJN_MARCS_OR_U21
LES_CHARTREUX_U21
DJN_VICTOR_HUGO_U11
GRE_ABBAYE_U31
MAUGUIO_U31
ST_JEROME_U31
AIGUELONGUE_U11
DJN_HAVRE_U31
23
BK Day
Setup Day
Bk rate day
Bk & BH
Setup & BH
Bk rate BH
796
515
279
338
504
297
317
245
267
247
279
179
249
172
193
310
144
161
145
161
215
122
145
133
135
97
114
107
101
113
103
99
95
128
98
107
112
122
83
85
84
78
77
140
79
70
99
61
74
69
64
58
58
85
75504
23104
21612
27698
1962
20546
20132
17564
17850
20098
7600
12697
5761
13129
14707
4504
11916
13154
9049
14210
10344
8082
8726
10587
9464
9278
5931
8335
10379
9373
7631
8565
9542
995
6121
7513
8915
10167
7014
8765
6999
5121
5500
3911
3923
8143
3248
8044
8775
6977
4713
3889
5308
3788
1,1%
2,2%
1,3%
1,2%
25,7%
1,4%
1,6%
1,4%
1,5%
1,2%
3,7%
1,4%
4,3%
1,3%
1,3%
6,9%
1,2%
1,2%
1,6%
1,1%
2,1%
1,5%
1,7%
1,3%
1,4%
1,0%
1,9%
1,3%
1,0%
1,2%
1,3%
1,2%
1,0%
12,9%
1,6%
1,4%
1,3%
1,2%
1,2%
1,0%
1,2%
1,5%
1,4%
3,6%
2,0%
0,9%
3,0%
0,8%
0,8%
1,0%
1,4%
1,5%
1,1%
2,2%
230
142
188
124
143
101
81
105
80
86
86
103
76
100
76
70
74
84
59
58
52
73
55
58
48
62
52
52
49
54
60
51
51
43
60
43
41
40
38
44
35
37
47
20
33
35
25
29
32
37
41
29
36
21
6126
2382
2313
2797
370
2483
2054
2036
1949
2213
818
1369
713
1378
1690
739
1393
1524
1034
1457
1101
1029
1035
1107
1118
1056
730
1052
1179
1063
844
998
1506
263
724
1106
971
1191
1023
1040
758
594
644
515
609
959
453
821
993
788
578
547
621
484
3,8%
6,0%
8,1%
4,4%
38,6%
4,1%
3,9%
5,2%
4,1%
3,9%
10,5%
7,5%
10,7%
7,3%
4,5%
9,5%
5,3%
5,5%
5,7%
4,0%
4,7%
7,1%
5,3%
5,2%
4,3%
5,9%
7,1%
4,9%
4,2%
5,1%
7,1%
5,1%
3,4%
16,3%
8,3%
3,9%
4,2%
3,4%
3,7%
4,2%
4,6%
6,2%
7,3%
3,9%
5,4%
3,6%
5,5%
3,5%
3,2%
4,7%
7,1%
5,3%
5,8%
4,3%
rank
1
3
6
6
7
9
12
12
16
17
21
22
22
23
25
26
31
31
43
44
52
52
53
55
61
70
74
78
79
81
83
86
87
89
91
92
105
106
115
140
154
159
168
173
177
177
185
189
195
208
211
224
234
272
Blocking Cause
Unspecified
LackOfBandwidth & Unspecified
Unspecified
Unspecified
LackOfBandwidth
Unspecified
LackOfBandwidth
LackOfBandwidth
Unspecified
Unspecified
LackOfBandwidth
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
LackOfBandwidth
Unspecified
LackOfBandwidth
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
days with
Bk>2%
4
7
7
5
8
4
4
6
5
5
8
7
8
6
5
11
6
6
5
4
7
6
6
6
7
5
7
7
7
5
7
5
6
11
7
6
6
6
5
6
5
7
7
7
7
6
8
6
4
7
9
6
7
6
days with
Bk>0%
7
8
9
10
8
7
7
7
7
8
8
9
9
9
7
11
7
7
8
7
9
7
7
8
9
7
8
9
7
7
7
8
7
11
7
7
9
7
7
9
7
7
7
7
7
7
8
7
7
7
9
7
7
7
Main observations:
- Practically no DL
Power or Codes
blocking monitored
during Obs. Period.
(this is specific to the
entire network, not
only TopN list)
- Unspecified &
LackOfBandwidth are
the only blocking
causes monitored in
the network.
Agenda
> Introduction


> Conclusions
24
Bottleneck analysis
Unspecified
Blocking detection
> The Unspecified RB Establishment Unsuccess is not always directly

linked to a specific UTRAN bottleneck, thus the association with the load
is not obvious for this blocking cause.
> This blocking cause is identified through screening Unspecified of the
VS.RadioBearerEstablishmentUnsuccess counter - See bullet 6 in the RB
Allocation Procedure Data Flow Diagram.
> It covers the following Call Setup failures causes:
CEM resources shortage
User Plane Initialization failure between RNC and Core Network (Iu issues).
From UA4.2 the HSDPA CAC rejected calls are also pegging this counter.
> In general, it is a good method to detect the CEM resources shortage as

the CEMAllocFail counter has some limitations (see CEM analysis).
> HSDPA CAC is also pegging the UnsuccesfulHsdpaCac counter (#0958)
25
Bottleneck analysis
Unspecified
Detailed investigation method
RB Establishment Unsuccess
no
Unspecified > 0
Stop
yes
RL Reconfiguration Prepare Unsuccess

RLReconfFailure RB Establishment Unsuccess
Unspecified
no
RL Reconfiguration Cancel > 0
And correlated in time with
Unspecified
no
Unsucc. HSDPA CAC > 0
Unspecified
26
yes
yes
Call allocation failure due to lack of CEM resources

(HBBU or DBBU) => relay on CEM Bottleneck analysis
Possible RNC - Core Network UPlane initialization issues. Confirmed if

the issue occurs on several BTSs of the same RNC (depending on their
traffic load).
It is possible to identify the Core domain generating the issue by
checking the RadioLinkReconfigurationCancel.DlAccessStratumConf5 for CS or
DlAccessStratumConf2/6/7 for PS
Check Core Network Counters & Alarms for more details
yes
The HSDPA limit of 20 UEs per cell is reached (HSDPA CAC)

Bottleneck analysis
Unspecified
RadioBearerEstablishmentUnsuccess.Unspecified vs. RadioLinkReconfigurationCancel
Example
> During observation period (w10 &
w11) a large amount of
160
140
120
VS.RadioBearerEstablishmentUnsuccess.Un
specified was monitored on a large
number of ORF BTSs. It was

perfectly correlated with the
100
80
60
40
VS.RadioLinkReconfigurationCancel:
20
> The investigations showed that only
VS.RadioLinkReconfigurationCancel.DlAcce
ssStratumConf5 (CS voice) was
pegged, thus a possible issue

between RNC and the Core CS.
VS.RadioLinkReconfigurationCancel
VS.RadioBearerEstablishmentUnsuccess.Unspecified
7000
> When investigated at RNC level, the

issue was more visible on 6 RNCs
connected to the same MSC (and
probably to the same ALI board)
> The issue disappeared after some
operations of MSC side (RNC
reparenting & ALI redimensioning) but
it seems to be back again after 3
weeks (to be checked):
27
VS.RadioBearerEstablishm entUnsuccess.Unspecified
6000
5000
GRENOBLE1
4000
MARSESTM2
MONTPELL1
MARSESTM1
3000
DIJONC1
TOULON_SF1
2000
1000
Bottleneck analysis
BTS Channel elements (CEM)
Blocking Detection
>
The CEM blocking is particular annoying as this resource is not managed

by the RNC. Thus, if no CEM resources available, the call is released (no
iRM downgrade based on this resources load is possible until UA5.0)
>
Call admission blocking due to CEM resources shortage can be detected

by two methods:
1. Using the VS.RadioBearerEstablishmentUnsuccess.Unspecified counter

see the Unspecified analysis above.
2. Using BTS counter CEMAllocFail. Method drawbacks:
>
This counter provides the % of CEM resources requests that are refused from
total CEM resources requests. All requests are considered: RL Setup SRB or
TRB, RL Reconfiguration Up or Down thus it will be slightly incremented even
in case of high blocking.
It is rounded to Integer (if 0.8% is calculated => 0% is displayed)
Recommendation: use the first method and only confirm (if it is the case)
with the CEMAllocFail method.
28
Bottleneck analysis
Resource Load evaluation
> CEM load (DBBU) is measured by means of CEMUsed (BTS counter)
>
The CEMUsed screenings (Avg, Min, Max.) allows to:
>
Min during the night it will provide info on Common Channels utilization (usually 18% for
STSR1 on 1 iCEM64)
Avg Average load during one Hour used for dimensioning purposes
Max allows to determine the moments when the alarm thresholds were exceeded
triggering blocking.
RAB Type (UL/DL)
Block. thresholds
CEMUsed booking levels for

the most used RABs in ORF
in case of 1 iCEM64:
CS 12.2/12.2
98%
PS 64/64, 128/128, 128/384, 128/0

(HSDPA)
85%
PS 64/384
72%
PS 384/0 (HSDPA)
65%
>
Recommendation: set an Yellow alarm monitoring trigger for CEMUsed.Avg

exceeding 50% and a red one for CEMUsed.Max exceeding constantly 70%.
>
CEM load (HBBU) cannot be directly monitored in UA4.2. Alternative through

DlAsConfIdAvgNbrEstab.Max is proposed (next slide). Complete solution in UA5.0
29
Bottleneck analysis
no
Unspecified analysis
shows CEM blocking
Stop
yes (Optional)
yes
CEMAllocFail >
Call allocation
failure due to
lack of CEM
CEMUsed.Max
> 70%
yes
Plan to add additional
CEM (DBBU) resources
30
no
CEMAllocFail could display 0 even with

High PS blocking if there are many
resources requests that are accepted (small
RABs) => continue CEM investigation
yes
no
UA4.2
UA5.0
MAX
[DlAsConfIdAvgNbrEstab.Max
HsdpaUesperHbbu.Max
=X
(scr.27)] ~ X
yes

CEM (HBBU) resources
no
-Potential issues with CEM configuration
(check CCP configuration).
- STSR2 is activated and the traffic is
unbalanced between frequencies => Add
additional CEM resources
X = 20 (UA4.2)
X = 48 (UA5.0)
Bottleneck analysis
Iub Interface
Blocking Detection
> The Iub resources management is done at RNC Level. From UA4.2 this
resource will be taken into account in the iRM @ CAC mechanism.
> Call admission blocking due to Iub resources shortage can be detected
through the counter:
VS.RadioBearerEstablishmentUnsuccess.LackOfBandwidth & LackOfCid

In UA4.1 this counter is not making the difference between different Iux interfaces,
thus additional check is needed => if problem is seen only on some (isolated)
BTSs, then it is an Iub problem.
From UA4.2, specific screenings per Iux interface will be available (better
precision during bottleneck identification phase)
> Additional indication about call admission blocking and iRM upgrade
procedures fail due to lack of Iub resources is provided by:
VS.RadioLinkReconfigurationPrepareUnsuccess.INodeRefusal (enhanced by
two new screenings in UA4.2 LackBwthIub & LackCid)
> When the mobility is affected by the lack of Iub resources the following
counter will be pegged: VS.RadioLinkSetupUnsuccess.INodeRefusal
(enhanced by two new screenings in UA4.2 LackBwthIub & LackCid)
31
Bottleneck analysis
Iub Interface
> Iub Load indicators available in UA4.1:

Real load of the Iub calculated from BTS Transport counters (average/hour):
Monitored_Iub_Load = (VS.AAL2NbReceivedCell + VS.AAL5NbReceivedCell) / 4528
The Iub Load estimated by the RNC and used by iRM CAC:
RNC_Estimated_Iub_load = ( RadioLinkEstablishedPerCell.Avg) * ECR * SrHO% (at cell level)
The ECRs are calculated from configured EBRs.
> If the EBR configuration is very conservative (AF 100% considered for all
RBs, especially the big PS RBs), the gap between the Monitored_Iub_Load
and RNC_Estimated_Iub_load will be important and the blocking will be seen
with very low Iub traffic (currently the case in ORF).
> From UA4.2, the real Iub load is taken into consideration in the iRM and it
will be possible to monitor the percentage of time a certain load level was
reached through iRM specific counters:
#1155 VS.IRMTimeCellDlIubTransportColorYellow (recommended threshold @ 70%)
#1148 VS.IRMTimeCellDlIubTransportColorRed (recommended threshold @ 90%)
32
Bottleneck analysis
Iub Interface
LackOfBandwidth will be replaced in UA4.2 by
LackOfBandwidthOnIu
LackOfBandwidthOnIur
LackOfBandwidthOnIub
And Lack of CID
LackOfCidOnIu
LackOfCidOnIur
LackOfCidOnIub
no
Lack of bandwidth > 0

Or
Lack of CID > 0
yes
Call allocation failure
due to Iub Lack of
bandwidth or CIDs
yes (optional)
RL Reconfig Prepare Unsuccess

INodeRefusal RB Establishment Unsuccess
LackOfBandwidth
yes
Call allocation & iRM Sched. upgrade
failure due to lack of Iub Resources
Monitored_Iub_Load ~
IRMTimeCellDlIubTransportColorRed X%
RNC_Estimated_Iub_load?
yes
PCM resources
33
RadioLink Reconfiguration Prepare Unsuccess

INodeRefusal will be completed in UA4.2 with:
LackBwthIub
LackOfCid
Stop
no
UA4.2
UA4.1
no
Transport configuration
allows EBR Tuning?
- X can vary with EBR config., traffic type

(R99/HSDPA) and Y2R/R2Y Iub
thresholds
- For R99, EBR at max and Y2R/R2Y Iub =
90%/80%, X is expected to be 1%
Additional analysis is needed for HSDPA
yes
Do EBR Tuning
Agenda
> Introduction


> Conclusions
34
Capacity Monitoring Use cases

Use case 1: Low RB Setup and high blocking
Use case 2: High RB Setup and high blocking
Use case 3: High RB Setup and low Blocking
35
USE CASE 1: Low RBSetup but high blocking

Summary
> Site to be analyzed : ST_ETN_GARE
> Cell : ST_ETN_GARE_U11
> Capacity Analysis:
-
One day from the Obs. period (14/03) is chosen for detailed analysis
Blocking causes identification: LackOfBandwidth & Unspecified
Bottlenecks identification: Iub & CEM
Traffic analysis:
High amount of PS traffic : 9 Erl /BH (several hours) & 166 Kbps @BH
PS384 main traffic: Setup/Request = 77 / 179 = 43% admission / day /site
PS384 converted to PS64 due to Iub blocking: 80 (44%) / day /site
PS384 lost due to Iub blocking: 22 (13%) / day /site
- Recommendations for this site:

- Tuning EBRs or add PCM
- add CEM
36

Choosing blocking day for detailed analysis
RB Blocking Rate at BH (ST_ETN_GARE_U11)
70%
Blocking (%)
50%
60
Day chosen for

detailed analysis
50
40%
40
30%
30
20%
20
10%
10
0%
Nb of RBs
60%
70
RB Blocking Rate at BH
RB Setup Request at BH
RB Blocked at BH
> Cell very blocked during the entire week (exception being the week-end)
14/03 is chosen for deeper analysis the Blocking rate is not

the highest at this date, but the cell has the highest number of
RB Setup Requests and RB Blocking.
37

Blocking causes identification
Blocking causes identification (ST_ETN_GARE_U11)
40
35
35
32
30
29
27
25
RBEstablishmentUnsuccess - total
Peaks of
Lack of Bandwidth
& Unspecified
20
RBEstablishmentUnsuccess.Unspecified
RBEstablishmentUnsuccess.LackOfBandw idth
RBEstablishmentUnsuccess.UnavailableDlCodeResources
RBEstablishmentUnsuccess.UnavailableDlPow erResources
15
13
12
12
13
10
8
5
0
4
3
1
5
4
3
3
2
2
1
1
1
1
1
0
00
0
0
0
0
0
0
0
0
0
0
0
00
0
0
00
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
> High rate of Lack of Bandwidth is observed:

From UA4.2 Iub/Iu/Iur specific screenings will be available.
> A second cause of blocking is Unspecified:

Additional investigation is needed to clearly identified the cause of unspecified
blocking (see next slide)
38
No Codes & Power blocking issues
Lack of Bandwidth and Unspecified blocking identified


Bottlenecks analysis
Bottlenecks analysis - "Unspecified" detailed investigation
35
31
30
28
29
27
25
RLReconfPrepareUnsuccess.RadioLinkReconfigurationFailure
20
RLReconfPrepareUnsuccess.INodeRefusal
15
13
13
12
12
10
14
12
8
5
7
6
3
4
2
2
1
1
11
1
0
0
0
0
0
0
0
00
0
0
0
00
0
0
0
00
0
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
3
> RL Reconfiguration Cancel is 0, so no Core Network issues are foreseen

> RL Reconfiguration is failing in the Preparation phase:
Cause INodeRefusal is confirming the Iux lack of bandwidth (linked to
LackofBandwidth cause)
=>As the issue is not seen on the entire RNC we can conclude that Iux = Iub
Cause RadioLinkReconfigurationFailure confirms a lack of resources at NodeB
level (generally caused by CEM resources).
Iub and CEM blocking are confirmed

39

Blocked traffic type identification
Rejected Traffic vs Blocking
30
25
21
RB Setup Unsucc PS64
Nb of RBs
20
17
16

RB Setup Unsucc CS
15

10
10
11
10
RBEstablishmentUnsuccess.LackOfBandwidth
7
6
5
2
00
00
00
00
00
00
00
00
2
0
1
0
3
2
22
00
4
2
00
00
00
00
> RB Setup Unsuccess is calculated per RB type as difference between RB Setup

Request and RB Setup Success.
> The CS and PS128 traffic are practically not blocked
40
CS is a small RB which passes even if high blocking is present at Iub and CEM level.
PS128 no blocking as very few requests are present.
The only traffic blocked is the PS384 and PS64


Blocking traffic analysis
Max RL Establsihed vs Blocking
12
35
Peak of PS384
call duration (700s)
10
9
8
30
9
25
Nb of RL
20
6
5
15
Max of 3 PS384
4
3
3
2
22
1
0
0
01:00
10
2
00:00
02:00
Max Nb of RL PS64
1
0
03:00
1
0
04:00
00
00
00
05:00
06:00
07:00
Max Nb of RL PS384
2
1
1
00
08:00
Max Nb of RL CS
09:00
10:00
11:00
Max Nb of RL PS128
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
>
The max of 3 PS384 accepted by the Iub (with the current EBR configuration) is reached
during 4 hours only in the observed cell (not counting the traffic in other cells).
>
This is combined with a high PS384 Call duration (200 s in average, 700s peak at 14h00)
>
The Iub capacity with the current

EBR config - see tables:
41
if x PS384
1
2
3
PS64 ?
15
9
3
PS128?
7
4
1
if x PS64
7
8
9
10
PS128?
7
6
6
5
PS384?
2
2
2
1
Iub limit is reached constantly during the day => blocking

23:00
RB Blocked
10

Traffic blocking consequences
PS64 Setup correlation with Iub Blocking
30
25
20
15
10
RB Setup Request PS64
> Due to rapid blocking at Iub level (max 3 PS384 per Iub with 1 PCM), a
RB Reallocation mechanism is triggered at Core PS level (see details in
next slide). Due to this mechanism, a PS384 failed setup is replaced by a
PS64 RB request.
This mechanism is allocating a lower PS RAB (PS64) maintained

during entire call duration (not eligible to any iRM Upgrade) => user
perception: Good for call admission but Bad for service quality
42

RequestedUEMaximum
Bit Rate not Available
(20)
Node B
RNC
CN - PS
PS call initial connection (RRC phase)

PS call RAB allocation phase starts with PS384
RAB Assignment Request (DL384/UL64)
No Ressources
RAB Assignment Response (Fail: 20)
PS call RAB allocation phase continue with PS64
> If no resources are available at RNC level, the RB Assignment Request

(for PS384 or PS128) is answered with a RAB Assignment Response
(Fail: 20) which is immediately followed by a new request for a lower RAB
(instead of Iu Release Command)
to be confirmed if it works only with Iub or all other resources managed by
RNC (Codes & Power)
It not works with the CEM resources which are managed by the BTS.
Using this Core PS mechanism is helpful to reduce Iub blocking,

but it will work against RB adaptation feature (UA4.2) allocated
RB will not be eligible to any upgrade.
43

Load details all resources
Load per Resource type
100%
90%
14/03
80%
Load (%)
70%
iRM Green2Yellow limit
60%
50%
40%
30%
20%
10%
0%
Pow er load Max
Codes Load Max
CEM Used Max
IUB Load
> Iub load curve represents the average Iub usage during each hour.
> Power, Codes and CEM Load curves present the Max load.
Power & Codes load is below iRM Green2Yellow threshold (50%)
CEM load is significantly high explaining the CEM blocking
IuB load is low but the Iub blocking is present > to be investigated
44

CEM Blocking vs. load (week11)
CEM Load vs CEM Blocking (w eek)
load (%)
90%
10
14/03
PS Blocking limit
80%
70%
60%
50%
40%
30%
20%
10%
0%
RB Estab Blocked by CEM
CEM Load Max (%)
RB Blocked
100%
CEM Used Avg (%)
> CEM Blocking is observed only when the PS384 & PS64 blocking limit is reached
this happens constantly during the loaded period of the week (working days)
> CEMAllocFail was < 1% during all this period as the number of CEM resources
request was much higher that the refusal > not a good indicator for CEM blocking
CEM Blocking limit is constantly reached during working days
45
Recommendation => plan to add CEM


Iub Blocking vs. load (week11)
Iub traffic: Real vs Estimated
3500
35
14/03
Peak of
PS384 Setup
on Cell U21
3000
30
25
cells/s
2500
20
2000
15
1500
Mostly
CS traffic
1000
10
500
RB Estab on current cell Blocked by Iub
ECR Estimated
RB Blocked
4000
ECR realy passed
> Important gap is seen between the real ECR and the ECR estimated by the RNC
> Configuring EBRs at AF 100% for the PS traffic (especially PS384) is creating
important false blocking.
> If the EBR cannot be reduced (transmission architecture constraints), additional
PCM is to be added on Iub.
EBRs for PS are overestimated possible parameters tuning

46
Alternative: additional PCMs
Agenda
> Introduction


> Conclusions
47
Conclusions
> Very high blocking was observed during the study (w10-w11). Important
part was coming from non-UTRAN causes.
> UTRAN Blocking is mainly due to Iub lack of bandwidth and CEM
resources.
> No blocking coming from OVSF Codes or RF Power was monitored.
> Resources load seems to be below the alarm limit for almost all BTS
(some exceptions for CEM). Planning exercise could be foreseen to
prepare for future traffic growth.
> Real load at Iub level is significantly lower than Estimated load due to
very conservative EBR Values:
EBR Values
DL RB
PS 64
PS 128
PS 384
ORF
69632
136832
408000
Operator 1 Operator 2
x 2/3
x 3/5
x 1/2
x1
x 3/4
x 1/2
> Consequence of Iub "virtual load" and Blocking is an iRM like mechanism
triggered at Core PS level forcing to lower PS RABs. In UA4.2 this system
behavior will negatively impact RB Adaptation feature.
48
Thanks for your patience!
49
50
ORF Capacity Monitoring Study

- Detailed presentation
Wireless Network Engineering
CTF/W20
51
Agenda
> Introduction & Executive summary

> Capacity Monitoring Use cases

> iRM & Benchmark
52

> Objective:
Networks have been deployed focusing on the service availability at the expense
of capacity
Traffic is growing constantly :
Traffic evolution during last 6 months
200000000
180000000
160000000
140000000
120000000
100000000
80000000
60000000
CS DL traffic KBytes
PS DL Traffic KBytes
15 A pr 06
8 A pr 06
1 A pr 06
2 5 -m a rs -0 6
1 8 -m a rs -0 6
1 1 -m a rs -0 6
0 4 -m a rs -0 6
25 Feb 06
18 F eb 06
11 F eb 06
4 Feb 06
2 8 -ja n v -0 6
2 1 -ja n v -0 6
1 4 -ja n v -0 6
31 Dec 05
24 D ec 05
17 Dec 05
10 Dec 05
3 Dec 05
2 6 -n o v -0 5
1 9 -n o v -0 5
1 2 -n o v -0 5
0 5 -n o v -0 5
2 9 -o c t -0 5
2 2 -o c t -0 5
1 5 -o c t -0 5
0 8 -o c t -0 5
0 1 -o c t -0 5
20000000
0 7 -ja n v -0 6
40000000
total PS + CS
Operators start to experience some congestion in their networks and foresee

further capacity issues.
They expect capacity analysis guidelines in order to be ready for capacity
planning.
> Scope:
This presentation has been prepared in the scope of UA4.1 pointing out also
possible UA4.2 evolutions (when the case)
53

> Study coverage
The capacity assessment is done for a period of two weeks: w10 &
w11
All the cells of the networks were analyzed (5495 cells)
All the RNCs (19 RNCs)
> Software release

Nortel OAM Release OAM5.0
Nortel UTRAN Release UA4.1 (17 RNCs) and UA4.2 (Lyonecul1 &
Lyontrio1)
> Elements of NodeB configuration:

Multi-carrier BTS : only some of the VO sites
54
X=1
X=2
X=3
X=4
BTS with X CEM
2058
28
BTS with X PCM
2060
29
Executive summary
> Very high blocking was observed during the study (w10-w11).
Important part was coming from non-UTRAN causes.
> UTRAN Blocking is mainly due to Iub lack of bandwidth and CEM
resources.
> Real load at Iub level is significantly lower than Estimated load due
to very conservative EBR Values.
> Consequence of Iub "virtual load" and Blocking is an iRM like
mechanism triggered at Core PS level forcing to lower PS RABs. In
UA4.2 this system behavior will negatively impact RB Adaptation
feature.
> No blocking coming from OVSF Codes or RF Power was monitored.
> Due to low load and blocking of Iub resources, the iRM @ CAC is
triggered only due to RL color.
> Reduction of AON T1 could be foreseen in order to gain extra
capacity
55
Agenda


> iRM & Benchmark
56
UTRAN congestion detection principles

> Principle of congestion
detection
Combination of blocking + load
indicators for a specific resource
Blocking?
> 3 states
=0
>0
No blocking No action
Blocking, low load Capacity
analysis and tuning required
Blocking + High load Capacity
analysis and tuning required
and/or resource addition
Load
Low
Status Yellow
Capacity analysis/tuning
High
Status Red
Capacity analysis/tuning
and/or
Resources addition
57
Status Green
No action required
Scope of
package
Blocking Characterization
> Blocking situation definition : each time the UE requests an UTRAN
resource and is not getting it because the resource is not available.
Call Phase
Blocking Cause
Effect
Monitoring detection
method
Call Admission
Lack of resources at
call setup
Call admission failure
- RB Establishment Unsuccess
Lack of resources to
perform iRM
transitions (AON
Upsize, iRM Sched
Upgrade)
Call is not reconfigured - RL Reconfiguration Unsuccess

(iRM Reconf)
(impact on user
throughput)
- RL Setup Unsuccess (AON)
Call
Reconfiguration
Mobility
- RL Reconfiguration Unsuccess
and Cancel
- AON/iRM Scheduling failure

counters
- RL Setup Unsuccess
No resources
Additional RL not
available for additional added in the Active Set - RL Addition Unsuccess
RL
(risk of call drop)
- RL & RB Reconfiguration
Unssuccess for HSDPA
This study is mainly focused on Blocking during Call Admission phase as it

is the most impacting for call success.
In general, if the call admission blocking is solved, the blocking on other call
phases is also solved (same bottlenecks involved).
58
Resources Load
Main possible bottleneck resources monitored at UTRAN Level:
> BTS Channel Elements - BTS Resource
The load can be monitored at BTS level

Blocking of this resource RB rejection or RL Setup/Addition/Reconfiguration
failures
> Iub ATM
The load can be monitored at BTS level (AAL2&AAL5 traffic)

alternative solution monitor the Traffic load per BTS at RNC level
> RF power - BTS Resource
The load can be monitored per cell via BTS or RNC counters
> OVSF Codes - RNC Resource
The load can be monitored per cell via RNC counters

> RNC CPU
59
The load can be monitored at card level through RNC counters

Blocking of this resource Overload mechanism => RB rejection
Agenda


> iRM & Benchmark
60
Congestion and Load on the Network

> Congestion at network level is evaluated through Blocking
Rate distribution per cell.
Blocking Rate per cell is computed as a ratio between the RB Blocking at
BH and RB Setup Request at BH for the entire observation period.
The BH is based on the most loaded Hour of the day in terms of Radio
Bearer Setup Request and it is calculated for each cell, each day. It can
be different for each cell, each day.
> Load is analyzed by bottleneck type at the BH of each Cell:

CEM Load through Max of CEMUsed.Avg&Max per cell at BH.
Iub Load through Max of Iub Load DL metric calculated per day
DL Power Load trough Tx Carrier Power Avg & Max at BH divided
by PA Power available@ref_point (calculated)
Codes load through Average of Free codes SF128 Min at BH metric
TMU load through Average and Maximum TMU Load for the entire
period (for each RNC)
> All metrics used will be available in a metric library to be

delivered with the study.
61
Congested cells @ Network level

Global Blocking
Blocking Rate at cell BH Distribution
4989
100%
4500
90%
4000
80%
3500
70%
2807
3000
2500
60%
50%
2102
2000
40%
1500
% of cells
5000
30%
1083
1000
20%
273
500
37
>7%
>10%
>20%
>30%
0
>=0%
>0%
>0,5%
>2%
>5%
10%
104
0%
Blocking rate > x %

Blocked cells Count
Blocked cells %
> Main contributor to this high blocking level was a Core CS dimensioning issue
(MSC Trion) which affected almost all Nortel RNCs.
> The rest is coming from Iub congestion.
62
Significant amount of blocking (> 2%) observed during w10 &

w11 at Cell BH for 22% of the cells
CEM load @ Network level

CEM Load Distribution (Avg & Max @ BH)
4979
4757
4757
4500
100%
90%
4144
4000
80%
3482
3500
70%
3000
60%
2717
2500
50%
2000
40%
1500
30%
1060
765
1000
500
20%
116
15
279
4
0
>10%
>20%
>30%
% of cells
5000
>40%
>50%
>60%
64
>70%
17
10%
>80%
>90%
0%
>95%
CEMUsed > x %
Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, most part of the CEMs were loaded in average
less than 50% (the attention limit)
> When investigating the Max CEMUsed for the same period, we can see that 64
cells (and the associated CEMs) exceeded the 70% load which represents the
upper blocking limit of PS384.
63
37 BTS (64 cells) are reaching the dangerous zone of the CEM
Iub load @ Network level

Iub real Load Distribution (Max@BH)
100%
4484
4500
90%
4000
80%
3500
70%
3016
3000
60%
2500
50%
2000
40%
1500
% of cells
5000
30%
1074
1000
20%
311
500
112
48
18
>20%
>25%
>30%
>35%
40%
10%
0%
>2%
>5%
>10%
>15%
Iub Load > x %

Max Load Count
Max Load (%)
> As it is based on a BTS counter, the monitored Iub load (@ BH) has to be seen
as the average load per hour. In the graph, the Max of these averages (for the
observation period) is captured.
Iub utilization is very low, not exceeding 35% of the Iub bandwidth.
This is not preventing from having Iub blocking as the admission
criteria is based on the estimated Iub load (at the RNC)
64
DL Power load @ Network level

DL RF Power Distribution (Avg & Max)
49574954
4780
4390
4500
100%
4326
90%
4000
80%
3500
70%
3080
3000
60%
2503
2500
50%
2000
40%
1486
1500
30%
1000
283
500
% of cells
5000
20%
514
83
26
151
12
45
10%
0%
>10%
>20%
>25%
>30%
>35%
>40%
>45%
>50%
>60%
>70%
>80%
DL Pow er Load > x %

Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, most part of the cells were loaded in average less
than 50%
> When investigating the Max load for the same period, we can see that only 1 cell
punctually exceeded 80% (Yellow2Red iRM power threshold).
DL power load is relatively low in the network. The loaded sites

being mostly sites from VO zone (JONAGE_COTTAGE, MEYZIEU_CARREAU,
MEYZIEU_GD_LARGE, MEYZIEU_OUEST) which use PA/2 (due to STSR2)
65
Codes load @ Network level

OVSF Codes Load Distribution (Avg & Max @ BH)
4933
4797
4873
100%
4500
90%
3746
4000
80%
3377
3500
70%
3000
60%
2500
50%
2000
40%
1352
1500
30%
745
1000
20%
459
500
% of cells
5000
93
54
10
12
10%
0%
>5%
>10%
>20%
>30%
>40%
>50%
>60%
>70%
>80%
Codes Load > x %

Max Load Count
Avg Load Count
Max Load (%)
Avg Load (%)
> During the Observation period, all the cells were loaded in average less than 50%
> When investigating the Max load for the same period, we can see that only 2 cells
punctually exceeded 70% (Yellow2Red iRM codes threshold).
66
Low codes load => only two cells being able to reach a max load
leading to a red iRM cell color.
RNC CPU load @ Network level

TMU load Avg & Max
100
90
80
TM U Load (%)
70
GRENOBLE1 Avg
60
GRENOBLE1 Max
LYONECUL1 Avg
50
LYONECUL1 Max
MONTPELL1 Avg
40
MONTPELL1 Max
30
20
10
0
13/3/ 13/3/ 13/3/ 13/3/ 14/3/ 14/3/ 14/3/ 14/3/ 15/3/ 15/3/ 15/3/ 15/3/ 16/3/ 16/3/ 16/3/ 16/3/ 17/3/ 17/3/ 17/3/ 17/3/ 18/3/
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00 6:00 12:00 18:00 0:00
> Only 3 RNCs are captured in this graph (3 most loaded from TMU point of view)
> For these 3 RNCs, the TMU load is remaining in acceptable limits:
Average < 20%

Max < 35% (the only exception is Montpell1 with some local issues on 15-03-06)
TMU load is far from being a concern for ORF network

67
Agenda


> iRM & Benchmark
68

> Counters Granularity: Hour
For each Cell : 4 metrics calculation
RbRejected@BH where BH=Hour[Max(RbSetReq)]
days
RbRejected@BkH where BkH=Hour[Max(RbRejected)]

days
RbRejected
days hour
BHBKRate(%) = RbRejected / RbSetReq (@BH)
N.B RbRejected corresponds to counter VS.RadioBearerEstablishmentUnsucces (without screening 0)
RbSetReq corresponds to counter VS.RadioBearerSetupRequest
Method aims to create a list of most representative cells in terms of

blocking by taking into account the amount of rejections at different
periods of the day but also the persistence in time of the issue.
69

CellsRanking
[ RbRejected]
day hour
CellsRanking
[RbRejected@BH]
Cells Filtering
[Condition1>X & Condition2>Y ]
X>Y
CellsRanking
[RbRejected@BkH]
Bottleneck Identification
[RbRejected Screening]
In our Study:
Obs.Period =14 days
X=7
Y=4
70
Final cells List to investigate


> Advantages:
Ranking is helping to focus on cells with important amount of traffic
and blocking (putting in lower priority low loaded cells or low blocked
cells) this step is not mandatory in case of a day bay day monitoring
the temporal factor is considered during the filtering only cells with
constant blocking are picked up
The double filter, even it is not mandatory (simple filter could be
enough for most of the cases), add to detect cells exceeding a given
threshold (condition 1) and also cells with constant load (condition 2)
> Drawback:
only blocking at BH global (CS+PS) is considered risk to focus loose
one blocking period if the BH PS BH CS
=> The method can be improved by analyzing two different BH (CS&PS)
71
Top N most congested cells

identification - Result
Cell
DJN_HAVRE_U11
BOURGOIN_EST_U11
BIONNE_TDFT_U31
ST_ETN_GARE_U11
GRE_EUROPOLE_U11
FERREOL_U31
ECHIROLLES_U11
FERREOL_U11
GRE_JEAN_JAURES_U11
BEAUREGARD_U21
ECHIROLLES_U31
AIX_CARCASSONNE_U21
FONTAINE_CHARM_U21
GRE_EUROPOLE_U21
DJN_CFRT_U11
DJN_HAVRE_U21
GRE_JEAN_JAURES_U31
RABATEAU_U31
GRE_AMPERE_DRAC_U11
SALON_SUD_U31
BEAUREGARD_U31
ALLAUCH_U31
VIENNE_PIPET_U11
GARIBALDI_U11
MARSEILLE_PARTY_U21
FONTAINE_OUCHE_U31
TERRON_U21
GRE_EAUX_CLAIR_U31
BIONNE_TDFT_U21
GRE_AMPERE_DRAC_U21
SEYSSINET_NORD_U11
TOUR_PIN_U31
CROLLES_U11
TRAMOYES_U31
CORDERIE_U11
DJN_MARCS_OR_U21
LES_CHARTREUX_U21
DJN_VICTOR_HUGO_U11
GRE_ABBAYE_U31
MAUGUIO_U31
ST_JEROME_U31
AIGUELONGUE_U11
DJN_HAVRE_U31
72
BK Day
Setup Day
Bk rate day
Bk & BH
Setup & BH
Bk rate BH
Bk & BkH
Setup & BkH
Bk rate BhK
796
515
279
338
504
297
317
245
267
247
279
179
249
172
193
310
144
161
145
161
215
122
145
133
135
97
114
107
101
113
103
99
95
128
98
107
112
122
83
85
84
78
77
140
79
70
99
61
74
69
64
58
58
85
75504
23104
21612
27698
1962
20546
20132
17564
17850
20098
7600
12697
5761
13129
14707
4504
11916
13154
9049
14210
10344
8082
8726
10587
9464
9278
5931
8335
10379
9373
7631
8565
9542
995
6121
7513
8915
10167
7014
8765
6999
5121
5500
3911
3923
8143
3248
8044
8775
6977
4713
3889
5308
3788
1,1%
2,2%
1,3%
1,2%
25,7%
1,4%
1,6%
1,4%
1,5%
1,2%
3,7%
1,4%
4,3%
1,3%
1,3%
6,9%
1,2%
1,2%
1,6%
1,1%
2,1%
1,5%
1,7%
1,3%
1,4%
1,0%
1,9%
1,3%
1,0%
1,2%
1,3%
1,2%
1,0%
12,9%
1,6%
1,4%
1,3%
1,2%
1,2%
1,0%
1,2%
1,5%
1,4%
3,6%
2,0%
0,9%
3,0%
0,8%
0,8%
1,0%
1,4%
1,5%
1,1%
2,2%
230
142
188
124
143
101
81
105
80
86
86
103
76
100
76
70
74
84
59
58
52
73
55
58
48
62
52
52
49
54
60
51
51
43
60
43
41
40
38
44
35
37
47
20
33
35
25
29
32
37
41
29
36
21
6126
2382
2313
2797
370
2483
2054
2036
1949
2213
818
1369
713
1378
1690
739
1393
1524
1034
1457
1101
1029
1035
1107
1118
1056
730
1052
1179
1063
844
998
1506
263
724
1106
971
1191
1023
1040
758
594
644
515
609
959
453
821
993
788
578
547
621
484
3,8%
6,0%
8,1%
4,4%
38,6%
4,1%
3,9%
5,2%
4,1%
3,9%
10,5%
7,5%
10,7%
7,3%
4,5%
9,5%
5,3%
5,5%
5,7%
4,0%
4,7%
7,1%
5,3%
5,2%
4,3%
5,9%
7,1%
4,9%
4,2%
5,1%
7,1%
5,1%
3,4%
16,3%
8,3%
3,9%
4,2%
3,4%
3,7%
4,2%
4,6%
6,2%
7,3%
3,9%
5,4%
3,6%
5,5%
3,5%
3,2%
4,7%
7,1%
5,3%
5,8%
4,3%
516
227
227
224
158
193
192
185
164
151
117
124
129
125
124
112
143
111
107
100
85
92
92
93
94
96
82
81
88
76
76
81
82
72
71
77
67
65
88
58
62
62
53
64
57
62
55
77
54
50
50
61
51
41
4638
2045
1909
2352
314
1782
1507
1559
1519
1740
651
954
539
1124
1265
431
1040
1045
843
1062
897
690
809
838
627
672
532
858
727
804
619
720
747
157
507
633
710
786
572
709
542
394
357
275
430
693
271
514
655
443
433
321
457
334
11,1%
11,1%
11,9%
9,5%
50,3%
10,8%
12,7%
11,9%
10,8%
8,7%
18,0%
13,0%
23,9%
11,1%
9,8%
26,0%
13,8%
10,6%
12,7%
9,4%
9,5%
13,3%
11,4%
11,1%
15,0%
14,3%
15,4%
9,4%
12,1%
9,5%
12,3%
11,3%
11,0%
45,9%
14,0%
12,2%
9,4%
8,3%
15,4%
8,2%
11,4%
15,7%
14,8%
23,3%
13,3%
8,9%
20,3%
15,0%
8,2%
11,3%
11,5%
19,0%
11,2%
12,3%
rank
1
3
6
6
7
9
12
12
16
17
21
22
22
23
25
26
31
31
43
44
52
52
53
55
61
70
74
78
79
81
83
86
87
89
91
92
105
106
115
140
154
159
168
173
177
177
185
189
195
208
211
224
234
272
days with
Bk>2%
4
7
7
5
8
4
4
6
5
5
8
7
8
6
5
11
6
6
5
4
7
6
6
6
7
5
7
7
7
5
7
5
6
11
7
6
6
6
5
6
5
7
7
7
7
6
8
6
4
7
9
6
7
6
days with
Bk>0%
7
8
9
10
8
7
7
7
7
8
8
9
9
9
7
11
7
7
8
7
9
7
7
8
9
7
8
9
7
7
7
8
7
11
7
7
9
7
7
9
7
7
7
7
7
7
8
7
7
7
9
7
7
7
Two filter criteria are

used:
period
period
The rank is calculated
following Step 1
54 regularly
blocked
cells with
high impact
on user
perception
The different blocking causes to be investigated are identified
through VS.RadioBearerEstablishmentUnsuccess screenings)
Scr. 0: invalid RAB parameters value not to be considered as blocking

cause, thus not taken into account in the blocking rate computation
Scr. 1: unavailable dl code resources Code shortage indication
Scr. 2: unavailable dl power resources DL power shortage indication
Scr. 3: Unspecified covers CEM resources and other possible issues during
call setup (Core Network UP Init. failures...)
Scr. 4: Lack of bandwidth Iux bandwidth allocation shortage (all interfaces:
Iub/Iu/Iux) this screening is replaced by screenings #10, #12 and #14 in
UA04.2
Scr. 5: Lack of CID Iux CIDs allocation shortage (all interfaces: Iub/Iu/Iux)
this screening is replaced by screenings #9, #11 and #13 in UA04.2
Scr. 6: CAC RNC Processing resources TMU resources shortage (overload
situations)
Scr. 9: Lack of CID on the Iu introduced in UA04.2
Scr. 10: Lack of bandwidth on the Iu introduced in UA04.2
Scr. 11: Lack of CID on the Iur introduced in UA04.2
Scr. 12: Lack of bandwidth on the Iur introduced in UA04.2
Scr. 13: Lack of CID on the Iub introduced in UA04.2
Scr. 14: Lack of bandwidth on the Iub introduced in UA04.
73
Bottlenecks identification - Result

Cell
DJN_HAVRE_U11
BOURGOIN_EST_U11
BIONNE_TDFT_U31
ST_ETN_GARE_U11
GRE_EUROPOLE_U11
FERREOL_U31
ECHIROLLES_U11
FERREOL_U11
GRE_JEAN_JAURES_U11
BEAUREGARD_U21
ECHIROLLES_U31
AIX_CARCASSONNE_U21
FONTAINE_CHARM_U21
GRE_EUROPOLE_U21
DJN_CFRT_U11
DJN_HAVRE_U21
GRE_JEAN_JAURES_U31
RABATEAU_U31
GRE_AMPERE_DRAC_U11
SALON_SUD_U31
BEAUREGARD_U31
ALLAUCH_U31
VIENNE_PIPET_U11
GARIBALDI_U11
MARSEILLE_PARTY_U21
FONTAINE_OUCHE_U31
TERRON_U21
GRE_EAUX_CLAIR_U31
BIONNE_TDFT_U21
GRE_AMPERE_DRAC_U21
SEYSSINET_NORD_U11
TOUR_PIN_U31
CROLLES_U11
TRAMOYES_U31
CORDERIE_U11
DJN_MARCS_OR_U21
LES_CHARTREUX_U21
DJN_VICTOR_HUGO_U11
GRE_ABBAYE_U31
MAUGUIO_U31
ST_JEROME_U31
AIGUELONGUE_U11
DJN_HAVRE_U31
74
BK Day
Setup Day
Bk rate day
Bk & BH
Setup & BH
Bk rate BH
796
515
279
338
504
297
317
245
267
247
279
179
249
172
193
310
144
161
145
161
215
122
145
133
135
97
114
107
101
113
103
99
95
128
98
107
112
122
83
85
84
78
77
140
79
70
99
61
74
69
64
58
58
85
75504
23104
21612
27698
1962
20546
20132
17564
17850
20098
7600
12697
5761
13129
14707
4504
11916
13154
9049
14210
10344
8082
8726
10587
9464
9278
5931
8335
10379
9373
7631
8565
9542
995
6121
7513
8915
10167
7014
8765
6999
5121
5500
3911
3923
8143
3248
8044
8775
6977
4713
3889
5308
3788
1,1%
2,2%
1,3%
1,2%
25,7%
1,4%
1,6%
1,4%
1,5%
1,2%
3,7%
1,4%
4,3%
1,3%
1,3%
6,9%
1,2%
1,2%
1,6%
1,1%
2,1%
1,5%
1,7%
1,3%
1,4%
1,0%
1,9%
1,3%
1,0%
1,2%
1,3%
1,2%
1,0%
12,9%
1,6%
1,4%
1,3%
1,2%
1,2%
1,0%
1,2%
1,5%
1,4%
3,6%
2,0%
0,9%
3,0%
0,8%
0,8%
1,0%
1,4%
1,5%
1,1%
2,2%
230
142
188
124
143
101
81
105
80
86
86
103
76
100
76
70
74
84
59
58
52
73
55
58
48
62
52
52
49
54
60
51
51
43
60
43
41
40
38
44
35
37
47
20
33
35
25
29
32
37
41
29
36
21
6126
2382
2313
2797
370
2483
2054
2036
1949
2213
818
1369
713
1378
1690
739
1393
1524
1034
1457
1101
1029
1035
1107
1118
1056
730
1052
1179
1063
844
998
1506
263
724
1106
971
1191
1023
1040
758
594
644
515
609
959
453
821
993
788
578
547
621
484
3,8%
6,0%
8,1%
4,4%
38,6%
4,1%
3,9%
5,2%
4,1%
3,9%
10,5%
7,5%
10,7%
7,3%
4,5%
9,5%
5,3%
5,5%
5,7%
4,0%
4,7%
7,1%
5,3%
5,2%
4,3%
5,9%
7,1%
4,9%
4,2%
5,1%
7,1%
5,1%
3,4%
16,3%
8,3%
3,9%
4,2%
3,4%
3,7%
4,2%
4,6%
6,2%
7,3%
3,9%
5,4%
3,6%
5,5%
3,5%
3,2%
4,7%
7,1%
5,3%
5,8%
4,3%
rank
1
3
6
6
7
9
12
12
16
17
21
22
22
23
25
26
31
31
43
44
52
52
53
55
61
70
74
78
79
81
83
86
87
89
91
92
105
106
115
140
154
159
168
173
177
177
185
189
195
208
211
224
234
272
Blocking Cause
Unspecified
Unspecified
Unspecified
LackOfBandwidth
Unspecified
LackOfBandwidth
LackOfBandwidth
Unspecified
Unspecified
LackOfBandwidth
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
LackOfBandwidth
Unspecified
LackOfBandwidth
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
Unspecified
days with
Bk>2%
4
7
7
5
8
4
4
6
5
5
8
7
8
6
5
11
6
6
5
4
7
6
6
6
7
5
7
7
7
5
7
5
6
11
7
6
6
6
5
6
5
7
7
7
7
6
8
6
4
7
9
6
7
6
days with
Bk>0%
7
8
9
10
8
7
7
7
7
8
8
9
9
9
7
11
7
7
8
7
9
7
7
8
9
7
8
9
7
7
7
8
7
11
7
7
9
7
7
9
7
7
7
7
7
7
8
7
7
7
9
7
7
7
Main observations:
- Practically no DL
Power or Codes
blocking monitored
during Obs. Period.
(this is specific to the
entire network, not
only TopN list)
- Unspecified &
LackOfBandwidth are
the only blocking
causes monitored in
the network.
Agenda


> iRM & Benchmark
75
Bottleneck analysis
RB Allocation Procedure (1/2)
UE
Node B
RNC
CN - CS
RAB Assignment Request
1
2
CAC
Radio Link Reconfiguration Prepare
Radio Link Reconfiguration Ready
4
5
UP / DL Synchronization
UP / UL Synchronization
AAL2 / ERQ
AAL2 / ECF
UP / Initialization
UP / Initialization Ack.
Radio Link Reconfiguration Commit
Radio Bearer Setup

Radio Bearer Setup Complete
8
76
RAB Assignment Response
Bottleneck analysis
RB Allocation Procedure (2/2)
1
#0625 - RB Setup Request (Downlink Access Stratum)
#0631.0 - RB Establishment Unsuccess cause Invalid RAB parameters value
#0631 - RB Establishment Unsuccess

1 - Unavailable code resource
2 - Unavailable Power resource
4 - Lack of bandwidth (replaced by screenings #10, #12 and #14 in UA04.2)
5 - Lack of CID (replaced by screenings #9, #11 and #13 in UA04.2)
6 - RNC Processing resources
9 - Lack of CID on IU (introduced in UA04.2)
10 - Lack of bandwidth on IU (introduced in UA04.2)
11 - Lack of CID on IUR (introduced in UA04.2)
12 - Lack of bandwidth on IUR (introduced in UA04.2)
13 - Lack of CID on IUB (introduced in UA04.2)
14 - Lack of bandwidth on IUB (introduced in UA04.2)
#0023 Radio Link Reconfiguration Request (Downlink Access Stratum) (introduced in UA04.2)
5 #0007 - Radio Link Reconfiguration Success (Downlink Access Stratum)
#0008 - Radio Link Reconfiguration Prepare Unsuccess
0 - Reception of RL Reconfiguration Failure
1 - Time-out
2 - Rrm refusal (ie: no more power available, no more code available, ...)
3 - I-Node refusal (replaced by screenings #6, #7 and #8 in UA04.2)
6 - Lack of CID on the Iub (introduced in UA04.2)
7 - Lack of bandwidth on the Iub (introduced in UA04.2)
8 - I-Node refusal (ie: other I-Node resource not available ...) (introduced in UA04.2)
77
#0631.3 - RB Establishment Unsuccess cause Unspecified
#0010 - Radio Link Reconfiguration Commit (Downlink Access Stratum)

#0009 - Radio Link Reconfiguration Cancel (Downlink Access Stratum)
#0601 - Radio Bearer Setup Success (Downlink Access Stratum)

#0602 - Radio Bearer Setup Unuccess (Failure cause)
Bottleneck analysis
Unspecified
Blocking detection
> The Unspecified RB Establishment Unsuccess is not always directly

linked to a specific UTRAN bottleneck, thus the association with the load
is not obvious for this blocking cause.
> This blocking cause is identified through screening Unspecified of the
VS.RadioBearerEstablishmentUnsuccess counter - See bullet 6 in the RB
Allocation Procedure Data Flow Diagram.
> It covers the following Call Setup failures causes:
CEM resources shortage
User Plane Initialization failure between RNC and Core Network (Iu issues).
From UA4.2 the HSDPA CAC rejected calls are also pegging this counter.
> In general, it is a good method to detect the CEM resources shortage as

the CEMAllocFail counter has some limitations (see CEM analysis).
> HSDPA CAC is also pegging the UnsuccesfulHsdpaCac counter (#0958)
78
Bottleneck analysis
Unspecified
no
Unspecified > 0
Stop
yes
RL Reconfiguration Prepare Unsuccess

RLReconfFailure RB Establishment Unsuccess
Unspecified
no
RL Reconfiguration Cancel > 0
Unspecified
no
Unsucc. HSDPA CAC > 0
Unspecified
79
yes
yes
Call allocation failure due to lack of CEM resources

(HBBU or DBBU) => relay on CEM Bottleneck analysis
Possible RNC - Core Network UPlane initialization issues. Confirmed if

the issue occurs on several BTSs of the same RNC (depending on their
traffic load).
It is possible to identify the Core domain generating the issue by
checking the RadioLinkReconfigurationCancel.DlAccessStratumConf5 for CS or
DlAccessStratumConf2/6/7 for PS
Check Core Network Counters & Alarms for more details
yes
The HSDPA limit of 20 UEs per cell is reached (HSDPA CAC)

Bottleneck analysis
Unspecified
RadioBearerEstablishmentUnsuccess.Unspecified vs. RadioLinkReconfigurationCancel
Example
> During observation period (w10 &
w11) a large amount of
160
140
120
VS.RadioBearerEstablishmentUnsuccess.Un
specified was monitored on a large
number of ORF BTSs. It was

perfectly correlated with the
100
80
60
40
VS.RadioLinkReconfigurationCancel:
20
> The investigations showed that only
VS.RadioLinkReconfigurationCancel.DlAcce
ssStratumConf5 (CS voice) was
pegged, thus a possible issue

between RNC and the Core CS.
VS.RadioBearerEstablishmentUnsuccess.Unspecified
7000
> When investigated at RNC level, the

issue was more visible on 6 RNCs
connected to the same MSC (and
probably to the same ALI board)
> The issue disappeared after some
operations of MSC side (RNC
reparenting & ALI redimensioning) but
it seems to be back again after 3
weeks (to be checked):
80
VS.RadioBearerEstablishm entUnsuccess.Unspecified
6000
5000
GRENOBLE1
4000
MARSESTM2
MONTPELL1
MARSESTM1
3000
DIJONC1
TOULON_SF1
2000
1000
Bottleneck analysis
Blocking Detection
>
The CEM blocking is particular annoying as this resource is not managed

by the RNC. Thus, if no CEM resources available, the call is released (no
iRM downgrade based on this resources load is possible until UA5.0)
>
Call admission blocking due to CEM resources shortage can be detected

by two methods:
1. Using the VS.RadioBearerEstablishmentUnsuccess.Unspecified counter

see the Unspecified analysis above.
2. Using BTS counter CEMAllocFail. Method drawbacks:
>
This counter provides the % of CEM resources requests that are refused from
total CEM resources requests. All requests are considered: RL Setup SRB or
TRB, RL Reconfiguration Up or Down thus it will be slightly incremented even
in case of high blocking.
It is rounded to Integer (if 0.8% is calculated => 0% is displayed)
Recommendation: use the first method and only confirm (if it is the case)
with the CEMAllocFail method.
81
Bottleneck analysis
> CEM load (DBBU) is measured by means of CEMUsed (BTS counter)
>
The CEMUsed screenings (Avg, Min, Max.) allows to:
>
Min during the night it will provide info on Common Channels utilization (usually 18% for
STSR1 on 1 iCEM64)
Avg Average load during one Hour used for dimensioning purposes
Max allows to determine the moments when the alarm thresholds were exceeded
triggering blocking.
RAB Type (UL/DL)
Block. thresholds
CEMUsed booking levels for

the most used RABs in ORF
in case of 1 iCEM64:
CS 12.2/12.2
98%
PS 64/64, 128/128, 128/384, 128/0

(HSDPA)
85%
PS 64/384
72%
PS 384/0 (HSDPA)
65%
>
Recommendation: set an Yellow alarm monitoring trigger for CEMUsed.Avg

exceeding 50% and a red one for CEMUsed.Max exceeding constantly 70%.
>
CEM load (HBBU) cannot be directly monitored in UA4.2. Alternative through

DlAsConfIdAvgNbrEstab.Max is proposed (next slide). Complete solution in UA5.0
82
Bottleneck analysis
no
Unspecified analysis
shows CEM blocking
Stop
yes (Optional)
yes
CEMAllocFail >
Call allocation
failure due to
lack of CEM
CEMUsed.Max
> 70%
yes
CEM (DBBU) resources
83
no
CEMAllocFail could display 0 even with

High PS blocking if there are many
resources requests that are accepted (small
RABs) => continue CEM investigation
yes
no
UA4.2
UA5.0
MAX
[DlAsConfIdAvgNbrEstab.Max
HsdpaUesperHbbu.Max
=X
(scr.27)] ~ X
yes

CEM (HBBU) resources
no
-Potential issues with CEM configuration
(check CCP configuration).
- STSR2 is activated and the traffic is
unbalanced between frequencies => Add
additional CEM resources
X = 20 (UA4.2)
X = 48 (UA5.0)
Bottleneck analysis
Iub Interface
Blocking Detection
> The Iub resources management is done at RNC Level. From UA4.2 this
resource will be taken into account in the iRM @ CAC mechanism.
> Call admission blocking due to Iub resources shortage can be detected
through the counter:
VS.RadioBearerEstablishmentUnsuccess.LackOfBandwidth & LackOfCid

In UA4.1 this counter is not making the difference between different Iux interfaces,
thus additional check is needed => if problem is seen only on some (isolated)
BTSs, then it is an Iub problem.
From UA4.2, specific screenings per Iux interface will be available (better
precision during bottleneck identification phase)
> Additional indication about call admission blocking and iRM upgrade
procedures fail due to lack of Iub resources is provided by:
VS.RadioLinkReconfigurationPrepareUnsuccess.INodeRefusal (enhanced by
two new screenings in UA4.2 LackBwthIub & LackCid)
> When the mobility is affected by the lack of Iub resources the following
counter will be pegged: VS.RadioLinkSetupUnsuccess.INodeRefusal
(enhanced by two new screenings in UA4.2 LackBwthIub & LackCid)
84
Bottleneck analysis
Iub Interface
> Iub Load indicators available in UA4.1:

Real load of the Iub calculated from BTS Transport counters (average/hour):
Monitored_Iub_Load = (VS.AAL2NbReceivedCell + VS.AAL5NbReceivedCell) / 4528
The Iub Load estimated by the RNC and used by iRM CAC:
RNC_Estimated_Iub_load = ( RadioLinkEstablishedPerCell.Avg) * ECR * SrHO% (at cell level)
The ECRs are calculated from configured EBRs.
> If the EBR configuration is very conservative (AF 100% considered for all
RBs, especially the big PS RBs), the gap between the Monitored_Iub_Load
and RNC_Estimated_Iub_load will be important and the blocking will be seen
with very low Iub traffic (currently the case in ORF).
> From UA4.2, the real Iub load is taken into consideration in the iRM and it
will be possible to monitor the percentage of time a certain load level was
reached through iRM specific counters:
#1155 VS.IRMTimeCellDlIubTransportColorYellow (recommended threshold @ 70%)
#1148 VS.IRMTimeCellDlIubTransportColorRed (recommended threshold @ 90%)
85
Bottleneck analysis
Iub Interface
LackOfBandwidth will be replaced in UA4.2 by
LackOfBandwidthOnIu
LackOfBandwidthOnIur
LackOfBandwidthOnIub
And Lack of CID
LackOfCidOnIu
LackOfCidOnIur
LackOfCidOnIub
no
Lack of bandwidth > 0

Or
Lack of CID > 0
yes
Call allocation failure
due to Iub Lack of
bandwidth or CIDs
yes (optional)

INodeRefusal RB Establishment Unsuccess
LackOfBandwidth
yes
failure due to lack of Iub Resources
Monitored_Iub_Load ~
IRMTimeCellDlIubTransportColorRed X%
RNC_Estimated_Iub_load?
yes
PCM resources
86
RadioLink Reconfiguration Prepare Unsuccess

INodeRefusal will be completed in UA4.2 with:
LackBwthIub
LackOfCid
Stop
no
UA4.2
UA4.1
no
Transport configuration
allows EBR Tuning?
- X can vary with EBR config., traffic type

(R99/HSDPA) and Y2R/R2Y Iub
thresholds
- For R99, EBR at max and Y2R/R2Y Iub =
90%/80%, X is expected to be 1%
Additional analysis is needed for HSDPA
yes
Do EBR Tuning
Bottleneck analysis
BTS DL RF Power
Blocking Detection
>
The DL Power management is done by the RNC. This resource is taken

into account in the iRM @ CAC mechanism (the blocking due to this
resource can be controlled through cell color thresholds).
>
Call admission blocking due to DL RF Power shortage can be detected

through the counter: VS.RadioBearerEstablishmentUnsuccess.
UnavailableDlPowerResources.
>
Additional indication about call admission blocking and iRM upgrade

procedures fail due to lack of power is provided by:
VS.RadioLinkReconfigurationPrepareUnsuccess.RrmRefusal
>
When the mobility is affected by the lack of power the following counter
will be pegged: VS.RadioLinkSetupUnsuccess.RrmRefusal
>
The RrmRefusal cause is also covering the lack of OVSF codes

resources.
87
Bottleneck analysis
BTS DL RF Power
>
Power utilization is measured by means of VS.AvgTxPower counter
>
Power usage is computed based on PA_Power @ Reference point

Power_Load (%) = VS.AvgTxPower / PA_Power@Refpoint
PA_Power@Refpoint = maxPowerAmplification TotalLoss
>
Call Admission is applied on 85% of Power_Traffic:

Power_Traffic= PA_Power@Refpoint Power_Common_Channel
>
For details on maxPowerAmplification, TotalLoss & Power Common

Channel computation see UPUG
>
Recommendation: set an alarm monitoring trigger for Power_Load Max

(based on VS.AvgTxPower.Max) exceeding constantly 80%
88
Bottleneck analysis
BTS DL RF Power
UnavailableDlPowerResources > 0
no
Stop
yes (optional)
yes

RrmRefusal > RB Establishment Unsuccess
UnavailableDlPowerResources
yes
Call allocation failure due to
lack of DL Power resources

failure due to lack of DL Power resources
Power_Load.Max (%) > 80 %
Power_Load % = VS.AvgTxPower / PA_Power@Refpoint

PA_Power@Refpoint = Min(PAMax Loss, MaxTxPower)
yes
- Reduction of iRM Power Thresholds
- Tuning of Power allocation of Radio Bearer
- Tuning of Power allocation of common Channels
- Add a new capacity Layer
89
Bottleneck analysis
OVSF Codes
Blocking Detection
>
The OVSF codes management is done by the RNC. This resource is taken
into account in the iRM @ CAC mechanism (the blocking due to this
resource can be controlled through cell color thresholds).
>
Call admission blocking due to OVSF Codes shortage can be detected

through the counter: VS.RadioBearerEstablishmentUnsuccess.
UnavailableDlCodeResources.
>
Additional indication about call admission blocking and iRM upgrade

procedures fail due to lack of codes is provided by:
VS.RadioLinkReconfigurationPrepareUnsuccess.RrmRefusal
>
When the mobility is affected by the lack of codes the following counter will
be pegged: VS.RadioLinkSetupUnsuccess.RrmRefusal
>
The RrmRefusal cause is also covering the lack of DL Power resources.
90
Bottleneck analysis
OVSF Codes
>
Codes load is measured by means of
VS.IRMTimeFreeDlCodesBySpreadingFactor counter. It is recommended to
use SF128 as it has a better granularity.

>
Following metric is to be used to monitor the Codes load:

128_Codes_load (%) = (128 - VS.IRMTimeFreeDlCodesBySpreadingFactor.128) / 128
>
The VS.IRMTimeFreeDlCodesBySpreadingFactor screenings (Avg, Min,

Max.) allows to:
>
Max during the night it will provide info on Common Channels utilization
(usually 3-4%)
Min allows to determine the moments when the alarm thresholds were
exceeded triggering blocking.
OVSF Codes booking levels for

the most used DL RBs in ORF:
91
RB Type (DL)
SF128_Blocking threshold
CS12.2
99%
PS 64
97%
PS 128
90%
PS 384
78%
Bottleneck analysis
OVSF Codes
UnavailableDlCodeResources > 0
no
Stop
yes (optional)
RrmRefusal > RB Establishment Unsuccess
UnavailableDlCodeResources
yes
yes
Call allocation failure due
to lack of OVSF codes
128_Codes_load_Max (%) >
75%
yes
frequency (additional
codes tree)
92

failure due to lack of OVSF codes
yes (optional)
iRM threshold for codes (green2Yellow &
yellow2RedCLCThreshold) reduction is another
alternative but it has to be correlated with operator
strategy against user service quality
Bottleneck analysis
Blocked traffic investigation
> Even it is an optional step in the capacity bottlenecks study, it
is an important pointy of investigation which can provide
important information on the cause and the source of
blocking.
> Once the bottleneck identified, the blocking investigation can
be pushed further by analyzing the difference:
VS.RadioBearerSetupRequest.DlAccessStratumConfX VS.RadioBearerSetupSuccess.DlAccessStratumConfX (X from 0 to 29)
> This will reveal the RB blocked an can indicate some actions
to take:
If CS is blocked, there is not too much tuning to perform resources
addition is needed.
If PS is blocked there is still iRM tuning to foresee before deciding to
add resources.
93
Agenda


> iRM & Benchmark
94

95

Summary
> Site to be analyzed : ST_ETN_GARE
> Cell : ST_ETN_GARE_U11
> Capacity Analysis:
-
One day from the Obs. period (14/03) is chosen for detailed analysis
Blocking causes identification: LackOfBandwidth & Unspecified
Bottlenecks identification: Iub & CEM
Traffic analysis:
High amount of PS traffic : 9 Erl /BH (several hours) & 166 Kbps @BH
PS384 main traffic: Setup/Request = 77/179 = 43% admission / day /site
PS384 converted to PS64 due to Iub blocking: 80 (44%) / day /site
PS384 lost due to Iub blocking: 22 (13%) / day /site
- Recommendations for this site:

- Tuning EBRs or add PCM
- add CEM
96

RB Blocking Rate at BH (ST_ETN_GARE_U11)
70%
Blocking (%)
50%
60
Day chosen for

detailed analysis
50
40%
40
30%
30
20%
20
10%
10
0%
Nb of RBs
60%
70
RB Blocking Rate at BH
RB Blocked at BH
> Cell very blocked during the entire week (exception being the week-end)
97
14/03 is chosen for deeper analysis the Blocking rate is

not the highest at this date, but the cell has the highest
number of RB Setup Requests and RB Blocking.

Blocking causes identification (ST_ETN_GARE_U11)
40
35
35
32
30
29
27
25
RBEstablishmentUnsuccess - total
Peaks of
Lack of Bandwidth
& Unspecified
20
RBEstablishmentUnsuccess.UnavailableDlCodeResources
RBEstablishmentUnsuccess.UnavailableDlPow erResources
15
13
12
12
13
10
8
5
0
4
3
1
5
4
3
3
2
2
1
1
1
1
1
0
00
0
0
0
0
0
0
0
0
0
0
0
00
0
0
00
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
> High rate of Lack of Bandwidth is observed:

From UA4.2 Iub/Iu/Iur specific screenings will be available.
> A second cause of blocking is Unspecified:

blocking (see next slide)
98


35
31
30
28
29
27
25
RLReconfPrepareUnsuccess.RadioLinkReconfigurationFailure
20
RLReconfPrepareUnsuccess.INodeRefusal
15
13
13
12
12
10
14
12
8
5
7
6
3
4
2
2
1
1
11
1
0
0
0
0
0
0
0
00
0
0
0
00
0
0
0
00
0
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
3
> RL Reconfiguration Cancel is 0, so no Core Network issues are foreseen

> RL Reconfiguration is failing in the Preparation phase:
Cause INodeRefusal is confirming the Iux lack of bandwidth (linked to
LackofBandwidth cause)
=>As the issue is not seen on the entire RNC we can conclude that Iux = Iub
Cause RadioLinkReconfigurationFailure confirms a lack of resources at NodeB
level (generally caused by CEM resources).
Iub and CEM blocking are confirmed

99

Blocked traffic type identification
Rejected Traffic vs Blocking
30
25
21
Nb of RBs
20
17
16

RB Setup Unsucc CS
15

10
10
11
10
7
6
5
2
00
00
00
00
00
00
00
00
2
0
1
0
3
2
22
00
4
2
00
00
00
00
> RB Setup Unsuccess is calculated per RB type as difference between RB Setup

Request and RB Setup Success.
> The CS and PS128 traffic are practically not blocked
CS is a small RB which passes even if high blocking is present at Iub and CEM level.
PS128 no blocking as very few requests are present.
The only traffic blocked is the PS384 and PS64
100

Max RL Establsihed vs Blocking
12
35
Peak of PS384
call duration (700s)
10
9
8
30
9
25
Nb of RL
20
6
5
15
Max of 3 PS384
4
3
3
2
22
1
0
0
01:00
10
2
00:00
02:00
Max Nb of RL PS64
1
0
03:00
1
0
04:00
00
00
00
05:00
06:00
07:00
Max Nb of RL PS384
2
1
1
00
08:00
Max Nb of RL CS
09:00
10:00
11:00
Max Nb of RL PS128
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
>
The max of 3 PS384 accepted by the Iub (with the current EBR configuration) is reached
during 4 hours only in the observed cell (not counting the traffic in other cells).
>
This is combined with a high PS384 Call duration (200 s in average, 700s peak at 14h00)
>
The Iub capacity with the current

EBR config - see tables:
101
if x PS384
1
2
3
PS64 ?
15
9
3
PS128?
7
4
1
if x PS64
7
8
9
10
PS128?
7
6
6
5
PS384?
2
2
2
1
Iub limit is reached constantly during the day => blocking

23:00
RB Blocked
10

Traffic blocking consequences
PS64 Setup correlation with Iub Blocking
30
25
20
15
10
RB Setup Request PS64
> Due to rapid blocking at Iub level (max 3 PS384 per Iub with 1 PCM), a
RB Reallocation mechanism is triggered at Core PS level (see details in
next slide). Due to this mechanism, a PS384 failed setup is replaced by a
PS64 RB request.
This mechanism is allocating a lower PS RAB (PS64) maintained

during entire call duration (not eligible to any iRM Upgrade) => user
perception: Good for call admission but Bad for service quality
102

RequestedUEMaximum
Bit Rate not Available
(20)
Node B
RNC
CN - PS
PS call initial connection (RRC phase)

PS call RAB allocation phase starts with PS384
No Ressources
RAB Assignment Response (Fail: 20)
PS call RAB allocation phase continue with PS64
> If no resources are available at RNC level, the RB Assignment Request

(for PS384 or PS128) is answered with a RAB Assignment Response
(Fail: 20) which is immediately followed by a new request for a lower RAB
(instead of Iu Release Command)
to be confirmed if it works only with Iub or all other resources managed by
RNC (Codes & Power)
It not works with the CEM resources which are managed by the BTS.
Using this Core PS mechanism is helpful to reduce Iub blocking,

but it will work against RB adaptation feature (UA4.2) allocated
RB will not be eligible to any upgrade.
103

Load per Resource type
100%
90%
14/03
80%
Load (%)
70%
iRM Green2Yellow limit
60%
50%
40%
30%
20%
10%
0%
Pow er load Max
Codes Load Max
CEM Used Max
IUB Load
> Iub load curve represents the average Iub usage during each hour.
Power & Codes load is below iRM Green2Yellow threshold (50%)
CEM load is significantly high explaining the CEM blocking
IuB load is low but the Iub blocking is present > to be investigated
104

CEM Blocking vs. load (week11)
CEM Load vs CEM Blocking (w eek)
load (%)
90%
10
14/03
PS Blocking limit
80%
70%
60%
50%
40%
30%
20%
10%
0%
RB Estab Blocked by CEM
CEM Load Max (%)
RB Blocked
100%
CEM Used Avg (%)
> CEM Blocking is observed only when the PS384 & PS64 blocking limit is reached
this happens constantly during the loaded period of the week (working days)
> CEMAllocFail was < 1% during all this period as the number of CEM resources
request was much higher that the refusal > not a good indicator for CEM blocking
CEM Blocking limit is constantly reached during working days
105
Recommendation => plan to add CEM


Iub Blocking vs. load (week11)
Iub traffic: Real vs Estimated
3500
35
14/03
Peak of
PS384 Setup
on Cell U21
3000
30
25
cells/s
2500
20
2000
15
1500
Mostly
CS traffic
1000
10
500
RB Estab on current cell Blocked by Iub
ECR Estimated
RB Blocked
4000
ECR realy passed
EBRs for PS are overestimated possible parameters tuning

106
Alternative: additional PCMs

107
USE CASE 2: High BRSetup & high blocking

Summary
> Site to be analyzed : DJN_HAVRE
> Cell : DJN_HAVRE_U11
> Capacity Analysis :
- One day from the Obs. period (15/03) is chosen for detailed
analysis
- Blocking causes identification: LackOfBandwidth & Unspecified
- Unspecified cause investigation => Core CE issue
- Bottlenecks identification: Iub
- Traffic analysis:
- CS -> main requested traffic
- PS -> mix of PS128 and PS384
- Recommendations for this cell/site:

- Tuning EBRs for Iub or add PCM
108
USE CASE 2: High RBSetup & high blocking

20%
Day chosen for

detailed analysis
Radio Bearer Blocking at BH

250
18%
16%
200
14%
12%
150
10%
RB Blocking Rate BH
8%
100
RB Blocking at BH
6%
4%
50
2%
0%
0
0607080910111213141516171819mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars06
06
06
06
06
06
06
06
06
06
06
06
06
06
109
15/03 is identified as the most blocked day: deeper analysis

is to be performed

Blocking cause identification
35
Peaks of
Lack of Bandwidth
& Unspecified
30
25
20
15
10
5
0
RBEstablishmentUnsuccess - Total
RB EstablishmentUnsuccess.Unspecified
RB EstablishmentUnsuccess.LackOfBandwidth
RB EstablishmentUnsuccess.UnavailableDlCodeResources
RB EstablishmentUnsuccess.UnavailableDlPowerResources
> High rate of Unspecified is observed:

blocking
> A second cause of blocking is lack of Bandwidth:
Iu cause is discarded because the issue is not spread over entire RNC.
Iur cause is to be foreseen only if the BTS is on RNC border
is most probably Iub as it is seen only on this site
110


Botte lneck Analysis
35
30
25
20
15
10
5
23:00
22:00
21:00
20:00
19:00
18:00
17:00
16:00
15:00
14:00
13:00
12:00
11:00
10:00
09:00
08:00
07:00
06:00
05:00
04:00
03:00
02:00
01:00
00:00
RL ReconfigurationCancel
RL ReconfigurationPrepareUnsuccess.INodeRefusal
RLReconfigPrepareUnsuccess.ReconfigurationFailure
> No RLReconfigPrepUnsuccess.ReconfigFailure Leads to CEM Blocking cause

discard
> Clear correlation between Unspecified reason and RLRecofingCancel
Root cause may be on CoreNetwork to be deeply investigated (see next slide)
> Clear correlation between LackOfBandwidth Blocking and InodeRefusal cause of
RLReconfig Failure
111
Lack of Bandwidth confirmed and CEM blocking discarded

USE CASE 2: High RBSetup but High blocking

Bottlenecks analysis Unspecified
Bottlneck analysis "Unspecified" investiguation

35
30
25
20
> This Cell belongs to Rnc Genoble1 : Cell

Curve for Unspecified blocking follows
the one for the Rnc which confirms a
global Issue on Rnc
=> ( see slide 30 on Unspecified analysis)
10
5
0
RLReconfigCancel.CsSpeech
RL ReconfigurationCancel - Total
"Unspecified" correlation between Cell and corresponding Rnc
100
90
80
70
60
50
40
30
20
10
0
1000
900
800
700
600
500
400
300
200
100
0
06- 07- 08- 09- 10- 11- 12- 13- 14- 15- 16- 17- 18- 19mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars- mars06
06
06
06
06
06
06
06
06
06
06
06
06
06
DJN_HAVRE_U11
112
Unspecified cause linked to CS CoreNetwork issue

Dijon
"Unspecified" Blocking for Rnc
a possible issue between RNC and the

CoreNetwork CS
15
"Unspecified" Blocking for Cell
> Only CS calls are affected indicates

Max RL Established vs Blocking
14
30
Bandwith Blocking
& PS traffic peak
12
25
Nb of RL
10
20
8
15
6
10
2
0
0
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
Max RL PS 384
Max RL PS 128
Max RL PS 64
Max RL Cs
> Important amount of Voice traffic

> Bandwidth-Blocking correlated to PS traffic amount and the apparition of
PS64 Rb Setup
113
Lack of Bandwidth cause linked to PS Traffic peaks

USE CASE 2: High RBSetup but high

blocking
Max Load per Resource (5 days evolution)
CEM Peaks
100%
15/03
90%
80%
70%
60%
50%
40%
30%
20%
Max Codes Load
IuB Load
Max CEM Load
CEM will be the next blocking issue
There is a Margin on Power and Code usage

21:00
18:00
15:00
12:00
09:00
06:00
03:00
00:00
21:00
18:00
15:00
Max Power load
> Iub load curve presents the Average load.
114
12:00
09:00
06:00
03:00
00:00
21:00
18:00
15:00
12:00
09:00
06:00
03:00
00:00
21:00
18:00
15:00
12:00
09:00
06:00
03:00
00:00
21:00
18:00
15:00
12:00
09:00
06:00
03:00
0%
00:00
10%
USE CASE 2: High RBSetup but high

blocking
Iub Blocking vs. load
IuB Traffic: Real vs Estimated
3000
25
15/03
20
2000
15
1500
10
RB Blocked
Equivalent Cell Rate
2500
1000
500
Iub Estimated ECR
Iub Real Cell Rate
> EBRs for PS are overestimated possible parameters tuning

> Alternative: additional PCMs
115

116
USE CASE 3: High RBSetup but Low blocking

Summary
> Site to be analyzed : GRE_ALSACE_LORRAINE
> Cell : GRE_ALSACE_LORRAINE_U21
> Capacity Analysis :
One day from the Obs. period (13/03) is chosen for detailed
analysis
Blocking causes identification: Unspecified
Unspecified cause investigation => Core CE issue
Bottlenecks identification: No UTRAN botleneck
Traffic analysis:
CS -> main requested traffic
PS -> very low PS traffic level
Recommendations for this cell/site:

None
117

Day chosen for
detailed analysis
> Cell with High Traffic and High-but-ponctual blocking on few days
118
13/03 is identified as the most blocked day with the higher

traffic: deeper analysis is to be performed

Blocking cause Identification (13/03)
120
100
80
60
40
20
0
RB Establishement Unsuccess - Total
RB Establishement Unsuccess.Unspecified
RB Establishement Unsuccess.LackOfBandwidth
RB Establishement Unsuccess.UnavailableDlCodeResources
RB Establishement Unsuccess.UnavailableDlPowerResources
> No Codes , Power, lack of Bandwidth blocking

> Total Blocking curve is equal to Unspecified Blocking cause
119
Unspecified is the root cause of blocking


Bottlenecks analysis Unspecified

> VS.RadioBearerEstablishmentUnsuccess.
Unspecified is perfectly correlated with the
> Only CS calls are affected; thus a possible
issue between RNC and the Core Network
CS
> This Cell belongs to Rnc Genoble1 : Cell
Curve for Unspecified blocking follows the
one for the Rnc which confirms a global Issue
on Rnc
=> ( see slide 30 on Unspecified analysis)
140
120
100
80
60
40
20
0
RLReconfigCancel
RLReconfPrepareUnsuccess
RLReconfCancel.CsSpeech
Unspecified Correlation between Cell and Corresponding Rnc
4000
1000
3500
900
800
3000
700
2500
600
2000
500
1500
400
300
1000
200
500
100
0
0607080910111213141516171819mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06 mars-06
120
RNC: GRENOBLE1
Unspecified cause linked to CS Core Network issue


traffic type distribution
Max RadioLink Established vs Blocking
25
120
Nb of RL
80
15
60
10
40
5
Nb of Blocking
100
20
20
Max Nb of RL Cs
Max Nb of RL Ps 128
Max Nb of RL Ps64
Max Nb of RL Ps 384
> Very few Ps Calls

> The Cell is Speech Oriented : This Confirms that Cell is not a serious candidate to
Capacity Issue
121
The Cell is Speech Oriented ; Low Blocking probability


Load per Resource Type
100%
90%
13/03
80%
70%
60%
50%
40%
30%
20%
10%
0%
00:00 07:00 14:00 21:00 04:00 11:00 18:00 01:00 08:00 15:00 22:00 05:00 12:00 19:00 02:00 09:00 16:00 23:00
Max Codes Load
IUB Load
Max CEM Load
Max Power load
> More than 30% Margin on CEM Load before blocking , considering the
same CS profile
> Power and Codes Load curves far from the iRM GreenToYellow threshold
(50%)
> considering the CS oriented traffic, the Iub load should reflect the estimated
one
enough margin for additional traffic
122
Load analysis confirms the absence of capacity issues

Agenda


> iRM & Benchmark
123
iRM Benchmark
Summary
> Benchmark based on Configuration information and Monitoring results

coming from 3 different Operators.
one representative RNC per Operator is monitored (usually the most loaded)
One RNC is in UA4.1 (Operator 2) and the other two (Lyonecul1 & Operator 1)
are in UA4.2 but with basically no UA4.2 features activated (only UA4.1 features)
Observation period: one week (in April)
> RRM State Machine for UA4.1 and UA4.2 evolution

> iRM Configuration for the 3 operators:
iRM Table,
Cell/RL color & iRM Preemption
iRM Scheduling Downgrade & Upgrade
Always_ON,
> Monitored results for the three Operators:
Traffic profile in terms volume (Kbytes) & type of PS traffic.

High level Blocking analysis (RNC level)
Cell/RL color & iRM Preemption
IRM Downgrade (iRM&CAC)
iRM Scheduling Downgrade & Upgrade
Always_ON
> Conclusions
124
iRM Benchmark
RRM State Machine: UA4.1
Reference
- From UA4.1 the RRN state

machine becomes complex
with many interactions.
- Even more complex in
UA4.2 see next slide
iRM Cac
Quality Trigger
IC Target = IRM Table(Reference)
iRM Sched Upgrade

DTxCP
Default : Selected = IC Target
Selected = MIN(IS Target, IC Target)
iRM
Scheduling
Downgraded
Activity Trigger
iRM Sched Downgrade

BLER
Always
On
Downsize
d
if Preempted is
384, 256 or 128
Capacity Trigger
Selected
Selected
Always-On
Upsize
Always On
Release
Always-On
Downsize
iRM Preemption
Preempted
125
Idle
iRM Benchmark
RRM State Machine: UA4.2
Reference
Quality Trigger
iRM Cac
IC Target = IRM Table(Reference)
iRM Sched Upgrade

DTxCP
iRM
Scheduling
Downgraded
RB Rate Adaptation
(Upsize)
RB Rate Adaptation
(Downsize)
Default : Selected = IC Target
Selected = MIN(IS Target, IC Target)
Selected = MAX(Current, MIN(IC

Target, RA Target))
Selected = MIN(RA Target, IC Target)
Selected
Selected
iRM Sched Downgrade

BLER / DTxCP
Always-On
Upsize
Always
On
Downsize
d
if Preempted is
384, 256 or 128
Capacity Trigger
Activity Trigger
Always On
Release
Always-On
Downsize
iRM Preemption
Preempted
Idle
126
iRM Benchmark
RRM Configuration UA4.1
Parameter
irmDlCoverageThreshold
irmDlPowerThreshold
ORF
Operator 1
Operator2
-100 -100
-100
-103
15
14
15
12
yellow2GreenCLCThreshold
40
40
52
green2YellowCLCThreshold
50
50
56
red2YellowCLCThreshold
60
60
65
yellow2RedCLCThreshold
70
70
70
yellow2GreenPLCThreshold
40
40
65
green2YellowPLCThreshold
50
50
70
red2YellowPLCThreshold
75
60
80
yellow2RedPLCThreshold
80
70
85
PS384 RL Green Cell Green
384
384
384
PS384 RL Green Cell Yellow
384
128
128
PS384 RL Green Cell Red
64
64
64
PS384 RL Red Cell Green
128
128
128
PS384 RL Red Cell Yellow
128
64
128
PS384 RL Red Cell Red
64
64
64
PS128 RL Green Cell Green
128
128
128
PS128 RL Green Cell Yellow
128
64
128
PS128 RL Green Cell Red
64
64
64
PS128 RL Red Cell Green
128
64
128
PS128 RL Red Cell Yellow
128
64
128
PS128 RL Red Cell Red
64
64
64
127
RL Color thresholds are close in

terms of Ec/N0. Operator2 more
permissive in terms of RSCP.
Cell Color thresholds for codes are
very close for the 3 Operators. Again
Operator 2 is more permissive for the
power thresholds
Different strategies for iRM table:
ORF no difference between green
and yellow in terms of decision. Only
cell red can lead to PS64
Operator1 aggressive downgrade
policy especially for RL Red
Operator 2 is playing moderate.
Cell Red is triggering PS64 (as ORF)
iRM Benchmark
Parameter
RRM Configuration UA4.1
Always_ON timers are completely

different configured: very aggressive in
case of Operator 1 & 2 (due to DCH
used as downsize state) and very
relax in case of ORF (due to FACH
used as downsize state)
ORF
Operator 1
Operator2
timerT1-gold
20000
5000
3000
timerT2-gold
120000
10000
20000
timerT1-silver
20000
5000
3000
timerT2-silver
120000
10000
20000
targetDlRbSetForIrmScheduling6
3 (false)
3 (false)
targetDlRbSetForIrmScheduling7
2000
5000
2000
default
default
default
yes
yes
no
isIrmSchedulingUpgradeAllowedFro
mThisUS
128
64
isIrmSchedulingUpgradeAllowedToT
hisUS
384
128
384
23
27
26.5
384
128
384
5000
5000
5000
384
128
128
55000
500
500
timeToTrigger (PS384 -> PSxx)

radioQualityMeasurementQuantity
isIrmSchedulingUpgradeAllowed
iRM Scheduling Downgrade is mainly

used for PS384 (only Operator1 using
it for PS128 too). Very long time to
trigger for Operator1.
iRM Scheduling Upgrade is only used
by ORF and Operator 1.
iRM Preemption is used by ORF and
Operator 1. Thresholds used for
congested state are same as for the
Yellow2Red/Red2Yellow (iRM table)
FlipflopUpDowngradeTimer
thresholdTransCodePower (dBm)
highBitRate
timeToTrigger
deltaThresholdTransCodePower
intermediateRate
deltaTimeToTrigger
isIrmPreemptionAllowed
yes
yes
no
normal2CongestedPLCThreshold
80
70
70
congested2NormalPLCThreshold
75
60
60
normal2CongestedCLCThreshold
70
70
70
60
60
congested2NormalCLCThreshold
128
Same as iRM
Y2R & R2Y
60
Lower than iRM

Y2R & R2Y
iRM Benchmark
Orange FR - RRM diagram UA4.1
384
RL Good
Green
Cell
Yellow Cell
384
384
Reference RB
EcNo: -12
RSCP: -100
Red Cell
Green
Cell
64
Codes
RL Bad
Yellow Cell
Red
Cell
128
64
128
70
60
50
40
Power
384
128
128
64
iRM
Sched.
TimerT1 = 20s
Always On (FACH)
129
Idle
TimerT2 = 120s
80
75
50
40
iRM Benchmark
Operator 1 - RRM diagram UA4.1
384
RL Good
Green
Cell
Yellow Cell
384
128
Reference RB
EcNo: -15
RSCP: -100
Red Cell
Green
Cell
64
Codes
RL Bad
Yellow Cell
Red
Cell
64
64
128
70
60
50
40
Power
384
iRM
Sched.
128
64
64
TimerT1 = 5s
Always On (DCH)
130
Idle
TimerT2 = 10s
70
60
50
40
iRM Benchmark
Operator 2 - RRM diagram UA4.1
384
RL Good
Green
Cell
Yellow Cell
384
128
Reference RB
EcNo: -14
RSCP: -103
Red Cell
Green
Cell
64
Codes
RL Bad
Yellow Cell
Red
Cell
128
64
128
70
65
56
52
Power
384
128
128
64
iRM
Sched.
TimerT1 = 3s
Always On (DCH)
131
Idle
TimerT2 = 20s
85
80
70
65
iRM Benchmark
Monitoring Results Traffic Type & Volume
DedicatedDownlinkKbytesRlc (All traffic & PS only)
RBSetupRequest PS Repartition (%)

60000000
100%
90%
50000000
80%
40000000
70%
KByts
60%
50%
40%
30000000
20000000
30%
10000000
20%
10%
0
Day 1
0%
Day 1
Day 2
ORF PS384
ORF PS128
Day 3
OP1 PS384
Day 4
Op1 PS128
Op2 PS384
Day 5
Op2 PS128
Day 2
Day 3
Day 4
RNC: LYON1 (PS)
RNC: Op1 (PS)
RNC: Op2 (PS)
RNC: LYON1 (All)
RNC: Op1 (All)
RNC: Op2 (All)
Day 5
> Three different operators with three different traffic allocation strategies:
Orange mix of PS128 & PS384 RBs

> In terms of Volume: The most loaded is Operator 2 followed by Operator 1

which is also the most loaded in terms of PS traffic.
For this benchmark, ORF RNC (Lyonecul1) is the less loaded RNC
in terms of total traffic and PS traffic, but it has an homogeneous
PS traffic mix.
132
iRM Benchmark
Monitoring Results High Level Blocking analysis
Blocking rate comparison (RNC Level)
0,80%
Lyn1 Blocking cause = Iub

Op1 Blocking cause = Codes
Op2 Blocking cause = RF Power
0,70%
0,60%
0,50%
0,40%
0,30%
0,20%
0,10%
0,00%
Blocking rate Light % Lyn1
> A Blocking rate Light taking into account all causes except unspecified is
calculated:
The Unspecified cause is not considered as it concerns only the CEM which is
not managed by the iRM in UA4.1 & UA4.2.
All other causes (Iub, Codes, RF Power) are covered by this metric.
> Operators 1 & 2 are almost not blocked at all (< 0,1%), blocking coming
from Codes (Op1) & RF Power (Op2)
Lyonecul1 is the most blocked RNC, the entire blocking coming

from Iub.
133
iRM Benchmark
Monitoring Results Cell Color analysis (RNC level)
cells of only one
site (BRON) were
yellow 100% of time
To be investigated
Cell Color evolution (RNC Level)

1,4%
1,2%
1,0%
0,8%
0,6%
0,4%
0,2%
0,0%
Avg PS RL established
Cell Color Red % Lyn1
Cell Color Yellow % Lyn1
Cell Color Red % Op1
Cell Color Yellow % Op1
Cell Color Red % Op2
Cell Color Yellow % Op2
90
80
70
60
50
40
30
20
10
0
Avg Nb of PS RBs established Lyn1
>
>
Avg Nb of PS RBs established Op1
Avg Nb of PS RBs established Op2
The ratio of time when the Cell color was Red & Yellow for each of the 2 RNCs is presented on
the first graph (upper).
Average Established PS RBs per RNC/hour are presented in the lower graph allowing to
correlate with the cell color.
No R and very few Y cell color for Lyn1. iRM@CAC decision is based
practically only on RL color.
Op 1: Cell Color is following the traffic load = > full iRM table usage
134
Op 2 is slightly passing to Y and R (high thresholds for power)

iRM Benchmark
Monitoring Results Cell Color analysis (Cell level)
BRON site cells
not included
>
Monitoring interval is 5 days = 120 H = 7200 min
>
BRON site cell color is not included
>
Graphs show the number of cells spending more than X s in Y and R state (during the 5 days)
Lyn1 has very few cells in Yellow and for very short time. The traffic is
low and blocked by Iub before to affect the codes&power.
Op1 has lower number of cells congested (in Y and R state) than Op2
but the time spend in congestion is much higher => high downgrade
135
iRM Benchmark
Monitoring Results iRM Preemption analysis (RNC level)
iRM Preemption (RNC Level)
0,16%
Codes congestion
0,14%
Power congestion
0,12%
0,10%
0,08%
0,06%
0,04%
0,02%
0,00%
IrmPreemptionBecauseOfOvsfCodes Lyn1
IrmPreemptionBecauseOfOvsfCodes Op1
IrmPreemptionBecauseOfOvsfCodes Op2
IrmPreemptionBecauseOfPower Lyn1
IrmPreemptionBecauseOfPower Op1
IrmPreemptionBecauseOfPower Op2
> The iRM Preemption analysis can confirm the cause of cell color change.
> Even the iRM preemption is not activated in Operator 2, the iRM preempt.
counters are pegged each time the congested level is reached.
No iRM congestion monitored for Lyonecul1 => confirms 0 Cell Red
Operator 1 the OVSF codes are the main cause of Cell color
change
Operator 2 the RF Power is the main cause for Cell color change
136
iRM Benchmark
Monitoring Results RL Color analysis
RL Red Evolution (week)
30%
07:00 AM
% of RL Red
25%
20%
15%
10%
5%
0%
RNC: LYON1
RNC: Op1
RNC: Op2
> Operator 2 is clearly the worst in terms of RL red (17% in average). Possible
coverage issues as it uses low PCpich values (29.5 dbm). ORF & OP1 use similar
Common Channels settings.
> Interesting phenomenon: Operator 2 has peaks of RL Red et 7:00 AM each work day
of the week (day1 was public holyday). Coverage problems during home-work route?
No RL Color dependence on traffic is observed (flat during the day)
The RL Color seems more related to coverage issues.
Lyonecul1 is better than Op2 and comparable with Op1

137
iRM Benchmark
Monitoring Results iRM CAC Downgrade analysis
iRM CAC Downgrade ratio (PS384)
25%
Traffic peaks
20%
15%
10%
5%
0%
IrmcacDow ngrade Ratio PS384 Lyn1
IrmcacDow ngrade Ratio PS384 Op1
IrmcacDow ngrade Ratio PS384 Op2
> Monitoring obs. shows that PS384 is the only RB downgraded at admission, thus
the iRM CAC Downgrade ratio was computed based on PS384 RB requests (more
accurate).
> In case Lyonecul1 and Operator 2 the iRM CAC Downgrade ratio is flat during the
day which confirms the involvement of RL Color only.
> Operator 2 having a predominant PS128 traffic is less exposed to iRM downgrades
> Operator 1 IRM Downgrade curve is clearly impacted by cell color (peaks of traffic
during the day)
Lyn1 downgrade driven only by RL color based on coverage issues.

No change in UA4.2 (R99 cells), as the Iub load in iRM is performing
cell color calculation based on real load not RNC estimated Iub load.
On sites with HSDPA, the Iub load will probably change the cell color.
138
iRM Benchmark
Monitoring Results iRM Scheduling Downgrade analysis
iRM Sched Downgrade (PS384) vs Avg Nb of PS384
iRM Scheduling Downgrade Ratio (PS384)

10%
35
8%
30
25
6%
20
4%
15
10
2%
0%
Day 1
Day 1
Day 2
Day 3
Day 4
Day 5
IRMSchedulingDowngrade PS384 (%) Lyn1

IRMSchedulingDowngrade PS384 (%) Op1
Day 2
Day 3
Day 4
Day 5
iRM Sched vs Avg Nb of PS384 Lyn1

iRM Sched vs Avg Nb of PS384 Op1
iRM Sched vs Avg Nb of PS384 Op2
IRMSchedulingDowngrade PS384 (%) Op2
> The iRM Scheduling is triggered only for PS384 for all three operators.
> First graph (left) presents standard iRM Scheduling Downgrade Ratio metric. This
standard metric is based on RAB Establishment Success, thus exposed to large
variation in case of high number of RAB Requests (case of AON T1/T2 very low).
> A second graph (right) is presenting the number of iRM Scheduling Downgrade per
Average PS384 established during the day (PS384 call duration is considered)
iRM Scheduling downgrade seems to behave normally on Lyonecul1
Op1 has much higher PS load but also higher TimeToTrigger which
compensate => Op1 same level of iRM Sched downgrade as Lyn1
139
iRM Benchmark
Monitoring Results iRM Scheduling Upgrade analysis
IRM Scheduling Upgrade/Downgrade Ratio
30%
25%
20%
15%
10%
5%
0%
Day 1
Day 2
Day 3
Day 4
Day 5
IRM Sched Upgrade/Downgrade Ratio Lyn1

IRM Sched Upgrade/Downgrade Ratio Op1
> The iRM Scheduling upgrade is not activated in Operator 2 (so no data
available)
> The two different criteria for upgrade and downgrade (in UA4.2) are making
difficult an evaluation of the feature efficiency
iRM Scheduling upgrade seems to have the same behavior for the
two operators despite difference in thresholdTransCodePower ->
possible cause the different fallback RB used (64 in Op1 & PS128
Lyn1).
140
iRM Benchmark
Monitoring Results Always ON analysis (T1)
AON Down Step1 / Average Number of PS RB Established (Erl PS)
8000
T1 = 3s
7000
6000
5000
T1 = 5s
4000
3000
2000
T1 = 20s
1000
0
Day 1
Day 2
Day 3
AON Dow n Step1 / Average PS RB Established Lyn1
Day 4
Day 5
AON Dow n Step1 / Average PS RB Established Op1
AON Dow n Step1 / Average PS RB Established Op2
> The graph is presenting the number of Always ON Downsize per Average
number of PS established during the day (PS call duration is considered
in this case). Clear dependency: T1 value => AON downgrade / PS call
High T1 means long perceived PS RAB durations (low number of

downsizes per PS RAB) => waste of UPlane resources & low PS
sessions fragmentation => increased blocking on bottlenecks.
Low T1 is part of Op1 & Op2 strategy to deal with high PS traffic
141
iRM Benchmark
Monitoring Results Always ON analysis (T2)
AON Release / PS Call
0,9
0,8
T2 = 10s
0,7
0,6
T2 = 20s
0,5
0,4
0,3
0,2
T2 = 120s
0,1
0,0
Day 1
Day 2
Day 3
AON Dow n Step2 /PS Setup Lyn1
AON Dow n Step2 /PS Setup Op1
Day 4
Day 5
AON Dow n Step2 /PS Setup Op2
> The graph is presenting the number of Always ON Downsize Step2 per PS
call Established. Clear dependency: T2 value => AON release / PS call
Low T2 generates several PS RAB Establishments for one User
session -> 80% of PS calls in Op1 are ending through AON release
Very few of the PS calls are ended by Always On release in Lyn1 (<
20%): good for user perception but RNC FACH context consuming
(not an issue for the moment)
142
iRM Benchmark
Conclusions
> ORF RNC (Lyonecul1) is less loaded that the other two RNCs in the
benchmark (in terms of total traffic and PS traffic), but it has an homogeneous
PS traffic mix.
> Lyonecul1 is the most blocked RNC from the three and the entire blocking is
coming from Iub (and slightly Iur). The other Operators are not facing this
issue as use different EBR Configuration:
EBR Values
DL RB
PS 64
PS 128
PS 384
ORF
69632
136832
408000
Operator 1 Operator 2
x 2/3
x 3/5
x 1/2
x1
x 3/4
x 1/2
> The Cell color is practically unused for Lyonecul1 (traffic is low and blocked by
Iub before to affect the codes & power). iRM@CAC decision base only on RL
color.
> Normal behavior/settings of iRM Scheduling downgrade.
> Long T1 timer is generating less AON downsize procedures (thus less CPlane
signaling) but is also wasting valuable UPlane resources (generating
additional Blocking).
> T1+T2 duration is seriously impacting the number of PS RAB established and
the RAB duration monitored through UTRAN counters (see call profile ORF
vs. Operator 1 next slide). Low T1 is a good method to reduce admission
blocking
143
Back to highlights
Call Profile Resume

ORF
Metric name
BHCA
Mean Call Duration
Active Set Update per second
Mean Sector per user
Percentage of softer HO
Inter-RAT cell reselection
SMS
Nb of AO Downsize per PS call
Nb of AO Upsize per call
Nb of AO Release per call
Nb of IRM Sched Downgrade per
call
% of 3G-2G HO per CS call
% of 3G-2G HO per PS call
Number of 2G-3G CS HHO
PS
CS V CS D 384
1,05
95
0.01
108
0,01
636
Operator 1
PS
128
PS
Ps 64 CS V CS D 384
0,06 0,001 0,93

110 452,0 55
0,01
48
0,19
34
PS
128
0,02
34,9
Operator 3
PS
Ps 64 CS V CS D 384
0,01
23
2,04
82
0,06
103
0,26
50
0,12
0,18
0,145
1,71
1,95
1,6
27%
1,36
0,33
2,36
1,88
0,25
35%
1,81
0,27
1,57
0,79
0,68
24%
1,23
0,42
1,75
1,2
0,44
0,07
0,01
0,08
11%
13%
0
23%
14%
0
5%
10%
0
PS
128
0,03
119
Ps 64
N/A
N/A
Significant differences between ORF profile and other operators:

Low number of PS calls/Sub but very long calls (impact on UPlane) >
AON timers settings consequence.
Mean sector per user reasonable value (OK from capacity point of view).
Very low number of AON release per call unnecessary resources usage.
144
Thanks for your patience!
145
Backup
146
147

1 - Capacity Study (Light + Detailed Version)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 - Capacity Study (Light + Detailed Version)

Uploaded by

Copyright:

Available Formats

ORF Capacity Monitoring Study

Nortel Confidential Information

> Capacity Monitoring method

Blocking & Resources Load Characterization

> Capacity Monitoring Use case Method application

Nortel Confidential Information

UTRAN capacity analysis introduction

Operators start to experience some congestion in their networks and foresee

Nortel Confidential Information

UTRAN capacity analysis introduction

> Software release

> Elements of NodeB configuration:

BTS with X CEM

BTS with X PCM

Nortel Confidential Information

0,06 0,001 0,93

Significant differences between ORF profile and other operators:

Nortel Confidential Information

RBSetupRequest PS Repartition (%)

RNC: LYON1 (PS)

RNC: Op1 (PS)

RNC: Op2 (PS)

RNC: LYON1 (All)

RNC: Op1 (All)

RNC: Op2 (All)

Orange mix of PS128 & PS384 RBs

> In terms of Volume: The most loaded is Operator 2 followed by Operator 1

Nortel Confidential Information

Lyn1 Blocking cause = Iub

Blocking rate Light % Lyn1

Blocking rate Light % Op1

Blocking rate Light % Op2

Lyonecul1 is the most blocked RNC, the entire blocking coming

Nortel Confidential Information

> Capacity Monitoring method

Blocking & Resources Load Characterization

> Capacity Monitoring Use case Method application

Nortel Confidential Information

Call admission failure

Call is not reconfigured - RL Reconfiguration Unsuccess

- AON/iRM Scheduling failure

This study is mainly focused on Blocking during Call Admission phase as it

Nortel Confidential Information

The load can be monitored at BTS level

> Iub ATM

The load can be monitored at BTS level (AAL2&AAL5 traffic)

> RF power - BTS Resource

> OVSF Codes - RNC Resource

The load can be monitored per cell via RNC counters

> RNC CPU

The load can be monitored at card level through RNC counters

Congested cells @ Network level

Blocking rate > x %

Significant amount of blocking (> 2%) observed during w10 &

CEM load @ Network level

Avg Load Count

Max Load (%)

Avg Load (%)

Iub load @ Network level

Iub Load > x %

Max Load (%)

Nortel Confidential Information

DL Power load @ Network level