UMTSYSDD018826LR15W V1 Call Admission Control

Call Admission Control (Radio)
Document number:
Document issue:
Document status:
Date:
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
External document
Copyright 2009-2015 Alcatel-Lucent, All Rights Reserved
Printed in France
4
5
6
7
8
9
10
11
ALCATEL-LUCENT CONFIDENTIAL
The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in
writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the
information only to its employees with a need to know, and shall protect the information from disclosure and
dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted
no rights to use the information contained herein. If you have received this document in error, please notify the
sender and destroy it immediately.
12
13
PUBLICATION HISTORY
28/Jan/2009
14
Issue 03.01/ EN, Draft, Author: M. Bruegmann
15
Creation based on 02.04 doc release
16
New Features: 75069
17
18
06/Feb/2009
19
Issue 03.02/ EN, Standard, Author: M. Bruegmann
20
Change to Standard after review
21
22
06/Mar/2009
23
Issue 04.01/ EN, Preliminary, Author: A. Agin
24
New edition issued to cover UA07.1
25
New feature: 31868
26
27
28
28/Aug/2009
Issue 04.02/ EN, Standard, Author: A. Agin
29
30
11/Feb/2011
31
Issue 07.01/ EN, Draft, Author: R.George
32
New edition issued to cover UA08.1
33
New feature: 89857
34
35
36
Note: Issue 05.xx/EN and 06.xx/EN reserved for UA07.1.3 and UA08.0 respectively (hence
07.xx/EN for UA8.1)
37
38
22/Mar/2012
39
Issue 07.02/ EN, Preliminary, Author: M. Wargui
40
New feature: 119026 (soft congestion)
41
42
43
14/May/2012
Issue 07.03/ EN, Standard, Author: M. Wargui
44
45
01/Nov/2012
46
Issue 08.01/EN, Draft, Author: Bill Dickson
47
New edition to cover LR13W
48
New feature 127550
49
50
51
16/Nov/2012
Issue 08.02/EN, Standard, Author: Bill Dickson
Alcatel-Lucent confidential
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 2/72

52
53
54
New edition to cover LR13W

New feature 127550
26/May/2013
55
Issue 08.03/EN, Preliminary, Author: JF Lutier
56
New edition to cover LR13.3W
57
New feature 127550/168556/LR13.3
58
59
60
61
62
63
15/July /2013
Issue 08.04/EN, Standard, Author: JF Lutier
27/Nov/2013
New feature 131683/122612 LR14.W, 09.01/EN, Preliminary, Author: MC. Ly /P. Pike
04/Feb/2014
Updated according to remarks, 09.02/EN, Standard, Author: MC. Ly /P. Pike
64
27/Feb/2015
65
66
Updated for Soft congestion and Preemption enhancement (PM177049), 10.01/EN,

Draft, Author: Balbeer Tiwari
67
68
69
20/Mar/2015
Updated for Review Comment on v10.01, 10.02/EN, Standard, Author: Balbeer Tiwari
70
71
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 3/72

72
CONTENTS
73
74
75
76
77
INTRODUCTION ............................................................................................................................6
1.1
1.2
1.3
78
79
OBJECT .......................................................................................................................................6
SCOPE OF THIS DOCUMENT ...........................................................................................................6
AUDIENCE FOR THIS DOCUMENT ....................................................................................................6
RELATED DOCUMENTS ..............................................................................................................7
2.1
2.2
APPLICABLE DOCUMENTS ..............................................................................................................7

REFERENCE DOCUMENTS .............................................................................................................7
80
FUNCTION OVERVIEW ................................................................................................................8
81
FUNCTIONAL DESCRIPTION ................................................................................................... 10
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
4.1
MANAGEMENT OF DOWNLINK RADIO RESOURCES IN CASE FAIR SHARING DISABLED .................... 10

4.1.1
CAC of HSDPA Radio Resources CAC ....................................................................... 10
4.1.2
DL Power for R99 ......................................................................................................... 10
4.1.3
DL Power for HSDPA ................................................................................................... 11
4.1.4
OVSF code tree ........................................................................................................... 11
4.2 MANAGEMENT OF DOWNLINK RADIO RESOURCES IN CASE FAIR SHARING IS ENABLED .................... 11
4.2.1
Introduction................................................................................................................... 11
4.2.2
Description ................................................................................................................... 13
4.3 TRAFFIC FILTERING IN CELL OVERLOAD ....................................................................................... 20
4.3.1
127550 Feature aim .................................................................................................. 20
4.3.2
connection setup .......................................................................................................... 21
4.3.3
Upsize from PCH State ................................................................................................ 24
4.3.4
A.On upsize inter-action ............................................................................................... 26
4.3.5
Configuration Management .......................................................................................... 26
4.4 SELECTIVE PAGING DISCARD...................................................................................................... 27
4.4.1
131683 Feature aim .................................................................................................. 27
4.4.2
Activation ...................................................................................................................... 27
4.4.3
Interworking with other features ................................................................................... 30
4.4.4
Configuration Management .......................................................................................... 32
4.5 MANAGEMENT OF UL RADIO RESOURCES CAC ........................................................................... 34
4.5.1
Uplink token based CAC .............................................................................................. 34
4.5.2
Uplink radio load .......................................................................................................... 35
4.6 MANAGEMENT OF RADIO RESOURCES SHORTAGE ....................................................................... 38
4.7 TRANSMISSION RESOURCES MANAGEMENT ................................................................................. 41
4.8 RNS INTER-RELEASE COMPATIBILITY USE CASES ....................................................................... 41
4.8.1
RNS Vn+1 facing RNS Vn ........................................................................................... 41
4.8.2
RNS Vn+1+activated feature facing RNS Vn ............................................................... 41
4.8.3
RNS Vn+1+ activated feature facing mixed RNS Vn+1 ............................................ 41
4.8.4
RNS Vn+1+activated feature facing RNS Vn+1 without the feature ............................ 41
4.8.5
RNS Vn+1+activated feature facing other vendor RNS ............................................... 42
5
113
114
115
116
OAM ............................................................................................................................................ 43
5.1
5.2
5.3
CONFIGURATION MANAGEMENT ................................................................................................. 43

FAULT MANAGEMENT................................................................................................................. 51
PERFORMANCE MANAGEMENT .................................................................................................... 51
OAM PROCEDURES.................................................................................................................. 68
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 4/72

117
118
119
120
6.1
6.2
6.3
7
121
122
123
124
125
126
127
128
129
130
UPGRADES................................................................................................................................ 68
INSTALLATION & COMMISSIONING PROCEDURES.......................................................................... 68
MAINTENANCE ........................................................................................................................... 68
FIELD INTRODUCTION ............................................................................................................. 69
7.1
7.2
7.3
7.4
7.5
7.6
8
HARDWARE CONSTRAINTS ......................................................................................................... 69

SPARE PART CONSTRAINTS ....................................................................................................... 69
INTER RNS VERSION INTERWORKING ......................................................................................... 69
CORE NETWORK INTERWORKING ................................................................................................ 69
MS INTERWORKING ................................................................................................................... 69
GERAN INTERWORKING ............................................................................................................ 69
ABBREVIATIONS AND DEFINITIONS ...................................................................................... 70
8.1
8.2
ABBREVIATIONS......................................................................................................................... 70
DEFINITIONS ............................................................................................................................. 71
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 5/72

131
132
1
1.1
INTRODUCTION
OBJECT
133
134
The objective of this document is to describe the call admission control mechanisms for
radio resources as:
135
downlink cell power,
136
downlink OVSF cell code tree,
137
uplink radio load,
138
uplink token model based CAC,
139
traffic filtering Services for UE coming from idle or XXX_PCH mode.
140
141
The transmission resources call admission control is moved into [R20].
1.2
SCOPE OF THIS DOCUMENT
142
This document is applicable upto LR15W.
143
144
In LR13W, the below functionalities are introduced, dealing or interworking with radio
resources CAC. This document describes the following features:
145
127550 Traffic Filtering in cell overload
146
126055 UL_radio_overload_handling_enhancements
147
The transmission CAC features are described in [R20] and preemption in [R16]
148
The following features are added for LR14W:
149
PM131683 Selective Paging Discard (cf. 4.4),
150
PM122612 E-DCH Performance Enhancement (cf. 4.5.2.2).
151
The following features are added for LR14W:
152
153
154
155
1.3
PM177049 Soft congestion Extension
AUDIENCE FOR THIS DOCUMENT

The targeted audience is R&D, PLM, testing and engineering departments but also
customers.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 6/72

156
157
2
2.1
RELATED DOCUMENTS
APPLICABLE DOCUMENTS
158
Ref. #
Document Identifier
Document Title
[A1]
FTS 89857
iMCRA Step 2
159
160
2.2
REFERENCE DOCUMENTS
161
Ref. #
Document Identifier
Document Title
[R1]
TS 25.331
UTRAN Uu interface RRC
[R2]
TS 25.413
UTRAN Iu interface RANAP signalling
[R3]
TS 25.423
UTRAN Iur interface RNSAP signalling
[R4]
TS 25.433
UTRAN Iub interface NBAP signalling
[R5]
TS 25.133
Requirements for Support of Radio Resource Management (FDD)
[R6]
TS 25.215
Physical Layer Measurements (FDD)
[R13]
UMT/IRC/DD/0011
UTRAN Parameters User Guide
[R14]
UMT/SYS/DD/013319
HSDPA system specification
[R15]
UMT/SYS/DD/018827
Enhanced DCH system specification
[R16]
UMT/SYS/DD/86
UTRAN Power management
[R17]
UMT/SYS/DD/128
Intelligent RAB Mapping
[R18]
UMT/SYS/DD/18827
E-DCH system specification
[R19]
UMT/SYS/DD/023091
Preemption
[R20]
UMT/SYS/DD/023087
UTRAN Architecture & Transmission management
[R21]
UMT/SYS/DD/041805
SDS Enhanced CELL_FACH
[R22]
UMT/SYS/DD/0054
UMTS Radio Mobility
[R23]
UMT/SYS/DD/032705
SoftCongestion
[R24]
UMT/SYS/DD/000034
SDS PS call management
[R25]
UMT/SYS/APR/042563
FSD - 177049 Soft Congestion Extension
162
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 7/72

163
FUNCTION OVERVIEW
164
165
At each establishment, release or reconfiguration of a link over DCH, a call admission

is performed on the following radio resources:
166
downlink cell power (starting UA01)
167
downlink OVSF cell code tree (starting UA01)
168
uplink radio load (introduced in UA05)
169
uplink token model based CAC (introduced in UA4.2 and enhanced in UA05)
170
Moreover, an AAL2 CAC is performed (enhanced in UA05).
171
172
Please note that call admission is also performed based on the memory/processing
capacity of the RNC and Node B and are not part of this document.
173
174
175
176
- With the support of GBR over HSDPA (29804) (described in [R14]) and fair sharing
(33694), a CAC is also introduced on radio and transmission resources in order to have
the means to guarantee a throughput to the end-user. This CAC is active when the fair
sharing feature is enabled.
177
178
179
- with the support of fair sharing of resources (33694), the sharing of radio resources
allocated to calls handled on R99 and HSDPA/HSUPA is managed dynamically
providing better capacity management.
180
181
182
183
184
185
186
- with the support of (127550 in LR13.1 & 168556 in LR13.3 a new CAC is added
through the concept of traffic filtering. it will allow rejecting low priority service and
allowing high priority service establishment on the originating cell, for UE coming from
idle or XXX_PCH mode. (LR13.3W) The feature is activated using the following flags
isRrcFilteringAllowed (in both the RadioAccessService and FDDCell classes) which
takes
into
account
csrArrivalCondition
and
csrFailureCondion
in
CarrierSelectionCondition.
187
188
In LR13.3 the traffic filtering procedure is improved by new triggers based on event
definition based on Cell load / Arrival rate / failure rate, and new call types definition.
189
190
This feature will allow rejecting low priority service and favorizing high priority service
establishment on the originating cell, for UE coming from idle or XXX_PCH mode
191
192
isAcbForRrcFilteringAllowed which activates/ deactivates automatic trigger for ACB

feature
193
194
195
isAOUpsizeFilteringAllowed which determines whether the traffic filtering feature

needs be applied to UEs in PCH mode (LR13.3W) and making a Cell Update for a new
service establishment or for traffic reasons.
196
197
198
The full functionality of this feature is more fully covered in the System Design
Specification for UMTS Radio Mobility (UMT/SYS/DD/0054) [R22]
199
200
201
- with the support of Preemption feature (33322) described in [R19]), when the most
priority calls cannot be granted, the system will initiate a preemption mechanism which
will downgrade/release less priority calls to give room to these high priority calls.
202
203
204
205
- FRS 119026 Soft Congestion intends to improve functionality of current UA06 preemption feature. Instead of FRS 33322 that may trigger call release (not accepted by
AT&T for some regulatory constraints), a capability of soft congestion is introduced in case
of HSDPA CAC failure due to reaching max HSPA connection in Node B.
206
207
208
Like pre-emption, when this CAC happens, it means the cell/ Node B enters in congestion
status on HSDPA connection, so a decongestion procedure is needed to free some
HSDPA resources.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 8/72

209
210
211
-PM177049 Soft congestion extension brings in applicability of soft congestion to AO

upsize and Multi carrier ( DC ) also. Multi carrier access restriction based on cell colour is
also added as part of soft congestion enhancement.
212
213
214
215
- with the support of RRC Redirection feature (89857), the calls can be redirected to
specific layers as configured by the operator and for load balancing options.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 9/72

216
FUNCTIONAL DESCRIPTION
217
218
This section describes briefly the CAC mechanisms on downlink radio resources i.e.
power and OVSF code tree.
219
Two modes of operation are available:
220
221
when fair sharing is not enabled, the call admission control is resource oriented
i.e. resources are more or less managed independently for R99 and HSDPA
222
223
224
when fair sharing is enabled, the call admission is service oriented meaning
resources and CAC are managed as one pool whatever is the pipe used (dedicated
or shared)
225
226
227
228
4.1
MANAGEMENT OF DOWNLINK RADIO RESOURCES IN

CASE FAIR SHARING DISABLED
4.1.1 CAC OF HSDPA RADIO RESOURCES CAC
229
230
231
232
When fair sharing is disabled, the basic Call Admission Control for HSDPA and E-DCH
are based on a number of users and there is no radio resource based CAC for call
admission. When the call is admitted, the resources granted for the UE are managed
by the scheduler based on the current radio resources availability.
233
Full details are available in [R14] for HSDPA and in [R18] for E-DCH.
234
235
236
With eFACH DL R7 introduction in LR13.3 the CAC procedure is more or less the same
with in addition common HSDPA users. Full details are available in [R21] for eFACH DL
R7
237
238
239
4.1.2 DL POWER FOR R99

