Cell Broadcast Service

1 Introduction

This document describes Cell Broadcast Service (CBS) within the WCDMA Radio Access Network (RAN).

1.1 Scope

The document describes the CBS features including operator parameters, engineering guidelines and information about the activation and deactivation of the features.
There are two optional features for CBS controlled by separate licenses in the RNC:

• Cell Broadcast Service, FAJ 121 1326
• Cell Broadcast Service - UE battery consumption improvements, FAJ 121 1406

1.2 Target Groups

The target groups for this document are the following:

• System operators who need a general understanding of the CBS feature in WCDMA RAN
• Personnel working on Ericsson products or systems

1.3 Revision Information

Apart from editorial changes this document has been revised as listed in Table 1.

Table 1 Revision History

Revision	Reason for Revision
A	This is a new document based on 126/1553-HSD 10102/7. The document is updated with information about the feature CBS - UE battery consumption improvements (FAJ 121 1406).
B	Information about counter pmNoDiscardedBmcCbsMsgs is added in section 4.2. The engineering guidelines for Level 2 Scheduling in section 6.2 is updated.
C	Revised Section 6.2 about recommended parameter setting for Level 2 Scheduling.
D	Incorrect information describing the mapping of CBS Schedule periods to the SFN cycle is removed in Section 4.4.2. Also Figure 5 in Section 4.4.2 is revised.

1.4 Concepts

The following concepts are addressed in this document:

Cell Broadcast (CB) message		User data as transmitted from the CBC to the UE.
Cell Broadcast Service Area (CBSA)		A CBSA represents the smallest geographical area where CB messages can be broadcast. One CBSA contains one UTRAN cell.
BMC CBS Message		BMC CBS Messages are sent from WCDMA RAN to the UE using the BMC protocol. A BMC CBS Message contains one CB message.
CTCH occasion		A radio frame on the Secondary CCPCH where CTCH data can be sent.
CBS schedule period		A CBS schedule period consists of a number of consecutive CTCH occasions scheduled on S-CCPCH.
BMC Schedule Message		BMC Schedule Messages are sent from WCDMA RAN to the UE using the BMC protocol. A BMC Schedule message contains information about the BMC messages (BMC Schedule Messages and BMC CBS Messages) to be broadcast in the next CBS schedule period.

2 Overview

This section provides an overview of the CBS features in WCDMA RAN.
The CBS features enable broadcast of short text messages to defined geographical areas known as Cell Broadcast Service Areas (CBSAs). The messages are repeated over the air interface at a frequency and for a duration agreed by the content provider.
CB messages are generated by the Cell Broadcast Center (CBC) and sent to WCDMA RAN via the Iu-BC interface, see Figure 1. The CBC is an external node provided by the operator, that is, the functionality is not integrated in the Ericsson Core Network.

Figure 1 CBS Overview

The Iu-BC interface is standardized by 3GPP and the protocol stack is illustrated in Figure 2 below.

Figure 2 Iu-BC protocol stack

The Service Area Broadcast Protocol (SABP), specified in Reference [2], is used to distribute CB messages from CBC to a number of CBSAs in RNC. Each CBSA contains only one UTRAN cell. The lower layers of the Iu-BC interface are specified in Reference [3]. Both IP and ATM transport is supported in WCDMA RAN.
The CB messages received from CBC are stored in WCDMA RAN and the Broadcast Multicast Control (BMC) protocol, specified in Reference [4], is used on the Uu interface to schedule and broadcast corresponding BMC CBS messages in the cell. Each BMC CBS message contains one CB message. The BMC CBS messages are sent on the logical channel CTCH using RLC unacknowledged mode. The CTCH is multiplexed on a FACH transport channel carried by a Secondary CCPCH.
CB messages are received by UEs in Idle mode and in state URA_PCH. The UE will monitor the CTCH during time intervals which do not conflict with the UE specific paging occasions on PICH.

2.1 Cell Broadcast Service (FAJ 121 1326)

This feature provides the basic functionality for CBS including support for the Iu-Bc interface and broadcast of BMC CBS Messages on CTCH using the Level 1 Scheduling as described in Section 4.4.1.

