If you have any questions about anything for TELECOMMS environment or some suggestion to improve our BLOG, please letme know! Please to help us to keep this blog, just a quickly click on the advertising, just click it and improve your knowledge!eng.emerson.eduardo.rodrigues skype

Fine Optimization Engineers

Developed for IT and Telecom EngineersMadrid, Madrid, Spain

Blog for Engineers, Operators and students of telecom environment. If you have any doubt or suggestion, please don´t hesitate to contact me using my skipe: eng.emerson.eduardo.rodrigues

View my complete profile

المدونة اإللكترونية التالية» المزيد تسجيل الخروج۰ لوحة التحكم الرئيسية atbarawi14@gmail.com

Friday, June 3, 2011

Capacity Management WCDMA RAN

Ericsson's WCDMA RAN (Wideband Code Division Multiple Access Radio Access Network) Capacity Management solution, with support from other radio network functions, controls thestability and accessibility in the WCDMA cell. This enables the system to provide the requested Quality of Service (QoS) and coverage for individual connections. Capacity Managementfunctions 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

As a highlevel description, this document explains the capabilities, function and logic of the Capacity Management solution. It also describes parameters and engineering guidelines related tothe 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.

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

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 usersTable 3 updated to include IF/IRAT mobility on HSPA

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 individualconnections. 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 Managementsolution consists of three main functions:

System Resources Handling

RN Admission Control

RN Congestion Control

Figure 1 shows the general overview of Capacity Management functions.

1 Introduction

1.1 Scope

1.2 Target Groups

1.3 Revision Information

2 Overview

There was an error in this gadget

2011 (17)

September (8)

June (9)

Jun 08 (1)

Jun 03 (8)

Capacity Management WCDMA RAN

Verifying the UMTS Services HUAWEI Equipment

Multiuser CooperativeDiversity and Virtual MIMO

Multiuser CooperativeDiversity and Virtual MIMO

LTE CS Fallback Procedure

CA (Carrier Aggregation)Scenarios in LTEAdvanced...

WCDMA RAN 7 HandoverTypes SIDE 2

WCDMA RAN 7 HandoverTypes SIDE 1

Blog Archive

There was an error in this gadget

Join this sitew ith Google Friend Connect

Members (4)

Already a member? Sign in

Followers

Search This Blog

Figure 1 General Overview of Capacity Management Functions

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 aWCDMA 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 resourceswithin the selected set.

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 radioconnections 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 Controlfunction 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 ora 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 arequest, RN Soft Congestion evaluates whether to reduce the rate of one or more existing low priority users or whether to preempt one or more Radio Access Bearers (RABs) (implies therelease 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 examplesuch as the Handover function, see Reference [5].

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 sufficientto 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 theresource, 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

2.1 System Resource Handling

2.2 RN Admission Control

2.3 RN Congestion Control

Search

Emerson Eduardo Rodrigues

Criar seu atalho

Atalho do Facebook

Make Top Rank Blog

Wowziograb this · technology blog

Wowzio Live Activity Feed

Where am I?

Feedjit traffic tracker

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 (asthey 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 nonHSDPA DL transmitted carrier power in a cell reaches critical levels and the RN Congestion Control blocks all admission requests in the cell, while congestionresolve actions are taken to reduce the resource utilization. The situation is restored when nonHSDPA 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 congestionresolve actions to rebalance 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 nonGBR users as well as GBR users.

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

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, andeach instance is located in the Controlling Radio Network Controller (CRNC).

Figure 2 Capacity Management Architecture OverviewIn 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 forWCDMA subnetwork) 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 RNAdmission 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

2.4 Connection to other Functions

2.5 Allocating Functions

Welcome To Feedjit

There was an error in this gadget

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) messageover 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 Iurinterface.

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.

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 toprovide the coverage and QoS for individual connections.

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

Downlink channelization codes

Downlink transmitted carrier power, nonHS part and HSrequired 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 nonserving 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.

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 thedownlink 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 ADCHs)

SF CCH is the spreading factor of the common control channels including HSSCCH, EHICH, ERGCH, EAGCH as well as MTCH, MICH and MCCH channels for MBMS

