Load Control Description (2008!05!30)

Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd

RAN

Load Control Description

Issue 01
Date 2008-05-30

Huawei Proprietary and Confidential

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For
any assistance, please contact our local office or company headquarters.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com

Copyright Huawei Technologies Co., Ltd. 2008. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

RAN
Load Control Description Contents

Issue 01 (2008-05-30) Huawei Proprietary and Confidential
i

Contents
1 Load Control Change History..................................................................................................1-1
2 Load Control Introduction .......................................................................................................2-1
3 Load Control Algorithm Overview........................................................................................3-1
3.1 Load Control Workflow................................................................................................................................3-1
3.2 Algorithm Introduction..................................................................................................................................3-3
3.3 Priorities Involved in Load Control...............................................................................................................3-4
3.3.1 User Priority.........................................................................................................................................3-4
3.3.2 RAB Integrate Priority.........................................................................................................................3-5
3.3.3 User Integrate Priority..........................................................................................................................3-6
4 Load Measurement Algorithm................................................................................................4-1
4.1 Measurement Quantities and Procedure........................................................................................................4-1
4.1.1 Major Measurement Quantities............................................................................................................4-1
4.1.2 LDM Procedure ...................................................................................................................................4-1
4.2 Load Measurement Filtering .........................................................................................................................4-2
4.2.1 Filtering on the NodeB Side.................................................................................................................4-2
4.2.2 Smooth Window Filtering on the RNC Side........................................................................................4-3
4.2.3 Reporting Interval ................................................................................................................................4-4
4.2.4 Provided Bit Rate.................................................................................................................................4-4
4.3 Auto-Adaptive Background Noise Update....................................................................................................4-4
5 Potential User Control Algorithm...........................................................................................5-1
6 Intelligent Access Control Algorithm....................................................................................6-1
6.1 IAC Overview...............................................................................................................................................6-1
6.2 RRC Connection Processing .........................................................................................................................6-3
6.2.2 RRC DRD............................................................................................................................................6-4
6.2.3 RRC Redirection..................................................................................................................................6-5
6.3 Rate Negotiation............................................................................................................................................6-5
6.3.1 Maximum Expected Rate Negotiation.................................................................................................6-5
6.3.2 GBR Negotiation for PS Services........................................................................................................6-6
6.3.3 Initial Rate Negotiation........................................................................................................................6-6
6.3.4 Target Rate Negotiation .......................................................................................................................6-7
6.4 RAB Directed Retry Decision.......................................................................................................................6-7
Contents
RAN

ii Huawei Proprietary and Confidential
Issue 01 (2008-05-30)

6.4.1 RAB DRD Overview...........................................................................................................................6-7
6.4.2 Inter-Frequency DRD for Service Steering..........................................................................................6-9
6.4.3 Inter-Frequency DRD for Load Balancing......................................................................................... 6-11
6.4.4 Inter-Frequency DRD ........................................................................................................................6-18
6.4.5 Inter-RAT DRD..................................................................................................................................6-20
6.5 Preemption ..................................................................................................................................................6-22
6.6 Queuing.......................................................................................................................................................6-25
6.7 IAC for Emergency Calls ............................................................................................................................6-26
6.7.1 RRC Connection Process of Emergency Calls...................................................................................6-26
6.7.2 RAB Process of Emergency Calls......................................................................................................6-27
7 Call Admission Control Algorithm........................................................................................7-1
7.1 CAC Overview..............................................................................................................................................7-1
7.2 CAC Based on Code Resource......................................................................................................................7-3
7.3 CAC Based on Power Resource....................................................................................................................7-3
7.3.1 Power Admission Decision Overview .................................................................................................7-3
7.3.2 Signaling Radio Bearer Admission Decision.......................................................................................7-5
7.3.3 Algorithm 1 of Power Admission.........................................................................................................7-5
7.3.4 Algorithm 2 of Power Admission.......................................................................................................7-12
7.3.5 Algorithm 3 of Power Admission.......................................................................................................7-14
7.4 CAC Based on NodeB Credit Resource......................................................................................................7-14
7.4.1 NodeB Credit .....................................................................................................................................7-14
7.4.2 Procedure for NodeB Credit Resource Decision................................................................................7-16
7.5 CAC Based on Iub Interface Resource........................................................................................................7-17
7.6 CAC Based on the Number of HSPA Users ................................................................................................7-17
7.6.1 CAC of HSDPA Users .......................................................................................................................7-17
7.6.2 CAC of HSUPA Users .......................................................................................................................7-17
8 Intra-Frequency Load Balancing Algorithm.........................................................................8-1
9 Load Reshuffling Algorithm...................................................................................................9-1
9.1 Basic Congestion Triggering.........................................................................................................................9-1
9.1.1 Power Resource ...................................................................................................................................9-1
9.1.2 Code Resource .....................................................................................................................................9-2
9.1.3 Iub Resources or Iub Bandwidth..........................................................................................................9-3
9.1.4 NodeB Credit Resource .......................................................................................................................9-3
9.2 LDR Procedure..............................................................................................................................................9-4
9.3 LDR Actions..................................................................................................................................................9-8
9.3.1 Inter-Frequency Load Handover ..........................................................................................................9-8
9.3.2 BE Rate Reduction...............................................................................................................................9-9
9.3.3 Uncontrolled Real-Time QoS Renegotiation .....................................................................................9-10
9.3.4 Inter-RAT Handover in the CS Domain.............................................................................................9-10
9.3.5 Inter-RAT Handover in the PS Domain ............................................................................................. 9-11
9.3.6 AMR Rate Reduction......................................................................................................................... 9-11
RAN
Load Control Description Contents

iii

9.3.7 Code Reshuffling ...............................................................................................................................9-12
9.3.8 MBMS Power Reduction...................................................................................................................9-13
9.3.9 UL and DL LDR Action Combination of a UE..................................................................................9-13
10 Overload Control Algorithm...............................................................................................10-1
10.1 OLC Triggering.........................................................................................................................................10-1
10.2 General OLC Procedure............................................................................................................................10-2
10.3 OLC Actions..............................................................................................................................................10-3
10.3.1 TF Control........................................................................................................................................10-3
10.3.2 Switching BE Services to Common Channel...................................................................................10-6
10.3.3 Release of Some RABs....................................................................................................................10-7
11 Load Control Reference Documents ..................................................................................11-1

RAN
Load Control Description 1 Load Control Change History

1-1

1 Load Control Change History
Load Control Change History provides information on the changes between different
document versions.
Document and Product Versions
Table 1-1 Document and product versions
Document Version RAN Version RNC Version NodeB Version
01 (2008-05-30) 10.0 V200R010C01B051 V100R010C01B049
V200R010C01B040
Draft (2008-03-20) 10.0 V200R010C01B050 V100R010C01B045

There are two types of changes, which are defined as follows:

Feature change: refers to changes in the feature of a specific product version.

Editorial change: refers to changes in information that has already been included, or the
addition of information that was not provided in the previous version.
01(2008-05-30)
This is the document for the first commercial release of RAN10.0.
Compared with draft (2008-03-20) of RAN10.0, issue 01 (2008-05-30) of RAN10.0
incorporates the changes described in the following table.
Change
Type
Change Description Parameter Change
Feature
change
Inter-Frequency DRD for Load Balancing is
optimized. For detailed information, see
6.4.3 Inter-Frequency DRD for Load
Balancing.
UL and DL LDR Action Combination of a
UE is optimized. For detailed information,
see 9.3.9 UL and DL LDR Action
The parameters that are changed
to be non-configurable are listed
as follows:

Cell overload threshold[%]

Cell underload threshold[%]

Time unit of HSDPA need
RAN

1-2 Huawei Proprietary and Confidential
Issue 01 (2008-05-30)

Change
Type
Combination of a UE. pwr meas cycle

Time unit of HSDPA bit rate
meas cycle

Time unit of HSUPA bit rate
meas cycle

DL basic common measure
filter coeff

UL basic common measure
filter coeff

DL CAC moving average
filter length

DL LDR moving average
filter length

Dl MBMS reserved
factor[%]

DL OLC moving average
filter length

DL OLC trigger
hysteresis[10ms]

Max inter-RAT direct retry
number

HSDPA need power filter len

HSDPA bit rate filter len

HSUPA Credit Consume
Type

HSUPA Non-Server cell
interfere factor[%]

HSUPA bit rate filter len

HSDPA bit rate meas
cycle[m]

HSDPA need pwr meas
cycle[m]

HSUPA bit rate meas
cycle[m]

Nonorthogonality factor

Pilot power adjustment
step[0.1dB]

PUC moving average filter
length

LDB moving average filter
length

Queue length

DL TF rate recover
coefficient[%]
RAN

1-3

Change
Type

Load level division
hysteresis[%]

DL basic meas rprt
cycle[10ms]

UL basic meas rprt
cycle[10ms]

HSDPA bit rate meas
cycle[10ms]

HSDPA need pwr meas
cycle[10ms]

HSUPA bit rate meas
cycle[10ms]

UL CAC moving average
filter length

UL LDR moving average
filter length

UL OLC moving average
filter length

DL basic meas rprt cycle[m]

UL basic meas rprt cycle[m]

DL State Trans Hysteresis
threshold[ms]

Time unit for UL basic meas
rprt cycle

Time unit for DL basic meas
rprt cycle

Poll timer length

UL neighbor interference
factor

PUC period timer length

Intra-frequency LDB period
timer length
The added parameters are listed
as follows:

Load balance DRD switch
for DCH

Load balance DRD switch
for HSDPA

Load balance DRD choice

Dl load balance drd power
remain threshold for DCH

Dl load balance drd power
remain threshold for HSDPA

Load balance DRD offset on
RAN

Issue 01 (2008-05-30)

Change
Type
HSDPA

Load balance DRD offset on
DCH

Load balance drd total
power protect threshold
The deleted parameters are listed
as follows:

Power balancing drd switch

DL power Balancing DRD
power threshold for DCH

DL power Balancing DRD
power threshold for HSDPA

Power balancing drd offset
The parameters modified are
listed as follows:

Code balanceing drd switch
is modified to Code balance
drd switch

Minimum SF threshold for
code balanceing drd is
modified to Minimum SF
threshold for code balance
drd

Code occupied rate threshold
for code balancing balance
drd is modified to Code
occupied rate threshold for
code balance balance drd

Preemption Referenc
Preemptvulnerability for
emergency call switch is
modified to
Emergency call switch

DL total nonhsdpa
equivalent user number is
modified to DL total
equivalent user number

DL OLC fast TF restrict data
rate restrict coefficient is
modified to DL TF rate
restrict coefficient

DL OLC fast TF restrict data
rate recover timer length is
modified to DL TF rate
recover timer length
RAN

1-5

Change
Type
Editorial
change
General documentation change:

The RAN Sharing Parameters is removed
because of the creation of RAN10.0
parameter Reference.

The structure is optimized.
None.

Draft (2008-03-20)
This is a draft of the document for the first commercial release of RAN10.0.
Compared with issue 03 (2008-01-20) of RAN6.1, this issue incorporates the changes
described in the following table.
Change
Type
Feature
change
The RAB processing in IAC is optimized.
For detailed information, see 6.1 IAC
Overview.
as follows:

R99 PS separation indicator

R99 CS separation indicator
RAN

Issue 01 (2008-05-30)

Change
Type
The RAB DRD algorithm used in RAB
processing is optimized. For detailed
information, see 6.4 RAB Directed Retry
Decision.
The added parameters are listed as
follows:

Service differential drd
switch

Service priority group
Identity

Service priority of R99 RT
service

Service priority of R99 NRT
service

Service priority of HSPA
service

Service priority of Other
service

Load balancing drd switch

Code balancing drd switch

Dl load balancing drd power
threshold for DCH

Dl load balancing drd power
threshold for HSDPA

Minimum SF threshold for
code balancing drd

Code occupied rate threshold
for code balancing drd
The queuing algorithm used in RAB
processing is optimized. For detailed
information, see 6.6 Queuing.
The parameter Max queuing time
length N (N: 1 to 12) is changed
to the parameter Max queuing
time length.
The description of "Uplink Power
Admission Decision for HSPA Cells" is
added to 7.3.3 Algorithm 1 of Power
Admission.
The added parameters are listed as
follows:

Low Priority HSUPA user
PBR threshold

Equal Priority HSUPA user
PBR threshold

High Priority HSUPA user
PBR threshold
RAN

1-7

Change
Type
Parameter tables in "Algorithm 1 of
Power Admission" are modified. The
table in "Load Control Parameters" is
updated as well. For detailed information,
see 7.3.3 Algorithm 1 of Power
Admission.
as follows:

MBMS Control Switch

The least coverage rate of
MTCH for RAB priority 0

The least coverage rate of
MTCH for RAB priority 15
The description of MBMS power
admission is moved from 7.3.3 Algorithm
1 of Power Admission to MBMS
Description.
None.
General documentation change:
Implementation information has been
moved to a separate document. For
detailed information on how to implement
Load Control, see Configuring Load
Control in RAN Feature Configuration
Guide.
None.
Editorial
change
The description of IAC procession for
emergency call is added, see 6.7 IAC for
Emergency Calls.
The Preemption Referenc
emergency,call switch parameter
is added.

RAN
Load Control Description 2 Load Control Introduction

2-1

2 Load Control Introduction
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.
Through the control of key resources, such as power, downlink channel 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.
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.
Impact

Impact on System Performance
This feature has no impact on system performance.

Impact on Other Features
This feature has no impact on other features.
Network Elements Involved
Table 2-1 shows the Network Elements (NEs) involved in load control.
Table 2-1 NEs involved in load control
UE NodeB RNC MSC Server MGW SGSN GGSN HLR
- - - - -
NOTE:
: not involved
: involved
UE = User Equipment, MSC = Mobile Service Switching Center, MGW = Media Gateway, SGSN =
Serving GPRS Support Node, GGSN = Gateway GPRS Support Node, HLR = Home Location Register

RAN
Load Control Description 3 Load Control Algorithm Overview

3-1

3 Load Control Algorithm Overview
The following lists the contents of this chapter.

Load Control Workflow

Algorithm Introduction

Priorities Involved in Load Control
3.1 Load Control Workflow
Depending on the actual phase of UE access, different load control algorithms are used, as
shown in the following figure.
Figure 3-1 Load Control algorithms in different UE access phases

PUC = Potential User Control, IAC = Intelligent Access Control, CAC = Call Admission Control, LDB
= Load Control Balancing, LDR = Load Reshuffling, OLC = Overload Control
The load control algorithms are applied to the different UE access phases as follows:

Before UE access: Potential User Control (PUC)

During UE access: Intelligent Access Control (IAC) and Call Admission Control (CAC)

After UE access: intra-frequency Load Balancing (LDB), Load Reshuffling (LDR), and
Overload Control (OLC)
In addition, functional load control algorithms vary depending on the load levels of the cell, as
shown in the following figure.
RAN

Issue 01 (2008-05-30)

Figure 3-2 Load control algorithms used on different cell load levels

The following figure shows the thresholds and actions of the load control algorithms.
Figure 3-3 Thresholds and actions of the load control algorithms

