RAN

Load Control Parameter Description

Issue01

Date2009-03-30

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 BaseBantian, LonggangShenzhen 518129People's Republic of China

Website:http://www.huawei.com

Email:support@huawei.com

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

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

About This DocumentAuthorPrepared byWu XianbinDate2008-10-26

Edited byCheng XiaoliDate2008-12-09

Reviewed byZeng YongmeiDate2008-12-10

Translated byWang XiaofenDate2008-12-20

Tested byZhang ShashaDate2009-01-10

Approved byDuan ZhongyiDate2009-03-30

RANLoad Control Parameter DescriptionAbout This Document

Issue 01 (2009-03-30)Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltdiii

Contents1 Change History32 Load Control Introduction33 Load Control Algorithm Overview33.1 Load Control Workflow33.2 Algorithm Introduction33.3 Priorities Involved in Load Control33.3.1 User Priority33.3.2 RAB Integrated Priority33.3.3 User Integrated Priority34 Load Measurement Algorithm34.1 Measurement Quantities and Procedure34.1.1 Major Measurement Quantities34.1.2 LDM Procedure34.2 Load Measurement Filtering34.2.1 Filtering on the NodeB Side34.2.2 Smooth Window Filtering on the RNC Side34.2.3 Reporting Period34.2.4 Provided Bit Rate34.3 Auto-Adaptive Background Noise Algorithm35 Potential User Control Algorithm36 Intelligent Access Control Algorithm36.1 IAC Overview36.2 IAC During RRC Connection Setup36.2.1 RRC Redirection for Service Steering36.2.2 RRC DRD36.2.3 RRC Redirection After DRD Failure36.3 Rate Negotiation36.3.1 PS MBR Negotiation36.3.2 PS GBR Negotiation36.3.3 Initial Rate Negotiation36.3.4 Target Rate Negotiation36.4 RAB DRD36.4.1 RAB DRD Overview36.4.2 Inter-Frequency DRD for Service Steering36.4.3 Inter-Frequency DRD for Load Balancing36.4.4 Inter-Frequency DRD36.4.5 Inter-RAT DRD36.5 Preemption36.6 Queuing36.7 Low-Rate Access of the PS BE Service36.8 IAC for Emergency Calls36.8.1 RRC Connection Setup Process of Emergency Calls36.8.2 RAB Process of Emergency Calls37 Call Admission Control Algorithm37.1 CAC Overview37.2 CAC Based on Code Resource37.3 CAC Based on Power Resource37.3.1 Overview37.3.2 Admission Decision for RRC Connection Setup Request37.3.3 Power-Based Admission Algorithm 137.3.4 Power-Based Admission Algorithm 237.3.5 Power-Based Admission Algorithm 337.4 CAC Based on NodeB Credit Resource37.4.1 NodeB Credit37.4.2 Procedure of Admission Decision Based on NodeB Credit37.5 CAC Based on Iub Resource37.6 CAC Based on the Number of HSPA Users37.6.1 CAC of HSDPA Users37.6.2 CAC of HSUPA Users38 Intra-Frequency Load Balancing Algorithm39 Load Reshuffling Algorithm39.1 Basic Congestion Triggering39.1.1 Power Resource39.1.2 Code Resource39.1.3 Iub Resource39.1.4 NodeB Credit Resource39.2 LDR Procedure39.3 LDR Actions39.3.1 Inter-Frequency Load Handover39.3.2 BE Rate Reduction39.3.3 QoS Renegotiation for Uncontrollable Real-Time Services39.3.4 Inter-RAT Handover in the CS Domain39.3.5 Inter-RAT Handover in the PS Domain39.3.6 AMR Rate Reduction39.3.7 Code Reshuffling39.3.8 MBMS Power Reduction39.3.9 UL and DL LDR Action Combination of a UE310 Overload Control Algorithm310.1 OLC Triggering310.2 General OLC Procedure310.3 OLC Actions310.3.1 Performing TF Control of BE Services310.3.2 Switching BE Services to Common Channels310.3.3 Adjusting the Maximum FACH TX Power310.3.4 Releasing Some RABs311 Dynamic Power Sharing Among Carriers311.1 Introduction311.2 Power Sharing Mode312 Load Control Parameters312.1 Description312.2 Values and Ranges313 Reference Documents3

RANLoad Control Parameter DescriptionContents

Issue 01 (2009-03-30)Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltdvii

1 Change HistoryThe change history provides information on the changes in different document versions.Document and Product VersionsDocument VersionRAN Version

01 (2009-03-30)11.0

Draft (2009-03-10)11.0

Draft (2009-01-15)11.0

This document is based on the BSC6810 and 3900 series NodeBs.The available time of each feature is subject to the RAN product roadmap.There are two types of changes, which are defined as follows:Feature change: refers to the change in the load control feature.Editorial change: refers to the change in the information that was inappropriately described or the addition of the information that was not described in the earlier version.01 (2009-03-30)This is the document for the first commercial release of RAN11.0.Compared with issue draft (2009-03-10) of RAN11.0, this issue incorporates the following changes:Change TypeChange DescriptionParameter Change

Feature changeThe description of Control RTWP Anti-interfence algorithm is added. For details, see 7.3 "CAC Based on Power Resource" and 10.3 "OLC Actions."The added parameter is as follows: RsvdPara1.

Editorial changeNone.None.

Draft (2009-03-10)This is the second draft of the document for RAN11.0.Compared with issue draft(2009-01-15) of RAN11.0, draft (2009-03-10) incorporates the following changes:Change TypeChange DescriptionParameter Change

Feature changeNone.None.

Editorial changeThe description of dynamic cell shutdown algorithm is moved to Green BTS Description.The corresponding parameters as follows are move to Green BTS Description:StartTime1EndTime1StartTime2EndTime2StartTime3EndTime3DynShutdownSwitchTotalUserNumThdHsdpaUserNumThdHsupaUserNumThdNCellLdrRemainThdDynCellShutdownProtectTimerlenDynCellOpenJudgeTimerlen

Draft (2009-01-15)This is the initial draft of the document for RAN11.0.Compared with issue 03 (2008-12-30) of RAN10.0, draft (2009-01-15) incorporates the following changes:Change TypeChange DescriptionParameter Change

Feature changeSome parameters are added to section 4.1 "Measurement Quantities and Procedure."The added parameters are as follows:UlBasicCommMeasFilterCoeffDlBasicCommMeasFilterCoeffPucAvgFilterLenUlCacAvgFilterLenDlCacAvgFilterLen LdbAvgFilterLenUlLdrAvgFilterLenDlLdrAvgFilterLenUlOlcAvgFilterLenDlOlcAvgFilterLenHsdpaNeedPwrFilterLenChoiceRprtUnitForHsdpaPwrMeasTenMsecForHsdpaPwrMeasMinForHsdpaPwrMeasChoiceRprtUnitForHsdpaRateMeasTenMsecForHsdpaPrvidRateMeasMinForHsdpaPrvidRateMeasChoiceRprtUnitForHsupaRateMeasTenMsecForHsupaPrvidRateMeasMinForHsupaPrvidRateMeasHsdpaPrvidBitRateFilterLenHsupaPrvidBitRateFilterLen

The description of RRC redirection for service steering is added. For details, see 6.2.1 "RRC Redirection for Service Steering."The added parameters are as follows:RedirSwitchRedirFactorOfNormRedirFactorOfLDRRedirBandInReDirUARFCNUplinkIndReDirUARFCNUplinkReDirUARFCNDownlink

The description of initial rate negotiation for BE services is optimized. For details, see 6.3.3 "Initial Rate Negotiation." The added parameters are as follows:EcN0EffectTimeEcN0Ths

The description of low-rate access is added. For details, see 6.1 "IAC Overview" and 6.7 "Low-Rate Access of the PS BE Service." The added parameters are as follows:PSBELowRateAccessSwitchZeroRateUpFailToRelTimerLen

The description of an OLC action, that is, the adjustment of maximum FACH transmit power, is added. For details, see 10.3.3 "Adjusting the Maximum FACH TX Power." The added parameter is as follows:FACHPwrReduceValue

