WCDMA UMTS Load Control Algorithm and Parameters ISSUE1.00

WCDMA Load Control Algorithm and Parameters N-1
WCDMA Load Control

Algorithm and
Parameters
www.huawei.com
Copyright © 2009 Huawei Technologies Co., Ltd. All rights reserved.
Confidential Information of Huawei. No Spreading Without Permission

Foreword
z The WCDMA system is a self-interfering system, so the capacity,
coverage, and QoS are mutually affected
z The target of load control is to maximize the system capacity

while ensuring coverage and QoS, and provide differentiated
services for users
Copyright © 2009 Huawei Technologies Co., Ltd. All rights reserved. Page2
z The WCDMA system is a self-interfering system. As the load of the system increases, the
interference rises. A relatively high interference can affect the coverage and QoS of
established services. Therefore, the capacity, coverage, and QoS of the WCDMA system
are mutually affected.
z Through the control of key resources, such as power, downlink channelization codes,
channel elements (CEs), Iub transmission resources, which directly affect user experience,
load control aims to maximize the system capacity while ensuring coverage and QoS.
z In addition, load control provides differentiated services for users with different priorities.
For example, when the system resources are insufficient, procedures such as direct
admission, preemption, redirection can be performed to ensure the successful access of
emergency calls to the network.
z Load control is implemented in the RNC through measurement reports from the NodeBs.

References
z 3GPP TS 25.133: Requirements for Support of Radio Resource
Management (FDD)
z 3GPP TS 25.215: Physical Layer - Measurements (FDD)
z 3GPP TS 25.304: UE Procedures in Idle Mode and Procedures for Cell
Reselection in Connected Mode
z 3GPP TS 25.321: Medium Access Control (MAC) Protocol Specification
z 3GPP TS 25.331: Radio Resource Control (RRC)
z 3GPP TS 25.413: UTRAN Iu Interface RANAP Signaling

Objectives
z Upon completion of this course, you will be able to:
Outline the principle of load control
Describe the realization method of load control
Perform the parameter adjustment of load control

Contents
1. Load Control Overview
2. Load Control Algorithms

Contents
1.1 Load Control Algorithms Overview
1.2 Load Measurement
1.3 Priorities Involved in Load Control

Load Definition
z Load: the occupancy of capacity
z Two kinds of capacity in WCDMA system:

Hard capacity:
Cell DL OVSF code
Iub transport resource
NodeB processing capability (NodeB credit)
Soft capacity:
Cell power (UL and DL)
z WCDMA network load can be defined by four factors:

Power, includes DL transmitting power of cell and increased UL interference (RTWP)
DL OVSF code of a cell.
DL and UL NodeB processing capability which is defined by NodeB credit.
Iub transmission bandwidth of a NodeB.
z The power resource is related to the mobility, distribution of the UE and also effected by
the radio conditions. Therefore, for a fixed power resource, the numbers of service can be
supported is not a fix result. We believe the UL and DL power resources are soft.

Load Control Algorithms

z The load control algorithms are applied to the different UE
access phases as follows:
PUC: Potential User Control CAC: Call Admission Control

IAC: Intelligent Access Control LDB : Intra-frequency Load Balancing
LDR: Load Reshuffling OLC: Overload Control
z In addition, functional load control algorithms vary depending on the load levels of the cell,
as shown in the following figure:

Load Control Algorithms (Cont.)

z Resources considered by different load control algorithms:
Resources
Load Control Algorithm
Power Code NodeB Credits Iub Bandwidth
PUC √ - - -
IAC √ √ √ √
CAC √ √ √ √
LDB √ - - -
LDR √ √ √ √
OLC √ - - √
–: not considered; √: considered

Contents

Load Measurement
z Load control function in the WCDMA system:
z The load control functions, such as OLC and CAC, use load measurement values in the
uplink and the downlink. A common Load Measurement (LDM) function is used to control
load measurement in the uplink and the downlink separately.
z Load measurement is implemented by the NodeB. The filtering of measurement quantities
is implemented by the NodeB and the RNC.

Load Measurement Quantities

z The major load-related measurement quantities are as follows:
Uplink Received Total Wideband Power (RTWP)
Downlink Transmitted Carrier Power (TCP)
Non-HSPA power: TCP excluding the power used for transmission on
HSPA channels
Provided Bit Rate (PBR) on HS-DSCH
PBR on E-DCH
Power Requirement for GBR (GBP) on HS-DSCH: minimum power required
to ensure the GBR on HS-DSCH
Received Scheduled E-DCH Power Share (RSEPS): power of the E-DCH
scheduling service

Load Measurement Procedure
z The NodeB measures the major quantities related to load control. After layer 3 filtering,
the measurement values are reported to the RNC.
z The RNC performs smooth filtering on the measurement values reported from the NodeB
and then obtains the measurement values, which further serve as data input for the load
control algorithms.

Load Measurement Procedure (Cont.)

z Layer 3 filtering on the NodeB side:
z A is the sampling value of the measurement
z B is the measurement value after layer 1 filtering
z C is the measurement value after layer 3 filtering
z C' is another measurement value (if any) for measurement evaluation
z D is the reported measurement value after measurement evaluation on the

conditions of periodic measurement and event-triggered measurement
z Layer 1 filtering is not standardized by protocols and it depends on vendor equipment.

Layer 3 filtering is standardized. The filtering effect is controlled by a higher layer. The
alpha filtering that applies to layer 3 filtering is calculated according to the following
formula:
z Here:
Fn is the new post-filtering measurement value.
Fn-1 is the last post-filtering measurement value.
Mn is the new measurement value from the physical layer.
α = (1/2)k/2, where k is specified by the UlBasicCommMeasFilterCoeff or
DlBasicCommMeasFilterCoeff parameter.
Set the above parameters through SET ULDM.
z PBR measurement does not use alpha filtering on the NodeB side.

z The NodeB periodically reports each measurement quantity to the RNC. The following
table lists the reporting period parameters for setting different measurement quantities.
Measurement Reporting Period Parameter

RTWP ChoiceRprtUnitForUlBasicMeas
TenMsecForUlBasicMeas
RSEPS MinForUlBasicMeas
TCP ChoiceRprtUnitForDlBasicMeas
TenMsecForDlBasicMeas
Non-HSDPA power MinForDlBasicMeas
ChoiceRprtUnitForHsdpaPwrMeas
GBP TenMsecForHsdpaPwrMeas
MinForHsdpaPwrMeas
z The Provided Bit Rate (PBR) measurement quantity is also reported by the NodeB to the
RNC. Different from other power measurement quantities, PBR does not undergo alpha
filtering on the NodeB side.
Measurement Reporting Period Parameter

ChoiceRprtUnitForHsdpaRateMeas
HS-DSCH PBR TenMsecForHsdpaPrvidRateMeas
MinForHsdpaPrvidRateMeas
ChoiceRprtUnitForHsupaRateMeas
E-DCH PBR TenMsecForHsupaPrvidRateMeas
MinForHsupaPrvidRateMeas
z Set the above parameters through SET ULDM.

Load Measurement Procedure (Cont.)

z Smooth filtering on the RNC side:
After the RNC receives the measurement report, it filters the
measurement value with the smooth window
Assuming that the reported measurement value is Qn and that the

size of the smooth window is N, the filtered measurement value is:
z LDM must apply different smooth filter coefficients and measurement periods to PUC, CAC,
LDR, and OLC so as to obtain appropriate filtered values.
z The following table lists the smooth window length parameters for setting different
functions:
Function Smooth Window Length Parameter

PUC PucAvgFilterLen
UlCacAvgFilterLen
CAC
DlCacAvgFilterLen
LDB LdbAvgFilterLen
UlLdrAvgFilterLen
LDR
DlLdrAvgFilterLen
UlOlcAvgFilterLen
OLC
DlOlcAvgFilterLen
z GBP measurements have the same smooth window length in all related functions. The
filter length for GBP measurement is specified by the HsdpaNeedPwrFilterLen parameter.
z On the RNC side, the length of the PBR smooth filter window is specified by the
HsdpaPrvidBitRateFilterLen/HsupaPrvidBitRateFilterLen parameter.
z Set the above parameters through SET ULDM.

Contents

Priority
z The QoS of the services or users with low priority will be
affected by the load control algorithms first
z Three kinds of priorities involved in load control:

User priority
RAB integrated priority
User integrated priority
z User priority: mainly applying to provide different QoS for different users. Eg., setting
different GBR according to the user priority for BE service. No consideration about the
service.
z RAB integrated priority: priority of a service, related to the service type, and the user
priority of the user.
z User integrated priority: only used for multi-RAB user, it is a temporary priority of an
ongoing-service user.

User Priority
z There are three levels of user priority:
gold (high priority), silver (middle priority) and copper (low priority)
users
User priority Gold Silver Copper gold

user
Uplink 384kbps 128kbps 64kbps
Downlink 384kbps 128kbps 64kbps
z In CN HLR, operator can set ARP (Allocation Retention Priority ). During service setup, CN
sends ARP to RNC. Based on the mapping relation (configured in RNC), RNC can identify
the user’s priority, namely gold, silver or copper one.
z The levels of user priority are mainly used to provide different QoS for different users, for
example, setting different Guaranteed Bit Rate (GBR) values for BE services according to
different priority levels.
z The GBR of BE services are configurable. According to the traffic class, priority level, and
carrier type (DCH or HSPA), the different values of GBR are configured through the SET
UUSERGBR command.

User Priority (Cont.)

z The mapping relation between user priority and ARP is configured
in RNC by SET UUSERPRIORITY
Typical relation between user priority and ARP:
ARP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User
Gold Silver Copper
Priority
z ARP 15 is always the lowest priority and is not configurable. It corresponds to lowest user
priority (copper user).
z If ARP is not received in messages from the Iu interface, the user priority is regarded as
copper.

RAB Integrated Priority

z RAB integrated priority is mainly used in load control algorithms
z RAB integrated priority are set according to :

ARP
Traffic Class
Traffic Handling Priority (THP, only for interactive services)
Carrier types: HSPA or DCH
z During load control, the RABs need to be ranked by priority so that they can be chosen by
different load control actions. The priority of a RAB is determined by its traffic class, ARP,
and carrier type. Such a priority is called RAB integrated priority. RAB integrated priority is
mainly used in load control functions.

z The values of RAB integrated priority are set according to the integrated priority
configuration reference parameter (PriorityReference):
If the integrated priority configuration reference parameter is set to Traffic Class,
the integrated priority abides by the following rules:

Traffic classes: conversational > streaming > interactive > background
Services of the same class: priority based on Allocation/Retention Priority
(ARP) values, that is, ARP1 > ARP2 > ARP3 > ... > ARP14 > ARP15
Only for the interactive service of the same ARP value: priority based on
Traffic Handling Priority (THP), that is, THP1 > THP2 > THP3 > ... > THP14 >
THP15
Services of the same ARP, traffic class and THP (only for interactive services):
High Speed Packet Access (HSPA) or Dedicated Channel (DCH) service
preferred depending on the carrier type priority indicator parameter
(CarrierTypePriorInd).
If the integrated priority configuration reference parameter is set to ARP, the
integrated priority abides by the following rules:
ARP: ARP1 > ARP2 > ARP3 > ... > ARP14 > ARP15
Services of the same ARP: priority based on traffic classes, that is,
conversational > streaming > interactive > background
Only for the interactive service of the same ARP value: priority based on
Traffic Handling Priority (THP), that is, THP1 > THP2 > THP3 > ... > THP14 >
THP15
Services of the same ARP, traffic class and THP (only for interactive services):
HSPA or DCH service preferred depending on the carrier type priority
indicator parameter.
ARP and THP are carried in the RAB ASSIGNMENT REQUEST message, and they are
not configurable on the RNC LMT.

An Example for RAB Integrated Priority

Based on ARP, HSPA priority is higher
Service Bear
ARP Traffic Class
ID type
Services attribution in the cell B 1 Interactive HSDPA

A 1 Interactive DCH
Service Bear
ARP Traffic Class C 2 Conversational DCH
ID type
A 1 Interactive DCH D 2 Background DCH
B 1 Interactive HSDPA Based on Traffic Class, HSPA priority is higher

C 2 Conversational DCH
Service Bear
D 2 Background DCH Traffic Class ARP
ID type
C Conversational 2 DCH
B Interactive 1 HSDPA
A Interactive 1 DCH
D Background 2 DCH
z This example shows the RAB integrated priority calculation in 2 different conditions.

User Integrated Priority

z For single-RAB user, the user integrated priority is the same as
the RAB integrated priority
z For multiple-RAB user, the user integrated priority is based on

the highest priority of RAB
z A user may have multiple RABs, and the RABs may have different priorities. In this case,
the highest priority is taken as the priority of this user. Such a priority is called user
integrated priority. User integrated priority is used in user-specific load control. For
example, the selection of R99 users during preemption, the selection of users during inter-
frequency load handover for LDR, and the selection of users during switching of BE
services to common channels are performed according to the user integrated priority.

Parameters of Priority
z PriorityReference
Parameter name: Integrate Priority Configured Reference
Recommended value: ARP
z CarrierTypePriorInd
Parameter name: Indicator of Carrier Type Priority
Recommended value: NONE
z PriorityReference
Content: Reference used to determine which priority is arranged first in the priority
sequence. If the ARP is preferably used, the priority sequence is gold > silver >
copper. If the ARPs are all the same, the TrafficClass is used and the priority
sequence is conversational > streaming > interactive > background.
If the TrafficClass is preferably used, the priority sequence is conversational >
streaming > interactive > background. If the TrafficClass factors are all the same,
the ARP factor is used and the priority sequence is gold > silver > copper.
Value range: ARP, TrafficClass
Physical value range: ARP, TrafficClass
z CarrierTypePriorInd
Content: Decide which carrier is prior when ARP and TrafficClass are both identical.
Value range: NONE, DCH, HSPA
Physical value range: NONE, DCH, HSPA
z Set these parameters through SET UUSERPRIORITY.

Contents
2.1 PUC (Potential User Control)
2.2 LDB (Intra-Frequency Load Balancing)
2.3 CAC (Call Admission Control)
2.4 IAC (Intelligent Access Control)
2.5 LDR (Load Reshuffling)
2.6 OLC (Overload Control)

PUC Principle
z The Potential User Control (PUC) algorithm only controls the
Inter-frequency cell reselection of the potential UE, and
prevents UE from camping on a heavily loaded cell
z Potential UE:
UE in idle mode
UE in Cell-FACH, Cell-PCH and URA-PCH
z In the WCDMA system, the mobility management of the UE in idle or connected mode is
implemented by cell selection and reselection. The Potential User Control (PUC) function
controls the cell selection and cell reselection of the potential UE and prevents an idle UE
from camping on a heavily loaded cell.
z PUC procedure:
Periodically monitor the load of the

current cell and neighboring cells
Adjust the parameters of the Update and broadcast the system

current cell and neighboring cells information of the current cell and
according to the load neighboring cells
No Are these Yes

parameters changed?

PUC Load Judgment
z The RNC periodically monitors the downlink load of the cell:

If the cell load is higher than the upper threshold (SpucHeavy) plus the load level
division hysteresis (SpucHyst), the cell load is considered heavy.

If the cell load is lower than the lower threshold (SpucLight) minus SpucHyst, the
cell load is considered light.

z Based on the cell load, the PUC works as follows:
If the cell load becomes heavy, the PUC modifies cell selection and reselection
parameters and broadcasts them through system information. In this way, the PUC
leads UEs to the neighboring cells with light load.
If the cell load becomes normal, the PUC uses the cell selection and reselection
parameters configured on the RNC LMT.

If the cell load becomes light, the PUC modifies cell selection and reselection
parameters and broadcasts them through system information. In this way, the PUC
leads UEs to this cell.

PUC Procedure
Threshold
Cell TCP
Heavy?
Light?
Normal? System
cell reselection information
parameters
RNC NodeB UE
z PUC-related variables and their impacts on UEs:

Item Description
The variables related to cell selection and reselection are Qoffset1(s,n)
(load level offset), Qoffset2(s,n) (load level offset), and Sintersearch (start
threshold for inter-frequency cell reselection).
The NodeB periodically reports the transmit power of the cell, and the
PUC periodically triggers the following activities:
Implementation
zAssessing the cell load level based on the non-HSPA power and HS-
DSCH GBP
zSetting Sintersearch, Qoffset1(s,n), and Qoffset2(s,n) based on the cell
load level
zUpdating the parameters in system information SIB3 and SIB11
Based on the characteristics of inter-frequency cell selection and

reselection, the UE makes the corresponding adjustments:
zSintersearch
- When this value is increased by the serving cell, the UE starts inter-
frequency cell reselection ahead of schedule.
- When this value is decreased by the serving cell, the UE delays inter-
frequency cell reselection.
zQoffset1(s,n): applies to R (reselection) rule with CPICH RSCP
Adjustment - When this value is increased by the serving cell, the UE has a lower
probability of selecting a neighboring cell.
- When this value is decreased by the serving cell, the UE has a higher
zQoffset2(s,n): applies to R (reselection) rule with CPICH Ec/No
- When this value is increased by the serving cell, the UE has a lower
- When this value is decreased by the serving cell, the UE has a higher

PUC Procedure (Cont.)

Light load Normal load
Freq1 Modify 1. Sintersearch↓ Stay
2. Qoffset↑
System Info System Info
SIB3,11 SIB3,11
Heavy load
Freq2 1. Sintersearch↑ Modify

2. Qoffset ↓
System Info
SIB3,11
Idle state CCH state
z Depending on the load status of the serving cell, the cell reselection parameters are
adjusted up or down or kept unchanged. The setting of Sintersearch is related to the
serving cell:
Load State of the Change to
Sintersearch
Serving Cell Sintersearch
Light S'intersearch = Sintersearch + OffSinterLight ↓
Normal S'intersearch = Sintersearch →
Heavy S'intersearch = Sintersearch + OffSinterHeavy ↑
→: indicates that the parameter value remains unchanged.
↑: indicates that the parameter value increases.
↓: indicates that the parameter value decreases.

z The configurations of Qoffset1 and Qoffset are related to the load of the current cell and
the load of the neighboring cells:
Load State Load State

Change
of the of the Change to
Q'offset1 Q'offset2 to
Neighboring Serving Q'offset1
Q'offset2
Cells Cell
Light Light Q'offset1 = Qoffset1 → Q'offset2 = Qoffset2 →
Light Normal Q'offset1 = Qoffset1 → Q'offset2 = Qoffset2 →
Q'offset1 = Qoffset1 Q'offset2 = Qoffset2
Light Heavy ↓ ↓
+ OffQoffset1Light + OffQoffset2Light
Normal Light Q'offset1 = Qoffset1 → Q'offset2 = Qoffset2 →
Normal Normal Q'offset1 = Qoffset1 → Q'offset2 = Qoffset2 →
Normal Heavy ↓ ↓
+ OffQoffset1Light + OffQoffset2Light
Heavy Light ↑ ↑
+ OffQoffset1Heavy + OffQoffset2Heavy
Heavy Normal ↑ ↑
+ OffQoffset1Heavy + OffQoffset2Heavy
Heavy Heavy Q'offset1 = Qoffset1 → Q'offset2 = Qoffset2 →

Parameters of PUC
z NBMLdcAlgoSwitch-PUC
Parameter name: Cell LDC algorithm switch for PUC
Recommended value: OFF
z SpucHeavy
Parameter name: Load level division threshold 1
Recommended value: 70, namely 70%
z SpucLight
Parameter name: Load level division threshold 2
z NBMLdcAlgoSwitch-PUC
Content: Potential user control algorithm. Based on the cell load, this algorithm
changes the selection/reselection parameters of a cell to lead the UE to a lighter
loaded cell.
Value range: OFF, ON
Physical value range: 0, 1
Set this parameter through ADD UCELLALGOSWITCH/ MOD UCELLALGOSWITCH.
z SpucHeavy/SpucLight
Content: It is used to decide whether the cell load level is Heavy or Light. It is
denoted by the ratio of NodeB TX power to the maximum TX power.
Value range: 0~100
Physical value range: 0~100; step: 1
Physical unit: %
Set this parameter through ADD UCELLPUC/ MOD UCELLPUC.

Parameters of PUC (Cont.)

z SpucHyst
Parameter name: Load level division hysteresis
z PucPeriodTimerLen
Parameter name: PUC period timer length
Recommended value: 1800, namely 1800s
z SpucHyst
Content: Hysteresis used to determine the cell load level. It is denoted by the ratio
of NodeB TX power to the maximum TX power. It is used to avoid the unnecessary

ping-pong effect of a cell between two load levels due to tiny load change.
Value range: 0~100
Physical unit: %
Set this parameter through ADD UCELLPUC/ MOD UCELLPUC.
z PucPeriodTimerLen
Content: Identifying the potential user control period. When the cell load is high,
the cell selection and reselection can be periodically modified in order to enable
users in unconnected mode to select other cells more easily, thus reducing the
local cell load.
Value range: 6~86400
Physical unit: s
Set this parameter through SET ULDCPERIOD.


z OffSinterLight
Parameter name: Sintersearch offset 1
Recommended value: -2, namely -4dB
z OffSinterHeavy
Parameter name: Sintersearch offset 2
Recommended value: 2, namely 4dB
z OffSinteright
Content: Offset of Sintersearch when center cell load level is "Light“.
Value range: -10~10
Physical value range: -10~10; step: 2
Physical unit: dB
z OffSinterHeavy
Content: Offset of Sintersearch when center cell load level is “Heavy“.
Value range: -10~10
Physical unit: dB
z Set these parameters through ADD UCELLPUC/ MOD UCELLPUC.


z OffQoffset1Light (for RSCP)
Parameter name: Qoffset1 offset 1
z OffQoffset1Heavy (for RSCP)

z OffQoffset1Light
Content: Offset of Qoffset1 when neighboring cell load is lighter than that of the
center cell.
Value range: -20~20
Physical unit: dB
z OffSinterHeavy
Content: Offset of Qoffset1 when neighboring cell load is heavier than that of the
center cell.
Value range: -20~20
Physical unit: dB


z OffQoffset2Light (for Ec/No)
z OffQoffset2Heavy (for Ec/No)

Recommended value: 4 namely 4dB
z OffQoffset2Light
Content: Offset of Qoffset2 when neighboring cell load is lighter than that of the
center cell.
Value range: -20~20
Physical unit: dB
z OffQoffset2Heavy
Content: Offset of Qoffset2 when neighboring cell load is heavier than that of the
center cell.
Value range: -20~20
Physical unit: dB

Contents

LDB Principle
z Intra-frequency Load Balancing (LDB) is performed to adjust the
coverage areas of cells by modifying PCPICH power
z LDB affect UEs in all states
z Intra-frequency Load Balancing (LDB) is performed to adjust the coverage areas of cells
according to the measured values of cell load. Currently, the intra-frequency LDB function
is applicable only to the downlink.
z LDB between intra-frequency cells is implemented by adjusting the transmit power of the
Primary Common Pilot Channel (PCPICH) according to the downlink load of the associated
cells. When the load of a cell increases, the cell reduces its coverage to lighten its load.
When the load of a cell decreases, the cell extends its coverage so that some traffic is off-
loaded from its neighboring cells to it.