2.2 Cell Broadcast Service - UE battery consumption improvements (FAJ 121 1406)

This feature is an enhancement of the basic CBS functionality introduced by FAJ 121 1326. It makes it possible to improve UE standby time in idle mode and state URA_PCH by introducing support for Level 2 Scheduling, that is, definition of CBS schedule periods and broadcast of BMC Schedule Messages as described in Section 4.4.2.

3 Capabilities

A maximum of 20 CB messages, or a total payload of 2.5 kbyte, can be stored per CBSA in the RNC. When this limit is reached new CB messages addressed to the CBSA are discarded. If a CB message is discarded the cell counter pmNoDiscardedCbsMsgOrders is stepped, see Reference [6].
The maximum number of CBSAs is 65535 within a PLMN and 2304 within an RNC.
The size of incoming SABP messages is limited to 18000 octets. This should be large enough to cover a SABP WRITE-REPLACE message containing 2304 CBSAs. If the size exceeds 18000 octets the message is not decoded and WCDMA RAN responds by sending an SABP ERROR INDICATION to CBC.
RNC hardware: SPB21, SPB3 or later HW is required in RNC to activate the feature Cell Broadcast Service - UE battery consumption improvements (FAJ 121 1406).

4 Technical Description

4.1 Cell Broadcast Service Area

The CBS feature includes the area concept Cell Broadcast Service Area (CBSA) which represents the smallest geographical area where a CB message can be broadcast. The CBSA is only used towards the CBC node and it contains one UTRAN cell.
The service area identity (SAI) for a CBSA is defined as:
PLMN id + Location Area Code (LAC) + CB Service Area Code
The CB Service Area Code is configured in the RNC and the value is set by the cell parameter cellBroadcastSac. For PLMN id and LAC the already configured values for the cell are used.
In order to avoid configuration mismatch OSS provides a consistency check rule for verifying that the CBSAs are unique in all cells in the network. Warnings will be issued in case on non-unique SAI as same SAI in different cells may cause broadcasting of CB messages in the wrong area.
If the cellBroadcastSac parameter is set to “undefined” no CB messages can be broadcast in the cell.

4.2 Reception of new CB messages

Broadcast of a new CB message, or replacement of an old CB message, is initiated by CBC with SABP message WRITE-REPLACE. In addition to the actual CB payload the SABP WRITE-REPLACE message contains the following information

Message Identity and Serial Number		The Message Identity and the 12 left-most bits of the Serial Number uniquely identifies a CB message within a CBSA.
Old Serial Number		This information is optional and only included in the SABP WRITE-REPLACE message if there is a need to replace an already stored CB message for a given Message Identity.
Data Coding Scheme		This information is transferred transparently to the UE.
Service Areas List		List of CBSAs where the CB message is to be broadcast.
Repetition Period		Information about how often the CB message is to be broadcast.
Number of Broadcasts Requested		Information about how many times the CB message is to be broadcast. The broadcast can be either finite or infinite.
Category		This information indicates the priority of the CB message.

Figure 3 illustrates the steps performed in WCDMA RAN at reception of a SABP WRITE-REPLACE message.

Figure 3 WRITE-REPLACE

1. At reception of the SABP WRITE-REPLACE message RNC checks that all service areas included in the message are defined as CBSAs and responds with a SABP WRITE-REPLACE COMPLETE message.
2. For each defined CBSA listed in the SABP WRITE-REPLACE message the following steps are performed:
   • If the cell contained in the CBSA is enabled, the new CB message is stored. If the SABP WRITE-REPLACE message contains an Old Serial Number, the previously stored CB message is replaced with the new information. Broadcast of the old CB message is stopped.
   • The new CB message is broadcast on CTCH using the BMC protocol. The BMC CBS messages are broadcast with the repetition period requested by CBC. If the amount of data generated by the BMC layer is higher than the available CTCH capacity a congestion situation may occur where BMC CBS messages are discarded in RNC. If a BMC CBS message is discarded due to congestion the cell counter pmNoDiscardedBmcCbsMsgs is stepped.
3. For finite broadcast, the CB message is cleared when it has been repeated the number of times requested by CBC. For infinite broadcast, the CB message is repeated until it is deleted by CBC, see Section 4.3.