p is the number of DL codes reserved (SF = 16) for HSDSCH it is set by the parameter numHsPdschCodes see Section 3.4.5

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 reconfiguration of the radio connection. This is accomplished by the RBS measuring nonHSDPA and HSrequired 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

3 Technical Description

3.1 System Resource Handling

3.1.1 Downlink Channelization Codes Monitor

3.1.2 Downlink Transmitted Carrier Power Monitor

the utilization.

As a basis for RN Congestion Control in detecting both the occurrence and resolving DL overload on the nonHSDPA DL transmitted carrier power. This is accomplished by the RBSreporting the event of the nonHSDPA DL transmitted carrier power in a cell exceeding a level for some time, and reporting the event of the nonHSDPA DL transmitted carrier powerin 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 RBSmeasuring the HSrequired carrier power in a cell periodically and reporting (each second) the measurement to the CRNC. The CRNC will use the combination of this measurementand the nonHSDPA DL transmitted carrier power measurement to detect both the occurrence and resolving of the DL HS overload. For more details on how the HSrequired power isdetermined 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 nonHSDPA and HSrequired DL transmitted carrier power of a cell periodically, reporting (each second) the measurement to the CRNC, and filtering the measurement in the CRNC tofollow 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 theHSDPArequired power may consist of the power required for guaranteed bit rate connections, as well as a minimum power reserved for nonguaranteed bit rate connections, see HSDPA UserPlane, Reference [8]

The ASE intends to express to some extent the static load on the airinterface caused by radio bearers in a connection in a cell relative to the static load caused by a set of radio bearerscarrying 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 HSDSCH + guaranteed rate EDCH + 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 HSDSCH: the guaranteed rate of the HSDSCH macd flows in a radio connection

guaranteed rate EDCH: the guaranteed rate of the EDCH macd 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 cellis 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 averageuplink 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 onlyrequires 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 ofradio links in a connection for connections originating over Iur. A consequence of the preRNC division is the possible overestimation of the ASE UL value for connections using Iur, compared tothe 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

standalone 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 PS64/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.3 ASE 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 tothe 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 fora 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 partyeffects, the uplink RTWP is used by RN Congestion Control in order tocontrol these dynamic effects and block the setup or modification of new RABs. In order to detect an uplink overload situation, eventbased measurements are performed in the RBS; if apredefined level is exceeded, uplink congestion is detected in a cell.

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 hardwareutilization 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 NBAPSignalling, 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 andDL, to the CRNC. The definition of these consumption laws is connected to the HW costmodel of the RBS. There may be different cost models for different channels types and for differentRBSs (depending on HW type used), and therefore the HW costmodel in uplink may differ. The default uplink DCH costmodel for an RBS may be changed by means of the 'UL CEladder'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 casethe 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 bycalculating the change in CE in uplink and downlink and updating the monitor accordingly.

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 resourcesthat 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 Congestionfunctionality 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.

3.1.4 Received Total Wideband Power Monitor

3.1.5 RBS Hardware Monitor

3.2 RN Admission Control

Figure 5 Admission and Max Level concept

Up till the Admission Level, the request is admitted

Between the Admission and Max Level, (guaranteed, nonhandover) or (nonguaranteed, nonhandover/handover) requests are not admitted unless RN Soft Congestion actions canfind 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.

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

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 nonguaranteed connection parts (used in the evaluationof 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 requestclass. PS interactive is set to guaranteed only if it is accompanied to streaming service at 8 kbps. Otherwise it is nonguaranteed. When the request is for resources exceeding theminimum needed for satisfying the QoS (for example upswitch interactive PS to a higher dedicated rate), the request is nonguaranteed. Example of a nonguaranteed request is PSinteractive.

The preemption 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. Preemptionresults in the release of one or more RABs according to their priority and preemption 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 RANAPattributes, 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 preemption capability indicator (PCI) which consists of two values, 'shall not trigger preemption' and 'may trigger preemption' (this indicates the preemption capability of therequest).

The preemption vulnerability indicator (PVI) with the values “not preemptable” and “preemptable”. Note that the preemption vulnerability indicates whether a RAB in the connectioncan be released due to the admission of a higher priority, preemption 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 includesa conversational CS speech RAB and interactive PS RAB, a reconfiguration of the interactive PS connection part would lead to determination of the request attributes based on that connectionpart only. In case more connection parts are basis for request attribute determination, the following is applied:

3.2.1 Admission Request Attributes

The request class is nonguaranteed if at least one of the connection parts for which admission is requested is nonguaranteed. For example when adding conv. CS Speech(guaranteed) and Interactive PS 64/64 (nonguaranteed, as PS 0/0 is a lower resource consuming alternative) the request class is nonguaranteed.

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) andInteractive 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 preemption capable.

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 canlower its rate or be preempted. The behavior of RN Soft Congestion control differs depending on the request class: Nonguaranteed requests:

Can reduce the rate of other lower priority, nonguaranteed connection parts in steps (for example from interactive PS 384/64 to interactive PS 128/64), down to their lowestretainable 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 anequal priority interactive PS 128/64 to interactive PS 64/64, but not to lower rates).

Guaranteed requests:

Can reduce the rate of any priority, nonguaranteed connection parts in steps down to their lowest retainable rate. If that is not sufficient, RN Soft Congestion can preempt existingguaranteed RABs of lower priority, or nonguaranteed RABs at the lowest retainable rate if request is preemption capable and connection part targeted is preemption vulnerable (forexample conv. CS Speech (priority=3, preemption capable) can preempt conv. CS unknown (priority=4, preemption 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 arenot targeted.

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 thatresource 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 certainadmission 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 moreadmission 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, (GBRpart on HSDPA and SRBpart on DCH) Yes, (GBRpart on HSDPA and SRBpart on DCH) Yes, (GBRpart 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

Nonserving EUL Adm Policy No No Yes No

DL RBS HW Adm Policy Yes Yes Yes Yes

3.2.2 RN Soft Congestion

3.2.3 Admission Policies3.2.3.1 Introduction

UL RBS HW Adm Policy Yes Yes Yes No

MBMS Adm Policy No No No Yes

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 (nonguaranteed, nonhandover/handover) or (guaranteed, nonhandover) are conditionally blocked when the current DL channelization code is exceeding thedlCodeAdm level.

Admission requests (guaranteed, handover) are blocked if the usage arrives at 100% utilization (RN Soft Congestion action triggered).

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

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 (nonguaranteed, nonhandover/handover) or (guaranteed, nonhandover) are conditionally blocked when the monitored DL transmitted carrier power is exceedingthe 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.

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

Admission requests (nonguaranteed, nonhandover/handover) and (guaranteed, nonhandover) 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 AdmissionControl 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.

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

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

Admission requests (guaranteed, handover) are never blocked.

The Spreading Factor Admission Policy is divided into DL and UL for NonGuaranteed and Guaranteed Service Classes. NonGuaranteed Service Class Limits in Downlink RN Admission Control blocks nonguaranteed 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 isabove the following load control levels. Figure 6 shows the policy comprising:

Admission requests (nonguaranteed, handover/nonhandover) demanding spreading factor 8 in downlink are blocked when the usage of this spreading factor exceeds sf8Adm.

Admission requests (nonguaranteed, handover/nonhandover) demanding spreading factor 16 in downlink are blocked when the usage of this spreading factor exceeds sf16Adm.

3.2.3.2 The Downlink Channelization Code Admission Policy

3.2.3.3 The Downlink Transmitted Carrier Power Admission Policy

3.2.3.4 ASE Admission DL Policy

3.2.3.5 ASE Admission UL Policy

3.2.3.6 Spreading Factor Admission Policy

Admission requests (nonguaranteed, handover/nonhandover) 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/nonhandover) admission in case the resource usage plus the requested spreading factor 16 in DL (for example, streamingPS16/128 radio connection type) if the usage of this spreading factor exceeds sf16gAdm.

NonGuaranteed Service Class Limits in Uplink RN Admission Control blocks nonguaranteed request class requests in uplink, in case the resource usage plus the requested number of radio links per UL spreading factor usage ina cell is above the following load control levels.

Admission requests (nonguaranteed, handover/nonhandover) demanding spreading factor 4 in uplink (for example, PS384/HS radio connection type) if the usage of thisspreading factor exceeds sf4AdmUl.

Admission requests (nonguaranteed,handover/nonhandover) demanding spreading factor 8 in uplink if the usage of this spreading factor exceeds sf8AdmUl

Admission requests (nonguaranteed, handover/nonhandover) 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/nonhandover) admission in case the resource usage plus the requested spreading factor 8 in uplink if the usage of thisspreading factor exceeds sf8gAdmUl.

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 linksexceeds the parameter compModeAdm. This is to limit the UL/DL air interface due to compressed mode.

RN Admission Control blocks new radio link admission requests which involve the allocation to HSPDSCH/HSSCCH when the number of users assigned to the HSDSCH in thecell 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 HSusers. 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 HSDSCH cellchanges. Note that the Serving admission policy is only applied to requests for new HSDPA connections, which follow the Serving HSDSCH Cell Selection during RABEstablishment. Therefore, requests related to mobility of existing HSDPA connections, which follow the Serving HSDSCH Cell Change, are never blocked by the Serving HSadmission 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 parametermaxNumHsdpaUsers. Configurations exist where the licenses/parameters can exceed instant HW resources and in these cases, admission policies will fail to maintain margins andrejects will come from the RBS instead. There may also be admission blocking of HSDSCH users due to that there is a shortage of channel elements for ADCH, (ADCH channelelements resources are generally configured based on license level, max number of users parameters and number of HSDSCH resources, but can also be configured through theparameter maxNumADchReservation. For more details see Configuring HSDPA and EUL, Reference [19].

To monitor the number of users assigned to the physical EUL channels, two load control levels are defined by the eulServingCellUsersAdm and eulNonServingCellUsersAdmparameters. 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 thetotal 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 asnonserving cell. This is to be able to limit the amount of UL HW reserved for the nonserving connections. Therefore eulNonServingCellUsersAdm is used to be able to limit thenumber of EUL users having the cell as nonserving cell. RN Admission Control will reject an EUL user, requesting the cell as nonserving cell if the total number of nonserving cellEUL 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 thresholdeulServingCellUsersAdmTti2 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 withinthe set of eulServingCellUsersAdm which contains both 2 ms TTI and 10 ms TTI.

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 bythe parameter dlHwAdm for DL.

(Nonguaranteed, nonhandover/handover) and (guaranteed, nonhandover) admission requests are conditionally blocked when the resource usage exceeds the dlHwAdmlevel.

(Guaranteed, handover) admission requests are blocked when the downlink hardware usage arrives at 100% utilization (of the licensed value) (RN Soft Congestion is

3.2.3.7 Compressed Mode Radio Admission Policy

3.2.3.8 Serving HS Admission Policy

3.2.3.9 Serving and nonserving EUL Admission Policy.

3.2.3.10 The RBS Hardware DL Admission Policy

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 anadmission request is blocked on DL HW, connections in the cells connected to the same HW group are possibly targeted

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 theparameter ulHwAdm for UL.

(Nonguaranteed, nonhandover/handover) and (guaranteed, nonhandover) admission requests are conditionally blocked when the resource usage exceeds the ulHwAdmlevel.

(Guaranteed, handover) admission requests are blocked when the uplink hardware usage arrives at 100% utilization (of the licensed value) (RN Soft Congestion istriggered).

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 anadmission request is blocked on UL HW, connections in the cells connected to the same HW group are possibly targeted.

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 nonpreferred layer sessions is exceeded in the cell, the request will trigger RN Soft Congestion actions towards lower priority MBMS sessions.

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 HSDPAoverload see Section 2.3. Capacity Management has been updated to remove the differentiation of the guaranteedhs connection types as separate class. As a consequence, theinteractive/background PS services mapped on HS are not targeted during a DL cell congestion situation, while guaranteed services are targeted according to the guaranteed classdifferentiation settings.

Congestion detection is triggered by UL cell congestion, DL cell congestion and DL HSDPA 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

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 exceedsa certain configurable threshold for a longer time than the hysteresis time. The threshold for detection of downlink congestion is determined by the parameters pwrAdm + pwrOffsetand 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 thehysteresis time.

3.2.3.11 The RBS Hardware UL Admission Policy

3.2.3.12 The MBMS Admission Policy

3.3 RN Congestion Control

3.3.1 Congestion Detection

3.3.1.1 Uplink Cell Congestion Detection

3.3.1.2 Downlink Cell Congestion Detection

Figure 8 Detection of Downlink Cell Congestion Due to Downlink Transmitted Carrier Power

The DL transmitted carrier power is considered DL HSDPAoverloaded if the monitored nonHS DL power + HSrequired DL power > 100% utilization for a hysteresis timemaxPowerOverloadHystTime. This is indicated in the Figure 9. The nonHS DL power and the HSrequired power is reported by the RBS, see Reference [8] for more details.

Figure 9 Overload control using the HSrequired power and nonHS required power

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 inthe 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 arebased 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 ofASE in downlink to be released each congestion resolve action) is configurable per request class. For Iuoriginating connections, the ASE in downlink is released (when possible) byswitching 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 aretargeted in order of ARP priority, ignoring the preemption 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 nonguaranteed and guaranteed radio connections inthe congested cell.

Figure 10 Differentiation in Downlink Cell Congestion Resolve HandlingAfter detection of overload, an immediate action is taken to release releaseAseDlNg of ASEs in downlink for nonguaranteed service class connection in order of priority and thetimer tmInitialG is started. If after the initial congestion resolve action there are nonguaranteed service class connections remaining in the cell and the congestion situationpersist, 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 nonguaranteed

3.3.1.3 DL HSDPA congestion detection

3.3.2 Congestion Resolve Handling

service class connections are released and the timer tmInitialG is expired, timer tmCongAction is started. Then, releaseAseDl amount of ASEs in downlink for guaranteedservice class connections are released in a periodical fashion until the congestion situation in the downlink is resolved. Setting releaseAseDlNg or releaseAseDl to 0 means thatno congestion resolve actions are initiated on the nonguaranteed or guaranteed radio connections respectively Basically, when nonHS 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) Nonguaranteed RABs on dedicated, nonshared radio channels are reduced to their lowest retainable rate in the current radio configuration

Step 2) Guaranteed RABs and nonguaranteed RABs (remaining after step 1 and not on 0 kbps or on common radio channels) on dedicated, nonshared radio channelsare released