LDB Procedure
z The intra-frequency LDB is described as follows:

If the downlink load of a cell is higher than the cell overload threshold
(CellOverrunThd), it is an indication that the cell is heavily overloaded. In this case,

the transmit power of the P-CPICH needs to be reduced step by step. The step is
specified by the PCPICHPowerPace parameter.
If the current transmit power is equal to the minimum transmit power of P-CPICH
(MinPCPICHPower), the current transmit power is not adjusted.

If the downlink load of a cell is lower than the cell underload threshold
(CellUnderrunThd), it is an indication that the cell has sufficient remaining capacity

for more load. In this case, the transmit power of the P-CPICH can be increased
step by step to help lighten the load of neighboring cells. The step is specified by
the PCPICHPowerPace parameter.
If the current transmit power is equal to the maximum transmit power of P-CPICH
(MaxPCPICHPower), the current transmit power is not adjusted.

Parameters of LDB
z NBMLdcAlgoSwitch-INTRA_FREQUENCY_LDB
Parameter name: Cell LDC algorithm switch for LDB
z IntraFreqLdbPeriodTimerLen
Parameter name: Intra-frequency LDB period timer length
z NBMLdcAlgoSwitch-INTRA_FREQUENCY_LDB
Content: Intra-frequency load balance algorithm. It is also named cell breathing
algorithm. Based on the cell load, this algorithm changes the pilot power of the
cell to control the load between intra-frequency cells.
z IntraFreqLdbPeriodTimerLen
Content: Identifying the period of the Intra-frequency load balance algorithm.
When the cell load is high, the cell PCPICH TX power can be periodically reduced in
order to enable users in connected mode to be switched over to other cells more
easily, thus reducing the local cell load.
Physical unit: s

Parameters of LDB (Cont.)

z CellOverrunThd
Parameter name: Cell overload threshold
z CellUnderrunThd
Parameter name: Cell underload threshold
z PCPICHPowerPace
Parameter name: Pilot power adjustment step
Recommended value: 2, namely 0.2dB
z CellOverrunThd
Content: If the cell downlink load exceeds this threshold, the algorithm will decrease the pilot
transmit power of the cell so as to increase the whole system's capacity. This parameter is based on
network planning. When the cell breathing algorithm is activated, if the value is too small, the
physical coverage of the cell is limited so as to avoid cell capacity waste. If the value is too great, the
physical coverage is expanded and interference over other cells is increased.
Value range: 0~100
Physical unit: %
z CellUnderrunThd
Content: If the cell downlink load is lower than this threshold, the algorithm will increase the pilot
transmit power of the cell so as to share load of other cells. This parameter is based on network
planning. When the cell breathing algorithm is activated, if the value is too small, the physical
coverage of the cell is limited so as to avoid cell capacity waste. If the value is too great, the physical
coverage is expanded and interference over other cells is increased.
Value range: 0~100
Physical unit: %
z PCPICHPowerPace
Content: Pilot power adjustment step increased or decreased in each increase of the cell breathing
algorithm or decrease of cell pilot. If the value is too great, the cell pilot may change fiercely, which
is easy to lead to user call drops. If the value is too small, the cell pilot may change smoothly.
However, the response speed of the cell breathing algorithm is decreased, impacting the algorithm
performance.
Value range: 0~100
Physical value range: 0~10; step: 0.1
Physical unit: dB
z Set these parameters through ADD UCELLLDB/ MOD UCELLLDB.

Parameters of LDB (Cont.)

z PCPICHPower
Parameter name: PCPICH transmit power
Recommended value: 330, namely 33dBm
z MaxPCPICHPower
Parameter name: Max transmit power of PCPICH
Recommended value: 346, namely 34.6dBm
z MinPCPICHPower
Parameter name: Min transmit power of PCPICH
Recommended value: 313, namely 31.3dBm
z PCPICHPower
Content: TX power of the PCPICH in a cell.
Value range: -100~500

Physical value range: -10~50; step: 0.1
Physical unit: dBm
z MaxPCPICHPower
Content: Maximum TX power of the PCPICH in a cell.

Physical unit: dBm
z MinPCPICHPower
Content: Minimum TX power of the PCPICH in a cell.

Physical unit: dBm
z Set these parameters through ADD UPCPICH/ MOD UPCPICHPWR.

Contents

Why We Need CAC?

z WCDMA is an interference limited system, after a new service is
admitted, the system load will be increased
z If a cell is high loaded, a new service will affect the QoS of

ongoing user, even result in call drop
z CAC is used to determine whether the system resources are

sufficient to accept a new user's access request or not
z CAC is needed under such scenarios:

RRC connection setup request
RAB admission decision
Handover
Rate reconfiguration

CAC Procedure
Admission request
Code-based No
admission successful?
Yes
Power-based No
Yes
No
NodeB credit-based
Yes
No
Iub resource-based
Yes
Admission based on No
the number of HSPA users
successful?
Yes
Resource-based admission Resource-based admission

successful unsuccessful
z The admission decision is based on:

Available cell code resource
Available cell power resource
NodeB resource state, that is, NodeB credits, which are used to measure the
channel demodulation capability of NodeBs

Available Iub transport layer resource, that is, Iub transmission bandwidth
Number of HSDPA users (only for HSDPA services)
Number of HSUPA users (only for HSUPA services)
z A call can be admitted only when all of these resources are available.

CAC Algorithm Switches

z Power CAC
Uplink CAC algorithm switch: ALGORITHM_SECOND
Downlink CAC algorithm switch: ALGORITHM_FIRST
z NodeB credit CAC

CAC algorithm switch: ON
Cell CAC algorithm switch-CRD_ADCTRL: ON
z HSDPA user number CAC

Cell CAC algorithm switch-HSDPA_UU_ADCTRL: OFF
z HSUPA user number CAC

Cell CAC algorithm switch-HSUPA_UU_ADCTRL: OFF
z Code and Iub resource-based admission control are mandatory and can not be disabled. Other
admission control strategies may be enabled/disabled through the RNC command:
The switch of power CAC can be set by ADD UCELLALGOSWITCH/ MOD
UCELLALGOSWITCH:
Uplink CAC algorithm switch (NBMUlCacAlgoSelSwitch) selects the algorithm used
for power admission in the uplink.
Downlink CAC algorithm switch (NBMDlCacAlgoSelSwitch) selects the algorithm
used for power admission in the downlink.
The switch of NodeB credit CAC can be set by SET UCACALGOSWITCH and ADD
UCELLALGOSWITCH/ MOD UCELLALGOSWITCH:
CAC algorithm switch (CacSwitch) specifies whether to enable or disable the
NodeB level credit CAC algorithm.
Cell CAC algorithm switch (CRD_ADCTRL) specifies whether to enable or disable
the cell level credit CAC algorithm.
The switch of HSDPA user number CAC can be set by ADD UCELLALGOSWITCH/ MOD
UCELLALGOSWITCH:
Cell CAC algorithm switch (HSDPA_UU_ADCTRL) specifies whether to enable or
disable the HSDPA user number admission control algorithm.
The switch of HSUPA user number CAC can be set by ADD UCELLALGOSWITCH/ MOD
UCELLALGOSWITCH:
Cell CAC algorithm switch (HSUPA_UU_ADCTRL) specifies whether to enable or
disable the HSUPA user number admission control algorithm.

Code CAC
z Code resource CAC is involved in:
RRC connection setup
Handover
R99 services setup
z RRC connection setup and handover have higher priority
z When a new service attempts to access the network, code resource-based admission is
mandatory.
z Code resource–based admission is implemented as follows:
For RRC connection setup requests, the code resource-based admission is
successful if the current remaining code resource is sufficient for RRC connection
setup.
For handover services, the code resource-based admission is successful if the
current remaining code resource is sufficient for the service.

For other R99 services, the RNC has to ensure that the remaining code does not
exceed the DlHoCeCodeResvSf parameter after admission of the new service.

For HSDPA services, the reserved codes are shared by all HSDPA services. Therefore,
the code resource–based admission is not required.

Parameter of Code CAC

z DlHoCeCodeResvSf
Parameter name: DL handover credit and code reserved SF
Recommended value: SF32
z DlHoCeCodeResvSf
Content: Some cell resources can be reserved for handover UEs to guarantee
handover success rate and improve access priority of handover services. This
parameter defines the quantity of downlink code and CE resources reserved for
handover. SFOFF refers to that no resources is reserved. SF32 refers to that a code
resource with SF = 32 and its corresponding credit resource are reserved. The
backer position the value is in {SF4, SF8, SF16, SF32, SF64, SF128, SF256, SFOFF},
the less code and credit resources reserved for handover UEs. The possibility of
rejecting handover UE admissions increases and performance of UEs cannot be
guaranteed. The more frontal position the value is, the more the possibility of
rejecting new UEs is and some idle resources are wasted.
Value range: SF4, SF8, SF16, SF32, SF64, SF128, SF256, SFOFF
Physical value range: SF4, SF8, SF16, SF32, SF64, SF128, SF256, SFOFF
Set this parameter through ADD UCELLCAC/ MOD UCELLCAC.

Power CAC
z Power resource CAC is involved in:
Handover
Services setup
z The power CAC involves uplink admission control and downlink admission control. The
corresponding admission control switches NBMUlCacAlgoSelSwitch or
NBMDlCacAlgoSelSwitch are independent of each other.
z To enable the power-based admission control for HSDPA/HSUPA, the HSDPA_UU_ADCTRL
or HSUPA_UU_ADCTRL must also be set to on.

Power CAC Procedure
z The basic principles of power-based admission decision are as follows:

Four basic load thresholds are used for power-based admission decision. They are:
UL/DL access threshold for handover (UlNonCtrlThdForHo or DlHOThd)

UL/DL threshold of conversational AMR service (UlNonCtrlThdForAMR or
DlConvAMRThd)
UL/DL threshold of conversational non-AMR service
(UlNonCtrlThdForNonAMR or DlConvNonAMRThd)
UL/DL threshold of other services (UlNonCtrlThdForOther or DlOtherThd)
With these thresholds, the RNC defines the proportion of speech service to other
services while ensuring handover preference.

z For an intra-frequency handover request, only downlink admission decision is needed.
z For a non-intra-frequency handover request, both uplink and downlink decisions are
needed if both uplink CAC and downlink CAC are enabled.
z If there is a rate downsizing request, the RNC accepts it directly. For a rate upsizing
request, the RNC makes the power CAC decision.
z For a rejected RRC connection setup request, the RNC performs DRD or redirection. For a
rejected service request, the RNC performs preemption or queuing according to the actual
situation.

Power CAC Algorithms

z Algorithm 1: based on UL/DL load measurement and load
prediction (RTWP and TCP)
z Algorithm 2: based on Equivalent Number of User (ENU)
z Algorithm 3: loose call admission control algorithm
z Algorithm 1 (ALGORITHM_FIRST): admission decision based on predicted load increment

upon admission of a new service
Based on the current cell load (indicated by the uplink load factor and downlink
TCP) and the predicted load increment due to admission of the new service, the
RNC determines whether the cell load will exceed the threshold upon admitting
the new service. If yes, the RNC rejects the access request. If not, the RNC accepts
the access request.
z Algorithm 2 (ALGORITHM_SECOND): admission decision based on the ENU
Depending on the current ENU and the access request, the RNC determines
whether the ENU will exceed the threshold upon admitting a new service. If yes,
the RNC rejects the request. If not, the RNC accepts the request.
z Algorithm 3 (ALGORITHM_THIRD): admission decision based on no load increment upon
admission of a new service
This algorithm assumes that load increment upon admission of a new service is 0.
Based on the current cell load (indicated by the uplink load factor and downlink
TCP), the RNC determines whether the cell load will exceed the threshold upon
admitting the new service. If yes, the RNC rejects the access request. If not, the
RNC accepts the access request.

Power CAC for RRC Connection Setup

z For the RRC connection request is, tolerance principles are
applied :
Emergency call, detach, registration:
Direct admission
RRC connection request for other reasons:

Based on UL/DL OLC switches and trigger threshold
z To ensure that the RRC connection setup request is not denied by mistake, tolerance
principles are applied.
z The admission decision for RRC connection setup request is as follows:
When power-based admission is based on power or interference (algorithm 1 and
algorithm 3):
For the RRC connection setup request for the reason of emergency call,
detach or registration, direct admission is used.
For the RRC connection setup request for other reasons, the UL or DL OLC

trigger threshold (UlOlcTrigThd or DlOlcTrigThd) is used for admission.

When power-based admission is based on the ENU (algorithm 2):
For the RRC connection setup request for the reason of emergency call,
detach or registration, direct admission is used.
For the RRC connection setup request for other reasons, the admission
decision is made as follows:
a. When UL_UU_OLC or DL_UU_OLC is set to on, RRC connection
setup request is rejected when the cell is in the overload congestion
state. If the cell is not in the overload state, the UL or DL OLC trigger
threshold is used for power-based admission.
b. When UL_UU_OLC or DL_UU_OLC is set to off, the UL or DL OLC
trigger threshold is used for power-based admission.

Power CAC Algorithm 1

z Power-based admission decision based on algorithm 1 consists
of uplink power-based admission decision and downlink
power-based admission decision procedures:
Uplink admission decision:
R99 cell
HSPA cell
Downlink admission decision:

R99 cell
HSPA cell

Algorithm 1 - Uplink for R99 Cell
z The procedure of uplink power-based admission decision for R99 cells is as follows:
The RNC obtains the uplink RTWP of the cell and calculate the current uplink load
factor ηUL, where PN is the received uplink background noise.
The RNC calculates the uplink load increment ΔηUL based on the service request.
The RNC predicts the uplink load factor ηUL,predicted, where ηULcch is specified by
UlCCHLoadFactor.
By comparing the predicted uplink load factor ηUL,predicted with the
corresponding threshold (UlNonCtrlThdForHo, UlNonCtrlThdForAMR,
UlNonCtrlThdForNonAMR, or UlNonCtrlThdForOther), the RNC decides whether to
accept the access request. If the access request is accepted, the RNC processes the
access request. Otherwise, the RNC rejects the access request.

Parameters of Power CAC

z UlCCHLoadFactor
Parameter name: UL common channel load reserved coefficient
z UlNonCtrlThdForHo/UlNonCtrlThdForAMR/UlNonCtrlThdF
orNonAMR/UlNonCtrlThdForOther
Parameter name: UL threshold of handover/Conv AMR/Conv
non_AMR/other service
Recommended value: 80%, 75%, 75%, 60%
z UlCCHLoadFactor
Content: The admission control decision is only for dedicated channels. For
common channels, some resources instead of a special admission procedure are

reserved.
Value range: 0~100
Physical unit: %
z UlNonCtrlThdForHo/ UlNonCtrlThdForAMR/ UlNonCtrlThdForNonAMR/

UlNonCtrlThdForOther
Content: The percentage of the handover/conversational AMR/conversational non-
AMR/other service thresholds to the 100% uplink load. It is applicable to algorithm

1 and algorithm 2. If the value is too high the system load after admission may be
over large, which impacts system stability and leads to system congestion. If the
value is too low, the possibility of user rejects may increase, resulting in waste in
idle resources.
Value range: 0~100
Physical unit: %
z Set these parameters through ADD UCELLCAC/ MOD UCELLCAC.

Algorithm 1 - Uplink for HSPA Cell

z After the RSEPS measurement is
introduced, the UL RTWP is
divided into two parts:
controllable part and
uncontrollable part
z The controllable part is
generated by the E-DCH
scheduling service, and others
belong to the uncontrollable
part
z The E-DCH scheduling service involves the following types of UEs:

Type A: UEs of this type are in the serving E-DCH cell.
Type B: UEs of this type are not in the serving E-DCH cell.
z The methods of calculating the uplink load vary according to user type:
For type A, the uplink load generated by the E-DCH scheduling service is calculated
as follows:
RSEPS
ηUL , EDCH , S =
RTWP
For type B, the uplink load generated by the E-DCH scheduling service is calculated
through ηUL,EDCH,f, which is set to 0.
z The uplink uncontrollable load is calculated as follows:


(Cont.)
z Admission of DCH service is based on the following formulas:
z If formulas 1 and 2 are fulfilled, the RNC admits DCH service.

Otherwise, the RNC rejects the access request
z ηHS-DPCCH is the UlHsDpcchRsvdFactor parameter.

z ηthd is the cell UL admission threshold of a specific type of service. The threshold may be
UlNonCtrlThdForAMR, UlNonCtrlThdForNonAMR, UlNonCtrlThdForOther, or
UlNonCtrlThdForHo.
z ηthd-total is the UL total power threshold of the current cell (UlCellTotalThd).

Parameters of Power CAC (Cont.)

z UlHsDpcchRsvdFactor
Parameter name: UL HS-DPCCH reserve factor
z UlCellTotalThd
Parameter name: UL total power threshold
z UlHsDpcchRsvdFactor
Content: If the HS-DPCCH carries ACK/NACK, the system will not perform CAC. If
the HS-DPCCH carries CQI, the system will perform CAC. This parameter refers to
the resources reserved for the uplink HS-DPCCH carrying ACK/NACK. The
corresponding threshold is the uplink limit capacity multiplied by this parameter. If
the value is too high, the possibility of wrong rejection to uplink admissions
increases, leading to waste in uplink resources. If the value is too low, the uplink
resources is insufficient. However, because the possibility of burst load by
ACK/NACK and its impact are relatively low, the value can be set to a low level,
representing the loose admission rule.
Value range: 0~100
Physical unit: %
z UlCellTotalThd
Content: Admission threshold of total cell uplink power. This parameter is related
to the target load of the uplink schedule. The total uplink load fluctuates closing to
the target load due to the schedule mechanism of the HSUPA. Therefore, the
target load is added with margin, acting as the basis of this parameter. If the value
is too high, the system load after admission may be over large, which impacts
system stability and leads to system congestion. If the value is too low, the
possibility of user rejects may increase, resulting in waste in idle resources. If the
value is lower than the target load threshold of the uplink schedule, the possibility
of user rejects is great.
Value range: 0~100
Physical unit: %


(Cont.)
z PBR-based application in HSUPA cell
z Since the HSUPA scheduling algorithm consumes additional uplink power resources, the
power load of the HSUPA cell is always relatively high. Therefore, the CAC algorithm
combines the PBR-based decision with the load-based decision to reduce the number of
potential erroneous rejections.
z PBR-based decision is used to check whether the QoS requirement of existing users is
fulfilled. The QoS is measured on the basis of the Provided Bit Rate (PBR) of the users. If
the QoS requirement is fulfilled, new users are allowed to access the network.
z As shown in the previous figure, the Scheduling Priority Indicator (SPI) of a new HSUPA
user is SPINew user.
z ThdL is the low priority HSUPA user PBR threshold (HsupaLowPriorityUserPBRThd).
z ThdE is the equal priority HSUPA user PBR threshold (HsupaEqualPriorityUserPBRThd).
z ThdGE is the high priority HSUPA user PBR threshold (HsupaHighPriorityUserPBRThd).


(Cont.)
z The RNC admits the HSUPA scheduling services in either of the
following cases:
Formula 3, 4, or 5 is fulfilled
Formula 2 is fulfilled
z For HSUPA non-scheduling services, the RNC admits the HSUPA

non-scheduling services in either of the following cases:
Formula 3, 4, or 5 is fulfilled
Formulas 1 and 2 are fulfilled
z For the first HSUPA service accessing the cell, the decision formulas that involve PBR are
regarded as unsatisfied.
z If the PBR measurement is deactivated, the decision formulas that involve PBR are
z If the RSEPS measurement is deactivated, the admission algorithm automatically changes
into algorithm 2.


z HsupaLowPriorityUserPBRThd/HsupaEqualPriorityUserPB
RThdHsupaHighPriorityUserPBRThd
Parameter name: Low/Equal/High priority HSUPA user PBR
threshold
Recommended value: 100%, 100%, 100%
z HsupaLowPriorityUserPBRThd/ HsupaEqualPriorityUserPBRThd/
HsupaHighPriorityUserPBRThd
Content: Threshold of all the HSUPA user PBR whose schedule priority is
lower/equal/higher than that of users to be admitted. If this value is too high, the
possibility of rejecting HSUPA schedule services increases, which impacts access
success rate. If the value is too low, too many HSUPA schedule users may be
admitted, which impacts the admitted users and results in overload and system
congestion.
Value range: 0~100
Physical unit: %

Algorithm 1 - Downlink for R99 Cell
z The procedure of downlink power-based admission decision for R99 cells is as follows:
The RNC obtains the cell downlink TCP and calculates the downlink load factor
ηDL by dividing the maximum downlink transmit power Pmax by this TCP.
The RNC calculates the downlink load increment ΔηDL based on the service
request and the current load.

The RNC predicts the downlink load factor ηDL,predicted, where ηDLcch is the
percentage of reserved DL common channel load (DlCCHLoadRsrvCoeff).

By comparing the downlink load factor ηDL,predicted with the corresponding
threshold (DlConvAMRThd, DlConvNonAMRThd, DlOtherThd, and DlHOThd), the

RNC decides whether to accept the access request.


z DlCCHLoadRsrvCoeff
Parameter name: DL common channel load reserved coefficient
z DlHOThd/DlConvAMRThd/DlConvNonAMRThd/DlOtherTh
d
Parameter name: DL threshold of handover/Conv AMR/Conv
non_AMR/other service
Recommended value: 85%, 80%, 80%, 75%
z DlCCHLoadRsrvCoeff
Content: Different admission policies are used for dedicated channel and common
channel users. For common channel users, resources instead of separate power
admission decision are reserved.
Value range: 0~100
Physical unit: %
z DlHOThd/ DlConvAMRThd/ DlConvNonAMRThd/ DlOtherThd

Content: The percentage of the handover/conversational AMR/conversational non-
AMR/other service thresholds to the 100% downlink load. It is applicable to

algorithm 1 and algorithm 2. If the value is too high the system load after
admission may be over large, which impacts system stability and leads to system
congestion. If the value is too low, the possibility of user rejects may increase,
resulting in waste in idle resources and the failure to achieving network planning
target.
Value range: 0~100
Physical unit: %

Algorithm 1 - Downlink for HSPA Cell

z Admission of DCH service is based on the following formulas:
z The RNC admits the DCH RAB in either of the following

situations:
z Pnon-hspa is the current non-HSDPA power.

z Pcch-res is the power reserved for the common channel.
z Pmax is the cell maximum transmit power of the cell.
z Thdnon-hspa-cac is the cell DL admission threshold for a specific type of service. The threshold
may be DlConvAMRThd, DlConvNonAMRThd, DlOtherThd, and DlHOThd.
z Ptotal is the current downlink transmitted carrier power.
z Thdtotal-cac is the threshold of the total DL power of the cell (DlCellTotalThd).
z GBP is the minimum power required to ensure the GBR.
z Phsupa-res is the power reserved (DlHSUPARsvdFactor) for HSUPA downlink control channels,
that is, E-AGCH/E-RGCH/E-HICH channels.
z Pmax-hspa is the maximum available power for HSPA. Its value is associated with the HSDPA
power allocation mode.
z If the GBP measurement is deactivated, the GBP involved in the decision formulas is set to
0.