The downlink cell power is handled by the Node B but partitioned at the RNC level as
follows:
240
241
Power for common control channels. This power is the sum of power configured
for Primary CPICH, Primary CCPCH and Secondary CCPCH.
242
Power for OCNS
243
Power for HSDPA (MinimumPowerForHsdpa)
244
245
Power
for
E-AGCH,
RGCH_EHICH_TotalPower)
246
Power for common HSDPA (in LR13)
E-RGCH
and
E-HICH
(E-AGCH_E-
247
248
249
250
251
Power for traffic on R99 resources (DCH) is calculated as the difference between total
available power for the cell and the sum of above listed powers, where the common
control channels power is weighted by an activity factor in order to balance overestimation of the power used since common channel power is the sum of maximum
power used by the common channels.
252
253
This remaining R99 dedicated power is managed through a reservation mechanism at

the RNC.
254
255
256
257
258
On each allocation/modification/release of a RAB combination, a CAC is performed

taking into account the current power available , the power to be reserved for this RAB
combination (two reservation mechanisms are available: one based on maxDlTxPower
and the other one on initial Dl TX power) and a CAC threshold (which is different for
SHO and for leg establishment). If the power available is sufficient to handle the power
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 10/72

259
260
to be reserved, the CAC is declared successful and the power is reserved to the call,
otherwise the CAC is declared failed.
261
Full details available in [R16] which deals with power management in UTRAN.
262
4.1.3 DL POWER FOR HSDPA
263
264
When fair sharing is not enabled, the main principle is to make HSDPA use the
remaining power which is not used currently used by R99.
265
As stated above, there is a minimum Power for HSDPA which can be reserved.
266
267
268
For the maximum HSDPA power, the RNC has the means to limit the HSDPA power
used to the whole remaining power minus a margin. This margin could be also null, in
this case the NBAP IE will not be sent to the Node B.
269
Full details are available in [R14].
270
4.1.4 OVSF CODE TREE
271
272
In the current release, one downlink scrambling code (i.e. one OVSF code tree) is
managed per cell. In this OVSF tree, some codes are reserved:
273
codes for common control channels
274
codes for OCNS
275
a sub-tree is allocated to the Node B for HSDPA usage.
276
277
278
The rest of the OVSF tree is used by calls handled over R99 resources. For each
allocation, the OVSF tree will be run from up to down (filling the gaps if any), which
avoids to block too many branches.
279
280
If a free code is found, the resource is granted to the call and the OVSF code CAC is
successful, otherwise the call is rejected and the CAC on OVSF code is declared failed.
281
282
283
284
285
286
Please note that up to UA4.2, the number of codes reserved for HSDPA was static.
Starting UA05, thanks to Dynamic DL OVSF code tree management feature, the sharing
of the OVSF tree is dynamic and adjusted in function of the traffic on HSDPA and R99
resources with a priority to R99 calls: in case the occupancy is higher than a threshold
for R99 resources, a part of the sub-tree is preempted back for R99 calls. There is a
dual mechanism which allows giving back codes to HSDPA when not used by R99.
287
The Dynamic DL OVSF code tree management feature is described in [R14].
288
289
With eFACH DL R7 introduction in LR13.3 DL OVSF code inter-action is described in

[R21].
290
291
292
293
294
4.2
MANAGEMENT OF DOWNLINK RADIO RESOURCES IN

CASE FAIR SHARING IS ENABLED
4.2.1 INTRODUCTION
295
296
Note: fair sharing is required when FRS 31868 MBMS Broadcast is activated in HSPA
capable cells.
297
MBMS service is not part of this release.
298
299
Fair Sharing features aims at achieving several goals:
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 11/72

300
301
302
share resources between R99 users and HSDPA users in a fair way, ie.
resources are reserved for HSDPA users according to their needs (service to
establish and bitrate to achieve)
303
304
305
306
limit the number of HSDPA users according to the load of the system (amount
of users already admitted, depending on the services they have established
and the bitrates they need) so that each one can benefit from a certain level of
QoS
307
308
allow deploying new services on HSDPA that are no more best effort but needs
a guaranteed QoS (like streaming)
309
310
311
Fair Sharing consists in reserving an amount of resources for each established HSDPA
RAB which is a function of the bitrate needed for the service. Fair sharing applies to
power and OVSF code.
312
313
For I/B services, the bitrate is derived from a minimum bitrate provisioned at OMC-R as
a function of OLS (ARP and THP).
314
For Streaming Traffic, the bitrate is directly RANAP GBR (with an additional margin).
315
316
317
318
319
The amount of resources needed for the RAB is derived from this bitrate in all
circumstances (ie. whatever the resource usage due to other users), aiming at
guaranteeing this bitrate (in average for I/B) when there is radio congestion. For GBR
traffic, the RNC uses Node Bs feedback (on required power) in order to guarantee that
there is enough power reserved to achieve the GBR (if achievable!).
320
321
322
323
324
325
The reason for using a reservation based on a minimum bitrate is that this reservation
is only useful when all resources are consumed. While there are still some resources
available, HSDPA traffic can use them so HSDPA users can be provided a higher
bitrate. When all resources are consumed (from CAC perspective), the cell color is
supposed to be black so bitrates allocated to R99 traffic are reduced to the minimum
needed (red color of the iRM table) so the fairness between R99 and HSDPA is ensured.
326
327
Note: For DCH, a new cell load color Black has been introduced for better granularity:
Green < Yellow < Red < Black.
328
329
This reservation is integrated in the legacy R99 resources reservation mechanism

managed by the call admission control (CRNC function).
330
DCH
OK: admitted
common CAC
(for shared resources)
HS-DSCH
NOK: refused
331
332
333
334
If the admission of an HS-DSCH RB is refused then this is considered as normal CAC

failure, meaning that pre-emption or iMCTA can be triggered.
335
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 12/72

336
4.2.2 DESCRIPTION
337
4.2.2.1 FAIR BITRATE
338
339
The objective of the feature is to reserve resources (power, codes, ..) for each HSDPA
user while offering a differentiation per service and OLS. This is a function of the CRNC.
340
341
One way would be to directly provision resources needs according to the service & the
OLS.
342
OLS/service power, OVSF codes,..
343
344
Eg: I/B Bronze = 30dBm 0.5xSF16, I/B Silver = 33 dBm 1xSF16, I/B Gold = 36 dBm
2xSF16
345
346
This would not be applicable to GBR users (since amount of reserved resources
depends on GBR).
347
348
For convenience, the reservation is based on a bitrate (at application level, ie. above
RLC) that will be called the fair bitrate:
349
OLS/service fair bitrate power, OVSF codes, ..
350
351
Eg: I/B Bronze = 100 kbps, I/B Silver = 200 kbps, I/B Gold = 400 Kbps + 30dBm per
100kbps and 1xSF16 per 200kbps
352
353
For streaming services, this fair bitrate is derived from RANAP GBR (including radio
protocols overheads).
354
355
356
For I/B services, the fair bitrate will be provisioned at OMC-R as a minimum bitrate
(minBR), offering a differentiation per OLS (in fact ARP, THP and Traffic Class). If the
minBR is above RANAP MBR then the minBR for this RAB is downgraded to the MBR.
357
358
359
For I/B services, the operator has the choice to use this minBR as a MAC-hs GBR
(based on flag isDlPowerSelfTuningForPsIbAllowed), so that MAC-hs scheduler will
really try to enforce this minBR.
360
361
If minBR = 0 (for this TC/ARP/THP combination) then no GBR information is given to

Node B (or DRNC in case of Iur).
362
363
364
For minBR = 0, the operator can choose to reserve a minimum amount of resources.
This
amount
of
resources
will
be
based
on
an
OAM
bitrate
(minHsDschReservationForCac).
365
no
no
0
isminBRused
yes
fair bitrate
=0 ?
minBR
(TC, THP,
ARP)
Min()
yes
fair bitrate =
minHsDschReservationForCac
MBR
366
367
Fair bitrate determination for PS I/B RAB
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 13/72
Consider min (link color bitrate, iRM birate)

Bronze
Silver
Gold
DCH
RBrate1
Green
RBRate2
RBRate3
Yellow
Red
RBRate4
allocated DCH bitrate
Black
Cell color
Bronze
Silver
Gold
HS-DSCH I/B
min BitRate (capped to MBR)
RBrate1
RANAP GBR
HS-DSCH
Streaming
368
369
370
371
372
The main reason for not reusing the iRM table for HSDPA I/B RABs is due to the fact
that it is useless to provision different minBR for green and yellow cell loads (since there
is no resource shortage so HSDPA traffic can use these remaining resources).
373
374
The bitrate is determined by the SRNC. However the resource reservation is done by
the CRNC.
375
In case of Iur, the CRNC has no knowledge of the minBR (for PS I/B services):
376
377
378
379
380
If
the
operator
has
chosen
to
use
this
minBR
as
a
GBR
(isDlPowerSelfTuningForPsIbAllowed for this neighbouringRNC) then the DRNC
(CRNC) will receive a GBR information and will consider the MAC-d flow as a GBR one
(even though the traffic class of the RAB may be I/B). Thus it will reserve resources
based on this GBR.
381
382
383
384
385
If the operator has chosen to not use this minBR as a GBR then the DRNC (CRNC) will
not receive any information to determine the amount of resources that need to be
reserved (this would be also the case with a 3 rd party SRNC which follows a different
strategy).
In
this
case,
it
will
reserve
resources
based
on
minHsDschReservationForCac.
386
4.2.2.2 RESERVATION HIGH LEVEL VIEW
fair
bitrate
max
Power
reserved
Power per Kbps

Codes per Kbps Reservation factor codes (GBR)
Activity factor
(for I/B)
387
388
389
390
391
392
Codes
reserved
(over-)reservation factor applies only to GBR traffics (so also to PS I/B when
minBR is considered to be a GBR) ; for pure best effort traffics, it is 100%
activity factor is for I/B and is derived from OMC parameter

initialActivityFactorForIb ; for streaming, 100% activity is considered (since
reservation is based on RANAP GBR)
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 14/72

393
4.2.2.3 POWER RESERVATION
394
395
396
Some power is reserved for each RB mapped on HS-DSCH. The reservation is done or
updated each time a MAC-d flow is setup, deleted or reconfigured or on mobility of the
serving HS-DSCH cell.
397
398
399
400
It is updated periodically for GBR MAC-d flows by a self-tuning mechanism (thanks to

NBAP HS-DSCH Required Power common measurement). These MAC-d flows
correspond to Streaming RABs, and PS I/B RABs if the operator has provision a minBR
and he has decided to use this minBR as a GBR (isDlPowerSelfTuningForPsIbAllowed).
401
This power is released when the radio-bearer is released.
402
The CAC on power becomes (see [R16]):
403
404
R99 used + HSDPA Required Power (GBR) + HSDPA Reserved Power (non GBR)
< P traffic
405
R99 part is not modified from UA05.
406
HSDPA reservation is done as described below.
407
Self-tuned
408
Self-tuned
Pcch+Pocns+Pedch
DCH
HS GBR
Reservations
Extra power that can be used
HS nonGBR available for CAC
Power needed
P traffic
409
410
411
There is only one threshold for call admission (Ptraffic) that is common to DCH and HSDSCH traffics. This threshold is defined by:
412
Ptraffic max TxPower Pcch Psho Pocns Pedch
413
414
415
416
417
418
419
Pcch is the power reserved for Common Control Channels and is not self-tuned.
However an activity factor (FDDCell.ActivityFactorCCH) is applied to the the
power configured at OMC for CCH to obtain Pcch.. If it happens that CCH
consumes more than what was provisioned with Pcch then this extra-power will
be accounted in the DCH pool (even if there are no DCH established). In case
CCH consumes less the power difference (Pcch actual consumption of CCH)
will not be recovered to admit extra traffic
420
Psho is the power reserved for sho admission
421
Pocns is the power reserved for OCNS
422
423
Pedch is the power reserved for the DL channels related to E-DCH (power for EAGCH, E-RGCH and E-HICH (E-AGCH_E-RGCH_EHICH_TotalPower))
424
425
Derivation of the power from the bitrate:
426
The power to reserve for this HS-DSCH RAB is directly proportional to the fair bitrate:
427
power c * bitrate
428
429
The coefficient c is derived from OMC-R provisioning: dlTxPowerEstimation allows

defining the amount of power to reserve for several reference bitrates.
430
431
If the fair bitrate is between two reference bitrates then the RNC will perform a linear
interpolation between these two values.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 15/72

432
For example, if
433
dlTxPowerEstimation[a bps] = w watts and
434
dlTxPowerEstimation[b bps] = y watts
435
then the power z to reserve for c bps is
436
z = w + (c-a) * (y-w) / (b-a) with b < c < a
437
438
If the fair bitrate is above the highest reference bitrate provisioned by the operator then
the RNC will perform a linear interpolation from this highest reference value.
439
For example, if
440
dlTxPowerEstimation[a bps] = w watts
441
then the power z to reserve for c bps is
442
z=w*c/a
443
444
I/B Activity Factor:
445
446
For PS I/B MAC-d flows (either GBR or non GBR), the activity factor is taken into
account to weight the power reservation
447
448
Over-reservation factor:
449
450
451
There is no over-reservation factor GBR MAC-d flows since the RNC has an accurate
view of the power needed thanks to the NBAP measurement HS-DSCH Required Power
coming from the Node B.
452
453
Impact on cell color:
454
455
For R99 users, the power cell color that is used for iRM is modified to include the power
used by the HS-DSCH users.
456
457
A new cell load color (black) has been introduced for better granularity along with the
existing cell load colors for DCH and HSPA traffic.
458
Thus in the new configuration, Green < Yellow < Red < Black
459
460
Self-tuning of power for GBR MAC-d flows:
461
This section is applicable to GBR MAC-d flows.
462
463
464
At admission, reservation will be done as explained above (power as a function of

bitrate). For non-GBR MAC-d flows, this reservation will not change until the resources
are released (RB delete, moves to another serving cell)
465
466
467
468
469
In case of GBR MAC-d flow the Node B will send an NBAP Required Power for GBR
measurement (per SPI) to the RNC to inform that it needs a certain amount of power to
guarantee the GBR of all GBR MAC-d flows of a given priority level (SPI). This
measurement is given per SPI (corresponds to the power needed to ensure the GBR of
all MAC-d flows having this SPI).
470
471
From CAC perspective, the RNC only needs the total power required for all priority
levels.
472
473
474
On reception of a new NBAP measurement HS-DSCH Required Power, the new

requirement may possibly lead to consume all power resources (eventually going above
Ptraffic).
475
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 16/72

476
477
478
The NBAP HS-DSCH Required Power common measurement is configured by the

CRNC at cell setup when fair sharing is activated in the cell.
4.2.2.4 OVSF CODES RESERVATION
479
480
481
Some OVSF SF16 codes are reserved for each RAB mapped on HS-DSCH. The
reservation is done or updated each time a MAC-d flow is setup, deleted or reconfigured
or on mobility of the serving HS-DSCH cell.
482
483
As for power, the number of codes to reserve per HS-DSCH RB is derived from the fair
bitrate.
484
485
486
Contrary to power, the modulation capability of the UE (QPSK only or 16-QAM capable
derived from the HSDPA UE category) is taken into account because 16-QAM
modulation uses potentially less OVSF codes for the same throughput.
487
488
489
Even though modulation choice is under MAC-hs scheduler responsibility (so unknown
by the RNC), differentiating 16-QAM capable UEs allows to consider that these UEs will
bring a better usage of OVSF codes (in average).
490
491
492
493
Parameters ovsfCodesThroughputQpskUE and ovsfCodesThroughput16QamUE allow

the operator to define which bitrate can be achieved with one HS-PDSCH code
(1xSF16). The RNC will then perform a simple interpolation to deduce how many HSPDSCH codes are needed to ensure a given bitrate:
494
For QPSK UE (HSDPA categories 11 and 12):
495
Number of SF16 codes to reserve for MAC-d flow =
496
497
number)
498
For 16-QAM UE (HSDPA categories 1 to 10):
499
500
501
fair bitrate / ovsfCodesThroughputQpskUE [1xSF16] (it is a floating point
Number of SF16 codes to reserve for MAC-d flow =

number)
fair bitrate / ovsfCodesThroughput16QamUE [1xSF16] (it is a floating point
502
503
I/B Activity Factor:
504
505
For PS I/B MAC-d flows (either GBR or non GBR), the activity factor is taken into
account to weight the power reservation.
506
507
Over-reservation factor:
508
509
510
511
512
For GBR MAC-d flows the RNC can apply an over-reservation factor
(reservationFactorOnCodesForGbrTraffic) because it is much more important to
reserve enough codes for these flows than for best effort MAC-d flows, given that there
is no feedback from Node B when there are not enough HS-PDSCH codes to reach the
GBR.
513
514
515
516
517
518
519
520
4.2.2.5 OVSF TREE MANAGEMENT

Basically, the fair sharing feature modifies the OVSF tree management by reserving
some SF16 codes for HS-DSCH radio-bearers. These n codes are blocked for HSPDSCH and cannot be allocated to R99 radio-bearers, where n represents the sum for
all HS-DSCH radio-bearers. As for power the number of codes n is re-evaluated
according to the HSDPA traffic (new RAB admission, RAB release, reconfiguration,
moblity) but is not self-tuned.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 17/72

521
522
523
Mac-hs scheduler will make use of all codes not allocated to R99 (the yellow ones and
blue ones in some cases not all can be used), knowing that at least n will not be
allocated to R99. The usage of codes by the Node B is detailed after.
n
Allocated to R99 users

free
Reserved for HSDPA users
used by MAC-hs
524
525
526
4.2.2.5.1
RNC
527
528
529
At cell setup, as many HS-PDSCH codes as possible will be configured by RNC

(meaning that all SF16 codes except the ones blocked by CCH, SCCPCH, HS-SCCH,
E-AGCH and E-HICH/E-RGCHs).
530
531
The RNC will update the number of SF16 codes reserved for all HSDPA radio-bearers,
each time HSDPA traffic changes (see section [OVSF Codes reservation]).
532
If there are k HS-DSCH radio bearer established in the cell:
533
534
SF16ReservedForHsdpa = SF16 reserved for RB #1 + SF16 reserved for RB #2 .. + SF 16
535
536
As SF16 reserved for RB #i is a floating pointer number, n is derived by rounding up to

the nearest integer:
reserved for RB #k
n = ceil(TotalSF16ReservedForHsdpa ).
537
538
Call Admission:
539
For an HS-DSCH MAC-d flow the call admission will accept it if:
SizeBiggestSF16Pool - n >= 0
540
541
where
542
- n is the updated n including the incoming HS-DSCH RB (or reconfigured RB)).
543
544
545
- SizeBiggestSF16Pool represents the number of SF16 codes of the biggest pool of