Note that neither guaranteed nor nonguaranteed RABs on HSDPA radio channels are targeted during these steps, as they are not contributing to the nonHS DL transmitted carrierpower overload situation. When DL HSDPA overload is detected, or a combination of nonHS 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) Nonguaranteed RABs on dedicated, nonshared 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 nonguaranteed RABs (remaining after step 1 and not on 0 kbps or on common radiochannels) on dedicated, nonshared radio channels are released

Note that the nonguaranteed RABs on HSDPA radio channels are not targeted during these steps, as they are controlled by the HSDPA Scheduler. Note that neither SRBonly northe 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 whichhave a higher allocation/retention priority than the connections being targeted.

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 HSPDSCH channel codes (SF=16) that can be allocated for a HSDPA capable cell there is one limit:

Maximum Number of HSPDSCH Codes

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 transmiton 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 estimationof the system resource monitoring.

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 toomuch 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 isrelative to primary CPICH power in a cell.

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, themaximum 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 percell definable mapping, based on the maximum rate of the radio link. Currently, threemapping points can be configured, through which inbetween 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.

3.4 Capacity Management Related Configurations

3.4.1 Maximum UE Transmitted Power

3.4.2 Minimum Downlink Transmitted Code Power

3.4.3 Maximum Downlink Transmitted Code Power

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 theprimary 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 aremapped 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 themaximum radio link rate for each connection type.