z DlCellTotalThd
Parameter name: DL total power threshold
z DlHSUPARsvdFactor
Parameter name: DL HSUPA reserved factor
z DlCellTotalThd
Content: Admission threshold of the total cell downlink power. If the value is too
high, too many users will be admitted. However, the throughput of a single user is
easy to be limited. If the value is too low, cell capacity will be wasted.
Value range: 0~100
Physical unit: %
z DlHSUPARsvdFactor
Content: Reserved DL power factor for HSUPA user. The higher the value is, the
more resources reserved for the HSUPA control channel, which leads to resource
waste. If the value is too low, HSUPA user quality may be impacted.
Value range: 0~100
Physical unit: %


(Cont.)
z When the admission of the HSDPA RAB is implemented, the
following formulas apply:
z PBRstrm is the provided bit rate of all existing streaming services.

z Thdhsdap-str is the admission threshold for streaming PBR decision (HsdpaStrmPBRThd).
z PBRbe is the provided bit rate of all existing BE services.
z Thdhsdap-be is the admission threshold for BE PBR decision (HsdpaBePBRThd).


(Cont.)
z The RNC admits the HSDPA streaming RAB in any of the following
situations:
z The RNC admits the HSDPA BE RAB in any of the following situations:
z If PS conversational services are carried on HSPA, the services can be treated as streaming
services during admission control.
z If the GBP measurement is deactivated, the GBP involved in the decision formulas is set to
0.
z If the PBR measurement is deactivated, the decision formulas that involve PBR are
regarded as dissatisfied.
z For the first HSDPA service accessing the cell, the decision formulas that involve PBR are


z HsdpaStrmPBRThd
Parameter name: HSDPA streaming PBR threshold
z HsdpaBePBRThd
Parameter name: HSDPA best effort PBR threshold
z HsdpaStrmPBRThd
Content: Average throughput admission threshold of the HSDPA streaming service. If the
sum of PBR of all the accessed streaming users is lower than the average throughput
admission threshold of the HSDPA streaming service multiplied by the sum of GBR of all the
accessed streaming users, it indicates that the QoS of the accessed users cannot be satisfied
and new HSDPA streaming services are not allowed. Otherwise, the QoS can be satisfied
and new HSDPA streaming services are allowed. If the value is too high, admission
requirement of the HSDPA streaming service is strict, which improves the service quality of
the HSDPA streaming service but also may lead to HSDPA capacity waste. If the value is too
low, admission requirement of the HSDPA streaming service is loose, which allows more
HSDPA streaming services but QoS of the HSDPA streaming service cannot be guaranteed.
Value range: 0~100
Physical unit: %
z HsdpaBePBRThd
Content: Average throughput admission threshold of the HSDPA best effort traffic. If the
sum of PBR of all the accessed HSDPA BE users is lower than the average throughput
admission threshold of the HSDPA BE service multiplied by the sum of GBR of all the
accessed HSDPA BE users, it indicates that the QoS of the accessed users cannot be
satisfied and new HSDPA BE services are not allowed. Otherwise, the QoS can be satisfied
and new HSDPA BE services are allowed. If the value is too high, admission requirement of
the HSDPA BE service is strict, which improves the service quality of the HSDPA BE service
but also may lead to HSDPA capacity waste. If the value is too low, admission requirement
of the HSDPA BE service is loose, which allows more BE services but QoS of the HSDPA BE
service cannot be guaranteed.
Value range: 0~100
Physical unit: %


z When the CAC function uses algorithm 2, the admission of
uplink/downlink power resources uses the algorithm depending
on the Equivalent Number of Users (ENU)
z The 12.2 kbit/s AMR traffic is defined as one ENU. Thus, the
12.2 kbit/s AMR traffic can be used to calculate the ENU of all
other services
z The following table describes the typical ENU of some services (with activity factor to be
100%):
ENU
Service Uplink for Downlink
HSDPA HSUPA
DCH for DCH
3.4 kbit/s SIG 0.44 0.42 0.28 1.76
3.4+12.2
1.44 1.42 - -
kbit/s
3.4+8 kbit/s
1.35 1.04 0.78 2.26
(PS)
3.4+16 kbit/s
1.62 1.25 1.11 2.37
(PS)
3.4+32 kbit/s
2.15 2.19 1.70 2.60
(PS)
3.4+64 kbit/s
3.45 3.25 2.79 3.14
(PS)
3.4+128
5.78 5.93 4.92 4.67
kbit/s (PS)
3.4+384
14.27 15.52 14.17 9.36
kbit/s (PS)

Power CAC Algorithm 2 Procedure

Admission request
N
Get current total ENU ENU total (N ) = ∑ ENU
i =1
i
Get the traffic characteristic, and

ENU new
estimate the increment of ENU
Calculate the predicted ENU ENU total ( N + 1) = ENU total ( N ) + ENU new
Y
Smaller than the
N
ENULoad = ENU total ( N + 1) / ENU max
threshold?
admitted rejected
End of UL/DL CAC
z The procedure of ENU resource decision for uplink/downlink is as follows:

The RNC obtains the total ENU of all existing users.
The RNC gets the ENU of the new incoming user.
The RNC uses the formula (ENUtotal + ENUnew)/ENUmax to forecast the ENU load,
where ENUmax is the configured maximum ENU (UlTotalEqUserNum or

DlTotalEqUserNum).
By comparing the forecasted ENU load with the corresponding threshold, the RNC
decides whether to accept the access request.

z The admission thresholds for different types of service are different. The following table
lists the parameters used to set admission thresholds for different types of service:
Service Type Admission Threshold

UL threshold of conversational AMR service
(UlNonCtrlThdForAMR)
UL threshold of conversational non-AMR service
UL DCH/HSUPA
(UlNonCtrlThdForNonAMR)
UL threshold of other services (UlNonCtrlThdForOther)
UL access threshold for handover (UlNonCtrlThdForHo)
DL threshold of conversational AMR service (DlConvAMRThd)
DL threshold of conversational non-AMR service
DL DCH (DlConvNonAMRThd)
DL threshold of other services (DlOtherThd)
DL access threshold for handover (DlHOThd)
HSDPA DL total power threshold (DlCellTotalThd)


z UlTotalEqUserNum
Parameter name: UL total equivalent user number
Recommended value: 80
z DlTotalEqUserNum
Parameter name: DL total equivalent user number
z UlTotalEqUserNum
Content: When the algorithm 2 is used, this parameter defines the total equivalent
user numbers corresponding to the 100% uplink load. The parameter should be
related to the admission threshold and actual condition of the network. If the value
possibility of user rejects may increase, resulting in waste in idle resources.
Value range: 1~200
Physical value range:1~200; step: 1
z DlTotalEqUserNum
Content: When the algorithm 2 is used, this parameter defines the total equivalent
user number corresponding to the 100% downlink load. he parameter should be

related to the admission threshold and actual condition of the network. If the value
possibility of user rejects may increase, resulting in waste in idle resources.
Value range: 1~200


z Algorithm 3 is similar to algorithm 1. The difference is that the
estimated load increment in algorithm 3 is always set to 0
z In accordance with the current cell load (uplink load factor and
downlink TCP), the RNC determines whether the cell load will
exceed the threshold, with the estimated load increment set to
0. If yes, the RNC rejects the request. If not, the RNC accepts
the request

NodeB Credit CAC

z CE is used to measure the channel demodulation capability of
the NodeBs. On the RNC side, it is referred to the NodeB credit.
On the NodeB side, it is the channel element
z The resource of one equivalent 12.2 kbit/s AMR voice service,
including 3.4 kbit/s signaling, is defined as one CE
z There are two kinds of CE, that is, uplink CE supporting uplink
services and downlink CE supporting downlink services.
Therefore, one 12.2 kbit/s AMR voice service consumes one
uplink CE and one downlink CE
z The principles of NodeB credit-admission control are similar to those of power-based

admission control, that is, to check in the local cell, local cell group (if any), and NodeB
whether the remaining credit can support the requesting services.
z The CE capabilities at the levels of local cell, local cell group, and NodeB are reported to
the RNC through the NBAP_AUDIT_RSP message over the Iub interface.
The CE capability of local cell level indicates the maximum capability in terms of
hardware that can be used in the local cell.

The CE capability of local cell group level indicates the capability obtained after the
license and hardware are taken into consideration.

The CE capability of NodeB level indicates the number of CEs allowed to use as
specified in the license.

For details about local cell, local cell group, and capacity consumption law, refer to
the 3GPP TS 25.433.

z According to the capacity consumption laws of common and dedicated channels, the
Controlling RNC (CRNC) debits the amount of the credit resource consumed from or
credits the amount to the Capacity Credit (CC) of the local cell (or local cell group, if any)
based on the SF. The specific scenarios are the addition, removal, and reconfiguration of
the common and dedicated channels.
If the UL CC and the DL CC are separate, they are maintained separately in the
local cell or local cell group.

If the UL CC and DL CC are not separate, only the total CC is maintained in the
local cell or local cell group.

z For the DCH service, the RNC uses the MBR to calculate the SF and searches the following
table for the number of consumed CEs.
Rate Number of CEs Corresponding Credits
Direction SF
(kbit/s) Consumed Consumed
3.4 256 1 2
8 64 1 2
32 32 1.5 3
UL
64 16 3 6
128 8 5 10
384 4 10 20
3.4 256 1 1
8 128 1 1
32 64 1 1
DL
64 32 2 2
128 16 4 4
384 8 8 8
z For the HSUPA service, if the NodeB reports through its private interface that the dynamic
CE function of the cell is enabled, the RNC uses the GBR to calculate the spreading factor.
If the NodeB reports that the dynamic CE function is disabled, the RNC uses the MBR to
calculate the spreading factor. If the NodeB does not report whether the dynamic CE
function is enabled, the RNC determines whether to use the GBR or MBR to calculate the
spreading factor, based on the value of HsupaCeConsumeSelectio. Then, the RNC searches
the following table for the number of consumed CEs.
Rate Number of CEs Corresponding Credits

Direction SF
(kbit/s) Consumed Consumed
UL 8 64 1 2
UL 32 32 1 2
UL 64 32 1 2
UL 128 16 2 4
UL 384 4 8 16
UL 1450 2SF4 16 32
UL 2048 2SF2 32 64
UL 2890 2SF2 32 64
UL 5760 2SF2+2SF4 48 96

NodeB Credit CAC (Cont.)

z NodeB credit CAC is involved in:
Handover
Services setup
z When a new service tries to access the network, the admission decision based on NodeB
credit is implemented as follows:
For an RRC connection setup request, the credit resource-based admission is
successful if the current remaining credit resources of the local cell, local cell group
(if any), and NodeB are sufficient for RRC connection setup.
For a handover service, the credit resource-based admission is successful if the
current remaining credit resources of the local cell, local cell group (if any), and
NodeB are sufficient for the service.
For other services, the RNC has to ensure that the remaining credit of the local cell,
local cell group (if any), and NodeB does not exceed the value of UlHoCeResvSf (for
the uplink) or DlHoCeCodeResvSf (for the downlink) after admission of the new
services.

Parameter of NodeB Credit CAC

z UlHoCeResvSf
Parameter name: UL handover credit reserved SF
z DlHoCeCodeResvSf
Parameter name: DL handover credit and code reserved SF
z HsupaCeConsumeSelection
Parameter name: HSUPA Credit Consume Type
Recommended value: MBR
z UlHoCeResvSf
Content: Uplink Credit Reserved by Spread Factor for HandOver. SFOFF means that none of them are
reserved for handover. If the UL spare resource cant satisfy the reserved resource after the access of
a new service, the service will be rejected. If the value is too high, the credit resource reserved for
handover UEs will be less, leading to the increased possibility of rejecting handover UE admissions,
and performance of handover UEs cannot be guaranteed. If the value is too low, the possibility of
rejecting new UEs may increase and some idle resources are wasted.
z DlHoCeCodeResvSf
Content: Some cell resources can be reserved for handover UEs to guarantee handover success rate
and improve access priority of handover services. This parameter defines the quantity of downlink
code and CE resources reserved for handover. SFOFF refers to that no resources is reserved. SF32
refers to that a code resource with SF = 32 and its corresponding credit resource are reserved. The
backer position the value is in {SF4, SF8, SF16, SF32, SF64, SF128, SF256, SFOFF}, the less code and
credit resources reserved for handover UEs. The possibility of rejecting handover UE admissions
increases and performance of UEs cannot be guaranteed. The more frontal position the value is, the
more the possibility of rejecting new UEs is and some idle resources are wasted.
z HsupaCeConsumeSelection
Content: When the dynamic CE algorithm on NodeB is applied, the CE consumption of HSUPA UE is
based on the GBR. When the dynamic CE algorithm on NodeB is not applied, the CE consumption of
HSUPA UE is based on the MBR. If the CE consumption of HSUPA UE is based on the GBR, the CE
LDR will not select HSUPA users to do data rate reduction. If the CE consumption of HSUPA UE is
based on the MBR,the CE LDR will select HSUPA users to do data rate reduction on condition that
the HSUPA DCCC switch is ON.
Value range: MBR, GBR
Physical value range: MBR, GBR
Set this parameter through ADD UNODEBALGOPARA/ MOD UNODEBALGOPARA.

Iub Resource CAC

z Iub overbooking
The Iub overbooking feature considers the statistic multiplexing of
service activities and multiple users
Through the admission of more users, Iub overbooking increases

the resource utilization on the Iub interface
z The Universal Mobile Telecommunications System (UMTS) supports four traffic classes:
conversational, streaming, interactive, and background. The transmission rate varies with
the traffic class as follows:
For Circuit Switched (CS) conversational services, the channel transmits voice
signals at a certain rate (for example, 12.2 kbit/s) during a conversation and only
transmits Silence Descriptors (SIDs) at intervals when there is no conversation.
For Packet Switched (PS) interactive and background services, such as web
browsing, there is data transmitted during data downloading. After a web page
has been downloaded, and when the user is reading the page, however, there is
very little data to transfer.
z If the Radio Network Controller (RNC) allocates the maximum bandwidth to the subscriber
when a service is established, a large proportion of the Iub transmission bandwidth is
unused. For example, downloading a 50 KB page takes only about one second, but
reading this page needs dozens of seconds. Thus, over 90% of the Iub transmission
bandwidth is not used.
z To save the Iub transmission bandwidth for operator use, Huawei provides the Iub
overbooking function, which applies an admission control mechanism to access the
service. Services are admitted according to the different activity factors. PS interactive and
background services can be admitted according to the Guaranteed Bit Rate (GBR). In this
way, the maximum number of users with the minimum number of activity request to use
voice and PS Best Effort (BE) services can access the network, thus achieving a better
utilization of transmission bandwidth.

Iub Resource CAC (Cont.)

z Activity factor
RT services, including conversational and streaming services, are
admitted at the Maximum Bit Rate (MBR):
Admission bandwidth = MBR x activity factor
NRT services, including interactive and background services, are

admitted at the GBR:
Admission bandwidth = GBR x activity factor
z For BE services, the GBR can be set by running the SET UUSERGBR command.
z Activity factors can be configured for different types of service by running the ADD
TRMFACTOR/ MOD TRMFACTOR command.
z Default settings of activity factors for typical types of service:
Type of Service Default Activity Factor (%)

SRB 15/15 (DL/UL)
AMR voice 70/70 (DL/UL)
R99 CS streaming 100/100 (DL/UL)
R99 PS conversational 70/70 (DL/UL)
R99 PS streaming 100/100 (DL/UL)
R99 PS interactive 100/100 (DL/UL)
R99 PS background 100/100 (DL/UL)
HSPA SRB 50/50 (DL/UL)
HSPA voice 70/70 (DL/UL)
HSPA conversational 70/70 (DL/UL)
HSPA streaming 100/100 (DL/UL)
HSPA interactive 100/100 (DL/UL)
HSPA background 100/100 (DL/UL)

Iub Resource CAC Procedure

z For handover of a user, the following requirements apply:
Load of the path + Bandwidth required by the user < Total
configured bandwidth of the path
z For a new user, the following requirements apply:

configured bandwidth of the path - Bandwidth reserved for
handover
z For rate upsizing of a user, the following requirements apply:

configured bandwidth of the path - Congestion threshold
z The parameters of threshold should satisfy with: Bandwidth reserved for handover ≤
Congestion threshold ≤ Congestion resolving threshold.
z The congestion threshold and the congestion resolving threshold are used to prevent the
ping-pong effect.
z Based on the preceding requirement, the user priorities are as follows:
User requesting handover > New user > User requesting rate upsizing
z The congestion thresholds are FWDCONGBW and BWDCONGBW, and the congestion
resolving thresholds are FWDCONGCLRBW and BWDCONGCLRBW.
z The parameters that are used to reserve bandwidth for handover are as follows:
FWDHORSVBW
BWDHORSVBW

z The admission procedure is as follows:

The new user attempts to be admitted to available bandwidth 1 on the primary path.
If the user succeeds in applying for the resources on the primary path, the user is admitted
to the primary path.
If the user fails to apply for the resources on the primary path, the user then attempts to be
admitted to available bandwidth 2 on the secondary path.
If the user succeeds in applying for the resources on the secondary path, the user is
admitted to the secondary path. If the user fails, the bandwidth admission request of the
user is rejected.
z Admission procedure for handover of a user:
z Admission procedure for a new user:
z Admission procedure for rate upsizing of a user:

Parameters of Iub Resource CAC

z FWDHORSVBW/BWDHORSVBW
Parameter name: Forward/Backward handover reserved bandwidth
Recommended value: 0, namely 0Kbit/s
z FWDCONGBW/BWDCONGBW
Parameter name: Forward/Backward congestion threshold
z FWDCONGCLRBW/BWDCONGCLRBW
Parameter name: Forward/Backward congestion clear threshold
z FWDHORSVBW/BWDHORSVBW
Content: Reserved forward/backward bandwidth for handover user .
Physical unit: Kbit/s
z FWDCONGBW/BWDCONGBW
Content: If the available forward/backward bandwidth is less than or equal to this
value, the forward/backward congestion alarm is emitted.

z FWDCONGCLRBW/BWDCONGCLRBW
Content: If the available forward/backward bandwidth is greater than this value,
the forward/backward congestion alarm is cleared.

z Set these parameters through ADD AAL2PATH/ MOD AAL2PATH (for ATM networking)
and ADD IPPATH/ MOD IPPATH (for IP networking).

HSPA User Number CAC

z HSPA user number CAC is involved in:
Cell level
Maximum number of HSPA users in a cell
NodeB level
Maximum number of HSPA users in all the cells configured in one NodeB
HSDPA user number CAC:

z When HSDPA_UU_ADCTRL is set to on, the HSDPA services have to undergo admission
decision based on the number of HSDPA users.
z When a new HSDPA service attempts to access the network, the algorithm admits the
service if the following conditions are met:
The number of HSDPA users in the cell does not exceed the maximum value
specified by MaxHsdpaUserNum.
The number of HSDPA users in the NodeB does not exceed the maximum value
specified by NodeBHsdpaMaxUserNum.
z Otherwise, the algorithm rejects the service request.
HSUPA user number CAC:

z When HSUPA_UU_ADCTRL is set to on, the HSUPA services have to undergo admission
decision based on the number of HSUPA users.
z When a new HSUPA service attempts to access the network, the algorithm admits the
service if the following conditions are met:
The number of the HSUPA users in the cell does not exceed the maximum value
specified by MaxHsupaUserNum.
The number of the HSUPA users in the NodeB does not exceed the maximum value
specified by NodeBHsupaMaxUserNum.
z Otherwise, the algorithm rejects the service request.

Parameters of HSPA User Number CAC

z MaxHsdpaUserNum
Parameter name: Maximum HSDPA user number
z NodeBHsdpaMaxUserNum
Parameter name: NodeB Max HSDPA User Number
z MaxHsdpaUserNum
Content: Maximum number of users supported by the HSDPA channel. The user in
this parameter refers to the user with services on the HSDPA channel, regardless of
the number of RABs carried on the HSDPA channel. Maximum HSDPA user number
cannot exceed the HSDPA capability of the NodeB product, In practice, the value
can be set based on the cell type and the richness of the available HSDPA power
and code resources. If the value is too low, the cell HSDPA capacity may be
reduces, leading to waste in HSDPA resources. If the value is too high, HSDPA
services may be congested.
Value range: 0~100
z NodeBHsdpaMaxUserNum
Content: Maximum number of HSDPA users of the NodeB.
Value range: 0~3840

Parameters of HSPA User Number CAC

(Cont.)
z MaxHsupaUserNum
Parameter name: Maximum HSUPA user number
z NodeBHsupaMaxUserNum
Parameter name: NodeB Max HSUPA User Number
z MaxHsupaUserNum
Content: Maximum number of users supported by the HSUPA channel. The user in
this parameter refers to the user with services on the HSUPA channel, regardless of
the number of RABs carried on the HSUPA channel. Maximum HSUPA user number
cannot exceed the HSUPA capability of the NodeB product, In practice, the value
can be set based on the cell type and the richness of the available HSUPA power
and code resources. If the value is too low, the cell HSDPA capacity may be
reduces, leading to waste in HSUPA resources. If the value is too high, HSUPA
services may be congested.
Value range: 0~100
z NodeBHsupaMaxUserNum
Content: Maximum number of HSUPA users of the NodeB.
Value range: 0~3840

Contents

Why we need IAC?

z The disadvantages of CAC:
For PS NRT (Non-Real Time) services, CAC is not flexible
No consideration about the priority of different users
No consideration about Directed Retry after CAC rejection
z “Intelligent” means the algorithm can increase admission

successful rate
z The purpose of Intelligent Access Control (IAC) is to increase the access success rate, that
is, RRC connection success rate and RAB setup success rate.

IAC Procedure
z IAC procedure supported by services:
Rate Negotiation DRD

Negotiation
Negotiation
Negotiation
Negotiation
Target Rate
Low-
Initial Rate
Frequency
Inter-RAT
Service
Rate Preemption Queuing Inter-
MBR
GBR
Type
Access
DCH √ √ √ √ √ √ √ √ √
HSUPA – √ √ √ √ √ √ √ –
HSDPA – √ √ – – √ √ √ –