free SF16 (free means not allocated or blocked by DCH, CCH, S-CCPCH, HS-SCCH,
E-AGCH, E-RGCH/E-HICH) as illustrated below
546
Allocated to R99 users
547
free
548
549
550
Biggest pool
551
552
553
554
For a DCH, CCH or MBMS, as in UA05, the first free code in the tree will be allocated.
However the RNC will verify that after the allocation of this code the following condition
is still verified:
SizeBiggestSF16Pool - n >= 0
555
556
where
557
- n is the number of SF16 reserved for HSDPA users
558
559
- SizeBiggestSF16Pool represents the number of SF16 codes of the biggest pool of

free SF16 after the allocation of this new R99 code
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 18/72

560
561
Code load calculation:
562
For each SF level, the RNC will consider that these n SF16 codes are blocked.
563
The code load calculation used for OVSF load monitoring is modified:
564
Code
load
load
1
NumberOfFreeCodesPer SpreadingFactor ( SFi )
1
NumberOfSpreadingFactors allSFi
SFi
565
566
567
becomes:
568
Code
1
NumberOfFreeCodesPer SpreadingFactor ( SFi ) n * SFi
1
NumberOfSpreadingFac tors allSFi

SFi
569
570
571
572
Where n *SFi/16 represents the codes that are reserved for HSDPA users at SFi level
(n being a number of SF16 codes).
573
574
575
NumberOfFreeCodesPerSpreadingFactor[SF]: codes configured as HS-PDSCH are

considered as free. Only codes allocated to CCH (including HS-SCCH, E-AGCH, ERGCH/E-HICH), DCH and MBMS are considered to be consumed.
576
577
Each time a code for a given SF is allocated for R99 radio-bearer (CCH, DCH),
NumberOfFreeCodesPerSpreadingFactor[] is updated (for all SF) as in UA05.
578
579
4.2.2.5.2
NODE B
580
581
HS-PDSCH codes handling is modified compared to UA05. They will not be

reconfigured using NBAP Physical Shared Channel Reconfiguration procedure.
582
Node B will manage a dynamic view of codes usable as HS-PDSCH.
583
584
585
After cell setup, the RNC will configure a set of HS-PDSCH codes (by usual NBAP
PSCR, configuring the whole tree as HS-PDSCH except common channels). MAC-hs
will use a subset of these codes.
586
587
588
The RNC is allowed to allocate codes for R99 traffic (including MBMS) in this HSPDSCH configured set (using NBAP Radio Link Setup, Addition and Reconfiguration):
this will be the nominal way of allocating codes to R99 traffic.
589
590
591
592
593
594
Node B maintains a view of the codes allocated to R99 in the HS-PDSCH set. These
codes will block some SF16 codes, so forbid the usage of these SF16 codes as HSPDSCH until the corresponding R99 codes are released (NBAP Radio Link
Reconfiguration and Deletion). MAC-hs is able to use only the biggest pool of free SF16
as HS-PDSCH (free means not blocked by R99 allocations) when there are several
pools of free SF16 due some codes blocked by R99 in between.
595
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 19/72

596
597
4.3
TRAFFIC FILTERING IN CELL OVERLOAD
4.3.1 127550 FEATURE AIM
598
599
600
601
The primary aim for the feature is to prioritise different requests for service and ensure
service to high priority requests under traffic overload situations. Two different scenarios is
identified to undergo this filtering procedure.
602
603
UEs in idle mode sending an RRC Connection Request to the network for
establishing a new connection.
604
605
UEs in PCH state sending a Cell Update message to the network requesting an
upsize from PCH state.
606
607
608
Calls are filtered based on the basic call type and group call type as configured for iMCRA
step 2.
4.3.1.1 CAC FAILURE RATE AND ARRIVAL RATE CALCULATIONS
609
610
611
Currently iMCRA uses the cell colour as a means to determine redirection to another carrier.
In addition 127550 introduces the ability to also use the connection request arrival rate and
the CAC failure rates to aid in the decision to redirect or reject a connection request.
612
613
614
615
The arrival/failure rates are both updated on a regular basis on a per cell basis and the
average calculated over a period of time via a sliding window mechanism. The averaged
value is compared against thresholds set for arrival rate and cac rates to determine if the
cell is overloaded.
616
CAC Failure Rate:

FailureRateInterval1
617
FailureRat e
NumberofConnectionsm etswithCac Failure
N 0
FailureRateInterval1
NumberofConnectionAt tempts
N 0
618
619
Each time a call admission fails in a particular cell, it is included in the CAC failure rate for
that cell
620
621
622
Failures due to resource unavailability in the cell are considered: e.g. CAC failure recorded
due to unavailable DL power resources, unavailable DL code resources, Overload etc (other
reasons like UE EcNo lower than qQualMin are not considered overload).
623
624
625
Call admission is monitored over a period of time and averaged over a small interval (Failure
Rate Interval = 30 sec) to yield a stable value which could then be compared against a
configured threshold.
626
627
Arrival Rate:
628
ArrivalRate
ArrivalRateInterval1
NumberofConnectionAt tempts
N 0
629
630
The RNC monitors the RRC Connection Requests coming from UEs over a short period and
the number of arrivals is then compared against a configured threshold.
631
632
633
634
A set of three options are identified by parameter carArrivalRate for arrival rate
computation, namely GlobalArrivalRate, CsArrivalRate and PsArrivalRate, each computing
the arrival rate in the corresponding domain based on the Domain Indicator IE in the RRC
Connection Request.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 20/72

635
636
637
For the option GlobalArrivalRate, it computes the ingress traffic irrespective of CN domain
attached to each new connection request to the network.
4.3.2 CONNECTION SETUP
638
639
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 21/72

Carrier Selection
Algorithm
False
Call
Type in
Action
Select next action list

entry
True
Carrier Selection List

processing
False
True
End of
Action
List?
True
Output: Target Carrier

(FDD Cell or RAT) or
REJECT
Target
Carrier
empty?
False
Update redirection
percentage figure
Target carrier =
Originating cell
Target carrier =
Originating cell
Redirection
required
according to
percentage figure
False
True
Is CSL
outcome
REJEC
False
True
False
isRrcFilteri
ngAllowed
enabled?
Perform
Redirection
True
Send RRC Connection

Reject with IE Frequency
info empty
640
641
Figure 1: Algorithm for Traffic filtering in Cell Overload for RRC Connection Requests.
642
643
644
645
If parameter isRRCFilteringAllowed is enabled on a cell basis then the traffic filtering

process is applicable to all the UEs making a new RRC Connection Request when the cell is
congested. RRC Connection Request filtering is overlaid over the existing UA8.1 iMCRA Step
2 feature (PM89857). 127550 reuses the same set of ImcraActionList and CarrierSelectionList
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 22/72

646
647
concept to determine whether the new RRC Connection Request would qualify for being
filtered.
648
649
650
If the cell is congested and if the configuration data allows it, a call requesting service may
be rejected via a RRC Connection Reject message with a wait time to prevent the UE from
receiving service for a period of time.
651
652
Calls that are rejected may re-attempt after the wait time and may go through the filtering
procedure again.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 23/72

653
4.3.3
UPSIZE FROM PCH STATE

UE in PCH state and
initiates a state transition
False
Call
Type in
Decision
Select next Decision

list entry
True
AO Upsize Decision List

processing
False
End of
Decisio
n List?
True
Decisio
n
empty?
True
False
Rejection
required
according to
percentage figure
False
True
False
Is
outcome
REJEC
True
Send Cell Update Confirm

with Wait Time IE set and
retaining UE in PCH state
Continue state transition procedure,

trigger iMCTA on AO Upsize subfeature if enabled
654
655
656
Figure 2: Algorithm for Traffic filtering in Cell Overload for Cell Update Requests
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 24/72

657
658
659
660
661
662
If the parameter isAOUpsizeFilteringAllowed is enabled (at both the RNC and cell levels),
then the traffic filtering feature is applied for UEs in PCH state performing a state
transition to the DCH state by way of Cell Update message. This functionality is available in
LR13.3. In congestion situation if the configuration data allows it, calls that are trying to
upsize from PCH to DCH may be rejected. These calls remain in the PCH state.
663
664
665
666
667
668
669
670
671
Once the class of the cell update request has been identified as subject to rejection (e.g.
which would be more likely to be the case for a low priority service such as non-CS or nonEmergency call), it sends out a Cell Update Confirm message retaining the UE in the
xxx_PCH state by populating the Wait Time IE in the Cell Update Confirm message sent to
UE . This would typically be the case if the request was for a low priority request and it falls
within the rejection percentage as defined. High priority requests (such as CS call) are
typically admitted to the cell. The wait time is populated by the time equal to the
configured parameter waitTimeAOFiltering, thus prevents any immediate initiation of new
Cell Update requests for a certain time period
672
673
The filtering procedure is applicable for cell update with cause UL data Transmission
only
Case
674
Next state
Device Type
Case 1: MT CS RAB
CELL_PCH or URA_PCH
Establishment
UE is in CELL_PCH/URA_PCH
and CS CN requests establishment
of a new service. RNC pages UE.
The UE responds with cell update
msg w/ cell update cause=UL
Data Transmission and
Establishment Cause is
Terminating Conversational
Call
CELL_DCH
R5 onward that support

Establishment Cause
Case 2: MO CS RAB
CELL_PCH or URA_PCH
Establishment
and requests establishment of a
new CS call. UE send cell update
msg w/ cell update cause=UL
Data Transmission and
Establishment Cause is
Originating Conversational Call
Case 3: DL PS Traffic
CELL_PCH or URA_PCH
Resumption
and PS CN sends DL UP data to
RNC. RNC page UE and UE
responds with cell update msg with
cell update cause= Paging
Response
(No Establishment Cause sent)
(No TVI)
Case 4: UL PS Traffic
CELL_PCH or URA_PCH
Resumption
Mono PS I/B where UE is in
CELL_PCH/ URA_PCH and
requests UL data transfer. UE send
cell update msg with cell update
cause=Uplink Data
Transmission
TVI Included
(No Establishment Cause sent)
CELL_DCH
SRB3.4 + PS 0/0 SRB3.4 Establishment Cause
+ CS + PS 0/0
(with PM108389)
SRB13.6 + PS 0/0
SRB3.4 + CS + PS 0/0
(with PM159246)
675
Initial state
SRB3.4 + PS 0/0 SRB3.4

+ CS + PS 0/0
(with PM108389)
SRB13.6 + PS 0/0
SRB3.4 + CS + PS 0/0
(with PM159246)
CELL FACH
(with PM108389)
CELL_DCH (PS I/B TRB +
SRB)
(with PM159246)

SRB)
(with PM108389)
(TVI included)
SRB)
(with PM159246)
(with or w/o TVI)

Establishment Cause
R6 onward for TVI support
Figure 3: Scenarios for PCH upsize to DCH
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 25/72

676
677
4.3.4 A.ON UPSIZE INTER-ACTION
678
Traffic filtering cannot be applicable to legacy A.On upsize step2.
679
Full details are available in [R21] for A.On upsize.
680
681
4.3.5 CONFIGURATION MANAGEMENT
682
Name
isRrcFilteringAllowed
Object/Class
RadioAccessService
isAcbForRrcFilteringAllowed
RadioAccessService
isAOUpsizeFilteringAllowed
RadioAccessService
isRrcFilteringAllowed
FDDCell
isAOUpsizeFilteringAllowed
FDDCell
waitTimeRrcFiltering
FDDCell
isAcbForRrcFilteringAllowed
FDDCell
acbEventFrameworkIdList
FDDCell
acbActivationTimer
FDDCell
crrFailureRate
CarrierRejectionCondition
Definition
This parameter is an activation flag
that allows to take into account
csrArrivalCondition and
csrFailureCondion in
CarrierSelectionCondition
which activates/ deactivates
automatic trigger for ACB feature
filtering for upsize from PCH to
DCH state
that allows to take into account
csrArrivalCondition and
csrFailureCondion in
filtering for upsize from PCH to
DCH state
Determines the time UE should
wait before attempting a new RRC
Connection Request
automatic trigger for ACB feature
at cell level
Reference to a list of instances of
the EventFramework object applied
for triggering ACB
This parameter defines the interval
for the evaluation of access class
barring in relation to overload. The
rate monitor metric is evaluated
every acbActivationTimer * 2
seconds to determine whether to
trigger/deactivate access class
barring.
Variable to be defined for
validating the rejection condition
with respect to CAC failure rate,
e.g. GlobalCacFailure,
CSCacFailure, PSCacFailure
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 26/72

crrFailureThreshold
CarrierRejectionCondition
carArrivalRate
CarrierArrivalCondition
carArrivalThreshold
CarrierArrivalCondition
683
684
685
4.4
Threshold to be defined for the