Table 4 Maximum Radio Link Rate for some RadioConnections , 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 ADCH. Note also that maximum downlink transmitted code power must not be set to a lower value than the minPwrRl.

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 settingup or reconfiguring a cell; when maximumTransmissionPower is higher than the maximum downlink power capability reported by the RBS, the latter is automatically taken as thelimit of the total maximum power allowed in the cell. This mechanism simplifies setup and reconfiguration of cells and enables the UTRAN to handle changes in RBS maximumdownlink 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 measurementsused by the Downlink Transmitted Carrier Power Monitor (see Section 3.1.2). As for HSDSCH transmission, the process in the RBS that determines the estimation of the remaining power and the allocation to the HSPDSCH/HSSCCH codes is described inHSDPA User Plane, Reference [8] and Power Control, Reference [11].

The operator can configure the number of HSPDSCH codes (SF=16) that should be reserved for a HSDPA capable cell by setting numHsPdschCodes. The maximum number of HSPDSCH codes is dependent on license level and parameter maxNumHsPdschCodes; up to 15 codes may be allocated. With a high number of HSPDSCH codes allocated, the risk forcode blocking will however increase and allocating 15 HSPDSCH codes from the RNC is not advised. The number of HSPDSCH codes in use for HSDSCH transmission may alsobe 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 changingthe parameter maxNumHsPdschCodes The number of HSSCCH codes (SF=128) in use is controlled with the numHsScchCodes parameter. The number of HSSCCH codes configured controls how many users that maysimultaneously be scheduled per 2 ms TTI, see HSPDA User Plane.

