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 Copyright © Huawei Technologies Co., Ltd

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: [email protected]

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.

http://www.huawei.com/

mailto:[email protected]

RAN Load Control Description Contents

Issue 01 (2008-05-30) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd

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

Load Control Description

ii Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd

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

1 Load Control Change History RAN


1-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd

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[%]



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




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 Preemptvulnerability for 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



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.


R99 PS separation indicator R99 CS separation indicator




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.


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.


Low Priority HSUPA user PBR threshold

Equal Priority HSUPA user PBR threshold

High Priority HSUPA user PBR threshold



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.


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 Preemptvulnerability for 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.

3 Load Control Algorithm Overview 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, ThLDR = Load Reshuffling Threshold, ThOLC = Overload Control Threshold



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




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.



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 =>




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. That’s, 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.

4 Load Measurement Algorithm 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.



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:

Fn is the new measurement value after filtering. Fn-1 is the last measurement value after filtering. Mn 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 Qn 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




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.



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.




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.

5 Potential User Control Algorithm 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.

5 Potential User Control Algorithm 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

↘ Q'offset2 = Qoffset2 + Qoffset2 offset 1

↘

Heavy Light Q'offset1 = Qoffset1 + Qoffset1 offset 2

→ Q'offset2 = Qoffset2 + Qoffset2 offset 2

→

Heavy Normal Q'offset1 = Qoffset1 + Qoffset1 offset 2

↗ Q'offset2 = Qoffset2 + 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.

6 Intelligent Access Control Algorithm 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.



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 Negotiation

GBR Rate Negotiation

Initial Rate Negotiation

Target Rate Negotiation

Preemption Queuing

Inter-Frequency

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.




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.



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.




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:



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.




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.



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




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:



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.




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 power（GBP)

Load of Non-HSDPA power

load

DCH service HSDPA service

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



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 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. − The candidate cell supports the requested service.

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 HThd P Thd− −− >

b. For HSDPA bearer

( ), ,total cutcell GBP cutcell HThd P Thd− >




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 HThd P Thd− −− >

b. For HSDPA bearer

( ), , ,/H uu cutcell H ue cutcell H ue cutcell HThd P Thd Thd− − −− >

Where

non HThd − is Dl load balance drd power remain threshold for DCH of the current cell.

HThd 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 loadoffsetThd P Thd P Thd− − − >

( ) ( ), , , , ,total cutcell load cutcell total nbcell load nbcell total loadoffsetThd P Thd P Thd− − − <

b. For a DCH service

( ) ( ), , , , ,AMR nbcell non H nbcell AMR cutcell non H cutcell D loadoffsetThd P Thd P Thd− −− − − >

( ) ( ), , , , ,total cutcell load cutcell total nbcell load nbcell total loadoffsetThd 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



6-15

( ) ( ), , , , ,AMR nbcell D enu nbcell AMR cutcell D enu cutcell D loadoffsetThd P Thd P Thd− −− − − >

Where:

Current cell Inter-frequency neighboring cell

Description

,total cutcellThd ,total nbcellThd DL total power threshold

,GBP cutcellP ,GBP nbcellP HS-DSCH required power load (GBP)

Total power load. It is the sum of the non-HSDPA power and GBP.

,non H cutcellP − ,non H nbcellP − Non-HSDPA power load

,AMR cutcellThd ,AMR nbcellThd DL threshold of Conv AMR service

,H ue cutcellThd − ,H ue nbcellThd − Maximum HSDPA user number

,H ue cutcellP − ,H ue nbcellP − Number of all existing HSDPA users

,D enu cutcellP − ,D enu nbcellP − Total ENU of all existing DCH services

,H loadoffsetThd - Load balance DRD offset for HSDPA

,D loadoffsetThd - Load balance DRD offset for DCH

,total loadoffsetThd - 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.




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.



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.




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



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:




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 candidate cell supports the requested service. − The frequency of the candidate cell is within the band supported by the UE. − The quality of the candidate cell meets the requirements of inter-frequency DRD.

2. The RNC selects a target cell from the candidate cells for UE access.

Based on the relation between 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.



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.




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.



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




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.



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, Telapsed, 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:




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:

Pqueue = Telapsed

where

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

Telapsed is the time in milliseconds that the service request has spent in the queue. The value of Telapsed 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.



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.

7 Call Admission Control Algorithm 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.



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.




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.



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.




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



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.




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 SPINew 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 part–based decision and the total load–based decision. When the admission of HSUPA non-scheduling services or DCH services is implemented, the following formulas apply:



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 Pmax 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:




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 ΔPDL 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).



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. − Formulas 1 and 3 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.




Issue 01 (2008-05-30)

The RNC admits the HSDPA streaming RAB in any of the following situations: − Formula 1 is fulfilled. − Formulas 3 and 4 are fulfilled. − Formulas 3 and 5 are fulfilled. The RNC admits the HSDPA BE RAB in any of the following situations: − Formula 2 is fulfilled. − Formulas 3 and 4 are fulfilled. − Formulas 3 and 5 are fulfilled.

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.

7.3.4 Algorithm 2 of Power Admission 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



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 ENUtotal = ∑all_exist_userENUi. 2. The RNC gets the ENU of the new incoming user ENUnew. 3. The RNC uses the formula (ENUtotal + ENUnew)/ENUmax to forecast the ENU load, where

ENUmax 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




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:

(ENUtotal + ENUnew)/ENUmax ≤ 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.

7.3.5 Algorithm 3 of Power Admission 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.



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




Issue 01 (2008-05-30)





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





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.



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.

9 Load Reshuffling Algorithm 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.



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.




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_LDR

LC_CREDIT_LDR_SWITCH

-

Type B - LCG_CREDIT_LDR_SWITCH

LCG_CREDIT_LDR

Type C - NODEB_CREDIT_LDR_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



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.




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.



9-7

Table 9-2 LDR actions intended for different resources

LDR Actions Resource UL/DL Channel

Inter-Frequency Load Handover

BE Rate Reduction

Inter-RAT Handover in CS Domain

Inter-RAT Handover in PS Domain

AMR Rate Reduction

Iu QoS Renegotiation

Code Reshuffling

MBMS Power Reduction

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)




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.



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.




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.



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.




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. The LDR takes the next action.

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. The LDR takes the next action.

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.



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




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.

10 Overload Control Algorithm 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)



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:




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.



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.




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.



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.




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