corresponding variable defined in
crrFailureRate
Variable to be defined for
validating the rejection condition
with respect to arrival rate, e.g.
GlobalArrivalRate, CSArrivalRate,
PSArrivalRate
Threshold to be defined for the
corresponding variable defined in
crrArrivalRate
SELECTIVE PAGING DISCARD
4.4.1 131683 FEATURE AIM
686
687
688
689
690
The primary aim for the feature is to selectively discard lower priority (compared to other
services) paging request messages towards cells in severe cell overload conditions, thus
reducing the traffic demand during localized overload events. This feature applies to per
Core Network domain and paging cause, where as paging messages are discarded (via
configurable % values), when the trigger-criteria > configurable threshold.
691
The trigger-criteria are intended to include one or more of the following 3 criteria:
692
Cell colour
693
RRC arrival rate
694
CAC failure %
695
696
697
698
There may be one or more supported trigger-criteria sets, and each trigger-criteria set will
activate a specific configuragble paging-discard-profile. Further, the paging-discard-profile,
will provide the ability to specify degree of paging discards on a per-domain basis as well as
on a per-cause basis.
699
700
701
Paging messages would no longer be discarded, when all of the configured trigger-criteria
fall below their associated configurable thresholds. The feature should also provide
accounting of discarded paging due to cell overload (for inclusion in applicable KPIs).
702
The feature is applicable to UEs in idle & XXX_PCH mode.
703
704
705
706
4.4.2 ACTIVATION
Like for Access Class Barring feature, 3 activation triggering events can be considered for
this feature by order of precedence (from highest priority to lowest priority):
707
Manual SPD Activation
708
709
Automatic SPD Activation based on Cell overload and/or CAC failure Rate and/or
RRC Arrival Rate
710
1) Automatic Selective Paging Discard Activation (activatable at cell level)
711
712
The principle of the Selective Paging Discard activation based on Cell Overload/CAC Failure
Rate/RRC Arrival Date is the following:
713
714
715
The feature can be activated by the operator at the cell level with a new activation flag
isSelectivePagingDiscardActivated (and with a new global activation flag
isSelectivePagingDiscardAllowed at RNC/RadioAccessService level)
Here is the algorithm for SPD activation based on configured trigger-criteria:
716
717
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 27/72

UE is in IDLE or XXX_PCH mode and is
SPD feature activated?
(isSpdAllowed=TRUE)
Result
TRUE
SPD Condition in SPD Activation List?
Result
TRUE
FALSE
SPD Condition Activation List Processing

Next SPD Condition List entry
Is SPD Condition empty?
Result
FALSE
TRUE
FALSE
End of SPD Condition List?
FALSE
Trigger-criteria conditions are met (based on cell

load/cac failure/arrival rate)?
Result
Result
TRUE
TRUE
Discard paging required according to percentage
Paging message is sent
Note: In case of manual SPD activation, the check in grey is not done.
718
719
720
721
722
723
According to a configurable discard percentage, this feature enables the operator to

discard paging based on CN domain Indicator IE (i.e. CS, PS) and/or Paging Cause
IE of RRC. The existing mechanism performed in feature n127550 (Traffic Filtering in cell
overload) is reused for the Selective Paging Discard feature activation. The decision to
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 28/72

724
725
726
trigger SPD feature (similar to AO Upsize Carrier Rejection Decision) is also based on the
cell load and/or CAC failure rate and/or RRC Arrival rate. Here is an example of Selective
Paging Discard Configuration:
SPD Automatic Activation List #4
#
Load
Type*
Op
*
Load
Value*
Failure
Rate*
Op
*
Failure Rate
Threshold*
(%)
Arrival
Rate*
Op
*
Arrival Rate
Threshold*
Decision
Domain
Discard
Percent
Paging
Cause*
DCH
Load
Black
CS
CAC
Failure
>=
10
CS
Arrival
Rate
>=
2000
Discard
CS
80
Term
Conv
Call
DCH
Load
Black
CS
CAC
Failure
>=
10
CS
Arrival
Rate
>=
2000
Discard
CS
70
DCH
Load
Black
PS CAC
Failure
>=
10
CS
Arrival
Rate
>=
2000
Discard
PS
85
DCH
Load
Black
Global
CAC
Failure
>=
10
Discard
PS
90
TermS
tream
Call
727
728
* - Optional, implies either Arrival rate can be defined or CAC failure rate can be defined,
not necessary to define both
729
730
731
Note: Within each rule, the conditions follow AND operation, i.e. Rule #1 CS Domain, Paging
Cause =TermConvCall, DCH Load = Black, CS CAC Failure >= 10% AND CS Arrival Rate >=
2000, implies DISCARD 80% of CS Paging.
732
733
734
735
When one first rule is satisfied (i.e. when one SPD trigger-criteria based on cell load and/or
cac failure and/or arrival rate is met), RNC triggers the paging discard according to the
configured thresholds (i.e. domain/paging cause/percentage value) and RNC stops to check
the other rules. When no rule is satisfied, no SPD is triggered.
736
737
738
739
It should be also noted that if the operator sets Load Type to callTypeLoad value as a
condition rule in the table above, this value is not meaningful for SPD feature. As
consequence, it is recommended to not configure Load Type with callTypeLoad value to
trigger SPD feature.
740
2) Manual Selective Paging Discard Activation (activatable at Cell level)
741
742
743
744
745
746
The feature can be manually activated by the operator at the cell level with a new activation
flag isManualSelectivePagingDiscardActivated (at fddCell MO). This manual activation is the
highest priority activation, as it doesnt depend on any other trigger-criteria (cf. Automatic
Selective Paging Activation below). In case of manual SPD activation, the operator can
configure as follows (Selective Paging Discard activation independent of cell load, cac failure
rate, arrival rate):
SPD Manual Activation List #4
#
Load
Type
*
Op
*
Load
Value*
Failure
Rate*
Op
*
Failure Rate
Threshold*
(%)
Arrival
Rate*
Op
*
Arrival Rate
Threshold*
Decision
Domain
Discard
Percent
Paging
Cause*
Discard
CS
90
TermC
onvCall
Discard
CS
80
Discard
PS
90
747
748
749
In case automatic SPD is activated (isSelectivePagingDiscardAllowed set to TRUE), when the

operator activates manual SPD on a cell (isManualSelectivePagingDiscardActivated set to
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 29/72

750
751
752
753
754
755
TRUE), the decision to discard paging according to configured manual thresholds will be
immediately invoked, even if automatic SPD activation conditions (ex: DCH load is not Black,
Arrival/CAC failure rates are below configured thresholds) are not satisfied. Moreover, if the
conditions for automatic SPD activation are satisfied while manual SPD is enabled, manual
SPD will take precedence. Once manual SPD is deactivated, automatic SPD precedence (and
potential activation) will resume.
756
4.4.3 INTERWORKING WITH OTHER FEATURES
757
1) Interworking with Access Class Barring and/or Fast dormancy
758
759
760
761
762
763
764
765
766
767
768
The Access Class Barring feature provides the operator with the ability to reduce the traffic
for a group of cells based on a specified percentage of non-emergency calls. The operator can
define the impact of class barring separately for CS or PS calls. This allows cells in overload
can take advantage of the Access Class Barring capability without unnecessarily impacting a
larger area. When ACB is triggered due to cell overload and/or arrival rate and/or cac failure
rate, the cell barring mechanism consists in barring access class to a given cell for all UEs.
When access class are barred the UE stays in the cell but can't do RRC connection: in such
case, RNC will allow the inactive UE to downsize to PCH. When Access Class Barring criterion
is triggered and Selective Paging Discard feature is activated at the same time, when an
Always-On downsizing is triggered by RNC, the UEs state should be forced to Idle mode (and
not PCH mode).
769
770
771
772
This also applies to the case where the UE sends an SCRI (e.g. Signaling Connection Release
Indicator) message and Fast Dormancy is activated (with isFastDormancyAllowed set to
TRUE). In this case, Fast Dormancy should not push the UE to PCH upon reception of SCRI;
instead it should allow the UE to transition to Idle mode.
773
774
775
To enable this new Always-on transition above (in red) in case of AO downsize, new
activation flags isAcbWithSpdAllowed (RadioAccessService) and isAcbWithSpdActivated
(fddCell) should be set to TRUE by the operator.
776
777
2) Interworking with Traffic Filtering
778
779
780
781
782
783
According to Figure 3 Case 3, the 131683 Selective Paging Discard feature provides coverage
for the missing coverage from 127550 Traffic filtering in cell overload. To enable the
interworking
with
Traffic
Filtering,
new
activation
flags
isDlPsTrafficResumptionWithSpdAllowed and isDlPsTrafficResumptionWithSpdActivated
should be introduced.As a result, whenever the SGSN sends a DL PDU to a UE who is in the
XX_PCH state, the following occurs:
784
785
786
Case 1: The resulting DL paging is (due to either manual SPD or automatic SPD)
discarded by SPD. In this case there is no interaction with 127550 because there is no
resulting CU.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 30/72
RNC
UE
SGSN
Nominal case of
DL PS Resumption
DL PDU
Selective Paging
Discard
Paging Type 1 (URNTI) RLC TM
In case of SPD is triggered

(conditions are met):
- Paging discarded by SPD
- VS.NbrCellUpdatesWithPagingResponse
is pegged
- Paging is not sent to UE
- No resulting CU from UE
Cell Update (Cause = paging response) _ RLC TM
Cell Update Confirm RLC UM (Wait Time = 15s)

RB Reconfiguration Complete RLC AM
Initial Direct Transfer (Paging Response)

Connection Request(RANAP Initial UE msg(Paging Rsp))
Connection Confirm
787
788
789
790
791
792
793
Case 2: The resulting DL paging is not discarded by SPD, resulting in a CU (Paging

cause). This is the missing use case from 127550 which is now included in 131683. In
this case, RNC sends Cell Update Confirm message retaining the UE in the xxx_PCH
state, the counter #1246 VS.AOUpsizeFilter introduced for Traffic Filtering algorithm
(FSD n127550) will be pegged.
RNC
UE
Nominal case of
DL PS Resumption
Traffic Filtering
PM127550
SGSN
DL PDU
Cell Update Confirm _ RLC TM (Wait Time=15s)

In case of Traffic Filtering is triggered
(conditions are met):
- Filter CU(paging) related to U-RNTI
- Resulting CUC is counted by
VS.AOUpsizeFilter
- No RB Reconfiguration is sent.
794
795
796
797
Case 3: Similar to Case 2 but UE resends a Cell Update before Wait Time expiration
(incuding in Cell Update Confirm message sent by RNC). In this case, the new counter
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 31/72

798
799
800
VS.RESERVED177 (VS.RrcConnReleaseDueToWaitTimeViolation in LR15W) should be

pegged instead of counter #1246 VS.AOUpsizeFilter and the Cell Update Procedure is
modified as follows:
RNC
UE
Nominal case of
DL PS Resumption
Traffic Filtering
PM127550
SGSN
DL PDU
Cell Update Confirm _ RLC TM (Wait Time=15s)

Wait Time
RRC Connection Release (Cause = congestion)
In case of Traffic Filtering is triggered

(conditions are met) and UE resends CU
before Wait Time expiration:
- Filter CU(paging) related to U-RNTI
- Peg counter VS.RESERVED177
(VS.RrcConnReleaseDueToWaitTimeViola
tion in LR15W) to indicate that the call
is released (do not peg counter
VS.AOUpsizeFilter for calls that are
released)
801
802
803
4.4.4 CONFIGURATION MANAGEMENT

Name
isSelectivePagingDiscardAllowed
Object/Class
RadioAccessService
isManualSelectivePagingDiscardAllow
ed
RadioAccessService
isAcbWithSpdAllowed
RadioAccessService
Definition
This parameter
activates/deactivates at RNC level
the automatic discard of paging
messages based on cell load and/or
Arrival Rate and/or CAC Failure
Rate.
This parameter
activates/deactivates within the
RNC the manual discard of paging
messages. This manual activation
shouldnt depend of trigger criteria
(cell load and/or Arrival Rate
and/or CAC Failure Rate).
This parameter
activates/deactivates within the
RNC the capability to perform AO
downsize and to release UEs in Idle
mode (instead of PCH mode)
when ACB and SDP features are
simultaneously activated (and some
Access Classes are barred) or when
Fast Dormancy (with
isFastDormancyAllowed set to
TRUE) and SPD features are
simultaneously activated.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 32/72

isDlPsTrafficResumptionWithSpdAllow
ed
RadioAccessService
isSelectivePagingDiscardActivated
FDDCell
isManualSelectivePagingDiscardActiva
ted
FDDCell
isAcbWithSpdActivated
FDDCell
isDlPsTrafficResumptionWithSpdActiv
ated
FDDCell
spdDomain
SpdCondition (New MO)
spdPercentage
spdPagingCause
This parameter activates the

mechanism which includes support
(in the Traffic Filtering algorithm)
for the use case where a Cell
Update message is received with
cause = Paging Response due to
UE DL PS Traffic Resumption.
This parameter enables/disables the
discard of paging messages
according to a configurable
percentage per domain and/or
paging cause at cell level. The
activation depends of trigger
criteria (i.e. cell load/arrival
rate/cac failure rate)
This parameter enables/disables the
manual SPD trigger according to a
configurable percentage per
domain and/or paging cause. This
manual activation priority is
typically configured higher than the
automatic activation as it is not
dependent of trigger criteria (i.e.
cell load/arrival rate/cac failure
rate). When this flag is enabled, its
SPD criteria supercede automatic
SPD (irrespective of whether it is
higher or lower).
This parameter
activates/deactivates at cell level
the capability to perform AO
downsize and to release UEs in Idle
mode (instead of PCH mode) when
ACB and SDP features are
simultaneously activated (and some
Access Classes are barred) or when
Fast Dormancy (with
isFastDormancyAllowed set to
TRUE) and SPD features are
simultaneously activated.
This parameter activates the
mechanism which includes support
(in the Traffic Filtering algorithm)
for the use case where a Cell
Update message is received with
cause = Paging Response due to
UE DL PS Traffic Resumption.
This parameter provides the
domain that can be impacted by the
SPD feature.
This parameter enables to provide a
percentage of paging discard per
domain or per paging cause.
This parameter represents all types
of paging-related causes related to
SPD feature.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 33/72

spdEventFrameworkId
spdConditionIdList
FDDCell
spdActivationTimer
FDDCell
804
Reference to an instance of the

EventFramework object applied for
triggering SPD (Selective Paging
Discard)
SpdCondition object applied for
triggering SPD.
This parameter defines the interval
for the evaluation of Selective
Paging Discard in relation to
overload. The rate monitor metric
is evaluated every
spdActivationTimer * 2 seconds to
determine whether to
trigger/deactivate Slective Paging
Discard. (similar timer to existing
acbActivationTimer)
805
806
4.5
MANAGEMENT OF UL RADIO RESOURCES CAC
807
4.5.1 UPLINK TOKEN BASED CAC
808
4.5.1.1 PRINCIPLE
809
810
811
The principle is to define a cost per UL RAB and a total UL capacity. At each
allocation/release/reconfiguration of an UL resource (as already performed for DL
power):
812
813
the UL load is incremented/decremented/adjusted in function of the source and

target UL RAB combination cost.
814
815
this UL capacity pool is compared to a threshold: if lower, the call is accepted