z As shown in the previous figure, the procedure of service access includes the procedures
for RRC connection setup and RAB setup. The successful setup of the RRC connection is
one of the prerequisites for the RAB setup.
z During the RRC connection processing, the RNC first performs RRC redirection for service
steering:
If the RNC decides UE access from the current cell, it then makes a resource-based
admission decision through the CAC algorithm. If the resource-based admission
fails, the RNC performs DRD and redirection. Here, the resources include power
resource, code resource, Iub resource, credit resource, and number of HSPA users.
If the RNC decides UE access from another cell, it then sends an RRC connection
reject message to the UE. The message carries the information about the cell and
instructs the UE to set up an RRC connection to the cell.
z During the RAB processing, the RNC performs the following steps:
1. Performs inter-frequency DRD to select a suitable cell for service steering or load
balancing.
2. Performs rate negotiation according to the service requested by the UE.
3. Makes cell resource-based admission decision. If the admission is successful, UE
access is granted. Otherwise, the RNC performs the next step.
4. Selects a suitable cell, according to the inter-frequency DRD algorithm, from the
cells where no admission attempt has been made, and then goes to 2. If the
attempt fails, the RNC performs the next step.
5. Selects a suitable cell, according to the inter-RAT DRD algorithm. If the inter-RAT
admission is successful, UE access is granted in the inter-RAT cell. If the inter-RAT
DRD fails or is not supported, the RNC performs the next step.
6. Makes a preemption attempt. If the preemption is successful, UE access is granted.
If the preemption fails or is not supported, the RNC performs the next step.
7. Makes a queuing attempt. If the queuing is successful, UE access is granted. If the
queuing fails or is not supported, the RNC performs the next step.
8. Performs low-rate access. If the low-rate access is admitted, UE access is granted.
If the low-rate access is unsuccessful, the RNC performs the next step.
9. Rejects UE access.

IAC - RRC Connection Setup
z Before a new service is admitted to the network, an RRC connection must be set up.
z During the RRC connection setup, the RRC redirection for service steering function is used
for service steering and load sharing between inter-frequency or inter-RAT cells.
z When the resources of a cell for UE access are insufficient, the RNC instructs the UE to an
inter-frequency or inter-RAT cell through DRD or redirection to increase the access rate.
z After receiving an RRC CONNECTION REQUEST message from the UE, the RNC uses the
RRC redirection algorithm for service steering to decide whether the UE may access the
network from the current cell:
If the UE needs to access the network from another cell according to the decision,
the RNC sends an RRC CONNECTION REJECT message to the UE. The message
carries the information about this cell.
If the UE attempts to access the network from the current cell according to the
decision, the RNC uses the CAC algorithm to decide whether an RRC connection
can be set up between the UE and the current cell.
If the RRC connection can be set up between the UE and the current cell,
the RNC sends an RRC CONNECTION SETUP message to the UE.
If no RRC connection can be set up between the UE and the current cell,
the RNC attempts to set up an RRC connection through RRC DRD or RRC
redirection.

RRC Redirection for Service Steering

z During the RRC connection setup, the RNC implements service
steering between inter-frequency or inter-RAT cells according
to the cause of RRC connection setup. In addition, the RNC
considers the load of the cell for access and the redirection
factors to control the degree of load balancing
Algorithm switch: DrSwitch-DR_ RRC_DRD_SWITCH
Triggering factor: RedirFactorOfNorm or RedirFactorOfLDR
Target cell: RedirSwitch
The procedure of RRC redirection for service steering is as follows:

1. The RNC obtains the information about the service requested by the UE and the capability of the
UE.
2. If the switch of RRC redirection for service steering is on, the RNC determines the service type
requested by the UE. If the switch is off or the RNC fails to determine the service type, the RNC
handles the RRC connection setup request of the UE in the current cell.
3. If the RNC succeeds in determining the service type requested by the UE and the switch of RRC
direction for service steering (RedirSwitch) is set to ONLY_TO_INTER_FREQUENCY or
ONLY_TO_INTER_RAT, the RNC performs the next step. Otherwise, the RNC handles the RRC
connection setup request of the UE in the current cell.
4. Based on the cell load and the redirection factors, the RNC decides whether to perform RRC
redirection for service steering.
If the cell is normal, the RNC generates a random number between 0 and 1 and compares
it with the corresponding unconditional redirection factor (RedirFactorOfNorm). If the
random number is smaller than this factor, the RNC performs the next step. Otherwise, the
RNC handles the RRC connection setup request of the UE in the current cell.
If the cell is in the basic congestion or overload state, the RNC generates a random
number between 0 and 1 and compares it with the value of RedirFactorOfLDR. If the
random number is smaller than this factor, the RNC performs the next step. Otherwise, the
RNC handles the RRC connection setup request of the UE in the current cell.
5. Based on the setting of RedirSwitch, the RNC takes the corresponding actions:
If RedirSwitch is set to ONLY_TO_INTER_FREQUENCY, the RNC sends an RRC
CONNECTION REJECT message to the UE, redirecting the UE to the destination frequency
carried in the message.
If RedirSwitch is set to ONLY_TO_INTER_RAT, the RNC sends an RRC CONNECTION
REJECT message to the UE. The message carries the information about inter-RAT
neighboring cells.

Parameters of IAC
z DrSwitch-DR_ RRC_DRD_SWITCH
Parameter name: DRD switch for RRC connection
Recommended value: ON
z RedirSwitch
Parameter name: Redirection Switch
z RedirFactorOfNorm/RedirFactorOfLDR
Parameter name: Redirection Factor Of Normal/LDR
Recommended value: 0, 100
z DrSwitch-DR_ RRC_DRD_SWITCH
Content: When the switch is on, DRD and redirection is performed for RRC connection if retry is
required.
Set this parameter through SET UCORRMALGOSWITCH.
z RedirSwitch
Content: This parameter specifies whether the RRC redirection algorithm is valid for the specified
traffic type. The algorithm is valid only when the RRC redirection switch is enabled and when this
parameter is set to ONLY_TO_INTER_FREQUENCY or ONLY_TO_INTER_FREQUENCY. Value OFF
indicates that RRC redirection is not allowed. Value ONLY_TO_INTER_FREQUENCY indicates that only
the RRC redirection to an inter-frequency neighboring cell is allowed. Value ONLY_TO_INTER_RAT
indicates that only the RRC redirection to an inter-RAT neighboring cell is allowed.
Value range: OFF, ONLY_TO_INTER_FREQUENCY, ONLY_TO_INTER_RAT
Set this parameter through SET UREDIRECTION/ ADD UCELLREDIRECTION.
z RedirFactorOfNorm/RedirFactorOfLDR
Content: When the load of the serving cell is within the normal range, a UE may be redirected to
another cell according to the traffic type. This parameter specifies the possibility of redirecting the
UE to another cell. When this parameter is set to 0, the RRC redirection is not performed if the load
of the serving cell is within the normal range. When the UL load state or DL load state of the
serving cell is LDR or OLC, a UE may be redirected to another cell according to the traffic type. This
parameter specifies the possibility of redirecting the UE to another cell. When this parameter is set to
0, the RRC redirection is not performed if the load state on the serving cell is LDR or OLC. LDR
indicates basic congestion. OLC indicates overload congestion.
Value range: 0~100
Physical unit: %
Set these parameters through SET UREDIRECTION/ ADD UCELLREDIRECTION.

RRC DRD
z Algorithm switch: DrSwitch-DR_ RRC_DRD_SWITCH
z Target cell: intra-band inter-frequency neighboring cells, which

quality is large than threshold:
z The RNC selects intra-band inter-frequency neighboring cells of the current cell. These
neighboring cells are suitable for blind handovers.
z The RNC generates a list of candidate DRD-supportive inter-frequency cells. The quality of
the candidate cell meets the above formula. Here:
(CPICH_EcNo)RACH is the cached CPICH Ec/N0 value included in the RACH
measurement report.
DRD_EcNOnbcell is the DRD threshold (DRDEcN0Threshhold).
z The RNC selects a target cell from the candidate cells for UE access. If the candidate cell
list contains more than one cell, the UE tries a cell randomly.
If the admission is successful, the RNC initiates an RRC DRD procedure.
If the admission to a cell fails, the UE tries admission to another cell in the
candidate cell list. If all the admission attempts fail, the RNC makes an RRC
redirection decision.
z If the candidate cell list does not contain any cell, the RRC DRD fails. The RNC performs
the next step, that is, RRC redirection.

Parameters of IAC (Cont.)

z DRDEcN0Threshhold
Parameter name: Drd Ec/N0 threshold
z DRDEcN0Threshhold
Content: This parameter is used as the DRD Ec/No threshold of whether to perform
the blind handover. If the Ec/No measured value of the current cell is greater than
this parameter of the inter-frequency neighboring cell, this neighboring cell can be
selected to be the candidate DRD cell.
Value range: -24~0
Physical unit: dB
Set this parameter through ADD UINTERFREQNCELL/ MOD UINTERFREQNCELL.

RRC Redirection after DRD Failure

z Algorithm switch:
DrSwitch-DR_ RRC_DRD_SWITCH
ConnectFailRrcRedirSwitch
z Target cell: intra-band inter-frequency neighboring cells or

inter-RAT neighboring cells
z When the RRC DRD fails, the associated RRC connection fails to be set up if the DR_
RRC_DRD_SWITCH subparameter of the DrSwitch parameter is set to OFF or if the switch
of RRC redirection after DRD failure (ConnectFailRrcRedirSwitch) is set to OFF. Otherwise,
the RNC performs the following steps when the RRC DRD fails:
The RNC selects all intra-band inter-frequency cells of the local cell.
The RNC selects candidate cells. The candidate cells are the cells selected in step 1
but exclude the cells that have carried out inter-frequency RRC DRD attempts.
If more than one candidate cell is available, the RNC selects a cell randomly and
redirects the UE to the cell.
If no candidate cell is available,
If the switch of RRC redirection after DRD failure is set to
Only_To_Inter_Frequency, the RRC connection setup fails.
If the switch of RRC redirection after DRD failure is set to
Allowed_To_Inter_RAT, then:
a. If a neighboring GSM cell is configured, the RNC redirects the UE to that
GSM cell.
b. If no neighboring GSM cell is configured, the RRC connection setup fails.


z ConnectFailRrcRedirSwitch
Parameter name: RRC redirect switch
Recommended value: Only_To_Inter_Frequency
z DRDEcN0Threshhold
Content: This parameter specifies the RRC redirection strategy. OFF: RRC
redirection is not allowed. Only_To_Inter_Frequency: Only RRC redirection to inter-

frequency cells is allowed. Allowed_To_Inter_RAT: RRC redirection to inter-
frequency cells and redirection to inter-RAT cells are both allowed.
Value range: OFF, Only_To_Inter_Frequency, Allowed_To_Inter_RAT
Physical value range: OFF, Only_To_Inter_Frequency, Allowed_To_Inter_RAT
Set this parameter through SET UDRD.

IAC - RAB DRD

z The basic procedure of RAB DRD is as follows:
The RNC performs inter-frequency DRD. According to the purposes
of directed retry, Inter-frequency DRD is of the following types:
Inter-frequency DRD for service steering
Inter-frequency DRD for load balancing
If all admission attempts of inter-frequency DRD fail, the RNC

performs an inter-RAT DRD
If all admission attempts of inter-RAT DRD fail, the RNC selects a
suitable cell to perform preemption and queuing
z Through the RAB DRD procedure, the RNC selects a suitable cell for RAB processing during
access control. RAB DRD is of two types: inter-frequency DRD and inter-RAT DRD. Inter-
frequency DRD is further classified into inter-frequency DRD for service steering and inter-
frequency DRD for load balancing.
z After receiving a Radio Access Network Application Part (RANAP) message RAB
ASSIGNMENT REQUEST, the RNC initiates a RAB DRD procedure to select a suitable cell for
RAB processing during access control.

Inter-Frequency DRD for Service

Steering
The procedure of DRD for service steering is as follows:

1. The RNC determines the candidate cells to which blind handovers can be performed and sorts the
candidate cells in descending order according to service priority.
A candidate cell must meet the following conditions:
The frequency of the candidate cell is within the band supported by the UE.
The quality of the candidate cell meets the requirements of inter-frequency DRD. For details,
refer to RRC DRD.
The candidate cell supports the requested service.
2. The RNC selects a target cell from the candidate cells in order of service priority for UE access.
If there is more than one cell with the same service priority,
When the cell, in which the UE requests the service, is one of the candidate cells with the
same service priority, preferably, the RNC selects this cell for admission decision.
Otherwise, the RNC randomly selects a cell as the target cell.
3. The CAC algorithm makes an admission decision based on the status of the target cell.
If the admission attempt is successful, the RNC accepts the service request.
If the admission attempt fails, the RNC removes the cell from the candidate cells and then
checks whether all candidate cells are tried.
If there are any cells where no admission decision has been made, the algorithm
goes back to step 2.
If admission decisions have been made in all the candidate cells, then:
a. If the service request is an HSPA one, the HSPA request falls back to a
DCH one. Then, the algorithm goes back to step 1 to make an admission
decision based on R99 service priorities.
b. If the service request is a DCH one, the RNC initiates an inter-RAT DRD.

Inter-Frequency DRD for Service

Steering (Cont.)
z Cell service priorities refer to the priorities of cells under the
same coverage accepting specific service types. These priorities
help achieve traffic absorption in a hierarchical way
Service Service Service Service Service

Priority Priority of Priority of Priority of Priority of
Cell
Group R99 RT R99 NRT HSPA Other
Identity Service Service Service Service
A 1 2 1 1 0
B 2 1 2 0 0
z Service priority groups are configured on the LMT. In each group, priorities of R99 RT
services, R99 NRT services, HSPA services, and other services are defined.
z The priorities of specific service types in cells are configurable. If a cell does not support a
service type, the priority of this service type is set to 0 in this cell. The group of service
priorities in each cell is specified by the service priority group identity (SpgId) parameter.
z When selecting a target cell for RAB processing, the RNC selects a cell with a high priority,
that is, a cell that has a small value of service priority.


z ServiceDiffDrdSwitch
Parameter name: Service differential drd switch
z SpgId
Parameter name: Service priority group Identity
z PriorityServiceForR99RT/R99NRT/HSPA/ExtRab
Parameter name: Service priority of R99 RT/R99 NRT/HSPA/Other
service
Recommended value: 1, 1, 1, 1
z ServiceDiffDrdSwitch
Content: This parameter specifies whether the service differential DRD algorithm
will be applied.
Set this parameter through ADD UCELLDRD/ SET UDRD.
z SpgId
Content: This parameter identifies a group of cells that have specific capabilities for
four service types: R99 real-time services, R99 non-real-time services, HSPA services,
and other services.
Value range: 1~8
Set this parameter through ADD USPG/ MOD USPG.
z PriorityServiceForR99RT/R99NRT/HSPA/ExtRab
Content: These parameters specifie the capability of the cells with a specific SpgId
for R99 real-time/R99 non-real-time/HSPA/extension services. The value 0 means

that these cells do not support these kinds of services. The value 1 indicates the
highest priority whereas the value 7 indicates the lowest.
Value range: 0~7
Set these parameters through ADD USPG/ MOD USPG.

Inter-Frequency DRD for Load Balancing

z Load balancing considers two resources, power and code:
The availability of power-based DRD for load balancing for DCH
service is specified by the LdbDRDSwitchDCH parameter
The availability of power-based DRD for load balancing for HSDPA

service is specified by the LdbDRDSwitchHSDPA parameter
The availability of code-based DRD for load balancing is specified

by the CodeBalancingDrdSwitch parameter
z If the UE requests a service setup or channel reconfiguration in an area covered by multiple

frequencies, the RNC sets up the service on a carrier with a light load to achieve load
balancing among the cells on the different frequencies.
z In practice, it is recommended that only either a power-based DRD for load balancing or a
code-based DRD for load balancing be activated. If both are activated, power-based DRD
for load balancing takes precedence over code-based DRD for load balancing.
z Code-based DRD for load balancing is applicable to only R99 services because HSDPA
services use reserved codes.


z LdbDRDSwitchDCH
Parameter name: Load balance DRD switch for DCH
z LdbDRDSwitchHSDPA
Parameter name: Load balance DRD switch for HSDPA
z CodeBalancingDrdSwitch
Parameter name: Code balance drd switch
z LdbDRDSwitchDCH
Content: This parameter specifies whether the load balancing DRD algorithm will
be applied for services carried on DCH.

z LdbDRDSwitchHSDPA
Content: This parameter specifies whether the load balancing DRD algorithm will
be applied for services carried on HS-DSCH.

z CodeBalancingDrdSwitch
Content: This parameter specifies whether the code balancing DRD algorithm will
be applied.
z Set these parameters through ADD UCELLDRD/ SET UDRD.

Power-Based DRD for Load Balancing

z Two algorithms are available for power-based load balancing:
Algorithm 1: DL non-HSDPA power and DL HS-DSCH GBP
Algorithm 2: DCH ENU and HSDPA ENU
z Cell B has a lighter load of non-HSDPA power than cell A. If the UE requests a DCH service in
cell A, preferably, the RNC selects cell B for the UE to access
z Cell A has a lighter load of HS-DSCH GBP than cell B. If the UE requests an HSDPA service in
cell B, preferably, the RNC selects cell A for the UE to access
z Algorithm 1: DRD for load balancing is performed according to the cell measurement
values about the DL non-HSDPA power and DL HS-DSCH GBP.
For DCH service, the RNC sets up the service on a carrier with a light load of non-
HSPA power to achieve load balancing among the cells at the different frequencies.
For HSDPA service, the RNC sets up the service on a carrier with a light load of HS-
DSCH GPB to achieve load balancing among the cells at different frequencies.
z Algorithm 2: DRD for load balancing is performed according to the DCH ENU and HSDPA
user number.
For DCH service, the RNC sets up the service on a carrier with a light load of DCH
ENU to achieve load balancing among the cells on different frequencies.

For HSDPA service, the RNC sets up the service on a carrier with a light load of
HSDPA user to achieve load balancing among the cells on different frequencies.


z LdbDRDchoice
Parameter name: Load balance DRD choice
Recommended value: UserNumber, namely Alogrithm 2
z LdbDRDchoice
Content: This parameter specifies which choice the load balancing DRD algorithm
will be applied. Power: Power (Downlink none-HSDPA power is used for services
carried on DCH, and downlink HSDPA guarantee power is used for services carried
on HS-DSCH) will be applied to the load balancing DRD algorithm. UserNumber:
User number (Downlink R99 equivalent user number is used for services carried on
DCH, and downlink HSDPA user number is used for services carried on HS-DSCH)
will be applied to the load balancing DRD algorithm.
Value range: Power, UserNumber
Physical value range: Algorithm 1, Algorithm 2
Set these parameters through ADD UCELLDRD/ SET UDRD.


(Cont.)
The procedure of power-based DRD for load balancing is as follows:

1. The RNC determines the candidate cells to which blind handovers can be performed.
A candidate cell must meet the following conditions:
The frequency of the candidate cell is within the band supported by the UE.
The quality of the candidate cell meets the requirements of inter-frequency DRD.
2. If the current cell is such a candidate cell, the RNC goes to step 3. Otherwise, the RNC
selects a cell with the lightest load from the candidate cells as the target cell and then
goes to step 4.
3. The RNC determines whether the DL radio load of the current cell is lower than the
threshold of power-based DRD for load balancing (condition 1). Based on the bearer type
(DCH or HSDPA) of the requested service, the RNC selects an appropriate condition.
If the condition 1 is met, the service tries admission to the current cell. And go to
step 5.
Otherwise, go to step 4.

4. The RNC selects a target cell for UE access.

The RNC determines whether any inter-frequency neighboring cell meets the
condition 2. Based on the bearer type (DCH or HSDPA) of the requested service,
the RNC selects an appropriate condition.
Then, the RNC selects the target cell as follows:
If there is only one inter-frequency neighboring cell that meets the
conditions of DRD for load balancing, the RNC selects this cell as the
target cell. If there are multiple such cells:
For a DCH service:
a. If algorithm 1 is used, the RNC selects the cell with the lightest non-
HSDPA load as the target cell.
b. If algorithm 2 is used, the RNC selects the cell with the lightest load
of DCH ENU as the target cell.
For an HSDPA service:
a. If algorithm 1 is used, the RNC selects the cell with the lightest load
of HS-DSCH required power as the target cell.
b. If algorithm 2 is used, the RNC selects the cell with the lightest load
of HSDPA user as the target cell.
If there is no such cell, the RNC selects the current cell as the target cell.
5. The CAC algorithm makes an admission decision based on the status of the target cell.
If the admission attempt is successful, the RNC admits the service request.
If the admission attempt fails, the RNC checks whether admission decisions have
been made in all candidate inter-frequency neighboring cells.
If there is any cell where no admission decision is made, the algorithm
goes back to step 2.
If admission decisions have been made in all the candidate cells:
a. When the service request is an HSPA one, the HSPA request falls
back to a DCH one. Then, the algorithm goes back to step 1 to
make an admission decision based on R99 service priorities.
b. When the service request is a DCH one, the RNC initiates an inter-
RAT DRD.


(Cont.)
z DRD condition 1:
For algorithm 1:
For DCH bearer:
(Thd AMR , cutcell − Pnon − H , cutcell ) > Thd non − H

For HSDPA bearer:
(Thd total , cutcell − PGBP , cutcell ) > Thd H

For algorithm 2:
For DCH bearer:
(Thd AMR , cutcell − PD − ENU , cutcell ) > Thd non − H
For HSDPA bearer:
(Thd H −ue ,cutcell − PH −ue ,cutcell ) / Thd H −ue ,cutcell > Thd H
Factor Description Parameter
DL threshold of
ThdAMR,cutcell DlConvAMRThd
conversational AMR service
Pnon-H,cutcell Non-HSDPA power load -
Dl load balance DRD power

Thdnon-H LdbDRDLoadRemainThdDCH
remain threshold for DCH
Thdtotal,cutcell DL total power threshold DlCellTotalThd

PGBP,cutcell HS-DSCH GBP -
Dl load balance DRD power

ThdH LdbDRDLoadRemainThdHSDPA
remain threshold for HSDPA
PD-ENU,cutcell DCH ENU load -
Maximum number of
ThdH-ue,cutcell MaxHsdpaUserNum
HSDPA users
Total number of HSDPA
PH-ue,cutcell -
users


z Recommended values for power-based DRD condition 1:
Recommended
Parameter Parameter name
value
DL threshold of Conv AMR
DlConvAMRThd 80%
service
LdbDRDLoadRemainT Dl load balance DRD power
35%
hdDCH remain threshold for DCH
DlCellTotalThd DL total power threshold 90%
LdbDRDLoadRemainT Dl load balance DRD power
100%
hdHSDPA remain threshold for HSDPA
MaxHsdpaUserNum Maximum HSDPA user number 64
z DlConvAMRThd
Content: The percentage of the conversational AMR service threshold to the 100%
downlink load. It is applicable to algorithm 1 and algorithm 2.

z LdbDRDLoadRemainThdDCH
Content: This parameter specifies the downlink load threshold to trigger load
balancing DRD for services carried on DCH. The load balancing DRD will probably
be triggered only when the downlink cell remanent non H power or remanent R99
equivalent user number is less than this threshold.
z DlCellTotalThd
Content: Admission threshold of the total cell downlink power.
z LdbDRDLoadRemainThdHSDPA
Content: This parameter specifies the downlink load threshold to trigger load
balancing DRD for services carried on HS-DSCH. The load balancing DRD will
probably be triggered only when the downlink cell remanent HSDPA guarantee
power or remanent HSDPA user number is less than this threshold.
z MaxHsdpaUserNum
Content: Maximum number of users supported by the HSDPA channel. The user in
this parameter refers to the user with services on the HSDPA channel, regardless of
the number of RABs carried on the HSDPA channel.