The description of dynamic cell shutdown algorithm is added.The added parameters are as follows:StartTime1EndTime1StartTime2EndTime2StartTime3EndTime3DynShutdownSwitchTotalUserNumThdHsdpaUserNumThdHsupaUserNumThdNCellLdrRemainThdDynCellShutdownProtectTimerlenDynCellOpenJudgeTimerlen

The description of dynamic power sharing among carriers is added. For details, see 11 "Dynamic Power Sharing Among Carriers."The added parameters are as follows:SLOCELLDLOCELLMAXSHRTOSHMGN

Editorial changeThe title of the document is changed from Load Control Description to Load Control Parameter Description. Parameter names are replaced with parameter IDs. None.

RANLoad Control Parameter Description1 Change History

Issue 01 (2009-03-30)Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd4

2 Load Control IntroductionThe 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 channelization codes, channel elements (CEs), Iub transmission resources, which directly affect user experience, load control aims to maximize the system capacity while ensuring coverage and QoS.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.Intended AudienceThis document is intended for: System operators who need a general understanding of load control.Personnel working on Huawei products or systems.ImpactImpact on System PerformanceThis feature has no impact on system performance.Impact on Other FeaturesThis feature has no impact on other features.Network Elements InvolvedTable 2-1 lists the Network Elements (NEs) involved in load control.Table 2-1 NEs involved in load controlUENodeBRNCMSC ServerMGWSGSNGGSNHLR

----

NOTE: : not involved: involvedUE = User Equipment, RNC = Radio Network Controller, MSC Server = Mobile Service Switching Center Server, MGW = Media Gateway, SGSN = Serving GPRS Support Node, GGSN = Gateway GPRS Support Node, HLR = Home Location Register

RANLoad Control Parameter Description9 Load Reshuffling Algorithm

3 Issue 01 (2009-03-30)Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd4

4 Load Control Algorithm OverviewThis chapter consists of the following sections:Load Control WorkflowAlgorithm IntroductionPriorities Involved in Load Control4.1 Load Control WorkflowDepending on the actual phase of UE access, different load control algorithms are used, as shown in the following figure.Figure 4-2 Load Control algorithms in different UE access phases

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.Figure 4-3 Load control algorithms used on different cell load levels

4.2 Algorithm IntroductionThe load control algorithms are built into the RNC.The input of load control comes from the measurement information of the NodeB.Figure 4-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 taking the following actions:Inter-frequency load handoverCode reshufflingBE service rate reductionAMR voice service rate reductionQoS renegotiation for uncontrollable real-time services CS inter-RAT load handoverPS inter-RAT load handoverMBMS power reductionOverload 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 serviceSwitching BE services to common channelsAdjusting the maximum transmit power of FACHsReleasing some RABsDynamic power sharing among carriersIn dynamic power sharing among carriers, a carrier that carries the HSPA service can dynamically use the idle power resource of another carrier, thus improving the power usage and the cell HSPA service rate. Each load control algorithm involves three factors: measuring, triggering, and controlling. Valid measurement is a prerequisite for effective control.The following table lists the resources that are considered by different load control algorithms.Table 4-2 Resources used by different load control algorithmsLoad Control AlgorithmResources

PowerCodeNodeB CreditsIub Bandwidth

CAC

IAC

PUC---

LDB---

LDR

OLC--

Dynamic power sharing among carriers---

NOTE: not considered: considered

4.3 Priorities Involved in Load ControlThe priorities involved in load control are user priority, Radio Access Bearer (RAB) integrated priority, and user integrated priority.4.3.1 User PriorityThere 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) can be set through SET USERPRIORITY command; the typical relation is shown in the following table.Table 4-3 Typical relation between user priority and ARPARP0123456789101112131415

User PriorityERROR111112222233333

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 for BE services according to different priority levels.The GBR of BE services are configurable. According to the traffic class, priority level, and carrier type (DCH or HSPA), the different values of GBR are configured through the SET 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)Adaptive Multi-Rate Wideband (AMR-WB)Iub overbookingLoad control4.3.2 RAB Integrated PriorityRAB integrated priority is mainly used in load control algorithms.The values of RAB integrated priority are set according to the integrated priority configuration reference parameter (PriorityReference):If the integrated priority configuration reference parameter is set to Traffic Class, the integrated priority abides by the following rules:Traffic classes: conversational -> streaming -> interactive -> background =>Services of the same class: priority based on Allocation/Retention Priority (ARP) values, that is, ARP1 -> ARP2 -> ARP3 -> ... -> ARP14 =>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 carrier type priority indicator parameter (CarrierTypePriorInd).If the integrated priority configuration reference parameter is set to ARP, the integrated priority abides by the following rules:ARP: ARP1 -> ARP2 -> ARP3 -> ... -> ARP14 =>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 =>Services of the same ARP, traffic class and THP (only for interactive services): HSPA or DCH service preferred depending on the carrier type priority indicator parameter.

ARP and THP are carried in the RAB ASSIGNMENT REQUEST message, and they are not configurable on the RNC LMT.4.3.3 User Integrated PriorityFor multiple-RAB users, the integrated priority of the user is based on the service of the highest priority. User integrated priority is used in user-specific load control. For example, the selection of R99 users during preemption, the selection of users during inter-frequency load handover for LDR, and the selection of users during switching of BE services to common channels are performed according to the user integrated priority.4.3.4 5 Load Measurement AlgorithmThe 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.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.This chapter consists of the following sections:Measurement Quantities and ProcedureLoad Measurement FilteringAuto-Adaptive Background Noise Algorithm5.1 Measurement Quantities and Procedure5.1.1 Major Measurement QuantitiesThe major measurement quantities of the LDM are as follows:Uplink Received Total Wideband Power (RTWP)Downlink Transmitted Carrier Power (TCP)Non-HSPA power: TCP excluding the power used for transmission on HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH, and E-HICHHere:HS-PDSCH: High Speed Physical Downlink Shared ChannelHS-SCCH: High Speed Shared Control ChannelE-AGCH: Enhanced Dedicated Channel (E-DCH) Absolute Grant ChannelE-RGCH: E-DCH Relative Grant ChannelE-HICH: E-DCH HARQ Acknowledgement Indicator Channel Provided Bit Rate (PBR) on HS-DSCHPBR on E-DCHPower Requirement for GBR (GBP) on HS-DSCH: minimum power required to ensure the GBR on HS-DSCHReceived Scheduled E-DCH Power Share (RSEPS): power of the E-DCH scheduling service5.1.2 LDM ProcedureThe following figure shows the LDM procedure.Figure 5-5 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.5.2 Load Measurement Filtering5.2.1 Filtering on the NodeB Side

The Provided Bit Rate (PBR) measurement, however, does not use alpha filtering on the NodeB side.The following figure shows the measurement model at the physical layer that is compliant with 3GPP 25.302.Figure 5-6 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.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 according to the following formula:

Here:Fn is the new post-filtering measurement value.Fn-1 is the last post-filtering measurement value.Mn is the new measurement value from the physical layer. = (1/2)k/2, where k is specified by the UlBasicCommMeasFilterCoeff or DlBasicCommMeasFilterCoeff parameter.5.2.2 Smooth Window Filtering on the RNC SideAfter 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 parameters for setting different algorithms.Algorithm Smooth Window Length Parameter

PUC PucAvgFilterLen

CAC UlCacAvgFilterLenDlCacAvgFilterLen

LDBLdbAvgFilterLen

LDR UlLdrAvgFilterLenDlLdrAvgFilterLen

OLCUlOlcAvgFilterLenDlOlcAvgFilterLen

GBP measurements have the same smooth window length in all related algorithms. The filter length for GBP measurement is specified by the HsdpaNeedPwrFilterLen parameter.5.2.3 Reporting PeriodThe NodeB periodically reports each measurement quantity to the RNC. The following table lists the reporting period parameters for setting different measurement quantities.Measurement Reporting Period Parameter

RTWPChoiceRprtUnitForUlBasicMeasTenMsecForUlBasicMeasMinForUlBasicMeasChoiceRprtUnitForDlBasicMeasTenMsecForDlBasicMeasMinForDlBasicMeas

RSEPS

TCP

Non-HSDPA power