otherwise it is refused.
816
817
This will allow stopping admission before UL radio congestion.
4.5.1.2 SOLUTION DESCRIPTION
818
Let UL capacity threshold, be a parameter which defines the UL capacity.
819
Let UL cost (UL RAB) the cost for an UL RAB handled over a dedicated channel.
820
Initialisation of UL load
821
The proposal is to initialize UL load = 0 and to not account for UL common channels
822
UL load calculation
823
On establishment of an UL RAB combination:
824
UL load for test = UL load + Cost (RAB combi)
825
On release of an UL RAB combination:
826
UL load for test = UL load - Cost (RAB combi)
827
On reconfiguration from an UL RAB combination1 to an UL RAB combination2:
828
UL load for test = UL load + Cost (RABcombi2) - Cost (RABcombi1)
829
Afterwards, a CAC test is performed:
830
If UL load for test <= UL capacity, the call is granted and UL load = UL load for test
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 34/72

831
Otherwise the call is rejected.
832
Starting UA05.0, the Cost is configurable:
833
834
UL cost (UL RABcombination) = ulCostForUlTokenCac parameter configurable per

UserService
835
This feature impacts only RNC (and OMC) and does not impact Node B.
836
4.5.2 UPLINK RADIO LOAD
837
4.5.2.1 PRINCIPLE
838
839
840
The goal of controlling the Uplink is to maintain the UL load under fixed level. The current
absolute UL RTWP (i.e. Received Total Wideband Power) as defined in the 3GPP ([R6])
cannot be measured with enough accuracy (+/- 4 dB). It depends on:
841
N (thermal noise) depends on the temperature and varies in time
842
N also depends on the site conditions
843
Hence it is difficult to define fixed UL load threshold per site
844
845
Due to these constraints UL load cannot be controlled based on direct UL RTWP

measurement => Needs for enhanced estimation.
846
847
The scope of this feature is to define this UL load and its usage in the Node B basic
CAC and in the RNC as an UL load color for UL iRM table.
848
Estimation of UL load with a better
accuracy than with direct UL RSSI
measurement
UL load estimation
RB setup or
reconfiguration
UL iRM
UL CAC
N
RB rate is adapted to
maximize # of users at
the planned UL load.
RB
rejected
RB is admitted only if it
does not cause the
system to exceed the
planned UL load.
849
850
Boxes 1 and 2 are part of this feature.
851
852
Please note that whatever the fair sharing is disabled or enabled, the uplink radio CAC
is not modified.
853
854
4.5.2.2 SOLUTION DESCRIPTION

This feature can be divided into 7 sub-features:
855
configuration of NBAP COMMON MEASUREMENT BY THE RNC
856
self learning of the RTWPref at the Node B
857
calculation of UL load
858
estimation of the non E-DCH contribution to UL load
859
basic call admission control at the Node B

UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 35/72

860
coding and reporting of the UL load non E-DCH to the RNC
861
derivation of UL radio load color at the RNC
862
clean up of CAC on RACH on UL RSSI (suppress it)
863
864
865
CONFIGURATION OF NBAP COMMON MEAS BY THE RNC (RNC IMPACT)

If (isNbapCommonMeasRtwpAllowed = Yes), the RNC should send a Measurement
Control to the Node B with the following characteristics:
866
Measurement Quantity = RTWP
867
Reporting mode = Periodic
868
Period of reporting = NbapCommonMeasRtwpReportingPeriod
869
Filter coefficient = NbapCommonMeasRtwpFilterCoeff
870
871
872
This NBAP Common Measurement Request will configure the RTWP measurements in
the Node B and the reporting of RTWP towards the RNC.
SELF-LEARNING OF RTWPREF AT THE NODE B (NODEB IMPACT)
873
874
The self-learning is performed on all the cells of the Node B when the parameter
isRtwpReferenceSelfLearning is set to True.
875
876
The RTWP reference value (called RTWPref) should correspond to the minimum value
of RTWP values received in the cell when there are no connections in the Node B.
877
878
During the learning time (24hours), the Node B keeps the RTWPcurr values measured
(filtered by L3 filtering- param sent by the RNC) if no traffic in the Node B.
879
880
881
On expiry of the 24 hours, if the number of kept RTWP values is lower than
MinSamplesForValidity (10), the estimation of the RTWPref is not performed and the
previous RTWPref will be considered for the next 24 hours.
882
883
Otherwise the rtwpMinSamples (20) lowest values will be taken into account to derive
a mean value of RTWPmin.
884
885
The next RTWPref will be derived from the previous RTWPref and this RTWPmin
differently depending on the distance between RTWPref new and previous.
886
Please note that the first learning cycle is faster than 24 hours.
887
CALCULATION OF UL LOAD (NODEB LEVEL)
888
The UL load is calculated in the following way:
889
ULLoad 1 10 RoT ( dB) / 10
890
891
(RoT (dB) i.e. Rise Over Thermal ) being calculated as: RTWPcur(dBm)
RTWPref(dBm)
892
UL load is then bounded between 0 and 1
893
ESTIMATION OF NON E-DCH CONTRIBUTION (NODEB LEVEL)
894
895
896
For each E-DCH connection the SIR will be estimated in function of the SIR on UL
DPCCH and the gain factors. These SIR are cumulated and then the contribution of EDCH to the RoT is estimated.
897
898
The UL load due to non E-DCH will then be derived using the formula described in the
previous sub-function.
899
This step is performed only for E-DCH capable cells.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 36/72

900
ESTIMATION OF E-DCH CONTRIBUTION (NODEB LEVEL)
901
902
903
904
905
In LR14.2 feature PM122612 introduces an enhanced UL load estimation mechanism which

allows the RNC to account for a minimum E-DCH load when determining the radio load colour
(termed enhanced radio load colour), in addition to the existing non-EDCH load already
implemented. This allows the RNC RRM and CAC to respond to the overall system load
increase in a more timely and proactive manner.
906
Refer to [R18] for full details of this minimum E-DCH load.
907
908
BASIC CALL ADMISSION AT THE NODE B (NODEB LEVEL)
909
910
The Node B performs a very basic CAC without considering the cost of the link to be
established/reconfigured/released.
911
912
913
It compares the current UL load for non E-DCH calls (either derived from previous subfunction for E-DCH capable cells, or equal to UL load as calculated above for non EDCH capable cells) to an OMC-B configurable threshold.
914
In case this UL load is lower or equal, it is admitted, otherwise it is rejected.
915
916
917
918
919
920
921
922
This non E-DCH CAC threshold is configured in % at the OMC-B while in case the cell
is E-DCH capable, the total RoTmax E-DCH parameter is defined in dB at the OMC-R
and provided by the RNC to the Node B via the PHYSICAL SHARED CHANNEL
RECONF message. Hence, in case the cell is E-DCH capable, the operator should
convert the ROTmax into a % through the UL load formula described in the third subfunction and insure that it is higher than the CAC threshold of the OMC-B (in %). In case
this condition is not fulfilled, the CAC threshold used for non E-DCH will be RoT Total
max (the parameter defined on the OMC-R):
923
If (ROTtotalmax <= ROTnonE-DCH) => ROT used for DCH CAC will be ROT totalmax
924
CODING AND REPORTING OF THE ROT TO THE RNC (NODE B LEVEL)
925
In case the cell is E-DCH not capable:
926
927
The ROT total derived as RTWPcur - RTWPref is coded into a RTWP like measurement
by:
928
RTWP 106.1 RoTtotal (dB)........(indBm )
929
In case the cell is E-DCH capable:
930
931
The RoT for non E-DCH calls (derived in 4.3.4) will be coded into a RTWP like
measurement by:
932
RTWP 106.1 RoTnon E DCH (dB)........(indBm )
933
And sent as RTWP in the Common Measurement Report.
934
935
936
See [R18] for more details on RTWP calculations.
DERIVATION OF THE UL RADIO LOAD COLOR BY THE RNC (RNC LEVEL)
937
938
On the reception of the common measurement report holding the RTWP, the RNC
decodes back the RoT by doing:
939
RoT (dB) RTWPreceived (dBm) 106.1
940
Then the UL load non E-DCH will be derived by:
941
UL _ Load non E DCH 1 10 RoTnon E DCH ( dB) / 10

UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 37/72

942
It will use it as the UL load from non E-DCH calls.
943
For full details on cell color calculation, please refer to [R17]
944
945
946
In LR14.2 feature PM122612 introduces a new method of calculating the cell colour.
Please refer to [R18] for full details of calculation.
947
948
LR14.2 PM122612 E-DCH400 CAC
949
950
951
952
953
954
The parameter cellLoadCacForEdch400kbs controls the allocation of E-DCH400

resources at the RNC. If cellLoadCacForEdch400kbs is set to TRUE and the UL radio
load colour is equal to or worse than maxColorForEdchClassic or if the number of
active EDCH users is larger than or equal to maxNumActiveUsersForEdchClassic,
then the RNC selects EDCH400 for existing or incoming EDCH PS RABs (or legs) for
the call.
955
956
The parameter maxColorForEdchClassic can take the following values: {Green(0),

Yellow(1), Red(2), Black(3)}
957
The value Green is used to bypass the UL radio load colour condition
958
959
960
The calculation of the cell colour based on the UL radio load must be activated for the
cell colour to be used: i.e., isUplinkRadioLoadEnabled and
isUlRadioLoadColourEnabled must both be set to True.
961
See [R18] for enhanced cell colour calculation information.
962
963
964
965
If the UL radio load colour is equal to or worse than maxColorForCacSrbEdch, or if the

existing number of active EDCH users is larger than or equal to
maxNumActiveUsersForCacSrbEdch, then the RNC selects SRB over DCH for
existing or incoming E-DCH PS RABs (or legs).
966
967
maxColorForSrbEdch = maxColorForEdchClassic enforces the use of SRB over

DCH during high load
968
969
maxColorForSrbEdch = Green (disabled) allows SRB over E-DCH400 to be used

in high cell load.
970
971
972
The number of active E-DCH users is managed by PM82602 R2 (based on MAC-es

PDU throughput), which requires that useEnhancedUserActivityDetection be set to True
(sub-feature 82602 R2 enabled).
973
974
Setting maxNumActiveUsersForEdchClassic = '0' disables the use the active E-DCH

for SRB type determination.
975
976
maxNumActiveUsersForCacSrbEdch = maxNumActiveUsersForEdchClassic
enforces the use of SRB over DCH during high load.
977
978
maxNumActiveUsersForCacSrbEdch = 0 (disabled) allows SRB over EDCH400

to be used in high cell load.
979
980
981
Note: The E-FACH contribution to E-DCH UL Load is taken into consideration at the
NodeB via the serving users contribution. Therefore the presence or not of E-FACH
makes no difference to the RNC algorithms or thresholds used for E-DCH400 CAC.
982
983
984
985
986
987
4.6
MANAGEMENT OF RADIO RESOURCES SHORTAGE

In order to setup high priority HSDPA service, the Soft congestion is triggered to make the
established lower priority HSDPA service / user fallback to DCH, as well optionally queue
incoming HSDPA service request in internal queue to retry the establishment after certain
period. The behaviour of soft congestion in RNC is similar with pre-emption, however soft
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 38/72

988
989
congestion is triggered as first step in case of HSPA setup CAC failure while pre-emption
is called as last rescue method as it is shown in the figure below.
Soft Congestion feature is called only in case of CAC
119026
Soft Congestion
failure = maximum number of HSxPA connexion reached
CAC
failure
No call drop is
initiated if
SoftCongestion
If the targeted call failed to be fall backed to DCH, it

should be maintained in his old status (HSPA status,
unchanged). It means no call drop happened due to
soft congestion
990
991
992
The FRS 119026 Soft Congestion is based on the following assumptions:
993
Assumption 1
994
995
Only Rab Assignment Procedure can trigger soft congestion procedure, other case
(Mobility, always etc) is out of scope of UA8.1.
996
997
Here: RAB Assignment Procedure means RNC received the RANAP RAB assignment
Request message, it may contain following requirement from the Core Network:
998
a. Set up one or more Rabs
999
b. Delete one or more Rabs
1000
c.
1001
1002
RNANP Iu Release triggered Rab release is not considered Rab assignment

procedure.
Modify one or more Rabs
1003
1004
In LR15.2, following triggering procedures also got included for soft congestion.
1005
AO Upsize
1006
AO Upsize from PCH to DCH
1007
AO Upsize from FACH to DCH
1008
1009
Soft congestion also became applicable for above procedures of Multi carrier (DC).
1010
1011
1012
1013
1014
Assumption 2
If the targeted call failed in its fall back attempt to DCH, it should be maintained in his
old status (HSPA status, unchanged). It means no call drop happened due to soft
congestion
1015
Assumption 3
1016
1017
1018
When soft congestion happens in one cell due to one high priority HSDPA CAC failure
in NodeB, de-congestion will be done on cell-level in RNC. It is RNC implementation
restriction.
1019
1020
1021
It means, one HSDPA call CAC fail, RNC know which cell is congestion by NBAP
message, then RNC will choose lower priority call in that cell to downgrade (not all cells
in that NodeB)
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 39/72

1022
1023
In LR15W, a parameter NodeBCacAtRNC have been to introduced to control the soft

congestion at Cell level of Board level.
1024
NodeBCacAtRNC = 0 : Soft congestion at cell level
1025
NodeBCacAtRNC = 0 : Soft congestion at board level
1026
1027
Assumption 4
1028
1029
If one UE has muli-Rab established in HSDPA, if and only if all HSDPA Rabs are
vulnerable to be downgrade to DCH, then this UE can be considered as vulnerable.
1030
Example: in the MIB configuration,
1031
PS Str on HSPA is not vulnerable as softcongestion target.
1032
PS I/B on HSPA is vulnerable as softcongestion target.
1033
1034
Then a UE with PS str over HSPA + PS i/B HSPA cannot be considered a target
candidate.
1035
1036
The RNC has to deal with two kinds of users:
1037
1038
The user who may trigger soft congestion actively when HSDPA CAC failure due to
maximum HSPA number users reached in NodeB.
1039
1040
1041
The user who should be reconfigured from HSDPA to DCH due to his priority level. It
means such user is a candidate, which may be chosen as candidate to be downgraded
from HSPA to DCH when soft congestion happens.
1042
Full details are available in [R23] & R[25].
1043
1044
1045
1046
1047
1048
In case where 119026 Soft Congestion has not resolved this CAC shortage issue, and
after trying IMCTA procedures, the uplink or downlink radio resource shortage still
present, a preemption mechanism is triggered on CAC failure on high priority calls.
When triggered, this mechanism downgrades or preempts lower priority calls in order
to free resources for the outstanding high priority calls.
1049
Full details are available in [R19].
1050
1051
1052
1053
RRC connection setup on a twin cell can be triggered on CAC failure based on the CAC
Action List in iMCRA Step 2 (89857). parameter isEmergencyCallRedirectionOnCac
has been introduced in iMCRA Step 2 to handle emergency call related application of
rrcRedirectionType (Parameter replaced from iMCRA Step 1 - 75069).
1054
Note that pre-emption is not applied for MBMS in this release. This means that:
1055
A MBMS session in PTM mode can not preempt MBMS or non-MBMS services
1056
1057
An ongoing MBMS session in PTM mode can not be preempted by another

MBMS PTM or non-MBMS service of higher priority
1058
1059
1060
In LR15.2, based on Soft congestion-Preemption interaction, Preemption will not be triggered when Soft
congestion is attempted for PS RAB.
1061
1062
1063
1064
As Part of Soft congestion enhancement (PM177049), Multi Carrier Access restriction based on cell
color is introduced in Release 15.2. Multi carrier access restriction introduces restriction on lower priority
users from accessing the DC resources based on cell load.
1065
1066
The following example configuration table illustrates the manner in which the rncAccessRestriction is
controlled based on the combination of OLS and cell load
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 40/72