4.3 Deletion of CB messages

An active CB message can be deleted by request from CBC using one of the SABP procedures KILL or RESET. The KILL procedure is used to stop broadcast of one CB message in one or several CBSAs whereas the RESET procedure is used to stop broadcast of all CB messages stored in one or several CBSAs. Both procedures are supported in WCDMA RAN.
If a cell with a defined CBSA becomes disabled the broadcast is stopped in that cell and all stored CB messages are cleared.

4.4 Scheduling of BMC messages over the Uu interface

Broadcast of BMC data over the Uu interface is controlled by the following two scheduling schemes:

• CBS Level 1 Scheduling
• CBS Level 2 Scheduling (DRX mode)

Level 1 Scheduling is the basic scheduling scheme provided by FAJ 121 1326. This scheduling can be used as a stand alone scheduling scheme or it can be combined with the Level 2 Scheduling provided by FAJ 121 1406. The different scheduling schemes are further described below.

4.4.1 CBS Level 1 Scheduling

CBS Level 1 Scheduling introduces support for CTCH occasions on S-CCPCH and makes it possible to broadcast BMC CBS Messages over the Uu interface.
The logical channel CTCH is multiplexed on FACH1, carried by the existing S-CCPCH used for 32 kbps Interactive PS RB and SRBs. The CTCH is scheduled on S-CCPCH during predefined CTCH occasions. The CTCH occasions are fixed on the SFN cycle 0...4095 and thus repeated cyclically.
CTCH occasions are defined as the radio frames in which the following equation is true:
SFN = K + m*N, m = 0, 1, 2, ... M (Reference [5])
K is the offset to the first CTCH occasion on the SFN cycle. The value is hard coded to 0.
N is the period of CTCH occasions on S-CCPCH. The value is set by the parameter ctchOccasionPeriod.
M is the maximum value that fulfills the equation K + M*N 4095 (Max SFN)

Figure 4 Scheduling of CTCH occasions on Secondary CCPCH

Note that the TTI for FACH1 is 10 ms, that is, each CTCH occasion corresponds to one TTI on FACH1.
The parameters K and N are signalled to the UE in system information (SIB5).

4.4.2 CBS Level 2 Scheduling

CBS Level 2 Scheduling introduces support for CBS schedule periods and transmission of BMC Schedule Messages on CTCH.
A CBS schedule period consists of P consecutive CTCH occasions scheduled on S-CCPCH. P is set by parameter cbsSchedulePeriodLength.
The CTCH occasion period N, that is, the time between two consecutive CTCH occasions within a CBS schedule period, is controlled by the Level 1 Scheduling described in Section 4.4.1. Thus the length of a CBS Schedule period can be defined as (P *N /100) seconds.

Figure 5 Example of CBS Level 2 Scheduling using P=8.

The length of a CBS schedule period is fix and the periods are repeated on S-CCPCH every P CTCH occasion. A BMC Schedule Message is sent in the beginning of each CBS schedule period. It contains information about the messages to be scheduled in the next coming period, that is, the BMC Schedule message sent in period x lists the BMC messages to be scheduled on CTCH in period x+1. Based on this information the UE knows beforehand when there is a need to listen to S-CCPCH. Only if a CTCH occasion contains a BMC Schedule Message or a new BMC CBS Message the UE is required to listen to S-CCPCH. For all other CTCH occasions the UE can remain idle.

4.5 Iu-BC Transport

4.5.1 Network Aspects

4.5.1.1 Overview

Iu-BC and O&M traffic will share the same IP host in RNC.
For ATM case Iu-BC traffic is carried to O&M router using ATM, see Figure 5. The CBC node must be connected using IP/Ethernet to O&M Router.

 Figure 6 Iu-BC using ATM transport
For IP case Iu-BC can be carried over IP/Ethernet straight to the CBC node from RNC, see Figure 6.

Figure 7 Iu-BC using IP transport

For IP over ATM case, all IP Routing configuration in RNC for Mur can be reused for Iu-BC, as the Iu-BC interface is connected to the same O&M IP network as Mur. There is no need to add or modify routes as all traffic is sent to the O&M Router.
The fact that the Iu-BC interface will be connected to the same O&M IP network as Mur implies the following:

• QoS must be considered as the Iu-BC traffic will compete for bandwidth with the O&M traffic
• Iu-BC interface and traffic will experience the same level of network security as O&M traffic and as provided by the O&M IP network
• The CBC node must be connected to the O&M IP network
• The O&M IP network must allow the TCP port for SABP 3452 and will compete for bandwidth with the O&M traffic

4.5.1.2 QoS

From RNC to CBC node the Iu-BC traffic will get the same QoS characteristics as O&M traffic. For the traffic from the CBC to the RNC, QoS separation in the IP network using different settings of the DSCP (DiffServ Code Point) can be done if the CBC node supports it. The QoS characteristics currently recommended for O&M traffic is assumed to be adequate for Iu-BC traffic. An operator may choose to implement an O&M IP network with a higher QoS level.

4.5.1.3 Dimensioning

The dimensioning of the O&M IP network should take into account Iu-BC traffic. The Iu-BC traffic volume is expected to be low and the impact on the dimensioning should be small.
The Iu-BC capacity demand can be calculated using the formula below:
C_Iu-BC = Msglength * numMsgs/second
Msglength is the length of the SABP message.
numMsgs/second is the number of SABP messages sent over the Iu-BC interface per second.

4.5.1.4 Security

IP network security must be considered when adding Iu-BC traffic to the O&M IP network. This network has many access points compared to the networks for user traffic and is potentially exposed to greater security threats.
To improve security it is recommended to turn on the Filter for IP source address validation in the RNC by setting parameter sourceIpAddressValidation to TRUE. This filter will avoid the establishment of connections from other IP source addresses than the configured IP address for the CBC.
It is possible to turn this filter off if there is a need to establish connections from more than one IP address.

Note:

If the filter is not used the security level may need to be increased for the entire O&M IP network.

4.5.2 Configuration

In order to start CBS operation the MO IuBcLink has to be created in RNC. The recommended configuration of the IuBcLink can be found in Table 2 below.

Table 2 Iu-BC configuration

MO: =	=	Comment
IuBcLink=1	administrativeState = UNLOCKED	UNLOCKED will activate CBS
	cbcIpAddress [0..15]	IP address of the CBC according to IP address plan
	sourceIpAddressValidation = TRUE	It is recommended to set the parameter to TRUE

4.6 Iub Transport

The new logical channel CTCH is carried over the existing transport bearer established for FACH1.

5 Activation and Deactivation

This section describes activation and deactivation of the CBS features.

5.1 FAJ 121 1326, Cell Broadcast Service

Cell Broadcast Service (FAJ 121 1326) is an optional feature.

5.1.1 Preconditions for activation

• Order and install the feature Cell Broadcast Service (FAJ 121 1326).

5.1.2 Activation

In order to activate CBS operation the following steps must be performed:

1. Activate and install the license key for Cell Broadcast Service (CXC 403 0043) in RNC. The feature activates by RNS when the featureState attribute, for designation cellBroadcastService, is set to ACTIVATED in the RncFeature MO.
2. Configure the Iu-BC link as described in Section 4.5.2.
3. Make sure that the cells in which CB messages are to be broadcast are enabled and that a CBSA is defined for each cell, see Section 4.1.

Note that the actions described in 1-3 above can be performed in any order.
As soon as step 1 and 3 are performed, the CTCH configuration is included in system information, SIB5, and the UE will start monitoring the CTCH occasions on S-CCPCH in cells where a CBSA has been defined. However, no CB messages can be broadcast in the cells as long as the Iu-BC link is not configured.
Once all steps 1, 2 and 3 are performed, RNC informs CBC about the service areas that are operable by sending a SABP RESTART message. The SABP RESTART message contains a list of all defined CBSAs within the RNC.
If a cell with a defined CBSA becomes disabled the broadcast is stopped in that cell and all stored CB messages are cleared. As soon as the cell is up again a restart indication is triggered for the cell. To avoid that SABP RESTART messages are sent too often over the Iu-BC interface a periodic timer of 30 seconds is implemented in the RNC to monitor the restart indications. Whenever the timer expires RNC will send a SABP RESTART message to CBC containing a list all CBSAs that have triggered a restart indication during the last 30 seconds. If there were no restart indications when the timer expires, no SABP RESTART message is sent for that period.