3.4.4 Maximum Downlink Transmission Power

3.4.5 Maximum Number of HSPDSCH Codes

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 HSPDSCH 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 costmodel 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 EDCH 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 deployingmore 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 firstbaseband 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]

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 inthe sense that AMR codecs are changed during an ongoing speech connection; rather there is a possibility to adapt the rate at RAB establishment.

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 radioconnection 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 beselected (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 isexcluded 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 thresholdsetting and load measurement suggests otherwise.

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 disablethe 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 cellswhere 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. Anotheraspect 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

3.6 Initial rate selection for AMR NB

3.6.1 Initial selection algorithm

4 Engineering Guidelines

4.1 RN Admission Control4.1.1 ASE Admission Policy

services. To be able to secure system stability, the current ASE for each link for all bearers except speech assumes high activity (7080%). Typically, the activity factor for a packetconnection 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 ASEusage 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 nonguaranteed, nonhandover due to removed best effortmargin, will have limited impact. The reason is that even if more nonguaranteed packet data connections are admitted, RN Soft Congestion can downswitch these connections tolowest retainable rate (CELL_FACH) at congestion, while a new incoming connection is allowed according to the conditionally blocking principle. Thus keeping the P5 configurationof 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. Innetworks 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.

The downlink transmitted carrier power admission policy controls the downlink power utilized by release99 channel connections. The remaining power can then be used fortransmission of HSPDSCH/HSSCCH channels to HSDPA users. By changing the setting of pwrAdm, the portion of downlink power at admission reserved for HSDPA connectionscan 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 UserPlane. 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 PAcapability 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 thetotal 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 iscaused by such a change.

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 SoftCongestion can trigger lower rates on lower priority, nonguaranteed connections. It is possible to further tune the default parameter settings for increased capacity. ChangingdlCodeAdm 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 thatthe 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.

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 besteffort 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 defaultparameter values for sf8AdmUl and sf16AdmUl to avoid unnecessary restriction of accessibility.

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 intoconsideration the tradeoff between number of HS users and user throughput. It should be noted that users accessing the cell using HSDSCH cell change are never rejected due tothis 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 andreducing 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 throughputconnection should be considered when setting the value of the parameter. The number of simultaneous HSDPA users is closely related to the configuration ofhsdschInactivityTimer 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.

The parameters eulServingCellUsersAdm and eulServingCellUsersAdmTti2 can be set to limit a large number of EUL users in the serving cell, which otherwise may cause toopoor 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 admissionlimits 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]. ParameterseulServingCellUsersAdm and eulNonServingCellUsersAdm limit the total number of EUL users, i.e. both 2ms TTI and 10ms TTI EUL users, while eulServingCellUsersAdmTti2only 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 EULusers (FAJ 121 1129) as set in the RBS.

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 isreserved 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 congestionfunctionality. When setting the admission thresholds it is important to consider any capacity requirement, especially for low capacity cells. This means reviewing the capacityrequirement 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

