Capacity Management - WCDMA RAN

1 Introduction

Ericsson's WCDMA RAN (Wideband Code Division Multiple Access Radio Access Network) Capacity Management solution, with support from other radio network functions, controls the stability and accessibility in the WCDMA cell. This enables the system to provide the requested Quality of Service (QoS) and coverage for individual connections. Capacity Management functions by:

• Monitoring the utilization of a selected set of system resources and estimating the required resources for the new and changed radio connections in the system
• Enforcing the admission policies on a selected set of system resources
• Detecting and resolving overload situations of a selected set of system resources

1.1 Scope

As a high-level description, this document explains the capabilities, function and logic of the Capacity Management solution. It also describes parameters and engineering guidelines related to the Capacity Management solution.
The documents Operation and Maintenance, Reference [10] and System Performance Statistics, Reference [13] describe Performance Observability of Capacity Management functions.
The terminology used in this document is explained in Glossary of Terms and Acronyms, Reference [3].
The utilization of transport resources is not monitored by the Capacity Management functionality, see Transport Network Functionality, Reference [14] for more information.

1.2 Target Groups

This User Description describes WCDMA RAN Capacity Management functionality from a user point of view. Written mainly for operators, this document serves as an important starting point for those who want to understand the functionality in more detail, in order to optimize the parameter settings.
It is assumed that users of this document:

• Are familiar with WCDMA basic knowledge
• Have a working knowledge of 3G telecommunication

1.3 Revision Information

Apart from editorial changes, this document has been revised as follows:

Table 1 Revision History

Revision	Reason for revision	P7.0
A	First release for P7, updates from P6 are: Chapter 3.2.3.8 updated with extended number of HSDPA users Table 3 updated to include IF/IRAT mobility on HSPA

2 Overview

Ericsson's WCDMA RAN Capacity Management solution controls the load in the WCDMA cell. This makes it possible for the system to provide the requested QoS and coverage for individual connections. Each cell or group of cells has its own set of Capacity Management functions responsible for monitoring and controlling the resources of that cell. The Capacity Management solution consists of three main functions:

• System Resources Handling
• RN Admission Control
• RN Congestion Control

Figure 1 shows the general overview of Capacity Management functions.

Figure 1 General Overview of Capacity Management Functions

2.1 System Resource Handling

The System Resource Handling function collects and provides information about the current usage of a selected set of system resources that are relevant for the stability and accessibility of a WCDMA cell. This is done by performing measurements and keeping track of every Radio Connection setup, addition, deletion, and modification in the cell.
A technical description together with the set of System Resources can be found in Section 3.1. In the remainder of this document the term system resource is used and refers to resources within the selected set.

2.2 RN Admission Control

The RN Admission Control function blocks or admits resource requests according to admission policies defined on system resources. Those requests are initiated for example when new radio connections are set up, cell changes performed, existing radio connections are modified or soft handover is performed. To decide on whether to admit the request, the RN Admission Control function requires information about the system resource load and the amount of resources needed by the requester. This information is provided by the System Resource Handling function.
RN Admission Control policies can differentiate accessibility of system resources dependent on the characteristics of the request (e.g. the request relates to set up of a new radio connection or a handover of an existing radio connection etc.), allowing reservation of system resources for high priority connections and for mobility.
To be able for the system to balance the available resources between radio connections in case of lack of system resources, RN Soft Congestion is used, see Section 3.2.2. When admitting a request, RN Soft Congestion evaluates whether to reduce the rate of one or more existing low priority users or whether to pre-empt one or more Radio Access Bearers (RABs) (implies the release of the RAB).
In case of admission reject, RN Admission Control is not taking any further actions in terms of asking for admission again, it is up to the requesting function to retry on a lower rate, for example such as the Handover function, see Reference [5].

2.3 RN Congestion Control

For most systems resources, the radio connections utilizing the resource never use more of the resource than was admitted. In those cases the RN Admission Control functionality is sufficient to control the resource utilization. For some system resources, such as UL interference and DL transmitted carrier power, admitted radio connections may dynamically utilize more of the resource, depending on for example the radio conditions, and can cause overload. Resource overload threatens the QoS of connections and the stability of the system. In those cases, RN Admission Control alone is not sufficient and additional control is needed to deal with overload on the resource.
The RN Congestion Control functionality detects and resolves three types of overload:

• UL Overload: The UL interference in a cell reaches a critical level and the RN Congestion Control blocks all admission requests in the cell, except for handover of connections (as they typically contribute to the lowering of the UL interference). The situation is restored when the UL interference is back to acceptable levels.
• DL Overload: The non-HSDPA DL transmitted carrier power in a cell reaches critical levels and the RN Congestion Control blocks all admission requests in the cell, while congestion resolve actions are taken to reduce the resource utilization. The situation is restored when non-HSDPA DL transmitted carrier power level is back to acceptable levels.
• DL HSDPA Overload: The DL transmitted carrier power available for radio connections on HSDPA is not sufficient to meet their QoS. The RN Congestion Control will start congestion resolve actions to re-balance the resource utilization between the radio connections on HSDPA and release 99 channel, while selectively blocking admission requests in the cell. Note that for HSDPA overload it considers non-GBR users as well as GBR users.

2.4 Connection to other Functions

Other functions interact with RN Admission Control and RN Congestion Control during admission requests or overload situations, those functions are:

• Channel Switching, see Reference [1]. To free up requested resources or for overloaded situation, RN Admission Control or RN Congestion Control can reduce the rate of lower priority users by switching them to a lower rate or to common channel depending on the situation.
• RAB Release, see Reference [2]. To free up requested resources RN Admission Control or RN Congestion Control can release lower priority users RABs.
• Connection Handling, see Reference [2]. To free up requested resources RN Admission Control or RN Congestion Control can release lower priority users signalling connection.

2.5 Allocating Functions

Figure 2 illustrates the allocation of the Capacity Management functionality in the WCDMA node architecture. There is one instance of Capacity Management functionality for each cell, and each instance is located in the Controlling Radio Network Controller (CRNC).

Figure 2 Capacity Management Architecture Overview

In general, once a radio connection is established, the Serving RNC (SRNC) is responsible for handling the connection between the User Equipment (UE) and UTRAN (standardized term for WCDMA sub-network) until it is released. When the UE needs to establish a radio link in a cell connected to the same physical RNC, internal interfaces are used to interact with the RN Admission Control, RN Congestion Control, and System Resource Handling functions. When the UE needs to establish a radio link in a cell connected to another physical RNC , the external Iur interface is used to interact with the set of Capacity Management functions in that cell, as this functionality for that cell is located in that RNC.

Figure 3 describes the process that involves RN Admission Control when a RAB request arrives from the Core Network (CN) by means of the Iu interface.

Figure 3 RAB Request Over the Iu Interface

1. The CN requests the SRNC to establish a RAB with an indicated set of QoS parameters. This is received by means of the Radio Access Network Application Part (RANAP) message over the Iu interface.
2. According to the QoS parameters, the requested service is mapped on to a set of Radio Bearers (RBs).
3. The required amount of system resources is estimated and the CRNC requests admission for those resources.
4. If the request is admitted, the CRNC allocates the necessary resources.
5. The CN is informed about the result of the RAB establishment process. This is done by means of the RANAP message over the Iu interface.

Figure 4 shows the process that involves RN Admission Control when the radio link setup request arrives over the Iur interface.

Figure 4 RAB Request Over the Iur Interface

1. A request to establish the radio link is sent from the SRNC to the CRNC. This is done by means of a RNSAP (Radio Network Subsystem Application Part) message over the Iur interface.
2. The RNSAP information is converted into admission request attributes.
3. The required amount of system resources is estimated and the CRNC requests admission for those resources.
4. If the request is admitted, the CRNC allocates the necessary resources.
5. The CRNC informs the SRNC of the results of the admission process. This is done by means of the RNSAP message over the Iur interface.

3 Technical Description

The set of Capacity Management functions consists of: System Resource Handling, RN Admission Control and RN Congestion Control. Together, these functions control the load in order to provide the coverage and QoS for individual connections.

3.1 System Resource Handling

The following set of system resources are relevant within the Capacity Management scope:
Per Cell:

• Downlink channelization codes
• Downlink transmitted carrier power, non-HS part and HS-required part
• Air Interface Speech Equivalents (ASE) in uplink and downlink
• Uplink Received Total Wideband Power (RTWP)
• The number of radio links per DL Spreading Factor (not including the codes (spreading factor = 16) reserved for or used by HSDPA connections)
• The number of radio links per UL Spreading Factor (not including codes used by EUL)
• The number of radio links in compressed mode
• The number of serving HS connections
• The number of serving EUL connections
• The number of serving 2 ms TTI EUL connections
• The number of non-serving EUL connections

Per Hardware Pool:

• RBS hardware utilization in uplink (both DCH and EUL) and downlink (both DCH and MTCH)

To monitor the system resources, Capacity Management performs periodic and event based measurements and keeps track of every radio connection setup, deletion and modification in a cell.

3.1.1 Downlink Channelization Codes Monitor

The Downlink Channelization Code Monitor provides a measure for code tree utilization in the downlink. The monitoring of this dedicated resource is based on tracking the fraction of the downlink code tree in use. The fraction of codes in use is calculated as follows:
(Sum _user (1 / SF _user) + Sum _cch ( 1 / SF _cch))/(1–p/16)

Where:

SF user		is the DL spreading factor relating to the set of DCHs of the user (including the A-DCHs)
SF CCH		is the spreading factor of the common control channels including HS-SCCH, E-HICH, E-RGCH, E-AGCH as well as MTCH, MICH and MCCH channels for MBMS
p		is the number of DL codes reserved (SF = 16) for HS-DSCH it is set by the parameter numHsPdschCodes see Section 3.4.5

3.1.2 Downlink Transmitted Carrier Power Monitor

The DL transmitted carrier power in a cell is one of the system resources monitored by the RAN capacity management. The intention of the monitoring is to serve as:

• As basis for RN Admission Control in admitting requests for setup or re-configuration of the radio connection. This is accomplished by the RBS measuring non-HSDPA and HS-required DL transmitted carrier power of a cell periodically, reporting (each second) the measurement to the CRNC, and filtering the measurement in the CRNC to follow the trend of the utilization.
• As a basis for RN Congestion Control in detecting both the occurrence and resolving DL overload on the non-HSDPA DL transmitted carrier power. This is accomplished by the RBS reporting the event of the non-HSDPA DL transmitted carrier power in a cell exceeding a level for some time, and reporting the event of the non-HSDPA DL transmitted carrier power in a cell getting below that level for some time, to the CRNC.
• As a basis for RN Congestion Control in detecting both the occurrence and the resolving of DL HS overload on the DL transmitted carrier power. This is accomplished by the RBS measuring the HS-required carrier power in a cell periodically and reporting (each second) the measurement to the CRNC. The CRNC will use the combination of this measurement and the non-HSDPA DL transmitted carrier power measurement to detect both the occurrence and resolving of the DL HS overload. For more details on how the HS-required power is determined see HSDPA User Plane, Reference [8].
• As basis for the initial rate selection see Section 3.6 and the directed retry functionality (see Connection Handling, Reference [2]). This is accomplished by the RBS measuring non-HSDPA and HS-required DL transmitted carrier power of a cell periodically, reporting (each second) the measurement to the CRNC, and filtering the measurement in the CRNC to follow the trend of the utilization.

Note that part of the DL transmitted carrier power resource is monitored and controlled by the HSDPA scheduler on TTI basis, see HSDPA User Plane, Reference [8]. Also note that the HSDPA-required power may consist of the power required for guaranteed bit rate connections, as well as a minimum power reserved for non-guaranteed bit rate connections, see HSDPA User Plane, Reference [8]

3.1.3 ASE Monitor

The ASE intends to express to some extent the static load on the air-interface caused by radio bearers in a connection in a cell relative to the static load caused by a set of radio bearers carrying a regular conversational CS speech 12.2 kbps RABs.
The general definition of the ASE for a connection is as follows:
ASE = (effective rate DCH + guaranteed rate HS-DSCH + guaranteed rate E-DCH + guaranteed rate MBMS) / (effective rate conv CS speech 12.2 kbps)
Where (see Table 2 for example ASE values):

• effective rate DCH: the effective rate DCH is the sum of the effective rate of dedicated transport channels in a radio connection (including SRB) based on the Transport Format Set, Transport Format Combination Set, and number of Transport Blocks.
• guaranteed rate HS-DSCH: the guaranteed rate of the HS-DSCH mac-d flows in a radio connection
• guaranteed rate E-DCH: the guaranteed rate of the E-DCH mac-d flows in a radio connection
• guaranteed rate MBMS: the guaranteed rate of the MBMS traffic channels MTCH and control channels MCCH and MICH
• effective rate conv CS speech 12.2 kbps: the effective rate of the dedicated transport channels used for conversational CS speech 12.2 kbps, considering an activity factor of 0.5

The ASE Monitor algorithm monitors ASE usage at cell carrier level, separately for uplink and downlink. For connections having radio links in different cells, the ASE UL contribution in each cell is taken to be the ASE UL of the connection divided by the number of radio links of the connection within the RNC the cell is residing. The principle behind the division of ASE is that the average uplink interference created by a UE connection in a cell it is connected to, is proportional to the number of cells the UE is connected to. If, for example, a UE is connected to two cells, it only requires approximately half the Ec/No compared to using one cell. The background for considering only the cells within an RNC is the fact that it is not possible to know the total number of radio links in a connection for connections originating over Iur. A consequence of the pre-RNC division is the possible overestimation of the ASE UL value for connections using Iur, compared to the situation where all radio links are within the same RNC.
Table 2 shows the values of ASE for some of the radio configurations. Section 3.2.1 describes the radio connection types included in the table.

Table 2 ASE Values for some Radio Links, as illustration (i.e. not a complete list)

Radio Connection Type	Uplink ASEs	Downlink ASEs
stand-alone SRB 13.6 kbps	0.45	0.45
conversational CS speech 12.2/12.2 kbps	1.12	1.12
conversational CS 64/64 kbps	10.61	10.61
streaming PS 16/64	4.25	10.10
interactive PS 64/384 kbps	7.83	39.78
conversational CS speech 12.2/12.2 kbps + interactive PS 64/64 kbps	8.83	8.83
interactive PS 64/HS kbps	7.83	0.12
MBMS ptm PS 0/64.8 kbps	0	10.62
MBMS ptm PS 0/129.6 kbps	0	21.25
MBMS ptm PS 0/259.3 kbps	0	42.49

3.1.4 Received Total Wideband Power Monitor

The uplink Received Total Wideband Power (RTWP) is monitored in order to provide information to RN Congestion Control regarding the uplink interference. Uplink interference fluctuates due to the number of users in the area, the service and type of radio connection of the users, and the radio conditions. However, as the RTWP measurement does not provide the absolute accuracy for a proper decision (~+/- 2.5 dB), the uplink ASE is an additional measure to be used as a basis for RN Admission Control in uplink.
Since the ASE in uplink is only representing the own interference and not variations in external interference or party-effects, the uplink RTWP is used by RN Congestion Control in order to control these dynamic effects and block the setup or modification of new RABs. In order to detect an uplink overload situation, event-based measurements are performed in the RBS; if a predefined level is exceeded, uplink congestion is detected in a cell.

3.1.5 RBS Hardware Monitor

The available RBS hardware is a limited resource due to, for example, the amount of installed hardware or licensing restrictions (see Handling of License Control, Reference [4]). The hardware utilization in uplink and downlink is monitored by the RBS Hardware Monitor, by means of the capacity credit and consumption law mechanism, as standardized in UTRAN Iub Interface NBAP Signalling, Reference [15].
The monitor is based on that each HW pool in the RBS provides the total amount of available Channel Elements (CE) for dedicated channels and a set of consumption laws, separate for UL and DL, to the CRNC. The definition of these consumption laws is connected to the HW cost-model of the RBS. There may be different cost models for different channels types and for different RBSs (depending on HW type used), and therefore the HW cost-model in uplink may differ. The default uplink DCH cost-model for an RBS may be changed by means of the 'UL CE-ladder' feature key, see Section 3.5.
The estimation of hardware usage of an RBS is performed as follows:
HW _dl= (Sum _rls (CE _{rls dl}) + Sum _MTCH (CE _MTCH) + Sum _MCCH (CE _MCCH) + Sum _MICH (CE _MICH)) / total CE _dl
HW _ul= Sum _rls (CE _{rls ul}) / total CE _ul
Where:

HW dl		is the total hardware usage in downlink
CE rls dl		is the number of CE in downlink used by a radio link set
total CE dl		is the total available CE in downlink (as reported by the RBS)
HW ul		is the total hardware usage in uplink
CE rls ul		is the number of CE in uplink used by a radio link set.
total CE ul		is the current total available CE in uplink (as reported by the RBS)
CE MTCH		Is the current number of CE used by a MBMS point to multipoint (ptm) traffic channel
CE MCCH		Is the current number of CE used by a MBMS ptm control channel
CE MICH		Is the current number of CE used by a MBMS ptm control channel

The initial RBS hardware capacity (in terms of total available uplink and downlink capacity CE) and the corresponding radio link set consumption laws are reported at RBS initialization, in case the RBS hardware capacity changes, or in case the license changes. Each radio connection setup, deletion and modification in a cell that indicates a change of spreading factor is tracked by calculating the change in CE in uplink and downlink and updating the monitor accordingly.

3.2 RN Admission Control

When new resources are needed for a radio connection, the RN Admission Control function receives a request for admission. The request specifies the estimated amount of system resources that the radio connection needs. The request is evaluated by one or more admission policies. A response is sent out to grant or deny the new resource request.
RN Admission Control has different policies judging for each resource whether a request can be admitted or should be rejected. If no resources are available, the RN Soft Congestion functionality may free resources of existing radio connections and thereby enable the request.
Each admission policy monitors the resource against an Admission Level and a Max Level, see Figure 5.

Figure 5 Admission and Max Level concept

• Up till the Admission Level, the request is admitted
• Between the Admission and Max Level, (guaranteed, non-handover) or (non-guaranteed, non-handover/handover) requests are not admitted unless RN Soft Congestion actions can find the required resources to release.
• Up till the Max Level (guaranteed, handover) requests are admitted (if physical resources are available). RN Soft Congestion action is triggered, but it is not a condition for admission.

3.2.1 Admission Request Attributes

To decide which admission policy to evaluate and how to treat the admission request in case one or more admission policies are blocking, each admission request contains a number of attributes:

• The request type, indicating whether the request for resources concerns a handover of a connection or not (used in the evaluation of admission policies).
• The request class, indicating whether the request for resources concerns a request for guaranteed rate connection parts or non-guaranteed connection parts (used in the evaluation of admission policies). A request is guaranteed when requesting minimum amount of resources for a radio connection satisfying its QoS (this is referred to lowest retainable rate). Example of a guaranteed request is CS conversational, CS or PS streaming and PS interactive 8/8. Guaranteed RABs with attribute GBR from CN are set to guaranteed request class. PS interactive is set to guaranteed only if it is accompanied to streaming service at 8 kbps. Otherwise it is non-guaranteed. When the request is for resources exceeding the minimum needed for satisfying the QoS (for example up-switch interactive PS to a higher dedicated rate), the request is non-guaranteed. Example of a non-guaranteed request is PS interactive.
• The pre-emption capability of the request, indicating whether this request can preempt a lower priority (part of a) radio connection or not in case of resource shortage. Pre-emption results in the release of one or more RABs according to their priority and pre-emption vulnerability settings, see QoS Configuration, Reference [18]
• The priority of the request
• Indication of additional resources required, including additional UL/DL channelization codes, UL/DL ASE, etc.

A number of these admission request attributes are determined from Allocation Retention Priority (ARP) attributes. ARP attributes are by default defined statically as function of RANAP attributes, or can optionally be defined by the operator, see QoS Configuration, Reference [18] for more details. Depending on the RANAP attributes the ARP table determines:

• The priority level (1.. 15) where value 15 means 'no priority' and 1 is highest priority.
• The pre-emption capability indicator (PCI) which consists of two values, 'shall not trigger pre-emption' and 'may trigger pre-emption' (this indicates the pre-emption capability of the request).
• The pre-emption vulnerability indicator (PVI) with the values “not pre-emptable” and “pre-emptable”. Note that the pre-emption vulnerability indicates whether a RAB in the connection can be released due to the admission of a higher priority, pre-emption capable request or not.

The default mapping of the ARP attributes is based on the traffic class (conversational, streaming, interactive, background), CN indicator (CS/PS), Source Statistics Descriptor (SSD) (speech). All examples below are derived from the default mapping table, the mapping and the default mapping table are described in the QoS Configuration, Reference [18]

The admission request attributes are determined depending on the parts for the radio connection for which additional resources are needed. For example, in case the radio connection includes a conversational CS speech RAB and interactive PS RAB, a re-configuration of the interactive PS connection part would lead to determination of the request attributes based on that connection part only. In case more connection parts are basis for request attribute determination, the following is applied:

• The request class is non-guaranteed if at least one of the connection parts for which admission is requested is non-guaranteed. For example when adding conv. CS Speech (guaranteed) and Interactive PS 64/64 (non-guaranteed, as PS 0/0 is a lower resource consuming alternative) the request class is non-guaranteed.
• The request priority is the highest ARP priority of the connection parts for which admission is requested (for example when requesting resources for conv. CS Speech (priority 3) and Interactive PS (priority 7), the request priority is 3.
• The preemption capability is set to capable in case at least one of the connection parts for which admission is requested is pre-emption capable.

3.2.2 RN Soft Congestion

RN Soft Congestion control is part of the RN Admission Control feature, and aims to increase the accessibility by admitting users in a cell in case of resource shortage, if a low priority user can lower its rate or be pre-empted.
The behavior of RN Soft Congestion control differs depending on the request class:
Non-guaranteed requests:

• Can reduce the rate of other lower priority, non-guaranteed connection parts in steps (for example from interactive PS 384/64 to interactive PS 128/64), down to their lowest retainable rate. Equal priority request and connection parts will equally balance their resource utilization (for example a request for interactive PS 64/64 can reduce the rate of an equal priority interactive PS 128/64 to interactive PS 64/64, but not to lower rates).

Guaranteed requests:

• Can reduce the rate of any priority, non-guaranteed connection parts in steps down to their lowest retainable rate. If that is not sufficient, RN Soft Congestion can pre-empt existing guaranteed RABs of lower priority, or non-guaranteed RABs at the lowest retainable rate if request is pre-emption capable and connection part targeted is pre-emption vulnerable (for example conv. CS Speech (priority=3, pre-emption capable) can pre-empt conv. CS unknown (priority=4, pre-emption vulnerable).

Note that in the current release of the product, RN Soft Congestion control does not target radio connections originating over Iur. Also note that MBMS control channels MCCH and MICH are not targeted.

3.2.3 Admission Policies

3.2.3.1 Introduction

Admission requests are evaluated for different system resources through admission policies. An admission policy is a set of rules on a system resource deciding whether a request for that resource shall either be:

• Admitted
• Blocked
• Conditionally blocked, that is when the request is admitted under condition that RN Soft Congestion can free the resources needed

The rules are expressed in terms of a certain combination of admission request attributes, the current resource utilization and thresholds. Whether an admission policy is evaluated for a certain admission request, depends on the admission request attributes, the admission policy evaluated can be summarized as in Table 3. Depending on the channel type of the requests, one or more admission policy is evaluated, for example the UL ASE Admission policy is evaluated for the channel type requests DCH/DCH, DCH/HSDPA and for EUL/HSDPA but not for MBMS (i.e “Yes” means that the policy will be evaluated and “No” means that the policy will not be evaluated).

Table 3 Summary of the Admission Policy Evaluation

Admission Policy	Channel type	Channel type	Channel type	Channel type
	DCH/DCH	DCH/HSDPA	EUL/HSDPA	MBMS
DL Ch Code Adm Policy	Yes	Yes (DL code for SRB part on DCH)	Yes (DL code for SRB part on DCH)	Yes
DL Power Adm Policy	Yes	Yes	Yes	Yes
DL ASE Adm Policy	Yes	Yes, (GBR-part on HSDPA and SRB-part on DCH)	Yes, (GBR-part on HSDPA and SRB-part on DCH)	Yes, (GBR-part on DCH)
UL ASE Adm Policy	Yes	Yes	Yes	No
DL SF Adm Policy	Yes, ( SF 8, 16, 32)	No	No	No
UL SF Adm Policy	Yes, ( SF 8, 16, 32)	Yes, ( SF 8, 16, 32)	No	No
CPM Adm Policy	Yes	Yes	Yes	No
Serving HS Adm Policy	No	Yes	Yes	No
Serving EUL Adm Poliicy	No	No	Yes	No
Non-serving EUL Adm Policy	No	No	Yes	No
DL RBS HW Adm Policy	Yes	Yes	Yes	Yes
UL RBS HW Adm Policy	Yes	Yes	Yes	No
MBMS Adm Policy	No	No	No	Yes

3.2.3.2 The Downlink Channelization Code Admission Policy

The Downlink Channelization Code Admission Policy is evaluated when DL channelization codes are requested.
The admission request can be granted in case the resource usage plus the additional spreading factor is below the admission level dlCodeAdm.

• Admission requests (non-guaranteed, non-handover/handover) or (guaranteed, non-handover) are conditionally blocked when the current DL channelization code is exceeding the dlCodeAdm level.
• Admission requests (guaranteed, handover) are blocked if the usage arrives at 100% utilization (RN Soft Congestion action triggered).

If HS-DSCH is activated and enabled in a cell, the code threshold dlCodeAdm will be based on the code tree, excluding the codes reserved for HS-DSCH.

3.2.3.3 The Downlink Transmitted Carrier Power Admission Policy

The Downlink Transmitted Carrier Power Admission Policy is evaluated in case additional DL transmitted carrier power is requested. The admission level is defined by the parameter pwrAdm.

• Admission requests (non-guaranteed, non-handover/handover) or (guaranteed, non-handover) are conditionally blocked when the monitored DL transmitted carrier power is exceeding the pwrAdm level
• Admission requests (guaranteed, handover) are blocked if the usage arrives at 100% utilization.
• Admission requests are blocked in case the cell is either in DL overload or in DL HSDPA overload and lower priority users are being targeted to free resources.

3.2.3.4 ASE Admission DL Policy

The ASE Admission Policy is evaluated in case the request indicates a need for additional ASE DL.

• Admission requests (non-guaranteed, non-handover/handover) and (guaranteed, non-handover) are conditionally blocked if the ASE downlink usage exceeds aseDlAdm .

• Admission requests (guaranteed, handover) are never blocked.

In the downlink, the downlink transmitted carrier power is the main system resource used to control the air interface load. The parameter aseDlAdm is a complement to the RN Admission Control when the cell can support so many users that it is close to the pole capacity, which can cause instability. Therefore, if the downlink transmitted carrier power is the limiting resource, aseDlAdm can be set very high, so it does not interfere with the control strategy used for the downlink transmitted carrier power.

3.2.3.5 ASE Admission UL Policy

The ASE Admission Policy is evaluated in case the request indicates a need for additional ASE UL.

• Admission requests (non-guaranteed, handover/non-handover) and (guaranteed, non-handover) are conditionally blocked if the ASE uplink usage exceeds aseUlAdm.

• Admission requests (guaranteed, handover) are never blocked.

3.2.3.6 Spreading Factor Admission Policy

The Spreading Factor Admission Policy is divided into DL and UL for Non-Guaranteed and Guaranteed Service Classes.
Non-Guaranteed Service Class Limits in Downlink
RN Admission Control blocks non-guaranteed request class requests in downlink, in case the resource usage plus the requested number of radio links per DL spreading factor usage in a cell is above the following load control levels. Figure 6 shows the policy comprising:

• Admission requests (non-guaranteed, handover/non-handover) demanding spreading factor 8 in downlink are blocked when the usage of this spreading factor exceeds sf8Adm.
• Admission requests (non-guaranteed, handover/non-handover) demanding spreading factor 16 in downlink are blocked when the usage of this spreading factor exceeds sf16Adm.
• Admission requests (non-guaranteed, handover/non-handover) demanding spreading factor 32 in downlink are blocked when the usage of this spreading factor exceeds sf32Adm.
• Guaranteed Service Class Limits in Downlink
  RN Admission Control blocks (guaranteed, handover/non-handover) admission in case the resource usage plus the requested spreading factor 16 in DL (for example, streaming PS16/128 radio connection type) if the usage of this spreading factor exceeds sf16gAdm.
  
  Non-Guaranteed Service Class Limits in Uplink
  RN Admission Control blocks non-guaranteed request class requests in uplink, in case the resource usage plus the requested number of radio links per UL spreading factor usage in a cell is above the following load control levels.
  
  • Admission requests (non-guaranteed, handover/non-handover) demanding spreading factor 4 in uplink (for example, PS384/HS radio connection type) if the usage of this spreading factor exceeds sf4AdmUl.
  • Admission requests (non-guaranteed,handover/non-handover) demanding spreading factor 8 in uplink if the usage of this spreading factor exceeds sf8AdmUl
  • Admission requests (non-guaranteed, handover/non-handover) demanding spreading factor 16 in uplink if the usage of this spreading factor exceeds sf16AdmUl
  
  Guaranteed Service Class Limits in Uplink
  RN Admission Control blocks (guaranteed, handover/non-handover) admission in case the resource usage plus the requested spreading factor 8 in uplink if the usage of this spreading factor exceeds sf8gAdmUl.
  
  

  3.2.3.7 Compressed Mode Radio Admission Policy

  The amount of radio links in compressed mode is monitored and RN Admission Control blocks admission requests for such a radio link when the current number of radio links exceeds the parameter compModeAdm. This is to limit the UL/DL air interface due to compressed mode.
  

  3.2.3.8 Serving HS Admission Policy

  RN Admission Control blocks new radio link admission requests which involve the allocation to HS-PDSCH/HS-SCCH when the number of users assigned to the HS-DSCH in the cell exceeds the load control level hsdpaUsersAdm. The parameter hsdpaUsersAdm should be set dependent on the maximum number of users that may simultaneously be served. This is determined by the parameter maxNumHsdpaUsers and the license level for number of HS-users.
  If a difference is set between the parameter hsdpaUsersAdm and the parameter maxNumHsdpaUsers there will be a margin, e.g., for mobility purposes, to avoid blocking HS-DSCH cell changes. Note that the Serving admission policy is only applied to requests for new HSDPA connections, which follow the Serving HS-DSCH Cell Selection during RAB Establishment. Therefore, requests related to mobility of existing HSDPA connections, which follow the Serving HS-DSCH Cell Change, are never blocked by the Serving HS admission policy. Also note that the margin for mobility purposes can only be secured if the RBS HW handles the total amount of users that are limited by the parameter maxNumHsdpaUsers. Configurations exist where the licenses/parameters can exceed instant HW resources and in these cases, admission policies will fail to maintain margins and rejects will come from the RBS instead. There may also be admission blocking of HS-DSCH users due to that there is a shortage of channel elements for A-DCH, (A-DCH channel elements resources are generally configured based on license level, max number of users parameters and number of HS-DSCH resources, but can also be configured through the parameter maxNumADchReservation. For more details see Configuring HSDPA and EUL, Reference [19].
  

  3.2.3.9 Serving and non-serving EUL Admission Policy.

  To monitor the number of users assigned to the physical EUL channels, two load control levels are defined by the eulServingCellUsersAdm and eulNonServingCellUsersAdm parameters. Both parameters include 2 ms TTI and 10 ms TTI.
  A request to use EUL is allowed up to a certain limit defined by a eulServingCellUsersAdm. RN Admission Control shall reject an EUL user, requesting the cell as serving cell if the total number of serving cell EUL users including the requested is above eulServingCellUsersAdm.
  EUL users can be in soft/softer handover. Since eulServingCellUsersAdm only includes serving cell users it is also possible to be able to limit the EUL users having the cell as non-serving cell. This is to be able to limit the amount of UL HW reserved for the non-serving connections. Therefore eulNonServingCellUsersAdm is used to be able to limit the number of EUL users having the cell as non-serving cell. RN Admission Control will reject an EUL user, requesting the cell as non-serving cell if the total number of non-serving cell EUL users including the requested is above eulNonServingCellUsersAdm.
  
  EUL connections using a TTI of 2 ms use more radio resources than EUL connections using a TTI of 10 ms. For that reason, a separate admission threshold eulServingCellUsersAdmTti2 is used to limit the number of EUL connections in a cell using a TTI of 2 ms. The parameter eulServingCellUsersAdmTti2 is a 2 ms TTI limit within the set of eulServingCellUsersAdm which contains both 2 ms TTI and 10 ms TTI.
  

  3.2.3.10 The RBS Hardware DL Admission Policy

  The RBS Hardware Monitor provides RN Admission Control with the estimation of the hardware usage per radio link type in a cell for the downlink. The admission level is defined by the parameter dlHwAdm for DL.
  
  • (Non-guaranteed, non-handover/handover) and (guaranteed, non-handover) admission requests are conditionally blocked when the resource usage exceeds the dlHwAdm level.
  • (Guaranteed, handover) admission requests are blocked when the downlink hardware usage arrives at 100% utilization (of the licensed value) (RN Soft Congestion is triggered).
  Note that the RN Soft Congestion mechanism on the DL HW resource will consider the connections in the related cells on cell group level as possible targets. For example, if an admission request is blocked on DL HW, connections in the cells connected to the same HW group are possibly targeted
  

  3.2.3.11 The RBS Hardware UL Admission Policy

  The RBS Hardware Monitor provides RN Admission Control with the estimation of the hardware usage per radio link type in a cell for the uplink . The admission level is defined by the parameter ulHwAdm for UL.
  
  • (Non-guaranteed, non-handover/handover) and (guaranteed, non-handover) admission requests are conditionally blocked when the resource usage exceeds the ulHwAdm level.
  • (Guaranteed, handover) admission requests are blocked when the uplink hardware usage arrives at 100% utilization (of the licensed value) (RN Soft Congestion is triggered).
  Note that the RN Soft Congestion mechanism on the UL HW resource will consider the connections in the related cells on cell group level as possible targets. For example, if an admission request is blocked on UL HW, connections in the cells connected to the same HW group are possibly targeted.
  

  3.2.3.12 The MBMS Admission Policy

  The MBMS admission policy is evaluated in case the MBMS traffic channel (MTCH) is established in a cell. In case the maximum amount of preferred layer sessions or non-preferred layer sessions is exceeded in the cell, the request will trigger RN Soft Congestion actions towards lower priority MBMS sessions.
  

  3.3 RN Congestion Control

  The RN Congestion Control function detects and resolves overload situations on certain system resources. It consists of three types, UL overload, DL overload and DL HSDPA overload see Section 2.3. Capacity Management has been updated to remove the differentiation of the guaranteed-hs connection types as separate class. As a consequence, the interactive/background PS services mapped on HS are not targeted during a DL cell congestion situation, while guaranteed services are targeted according to the guaranteed class differentiation settings.
  

  3.3.1 Congestion Detection

  Congestion detection is triggered by UL cell congestion, DL cell congestion and DL HSDPA congestion detection.
  

  3.3.1.1 Uplink Cell Congestion Detection

  As shown in Figure 7, congestion due to radio overload in uplink is detected when the UL RWTP exceeds a certain configurable threshold for a longer time than the hysteresis time. The threshold for detection of UL congestion is determined by iFCong and the hysteresis time is determined by iFHyst.
  RN Congestion Control considers UL congestion to be resolved when the uplink RTWP for a particular cell is below iFCong for a longer time than the hysteresis time iFHyst.
  
  
   Figure 7 Detection of UL Cell Congestion due to UL RTWP
  

  3.3.1.2 Downlink Cell Congestion Detection

  As shown in Figure 8, congestion due to radio overload in the non HS downlink transmitted carrier power is detected when the measured downlink transmitted carrier power exceeds a certain configurable threshold for a longer time than the hysteresis time. The threshold for detection of downlink congestion is determined by the parameters pwrAdm + pwrOffset and the hysteresis time pwrHyst.
  Downlink cell congestion is considered to be resolved when the downlink transmitted carrier power for a particular cell is below pwrAdm + pwrOffset for a longer time than the hysteresis time.
  
  
  Figure 8 Detection of Downlink Cell Congestion Due to Downlink Transmitted Carrier Power

  3.3.1.3 DL HSDPA congestion detection

  The DL transmitted carrier power is considered DL HSDPA-overloaded if the monitored non-HS DL power + HS-required DL power > 100% utilization for a hysteresis time maxPowerOverloadHystTime. This is indicated in the Figure 9. The non-HS DL power and the HS-required power is reported by the RBS, see Reference [8] for more details.
  
  
  Figure 9 Overload control using the HS-required power and non-HS required power

  3.3.2 Congestion Resolve Handling

  In case of only DL overload, or DL overload and DL HSDPA overload, besides denying admission to the congested cell, RN Congestion Control starts congestion resolve actions in the cell. The congestion resolve actions are periodic from the start of downlink congestion until the downlink cell congestion situation is resolved. The congestion resolve actions are based on the release of a certain amount of ASE in downlink. The release is done by reducing the rate in downlink (if possible) or to release RABs in one or more radio connections. The 'pace' of the congestion resolve actions (that is the interval between periodic congestion resolve actions) and the 'strength' of the congestion resolve actions (that is the amount of ASE in downlink to be released each congestion resolve action) is configurable per request class. For Iu-originating connections, the ASE in downlink is released (when possible) by switching the connection to the common channel or releasing RAB. While for connections originating over Iur the release of ASE in downlink is done by terminating the radio link, which in turn leads to the release of the whole connection. The connections with the highest ASE in downlink are targeted first, if they have the same priority. The connections are targeted in order of ARP priority, ignoring the pre-emption vulnerability setting.
  Figure 10 shows the principle of the differentiation in congestion resolve handling for a typical situation in which there is a mix of non-guaranteed and guaranteed radio connections in the congested cell.
  
  
  Figure 10 Differentiation in Downlink Cell Congestion Resolve Handling
  After detection of overload, an immediate action is taken to release releaseAseDlNg of ASEs in downlink for non-guaranteed service class connection in order of priority and the timer tmInitialG is started. If after the initial congestion resolve action there are non-guaranteed service class connections remaining in the cell and the congestion situation persist, the release of ASEs in downlink is repeated with the period tmCongActionNg. In case the overload situation remains after all the ASEs in downlink of the non-guaranteed service class connections are released and the timer tmInitialG is expired, timer tmCongAction is started. Then, releaseAseDl amount of ASEs in downlink for guaranteed service class connections are released in a periodical fashion until the congestion situation in the downlink is resolved. Setting releaseAseDlNg or releaseAseDl to 0 means that no congestion resolve actions are initiated on the non-guaranteed or guaranteed radio connections respectively
  Basically, when non-HS DL transmitted carrier power overload is detected, over load actions are taken in the following sequence (within steps in order of allocation/retention priority):
  
  • Step 1) Non-guaranteed RABs on dedicated, non-shared radio channels are reduced to their lowest retainable rate in the current radio configuration
  • Step 2) Guaranteed RABs and non-guaranteed RABs (remaining after step 1 and not on 0 kbps or on common radio channels) on dedicated, non-shared radio channels are released
  Note that neither guaranteed nor non-guaranteed RABs on HSDPA radio channels are targeted during these steps, as they are not contributing to the non-HS DL transmitted carrier power overload situation.
  When DL HSDPA overload is detected, or a combination of non-HS DL transmitted carrier power and DL HSDPA overload, the overload actions are taken in the following sequence (within steps in order of allocation/retention priority):
  
  • Step 1) Non-guaranteed RABs on dedicated, non-shared radio channels are reduced to their lowest retainable rate in the current radio configuration
  • Step 2) Guaranteed RABs on dedicated radio channels (including HSDPA) and non-guaranteed RABs (remaining after step 1 and not on 0 kbps or on common radio channels) on dedicated, non-shared radio channels are released
  Note that the non-guaranteed RABs on HSDPA radio channels are not targeted during these steps, as they are controlled by the HSDPA Scheduler. Note that neither SRB-only nor the common MBMS channels MCCH and MICH are targeted during an overload situation. Note that in case of HSDPA overload only, admission is still passed for requests which have a higher allocation/retention priority than the connections being targeted.
  

  3.4 Capacity Management Related Configurations

  In the power per radio link there are three limits:
  
  • Maximum UE Transmitted Power
  • Minimum Downlink Transmitted Code Power
  • Maximum Downlink Transmitted Code Power
  In the downlink transmitted carrier power per cell there is one limit:
  
  • Maximum Downlink Transmission Power
  In the number of HS-PDSCH channel codes (SF=16) that can be allocated for a HSDPA capable cell there is one limit:
  
  • Maximum Number of HS-PDSCH Codes

  3.4.1 Maximum UE Transmitted Power

  The operator can limit the uplink transmitted power by setting maxTxPwrUL. The parameter maxTxPwrUL (dBm) defines the maximum transmission power a user is allowed to transmit on cell level. For more information, see Idle Mode and Common Channel Behavior, Reference [9]. However, uplink transmitted power is not taken into consideration in the estimation of the system resource monitoring.
  

  3.4.2 Minimum Downlink Transmitted Code Power

  If the power of a radio link is very low, it is very sensitive to various interference. To avoid that the Power Control function (see Power Control, Reference [11]) decreases the power too much due to temporary good radio conditions, a minimum downlink transmitted code power value is configured. The parameter that sets this value per cell is minPwrRl (dB) and it is relative to primary CPICH power in a cell.
  

  3.4.3 Maximum Downlink Transmitted Code Power

  It is important that the Power Control function can increase the power to the level that is required to maintain the quality of the connection (see Power Control, Reference [11]). Therefore, the maximum downlink transmitted code power needs to be set high enough to support the coverage that is expected for the radio connection type. However, the maximum downlink transmitted code power cannot be too high, as it must avoid instability due to a faster Inner Loop Power Control compared to Capacity Management functions.
  Maximum downlink transmitted code power setting per radio link is determined by a per-cell definable mapping, based on the maximum rate of the radio link. Currently, three mapping points can be configured, through which in-between values are interpolated. The following six parameters set these mapping points: minPwrMax (dB), minimumRate (bps), interPwrMax (dB), interRate (bps), maxPwrMax (dB), maxRate (bps). The operator can modify the shape of the curve by changing the related parameters.
  
  
  Figure 11 Relationship between Bit Rate (bps) and Maximum Downlink Transmitted Code Power (dB)
  Figure 11 shows the mapping curve of the maximum radio link rate onto the maximum power per radio link. The maximum power per radio link (dB) is calculated relative to the primary CPICH. A radio link requires a certain rate (bps) and this rate is mapped onto the maximum power allowed for that radio link. Requests for a bit rate below minimumRate are mapped on minPwrMax. Requests above maxRate are mapped on maxPwrMax. If a request is between the three mapping points, these values are interpolated. Table 4 gives the maximum radio link rate for each connection type.
  

  Table 4 Maximum Radio Link Rate for some Radio Connections , not a complete list

  Radio Connection Type	Maximum DL Radio Link Rate
  PS384/HS	3700
  SRB 13.6	14800
  AMR 12.2	15900
  CS64	67700
  PS64/64	70900
  MultiRAB (CS64 + PS8/8)	76100
  PS64/384	406900

  Note that in case of the optional PS64/HS and PS384/HS radio connection types, the maximum radio link rate in downlink only involves the A-DCH.
  Note also that maximum downlink transmitted code power must not be set to a lower value than the minPwrRl.
  

  3.4.4 Maximum Downlink Transmission Power

  The operator can limit the total maximum power that is allowed to be transmitted by an RBS in a cell by setting maximumTransmissionPower. This parameter is used when setting up or re-configuring a cell; when maximumTransmissionPower is higher than the maximum downlink power capability reported by the RBS, the latter is automatically taken as the limit of the total maximum power allowed in the cell. This mechanism simplifies setup and re-configuration of cells and enables the UTRAN to handle changes in RBS maximum downlink power capability in a transparent fashion.
  Note that the total maximum downlink transmission power in a cell also represents the calibration value for the 100% level of the downlink transmitted carrier power measurements used by the Downlink Transmitted Carrier Power Monitor (see Section 3.1.2).
  As for HS-DSCH transmission, the process in the RBS that determines the estimation of the remaining power and the allocation to the HS-PDSCH/HS-SCCH codes is described in HSDPA User Plane, Reference [8] and Power Control, Reference [11].
  

  3.4.5 Maximum Number of HS-PDSCH Codes

  The operator can configure the number of HS-PDSCH codes (SF=16) that should be reserved for a HSDPA capable cell by setting numHsPdschCodes. The maximum number of HS-PDSCH codes is dependent on license level and parameter maxNumHsPdschCodes; up to 15 codes may be allocated. With a high number of HS-PDSCH codes allocated, the risk for code blocking will however increase and allocating 15 HS-PDSCH codes from the RNC is not advised. The number of HS-PDSCH codes in use for HS-DSCH transmission may also be dynamically adapted by the HSDPA Dynamic Code Allocation feature, see HSDPA User Plane, Reference [8]. Observe that the cell has to be locked/unlocked when changing the parameter maxNumHsPdschCodes
  The number of HS-SCCH codes (SF=128) in use is controlled with the numHsScchCodes parameter. The number of HS-SCCH codes configured controls how many users that may simultaneously be scheduled per 2 ms TTI, see HSPDA User Plane.
  

  3.5 Relevant Capacity Keys

  The total amount of RBS hardware that can be used might be limited by the following capacity keys:
  
  • WCDMA RBS key for Channel Elements UL: FAJ 121 072
  • WCDMA RBS key for Channel Elements DL:FAJ 121 073
  The keys set a limit on the available amount of Channel Elements that may be utilized simultaneously in the RBS, separately for uplink and downlink.
  The maximum number of HS-PDSCH codes set per HSDPA capable cell by the following capacity key:
  
  • WCDMA RBS key for HSDPA Codes per cell: FAJ 121 0332
  The number of HSPA users per cell can be set by the following license key:
  
  • WCDMA RBS key for HSDPA Users per Cell: FAJ 121 1011
  The default cost-model used as a basis for the RBS capacity licensing and monitoring in uplink may be changed by means of the following capacity keys:
  
  • WCDMA RBS key for DCH Channel Element Ladder: FAJ 121 1007
  • WCDMA RBS key for E-DCH Channel Element Ladder: FAJ 121 1157
  In the case of utilizing more than one baseband pool in either UL or DL, the license has to be statically divided over these two base band pools. This is for example when deploying more than two carriers in a base station. This can be done for UL and DL separately by using the parameters ulLicFractBbPool2 or dlLicFractBbPool2. By default the first baseband pool, UL or DL gets 100% of the licenses.
  
  Information about ordering and installation of license keys in the network can be found in Handling of License Control, Reference [4]
  

  3.6 Initial rate selection for AMR NB

  With AMR NB it is possible to use lower speech codec rates than 12.2 kbps. The radio network supports 7.95 kbps, 5.9 kbps and 4.75 kbps AMR codecs. There is no adaptation in the sense that AMR codecs are changed during an ongoing speech connection; rather there is a possibility to adapt the rate at RAB establishment.
  

  3.6.1 Initial selection algorithm

  The initial AMR rate selection algorithm will, based on system resource load and thresholds of DL Power, DL Code and UL ASE, determine the initial AMR rate. If the radio connection is in more then one cell, the thresholds needs to be combined (for example the minimum of DL Power, UL ASE and DL Code combined) and the minimum rate will be selected (for example if the radio connections consist of 5.9 kbps and 7.95 kbps, 5.9 kbps will be selected).
  The load thresholds should be set according to operator preference. Default values of these thresholds will only give AMR 12.2 kbps selection, independent of load.
  

  Table 5 Load thresholds for AMR

  Rate/ Resource	DL Power	UL ASE	DL Code
  AMR 12.2 kbps	pwrLoadThresholdDlSpeech. amr12200	aseLoadThresholdUlSpeech. amr12200	codeLoadThresholdDlSf128
  AMR 7.95 kbps	pwrLoadThresholdDlSpeech. amr7950	aseLoadThresholdUlSpeech. amr7950	codeLoadThresholdDlSf128
  AMR 5.9 kbps	pwrLoadThresholdDlSpeech. amr5900	aseLoadThresholdUlSpeech. amr5900	-
  AMR 4.75 kbps	-	-	-

  If rate selection involves more than one cell, the rates selected per individual cell shall be considered as maximum rates only. It is thus perfectly possible that even though one rate is excluded from selection in one cell, it may still be the rate selected when taking more cells into consideration.
  All multiRABs will use the AMR 12.2 kbps mode. If a Guaranteed Bit Rate (GBR) attribute is set, this rate will always be the minimum rate, irrespective of if the load threshold setting and load measurement suggests otherwise.
  

  4 Engineering Guidelines

  
  
  

  4.1 RN Admission Control

  4.1.1 ASE Admission Policy

  In many networks, downlink power is the limiting resource, why downlink resource handling is better controlled by the downlink transmitted carrier power admission policy. To disable the DL ASE admission policy, aseDlAdm should be set to its maximum value (500).
  For uplink RN Admission Control, the UL ASE admission policy provides a way to limit excessive UL interference avoiding large variations in cell breathing. This can be used in cells where there is an observed high UL interference. In other cells the UL ASE admission policy can turned of by setting aseUlAdm to its maximum value (500).
  Depending on the network configuration, level of RF tuning, user distribution, the admission limit aseUlAdm can be adjusted to better reflect the actually deployed network. Another aspect to consider is the activity factor on the radio bearers. This has little impact for speech and UDI radio bearers since the activity is known and fairly constant, but not for packet services. To be able to secure system stability, the current ASE for each link for all bearers except speech assumes high activity (70-80%). Typically, the activity factor for a packet connection is lower than the assumption, especially in the UL. This all depends on application behavior and parameter settings. This assumption leads to an overestimation of ASE usage in cells with predominantly packet traffic, why the UL ASE admission limit aseUlAdm can be raised from the default of 160 ASEs.
  The best effort margin and offset parameters are removed from the ASE admission. The increased admission level for non-guaranteed, non-handover due to removed best effort margin, will have limited impact. The reason is that even if more non-guaranteed packet data connections are admitted, RN Soft Congestion can downswitch these connections to lowest retainable rate (CELL_FACH) at congestion, while a new incoming connection is allowed according to the conditionally blocking principle. Thus keeping the P5 configuration of the parameter aseUlAdm will give a similar ASE UL admission function as for P5.
  The ASE values has been modified for most Radio Links, see Table 2. The largest changes applies to Stand alone SRB, Conversational CS speech 12.2/12.2 and HSDPA. In networks where such RABs are predominant, it may be necessary to reduced the ASE admission level to achieve the same load level as in older releases.
  

  4.1.2 The Downlink Transmitted Carrier Power Admission Policy

  The downlink transmitted carrier power admission policy controls the downlink power utilized by release99 channel connections. The remaining power can then be used for transmission of HS-PDSCH/HS-SCCH channels to HSDPA users. By changing the setting of pwrAdm, the portion of downlink power at admission reserved for HSDPA connections can be increased or decreased. The default settings balance a mix of release 99 channel users and available power for HSDPA, providing a minimum of 25% power to HSDPA, except for those cases when release 99 channel takes part of that power due to mobility, power variations of users in the cell and parameter hsPowerMargin. See HSDPA User Plane.
  For a cell with predominantly release 99 channel traffic, it is possible to increase the power admission threshold to maximize capacity. An option is to make use of the complete PA capability before the congestion resolve mechanism is activated, which is possible thanks to the fast RN Congestion Control mechanism in the RBS. This is achieved by setting the total values of parameters pwrAdm and pwrOffset equal to 99% (so that congestion resolve actions can still be triggered, see Section 3.3.1.2 Downlink Cell Congestion Detection). Parameter pwrAdm can be set to 84% maintaining pwrOffset at 15%. Dropped calls and soft handover failures should be carefully monitored to make sure that no negative impact is caused by such a change.
  

  4.1.3 The Downlink Channelization Code Admission Policy

  The best effort margin is removed from the downlink channelization code admission. This will only have limited effect on the downlink channelization code admission as RN Soft Congestion can trigger lower rates on lower priority, non-guaranteed connections. It is possible to further tune the default parameter settings for increased capacity. Changing dlCodeAdm to 90% or even higher will further increase the code tree usage and still allow a margin for new soft handover legs. It is recommended to monitor statistics to verify that the network admission behavior is as expected and fully admits soft handovers.
  Note that downlink channelization codes used for HSDPA are excluded from the calculation of the downlink channelization code admission.
  

  4.1.4 The Spreading Factor Admission Policy

  In downlink, it is recommended to disable the spreading factor admission policy since, under normal conditions, the ASE, power and code admission mechanisms limit the best effort services through the RN Soft Congestion control.
  In uplink, the number of users on UL SF4 in a cell can be controlled by parameter sf4AdmUl (including the 384/HS connections). It is also recommended to increase the default parameter values for sf8AdmUl and sf16AdmUl to avoid unnecessary restriction of accessibility.
  

  4.1.5 The Serving HS Admission Policy

  The admission threshold hsdpaUsersAdm determines the maximum number of simultaneous HSDPA users to be admitted in a cell at call setup, and should be set taking into consideration the trade-off between number of HS users and user throughput. It should be noted that users accessing the cell using HS-DSCH cell change are never rejected due to this limit. Therefore, when setting this threshold, there should be room left for HS cell changes, so that the serving cell is always the optimal cell, ensuring high throughput and reducing the risk for dropped calls. Factors such as cell traffic level from release 99 channels and user perception from a blocked connection compared to receiving a low throughput connection should be considered when setting the value of the parameter. The number of simultaneous HSDPA users is closely related to the configuration of hsdschInactivityTimer see Reference [1] for more information. Note that the hsdpaUsersAdm should not be set higher than a the capacity license on number of HSDPA users (FAJ 121 1011) as set in the RBS.
  

  4.1.6 The serving and non-serving EUL Admission Policy

  The parameters eulServingCellUsersAdm and eulServingCellUsersAdmTti2 can be set to limit a large number of EUL users in the serving cell, which otherwise may cause too poor user performance. The parameter eulNonServingCellUsersAdm is by default set to its maximum value not to affect the EUL number of users. When any of above admission limits are reached, and the new request is blocked, the request will retry on, if possible, EUL 10ms TTI or a release 99 channel, see Connection Handling Reference [2]. Parameters eulServingCellUsersAdm and eulNonServingCellUsersAdm limit the total number of EUL users, i.e. both 2ms TTI and 10ms TTI EUL users, while eulServingCellUsersAdmTti2 only limit the EUL 2ms TTI users.
  Note that the eulServingCellUsersAdm, eulServingCellUsersAdmTti2 and eulNonServingCellUsersAdm should not be set higher than the capacity license on number of EUL users (FAJ 121 1129) as set in the RBS.
  

  4.1.7 The RBS Hardware Admission Policy

  The RBS hardware monitoring admission policy is disabled by default in both uplink and downlink (parameters ulHwAdm=100, dlHwAdm=100). This implies that no hardware is reserved for handover of connections, and that no RN Soft Congestion mechanism is active (this only applies for RBS HW resources).
  However, it is recommended to set the limiting parameters to values below their maximum values as that will reserve resources for handover and also activate the RN Soft congestion functionality. When setting the admission thresholds it is important to consider any capacity requirement, especially for low capacity cells. This means reviewing the capacity requirement for requested radio bearers as well as identifying an optimized reservation level of handover resources. For most networks and cell scenarios, it is expected that the admission thresholds are set to 90% or higher. The RN Soft Congestion control works only when the resource utilization is lower than 100%. It is important to monitor admission statistics to make sure that capacity and performance is as expected.
  
  The observability for Channel Elements is updated and visualized by new RNC based counters in MO Class IubLink. The Channel Element usage is available in pdf as well as average and square average measurements.
  The 8 new counters are pmDlCredits, pmUlCredits, pmSumDlCredits, pmSumSqrDlCredits, pmSamplesDlCredits, pmSumUlCredits, pmSumSqrUlCredits and pmSamplesUlCredits.
  

  4.1.8 AMR NB Rate Selection Policy

  The initial rate selection for AMR NB can be controlled for each rate by DL power, ASE UL and DL code thresholds. The feature is by default configured to always give admission to AMR 12.2 kbps. One alternative is to set parameters pwrLoadThresholdDlSpeech.amr7950 and aseLoadThresholdUlSpeech.amr7950 to 100, which triggers allocation of AMR 7.95 kbps at admission. The usage of AMR 7.95 kbps instead of AMR 12.2 kbps improves the capacity and coverage.
  It is also possible to control the AMR rate selection to adapt to changes in the load situation in the cells. A low load gives AMR 12.2 kbps at admission, while a high load gives a lower AMR rate. This can be done by setting the parameters individually for each rate admission. It is then important to set the parameters based only on rate selection being performed at admission and that no re-configuration of rate is possible on ongoing calls.
  

  4.2 RN Congestion Control

  4.2.1 Congestion Detection

  4.2.1.1 Downlink Cell Congestion Detection

  The downlink cell congestion detection level is set relative to the total maximum power allowed in the cell (see Section 3.4.4 and Section 4.3.3), using the sum of parameters pwrAdm and pwrOffset. The hysteresis time is set defined by parameter pwrHyst.
  Parameter pwrHyst should cope with short peaks in the downlink transmitted carrier power that in general do not lead to downlink cell congestion situations, so that unnecessary blocking of the cell and (even worse) unnecessary congestion resolve actions are avoided.
  Field tests have shown that the default setting as stated in Section 5 is acceptable in most cases. Nevertheless, pwrHyst can be modified depending on the duration of the peaks in the downlink transmitted carrier power, which may be influenced by the UE behavior, radio environment and power control settings.
  

  4.2.1.2 DL HSDPA Congestion Detection

  It is possible to reserve DL carrier power for non-GBR HS service users by configuring the RBS parameter schMinPowerNonGbrHsUsers, see Reference [8], for parameter details. If for example this parameter is set to 20%, then 20% of the DL carrier power will be reserved for the non-GBR HS users if needed. If the non-GBR HS users are satisfied and are using for example 4% of the power, then 4% is reported as HS-DSCH required power by RBS. But if congestion is detected for the non-GBR HS users, see HSDPA User Plane, schMinPowerNonGbrHsUsers is reported as HS-DSCH required power instead of measured power.
  DL HSDPA congestion detection is triggered when any of the GBR HS users and/or the group of non-GBR HS users are unsatisfied for a period of maxPowerOverloadHystTime. The GBR HS users are unsatisfied when not fulfilling the delay requirements for each SPI. The group of non-GBR users is unsatisfied if the DL carrier power ratio set by parameter schMinPowerNonGbrHsUsers is not reached and at least schCongThreshNonGbr priority queues are not scheduled even though passing the validation procedure.
  The default value of schMinPowerNonGbrHsUsers is 0, but can be increased to secure non-GBR HS traffic. Note, that a high parameter value will as a first step in a congestion scenario reduce the release 99 packet data rate, but in extreme configuration/traffic scenarios even GBR HS and voice connects be affected.
  The higher valuer on parameter schCongThreshNonGbr, the lower possibility of DL HSDPA congestion detection. If the parameter schCongThreshNonGbr is very low compared to the actual number of priority queues the soft HSDPA reservation schMinPowerNonGbrHsUsers may appear as a fixed reservation as it is always used for non-GBR HS.
  

  4.2.1.3 Uplink Cell Congestion Detection

  The detection level for uplink cell congestion is determined by iFCong and by the hysteresis time setting iFHyst.
  The uplink cell congestion detection is based on the uplink Received Total Wideband Power (RTWP). The signal is measured in the RBS and feeder losses and TMA gain are compensated for, to receive RTWP in the reference point. Due to measurement uncertainties, different feeder losses and gains as well as variations in background noise, RTWP can vary from cell to cell. Incorrect system values for feeder losses and TMA gains directly effect the accuracy of RTWP. Because of the above uncertainties, it is important to tune the detection level on cell basis.
  By default, uplink cell congestion detection is disabled by setting iFCong to -49.9 dBm and iFHyst to 6000 ms. In many networks, UL interference is not the main limitation and this setting is acceptable in most cases. If there is a high degree of uplink interference in a cell, it can be relevant to tune these parameters to resolve excessive cell breathing.
  It is possible to use RBS counters to measure RSSI distribution, which then can be used as input when configuring iFCong. Note interference from EUL traffic is included in the measurements and may therefore trigger the congestion detection if not considered. When setting parameter iFHyst, short duration of UL interference peaks should be disregarded as, in general, they do not lead to uplink cell congestion. Unnecessary detection of uplink congestion leads to unnecessary blocking of the cell. Field tests have shown that there might be special conditions in a cell or specific UE behaviors that may require this parameter to be tuned on cell basis.
  Networks with EUL traffic can benefit by controlling the EUL traffic by using parameter eulMaxRotCoverage. For more information see Reference [17].
  

  4.2.2 Congestion Resolve Handling

  When downlink cell congestion is detected, the process of taking congestion resolve actions starts. Congestion resolve actions are differentiated according to whether they affect guaranteed or non-guaranteed service class connections.
  The congestion resolve handling can be speeded up for non-guaranteed connections by reducing the period tmCongActionNg and/or increasing the released ASE per period releaseAseDlNg. If changed statistics shall be monitored to identify if the congestion resolve handling still is stable.
  

  4.3 Capacity Management Related Configurations

  4.3.1 Minimum Downlink Transmitted Code Power

  The minimum downlink transmitted code power, minPwrRl, must be set in such a way that the risk for downlink power rushes in transmitted downlink power is reduced. Field tests have shown that if minimum downlink transmitted code power is set to a too low level, there is the risk (depending on the mobile vendor) that UEs cause a sudden rush in downlink power behavior, which can result in downlink cell congestion being unnecessarily detected. A value set too low can also lead to uplink interference peaks, as the Power Control function may have problems receiving the control information. As a rule of thumb, the minimum power for each radio link should be set 25 dB below the maximum power allowed maxDlPowerCapability in the RBS (see Section 4.3.3).
  

  4.3.2 Maximum Downlink Transmitted Code Power

  The setting for the maximum downlink transmitted code power is dependent on the downlink coverage required for a specific service in the cell. This setting must also take into account the load and interference situation. The maximum downlink transmitted code power is set using the DL power mapping curve (see Figure 11). It must be set high enough to support the coverage that is expected for the radio connection type. However, field tests have shown that it is rather important not to set this maximum power too high, because it will lead to instability in the downlink transmitted carrier power behavior. Therefore, the combined values of parameters primaryCpichPower and maxPwrMax should not exceed 40% of the maximum downlink transmission power (see Section 4.3.3).
  

  4.3.3 Maximum Downlink Transmission Power

  Parameter maximumTransmissionPower allows the operator to limit the maximum used power in the cell. In normal cases this is not necessary. Exceptions can occur, for example when regulations require limited EIRP at the antenna.
  To ensure that the maximum power is available in the cell, maximumTransmissionPower must be set at, or beyond, the downlink power capability reported by the RBS ( maxDlPowerCapability). Note that if maximumTransmissionPower is set to a value higher than maxDlPowerCapability, the actual maximum power is still equal to maxDlPowerCapability.
  

  4.3.4 Dynamic Code Allocation and Number of HS-PDSCH Codes

  Dynamic Code Allocation (see also HSDPA User Plane) is turned on using parameter dynamicHsPdschCodeAdditionOn. Live network verifications show improved performance and capacity when it is activated. The benefits are further increased when Dynamic Code Allocation is used in combination with Code Multiplexing (see Section 4.3.5). When Dynamic Code Allocation is activated it is beneficial to set the number of allocated HS_PDSCH codes ( numHsPdschCodes) to a requested trade-off level between capacity and performance. A too high value can cause an over allocation of resources for HSDPA, meaning that non-HSDPA traffic may suffer from unnecessary congestion of codes. If a too low value is used HSDPA traffic may suffer from reduced performance as the codes are prioritized for non-HSDPA traffic. In networks with high non-HSDPA traffic it is often beneficial to reduce the setting compared to the default setting. Parameter maxNumHsPdschCodes is only be set to match the hardware limitation in the cell as it otherwise may limit performance.
  When reducing the number of HS-PDSCH codes ( numHsPdschCodes), the codes that are to be released are transparently de-allocated, without affecting ongoing traffic. Conversely, in case of an increase, the cell will temporarily be disabled due to its implicit lock/unlock, leading to the release of all the ongoing traffic in the cell (see HSDPA Migration and Activation).
  

  4.3.5 Number of HS-SCCH Codes

  Parameter numHsScchCodes controls the number of HS-SCCH codes used, and thereby number of simultaneous HSDPA users for each TTI. It is possible to achieve a higher HSDPA performance due to more efficient use of the TTI by setting this parameter to a higher value (see HSDPA User Plane). The gain depend among others on the application behavior as users with low rate and/or bursty application can share a TTI, which then improves performance.
  

  4.4 Feature/Capacity Key Handling

  Because the RBS capacity keys are node specific, it is important to check the Performance Management (PM) statistics for each node before activating license control. Large care must be taken to get the correct individual levels for each node.
  Once the usage is known, this can be converted into license capacity needs for each node. These keys should then be ordered from Ericsson and installed in the correct node (see Handling of License Control, Reference [4]). It is recommended to measure the CE usage for one week to obtain a complete CE usage profile.
  If the plotting of the Channel Element usage for a certain RBS is flat at the maximum level, the licensed capacity might be too low. The behavior shown in Figure 12, where there is a change from something that looks like diagram A to something like diagram B, resembles that of hardware limitations.
  
  
  
  Figure 12 Channel Element Usage in the RBS (uplink or downlink)
  When capacity keys are installed, regular monitoring of the RBS utilization is required in order to decide on ordering new capacity keys for the RBS. The need for new capacity keys may be identified in different ways. Once the operator has excluded the reason that the behavior is due to overload in the radio and transport network, an RBS capacity upgrade should be performed.
  However, if the RBS hardware admission policy is activated, some requests might already be blocked due to RBS hardware limits. In this case, it is recommended to monitor the increase in call setup blocking and correlate that information with the setting of the RBS hardware admission policy. An increased amount of call setup blocking may indicate a need to increase the RBS hardware capacity.
  

  5 Parameters

  This section describes all parameters that the operator can configure to control WCDMA RAN Capacity Management functions.
  

  5.1 Descriptions

  5.1.1 System Resource Handling and Capacity Management Related Configurations

  maximumTransmissionPower		Cell parameter that can be used to limit the total downlink transmitted power in a cell to a value lower than the downlink power capability of the RBS.
  maxTxPowerUl		Used in UE functions for cell selection/re-selection in idle mode and connected mode and also used by UTRAN to control the maximum transmitted power level a UE can use. If the current UE uplink transmit power is above the indicated power value, the UE decreases the power to a level below the power value (note that there are more parameters with this name; the one described here is in object UtranCell).
  interPwrMax		Cell parameter that defines the intermediate relative power for maximum downlink power mapping for resource estimation (see Figure 11).
  interRate		Cell parameter that defines the intermediate rate for maximum downlink power mapping for resource estimation (see Figure 11).
  maxPwrMax		Cell parameter that defines the maximum relative power for maximum downlink power mapping for resource estimation (see Figure 11).
  maxRate		Cell parameter that defines the maximum rate for maximum downlink power mapping for resource estimation (see Figure 11).
  minimumRate		Cell parameter that defines the minimum rate for maximum downlink power mapping for resource estimation (see Figure 11).
  minPwrMax		Cell parameter that defines the minimum relative power for maximum downlink power mapping for resource estimation (see Figure 11).
  minPwrRl		Cell parameter that defines the minimum power per radio link for resource estimation purposes.
  numHs PdschCodes		Parameter that defines the number of HS-PDSCH codes allocated in a cell.

  5.1.2 RN Admission Control

  aseDlAdm		Cell parameter that defines the absolute admission limit for ASEs in the downlink.
  aseUlAdm		Cell parameter that defines the absolute admission limit for ASEs in the uplink.
  compModeAdm		Cell parameter that defines the absolute admission limit for the number of radio links in compressed mode in a cell.
  dlCodeAdm		Cell parameter that defines the absolute admission limit for downlink code usage.
  pwrAdm		Cell parameter that defines the absolute admission limit for downlink power utilization. It is relative to the min( maximumTransmissionPower, maxDlPowerCapability), it is expressed as a percentage and that is a percentage of min.( maximumTransmissionPower, maxDlPowerCapability).
  hsdpaUsersAdm		Cell parameter that defines the admission limit for the number of users assigned to the HS-DSCH. Applicable to admission requests related to RAB setup of an HSDPA service.
  eulServingCellUsersAdm		Cell parameter that defines the admission limit for the number of EUL users having the cell as serving cell.
  eulNonServingCellUsersAdm		Cell parameter that defines the admission limit for the number of EUL users having the cell as non-serving cell.
  eulServingCellUsersAdmTti2		Cell parameter that defines the admission threshold for the number of 2 ms TTI E-DCH users having this cell as serving cell. Applicable at serving cell change, at RAB establishment and at re-configuration to EUL.
  sf8Adm		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 8 in downlink.
  sf16Adm		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 16 in downlink for which new non-guaranteed admission requests will continue to be allowed.
  sf32Adm		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 32 in downlink.
  sf16gAdm		Cell parameter that defines the maximum number of radio links with spreading factor = 16 in downlink for which new guaranteed admission requests will continue to be allowed. Reaching or exceeding this number of radio links (any service class) using downlink spreading factor = 16 will block setup/adding any more guaranteed service class radio links requiring additional downlink spreading factor = 16 in this cell.
  sf4AdmUl		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 4 in uplink (radio connection type PS384/HS).
  sf8AdmUl		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 8 in uplink.
  sf16AdmUl		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 16 in uplink.
  sf8gAdmUl		Cell parameter that defines the absolute admission limit for the number of radio links with spreading factor = 8 in uplink.
  dlHwAdm		Parameter that defines the admission limit for the downlink hardware usage in the cell group.
  ulHwAdm		Parameter that defines the admission limit for the uplink hardware usage in the cell group.
  maxNumHsdpaUsers		Parameter that limits the maximum allowed number of simultaneous HSDPA users per cell that can be served.
  maxNumADchReservation		The maximum number of A-DCH resources that may be configured in a baseband pool.
  ulLicFractBbPool2		Parameter that defines the UL capacity of the second Base Band Pool in percentage of licensed UL capacity.
  dlLicFractBbPool2		Parameter that defines the DL capacity of the second Base Band Pool in percentage of licensed DL capacity

  5.1.3 RN Congestion Control

  5.1.3.1 Congestion Detection

  iFCong		Cell parameter that defines the absolute uplink congestion resolve level for uplink cell congestion.
  iFHyst		Cell parameter that defines a measurement hysteresis time for detecting uplink cell congestion. Congestion is detected when the uplink interference remains over a predefined threshold iFCong for a longer time than iFHyst. Congestion is considered to be resolved when the uplink interference remains below iFCong for a longer time than iFHyst
  pwrHyst		Cell parameter that defines a measurement hysteresis time for detecting downlink cell congestion. Congestion is detected when the downlink power load remains over pwrAdm + pwrOffset for a longer time than pwrHyst. Congestion is considered to be resolved when the downlink power load remains below pwrAdm + pwrOffset for a longer time than pwrHyst
  pwrOffset		Cell parameter that defines the margin on pwrAdm to be used as detection level for downlink cell congestion. It is relative to the min. ( maximumTransmissionPower, maxDlPowerCapability), it is expressed as a percentage and that is a percentage of min. ( maximumTransmissionPower, maxDlPowerCapability).
  maxPowerOverloadHystTime		Cell parameter that defines the hysteresis time for HS overload detection.

  5.1.3.2 Congestion Resolve Actions

  releaseAseDl		Cell parameter that defines the amount of ASEs to be released in the downlink in case cell congestion resolve actions target guaranteed service class connections. If set to 0, no congestion resolve actions are initiated on guaranteed service class connections.
  tmInitialG		Cell parameter that defines the minimum time between start of downlink congestion and initiation of congestion resolve actions on guaranteed service class connections.
  tmCongAction		Cell parameter that defines the time interval between two cell congestion resolve actions that target guaranteed service class connections.
  releaseAseDlNg		Cell parameter that defines the amount of ASEs to be released in downlink during each cell congestion resolve action targeting non-guaranteed service class connections. If set to 0, no congestion resolve actions are initiated on non-guaranteed service class connections.
  tmCongActionNg		Cell parameter that defines the time interval between two cell congestion resolve actions targeting non-guaranteed service class connections.

  5.1.4 Initial rate selection for AMR NB

  pwrLoadThresholdDlSpeech.amr12200		DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR12.2 speech codec in setup of AMR-NB multi-rate
  pwrLoadThresholdDlSpeech.amr7950		DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR7.95 speech codec in setup of AMR-NB multi-rate
  pwrLoadThresholdDlSpeech.amr5900		DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR5.9 speech codec in setup of AMR-NB multi-rate
  aseLoadThresholdUlSpeech.amr12200		UL ASE threshold to be used in the initial AMR rate selection algorithm for selecting AMR 12.2 speech codec in setup of AMR-NB multi-rate

  aseLoadThresholdUlSpeech.amr7950		UL ASE threshold to be used in the initial AMR rate selection algorithm for selecting AMR 7.95 speech codec in setup of AMR-NB multi-rate
  aseLoadThresholdUlSpeech.amr5900		UL ASE threshold to be used in the initial AMR rate selection algorithm for selecting AMR 5.9 speech codec in setup of AMR-NB multi-rate
  codeLoadThresholdDlSf128		Threshold to be used in the initial AMR rate selection algorithm for selecting SF128- or SF256-based AMR codec modes in setup of AMR-NB multi-rate.

  5.1.5 Code allocation

  maxNumHsPdschCodes		Parameter that defines the maximum number of HS-PDSCH codes that may be allocated in a cell. Observe that the cell has to be locked/unlocked when changing the parameter maxNumHsPdschCodes.

  numHsScchCodes		Parameter that determines how many HS-SCCH’s that shall be configured.

  5.2 Values and Ranges

  Table 6 shows parameters mentioned in this document. Default value, value range, resolution, and unit are shown for each parameter. To facilitate the reading, a translation to a more convenient unit is included wherever necessary. The list of recommended values can be found in Radio Network Parameters Reference [12].
  

  Table 6 WCDMA RAN Capacity Management Parameters

  Parameter Name	Default Value	Value Range	Resolution	Unit
  System Resource Handling and Capacity Management Related Configurations
  maximumTransmissionPower	400	0..500	1	0.1 dBm
  	[40.0]	[0..50.0]	[0.1]	[dBm]
  maxTxPowerUl (UtranCell)	100	–50..33, 100	1	1 dBm and 100 indicates that the maximum UL transmission power has not been specified by the operator.
  interPwrMax	38	-350..+150	1	0.1 dB
  	[3.8]	[-35.0..+15.0]	[0.1]	[dB]
  interRate	7760	0..1600000	1	10 bps
  	[77.60]	[0..16000.00]	[0.01]	[kbps]
  maxPwrMax	48	-350..+150	1	0.1 dB
  	[4.8]	[-35.0..+15.0]	[0.1]	[dB]
  maxRate	40690	0..1600000	1	10 bps
  	[406.90]	[0..16000.00]	[0.01]	[kbps]
  minimumRate	1590	0..1600000	1	10 bps
  	[15.90]	[0..16000.00]	[0.01]	[kbps]
  minPwrMax	0	-350..+150	1	0.1 dB
  	[0.0]	[-35.0..+15.0]	[0.1]	[dB]
  minPwrRl	-150	-350..+150	1	0.1 dB
  	[-15.0]	[-35.0..+15.0]	[0.1]	[dB]
  numHsPdschCodes	5	1..15	1	# of codes
  RN Admission Control Admission Policies
  aseDlAdm	240	0..500	1	ASE
  aseUlAdm	160	0..500	1	ASE
  hsdpaUsersAdm	10	0..1000	1	# of radio links
  eulServingCellUsersAdm	4	0..100	1	1 EUL user
  eulNonServingCellUsersAdm	100	0..100	1	1 EUL user
  eulServingCellUsersAdmTti2	2	0..100	1	1EUL 2 ms user
  compModeAdm	15	0..128	1	# of radio links
  dlCodeAdm	80	0..100	1	%
  pwrAdm	75	0..100	1	%
  sf8Adm	8	0..8	1	# of radio links
  sf16Adm	16	0..16	1	# of radio links
  sf32Adm	32	0..32	1	# of radio links
  sf16gAdm	16	0..16	1	# of radio links
  sf4AdmUl	0	0..1000	1	# of radio links
  sf8AdmUl	8	0..50	1	# of radio links
  sf16AdmUl	16	0..50	1	# of radio links
  sf8gAdmUl	0	0..8	1	# of radio links
  dlHwAdm	100	0..100	1	%
  ulHwAdm	100	0..100	1	%
  maxNumHsdpaUsers	16	1..64	1	# of users
  maxNumADchReservation	128	0.. 384	1	# ADCH resources
  ulLicFractbbPool2	0	0.. 100	1	%
  dlLicFractbbPool2	0	0.. 100	1	%
  RN Congestion Control Congestion Detection
  iFCong	621	0..621	1	-
  	[-49.9]	[-112.0..-49.9]	[0.1]	[dBm]
  iFHyst	6000	0..6000	1	10 ms
  	[60000]	[0..60000]	[10]	[ms]
  pwrHyst	300	0..60000	10	ms
  pwrOffset	5	0..100	1	%
  maxPowerOverloadHystTime	10	0..50	1	sec
  RN Congestion Control Congestion Resolve Actions
  releaseAseDl	1	0..500	1	ASE
  releaseAseDlNg	3	0..500	1	ASE
  tmCongAction	2000	300..100000	1	ms
  tmCongActionNg	800	500..100000	1	ms
  tmInitialG	3000	10..100000	1	ms
  Initial rate selection for AMR NB
  pwrLoadThresholdDlSpeech.amr12200	100	0..100	1	%
  pwrLoadThresholdDlSpeech.amr7950	0	0..100	1	%
  pwrLoadThresholdDlSpeech.amr5900	0	0..100	1	%
  aseLoadThresholdUlSpeech.amr12200	100	0..100	1	%
  aseLoadThresholdUlSpeech.amr7950	0	0..100	1	%
  aseLoadThresholdUlSpeech.amr5900	0	0..100	1	%
  codeLoadThresholdDlSf128	100	0..100	1	%
  Code Allocation
  maxNumHsPdschCodes	5	5..15	1	# of codes
  numHsScchCodes	1	1..4	1	# of codes