TF = Transport Format, BE = Best Effort, AMR = Adaptive Multi Rate, CS = Circuit Switched, PS =
Packet Switched, MBMS = Multimedia Broadcast Multicast Service, Th
LDR
= Load Reshuffling
Threshold, Th
OLC
= Overload Control Threshold
RAN

3-3

3.2 Algorithm Introduction
The load control algorithms are built into the RNC. The input of load control comes from the
measurement information of the NodeB.
Figure 3-4 Load control algorithm in the WCDMA system

Load control has the following algorithms:

Potential User Control (PUC)
The function of PUC is to balance traffic load between inter-frequency cells. The RNC
uses PUC to modify cell selection and reselection parameters, and broadcasts them
through system information. In this way, UEs are led to cells with a light load. The UEs
can be in idle mode, CELL_FACH state, CELL_PCH state, or URA_PCH state.

Intelligent Access Control (IAC)
The function of IAC is to increase the access success rate with the current QoS
guaranteed through rate negotiation, queuing, preemption, and Directed Retry Decision
(DRD).

Call Admission Control (CAC)
The function of CAC is to decide whether to accept resource requests from UEs, such as
access, reconfiguration, and handover requests, depending on the resource status of the
cell.

Intra-frequency Load Balancing (LDB)
The function of intra-frequency LDB is to balance the cell load between neighboring
intra-frequency cells to provide better resource usage.

Load Reshuffling (LDR)
The function of LDR is to reduce the cell load when the available resources for a cell
reach the specified alarm threshold. The purpose of LDR is to increase the access success
rate by using the following actions:
Inter-frequency load handover
Code reshuffling
BE service rate reduction
AMR voice service rate reduction
Uncontrolled real-time traffic QoS renegotiation
CS inter-RAT load handover
PS inter-RAT load handover
MBMS power reduction
RAN

Issue 01 (2008-05-30)

Overload Control (OLC)
The function of OLC is to reduce the cell load rapidly when the cell is overloaded. The
purpose of OLC is to ensure the system stability and the QoS of most UEs in the
following ways:
Restricting the Transport Format (TF) of the BE service
Switching BE services to common channels
Releasing some RABs
Each load control algorithm involves the following three factors: measuring, triggering, and
controlling. Valid measurement is a prerequisite for effective control.
The following table lists the resources that are considered by the different load control
algorithms.
Table 3-1 Resources used by different load control algorithms
Resources Load Control Algorithm
Power Code NodeB Credits Iub Bandwidth
CAC
IAC
PUC
LDB
LDR
OLC
NOTE
: not considered
: considered

3.3 Priorities Involved in Load Control
The priorities involved in load control are user priority, Radio Access Bearer (RAB) integrate
priority, and user integrate priority.
3.3.1 User Priority
There are three levels of user priority (1, 2, and 3), which are denoted as gold (high priority),
silver (middle priority) and copper (low priority) users. The relation between user priority and
Allocation Retention Priority (ARP) is configurable; the typical relation is shown in the
following table.
RAN

3-5

Table 3-2 Typical relation between user priority and ARP
ARP 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User
Priority
ERROR 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3

ARP 15 is always the lowest priority and is not configurable. It corresponds to user priority 3 (copper).
If ARP is not received in messages from the Iu interface, the user priority is regarded as copper.
The levels of user priority are mainly used to provide different QoS for different users, for
example, setting different Guaranteed Bit Rate (GBR) values according to the priority level of
the users for a BE service.
The GBR of BE services are configurable. According to the traffic class, priority level of
users, and carrier type (DCH or HSPA), the different values of GBR are configured through
the SET USERGBR command.
Changes in the mapping between ARP and user priority have an influence on the following
features:

High Speed Downlink Packet Access (HSDPA)

High Speed Uplink Packet Access (HSUPA)

Adaptive Multi Rate (AMR)

AMR-WB

Iub overbooking
3.3.2 RAB Integrate Priority
RAB Integrate Priority is mainly used in load control algorithms.
The values of RAB Integrate Priority are set according to the Integrate Priority Configured
Reference parameter as follows:

If Integrate Priority Configured Reference is set to Traffic Class, the integrate
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 =>
Only for the interactive service of the same ARP value: priority based on Traffic
Handling Priority (THP), that is, THP1 -> THP2 -> THP3 -> ... -> THP14 =>
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 value of the Indicator of Carrier Type Priority parameter.

If Integrate Priority Configured Reference is set to ARP, the integrate priority abides
by the following rules:
ARP: ARP1 -> ARP2 -> ARP3 -> ... -> ARP14 =>
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 =>
RAN

Issue 01 (2008-05-30)

Services of the same ARP, traffic class and THP (only for interactive services): HSPA
or DCH service preferred depending on the value of the Indicator of Carrier Type
Priority parameter.

ARP and THP are carried in the RAB ASSIGNMENT REQUEST message, and they are not
configurable on the RNC LMT.
3.3.3 User Integrate Priority
For multiple-RAB users, the integrate priority of the user is based on the service of the highest
priority. User integrate 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 BE services to CCH are performed
according to the user integrate priority.
RAN
Load Control Description 4 Load Measurement Algorithm

4-1

4 Load Measurement Algorithm
The load control algorithms, such as OLC and CAC, use load measurement values in the
uplink and the downlink. A common Load Measurement (LDM) algorithm is required to
control load measurement in the uplink and the downlink, which makes the algorithm
relatively independent.

Measurement Quantities and Procedure

Load Measurement Filtering

Auto-Adaptive Background Noise Update
4.1 Measurement Quantities and Procedure
The NodeB and the RNC perform measurements and filtering. The statistics obtained after the
measurements and filtering serve as the data input for the load control algorithms.
4.1.1 Major Measurement Quantities
The major measurement objects of the LDM are as follows:

Uplink Received Total Wideband Power (RTWP)

Downlink Transmitted Carrier Power (TCP)

TCP of all codes not used for High Speed Physical Downlink Shared Channel
(HS-PDSCH), High Speed Shared Control Channel (HS-SCCH), E-DCH Absolute Grant
Channel (E-AGCH), E-DCH Relative Grant Channel (E-RGCH) and E-DCH HARQ
Acknowledgement Indicator Channel (E-HICH) transmission. Thats, non-HSPA power.

Provided Bit Rate (PBR) on HS-DSCH

HS-DSCH required power (also called Guaranteed Bit Rate (GBR) required power
(GBP))

Received scheduled Enhanced Dedicated Channel (E-DCH) power share (RSEPS)

E-DCH Provided Bit Rate
4.1.2 LDM Procedure
The following figure shows the LDM procedure.
RAN

Issue 01 (2008-05-30)

Figure 4-1 LDM procedure

The NodeB measures the major measurement quantities and then obtains original
measurement values. After layer 3 filtering on the NodeB side, the NodeB reports the cell
measurement values to the RNC.
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.
4.2 Load Measurement Filtering
For most measurement quantities, the NodeB performs layer 3 filtering of original
measurement values, and the RNC performs smooth filtering of the values reported from the
NodeB. The Provided Bit Rate (PBR) measurement, however, does not use alpha filtering on
the NodeB side.
4.2.1 Filtering on the NodeB Side
The following figure shows the measurement model at the physical layer that is compliant
with 3GPP 25.302.
Figure 4-2 Measurement model at the physical layer

In Figure 4-2:

A is the sampling value of the measurement.

B is the measurement value after layer 1 filtering.
RAN

4-3

C is the measurement value after layer 3 filtering.

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

D is the reported measurement value after measurement evaluation on the conditions of
periodic measurement and event-triggered measurement.
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 with the following formula:

where:

F
n
is the new measurement value after filtering.

F
n-1
is the last measurement value after filtering.

M
n
is the latest measurement value from the physical layer.
= (1/2)
k/2

When is set to 1, that is, k = 0, no layer 3 filtering is performed.
4.2.2 Smooth Window 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 Q
n
and that the size of the smooth window
is N, the filtered measurement value is

Delay susceptibilities of PUC, CAC, LDR, and OLC to common measurement are different.
The LDM algorithm must apply different smooth filter coefficients and measurement periods
to those algorithms; thus, they can get expected filtered values.
The following table lists the smooth window length for different algorithms.
Algorithm Smooth Window Length
PUC 32
CAC 3
LDB 32
LDR 25
OLC 25

RAN

Issue 01 (2008-05-30)

Different from other measurement quantities, GBP measurements have the same smooth window length
in all related algorithms. The filter length for GBP measurement is 1.
4.2.3 Reporting Interval
The NodeB periodically reports each measurement quantity to the RNC. The following table
lists the reporting intervals for the measurement quantities.
Measurement Reporting Interval ( Unit: ms )
RTWP 1000
RSEPS 1000
TCP 200
Non-HSDPA power 200
GBP 1000

4.2.4 Provided Bit Rate
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.
For detailed information about PBR, refer to 3GPP 25.321.
The following table lists the PBR reporting intervals.
Measurement Reporting Interval ( Unit: ms )
HS-DSCH PBR 100
E-DCH PBR 100

On the RNC side, the length of the PBR smooth filter window is 1.
4.3 Auto-Adaptive Background Noise Update
The UL background noise is easily affected by temperature. Auto-adaptive background noise
update is added to the LDM algorithm to ensure that the configured value of the background
noise can constantly represent the real situation.
As the UL background noise is easily affected by temperature, the following has to be
observed:

If the temperature in the equipment room is constant and the background noise changes
little, the background noise does not have to be adjusted after the initial value is set.

If the temperature in the equipment room changes with the outside temperature, the
background noise also changes to a great extent; therefore, it must be updated.
RAN

4-5

Figure 4-3 shows the procedure for updating background noise when the Auto-Adaptive
Background Noise Update Switch is already set to ON:
Figure 4-3 Procedure for updating background noise

1. The time period of the background noise update is specified by setting the Background
Noise Update Start Time and Background Noise Update End Time parameters.
During the period when the background noise update algorithm is applied, background
noise updating is performed if the Auto-Adaptive Background Noise Update Switch
parameter is set to ON.
RAN

Issue 01 (2008-05-30)

2. The measured value of background noise is effective when the current equivalent
number of users in the cell is smaller than the value of the Equivalent User Number
Threshold for Background Noise parameter.
3. The time that one background noise update takes is specified by setting the Background
Noise Update Continuance Time parameter.
4. The discarding threshold of abnormal RTWP during the update is specified by setting
Background Noise Abnormal Threshold. This setting avoids temporary burst
interference and RTWP peak.
5. The variation of the RTWP that triggers the background noise update is specified by
setting the Background Noise Update Trigger Threshold parameter. This setting
avoids frequent updates over the Iub interface.
RAN
Load Control Description 5 Potential User Control Algorithm

5-1

5 Potential User Control Algorithm
In the WCDMA system, the mobility management of the UE in idle or connected mode is
implemented by cell selection and cell reselection. The Potential User Control (PUC)
algorithm controls the cell selection of the potential UE, and prevents an idle UE from
camping on a heavily loaded cell.
Figure 5-1 shows the PUC procedure.
Figure 5-1 PUC procedure

The PUC algorithm is available only after it is enabled, that is, after PUC under the Cell LDC
algorithm switch parameter is set to 1.
The RNC periodically monitors the downlink load of the cell and compares the measurement
results with the configured thresholds Load level division threshold 1 and Load level
division threshold 2, that is, load level division upper and lower thresholds.

If the cell load is higher than the load level division upper threshold plus the load level
division hysteresis which equals 5%, the cell load is considered heavy.

If the cell load is lower than the load level division lower threshold minus the load level
division hysteresis which equals 5%, the cell load is considered light.
Cell load is of three states: heavy, normal, and light, as shown Figure 5-2.
RAN

Issue 01 (2008-05-30)

Figure 5-2 Cell load states

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.
Item Description
Implementation The parameters related to cell selection and cell 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 total TCP of the cell, and the PUC
periodically triggers the following activities:

Assessing the cell load level based on the total TCP

Configuring Sintersearch, Qoffset1(s,n), and Qoffset2(s,n) based on the
cell load level

Updating the parameters of system information SIB3 and SIB11
RAN
Load Control Description 5 Potential User Control Algorithm

5-3

Item Description
Adjustment Based on the characteristics of inter-frequency cell selection and
reselection.

Sintersearch
-
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.

Qoffset1(s,n): applies to R (reselection) rule with CPICH RSCP
-
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 probability of selecting a neighboring cell.

Qoffset2(s,n): applies to R (reselection) rule with CPICH Ec/I0
-
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 probability of selecting a neighboring cell.

Depending on the load status of the current cell, the cell reselection parameters are adjusted.
The configuration of Sintersearch affects the current cell. Its value is related to the load of the
current cell. The following table describes the change of Sintersearch.
Table 5-1 Change of cell reselection parameters according to the load state (1)
Load of Current
Cell
Sintersearch Change of
Sintersearch
Light S'intersearch = Sintersearch + Sintersearch
offset 1

Normal S'intersearch = Sintersearch
Heavy S'intersearch = Sintersearch + Sintersearch
offset 2

: indicates that the parameter value remains unchanged.
: indicates that the parameter value increases.
: indicates that the parameter value decreases.

For detailed information about Sintersearch, see "Cell Reselection" in UE Behaviors in Idle
Mode.
The configuration of Qoffset1 and Qoffset2 affects the neighboring cells. Their values are
related to the load of the current cell and the load of the neighboring cells. The following table
describes the change of Qoffset1 and Qoffset2.
RAN

Issue 01 (2008-05-30)

Table 5-2 Change of cell reselection parameters according to the load state (2)
Neighboring
Cell Load
Current
Cell
Load
Q'offset1 Change of
Q'offset1
Q'offset2 Change of
Q'offset2
Light Light Q'offset1 = Qoffset1 Q'offset2 = Qoffset2
Light Normal Q'offset1 = Qoffset1 Q'offset2 = Qoffset2
Light Heavy Q'offset1 = Qoffset1 +
Qoffset1 offset 1
Q'offset2 = Qoffset2 +
Qoffset2 offset 1

Normal Light Q'offset1 = Qoffset1 Q'offset2 = Qoffset2
Normal Normal Q'offset1 = Qoffset1 Q'offset2 = Qoffset2
Normal Heavy Q'offset1 = Qoffset1 +
Qoffset1 offset 1
Qoffset2 offset 1

Heavy Light Q'offset1 = Qoffset1 +
Qoffset1 offset 2
Qoffset2 offset 2

Heavy Normal Q'offset1 = Qoffset1 +
Qoffset1 offset 2
Qoffset2 offset 2

Heavy Heavy Q'offset1 = Qoffset1 Q'offset2 = Qoffset2

The prerequisite for the changes of the preceding parameters is that these parameters take their default
values.
RAN
Load Control Description 6 Intelligent Access Control Algorithm

6-1

6 Intelligent Access Control Algorithm
The access of a service to the network consists of setup of an RRC connection and an RAB.
The Intelligent Access Control (IAC) algorithm is used to improve the access success rate.
The IAC procedure includes rate negotiation, Call Admission Control (CAC), preemption,
queuing, and Directed Retry Decision (DRD).