(Cont.)
z DRD condition 2:
Algorithm Bearer Formula
(Thd AMR,nbcell − Pnon−H ,nbcell ) − (ThdAMR,cutcell − Pnon−H ,cutcell ) > ThdD,loadoffset

(Thd − Pload ,cutcell ) − (Thdtotal ,nbcell − Pload ,nbcell ) < Thdtotal ,loadoffset
DCH
total ,cutcell
Algorithm 1
HSDPA
(Thd total ,nbcell − PGBP,nbcell ) − (Thdtotal ,cutcell − PGBP,cutcell ) > Thd H ,loadoffset
(Thd total , cutcell − Pload ,cutcell ) − (Thdtotal , nbcell − Pload , nbcell ) < Thdtotal ,loadoffset
DCH (Thd AMR,nbcell −PD−enu,nbcell ) −(ThdAMR,cutcell − PD−enu,cutcell ) >ThdD,loadoffset

Algorithm 2
HSDPA
(Thd H−ue,nbcell − PH−ue,nbcell ) /ThdH−ue,nbcell − (ThdH−ue,cutcell − PH−ue,cutcell ) /ThdH−ue,cutcell
> ThdH,loadoffset
Inter-frequency
Current cell Description
neighboring cell
DL threshold of conversational AMR service
ThdAMR,cutcell ThdAMR,nbcell
(DlConvAMRThd)
Pnon-H,cutcell Pnon-H,nbcell Non-HSDPA power load
Load balancing DRD offset for DCH
ThdD,loadoffset -
(LdbDRDOffsetDCH)
Thdtotal,cutcell Thdtotal,nbcell DL total power threshold (DlCellTotalThd)
Total power load, which is the sum of the
Pload,cutcell Pload,nbcell
non-HSDPA power and the GBP
Load balancing DRD total power protect
Thdtotal,loadoffset -
threshold (LdbDRDTotalPwrProThd)
PGBP,cutcell PGBP,nbcell HS-DSCH GBP
Load balancing DRD offset for HSDPA
ThdH,loadoffset -
(LdbDRDOffsetHSDPA)
PD-enu,cutcell PD-enu,nbcell DCH ENU load
Maximum number of HSDPA users
ThdH-ue,cutcell ThdH-ue,nbcell
(MaxHsdpaUserNum)
PH-ue,cutcell PH-ue,nbcell Total number of HSDPA users


z Recommended values for power-based DRD condition 2:
Recommended
value
Load balance DRD offset for
LdbDRDOffsetDCH 10%
DCH
Load balance DRD offset for
LdbDRDOffsetHSDPA 10%
HSDPA
Load balance DRD total
LdbDRDTotalPwrProThd 30%
power protect threshold
z LdbDRDOffsetDCH
Content: This parameter specifies the threshold of remanent load offset between
the current cell and the target cell when load balancing DRD is applied for DCH
users. Only when the remanent load offset reaches this threshold can a
neighboring cell be selected as a candidate DRD cell for DCH users. (If Load
balance DRD choice is Power, additional condition should also be statisfied, that is
total power remain difference between the current cell and target cell should be
less than Load Balance DRD Total Power Protect Threshold; if Load balance DRD
choice is UserNumber, additional condition is not needed.)
z LdbDRDOffsetHSDPA
Content: This parameter specifies the threshold of remanent load offset between
the current cell and the target cell when load balancing DRD is applied for HSDPA
users. Only when the remanent load offset reaches this threshold can a
neighboring cell be selected as a candidate DRD cell for HSDPA users. (If Load
balance DRD choice is Power, additional condition should also be statisfied, that is
total power remain difference between the current cell and target cell should be
less than Load Balance DRD Total Power Protect Threshold; if Load balance DRD
choice is UserNumber, additional condition is not needed.)
z LdbDRDTotalPwrProThd
Content: This parameter specifies the threshold of the downlink remanent total
power difference between the current cell and the target cell when load balancing
DRD is applied and the load balancing DRD choice is Power. Only when the
downlink remanent total power difference is less than this threshold can a
neighboring cell be selected as a candidate DRD cell.
z Set these parameters through SET UDRD.

Code-Based DRD for Load Balancing
The procedure of code-based DRD for load balancing is as follows:

1. The RNC determines whether the minimum remaining SF of the current cell is smaller than
the minimum SF threshold of DRD for code balancing (CodeBalancingDrdMinSFThd).
If the minimum SF is smaller than this threshold, the RNC tries the admission of
the service request to the current cell.
If the minimum SF is not smaller than this threshold, the RNC goes to the next
step.
2. The RNC determines whether the code load of the current cell is lower than the code
occupation rate threshold of DRD for code balancing (CodeBalancingDrdCodeRateThd).
If the code load is lower than this threshold, the service tries the admission to the
current cell.
If the code load is higher than or equal to this threshold, the RNC selects the cell
with the lightest load or the current cell as the target cell. The RNC selects the cell
as follows:
If the minimum SF supported by the cell with the lightest code load is the
same as that supported by the current cell, and the difference between
the code resource occupancies of the two is larger than or equal to the
value of DeltaCodeOccupiedRate, the RNC selects the cell with the lightest
code load as the target cell. Otherwise, the RNC selects the current cell as
the target cell.
If the minimum SF supported by the cell with the lightest code load is
smaller than the minimum SF supported by the current cell, the RNC
selects the cell with the lightest code load as the target cell.


z Recommended values for code-based DRD:
Recommended
value
CodeBalancingDrdMinSF Minimum SF threshold for
SF8
Thd code balance drd
CodeBalancingDrdCodeR Code occupied rate threshold

13%
ateThd for code balancing drd
DeltaCodeOccupiedRate Delta code occupied rate 7%
z CodeBalancingDrdMinSFThd
Content: This parameter specifies one of the triggering conditions of code
balancing DRD. (The other condition is the code occupancy.) This condition refers
to that the minimum spreading factor of the best cell is not smaller than the value
of this parameter.
z CodeBalancingDrdCodeRateThd
Content: This parameter specifies one of the triggering conditions of code
balancing DRD. (The other condition is the minimum spreading factor.) This
condition refers to that the code occupancy in the best cell is not lower than the
value of this parameter.
z DeltaCodeOccupiedRate
Content: This parameter specifies the threshold of code occupancy offset between
the current cell and the target cell when code balancing DRD is applied. Only when
the cell code occupancy offset reaches this threshold can a neighboring cell be
selected to be a candidate cell for DRD.
Set this parameter through SET UDRD.

Inter-Frequency DRD
z Relation Between DRD for Service Steering and DRD for Load
Balancing:
When both DRD for service steering and DRD for load balancing
are enabled, the general principles of inter-frequency DRD are as
follows:
DRD for service steering takes precedence over DRD for load balancing,
that is, preferably considers service priorities
To services of the same service priority, load balancing applies
z For example, Universal Terrestrial Radio Access Network (UTRAN) f1, UTRAN f2, UTRAN f3, and
UTRAN f4 are inter-frequency cells with the same coverage. The service priorities of real-time R99
services in these cells are listed in the following table.
Cell Value of Service Priority of R99 Real-Time Service
UTRAN f1 3
UTRAN f2 2
UTRAN f3 1
UTRAN f4 1
z According to the principles of inter-frequency DRD, the RAB DRD of a real-time R99 service will
select UTRAN f3 to make a CAC decision, as shown in the following figure.

Inter-Frequency DRD Procedure
The procedure of inter-frequency DRD is as follows:

z If DRD for service steering is enabled but DRD for load balancing is disabled, as shown in
A in the previous figure, the inter-frequency DRD procedure is the procedure of DRD for
service steering.
z If DRD for load balancing is enabled but DRD for service steering is disabled, as shown in
B in the previous figure, the inter-frequency DRD procedure is the procedure of DRD for
load balancing.
z If both DRD for load balancing and DRD for service steering are disabled:
1. The UE attempts to access the current cell when its service priority is not 0. If the
service priority of the current cell is 0, the UE attempts to access another
candidate cell whose service priority is not 0.
2. The CAC algorithm makes an admission decision based on the cell status.
If the admission attempt is successful, the RNC admits the service request.
If the admission attempt fails, the UE attempts to access another
candidate cell randomly.
3. If any request for access to a candidate cell is rejected, then:
If the service request is an HSPA one, the HSPA request falls back to a
DCH one. Then, the algorithm goes back to step 1 to retry admission
based on R99 service priorities.
If the service request is a DCH one, the RNC initiates an inter-RAT DRD.

z If both DRD for load balancing and DRD for service steering are enabled:
1. The RNC determines the candidate cells to which blind handovers can be
performed. A candidate cell must meet the following conditions:
The frequency of the candidate cell is within the band supported by the
UE.
The quality of the candidate cell meets the requirements of inter-
frequency DRD.
2. The RNC selects a target cell from the candidate cells for UE access.
Based on the relation between DRD for service steering and DRD for load
balancing:
The RNC preferably selects the cell with the highest service priority.
If there are multiple cells with the highest service priority, load balancing
applies to these cells.
3. The CAC algorithm makes an admission decision based on the resource status of
the cell.
If the admission attempt is successful, the RNC initiates an inter-frequency
blind handover to the cell.
If the admission attempt fails, the RNC removes the cell from the
candidate cells and then checks whether all candidate cells are tried.
a. If there is any candidate cell not tried, the algorithm goes back to step 2
to try this cell.
b. If all candidate cells haven been tried, then:
-If the service request is an HSPA one, the HSPA request falls back to a
DCH one. Then, the algorithm goes back to step 1 to retry admission
based on R99 service priorities.
-If the service request is a DCH one, the RNC initiates an inter-RAT DRD.

Inter-RAT DRD
The inter-RAT DRD procedure is as follows:

1. If the current cell is configured with any neighboring GSM cell suitable for blind handover,
and if the "service handover" IE that is contained in the RAB assignment signaling
assigned by the CN is set to "handover to GSM should be performed", then the RNC
performs step 2. Otherwise, the service request undergoes preemption and queuing.
2. The RNC generates a list of candidate DRD-supportive inter-RAT cells that fulfill the
following requirement:
Here:
(CPICH_EcNO)RACH is the cached CPICH Ec/N0 value included in the RACH
measurement report.
DRD_EcNOnbcell is the DRD threshold (DRDEcN0Threshhold).
If the candidate cell list does not include any cell, the service request undergoes
preemption and queuing.
3. The RNC selects target GSM cells for the service request according to the blind handover
priority.
4. If all admission attempts fail or the number of inter-RAT handover retries exceeds the
value of DRMaxGSMNum, the service request undergoes preemption and queuing.


z DRDEcN0Threshhold
Parameter name: Drd Ec/N0 threshold
z DRMaxGSMNum
Parameter name: Max inter-RAT direct retry number
Recommended value: 2, namely 2 times
z DRDEcN0Threshhold
Content: This parameter is used as the DRD Ec/No threshold of whether to perform
the blind handover. This parameter is used as the DRD Ec/No threshold of whether
to perform the blind handover. When choosing a DRD candidate cell, if the Ec/No
value of the current cell is greater than the threshold of inter-RAT/inter-frequency
neighboring cell, the DRD is permitted.
Value range: -24~0
Physical unit: dB
Set this parameter through ADD U2GNCELL/ MOD U2GNCELL.
z DRMaxGSMNum
Content: This parameter specifies the maximum number of inter-RAT RAB directed
retries. It decides the size of the candidate set for inter-RAT DRD. The value 0
indicates that inter-RAT RAB DRD is not applicable.
Value range: 0~5

IAC - Rate Negotiation

z Rate negotiation includes:
MBR negotiation
GBR negotiation
Initial rate negotiation
Target rate negotiation

MBR Negotiation
z If the IE "Alternative RAB Parameter Values" is present in the
RANAP RAB ASSIGNMENT REQUEST or the RELOCATION
REQUEST message when a PS service is set up, reconfigured, or
admitted, then the RNC and the CN negotiate the rate
according to the UE capability to obtain the MBR while
ensuring a proper QoS
z For the PS streaming service, when PS_STREAM_IU_QOS_NEG_SWITCH is set to 1, the Iu

QoS negotiation function is enabled for MBR negotiation.
z For the PS BE service:
When both PS_BE_IU_QOS_NEG_SWITCH and
PS_BE_STRICT_IU_QOS_NEG_SWITCH are set to 1, the Iu QoS negotiation function

is enabled, and the RNC determines the MBR of Iu QoS negotiation based on the
information about UE capability, cell capability and other settings.
When PS_BE_IU_QOS_NEG_SWITCH is set to 1 and
PS_BE_STRICT_IU_QOS_NEG_SWITCH is set to 0, the Iu QoS negotiation function is

enabled, and the RNC determines the MBR of Iu QoS negotiation based on the
maximum rate supported by the UE rather than the cell capability and other
settings.


z PsSwitch-PS_STREAM_IU_QOS_NEG_SWITCH
Parameter name: PS rate negotiation switch for Streaming service
z PsSwitch-PS_ BE_IU_QOS_NEG_SWITCH
Parameter name: PS rate negotiation switch for BE service
z PsSwitch-PS_BE_STRICT_IU_QOS_NEG_SWITCH
Parameter name: PS rate negotiation switch for strict BE service
Content: When the switch is on, the Iu QoS Negotiation function is applied to the PS
STREAM service if Alternative RAB Parameter Values IE is present in the RANAP RAB
ASSIGNMENT REQUEST or RELOCATION REQUEST message.
z PsSwitch-PS_ BE_IU_QOS_NEG_SWITCH
Content: When the switch is on, the Iu QoS Negotiation function is applied to the PS BE
service if Alternative RAB Parameter Values IE is present in the RANAP RAB ASSIGNMENT
REQUEST or RELOCATION REQUEST message.
z PsSwitch-PS_BE_STRICT_IU_QOS_NEG_SWITCH
Content: When the switch is on, the strict Iu QoS Negotiation function is applied to the PS
BE service, RNC select Iu max bit rate based on UE capacity, cell capacity, max bitrate and
alternative RAB parameter values in RANAP RAB ASSIGNMENT REQUEST or RELOCATION
REQUEST message. When the switch is off, the loose Iu QoS Negotiation function is applied
to the PS BE service, RNC select Iu max bit rate based on UE capacity, max bitrate and
alternative RAB parameter values in RANAP RAB ASSIGNMENT REQUEST or RELOCATION
REQUEST message, not consider cell capacity, this can avoid Iu QoS Renegotiation between
different cell. The switch is valid when PS_BE_IU_QOS_NEG_SWITCH is set to ON.
z Set these parameters through SET UCORRMALGOSWITCH.

GBR Negotiation
z During the setup, reconfiguration, or handover of a real-time
PS service, if the RAB assignment message carries multiple
alternative GBRs and PS_STREAM_IU_QOS_NEG_SWITCH is set
to 1, the RNC selects the minimum rate as the GBR of this RAB
and sends it to the CN. If the IE "Type of Alternative
Guaranteed Bit Rate Information" in the message is set to
unspecified, the GBR is set to 8 kbit/s

Initial Rate Negotiation

z For a non-real-time service in the PS domain, the RNC selects an initial
rate to allocate bandwidth for the service before the admission
request based on cell resources in the following cases:
A service is set up
The UE state changes from CELL_FACH to CELL_DCH
z The negotiation is based on the cell load information, which includes:

Uplink and downlink radio bearer status of the cell
Minimum spreading factor (SF) supported
HSPA capability

Initial Rate Negotiation (Cont.)

z Initial rate definition for DCH services:
DCCC PS BE Initial Rate Dynamic

Actual Initial Rate
Switch Configuration Switch
In the uplink, the initial rate is the smaller one
of the MBR and 384 kbit/s.
ON ON In the downlink, the initial rate is dynamically
set on the basis of Ec/No. For the specific
method, see the following description.
In the uplink, the initial rate is the smaller one
of the MBR and the initial rate of the uplink
BE service.
ON OFF
In the downlink, the initial rate is the smaller
one of the MBR and the initial rate of the
downlink BE service.
OFF - MBR
z As described in the table, when the two switches are ON, the initial rate is dynamically set
on the basis of Ec/No in the downlink. The specific method is as follows:
When receiving an RRC connection setup request, the RNC starts the timer
EcN0EffectTime.
Before the timer expires, the RNC dynamically sets the initial rate based on the P-
CPICH Ec/No carried in the RRC CONNECTION REQUEST message:

If the cell Ec/No is above the Ec/No threshold (EcN0Ths), the RNC sets the
actual initial rate to the smaller one of the MBR and 384 kbit/s.
If the cell Ec/No is below or at the Ec/No threshold (EcN0Ths) or the RRC
CONNECTION REQUEST message does not carry the information about
Ec/No, the RNC sets the actual initial rate to the smaller one of the MBR
and the initial rate of the downlink BE service (DlBeTraffInitBitrate).


z DraSwitch-DRA_DCCC_SWITCH
Parameter name: Dynamic resource allocation switch for DCCC
z PsSwitch-PS_BE_INIT_RATE_DYNAMIC_CFG_SWITCH
Parameter name: PS rate negotiation switch for initial rate
reconfiguration
Content: When the switch is on, the dynamic channel reconfiguration control
algorithm is used for the RNC.

z PsSwitch-PS_BE_INIT_RATE_DYNAMIC_CFG_SWITCH
Content: When the switch is on, the initial rate of the service should be
dynamically configured according to the value of Ec/No reported by the UE when

the PS BE service is established.
z Set these parameters through SET UCORRMALGOSWITCH.


z EcN0EffectTime
Parameter name: Ec/N0 effective time
Recommended value: 30000, namely 30000ms
z EcN0Ths
Parameter name: Ec/N0 threshold
Recommended value: 41, namely -4dB
z DlBeTraffInitBitrate
Parameter name: DL BE traffic Initial bit rate
Recommended value: D64, namely 64kbit/s
z EcN0EffectTime
Content: This parameter specifies the time duration when the reported Ec/No is
valid. The reported Ec/No is valid for the period (starting from the time when the
RRC connection request is initiated) specified by this parameter.
Physical unit: ms
Set this parameter through ADD UCELLFRC/ SET UFRC.
z EcN0Ths
Content: This parameter specifies the threshold for determining the signal quality
in a cell. If the reported Ec/No exceeds the value of this parameter, you can infer
that the signal quality in the cell is good and a high code rate can be set for initial
access.
Value range: 0~49
Physical value range: -24.5~0 (0: -24.5, 1: -24 ……49: 0)
Physical unit: dB
Set this parameter through ADD UCELLFRC/ SET UFRC.
z DlBeTraffInitBitrate
Content: DL BE traffic Initial bit rate. When DCCC function is enabled, the downlink
initial bit rate will be set to this value if the downlink max bit rate is higher than the
initial bit rate.
Value range: D8, D16, D32, D64, D128, D144, D256, D384
Physical value range: 8, 16, 32, 64, 128, 144, 256, 384
Physical unit: kbit/s
Set this parameter through SET UFRC.

Initial Rate Negotiation (Cont.)

z Initial rate definition for HSUPA services:
If HSUPA_DCCC_SWITCH is set to 1, the actual initial rate is the
initial rate of the HSUPA BE service (HsupaInitialRate)
If the HSUPA DCCC function is disabled, the actual initial rate is the
MBR


z DraSwitch-DRA_HSUPA_DCCC_SWITCH
Parameter name: Dynamic resource allocation switch for HSUPA
DCCC
z HsupaInitialRate
Parameter name: Initial rate of HSUPA BE traffic
Recommended value: D256, namely 256kbit/s
z DraSwitch-DRA_HSUPA_DCCC_SWITCH
Content: When the switch is on, the DCCC algorithm is used for HSUPA. The DCCC
switch must be also on before this switch takes effect.

z HsupaInitialRate
Content: HSUPA BE traffic Initial bit rate. When DCCC algorithm switch and HSUPA
DCCC algorithm switch are enabled, the uplink initial bit rate will be set to this
value if the uplink max bit rate is higher than the initial bit rate.
Value range: D8, D16, D32, D64, D128, D144, D256, D384, D608, D1440, D2048,
D2880, D5740
Physical value range: 8, 16, 32, 64, 128, 144, 256, 384, 608, 1440, 2048, 2880,
5740
Physical unit: kbit/s
Set this parameter through SET UFRC.

Target Rate Negotiation

z For a non-real-time service in the PS domain, if cell resource-
based admission fails, the RNC selects a target rate to allocate
bandwidth for the service based on cell resource in following
cases:
Service setup
Soft handover
DCCC rate upsizing
z If the cell has sufficient code and CE resources, the RNC sets the candidate target rate to
the one that matches the cell resource surplus. Then, the RNC sets the target rate to the
greater one of the candidate target rate and the GBR.
z In the case of soft handover, the actual target rate is the candidate target rate set by the
RNC.
z In the case of DCCC rate upsizing, if the rate upsizing fails, the target rate is the greater
one of the candidate target rate and the pre-upsizing DCCC rate.

IAC - Preemption
z After CAC fails, the RNC performs preemption firstly
z Precondition of preemption and queuing:

According to RAB ASSIGNMENT REQUEST message, preemption
and queuing are supported
The related algorithm switches are set to ON
z Preemption and queuing guarantee the success in the access of a higher-priority user by
forcibly releasing the resources of a lower-priority user.
z Preemption and queuing are applicable to the following scenarios:
Setup or modification of a service
Hard handover or SRNS relocation
UE state transition from CELL_FACH to CELL_DCH

z The following table describes the selection of the target cell for preemption or queuing.
DRD Power-Based Code-Based
Switch for DRD Switch DRD Switch
Target Cell for Preemption or Queuing
Service for Load for Load
Steering Balancing Balancing
ON - The cell with the lightest load among the cells
- ON with the highest service priority.
The cell with the highest service priority. If there

are multiple such candidate cells, the target cell
ON is selected as follows:
If the current cell is one of the candidate cells,
OFF OFF
the current cell is selected as the target cell.
Otherwise, a neighboring cell that supports
blind-handover is selected randomly from the
candidate cells.
ON -
The cell that supports the service and has the
lightest load. If there are multiple such candidate
cells, the target cell is selected as follows:
If the current cell is one of the candidate cells,
- ON the current cell is selected as the target cell.
Otherwise, a neighboring cell that supports
OFF blind-handover is selected randomly from the
candidate cells.
Preferably the current cell. If the current cell does

OFF OFF not support the service, a cell is selected
randomly from the cells that support this service.
z The following table describes the preemption for different types of service on different resources.
Service That Can Be Preempted

Service Resource
R99 HSUPA HSDPA R99+HSPA
Code √ - - √
Power √ √ √ √
R99 service
CE √ √ - √
Iub bandwidth √ √ √ √
Code - - - -
HSDPA Power √ - √ √
service CE - - - -
Iub bandwidth √ - √ √
Code - - - -
HSUPA Power √ √ - -
service CE √ √ - √
Iub bandwidth √ √ - √

Preemption Procedure
z Sorts the preemptable users by user integrated priority, or sorts the
preemptable RABs by RAB integrated priority
Only the users or RABs with priorities lower than the RAB to be established are
selected
z Selects as many users or RABs as necessary in order to match the resource