GBPChoiceRprtUnitForHsdpaPwrMeasTenMsecForHsdpaPwrMeasMinForHsdpaPwrMeas

5.2.4 Provided Bit RateThe 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 details about PBR, see the 3GPP 25.321.The following table lists the PBR reporting period parameters. Measurement Reporting Period Parameter

HS-DSCH PBRChoiceRprtUnitForHsdpaRateMeasTenMsecForHsdpaPrvidRateMeasMinForHsdpaPrvidRateMeas

E-DCH PBR ChoiceRprtUnitForHsupaRateMeasTenMsecForHsupaPrvidRateMeasMinForHsupaPrvidRateMeas

On the RNC side, the length of the PBR smooth filter window is specified by the HsdpaPrvidBitRateFilterLen / HsupaPrvidBitRateFilterLen parameter.5.3 Auto-Adaptive Background Noise AlgorithmUplink (UL) background noise is sensitive to environmental conditions. Therefore, the LDM algorithm incorporates an auto-adaptive update algorithm to restrict the background noise within a specified range, as described here:If the temperature in the equipment room is constant, the background noise changes slightly. In this case, the background noise requires no more adjustment after initial correction. If the temperature in the equipment room varies with the ambient temperature, the background noise changes greatly. In this case, the background noise requires auto-adaptive upgrade. Figure 4-3 shows the procedure of auto-adaptive background noise upgrade, which is enabled by the BGNSwitch parameter.

BGNSwitch is set to ON by default. Figure 5-7 Procedure of auto-adaptive background noise upgrade

The Alpha filter formula is: Fn = (1 - ) x Fn-1 + x Mn (n1). For details about this formula, see 4.2.1 "Filtering on the NodeB Side." Counting threshold = (Duration of background noise)/(RTWP reporting period). The duration of background noise is used in auto-adaptive upgrade decision and is set through BGNAdjustTimeLen. For the setting of RTWP reporting period, see 4.2.3 "Reporting Period." In the case that BGNSwitch is set to ON, the procedure of auto-adaptive background noise upgrade is as follows:1. The RNC initializes the counter and filter that are used for auto-adaptive upgrade and sets the initial value (F0) of the filter to BackgroundNoise. 3. The RNC receives the latest RTWP measurement value (Mn) from the physical layer. 4. The RNC determines whether the current time is within the effective period of the algorithm, that is, whether the current time is later than BgnStartTime and earlier than BgnEndTime. If the current time is within the effective period, the RNC performs the next step. Otherwise, the RNC waits for the next RTWP measurement value. 5. The RNC determines whether the current Equivalent Number of Users (ENU) in the cell is greater than the value of BGNEqUserNumThd:If the current ENU is greater than this threshold value, the RNC infers that Mn includes other noises in addition to the background noise, and therefore it does not feed Mn to the filter. In addition, the RNC sets the counter to zero, keeps the current background noise unchanged, sets the initial value of the filter to the current background noise, and waits for the next RTWP measurement value. If the current ENU in the cell is smaller than or equal to the threshold value, the RNC feeds Mn to the filter and performs the next step. 6. The RNC determines whether |Mn Fn-1| is smaller than the value of BgnAbnormalThd. If it is smaller than this threshold value, the RNC increments the counter by one, calculates Fn according to the Alpha filter formula, and performs the next step. Otherwise, the RNC waits for the next RTWP measurement value. 7. The RNC determines whether the counter reaches the counting threshold. If it reaches the counting threshold, the RNC performs the next step. Otherwise, the RNC waits for the next RTWP measurement value. 8. The RNC determines whether |Fn - BackgroundNoise| is smaller than the value of BgnAbnormalThd. The purpose is to prevent burst interference and RTWP spike. If it is smaller than the value of BgnAbnormalThd, the RNC performs the next step. Otherwise, the RNC sets the counter to zero and waits for the next RTWP measurement value. 9. The RNC determines whether |Fn - current background noise| is greater than the value of BgnUpdateThd. The purpose is to prevent frequent background noise upgrades on the Iub interface. If it is greater than the value of BgnUpdateThd, the RNC sets the current background noise to Fn, sets the counter to zero, and waits for the next RTWP measurement value. Otherwise, the RNC sets the counter to zero and waits for the next RTWP measurement value. 6 7 Potential User Control AlgorithmIn the WCDMA system, the mobility management of the UE in idle or connected mode is implemented by cell selection and reselection. The Potential User Control (PUC) algorithm controls the cell selection and cell reselection of the potential UE and prevents an idle UE from camping on a heavily loaded cell.

The PUC algorithm is only valid for inter-frequency cells. Figure 5-1 shows the PUC procedure.Figure 7-8 PUC procedure

The PUC algorithm is enabled only when the PUC subparameter of the NBMLdcAlgoSwitch parameter is set to 1.The RNC periodically monitors the downlink load of the cell. If the cell load is higher than the upper threshold (SpucHeavy) plus the load level division hysteresis (SpucHyst), the cell load is considered heavy.If the cell load is lower than the lower threshold (SpucLight) minus SpucHyst, the cell load is considered light.The states of cell load are heavy, normal, and light, as shown Figure 5-2.Figure 7-9 Cell load states

PUC takes effect only in downlink.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.Table 5-1 describes PUC-related variables and their impacts on UEs.Table 7-4 PUC-related variables and their impacts on UEsItemDescription

ImplementationThe variables related to cell selection and reselection are Qoffset1(s,n) (load level offset), Qoffset2(s,n) (load level offset), and Sintersearch (start threshold for inter-frequency cell reselection).The NodeB periodically reports the transmit power of the cell, and the PUC periodically triggers the following activities:Assessing the cell load level based on the non-HSPA power and HS-DSCH GBPSetting Sintersearch, Qoffset1(s,n), and Qoffset2(s,n) based on the cell load levelUpdating the parameters in system information SIB3 and SIB11

AdjustmentBased on the characteristics of inter-frequency cell selection and reselection, the UE makes the corresponding adjustments: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 setting of Sintersearch affects the current cell. Its value is related to the load of the current cell. Table 5-2 describes the changes of Sintersearch.Table 7-5 Changes of Sintersearch according to the load stateLoad State of the Current CellSintersearchChange of Sintersearch

LightS'intersearch = Sintersearch + OffSinterLight

NormalS'intersearch = Sintersearch

HeavyS'intersearch = Sintersearch + OffSinterHeavy

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

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. Table 5-3 describes the changes of Qoffset1 and Qoffset2. Table 7-6 Changes of Qoffset1 and Qoffset2 according to the load stateLoad State of the Neighboring CellsLoad State of the Current CellQ'offset1Change of Q'offset1Q'offset2Change of Q'offset2

LightLightQ'offset1 = Qoffset1Q'offset2 = Qoffset2

LightNormalQ'offset1 = Qoffset1Q'offset2 = Qoffset2

LightHeavyQ'offset1 = Qoffset1 + OffQoffset1LightQ'offset2 = Qoffset2 + OffQoffset2Light

NormalLightQ'offset1 = Qoffset1Q'offset2 = Qoffset2

NormalNormalQ'offset1 = Qoffset1Q'offset2 = Qoffset2

NormalHeavyQ'offset1 = Qoffset1 + OffQoffset1LightQ'offset2 = Qoffset2 + OffQoffset2Light

HeavyLightQ'offset1 = Qoffset1 + OffQoffset1HeavyQ'offset2 = Qoffset2 + OffQoffset2Heavy

HeavyNormalQ'offset1 = Qoffset1 + OffQoffset1HeavyQ'offset2 = Qoffset2 + OffQoffset2Heavy

HeavyHeavyQ'offset1 = Qoffset1Q'offset2 = Qoffset2

The prerequisite for the changes of the preceding parameters is that these parameters take their default values.8 9 Intelligent Access Control AlgorithmThe access of a service to the network consists of setup of an RRC connection and a RAB. The Intelligent Access Control (IAC) algorithm is used to improve the access success rate. This chapter consists of the following sections:IAC OverviewIAC During RRC Connection SetupRate NegotiationRAB DRDPreemptionQueuingLow-Rate Access of the PS BE ServiceIAC for Emergency Calls9.1 IAC OverviewFigure 6-1 shows a typical procedure of service access control.Figure 9-10 Service access control procedure