IAC Overview

RRC Connection Processing

Rate Negotiation

RAB Directed Retry Decision

6.5 Preemption

Queuing

IAC for Emergency Calls
6.1 IAC Overview
The procedure for the UE access includes the RRC connection setup and RAB setup.
Figure 6-1 shows a typical procedure for service access control.
RAN

Issue 01 (2008-05-30)

Figure 6-1 Service access procedure

As shown in Figure 6-1, the procedure for the UE access includes the procedures for RRC
connection setup and RAB setup. The success in the RRC connection setup is one of the
prerequisites for the RAB setup.

During the RRC connection processing, if resource admission fails, DRD and redirection
apply.

During the RAB processing, the RNC performs the following steps:
1. Performs RAB DRD to select a suitable cell to access, for service steering or load
balancing.
2. Performs rate negotiation according to the service requested by the UE.
3. Performs cell resource admission decision. If the admission is passed, UE access is
granted. Otherwise, the RNC performs the next step.
4. Selects a suitable cell, according to the RAB DRD algorithm, from the cells where no
admission attempt has been made, and then goes to 2. If all DRD admission attempts to
the cells fail, go to the next step.
5. 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.
6. 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.
7. Rejects UE access.
RAN

6-3

After the admission attempts of an HSPA service request fail in all candidate cells, the service falls back
to the DCH. Then, the service reattempts to access the network.
Table 6-1 IAC procedure supported by services
Rate Negotiation DRD Service
Maximum
Expected
Rate
Negotiati
on
GBR Rate
Negotiati
on
Initial
Rate
Negotiati
on
Target
Rate
Negotiati
on
Preemption Queui
ng
Inter-
Frequ
ency
Inter-
RAT
DCH
HSUPA
HSDPA

For detailed information about CAC, see 7 Call Admission Control Algorithm.
6.2 RRC Connection Processing
When a new service accesses the network, an RRC connection must be set up first. If the RRC
connection request is denied, DRD is performed; If DRD also fails, RRC redirection is
performed to direct the UE to an inter-frequency or inter-RAT cell through cell reselection.
Figure 6-2 shows the procedure for RRC connection processing.
RAN

Issue 01 (2008-05-30)

Figure 6-2 RRC connection processing

After the RNC receives the RRC CONNECTION REQUEST message, the CAC algorithm
decides 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. For detailed information about the
admission control, see "7 Call Admission Control Algorithm".

If the RRC connection cannot be set up between the UE and the current cell, the RNC
takes the following actions:
RRC DRD
RRC Redirection
6.2.1 RRC DRD
If the DRD_SWITCH is set to 0, the RRC DRD fails, and RRC redirection is performed. Else,
the RNC performs the following steps:
1. The RNC selects inter-frequency, but intra-band neighboring cells of the current cell.
These neighboring cells are suitable for blind handovers.
2. The RNC generates a list of candidate DRD-supportive inter-frequency cells. The quality
of the candidate cell meets the requirements of inter-frequency DRD:

Where
is the cached CPICH Ec/N0 value included in the RACH
measurement report.
RAN

6-5

is the DRD Ec/N0 Threshold set for the inter-frequency
neighboring cell.
3. 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.
4. If the candidate cell list does not contain any cell, the RRC DRD fails. The RNC
performs the next step, that is, RRC redirection.
6.2.2 RRC Redirection
When the RRC DRD fails, the associated RRC connection fails to be set up if RRC redirect
switch is set to OFF. If RRC redirect switch is set to a value other than OFF, the RNC
performs the following steps when the RRC DRD fails:
1. The RNC selects all inter-frequency but intra-band cells of the local cell.
2. 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.
3. If more than one candidate cell is available, the RNC selects a cell randomly and
redirects the UE to the cell.
4. If no such candidate cell is available,
If RRC redirect switch is set to Only To Inter Frequency, the RRC connection setup
fails.
If RRC redirect switch is set to Allowed To Inter RAT,
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.
6.3 Rate Negotiation
Rate negotiation includes the maximum expected rate negotiation, GBR negotiation, initial
rate negotiation, and target rate negotiation.
For the maximum and initial rates of AMR and AMR-WB voice services in the CS domain,
see "Initial Access Rate of AMRC/AMRC-WB" in Rate Control.
6.3.1 Maximum Expected Rate Negotiation
When setting up, modifying, or admitting a PS service (conversational, streaming, interactive,
or background service), and the 'Alternative RAB Parameter Values' of IE is present in the
RANAP RAB ASSIGNMENT REQUEST or the RELOCATION REQUEST message, the
RNC and the CN negotiate the rate according to the UE capability to obtain the maximum
expected rate while ensuring a proper QoS. For the real-time PS services, Iu QoS negotiation
function is applicable only when the IU_QOS_NEG_SWITCH is enabled.
For the PS BE services, Iu QoS negotiation function is applicable regardless of the
IU_QOS_NEG_SWITCH.
RAN

Issue 01 (2008-05-30)

6.3.2 GBR Negotiation for PS Services
During the setup, modification, or handover of real-time PS services, if the RAB assignment
message includes multiple alternative guaranteed bit rates and the IU_QOS_NEG_SWITCH
is set to 1, the RNC selects the smallest one as the negotiated guaranteed rate and responds to
the CN. If the IE "Type of Alternative Maximum Bit Rate Information" of the message is set
to "unspecified", the negotiated guaranteed rate is zero.
For the PS BE services, GBR negotiation function is applicable regardless of
IU_QOS_NEG_SWITCH, and the negotiated guaranteed rate is zero.
6.3.3 Initial Rate Negotiation
For a non-real-time service in the PS domain, the RNC selects an initial rate to allocate
bandwidth for the service before the cell resource request in following cases:

Setup of a service

UE state transits from CELL_FACH to CELL_DCH
The negotiation is based on the cell load information, which includes:

Uplink and downlink radio bearer status of the cell

Minimum spreading factor supported

HSPA capability
For DCH service, the initial rate is defined as follows:

When the Dynamic Channel Configuration Control (DCCC) function is enabled:
When the RAB downsizing function is enabled (that is, RAB_Downsizing_Switch is
set to 1), the negotiated rate will be available based on cell resource, and is not lower
than GBR.
a. For uplink, the value of the negotiated rate and the value of UL BE traffic Initial
bit rate are compared. The lower value will be used as actual initial rate.
b. For downlink, the value of the negotiated rate and the value of DL BE traffic
Initial bit rate are compared. The lower value will be used as actual initial rate.
If the RAB downsizing function is disabled (that is, RAB_Downsizing_Switch is set
to 0), the actual initial access rate is the value of UL BE traffic Initial bit rate or DL
BE traffic Initial bit rate.

When the Dynamic Channel Configuration Control (DCCC) function is disabled, the
actual initial access rate is the maximum expected rate.
RAB Downsizing
Switch
DCCC
Switch
Actual Initial Access Rate for DCH
ON ON Min(UL/DL BE traffic Initial bit rate, the
negotiated rate based on cell resources)
OFF ON UL/DL BE traffic Initial bit rate
- OFF Maximum expected rate

For HSUPA service, the initial rate is defined as follows:
RAN

6-7

When the HSUPA DCCC function is enabled (that is, DCCC_SWITCH and
HSUPA_DCCC_SWITCH are both set to 1):
When the RAB downsizing function is enabled (that is, RAB_Downsizing_Switch is
set to 1), the negotiated rate will be available based on cell resource, and is not lower
than GBR. The actual initial access rate is the lower one between the negotiated rate
and the value of Initial rate of HSUPA BE traffic.
If the RAB downsizing function is disabled (that is, RAB_Downsizing_Switch is set
to 0), the actual initial access rate is the value of Initial rate of HSUPA BE traffic.

When the HSUPA DCCC function is disabled, the actual initial access rate is the
maximum expected rate.
RAB Downsizing
Switch
HSUPA DCCC
Switch
Actual Initial Access Rate for HSUPA
ON ON Min(Initial rate of HSUPA BE traffic, the
negotiated rate based on cell resources)
OFF ON Initial rate of HSUPA BE traffic
- OFF Maximum expected rate
6.3.4 Target Rate Negotiation
For a non-real-time service in the PS domain, if cell resource admission fails, the RNC
chooses a target rate to allocate bandwidth for the service based on cell resource in following
cases:

Service setup

Soft handover
Based on the status of cell resources, the target rate is determined if the code or CE resource is
insufficient, the available target rate is obtained by matching the remaining resources of the
cell.
The higher value between the obtained available target rate and the GBR of the service is
selected as the target rate.
In the case of soft handover, the actual target rate is the obtained available target rate.
6.4 RAB Directed Retry Decision
RAB Directed Retry Decision (DRD) is used to select a suitable cell for the UE to try an
access.
6.4.1 RAB DRD Overview
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. For
inter-frequency DRD, the service steering and load balancing algorithms are available.
RAN

Issue 01 (2008-05-30)

RAB DRD Basic Procedure
After receiving a Radio Access Network Application Part (RANAP) message RAB
ASSIGNMENT REQUEST, the RNC initiates an RAB DRD procedure to select a suitable
cell for RAB processing during access control.
The basic procedure for RAB DRD is as follows:
1. The RNC performs inter-frequency DRD. According to the purposes of directed retry,
RAB directed retry is of the following types:
Service steering directed retry
For detailed information, see Inter-Frequency DRD for Service Steering.
Load balancing directed retry
For detailed information, see Inter-Frequency DRD for Load Balancing.
2. If all admission attempts of inter-frequency DRD fail, the RNC performs an inter-RAT
DRD.
For detailed information about inter-RAT DRD, see Inter-RAT DRD.
3. If all admission attempts of inter-RAT DRD fail, the RNC selects a suitable cell to
perform preemption and queuing (for selection of the target cell for preemption or
queuing, see Preemption).
For detailed information about preemption and queuing, see Preemption and Queuing,
respectively.
RAB DRD Switches
Whether the DRD action is executable depends on the settings of the basic DRD algorithm
switches. Table 6-2 describes the DRD algorithm switches applicable to different scenarios.
Table 6-2 DRD algorithm switches applicable to different scenarios
Scenario Switch Description
DRD switch DRD_SWITCH This is the primary DRD algorithm
switch. The secondary DRD switches
are valid only when this switch is on.
Combined
services
COMB_SERV_DRD_SWITCH DRD is applicable to combined
services only when this switch is on.
HSDPA
service
HSDPA_DRD_SWITCH DRD is applicable to HSDPA services
only when this switch is on.
HSUPA
service
HSUPA_DRD_SWITCH DRD is applicable to HSUPA services
only when this switch is on.
RAB
modification
RAB_MODIFY_DRD_SWITCH DRD is applicable to RAB
modification only when this switch is
on.
RAN

6-9

Scenario Switch Description
DCCC RAB_DCCC_DRD_SWITCH DRD is applicable to
traffic-volume-based DCCC procedure
or UE state transition only when this
switch is on.
RAB setup RAB_SETUP_DRD_SWITCH DRD is applicable to RAB setup only
when this switch is on.

A DRD action is executable only when all the related switches are on. The switches in Table 6-2 are
basic switches for DRD algorithm, and there are corresponding switches for each type of DRD.
For example, during the RAB setup process of an HSUPA service, DRD can be applied, if necessary,
only when the DRD_SWITCH, RAB_SETUP_DRD_SWITCH, and the HSUPA_DRD_SWITCH
are on.
6.4.2 Inter-Frequency DRD for Service Steering
If the UE requests a service in an area covered by multiple frequencies, the RNC selects the
cell with the highest service priority for UE access, based on the service type of RAB and the
definitions of service priorities in the cells.
The availability of the service steering DRD is defined by the Service differential drd switch
parameter.
Cell Service Priorities Introduction
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.
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 identified by the Service priority group Identity parameter.
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.
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.
Assume that the service priority groups given in the following table are defined on an RNC.
Service
Priority
Group
Identity
Service
Priority of
R99 RT
Service
Service
Priority of R99
NRT Service
Service
Priority of
HSPA Service
Service
Priority of
Other Service
1 2 1 1 0
2 1 2 0 0

RAN

Issue 01 (2008-05-30)

As shown in Figure 6-3, cell B has a higher service priority of the R99 RT service than cell A.
If the UE requests an RT service in cell A, preferably the RNC selects cell B for the UE to
access.
Figure 6-3 Example of inter-frequency DRD for service steering

If the requested service is a combination of multiple services, the RAB with the highest priority is used
when a cell is selected for RAB processing. In addition, the target cell must support all these services.
Service Steering DRD Procedure

This section takes only the service steering DRD into consideration. That is, the load balancing DRD is
regarded as disabled.
Figure 6-4 Service steering DRD procedure

The procedure for the service steering DRD is as follows:
RAN

6-11

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 (see
6.2 RRC Connection Processing).
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 2.
If admission decisions have been made in all the candidate cells, and
a. The service request is an HSPA one, the HSPA request falls back to a DCH one.
Then, the algorithm goes back to 1 to make an admission decision based on R99
service priorities.
b. The service request is a DCH one, the RNC initiates an inter-RAT DRD.
6.4.3 Inter-Frequency DRD for Load Balancing
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.
Load Balancing DRD Overview
Load balancing considers two resources, power, and code.
The availability of load balancing DRD is defined by the associated parameters as follows:

The availability of power-based load balancing DRD for DCH service is defined by the
Load balance DRD switch for DCH parameter.

The availability of power-based load balancing DRD for HSDPA service is defined by
the Load balance DRD switch for HSDPA parameter.

The availability of code-based load balancing DRD is defined by the Code balance drd
switch parameter.
In practice, it is recommended that only either a power-based load balancing DRD or a
code-based load balancing DRD is activated. If both are activated, power-based load
balancing DRD takes precedence over code-based load balancing DRD.
Code-based load balancing DRD is applicable to only R99 services because HSDPA services
use reserved codes.
RAN

Issue 01 (2008-05-30)

Load Balancing DRD Based on Power Resource

Note that only the load balancing DRD procedure is described herein, the service steering DRD is
regarded as disabled.
The following two algorithms are available for power load balancing. If the power load
balancing DRD is enabled, one of them can be used, and the algorithm used is defined by the
Load balance DRD choice parameter.

Algorithm 1: The load balancing DRD is performed according to the cell measurement
values about the DL non-HSDPA power and DL HS-DSCH required power.
For DCH service, the RNC sets up the service on a carrier with a light load of
non-HSDPA power to achieve load balancing among the cells on the different
frequencies.
For HSDPA service, the RNC sets up the service on a carrier with a light load of
HS-DSCH required power to achieve load balancing among the cells on different
frequencies.

Algorithm 2: The load balancing DRD is performed according to the DCH Equivalent
Number of Users (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.
As shown in Figure 6-5:

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.

Cell A has the lighter load of HS-DSCH required power than Cell B .If the UE requests
an HSDPA service in Cell B, preferably, the RNC selects Cell A for the UE to access.
Figure 6-5 Load balancing DRD based on power resource description
Cell A
Cell B
Load of HS-DSCH require powerGBP)
Load of Non-HSDPA power
load
DCH service
HSDPA service

Figure 6-6 shows the procedure for power-based load balancing DRD.
RAN