OLS/Cell
Colour
Green
Yellow
Red
Black
Gold
Silver
Bronze
1067
Above is Sample OLS Vs Cell color matrix for mcAccessRestriction
1068
1069
Users will be allowed to access the DC resources if its OLS is allowed for current cell color of both
primary and secondary cell.
1070
1071
1072
1073
1074
1075
4.7
1076
1077
1078
1079
1080
1081
TRANSMISSION RESOURCES MANAGEMENT

The transmission resources management and CAC is fully described in [R20]
4.8
RNS INTER-RELEASE COMPATIBILITY USE CASES

This section deals with interworking use cases for "Redirection during RRC connection
Setup" (75069) and MBMS broadcast (31868) features. As this feature are CRNC
features, no interworking issues foreseen with an RNC Vn.
4.8.1 RNS VN+1 FACING RNS VN
1082
Case 1
SRNS Vn+1
DRNS Vn
Case 2
SRNS Vn
DRNS Vn+1
1083
Case 1
1084
No interworking issues foreseen.
1085
Case 2
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
4.8.2 RNS VN+1+ACTIVATED FEATURE FACING RNS VN

4.8.3 RNS VN+1+ ACTIVATED FEATURE FACING MIXED RNS

VN+1
4.8.4 RNS VN+1+ACTIVATED FEATURE FACING RNS VN+1

WITHOUT THE FEATURE
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 41/72

1096
1097
1098
4.8.5 RNS VN+1+ACTIVATED FEATURE FACING OTHER VENDOR

RNS
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 42/72

1099
OAM
1100
1101
Warning: The NTPs are the reference for the names and values regarding the OAM
items: the name and values of these OAM items can change until the CuR.
5.1
1102
CONFIGURATION MANAGEMENT
1103
For parameters related to MBMS (31868), see [R21].
1104
Parameters related to iMCRA Step 2 (89857)
1105
Name
isImcraActivated
Object/Class
RadioAccessService
fddUnsupportedTargetCarrierList
FDDCell
imcraServiceActionListId
RadioAccessService
imcraCacActionListId
FDDCell
fddRejectCellList
FDDCell
twinCellList
InterFreqHhoFddCell
isRedirectionBasedOnEstablishmentCau
se
FDDCell
isEmergencyCallRedirectionOnCac
FDDCell
waitTimeImcraRedirectFailure
FDDCell
userSpecificInfo
ImcraActionList
callType
ImcraAction
redirectPercentage
ImcraAction
carrierSelectionListId
ImcraAction
csrTargetCarrierList
CarrierSelectionRule
Definition
Feature activation flag for iMCRA
step 2 functionality in the RNC
Enables/disables inter band
redirection per pair of FDD
frequency bands.
iMCRA Action list object applied
for iMCRA service
iMCRA Action list object applied
for iMCRA service
List of up to 5 inter frequency twin
cells to which inter frequency RRC
redirection is not allowed to b
eperformed.
List of up to 5 inter-frequency twin
cells (co-located cells referenced
by Cell Id1) to which interfrequency RRC redirection is
considered.
Enables/disables the use of
establishment cause for call type
determination
Enables/disables emergency call
redirection in case of CAC failure.
Defines the wait time to provide to
UE in RRC connection reject
message in case of redirection of an
speech call to 2G or another FDD
carrier or to LTE.
User specific information for the
action list
Defines the call type for which the
action shall be applied
Action applied for the configured
percentage of calls
Reference to a carrier selection list
MO instance
List of applicable target carriers
The Cell identifier is used to uniquely identify a cell within the RNC.
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 43/72

csrCarrier
csrLoadType
csrOperator
csrloadValue
fddUnsupportedTargetCarrierList
FddCarrier
dlFrequencyNumber
ulFrequencyNumber
isPinitRrcRedirectionAllowed
FDDCarrier
FDDCarrier
RadioAccessService
green2YellowHspaPwrDlLoadThreshold
HspaCellLoadParameters
yellow2GreenHspaPwrDlLoadThreshold
yellow2RedHspaPwrDlLoadThreshold
red2YellowHspaPwrDlLoadThreshold
This parameter includes 2

additional values with values:
None no FDD carrier is to be
defined
Fo originating carrier to be
referenced
Load to be considered for load
condition
Operator for the load condition
Load of the configured load type
Defines which target carriers are
not supported for inter band
redirection
Downlink UARFCN
Uplink UARFCN
Activation/deactivation of the use
of the Pinit based on the ratio
between Total Transmitted power
used on originating cell and target
cells. It applies during RRC
redirection procedure.
This parameter defines the
threshold on HSPA Downlink
power cell load to transition from
green to yellow. The value
indicates the percentage of the cell
capacity being occupied, i.e. not
available to a new user. The lower
the value, the more capacity is
available.
yellow to green. The value
available.
yellow to red. The value indicates
the percentage of the cell capacity
being occupied, i.e. not available to
a new user. The lower the value,
the more capacity is available.
red to yellow. The value indicates
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 44/72

red2BlackHspaPwrDlLoadThreshold
black2RedHspaPwrDlLoadThreshold
green2YellowHspaCodesDlLoadThresho
ld
yellow2GreenHspaCodesDlLoadThresho
ld
yellow2RedHspaCodesDlLoadThreshold
red2YellowHspaCodesDlLoadThreshold
red2BlackHspaCodesDlLoadThreshold

red to black. The value indicates
black to red. The value indicates
codes cell load to transition from
green to yellow. The value
available.
yellow to green. The value
available.
yellow to red. The value indicates
red to yellow. The value indicates
red to black. The value indicates
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 45/72

black2RedHspaCodesDlLoadThreshold
red2BlackUlRadioLoadThreshold
UlIrmRadioLoadParameter
s
black2RedUlRadioLoadThreshold
UlIrmRadioLoadParameter
s
red2BlackCLCThreshold
IrmOnCellColourParamete
rs
black2RedCLCThreshold
rs
red2BlackPLCThreshold
rs
black2RedPLCThreshold
rs
red2BlackDlCEMThreshold
DlIrmCEMParameters
black2RedDlCEMThreshold
DlIrmCEMParameters
red2BlackUlCEMThreshold
UlIrmCEMParameters
black2RedUlCEMThreshold
UlIrmCEMParameters
red2BlackDlTLCThreshold
IrmIubTransportLoadPara
meters
black2redDlTLCThreshold
IrmIubTransportLoadPara
meters
1106

black to red. The value indicates
threshold on UL radio load for
transition from Red to Black
threshold on UL radio load to
transition from Black to Red
threshold on code load to transition
from Red to Black
threshold on code load to transition
from Black to Red
threshold on power load to
threshold on power load to
Threshold used for decision of
transition of Dl CEM Cell Load
Color from Red to Black
Threshold used for decision of
transition of Dl CEM Cell Load
Color from Black to Red
threshold on UL CEM load to
threshold on UL CEM load to
Threshold (in %) used for decision
of transition of Downlink
Transport cell Load Color from
Red to Black
Threshold (in %) used for decision
of transition of Downlink
Transport cell Load Color from
Black to Red
1107
1108
1109
1110
1111
1112
1113
1114
Fair sharing (33694)

UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 46/72

1115
1116
RNC
1..1
Radio Access
Service
0..400
NodeB
NodeB
NodeB
1..6
FddCell
FddCell
FddCell
1117
1118
1119
1120
1121
0..15
HSxPA R99
Resources
Sharing Cell
Class
Parameters in hsxpaR99ResourcesSharingCellClass:
Managed Object
HSxPA R99 Resources Sharing Cell Class
Attribute Name
dlTxPowerEstimation[]
Scope
Operator
Class/Detail
3-a2
Associated Event (3-a2 only)
Next RAB Assignment or mobility Transport Type switching
Mandatory / Optional
Mandatory
Range / Step / Unit
The number of elements in this list is exactly MAX_NB_BIT_RATES (7)

Integer [-350 150] in 0.1dB
A bit rate value is associated to each element in the list as follow:
0=64kbps,
1=128kbps
2=256kbps
3=384kbps
4=1000kbps
5=2000kbps
6=4000kbps
Definition
This parameter defines the estimated downlink power used by NodeB for a new
incoming service. It represents a power relative to P-CPICH power.
Managed Object
Attribute Name
ovsfCodesThroughputQpskUe[MAX_SF16]
Scope
Operator
Class
3-a2
1122
1123
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 47/72

Mandatory
Range / Step / Unit
Integer [014400] in kbps
Definition
Resulting HSDPA throughput for a QPSK only UE provided by one HS-PDSCH

code (SF16) (for QPSK only UE, ie HSDPA categoried11 to 12).
Only first value is meaningful (1xSF16).
Managed Object
Attribute Name
ovsfCodesThroughput16QamUe[MAX_SF16]
Scope
Operator
Class
3-a2
Mandatory
Range / Step / Unit
Integer [014400] in kbps
Definition
Resulting HSDPA throughput for a 16 QAM capable UE provided by one HSPDSCH code (SF16) (for 16 QAM capable UE, ie HSDPA categoried1 to 10).
Only first value is meaningful (1xSF16).
Managed Object
Attribute Name
initialActivityFactorForIb
Scope
Operator
Class
3-a2
Mandatory
Range / Step / Unit
Integer [0100%]
Definition
This parameter is a default activity factor to consider for initial admission on PS I/B
RAB.
Managed Object
Attribute Name
reservationFactorOnCodesForGbrTraffic
Scope
Operator
Class
3-a2
Mandatory
Range / Step / Unit
Integer [0500%]
Definition
This parameter is a corrective factor. It is applied to above codes reservation to

allow for more / less conservative reservation.
1124
1125
1126
1127
1128
1129
1130
1131
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 48/72

Managed Object
Attribute Name
minHsDschReservationForCac
Scope
Operator
Class/Detail
3-a2
Mandatory
Range / Step / Unit

Definition
Integer [0 .. 1024], in kbps,
Value 0 means that there is no minimum resource reserved for PS I/B RAB
on HSDPA.
This parameter defines a minimum bit rate to reserve resources for a new incoming
PS I/B HSDPA user.
1132
1133
1134
Parameters in existing MOs:

Managed Object
FDD Cell
Attribute Name
isHsxpaR99ResourcesSharingOnCellAllowed
Scope
Class
Operator
2
N/A
Mandatory
Range / Step / Unit
False, True;
Definition
This parameter allows or not the ability to share resources (DL power, OVSF
codes) between HS-DSCH and R99 calls for the HSDPA Cell Class instance.
Managed Object
FDD Cell
Attribute Name
hsxpaR99ResourcesSharingRef
Scope
Class
Operator
3-A1
N/A
Mandatory - Present if isHsxpaR99ResourcesSharingOnCellAllowed is set to

TRUE
Range / Step / Unit
015
Definition
Pointer to MO HSxPA R99 Resource Sharing.
Managed Object
FDD Cell Class
Attribute Name
isDlPowerSelfTuningForPsIbOnHsdpaEnabled
Scope
Operator
Class
3-A1
N/A
Mandatory
Range / Step / Unit
False, True;
1135
1136
1137
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 49/72

This parameter allows or not the RNC to send MAC-hs GBR (based on MinBR
configurable value) to the NodeB for PS I/B RAB on HSDPA.
Definition
This allows the RNC to perform DL power self-tuning for PS I/B HSDPA RB (based
on NBAP measurement HS-DSCH Required Power) and allows to guarantee minBR
by MAC-hs scheduler.
Managed Object
Neighbouring RNC
Attribute Name
isDlPowerSelfTuningForPsIbOnHsdpaEnabled
Scope
Operator
Class
3-A1
N/A
Mandatory
Range / Step / Unit
False, True;
Definition
This parameter allows or not the RNC to send MAC-hs GBR (based on MinBR
configurable value) to the Drift RNC in order to activate the DL power self-tuning for
PS I/B RAB on HSDPA.
1138
1139
Managed Object
Measurement Conf Class
Attribute Name
nbapMeasurementParameters.hsdschReqPwFilterCoeff
Scope
Operator
Class
N/A
Mandatory
Enum [014]
Range / Step / Unit
Definition
Enum (0 (0), 1 (1), 2 (2), 3 (3), 4 (4), 5 (5), 6 (6), 7 (7), 8 (8), 9 (9), 11 (10), 13 (11), 15
(12), 17 (13), 19 (14))
The filtering coefficient to be applied to the common measurements HS-DSCH
Required Power. Defines the coefficient filter used by NodeB.
1140
Managed Object
Measurement Conf Class
Attribute Name
nbapMeasurementParameters.hsdschReqPwReportingPeriod
Scope
Operator
Class
N/A
Mandatory
External Range / Step / Unit
Integer [103600000], in units of 1 ms, step 10ms
Definition
Defines the reporting period for HS-DSCH Required Power Common

Measurement.
1141
1142
For the OMC-B:
1143
Managed Object
BtsEquipment
Attribute Name
hsdpaCodeTreeManagementActivation
Scope
Operator
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 50/72

Class
N/A
Mandatory
External Range / Step / Unit
Boolean (TRUE, FALSE)
This parameter activates part of the feature. The CCM must monitor the code
occupancy all the time. If TRUE, HS-PDSCH code are determined by CCM and
HBBU is dynamically reconfigured. If FALSE, HS-PDSCH codes are determined by
the RNC and PSCR is directly applied.
Definition
1144
1145
1146
5.2
FAULT MANAGEMENT
1147
1148
NA
5.3
PERFORMANCE MANAGEMENT
1149
Counters are described in feature 29804.
1150
iMCRA Step 2 (89857)
1151
The following counters are reused in 89857
1152
COUNTER ID
409
Name
3GPP Name
NT_Rrc_connection_request
RRC.AttConnEstab
Location
Cell
Unit
Event
Range
31 bits
Type
CUM
Family
RRC Connection Establishment
Meaning, Description
Number of RRC connection request received

Reception RRC/RRC_CONNECTION_REQUEST
Cause for rrc establishement, from 3GPP TS 25.331
Originating Conversational call
Originating Streaming call
Originating Interactive call
Originating Background call
Originating Subscribed Traffic call
Terminating Conversational call
Terminating Streaming call
Terminating Interactive call
Terminating Background call
Emergency Call
Inter-RAT cell re-selection
Inter-RAT cell change order
registration
Detach
Originating High Priority Signalling
Originating Low Priority Signalling
Triggering Event
Screening Criteria
Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
Screening 7
Screening 8
Screening 9
Screening 10
Screening 11
Screening 12
Screening 13
Screening 14
Screening 15
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 51/72
Screening 20
Call re-establishment
Terminating High Priority Signalling
Terminating Low Priority Signalling
Terminating- cause unknown
Spare 12
Domain
N/A
Screening 16
Screening 17
Screening 18
Screening 19
Notes
This is incremented for any rrc connection request received.
Software component or entity: NOB_RRC
1153
COUNTER ID
404
Name
3GPP Name
NT_Rrc_connection_failure
RRC.FailConnEstab
Location
Cell
Unit
Event
Range
31 bits
Type
CUM