4.1.2 The Downlink Transmitted Carrier Power Admission Policy

4.1.3 The Downlink Channelization Code Admission Policy

4.1.4 The Spreading Factor Admission Policy

4.1.5 The Serving HS Admission Policy

4.1.6 The serving and nonserving EUL Admission Policy

4.1.7 The RBS Hardware Admission Policy

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 admissionstatistics 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 asaverage and square average measurements. The 8 new counters are pmDlCredits, pmUlCredits, pmSumDlCredits, pmSumSqrDlCredits, pmSamplesDlCredits, pmSumUlCredits, pmSumSqrUlCredits andpmSamplesUlCredits.

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 toAMR 12.2 kbps. One alternative is to set parameters pwrLoadThresholdDlSpeech.amr7950 and aseLoadThresholdUlSpeech.amr7950 to 100, which triggers allocation of AMR7.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 alower 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 beingperformed at admission and that no reconfiguration of rate is possible on ongoing calls.

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 pwrAdmand 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 unnecessaryblocking 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 inthe downlink transmitted carrier power, which may be influenced by the UE behavior, radio environment and power control settings.

It is possible to reserve DL carrier power for nonGBR HS service users by configuring the RBS parameter schMinPowerNonGbrHsUsers, see Reference [8], for parameter details. Iffor example this parameter is set to 20%, then 20% of the DL carrier power will be reserved for the nonGBR HS users if needed. If the nonGBR HS users are satisfied and are usingfor example 4% of the power, then 4% is reported as HSDSCH required power by RBS. But if congestion is detected for the nonGBR HS users, see HSDPA User Plane,schMinPowerNonGbrHsUsers is reported as HSDSCH required power instead of measured power. DL HSDPA congestion detection is triggered when any of the GBR HS users and/or the group of nonGBR HS users are unsatisfied for a period of maxPowerOverloadHystTime. TheGBR HS users are unsatisfied when not fulfilling the delay requirements for each SPI. The group of nonGBR users is unsatisfied if the DL carrier power ratio set by parameterschMinPowerNonGbrHsUsers 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 nonGBR HS traffic. Note, that a high parameter value will as a first step in a congestionscenario 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 theactual number of priority queues the soft HSDPA reservation schMinPowerNonGbrHsUsers may appear as a fixed reservation as it is always used for nonGBR HS.

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 arecompensated 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 canvary 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 thedetection 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 thissetting 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 themeasurements and may therefore trigger the congestion detection if not considered. When setting parameter iFHyst, short duration of UL interference peaks should be disregardedas, 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 theremight 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].

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

4.1.8 AMR NB Rate Selection Policy

4.2 RN Congestion Control4.2.1 Congestion Detection4.2.1.1 Downlink Cell Congestion Detection

4.2.1.2 DL HSDPA Congestion Detection

4.2.1.3 Uplink Cell Congestion Detection

4.2.2 Congestion Resolve Handling

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 testshave 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 downlinkpower 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 Controlfunction 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 allowedmaxDlPowerCapability in the RBS (see Section 4.3.3).

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 intoaccount 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 tosupport 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 itwill 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).

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 examplewhen 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 tomaxDlPowerCapability.

Dynamic Code Allocation (see also HSDPA User Plane) is turned on using parameter dynamicHsPdschCodeAdditionOn. Live network verifications show improved performance andcapacity 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 DynamicCode Allocation is activated it is beneficial to set the number of allocated HS_PDSCH codes ( numHsPdschCodes) to a requested tradeoff level between capacity and performance. Atoo high value can cause an over allocation of resources for HSDPA, meaning that nonHSDPA traffic may suffer from unnecessary congestion of codes. If a too low value is usedHSDPA traffic may suffer from reduced performance as the codes are prioritized for nonHSDPA traffic. In networks with high nonHSDPA traffic it is often beneficial to reduce thesetting 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 HSPDSCH codes ( numHsPdschCodes), the codes that are to be released are transparently deallocated, 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 andActivation).