needed by the RAB to be established
When the priorities of two users or RABs are the same, the algorithm selects the
user or RAB that can release the most resources
z The RNC releases the resources occupied by the candidate users or RABs
z The requested service directly uses the released resources to access the
network without admission decision


z PreemptAlgoSwitch
Parameter name: Preempt algorithm switch
z PreemptAlgoSwitch
Content: Indicating whether preemption is supported.
Set this parameter through SET UQUEUEPREEMPT.

IAC - Queuing
z After preemption fails, UE can be put into the queue, then
admission attempts are made periodically till maximum queuing
time
z The queuing function is triggered by the heartbeat timer that

equals 500 ms. Each time the timer expires, the RNC selects the
service that meets the requirement to make an admission
attempt

The queuing function takes the following actions:

z The queuing algorithm checks whether the queue is full, that is, whether the number of
service requests in the queue exceeds the queue length, which equals 5.
z The queuing algorithm decides whether to put the request into the queue, as described in
the following table.
If the queue is... Then the queuing algorithm...
z Stamps this request with the request time (T_request).

Not full z Puts this request into the queue.
z Starts the heartbeat timer if it is not started.
Checks whether the integrated priority of any existing request

is lower than that of the new request.
z If yes, then the queuing algorithm:
- Checks the queuing time of each request. The algorithm

removes the request with the longest queuing time from the
Full queue.
- Stamps the new request with the request time (T_request)
and then puts it into the queue.
- Starts the heartbeat timer if it is not started.
z If no, then the queuing algorithm rejects the new request
directly.
z After the heartbeat timer expires, the queuing algorithm performs resource-based
admission attempts as follows:
Rejects the request if the queuing time of the request, Telapsed, is longer than the
maximum queuing time (MaxQueueTimeLen). Here, Telapsed is equal to the

current time minus the request time (T_request).
Selects the request with the highest integrated priority for a resource-based
admission attempt.
If more than one service has the highest integrated priority, the RNC selects the
request with the longest queuing time for a power-based admission attempt.
If the attempt is successful, the heartbeat timer is restarted for the next processing.
If the attempt fails, the queuing algorithm proceeds as follows:
Puts the service request back into the queue with the request time
(T_request) unchanged for the next attempt.
Selects the request with the longest queuing time from the rest and makes
another attempt until a request is accepted or all requests are rejected.


z QueueAlgoSwitch
Parameter name: Queue algorithm switch
z MaxQueueTimeLen
Parameter name: Max queuing time length
z QueueAlgoSwitch
Content: Indicating whether queue is supported. When a user initiates a call, if cell
resources are insufficient and the user is queue supportive, the RNC tries to
arrange this user to join the queue to increase access success ratio.
z MaxQueueTimeLen
Content: Maximum queue time of users. When a user initiates a call, it joins the
queue due to cell resource insufficiency. This parameter defines the maximum
length of time required for queuing of a user. If cell resources are still insufficient
after expiration, access fails.
Value range: 1~60
Physical unit: s
z Set these parameters through SET UQUEUEPREEMPT.

IAC - Low-Rate Access of the PS BE

Service
z Low-rate access means access from the DCH at 0 kbit/s, FACH,
or enhanced FACH (E-FACH)
z Low-rate access is used in the following scenarios:

RAB setup
Hard handover or relocation
z If the PS_BE_EXTRA_LOW_RATE_ACCESS_SWITCH subparameter of the PsSwitch

parameter is set to 1, the PS BE service can access the target cell at a low rate in the case
of a preemption or queuing failure to increase the access success rate.
z After an appropriate access action is determined, the service attempts to access the
network.
If the action of access from the DCH at 0 kbit/s is determined, the service attempts
to access the network at 0 kbit/s for traffic and at the normal rate for signaling.
If the action of access from the FACH/E-FACH is determined, the service attempts
to access the network from the FACH/E-FACH.

If the attempt fails, this service is rejected.
z For the service that accesses the network at 0 kbit/s, the ZeroRateUpFailToRelTimerLen
timer is started after the service rate fails to increase for the first time. If the rate fails to
increase even when the timer expires, the service is released, and the connection is also
released for a single service.


z PsSwitch-PS_BE_EXTRA_LOW_RATE_ACCESS_SWITCH
Parameter name: PS rate negotiation switch for low rate access
z ZeroRateUpFailToRelTimerLen
Parameter name: Release 0 kbit/s Timer length for failed to rate up
z PsSwitch-PS_BE_EXTRA_LOW_RATE_ACCESS_SWITCH
Content: When the switch is on, access at a rate of 0 kbit/s or on the FACH is
determined according to the current connection state of the RRC if the PS BE

admission and the later preemption and queuing fail.
z ZeroRateUpFailToRelTimerLen
Content: For the PS BE service at a rate of 0 kbit/s, this parameter is used for the
rate upsizing for DCCC triggered by event 4A. Unsuccessful rate upsizing indicates
that the resources are insufficient in the cell. The service may run at a rate of 0
kbit/s for a long time. If the timer is started, the 0 kbit/s service of the UE is
released after the timer expires. If the length is set to 0, the timer is not started.
Physical unit: s
Set this parameter through SET UCOIFTIMER.

IAC for Emergency Calls

z RRC connection setup process of emergency calls:
No admission on power resource
Admission is successful if the current remaining hard resources are

sufficient
If the hard resource admission fails preemption is performed
regardless of the preemption switch
z Compared with the RRC connection setup process of ordinary services, the RRC connection
setup process of emergency calls incorporates the preemption due to hard resource-based
admission failure. Hard resources include code, Iub, and CE resources.
z To guarantee a successful admission of an emergency call, the RNC does not perform RRC
redirection for service steering.
z In the case of power-based admission, the emergency call is admitted regardless of
whether the CAC function is enabled or not.
z In the case of hard resource-based admission, the emergency call is admitted if the current
remaining resources are sufficient for RRC connection setup. If the admission fails,
preemption is performed regardless of whether the preemption is enabled or not. The
emergency call that triggers preemption has the highest priority. The range of users that
can be preempted is specified by the EmcPreeRefVulnSwitch parameter.
If EmcPreeRefVulnSwitch is set to ON, all non-emergency users that have accessed
the network can be preempted, regardless of the preemption-prohibited attribute

of the users.
If EmcPreeRefVulnSwitch is set to OFF, only the non-emergency users with
preemption-allowed attribute can be preempted.

The principles for selection of specific users to be preempted are the same as those
for ordinary services.

IAC for Emergency Calls (Cont.)

z RAB process of emergency calls:
For power resource admission:
When EMC_UU_ADCTRL is on, power admission fails if the system is in
overload. Otherwise, the admission succeeds
If the CAC algorithm switch is off, the emergency calls are directly
admitted
Admission is successful if the current remaining hard resources are

sufficient
If the hard resource admission fails preemption is performed

regardless of the preemption switch
z Compared with the RAB process of ordinary services, the RAB process of emergency calls
incorporates special processing of resource-based admission and preemption.
z RAB admission of emergency calls:
In case of power resources:
If the CAC function is enabled, regardless of which algorithm is selected,
the admission decision-making is as follows:
a. When the EMC_UU_ADCTRL subparameter of the
NBMCacAlgoSwitch parameter is set to 1, power-based admission
fails if the system is in the overload congestion state. Otherwise,
the admission succeeds.
b. When this subparameter is set to 0, the emergency calls are
directly admitted.
If the CAC function switch is off, the emergency calls are directly admitted.
For hard resources (that is, code, Iub, and CE), the resource-based admission is
successful if the current remaining resources are sufficient for the request.
z Preemption of emergency calls:
If cell resource-based admission fails, preemption is performed regardless of
whether the preempt function is enabled or not. The emergency calls that trigger
preemption have the highest priority. The range of users that can be preempted is
specified by the EmcPreeRefVulnSwitch parameter.


z EmcPreeRefVulnSwitch
Parameter name: Preemptvulnerability for Emergency call switch
z NBMCacAlgoSwitch-EMC_UU_ADCTRL
Parameter name: Cell CAC algorithm switch for UU resource of
emergency call
z EmcPreeRefVulnSwitch
Content: When the switch is enabled, users of emergency call can preempt all the
users of non emergency call. When the switch is disabled, users of emergency call
can only preempt users of non emergency call with the preempted attributes.
Set this parameter through SET UQUEUEPREEMPT.
z NBMCacAlgoSwitch-EMC_UU_ADCTRL
Content: Control power admission for emergency user.

Contents

Load LCC (Load Congestion Control)
100%
section A Overload state: OLC
THOLC
section B
THLDR Basic congestion state: LDR
section C
Normal state
z LCC (Load Congestion Control) consist of LDR (Load Reshuffling) and OLC (Over Load
Control).
z In basic congestion state, LDR will be used to optimize resource distribution, the main rules
is not to affect the feeling of users as possible as we can.
z In overload state, OLC will be used to release overload state quickly, keep system stability
and the service of high priority users.

LDR Principle
z Reason:
When the cell is in basic congestion state, new coming calls could
be easily rejected by system
z Purpose:
Optimizing cell resource distribution
Decreasing load level, increasing admission successful rate
z Triggering:
Power, code, Iub or NodeB credit
z When the usage of cell resource exceeds the basic congestion triggering threshold, the cell
enters the basic congestion state. In this case, Load Reshuffling (LDR) is required to reduce
the cell load and increase the access success rate.
z The basic congestion of a cell can be caused by power resource, code resource, Iub
resource, or NodeB credit resource. For power resource, the RNC performs periodic
measurement and checks whether the cells are congested. For code, Iub, and NodeB
credit resources, the RNC checks whether the cells are congested when resource usage
changes.

LDR Triggering - Power Resource
z Congestion control based on power resource can be enabled through the DL_UU_LDR and
UL_UU_LDR subparameters of the NBMLdcAlgoSwitch parameter.
z The above figure shows the triggering and relieving of basic congestion:
For an R99 cell:
If the current UL/DL load of the R99 cell is higher than or equal to the
UL/DL LDR trigger threshold (UlLdrTrigThd or DlLdrTrigThd) for 1,000 ms,
the cell is in the basic congestion state, and the related load reshuffling
actions are taken.
If the current UL/DL load of the R99 cell is lower than the UL/DL LDR relief

threshold (UlLdrRelThd or DlLdrRelThd) for 1,000 ms, the cell enters the
normal state again.
For an HSPA cell:
In the uplink, the basic congestion decision is based on the comparison
between the UL LDR trigger threshold (UlLdrTrigThd) and the
uncontrollable load of the cell.
In the downlink, the basic congestion decision is based on the comparison
between the DL LDR trigger threshold (DlLdrTrigThd) and the sum of the
non-HSPA power and the GBP.

Parameters of LDR
z NBMLdcAlgoSwitch-UL_UU_LDR/DL_UU_LDR
Parameter name: Cell LDC algorithm switch for LDR
Recommended value: OFF, OFF
z UlLdrTrigThd/DlLdrTrigThd
Parameter name: UL/DL LDR trigger threshold
Recommended value: 55%, 70%
z UlLdrRelThd/DlLdrRelThd
Parameter name: UL/DL LDR release threshold
z NBMLdcAlgoSwitch-UL_UU_LDR/DL_UU_LDR
Content: UL/DL UU load reshuffling algorithm. When the cell is heavily loaded in UL/DL, this
algorithm reduces the cell load in UL/DL by using inter-frequency load handover, BE service rate
reduction, uncontrollable real-time service QoS renegotiation and inter-RAT handover as well.
z UlLdrTrigThd/DlLdrTrigThd
Content: If the ratio of UL/DL load of the cell to the uplink/downlink capacity is not lower than this
threshold, the UL/DL load reshuffling function of the cell is triggered. After the basic congestion
state of the cell load is released, the system no longer implements the LDR action. Because the load
fluctuates, the difference between the LDR release threshold and trigger threshold should be higher
than 10%. The lower the LDR trigger and release thresholds are, the easier the system enters the
preliminary congestion status, the harder it is released from this status, the easier the LDR action is
triggered, and the more likely the users are affected. But, the admission success rate becomes higher
since the resources are preserved.
Value range: 0~100
Physical unit: %
Set these parameters through ADD UCELLLDM/ MOD UCELLLDM.
z UlLdrRelThd/DlLdrRelThd
Content: If the ratio of UL/DL load of the cell to the uplink capacity is lower than this threshold, the
UL/DL load reshuffling function of the cell is stopped.
Value range: 0~100
Physical unit: %

LDR Triggering - Code Resource

z Congestion control based on code resource can be enabled
through the CELL_CODE_LDR subparameter of the
NBMLdcAlgoSwitch parameter
z If the SF corresponding to the current remaining code of the

cell is larger than the value of CellLdrSfResThd, code congestion
is triggered and the related load reshuffling actions are taken

Parameters of LDR (Cont.)

z NBMLdcAlgoSwitch-CELL_CODE_LDR
Parameter name: Cell LDC algorithm switch for LDR
z CellLdrSfResThd
Parameter name: Cell LDR SF reserved threshold
z NBMLdcAlgoSwitch-CELL_CODE_LDR
Content: Code reshuffling algorithm. When the cell CODE is heavily loaded, this
algorithm reduces the cell CODE load by using BE service rate reduction and code
tree reshuffling.
z CellLdrSfResThd
Content: Cell SF reserved threshold. The code load reshuffling could be triggered
only when the minimum available SF of a cell is higher than this threshold. The
lower the code resource LDR trigger threshold is, the easier the downlink code
resource enters the initial congestion status, the easier the LDR action is triggered,
and the easier the subscriber perception is affected. But a lower code resource LDR
trigger threshold causes a higher admission success rate because the resource is
reserved.
Value range: SF4(SF4), SF8(SF8), SF16(SF16), SF32(SF32), SF64(SF64),
SF128(SF128), SF256(SF256)
Physical value range: SF4, SF8, SF16, SF32, SF64, SF128, SF256
Set this parameter through ADD UCELLLDR/ MOD UCELLLDR.

LDR Triggering - Iub Resource

z Congestion control based on Iub resource can be enabled
through the IUB_LDR subparameter of the
NodeBLdcAlgoSwitch parameter
z Iub congestion control in both the uplink and downlink is

NodeB-oriented. So for the basic congestion caused by Iub
resource, all UEs under the NodeB are the objects of related
LDR actions
z For a path, the following congestion-related parameters are applicable:

Congestion detection parameters:
FWDCONGBW
BWDCONGBW
The default values of the two parameters are 0, which indicates that no congestion
detection will be performed. If the parameters are set to values other than 0, TRM
performs congestion detection according to the settings.
Congestion resolving parameters:
FWDCONGCLRBW
BWDCONGCLRBW

These two parameters are used to determine whether the congestion is resolved.
z Assume that the forward parameters of a port for congestion detection are defined as
follows:
Configured bandwidth: AVE
Forward congestion threshold: CON
Forward congestion resolving threshold: CLEAR (Note that CLEAR is greater than
CON.)
Used bandwidth: USED
z Then, the mechanism of congestion detection for the port is as follows:

Congestion occurs on the port when CON + USED ≥ AVE.
Congestion disappears from the port when CLEAR + USED < AVE.


z NodeBLdcAlgoSwitch-IUB_LDR
Parameter name: NodeB LDC algorithm switch for LDR
z NodeBLdcAlgoSwitch-IUB_LDR
Content: When the NodeB Iub load is heavy, users are assembled in priority order
among all the NodeBs and some users are selected for LDR action (such as BE
service rate reduction) in order to reduce the NodeB Iub load.

LDR Triggering – NodeB Credit

Resource
z The basic congestion caused by NodeB credit resource is of the
following types:
Type A: Basic congestion at local cell level
Type B: Basic congestion at local cell group level (if any)
Type C: Basic congestion at NodeB level
z The switches of NodeB credit LDR:

Algorithm Load Control Algorithm Switch LDC Algorithm Switch
Type A LC_CREDIT_LDR_SWITCH CELL_CREDIT_LDR
Type B LCG_CREDIT_LDR_SWITCH LCG_CREDIT_LDR
Type C NODEB_CREDIT_LDR_SWITCH NODEB_CREDIT_LDR

z The threshold of NodeB credit LDR:
Type A: If the cell UL/DL current remaining SF (mapped to credit resource) is higher
than UlLdrCreditSfResThd or DlLdrCreditSfResThd (set through the ADD UCELLLDR

command), credit congestion at cell level is triggered and related load reshuffling
actions are taken in the current cell.
Type B and C: If the cell group or NodeB UL/DL current remaining SF (mapped to
credit resource ) is higher than UlLdrCreditSfResThd or DlLdrCreditSfResThd (set

through the ADD UNODEBLDR command), credit congestion at cell group or
NodeB level is triggered and related load reshuffling actions are taken. The range
of LDR actions is the same as the first type, but the range of UEs to be sorted by
priority is different. All the UEs in the normal cells that belong to the cell group or
NodeB will be sorted.


Parameter Parameter name Recommended value
Type A:
Cell LDC algorithm switch for LDR OFF
CELL_CREDIT_LDR
Type A:
UL LDR credit SF reserved threshold SF8
UlLdrCreditSfResThd
Type A:
DL LDR credit SF reserved threshold SF8
DlLdrCreditSfResThd
Type B:
NodeB LDC algorithm switch for LDR OFF
LCG_CREDIT_LDR
Type C:
NodeB LDC algorithm switch for LDR OFF
NODEB_CREDIT_LDR
Type B/C:
UL LDR credit SF reserved threshold SF8
UlLdrCreditSfResThd
Type B/C:
DL LDR credit SF reserved threshold SF8
DlLdrCreditSfResThd
z Type A: CELL_CREDIT_LDR
z Type A: UlLdrCreditSfResThd/DlLdrCreditSfResThd
Set these parameters through ADD UCELLLDR/ MOD UCELLLDR.
z Type B/C: LCG_CREDIT_LDR/NODEB_CREDIT_LDR

Set these parameters through ADD UNODEBALGOPARA/ MOD
UNODEBALGOPARA.
z Type B/C: UlLdrCreditSfResThd/DlLdrCreditSfResThd
Set these parameters through ADD UNODEBLDR/ MOD UNODEBLDR.


z If the congestion of all resources is triggered in a cell, the congestion
is relieved in order of resource priority for load reshuffling as
configured through the SET ULDCALGOPARA command
z Recommended setting is as follows:
The first priority for load reshuffling (LdrFirstPri) is set to IUBLDR
The second priority for load reshuffling (LdrSecondPri) is set to
CREDITLDR
The third priority for load reshuffling (LdrThirdPri) is set to CODELDR
The fourth priority for load reshuffling (LdrFourthPri) is set to UULDR
z LdrFirstPri/LdrSecondPri/LdrThirdPri/LdrFourthPri
Content: If congestion is triggered by multiple resources such as credit and code at
the same time, the congestion of resources specified in this parameter is processed
with the first priority. IUBLDR refers to processing of LDR action trigged by Iub
bandwidth. CREDITLDR refers to processing of LDR action trigged by credit.
CODELDR refers to processing of LDR action trigged by code. UULDR refers to
processing of LDR action trigged by Uu.
Value range: IUBLDR(Iub load reshuffling), CODELDR(Code load reshuffling),
UULDR(Uu load reshuffling), CREDITLDR(Credit load reshuffling)
Physical value range: IUBLDR, CODELDR, UULDR, CREDITLDR
Set these parameters through SET ULDCALGOPARA.

LDR Procedure
z The RNC periodically takes actions if the basic congestion is detected:
Inter-frequency load handover
Code reshuffling
BE service rate reduction
AMR rate reduction
Inter-RAT load handover in the CS domain
Inter-RAT load handover in the PS domain
Iu QoS renegotiation
MBMS power reduction
z The sequence of LDR actions can be changed through the ADD UCELLLDR command, and
the waiting timer for LDR period is specified by the LdrPeriodTimerLen parameter through
the SET ULDCPERIOD command.
z Whether the users of gold priority are selected by LDR actions is specified by the
GoldUserLoadControlSwitch parameter.

LDR procedure:
Turn on the LDR algorithm switch
Mark "current LDR state = uncongested"
Start sending the LDM congestion indication
Mark "current action = first LDR action"
Clear "selected" mark of all UE LDR actions

Congestion
state indication Wait for congestion indication
Trigger the LDR

period timer Yes No
Current LDR state = congested?
Inter-frequency Yes
Successful?
load handover
No
Code Yes
Successful?
reshuffling Wait for the
No
expiration of the timer
BE rate Yes
Successful?
reduction
No
Keep the
Inter-RAT
action Yes
handover Successful? Mark
sequence in CS domain
No "current action
unchanged
Inter-RAT = successful
and take the Yes
handover Successful? action"
current action
in PS domain
firstly No
AMR rate Yes
Successful?
reduction
No
QoS
Yes
renegotiation Successful?
on Iu interface No
MBMS power Yes
Successful?
reduction
No
No LDR action is taken Mark

or all actions fail "current action = first LDR action"
z As shown in the previous figure, when the system is congested, the inter-frequency load handover
is initiated first.
If the handover succeeds, the algorithm continues to check whether the system is
congested. If the system is still congested, the inter-frequency load handover is initiated
again.
If the handover fails, code reshuffling is performed.
If the code reshuffling succeeds, the algorithm continues to check whether the system is
congested. If the system is still congested, the code reshuffling is initiated again.
If the code reshuffling fails, the next action, that is, BE rate reduction, is taken.
The rest may be deduced by analogy.

z LDR actions intended for different resources:

LDR Actions
Load Handover
Frequency
Inter-
Reduction
BE Rate
Domain
Handover in CS
Inter-RAT
Domain
Handover in PS
Inter-RAT
Reduction
AMR Rate
Renegotiation
Iu QoS
Reshuffling
Code
Reduction
MBMS Power
Resource UL/DL Channel
Power UL DCH √ √ √ √ √ √
HSUPA √ √
DL DCH √ √ √ √ √* √
HSDPA √ √
FACH √*
(MBMS)
Iub UL DCH √ √ √
HSUPA √
DL DCH √ √ √
HSDPA √
FACH
(MBMS)
Code – –
DL DCH √ √ √
HSDPA
FACH
(MBMS)
Credit UL DCH √ √ √ √
HSUPA √ √
DL DCH √ √ √ √
HSDPA
FACH
(MBMS)
z If the downlink power-based admission uses the ENU algorithm, the basic congestion can
also be caused by the ENU. In this situation, LDR actions do not involve AMR rate
reduction or MBMS power reduction, as indicated by the symbol "*" in the previous table.
z For HSUPA services, the CE consumption, which is calculated on the basis of the
Maximum Bit Rate (MBR), can be reduced through rate downsizing. Therefore, the BE
service rate downsizing for HSUPA is applicable only to the relief of CE resource
congestion.
z If the basic congestion of uplink power in an HSPA cell occurs, scheduled HSUPA users
cannot be selected by LDR actions.
z The parameter CodeCongSelInterFreqHoInd can be set so that the inter-frequency
handover can relieve the basic congestion caused by code resource.