6-13

Figure 6-6 Load balancing DRD based on power resource procedure

The procedure for power-based load balancing DRD 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 quality of the candidate cell meets the requirements of inter-frequency DRD.
2. If the current cell is not a candidate cell, the RNC selects a cell with the lightest load
from the candidate cells as the target cell.
If the current cell is a candidate cell, go to 3.
3. The RNC determines whether the DL radio load of the current cell is lower than the
power threshold for load balancing DRD (condition 1). Based on the bearer type (DCH
or HSDPA) of the requested service, the RNC selects an appropriate condition.
For the algorithm 1, the condition 1 is as follows:
a. For DCH bearer
( )
, , AMR cutcell non H cutcell non H
Thd P Thd

>
b. For HSDPA bearer
( )
, , total cutcell GBP cutcell H
Thd P Thd >
RAN

Issue 01 (2008-05-30)

For the algorithm 2, the condition 1 is as follows:
a. For DCH bearer
( )
, , AMR cutcell D ENU cutcell non H
Thd P Thd

>

b. For HSDPA bearer
( )
, , ,
/
H uu cutcell H ue cutcell H ue cutcell H
Thd P Thd Thd

>

Where
non H
Thd

is Dl load balance drd power remain threshold for DCH of the current cell.
H
Thd is Dl load balance drd power remain threshold for HSDPA of the current cell.
If... Then...
The condition 1 is met The service tries admission to the current cell. Go to 5.
The condition 1 is not met Go to 4.

4. The RNC selects a target cell from the inter-frequency neighboring cells for UE access.
The RNC determines whether any inter-frequency neighboring cell meets the following
condition (condition 2): Based on the bearer type (DCH or HSDPA) of the requested
service, the RNC selects an appropriate condition as follow:
If the algorithm 1 is used , the condition 2 is as follows:
a. For an HSDPA service
( ) ( )
, , , , , total nbcell GBP nbcell total cutcell GBP cutcell H loadoffset
Thd P Thd P Thd >

( ) ( )
, , , , , total cutcell load cutcell total nbcell load nbcell total loadoffset
Thd P Thd P Thd <

b. For a DCH service
( ) ( )
, , , , , AMR nbcell non H nbcell AMR cutcell non H cutcell D loadoffset
Thd P Thd P Thd

>

( ) ( )
, , , , , total cutcell load cutcell total nbcell load nbcell total loadoffset
Thd P Thd P Thd <

If the algorithm 2 is used ,the condition 2 is as follows:

a. For an HSDPA service
( ) ( )
, , , , , ,
,
/ /
H ue nbcell H ue nbcell H ue nbcell H ue cutcell H ue cutcell H ue cutcell
H loadoffset
Thd P Thd Thd P Thd
Thd

>

b. For an DCH service
RAN

6-15

( ) ( )
, , , , , AMR nbcell D enu nbcell AMR cutcell D enu cutcell D loadoffset
Thd P Thd P Thd

>

Where:
Current cell Inter-frequency
neighboring cell
Description
, total cutcell
Thd
, total nbcell
Thd
DL total power threshold
, GBP cutcell
P
, GBP nbcell
P HS-DSCH required power load (GBP)

Total power load. It is the sum of the
non-HSDPA power and GBP.
, non H cutcell
P

, non H nbcell
P

Non-HSDPA power load
, AMR cutcell
Thd
, AMR nbcell
Thd DL threshold of Conv AMR service
, H ue cutcell
Thd

, H ue nbcell
Thd

Maximum HSDPA user number
, H ue cutcell
P

, H ue nbcell
P

Number of all existing HSDPA users
, D enu cutcell
P

, D enu nbcell
P

Total ENU of all existing DCH services
, H loadoffset
Thd - Load balance DRD offset for HSDPA
, D loadoffset
Thd - Load balance DRD offset for DCH
, total loadoffset
Thd - Load balance drd total power protect
threshold

DL total power threshold and DL threshold of Conv AMR service are described in 7.3.3
Algorithm 1 of Power Admission.
Then, the RNC selects the target cell as follows:

If there is only one inter-frequency neighboring cell that meets the load balancing DRD
conditions, the RNC selects this cell as the target cell. If there are multiple such cells:
For DCH service
a. If the algorithm 1 is used, the RNC selects the cell with the lightest non-HSDPA
load as the target cell.
b. If the algorithm 2 is used, the RNC selects the cell with the lightest load of DCH
ENU as the target cell.
For HSDPA service
a. If the algorithm 1 is used, the RNC selects the cell with the lightest load of
HS-DSCH required power as the target cell.
b. If the algorithm 2 is used, the RNC selects the cell with the lightest load of
HSDPA user as the target cell.
RAN

Issue 01 (2008-05-30)

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
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 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.
Load Balancing DRD Based on Code Resource
The procedure for load balancing DRD based on code resource is similar to that based on
power resource.
Figure 6-7 shows the procedure for selecting a target cell based on code resource.
RAN

6-17

Figure 6-7 Load balancing DRD based on code resource

The procedure is as follows:
1. The RNC determines whether the minimum remaining spreading factor of the current
cell is smaller than Minimum SF threshold for code balance drd.

If the minimum SF is smaller than Minimum SF threshold for code balance drd, the
RNC tries the admission of the service request to the current cell.

If the minimum SF is not smaller than Minimum SF threshold for code balance drd,
the RNC performs the next step.
2. The RNC determines whether the code load of the current cell is lower than Code
occupied rate threshold for code balance drd.

If the code load is lower than Code occupied rate threshold for code balance drd, the
service tries the admission to the current cell.

If the code load is not lower than Code occupied rate threshold for code balance drd,
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 the
minimum SF supported by the current cell, and the difference between the code
resource occupancies of the cell and the current cell is larger than the value of Delta
code occupied rate, 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.
RAN

Issue 01 (2008-05-30)

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.
6.4.4 Inter-Frequency DRD
According to the settings of the service steering DRD and load balancing DRD algorithms,
the RNC takes the associated inter-frequency DRD actions.
Relation Between Service Steering DRD and Load Balancing DRD
When both service steering DRD and load balancing DRD are enabled, the general principles
of inter-frequency DRD are as follows:

Service steering DRD takes precedence over load balancing DRD. That is, preferably
take service priorities into consideration.

To services of the same service priority, load balancing applies.
For example, Universal Terrestrial Radio Access Network (UTRAN) f1, UTRAN f2, UTRAN
f3, and UTRAN f4 in Figure 6-8 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 the Service priority of R99 RT service Parameter
UTRAN f1 3
UTRAN f2 2
UTRAN f3 1
UTRAN f4 1

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 Figure 6-8.
Figure 6-8 Example of inter-frequency DRD

RAN

6-19

Inter-Frequency DRD Procedure
If the UE requests a service in an area covered by multiple frequencies, the RNC selects a
suitable cell for access based on the service priority in each candidate cell and the service type.
In addition, during cell selection, the RNC considers whether service steering DRD and load
balancing DRD are enabled. Figure 6-9 shows the procedure.
Figure 6-9 Inter-frequency DRD

The procedure for inter-frequency DRD is as follows:

If service steering DRD is enabled but load balancing DRD is disabled, as shown in A in
Figure 6-9, the inter-frequency DRD procedure is the service steering DRD procedure.
For detailed information, see Inter-Frequency DRD for Service Steering.

If load balancing DRD is enabled but service steering DRD is disabled, as shown in B in
Figure 6-9, the inter-frequency DRD procedure is the service steering DRD procedure.
For details, refer to Inter-Frequency DRD for Load Balancing.

If both load balancing DRD and service steering DRD are disabled:
1. The UE attempts to access the current cell.
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.
3. If access to any of the candidate cells is rejected, and:
The service request is an HSPA one, the HSPA request falls back to a DCH one. Then,
the algorithm goes back to 1 to retry admission based on R99 service priorities.
The service request is a DCH one, the RNC initiates an inter-RAT DRD.

If both load balancing DRD and service steering DRD are enabled:
RAN

Issue 01 (2008-05-30)

1. The RNC determines the candidate cells to which blind handovers can be performed. A
candidate cell must meet the following conditions:
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 service steering DRD and load balancing DRD:
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. In this case, the RNC follows the same DRD logic as described in
Inter-Frequency DRD for Load Balancing.
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 2 to try this cell.
b. If all candidate cells haven been tried, and:
The service request is an HSPA one, the HSPA request falls back to a DCH one.
Then, the algorithm goes back to 1 to retry admission based on R99 service
priorities.
The service request is a DCH one, the RNC initiates an inter-RAT DRD.
For detailed information about the CAC procedure, see "7 Call Admission Control
Algorithm".
For detailed information about inter-RAT DRD, see Inter-RAT DRD.
For detailed information about inter-frequency blind handover, see Inter-Frequency Handover.
6.4.5 Inter-RAT DRD
When all admission attempts for inter-frequency DRD during RAB processing fail, the RNC
determines whether to initiate an inter-RAT DRD.
Figure 6-10 shows the inter-RAT DRD procedure.
RAN

6-21

Figure 6-10 Inter-RAT DRD procedure

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 the Service Handover Indicator is set to
HO_TO_GSM_SHOULD_BE_PERFORM, the RNC performs 2. Otherwise, the service
request undergoes preemption and queuing.
For detailed information about the Service Handover Indicator parameter, see "Service
Handover Indicator" in Inter-RAT Handover Description.
2. The RNC generates a list of candidate DRD-supportive inter-RAT cells that fulfill the
following requirement:

Where
is the cached CPICH Ec/N0 value included in the RACH
measurement report.
is the DRD Ec/N0 Threshold set for the inter-RAT
neighboring cell.
If the candidate cell list does not include any cell, the service request undergoes
preemption and queuing.
3. The service request then tries admission to a target GSM cell in order of blind handover
priority.
4. If all admission attempts fail or the number of inter-RAT directed retries exceeds 2, the
service request undergoes preemption and queuing.
RAN

Issue 01 (2008-05-30)

For detailed information about inter-RAT handover, see Inter-RAT Handover Description.

The RAN10.0 does not support inter-RAT DRD for RABs of combined services.
The RAN10.0 does not support inter-RAT DRD for R99 PS services.
The RAN10.0 does not support inter-RAT DRD for HSPA services.
6.5 Preemption
Preemption guarantees the success in the access of a higher-priority user by forcibly releasing
the resources of a lower-priority user.
After cell resource admission fails, the RNC performs preemption if the following conditions
are met:

The RNC receives an RAB ASSIGNMENT REQUEST message indicating that
preemption is supported.

The preemption algorithm switch Preempt algorithm switch is set to ON.
Preemption is applicable to the following cases:

Setup or modification of a service

Hard handover or SRNS relocation

UE state transits from CELL_FACH to CELL_DCH
For preemption, the RNC selects a suitable cell according to the settings of the DRD
algorithms. Table 6-3 describes the selection of the target cell for preemption or queuing.
Table 6-3 Selection of the target cell for preemption or queuing
Service
Steering
DRD
Switch
Power-Based
Load
Balancing
DRD Switch
Code-Based
Load
Balancing
DRD Switch
Target Cell for Preemption or
Queuing
ON
ON
The cell with lightest load among the
cells with the highest service priority.
ON
OFF OFF The cell with the highest service priority.
If there are multiple such candidate cells,
the target cell is selected as follows:
If the current cell is one of the candidate
cells, the current cell is selected as the
target cell.
Otherwise, a neighboring cell that
supports blind-handover is selected
randomly from the candidate cells.
RAN

6-23

Service
Steering
DRD
Switch
Power-Based
Load
Balancing
DRD Switch
Code-Based
Load
Balancing
DRD Switch
Target Cell for Preemption or
Queuing
ON
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, the current cell is selected as the
target cell.
Otherwise, a neighboring cell that
supports blind-handover is selected
randomly from the candidate cells.
OFF
OFF OFF Preferably the current cell. If the current
cell does not support the service, a cell is
selected randomly from the cells that
support this service.

Table 6-4 describes the preemption for different types of service on different resources.
Table 6-4 Preemption of different types of service on different resources
Service That can Be Preempted Service Resource
R99
Service
HSUPA
Service
HSDPA
Service
R99 + HSPA
Combined
Service
Code - -
Power -
CE -
R99
service
Iub
bandwidth

Code - - - -
Power -
CE - - - -
Iub
bandwidth
-
HSDPA
service
Number of
users
- -
HSUPA
service
Code - - - -
RAN

Issue 01 (2008-05-30)

Service That can Be Preempted Service Resource
R99
Service
HSUPA
Service
HSDPA
Service
R99 + HSPA
Combined
Service
Power - - -
CE -
Iub
bandwidth
-
HSUPA
service
Number of
users
- -

To enable resource-triggered preemption for MBMS services, the Mbms PreemptAlgoSwitch must be
set to ON.
For detailed information about preemption of MBMS services, see MBMS Description.
The preemption procedure is as follows:
1. The preemption algorithm determines which radio link sets can be preempted. The
algorithm proceeds as follows:
a. Chooses SRNC users first. If no user under the SRNC is available, the algorithm
chooses users under the DRNC.
b. Sorts the pre-emptable users by user integrate priority, or sorts the pre-emptable
RABs by RAB integrate priority.
c. Determines candidate users or RABs.
Only the users or RABs with priorities lower than the RAB to be established are
selected. If the Integrate Priority Configured Reference parameter is set to Traffic
Class and the switch PreemptRefArpSwitch is set to ON, only the ones with higher
ARP and lower priority than the RAB to be established are selected. This applies to
RABs of streaming or BE services.
d. 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 chooses the user or RAB that can release the most resources.

For the preemption triggered for the power reason, the preempted objects can be R99 users, R99 +
HSDPA combined users, or HSDPA RABs.
For the preemption triggered for the Iub bandwidth reason, the preempted objects can only be RABs.
For the preemption triggered for the code or Iub resource reason, only one user can be preempted.
For the preemption triggered for the power or credit resource reason, more than one user can be
preempted.
2. The RNC releases the resources occupied by the candidate users or RABs.
3. The requested service directly uses the released resources to access the network without
admission decision.
RAN

6-25

6.6 Queuing
After the admission of a service fails, the service request is put into a specific queue. Then
admission attempts for the service are made periodically during a defined period of time.
After the cell resource decision fails, the RNC performs queuing if the RNC receives an RAB
ASSIGNMENT REQUEST message indicating the queuing function is supported and Queue
algorithm switch is set to ON.
The queuing algorithm is triggered by the heartbeat timer which equals 500 ms. Each time the
timer expires, the RNC chooses the service that meets the requirement to make an admission
attempt. The specific process of the queuing algorithm is as follows:

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.

The queuing algorithm proceeds as shown in Table 6-5.
Table 6-5 Putting the new request into the queue
If the
queue is...
Then the queuing algorithm...
Not full

Stamps this request with the current time.

Puts this request into the queue.

Starts the heartbeat timer if it is not started.
Full Checks whether there are requests whose integrate priorities are lower than
that of the priority of the new request.