As shown in Figure 6-1, the procedure of service access includes the procedures for RRC connection setup and RAB setup. The successful setup of the RRC connection is one of the prerequisites for the RAB setup.During the RRC connection processing, the RNC first performs RRC redirection for service steering:If the RNC decides UE access from the current cell, it then makes a resource-based admission decision through the CAC algorithm. If the resource-based admission fails, the RNC performs DRD and redirection.

The resources include power resource, code resource, Iub resource, credit resource, and number of HSPA users.If the RNC decides UE access from another cell, it then sends an RRC connection reject message to the UE. The message carries the information about the cell and instructs the UE to set up an RRC connection to the cell. During the RAB processing, the RNC performs the following steps:1. Performs inter-frequency DRD to select a suitable cell for service steering or load balancing. 1. Performs rate negotiation according to the service requested by the UE.1. Makes cell resourcebased admission decision. If the admission is successful, UE access is granted. Otherwise, the RNC performs the next step.1. Selects a suitable cell, according to the inter-frequency DRD algorithm, from the cells where no admission attempt has been made, and then goes to 2. If the attempt fails, the RNC performs the next step.1. selects a suitable cell, according to the inter-RAT DRD algorithm. If the inter-RAT access is successful, UE access in the inter-RAT cell. If the inter-RAT DRD fails or is not supported, the RNC performs the next step.1. 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.1. 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.1. Performs low-rate access. If the low-rate access is successful, UE access is granted. If the low-rate access is unsuccessful, the RNC performs the next step. 1. Rejects UE access.

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 9-7 IAC procedure supported by servicesService TypeLow-Rate Access Rate NegotiationPreemptionQueuingDRD

MBR NegotiationGBR NegotiationInitial Rate NegotiationTarget Rate NegotiationInter-FrequencyInter-RAT

DCH

HSUPA-

HSDPA-

In the previous table, MBR stands for maximum bit rate. For details about CAC, see 7 "Call Admission Control Algorithm."9.2 IAC During RRC Connection SetupBefore a new service is admitted to the network, an RRC connection must be set up. During the RRC connection setup, the RRC redirection for service steering algorithm is used for service steering and load sharing between inter-frequency or inter-RAT cells.When the resources of a cell for UE access are insufficient, the RNC instructs the UE to an inter-frequency or inter-RAT cell through DRD or redirection to increase the access rate. Figure 9-11 RRC connection setup procedure

After receiving an RRC CONNECTION REQUEST message from the UE, the RNC uses the RRC redirection algorithm for service steering to decide whether the UE may access the network from the current cell: If the UE needs to access the network from another cell according to the decision, the RNC sends an RRC CONNECTION REJECT message to the UE. The message carries the information about this cell. If the UE attempts to access the network from the current cell according to the decision, the RNC uses the CAC algorithm to decide whether an RRC connection can be set up between the UE and the current cell. If the RRC connection can be set up between the UE and the current cell, the RNC sends an RRC CONNECTION SETUP message to the UE. For details about CAC, see 7 "Call Admission Control Algorithm."If no RRC connection can be set up between the UE and the current cell, the RNC attempts to set up an RRC connection through RRC DRD or RRC redirection. 2. RRC Redirection for Service Steering

This algorithm is not applicable to combined services. The switch of RRC redirection for service steering can be set through the DR_ RRC_DRD_SWITCH subparameter of the DrSwitch parameter.During the RRC connection setup, the RNC implements service steering between inter-frequency or inter-RAT cells according to the cause of RRC connection setup. In addition, the RNC considers the load of the cell for access and the redirection factors to control the degree of load balancing. The procedure of RRC redirection for service steering is as follows:19. The RNC obtains the information about the service requested by the UE and the capability of the UE. 20. If the switch of RRC redirection for service steering is on, the RNC determines the service type requested by the UE. If the switch is off or the RNC fails to determine the service type, the RNC handles the RRC connection setup request of the UE in the current cell. 21. If the RNC succeeds in determining the service type requested by the UE and the switch of RRC direction for service steering (RedirSwitch) is set to ONLY_TO_INTER_FREQUENCY or ONLY_TO_INTER_RAT, the RNC performs the next step. Otherwise, the RNC handles the RRC connection setup request of the UE in the current cell. 22. Based on the cell load and the redirection factors, the RNC decides whether to perform RRC redirection for service steering. If the cell is normal, the RNC generates a random number between 0 and 1 and compares it with the corresponding unconditional redirection factor (RedirFactorOfNorm). If the random number is smaller than this factor, the RNC performs the next step. Otherwise, the RNC handles the RRC connection setup request of the UE in the current cell. If the cell is in the basic congestion or overload state, the RNC generates a random number between 0 and 1 and compares it with the corresponding LDR-triggered redirection factor (RedirFactorOfLDR). If the random number is smaller than this factor, the RNC performs the next step. Otherwise, the RNC handles the RRC connection setup request of the UE in the current cell. 23. Based on the setting of RedirSwitch, the RNC takes the corresponding actions: If RedirSwitch is set to ONLY_TO_INTER_FREQUENCY, the RNC sends an RRC CONNECTION REJECT message to the UE, redirecting the UE to the destination frequency carried in the message.

The frequency information carried in the message can be set through the parameters RedirBandInd, ReDirUARFCNUplinkInd, ReDirUARFCNUplink, and ReDirUARFCNDownlink. If RedirSwitch is set to ONLY_TO_INTER_RAT, the RNC sends an RRC CONNECTION REJECT message to the UE. The message carries the information about inter-RAT neighboring cells. 9.2.3 RRC DRDIf the DR_ RRC_DRD_SWITCH subparameter of the DrSwitch parameter is set to 0, the RNC performs RRC redirection without performing RRC DRD. Otherwise, the RNC performs the following steps: 1. The RNC selects intra-band inter-frequency neighboring cells of the current cell. These neighboring cells are suitable for blind handovers.25. 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:

Here: is the cached CPICH Ec/N0 value included in the RACH measurement report. is the DRD threshold (DRDEcN0Threshhold).26. 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.27. If the candidate cell list does not contain any cell, the RRC DRD fails. The RNC performs the next step, that is, RRC redirection.9.2.4 RRC Redirection After DRD FailureWhen the RRC DRD fails, the associated RRC connection fails to be set up if the DR_ RRC_DRD_SWITCH subparameter of the DrSwitch parameter is set to 0 or if the switch of RRC redirection after DRD failure (ConnectFailRrcRedirSwitch) is set to OFF. Otherwise, the RNC performs the following steps when the RRC DRD fails:1. The RNC selects all intra-band inter-frequency cells of the local cell.29. 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.30. If more than one candidate cell is available, the RNC selects a cell randomly and redirects the UE to the cell. 31. If no candidate cell is available,If the switch of RRC redirection after DRD failure is set to Only_To_Inter_Frequency, the RRC connection setup fails.If the switch of RRC redirection after DRD failure is set to Allowed_To_Inter_RAT, then:a.If a neighboring GSM cell is configured, the RNC redirects the UE to that GSM cell.b.If no neighboring GSM cell is configured, the RRC connection setup fails.9.3 Rate NegotiationRate negotiation includes MBR negotiation, GBR negotiation, initial rate negotiation, and target rate negotiation.For details about AMR and AMR-WB speech services in the CS domain, see the Rate Control Parameter Description.9.3.1 PS MBR NegotiationIf the IE "Alternative RAB Parameter Values" is present in the RANAP RAB ASSIGNMENT REQUEST or the RELOCATION REQUEST message when a PS service is set up, reconfigured, or admitted, then the RNC and the CN negotiate the rate according to the UE capability to obtain the MBR while ensuring a proper QoS.For the PS streaming service, when PS_STREAM_IU_QOS_NEG_SWITCH is set to 1, the Iu QoS negotiation function is enabled for MBR negotiation. For the PS BE service:When both PS_BE_IU_QOS_NEG_SWITCH and PS_BE_STRICT_IU_QOS_NEG_SWITCH are set to 1, the Iu QoS negotiation function is enabled, and the RNC determines the MBR of Iu QoS negotiation based on the information about UE capability, cell capability and other settings..When PS_BE_IU_QOS_NEG_SWITCH is set to 1 and PS_BE_STRICT_IU_QOS_NEG_SWITCH is set to 0, the Iu QoS negotiation function is enabled, and the RNC determines the MBR of Iu QoS negotiation based on the maximum rate supported by the UE rather than the cell capability and other settings.9.3.2 PS GBR NegotiationDuring the setup, reconfiguration, or handover of a real-time PS service, if the RAB assignment message carries multiple alternative GBRs and PS_STREAM_IU_QOS_NEG_SWITCH is set to 1, the RNC selects the minimum rate as the GBR of this RAB and sends it to the CN. If the IE "Type of Alternative Guaranteed Bit Rate Information" in the message is set to unspecified, the GBR is set to 8 kbit/s. 9.3.3 Initial Rate NegotiationFor a non-real-time service in the PS domain, the RNC selects an initial rate to allocate bandwidth for the service before the admission request based on cell resources in the following cases: A service is set up.The UE state changes from CELL_FACH to CELL_DCH.The negotiation is based on the cell load information, which includes:Uplink and downlink radio bearer status of the cellMinimum spreading factor (SF) supportedHSPA capabilityInitial Rate Definition for DCH ServicesFor DCH services, the initial rate is defined as follows:DCCC SwitchPS BE Initial Rate Dynamic Configuration SwitchActual Initial Rate