z LdrPeriodTimerLen
Parameter name: LDR period timer length
z GoldUserLoadControlSwitch
Parameter name: Gold user load control switch
z LdrPeriodTimerLen
Content: Identifying the period of the LDR execution. When basic congestion
occurs, execution of LDR can dynamically reduce the cell load. The lower the
parameter value is, the more frequently the LDR action is executed, which
decreases the load quickly. If the parameter value is excessively low, an LDR action
may overlap the previous one before the previous result is displayed in LDM. The
higher the parameter value is, the more likely this problem can be prevented. If the
parameter value is excessively high, the LDR action may be executed rarely, failing
to lower the load timely.
Physical unit: s
z GoldUserLoadControlSwitch
Content: Indicates whether gold users involve in the switch of congestion control.
According to the policy set for gold users by operators, if service quality of gold
users should be guaranteed even in resource congestion, the switch should be
disabled. If the switch is enabled, LDR such as rate reduction and handover also
occurs on gold users even in cell resource congestion, which impacts user service
quality. If the switch is disabled, no action is performed on gold users.


z DlLdrFirstAction to DlLdrTenthAction
Parameter name: DL LDR first action to DL LDR tenth action
Recommended value: CodeAdj, InterFreqLDHO, BERateRed
z UlLdrFirstAction to UlLdrEighthAction
Parameter name: UL LDR first action to UL LDR eighth action
Recommended value: InterFreqLDHO, BERateRed
z DlLdrFirstAction to DlLdrTenthAction
Content: Downlink LDR actions.
Value range: NoAct(no action), InterFreqLDHO(inter-freq load handover),
BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-
negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load
handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover),
AMRRateRed(AMR traff rate reduction), MBMSDecPower(MBMS descend power),
CodeAdj(Code adjust), CSInterRatShouldNotLDHO(CS domain inter-rat should not
be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be
load handover)
z UlLdrFirstAction to UlLdrEighthAction
Content: Uplink LDR actions.
Value range: NoAct(no action), InterFreqLDHO(inter-freq load handover),
BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-
negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load
handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover),
AMRRateRed(AMR traff rate reduction), CSInterRatShouldNotLDHO(CS domain
inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain
inter-rat should not be load handover)
z Set these parameters through ADD UCELLLDR/ MOD UCELLLDR.

LDR Actions - Inter-Frequency Load

Handover
z Target cell:
Supporting inter-frequency blind handover
The current load is normal:

Power reason: UlInterFreqHoCellLoadSpaceThd/DlInterFreqHoCellLoadSpaceThd
Code reason: LdrCodeUsedSpaceThd
z Target user:
The UE with the lowest integrated priority
User selection algorithm switch:
NbmLdcBHOUeSelSwitch
The inter-frequency LDR algorithm performs the following steps:

1. The algorithm checks whether cells for inter-frequency blind handover are available. If
available, the algorithm goes to the next step. Otherwise, the action fails, and the
algorithm takes the next action.
2. The algorithm selects the target cell according to the type of resource that causes the
basic congestion:
If the basic congestion is caused by power resource:
The algorithm checks whether the load margin of the target cell is higher than
both UlInterFreqHoCellLoadSpaceThd and DlInterFreqHoCellLoadSpaceThd and
whether the load of the target cell is normal.
If the margin is not higher than the threshold, the action fails, and the algorithm
takes the next action. If there is more than one cell meeting the requirements, the
first one is selected as the blind handover target cell.
The load margin refers to the difference between the load of the target cell and
the basic congestion triggering threshold of the target cell, but not the difference
between the load of the target cell and the load of the current cell.
If the basic congestion is caused by code resource:
Whether there are blind handover target cells meeting the requirements is decided
by the following conditions:
a. The minimum SF of the target cell is not greater than that of the current cell.
b. The difference of code usage between the current cell and the target cell is
greater than LdrCodeUsedSpaceThd.
c. The state of target cell is normal.
If there is no such cell, this action fails and the algorithm takes the next action. If
there is more than one cell meeting the requirements, the first cell is selected as
the blind handover target cell.

3. The algorithm selects the UEs to be handed over according to the setting of
NbmLdcBHOUeSelSwitch:
If NbmLdcBHOUeSelSwitch is set to NBM_LDC_MATCH_UE_ONLY, the algorithm
performs the following steps:
a. Selects the UEs whose service types are supported by the target cell as
candidate UEs.
b. Sorts the candidate UEs whose rates are not higher than the handover
bandwidth thresholds, based on the integrated priority.
c. Selects the UE with the lowest integrated priority for handover.
If NbmLdcBHOUeSelSwitch is set to NBM_LDC_MATCH_UE_FIRST, the algorithm
performs the following steps:
a. Selects the UEs whose service types are supported by the target cell as
candidate UEs.
b. Sorts the candidate UEs whose rates are not higher than the handover
bandwidth thresholds, based on the integrated priority.
If the rates of all the candidate UEs are higher than the handover bandwidth
thresholds, the algorithm performs the following steps:
a. Selects the UEs whose service types are not supported by the target cells as
candidate UEs.
b. Sorts the UEs whose rates are not higher than the handover bandwidth
threshold, based on the integrated priority.
If NbmLdcBHOUeSelSwitch is set to NBM_LDC_ALL_UE, the algorithm performs
the following steps:
a. From the current cell, selects the UEs whose rates are not higher than the
handover bandwidth thresholds, and then sorts them by integrated priority.
b. Selects the UE with the lowest integrated priority for handover.
If multiple UEs have the same lowest integrated priority, the algorithm selects the
one with the lowest rate for handover.
The UL and DL handover bandwidth thresholds are specified by
UlInterFreqHoBWThd and DlInterFreqHoBWThd respectively. Both the thresholds
are considered in the selection of the target UE.
4. After selecting the target cell and the UE, the algorithm takes handover actions according
to the status of the UE and the measurement of the signal quality.


z UlInterFreqHoCellLoadSpaceThd/DlInterFreqHoCellLoadS
paceThd
Parameter name: UL/DL HO load space threshold
z LdrCodeUsedSpaceThd
Parameter name: InterFreq HO code used ratio space threshold
z UlInterFreqHoCellLoadSpaceThd/DlInterFreqHoCellLoadSpaceThd
Content: The inter-frequency neighboring cell could be selected as the destination
of load handover only when its load remaining space is larger than this threshold.
The lower the parameter is, the easier it is to find a qualified target cell for the
blind handover. Excessively small value of the parameter, however makes the
target cell easily enter the congestion status. The higher the parameter is, the more
difficult it is for the inter-frequency blind handover occurs.
Value range: 0~100
Physical unit: %
z LdrCodeUsedSpaceThd
Content: Code resource usage difference threshold. Inter-frequency handover is
triggered when the difference of the resource usage of the current cell and that of
the target cell is greater than this threshold. The smaller this parameter value, the
easier it is to find the qualified target cell for blind handover. Excessively small
values of the parameter, however makes the target cell easily enters the
congestion status. The higher the parameter value, the more difficult it is for the
inter-frequency blind handover occurs, and the easier it is to guarantee the stability
of the target cell.
Value range: 0~100
Physical unit: %


z NbmLdcBHOUeSelSwitch
Parameter name: BHO Select User algorithm switch
Recommended value: NBM_LDC_MATCH_UE_ONLY
z UlInterFreqHoBWThd/DlInterFreqHoBWThd
Parameter name: UL/DL HO maximum bandwidth
Recommended value: 200000bit/s, 200000bit/s
z NbmLdcBHOUeSelSwitch
Content: NBM_LDC_ALL_UE: When inter-frequency blind handover select user occurs, no
need to consider whether target cell support users. NBM_LDC_MATCH_UE_ONLY: When
inter-frequency blind handover select user occurs, only consider users supported by target
cell. NBM_LDC_MATCH_UE_FIRST: When inter-frequency blind handover select user occurs,
first consider users supported by target cell.
Value range: NBM_LDC_ALL_UE(Select all users), NBM_LDC_MATCH_UE_ONLY(Select
users match target cell support only), NBM_LDC_MATCH_UE_FIRST(Select users match
target cell support first)
Physical value range: NBM_LDC_ALL_UE, NBM_LDC_MATCH_UE_ONLY,
NBM_LDC_MATCH_UE_FIRST
z UlInterFreqHoBWThd/DlInterFreqHoBWThd
Content: The UE can be selected to process load handover only when its bandwidth is less
than this threshold. The higher the parameter is, the higher the service rate of the user in
handover is, and the more obviously the cell load is decreased. However, high value of the
parameter gives rise to the fluctuation and congestion of the target cell load. The lower the
parameter is, the smaller amplitude of the load decreases as a result of the inter-frequency
load handover, and the easier it is to maintain the stability of the target cell load.
Physical unit: bit/s

LDR Actions - BE Rate Reduction

z Target RAB:
The RAB with the lowest integrated priority
The current rate is higher than GBR
Number:
UlLdrBERateReductionRabNum/DlLdrBERateReductionRabNum
z The RNC sends a RADIO BEARER RECONFIGURATION message

to the UE
z The BE rate reduction function is controlled by the DCCC algorithm switch. BE rate
reduction can only be performed when the DCCC algorithm is enabled.
z Different from the TF restriction to the OLC function, the BE rate reduction is implemented
by bandwidth reconfiguration. The bandwidth reconfiguration requires signaling
interaction on the Uu interface. This procedure is relatively long.
z In the same environment, different rates have different downlink transmit powers. The
higher the rate, the greater the downlink transmit power. Therefore, the load can be
reduced by bandwidth reconfiguration.
z For HSUPA services, the consumption of CEs is based on the bit rate. The higher the rate,
the more the consumption of CEs. Therefore, the consumption of CEs can be reduced by
bandwidth reconfiguration.
z The LDR algorithm operates as follows:
Based on the integrated priority, the algorithm sorts the RABs in descending order.
The algorithm selects the RABs with the lowest integrated priorities and with the
current rate higher than the GBR specified through the SET UUSERGBR command
for related to the BE services. If the integrated priorities of some RABs are identical,
the RAB with the highest rate is selected. The number of selected RABs is specified
by the UlLdrBERateReductionRabNum or DlLdrBERateReductionRabNum
parameter.
If services can be selected, the action is successful. If services cannot be selected,
the action fails. The algorithm takes the next action.
The reconfiguration is completed as indicated by the RADIO BEARER
RECONFIGURATION message on the Uu interface and through the synchronized
radio link reconfiguration procedure on the Iub interface.


z UlLdrBERateReductionRabNum/DlLdrBERateReductionRa
bNum
Parameter name: UL/DL LDR-BE rate reduction RAB number
z UlLdrBERateReductionRabNum/DlLdrBERateReductionRabNum
Content: Number of RABs selected in a UL/DL LDR BE traffic rate reduction. In the
actual system, this parameter can be set on the basis of the actual circumstances. If
the high-rate subscribers occupy a high proportion, set the parameter to a
comparatively low value. If the high-rate subscribers occupy a low proportion, set
the parameter to a comparatively high value. Because the basic congestion control
algorithm is designed to slowly decrease cell load, you need to set this parameter
to a comparatively low value.
Value range: 1~10

LDR Actions - QoS Renegotiation

z QoS renegotiation function switch:
DRA_IU_QOS_RENEG_SWITCH
z Target RAB:
Number:
UlLdrPsRTQosRenegRabNum/DlLdrPsRTQosRenegRabNum
z The RNC sends a RAB MODIFY REQUEST message to the CN
z Uncontrollable real-time services refer to PS streaming services.

z The QoS renegotiation function for uncontrollable real-time services is set by the
DRA_IU_QOS_RENEG_SWITCH subparameter of the DraSwitch parameter.
z The load can be reduced by adjusting the rates of real-time services through QoS
renegotiation. In 3GPP R5, the RNC initiates the RAB renegotiation procedure through the
RAB MODIFY REQUEST message on the Iu interface. Upon reception of the RAB MODIFY
REQUEST message, the Core Network (CN) sends the RAB ASSIGNMENT REQUEST
message to the RNC for RAB parameter reconfiguration. Based on this function, the RNC
can adjust the rate of real-time services to reduce the load of the current cell.
z The LDR algorithm operates as follows:
Based on the integrated priority, the algorithm sorts the RABs for real-time services
in the PS domain in descending order.

The algorithm selects the RABs with the lowest integrated priorities for QoS
renegotiation. The number of selected RABs is specified by the

UlLdrPsRTQosRenegRabNum or DlLdrPsRTQosRenegRabNum parameter.
The algorithm performs QoS renegotiation for the selected services. The GBR
during the service setup is the minimum rate of the service after the QoS
renegotiation.
The RNC initiates the RAB MODIFY REQUEST message to the CN for the QoS
renegotiation.
If the RNC cannot find an appropriate service for the QoS renegotiation, the action
fails. The algorithm takes the next action.


z DraSwitch-DRA_IU_QOS_RENEG_SWITCH
Parameter name: Dynamic resource allocation switch for IU QoS
RENEQ
z UlLdrPsRTQosRenegRabNum/DlLdrPsRTQosRenegRabNu
m
Parameter name: UL/DL LDR un-ctrl RT Qos re-nego RAB num
z DraSwitch-DRA_IU_QOS_RENEG_SWITCH
Content: When the switch is on and the Iu QoS RENEQ license is activated, the
RNC supports renegotiation of the maximum rate if the QoS of real-time services is
not ensured according to the cell status.
z UlLdrPsRTQosRenegRabNum/DlLdrPsRTQosRenegRabNum
Content: Number of RABs selected in a UL/DL LDR uncontrolled real-time traffic
QoS renegotiation. The target subscribers of this parameter are the PS domain
real-time subscribers. The setting of this parameter is analogous to the setting of
BE service rate reduction subscriber number. Because the number of subscribers
performing QoS renegotiation may be smaller than the value of this parameter, for
example, the candidate subscribers selected for downlink LDR do not meet the
QoS renegotiation conditions, you must leave some margin when setting this
parameter to ensure the success of load reshuffling.
Value range: 1~10

LDR Actions - Inter-RAT Handover

z Target user:
The user with the lowest integrated priority
z Service handover indicator:

HO_TO_GSM_SHOULD_BE_PERFORM
HO_TO_GSM_SHOULD_NOT_BE_PERFORM
GSM cell
WCDMA cell
Inter-RAT handover in the CS/PS domain involves the following actions:

z Inter-RAT Should Be Load Handover in the CS/PS domain:
Based on the integrated priority, the algorithm sorts the UEs with the "service
handover" IE set to "handover to GSM should be performed" in the CS/PS domain
in descending order.
The algorithm selects the UEs with the lowest integrated priorities. The number of
selected UEs is specified by the UlCSInterRatShouldBeHOUeNum or
DlCSInterRatShouldBeHOUeNum parameter for CS domain, and
UlPSInterRatShouldBeHOUeNum or DlPSInterRatShouldBeHOUeNum parameter for
PS domain.
For the selected UEs, the LDR module sends the load handover command to the
inter-RAT handover module to ask the UEs to be handed over to the 2G system.
The handover module decides to trigger the inter-RAT handover, depending on the
capability of the UE to support the compressed mode.
If a UE that satisfies the handover criteria is not found, the algorithm takes the next
action.
z Inter-RAT Should Not Be Load Handover in the CS/PS domain:
The algorithm for this action is the same as that for the action "Inter-RAT Should
Be Load Handover in the CS/PS Domain". The difference is that this action only
involves CS/PS users with the "service handover" IE set to "handover to GSM
should not be performed".
The number of selected UEs is specified by the UlCSInterRatShouldNotHOUeNum
or DlCSInterRatShouldNotHOUeNum parameter for CS domain, and
UlPSInterRatShouldNotHOUeNum or DlPSInterRatShouldNotHOUeNum parameter
for PS domain.

Recommended
value
UlCSInterRatShouldBeHOUeNum UL CS should be HO user number 3
DlCSInterRatShouldBeHOUeNum DL CS should be HO user number 3
UlCSInterRatShouldNotHOUeNum UL CS should not be HO user number 3
DlCSInterRatShouldNotHOUeNum DL CS should not be HO user number 3
UlPSInterRatShouldBeHOUeNum UL PS should be HO user number 1

DlPSInterRatShouldBeHOUeNum DL PS should be HO user number 1
UlPSInterRatShouldNotHOUeNum UL PS should not be HO user number 1
DlPSInterRatShouldNotHOUeNum DL PS should not be HO user number 1

LDR Actions - AMR Rate Reduction

z Target RAB:
Number:
UlLdrAMRRateReductionRabNum/DlLdrAMRRateReductionRabNum
z In uplink:
The RNC sends the TFC CONTROL command to the UE
z In downlink:
The RNC sends the Rate Control Request message through the Iu interface
to the CN
z The action is restricted by the AMRC algorithm switch. This action can only be performed
when the AMRC algorithm is enabled.
z The LDR algorithm operates in the uplink as follows:
rates higher than the GBR for AMR services (conversational). The number of
selected RABs is determined by the UlLdrAMRRateReductionRabNum parameter.
The RNC sends the TFC CONTROL command to the UE to adjust the AMR rate to
the GBR.
If the RNC cannot find an appropriate RAB for the AMR rate reduction, the action

z The LDR algorithm operates in the downlink as follows:
rates higher than the GBR for AMR services (conversational). The number of
selected RABs is specified by the DlLdrAMRRateReductionRabNum parameter.
The RNC sends the Rate Control Request message through the Iu interface to the
CN to adjust the AMR rate to the GBR.

If the RNC cannot find an appropriate RAB for the AMR rate reduction, the action


z UlLdrAMRRateReductionRabNum/DlLdrAMRRateReductio
nRabNum
Parameter name: UL/DL LDR-AMR rate reduction RAB number
z UlLdrAMRRateReductionRabNum/DlLdrAMRRateReductionRabNum
Content: This parameter defines the maximum number of RABs selected in
executing uplink/downlink LDR-AMR voice service rate reduction. If the parameter
value is too high, the LDR action may fluctuate greatly and over control may occur
(the state of basic congestion turns into another extreme--underload). If the
parameter value is too low, the LDR action has a slow response and the effect is
not apparent, affecting the LDR performance.
Value range: 1~10

LDR Actions - Code Reshuffling
z The code reshuffling algorithm operates as follows:

Initializes SF_Cur to CellLdrSfResThd.
Traverses all the subtrees with this SF_Cur at the root node except the subtrees
occupied by common channels and HSDPA channels, and takes the subtrees in
which the number of users is not larger than the value of MaxUserNumCodeAdj as
candidates for code reshuffling.
If such candidates are available, the algorithm goes to step 3.
If no such candidate is available, subtree selection fails. This procedure ends.
Selects a subtree from the candidates according to the setting of LdrCodePriUseInd.
If this parameter is set to TRUE, the algorithm selects the subtree with the largest
code number from the candidates.
If this parameter is set to FALSE, the algorithm selects the subtree with the smallest
number of users from the candidates. In the case that multiple subtrees have the
same number of users, the algorithm selects the subtree with the largest code
number.
Treats each user in the subtree as a new user and allocates code resources to each
user.
Initiates the reconfiguration procedure for each user in the subtree and
reconfigures the channelization codes of the users to the newly allocated code
resources. The reconfiguration procedure on the UU interface is implemented
through the PHYSICAL CHANNEL RECONFIGURATION message and that on the Iub
interface through the RL RECONFIGURATION message.
z The above figure shows an example of code reshuffling. In this example, CellLdrSfResThd is
set to SF8, and MaxUserNumCodeAdj is set to 1.


z CellLdrSfResThd
Parameter name: Cell LDR SF reserved threshold
z MaxUserNumCodeAdj
Parameter name: Max user number of code adjust
z LdrCodePriUseInd
Parameter name: LDR code priority indicator
Recommended value: FALSE
z CellLdrSfResThd
Content: Cell SF reserved threshold. The code load reshuffling could be triggered only when
the minimum available SF of a cell is higher than this threshold. The lower the code
resource LDR trigger threshold is, the easier the downlink code resource enters the initial
congestion status, the easier the LDR action is triggered, and the easier the subscriber
perception is affected. But a lower code resource LDR trigger threshold causes a higher
admission success rate because the resource is reserved.
Value range: SF4(SF4), SF8(SF8), SF16(SF16), SF32(SF32), SF64(SF64), SF128(SF128),
SF256(SF256)
Physical value range:SF4, SF8, SF16, SF32, SF64, SF128, SF256
z MaxUserNumCodeAdj
Content: This parameter specifies the number of users selected in code reshuffling. Code
reshuffling can be triggered only when the number of users on a code is no greater than
the threshold. Code reshuffling has a big impact on the QoS. In addition, the reshuffled
subscribers occupy two code resources during code reshuffling. Thus, the parameter should
be set to a comparatively low value.
Value range: 1~3
z LdrCodePriUseInd
Content: FALSE means not considering the code priority during the code reshuffling. TRUE
means considering the code priority during the code reshuffling. If the parameter is TRUE,
the codes with high priority are reserved during the code reshuffling.
Value range: FALSE, TRUE
Physical value range: FALSE, TRUE

LDR Actions - MBMS Power Reduction

z Target RAB:
The ARP is higher than MbmsDecPowerRabThd
z The RNC sends a COMMON TRANSPORT CHANNEL

RECONFIGURATION REQUEST message to NodeB
z The downlink power load can be reduced by lowering power on MBMS traffic channels.
z The algorithm operates as follows:
The algorithm selects a RAB with the lowest integrated priority and with the
current power higher than the minimum transmit power of the corresponding
MTCH. That is, it selects a RAB of which the ARP value is higher than
MbmsDecPowerRabThd.
The algorithm triggers a reconfiguration procedure to set the power to the
minimum transmit power of the FACH onto which the MTCH is mapped.
The reconfiguration procedure on the Iub interface is implemented through the
COMMON TRANSPORT CHANNEL RECONFIGURATION REQUEST message.


z MbmsDecPowerRabThd
Parameter name: MBMS descend power rab threshold
z MbmsDecPowerRabThd
Content: When the priority of the RAB of MBMS services exceeds this threshold,
reconfigure the MBMS power to the minimum power. The lower the parameter
value is, the bigger the scope for selecting the MBMS services is, the more cell load
is decreased, the more effect there is on the MBMS service. At the same time, the
cell overload is significantly decreased while the impact on the MBMS services
becomes bigger. The higher the parameter value is, the smaller the scope for
selecting the MBMS services is, the less cell load is decreased, the more effect
there is on the MBMS services, and the quality of services with high priority,
however, can be guaranteed. The MBMS service at each rate is set on the basis of
two power levels. The power set for an MBMS service is determined according to
cell load during the service access. In addition, the FACH power of the MBMS
service must be decreased as required in the duration of cell congestion. Some
services with high priority, for example the disaster pre-alert, however, do not
need the coverage shrink caused by cell load. In such a case, you can adjust the
service priority threshold to protect the services with high priority against the
impact of the service access failure and the load control algorithm.
Value range: 1~15

Contents