If yes, then the queuing algorithm
- Checks the weights of these requests. If not all weights are the
same, the algorithm rejects the request with the smallest weight
value.
- Stamps the new request with the current time and then puts it into
the queue.
- Starts the heartbeat timer if it is not started.

If no, then the queuing algorithm rejects the new request directly.

After the heartbeat timer expires, the queuing algorithm proceeds as follows:

Rejects the request if the actual waiting time of the request, T
elapsed
, is longer than the
value of the Max queuing time length parameter for the service.

Selects the request with the highest integrate priority for an attempt of resource
allocation.

If more than one service has the same highest integrate priority, the RNC calculates the
weights of all requests in the queue and chooses the request with the greatest weight for
an attempt of resource allocation. The method of calculating the weight of a service
request is described subsequently.

If the attempt is successful, the heartbeat timer is restarted for the next processing upon
expiry of this timer.

If the attempt fails, the queuing algorithm proceeds as follows:
RAN

Issue 01 (2008-05-30)

Puts the service request back into the queue with the time stamp unchanged for the
next attempt.
Chooses the request with the greatest weight from the rest and makes another attempt
until a request is accepted or all requests are rejected.
The queuing weight is calculated with the following formula:
P
queue
= T
elapsed

where

P
queue
is the weight for the queuing service request. The service with the lowest value of
P
queue
undergoes admission attempt.

T
elapsed
is the time in milliseconds that the service request has spent in the queue. The
value of T
elapsed
is calculated by the current time stamp minus the recorded queuing time
stamp of the service request.
6.7 IAC for Emergency Calls
To guarantee successful access of emergency calls, the RNC takes special measures for
emergency calls.
6.7.1 RRC Connection Process of Emergency Calls
Compared with the RRC connection process of ordinary services, the RRC connection
process of emergency calls incorporates the preemption due to hard resource admission
failure. Figure 6-11 shows the RRC connection process of emergency calls.
Figure 6-11 RRC connection process of emergency calls

In case of power resources, direct admission is used without considering the CAC
algorithm switch.

In case of hard resources, (that is, code, Iub, and CE), the resource admission is
successful if the current remaining resources are sufficient for the RRC connection.
If the hard resource admission fails, preemption is performed regardless of whether the
preemption switch is on or off. The emergency calls that trigger preemption have the highest
priority. The range of users that can be preempted is defined by the Preemptvulnerability for
emergency call switch parameter.

If this switch 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 this switch is set to OFF, only the non-emergency users with preemption-allowed
attribute can be preempted.
RAN

6-27

The principles for selection of specific users to be preempted are the same as those for
ordinary services. For detailed information, see 6.5 Preemption.
6.7.2 RAB Process of Emergency Calls
Compared with the RAB process of ordinary services, the RAB process of emergency calls
incorporates special processing of resource admission and preemption.
RAB Admission of Emergency Calls
In case of power resources:

If the CAC algorithm switch is on, regardless of which algorithm is selected, the
admission decision-making is as follows:
When EMC_UU_ADCTRL (set through Cell CAC algorithm switch) is on, power
admission fails if the system is in overload congestion state. Otherwise, the admission
succeeds.
When EMC_UU_ADCTRL is off, the emergency calls are directly admitted.

If the CAC algorithm switch is off, the emergency calls are directly admitted.
For hard resources (that is, code, Iub, and CE), the resource admission is successful if the
current remaining resources are sufficient for the request.
Preemption of Emergency Calls
If cell resource admission fails, preemption is performed regardless of whether the preempt
algorithm switch is on or off. The emergency calls that trigger preemption have the highest
priority. The range of users that can be preempted is defined by the Preemptvulnerability for
emergency call switch parameter.

If this switch is on, all non-emergency users that have accessed the network can be
preempted, regardless of the preemption-prohibited attribute of the users.

If this switch is 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. For detailed information, see 6.5 Preemption.
RAN
Load Control Description 7 Call Admission Control Algorithm

7-1

7 Call Admission Control Algorithm
As the access decision procedure of IAC, Call Admission Control (CAC) is used to determine
whether the system resources are sufficient to accept a new user's access request. If the system
resources are sufficient, the new user's access request is accepted; otherwise, the user is
rejected.

CAC Overview

CAC Based on Code Resource

CAC Based on Power Resource

CAC Based on NodeB Credit Resource

CAC Based on Iub Interface Resource

CAC Based on the Number of HSPA Users
7.1 CAC Overview
The CAC algorithm consists of CAC based on power resource, CAC based on code resource,
CAC based on credit resource, CAC based on Iub resource, and CAC based on HSPA user
number.
A CAC procedure contains RRC signaling admission control and RAB admission control.
Figure 7-1 shows the basic procedure for resource admission decision.
RAN

Issue 01 (2008-05-30)

Figure 7-1 Basic procedure for resource admission decision

The admission decision is based on:

Cell available code resource

Cell available power resource

NodeB resource state, that is, NodeB credits (They 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)
A call can be admitted only when all of these resources are available.

Except the mandatory code and Iub resource admission control, the admission control based on any
other resource can be disabled through the ADD CELLALGOSWITCH command.
Some CAC-related switches are available from the Cell CAC algorithm switch parameter.
The power admission switch is available from the Uplink/Downlink CAC algorithm switch
parameter.
RAN

7-3

7.2 CAC Based on Code Resource
When a new service attempts to access the network, code resource admission is mandatory.
Code resource admission is implemented as follows:

For RRC connection setup requests, the code resource admission is successful if the
current remaining code resource is enough for the RRC connection.

For handover services, the code resource admission is successful if the current remaining
code resource is enough for the service.

For other R99 services, the RNC has to ensure that the remaining code does not exceed
the configurable OM threshold (Dl HandOver Credit and Code Reserved SF) after
admission of the new service.
For HSDPA services, the reserved codes are shared by all HSDPA services. Therefore, the
code resource admission is not needed.
For detailed information about HSDPA code allocation, see "HSDPA Code Resource
Management" in HSDPA Description.
7.3 CAC Based on Power Resource
7.3.1 Power Admission Decision Overview
Power admission decision consists of signaling radio bearer admission decision and RAB
admission decision based on algorithm 1, algorithm 2, and algorithm 3.
The following three algorithms are available for power resource admission decision. If the
power resource admission control is enabled, one of them can be used for the admission
decision. The algorithm used is defined by the Uplink/Downlink CAC algorithm switch
parameter.

Algorithm 1: power resource admission decision based on power or interference.
Depending on the current cell load (uplink load factor and downlink transmitted carrier
power) and the access request, the RNC determines whether the cell load will exceed the
threshold or not upon admitting a new call. If yes, the RNC rejects the request. If not, the
RNC accepts the request.

Algorithm 2: power resource admission decision based on the number of equivalent
users.
Depending on the current number of equivalent users and the access request, the RNC
determines whether the number of equivalent users will exceed the threshold or not upon
admitting a new call. If yes, the RNC rejects the request. If not, the RNC accepts the
request.

Algorithm 3: power resource admission decision based on power or interference, but
with the estimated load increment always set to 0.
Depending on the current cell load (uplink load factor and downlink TCP) and the access
request, the RNC determines whether the cell load will exceed the threshold or not, with
the estimated load increment set to 0. If yes, the RNC rejects the request. If not, the RNC
accepts the request.
Figure 7-2 shows the basic procedure for power resource admission decision.
RAN

Issue 01 (2008-05-30)

Figure 7-2 Basic procedure for power resource admission decision

The basic principles of power resource admission decision are as follows:

Four basic load thresholds are used for power resource admission decision. They are:
UL/DL Handover access threshold
UL/DL threshold of Conv AMR service
UL/DL threshold of Conv non_AMR service
UL/DL threshold of other services
With these thresholds, the RNC defines the proportion between speech service and other
services while ensuring handover preference.

Admission control involves uplink and downlink. The admission control switches in the
two directions are independent of each other.

For an intra-frequency handover request, only downlink admission decision is needed.

For a non-intra-frequency handover request, both uplink and downlink decisions are
needed if both uplink CAC and downlink CAC are enabled.

If there is a rate downsizing request, the RNC accepts it directly.
For a rate upsizing request, the RNC makes the decision as shown in Figure 7-2.

For a rejected RRC connection request, the RNC performs DRD or redirection.
For a rejected service request, the RNC performs preemption or queuing according to the
actual situation.
RAN

7-5

7.3.2 Signaling Radio Bearer Admission Decision
To ensure that the RRC connection request is not denied by mistake, tolerance principles are
applied.
The admission decision is made for the following reasons of the RRC connection request:

When power admission depends on power or interference (algorithm 1 and algorithm 3):
For the RRC connection request for the reason of emergency call, detach or
registration, direct admission is used.
For the RRC connection request for other reasons, UL/DL OLC Trigger threshold is
used for admission.
For detailed information about UL/DL OLC Trigger threshold parameter, see 10.1
OLC Triggering.

When power admission is based on the equivalent number of users (algorithm 2):
For the RRC connection request for the reason of emergency call, detach or
registration, direct admission is used.
For the RRC connection request for other reasons, the admission decision is made as
follows:
a. When the OLC switch is on, RRC connection request is rejected when the cell is
in the overload congestion state. If the cell is not in the overload state, the
UL/DL OLC Trigger threshold is used for power admission.
b. When the OLC switch is off, UL/DL OLC Trigger threshold is used for power
admission.
7.3.3 Algorithm 1 of Power Admission
Power admission decision based on algorithm 1 consists of uplink power admission decision
and downlink power admission decision procedures.
Uplink Power Admission Decision Procedure Based on Algorithm 1
Uplink Power Admission Decision for R99 Cells
The following table shows the procedure for uplink power admission decision for R99 cells.
RAN

Issue 01 (2008-05-30)

Figure 7-3 Uplink power admission decision for R99 cells

The procedure for uplink power admission decision for R99 cells is as follows:
1. The RNC obtains the uplink RTWP of the cell and uses the formula

to calculate the current uplink load factor
UL
, where P
N
is the received uplink
Background noise.
2. The RNC calculates the uplink load increment
UL
based on the service request.
3. The RNC uses the following formula to predict the uplink load factor:
UL,predicted
=
UL
+
UL
+
ULcch

In the formula,
ULcch
is the value of the UL common channel load factor, which
defines the factor of UL common channel resources reserved.
4. By comparing the predicted uplink load factor
UL,predicted
with the corresponding
threshold (UL threshold of Conv AMR service, UL threshold of Conv non_AMR
service, UL threshold of other services, or UL Handover access threshold), the RNC
decides whether to accept the access request or not.

The uplink load increment
UL
is determined by the following factors:
The Eb/No of the new incoming call: The uplink load increment is proportional to the value of
Eb/No.
UL neighbor interference factor: The uplink load increment is proportional to the factor.
Active Factor(AF) of the new incoming call: The uplink load increment is proportional to the active
factor. The value of AF varies with the traffic class, priority level of user, and carrier type (DCH or
HSPA).
Uplink Power Admission Decision for HSPA Cells
The power increment of an HSUPA service is related to the Ec/No of the GBR of the service
and the neighboring interference factor and AF of the service. The formula is similar to that
for R99.
RAN

7-7

After the RSEPS measurement is introduced, the UL RTWP is divided into two parts:
controllable part and uncontrollable part. The UL interference generated by E-DCH
scheduling services belongs to the controllable part, whereas the others belong to the
uncontrollable part. The following table shows the uncontrollable part.
Figure 7-4 Uncontrollable part of the UL RTWP

E-DCH scheduling services consists of the following two types:

Type A: all UEs for which this cell is the serving E-DCH cell

Type B: all UEs for which this cell is not the serving E-DCH cell
The method of calculating the uplink load varies with the user type.

The uplink load generated by the type A of E-DCH scheduling services is defined as
follows:
.

The uplink load generated by the type B of E-DCH scheduling services is defined by
, which is fixed to zero
The uplink uncontrollable load is defined as follows:
.
The measure taken by CAC is determined by the actual bearer type and whether the
scheduling mode is used.

Admission of HSUPA Scheduling Services
Since the HSUPA scheduling algorithm consumes additional uplink power resources, the
power load of the WCDMA system is always relatively high. Therefore, the CAC
algorithm combines the PBR-based decision with the total load-based decision to reduce
the number of potential erroneous rejections.
RAN

Issue 01 (2008-05-30)

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.

As shown in the previous figure, the Scheduling Priority Indicator (SPI) of a new
HSUPA user is SPI
New user
.
When the admission of HSUPA scheduling services is implemented, the following
formulas apply:
1.
2.
3.
4.
where
is the Low Priority HSUPA user PBR threshold of the current cell.
is the Equal Priority HSUPA user PBR threshold of the current cell.
is the High Priority HSUPA user PBR threshold of the current cell.
is the value of the UL HS-DPCCH reserve factor parameter, which
defines the factor of UL HS-DPCCH resources reserved.
The RNC admits the HSUPA scheduling services in either of the following cases:
Formula 1, 2, or 3 is fulfilled.
Formula 4 is fulfilled.

Admission of HSUPA Non-Scheduling Services and DCH Services
Uncontrollable interference must be kept within a certain range. The purpose is to ensure
the stability of the system and to prevent non-scheduling services and DCH services
from seizing the resources of HSUPA services. In this regard, the CAC algorithm
combines the uncontrollable partbased decision and the total loadbased decision.
When the admission of HSUPA non-scheduling services or DCH services is
implemented, the following formulas apply:

RAN

7-9

where
is the UL total power threshold of the current cell.

thd
is the cell UL admission threshold for different types of service, (that is, UL
threshold of Conv AMR service, UL threshold of Conv non_AMR service, UL
threshold of other services, or UL Handover access threshold).
The RNC admits the HSUPA Non-Scheduling Services or DCH Services if formulas 1
and 2 are fulfilled.

The IMS signaling service over HSUPA can be directly admitted. If the PBR measurement is deactivated,
the decision formulas that involve PBR are regarded as dissatisfied. If the RSEPS measurement is
deactivated, the admission algorithm automatically changes into algorithm 2. For detailed information
about the scheduling mode of services on HSUPA, see Radio Bearer Description.
Downlink Power Admission Decision Procedure Based on Algorithm 1
Downlink Power Admission Decision for R99 Cells
Figure 7-5 shows the procedure for downlink power admission decision.
Figure 7-5 Downlink power admission decision procedure

The procedure for downlink power admission decision is as follows:
1. The RNC obtains the cell downlink TCP and calculates the downlink load factor
DL
by
dividing the maximum downlink transmit power P
max
by this TCP.
2. The RNC calculates the downlink load increment
DL
based on the service request and
the current load.
3. The RNC uses the following formula to predict the downlink load factor:
RAN

Issue 01 (2008-05-30)

DL,predicted
=
DL
+
DL
+
DLcch

In the formula,
DLcch
is the value of DL common channel load reserved coefficient,
which defines the factor of DL common channel resources reserved.
4. By comparing the downlink load factor
DL,predicted
with the corresponding threshold (DL
threshold of Conv AMR service, DL threshold of Conv non_AMR service, DL
threshold of other services, or DL Handover access threshold), the RNC decides
whether to accept the access request or not.