ONONIn the uplink, the initial rate is the smaller one of the MBR and 384 kbit/s. In the downlink, the initial rate is dynamically set on the basis of Ec/N0. For the specific method, see the description following this table.

ONOFFIn the uplink, the initial rate is the smaller one of the MBR and the initial rate of the uplink BE service. In the downlink, the initial rate is the smaller one of the MBR and the initial rate of the downlink BE service.

OFF-MBR

The parameter corresponding to the DCCC switch is DCCC_SWITCH. The parameter corresponding to the PS BE initial rate dynamic configuration switch is PS_BE_INIT_RATE_DYNAMIC_CFG_SWITCH.

As described in the table, when the two switches are ON, the initial rate is dynamically set on the basis of Ec/N0 in the downlink. The specific method is as follows:When receiving an RRC connection setup request, the RNC starts the timer EcN0EffectTime. Before the timer expires, the RNC dynamically sets the initial rate based on the P-CPICH Ec/N0 carried in the RRC CONNECTION REQUEST message:If the cell Ec/N0 is above the Ec/N0 threshold (EcN0Ths), the RNC sets the actual initial rate to the smaller one of the MBR and 384 kbit/s. If the cell Ec/N0 is below or at the Ec/N0 threshold (EcN0Ths) or the RRC CONNECTION REQUEST message does not carry the information about Ec/N0, the RNC sets the actual initial rate to the smaller one of the MBR and the initial rate of the downlink BE service (DlBeTraffInitBitrate).

If the DCCC function is enabled and PS_RAB_Downsizing_Switch is set to 1, the RNC can decrease the rate through the RAB rate decrease function when the admission based on the initial rate fails. Initial Rate Definition for HSUPA ServicesFor the HSUPA service, the initial rate is defined as follows:If HSUPA_DCCC_SWITCH is set to 1, the actual initial rate is the initial rate of the HSUPA BE service (HsupaInitialRate). If the HSUPA DCCC function is disabled, the actual initial rate is the MBR. 9.3.4 Target Rate NegotiationFor a non-real-time service in the PS domain, if cell resourcebased admission fails, the RNC selects a target rate to allocate bandwidth for the service based on cell resource in following cases:Service setupSoft handoverDCCC rate upsizingIf the cell has sufficient code and CE resources, the RNC sets the candidate target rate to the one that matches the cell resource surplus. Then, the RNC sets the target rate to the greater one of the candidate target rate and the GBR. In the case of soft handover, the actual target rate is the candidate target rate set by the RNC.In the case of DCCC rate upsizing, if the rate upsizing fails, the target rate is the greater one of the candidate target rate and the pre-upsizing DCCC rate.9.4 RAB DRDRAB DRD is used to select a suitable cell for the UE to try an access.For a single service, RAB DRD can be enabled by the DR_RAB_SING_DRD_SWITCH subparameter of the DrSwitch parameter. For combined services, RAB DRD can be enabled by the DR_RAB_COMB_DRD_SWITCH subparameter of the DrSwitch parameter.9.4.1 RAB DRD OverviewThrough the RAB DRD procedure, the RNC selects a suitable cell for RAB processing during access control. RAB DRD is of two types: inter-frequency DRD and inter-RAT DRD. Inter-frequency DRD is further classified into inter-frequency DRD for service steering and inter-frequency DRD for load balancing.After receiving a Radio Access Network Application Part (RANAP) message RAB ASSIGNMENT REQUEST, the RNC initiates a RAB DRD procedure to select a suitable cell for RAB processing during access control.The basic procedure of RAB DRD is as follows:0. The RNC performs inter-frequency DRD. According to the purposes of directed retry, Inter-frequency DRD is of the following types:Inter-frequency DRD for service steeringFor details, see Inter-Frequency DRD for Service Steering.Inter-frequency DRD for load balancingFor details, see Inter-Frequency DRD for Load Balancing.1. If all admission attempts of inter-frequency DRD fail, the RNC performs an inter-RAT DRD.For details about inter-RAT DRD, see Inter-RAT DRD.2. 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 details about preemption and queuing, see Preemption and Queuing, respectively.9.4.2 Inter-Frequency DRD for Service SteeringIf 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 DRD for service steering is specified by the ServiceDiffDrdSwitch parameter.

"Inter-frequency DRD for service steering" is called "DRD for service steering" for short in this section.Cell Service Priorities IntroductionCell 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 specified by the service priority group identity (SpgId) 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.CellService Priority Group IdentityService Priority of R99 RT ServiceService Priority of R99 NRT ServiceService Priority of HSPA ServiceService Priority of Other Service

A12110

B21200

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 9-12 Example of 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.Procedure of DRD for Service Steering

This section describes the procedure of DRD for service steering when DRD for load balancing is disabled.Figure 9-13 Procedure of DRD for service steering

The procedure of DRD for service steering is as follows: 1. The RNC determines the candidate cells to which blind handovers can be performed and sorts the candidate cells in descending order according to service priority.A candidate cell must meet the following conditions: The frequency of the candidate cell is within the band supported by the UE.The quality of the candidate cell meets the requirements of inter-frequency DRD. For details, see 6.2 "IAC During RRC Connection Setup."The candidate cell supports the requested service.3. 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.4. The CAC algorithm makes an admission decision based on the status of the target cell.If the admission attempt is successful, the RNC accepts the service request.If the admission attempt fails, the RNC removes the cell from the candidate cells and then checks whether all candidate cells are tried.If there are any cells where no admission decision has been made, the algorithm goes back to step 2.If admission decisions have been made in all the candidate cells, then:a.If the service request is an HSPA one, the HSPA request falls back to a DCH one. Then, the algorithm goes back to step 1 to make an admission decision based on R99 service priorities.b.If the service request is a DCH one, the RNC initiates an inter-RAT DRD.9.4.3 Inter-Frequency DRD for Load BalancingIf 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.

"Inter-frequency DRD for load balancing" is called "DRD for load balancing" for short in this section.Overview of DRD for Load BalancingLoad balancing considers two resources, power, and code.The availability of DRD for load balancing is specified by the associated parameters as follows:The availability of power-based DRD for load balancing for DCH service is specified by the LdbDRDSwitchDCH parameter.The availability of power-based DRD for load balancing for HSDPA service is specified by the LdbDRDSwitchHSDPA parameter.The availability of code-based DRD for load balancing is specified by the CodeBalancingDrdSwitch parameter.In practice, it is recommended that only either a power-based DRD for load balancing or a code-based DRD for load balancing is activated. If both are activated, power-based DRD for load balancing takes precedence over code-based DRD for load balancing.Code-based DRD for load balancing is applicable to only R99 services because HSDPA services use reserved codes.Power-Based DRD for Load Balancing