Meaning, Description Failed RRC Connection Establishments by Cause.
Triggering Event
Pegged when the RNC rejects an RRC connection request or the RNC receives no
response from UE after RRC connection setup sent.
Pegged against the cell the RRC Connection Reject is targeted for. For 'timeout' scenarios
see details under screening description
Screening Criteria
Cause for Failed RRC Connection Establishment
Screening 0
Timeout for first or any repeated RRC Connection Requests in the N300*T300 window,
when the 'RRC Connection Request' is received
Screening 1
unavailable dl code resources
Screening 2
unavailable dl power resources
Screening 3
Unspecified (Obsolete)
Screening 4
RSSI
Screening 5
Cell_FACH - Cause CAC or Unspecified (excluding lack of context)
Screening 6
Overload
Screening 7
3G to 2G Redirection for Emergency Calls
Screening 8
CAC (excluding FACH Ues)
Screening 9
Cell_DCH - lack of context, pegged when the number of DCH contexts in RNC_CALL
is exhausted.
Screening 10
Cell_FACH - lack of context, pegged when the number of FACH contexts in
RNC_CALL is exhausted.
Screening 11
No answer from the NodeB
Screening 12
Lack of C-RNTI
Screening 13
UE Ec/No lower than qQualityMin
Screening 14
Repeated 'RRC Connection Request' received in a different cell from the preceding
attempt (during the N300*T300 window). To be pegged in the cell where the 'RRC
Connection Request' prior to reselection was received.
Screening 15
In case the Manual Overload Control at NodeB granularity feature is activated,if the
number of RLS in the NodeB is exceeded the thresholdEventA,RNC starts to reject 'RRC
Connection Request'until the number of RLS in the NodeB is less than thresholdEventB
Screening 16
SRNC receives a "Radio Link Setup Failure" message causing RRC Connection Reject
to be sent
Family
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 52/72

Screening 17
Screening 18
Screening 19
Screening 20
Domain
3G to 2G Redirection based on cell load

3G to 3G redirection based on cell load
3G to LTE redirection based on cell load
Congestion Preemption Lower Priority
CS, PS, CS+PS
Notes
Software Component or entity: CELLRRM
V8.1
Created by PM89857, introduce color Black
1154
1155
COUNTER ID
423
Name
3GPP Name
NT_Rrc_connection_Attempt_Incoming
VS.RrcConnectAttIncoming
Location
Cell
Unit
Event
Range
31 bits
Type
CUM
Family

Number of times that RNC instructs UE to setup a call on a different cell with a different
frequency from the initial RACH cell.
RNC sends an RRC connection setup message in case of target cell is different from the
initial RACH cell.
Call establishment cause
Originating Streaming Call
Originating Interactive Call
Originating Background Call
Originating Subscribed Traffic Call
Terminating Conversational Call
Terminating Streaming Call
Terminating Interactive Call
Terminating Background Call
Registration
Call Re-establishment
Emergency Call
Other
CS
Triggering Event
Screening Criteria
Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
Screening 7
Screening 8
Screening 9
Screening 10
Screening 11
Screening 12
Screening 13
Screening 14
Screening 15
Screening 16
Domain
Notes
Software Component or entity: UE_CALL
1156
COUNTER ID
424
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 53/72
3GPP Name
NT_Rrc_connection_Attempt_Outgoing
VS.RrcCnnectAttOutgoing
Location
Cell
Unit
Event
Range
31 bits
Type
CUM
Family
Screening 16

Number of times that RNC instructs UE to setup a call on a different cell with a different
frequency from the initial RACH cell.
RNC sends an RRC connection setup message in case of target cell is different from the
initial RACH cell.
Call establishment cause
Originating Streaming Call
Originating Interactive Call
Originating Background Call
Originating Subscribed Traffic Call
Terminating Conversational Call
Terminating Streaming Call
Terminating Interactive Call
Terminating Background Call
Registration
Call Re-establishment
Emergency Call
Other
Domain
CS
Name
Triggering Event
Screening Criteria
Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
Screening 7
Screening 8
Screening 9
Screening 10
Screening 11
Screening 12
Screening 13
Screening 14
Screening 15
Notes
Software Component or entity: UE_CALL
1157
1158
The following new counters have been included in 89857.
1159
COUNTER ID
NEW
Name
VS.IRMTimeCellRadioColorBlack
3GPP Name
VS.IRMTimeCellRadioColorBlack
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
Load counter that tracks the percentage of time during a collection period that a particular cell is considered
black by iRM
Triggering Event
iRM changes cell colour to or from black
Screening Criteria
NONE
Domain
N/A
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 54/72

Notes
1160
V8.1
COUNTER ID
NEW
Name
VS_IRMTimeCellTxPowerColorYellow
3GPP Name
VS_IRMTimeCellTxPowerColorYellow
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
Load counter that tracks the percentage of time during a collection period that a particular cell is
considered Yellow( DCH TxPowerColor ) by iRM
Triggering Event
iRM changes cell DCH TxPowerColor to or from Yellow.
Screening Criteria
NONE
Domain
N/A
Notes
1161
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IRMTimeCellTxPowerColorRed
3GPP Name
VS_IRMTimeCellTxPowerColorRed
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Red (DCH TxPowerColor)by iRM
Triggering Event
iRM changes cell DCH TxPowerColor to or from Red
Screening Criteria
NONE
Domain
N/A
Notes
1162
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IRMTimeCellTxPowerColorBlack
3GPP Name
VS_IRMTimeCellTxPowerColorBlack
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 55/72

considered Black (TxPowerColor) by iRM
Triggering Event
iRM changes cell DCH TxPowerColor to or from Black
Screening Criteria
NONE
Domain
N/A
Notes
1163
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IRMTimeCellOvsfCodeColorYellow
3GPP Name
VS_IRMTimeCellOvsfCodeColorYellow
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Yellow(DL code color) by iRM
Triggering Event
iRM changes cell DL code color to or from Yellow.
Screening Criteria
NONE
Domain
N/A
Notes
1164
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IRMTimeCellOvsfCodeColorRed
3GPP Name
VS_IRMTimeCellOvsfCodeColorRed
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Red(DL code color) by iRM
Triggering Event
iRM changes cell DL code color to or from Red
Screening Criteria
NONE
Domain
N/A
Notes
1165
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IRMTimeCellOvsfCodeColorBlack
3GPP Name
VS_IRMTimeCellOvsfCodeColorBlack
Location
Cell
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 56/72

Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Black(DL code color) by iRM
Triggering Event
iRM changes cell DL code color to or from Black
Screening Criteria
NONE
Domain
N/A
Notes
1166
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_QosDlCemLdClrBlack
3GPP Name
VS_QosDlCemLdClrBlack
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Black(DL CEM load color) by iRM
Triggering Event
iRM changes cell DL CEM load color to or from Black
Screening Criteria
NONE
Domain
N/A
Notes
1167
V8.1
Created by PM89857
COUNTER ID
NEW
Name
VS_IrmTimeDlIubTransportColorBlack
3GPP Name
VS_IrmTimeDlIubTransportColorBlack
Location
Cell
Unit
0-100%
Range
31 bits
Type
Load
Family
QoS Performance
considered Black(Dl Iub Transport Color) by iRM
Triggering Event
iRM changes cell Dl Iub Transport Color to or from Black
Screening Criteria
Type of Downlink Iub transport resource
Screening 0
Iub Transport Color DL PS IB DCH

3GPP: DlPsIbDch
Screening 1
Screening 1 Descr.: Iub Transport Color DL PS STR DCH

3GPP: DlPsStrDch
Screening 2
Descr.: Iub Transport Color DL CS

3GPP: DlCs
Domain
CS, PS
Notes
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 57/72
1168
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_IRMTimeULRadioLoadColorBlack
3GPP Name
VS.IRMTimeULRadioLoadColorBlack
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered Black(UL Radio Color) by iRM
Triggering Event
iRM changes cell UL Radio Color to or from Black.
Screening Criteria
None
Domain
N/A
Notes:
Software component or entity: CELLRRM
1169
V8.1
COUNTER ID
New
Name
VS_QosUlCemLdClrBlack
3GPP Name
VS.QosUlCemLdClrBlack
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered Black(UL CEM load color) by iRM
Triggering Event
iRM changes cell UL CEM load color to or from Black
Screening Criteria
None
Domain
N/A
Notes:
1170
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_HsdpaTimeCellTxPowerColorYellow
3GPP Name
VS.HsdpaTimeCellTxPowerColorYellow
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA power load color Yellow by iRM
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 58/72
This counter only has meaning when PM81213 is enabled.

Triggering Event
iRM changes cell HSDPA power load color to or from Yellow
Screening Criteria
None
Domain
N/A
Notes:
1171
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_HsdpaTimeCellTxPowerColorRed
3GPP Name
VS.HsdpaTimeCellTxPowerColorRed
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA power load color Red by iRM.
Triggering Event
iRM changes cell HSDPA power load color to or from Red
Screening Criteria
None
Domain
N/A
Notes:
1172
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_HsdpaTimeCellTxPowerColorBlack
3GPP Name
VS.HsdpaTimeCellTxPowerColorBlack
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA power load color Black by iRM
Triggering Event
iRM changes cell HSDPA power load color to or from Black
Screening Criteria
None
Domain
N/A
Notes:
1173
V8.1
Created by PM89857
COUNTER ID
New
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 59/72

Name
VS_HsdpaTimeCellOvsfCodeColorYellow
3GPP Name
VS.HsdpaTimeCellOvsfCodeColorYellow
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA code load color Yellow by iRM
Triggering Event
iRM changes cell HSDPA code color to or from Yellow
Screening Criteria
None
Domain
N/A
Notes:
1174
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_HsdpaTimeCellOvsfCodeColorRed
3GPP Name
VS.HsdpaTimeCellOvsfCodeColorRed
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA code load color Red by iRM
Triggering Event
iRM changes cell HSDPA code color to or from Red
Screening Criteria
None
Domain
N/A
Notes:
1175
V8.1
Created by PM89857
COUNTER ID
New
Name
VS_HsdpaTimeCellOvsfCodeColorBlack
3GPP Name
VS.HsdpaTimeCellOvsfCodeColorBlack
Location
Cell
Unit
0-100%
Range
31 Bits
Type
LOAD
Family
QOS Performance
considered HSDPA code load color Black by iRM
Triggering Event
iRM changes cell HSDPA code color to or from Black

UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 60/72

Screening Criteria
None
Domain
N/A
Notes:
V8.1
Created by PM89857
1176
1177
Fair sharing (33694)
1178
1179
1180
RNC:
Number
Name
Status
308
NT_DL_Total_Tx_Power_R99Only
Added
309
NT_DL_Total_Power_HsdpaGbrOnly
Added
310
NT_DL_Total_Power_HsdpaNonGbrOnly
Added
1120
NT_IRMTime_DL_Codes_SF16ReservedForHsdpa
Added
1181
COUNTER ID
308
Name
NT_DL_Total_Tx_Power_R99Only
3GPP Name
VS.DlTtlTxPwrR99Only
Location
Cell
Unit
Type
CUM
Family
Power Management
DL TX power (of all codes not used for HS transmission) ratio P/Pmax received from NBAP common
measurement per cell.
Triggering Event
The reception of NBAP COMMON MEASUREMENT from NodeB to RNC including Tx Power of all
codes not used for HS transmission measurements. The corresponding screening corresponding to
the percentage of power used is incremented (measurement is periodic)
Screening Criteria
total downlink Power distribution percentage (5 buckets)
Screening 0
Descr.: ratio greater or equal zero and less than 20 3GPP: 00LeRatioLt20, First release: V6.0
Screening 1
Descr.: ratio greater or equal to 20 and less than 40 3GPP: 20RatioLt40, First release: V6.0
Screening 2
Descr.: ratio greater or equal to 40 and less than 60 3GPP: 40LeRatioLt60, First release: V6.0
Screening 3
Screening 4
Descr.: ratio greater or equal to 80 and less or equal to 100 3GPP: 80LeRatioLe100, First
release: V6.0
Domain
NA
Notes
It details the number of common measurements,
according to their respective ranges and during the reporting period
1182
1183
COUNTER ID
309
Name
NT_DL_Total_Power_HsdpaGbrOnly
3GPP Name
VS.DlTtlPwrHsdpaGbrOnly
Location
Cell
Unit
Type
CUM
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 61/72

Family
Power Management
Ratio between the DL total TX power reserved for GBR on HSDPA users (according to the reported
NBAP common meas HS-DSCH Req power from NodeB) and Pmax.
Triggering Event
The reception of NBAP COMMON MEASUREMENT from NodeB to RNC including HS-DSCH
Required Power measurements. The corresponding screening corresponding to the percentage of
power used is incremented (measurement is periodic)
Screening Criteria
Screening 0
Screening 1
Screening 2
Screening 3
Descr.: tratio greater or equal to 60 and less than 80 3GPP: 60LeRatioLt80, First release: V6.0
Screening 4
release: V6.0
Domain
NA
Notes
The HSDPA users to consider are the ones on which power self-tuning applies.
This ratio is based on the NBAP common measurement per cell received from the NodeB.
1184
1185
COUNTER ID
310
Name
NT_DL_Total_Power_HsdpaNonGbrOnly
3GPP Name
VS.DlTtlPwrHsdpaNonGbrOnly
Location
Cell
Unit
Type
CUM
Family
Power Management
Ratio between the DL total TX power reserved for non-GBR HSDPA users (the ones for which power
self-tuning is not applied) and Pmax.
Triggering Event
Modification of the pool of power dedicated to HSDPA non-GBR users (Not self-tuned HSDPA pool).
. The corresponding screening corresponding to the percentage of power used is incremented
(measurement is periodic)
Screening Criteria
Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
release: V6.0
Domain
NA
Notes
The HSDPA users to consider are the one for which power self-tuning is not applied.
The DL Tx power consumption for these users is estimated based on MIB provisioning
and depends on:
the user's priority (TC / THP / ARP) for PS I/B RAB with GBR,
Ranap GBR for PS Streaming RAB.
1186
1187
1188
1189
COUNTER ID
1120
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 62/72

Name
NT_IRMTime_DL_Codes_SF16ReservedForHsdpa
3GPP Name
VS.IRMTimeDlCodesSF16RsrvHs
Location
Cell
Unit
Number of SF16 codes
Type
LOAD
Family
QOS Performance
Load counter that tracks the average number of DL codes (on SF 16 only) reserved for HSDPA users
at RNC level.
Triggering Event
DL channelization code reserved or freed up for HSDPA services (on SF 16).
Screening Criteria
None
Domain
NA
Notes
OVSF code tree management evolves with PM33694:
At cell setup, codes are reserved for CCH, MBMS, HS-SCCH, E-xxCH, as in UA05.0. All the remaining available SF16 are
then allocated for HS-DSCH at NodeB level. At this stage, there is still no code reserved for HS-DSCH (RNC view).
Each new HSDPA RAB allocation leads to SF 16 code reservation. These codes are blocked / reserved for HSDPA and can
not be allocated for R99 traffic. This counter tracks the average number of DL codes blocked for HSDPA.
Note counter 1120 is pegged per cell and not per referenced cell. Indeed, it shall be triggered on each cell (cell being the
primary or not).
1190
1191
1192
PM122612 E-DCH Performance Enhancements