The downlink load increment
DL
is determined by the following factors:
Eb/No of the incoming new call (The larger the Eb/No, the larger the downlink load increment.)
Non-orthogonality factor (The larger the factor, the larger the downlink load increment.)
Current transmitted carrier power (The larger the power, the smaller the downlink load increment.)
Active factor (AF) of the incoming new call. (The larger the AF, the larger the downlink load
increment.)
Downlink Power Admission Decision for HSPA Cells

Power Increment Estimation for DCH RAB
The power increment estimation for the DCH RAB in the HSPA cell is similar to the
DCH RAB in the R99 cell.

Power Increment Estimation for HSDPA RAB
The power increment estimation for HSDPA RAB P
DL
is made based on GBR, Ec/No,
Non-orthogonality factor, and so on.

Downlink Radio Admission Decision for DCH RAB
When the admission of the DCH RAB is implemented, the following formulas apply:
1.
2.
3.
Where
is the current non-HSDPA power.
is the power reserved for the common channel.
is the cell maximum transmit power.
is the cell DL admission threshold for different types of service,
that is, DL threshold of Conv AMR service, DL threshold of Conv non_AMR
service, DL threshold of other services, or DL Handover access threshold.
is the current downlink transmitted carrier power.
is the threshold of cell DL total power. It is defined by the DL total
power threshold parameter.
is the power requirement for GBR.
is the power reserved for HSUPA downlink control channels
(E-AGCH/E-RGCH/E-HICH).
RAN

7-11

is the maximum available power for HSPA. Its value is associated with the
HSDPA power allocation mode. For detailed information, see HSDPA Power
Resource Management.
The RNC admits the DCH RAB in either of the following situations:
Formulas 1 and 2 are fulfilled.

If the GBP measurement is deactivated, the value of the GBP involved in the decision formulas is
regarded as zero.

Downlink Radio Admission Decision for HSDPA RAB
When the admission of the HSDPA RAB is implemented, the following formulas apply:
1.
2.
3.
4.
5.
Where
is the provided bit rate of all existing streaming services.
is the admission threshold for streaming PBR decision. It is defined
by the Hsdpa streaming PBR threshold parameter.
is the provided bit rate of all existing BE services.
is the admission threshold for BE PBR decision. It is defined by the
Hsdpa best effort PBR threshold parameter.
is the power requirement for GBR.
is the power reserved for HSUPA downlink control channels
(E-AGCH/E-RGCH/E-HICH).
is the maximum available power for HSPA. Its value is associated with the
HSDPA power allocation mode. For detailed information, see "HSDPA Power
Resource Management" in HSDPA Description.
is the current downlink transmitted carrier power.
is the cell maximum transmit power.
is the threshold of cell DL total power, which is defined by the DL total
power threshold parameter.
is the power reserved for the common channel.
is the current non-HSDPA power.
RAN

Issue 01 (2008-05-30)

The RNC admits the HSDPA streaming RAB in any of the following situations:
The RNC admits the HSDPA BE RAB in any of the following situations:

If PS conversational services are carried on HSPA, the services can be treated as streaming services
during admission control.
If the GBP measurement is deactivated, the value of the GBP involved in the decision formulas is
regarded as zero.
If the PBR measurement is deactivated, the decision formulas that involve PBR are regarded as
dissatisfied.

Downlink Radio Admission Decision for HSUPA Control Channels
The power of downlink control channels (E-AGCH/E-RGCH/E-HICH) is reserved by Dl
HSUPA reserved factor. Therefore, the power admission for these channels is not
needed.

Downlink Power Admission Decision for MBMS
For detailed information, see MBMS Description.
When the uplink CAC algorithm or the downlink CAC algorithm uses algorithm 2, the
admission of uplink/downlink power resources uses the algorithm depending on the
equivalent number of users.
Equivalent Number of Users
The 12.2 kbit/s AMR traffic is used to calculate the Equivalent Number of Users (ENU) of all
other services. The 12.2 kbit/s AMR traffic's ENU is assumed to be 1. The ENU calculation of
all other services is related to the following factors:

Cell type, such as urban or suburban

Traffic domain, CS or PS

Coding type, turbo code or 1/2 1/3 convolutional code

Traffic QoS, that is, Block Error Rate (BLER)
Table 7-1 describes the typical ENU of some services.
Table 7-1 Typical equivalent number of users (with activity factor to be 100%)
ENU Service
Uplink for DCH Downlink for DCH HSDPA HSUPA
3.4 kbit/s SIG 0.44 0.42 0.28 1.76
13.6 kbit/s SIG 1.11 1.11 0.74 1.89
RAN

7-13

ENU Service
Uplink for DCH Downlink for DCH HSDPA HSUPA
3.4 + 12.2 kbit/s 1.44 1.42 - -
3.4 + 8 kbit/s (PS) 1.35 1.04 0.78 2.26
3.4 + 16 kbit/s (PS) 1.62 1.25 1.11 2.37
3.4 + 32 kbit/s (PS) 2.15 2.19 1.70 2.60
3.4 + 64 kbit/s (PS) 3.45 3.25 2.79 3.14
3.4 + 128 kbit/s (PS) 5.78 5.93 4.92 4.67
3.4 + 144 kbit/s (PS) 6.41 6.61 5.46 4.87
3.4 + 256 kbit/s (PS) 10.18 10.49 9.36 6.61
3.4 + 384 kbit/s (PS) 14.27 15.52 14.17 9.36

In Table 7-1, for a 3.4 + n kbit/s service of HSDPA or HSUPA,
The 3.4 kbit/s is the rate of the signaling carried on the DCH.
The n kbit/s is the GBR of the service.
Procedure for ENU Resource Decision for Uplink/Downlink
The procedure for ENU resource decision for uplink/downlink is as follows:
1. The RNC obtains the total ENU of all existing users ENU
total
=
all_exist_user
ENU
i
.
2. The RNC gets the ENU of the new incoming user ENU
new
.
3. The RNC uses the formula (ENU
total
+ ENU
new
)/ENU
max
to forecast the ENU load, where
ENU
max
is the configured maximum ENU (UL total equivalent user number or DL
total equivalent user number).
4. By comparing the forecasted ENU load with the corresponding threshold (UL/DL
threshold of Conv AMR service, UL/DL threshold of Conv non_AMR service, UL/DL
threshold of other services, or UL/DL Handover access threshold), the RNC decides
whether to accept the access request.
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 DCH/HSUPA UL threshold of Conv AMR service
UL threshold of Conv non_AMR service
UL threshold of other services
UL Handover access threshold
RAN

Issue 01 (2008-05-30)

Service Type Admission Threshold
DL DCH DL threshold of Conv AMR service
DL threshold of Conv non_AMR service
DL threshold of other services
DL Handover access threshold
HSDPA DL total power threshold

For example, the admission of a new AMR service in the uplink based on algorithm 2 will be
successful if the following formula is fulfilled:
(ENU
total
+ ENU
new
)/ENU
max
UL threshold of Conv AMR service

If the cell is in the overload congestion state in the uplink, the RNC rejects any new RAB.
The ENU of MBMS downlink control channels (MICH and MCCH) is reserved.. Therefore, the
power admission for these channels is not needed.
The ENU of HSUPA downlink control channels (E-AGCH/E-RGCH/E-HICH) is reserved by Dl
HSUPA reserved factor. Therefore, the power admission for these channels is not needed.
Algorithm 3 of power resource admission decision is based on power or interference. In
algorithm 3, the estimated load increment is always set to 0.
Algorithm 3 is similar to algorithm 1, but in algorithm 3 the estimated load increment is
always set to 0.
In accordance with the current cell load (uplink load factor and downlink TCP) and the access
request, the RNC determines whether the cell load will exceed the threshold or not, with the
estimated load increment set to 0. If yes, the RNC rejects the request. If not, the RNC accepts
the request.
7.4 CAC Based on NodeB Credit Resource
When a new service accesses the network, NodeB credit resource admission is optional.
7.4.1 NodeB Credit
CE stands for NodeB credit on the RNC side and for Channel Element on the NodeB side. It
is used to measure the channel demodulation capability of the NodeBs.
The resource of one equivalent 12.2 kbit/s AMR voice service, including 3.4 kbit/s signaling
on the Dedicated Control Channel (DCCH), consumed in baseband is defined as one CE. If
there is only 3.4 kbit/s signaling on the DCCH but no voice channel, one CE is consumed.
Channel elements provide either uplink or downlink capacity for services. There are two
kinds of CE. One is uplink CE supporting uplink services, and the other is downlink CE
supporting downlink services. Therefore, one 12.2 kbit/s AMR voice service consumes one
uplink CE and one downlink CE.
RAN

7-15

The principles of NodeB credit admission control are similar to those of power resource
admission control, that is, to check in the local cell, local cell group (if any), and Node
whether the remaining credit can support the requesting services.
For detailed information about local cell, local cell group, and capacity consumption law,
refers to the 3GPP TS 25.433.
According to the common and dedicated channels capacity consumption laws, as well as the
addition, removal, and reconfiguration of the 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 of the local cell (and local cell group, if any) based on the
spreading factor.

If the UL Capacity Credit and DL Capacity Credit are separate, the maintenance on the
local cell (and local cell group, if any) is performed in the UL and DL, respectively.

If the UL Capacity Credit and DL Capacity Credit are not separate, the maintenance only
on the Global Capacity Credit is performed for the local cell (and local cell group, if
any).
The consumption of CEs and the relation between CE and credit are listed in Table 7-2 and
Table 7-3.
For DCH service, MBR is used to calculate the spreading factor and according to Table 7-2,
the number of consumed CEs is available.
For HSUPA service, the rate used to calculate the spreading factor is MBR. According to
Table 7-3, the number of consumed CEs is available.
Table 7-2 Consumption of credits related to SF for the DCH service
Direction Spreading
Factor
Number of CEs
Consumed
Corresponding
Credits Consumed
Typical
Traffic
Class
DL 256 1 1
UL 256 1 2
3.4 kbit/s
SRB
DL 128 1 1
UL 64 1 2
13.6 kbit/s
SRB
DL 128 1 1
UL 64 1 2
12.2 kbit/s
AMR
DL 32 2 2
UL 16 3 6
64 kbit/s VP
DL 64 1 1
UL 32 1.5 3
32 kbps PS
DL 32 2 2
UL 16 3 6
64 kbit/s PS
DL 16 4 4 128 kbit/s PS
RAN

Issue 01 (2008-05-30)

Direction Spreading
Factor
Number of CEs
Consumed
Corresponding
Credits Consumed
Typical
Traffic
Class
UL 8 5 10
DL 8 8 8
UL 4 10 20
384 kbit/s PS

Table 7-3 Consumption of credits related to SF for HSUPA services
Direction Spreading
Factor
Number of CEs
Consumed
Corresponding
Credits Consumed
Typical
Traffic
Class
UL 64 1 2 -
UL 32 1.5 3 64 kbit/s
UL 16 3 6 128 kbit/s
UL 8 5 10 256 kbit/s
UL 4 10 20 384 kbit/s
UL 2 x SF4 20 40 1.45 Mbit/s
UL 2 x SF2 32 64 2.04 Mbit/s
UL 2 x SF2 + 2 x
SF4
48 96 5.76 Mbit/s

As shown in Table 7-2 and Table 7-3, for each data rate and service, the number of UL credits is
equal to the number of UL CEs multiplied by 2. This is because the RESOURCE STATUS
INDICATION message over the Iub interface supports only integers. For example, a UL 32 kbit/s PS
service consumes 1.5 CEs. Then, the number of corresponding UL credits consumed is 3, an integer,
which can be carried in the RESOURCE STATUS INDICATION message.
There is no capacity consumption law for HS-DSCH in 3GPP TS 25.433, so certain credits are
reserved for HSDPA RAB, and credit admission for HSDPA is not needed.
7.4.2 Procedure for NodeB Credit Resource Decision
When a new service tries to access the network, the credit resource admission is implemented
as follows:

For an RRC connection setup request, the credit resource admission is successful if the
current remaining credit resources of the local cell, local cell group (if any), and NodeB
are sufficient for the RRC connection.

For a handover service, the credit resource 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.
RAN

7-17

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 configurable OM thresholds (Ul
HandOver Credit Reserved SF/Dl HandOver Credit and Code Reserved SF) after
admission of the new services.

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 both 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.
If the UL Capacity Credit and DL Capacity Credit are separate, the credit resource admission is
implemented in the UL and DL, respectively.
If the UL Capacity Credit and DL Capacity Credit are not separate, the credit resource admission is
implemented based on the total Capacity Credit.
7.5 CAC Based on Iub Interface Resource
When a new service accesses the network, Iub interface resource admission is mandatory.
For detailed information about resource admission at the Iub transport layer, see "Admission
Control" in Transmission Resource Management Description.
7.6 CAC Based on the Number of HSPA Users
When a new HSPA service attempts to access the network, the HSPA user number admission
is optional.
7.6.1 CAC of HSDPA Users
When the HSDPA_UU_ADCTRL is on, the HSDPA services have to undergo HSDPA user
number admission decision.
When a new HSDPA service attempts to access the network, it is admitted if the number of
HSDPA users in the cell and that in the NodeB do not exceed the associated configurable OM
thresholds (Maximum HSDPA user number and NodeB Max Hsdpa User Number).
Otherwise, the service request is rejected.
7.6.2 CAC of HSUPA Users
When a new HSUPA service attempts to access the network, it is admitted if the number of
the HSUPA users in the cell and that in the NodeB do not exceed the associated configurable
OM thresholds (Maximum HSUPA user number and NodeB Max Hsupa User Number).
Otherwise, the service request is rejected.
RAN
Load Control Description 8 Intra-Frequency Load Balancing Algorithm

8-1

8 Intra-Frequency Load Balancing
Algorithm
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 algorithm is
applicable only to the downlink.
LDB between intra-frequency cells is implemented by adjusting the transmit power of the
Primary Common Pilot Channel (P-CPICH) in 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.
When the intra-frequency LDB algorithm is active, that is, when
INTRA_FREQUENCY_LDB is set to 1, the RNC checks the load of cells periodically and
adjusts the transmit power of the P-CPICH in the associated cells based on the cell load.
Figure 8-1 shows the process of intra-frequency LDB.
Figure 8-1 Process of intra-frequency load balancing

8 Intra-Frequency Load Balancing Algorithm
RAN

Issue 01 (2008-05-30)

This process is described as follows:

If the downlink load of a cell is higher than the value of the threshold which equals 90%,
it is an indication that the cell is heavily loaded. In this case, the transmit power of the
P-CPICH needs to be reduced in steps of 0.2 dB. However, if the current transmit power
is equal to the value of the Min transmit power of PCPICH parameter, no adjustment
is performed.
Because of the reduction in the pilot power, the UEs at the edge of the cell can be handed
over to neighboring cells, especially to those with a relatively light load and with
relatively high pilot power. After that, the downlink load of the cell is lightened
accordingly.

If the downlink load of a cell is lower than the value of the threshold which equals 30%,
it is an indication that the cell has sufficient remaining capacity for more load. In this
case, the transmit power of the P-CPICH increases in steps of 0.2 dB, to help to lighten
the load of neighboring cells. However, if the current transmit power is equal to the value
of the Max transmit power of PCPICH parameter, no adjustment is performed.
RAN
Load Control Description 9 Load Reshuffling Algorithm