This section describes the procedure of DRD for load balancing when DRD for service steering is disabled.The following two algorithms are available for power-based load balancing. If power-based DRD for load balancing is enabled, one of them can be used. The algorithm used is specified by the LdbDRDchoice parameter.Algorithm 1: DRD for load balancing is performed according to the cell measurement values about the DL non-HSDPA power and DL HS-DSCH GBP.For DCH service, the RNC sets up the service on a carrier with a light load of non-HSPA power to achieve load balancing among the cells at the different frequencies.For HSDPA service, the RNC sets up the service on a carrier with a light load of HS-DSCH GPB to achieve load balancing among the cells at different frequencies.Algorithm 2: DRD for load balancing is performed according to the DCH ENU and HSDPA user number.For DCH service, the RNC sets up the service on a carrier with a light load of DCH ENU to achieve load balancing among the cells on different frequencies.For HSDPA service, the RNC sets up the service on a carrier with a light load of HSDPA user to achieve load balancing among the cells on different frequencies.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 a lighter load of HS-DSCH GBP than cell B. If the UE requests an HSDPA service in cell B, preferably, the RNC selects cell A for the UE to access.Figure 9-14 Power-based DRD for load balancing

Figure 6-6 shows the procedure of power-based DRD for load balancing.Figure 9-15 Procedure of power-based DRD for load balancing

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

b. For HSDPA bearer

For algorithm 2, condition 1 is as follows:a. For DCH bearer

b. For HSDPA bearer

Here: is specified by LdbDRDLoadRemainThdDCH. is specified by LdbDRDLoadRemainThdHSDPA.If...Then...

Condition 1 is metThe service tries admission to the current cell. Go to step 5.

Condition 1 is not metGo to step 4.

5. The RNC selects a target cell 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 algorithm 1 is used, condition 2 is as follows: For an HSDPA service

For a DCH service

If algorithm 2 is used, condition 2 is as follows:For an HSDPA service

For a DCH service

The related variables are described as follows:Current cellInter-frequency Neighboring CellDescription

DL total power threshold (DlCellTotalThd)

HS-DSCH GBP

Total power load, which is the sum of the non-HSDPA power and the GBP

Non-HSDPA power load

DL threshold of conversational AMR service (DlConvAMRThd)

Maximum number of HSDPA users (MaxHsdpaUserNum)

Total number of HSDPA users

DCH ENU load

-Load balancing DRD offset for HSDPA (LdbDRDOffsetHSDPA)

-Load balancing DRD offset for DCH (LdbDRDOffsetDCH)

-Load balancing DRD total power protect threshold (LdbDRDTotalPwrProThd)

Then, the RNC selects the target cell as follows:If there is only one inter-frequency neighboring cell that meets the conditions of DRD for load balancing, the RNC selects this cell as the target cell. If there are multiple such cells:For a DCH servicea.If algorithm 1 is used, the RNC selects the cell with the lightest non-HSDPA load as the target cell.b.If algorithm 2 is used, the RNC selects the cell with the lightest load of DCH ENU as the target cell.For an HSDPA servicea.If algorithm 1 is used, the RNC selects the cell with the lightest load of HS-DSCH required power as the target cell.b.If algorithm 2 is used, the RNC selects the cell with the lightest load of HSDPA user as the target cell.If there is no such cell, the RNC selects the current cell as the target cell.6. The CAC algorithm makes an admission decision based on the status of the target cell.If the admission attempt is successful, the RNC admits the service request.If the admission attempt fails, the RNC checks whether admission decisions have been made in all candidate inter-frequency neighboring cells.If there is any cell where no admission decision is made, the algorithm goes back to step 2.If admission decisions have been made in all the candidate cells:a.When the service request is an HSPA one, the HSPA request falls back to a DCH one. Then, the algorithm goes back to step 1 to make an admission decision based on R99 service priorities.b.When the service request is a DCH one, the RNC initiates an inter-RAT DRD.Code-Based DRD for Load BalancingThe procedure of DRD for load balancing 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.Figure 9-16 Procedure of code-based DRD for load balancing

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

"Inter-frequency DRD for service steering" is called "DRD for service steering" for short in this section. "Inter-frequency DRD for load balancing" is called "DRD for load balancing" for short in this section.When both DRD for service steering and DRD for load balancing are enabled, the general principles of inter-frequency DRD are as follows:DRD for service steering takes precedence over DRD for load balancing, that is, preferably considers service priorities.To services of the same service priority, load balancing applies.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. CellValue of Service Priority of R99 Real-Time Service

UTRAN f13

UTRAN f22

UTRAN f31

UTRAN f41

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 9-17 Example of inter-frequency DRD

Inter-Frequency DRD ProcedureIf 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 checks whether DRD for service steering and DRD for load balancing are enabled. Figure 6-9 shows the procedure.Figure 9-18 Inter-frequency DRD procedure

The procedure of inter-frequency DRD is as follows:If DRD for service steering is enabled but DRD for load balancing is disabled, as shown in A in Figure 6-9, the inter-frequency DRD procedure is the procedure of DRD for service steering. For details, see Inter-Frequency DRD for Service Steering.If DRD for load balancing is enabled but DRD for service steering is disabled, as shown in B in Figure 6-9, the inter-frequency DRD procedure is the procedure of DRD for load balancing. For details, see Inter-Frequency DRD for Load Balancing.If both DRD for load balancing and DRD for service steering are disabled:1. The UE attempts to access the current cell when its service priority is not 0. If the service priority of the current cell is 0, the UE attempts to access another candidate cell whose service priority is not 0.3. The CAC algorithm makes an admission decision based on the cell status.If the admission attempt is successful, the RNC admits the service request.If the admission attempt fails, the UE attempts to access another candidate cell randomly.4. If any request for access to a candidate cell is rejected, then:If the service request is an HSPA one, the HSPA request falls back to a DCH one. Then, the algorithm goes back to step 1 to retry admission based on R99 service priorities.If the service request is a DCH one, the RNC initiates an inter-RAT DRD.If both DRD for load balancing and DRD for service steering are enabled:1. The RNC determines the candidate cells to which blind handovers can be performed. A candidate cell must meet the following conditions: The 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.6. The RNC selects a target cell from the candidate cells for UE access.Based on the relation between DRD for service steering and DRD for load balancing:The RNC preferably selects the cell with the highest service priority.If there are multiple cells with the highest service priority, load balancing applies to these cells. In this case, the RNC follows the same DRD logic as described in Inter-Frequency DRD for Load Balancing.7. The CAC algorithm makes an admission decision based on the resource status of the cell.If the admission attempt is successful, the RNC initiates an inter-frequency blind handover to the cell.If the admission attempt fails, the RNC removes the cell from the candidate cells and then checks whether all candidate cells are tried.a. If there is any candidate cell not tried, the algorithm goes back to step 2 to try this cell.b. If all candidate cells haven been tried, then:If the service request is an HSPA one, the HSPA request falls back to a DCH one. Then, the algorithm goes back to step 1 to retry admission based on R99 service priorities.If the service request is a DCH one, the RNC initiates an inter-RAT DRD.For details about the CAC procedure, see 7 "Call Admission Control Algorithm."For details about inter-RAT DRD, see 6.4.5 "Inter-RAT DRD."9.4.5 Inter-RAT DRDWhen 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.Figure 9-19 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 if the "service handover" IE that is contained in the RAB assignment signaling assigned by the CN is set to "handover to GSM should be performed", then the RNC performs step 2. Otherwise, the service request undergoes preemption and queuing.9. The RNC generates a list of candidate DRD-supportive inter-RAT cells that fulfill the following requirement:

Here: is the cached CPICH Ec/N0 value included in the RACH measurement report. is the DRD threshold (DRDEcN0Threshhold).If the candidate cell list does not include any cell, the service request undergoes preemption and queuing.10. The RNC selects target GSM cells for the service request according to the blind handover priority. 11. If all admission attempts fail or the number of inter-RAT handover retries exceeds the value of DRMaxGSMNum, the service request undergoes preemption and queuing.