OLC Principle
z Reason:
In overload congestion state, the system is not stable
z Purpose:
Ensuring the system stability and making the system back to the
normal state as soon as possible
z Triggering:
Power resource and interference
z After the UE access is allowed, the power consumed by a single link is adjusted by the
single link power control function. The power varies with all kinds of factors such as the
mobility of the UE and the changes in the environment. In some situations, the total power
load of the cell can be higher than the target load. To ensure the system stability, Overload
Control (OLC) must be performed.
z OLC can be enabled through the UL_UU_OLC and DL_UU_OLC subparameters of the
NBMLdcAlgoSwitch parameter.

OLC Load Judgment
z The above figure shows the triggering and release of cell power overload:
If the current UL/DL load of an R99 cell is higher than or equal to the UlOlcTrigThd
or DlOlcTrigThd for 1,000 ms, the cell is in the overload state and the related
overload handling action is taken. If the current UL/DL load of the R99 cell is lower
than the UlOlcRelThd or DlOlcRelThd for 1,000 ms, the cell comes back to the
normal state.
The overload triggering and release mechanisms for UL HSPA cells are the same as
those for R99 cells.

Whether a DL HSPA cell is overloaded is estimated according to the sum of the
non-HSPA power and the GBP.

Parameters of OLC
z NBMLdcAlgoSwitch-UL_UU_OLC/DL_UU_OLC
Parameter name: Cell LDC algorithm switch for OLC
Recommended value: OFF, OFF
z UlOlcTrigThd/DlOlcTrigThd
Parameter name: UL/DL OLC trigger threshold
z UlOlcRelThd/DlOlcRelThd
Parameter name: UL/DL OLC release threshold
z NBMLdcAlgoSwitch-UL_UU_OLC/DL_UU_OLC
Content: UL/DL UU overload congestion control algorithm. When the cell is overloaded in UL/DL, this
algorithm reduces the cell load in UL/DL by quick TF restriction or UE release.
z UlOlcTrigThd/DlOlcTrigThd
Content: If the ratio of UL/DL load of the cell to the uplink/downlink capacity is not lower than this
threshold, the UL/DL overload and congestion control function of the cell is triggered. The lower the
OLC trigger threshold is, the easier the system is in the overload status. An excessively low value of
the OLC trigger threshold is very detrimental to the system performance. The lower the OLC release
threshold is, the harder the system releases the overload. The value of the OLC release threshold
should not be much lower than or close to the OLC trigger threshold, or the system state may have
a ping-pong effect. The recommended difference between the OLC release threshold and the OLC
trigger threshold is higher than 10%. It is desirable to set the two parameters a bit higher given that
the difference between OLC trigger threshold and OLC release threshold is fixed.
Value range: 0~100
Physical unit: %
z UlOlcRelThd/DlOlcRelThd
Content: If the ratio of UL/DL load of the cell to the uplink/downlink capacity is lower than this
threshold, the UL/DL overload and congestion control function of the cell is stopped.
Value range: 0~100
Physical unit: %

OLC Procedure
z When the cell is overloaded, the RNC takes one of the following actions in each period
specified by the OlcPeriodTimerLen parameter until the congestion is relieved:
Performing TF control of BE services
Switching BE services to common channels
Adjusting the maximum FACH TX power
Releasing some RABs
z As shown in the previous figure, the OLC procedure is as follows:

When the system is overloaded, the OLC takes the first action to perform TF
control. If the TF control succeeds, the OLC checks whether the system is
overloaded. If yes, the OLC performs TF control again.
If the number of times that TF control is performed exceeds DlOlcFTFRstrctTimes
and the system is still overloaded, the OLC takes the next action to switch BE
services to common channels.
If the TF control fails, the OLC takes the second action to switch BE services to
common channels. If the switching succeeds, the OLC checks whether the system
is overloaded. If yes, the OLC switches BE services to common channels again.
If the switching fails, the OLC takes the third action to adjust the maximum FACH
transmit power. If the adjustment succeeds, the OLC checks whether the system is
overloaded. If yes, the OLC adjusts the power again.
If the adjustment fails, the OLC takes the fourth action to release some RABs.

Parameters of OLC (Cont.)

z OlcPeriodTimerLen
Parameter name: OLC period timer length
Recommended value: 3000, namely 3000ms
z OlcPeriodTimerLen
Content: :Identifying the period of the OLC execution. When overload occurs,
execution of OLC can dynamically reduce the cell load. When setting the
parameter, consider the hysteresis for which the load monitoring responds to the
load change. If the OLC period is excessively long, the system may respond very
slowly to overload. If the OLC period is excessively short, unnecessary adjustment
may occur before the previous OLC action has taken effect, and therefore the
system performance is affected.
Value range:100~86400000
Physical unit: ms

OLC Actions - Performing TF Control of

BE Services
z OLC algorithm for TF control in the downlink:
Select RABs with the lowest integrated priority
The RNC sends the TF control indication message to the MAC
The MAC restricts the TFC selection: TFmax(N+1) = TFmax(N) x
Ratelimitcoeff
z OLC algorithm for TF control in the uplink:

the RNC sends a TRANSPORT FORMAT COMBINATION CONTROL message
to the UE
The UE restricts the TFC selection
For the TF control in the downlink, the OLC algorithm operates as follows:
1. Based on the integrated priority, the algorithm sorts the RABs in descending order.
2. The algorithm selects the following RABs:
DCH RABs with the bit rates higher than DlDcccRateThd for BE services.
RABs with the lowest integrated priorities.
The number of RABs selected is smaller than or equal to DlOlcFTFRstrctRabNum.

3. The RNC sends the TF control indication message to the MAC. Each MAC of the selected
RABs will receive one TF control indication message and will restrict the TFC selection of
the BE services to reduce the data rate step by step.
The MAC restricts the TFC selection according to the following formula:
TFmax(N+1) = TFmax(N) x Ratelimitcoeff
Here:
TFmax(0) is the maximum TB number of the BE service before the service is
selected for TF control.
TFmax(N+1) is the maximum TB number during the period from (T0 +
RateRstrctTimerLen x N) to (T0 + RateRstrctTimerLen x (N + 1)), where T0 is the
time when the MAC receives the TF control indication message.
Ratelimitcoeff is specified by the RateRstrctCoef parameter.
4. If the RNC cannot find an appropriate service for the TF control or the number of times
that TF control is performed exceeds DlOlcFTFRstrctTimes, the action fails. The OLC takes
the next action.

5. If the congestion is relieved, the RNC sends the congestion relief indication to the MAC.
At the same time, the rate recovery timer (RateRecoverTimerLen) is started. When this
timer expires, the MAC increases the data rate step by step.
MAC recovers the TFC selection by calculating the maximum TB number with the formula:
TFmax(N+1) = TFmax(N) x RateRecoverCoeff
Here:
TFmax(0) is the maximum TB number of the BE service before congestion relief
indication is received.
TFmax(N+1) is the maximum TB number during the period from (T1 +
RateRecoverTimerLen x N) to (T1 + (RateRecoverTimerLen x (N + 1)), where T1 is
the time when the MAC receives the congestion relief indication message.
RateRecoverCoeff is specified by the RecoverCoef parameter.
For the TF control in the uplink, the OLC algorithm operates as follows:
1. Based on the integrated priority, the algorithm sorts the DCH RABs in descending order.
2. The algorithm selects the RABs with the lowest integrated priorities and with the rates
higher than UlDcccRateThd. The number of selected RABs is specified by the
UlOlcFTFRstrctRabNum parameter.
3. The RNC sends the TRANSPORT FORMAT COMBINATION CONTROL message to the UE
that accesses the specified service. This message contains the following IEs:
Transport Format Combination Set Identity: defines the available TFC that the UE
can select, that is, the restricted TFC sub-set. It is always the two TFCs
corresponding to the lowest data rate.
TFC Control Duration: defines the period in multiples of 10 ms frames for which
the restricted TFC sub-set is to be applied. It is set to a random value from the
range of 10 ms to 5120 ms, so as to avoid data rate upsizing at the same time.
After the TFC control duration is due, the UE can apply any TFC of TFCS before the
TF control.
4. Each time, the RNC selects a certain number of RABs, which is specified by
UlOlcFTFRstrctRabNum, for TF control. The UE of each selected RAB will receive the
TRANSPORT FORMAT COMBINATION CONTROL message. The number of times that TF
control is performed is specified by UlOlcFTFRstrctTimes.
5. If the RNC cannot find an appropriate service, the OLC performs the next action.

Example of TF Control
z The above figure shows an example of TF control. In this example, the MAC performs TF
control of a downlink 384 kbit/s service, and RateRstrctCoef is set to 0.68. And the time
between point A and point B is specified by the RateRstrctTimerLen parameter.
Before point A, the cell is not in OLC state. The downlink data transfer rate is 384
kbit/s, the corresponding TF is 12 x 336, and TFS is {12 x 336, 8 x 336, 4 x 336, 2
x 336, 1 x 336, 0 x 336}.
At point A, the cell enters OLC state. The RNC selects this RAB for fast TF
restriction. MAC restricts the TFC selection during the period between point A and
point B by calculating the maximum TB number as follows:
TFmax(1) = TFmax(0) x Ratelimitcoeff = 12 x 0.68 = 8.16

Compare 8.16 with the TFS. Then, the maximum TB number is 8.

At point B, the MAC performs further TFC restriction by calculating maximum TB
number as follows:
TFmax(2) = TFmax(1) x Ratelimitcoeff = 8 x 0.68 = 5.44

Compare 5.44 with the TFS. Then, the maximum TB number is 4.

At point C and point D, similar process is followed.


z DlDcccRateThd
Parameter name: Downlink Bit Rate Threshold For DCCC
Recommended value: D64, namely 64Kbit/s
z DlOlcFTFRstrctRabNum
Parameter name: DL OLC fast TF restrict RAB number
z DlOlcFTFRstrctTimes
Parameter name: DL OLC fast TF restrict times
z DlDcccRateThd
Content: For a BE service that has a low maximum rate, the DCCC algorithm is not obviously
effective yet it increases algorithm processing. Thus, the traffic-based DCCC algorithm is applied to
BE services whose maximum DL rate is greater than the threshold.
Physical value range: 8, 16, 32, 64, 128, 144, 256, 384; step: 1
Set this parameter through SET UDCCC.
z DlOlcFTFRstrctRabNum
Content: Selection of RABs of the OLC is based on the service priorities and ARP values and bearing
priority indication. The RAB of low priority is under control. The higher the parameters are, the more
users are involved in fast TF restriction under the same conditions, the quicker the cell load decreases,
and the more user QoS is affected.
Value range: 1~10
Set this parameter through ADD UCELLOLC/ MOD UCELLOLC.
z DlOlcFTFRstrctTimes
Content: After the overload is triggered, the RNC immediately executes OLC by first executing fast TF
restriction. The internal counter is incremented by 1 with each execution. If the number of overloads
does not exceed the OLC action threshold, the system lowers the BE service rate by lowering TF to
relieve the overload. If the number of overloads exceeds the OLC action threshold, the previous
operation has no obvious effect on alleviating the overload and the system has to release users to
solve the overload problem.
Value range: 0~100


z RateRstrctTimerLen/RateRecoverTimerLen
Parameter name: DL TF rate restrict/recover timer length
Recommended value: 3000ms, 5000ms
z RateRstrctCoef/RecoverCoef
Parameter name: DL TF rate restrict/recover coefficient
z RateRstrctTimerLen/RateRecoverTimerLen
Content: These parameters define the downlink data rate restrict/recover timer
length in fast TF restriction. Both of them are effective only to the downlink. The
uplink fast TF restriction is performed by the UE. For the uplink fast TF restriction,
the RNC only delivers a new TFCS and randomly selects a comparatively bigger
time length in the signaling value scope. The UE automatically release the TF
restriction once the time expires.
Physical unit: ms
z RateRstrctCoef/RecoverCoef
Content: These parameters define the downlink OLC fast TF rate restrict/recovery
coefficient. Both of them are effective only to the downlink.

Value range: 1~99/100~200
Physical value range: 0.01~0.99/1~2; step:0.01
Physical unit: %
z Set these parameters through ADD UCELLOLC/ MOD UCELLOLC.


z UlDcccRateThd
Parameter name: Uplink Bit Rate Threshold For DCCC
Recommended value: D64, namely 64Kbit/s
z UlOlcFTFRstrctRabNum
Parameter name: UL OLC fast TF restrict RAB number
z UlOlcFTFRstrctTimes
Parameter name: UL OLC fast TF restrict times
z UlDcccRateThd
Content: For a BE service that has a low maximum rate, the DCCC algorithm is not obviously
effective yet it increases algorithm processing. Thus, the traffic-based DCCC algorithm is applied to
BE services whose maximum UL rate is greater than the threshold.
Physical value range: 8, 16, 32, 64, 128, 144, 256, 384; step: 1
Set this parameter through SET UDCCC.
z UlOlcFTFRstrctRabNum
Content: Selection of RABs of the OLC is based on the service priorities and ARP values and bearing
priority indication. The RAB of low priority is under control. The higher the parameters are, the more
users are involved in fast TF restriction under the same conditions, the quicker the cell load decreases,
and the more user QoS is affected.
Value range: 1~10
z UlOlcFTFRstrctTimes
Content: After the overload is triggered, the RNC immediately executes OLC by first executing fast TF
restriction. The internal counter is incremented by 1 with each execution. If the number of overloads
does not exceed the OLC action threshold, the system lowers the BE service rate by lowering TF to
relieve the overload. If the number of overloads exceeds the OLC action threshold, the previous
operation has no obvious effect on alleviating the overload and the system has to release users to
solve the overload problem.
Value range: 0~100

OLC Actions - Switching BE Services to

Common Channels
z Target user:
Select users with the lowest integrated priority
The users with the DCH or HSPA BE services in PS domain
z Execution:
The RNC sends “RB Reconfiguration” message to UE
The UE makes a response by “RB Reconfiguration Complete”
z For switching BE services to common channels, the OLC algorithm operates as follows:
Based on the integrated priority, the algorithm sorts all the UEs in the PS domain in
descending order.
The algorithm selects the UEs with the lowest integrated priorities. The number of
selected UEs is specified by TransCchUserNum. If the selection fails, the OLC takes
the next action.
The OLC switches the selected UEs to common channels.
z This function is disabled when the TransCchUserNum parameter is set to 0.


z TransCchUserNum
Parameter name: Transfer Common Channel User number
z TransCchUserNum
Content: When the system is overloaded and congested, users on the DCH or
HSPA can be reconfigured to the CCH in order to reduce the cell load and recover
the system. This parameter defines the maximum number of users selected in
executing reconfiguration to the CCH. If the parameter value is too high, the OLC
action may fluctuate greatly and over control may occur (the state of overload and
congestion turns into another extreme--underload). If the parameter value is too
low, the OLC action has a slow response and the effect is not apparent, affecting
the OLC performance.
Value range: 0~10
Set this parameters through ADD UCELLOLC/ MOD UCELLOLC.

OLC Actions - Adjusting the Maximum

FACH TX Power
z Target FACH channel:
During an OLC period, the OLC can adjust the power of only one
FACH. If multiple FACHs meet the conditions, the OLC adjusts
them one by one in different OLC periods
z Execution:
The cell adjusts the maximum FACH TX power:
Pt arg et = Pmax − Delta
z The procedure for adjusting the maximum FACH transmit power is as follows:
Set the maximum FACH transmit power to the target maximum transmit power.
The target maximum transmit power is calculated according to the above formula.
Ptarget is the target maximum transmit power.
Pmax is the maximum FACH transmit power (MaxFachPower).
Delta is the FACH power reduction step (FACHPwrReduceValue).

If the congestion is relieved after the power adjustment, the system starts the
FACH power recovery timer, which is set to 5s. When the timer expires, the
maximum FACH transmit power is increased to the original maximum FACH
transmit power if the system is always in the normal state before the timer expires.


z MaxFachPower
Parameter name: Max transmit power of FACH
z FACHPwrReduceValue
Parameter name: FACH power reduce value
z MaxFachPower
Content: The offset between the FACH transmit power and PCPICH transmit power
in a cell. If MaxFachPower is excessively low, the UE at the cell verge fails to
receive correctly the services and signaling borne over the FACH, resulting in the
influence on the downlink common channel coverage and the cell coverage. If
MaxFachPower is excessively high, other channels are interfered, the downlink
power resources are occupied, and consequently the cell capacity is influenced.
Physical unit: dB
Set this parameter through ADD UFACH.
z FACHPwrReduceValue
Content: This parameter defines the reduce value in reducing FACH power Action.
Value range: 0~30
Physical unit: dB

OLC Actions - Releasing Some RABs

z Target user:
Select RABs with high bit rate, when the integrated priority of
some RABs are identical
z Execution:
The RNC sends “IU RELEASE REQUEST” or “RAB RELEASE REQUEST”
message to CN, and sample call drop counter
z For the release of some RABs in the uplink, the OLC algorithm operates as follows:
Based on the integrated priority, the algorithm sorts all RABs including HSUPA and DCH
services in descending order.
The algorithm selects the RABs with the lowest integrated priorities. If the integrated
priorities of some RABs are identical, it selects the RAB with a higher rate (that is, the
current rate for DCH RAB or the GBR for HSUPA RAB) in the uplink. The number of selected
RABs is specified by UlOlcTraffRelRabNum.
The selected RABs are released directly.
z For the release of some RABs in the downlink, the OLC algorithm operates as follows:
If the SeqOfUserRel parameter is set to USER_REL, then:
Based on the integrated priority, the algorithm sorts all non-MBMS RABs in
descending order.
The algorithm selects the RABs with the lowest integrated priorities. If the
integrated priorities of some RABs are identical, it selects the RAB with a higher
rate (that is, the current rate for DCH RAB or the GBR for HSDPA RAB) in the
downlink. The number of selected RABs is specified by DlOlcTraffRelRabNum.
The selected RABs are directly released.
If all non-MBMS RABs are released but congestion persists in the downlink, MBMS

RABs are selected.

If the SeqOfUserRel parameter is set to MBMS_REL, then:
Based on the ARP, the algorithm sorts all MBMS RABs in descending order.
The algorithm selects the RABs with the lowest integrated priorities. The number of
selected RABs is specified by MbmsOlcRelNum.
The selected RABs are directly released.
If all MBMS RABs are released but congestion persists in the downlink, non-MBMS
RABs are selected.


z UlOlcTraffRelRabNum/DlOlcTraffRelRabNum
Parameter name: UL OLC traff release RAB number
z SeqOfUserRel
Parameter name: Sequence of user release
Recommended value: MBMS_REL
z MbmsOlcRelNum
Parameter name: MBMS services number released
z UlOlcTraffRelRabNum/DlOlcTraffRelRabNum
Content: These parameters define the maximum number of RABs released in
executing uplink/downlink OLC service release.
Value range: 0~10
z SeqOfUserRel
Content: This parameter indicates whether the MBMS service is released first or
user first when the overload occurs.
Value range: MBMS_REL(MBMS service), USER_REL(UE)
Physical value range: MBMS_REL, USER_REL
z MbmsOlcRelNum
Content: This parameter defines the maximum number of MBMS services released
in executing downlink OLC service release.
Value range: 0~8
z Set these parameters through ADD UCELLOLC/ MOD UCELLOLC.

Thank you
www.huawei.com

WCDMA UMTS Load Control Algorithm and Parameters ISSUE1.00

Загружено:

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

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

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

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

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

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

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

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

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

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

WCDMA UMTS Load Control Algorithm and Parameters ISSUE1.00

Загружено:

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

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

WCDMA Load Control Algorithm and Parameters N-1

WCDMA Load Control

Copyright © 2009 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

z The target of load control is to maximize the system capacity

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

 Describe the realization method of load control

 Perform the parameter adjustment of load control

Confidential Information of Huawei. No Spreading Without Permission

2. Load Control Algorithms

Confidential Information of Huawei. No Spreading Without Permission

1.2 Load Measurement

1.3 Priorities Involved in Load Control

Confidential Information of Huawei. No Spreading Without Permission

z Two kinds of capacity in WCDMA system:

 Iub transport resource

 NodeB processing capability (NodeB credit)

z WCDMA network load can be defined by four factors:

 DL OVSF code of a cell.

 DL and UL NodeB processing capability which is defined by NodeB credit.

 Iub transmission bandwidth of a NodeB.

Confidential Information of Huawei. No Spreading Without Permission

Load Control Algorithms

PUC: Potential User Control CAC: Call Admission Control

Confidential Information of Huawei. No Spreading Without Permission

Load Control Algorithms (Cont.)

Confidential Information of Huawei. No Spreading Without Permission

1.2 Load Measurement

1.3 Priorities Involved in Load Control

Confidential Information of Huawei. No Spreading Without Permission

Confidential Information of Huawei. No Spreading Without Permission

Load Measurement Quantities

Confidential Information of Huawei. No Spreading Without Permission

Load Measurement Procedure

Confidential Information of Huawei. No Spreading Without Permission

Load Measurement Procedure (Cont.)

z A is the sampling value of the measurement

z B is the measurement value after layer 1 filtering

z C is the measurement value after layer 3 filtering

z C' is another measurement value (if any) for measurement evaluation

z D is the reported measurement value after measurement evaluation on the

z Layer 1 filtering is not standardized by protocols and it depends on vendor equipment.

 Mn is the new measurement value from the physical layer.

 α = (1/2)k/2, where k is specified by the UlBasicCommMeasFilterCoeff or

Confidential Information of Huawei. No Spreading Without Permission

Measurement Reporting Period Parameter

Measurement Reporting Period Parameter

z Set the above parameters through SET ULDM.

Confidential Information of Huawei. No Spreading Without Permission

Load Measurement Procedure (Cont.)

 Assuming that the reported measurement value is Qn and that the

Function Smooth Window Length Parameter

Confidential Information of Huawei. No Spreading Without Permission

1.2 Load Measurement

1.3 Priorities Involved in Load Control

Confidential Information of Huawei. No Spreading Without Permission

z Three kinds of priorities involved in load control:

 RAB integrated priority

 User integrated priority

Confidential Information of Huawei. No Spreading Without Permission

User priority Gold Silver Copper gold

Downlink 384kbps 128kbps 64kbps

Confidential Information of Huawei. No Spreading Without Permission

Describe the realization method of load control

Perform the parameter adjustment of load control

Iub transport resource

NodeB processing capability (NodeB credit)

DL OVSF code of a cell.

DL and UL NodeB processing capability which is defined by NodeB credit.

Iub transmission bandwidth of a NodeB.

Mn is the new measurement value from the physical layer.

α = (1/2)k/2, where k is specified by the UlBasicCommMeasFilterCoeff or

Assuming that the reported measurement value is Qn and that the

RAB integrated priority

User integrated priority

Traffic Handling Priority (THP, only for interactive services)

Carrier types: HSPA or DCH

Recommended value: ARP

Recommended value: NONE

UE in Cell-FACH, Cell-PCH and URA-PCH

Recommended value: 5, namely 5%

Recommended value: 1800, namely 1800s

Physical value range: 0~100; step: 1

Set this parameter through ADD UCELLPUC/ MOD UCELLPUC.

Recommended value: -2, namely -4dB

Recommended value: 2, namely 4dB

Recommended value: -4, namely -4dB

Recommended value: 4, namely 4dB

Recommended value: -4, namely -4dB

Recommended value: 4 namely 4dB