9-1

9 Load Reshuffling Algorithm
When the usage of cell resource exceeds the basic congestion triggering threshold, the cell
enters the basic congestion state. In this case, LDR is required to reduce the cell load and
increase the access success rate.

9.1 Basic Congestion Triggering

LDR Procedure

LDR Actions
9.1 Basic Congestion Triggering
Four resources can trigger the basic congestion of the cell: power resource, code resource, Iub
resource, and 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, event-triggered congestion applies,
that is, the RNC checks whether the cells are congested when resource usage changes.
9.1.1 Power Resource
DL_UU_LDR and UL_UU_LDR under the Cell LDC algorithm switch parameter control
the functionality of the power congestion control algorithm.
Figure 9-1 shows the triggering and release of cell power basic congestion.
RAN

Issue 01 (2008-05-30)

Figure 9-1 Triggering and release of cell power basic congestion

For an R99 cell:

If the current UL/DL load of the R99 cell is not lower than the basic congestion control
threshold in UL/DL (UL/DL LDR Trigger threshold) for 100ms, the cell works in the
basic congestion state, and the related load reshuffling actions, as listed in Table 9-2, are
taken.

If the current UL/DL load of the R99 cell is lower than the UL/DL LDR Release
threshold for 100ms, the cell returns to the normal state.
For an HSPA cell:

In the uplink, the object to be compared with the associated threshold (UL LDR
triggering threshold) for decision is the uncontrollable load.

In the downlink, the object to be compared with the associated threshold (DL LDR
triggering threshold) for decision is the sum of the non-HSDPA power (TCP of all
codes not used for HS-PDSCH or HS-SCCH transmission) and the Power Requirement
for GBR (GBP).
9.1.2 Code Resource
CELL_CODE_LDR under the Cell LDC algorithm switch parameter command controls
the functionality of the code congestion control algorithm.
If the SF corresponding to the current remaining code of the cell is larger than Cell LDR SF
reserved threshold, code congestion is triggered and the related load reshuffling actions, as
listed in Table 9-2, are taken.
RAN

9-3

9.1.3 Iub Resources or Iub Bandwidth
The IUB_LDR parameter in the ADD NODEBALGOPARA or MOD
NODEBALGOPARA command controls the functionality of the Iub congestion control
algorithm.
Iub congestion control in both the uplink and downlink is NodeB-oriented. Iub congestion
control is implemented in a separate processing module, so its functionality is not controlled
by LDR switches. In the case of Iub congestion, however, LDR actions are applied to
congestion resolution. For detailed information about the decision on Iub congestion detection,
see "Congestion Control" in Transmission Resource Management Description.
For the basic congestion triggered for the Iub resource reason, all UEs in the NodeB are the
objects of related LDR actions.
9.1.4 NodeB Credit Resource
The basic congestion for NodeB credit is of the following types:

Type A: Basic congestion at local cell level
If the cell UL/DL current remaining SF (mapped to credit resource) is higher than UL
LDR Credit SF reserved threshold/DL LDR Credit SF reserved threshold(set
through the ADD CELLLDR command), credit congestion at cell level is triggered and
related load reshuffling actions are taken in the current cell.

Type B: Basic congestion at local cell group level (if any)