The RAN11.0 does not support inter-RAT DRD for RABs of combined services.The RAN11.0 does not support inter-RAT DRD for R99 PS services.The RAN11.0 does not support inter-RAT DRD for HSPA services.9.5 PreemptionBy forcibly releasing the resources of lower-priority users, the preemption algorithm increases the access success rate of higher-priority users.After cell resourcebased admission fails, the RNC performs preemption if the following conditions are met:The RNC receives a RAB ASSIGNMENT REQUEST message indicating that preemption is supported.The preemption algorithm switch (PreemptAlgoSwitch) is set to ON.Preemption is applicable to the following scenarios:Setup or modification of a serviceHard handover or SRNS relocationUE state transition from CELL_FACH to CELL_DCHFor preemption, the RNC selects a suitable cell according to the settings of the DRD algorithms. Table 6-2 describes the selection of the target cell for preemption or queuing. Table 9-8 Selection of the target cell for preemption or queuingDRD Switch for Service SteeringPower-Based DRD Switch for Load BalancingCode-Based DRD Switch for Load BalancingTarget Cell for Preemption or Queuing

ONON-The cell with the lightest load among the cells with the highest service priority.

-ON

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

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

-ON

OFFOFFPreferably 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-3 describes the preemption for different types of service on different resources.Table 9-9 Preemption of different types of service on different resourcesServiceResourceService That Can Be Preempted

R99 ServiceHSUPA ServiceHSDPA ServiceR99+HSPA Combined Services

R99 serviceCode--

Power

CE-

Iub bandwidth

HSDPA serviceCode----

Power-

CE----

Iub bandwidth-

HSUPA serviceCode----

Power--

CE-

Iub bandwidth-

To enable resource-triggered preemption for MBMS services, the MBMS preemption algorithm switch (MbmsPreemptAlgoSwitch) must be set to ON.For details about preemption of MBMS services, see the MBMS Parameter Description.The preemption procedure is as follows:1. The preemption algorithm determines the radio link sets to be preempted:a. Selects SRNC users first. If no user under the SRNC is available, the algorithm selects users under the DRNC.b. Sorts the preemptable users by user integrated priority, or sorts the preemptable RABs by RAB integrated priority.c. Determines candidate users or RABs.Only the users or RABs with priorities lower than the RAB to be established are selected. If PriorityReference is set to Traffic Class and PreemptRefArpSwitch is set to ON, only the ones with 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 selects the user or RAB that can release the most resources.

The preemption algorithm checks whether the resources released by preempted UEs or RABs are sufficient for setting up new RABs. It does not consider the remaining resources in the cell, because they may be used by other UEs during the preemption. 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.13. The RNC releases the resources occupied by the candidate users or RABs.14. The requested service directly uses the released resources to access the network without admission decision.9.6 QueuingWhen the queuing algorithm is enabled through QueueAlgoSwitch parameter and the RNC receives a RAB ASSIGNMENT REQUEST message, indicating that the queuing function is supported, the RNC triggers queuing actions if preemption fails. The queuing algorithm is triggered by the heartbeat timer that equals 500 ms. Each time the timer expires, the RNC selects the service that meets the requirement to make an admission attempt. The queuing algorithm takes the following actions: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 decides whether to put the request into the queue, as described in Table 6-4.Table 9-10 Putting the new request into the queueIf the queue is...Then the queuing algorithm...

Not fullStamps this request with the request time (T_request).Puts this request into the queue.Starts the heartbeat timer if it is not started.

FullChecks whether the integrated priority of any existing request is lower than that of the new request.If yes, then the queuing algorithm: Checks the queuing time of each request. The algorithm removes the request with the longest queuing time from the queue. Stamps the new request with the request time (T_request) and then puts it into the queue. Starts the heartbeat timer if it is not started. If no, then the queuing algorithm rejects the new request directly.

After the heartbeat timer expires, the queuing algorithm performs resource-based admission attempts as follows: Rejects the request if the queuing time of the request, Telapsed, is longer than the maximum queuing time (MaxQueueTimeLen). Here, Telapsed is equal to the current time minus the request time (T_request).Selects the request with the highest integrated priority for a resource-based admission attempt.If more than one service has the highest integrated priority, the RNC selects the request with the longest queuing time for a power-based admission attempt. If the attempt is successful, the heartbeat timer is restarted for the next processing.If the attempt fails, the queuing algorithm proceeds as follows: Puts the service request back into the queue with the request time (T_request) unchanged for the next attempt.Selects the request with the longest queuing time from the rest and makes another attempt until a request is accepted or all requests are rejected.9.7 Low-Rate Access of the PS BE ServiceIf the PS_BE_EXTRA_LOW_RATE_ACCESS_SWITCH subparameter of the PsSwitch parameter is set to 1, the PS BE service can access the target cell at a low rate in the case of a preemption or queuing failure to increase the access success rate. Low-rate access means access from the DCH at 0 kbit/s, FACH, or enhanced FACH (E-FACH). Low-rate access is used in the following scenarios:RAB setupHard handover or relocationAfter a service request is rejected, the low-rate access actions in different scenarios are as follows:ScenarioScenario DescriptionFACH/E_FACHDCH at 0 kbit/s

RAB setupThe RRC connection is set up on the FACH or E-FACH.

The RRC connection is set up on the DCH.

The RRC connection is set up on the HSPA channel.

Combined servicesHard handover or relocation is performed for the CS+PS combined services. (Note 1)

Hard handover or relocation is performed for the PS+PS combined services.

The CS service is set up, and a new PS service is to be set up.

The existing PS service is set up on the FACH/E-FACH, and a new PS service is to be set up.

The existing PS service is set up on the DCH, and a new PS service is to be set up.

The existing PS service is set up on the HSPA channel, and a new PS service is to be set up. (Note 2)

The PS service is set up, and a new CS service is to be set up.

Note 1: In this scenario, only the PS service can be admitted at 0 kbit/s. Note 2: In this scenario, the new PS service can be admitted at 0 kbit/s, and the existing service are not affected. After an appropriate access action is determined, the service attempts to access the network. If the action of access from the DCH at 0 kbit/s is determined, the service attempts to access the network at 0 kbit/s for traffic and at the normal rate for signaling. For details about the methods of resource-based admission decision, see 7 "Call Admission Control Algorithm."If the action of access from the FACH/E-FACH is determined, the service attempts to access the network from the FACH/E-FACH. If the attempt fails, this service is rejected. For the service that accesses the network at 0 kbit/s, the ZeroRateUpFailToRelTimerLen timer is started after the service rate fails to increase for the first time. If the rate fails to increase even when the timer expires, the service is released, and the connection is also released for a single service. If no data is transmitted during a period after the access, the UE state changes to another state. For details about state transition, see the Rate Control Parameter Description. 9.8 IAC for Emergency CallsTo guarantee successful access of emergency calls, the RNC takes special measures for emergency calls.9.8.1 RRC Connection Setup Process of Emergency CallsCompared with the RRC connection setup process of ordinary services, the RRC connection setup process of emergency calls incorporates the preemption due to hard resourcebased admission failure. Hard resources include code, Iub, and CE resources. Figure 6-11 shows the RRC connection setup process of an emergency call.Figure 9-20 RRC connection setup process of an emergency call