5.1.3 Preconditions for Deactivation

None.

5.1.4 Deactivation

The feature deactivates when the featureState attribute, for designation cellBroadcastService, is set to DEACTIVATED in the RncFeature MO.

5.2 FAJ 121 1406, Cell Broadcast Service - UE battery consumption improvements

Cell Broadcast Service - UE battery consumption improvements (FAJ 121 1406) is an optional feature.

5.2.1 Preconditions for activation

• Order and install the feature Cell Broadcast Service (FAJ 121 1326).
• Order and install the feature Cell Broadcast Service - UE battery consumption improvements (FAJ 121 1406).

5.2.2 Activation

In order to activate the feature the following steps must be performed:

1. Activate and install the license key for Cell Broadcast Service - UE battery consumption improvements (CXC 403 0070) in RNC. The feature activates by RNS when the featureState attribute, for designation cbsBatteryImprovements, is set to ACTIVATED in the RncFeature MO.
2. Activate feature Cell Broadcast Service (FAJ 121 1326) as described in Section 5.1.2.

Note that the steps 1 - 2 can be performed in any order.

5.2.3 Preconditions for Deactivation

None.

5.2.4 Deactivation

The feature deactivates when the featureState attribute, for designation cbsBatteryImprovements, is set to DEACTIVATED in the RncFeature MO.

6 Engineering guideline

6.1 CBS Level 1 Scheduling

The CTCH will share existing S-CCPCH resources used for SRB signalling and PS Interactive data on FACH. However, transmission of BMC messages will have highest priority in the RNC during a CTCH occasion. Thus the parameter ctchOccasionPeriod can be used to control the maximum bandwidth of the CTCH channel that can vary from 0.12 kbps (ctchOccasionPeriod = 256) up to 30.4 kbps (ctchOccasionPeriod = 1). If there are no BMC messages to transmit in a CTCH occasion, the TTI can be used by RNC to send other FACH1 or FACH2 data. Note that if the CTCH occasions are scheduled frequently, and the CBS load is high in the cell, the transmission of SRB signalling and PS Interactive data on FACH1 and FACH2 might get delayed.
When the Level 2 Scheduling is not applied a UE in idle mode and state URA_PCH must listen to every CTCH occasion scheduled on S-CCPCH even if it does not contain any CTCH data. If the CTCH occasions are scheduled frequently on S-CCPCH it will impact the UE battery consumption in idle mode and URA_PCH state. Thus the setting of the parameter ctchOccasionPeriod is a trade off between maximum CTCH bandwidth and UE standby time.
If a CTCH occasion conflicts with a paging occasion, the UE will prioritize paging before reading CTCH. The paging occasions are calculated based on the IMSI and the DRX cycle length coefficient. Different DRX cycle length coefficients can be configured for UEs in idle mode and in state URA_PCH, see Idle Mode and Common Channel Behavior.

Note:

In order to avoid that the same UE will miss all CTCH occasions it is important to make sure that the ctchOccasionPeriod is not set to a multiple of the DRX cycle length.

Note:

Changing the attribute ctchOccasionPeriod will affect any ongoing traffic in the cell. Whenever its value is set, the cell is disabled automatically and then re-enabled.

6.2 CBS Level 2 Scheduling