Parameter numHsScchCodes controls the number of HSSCCH codes used, and thereby number of simultaneous HSDPA users for each TTI. It is possible to achieve a higher HSDPAperformance 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 asusers with low rate and/or bursty application can share a TTI, which then improves performance.

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 caremust 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 (seeHandling 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 achange 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 keysmay 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 upgradeshould 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 theincrease 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 needto increase the RBS hardware capacity.

4.3 Capacity Management Related Configurations4.3.1 Minimum Downlink Transmitted Code Power

4.3.2 Maximum Downlink Transmitted Code Power

4.3.3 Maximum Downlink Transmission Power

4.3.4 Dynamic Code Allocation and Number of HSPDSCH Codes

4.3.5 Number of HSSCCH Codes

4.4 Feature/Capacity Key Handling

5 Parameters

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

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

maxTxPowerUl Used in UE functions for cell selection/reselection in idle mode and connected mode and also used by UTRAN to control the maximumtransmitted 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 alevel 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 HSPDSCH codes allocated in a cell.

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 HSDSCH. Applicable to admission requests related toRAB 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 nonserving cell.

eulServingCellUsersAdmTti2 Cell parameter that defines the admission threshold for the number of 2 ms TTI EDCH users having this cell as serving cell. Applicable at servingcell change, at RAB establishment and at reconfiguration 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 nonguaranteed 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 admissionrequests will continue to be allowed. Reaching or exceeding this number of radio links (any service class) using downlink spreading factor = 16 willblock 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

5.1 Descriptions5.1.1 System Resource Handling and Capacity Management Related Configurations

5.1.2 RN Admission Control

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

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 uplinkinterference remains over a predefined threshold iFCong for a longer time than iFHyst. Congestion is considered to be resolved when the uplinkinterference 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 downlinkpower load remains over pwrAdm + pwrOffset for a longer time than pwrHyst. Congestion is considered to be resolved when the downlink powerload 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.

releaseAseDl Cell parameter that defines the amount of ASEs to be released in the downlink in case cell congestion resolve actions target guaranteed service classconnections. 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 classconnections.

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 nonguaranteed service classconnections. If set to 0, no congestion resolve actions are initiated on nonguaranteed service class connections.

tmCongActionNg Cell parameter that defines the time interval between two cell congestion resolve actions targeting nonguaranteed service class connections.

pwrLoadThresholdDlSpeech.amr12200 DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR12.2 speech codec in setup of AMRNBmultirate

pwrLoadThresholdDlSpeech.amr7950 DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR7.95 speech codec in setup of AMRNBmultirate

pwrLoadThresholdDlSpeech.amr5900 DL Power threshold to be used in the initial AMR rate selection algorithm for selecting AMR5.9 speech codec in setup of AMRNB multirate

5.1.3 RN Congestion Control5.1.3.1 Congestion Detection

5.1.3.2 Congestion Resolve Actions

5.1.4 Initial rate selection for AMR NB

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 AMRNBmultirate

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

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

codeLoadThresholdDlSf128 Threshold to be used in the initial AMR rate selection algorithm for selecting SF128 or SF256based AMR codec modes in setup of AMRNB multirate.

maxNumHsPdschCodes Parameter that defines the maximum number of HSPDSCH codes that may be allocated in a cell. Observe that the cell has to be locked/unlocked whenchanging the parameter maxNumHsPdschCodes.

numHsScchCodes Parameter that determines how many HSSCCH’s that shall be configured.

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 moreconvenient 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 thatthe maximum UL

transmission power hasnot 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

5.1.5 Code allocation

5.2 Values and Ranges

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

TO HELP ALL OF ENGINEERS Developed for IT and Telecom Engineers at 6:44 AM

Reactions: (engraçado (0 (interessante (0 (legal (0

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

Recommend this on Google

No comments:

Post a Comment

Newer Post Older PostHome

Subscribe to: Post Comments (Atom)

Sign out

Notify me

Enter your comment...

Comment as: atbarawi (Google)

Publish Preview

Create a Link

Links to this post

44,173Total Pageviews

Project Remote? CONTACT ME!. Simple template. Template images by mariusFM77. Powered by Blogger.