Type C: Basic congestion at NodeB level
If the cell group or NodeB UL/DL current remaining SF (mapped to credit resource ) is
higher than UL LDR Credit SF reserved threshold/DL LDR Credit SF reserved
threshold(set through the ADD NODEBLDR 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-state cells that belong to the cell group or
NodeB will be sorted based on the integrated priority.
RAN

Issue 01 (2008-05-30)

Table 9-1 lists the switches which need to be enabled for the different algorithm types.
Table 9-1 Switches need to be enabled
Switches Need to Be Enabled Algorithm
Cell LDC
Algorithm Switch
Load Control
Algorithm Switch
NodeB LDC Algorithm
Switch
Type A CELL_CREDIT_LD
R
LC_CREDIT_LDR_S
WITCH
-
Type B - LCG_CREDIT_LDR_
SWITCH
LCG_CREDIT_LDR
Type C - NODEB_CREDIT_LD
R_SWITCH
NODEB_CREDIT_LDR

If the congestion of all resources is triggered in a cell, the congestion is resolved in order of
resource priority for load reshuffling as configured through the SET LDCALGOPARA
command.
For example, if the parameters are set as follows:

first priority for load reshuffling: IUBLDR

second priority for load reshuffling: CREDITLDR

third priority for load reshuffling: CODELDR

fourth priority for load reshuffling: UULDR
the basic congestion is resolved in the following sequence:

Iub resource

Credit resource

Code resource

Power resource
The information of cell status can be checked through the DSP CELLCHK command.
9.2 LDR Procedure
The RNC periodically takes actions if basic congestion is detected.
The following procedures apply to HSPA cells and R99 cells. For R99 cells, only DCH UEs
are selected by LDR actions.

Whether the users of gold priority are selected by LDR actions is defined by the Gold User Load
Control Switch parameter.
When the cell is in basic congestion state, the RNC takes one of the following actions in each
period (defined by the LDR period timer length parameter) until the congestion is resolved:

Inter-frequency load handover
RAN

9-5

Code reshuffling

BE service rate reduction

AMR rate reduction

Inter-RAT load handover in the CS domain
Inter-RAT Should Be Load Handover in the CS Domain
Inter-RAT Should Not Be Load Handover in the CS Domain

Inter-RAT load handover in the PS domain
Inter-RAT Should Be Load Handover in the PS Domain
Inter-RAT Should Not Be Load Handover in the PS Domain

Iu QoS renegotiation

MBMS power reduction
Figure 9-2 shows the detailed LDR procedure.
RAN

Issue 01 (2008-05-30)

Figure 9-2 Detailed LDR procedure

In Figure 9-2, the sequence of the LDR actions can be changed through the ADD CELLLDR
command, and the waiting timer for LDR period is defined by the LDR period timer length
parameter through the SET SATLDCPERIOD command.
Table 9-2 describes the LDR actions intended for different resources.
RAN

9-7

Table 9-2 LDR actions intended for different resources
LDR Actions Resource UL/DL Channel
Inter-Fre
quency
Load
Handove
r
BE
Rate
Redu
ction
Inter-RA
T
Handove
r in CS
Domain
Inter-
RAT
Hand
over
in PS
Dom
ain
AMR
Rate
Reductio
n
Iu
Qo
S
Re
neg
oti
ati
on
Code
Resh
uffli
ng
M
B
M
S
Po
we
r
Re
du
cti
on
DCH UL
HSUPA
DCH *
HSDPA
Power
DL
FACH
(MBMS)
*
DCH UL
HSUPA
DCH
HSDPA
Iub
DL
FACH
(MBMS)

DCH
HSDPA
Code
DL
FACH
(MBMS)

DCH UL
HSUPA
DCH
HSDPA
Credit
DL
FACH
(MBMS)

RAN

Issue 01 (2008-05-30)

If the downlink power admission uses the equivalent user number algorithm, basic congestion can
also be triggered by the equivalent number of users. In this situation, LDR actions do not involve
AMR rate reduction or MBMS power reduction, as indicated by the symbol "*" in Table 9-2.
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.
If basic congestion of uplink power in a HSPA cell is triggered, scheduled HSUPA users cannot be
selected by LDR actions.
The parameter Code congestion select inter-freq indication can be set so that the inter-frequency
handover can release the basic congestion caused by code resources.
When the inter-frequency load handover is made to reduce the cell load, only an inter-frequency
neighboring cell that supports blind handover can be a target cell of the inter-frequency load
handover.
The difference between the "Inter-RAT Should Be Load Handover In the CS/PS Domain" and
"Inter-RAT Should Not Be Load Handover In the CS/PS Domain" actions lies in the selection of
users. The former only involves CS/PS users with the "service handover" IE set to "handover to
GSM shall be performed", while the latter only involves CS/PS users with the "service handover" IE
set to "handover to GSM shall not be performed". For detailed information about the "service
handover" IE, see Service Handover Indicator.
9.3 LDR Actions
LDR actions include inter-frequency load handover, BE rate reduction, uncontrolled real-time
QoS renegotiation, inter-RAT handover in the CS domain, inter-RAT handover in the PS
domain, AMR rate reduction, code reshuffling, and MBMS power reduction.
9.3.1 Inter-Frequency Load Handover
The Inter-Frequency Load Handover algorithm is restricted by the inter frequency hard
handover algorithm switch. Inter-frequency load handover can only be performed when the
inter frequency hard handover algorithm is enabled.
The LDR algorithm proceeds as follows:
1. The LDR checks whether the existing cell has a target cell of inter-frequency blind
handover. If there is not such a target cell, the action fails, and the LDR takes the next
action.
2. The principles of selecting inter-freq handover target cell are different as a result of the
different resources which trigger the basic congestion.
If the basic congestion is triggered by the power resource:
The LDR checks whether the load difference between the current load and the basic
congestion triggering threshold of each target cell for blink handover is larger than
the UL/DL Inter-freq cell load handover load space threshold (both the uplink and
downlink conditions must be fulfilled), and the other resources (code resource, Iub
bandwidth, and NodeB credit resource) in the target cell do not trigger basic
congestion. If the basic congestion triggering threshold is not set, the admission
threshold of the cell is used.
If the difference is not larger than the threshold, the action fails, and the LDR 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.
RAN

9-9

If the basic congestion is triggered by the code resource:
Weather 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 current cell.
b. The difference of code occupy rate between current cell and the target cell is
greater than InterFreq HO code used ratio space threshold.
c. The state of target cell is normal.
If there is no such cell, this action fails and the LDR performs the next action. If there
is more than one cell meeting the requirements, the first cell is selected as the blind
handover target cell.

The load difference refers to the difference between the current load and the basic congestion triggering
threshold of each target cell, but not the difference between the load of the target cell and the load of the
existing cell.
3. If the LDR finds a target cell that meets the specified blind handover conditions, the
LDR selects one UE to perform an inter-frequency blind handover to the cell according
to the user integrate priority. For the selected UE, its UL/DL current bandwidth for DCH
or GBR bandwidth for HSPA has to be less than the UL/DL Inter-freq cell load
handover maximum bandwidth parameter (both the uplink and downlink conditions
must be fulfilled).
If there is more than one such UE, the one with the greatest bandwidth is taken.
If the LDR cannot find such a UE, the action fails and the LDR takes the next action.
4. After selecting the target cell and UE, the LDR performs a handover based on the status
of the UE and the measured signal quality.
For detailed information about the handover procedure, see Inter-Frequency Handover.
9.3.2 BE Rate Reduction
The BE rate reduction algorithm is controlled by the DCCC algorithm switch. BE rate
reduction can only be performed when the DCCC algorithm is enabled.
Different from the TF restriction to the OLC algorithm, the BE rate reduction is implemented
by bandwidth reconfiguration. The bandwidth reconfiguration requires signaling interaction
on the Uu interface. This procedure is relatively long.
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.
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.
The LDR algorithm operates as follows:
1. Based on the integrate priority, the LDR sorts the RABs in descending order. The top
RABs related to the BE services (whose current rate is higher than its GBR configured
by SET USERGBR command) are selected. If the integrate priorities of some RABs are
identical, the RAB with the highest rate is selected. The number of RABs to select is
determined by the UL/DL LDR-BE rate reduction RAB number parameter.
RAN

Issue 01 (2008-05-30)

2. The bandwidth of the selected services is reduced to the specified rate. For detailed
information about the rate reduction procedure, see "BE Rate Downsizing and Recovery
Based on Basic Congestion" in Rate Control Description.
3. If services can be selected, the action is successful. If services cannot be selected, the
action fails. The LDR takes the next action.
4. The reconfiguration is completed as indicated by the RB RECONFIGURATION
message on the Uu interface and through the RL RECONFIGURATION message on the
Iub interface.

When admission control of Power/NodeB Credit is disabled, it is not recommended that the BE Rate
Reduction be configured as an LDR action in order to avoid ping-pong effect.
9.3.3 Uncontrolled Real-Time QoS Renegotiation
The Uncontrolled Real-Time QoS Renegotiation algorithm is restricted by the
IU_QOS_RENEG_SWITCH. The uncontrolled real-time QoS renegotiation can only be
performed when the IU_QOS_RENEG_SWITCH is enabled.
The load can be reduced by adjusting the rate of the real-time services through uncontrolled
real-time QoS renegotiation. In 3GPP R5, the RNC initiates the RAB renegotiation procedure
through the RAB MODIFICATION REQUEST message on the Iu interface.
Upon receipt of the RAB MODIFICATION 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.
The LDR algorithm operates as follows:
1. Based on the integrate priority, the LDR sorts the real-time services in the PS domain in
descending order. The top services are selected for QoS renegotiation. The number of
RABs to select is determined by the UL/DL LDR un-ctrl RT Qos re-nego RAB num
parameter.
2. The LDR performs QoS renegotiation for the selected services. The GBR during the
service setup is the maximum rate of the service after the QoS renegotiation.
3. The RNC initiates the RAB MODIFICATION REQUEST message to the CN for the
QoS renegotiation.
4. If the RNC cannot find an appropriate service for the QoS renegotiation, the action fails.
The LDR takes the next action.
9.3.4 Inter-RAT Handover in the CS Domain
The action is restricted by the CS inter-rat handover algorithm switch. This action can only be
performed when the CS inter-rat handover algorithm parameter is enabled.

Inter-RAT Should Be Load Handover in the CS Domain
The cell sizes and coverage modes of 2G and 3G systems are different. Therefore, the
blind handover across systems are not taken into account.
The LDR operates in the downlink as follows:
Based on the integrate priority, the LDR sorts the UEs with the service handover cells
set to "handover to GSM shall be performed" in the CS domain in descending order.
The top CS services are selected, and the number of UEs is controlled by the UL/DL
CS should be ho user number parameter.
RAN

9-11

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 no UE that satisfies the handover criteria is found, the LDR takes the next action.

Inter-RAT Should Not Be Load Handover in the CS Domain
The algorithm for this action is the same as that in Inter-RAT Should Be Load Handover
in the CS Domain. The difference is that this action only involves CS users with the
"service handover" IE set to "handover to GSM shall not be performed".
The number of UEs is controlled by the UL/DL CS should not be ho user number
parameter.
9.3.5 Inter-RAT Handover in the PS Domain
The action is restricted by the PS inter-rat handover algorithm switch. This action can only be
performed when the PS inter-rat handover algorithm is enabled.

Inter-RAT Should Be Load Handover in the PS Domain
The algorithm for this action is the same as that in Inter-RAT Should Be Load Handover
in the CS Domain. The difference is that this action only involves PS users with the
"service handover" IE set to "handover to GSM shall be performed", but not CS users.
The number of UEs is controlled by the UL/DL PS should be ho user number
parameter.

Inter-RAT Should Not Be Load Handover in the PS Domain
The algorithm for this action is the same as that in Inter-RAT Should Not Be Load
Handover in the CS Domain. The difference is that this action only involves PS users
with the "service handover" IE set to "handover to GSM shall not be performed", but not
CS users.
The number of UEs is controlled by the UL/DL PS should not be ho user number
parameter.

HSPA services can be selected only when CM permission ind on HSDPA is set to true and CM
permission ind on HSUPA is not set to Limited.
For detailed information about the CM permission ind on HSDPA parameter, see Inter-Frequency
Handover of HSDPA. For detailed information about the CM permission ind on HSUPA parameter,
see Inter-Frequency Handover of HSUPA.
9.3.6 AMR Rate Reduction
The action is restricted by the AMRC algorithm switch. This action can only be performed
when the AMRC algorithm is enabled.
In the WCDMA system, voice services work in eight AMR modes. Each mode has its own
rate. Therefore, mode control is functionally equal to rate control.
LDR Algorithm for AMR Rate Control in the Downlink
The LDR algorithm operates in the downlink as follows:

Based on the integrate priority, the LDR sorts the RABs in descending order. RABs with
AMR services (conversational) and with the bit rate higher than the GBR are selected.
RAN

Issue 01 (2008-05-30)

The number of RABs to select is determined by the DL LDR-AMR rate reduction
RAB number parameter.

The RNC sends the Rate Control request message through the IuUP 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 fails.
LDR Algorithm for AMR Rate Control in the Uplink
The LDR algorithm operates in the uplink as follows:

Based on the integrate priority, the LDR sorts the RABs in descending order. The top
RABs accessing the AMR services (conversational) and with the bit rate higher than the
GBR are selected. The number of RABs to select is determined by the UL LDR-AMR
rate reduction RAB number 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 fails.
9.3.7 Code Reshuffling
When the cell is in basic congestion for shortage of code resources, sufficient code resources
can be reserved for subsequent service access through code reshuffling. Code subtree
adjustment refers to the switching of users from one code subtree to another. It is used for
code tree defragmentation, so as to free smaller codes first.
The algorithm operates as follows:
1. Initialize the SF_Cur of the root node of subtrees to Cell LDR SF reserved threshold.
2. Traverse all the subtrees with this SF_Cur at the root node. Leaving the subtrees
occupied by common channels and HSDPA channels out of account, take the subtrees in
which the number of users is not larger than the value of the Max user number of code
adjust parameter as candidates for code reshuffling.
If such candidates are available, go to 3.
If no such candidate is available, subtree selection fails. This procedure ends.
3. Select a subtree from the candidates according to the setting of the LDR code priority
indicator parameter.
If this parameter is set to TRUE, select the subtree with the largest code number from
the candidates.
If this parameter is set to FALSE, select the subtree with the smallest number of users
from the candidates. In the case that multiple subtrees have the same number of users,
select the subtree with the largest code number.
4. Treat each user in the subtree as a new user and allocate code resources to each user.
5. Initiate the reconfiguration procedure for each user in the subtree and reconfigure the
channel codes of the users to the newly allocated code resources.
The reconfiguration procedure on the air interface is implemented through the
PHYSICAL CHANNEL RECONFIGURATION message and that on the Iub interface
through the RL RECONFIGURATION message.
Figure 9-3 and Figure 9-4 show an example of code reshuffling. In this example, Cell LDR
SF reserved threshold is set to SF8 and Max user number of code adjust is set to 1.
RAN

9-13

Figure 9-3 Code tree before code reshuffling

Figure 9-4 Code tree after code reshuffling

9.3.8 MBMS Power Reduction
The downlink power load can be reduced by lowering power on MBMS traffic channels.
The algorithm is implemented as follows:
1. Select all the RABs with low priorities, that is, the RABs whose ARP values are higher
than the MBMS descend power rab threshold.
2. The RNC initiates the reconfiguration procedure and resets the transmit power of MTCH
(FACH) to the minimum value. The transmit power corresponds to the MBMS service.
3. The reconfiguration procedure on the Iub interface is implemented through the
COMMON TRANSPORT CHANNEL RECONFIGURATION REQUEST message.
9.3.9 UL and DL LDR Action Combination of a UE
LDR actions in the uplink and the downlink are independent. Sometimes, the actions in both
directions are applied to the same UE. In this situation, the actions are combined as follows:

If the actions in the two directions are identical, the actions are combined. For example,
if BE rate reduction actions in both uplink and downlink need to be applied to the same
RAN

Issue 01 (2008-05-30)

UE, then a single RB reconfiguration message can carry the indication to take BE rate
reduction actions in both directions.

If the actions in the two directions are different and if one direction requires
inter-frequency handover, the UE undergoes the inter-frequency handover. The other
action is not taken.

If the actions in the two directions are different and if one direction requires the
inter-RAT handover, the UE undergoes the inter-RAT handover. The other action is not
taken.

If the action in one direction requires inter-frequency handover, and the action in the
other direction requires inter-RAT handover, the UE undergoes the UL LDR action. The
DL LDR action is not taken.
RAN
Load Control Description 10 Overload Control Algorithm

10-1

10 Overload Control Algorithm
After the UE access is allowed, the power consumed by a single link is adjusted by the single
link power control algorithm. 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.

OLC Triggering

General OLC Procedure

OLC Actions
10.1 OLC Triggering
Only power resources and interference can result in overload congestion. Hard resources such
as the equivalent number of users, Iub bandwidth, and credit resources do not cause overload
congestion.
UL_UU_OLC and DL_UU_OLC under the Cell LDC algorithm switch parameter control
the functionality of the overload congestion control algorithm.
Figure 10-1 shows the triggering and release of cell power overload congestion.
RAN

Issue 01 (2008-05-30)

Figure 10-1 Triggering and release of cell power overload congestion

If the current UL/DL load of an R99 cell is not lower than the UL/DL OLC Trigger
threshold for 100ms, the cell works in overload congestion state and the related
overload handling action is taken. If the current UL/DL load of the R99 cell is lower than
the UL/DL OLC Release threshold for 100ms, the cell comes back to the normal state.

The HSPA cell has the same uplink decision criterion as the R99 cell. The load in the
downlink, however, is the sum of load of the non-HSPA power (transmitted carrier
power of all codes not used for HS-PDSCH or HS-SCCH transmission) and the GBP.
In addition to periodic measurement, event-triggered measurement is applicable to OLC.
If the OLC_EVENTMEAS is set to ON, the RNC requests the initiation of an event E
measurement on power resource in the NodeB. In the associated request message, the
reporting criterion is specified, including the key factors,UL/DL OLC trigger threshold and
UL/DL OLC release threshold. Then the NodeB checks the current power load in real time
according to this criterion and reports the status to the RNC periodically if the conditions of
reporting are met.

For HSDPA cells, the OLC_EVENTMEAS switch is recommended to be set to OFF. For 3GPP
limitation, however, the NodeB cannot check the total load of the non-HSDPA power and the GBP.
10.2 General OLC Procedure
The general OLC procedure covers the following actions: TF control of BE services, channel
switching of BE services, and release of RABs. The RNC takes periodical actions if overload
congestion is detected.
When the cell is overloaded, the RNC takes one of the following actions in each period
(defined by the OLC period timer length parameter) until the congestion is resolved:

TF control of BE service (only for DCH BE service)
RAN

10-3

Switching BE services to common channel

Choosing and releasing the RABs (for HSPA or DCH service)
If the first action fails or the first action is completed but the cell is still in congestion, then the
second action is taken.
Figure 10-2 shows the detailed OLC procedure.
Figure 10-2 Detailed OLC procedure

The state transition from FACH to DCH is forbidden when the cell is in overload congestion.
10.3 OLC Actions
The OLC actions of restricting the TF of the BE service, switching BE services to common
channel, and choosing and releasing RABs are supported in the current version.
10.3.1 TF Control
OLC Algorithm for TF Control in the Downlink
The OLC algorithm for the TF control in the downlink operates as follows:
RAN

Issue 01 (2008-05-30)

1. Based on the integrate priority, the OLC sorts the RABs in descending order. The
following RABs are selected:
The RABs with the DCH BE services whose bit rates are higher than Downlink bit
rate threshold for DCCC. For detailed information about the parameter, see "Rate
Reallocation Based on Traffic Volume" in Rate Control Description.
The RABs with the lowest integrate priority.
The number of RABs selected is lower than or equal to DL OLC fast TF restrict RAB
number.
2. The RNC sends the TF control indication message to the MAC. Each MAC of 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.
MAC restricts the TFC selection in a way like that the maximum TB number is
calculated with the formula:
TFmax(N+1) = TFmax(N) x Ratelimitcoeff
where:
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 time T0+RateRstrctTimerLen* (N)
to T0+RateRstrctTimerLen* (N+1), where T0 is the time MAC receiving the TF
control indication message. RateRstrctTimerLen is a configurable parameter (DL TF
rate restrict timer length).
Ratelimitcoeff is a configurable parameter (DL TF rate restrict coefficient).
3. If the RNC cannot find an appropriate service for the TF control or the time for
performing the TF control exceed the DL OLC fast TF restrict times parameter, the
action fails. The OLC performs the next action.
4. If the congestion is released, the RNC sends the congestion release indication to the
MAC. At the same time, the rate recovery timer (whose length is defined by DL TF rate
recover timer length) is started. When this timer is expired, the MAC increases the data
rate step by step.
MAC restricts the TFC selection by calculating the maximum TB number with the formula:
TFmax(N+1) = TFmax(N) x RateRecoverCoeff
where:

TFmax(0) is the maximum TB number of the BE service before congestion release
indication is received.

TFmax(N+1) is the maximum TB number during time T1+ RateRecoverTimerLen * (N)
to T1+RateRecoverTimerLen* (N+1), where T1 is the time MAC receiving congestion
release indication message. RateRecoverTimerLen is a configurable parameter (DL TF
rate recover timer length).

RateRecoverCoeff is equal to13%.
Figure 10-3 shows an example of TF control. In this example, the object of the TF control is a
downlink 384 kbit/s service, and DL TF rate restrict coefficient is set to 0.68.
RAN

10-5

Figure 10-3 Example of TF control

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 to do fast TF restriction.
MAC restricts the TFC selection during time 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
Match 8.16 and the TFS. Therefore, the maximum TB number is 8.

The time between point A and point B is defined by the DL TF rate restrict timer length parameter.

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

At point C and point D, similar process is followed.
OLC Algorithm for TF Control in the Uplink
For a UE accessing the DCH service, the RNC, in compliance with the 3GPP TS25.331,
restricts the TFC of the UE by sending the TRANSPORT FORMAT COMBINATION
CONTROL message to the UE. Figure 10-4 shows the message flow, in which the UE does
not have any response if the procedure can be performed successfully.
RAN

Issue 01 (2008-05-30)

Figure 10-4 TFC control on the Uu interface

The OLC algorithm for the TF control in the uplink operates as follows:
1. Based on the integrate priority, the OLC sorts the DCH BE services in descending order.
The BE services with the rate higher than the Uplink bit rate threshold for DCCC and
with the lowest integrate priority (with the largest integrate priority value) are selected.
The number of RABs to select is defined by the UL OLC fast TF restrict RAB
number parameter.
2. The RNC sends the TRANSPORT FORMAT COMBINATION CONTROL message to
the UE that accesses the specified service. The TRANSPORT FORMAT
COMBINATION CONTROL 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, UE can apply any TFC of TFCS before the TF
control.
3. Each time, the RNC selects a certain number of RABs (which is defined by UL OLC
fast TF restrict RAB number) to perform the TF control, and each UE of selected
RABs will receive the TRANSPORT FORMAT COMBINATION CONTROL message.
The number of times TF control is performed is defined by the UL OLC fast TF
restrict times parameter.
4. If the RNC cannot find an appropriate service, the OLC performs the next action.
10.3.2 Switching BE Services to Common Channel
The OLC algorithm for switching BE services to common channel operates as follows:
1. Based on the user integrate priority, the OLC sorts all UEs that only have PS services
including HSPA and DCH services (except UEs having also a streaming bearer) in
descending order.
2. The top N UEs are selected. The number of selected UEs is equal to Transfer Common
Channel user number. If UEs cannot be selected, the action fails. The OLC performs
the next action.
3. The selected UEs are switched to common channel.
RAN

10-7

This function can be disabled by setting the Transfer Common Channel user number parameter to
0.
Whether the selected UEs can be switched to common channel depends on the setting of
PS_BE_STATE_TRANS_SWITCH, HSDPA_STATE_TRANS_SWITCH, or
HSUPA_STATE_TRANS_SWITCH.
10.3.3 Release of Some RABs
OLC Algorithm for the Release of Some RABs in the Uplink
The OLC algorithm for the release of some RABs in the uplink operates as follows:
1. Based on the integrate priority, the OLC sorts all RABs including HSUPA and DCH
services in descending order.
2. The top RABs selected. If the integrate priorities of some RABs are identical, the RAB
with higher rate (current rate for DCH RAB and GBR for HSUPA RAB) in the uplink is
selected. The number of selected RABs is equal to UL OLC traff release RAB
number.
3. The selected RABs are released directly.
OLC Algorithm for the Release of Some RABs in the Downlink
The OLC algorithm for the release of some RABs in the downlink operates as follows:
If the Sequence of user release parameter is set to USER_REL:
1. Based on the integrate priority, the OLC sorts all non-MBMS RABs in descending order.
2. The top-priority RABs are selected. If the integrate priorities of some RABs are identical,
the RAB with higher rate (current rate for DCH RAB and GBR for HSUPA RAB) in the
downlink is selected. The number of selected RABs is equal to DL OLC traff release
RAB number.
3. The selected RABs are directly released.
4. If all non-MBMS RABs are released but congestion persists in the downlink, MBMS
RABs are selected.
If the Sequence of user release parameter is set to MBMS_REL:
1. Based on the ARP, the OLC sorts all MBMS RABs in descending order.
2. The top-priority RABs are selected. The number of selected RABs is equal to MBMS
services number released.
3. The selected RABs are directly released.
4. If all MBMS RABs are released but congestion persists in the downlink, non-MBMS
RABs are selected.

This function can be disabled by setting UL/DL OLC traff release RAB number or MBMS services
number released parameters to 0.
RAN

Issue 01 (2008-05-30)

The higher the value of UL OLC traff release RAB number/ DL OLC traff release RAB
number is, the more obviously the cell load decreases at the cost of negatively affecting user
experience.

RAN
Load Control Description 11 Load Control Reference Documents

11-1

11 Load Control Reference Documents
Load Control Reference Documents lists the reference documents related to the feature.

3GPP TS 25.133: Requirements for Support of Radio Resource Management (FDD)

3GPP TS 25.215: Physical layer - Measurements (FDD)

3GPP TS 25.304: UE Procedures in Idle Mode and Procedures for Cell Reselection in
Connected Mode

3GPP TS 25.321: Medium Access Control (MAC) protocol specification

3GPP TS 25.331: Radio Resource Control (RRC)

3GPP TS 25.413: UTRAN Iu Interface RANAP Signaling

Load Control Description (2008!05!30)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Load Control Description (2008!05!30)

Uploaded by

Copyright:

Available Formats

Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd

You might also like