The following counters have been introduced by PM122612 to aid UL CAC understanding:
Counter ID
1539
Name
VS_UplinkCacLoad
3GPP Name
VS.UplinkCacLoad
Location
Cell (Reference)
Unit
event
Type
LOAD
Family
HSUPA - CAC
Meaning,
Description
This counter takes the UL RSSI count and converts it into a CAC load measurement
via the following calculation:
UlCACLoad as a percentage = 1 1/ (10^((RSSI Noise Floor)/10).
The reception of NBAP COMMON MEASUREMENT from NodeB to RNC.
For iBTS:
If useEnhancedRadioCacUlLoad is set to True

o
Triggering
Event
UplinkCacLoad = enhanced UL radio load
Else,
o
If isNbapCommonMeasRsepsAllowed is set to False
UplinkCacLoad = non-EDCH load
If isNbapCommonMeasRsepsAllowed is set to True
Derived from total RTWP and RSEPS
For OneBTS:
If useEnhancedRadioCacUlLoad is set to True

UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 63/72

o
Else,
o
Screening
Criteria
None
Domain
CS+PS
UplinkCacLoad = enhanced UL radio load

1193
Counter ID
1540
Internal ID
New
Name
NT_DistUplinkCacLoad
3GPP Name
VS.DistUplinkCacLoad
Location
Cell (Reference)
Unit
event
Type
CUM
Family
HSUPA - CAC
Meaning, Description This counter shows the distribution of the calculated UL CAC load.
Triggering Event
The reception of NBAP COMMON MEASUREMENT from NodeB to RNC.
Screening Criteria
Percentage ranges
Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
Screening 7
Screening 8
Screening 5
Domain
1194
1195
1196
1197
1198
Descr.: 0<= range <10

3GPP: 0To10 First release: LR14.2
Descr.: 10 <= range <20
Descr.: 90 <= range <=100
CS+PS
PM131683 Selective Paging Discard

The following counters have been added by PM131683:
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 64/72

Counter ID
#1081
Name
NT_Paging_Discard_Per_Cause_Cs
3GPP Name
VS.PagingDiscardPerCauseCs
Location
Cell
Unit
event
Range
31 Bits
Type
CUM
Family
Paging
Meaning,
Description
Triggering Event
It represents the number of CS paging messages discarded by the RNC according

to the criteria- trigger(s) (e.g. cell color and/or arrival rate and/or cac failure rate)
and the percentage discards per paging cause (configured by the operator). This
counter is used to count the number of paging discard per paging cause (*).
CS Paging messages are discarded when criteria- trigger(s) are met (per
domain/paging cause).
Screening Criteria Paging Cause

Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
1199
1200
1201
1202
1203
1204
1205
Descr.: Terminating Conversational Call

3GPP: TerminatingConversationalCall First release: LR14.1
Modification: NEW
Descr.: Terminating Streaming Call
3GPP: TerminatingStreamingCall First release: LR14.1
Modification: NEW
Descr.: Terminating Interactive Call
3GPP: TerminatingInteractiveCall First release: LR14.1
Modification: NEW
Descr.: Terminating Background Call
3GPP: TerminatingBackgroundCall First release: LR14.1
Modification: NEW
Descr.: Terminating High Priority Signalling
3GPP: TerminatingHighPrioritySignalling First release: LR14.1
Modification: NEW
Descr.: Terminating Low Priority Signalling
3GPP: TerminatingLowPrioritySignalling First release: LR14.1
Modification: NEW
Descr.: Terminating Cause Unknown
3GPP: TerminatingCauseUnknown First release: LR14.1
Modification: NEW
Domain
CS
Notes
This is incremented for paging that is discarded at I-Node (PMC-RAB).

Screening 2 and 3 should be always set to zero.
(*): In case of dual paging/repeated paging, this counter shouldnt be pegged when possible. As this
counter is at Uplane side, Uplane can only avoid pegging the counter twice for the paging repetitions
that Uplane has knowledge of. For paging repetition triggered/processed in Cplane, Uplane has no
knowledge of which paging is which pagings repetition. So Uplane will peg the paging discard counter
independently. For paging repetitions that processed in Uplane, Uplane will avoid peg the counter
multiple times for the same paging record.
Counter ID
#1082
Name
NT_Paging_Discard_Per_Cause_Ps
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 65/72

3GPP Name
VS.PagingDiscardPerCausePs
Location
Cell
Unit
event
Range
31 Bits
Type
CUM
Family
Paging
Meaning,
Description
Triggering Event
It represents the number of PS paging messages discarded by the RNC according

to the criteria- trigger(s) (e.g. cell color and/or arrival rate and/or cac failure rate)
and the percentage discards per paging cause (configured by the operator). This
counter is used to count the number of paging discard per paging cause (*).
PS Paging messages are discarded when criteria- trigger(s) are met (per
domain/paging cause).
Screening Criteria Paging Cause

Screening 0
Screening 1
Screening 2
Screening 3
Screening 4
Screening 5
Screening 6
Descr.: Terminating Conversational Call

3GPP: TerminatingConversationalCall First release: LR14.1
Modification: NEW
Descr.: Terminating Streaming Call
3GPP: TerminatingStreamingCall First release: LR14.1
Modification: NEW
Descr.: Terminating Interactive Call
3GPP: TerminatingInteractiveCall First release: LR14.1
Modification: NEW
Descr.: Terminating Background Call
3GPP: TerminatingBackgroundCall First release: LR14.1
Modification: NEW
Descr.: Terminating High Priority Signalling
3GPP: TerminatingHighPrioritySignalling First release: LR14.1
Modification: NEW
Descr.: Terminating Low Priority Signalling
3GPP: TerminatingLowPrioritySignalling First release: LR14.1
Modification: NEW
Descr.: Terminating Cause Unknown
3GPP: TerminatingCauseUnknown First release: LR14.1
Modification: NEW
Domain
PS
Notes
This is incremented for paging that is discarded at I-Node (PMC-RAB).
1206
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 66/72

Counter ID
#1083
Name
VS_Downsizing_Direct_Success_ToIdle
3GPP name
VS. DownsizingDirectSuccessToIdle
Location
Cell
Family
UE State Transition
Type
Cum
Trigger event
Pegged when a RRC_CONNECTION_RELEASE message is sent to UE for AO Downsize

reason (number of successful communication release which reference cell is on serving
RNC).Number of succesful transition of a UE from DCH to Idle when AO downsize. In
addition to AO Downsize Measurement, Signalling Connection Release Indication or SCRI
(cf. Fast Dormancy feature) also causes a call release if decision is made to downsize
the call to PCH.
The counter will be pegged on the best cell of the Serving RNC, the UE was in Cell_DCH.
Range
31 bits
Unit
Event
Description
Number of successful UE transitions moving from DCH to idle on cell that is on serving
RNC during AO Downsize.
Screening Criteria
None
Domain
PS
Notes
Software component or entity: UE_CALL

RNC Role: PFLA-CALLP
1207
Counter ID
#1084
Name
NT_nbr_cell_updates_with_paging_response
3GPP Name
VS.NbrCellUpdatesWithPagingResponse
Location
Cell
Unit
event
Range
31 Bits
Type
CUM
Family
Cell / URA Update
Triggering Event
Number of Cell Update messages received with Cell Update cause value set to
Paging Response
RRC Cell Update received with Cell Update cause as Paging Response which
result in an AO upsize from PCH to FACH state (updates from PCH->DCH is
pegged by an already existing counter #1248 VS.NbrCellUpdatesByDomain ).
Screening Criteria
None
Domain
PS
Notes
Triggering conditions restricted to be only upsize from PCH to FACH (do not
include upsize from PCH to DCH that is already handled by an existing counter
VS. NbrCellUpdatesByDomain).
The counter is only applicable for PS.
1208
1209
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 67/72

1210
1211
6
6.1
1212
1213
1216
UPGRADES
NA
6.2
1214
1215
OAM PROCEDURES
INSTALLATION & COMMISSIONING PROCEDURES

NA
6.3
MAINTENANCE
NA
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 68/72

1217
1218
7
7.1
1219
1220
HARDWARE CONSTRAINTS
None
7.2
1221
1222
FIELD INTRODUCTION
SPARE PART CONSTRAINTS

None
7.3
1223
INTER RNS VERSION INTERWORKING

Please refer to section 5.4 where use cases are described
1224
7.4
CORE NETWORK INTERWORKING
1225
7.5
MS INTERWORKING
1226
1227
1228
None
7.6
GERAN INTERWORKING
None
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 69/72

1229
1230
8
8.1
ABBREVIATIONS AND DEFINITIONS

ABBREVIATIONS
ATM
CAS
CBC
CC
CDL
ChR
CM XML
CN
CuR
DER
DRNC
DRNS
DS1
E1
FAP
FRS
GBR
GPO
IP
KPI
MBMS
MCCH
MICH
MSCH
MTCH
NBAP
NE
NRP
OAM
OC3
PDH
PTM
PWI
RAN
RANAP
RDNID
RNC
RNS
RNSAP
RQMS
RRC
RTO
SAS
SDH
SI
SMLC
SONET
SRNC
SRNS
STM1
TIL
TML
TS
UTRAN
Asynchronous Transfer Mode

Component Administration System
Cell Broadcast Center
Cumulative Counter
Component Definition Language used in Passport
Channel Readiness
Configuration Management XML
Core Network
Customer Readiness
Discrete Event Registration
Drift RNC
Drift RNS
Digital Signal level 1 (1.544 Mbit/s)
Standard European PCM link (2.048 Mbit/s)
Feature Activation Procedure
Feature Requirements Specification
Guaranteed Bit Rate
General Permanent Observation
Internet Protocol
Key Performance Indicator
Multimedia Broadcast Multicast Service
MBMS PTM Control Channel
MBMS notification Indicator Channel
MBMS PTM Scheduling Channel
MBMS PTM Traffic Channel
Node B Application Part
Network Element (RNC or BTS)
Network Reconfiguration Procedure
Operation, Administration and Maintenace
Optical carrier-3 (155.52 Mbit/s)
Plesiochronous Digital Hierarchy
Point To Multipoint
Preside for Wireless Internet
Radio Access Network
Radio Access Network Application Part
relative distinguished name identifier
Radio Network Controller
Radio network subsystem
Radio network subsystem Application part
Reliability and Quality Measurements for Telecommunications Systems
Radio Resource Control
Real Time Observation
Standalone SMLC
Synchronous Digital Hierarchy
Status Inspection
Serving Mobile Location Center
Synchronous Optical Network
Serving RNC
Serving RNS
Synchronous Transport Module-1 (155.52 Mbit/s)
Terminal d'Installation Locale (Local I&C terminal)
Terminal de maintenance Locale (Local Maintenance Terminal)
Technical Specification
Universal Terrestrial Radio Access Network
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 70/72
1231
1232
VS
W-NMS
XML
WIPS
8.2
Vendor Specific
Wireless Network Management System (aka PWI)
eXtended Markup Language
Wireless Internet Provisioning System
DEFINITIONS
1233
Caution:
1234
Managed Object (MO) and component have the same meaning.
1235
Parameter and attribute have the same meaning.
1236
1237
Parameter Class
1238
1239
1240
Class 0: the parameter cannot be modified and a new object instance must be created
or recreated with the requested value thanks to build process or on line creation
command.
1241
1242
1243
Class 2: the object instance (or the parent object instance) must be locked to modify
the parameter and the modification will be taken into account after the object instance
(or the parent object instance) has been unlocked.
1244
1245
Class 3: the parameter can be changed on-line without impact on the service. The new
value is taken into account either immediately or for new calls only.
1246
Class 3-A1 new value immediately taken into account.
1247
1248
Class 3-A2 new value taken into account upon event reception (service establishment,
SRLR, for instance...).
1249
Class 3-B new value taken into account for next calls.
1250
1251
Data usage
1252
customer: the parameter is managed by the customer from the OAM.
1253
1254
1255
OAM Static Data: the item belongs to the OAM configuration data load and the
customer can not see and modify it. Its modification involves an OAM upgrade
procedure.
1256
1257
NE Static Data: the item belongs to the NE configuration data load and the customer
can not see and modify it. Its modification involves a NE upgrade procedure.
1258
1259
Customer category
1260
standard: the parameter can be used without restriction by the customer
1261
1262
reserve: the parameter must be used with caution by the customer because the
parameter modification has an impact on the KPIs.
1263
1264
dynamic data: the parameter can only be read by the customer because it comes from
the Network element.
1265
1266
1267
installationAndCommisioning the parameter must be used with caution by the

customer because the parameter is mandatory for the Network Element stat up. The
import/export DRF mechanisms ignore an installationAndCommisioning parameter.
1268
states & status: see [R13]
1269
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 71/72
END OF DOCUMENT
1270
UMT/SYS/DD/018826
10.02 / EN
Standard
20/03/2015
Page 72/72

UMTSYSDD018826LR15W V1 Call Admission Control

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UMTSYSDD018826LR15W V1 Call Admission Control

Загружено:

Авторское право:

Доступные форматы

Call Admission Control (Radio)

Copyright 2009-2015 Alcatel-Lucent, All Rights Reserved

Call Admission Control (Radio)

Issue 03.01/ EN, Draft, Author: M. Bruegmann

Creation based on 02.04 doc release

New Features: 75069

Issue 03.02/ EN, Standard, Author: M. Bruegmann

Change to Standard after review

Issue 04.01/ EN, Preliminary, Author: A. Agin

New edition issued to cover UA07.1

New feature: 31868

Issue 04.02/ EN, Standard, Author: A. Agin

Issue 07.01/ EN, Draft, Author: R.George

New edition issued to cover UA08.1

New feature: 89857

Issue 07.02/ EN, Preliminary, Author: M. Wargui

New feature: 119026 (soft congestion)

Issue 07.03/ EN, Standard, Author: M. Wargui

Issue 08.01/EN, Draft, Author: Bill Dickson

New edition to cover LR13W

New feature 127550

Call Admission Control (Radio)

New edition to cover LR13W

Issue 08.03/EN, Preliminary, Author: JF Lutier

New edition to cover LR13.3W

New feature 127550/168556/LR13.3

Updated for Soft congestion and Preemption enhancement (PM177049), 10.01/EN,

Call Admission Control (Radio)

APPLICABLE DOCUMENTS ..............................................................................................................7

FUNCTION OVERVIEW ................................................................................................................8

FUNCTIONAL DESCRIPTION ................................................................................................... 10

MANAGEMENT OF DOWNLINK RADIO RESOURCES IN CASE FAIR SHARING DISABLED .................... 10

CONFIGURATION MANAGEMENT ................................................................................................. 43

Call Admission Control (Radio)

HARDWARE CONSTRAINTS ......................................................................................................... 69

Call Admission Control (Radio)

downlink cell power,

downlink OVSF cell code tree,

uplink radio load,

uplink token model based CAC,

traffic filtering Services for UE coming from idle or XXX_PCH mode.

The transmission resources call admission control is moved into [R20].

SCOPE OF THIS DOCUMENT

This document is applicable upto LR15W.

127550 Traffic Filtering in cell overload

The following features are added for LR14W:

PM131683 Selective Paging Discard (cf. 4.4),

PM122612 E-DCH Performance Enhancement (cf. 4.5.2.2).

The following features are added for LR14W:

PM177049 Soft congestion Extension

AUDIENCE FOR THIS DOCUMENT

Call Admission Control (Radio)

UTRAN Uu interface RRC

UTRAN Iu interface RANAP signalling

UTRAN Iur interface RNSAP signalling

UTRAN Iub interface NBAP signalling

Requirements for Support of Radio Resource Management (FDD)

Physical Layer Measurements (FDD)

UTRAN Parameters User Guide

HSDPA system specification

Enhanced DCH system specification

UTRAN Power management

Intelligent RAB Mapping

E-DCH system specification