To guarantee a successful admission of an emergency call, the RNC does not perform RRC redirection for service steering. In the case of power-based admission, the emergency call is admitted regardless of whether the CAC algorithm is enabled or not.In the case of hard resourcebased admission, the emergency call is admitted if the current remaining resources are sufficient for RRC connection setup. If the admission fails, preemption is performed regardless of whether the preemption is enabled or not. The emergency call that triggers preemption has the highest priority. The range of users that can be preempted is specified by the EmcPreeRefVulnSwitch parameter.If EmcPreeRefVulnSwitch is set to ON, all non-emergency users that have accessed the network can be preempted, regardless of the preemption-prohibited attribute of the users.If EmcPreeRefVulnSwitch is set to OFF, only the non-emergency users with preemption-allowed attribute can be preempted.The principles for selection of specific users to be preempted are the same as those for ordinary services. For details, see 6.5 "Preemption."9.8.2 RAB Process of Emergency CallsCompared with the RAB process of ordinary services, the RAB process of emergency calls incorporates special processing of resource-based admission and preemption.RAB Admission of Emergency CallsIn case of power resources:If the CAC algorithm is enabled, regardless of which algorithm is selected, the admission decision-making is as follows:When the EMC_UU_ADCTRL subparameter of the NBMCacAlgoSwitch parameter is set to 1, power-based admission fails if the system is in the overload congestion state. Otherwise, the admission succeeds.When this subparameter is set to 0, 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-based admission is successful if the current remaining resources are sufficient for the request.Preemption of Emergency CallsIf cell resourcebased admission fails, preemption is performed regardless of whether the preempt algorithm is enabled or not. The emergency calls that trigger preemption have the highest priority. The range of users that can be preempted is specified by the EmcPreeRefVulnSwitch parameter.If EmcPreeRefVulnSwitch is set to ON, all non-emergency users that have accessed the network can be preempted, regardless of the preemption-prohibited attribute of the users.If EmcPreeRefVulnSwitch is set to OFF, only the non-emergency users with preemption-allowed attribute can be preempted.The principles for selection of specific users to be preempted are the same as those for ordinary services. For details, see 6.5 "Preemption."10 11 Call Admission Control AlgorithmAs 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 or not. If the system resources are sufficient, the access request is accepted; otherwise, the access request is rejected.This chapter consists of the following sections:CAC OverviewCAC Based on Code ResourceCAC Based on Power ResourceCAC Based on NodeB Credit ResourceCAC Based on Iub ResourceCAC Based on the Number of HSPA Users11.1 CAC OverviewThe CAC algorithm consists of CAC based on code resource, CAC based on power resource, CAC based on NodeB credit resource, CAC based on Iub resource, and CAC based on the number of HSPA users.A CAC procedure involves admission decision for RRC connection setup request and RAB admission decision.Figure 7-1 shows the basic procedure of resource-based admission decision.Figure 11-21 Basic procedure of resource-based admission decision

The admission decision is based on:Available cell code resourceAvailable cell power resourceNodeB resource state, that is, NodeB credits, which are used to measure the channel demodulation capability of NodeBsAvailable Iub transport layer resource, that is, Iub transmission bandwidthNumber 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 resourcebased admission control, the admission control based on any other resource can be disabled through the ADD CELLALGOSWITCH command.Some CAC algorithm switches are set by the NBMCacAlgoSwitch parameter. Power-based admission decision switches are set by the NBMUlCacAlgoSelSwitch and NBMDlCacAlgoSelSwitch parameters.11.2 CAC Based on Code ResourceWhen a new service attempts to access the network, code resourcebased admission is mandatory.Code resourcebased admission is implemented as follows:For RRC connection setup requests, the code resourcebased admission is successful if the current remaining code resource is sufficient for RRC connection setup.For handover services, the code resourcebased admission is successful if the current remaining code resource is sufficient for the service.For other R99 services, the RNC has to ensure that the remaining code does not exceed the DlHoCeCodeResvSf parameter after admission of the new service.For HSDPA services, the reserved codes are shared by all HSDPA services. Therefore, the code resourcebased admission is not required.For details about HSDPA code allocation, see the HSDPA Parameter Description.11.3 CAC Based on Power Resource11.3.1 OverviewPower-based admission decision involves admission decision for RRC connection setup request as well as RAB admission decision based on algorithms 1, 2, or 3.The algorithm switches are set by the NBMUlCacAlgoSelSwitch or NBMDlCacAlgoSelSwitch algorithm.

To enable the power-based admission control for HSDPA/HSUPA, the HSDPA_UU_ADCTRL or HSUPA_UU_ADCTRL subparameter must also be set to 1.Algorithm 1 (ALGORITHM_FIRST): admission decision based on predicted load increment upon admission of a new serviceBased on the current cell load (indicated by the uplink load factor and downlink TCP) and the predicted load increment due to admission of the new service, the RNC determines whether the cell load will exceed the threshold upon admitting the new service. If yes, the RNC rejects the access request. If not, the RNC accepts the access request. Algorithm 2 (ALGORITHM_SECOND): admission decision based on the ENUDepending on the current ENU and the access request, the RNC determines whether the ENU will exceed the threshold upon admitting a new service. If yes, the RNC rejects the request. If not, the RNC accepts the request.Algorithm 3 (ALGORITHM_THIRD): admission decision based on no load increment upon admission of a new serviceThis algorithm assumes that load increment upon admission of a new service is 0. Based on the current cell load (indicated by the uplink load factor and downlink TCP), the RNC determines whether the cell load will exceed the threshold upon admitting the new service. If yes, the RNC rejects the access request. If not, the RNC accepts the access request.

When NBMUlCacAlgoSelSwitch is set to ALGORITHM_OFF and the uplink OLC algorithm switch (UL_UU_OLC) is enabled, the following cases occur if the cell is in the OLC state triggered by the RTWP:If the Control RTWP Anti-interfence algorithm switch (RsvdBit1) is enabled, the system checks whether the uplink equivalent user load proportion of the cell is lower than 40%. If it is lower than 40%, the access request is accepted. Otherwise, the original algorithm procesure reamins unchanged.If the Control RTWP Anti-interfence algorithm switch is disabled, the RNC rejects the access request.Figure 7-2 shows the basic procedure of power-based admission decision.Figure 11-22 Basic procedure of power-based admission decision

The basic principles of power-based admission decision are as follows:Four basic load thresholds are used for power-based admission decision. They are:UL/DL access threshold for handover (UlNonCtrlThdForHo or DlHOThd)UL/DL threshold of conversational AMR service (UlNonCtrlThdForAMR or DlConvAMRThd)UL/DL threshold of conversational non-AMR service (UlNonCtrlThdForNonAMR or DlConvNonAMRThd)UL/DL threshold of other services (UlNonCtrlThdForOther or DlOtherThd)With these thresholds, the RNC defines the proportion of speech service to other services while ensuring handover preference.Admission control involves uplink admission control and downlink admission control. The corresponding admission control switches NBMUlCacAlgoSelSwitch and NBMDlCacAlgoSelSwitch 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 setup request, the RNC performs DRD or redirection.For a rejected service request, the RNC performs preemption or queuing according to the actual situation.11.3.2 Admission Decision for RRC Connection Setup RequestTo ensure that the RRC connection setup request is not denied by mistake, tolerance principles are applied.The admission decision for RRC connection setup request is as follows:When power-based admission is based on power or interference (algorithm 1 and algorithm 3):For the RRC connection setup request for the reason of emergency call, detach or registration, direct admission is used.For the RRC connection setup request for other reasons, the UL or DL OLC trigger threshold (UlOlcTrigThd or DlOlcTrigThd) is used for admission. For details about UL and DL OLC trigger thresholds, see 10.1 "OLC Triggering."When power-based admission is based on the ENU (algorithm 2):For the RRC connection setup request for the reason of emergency call, detach or registration, direct admission is used.For the RRC connection setup request for other reasons, the admission decision is made as follows:a. When UL_UU_OLC or DL_UU_OLC is set to 1, RRC connection setup request is rejected when the cell is in the overload congestion state. If the cell is not in the overload state, the UL or DL OLC trigger threshold is used for power-based admission.b. When UL_UU_OLC or DL_UU_OLC is set to 0, the UL or DL OLC trigger threshold is used for power-based admission.11.3.3 Power-Based Admission Algorithm 1Power-based admission decision based on algorithm 1 consists of uplink powerbased admission decision and downlink power-based admission decision procedures.Uplink PowerBased Admission Decision for R99 Cells Based on Algorithm 1Figure 7-3 shows the procedure of uplink powerbased admission decision for R99 cells.Figure 11-23 Uplink powerbased admission decision for R99 cells

The procedure of uplink powerbased 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.3. The RNC calculates the uplink load increment UL based on the service request.4. The RNC uses the following formula to predict the uplink load factor:UL,predicted = UL + UL + ULcchIn the formula, ULcch is specified by UlCCHLoadFactor.

The uplink load increment UL is determined by the following factors:Eb/N0 of the new incoming call, which has a positive correlation with the uplink load incrementUL neighbor interference factor, which has a positive correlation with the uplink load incrementActive Facto