The Level 2 Scheduling introduces a DRX mode for CTCH reception that makes it possible to reduce the power consumption in the UE when CBS is activated in WCDMA RAN. Based on the schedule information the UE knows beforehand when there is a need to read CTCH. Only if a CTCH occasion contains a BMC Schedule Message or a new BMC CBS Message the UE is required to listen to S-CCPCH. For all other CTCH occasions the UE can remain idle.
Since a BMC Schedule Message is transmitted once every CBS schedule period the length of the period, defined as (cbsSchedulePeriodLength * ctchOccasionPeriod / 100) seconds, controls how often the UE must read S-CCPCH. It should be noted that the size of a BMC Schedule Message is variable and the message can be transmitted in several CTCH occasions. The size depends on the setting of parameter cbsSchedulePeriodLength and the amount of user data scheduled in the period. When the schedule period contains no messages (or only a few messages) the BMC Schedule message will typically occupy {1, 1, 2, 3, 4} CTCH occasions for cbsSchedulePeriodLength = {8, 16, 32, 64, 128}.
The Level 2 Scheduling will increase the time to delivery (TTD) for new cell broadcast messages, that is, there will be a delay from reception of SABP WRITE-REPLACE in RNC until the BMC CBS Message can be transmitted on CTCH the first time. This is because the schedule information associated with the BMC CBS Message must be sent in a CBS schedule period prior to the one containing the actual user data. The TTD is typically between one and two CBS schedule periods.
To get an optimal setting of the parameters ctchOccasionPeriod and cbsSchedulePeriodLength the TTD requirement as well as the UE battery consumption must be considered. The recommendation is to use the highest possible value of ctchOccasionPeriod and then adjust the parameter cbsSchedulePeriodLength to get an acceptable delay for the first transmission of the BMC CBS Message. For example, if the TTD requirement is 90 seconds a setting of ctchOccasionPeriod = 255 and cbsSchedulePeriodLength = 16 is recommended. With this setting the CBS contribution to UE battery consumption can theoretically be reduced by 16 times compared to the scenario where only Level 1 Scheduling is applied. A TTD requirement of 11 minutes can theoretically reduce the UE battery consumption by 32 times using a setting of ctchOccasionPeriod = 255 and cbsSchedulePeriodLength = 128.
It should be noted that all segments of a BMC CBS Message must be transmitted within the same schedule period, that is, the lower values of parameter cbsSchedulePeriodLength should not be used for broadcast of long BMC CBS messages. If the size of the message is larger than 3-pages the cbsSchedulePeriodLength parameter should use a setting of 16 (or higher), if the message size is larger than 6-pages a setting of 32 (or higher) should be used, and for messages larger than 13-pages a setting of 64 (or higher) is recommended. If the schedule period is too short the BMC CBS message is discarded in RNC and counter pmNoDiscardedBmcCbsMsgs is stepped.

Note:

cbsSchedulePeriodLength 256 is not a valid setting according to 3GPP and should not be used.

Note:

Changing the attributes cbsSchedulePeriodLength and ctchOccasionPeriod will affect any ongoing traffic in the cell. Whenever their values are set, the cell is disabled automatically and then re-enabled.

7 Parameters

This section describes all parameters that the operator can configure to control the CBS features in WCDMA RAN. Further parameter information can be found in Radio Network Parameters.

7.1 Descriptions

cellBroadcastSac		Cell Broadcast Service Area Code within a location area. The parameter can be set per cell.
ctchOccasionPeriod		Period of CTCH allocations on S-CCPCH. The parameter can be set per cell.
cbsSchedulePeriodLength		Number of consecutive CTCH occasions on S-CCPCH that, together with the CTCH occasion period (configured through UtranCell.ctchOccasionPeriod), define a CBS schedule period. The parameter can be set per cell.
cbcIpAddress		IP address of the CBC. The input format used by the operator is four fields of digits, separated by dots. Each field may consist of three digits. The value of each field shall be in the range 0..255.
sourceIpAddressValidation		Indicates if the source IP address shall be validated when the CBC establishes a connection. When set to TRUE, only a source IP address equal to cbcIpAddress is accepted.

7.2 Range and Default Values

Table 3 WCDMA RAN Cell Broadcast Parameters

Parameter Name	Default Value	Value range	Unit of Measurement
cellBroadcastSac	-1 [undefined]	-1..65535 [undefined, 0..65535]	-
ctchOccasionPeriod	256	1..256	10 ms
cbsSchedulePeriodLength	64	[8, 16, 32, 64, 128, 256] Note 1	Number of consecutive CTCH occasions on S-CCPCH per CBS schedule period
cbcIpAddress	-	Four fields of digits, separated by dots. Each field may consist of three digits. The value of each field shall be in the range 0..255.	-
sourceIpAddressValidation	TRUE	FALSE, TRUE	-

Note 1: 256 is not a valid setting according to 3GPP and should not be used.

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