Sunteți pe pagina 1din 477

HSxPA Parameters User Guide

Document number:
Document issue:
Document status:
Date:

UMT/IRC/APP/016664
V03.10
Standard
02/Oct/2009

External Document

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

V03.10
02/OCT/2009

Copyright 2007 by Alcatel-Lucent. All Rights Reserved.


About Alcatel-Lucent
Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service
providers, enterprises and governments worldwide, to deliver voice, data and video
communication services to end-users. As a leader in fixed, mobile and converged broadband
networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end
solutions that enable compelling communications services for people at home, at work and on
the move. For more information, visit Alcatel-Lucent on the Internet: http://all.alcatellucent.com
Notice
The information contained in this document is subject to change without notice. At the time
of publication, it reflects the latest information on Alcatel-Lucents offer, however, our
policy of continuing development may result in improvement or change to the specifications
described.
Trademarks
Alcatel, Lucent Technologies, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of
Alcatel-Lucent. All other trademarks are the property of their respective owners. AlcatelLucent assumes no responsibility for inaccuracies contained herein.

Alcatel-Lucent Proprietary

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

CONTENTS
1

INTRODUCTION

HSXPA OVERVIEW

HSDPA PRINCIPLES, SCHEDULING AND RESOURCE MANAGEMENT

E-DCH PRINCIPLES, SCHEDULING AND RESOURCE MANAGEMENT

CALL MANAGEMENT

MOBILITY

DEPLOYMENT SCENARIOS

Alcatel-Lucent Proprietary

V03.10
02/OCT/2009

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

HSXPA PARAMETERS USER GUIDE

INTRODUCTION

Alcatel-Lucent Proprietary

V03.10
02/OCT/2009

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

CONTENTS
1

INTRODUCTION..........................................................................................................................11
1.1

OBJECT ..................................................................................................................................11

1.2

SCOPE OF THIS DOCUMENT .....................................................................................................12

1.3

AUDIENCE FOR THIS DOCUMENT ..............................................................................................12

1.4

NOMENCLATURE .....................................................................................................................13

1.5

RELATED DOCUMENTS ............................................................................................................15

PARAMETERS ORGANIZATION ...............................................................................................16

ABBREVIATIONS AND DEFINITIONS.......................................................................................18


3.1

ABBREVIATIONS ......................................................................................................................18

3.2

DEFINITIONS ...........................................................................................................................23

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 1/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

PUBLICATION HISTORY
02/10/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 3:
Clarification of the recommendation concerning the mac-d PDU size for Cat.6
and 12
Range
of
serviceMaxRate,
serviceLowRate corrected

serviceMinRate,

serviceHighRate,

New recommendation for serviceHighRate


Class of numberOfHsPdschCodes and numberOfHsScchCodes corrected
New value concerning the TBS applied from maximum MCS for Category
10 and xCem (value applicable from UA6.0.5)
Update of the Engineering Recommendation concerning the maximum
HSDPA throughput for UE Cat.10

In Volume 5:
Recommended value for dlTxPowerEstimation corrected

24/09/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 5:
Update concerning the parameter edchMaxNumberUserNodeB.

02/09/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 4:
Notes added to the parameters totalRotMax and referenceRTWP
concerning the utilisation of two distinguish classes.
Update of the parameter referenceRtwp

25/08/2009
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 2/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
Issue 03.10 / EN, Standard
Updates:
In Volume 4:
Deletion of the remarks, including comments related to the xCEM resets and
cell lock-unlock, for the parameters eagchPowerControlModeXcem,
ehichErrorProbability, minPowerCorrection, maxPowerCorrection,
pMinDlEDCH and pMaxDlEDCH

26/06/2009
Issue 03.09 / EN, Standard
Updates:
In Volume 1:
Clarification of the meaning of Class 3 parameters and also other class
general updates.
In Volume 3:
Wrong parameter name: hsdpaGbrNbUeTtiForgettingFactor replaced by
hsdpaGbrNbUePerTtiForgettingFactor
Clarification of the support of E-RGCH by iCem
Clarification of the recommendation for hsdpaFullPowerUsage
Clarification of the formula used to compute the power reservation from
DlTxPowerEstimation
Clarification of the case Mobility over Iur for the feature Dynamic mac-d pdu
size mgt
Clarification
concerning
HsdpaGbrIncreaseFactorForMobility

the

parameter

Description of the feature IU USER TRAFFIC CONFORMANCE added


(coming from Vol.7 Iub resource management)
Restriction added for the parameter maxHspaPowerOffset.
In Volume 4:
Clarification regarding edchTfciTableIndex : Table 0 (2msTtiTable0 and
10msTtiTable0) must not be used
Update of the recommended value for reserved0 : bit 24 and bit 25 are used
to select UL ILPC Algo2 for UE Category 4 TTI 2ms and UE Category 6 TTI
2ms.
Update of the recommended value for plNonMax, {Ref E-TFCI; Ref PO},
and maxSirTarget for Ue Category6 TTI 2ms with SRB on EDCH.
Clarification regarding the parameters edchMacdPowerOffsetEdchTti10
and edchMacdPowerOffsetEdchTti2

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 3/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
Clarification
regarding
the
isEdchFpBundlingModeForEdchTti2msAllowed
isEdchFpCrcPayloadPresence

parameters
and

Introduction de la feature: 81112 UL load estimation in presence of urban


noise (Vol4, section 4.1.3)
Update RSEPS (Vol4, section 4.1.2)
Update pour la UE category Cat4 to Cat6 (Vol4, section 5.2)
Update pour la partie: MACE scheduler inputs (Vol4, section 7.1)
Update pour la partie Scheduling Grant (Vol4, section 7.2)
Update pour la IBTS Local Congestion Control feature (Vol4, section 7.8.4)
Update pour le SRB on HSPA during Call vs HSUPA over Iur (Vol4, section
9)
New recommendation for nFramesBeforeEdchDeCongestion
In Volume 5:
Feature 84900 has been added
Clarification of GBR algorithms
Clarification of the recommendation for deltaCfnForEdchXXX
Clarification of the impact of the flag enhancedQualityOfService on
minBrForHsdpa usage
New recommendation for ovsfCodesThroughput16QamUe
Clarification of the RNC CAC on codes
Section 6.1.3 deleted because no more applicable in UA6
Clarification of the values for reservationFactorOnCodesForGbrTraffic and
initialActivityFactorForIb
Parameter timerT2ForMultiRabHsdpa (not used in UA6) replaced by
timerT2ForHsdpa
In Volume 6:
Clarification regarding Event 1J : an event 1J for Primary Cell replacement is
ignored by the RNC
In Volume 7:
Volume 7 has been deleted (see section 1.2)
In Volume 8 (new name: Volume 7 since Volume 7 has been deleted):
Mention PA power pooling restriction for STSR2 * 6 sectors configurations.

06/03/2009
Issue 03.08 / EN, Preliminary
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 4/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
Updates:
In Volume 3:
Clarification of the Dyn Bler Target algo
Clarification of the QoS management (section 4.3 SPI management
renamed QoS management) and Crmax behavior
Section related to the 656 PDU QUALCOMM UE BUG WORKAROUND
added
In Volume 4:
Update regarding the Iub congestion handling for edch in Vol.4; 6.8 & 7.8
Update regarding the priority info in mac-e scheduler in Vol.4; 6.7 & 7.6
Update regarding the ue categories in Vol.4; 5.2 and Vol.2; 4.2
Update regarding the ibts local congestion control in Vol.4; 7.8.4
Update regarding rseps measurements in Vol.4; 4.1.2
Update regarding the location of totalRotMax
Update of "xCEM/10ms TTI" and "xCEM/2ms/2xSF2 TTI" {Ref E-TFCI; Ref
PO} tables (Vol.4, 5.4), plNonMax recommended value for 2ms E-DCH TTI
(Vol.4, 5.5)
Update of happyBitDelayEdchTti2ms, periodicityOfSchedInfoXxx,
edchInitialTBIndex10msTTI, and 2ms edchMinSetEtfci recommended
values (Vol.4, 7.2, 7.4)
Update on 2ms E-DCH TTI activation method (Vol.4, 5.1)
Addition of recommended settings for 2ms TTI with SRB on E-DCH, incl.
addition of "xCEM/2ms TTI/2xSF2+2xSF4" {Ref E-TFCI; Ref PO} table (Vol.4,
5.4, 5.5, 8.1.2.3)
Updates on UA6 34249 "Optimized HARQ" feature (Vol.4, 8.1.2):
Behavior for E-DCH handled on iCEM, behavior for SRB on E-DCH case,
update of recommended settings
Updates on power control of E-DCH DL channels (Vol.4,
Correction of parameter definitions, update of recommended settings

8.2):

Updates on maxNrOfErgchEhich: Parameter definition, recommended


value for xCEM, configuration restrictions (Vol.4, 4.2.2.2)
Addition of recommended value for prohibitedStatusTimer in UL (Vol.4, 5.2)
In Volume 5:
Update
of
deltaCfnForEdchAndHsdpaMobility
and
deltaCfnForEdchAndHsdpaChannelTypeSwitching recommended value
(Vol.5, 5.1.2)
Update of the HSDPACombinationList table
activateOls added
Parameter name corrected (isDlPowerSelfTuningForPsIbOnHsdpaEnabled)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 5/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
Clarification of the rule of the parameter isGbrOnHsdpaAllowed
Clarification of the Fair Sharing/GBR features
In Volume 7:
Engineering recommendation concerning the maximumBucketSize is deleted
since this parameter is no more used in UA6.0
In Volume 8:
Volume 8 has been deleted (see section 1.2)
In Volume 9:
Volume 9 has been deleted (see section 1.2)
In Volume 10 (new name: Volume 8 since Volume 8 and 9 have been deleted):
Updates on UA6 29808 "PA Pooling" feature (Vol.10, 6.1.2.4): Change in "PA
overbooking ratio" definition

28/10/2008
Issue 03.07 / EN, Preliminary
Updates:
In Volume 2 and 3:
Granularity Change: Because of the 33621 HSPA Configuration at site
Granularity feature, its now possible to have until 15 different instances.
Different values can also be defined per FDDCell for the parameters under the
HsdpaUserService (this is possible using HsdpaUserServiceId under
HsdpaResource)
In Volume 3 :
Clarifications on Management of UL power profiles... sub-feature of UA6
34246: Sub-feature applies to both Global Market and USA market, and
includes all the functionalities of UA5.1.2 34652 (Vol.3, 8.5)
hsdschPowReportingPeriod replaced by hsdschReqPwReportingPeriod
New
recommendation
for
hsdpaBlerTargetLowerLimit,
hsdpaBlerTargetMediumLimit, hsdpaAdjustBlerToChannelVariation
Clarification of the recommendation for hsscchSnr
Modification of the recommendation for servicehighrate in case of PS
Streaming
Rule added related to ue capability and 656 bits feature
spi parameter added
Rule added related to DCTM and Fair Sharing activation
Correction of the numerical example given in the engg recommendation
related to spreadingFactorLevelForOvsfMonitoring
Clarification of the engg recommendation concerning the 656 bits activation
according to the ue categories (eligibleUeCategoryForHighPerformance)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 6/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
In Volume 4:
Correction on parameter name: Correction of parameter name: from
edchDeSequencingWaitTimerIP to DeSequencingWaitTimer (RAN Model
designation)
Update of "xCEM/10ms TTI" {Ref E-TFCI; Ref PO} table, addition of "UCUIII" {Ref E-TFCI; Ref PO} table (Vol.4, 5.4)
Update of nHarqRetransTargetSx parameters for 10ms E-DCH TTI (Vol.4,
8.1.2.3.4)
Mention of hard-coded offset on top of E-DCH maxSirTarget for 2ms E-DCH
TTI (Vol.4, 8.1.2.3.4)
edchSpi parameter added
In Volume 5:
Modification
of
the
recommendation
transportTypeSelectionTransferDelayThreshold

for

Clarification concerning HSxPA-to-DCH fallback when Fair Sharing is


enabled
Update of the HSDPACombinationList
Update of Fair Sharing description
In Volume 9:
General updates

29/08/2008
Issue 03.06 / EN, Preliminary
Updates:
General update of section on management of UL power profile for HSDPA calls, with
description of UA6 "Management of UL power profiles... sub-feature of UA6 34246
(Vol.3, 8.5)
General update of section on E-DCH UL OLPC (presentation, corrections), with
addition of iCEM and OneBTS specific parameter settings (Vol.4, 8.1)
General update of section on E-DCH Mobility (presentation, corrections), with
addition of information related to OneBTS (Vol.6, 3.3)
Update of section on setting of number of E-AGCH and E-RGCH/E-HICH channels
per cells (4.2.2.2): Changes in recommended values, mention of UA6 34175 "UA06
xCEM HSPA Capacity Evolution" feature, addition of warnings on operational impact
of wrong settings.
Clarifications regarding iBTS NodeB internal power checks (Vol.3, 8.4)
For some parameters (mostly related to E-DCH DL ch. power control), addition of
required operation at OAM (e.g. NodeB reboot) to take into account a parameter
setting change.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 7/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
Update of Abbreviations section (Vol.1, 3.1)
Miscellaneous
updates
(totalRotMax,
edchHarqMaxRetransEdchTtixx, harqType...)

edchInitialTBIndex,

plNonMax,

In Vol.3:
Forgetting factor formula for xCem (used to average the throughput of each
mac-d flow) corrected
Clarification concerning schedulingPriorityLevel in UA5.1 and UA6.0
serviceHighRate: value updated and engg recommendation addedhsdschReqPwReportingPeriod and hsdschReqPwFilterCoeff added
Minimum value for HS-SCCH power added
Clarification of the term factor used to compute the HS-DSCH power by
xCem
Updates of the computation of the number of HS-PDSCH codes used by
xCem
hsScchSnr value updated
hsdpaBlerTargetUpperLimitXcem value updated
Spectral Efficiency computation updated
Excess power algorithm updated
Restriction
concerning
the
algorithm
dynamicHarqTxTarget
hsdpaCqiBlerAdjustmentAlgorithmXcem) added

(parameter

In Vol4:
Update and addition of new UA6 parameters
Description of Mac-e non scheduled mode sub-feature
Description of RSEPS NBAP measurements
In Vol.5:
maximumNumberOfUsers : class 3, not class 0 and update of the definition.
Recommendation for minBrForHsdpa added
Recommendation for minHsDschReservationForCac added
Recommendation for dlTxPowerEstimation added
In Vol6 :
Description of HSUPA over Iur feature

27/06/2008
Issue 03.05 / EN, Preliminary
Updates
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 8/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
20/06/2008
Issue 03.04 / EN, Draft
Updates

06/06/2008
Issue 03.03 / EN, Draft
Updates

23/May/2008
Issue 03.02 / EN, Draft
Updates

28/March/2008
Issue 03.01 / EN, Draft
Document Creation

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 9/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

FIGURES
Figure 1: Static and Configuration Parameters

16

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 10/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

1 INTRODUCTION
1.1 OBJECT
The HSxPA Parameters User Guide (HPUG) document provides parameters setting
recommendations from Alcatel-Lucents experience, coming from studies, simulations
and experimentations. It gives the rationales of these settings by describing the
HSDPA & E-DCH (HSUPA) system from an engineering point of view. It also gives
some engineering rules related to parameters settings. This includes a system
description, configuration aspect and engineering recommendations.
The HPUG does not contain the complete list of configuration parameters, this
objective being covered in [R01].
The parameters described in this document are mainly customer configuration
parameters accessible by the customer (operator) via the MMI of the OMC.
Nevertheless, some manufacturer configuration parameters as well as some static
parameters are also covered when they are required to understand the different
UMTS mechanisms.
In the case where the recommended values of the HPUG are different from any other
document, the HPUG recommended should prevail.
The parameter values in HPUG are the recommended values by Alcatel-Lucent, which
means that they are the best values to achieve the optimal network performance.
A common and single UA06 load is delivered to address the needs of all AlcatelLucent WCDMA customers, which are grouped into two different markets due to their
particular functional specificities:
USA Market, i.e. customers with UTRAN where Alcatel-Lucent 939X Node B
(former Lucent OneBTS) is deployed
Global Market, i.e. any other customers
This document provides a description of the features included in the UA06 release. At
the beginning of each volume, a table has been added to clearly indicate to which
market, among the two listed previously, each feature is applicable to. Note that one
feature can belong to one or two markets but:
A feature which is not applicable to USA Market is not supported on a
UTRAN with Alcatel-Lucent 939X Node B (former Lucent OneBTS).
For features common to USA market and Global markets, the behaviour on
UTRAN with 939X Node B might be different from other Alcatel-Lucent Node
B products, in which case the differences are described in the Hardware
Dependencies section.
Features are by default not supported on 9313 Micro Node B nor 9314 Pico Node B.
For the list of features supported on these products please refer to 33341 AlcatelLucent 9313 Micro Node B and 33342 Alcatel-Lucent 9314 Pico Node B
descriptions.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 11/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

1.2 SCOPE OF THIS DOCUMENT


Features behavior or features can be specific to one board or common for several
boards. In the next volumes, the following rule is applied to define the feature
applicability:

Tag [iCEM] indicates that the behavior or the feature is specific to iCEM.

Tag [xCEM] indicates that the behavior or the feature is specific to xCEM only
or to xCEM and UCU-III if there is no [UCU-III] tag.

Tag [UCU-III] indicates that the behavior or the feature is specific to [UCU-III].

No tag indicates that the behavior or the feature is common for all the boads.

R99 related features and settings are not part of this document. Please refer to
[R01]a.[R02].

The following volumes have been deleted from the UA6.0 HPUG and replaced by a
specific document:
-

Volume 7: Iub Resource Management refer to [R01]a.[R03]

Volume 8: Capacity refer to [R01]a.[R04]

Volume 9: Product recommendations refer to [R01]a.[R05]

The HSxPA Parameters User Guide is not supposed to present the whole Plan of
record. For accurate Plan of record and feature delivery information please refer to
your account and PLM prime.

Refer also to [R01]a.[R06][R01]a.[R06] for more information on features available for


UA5.x.

Restriction: Pico/Micro NodeB


The Pico/Micro NodeB product is out of scope of this document, thus all engg information, algorithms
description and parameters values provided in this document are strictly related to standard AlcatelLucent NodeB products.
See [R01]a.[R07] for details related to HSxPA implementation in Pico & Micro NodeB.

1.3 AUDIENCE FOR THIS DOCUMENT


This document targets an audience involved in the following activities:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 12/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

RF engineering

UTRAN Datafill

Trials and VO

1.4 NOMENCLATURE

The parameter names are written in bold italic.

The objects names are written in bold.

The parameters properties are presented as follow:

Parameter
Range & Unit
User
Class
Value

Object
Granularity

The protocol messages are written in CAPITAL LETTERS.

The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.

The datafill rules are presented as the following:

The system restrictions are presented as the following:

The engineering recommendations on parameter value are presented as the


following:

Rule:

Restriction:

Engineering Recommendation:

The difference between Release N and Release N-1 are presented as the
following:

UAN-1-UAN Delta:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 13/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o

N.A.: Not Applicable.

N.S.: Not Significant.

O.D.: Operator Dependant (depends on operator network specific


configuration. Example: addressing parameters).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 14/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
1.5 RELATED DOCUMENTS
Reference documents:
[R01] NTP 411-8111-813

Access Network Parameters

[R02] UMT/DCL/DD/0020

UTRAN Parameters User Guide

[R03] UMT/IRC/APP/0164

Iub transport Engineering Guide

[R04] UMT/IRC/APP/025147

CEM Capacity Engineering guide

[R05] UMT/IRC/APP/007147

Product Engineering Information

[R06] UMT/SYS/INF/016608

UA05 Feature Planning Guide

[R07] UMT/BTS/INF/016135

Micro NodeB & 9314 Pico NodeB Feature


Planning Guide

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 15/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

2 PARAMETERS ORGANIZATION
In order to understand the definition and the role of the different parameters, it is
appropriate to explain how these parameters are linked together and grouped within
the RAN model.

For more information on the RAN model, please refer to [R01].

RNC

OMC

WPS

Static
WPS Templates
Customer
Non-Static
Manufacturer
CIQ

OMC
database

System DRF

Figure 1: Static and Configuration Parameters

There are two main kinds of parameters in Alcatel-Lucents system, the static and
configuration parameters.

The static parameters have the following characteristics:

They have a fixed value and cannot be modified at the OMC.

They are part of the network element load.

A new network element needs to be reloaded and built in order to change their values.

The customer cannot modify them.

The configuration parameters have the following characteristics:

They are contained in the OMC database.

They are subdivided in two main types: User / Manufacturer.


o

Customer: Can be modified by the customer at the OMC (at the MMI or with
DRFs).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 16/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
o

Manufacturer: They represent system constants defined by the manufacturer.


They do not appear at the MMI neither in the DRFs.

Regardless of the parameter type (customer or manufacturer), the parameters can have
the following classes:
o

Class 0: the value of the parameter is set at the parent object creation.
Currently, most of the objects can only be killed and re-created through a new
MIB built (either btsEquipmentMIB or rncMIB).

Class 1: new parameter value is taken into account on the next RNC restart.
This class is no longer valid.

Class 2: parameters of an object created at the OMC-R (respectively OMC-B)


can only be set when the object and its parent are both locked. The new value
will be taken into account after the object is back to working state
(administrative state set to unlocked).

Class 3: parameters of an object created on the OMCR (respectively OMC-B)


can be modified when the object (and parent object) is unlocked. The new
value is taken into account immediately.

Class 3-A1: new value is immediately taken into account.

Class 3-A2: new value is taken into account upon event reception
(service establishement, SRLR).

Class 3-B: new value is taken into account for next call.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 17/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

3 ABBREVIATIONS AND DEFINITIONS


3.1 ABBREVIATIONS
ACK

Acknowledgment

AICH

Acquisition Indicator Channel

AM

Acknowledged Mode

AMC

Adaptive Modulation and Coding

ARP

Allocation Retention Priority

ARQ

Automatic Repeat Request

ATM

Asynchronous Transfer Mode

AS

Active Set

BBU

Base-Band Unit

BLER

Block Error Rate

CAC

Call Admission Control

CC

Chase Combining

CCPCH

Common Control Physical Channel

CEM

Channel Element Module

CFN

Connection Frame Number

CM

Compressed Mode

CN

Core Network

CP

Passport: Control Processor

CPICH

Common Pilot Channel

CRC

Cyclic Redundancy Check

CS

Circuit Switched

DCH

Dedicated Channel

DDM

Dual Duplexer Module

DL

Downlink

DPCCH

Dedicated Physical Control Channel

DPDCH

Dedicated Physical Data Channel

DS

Delay Sensitive

DS1

Digital Signal level 1 (1.544 Mbit/s)

DTX

Discontinuous Transmission

E-AGCH

Enhanced Access Grant Channel

E-DCH

Enhanced DCH (also referred as HSUPA or EUL)

E-DPCCH

Enhanced Dedicated Physical Control Channel

E-DPDCH

Enhanced Dedicated Physical Data Channel

E-HICH

Enhanced Hybrid ARQ Indicator Channel

E-RGCH

Enhanced Relative Grant Channel

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 18/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
E-TFC

E-DCH Transport Format Combination

E-TFCI

E-DCH Transport Format Combination Indicator

EUL

Enhanced Uplink (stands for E-DCH)

FP

3GPP: Frame Protocol


Alcatel-Lucent Passport: Function Processor

FRS

Feature Requirements Specification

GMM

GPRS Mobility Management

H-ARQ

Hybrid ARQ

HCS

Hierarchical Cell Structure

HS-DSCH

High Speed Downlink Shared Channel

HS-SCCH

Shared Control Channel for HS-DSCH

HSDPA

High-Speed Downlink Packet Access

HSUPA

High-Speed Uplink Packet Access

HHO

Hard Handover

HO

Handover

IE

Information Element

iMCTA

intelligent Multiple Carrier Traffic Allocation

iRM

intelligent RAB mapping

IMEI

International Mobile Equipment Identification

IMSI

International Mobile Subscriber Identification

IP

Internet Protocol

IR

Incremental Redundancy

KPI

Key Performance Indicator

LA

Location Area

LAC

Location Area Code

LCG

Local Cell Group

MAC

Medium Access Control

MCPA

Multi-Carrier Power Amplifier (also referred as PA)

MIB

3GPP: Master Information Block;


Alcatel-Lucent RNC/NodeB: Management Information Base

MMI

Man-Machine Interface

MO

Mobile Originated

MT

Mobile Terminated

NACK

Negative Acknowledgement

NAS

Non Access Stratum

NBAP

NodeB Application Part

NDS

Non-Delay Sensitive

OAM

Operations, Administration and Maintenance

OLPC

Outer-Loop Power Control

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 19/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
OLS

Olympic Level Service

OMC

Operations and Maintenance Center

OMC-B

OMC NodeB

OMC-R

OMC RNC

OVSF

Orthogonal Variable Spreading Factor

PA

Power Amplifier (stands for MCPA)

P-CCPCH

Primary CCPCH

PCPCH

Physical Common Packet Channel

P-CPICH

Primary CPICH

PCR

Peak Cell Rate

PDU

Protocol Data Unit

PICH

Paging Indicator Channel

PLMN

Public Land Mobile Network

PRACH

Physical Random Access Channel

PS

Packet Switched

P-SCH

Primary SCH

PSCR

Physical Shared Channel Reconfiguration

QAM

Quadrature Amplitude Modulation

QoS

Quality of Service

QPSK

Quadrature Phase Shift Keying

RA

Registration Area

RAB

Radio Access Bearer

RACH

Random Access Channel

RAN

Radio Access Network

RANAP

Radio Access Network Application Part

RAT

Radio Access Technology

RB

Radio Bearer

RL

Radio Link

RLS

Radio Link Set

RLC

Radio Link Control

RMS

Root Mean Square

RNC

Radio Network Controller

RNC-AN

RNC Access Node

RNC-CN

RNC Control Node

RNC-IN

RNC Interface Node

RNS

Radio Network Subsystem (an RNC and its associated NodeBs)

RoT

Rise over Thermal

RRC

Radio Resource Control

RRM

Radio Resource Management

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 20/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
RSCP

Received Signal Code Power

RSN

Retransmission Sequence Number

RSSI

Received Signal Strength Indicator

RTWP

Received Total Wideband Power

SCCP

Signaling Connection Control Part

S-CCPCH

Secondary CCPCH

SCH

Synchronization Channel

S-CPICH

Secondary CPICH

SCR

Sustainable Cell Rate

SDU

Service Data Unit

SF

Spreading Factor

SFN

System Frame Number

SHO

Soft Handover

SI

Scheduling Information

SIB

System Information Block

SM

Session Management

SRB

Signaling Radio Bearer

SRLR

Synchronous Radio Link Reconfiguration

SS7

Signaling System 7

S-SCH

Secondary SCH

STM1

Synchronous Transport Module-1 (155.52 Mbit/s)

TFC

Transport Format Combination

TFCI

Transport Format Combination Indicator

TFCS

Transport Format Combination Set

THP

Traffic Handling Priority

TM

Transparent Mode

TNL

Transport Network Layer

TRB

Traffic Radio Bearer

TrCH

Transport Channel

TRM

Transceiver Module

TS

Technical Specification

TTI

Transmission Time Interval

UBR

Unspecified Bit Rate

UE

User Equipment

UL

Uplink

UM

Unacknowledged Mode

URA

UTRAN Registration Area

UTRAN

Universal Terrestrial Radio Access Network

VCC

Virtual Channel Connection

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 21/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
VP

Virtual Path

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 22/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction
3.2 DEFINITIONS

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 23/24

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 1 : Introduction

Z END OF DOCUMENT Y

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 24/24

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

HSXPA PARAMETERS USER GUIDE

HSXPA OVERVIEW

Alcatel-Lucent Proprietary

V03.10
02/OCT/2009

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

CONTENTS
1

INTRODUCTION............................................................................................................................4
1.1

OBJECT ....................................................................................................................................4

1.2

SCOPE OF THIS DOCUMENT .......................................................................................................4

RELATED DOCUMENTS ..............................................................................................................5


2.1

HPUG VOLUMES ......................................................................................................................5

2.2

REFERENCE DOCUMENTS ..........................................................................................................5

SYSTEM OVERVIEW ....................................................................................................................6


3.1

HSDPA ...................................................................................................................................9

3.1.1
Transport and physical channels ....................................................................................9
3.1.1.1
Downlink channels.................................................................................................... 12
3.1.1.2
Uplink channels ........................................................................................................ 13
3.1.2
Fast link adaptation .......................................................................................................15
3.1.3
Fast Retransmission Mechanism (HARQ) ....................................................................16
3.1.3.1
Number of HARQ Processes.................................................................................... 16
3.1.3.2
RV Parameters ......................................................................................................... 17
3.1.3.3
State of HARQ Processes ........................................................................................ 19
3.1.3.4
Choice of the HARQ type ......................................................................................... 21
3.1.4
Fast scheduling .............................................................................................................25
3.2
HSUPA (E-DCH)...................................................................................................................26
3.2.1
Transport and physical channels ..................................................................................26
3.2.1.1
Uplink channels ........................................................................................................ 28
3.2.1.2
Downlink channels.................................................................................................... 31
3.2.2
UA5 implementation of E-DCH .....................................................................................34
4

UE CATEGORIES........................................................................................................................35
4.1

HSDPA .................................................................................................................................35

4.2

HSUPA .................................................................................................................................36

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 1/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

TABLES
Table 1: HSUPA / HSDPA comparison
Table 2: Number of processes per UE category for iCEM
Table 3: RV coding for 16QAM
Table 4: RV coding for QPSK
Table 5: RV update table in the MIR case (Trv[i])
Table 6: RV update table in the PIR case (Trv[i])
Table 7: RV updates tables when harqType set to Dynamic Redundancy
Table 8: Number of processes per UE category for xCEM/UCU-III
Table 9: RV update table in the IR case (Trv[i])
Table 10: RV update table in the CC case (Trv[i])
Table 11: E-DPDCH slot formats
Table 12: E-DPCCH slot formats
Table 13: E-DPCCH power offset index vs. amplitude
Table 14: Relative grant information (E-RGCH)
Table 15: ACK/NACK information (E-HICH)
Table 16: HSDPA UE categories (3GPP TS25.306)
Table 17: HSUPA UE categories (3GPP TS25.306)

8
16
18
18
21
21
22
24
24
24
29
29
31
32
33
35
36

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 2/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

FIGURES
Figure 1: R99 principle ........................................................................................................................................ 6
Figure 2: HSDPA principle .................................................................................................................................. 6
Figure 3: HSDPA layer2/layer1 flows ................................................................................................................ 7
Figure 4: MAC-hs entity on UTRAN side .......................................................................................................... 7
Figure 5: Protocol Architecture of E-DCH......................................................................................................... 9
Figure 6: UE side MAC architecture .................................................................................................................. 9
Figure 7: Transport channel configuration...................................................................................................... 10
Figure 8: HSDPA channels and associated R99 channels.......................................................................... 11
Figure 9: Timing relationship at NodeB between physical channels .......................................................... 12
Figure 10: HS-SCCH structure......................................................................................................................... 13
Figure 11: HS-PDSCH structure ...................................................................................................................... 13
Figure 12: HS-DPCCH structure...................................................................................................................... 14
Figure 13: Example of AMC: Throughput versus Ior/Ioc (radio condition)................................................. 16
Figure 14: RV parameters assignment algorithm .......................................................................................... 19
Figure 15: ACK/NACK/DTX management for HARQ processes ................................................................ 20
Figure 16: Dynamic selection of HARQ type.................................................................................................. 23
Figure 17: HSUPA channels and associated R99 channels........................................................................ 27
Figure 18: E-DPCCH / E-DPDCH frame structure ........................................................................................ 29
Figure 19: E-DPDCH/E-DPCCH multiplexing on I/Q .................................................................................... 30
Figure 20: Uplink physical channels multiplexing.......................................................................................... 30
Figure 21: E-AGCH frame structure ................................................................................................................ 31
Figure 22: E-HICH frame structure .................................................................................................................. 33

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 3/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.

description,

configuration

aspect

and

engineering

1.2 SCOPE OF THIS DOCUMENT


This document gives an overview of the HSxPA.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 4/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios

2.2 REFERENCE DOCUMENTS


[R01] 3GPP TS 25.308
UTRA High Speed Downlink Packet Access
(HSPDA); Overall description; Stage 2
[R02] 3GPP TS 34.108
Common Test Environments for User Equipment
(UE) Conformance Testing
[R03] 3GPP TS 25.212

Multiplexing and channel coding (Release6)

[R04] 3GPP TS 25.214

Physical layer procedures (FDD)

[R05] 3GPP TS 25.306

UE Radio Access capabilities definition

[R06] 3GPP TS 25.213

Spreading and modulation (FDD)

[R07] UMT/BTS/INF/016135
Planning Guide

Micro NodeB & 9314 Pico NodeB Feature

[R08] UMT/IRC/APP/007147

UMTS BTS Product Engineering Information

[R09] UMT/IRC/APP/014654

HSxPA Engineering User Guide UA5.x

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 5/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

3 SYSTEM OVERVIEW
HSDPA
3GPP has standardized HSDPA in Release 5 [R01] in order to increase maximum
user throughput for downlink packet data (streaming, interactive and background
traffic classes) and decrease downlink packet transmission delay. This Release 5 is
fully compatible with the previous Release 99 (R99).

In R99, data are transmitted on a dedicated channel with a given user throughput and
a downlink transmitted power controlled according to the radio conditions:

Same Throughput

Unused

Power
Control

Unused Power

Data

Data Power

Figure 1: R99 principle

In HSDPA, data are transmitted on a shared channel by using all the available power
and by controlling the downlink user throughput according to the radio conditions:

100%

Rate
Adaptation

100% Power

Figure 2: HSDPA principle

Typically, a user in good radio conditions will receive his data with a high bit rate
whereas a user in bad radio conditions will receive his data with a lower bit rate.

The efficiency of this rate adaptation is due to a new MAC entity, the MAC-hs layer,
located in the NodeB (see the two following figures), near the physical channel, which
allows a high reactivity in the resource allocation according to the RF conditions
changes. This MAC-hs layer manages the scheduling of users and the
retransmissions of packets.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 6/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


RRC
RRC(RNC)
(RNC)
RLC
RLC(RNC)
(RNC)
PCCH BCCH CCCH CTCH

MAC Control

MAC Control

MAC Control

MAC-hs
MAC-hs
(NodeB)
(NodeB)

DCCH DTCH

DTCH

MAC-d
(S-RNC)
MAC-c/sh
MAC-c/sh
(C-RNC)
(C-RNC)

Associated
Downlink
Signaling

HS-DSCH

Associated
Uplink
Signaling

PCH

R5
R5L1:
L1:HSDPA
HSDPA(NodeB)
(NodeB)
HS-SCCH

HS-PDSCH

HS-DPCCH

FACH

RACH

CPCH

DSCH

DCH

DCH

R99
R99L1:
L1:Channel
ChannelCoding
Coding/ /Multiplexing
Multiplexing(NodeB)
(NodeB)
S-CCPCH

S-CCPCH

PRACH

PCPCH

PDSCH

DPCH

DPDCH/DPCCH

Figure 3: HSDPA layer2/layer1 flows

Figure 4: MAC-hs entity on UTRAN side

HSDPA benefits are based on:

New transport and physical channels.

Fast link adaptation.

Fast retransmission mechanism (HARQ).

Fast scheduling.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 7/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


HSUPA

3GPP has standardized HSUPA (official name is E-DCH) in release 6 in order to


increase maximum user coverage and throughput for uplink packet data and decrease
uplink packet transmission delay. This Release 6 is fully compatible with the previous
Releases (R99 and R5).
HSUPA uses the same new techniques of HSDPA:

HSDPA

HSUPA

Fast scheduling

Fast retransmission mechanism (HARQ)

Macrodiv

TTI

Modulation

Channel
coding

Power
control

HARQ

Fast
scheduling

Fast link
adaptation

Not
supported

2 ms
only

QPSK and
16QAM

Turbo

No

Supported

Supported

Supported

Supported

2 ms,
10 ms

BPSK and
QPSK

Supported

Supported
but less
reactive

Supported
but less
reactive

Turbo

Yes

Table 1: HSUPA / HSDPA comparison

The physical layer is similar to R99:

BPSK modulation only, QPSK is used when there is more than one E-DPDCH
physical channel (SF4).

Turbo coding

Spreading on a separate OVSF code and scrambling together with other


physical channels.

HSUPA is power controlled as for R99. Indeed, HSUPA channels have a


power offset relative to DPCCH.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 8/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

DTCH DCCH

DCCH DTCH

MAC-d

MAC-d

MAC-es

MAC-es /
MAC-e
MAC-e

MAC-e EDCH FP

PHY

UE

PHY

Uu

EDCH FP

TNL

TNL

NodeB

Iub

TNL

TNL

DRNC

Iur

SRNC

Figure 5: Protocol Architecture of E-DCH

PCCH BCC H CC CH C TCH SHC CH


( T D D only )

M A C C o ntro l D C C H

DTCH

D TC H

M A C -d

M A C -es /
M A C -e

E -D C H
A sso c ia te d
D o w nlink
S igna lling

A sso cia te d
U p link
S igna lling

M A C -c/sh

M A C -h s

H S -D S C H
A sso cia te d
A sso cia te d
D o w nlink
U p link
S igna lling
S igna lling

PC H

FA C H

FA C H R A C H

CPCH U SCH U SCH D SC H D SC H

DCH

( F D D only ) ( T D D only ) ( T D D only )

Figure 6: UE side MAC architecture

3.1 HSDPA
3.1.1 TRANSPORT AND PHYSICAL CHANNELS
In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on
the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are sent
on a HS-DSCH (High Speed Downlink Shared CHannel) which is mapped on one or
several HS-PDSCH (High Speed Physical Downlink Shared CHannel). Users are
multiplexed on the HS-DSCH channel in time and code. Transmission is based on
shorter sub-frames of 2ms (TTI) instead of 10ms in R99.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 9/38

DCH

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


In downlink, the HS-PDSCH are transmitted with the HS-SCCH (High Speed Shared
Control CHannel) channel. This channel is broadcasted over the cell but his
information concerned only the user who has to receive the HS-PDSCH. The HSSCCH allows the user to know if the HS-PDSCH is for him and to decode them
correctly.

Radio conditions information and acknowledgement are reported by the UE to the


NodeB through the HS-DPCCH channel. This channel allows the NodeB to adapt the
downlink data rate and to manage retransmission process. The HS-DPCCH is divided
in two parts. The first one is the Channel Quality Indicator (CQI) which is a value
between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30
= good radio conditions). The second one is the acknowledgement information: if data
are well received by the UE, the UE sends to the NodeB an Ack, otherwise a Nack.

HS-DSCH channel is always associated to a DCH. This induces the following


transport channel configuration for any UE established in HSDPA (see the following
figure):

One DCH handling the signaling in both UL and DL,

One DCH transporting the UL traffic,

One HS-DSCH for the DL traffic.

Figure 7: Transport channel configuration

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 10/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


The following figure summarizes the different channels needed for a HSDPA call:

HS-PDSCH for data (I/B) traffic


HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-DPCCH Feedback information

HSDPA channels

NodeB

HSDPA UE

Associated DPCH for data, speech + SRB traffic

Figure 8: HSDPA channels and associated R99 channels

The maximum bit rate that can be achieved in the UL can be the bottleneck for the
maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP
acknowledgements due to low bandwidth in the UL will limit the DL throughput, even if
the RF conditions would allow more.

From UA04.2, the RB adaptation feature is supported. This feature dynamically adapts
the UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from
8kbps up to 384kbps, but 8kbps is not recommended to be activated (configured as
eligible). Therefore, although UL:8 DL:[max bit rate for UE categories 12 and 6] will be
allocated by the RNC if UL:8 is explicitly requested in the RAB assignment, it is not
recommended to do so, otherwise the user will experience low throughput in the DL.

The following flowchart describes the timing relations between the different physical
channels:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 11/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


2 ms
HS-SCCH#1

HS-SCCH#2
2 slots

HS-PDSCH

N_acknack_transmit = 2
HS-DPCCH

ACK

ACK

ACK

7,5 slots

Figure 9: Timing relationship at NodeB between physical channels

3.1.1.1 DOWNLINK CHANNELS


The mobile receives a HS-SCCH subframe (see the following figure) containing
control information among which:

Channelization-code-set information (7 bits slot #0 of subframe)

Modulation scheme information (1 bit slot #0 of subframe), i.e.


QPSK/16QAM

Transport-block size information (6 bits slots #1 & #2 of subframe)

Hybrid-ARQ process information (3 bits slots #1 & #2 of subframe)

Redundancy and constellation version (3 bit slots #1 & #2 of subframe)

New data indicator (1 bit slots #1 & #2 of subframe)

UE identity (16 bits used as a mask in slots #0, #1 & #2 of subframe), i.e.
subset of the HRNTI

The SF is fixed to 128. It indicates to which UE data is intended to, on which codes
and with which parameters. There are as many HS-SCCH transmitted during a TTI as
scheduled user number.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 12/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


Tslot = 2560 chips = 40 bits

Data

Slot #0

Slot #2

Slot #1
1 HS-SCCH subframe = 2ms
Figure 10: HS-SCCH structure

A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been
assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this
slot #0, other information are given in slots #1 and 2): the mobile receives a transport
block on one or several HS-PDSCH (see the following figure).

Tslot = 2560 chips = M*10*2k bits (k = 4, SF16)

Data

Slot #0

Slot #1

Slot #2

M= 2 for QPSK
(960 coded bits per TTI)
M = 4 for 16QAM
(1920 coded bits per TTI)

1 HS-PDSCH subframe = 2ms

Figure 11: HS-PDSCH structure

The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload. The
SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One
HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of
codes is given by UE capabilities).

3.1.1.2 UPLINK CHANNELS


When addressed on HS-SCCH, the UE will then send feedback frame(s) on HSDPCCH (SF = 256), roughly 7.5slots after HS-PDSCH frame, containing (see the
following figure):

The HARQ Ack/Nack;

The CQI (Channel Quality Indication).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 13/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


2.Tslot = 5120 chips
= 20 bits

Tslot = 2560 chips


= 10 bits

ACK/NACK

CQI

Subframe #0

Subframe #4

Subframe #i
1 radio frame = 10ms
Figure 12: HS-DPCCH structure

The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the
N_acknack_transmit parameter, as specified in [R04] 6A.1.1.

Parameter
Range & Unit
User
Class
Value

ackNackRepetitionFactor
[1..4]
Customer
3
1

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

UA5.x-UA6.0 Delta: Granularity Change


Because of the 33621 HSPA Configuration at site Granularity feature, its now possible to have until 15
different instances. Different values can also be defined per FDDCell for the parameters under the
HsdpaUserService (this is possible using HsdpaUserServiceId under HsdpaResource)

Restriction: ackNackRepetitionFactor and xCEM


Only value no repetition (ackNackRepetitionFactor = 1) is allowed, since xCEM supports only this
value.

The CQI is only sent in some specific subframes, as specified in [R04] 6A.1.1,
depending on the following parameters:

Parameter
Range & Unit
User
Class
Value

The CQI feedback cycle: k,

The repetition factor of CQI: N_cqi_transmit.

cqiRepetitionFactor
[1..4]
Customer
3
1

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 14/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


Parameter
Range & Unit
User
Class
Value

Object
cqiFeedbackCycleK
Enum {0, 2, 4, 8, 10, 20, 40, 80, 160} ms
Customer
Granularity
3
2

HsdpaUserService
HsdpaUserService[0..14]

Rule: cqiRepetitionFactor and cqiFeedbackCycleK


These parameters have to respect the following rule:
cqiRepetitionFactor cqiFeedbackCycleK / 2
Note that cqiFeedbackCycleK = 0 is not supported.

Parameter
Range & Unit
User
Class
Value

cqiPowerOffset
[0..8]
Customer
3
5

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

Parameter
Range & Unit
User
Class
Value

ackPowerOffset
[0..8]
Customer
3
6

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

Parameter
Range & Unit
User
Class
Value

nackPowerOffset
[0..8]
Customer
3
7

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

Engineering Recommendation: HS-DPCCH power


Note that power allocated on the HS-DPCCH can be different for each data (Ack, Nack or CQI)
through the power offset parameters: ackPowerOffset, nackPowerOffset and cqiPowerOffset. The
nackPowerOffset has to be higher than the other power offset in order to secure the reception of Nack,
a Nack misdetection being unfavorable when TCP retransmission occurs.

3.1.2 FAST LINK ADAPTATION


Every TTI, Adaptive Modulation and Coding (AMC) is updated according to the radio
conditions experienced by the UE and his category (see 4.1). AMC (number of codes,
code rate and modulation type) is chosen among 30 possibilities corresponding to one
CQI in order to reach the maximum bit rate while guarantying a certain QoS (10%
BLER for example). All UE categories have to support QPSK and 16QAM modulation
except categories 11 and 12 which only support QPSK (16QAM modulation allowing
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 15/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


higher bit rate). The following figure illustrates the AMC by showing the throughput
versus the radio conditions (Ior/Ioc):

AMC Illustration
800
700

Throughput (kbps)

600
500

QPSK
QPSK
QPSK
16QAM
16QAM

400
300
200
100
0

-20

-15

-10

-5

Ior/Ioc (dB)

Figure 13: Example of AMC: Throughput versus Ior/Ioc (radio condition)

3.1.3 FAST RETRANSMISSION MECHANISM (HARQ)


The HARQ (Hybrid Automatic Repeat Query) is a retransmission mechanism which
consists in:

Retransmitting by the NodeB the data blocks not received or received with
errors by the UE;

Combining by the UE the transmission and the retransmissions in order to


increase the probability to decode correctly the information.

3.1.3.1 NUMBER OF HARQ PROCESSES


There is an HARQ process assigned per transport block for all the transmissions. The
number of processes per UE is limited and depends on its category. The number of
processes per UE category is the one given in [R02]:

Ue Category

10

11

12

Number of HARQ Processes

Table 2: Number of processes per UE category for iCEM

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 16/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


Once this number is reached, the UE should not be eligible by the scheduler for new
transmissions unless one of them is reset (ACK reception, discard timer expiration,
max number of retransmissions reached). If the maximum number of retransmission is
reached or if discard timer (discardTimer or timerT1) expiration, then the MAC-hs PDU
is discarded leading to a RLC retransmission.

The maximum number of allowed MAC-hs retransmissions is :


For iCEM:
Parameter
Range & Unit
User
Class
Value

harqNbMaxRetransmissions
[131] decimal
Customer
3
7

Object

HsdpaConf

Granularity

BTSCell

The two following parameters are common for iCEM and xCEM (RNC parameters):
Parameter
Range & Unit
User
Class
Value

Object
HsdpaUserService
discardTimer
Enum [20; 40; 60; 80; 100; 120; 140; 160; 180 ; 200; 250; 300; 400; 500; 750;
1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500] ms
Customer
Granularity
HsdpaUserService[0..14]
3
500
This parameter defines the time to live for a MAC-hs SDU starting from the instant of
its arrival into an HSDPA Priority Queue.The Node B shall use this information to
discard out-of-data MAC-hs SDUs from the HSDPA Priority Queues

Parameter
Range & Unit
User
Class
Value

Object
HsdpaUserService
timerT1
Enum [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, 400] ms
Customer
Granularity
HsdpaUserService[0..14]
3
100
This parameter is used by the NodeB to stop the re-transmission of the corresponding
MAC-hs PDU (but ignored by the iCEM).

3.1.3.2 RV PARAMETERS
The IR (Incremental Redundancy) and modulation parameters necessary for the
channel coding and modulation steps are: the r, s and b values. The r and s
parameters (Redundancy Version or RV parameters) are used in the second rate
matching stage, while the b parameter is used in the constellation rearrangement step
(see [R03] for details):

s is used to indicate whether the systematic bits (s=1) or the non-systematic


bits (s=0) are prioritized in transmissions.

r (range 0 to rmax-1) changes the initialization Rate Matching parameter value


in order to modify the puncturing or repetition pattern.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 17/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

The b parameter can take 4 values (0 3) and determines which operations


are produced on the 4 bits of each symbol in 16QAM. This parameter is not
used in QPSK and constitutes the 16QAM constellation rotation for averaging
LLR at the turbo decoder input.

These three parameters are indicated to the UE by the Xrv value sent on the HSSCCH (see section 3.1.1.1). The coding tables of Xrv are given hereafter:

Xrv (Value)

Table 3: RV coding for 16QAM

Xrv (Value)

Table 4: RV coding for QPSK

The determination of the s, r and b parameters will be based on the Xrv update, but
not necessarily in the increasing order. The update indeed follows a predefined order
stored in a table (called hereafter Trv). The only requirement to fill this table is that
Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be the
nominal configuration).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 18/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


The rules to compute the Xrv parameters then are (see the following figure):

For the first transmission, Xrv is initialized to Trv[0].

Upon reception of a NACK, Xrv is assigned the next value in the table (once
the last value of the table, Nmax, has been set, the next value should be the
first one again).

In case of no reception of ACK/NACK (DTX indication), the parameters must


not be updated so that the same information not received by the UE should be
sent again (this ensure no systematic bits are lost, because all blocks may not
be self-decodable).

Y
New transmission ?

Xrv = Trv[0]
k=0

N
DTX indication ?

Xrv(n) = Xrv(n-1)

N
k=k+1
Xrv(n) = Trv[k mod Nmax]

Nmax = 1 (CC)
= 4 (PIR - QPSK)
= 6 (PIR 16QAM)
= 8 (MIR)

Figure 14: RV parameters assignment algorithm

An update table is defined per HARQ type as described in section 3.1.3.4

3.1.3.3 STATE OF HARQ PROCESSES


The following figure describes the different states of HARQ processes and possible
actions related to these.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 19/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


HARQ process assigned
by the scheduler

Update of RV parameters
Data transmission

Wait for ACK/NACK


reception

ACK

WACK state

DTX
ACK/NACK/DTX ?

Insertion of DTX
indication

NACK
Reset HARQ process
Remove Mac-d PDU
Update structures

Nret = Nret +1

Nret > Nret_max ?

N
NACK/DTX state

Wait for
retransmission

Figure 15: ACK/NACK/DTX management for HARQ processes

Once a UE is scheduled, an HARQ process is assigned that may correspond to either


a new Transport Block or a retransmission. The RV parameters are computed
accordingly as described before (see 3.1.3.2 RV Parameters section) and data is
transmitted. The HARQ process is then waiting for feedback information
(ACK/NACK/DTX) and is set in the so-called WACK state (Waiting for
Ack/Nack/DTX). The exact timing for reception of the feedback information must be
computed thanks to the chip offset and relatively to the TTI corresponding to the
transmission.

Upon reception of the feedback information, three behaviors occur:

In case of an ACK, the HARQ process is reset and corresponding MAC-d


PDUs are removed from memory. This HARQ process can now be used for a
new transmission.

In case of a NACK, the number of retransmissions must be incremented. If the


maximum number of retransmissions is not reached, the HARQ process is set
in the so-called NACK state and then inserted in the NACK list of HARQ
processes.

In case of a DTX indication, the same actions as for a NACK reception are
done, except that a parameter must be updated to notify DTX detection (this

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 20/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


changes the RV parameter update compared to Nack reception, that is to say
that the RV parameter update is not the same as for Nack, so no update, see
3.1.3.2 RV Parameters section). The process is then set in the DTX state.

The processes in the NACK or DTX state are just waiting for being re-scheduled for a
new retransmission.

3.1.3.4 CHOICE OF THE HARQ TYPE


A configurable parameter (CC/PIR/MIR) indicates the possibility of switching between
Chase Combining, a Partial IR or a mix between Partial and Full IR sequence. It
implies that 3 different tables must be stored (see below), chosen accordingly:

The Chase Combining option corresponds to the first redundancy version


always applied for all (re)transmissions.

The PIR indicates that for all redundancy versions, the systematic bits must
be transmitted (blocks are self-decodable). Only the RV with s = 1 must be
taken into account.

The MIR corresponds to a sequence where both systematic and nonsystematic bits can be punctured. All possible redundancy versions are
assumed and it corresponds to default version.

Each HARQ type is characterized by its update table Trv (see tables below)

Xrv(QPSK)

Xrv(16QAM)

Table 5: RV update table in the MIR case (Trv[i])

Xrv(QPSK)

Xrv(16QAM)

Table 6: RV update table in the PIR case (Trv[i])

The choice of the HARQ type (CC, MIR or PIR) is defined for all the retransmissions
by setting the parameter harqType (= 1 for MIR, = 2 for PIR and = 3 for CC). When
the HARQ type is selected, specific RV tables are used, one for QPSK and another
one for 16QAM (as explained in the previous paragraphs).
With the feature HSDPA Performance Enhancement Optimal Redundancy Version
for HARQ retransmission (29819), a fourth HARQ type can be selected: the Dynamic
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 21/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


Redundancy noted DR (harqType = 4). This value is introduced to indicate that
dynamic RV selection must be performed.
The aim of this sub-feature is to optimize the redundancy version (RV) of the
retransmissions by dynamically selecting the most efficient HARQ type (and his
corresponding RV table presented below) according to several parameters: UE
category, number of HARQ processes and applied AMC for first transmission.
The different HARQ types (each one being associated to a restricted redundancy
version set) that can be selected are:

Chase Combining (CC): same redundancy version than first transmission is


applied (QPSK only).
RV = 0.

CC + Constellation rearrangement (CC+CoRe): same puncturing pattern is


applied but constellation rotation is performed (16QAM only).
RV [0; 4; 5; 6].

Partial Incremental Redundancy (PIR): systematic bits are prioritized.


RV [0; 2; 4; 6] in QPSK and [0; 2; 4; 5; 6; 7] in 16QAM.

Full Incremental Redundancy (FIR): parity bits are prioritized.


RV [1; 3; 5; 7] in QPSK and [1; 3] in 16QAM

Table 7: RV updates tables when harqType set to Dynamic Redundancy


The principle is that incremental redundancy is only selected when required, i.e. as
soon as punctured bits by the 2nd Rate Matching stage AND total number of softbits
per HARQ process the UE can handle are higher than the number of transmitted bits.
Otherwise, chase combining is sufficient. In case of IR, it is only necessary to puncture
systematic bits (FIR) in case it is not possible to transmit all parity bits punctured by
the 2nd RM stage in the first retransmission.
More in detail, during the Rate Matching step, following variables are computed:

NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes times
the modulation order (2 or 4) times 960 bits.

NIR: total number of softbits per HARQ process the UE can handle. It only
depends on the UE category and the number of allocated HARQ processes.

NSYS: number of systematic bits (not equal to transport block size).

NP1 and NP2: number of parity bits 1 and 2 after 1st RM step.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 22/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

NRM1 = NSYS + NP1 + NP2

NPUNC2 = NRM1 - NDATA: number of bits punctured by 2nd RM stage.

These values are then used to select the right HARQ type as explained by the
following figure:

Figure 16: Dynamic selection of HARQ type

Note: As the RV of the 1st transmission is identical whatever the HARQ type is,
previous variables should then be stored during the rate matching of the first
transmission. The HARQ Type only needs to be determined when 1st retransmission
occurs.

Parameters Settings:
See [Vol. 3].

HARQ with xCEM:


For xCEM as for iCEM, an HARQ process is assigned per transport block for all the
transmissions and the number of processes per UE is limited and depends on its
category:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 23/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


Ue Category

10

11

12

Number of HARQ Processes

Table 8: Number of processes per UE category for xCEM/UCU-III

Once this number is reached, the UE should not be eligible by the scheduler for new
transmissions unless one of them is reset (ACK reception, discard timer expiration,
max number of retransmissions reached). If the maximum number of retransmission is
reached or if discard timer (discardTimer or timerT1) expiration, then the MAC-hs PDU
is discarded leading to a RLC retransmission.

The maximum number of allowed MAC-hs retransmissions is :


Parameter
Range & Unit
User
Class
Value

harqNbMaxRetransmissionsXcem
[131] decimal
Customer
0
7

Object

HsdpaConf

Granularity

BTSCell

For UCU-III, the maximum number of retransmissions is set to 10

The HARQ type selection is done through the parameter harqTypeXcem:


Parameter
Range & Unit
User
Class
Value

harqTypeXcem
[ccType, irType]
Customer
3
irType

Object

HsdpaConf

Granularity

BTSCell

The following tables give according to [R03] the redundancy version and constellation
depending on the modulation:
i

Xrv(QPSK)

Xrv(16QAM)

Table 9: RV update table in the IR case (Trv[i])

Xrv(QPSK)

Xrv(16QAM)

Table 10: RV update table in the CC case (Trv[i])

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 24/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


3.1.4 FAST SCHEDULING
The aim of the MAC-hs scheduler is to optimize the radio resources occupancy
between users. Every TTI, it must then select Queue IDs for which data is going to be
transmitted and the amount of corresponding MAC-d PDUs to transmit.

[iCEM]
The scheduler first receives as input every TTI the number of codes available and the
remaining power for HS-PDSCH and HS-SCCH (see [Vol. 3]). The received
ACK/NACK and CQI must also be provided to the scheduler when available. Thanks
to this information, UE capabilities, configuration parameters provided by the RNC and
taking into account the previously scheduled data, the scheduler can select the sub
flows of the users to schedule in order to optimally use available resources. The main
concepts of the scheduler are:

Retransmissions are of higher priority than new transmissions and should be


scheduled first.

The Queue ID (QId) is chosen according the Scheduling Priority Indicator (SPI
or CmCH-PI) and the radio condition based on CQI.

The transport blocks should always be optimized according to the transmitted


CQI when possible (if enough codes and power are available and if theres no
CPU limitation).

No queue ID should be left starving, i.e. the scheduler should always allocate
even a small part of radio resources to all users (even those with low priority
and bad CQI).

From UA5.0, the MAC-hs scheduler has been enhanced (29807 MAC-hs scheduler
improvement) in order to support 2 MAC-hs scheduler types (Classical Proportional
Fair, ALU Proportional Fair,) and manage SPI.

The scheduling method for the different scheduler is the following one:

Classical Proportional Fair: Users are chosen according to the instantaneous


CQI/averaged CQI criteria. UEs that are in their best instantaneous conditions
with regard to their average are scheduled first.

Alcatel-Lucent Proportional Fair scheduler: Users are chosen according to the


number of transmitted bits and the reported CQI

[xCEM]
The aim of the scheduler is to share the resources between the different HSDPA
users. xCEM scheduler works in following steps:
-

To select of a limited number of users from those which are ready for
transmission in the curret TTI (the number of users per TTI being
limited by the number of HS-SCCH configured and by the available
resources mainly in term of codes and power).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 25/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


-

To select of a Transport Format resource Combination (TFRC =


{MAC-hs PDU size; number of HS-PDSCH codes; modulation
alphabet}) of each user.

To allocate of power for the HS-SCCH and HS-DSCH of each user.

To rank the users according to certain pre-defined scheduling metric,


which may or may not take the chosen TFRC into account.

With iCEM, the TFRC is chosen by doing a mapping between the CQI (CQI processed
in order to take into account the bler target and to fit with the available resources).
With xCEM, the TFRC selection is based on the Spectral Efficiency (SE). The SE for a
given SINR states the maximal number of bits before channel encoding and before
addition of CRC bits and tail bits for terminating the Turbo Code that can be
transmitted over an AWGN channel with a certain BLER. The SINR is based on the
CQI reported by the ue.

3.2 HSUPA (E-DCH)


3.2.1 TRANSPORT AND PHYSICAL CHANNELS
HSUPA proposed the following set of new physical channels:

E-DPCCH carries the UL signaling information

E-DPDCH carries the data traffic

E-HICH (Hybrid ARQ Indicator Channel) in DL to indicate if the UL


transmission are well received (ACK/NACK channel)

E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) in


DL to indicate to the HSUPA UE (individually or per group) what are their
allocated UL resources. This indication can be done using an explicit value
(through E-AGCH) or relatively to the last allocated UL resources (with ERGCH)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 26/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

H
PD
C
E-

HI
CH
EA
GC
ERG
H
CH

ED

E-

DP
CC

Volume 2 : HSxPA Overview

Figure 17: HSUPA channels and associated R99 channels

A specific E-DCH transport channel is defined. As the classical DCH transport channel
it allows to offer transport services to higher layers. The E-DCH transport channel is
characterized by:

Only for UL

Two possible TTI : 10ms and 2ms

Transport block size and Transport Block set size are free attributes of the
transport format.

Possibility of HARQ process with retransmission procedures applied at


NodeB. The maximum allowed number of retransmissions is defined via
edchHarqMaxRetransEdchTti10
(for
10ms
E-DCH
TTI)
and
edchHarqMaxRetransEdchTti2 (for 2ms E-DCH TTI) parameters.

Support of E-DCH HARQ retransmissions of type Incremental Redundancy.


Remark: In UA6, only Incremental Redundancy type of E-DCH HARQ is
supported. harqType parameter under EdchConf is ignored by the system,
(as in UA5), and there is no related parameter at RNC level (UA5
harqRvConfiguration parameter under EdchUserService has been
removed).

Turbo coding with rate 1/3 is used

CRC is 24 bits length

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 27/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

E-TFCI (Transport Format Combination Indication) indicates which format is


currently used for the UL transmission

Sequence number, redundancy version, E-TFCI must be placed onto E-DPCCH


channel. On the other hand the traffic transported by E-DCH TrCh must be placed on
the E-DPDCH part.
edchHarqMaxRetransEdchTti10: Defines the maximum number of retransmission at
E-DCH HARQ level when the UL RB is mapped on E-DCH with an E-DCH TTI of
10ms.
Parameter
Range & Unit
User
Class
Value

edchHarqMaxRetransEdchTti10
Integer [0 ..15], N/A
Customer
3
[iCEM] [xCEM] 4
[UCU-III] 3

Object

EdchParameters

Granularity

RNC,
UlRbSetConf

[xCEM]
edchHarqMaxRetransEdchTti2: Defines the maximum number of retransmission at
E-DCH HARQ level when the UL RB is mapped on E-DCH with an E-DCH TTI of 2ms.
Parameter
Range & Unit
User
Class
Value

edchHarqMaxRetransEdchTti2
Integer [0 ..7], N/A
Customer
3
7

Object

EdchParameters

Granularity

RNC,
UlRbSetConf

3.2.1.1 UPLINK CHANNELS


The E-DPDCH is used to carry the E-DCH transport channel. There may be zero, one,
or several E-DPDCH on each radio link.

The E-DPCCH is a physical channel used to transmit control information associated


with the E-DCH. There is at most one E-DPCCH on each radio link.

The E-DPDCH and E-DPCCH (sub) frame structure is presented on the figure below
(from [3GPPref]):

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 28/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


E-DPDCH

Data, Ndata bits


Tslot = 2560 chips, Ndata = 10*2k bits (k=07)

E-DPCCH

10 bits

Tslot = 2560 chips

Slot #0

Slot #1

Slot #2

Slot #i

Slot #14

1 subframe = 2 ms
1 radio frame, Tf = 10 ms

Figure 18: E-DPCCH / E-DPDCH frame structure

On uplink, each radio frame is divided in 5 sub frames, each of length 2 ms. Different
E-DPDCH and E-DPCCH slot formats have been defined as shown on the two tables
below:

Slot Format #i

Channel Bit Rate (kbps)

SF

Bits/ Frame

Bits/ Subframe

0
1
2
3
4
5
6
7

15
30
60
120
240
480
960
1920

256
128
64
32
16
8
4
2

150
300
600
1200
2400
4800
9600
19200

30
60
120
240
480
960
1920
3840

Bits/Slot
Ndata
10
20
40
80
160
320
640
1280

Table 11: E-DPDCH slot formats

Slot Format #i

Channel Bit Rate (kbps)

SF

Bits/ Frame

Bits/ Sub frame

15

256

150

30

Bits/Slot
Ndata
10

Table 12: E-DPCCH slot formats

E-DCH multicode transmission is possible only for SF = 4 and SF = 2.


The possible codes are SF 256 for e-DPCCH and SF2 to SF256 for e-DPDCH. These
two new channels produced a composite complex signal as described in the figure
below [3GPP ref]:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 29/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


ced,1

ed,1

iqed,1

ced,k

ed,k

iqed,k

E-DPDCH1
.
.
.
.
E-DPDCHk
.
.
.
.

ced,K

ed,K

iqed,K

cec

ec

iqec

I+jQ
Se-dpch

E-DPDCHN

E-DPCCH

Figure 19: E-DPDCH/E-DPCCH multiplexing on I/Q

DPCCH
DPDCHs

Sdpch

Spreading
Sdpch,n
Shs-dpcch

HS-DPCCH

Spreading
E-DPDCHs
E-DPCCH

I+jQ
S

Se-dpch

Spreading

Figure 20: Uplink physical channels multiplexing

The reference E-TFCI transport blocks and power offsets are signaled through the call
setup message. They contain a subset of the authorized E-TFCI.
One E-DPCCH frame contains 10 bits, 7 for E-TFCI index, 2 for the RV version used
(HARQ process), and 1 happy bit. The power offset of the E-DPCCH can be set
through deltaEdpcch parameter:
Parameter
Range & Unit
User
Class
Value

deltaEdpcch
Integer [0 8], N/A
Customer
0
4

Object

EdpchParameters

Granularity

RNC, EdpchInfoClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 30/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


The correspondence between the index and the amplitude is specified by 3GPP [R06]:
Quantized amplitude ratios for
E DPCCH

10 20

Signalling values for E-DPCCH


8
7
6
5
4
3
2
1
0

30/15
24/15
19/15
15/15
12/15
9/15
8/15
6/15
5/15
Table 13: E-DPCCH power offset index vs. amplitude

The value of ec is based on the power offset E-DPCCH signalled by higher layers. The
formula to apply is:

ec = c 10

E DPCCH

20

3.2.1.2 DOWNLINK CHANNELS


The E-DCH Absolute Grant Channel (E-AGCH) is a fixed rate (30 kbps, SF=256)
downlink physical channel carrying the uplink E-DCH absolute grant. The next figure
illustrates the frame and sub-frame structure of the E-AGCH:

E-AGCH

20 bits

Tslot = 2560 chips

Slot #0

Slot #1

Slot #2

Slot #i

Slot #14

1 subframe = 2 ms
1 radio frame, Tf = 10 ms

Figure 21: E-AGCH frame structure

An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one EAGCH frame. The transmission over one E-AGCH sub-frame and over one E-AGCH
frame shall be used for UEs for which E-DCH TTI is set to respectively 2 ms and
10 ms. 6 bits are used to code Access Grant values. One 16 bits CRC (xored by UE
id) is attached to the AG value to form one 22 bits word. A rate 1/3 convolution coding
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 31/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


(constraint length 9) is then used leading to a total of 90 protected bits. A specific
puncturing scheme is then applied to finally select a 60 bits sequences (30 bits are
removed). With this kind of mechanisms only one UE can be touched at each E-DCH
TTI.

The E-DCH Relative Grant Channel (E-RGCH) is a fixed rate (SF=128)


dedicated downlink physical channel carrying the uplink E-DCH relative
grants. The structure of the E-RGCH is the same than the one used for EHICH channel.

A relative grant is transmitted using 3, 12 or 15 consecutive slots and in each slot a


sequence of 40 ternary values is transmitted. The 3 and 12 slot duration shall be used
on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is in the
E-DCH serving radio link set and for which the E-DCH TTI is respectively 2 and 10
ms. The 15 slot duration shall be used on an E-RGCH transmitted to UEs for which
the cell transmitting the E-RGCH is not in the E-DCH serving radio link set.
The sequence bi,0, bi,1, , bi,39 transmitted in slot I (see Figure 22: E-HICH frame
structure) is given by:

bi,j = a Css,40,m(i),j
In a serving E-DCH radio link set, the relative grant a is set to +1, 0, or -1 and in a
radio link not belonging to the serving E-DCH radio link set, the relative grant a is set
to 0 or -1.
The relative grant (RG) command is mapped to the relative grant value as described
in the table below:

Command

RG Value (serving E-DCH RLS)

RG Value (other radio links)

UP

+1

not allowed

HOLD

DOWN

-1

-1

Table 14: Relative grant information (E-RGCH)

The orthogonal signature sequences Css,40, m(i) and the index m(i) in slot i are chosen in
the same tables than those used for E-HICH ACK/NACK indicators. The E-RGCH
signature sequence index l is given by higher layers.
In each cell, the E-RGCH and E-HICH assigned to a UE shall be configured with the
same channelisation code (SF 128).

The E-DCH Hybrid ARQ Indicator Channel (E-HICH) is a fixed rate (SF=128)
dedicated downlink physical channel carrying the uplink E-DCH hybrid ARQ
acknowledgement indicator.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 32/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


The following figure illustrates the structure of the E-HICH:

b i,0

b i,1

b i,39
T slot = 2560 chip

S lot #0

S lot #1

S lot #2

S lot #i

Slot #14

1 subfram e = 2 m s
1 radio fram e, T f = 10 m s

Figure 22: E-HICH frame structure

A hybrid ARQ acknowledgement indicator is transmitted using 3 or 12 consecutive


slots and in each slot a sequence of 40 binary values is transmitted. The 3 and 12 slot
duration shall be used for UEs which E-DCH TTI is set to respectively 2 ms and
10 ms.
The sequence bi,0, bi,1, , bi,39 transmitted in slot i in previous figure is given by :

bi,j = a Css,40, m(i),j.


In a radio link set containing the serving E-DCH radio link set, the hybrid ARQ
acknowledgement indicator a is set to +1 or 1, and in a radio link set not containing
the serving E-DCH radio link set the hybrid ARQ indicator a is set to +1 or 0.
The ACK/NACK command is mapped to the HARQ acknowledgement indicator as
described in the table below.

Command

HARQ acknowledgement indicator

ACK

+1

NACK (RLSs not containing the serving E-DCH cell)

NACK (RLS containing the serving E-DCH cell)

-1

Table 15: ACK/NACK information (E-HICH)

The orthogonal signature sequences Css,40,m(i) and the index m(i) are given in specific
tables. The E-HICH signature sequence index l is given by higher layers.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 33/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


3.2.2 UA5 IMPLEMENTATION OF E-DCH
Below rules and restrictions summarize Alcatel-Lucent implementation of E-DCH in
UA5. The term restriction in this section refers to E-DCH well-known functionalities
that are not available in UA5 release. It does not refer to specific restrictions regarding
what was commited by Product Line Management for UA5.
Rule: E-DCH always works with HSDPA established in downlink
With Alcatel-Lucent implementation, E-DCH always works with HSDPA established in downlink.
Precisely, for a given UE, when an E-DCH transport channel is established in uplink, the DL DTCH
logical channel is always mapped on HS-DSCH transport channel.

Restriction: E-DCH TTI


In UA5, only 10 ms E-DCH TTI is supported. 2 ms E-DCH TTI is not supported.

Restriction: E-DCH Macro-Diversity


In UA5, E-DCH Macro-Diversity is not supported. In other words, for a given E-DCH call only one EDCH transport channel can be established, i.e. E-DCH Active Set size is always equal to 1.

Restriction: E-DPDCH physical channels configuration (number and Spreading Factor)


In UA5, for both iCEM and xCEM, the highest configuration supported in terms of number of EDPDCHs and SF is 2xSF4. In other words, in UA5, 2xSF2 and 2xSF2+2xSF4 configurations are not
supported. Please refer to UA5 HPUG [R09] for more information regarding support of E-DPDCH SF
configurations in UA5.

Restriction: Non scheduled transmission


In UA5, Non-Scheduled transmission over E-DCH is not supported.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 34/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

4 UE CATEGORIES
4.1 HSDPA
3GPP has standardized several UE categories to accommodate a large spectrum of
HSDPA mobile implementations (see [R05]). The UE category provides the mobile
capabilities like max number of HS-PDSCH codes supported, modulation schemes
(16QAM, QPSK), MAC-HS transport block size, etc.
HS-DSCH category

Category 1
Category 2
Category 3
Category 4
Category 5
Category 6
Category 7
Category 8
Category 9
Category 10
Category 11
Category 12

Maximum
number of
HS-DSCH
codes
received
5
5
5
5
5
5
10
10
15
15
5
5

Minimu
m interTTI
interval
3
3
2
2
1
1
1
1
1
1
2
1

Maximum number of
bits of an HS-DSCH
transport block
received within
an HS-DSCH TTI
7298
7298
7298
7298
7298
7298
14411
14411
20251
27952
3630
3630

Total
number of
soft channel
bits
19200
28800
28800
38400
57600
67200
115200
134400
172800
172800
14400
28800

Table 16: HSDPA UE categories (3GPP TS25.306)


UEs of Categories 11 and 12 support QPSK only.
Each UE category has a table with 30 CQI (channel quality indicator) values. Each
CQI value provides complete information regarding the HS-DSCH to be received by
UE in DL in the next TTI.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 35/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


4.2 HSUPA
For HSUPA, the following UE categories have been specified in 3GPP [R05]:
E-DCH
category

Category 1

Maximum
number of
E-DCH
codes
transmitted

Minimum
spreading
factor

SF4

Support for
10 and 2 ms
TTI E-DCH

Maximum number of
bits of an E-DCH
transport block
transmitted within a
10 ms E-DCH TTI

Maximum number of
bits of an E-DCH
transport block
transmitted within a 2
ms E-DCH TTI

7110
10 ms TTI
only
Category 2
2
SF4
14484
2798
10 ms and
2 ms TTI
Category 3
2
SF4
14484
10 ms TTI
only
Category 4
2
SF2
20000
5772
10 ms and
2 ms TTI
Category 5
2
SF2
20000
10 ms TTI
only
Category 6
4
SF2
20000
11484
10 ms and
2 ms TTI
NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4

Table 17: HSUPA UE categories (3GPP TS25.306)


[xCEM]
In UA6 SF2 and 2msTTI are supported only by the xCEM (UE categories 4, 5 and 6
are supported) whereas the iCEM board keep the same capabilities as in UA5 (i.e UE
Cat 2, 4, 5 and 6 are not supported).

Restriction: HSUPA UE categories supported in UA5


In UA5, for both iCEM and xCEM, fully supported HSUPA UE Categories are Category 1 and 3. All
other HSUPA UE Categories are handled in best effort, i.e. only 10ms E-DCH TTI is supported and
the maximum throughput of Categories higher than 3 is limited to the maximum throughput of
Category 3 (i.e. 1.45 Mbps at MAC-e level).
Reminder: In UA5, only 10 ms E-DCH TTI is supported.

In term of bit rate, we can expect a maximum MAC-e throughput of:

2.0 Mbits/s for TTI = 10 ms


And a maximum RLC throughput of:

Category 3: 1380 kb/s

Category 5: 1890 kb/s

5.76 Mbits/s for TTI = 2 ms (Not Applicable to UA5)


And a maximum RLC throughput of:
o

Category 4: 2720 kb/s

Category 6: 5440 kb/s

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 36/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview


[UCU-III]
For the OneBTS UCU-III, only 10ms TTI is supported and minimum SF equal to 2SF2
in UA6 (i.e. cat 2, 4, and 6 on 2ms TTI are not supported). UCU-III supports up to
category 5, on 10 ms TTI only. It does not support category 6 (it would be managed
like a category 4 on 10ms TTI).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 37/38

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 2 : HSxPA Overview

Z END OF DOCUMENT Y

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 38/38

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

V03.10
02/OCT/2009

HSXPA PARAMETERS USER GUIDE

HSDPA PRINCIPLES, SCHEDULING AND RESOURCE


MANAGEMENT

Alcatel-Lucent Proprietary

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

CONTENTS
1

INTRODUCTION............................................................................................................................5
1.1

OBJECT ....................................................................................................................................5

1.2

SCOPE OF THIS DOCUMENT .......................................................................................................5

RELATED DOCUMENTS ..............................................................................................................8


2.1

HPUG VOLUMES ......................................................................................................................8

2.2

REFERENCE DOCUMENTS ..........................................................................................................8

HSDPA ACTIVATION....................................................................................................................9

SCHEDULER .................................................................................................................................9
4.1

ALGORITHM ..............................................................................................................................9

4.1.1
iCEM................................................................................................................................9
4.1.2
xCEM/UCU-III................................................................................................................11
4.1.2.1
UL processing........................................................................................................... 11
4.1.2.2
CQI SNR mapping and SNR SE mapping ...................................................... 11
4.1.2.3
HARQ process and priority queue selection ............................................................ 11
4.1.2.4
User ranking ............................................................................................................. 12
4.1.2.5
SNR estimation for HS-PDSCH................................................................................ 12
4.1.2.6
TFRC selection......................................................................................................... 12
4.2
SCHEDULER TYPES .................................................................................................................14
4.2.1
iCEM..............................................................................................................................14
4.2.2
xCEM.............................................................................................................................15
4.3
QOS MANAGEMENT .................................................................................................................17
4.3.1
iCEM..............................................................................................................................18
4.3.2
xCEM.............................................................................................................................20
4.4
UE CATEGORY MANAGEMENT ..................................................................................................28
4.4.1
iCEM..............................................................................................................................28
4.4.2
xCEM.............................................................................................................................29
4.5
HSDPA USER SCHEDULING.....................................................................................................29
4.5.1
4.5.2
5

iCEM..............................................................................................................................29
xCEM.............................................................................................................................30

TFRC MANAGEMENT ................................................................................................................31


5.1

MAC-D PDU SIZE MANAGEMENT .............................................................................................31

5.2

656 PDU QUALCOMM UE BUG WORKAROUND .........................................................................37

5.3

TRANSPORT BLOCK SIZE OPTIMIZATION...................................................................................38

5.4

TFRC SELECTION ...................................................................................................................44

CQI & MAC-HS BLER MANAGEMENT......................................................................................46


6.1

CQI PROCESSING ...................................................................................................................46

6.2

CQI ADJUSTMENT ACCORDING TO BLER .................................................................................47

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 1/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
6.3
7

HS-DPCCH PRESENCE DETECTION ........................................................................................54


OVSF CODES..............................................................................................................................58

7.1

CELL CONFIGURATION ............................................................................................................58

7.2

HSDPA CODE ALLOCATION ....................................................................................................59


7.2.1
7.2.2

Dynamic Code Tree Management ................................................................................60


Fair Sharing...................................................................................................................71

POWER MANAGEMENT FOR HSDPA ......................................................................................74


8.1

INTRODUCTION .......................................................................................................................74

8.2

HS-DSCH POWER MANAGEMENT ............................................................................................74

8.2.1
Power allocation............................................................................................................74
8.2.1.1
RNC level.................................................................................................................. 74
8.2.1.2
NodeB level .............................................................................................................. 78
8.2.1.3
Power available for HSDPA channels ...................................................................... 79
8.2.2
Power measurements ...................................................................................................79
8.2.2.1
Transmitted carrier power......................................................................................... 80
8.2.2.2
Averaged HSDPA power .......................................................................................... 80
8.2.2.3
Total non HSDPA power .......................................................................................... 81
8.2.2.4
Available HSDPA power........................................................................................... 82
8.2.2.5
HS-DSCH Required Power ...................................................................................... 83
8.2.3
HSDPA power distribution.............................................................................................85
8.2.3.1
HS-SCCH power ...................................................................................................... 85
8.2.3.2
HS-DSCH power ...................................................................................................... 86
8.2.3.3
HS-PDSCH power .................................................................................................... 88
8.2.4
Power management ......................................................................................................92
8.2.4.1
First transmission ..................................................................................................... 92
8.2.4.2
Retransmission......................................................................................................... 97
8.2.4.3
Multi-users per TTI ................................................................................................... 99
8.3
HS-SCCH POWER MANAGEMENT ......................................................................................... 100
8.4

PARAMETERS SETTINGS AND RECOMMENDATIONS ................................................................ 103

8.5

UA6 MANAGEMENT OF UL POWER PROFILES DEPENDING ON WHETHER HSDPA IS MAPPED ON

THE DL 106

8.5.1
8.5.2
8.5.3
9

Introduction................................................................................................................. 106
Feature Description.................................................................................................... 107
Parameters Settings and Recommendations ............................................................ 108

OTHER FEATURES ................................................................................................................. 110


9.1

HSDPA AND E-DCH SERVICE INDICATOR (32520)............................................................... 110

9.2

HSDPA PERFORMANCE ENHANCEMENT (29819) ................................................................. 111

9.3

HSDPA OCNS (34195)...................................................................................................... 112

9.3.1
HSDPA OCNS principle ............................................................................................. 112
9.3.2
HSDPA OCNS parameters ........................................................................................ 113
9.4
IU USER TRAFFIC CONFORMANCE ........................................................................................ 118
9.4.1
9.4.2
9.4.3
9.4.4

Feature applicable...................................................................................................... 118


Algorithm .................................................................................................................... 118
Parameters................................................................................................................. 119
Feature Behaviour...................................................................................................... 121

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 2/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

TABLES
Table 1: CQI mapping table for 336 bits MAC-d PDU size
Table 2: CQI mapping table for 656 bits MAC-d PDU size
Table 3: Max hsdschInterval value
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size
Table 5: Necessary throughput per HSDPA UE category
Table 6: Iub bandwidth per number of E1 links
Table 7: HS-SCCH power offset table according the reported CQI
UT

TU

UT

TU

TU

UT

TU

UT

UT

TU

TU

TU

UT

UT

40
41
42
43
44
44
100

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 3/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

FIGURES
Figure 1: MAC-hs scheduler overview ............................................................................................................ 10
Figure 2: TFRC selection algorithm used by the xCEM/ UCU-III ................................................................ 14
Figure 3 : Example of Scheduling Weight for different value of serviceBFactor ....................................... 22
Figure 4: Example of Scheduling Weight for different value of serviceKFactor ........................................ 23
Figure 5: Parameters to configure the feature MAC-d PDU size 656 bits .............................................. 35
Figure 6: Conditions to invoke the feature 79164 .......................................................................................... 38
Figure 7: Padding bits in the MAC-hs PDU .................................................................................................... 39
Figure 8: Codes limitation ................................................................................................................................. 45
Figure 9: Code boost ......................................................................................................................................... 46
Figure 10: CQI Processing................................................................................................................................ 47
Figure 11 : BLER Target according to the CQI and the UE category for the different BLER Ajustement
algorithm ...................................................................................................................................................... 49
Figure 12: CQI adjustment to BLER algorithm............................................................................................... 50
Figure 13: HS-DPCCH synchronization algorithm ........................................................................................ 55
Figure 14: R99, HSDPA & HSUPA Common Channels codes allocation ................................................. 59
Figure 15: HS-PDSCH codes pre-emption or re-allocation ......................................................................... 62
Figure 16: Number of HS-PDSCH codes pre-empted .................................................................................. 63
Figure 17: Number of HS-PDSCH codes re-allocated.................................................................................. 63
Figure 18: Illustration of the HS-PDSCH re-allocation blocking .................................................................. 64
Figure 19: Exemple of codes occupancy for SF16 ....................................................................................... 72
Figure 20: Power allocation at RNC level ....................................................................................................... 75
Figure 21: Physical shared channel reconfiguration message .................................................................... 78
Figure 22: Power allocation at NodeB level ................................................................................................... 78
Figure 23: Transmitted carrier power (on the left) and averaged HSDPA power (on the right) ............. 81
Figure 24: Common measurement .................................................................................................................. 81
Figure 25: Power measurement process ........................................................................................................ 83
Figure 26: Power distribution between HS-DSCH and HS-SCCH channels ............................................. 86
Figure 27: measurementPowerOffset transmission ...................................................................................... 87
Figure 28: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH......... 89
Figure 29: hsdpaAmpUsage parameter .......................................................................................................... 90
Figure 30: Dynamic Power Allocation ............................................................................................................. 91
Figure 31: HS-DSCH power management for 1st transmission.................................................................. 93
Figure 32: MAC-hs transport block adaptation according to the number of MAC-d PDU to transmit ... 95
Figure 33: Remaining power for multi-users per TTI scheduling ................................................................ 99
Figure 34: HS-SCCH power control overview.............................................................................................. 101
Figure 35: Algorithm for CQI Generating Function ...................................................................................... 115
Figure 36: Traffic Conformance Algorithm.................................................................................................... 119
TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

TU

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

TU

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

TU

TU

UT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 4/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.

description,

configuration

aspect

and

engineering

1.2 SCOPE OF THIS DOCUMENT


The following features are described in the document:

PM ID
27931

Feature Title
HSDPA Flexible
resources Mgt

Activation flag
N/A

Release

Global
US
market Market

UA4.2

Yes

Yes

UA4.2

Yes

Yes

hsdpaActivation
27932

HSDPA Step 1

hsdpaResourceActivation
isHsdpaAllowed

27939

HS-SCCH Power
Control

N/A

UA4.2

Yes

Yes

29809

UE Cat 7 & 8 Support N/A

UA5.0

Yes

Yes

29813

UE Cat 9 & 10
Support

UA5.0

Yes

Yes

UA5.0

Yes

Yes

UA5.0

Yes

Yes

UA5.0

Yes

Yes

29800

Dynamic DL Code
Tree Mgt For HSDPA

N/A
isHsPdschDynamicManagementAll
owed
isCellHsPdschDynamicManagemen
tActive (from UA6.0)
hsdpaSchedulerAlgorithm
hsdpaSchedulerWeightingFactor

29807

MAC-hs scheduler
improvement

hsdpaUeCategoryThroughputWeig
hting
hsdpaSpiRelativeWeight
isHsxpaServiceIndicatorEnabled

32520

HSDPA and E-DCH


Service Indicator

hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 5/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
hsdpaCqiBlerAdjustmentAlgo
29819

HSDPA Performance
Enhancement

ueCategory1..12

UA5.0

Yes

No

UA5.1

Yes

No

UA5.1

Yes

No

UA5.1

Yes

Yes

UA6.0

Yes

Yes

harqType
rxDemodulation
isDynamicMacdPduSizeManageme
ntAllowed

34340

UE cat.8 max.
throughput with PDU
656 & RLC
reconfiguration

eligibleUeCategoryForHighPerform
ance
minimumUserMbrForHighPerforma
nce
maxCellRadius (only in UA5.1)

27350
34652

xCEM hardware
introduction
High quality UL R99
RAB for High HSDPA
DL data rate

N/A
N/A

isDynamicMacdPduSizeManageme
ntAllowed
eligibleUeCategoryForHighPerform
ance
29799

MAC-d PDU size


Management for
HSDPA

minimumUserMbrForHighPerforma
nce
isHsdpaCellHighPerformance (from
UA6)
isHighPerformancePduSizeReconf
Allowed

29804

GBR on HSDPA

isGbrOnHsdpaAllowed (used only


to map Streaming on HSDPA)

UA6.0

Yes

Yes

33390

Dynamic BLER
Adjustment

hsdpaCqiBlerAdjustmentAlgo
hsdpaCqiBlerAdjustmentAlgorithm
xCEM

UA6.0

Yes

No

33391

HS-DSCH Power
Adjustment Evolution

hsdpaFullPowerUsage

UA6.0

Yes

No

UA6.0

Yes

Yes

RNC:
isHsxpaR99ResourcesSharingOnC
ellAllowed
U

33694

Fair Sharing of
Resources - HSDPA
vs DCH

NodeB:
U

BTSEquipment::hsdpaCodeTreeMa
nagementActivation (iCEM/xCEM)
OneBTSEquipment::hsdpaCodeTre

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 6/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
eManagementActivation (UCU-III)
34102
34195
79164

HSDPA Flexible
Modulation

hsdpaFlexibleModulationVsCodeAc
tivation

UA6.0

Yes

No

Support OCNS with


HSDPA
Qualcomm issue with
656 PDU size
workaround

proprietaryHSDPAOCNSActivation

UA6.0

No

Yes

UA6.0

Yes

Yes

IsRlcReconfigAllowedForR99

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 7/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios

2.2 REFERENCE DOCUMENTS


[R01] UMT/DCL/DD/0020

UTRAN Parameters User Guide

[R02] 3GPP TS 25.214

Physical layer procedures (FDD)

[R03] 3GPP TS25.306

UE Radio Access capabilities

[R04] 3GPP TS 23.107


architecture

Quality

[R05] UMT/SYS/DD/013319

HSDPA System Specification

[R06] UMT/BTS/INF/016135
Planning Guide

Micro NodeB & 9314 Pico NodeB Feature

of

Service

(QoS)

concept

and

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 8/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

3 HSDPA ACTIVATION
HSDPA is activated through several activation flags at RNC, FDDCell and BTSCell
level:

Parameter
Range & Unit
User
Class
Value

isHsdpaAllowed

Object

RadioAccessService

Granularity

RNC

False, True

Customer
3
True

Parameter
Range & Unit
User
Class
Value

Object

FDDCell

Customer
2
True

Granularity

Cell

hsdpaResourceActivation

Object

BTSCell

Granularity

Cell

hsdpaActivation
False, True

Parameter
Range & Unit
User
Class
Value

False, True

Customer
2
True

Note that isHsdpaAllowed exists also in two other objects (RNC / NeighbouringRNC
and RNC / NodeB / FDDCell / UMTSFddNeighbouringCell) in order to know if the
HSDPA call has to be reconfigured or not in DCH when the primary cell changes in
case of mobility over Iur.
HTU

HTU

UTH

UTH

UTH

UTH

HTU

UTH

UTH

4 SCHEDULER
4.1 ALGORITHM
4.1.1 iCEM
As described in the figure below, MAC-hs scheduling consists of choosing the MAC-d
flow (QId) to serve.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 9/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Figure 1: MAC-hs scheduler overview

The QId is selected using radio (CQI) and priority (SPI) criteria. The selection of a QId
to be scheduled is based on a single cost function with inputs from two costs:
- The first one (C1) depends on the scheduler type. It takes into account the radio
criterion.
- The second one (C2) takes into account the priority of the QID and mainly
depends on the base credits assigned to this SPI priority and the average CQI.
This is used by both Alcatel-Lucent PF and Classical PF schedulers.

The resulting cost is a function of these two costs, and is different according to the
scheduler type. Indeed, for Alcatel-Lucent Proportional Fair scheduler, the resulting
cost should be equal to C1+C2, while for the Classical Proportional Fair, the
resulting cost is rather equal to *C1*C2 (, , being hard coded). The QId with the
smallest cost is scheduled first. Costs are updated after the QId has been served.

Once a user is chosen to be scheduled according to its cost function, the scheduler
selects for this user a TFRC (transport block size, number of HS-PDSCH and
modulation) based on the reported CQI and by taking into account the available
resources in term of power and codes (see 8.2). CQI can also be adapted in order to
control the Mac-hs BLER (see 6)
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 10/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
4.1.2 xCEM/UCU-III
The following section describes the algorithm used by xCEM/UCU-III to schedule
several HSDPA users. Where there is difference in behavour between the two, it is
highlighted in the description.

4.1.2.1 UL PROCESSING
First of all, the scheduler needs to receive and decode the HS-DPCCH for all the
users in order to have Ack/Nack and CQI information.

4.1.2.2 CQI SNR MAPPING AND SNR SE MAPPING


According to the 3GPP ([R02]), the UE has to report a CQI assuming a 1st TX BLER of
10% and a transmitted power for the HS-DSCH equal to the following reference
power:
X

PHS-DSCH reference[dBm] = PP-CPICH[dBm] + [dB] + (CQIreported)[dB]


B

where

PP-CPICH is the power of the P-CPICH channel,


B

is the measurement power offset

is the reference power offset given by the reference tables of CQI [R02].
X

Contrary to iCEM, xCEM/UCU-III does not directly use the CQI. The received CQI
information is mapped to SNR values (SNRMAP,dB) depending on UE category. The
TFRC selection is then based on a second mapping between this SNR and the
Spectral Efficiency (SE). The SE defines the number of bits per HS-PDSCH code per
TTI that can be transmitted for a given symbol SNR and SF = 16 (assuming 10%
MAC-hs bler) in an AWGN channel.
B

4.1.2.3 HARQ PROCESS AND PRIORITY QUEUE SELECTION


The eligibility of the users is checked based on the number of HARQ processes
already used. Note that the 3GPP standard supports only one priority queue and one
HARQ process for each user to be used within one TTI. In case several HARQ
processes are ready for retransmission then priority is given to the process waiting the
longest.
HARQ process can be selected for transmission or retransmission only if no ack/nack
are expected.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 11/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
4.1.2.4 USER RANKING
A priority is assigned to each user (after its priority queue and HARQ process have
been selected) based on a cost function. xCEM scheduler also creates a user ranking
list by sorting users by increasing cost (first scheduled is the one with the lowest cost).
The xCEM scheduler will try to schedule users one after the other according to this
ranked list (first user in the ranking list will be schedule first, then the second user of
the rank list, and so on). This iterative process is repeated as long as the ranking list is
not empty or as long as some resources are still available.
The cost function computation depends on the scheduler used (cRmax or
proportionalThroughput for xCEM and cRmax, unconstrained and fairThroughput for
UCU-III) and if MAC-d flow is GBR enabled. See sections 4.2.2 & 4.3.2 for more
details.
X

4.1.2.5 SNR ESTIMATION FOR HS-PDSCH


For the user selected from the ranking list, the scheduler estimates the SNR of one
HS-PDSCH code based on the SNRMAP,dB derived from CQI (see previously) and on
the available power per HS-PDSCH code:
B

SNRdB = SNRMAP,dB + PavailableHS-PDSCH Pcpich + (ack,nack)


B

PavailableHS-PDSCH is the power available per HS-PDSCH code. (see


section 8.2.3.3 for more details)
B

SNRMAP,dB is the last SNR value mapped on CQI assuming a HSDSCH power of Pcpich + ( being the measurementPowerOffset/2 ).
B

(ack,nack) is a correction factor used to ensure that the 1st Tx BLER


or residual BLER after N transimissions is achieved. (ack,nack) is
increased or decreased depending whether a ACK or a NACK is
received (see section 6.1 for more details)
P

This SNRdB is then mapped to a SE and used for TFRC selection.


B

4.1.2.6 TFRC SELECTION


SE gives the number of bits per HS-PDSCH code per TTI that the user can receive for
given RF conditions and the available power. So, the xCEM/UCU-III scheduler will
select from a look up table the TFRC (transport block size TBS, number of HSPDSCH codes nHS-PDSCH and modulation). LUT is made such as the selected TFRC
corresponds to the higher TBS and the lower number of HS-PDSCH so that the
spectral efficiency of this TFRC is lower than the SE computed previously:
B

TBS / nHS_PDSCH SE with maximal TBS and minimal nHS_PDSCH


B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 12/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Modulation is selected in order to use resources most efficiently. If SE is low then
QPSK is preferred, whereas 16-QAM is used when SE is high and UE supports 16QAM. This xCEM/UCU-III behavior (QPSK and 16-QAM can be used whatever the
number of HS-PDSCH codes) is related to the feature 34102, which introduces similar
behavour in iCEM.

Note that the TFRC selection takes into account:


-

the UE capability

the buffer occupancy of the selected priority queue

the number of available HS-PDSCH codes

the spectral efficiency SE

For UCU III: in case of an HARQ retransmission, the scheduler will not use the
instantaneous SE but the cumulated SE over all the transmissions of this HARQ
process, allowing to account for IR or CC gains (SEcum = SEcurrent + SEcum).
B

For xCem: the spectral efficiency is SE = min(SEcurrent; SEcum).


B

The power allocated for the HS-DSCH of the user i is:


PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH
B

This power is also weighted by the term factor because if B/W is smaller than SE, it
means that less power is needed to achieve the same error rate:
PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH x factor
B

factor =

SNR( B / W )
SNR ( SE )

Where:
-

B is the Transport Block Size selected by the scheduler

W is the number of HS-PDSCH codes selected by the scheduler

Only for UCU III: After all users have been selected for this TTI, some portion of the
HSDPA power may still be unused. This unused power is called excess power and is
redistributed equally over all HS-PDSCH codes that have been allocated for the
scheduled users in the TTI.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 13/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
For more details on power management, see section 8.2.3.3.
X

Then, available resources are updated for the next round of scheduling.

The following drawing summarizes the algorithm used by the xCEM/UCU-III to select
the TFRC of a UE:

SNR (dB)

Log2lin

Number of HS-PDSCH
MAC-hs PDU Size

SE

SNR of one HS-PDSCH (linear)

SE

SE

CQI

SNR of one HS-PDSCH (linear)

SNR (dB)

SNR of one HS-PDSCH (dB)

Modulation

TFRC

CQI
UE Cat.
PowerHsPdschAvailable_dBm

Modulation Capability

PowerCpich_dBm

Number of HS-PDSCH available

MPO

max. MAC-hs Payload

DeltaAckNack

Figure 2: TFRC selection algorithm used by the xCEM/ UCU-III

4.2 SCHEDULER TYPES


4.2.1 iCEM
As explained in [R05], the RF cost function noted C1 is based on the following
principles:
X

- Alcatel-Lucent Proportional Fair:


U

costT = .costT-1 + (1 - ).(nb_bits_transmitted / nb_bits_optimum(CQI) )


B

The goal is to favour mobiles that have not been served (nb_bits_transmitted) versus
what they should have been (according to the CQI reported, nb_bits_optimum),
because there was not enough resources (power, codes or processing).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 14/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
- Classical Proportional Fair:
U

costT = CQIavT / CQIinstT with CQIavT = * CQIavT-1 + (1 - ) * CQIinstT


B

The goal is to favour mobiles that report a high CQI versus their averaged CQI to take
benefit from instantaneous good radio conditions vs. average conditions.

Where

is
the
forgetting
factor
(see
the
parameter
hsdpaSchedulerWeightingFactor), nb_bits_transmitted represents the number of
bits actually sent to the mobile (transport block size used), CQIinst is the latest CQI
reported (considered before CQI BLER adjustment).

Parameters:
Parameter
Range & Unit
User
Class
Value

hsdpaSchedulerWeightingFactor
[18] decimal
Customer
3
5

Object

HsdpaConf

Granularity

BTSCell

The selection of any of these scheduler types can be changed on line through a
customer class 3 parameter: hsdpaSchedulerAlgorithm.
Parameter
Range & Unit
User
Class
Value

hsdpaSchedulerAlgorithm
[alcatel-Lucent, proportionalFair] Enum
Customer
3
proportionalFair

Object

HsdpaConf

Granularity

BTSCell

Engineering Recommendation: hsdpaSchedulerAlgorithm


The recommended scheduler is proportionalFair.
Nevertheless, in case of tests with more than 4 users, the recommendation is to use alcatel-Lucent
scheduler since a lower throughput can be observed with 5 simultaneous users and more in a static
environment (No or very low CQI variation leads to high number of PDU discards).

4.2.2 xCEM
[xCEM]
Two schedulers are supported and can be selected through the parameter
hsdpaSchedulerAlgorithmXcem

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 15/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

hsdpaSchedulerAlgorithmXcem
[CRmax, proportionalThroughput] Enum
Customer
3
proportionalThroughput

Object

HsdpaConf

Granularity

BTSCell

Note that these 2 schedulers are the same when the QoS is disabled.
The cost of each priority queue is computed differently with CRmax and
proportionalThroughput:
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for
GBR MAC-d flows when R serviceMinRate
B

CostpropTh = (1/(ServiceBFactor(u,q)*100)) * J(u,q) / CR(u,q) for GBR MAC-d flows


when R < serviceMinRate
B

CostCRmax = SW(u,q) . J(u,q) / CR(u,q) for all MAC-d flow types


B

Where
-

SPIweight is given by the OAM parameter hsdpaSpiRelativeWeight

Scheduling weight SW(u,q) allows to control the scheduling priority for


each user u and queue q according to the measured MAC-d
throughput R. This throughput R is defined as the averaged number
of ACKed MAC-d PDUs times the PDU size divided by TTI duration to
get the bit rate. The scheduling weight can be controlled by the OMC
parameters serviceMinRate, serviceMaxRate, serviceBFactor and
serviceKFactor.
U

Job size J(u,q) represents the average throughput of the priority


queue (this throughput is smoothed, using an exponential filtering, by
the OAM parameter hsdpaSchedulerWeightingFactorXcem for
xCEM or hardcoded value for UCU-III). The job size is calculated by
the MAC-hs internally for each user and queue
U

Channel rate CR(u) is the spectral efficiency (SE) times the number
of available HSDPA codes
U

Note that the cost functions for PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
-

with PropTh, all the relative weights hsdpaSpiRelativeWeight have


to be set with the same value (the value 100 disables totally the SPI
management algorithm) or all the SPI have to be set with the same
value (e.g. 0).

with Crmax, the Scheduling Weight has to be equal to 1 by setting


serviceBFactor to 1

See section 4.3.2 for more details on QoS management for xCEM.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 16/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
[UCU-III]
Three different scheduling modes are offered, and are called CRMax,
Unconstrained and Fair Throughput. CRMax is the default setting, and with this
mode the handling of different traffic classes and scheduling priorities is supported.
The Unconstrained mode as well as the Fair Throughput mode do not take traffic
class into account, i.e. all calls are handled equally as far as the scheduling priorities
are concerned.

The Unconstrained mode assigns the priorities per user in the MAC-hs purely based
on the instantaneous RF conditions. Rate constraints are not taken into account. This
mode yields the highest cell throughput at the expense of reduced user throughput at
cell edge.

The Fair Throughput mode assigns the priorities per user in the MAC-hs based on
the hardcoded minimal and maximal rate constraints of 126 kbps and 130 kbps,
respectively. This means that the priority of a user is increased or decreased if its
measured throughput is below or above the given rate constraints. The minimal and
the maximal rates are not guaranteed. They are only applied to weight the user
priorities according to their measured throughput.

For the scheduling modes Fair Throughput and Unconstrained also service
parameters sets are introduced, which are read only in the OMC-U reflecting the
parameters hard coded in the Node B. No scheduling priority is allocated to them.

4.3 QOS MANAGEMENT


The QoS management is mainly done thanks to the usage of the SPI. The QoS
management depends on the scheduler type and can be applied to the following
schedulers:
-

Alcatel-Lucent Proportional Fair and Classical Proportional Fair


schedulers for iCEM

CRmax and Proportional Throughput for xCEM

CRmax for UCU-III

Engineering Recommendation: Tradeoff between QoS and capacity


The QoS management allows a better Quality Of Service for the users defined with a higher priority
compared to the others users. In order to maximize the cell throughput, the recommendation is to
disable to QoS management in order to avoid that users with high priority will be schedule first even if
experiencing bad RF conditions.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 17/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
4.3.1 iCEM
Basically, with iCem, the QoS management is done by differentiating the users
according to their SPI (the SPI are defined per TC/ARP/THP) and by applying a
relative weight for each SPI. The ratio between the relative weights of two different
SPI gives more or less the ratio of throughput between 2 users characterized by their
SPI assuming they experienced the same RF conditions. This is achieved through
second cost function C2.

This function is based on the priority of the QId, the base credits allocated to this SPI
priority, and the average CQI in order to share the HSDPA radio capacity of the cell
between users so that the throughput of each QId will be proportional :

to the weight of the SPI (see the parameter hsdpaSpiRelativeWeight)

to the transport block size of the averaged CQI reported by the UE

Practically C2 is expressed as the buffer occupancy ratio: C2 = Ncur / Nmax where


Ncur represents the current buffer filling and Nmax represents the buffer size. Anytime
the QId is scheduled, this buffer is filled by a quantity (Ncur is then updated):
-

proportional to the number of transmitted bits,

weighted by a factor that depends on averaged CQI (roughly inversely


proportional to corresponding transport block size defined in CQI
mapping tables).

For example, with two different QIds, the throughput of both QId is such that:
Thpt(QId1)/Thpt(QId2) =
Weight SPI(QId1)/ Weight SPI(QId2) * TBS[CQIav(QId1)] / TBS[CQIav(QId2)]

The base credits assigned per SPI priority (via hsdpaSpiRelativeWeight) provide the
relative weight given per priority. The absolute value is not meaningful, only the ratio
between priorities is important. Example: if base credits of priority queue #4 (resp #3)
is set to 20 (resp 10), a UE in priority queue #4 would be provided around twice
throughput than a UE in priority queue #3 if CQI are equal.

In case all base credits are set to 100, the whole SPI management is deactivated.
Note that in case base credits are equal but with a value different from 100, the
behavior should nevertheless roughly be the same but the SPI management part is
active.

Note that the ratio on throughputs may be subject to a certain tolerance (around 10%)
and will not be respected in case there is no resource limitation for some UEs (to
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 18/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
avoid wasting resources by artificially restraining some UEs while other UEs suffer
very bad radio conditions).

Parameters:
Parameter
Range & Unit
User
Class
Value

Object
hsdpaSpiRelativeWeight
[1..16][1..100] List of Decimal
Customer
Granularity
3
2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32

HsdpaConf
BTSCell

Engineering Recommendation: hsdpaSpiRelativeWeight


The recommendation in order to maximize the HSDPA cell throughput is to disable the QoS
management by setting the hsdpaSpiRelativeWeight to [100 100].

The setting of SPI (common for iCem and xCem) is done in RNC /
RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos:
Parameter
Range & Unit
User
Class
Value

Spi
[0..15]
Customer
3
Depends on customer strategy

Object

ThpBasedQos

Granularity

RNC

To disable the QoS, all the relative weights hsdpaSpiRelativeWeight have to be set
with the same value (the value 100 disables totally the SPI management algorithm) or
all the spi have to be set with the same value (e.g. 0).

Note :
[iCEM] [xCEM] Supports differentiation on all 16 SPI
[UCU-III] Supports QOS differentiation only on 7 different priorities. In deployments
with UCU-III, the RNC mapping of QOS to SPI will use a more restricted set of SPI.

GBR Handling:
U

In the presence of GBR MAC-d flows, these flows will be served first as long as their
GBR is not satisfied (irrespective of their SPI), even if the throughput of non GBR
MAC-d flows (and even with higher SPI) must be reduced down to 0 kbps.

To determine if a GBR MAC-d flow has reached its GBR or not, MAC-hs continuously
monitors the average throughput of the flow (using an exponential filtering based on
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi parameter). This averaging is

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 19/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
needed since the GBR has to be shown to hold over long-term (hundreds of ms to
seconds) compared to the 2ms TTI.
When several GBR MAC-d flows are below their GBR, they are ranked by decreasing
priorities (or SPI). For each GBR MAC-d flow, MAC-hs scheduler evaluates total radio
capacity and how much of the total radio capacity it shall allocate to this flow to
guarantee its GBR. These evaluations are smoothed by OMC-B parameters
hsdpaGbrNbUePerTtiForgettingFactor
and
hsdpaGbrNbNeededTtiForgettingFactor respectively.
For a given priority, if the radio capacity - according to above evaluation - is enough to
satisfy all GBR flows then the flows are ranked by decreasing deficit (difference
between actual throughput and GBR). If the radio capacity is not enough then the
flows are ranked by increasing deficit in order to guarantee the GBR of most flows
(moreover, GBR flows for which it is absolutely not possible to guarantee their GBR
even by allocating them all resources are put at the end of the list of GBR flows).

Parameters:
U

Parameter
Range & Unit
User
Class
Value

hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi
[1..16][1..11] List of Decimal
Customer
3
[8, .., 8] (default value)

Parameter
Range & Unit
User
Class
Value

hsdpaGbrNbUePerTtiForgettingFactor
[1..11] Decimal
Customer
3
8 (default value)

Parameter
Range & Unit
User
Class
Value

hsdpaGbrNbNeededTtiForgettingFactor
[1..11] Decimal
Customer
3
8 (default value)

Object

HsdpaConf

Granularity

BTSCell

Object

HsdpaConf

Granularity

BTSCell

Object

HsdpaConf

Granularity

BTSCell

Note that the parameter HsdpaGbrIncreaseFactorForMobility in HsdpaConf is not


used in UA6.0.

4.3.2 xCEM
The two xCEM schedulers manage the QoS differently:
-

With proportionalThroughput: a relative weight is applied on each SPI


via hsdpaSpiRelativeWeight (same parameter as with iCEM) so that
the throughputs of the different non GBR MAC-d flows, when they are
experiencing the same radio conditions, are proportional to their

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 20/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
respective SPI weights. For GBR flows measured throughput R is
compared with the following threshold per SPI and then appropriate
user ranking is applied as per section 4.2.2, which includes the use of
serviceBFactor again defined per SPI
X

serviceMinRate = MAC-hs GBR - serviceLowRate


-

With CRmax: for a given SPI, priority of the queue is increased (or
decreases) by multiplying the cost function by a Scheduling Weight
(SW) if the MAC-d throughput R is lower (or higher) than the
parameter serviceMinRate (or serviceMaxRate). The parameters
serviceBFactor and serviceKFactor are shaping factors for
increasing and decreasing the priorities:

the larger the values for serviceBFactor and serviceKFactor


the more the priority is decreased or increased, if the
measured average throughput R falls below serviceMinRate
or exceeds serviceMaxRate.

if serviceBFactor is set to one serviceMinRate and


serviceMaxRate are not taken into account. In this case the
priority of a user is neither decreased nor increased.

The Scheduling weight is computed as follow:


SW(u,q) = serviceBFactor
P

Where the term w depends on whether the measured MAC-d throughput R is lower or
higher than serviceMinRate:
If R serviceMinRate:

R serviceMinRate

serviceMaxRate serviceMinRate

serviceKFactor

If R < serviceMinRate:

serviceMinRate R

serviceMaxRate serviceMinRate

1 / serviceKFactor

For GBR MAC-d flows, with CRmax algorithm, serviceMinRate and serviceMaxRate
are not taken from OMC-B but fixed by MAC-hs according to MAC-hs GBR (NBAP)
with margins coming from OMC-B:

serviceMinRate = MAC-hsGBR - serviceLowRate and


serviceMaxRate = MAC-hs GBR + serviceHighRate

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 21/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The following figures give an example of the Scheduling Weight SW used by the
Crmax scheduler for different values of serviceBFactor and serviceKFactor and
according to the current throughput:
Priority W eighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7

B = 5, K = 7

B = 3, K = 7

B = 1, K = 7

7
6

Priority

5
4
3
2
1
0
20

30

40

50

60

70

80

Data Rate [kbps]

Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)


K_factor=7
1000

Scheduling Weight (log)

100

B=7

10

B=5
B=3
1
0

10

20

30

40

50

60

70

80

B=1

0,1

0,01
Data Rate (kbps)

Figure 3 : Example of Scheduling Weight for different value of serviceBFactor

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 22/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Priority W eighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7

B = 7, K = 5

B = 7, K = 3

B = 7, K = 1

7
6

Priority

5
4
3
2
1
0
20

30

40

50

60

70

80

Data Rate [kbps]

Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)


B_factor=7
1000

Scheduling Weight (log)

100

K=7

10

K=5
K=3
1
0

10

20

30

40

50

60

70

80

K=1

0,1

0,01
Data Rate (kbps)

Figure 4: Example of Scheduling Weight for different value of serviceKFactor

When the throughput of a user is lower than the serviceMinRate (Rmin), its priority is
increased.
When the throughput of a user is higher than the serviceMaxRate (Rmax), its priority
is decreased.
The higher the serviceBFactor or serviceKFactor are, the higher the Scheduling
Weight is.
Note that when the serviceBFactor is set to 1, the Scheduling Weight is equal to 1,
meaning that all the users have the same priority (no QoS).
Contrary to the PropTh (xCem) or PropFair (iCem) schedulers, Crmax scheduler can
apply different Scheduling Weight even if all the spi have the same value. If only one
SPI is defined, all the users will use the same value for serviceMinRate,
serviceMaxRate, serviceKFactor, serviceBFactor but the SW will depend on the
current throughput.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 23/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The throughput of each MAC-d flow (R as described previously) is monitored
permanently and is averaged using an exponential average whose forgetting factor is
determined by:
-

for xCEM: 1/(2^(serviceFilterFactor))

for UCU III: set to 0.001 for GBR and 0.005 for non GBR flows

The parameters used by the schedulers are the following ones:

Parameter
Range & Unit
User
Class
Value

hsdpaSchedulerWeightingFactorXcem
[18] decimal
Customer
0
8

Parameter
Range & Unit
User
Class
Value

serviceBFactor
[130] decimal
Customer
3
7 (default value)

Object

HsdpaConf

Granularity

BTSCell

Object

HsdschServiceParameterSet

Granularity

BTSCell

Engineering Recommendation: serviceBFactor


The recommendation in order to maximize the HSDPA cell throughput is to disable the QoS
management by setting the serviceBFactor to 1 and hsdpaSpiRelativeWeight to 100 for all SPI.

Parameter
Range & Unit
User
Class
Value

serviceKFactor
[130] decimal
Customer
3
7 (default value)

Object

HsdschServiceParameterSet

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

serviceMaxRate
[010000] decimal kb/s
Customer
3
120 (default value)

Object

HsdschServiceParameterSet

Granularity

BTSCell

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 24/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

serviceMinRate
[010000] decimal kb/s
Customer
3
40 (default value)

Object

HsdschServiceParameterSet

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

Object
serviceHighRate
[010000] decimal kb/s
Customer
Granularity
3
80 for PS Streaming and 300 for PS I/B

HsdschServiceParameterSet
BTSCell

Engineering Recommendation: serviceHighRate


Concerning the parameter serviceHighRate, the recommendation is to set a medium value (80kb/s)
for all GBR flows. This recommendation allows to guarantee a tighter control of the throughput around
the Ranap GBR for Streaming traffic class (SPI = 15 .. 13) and PS I/B traffic class with minimum bit
rate constraint (SPI = 11 .. 4) while at the same time allowing the resources to be distributed efficiently
between simultaneous active users
To summarize:
serviceHighRate = 80kb/s for PS Streaming and 300kb/s for PS I/B

Parameter
Range & Unit
User
Class
Value

serviceLowRate
[010000] decimal kb/s
Customer
3
0 (default value)

Object

HsdschServiceParameterSet

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

serviceFilterFactor
[111] decimal
Customer
3
8 (default value)

Object

HsdschServiceParameterSet

Granularity

BTSCell

The parameters in the object HsdschServiceParameterSet allow defining the priority


of only one SPI. 16 instances of HsdschServiceParameterSet have been created.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 25/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UA5.1-UA6.0 : schedulingPriorityLevel
In UA5.1, only 6 HsdschServiceParameterSet have been defined. So, the mapping between SPI and
HsdschServiceParameterSet was done thanks to the parameter schedulingPriorityLevel (in
HsdschServiceParameterSet).
In UA6.0, 16 HsdschServiceParameterSet have been defined (one per SPI). So, the parameter
schedulingPriorityLevel does not exist in UA6.0 since it is not useful anymore

UCU III handling:


U

Engineering Recommendation:
UCU III : supports QOS differentiation only on 7 different priorities. In deployments with UCU III, the RNC
mapping of QOS to SPI will use a more restricted set of SPI. HSDPA Service Parameter Set Instances for
these 7 different priorities are 1-7 : Table HS-DSCH Service Parameter Sets Instances:
U

Parent Object

HsdschServiceParameterSet

Instance Name

HSDSCHServiceParameterSet1

HsdschServiceParameterSet

HSDSCHServiceParameterSet2

HsdschServiceParameterSet

HSDSCHServiceParameterSet3

Default [Unit]
SchedulingPriorityLevel
= 15
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 14
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 13
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]

Remark

Parameter set
for scheduling
priority 15.
Can be
configured at
OMC

Parameter set
for scheduling
priority 14.
Can be
configured at
OMC

Parameter set
for scheduling
priority 13.
Can be
configured at
OMC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 26/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

HsdschServiceParameterSet

HsdschServiceParameterSet

HSDSCHServiceParameterSet4

HSDSCHServiceParameterSet5

HsdschServiceParameterSet

HSDSCHServiceParameterSet6

HsdschServiceParameterSet

HSDSCHServiceParameterSet7

ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 12
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 11
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7

Parameter set
for scheduling
priority 12.
Can be
configured at
OMC

Parameter set
for scheduling
priority 11.
Can be
configured at
OMC

Parameter set
for scheduling
priority 10.
Can be
configured at
OMC

Parameter set
for scheduling
priority 9. Can
be configured
at OMC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 27/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

HsdschServiceParameterSet

HSDSCHServiceParameterSetUc

ServiceKFactor = 7
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 1000
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 1

Parameter set
for scheduling
priority 10.
Can not be
configured at
OMC

ServiceKFactor = 1

HsdschServiceParameterSet

HSDSCHServiceParameterSetFt

ServiceMinRate = 126
[kbps]
ServiceMaxRate = 130
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 5

Parameter set
for scheduling
priority 10.
Can not be
configured at
OMC

ServiceKFactor = 13

Note : Scheduling modes Fair Throughput and Unconstrained also service parameters sets are
introduced, which are read only in the OMC-U reflecting the parameters hard coded in the UCU III .

4.4 UE CATEGORY MANAGEMENT


4.4.1 iCEM
UE categories also add some bias in the way virtual buffer are filled, described above.
The
impact
depends
on
the
value
of
the
OMC-B
parameter
hsdpaUeCategoryThroughputWeighting. It defines the way balance is performed
between different categories when one of them is limited by the transport block size.
Indeed, above CQI 15 for instance, the transport block size of a UE cat 12 remains
constant while for other categories (e.g. 6 or 10) their transport block size still
increases with the CQI.
Two behaviours are then defined according to the value of the parameter:

ueCategoryEquity: UE categories will reach the same throughput in average


at the same CQI. For instance at CQI 21, a UE cat 12 and 6 will get the same
throughput even if instantaneously, the UE cat 6 will benefit from higher
transport block size. UE cat 12 will then be scheduled more often to
compensate this.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 28/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

ueCategoryProportionality: UEs throughput will depend on their category.


Their throughput ratio will then be proportional to the ratio of transport block
size of corresponding CQI (when UEs have the same CQI). For instance, at
CQI 21 a UE cat 6 will roughly have twice the throughput of a UE category 12
(6554/3319 = 1.97), even though they are scheduled as often. Note that below
CQI 15, their throughput remains equal.

When hsdpaUeCategoryThroughputWeighting equals ueCategoryProportionality,


the TBS(CQI) is the mapping table CQITBS of the category of the UE. When it
equals ueCategoryEquity, the same table is used for all UE categories (i.e. the one of
category 12).

It must be noted that this parameter is only applicable when SPI management is
activated. Hence, it is disabled in case of all hsdpaSpiRelativeWeights [SPI] are
equal to 100.

Parameter
Range & Unit
User
Class
Value

hsdpaUeCategoryThroughputWeighting Object
[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
3
ueCategoryProportionality

HsdpaConf
BTSCell

4.4.2 xCEM
xCEM scheduler is able to balance throughput between different UE categories when
one of them is limited by the transport block size. The principle is the same as with
iCEM (see section 4.4.1 for more details), only the parameter name changes:
X

Parameter
Range & Unit
User
Class
Value

hsdpaUeCategoryThroughputWeightingXcem Object
[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
0
ueCategoryProportionality

HsdpaConf
BTSCell

4.5 HSDPA USER SCHEDULING


4.5.1 iCEM
Every TTI, the scheduler is launched in order to efficiently assign the available
resources (number of codes and remaining power) to the different users.

The first step consists in managing the retransmissions. The NACKed blocks are
scheduled first, in a FIFO order when possible (in case the UE capabilities prevent
from receiving data in the corresponding TTI, it is not retransmitted in that TTI). Then,
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 29/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
once retransmissions are handled, the remaining number of codes and power are
computed and constitute the input of the next step.

When there is no more retransmission to send, the scheduler selects the suitable QId
(according the cost function) for a user transmitting packet for the first time. This
selection is repeated as long as some resources remain (codes, power and CPU) and
if data can be scheduled for the corresponding TTI.

A user can only be considered as candidate if it is allowed to receive some data in the
current TTI, i.e. if several criteria are respected (CQIprocessed 0, min inter TTI distance,
AckNack repetition factor, one HARQ process available, UE not already scheduled for
retransmissions).
B

For each candidate user, HS-SCCH power is determined (see Power Management
section) and power checking is done on both the current TTI and the previous one
(HS-SCCH and corresponding HS-PDSCH only overlap by 1 slot). If there is not
enough power to transmit the HS-SCCH in the current TTI, the user is not selected.
X

Then for the UE with the lowest cost within the remaining candidates UEs, the number
of PDU to transmit as well as the number of codes and the transmitted power are
chosen according to the processed CQI in order to fit as well as possible to what the
UE can correctly receive (see Power Management section for more details on the
algorithm):
X

If there doesnt remain enough power to transmit the HS-PDSCH, another


configuration requiring less power is selected if possible (transport block size
reduced, corresponding to a smaller CQI referred as CQIapplied in Section 8
Power Management.
B

If there doesnt remain enough codes to transmit the HS-PDSCH, the


configuration is changed (transport block size reduced, corresponding to a
smaller CQI) to use the remaining codes. The power is then updated
accordingly.

4.5.2 xCEM
Before selecting the UEs to be scheduled in the TTI, the scheduler computes the
transmit power of the HS-SCCH for each user in the ranking list. It will remove from
the list all the UEs which cannot be scheduled because their HS-SCCH transmit
power is higher than the available power.

With iCEM, retransmissions are always transmitted before first transmissions.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 30/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
With xCEM, retransmissions are transmitted before first transmission only for different
HARQ processes of a given priority queue. Between two different priority queues
(between two different users), retransmissions have no priority over first transmissions
anymore. The aim is to maximize the cell throughput.

5 TFRC MANAGEMENT
5.1 MAC-D PDU SIZE MANAGEMENT
336 bits configuration might limit the throughput (especially for high UE category like
Cat.8 and above) due to UE processing capabilities (too many PDU/s to handle) or
due to RLC stalling (RLC window size is limited to 2047 PDU) in case of a too high
round-trip delay. So, a MAC-d PDU of 656 bits (maximum number of MAC-d PDU is
21 for 656 bits MAC-d PDU size and 42 for 336 bits for Cat.8) allows higher user
throughput.

Rule: Maximum HSDPA user throughput


The maximum HSDPA user throughput is limited either by UE processing capabilities (too many
PDU/s to handle) or by RLC window blocking (RLC window size being limited to 2047 MAC-d PDU)
-

when STATUS frequency from UE is too low to acknowledge the RLC window. STATUS
frequency is limited by the parameter prohibitedStatusTimer (minimum time in ms
between STATUS reports).

when RLC Round Trip Time is too high

Basically, maximum HSDPA user throughput can be evaluate to around :


Max HSDPA user throughput @ RLC=
RLC window size * (MAC-d PDU size MAC-d header) / (RLC Round Trip Time +
prohibitedStatusTimer)
Then maximum theorical HSDPA user throughput is around 5Mb/s for 336 bits or 10Mb/s for 656 bits
MAC-d PDU size (RLC window size = 2047 PDU, MAC-d header = 16 bits, RLC RTT = 60ms,
prohibitedStatusTimer = 70ms).

Decrease in the prohibitedStatusTimer leads to increase in the uplink Status traffic. The interest of
the 656 bits configuration is to allow reaching very high throughputs (6 Mbps and more) with moderate
uplink Status traffic.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 31/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: prohibitedStatusTimer and PollingTimer
Engineering recommendation is to set prohibitedStatusTimer to 30ms and PollingTimer to 150ms
(no real impact of the pollingTimer value on throughput).
Note that these parameters are located in :
RadioAccessService / RlcConfClass / PS_HSDSCH_EDCH_IB_AM / DlRlcAckMode

Engineering Recommendation: Maximum HSDPA throughput


In order to have high DL throughput, UL acknowledgements have to be sent very quickly. Thats why
DL HSDPA E2E throughput may be limited when some UL BLER peaks appear that lead to have
some bursts of DL data (may be seen with 336 or 656 bits). Solution is to have a low UL BLER by
- using HSUPA in UL with low BLER target
- or increasing minSirTarget of UL R99 RAB
Manual increase of the value of the minSirTarget parameter associated to a given UL service is a
solution that may only be used for demos. Indeed in past releases, such a modification affected all the
calls using the considered UL service, i.e. minSirTarget was increased even when HSDPA was not
used in the downlink!
Since UA6.0, a sub-feature of UA6 34246 Power Control Enhancements allows improving UL radio
quality for calls with HSDPA high data rate in the downlink, thus avoiding the issue of bursts of
application-level UL ACKs, which improves DL throughput and user experience.
Moreover, the following requirements are needed to reach maximum FTP throughput (with UE Cat.9
of 8.5Mbps or with UE Cat.10 of 10.8Mbps):
-

MAC-d PDU size = 656 bits

1 dedicated H-BBU per HSDPA cell

At least 6 E1 (Iub/Iur) for UE Cat.9 or 8 E1 for UE Cat.10 (Hybrid Iub is recommended to


avoid potential IUB limitations) in mono-user case and Core Network has to be
dimensioned to support data bursts with Iu-PS BW of 100Mbps or 10Mbps with Iu policing

UL service: HSUPA

UL MAC-e BLER measured ~ 0%

TCP/RLC setting :

RWIN (TCP window) = 146kB

DlRlcQueueSize = 128 RLC SDU for Cat.9 or 256 for Cat.10 (Note that the value
used by the RNC is 2 times the value datafilled. For example, in order to used 256 for
Cat.10, the datafilled value should be 128)

prohibitedStatusTimer = 30ms (could be reduced to 10 ms for Cat.10 demo purpose)

Socket Buffer Size = 200KBytes (Server configuration)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 32/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The feature 29799 MAC-d PDU size Management for HSDPA consists in choosing
the MAC-d PDU size according to several parameters:
-

eligibleUeCategoryForHighPerformance to define the UE categories eligible for


656 bits.

minimumUserMbrForHighPerformance to configure 656 bits if MBR (RANAP


Maximum BitRate) value is above this parameter.

isHsdpaCellHighPerformance to restrict primary cell to 336 bits.

Moreover isDynamicMacdPduSizeManagementAllowed flag allows activating or


deactivating the feature at RNC level.

UA5.1-UA6.0 Delta: MAC-d PDU size management


In UA5.1, the flag to restrict primary cell to 336 bits was MaxCellRadius (but since UA6.0 it has been
change to isHsdpaCellHighPerformance).
Basically, in UA5.1, the MAC-d PDU size does not change during the call whatever the configuration of
the primary cell. The difference between UA5.1 and UA6.0 is the possibility to reconfigure the MAC-d
PDU size during the call. This reconfiguration is allowed in UA6.0 if the flag
isHighPerformancePduSizeReconfAllowed is set to True.

Reconfiguration of the MAC-d PDU size is allowed in UA6.0 if the flag


isHighPerformancePduSizeReconfAllowed is set to True.

656 bits MAC-d PDU size has to be used at least for UE categories allowing high user
throughput, that is to say UE Cat.7, 8, 9 and 10.
Parameter
Range & Unit
User
Class
Value

HsdpaRncConf
eligibleUeCategoryForHighPerformance Object
BitString 64 bits (0=not eligible, 1=eligible)
Customer
Granularity
RNC
3
0000000000000000000000000000000000000000000000000000001111000000

Engineering Recommendation: eligibleUeCategoryForHighPerformance


This parameter defines the eligible HSDPA UE Categories for MAC-d PDU size of 656 bits. Bit 0
corresponds to category 1 and bit 63 to category 64. Bit value 0/1: 0=not eligible, 1=eligible.
Having defined bit #0 as the LSB (least significant bit) i.e. the bit at the right edge of the bit string, then
in order to have categories 7; 8; 9 and 10 eligible to 656 bits, bits #6 to #9 must be set to 1.
Due to IOT issues with some UEs, it is not recommended to allow the MAC-d PDU size of 656 bits for
UE Categories 12 and 6.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 33/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

minimumUserMbrForHighPerformance
Integer [0.. 16 000 000] bit/s
Customer
3
0 (customer dependant)

Object

HsdpaRncConf

Granularity

RNC

Engineering Recommendation: minimumUserMbrForHighPerformance


This parameter depends on operator strategy. Set this parameter to 0 bit/s allows to not take into
account this parameter during the MAC-d PDU size selection.

Parameter
Range & Unit
User
Class
Value

Parameter
Range &
Unit
User
Class
Value

isHsdpaCellHighPerformance
Boolean {True; False}
Customer
3
True

isDynamicMacdPduSizeManagementAllowed
Boolean
{True, False}
Customer
3
True

Object

FDDCell

Granularity

Cell

Object

RadioAccessService

Granularity

RNC

Restriction: 656 bits feature activation


-

All Node B should be upgraded to at least UA05.1 prior to the RNC activation
(isDynamicMacdPduSizeManagementAllowed).

656 bits PDU can be used only


(isMultiRabOnHsdpaAllowed = True).

if

29797

(multi-service

on

HSDPA)

is

enabled

Rule: UE capabilies and 656 bits feature activation


In order to have a correct behavior, when the 656 bits feature is enabled
(isDynamicMacdPduSizeManagementAllowed = TRUE), recommendation is to set the two following
parameters to True:

isUeCapabilitiesInRabMatchingAllowed = TRUE

isUeCapabilitiesInRabMatchingAllowedForPhyAndRlc = TRUE

See [R01] for more details.


X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 34/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

HsdpaRncConf
isHighPerformancePduSizeReconfAllowed Object
BitString 64 bits (0=not eligible, 1=eligible), one bit per UE Categorie (Cat. 1 on the
right)
Customer
Granularity
RNC
3
0000000000000000000000000000000000000000000000000000001111000000
True

UA5.1-UA6.0 Delta: Mac-d PDU size reconfiguration


The behavior of this feature is the same in UA5.1 and UA6.0 if the flag
isHighPerformancePduSizeReconfAllowed is set to False except concerning mixity (a 2nd RAB has
the same Mac-d PDU size that the 1st one in UA5.1 whereas in UA6.0, the Mac-d PDU size of a 2nd
RAB can be different)
P

The following flowchart summarizes the parameters configuration:

isDynamicMacdPduSizeManagementAllowed
True
eligibleUeCategoryForHighPerformance
1
minimumUserMbrForHighPerformance
< MBR
isHsdpaCellHighPerformance

False
0
> MBR
False

True

336 bits is used on RNC


336 bits is used for Cat.n
336 bits is used for this ue
336 bits is used at RB setup
for this cell

656bits is used at RB setup


for this cell
isHighPerformancePduSizeReconfAllowed
1
PDU size reconf. is allowed

PDU size reconf. is not allowed


(except in some special cases)
sduRetransmitAfterPduSizeChange

Figure 5: Parameters to configure the feature MAC-d PDU size 656 bits

MAC-d PDU selection: The MAC-d PDU size is chosen when an HS-DSCH MAC-d
flow is setup that is to say at RAB establishment or reconfiguration of the RB to HSDSCH. In UA05.1 (or in UA6.0 with reconfiguration disabled), if a second HS-DSCH
Mac-d flow is setup then it will use the same MAC-d PDU size than the first one (even
if its MBR would have lead to use a different size). In UA6.0 with reconfiguration
enabled, a second HS-DSCH Mac-d flow can use a Mac-d PDU size different from the
1st one.
U

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 35/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HSDPA-HSDPA Mobility: In case of HSDPA-HSDPA mobility (intra or inter-frequency),
the MAC-d PDU size can be reconfigured according to configuration of new cell if the
reconfiguration is enabled (isHighPerformancePduSizeReconfAllowed = True).
U

Mobility over Iur: The cell of DRNC is considered as 336 bits capable. In case of
mobility over Iur (HS-DSCH cell change towards a DRNS), the MAC-d PDU size of the
HS-DSCH MAC-d flow is not reconfigured if the reconfiguration is disabled
(isHighPerformancePduSizeReconfAllowed = False) : if the call was using the 336 bits
(or 656 bits), it will continue to use 336 bits (or 656 bits) after the mobility over Iur.
U

If the DRNS does not support the 656 bits configuration it will refuse the mobility of a
656 bits MAC-d flow thus leading to a DCH fallback of the RB by the SRNC (HSxPA
to DCH fallback feature has to be enabled).
If the reconfiguration is enabled (isHighPerformancePduSizeReconfAllowed =
True), the MAC-d PDU size can be reconfigured if necessary (e.g. MAC-d PDU size of
the new cell is different from the current MAC-d PDU size). When the SRNC has to
setup an HS-DSCH MAC-d flow over Iur, it configures it using 336 bits. For more
information on mobility over Iur, see [Vol. 6].
X

MAC-d PDU size reconfiguration: MAC-d PDU size reconfiguration may also happen
during transport channel type switching that is to say during HSDPA-R99 mobility or
AO transition. One exception is when this channel switching is due to a RAB
establishment (like a CS RAB or a second PS RAB where a first PS RAB was on
Cell_FACH due to inactivity). In this case, the configuration use for the PS RAB on
HS-DSCH is 336 bits. When reconfiguration is triggered, SDU can be managed in
different ways according to the parameters sduRetransmitAfterPduSizeChange (in
RadioAccessService / RlcConfClass / DlRlcAckMode). This parameter configures the
resegmentation upon RLC reconfiguration with MAC-d PDU size change. Following
values are possible:
U

None: all already received SDUs shall be discarded

NotTransmitted: only the not transmitted SDUs shall be re-segmented with


new RLC PDU size and transmitted. The others are discarded.

NotFullyTransmitted: SDUs that were partially transmitted shall be segmented


with new RLC PDU size and retransmitted.

NotFullyAcknowledged: SDUs that were not fully acknowledged, between the


time the DBearerModificationReq with RLC PDU size change message is
received in UPlane, until the new configuration is activated, are re-segmented
with new RLC PDU size and retransmitted

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 36/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UA5.x-UA6.0 Delta: sduRetransmitAfterPduSizeChange
This parameter is introduced in UA6.0. In UA5.1 the behaviour corresponds to NotTransmitted
(During a MAC-d PDU size reconfiguration, all RLC SDUs that were under transmission, meaning they
were already segmented and not yet acknowledged by UE, were discarded by the RNC thus relying on
TCP layer retransmissions).

Parameter
Range & Unit
User
Class
Value

Object
DlRlcAckMode
sduRetransmitAfterPduSizeChange
[none, notTransmitted, notFullyTransmitted, notFullyAcknowledged] Enum
Customer
Granularity
RlcConfClass
3
notFullyAcknowledged
UE capabilities handling: Along with 34340 (and according to the flag
isDynamicMacdPduSizeManagementAllowed), when a MAC-d flow is setup for an
3GPP R5 UE, the RNC will configure an RLC window size that fits into the UE
memory (totalRLC-AM-BufferSize IE in RLC-Capability and RLC-Capability-r5-ext UE
capabilities).
If
the
RLC
window
size
configured
at
OMC
(TransmissionWindowsSize) is too big for the UE, the RNC recomputes the RLC
window size to match with UE memory constraints ([R03]).
U

For 3GPP R5 UE, in case of PS RAB establishment when there are other PS RABs
established, if the UE has not enough memory to cope with the nominal (OAM) RLC
window sizes the RNC will trigger a standalone RLC reconfiguration (after the RRC
RB SETUP or RRC RB RELEASE) to rebalance the RLC windows.
With Streaming traffic, the RNC will always ensure that the RB is configured with a
minimum window size to be able to reach the GBR. This minimum equals
GBR*(RTD+RLC TimerStatusProhibit)/MAC-d PDU size where RTD=100 ms
hardcoded.

Note that a PDU size of 656 bits is always used for a Streaming MAC-d flow.

5.2 656 PDU QUALCOMM UE BUG WORKAROUND


In summary, this feature allows the activation of a workaround for a Qualcomm chipset
bug which occurs when UE transitions from URA_PCH/Cell_FACH to Cell_DCH and
at the same time the PDU size is reconfigured to 656 bits.
There is a bug on some Qualcomm E-DCH R6 UEs in relation to 656 PDU. If the UE
goes into URA_PCH state and then out again via FACH to DCH, the E-DCH
throughput is throttled to around 100kbps.
It is related to combined RLC reconfiguration and PDU size change during FACH to
DCH transition. UE does not apply the DCH parameters for UL RLC hence reducing
the UL throughput.
In general, any RRC Radio Bearer Reconfiguration which concurrently changes the
UL RLC parameters and DL PDU size to 656 bits will cause the problem.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 37/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The solution is to send a second RRC Radio Bearer Reconfiguration message with
just the UL RLC changes to a HSDPA category 8 E-DCH capable UE. Note that it
does not happen if 336 PDU size is used on DL or if the UE doesnt transition to
URA_PCH i.e. DCH -> FACH->DCH doesnt invoke the bug.
Following diagram shows all the conditions (in red) that need to be satisfied for the
PM79164 workaround to be invoked.

Figure 6: Conditions to invoke the feature 79164


The following existing Boolean has been re-used as the activation flag for this feature.
Parameter

IsRlcReconfigAllowedForR99

Range & Unit


User
Class
Value

True, False
Customer
3
True

Object

RadioAccessService

Granularity

RNC

5.3 TRANSPORT BLOCK SIZE OPTIMIZATION


When a UE is scheduled, the applied MCS (transport block size, number of codes,
modulation and reference power) depends on the reported CQI. Correspondence
between both is defined in CQI mapping tables.
In most cases, these defined transport block sizes lead to a high number of padding
bits with the MAC-d PDU sizes used (336 or 656 bits).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 38/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Mac-hs PDU = 1TTI
Mac-hs SDU
RLC SDU

21

320

Mac-d SDU = Mac-d PDU

16

320

16

320

16

Padding

Figure 7: Padding bits in the MAC-hs PDU

The purpose of the feature HSDPA performance enhancement Optimization of


transport block sizes (iCEM only) is then to define new CQI mapping tables,
depending on the MAC-d PDU size. These are provided in Table 1 and Table 2.
X

These new tables are activated via the following class 3 OMC-B parameters:
Parameter
Range &
Unit
User
Class
Value

Object

ueCategoryX
X = [1..12]
True, False

Customer
Granularity
3
True for all UE categories

HsdpaUeCategoryTransportBlockOptimisation

BTSCell

Engineering Recommendation: Transport Block Size Optimisation activation


Activation of TBS optimization is highly recommended over the whole RNC and for all the UE
categories.

Note that such activation is independent per UE category and only part of them can
then be optimized.
UE Category support
The mapping between CQI and Transport Block Size depends on the UE category.
The following tables summarize this mapping for MAC-d PDU size equal to 336 and
656 bits (iCEM only):
Mac-d PDU size = 336 bits
Number
Number
Applicable
of
of
for
Modulation
Power offset
HSMAC-d
UE
PDSCH
Default Optimised Max capability PDU
category
codes
377
365
1
QPSK
1
+4 dB
1 12
377
365
1
QPSK
1
+3 dB
1 12
377
365
1
QPSK
1
+2 dB
1 12
377
365
1
QPSK
1
+1 dB
1 12
377
365
1
QPSK
1
0dB
1 12
377
365
1
QPSK
1
-1 dB
1 12
377
365
1
QPSK
2
-2 dB
1 12
Transport Block Size

CQI

1
2
3
4
5
6
7

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 39/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8
9
10
11
12
13
14
15
16 - 30
16
17
18
19
20
21
22
23 - 30
23
24
25
26 - 30
26
27 - 30
27 - 30
27 - 30

792
792
1262
1483
1742
2279
2583
3319
3440
3565
4189
4664
5287
5887
6554
7168
7168
9719
11418
14411
14411
17237
17237

699
699
1036
1380
1711
2046
2404
3090
3440
3440
4115
4420
5101
5782
6438
7168
7168
9546
11216
14155
14155
17237
17237

21754

21754

20251

2
2
3
4
5
6
7
9
10
10
12
13
15
17
19
21
21
28
33
42
42
51
51
60
64

QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM

2
2
3
3
3
4
4
5
5
5
5
5
5
5
5
5
5
7
8
10
10
12
12
15
15

0dB
-1 dB
0dB
0dB
0dB
0dB
0dB
0dB
16 - CQI
0dB
0dB
0dB
0dB
0dB
0dB
0dB
22 - CQI
0dB
0dB
0dB
25 - CQI
0dB
26 - CQI
27 - CQI
27 - CQI

1 12
1 12
1 12
1 12
1 12
1 12
1 12
1 12
11 12
1 10
1 10
1 10
1 10
1 10
1 10
1 10
16
7 10
7 10
7 10
78
9 10
9
9
10

Table 1: CQI mapping table for 336 bits MAC-d PDU size

Mac-d PDU size = 656 bits


Number
Number
Applicable
of
of
for
Modulation
Power offset
HSUE
Default Optimised Max capability MAC-d
PDSCH
PDU
category
codes
792
686
1
QPSK
2
+7dB
1 - 12
792
686
1
QPSK
2
+6dB
1 - 12
792
686
1
QPSK
2
+5dB
1 - 12
792
686
1
QPSK
2
+4dB
1 - 12
792
686
1
QPSK
2
+3dB
1 - 12
792
686
1
QPSK
2
+2dB
1 - 12
792
686
1
QPSK
2
+1dB
1 - 12
792
686
1
QPSK
2
0dB
1 - 12
792
686
1
QPSK
2
-1dB
1 - 12
792
686
1
QPSK
3
-2dB
1 - 12
1483
1356
2
QPSK
3
0dB
1 - 12
1742
1356
2
QPSK
3
-1dB
1 - 12
2279
2010
3
QPSK
4
0dB
1 - 12
2279
4
QPSK
4
-1dB
1 - 12
2677
4
QPSK
4
0dB
1 - 12
3319
3319
5
QPSK
5
0dB
1 - 12
3319
3319
5
QPSK
5
-1dB
1 - 12
Transport Block Size

CQI

1
2
3
4
5
6
7
8
9
10
11
12
13
14
14
15
16

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 40/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
17 - 30
17
18
19
20
21
22
23 - 30
23 - 30
23
24
25
26 - 30
26
27 - 30
27 - 30
27 - 30

3319
4189
4664
5287
5287
6554
7168
7168

3319
3970
4664
5287
5287
5993
6673
6673

9719
11418
14411
14411
17237
17237

9210
11216
13904
13904
17237
17237

21754

21754

7298

20251

5
6
7
8
8
9
10
10
11
14
17
21
21
26
26
30
33

QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM

5
5
5
5
5
5
5
5
5
7
8
10
10
12
12
15
15

15 - CQI
0dB
0dB
0dB
-1dB
0dB
0dB
22 - CQI
23 - CQI
0dB
0dB
0dB
25 - CQI
0dB
26 - CQI
27 - CQI
27 - CQI

11 - 12
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1-6
1-6
7 - 10
7 - 10
7 - 10
7-8
9 - 10
9
9
10

Table 2: CQI mapping table for 656 bits MAC-d PDU size

Note that with MAC-d PDU size = 656 bits, the minimum number of HS-PDSCH codes
that can be managed is 2 if the feature Flexible Modulation (see section 5.4) is
disabled. If Flexible Modulation is enabled, even 1 HS-PDSCH code can be managed
with a MAC-d PDU of 656 bits.
X

Based on Figure 7: Padding bits in the MAC-hs PDU, the throughput can be computed
at different levels from the TBS and the Mac-d pdu size:
X

Th_MAC-hs = TBS / TTI


Nb_of_MAC-d_pdu = floor[(TBS 21)/MacdPduSize]
Th_MAC-d = Nb_of_MAC-d_pdu * MacdPduSize
Th_rlc = Nb_of_MAC-d_pdu * (MacdPduSize-16)

Some UE categories are limited to a maximum TBS (see [Vol. 2]). So, above a certain
CQI, TBS do not increase anymore but power is reduced by 1dB per CQI. Moreover,
for a given CQI, TBS can have different values:
X

Default values corresponding to values used in UA4.2.

Optimized values used when the Transport Block Size Optimization feature is
enabled in order to decrease the padding bits.

Max
capability
values
used
when
ueCategoryX
(in
HsdpaMaxUeCategoryCapabilityActivation) is set to True in order to increase
maximum throughput for a given UE category

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 41/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range &
Unit
User
Class
Value

ueCategoryX
X = [1..12]
True, False

Object

HsdpaMaxUeCategoryCapabilityActivation

Customer
3
True for all UE categories

Granularity

BTSCell

Note: There is a 3GPP limitation regarding the maximum number of MAC-d PDUs that
can be allocated in one Capacity Allocation: 2047 PDUs. This means that in order to
provide the maximum bit rate for a single UE of category X, the hsdschInterval
parameter must be set inferior or equal to 2047 / max nb of MAC-d PDU * 2ms:

UE
category

Maximum
Transport
Block Size

78

14411

20251

10

21754

MAC-d PDU
size
336
656
336
656
336
656

Maximum number
of
MAC-d PDU
42
21
60
30
64
33

hsdschInterval
max (ms)
90
190
60
130
60
120

Table 3: Max hsdschInterval value

A value too high for hsdschInterval parameter will lead to reduce throughput.

[iCEM]
For iCEM, the recommendation for hsdschInterval is 50ms.
Parameter
Range & Unit
User
Class
Value

hsdschInterval
[10500] ms step = 10
Customer
3
50ms

Object

HsdpaConf

Granularity

BTSCell

[xCEM]
For xCEM, the hsdschInterval is hardcoded. The MAC-hs flow control algorithm
calculates the maximal number of MAC-d PDUs that can be transmitted by the RNC
within a HS-DSCH interval of 80 ms. These credits are sent to the RNC in the
message HS-DSCH CAPACITY ALLOCATION. The maximal credit that can be
allocated to the RNC is 2047 MAC-d PDUs. A HS-DSCH CAPACITY ALLOCATION
message is sent to the RNC:
- when a HS-DSCH CAPACITY REQUEST was received from the RNC in the
Node B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 42/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
- or when the MAC-hs flow control algorithm determines at the end of the HSDSCH interval the necessity (at most each 80ms). The HS-DSCH interval is
80 ms and an infinite repetition period is used, allowing to not resend a
CAPACITY ALLOCATION each 80ms if it is not needed.

As described above, if the MCS selected corresponds to a Transport Block Size that
exceeds what the UE can support according to its category then a lower MCS is
selected and the power requirements are lowered by -1dB/CQI. This is described in
the below table
MAC-d PDU size = 336 bits
Ue
category

Maximum HS-DSCH
TBS per TTI

Maximum
MCS

TBS applied from


maximum MCS

Max MAC-d
PDUs

1 to 6
7 to 8
9

7298
14411
20251

22
25
27

7168
14155
20251

21
42
60

10

27952

27 (iCEM)
29 (xCEM)

21754 (iCEM)
23792 (xCEM)

64 (iCEM)
70 (xCEM)

11 to 12

3630

Ue
category
1 to 6
7 to 8
9

16
3440
MAC-d PDU size = 656 bits
Maximum HS-DSCH Maximum
TBS applied from
TBS per TTI
MCS
maximum MCS
7298
23
7298
14411
25
13904
20251 (iCEM)
20251
27
19891 (xCEM)

10
Max MAC-d
PDUs
11
21
30

10

27952

27 (iCEM)
30 (xCEM)

21754 (iCEM)
26490 (xCEM)

33 (iCEM)
40 (xCEM)

11 to 12

3630

15

3319

Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size

Restriction
The maximum RLC throughput with UE category may be limited (limit around 4-4.5 Mb/s) due to the
RLC window size limitation.
Against RLC window size limitation, prohibitedStatusTimer parameter can be decreased (from 70ms
to 30ms) or PDU size can be increased (from 336 bits to 656 bits) in order to reach higher throughput.
Decrease the prohibitedStatusTimer leads to increase the uplink Status traffic (impact has to be
study especially in multi-UE scenario).

The following tables give the HSDPA throughput at ATM layer and the Iub bandwidth
per E1:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 43/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HS-DSCH category

Throughput at RLC level (kbps)

Throughput at ATM layer


(+30% protocol headers)

Cat 11 12

1 440 kbps

1 872 kbps

Cat 1 6

3 360 kbps

4 368 kbps

Cat 7 8

6 720 kbps

8 736 kbps

Cat 9

8 160 kbps

10 608 kbps

Cat 10

12 160 kbps

15 808 kbps

Table 5: Necessary throughput per HSDPA UE category


# E1

IuB
bandwidth

1 E1

2 E1

3 E1

4 E1

5 E1

6 E1

7 E1

8 E1

(Kbps)

(Kbps)

(Kbps)

(Kbps)

(Kbps)

(Kbps)

(Kbps)

(Kbps)

1 920

3840

5760

7680

9600

11520

13440

15360

Table 6: Iub bandwidth per number of E1 links

5.4 TFRC SELECTION


With xCem, TFRC (modulation, number of HS-PDSCH and Transport Block Size) is
determinated as described in 4.1.2.6 based on Look Up Tables (LUT). These LUTs
allow flexibility between the number of HS-PDSCH codes and the modulation that is to
say QPSK and 16QAM can be used whatever the number of HS-PDSCH codes.
X

With iCem and previously to UA6.0, there was no flexibility between modulation and
number of HS-PDSCH codes (QPSK used with 1, 2, 3, 4 and 5 HS-PDSCH and
16QAM used with equal to or more than 5 codes). TFRC is selected according to the
mapping tables given in 5.3.
X

In UA6.0, the feature 34102 HSDPA Flexible Modulation has been implemented for
iCem in order to be able to use QPSK or 16QAM whatever the number of HS-PDSCH
codes, and then to optimize the cell throughput. This feature consists in choosing the
modulation (QPSK or 16-QAM) which is the most efficient regarding the situation (HSPDSCH codes shortage or not) : 16-QAM allows to transmit more data with the same
number of codes at the expense of power ; QPSK allows to transmit more data with
the same power at the expense of the number of codes.

When this feature is enabled (hsdpaFlexibleModulationVsCodeActivation = True),


TFRC selection depends on the available number of HS-PDSCH codes compared to
the requested:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 44/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Code limitation: when the number of HS-PDSCH codes available is lower than
the number of codes requested by the UE

Code boost: when the number of HS-PDSCH codes available is higher than
the number of codes requested by the UE

Code limitation
U

Basically, the codes limitation scenario corresponds to the multi-users case or when
few HS-PDSCH codes are configured.
The aim is to use, 16QAM instead of QPSK when there is a code limitation (normally
QPSK is used for less than 5 codes) in order to increase the Transport Block Size
(power may be increased in order to take into account the fact that 16-QAM
modulation is less efficient) and hence increase the throughput.
Implementation is based on different mapping tables according to the number of
remaining HS-PDSCH codes (1, 2, 3 or 4), to the UE category (only if the number of
remaining codes is higher or equal to 5) and the MAC-d PDU size. Based on these
inputs TFRC will be selected to maximize the throughput.

- Number of remaining codes

Mapping
tables

- Modulation = 16QAM

- ue category

- TBS

- mac-d PDU size

- Power offset

Figure 8: Codes limitation


The power offset is given by the tables and corresponds to the term rc explained in
8.2.4.1.
B

Note that :

The tables for the case with 5 or more remaining codes are the default tables
(when hsdpaFlexibleModulationVsCodeActivation = False).

Code limitation is not applicable for UE Cat.12 (only QPSK is supported)

Code boost
U

Basically, the codes boost scenario corresponds to the mono-user case when there
remain some unused HS-PDSCH codes.
The aim is to use the remaining codes with the QPSK instead of 16QAM (normally
16QAM is used for more than 5 codes) in order to the increase the Transport Block
Size (power remains the same) and hence increase the throughput.
Implementation is based on different mapping tables according to the number of
remaining HS-PDSCH codes (7, 8, 9, 10, 11, 12, 13, 14, 15), the MAC-d PDU size
and the UE capability (up to 10 codes for category 7-8, 12 for category 9 and up to 15

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 45/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
for category 10). Based on these inputs, TFRC will be selected to maximize the
throughput.

- Number of remaining codes

Mapping
tables

- Modulation = QPSK
- TBS

- mac-d PDU size


- ue category

Figure 9: Code boost


Note that the code boost is not applicable for Cat.1-6 and 12 (max nb of codes = 5)

Activation
U

Parameter
Range & Unit
User
Class
Value

hsdpaFlexibleModulationVsCodeActivation
Boolean {True, False}
Customer
3
True

Object

HSDPAConf

Granularity

BTSCell

Note that when the Flexible modulation is enabled, the two following flags are ignored
(see 5.3 for more details on these flags):
X

hsdpaUeCategoryTransportBlockOptimization

hsdpaMaxUeCategoryCapabilityActivation

6 CQI & MAC-HS BLER MANAGEMENT


6.1 CQI PROCESSING
The HS-DPCCH channel contains the CQI computed by the mobile from P-CPICH
power measurements. This CQI after demodulation and decoding by the NodeB
(noted CQIreported) is directly used by the scheduler.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 46/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HS-DPCCH demodulation
and CQI decoding
CQIreported
CQI adjustment based on BLER
(to reach a BLER target)
and HS-DPCCH activity (in order to deactivate
deficient UE by artificially setting its CQI to 0)
CQIprocessed
Figure 10: CQI Processing

Two algorithms have been introduced to handle bad UE behaviors that would disrupt
the system. Note that in the nominal case, these algorithms should not have any
impact.
The purpose of these algorithms is respectively to:

Adjust the received CQI (CQIreported) in order to maintain an acceptable BLER


on first transmission.

Isolate a deficient UE which never responds (constant DTX detection).

Both algorithms are processed just after the CQI report and can be processed in any
order. The resulting CQI from both steps (referred as CQIprocessed in this document)
constitutes the input of both flow control and scheduler algorithms (except HS-SCCH
power control).
B

6.2 CQI ADJUSTMENT ACCORDING TO BLER


Principle - iCEM
U

UA5.0-UA6.0 Delta: CQI adjustement according to BLER


In UA5.0, the purpose of the feature HSDPA performance enhancements Configurable CQI
adjustment according to BLER target algorithm is to put the parameters of this algorithm at the OMCB so that the operator can tune its BLER target.

In UA6.0, the algorithm of CQI adjustement according to BLER is further enhanced by


supporting multiple BLER targets (configurable via OMC-B) and auto selection of one
of these targets depending upon the average CQI and the UE speed.
The tuning of the algorithm is made possible through the following new and existing
parameters:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 47/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

hsdpaBlerTargetUpperLimit: defines the Upper BLER target.


U

hsdpaBlerTargetLowerLimit: defines the Lower BLER target.


U

hsdpaBlerTargeMediumLimit: defines the Medium BLER target.


U

hsdpaBlerObservationWindow: corresponds to the update period of the CQI


offset

hsdpaBlerStepSize: it corresponds to step in dB applied upon reception of


NACK. In case of ACK, the step is a function of this parameter and of the
BLER target.

hsdpaCqiBlerAdjustmentAlgo: this parameter is used to deactivate the


feature:

0: deactivated.

1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no


possible parameterization, for iso-functional introduction.

2: outerLoopLikeAlgo. It corresponds to the UA5.x algorithm, allowing


a single BLER target.

3: dynamicOuterLoopAlgo. It corresponds to the UA6.0 evolution, with


dynamic BLER target switching.

UA4.2-UA5.0-UA6.0 Delta: BLER adjustement Algorithm


The UA4.2 algorithm was rather a defense algorithm than a solution converging towards an exact
BLER target. Simulations showed that convergence is not guaranteed when the range is too small for
instance.
An evolution was then proposed along with parameterization of the algorithm, enabling to define and
converge towards a specific BLER target (and not a range) in UA5.0.
Finally in UA6.0 three set of BLER targets are available and one of them is selected to provide best
performance depending upon the RF conditions and UE mobility.

The main principle still remains, i.e. computation and use of a DeltaCqi, but the way
and the frequency this variable is updated changes:
- A CQI offset is computed and applied on the received CQI.
- This offset is updated according to received feedback for first transmission, ACK or
NACK only.
- This offset is now updated as an outer-loop-like algorithm. Up (resp. down) steps are
applied upon reception of ACK (resp. NACK). The Up steps are computed in
accordance to the selected BLER target.
- Anytime a CQI is received, the offset is applied and the resulting value constitutes
the entry point of the scheduler.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 48/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Algorithm - iCEM
U

The new algorithm has been shown in the following figure:


DeltaCqi

corresponds to the offset applied to the reported CQI. It is derived from


DeltaCqiCur and CountCqi.

DeltaCqiCur corresponds to the current value of the offset, updated anytime a


feedback is received from a first transmission.
nbAckNack corresponds to the update period. nbAckNack
hsdpaBlerObservationWindow (OMC-B parameter).

is

set

to

DownStep

(<0) is the step to update DeltaCqiCur when a NACK is received.

UpStep

(>0) is the step to update DeltaCqiCur when an ACK is received. And

upStepLowBlerT arg et =

downStep lowBlerT arg et


100 lowBlerT arg et

upStepMediumBlerT arg et =

upStepHighBlerT arg et =

downStep mediumBlerT arg et


100 mediumBlerT arg et

downStep highBlerT arg et


100 highBlerT arg et

The BLER target is selected according to the CQI compared to a threshold

if CQI <= cqiThLow, then BlerTarget = highBlerTarget

if CQI >= cqiThHigh, then BlerTarget = lowBlerTarget

if cqiThLow < CQI < cqiThHigh then BlerTarget = mediumBlerTarget

These thresholds (cqiThLow and cqiThHigh) are hard-coded and a value is defined
per UE category as illustrated in the following figure:
cqiThHigh
cqiThLow
hsdpaCqiBlerAdjustmentAlgo
dynamicOuterLoopAlgo
outerLoopLikeAlgo
blerRangeBasedAlgo

CQI
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Cat.12
Cat.1-6
Cat.7-10
Cat.x
Bler Target = hsdpaBlerTargetUpperLimit
Cat.x
Bler Target < 30% (in practice around 10%)
highBlerTarget = hsdpaBlerTargetUpperLimit
mediumBlerTarget = hsdpaBlerTargetMediumLimit
lowBlerTarget = hsdpaBlerTargetLowerLimit

Figure 11 : BLER Target according to the CQI and the UE category for the different BLER
Ajustement algorithm

Following steps are then performed:

Anytime feedback information is received from a scheduled UE, DeltaCqiCur


is updated:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 49/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

If ACK, DeltaCqiCur is increased by UpStep

If NACK, DeltaCqiCur is decreased by DownStep

If DTX, no update (as in UA4.2)

Any CountCqi ACK/NACK information received, DeltaCqi is updated. The


rounded valued of DeltaCqiCur, bounded by limits (5), is added to DeltaCqi.

DeltaCqi variation between two updates is limited to 5 (CQI) because the wide range
of OMC-B parameters may lead to an algorithm divergence for certain set of values
(e.g. large update period with a big step).

Figure 12: CQI adjustment to BLER algorithm

Parameters:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 50/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

Object
hsdpaCqiBlerAdjustmentAlgo
[deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo,
dynamicOuterLoopAlgo]
Customer
Granularity
3
dynamicOuterLoopAlgo

Parameter
Range & Unit
User
Class
Value

hsdpaAdjustBlerToChannelVariation
[TRUE, FALSE]
Customer
3
FALSE

HSDPAConf

BTSCell

Object

HSDPAConf

Granularity

BTSCell

Engineering Recommendation: hsdpaCqiBlerAdjustmentAlgo


BLER Target algo (dynamicOuterLoopAlgo) bring gain in most cases because the setting (BLER
target value) varies depending upon several factors: UE category, CQI distribution and UE speed (if
hsdpaAdjustBlerToChannelVariation flag is set to true).
That is why UA6.0 algo (dynamicOuterLoopAlgo) is recommended because its performance matches
the indoor and outdoor RF environments.

Parameter
Range & Unit
User
Class
Value

hsdpaBlerTargetUpperLimit
[[1..99]] %
Customer
3
30

Object

HSDPAConf

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

hsdpaBlerTargetLowerLimit
[[1..99]] %
Customer
3
1

Object

HSDPAConf

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

hsdpaBlerTargetMediumLimit
[[1..99]] %
Customer
3
20

Object

HSDPAConf

Granularity

BTSCell

Rule: Coherence between various BLER targets


Following interdependency rule should be observed on the values of hsdpaBlerTargetLowerLimit,
hsdpaBlerTargetMediumLimit and hsdpaBlerTargetUpperLimit:
hsdpaBlerTargetLowerLimit <= hsdpaBlerTargetMediumLimit <= hsdpaBlerTargetUpperLimit

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 51/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

hsdpaBlerObservationWindow
[1..100] Decimal (TTIs)
Customer
3
10

Object

HSDPAConf

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

hsdpaBlerStepSize
[0.1..1.0] step:0.1
Customer
3
0.1

Object

HSDPAConf

Granularity

BTSCell

Principle - xCEM:
U

With xCEM, constBlerTarget algorithm has been implemented to control the MAC-hs
BLER.
Note that the MAC-hs bler estimation is still based on ack/nack information reported
on HS-DPCCH.
With constBlerTarget algorithm, MAC-hs BLER is managed as with iCEM
outerLoopLikeAlgo algorithm, except that the offset (ack,nack) is applied on SNR of
one HS-PDSCH instead of directly on CQI. This calculated SNR is then mapped to a
spectral efficiency and used for TFRC selection. However unlike iCEM, xCEM loosely
targets the constant BLER or packet error rate for first transmission and may allow it to
deviate from the target to optimize throughput.

The first transmission target value for the packet error rate impacts the observed data
rate significantly. If the target error rate is set to very small value, the scheduler only
selects small transport block sizes. This results in a low throughput. On the other side
if the target value is set to a large value, larger transport block sizes are selected. In
this case it may happen that the packet is still not received correctly in the UE after all
HARQ retransmissions. Then RLC retransmissions are required, which also leads to a
reduced throughput.
Following equivalent parameters have been defined for xCEM as:

Parameter
Range & Unit
User
Class
Value

hsdpaCqiBlerAdjustmentAlgorithmXcem Object
[deactivated, constBlerTarget, dynamicHarqTxTarget] Enum
Customer
Granularity
3
constBlerTarget

HsdpaConf
BTSCell

UA5.1.1-UA6.0 Delta: hsdpaCqiBlerAdjustmentAlgorithmXcem


Concerning the parameter hsdpaCqiBlerAdjustmentAlgorithmXcem, the value activated in UA5.1.1
and the value constBlerTarget in UA6.0 activate the same algorithm.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 52/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Restriction: dynamicHarqTxTarget
For hsdpaCqiBlerAdjustmentAlgorithmXcem, only 2 values are supported :
-

deactivated,

constBlerTarget

The value dynamicHarqTxTarget should not be selected since this algorithm is not supported.

Parameter
Range & Unit
User
Class
Value

hsdpaBlerTargetUpperLimitXcem
[199] %
Customer
0
15

Object

HsdpaConf

Granularity

BTSCell

The parameter hsdpaBlerTargetUpperLimitXcem is used when constBLERTarget


is selected and determines which limit is used as target for HSDPA packet error rate.

Parameter
Range & Unit
User
Class
Value

hsdpaBlerTargetLowerLimitXcem
[199] %
Customer
0
1

Object

HsdpaConf

Granularity

BTSCell

The parameter hsdpaBlerTargetLowerLimitXcem is not used in this release.

Principle UCU III:


U

With UCU III, the method of "constBlerTarget" described above is supported with
down step set to 0.4dB (HSDPA_SINR_down_step) and packet error target of 20%
(HSDPA_packet_error_target). The correction term (ACK,NACK) is upper and lower
limited by 2dB (HSDPA_SINR_max_factor) and -1dB (HSDPA_SINR_min_factor)
respectively.
The up step size HSDPA_SINR_up_step is calculated in the MAC-hs as:

HSDPA_SINR_up_step
HSDPA_packet_error_target
=
HSDPA_SINR_down_step 1 HSDPA_packet_error_target
Parameter
Range & Unit
User
Class
Value

HSDPA_SINR_down_step
Integer 0,,512}& [0.001 dB]
0
0.4 dB

Object

HsdpaConf

Granularity

BTSCell

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 53/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

HSDPA_packet_error_target
Integer: {-63,,0} & step size of 0.1
0
-7

Object

HsdpaConf

Granularity

BTSCell

A default value of 7 corresponds to the logarithm of the packet error target rate of
20%.

Parameter
Range & Unit
User
Class
Value

HSDPA_SINR_max_factor
Integer:{-200,,330} & 0.1 dB
0
20 (meaning 2dB)

Object

HsdpaConf

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

HSDPA_SINR_min_factor
Integer: {-400,,200} & 0.1 dB
0
-10 (meaning -1dB)

Object

HsdpaConf

Granularity

BTSCell

6.3 HS-DPCCH PRESENCE DETECTION


Since UA5.0, the feature HSDPA performance enhancements HS-DPCCH
detection based on CQI is introduced to detect the presence of HS-DPCCH based on
CQI in order to schedule the UE only when HS-DPCCH decoding is reliable enough to
get valid CQI information and correctly decode ACK/NACK.

It is necessary for Compressed Mode in MAC-hs feature to introduce a detection


algorithm on CQI.

This algorithm manages two states: HSDPA Synchronized and HSDPA-Not


Synchronized. Main principles of the algorithm are as following:

The initial state is considered as not synchronized (HSD_OUT_SYNC), i.e.


nothing has been yet received on HS-DPCCH.

To acquire the synchronization on the HS-DPCCH (HSD_IN_SYNC), N


successive CQI must be detected.

Once in that HSD_IN_SYNC state, CQI are taken into account in the MAC-hs.
In case of DTX, the last decoded value is kept.

If M successive expected CQI are not detected (DTX), then the UE falls into
the HSD_OUT_SYNC state.

During that HSD_OUT_SYNC state, the UE must not be scheduled anymore.


CQI still remains to be detected & decoded in order to reactivate the UE if

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 54/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
possible. If ACK/NACK is expected during that out-of-synchronization period
from previously transmitted transport blocks, they must be decoded and taken
into account for HARQ process update. Pending retransmissions are
nevertheless not transmitted and are stored until the HSD_IN_SYNC state is
back. Finally, during that state, no Capacity Allocation should be sent to the
RNC.

Note: At the beginning of the communication, the UE is considered as unsynchronized


as long as no valid CQI sequence is received. No Capa alloc is sent during that time,
and that may delay a little bit the effective activation.
In case the CQI falls into an UL transmission gap (during compressed mode), it must
not be taken into account for this algorithm, i.e. neither as DTX nor as detected.
The following flowchart summarizes the state change triggers.

Figure 13: HS-DPCCH synchronization algorithm

M and N values are hard coded and fixed to 2 (for both)


The HS-DPCCH synchronization algorithm is activated thanks to the bit 1 of the
RxDemodulation parameter:
-

bit 1 = 0 ON - HS-DPCCH synchronization based on CQI is activated

bit 1 = 1 OFF - HS-DPCCH synchronization based on CQI is deactivated

This algorithm is activated by default. As the parameter is class 0, it cannot be


changed online.
U

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 55/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

RxDemodulation
[0..2147483647] Decimal
Customer
0
4

Object

BTSEquipmentl

Granularity

BTS

This parameter is used to activate/deactivate 3 features as follows:


Bit 0:

0: Activate the common Layer1 UL enhancement algorithm.

1: do not activate the common activate Layer1 UL enhancement algorithm

Bit 1:

0: H-BBU detection of the HS-DPCCH presence based on CQI ON

1: H-BBU detection of the HS-DPCCH presence based on CQI OFF

Bit 2:

0 : enhanced demodulation for high speed UE OFF

1 : enhanced demodulation for high speed UE ON

Note: the bit 0 deals with H-BBU and D-BBU improvements introduced in UA4.2.
Other H-BBU improvements have been introduced in UA5.0 through the bit 2.

All other Bit values are reserved.

Engineering Recommendation: RxDemodulation


In order to activate/deactivate one of the features mentioned above, follow the table below in most of
HSxPA deployment scenarios:
Enhanced

common Layer1 UL

HS-DPCCH presence

enhancement

detection

OFF

OFF

OFF

ON

OFF

OFF

OFF

ON

OFF

OFF

OFF

ON

OFF

ON

ON

ON

OFF

ON

ON

ON

OFF

RxDemodulation value

demodulation for high


speed UE

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 56/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
4

ON

ON

ON

When coming back into the HSD_IN_SYNC state, scheduler cost function must be
reinitialized (both costs set to respective lower cost of active QIDs).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 57/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

7 OVSF CODES
7.1 CELL CONFIGURATION
Since UA5.0, codes reservation at cell setup is done as follows:

Only the HS-PDSCH codes are reserved at the bottom of the OVSF code
tree. All the other channels are reserved just after the following channels (1)
common channels, (2) OCNS, (3) HS-SCCH channels, (4) DL HSUPA
channels)

Multiple S-CCPCH feature allows to use up to 3 S-CCPCH (1st S-CCPCH on


SF64,1, 2nd S-CCPCH on SF128,4, 3rd S-CCPCH on SF128,5). Then the common
channels take the equivalent of a SF32 in mono-S-CCPCH mode, a SF32 + a
SF128 in bi-S-CCPCH mode and a SF32 + 1SF64 in tri-S-CCPCH mode.
P

The number of HS-PDSCH codes reserved at cell setup is still defined by the
numberOfHsPdschCodes parameter as in UA4.2. When the feature
Dynamic DL Codes Tree Management for HSDPA is activated the number of
HS-PDSCH codes reserved for HSDPA traffic can be updated dynamically
according the number of free OVSF codes

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 58/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The following figures illustrate the different Common Channels configurations
described above:

Configuration with 1 S-CCPCH

Configuration with 2 S-CCPCH

Configuration with 3 S-CCPCH

Figure 14: R99, HSDPA & HSUPA Common Channels codes allocation

7.2 HSDPA CODE ALLOCATION


In UA6.0, OVSF codes reservation for the HS-PDSCH channels can be managed
statically or dynamically according to the activation or deactivation of the features
DCTM (implemented from UA5.0) and Fair Sharing (implemented in UA6.0):

DCTM disabled
and
Fair Sharing disabled:

DCTM enabled
(Fair Sharing has to be
disabled)

- Reservation of the HS-PDSCH codes is static and the number of HSPDSCH codes is defined by the parameter numberOfHsPdschCodes.
- HSDPA codes configuration is sent during the cell setup from RNC to
NodeB through the Physical Shared Channel Reconfiguration message
and these codes can not be used or pre-empted for other services.
- This message contains the number of HS-PDSCH and the index of the
first one knowing that HS-PDSCH codes are reserved at the bottom of
the OVSF tree.
- Reservation of HS-PDSCH codes is dynamic and depends on the R99
traffic.
- Codes not used by R99 can be used for HS-PDSCH channels.
- Nevertheless, some codes needed to be kept free in order to anticipate
the admission of a R99 call.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 59/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Fair Sharing is enabled


(DCTM has to be
disabled):

- New HS-PDSCH configuration is sent from RNC to NodeB through a


PSCR message each time a HS-PDSCH pre-emption or re-allocation is
triggered according to R99 traffic variation.
- OVSF codes are managed by NodeB autonomously that is to say that
the NodeB knows in real time which codes are used or not by R99
and then it is able to compute which block of consecutive SF16 codes
are available for HS-PDSCH.
- When change in the HS-PDSCH code usage occurs, the NodeB will
reconfigure the H-BBU in order to take into account the new number of
HS-PDSCH codes.
- As the NodeB knows TTI by TTI the occupancy of the codes tree, there
is no need to keep some codes free to anticipate the admission of a
R99 call.

Since UA5.0, the HS-SCCH codes are allocated at the top of the OVSF tree after the
common channels. The number of HS-SCCH is defined by the
numberofHsScchCodes.

7.2.1 DYNAMIC CODE TREE MANAGEMENT


When the feature Dynamic Code Tree Mgt is activated, the HS-PDSCH codes can
be pre-empted or re-allocated according to the number of free OVSF codes. The
number of free OVSF codes is re-evaluated for each R99 code release or allocation.
The new configuration (number of HS-PDSCH codes; HS-PDSCH start code number)
is transmitted from the RNC to the NodeB through a NBAP PHYSICAL SHARED
CHANNEL RECONFIGURATION REQUEST and replaces the old one
instantaneously (at the next TTI) as only asynchronous mode is supported. Note that
the HS-PDSCH codes are only reserved and may be unused if there is no HSDPA
user in the cell.

Monitoring line
U

The HS-PDSCH codes pre-emption or re-allocation is triggered by some thresholds


defined compared to the number of free OVSF codes noted #FreeOvsfCodesSfx. The
number of free OVSF codes can be monitored for different Spreading Factor from
SF16 to SF256.
This
monitoring
line
is
set
by
default
spreadingFactorLevelForOvsfMonitoring parameter.

to

SF16

via

the

HS-PDSCH codes pre-emption


U

The pre-emption (or stealing) of HS-PDSCH codes is triggered when the number of
free OVSF codes is strictly lower than threshCodesToTriggerStealing.

Triggering condition for HS-PDSCH codes pre-emption:


#FreeOvsfCodesSfx < threshCodesToTriggerStealing

(Cond.1)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 60/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
OR
threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nb of free SF8 codes == 0

(Cond.2)

As SFMonitoring can not be lower than SF16, the second condtion (Cond.2) allows
checking the availability of one SF8.

When the pre-emption condition is encountered, the RNC steals some HS-PDSCH
codes in order to have numCodesForDchAfterStealing free OVSF codes.

Number of free OVSF codes after stealing:


#FreeOvsfCodesSfx numCodesForDchAfterStealing

(Cond.3)

OR
New Nb of free SF8 codes > 0 if
((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing *
SF8/SFMonitoring) 1))
(Cond.4)

The second condition (Cond.4) allows to guarantee at least one SF8 if needed.

The HS-PDSCH codes are pre-empted from the top to the bottom of the OVSF tree
and the minNumberOfHsPdschCodes parameter guarantees a minimum number of
HS-PDSCH codes that can not be stolen.

In order to avoid reallocation just after a stealing, the RNC starts a timer
(minTimeBeforeReallocationofHsPdsch) when a stealing is triggered during which
reallocation is forbidden but stealing is allowed.

HS-PDSCH codes re-allocation


U

The re-allocation of HS-PDSCH codes is triggered when the number of free OVSF
codes is strictly higher than threshCodesToTriggerReallocation.

Triggering condition for HS-PDSCH reallocation:


#FreeOvsfCodesSfx > threshCodesToTriggerReallocation

When the re-allocation condition is encountered, the RNC re-allocate some HSPDSCH codes in order to have numCodesForDchAfterReallocation free OVSF
codes.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 61/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Number of free OVSF codes after re-allocation:
#FreeOvsfCodesSfx numCodesForDchAfterReallocation

(Cond.5)

OR
New Nb of free SF8 codes > 0 if
((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing *
SF8/SFMonitoring) 1))
(Cond.6)

The second condition (Cond.6) allows to guarantee at least one SF8 if needed.

The HS-PDSCH codes are re-allocated from the bottom to the top of the OVSF tree
and the maxNumberOfHsPdschCodes parameter guarantees a maximum number of
HS-PDSCH codes that can be re-allocated.

The following flowcharts summarize the DCTM algorithm:

R99 code allocation or release


RNC checks the number of free SFx

If #FreeOvsfCodesSfx
< threshCodesToTriggerStealing

No

Yes
No

If threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nf of free SF8 codes == 0
Yes

If #FreeOvsfCodesSfx
> threshCodesToTriggerReallocation
Yes

HS-PDSCH codes pre-emption is triggered

HS-PDSCH codes reallocation is triggered

Figure 15: HS-PDSCH codes pre-emption or re-allocation

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 62/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HS-PDSCH codes pre-emption is triggered

If ((old Number of free SF8 codes == 0)


AND
((threshCodesToTriggerStealing * SF8/SFMonitoring) 1))

No

Yes
Number of HS-PDSCH codes stolen is such as:
New Nb of free SF8 codes > 0

Number of HS-PDSCH codes stolen is such as:


#FreeOvsfCodesSfx numCodesForDchAfterStealing

Figure 16: Number of HS-PDSCH codes pre-empted

HS-PDSCH codes reallocation is triggered

If ((old Number of free SF8 codes == 0)


AND
((threshCodesToTriggerStealing * SF8/SFMonitoring) 1))

No

Yes
Number of HS-PDSCH codes re-allocated is such as:
New Nb of free SF8 codes > 0

Number of HS-PDSCH codes re-allocated is such as:


FreeOvsfCodesSfx numCodesForDchAfterReallocation

Figure 17: Number of HS-PDSCH codes re-allocated

PARAMETERS SETTINGS AND RECOMMENDATIONS


Restriction: HS-PDSCH codes re-allocation can be blocked by a R99 code even if re-allocation
is triggered
The HS-PDSCH codes have to be consecutive whatever the free OVSF codes. So, if a R99 code is
contiguous to the HS-PDSCH codes already reserved, new HS-PDSCH can not be re-allocated. This
scenario is illustrated by the following figure. HSDPA throughput impact should be low since it appears
in specific condition and can be reduce by setting appropriate value for the minimum codes for HSPDSCH.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 63/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
SF256

SF128

SF64

SF32

SF16

SF8

SF4

0
0

Common channels
(3 S-CCPCH) + 2 HS-SCCH

0
2
1
3

R99 codes

4
2
5
1

Free OVSF codes

6
3
7
8
4
9
2
10
5
11

Reallocation of a 5th HS-PDSCH


code is impossible because of the
R99 code even if the number of
free codes triggers the reallocation

12
6
13
3
14

HS-PDSCH (4 for ex)

7
15

Figure 18: Illustration of the HS-PDSCH re-allocation blocking

The isHsPdschDynamicManagementAllowed parameter allows the activation of the


Dynamic Code Tree Mgt feature:
Parameter
Range & Unit
User
Class
Value

isHsPdschDynamicManagementAllowed
[false, true]
Customer
3
False

Object

RadioAccessService

Granularity

RNC

The following parameter is used in UA6.0 to activate the DCTM feature at FDDCell
level:
Parameter
Range & Unit
User
Class
Value

isCellHsPdschDynamicManagementActive
[false, true]
Customer
0
False

Object

HsdpaCellClass

Granularity

CellClass

Engineering Recommendation: DCTM activation


In UA6, the recommendation is to use the dynamic codes management algorithm implemented with
the feature Fair Sharing (up to 15 HS-PDSCH, no more need to keep a margin, better reactivity).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 64/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Then the DCTM activation flags have to be set to False:
isHsPdschDynamicManagementAllowed = False
isCellHsPdschDynamicManagementActive = False
Note that DCTM and Fair Sharing are exclusive :
- Fair Sharing can be enabled only if DCTM is disabled
- DCTM can be enabled only if Fair Sharing is disabled

UA5.x-UA6.0 Delta: DCTM activation at FDDCell level


UA5.x : isHighPerformanceAllowed
UA6.0 : isCellHsPdschDynamicManagementActive

Note: When feature is disabled at RNC level, no NBAP message is sent by RNC to provide NodeB
with new configuration, that is to say that the number of HS-PDSCH remains the same after deactivation and is not equal to numberOfHsPdschCodes. In order to reinitialize the number of HSPDSCH to numberOfHsPdschCodes, we need either to lock/unlock the cell or to disable the feature
at FDDCell level (parameter being class 0).

Rule: DCTM and Fair Sharing activation


DCTM and Fair Sharing algorithms are totally incompatible.
Then:

Prior to DCTM activation, Fair Sharing (RNC and NodeB algo) has to be disabled

Prior to Fair Sharing activation (RNC and NodeB algo), DCTM has to be disabled

Parameter
Range & Unit
User
Class
Value

numberOfHsPdschCodes
[1..15]
Customer
0
5

Object

HsdpaCellClass

Granularity

CellClass

Parameter
Range & Unit
User
Class
Value

numberOfHsScchCodes
[1..4]
Customer
0
2

Object

HsdpaCellClass

Granularity

CellClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 65/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: numberOfHsPdschCodes & numberOfHsScchCodes
When the feature is de-activated:
U

The number of HS-PDSCH codes reserved in the HSDPA cell (numberOfHsPdschCodes) has to be
chosen according to the number of HS-SCCH codes (numberOfHsScchCodes) reserved and on the
UE category. For example, if only one HS-SCCH code (one user per TTI) is configured and majority of
users have UE Category 6 or 12 (5 HS-PDSCH codes max), there is no need to reserve more than 5
HS-PDSCH codes. In a trial context, we suppose 2 HS-SCCH codes (up to 2 UE per TTI) and UE
category 6 or 12 (5 HS-PDSCH codes max). So 10 HS-PDSCH codes are required.
In Live Network, there is a low probability to have more than 2 users scheduled during the same TTI
Moreover, the more UE are scheduled, the more HS-PDSCH codes are needed to avoid code
limitation. This is the reason why the number of HS-SCCH codes is set to 2.

When the feature is activated:


U

numberOfHsPdschCodes = 5 for shared carrier or 10 for dedicated carrier in order to keep the same
behavior as in UA4.2 (static reservation) if the feature is de-activated
numberOfHsScchCodes = 2 in order to schedule up to 2 HSDPA users when R99 traffic is low
numberOfHsScchCodes = 4 in order to schedule up to 4 HSDPA users when DL throughput is low
(number of HS-PDSCH needed is low) for HSUPA or VoIP services

Parameter
Range & Unit
User
Class
Value

maxNumberOfHsPdschCodes
[1..15]
Customer
3
15

Object

HsPdschDynamicManagement

Granularity

CellClass

Engineering Recommendation: maxNumberOfHsPdschCodes


This maximum value of 15 can never be reached because of the presence of at least the common
channel codes, the free codes and codes for SRB. Nevertheless, there is no reason to limit this value.

Parameter
Range & Unit
User
Class
Value

minNumberOfHsPdschCodes
[0..15]
Customer
3
1

Object

HsPdschDynamicManagement

Granularity

CellClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 66/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: minNumberOfHsPdschCodes
This parameter allows to guarantee a minimum QoS for HSDPA and depends on the operator
strategy:
Operator strategy

Recommended value

Full flexibility of the feature

No impact on HSDPA Cat12 user

Minimum HDSPA throughput (at least throughput of 1 PS384)

Engineering Recommendation: minNumberOfHsPdschCodes and MAC-d PDU size


As explained in 5.3, with iCem, the minimum number of HS-PDSCH that can be managed by the
scheduler with a MAC-d PDU size of 656 bits is 2 if the feature Flexible Modulation is disabled.
X

If only one HS-PDSCH code is configured (due to minNumberOfHsPdschCodes = 1 and very high
R99 traffic), the NodeB sends Capacity Allocation with 0 credits. To avoid that,
minNumberOfHsPdschCodes can be set to a value higher or equal to 2 if the MAC-d PDU is 656
bits and if Flexible Modulation is disabled.

The number of OVSF codes of SFX in the tree is monitored at each OVSF code
allocation or deallocation. The X corresponds to the parameter called
spreadingFactorLevelForOvsfMonitoring
Parameter
Range &
Unit
User
Class
Value

spreadingFactorLevelForOvsfMonitoring
[16, 32, 64, 128, 256]

Object

HsPdschDynamicManagement

Customer
3
16

Granularity

CellClass

The number of HS-PDSCH codes (SF16) that are reallocated will be computed so that
after reallocation, the number of SFX free for DCH is targeted to
numCodesForDchAfterReallocation parameter.
Parameter
Range &
Unit
User
Class
Value

numCodesForDchAfterReallocation
[1..255]

Object

HsPdschDynamicManagement

Customer
3
2

Granularity

CellClass

The number of HS-PDSCH codes (SF16) that are stolen will be computed so that after
stealing,
the
number
of
SFX
free
for
DCH
is
targeted
to
numCodesForDchAfterStealing parameter

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 67/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

numCodesForDchAfterStealing
[1..255]
Customer
3
2

Object

HsPdschDynamicManagement

Granularity

CellClass

When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is
strictly greater than threshCodesToTriggerReallocation parameter, the RNC will
reallocate some HS-PDSCH codes.
Parameter
Range &
Unit
User
Class
Value

threshCodesToTriggerReallocation
[1..255]

Object

HsPdschDynamicManagement

Customer
3
2

Granularity

CellClass

When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is
strictly lower than threshCodesToTriggerStealing parameter, the RNC will steal
some HS-PDSCH codes.
Parameter
Range & Unit
User
Class
Value

threshCodesToTriggerStealing
[1..255]
Customer
3
2

Object

HsPdschDynamicManagement

Granularity

CellClass

Engineering Recommendation: numCodesForDchAfterX & threshCodesToTriggerX


Parameters numCodesForDchAfterX & threshCodesToTriggerX allow defining the number of free
OVSF code when there is no pre-emption or re-allocation. This number of free OVSF codes dictates
the biggest R99 data RAB that the RNC can accept.
If the operator PS allocation policy is based on PS128, the parameters has to be set so that the
number of free codes to be equal to 1 SF16;
If the operator PS allocation policy is based on P384, the parameters have to be set so that the
number of free codes to be equal to 2 SF16.
Note that these values assume spreadingFactorLevelForOvsfMonitoring = SF16.
The above recommendations are given for a PS384 admission policy.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 68/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: spreadingFactorLevelForOvsfMonitoring
With typical parameters setting (monitoring line = SF16 and NaR = NaS = ThR = ThS = 2), the
maximum number of HS-PDSCH is 12 (1 SF16 for common channel, HS-SCCH and DL HSUPA
channels, 1 SF16 for SRBs and 2 free SF16).
For HSDPA KPI tests, the maximum number of HS-PDSCH codes can be increased by increasing
monitoring line SFx and by decreasing number of free SFx codes (in order to schedule several
HSDPA UE in the same TTI).
Higher number of HS-PDSCH codes can be reached with monitoring line equal to SF128 and 1 free
SF128 (1 SF16 for common channel including several HS-SCCH, 1 SF16 for SRBs including 1 free
SF128 and 14 SF16 for HS-PDSCH).
Note that configuration with monitoring line equal to SF256 and 1 free SF256 does not allow admitting
several HSDPA UE since HSDPA call is established with SRB13.6 (SF128). After establishment,
SRB13.6 is reconfigured in SRB3.4 (SF256).

When
stealing
has
been
triggered,
the
RNC
starts
minTimeBeforeReallocationOfHsPdsch timer during which reallocation is forbidden
but stealing is allowed
Parameter
Range &
Unit
User
Class
Value

minTimeBeforeReallocationOfHsPdsch
[0..3600] Decimal (s)

Object

HsPdschDynamicManagement

Customer
3
0

Granularity

CellClass

Engineering Recommendation: minTimeBeforeReallocationOfHsPdsch


Increasing this parameter leads to decrease in the number of PSCR for reallocation but HSDPA
throughput may be degraded if some free SF16 are not reallocated because of this timer. That why his
value is 0.

Note: The number of free OVSF codes is re-evaluated for each R99 code release or
allocation
except
at
timer
expiry.
When
the
timer
minTimeBeforeReallocationOfHsPdsch is expired, RNC will check automatically the
threshold compared to the number of free OVSF codes without waiting for a R99 code
release or reallocation.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 69/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Rule: Coherence between the parameters
To have normal feature behaviour:
U

numCodesForDcfhAfterReallocation <= threshCodesToTriggerReallocation


numCodesForDchAfterStealing >= threshCodesToTriggerStealing

To avoid ping-pong:
U

numCodesForDchAfterReallocation >= threshCodesToTriggerStealing


numCodesForDchAfterStealing <= threshCodesToTriggerReallocation

To be in line with monitoring line


U

numCodesForDchAfterReallocation <= spreadingFactorLevelForOvsfMonitoring


numCodesForDchAfterStealing <= spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerReallocation <= spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerStealing <= spreadingFactorLevelForOvsfMonitoring

To be coherent at cell setup


U

minNumberOfHsPdschCodes <= numberOfHsPdschCodes


numberOfHsPdschCodes <= maxNumberOfHsPdschCodes

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 70/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: OCNS configuration
OCNS code allocation is done before HSDPA configuration and it may lead to a conflict as HSPDSCH codes are always allocated from the bottom and need to be contiguous. To avoid any issue
with HS-PDSCH and the common channels codes, OCNS configuration has to be modified according
to the number of S-CCPCH codes:

Param identity
Default value Recommended value

Range

(Customer Class 2)
RNC / NodeB / FDDCell
OCNSActivation
OCNSSpreadingFactor

False

SF8

SF256

Enum [False; True]


Enum [SF4 SF256]

RNC / NodeB / FDDCell / OCNSChannelsParameters


OCNSPower

100%

Integer [0100]

8 with 1 S-CCPCH
OCNSChannelizationCodeNumber

10 with 2 S-CCPCH

Integer [0511]

12 with 3 S-CCPCH

Note that in UA6.0, the feature OCNS for HSDPA has been introduced for US market. See 9.3 for
more details.
X

7.2.2 FAIR SHARING


The feature Fair Sharing is divided in 2 parts:

One part of the Fair Sharing algorithm is located at RNC level and manages
the HSDPA CAC (see [Vol. 5] for more details)
X

The other part of Fair Sharing algorithm is located at NodeB level and
dynamically manages the HS-PDSCH codes allocation according to the R99
traffic (this section describes this part of the Fair Sharing algorithm).

In the previous releases, the HS-PDSCH codes configuration is managed by the RNC.
Indeed, the RNC sent to the NodeB through the PSCR message to configure (at cell
setup) or reconfigure (according to the R99 traffic if DCTM is ON) the HS-PDSCH
codes usuable by the scheduler.

In UA6.0 with Fair Sharing, the NodeB is able to know which HS-PDSCH codes can
be used for HSDPA traffic according the R99 traffic. For that, NodeB has a view in real
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 71/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
time of the R99 codes usage and then is able to compute which remaining codes can
be used for HS-PDSCH.
Fair Sharing feature consists in:
-

Monitoring the DL OVSF code tree occupancy

Determining the codes available for HS-PDSCH scheduling

Reconfiguring the H-BBU accordingly via a new internal message

Monitoring of the OVSF code tree occupancy


U

For each cell, CallP CCM must maintain an up-to-date view of the codes in use by
R99 and common channels. This view is updated anytime one of the following
channels is setup or released, or when its code and/or SF is reconfigured:
-

Common channels (P-CPICH, P-CCPCH, S-CCPCH, AICH, PICH, MICH, HSSCCH, E-AGCH)

Dedicated channels (DPCH, E-RGCH, E-HICH)

So, at each NBAP Radio Link Setup, Addition, Reconfiguration, Deletion, the Node B
rebuilds dynamically an image of the tree to determine which SF16 codes are not
blocked/allocated to DCH and can be used as HS-PDSCH by the MAC-hs scheduler.

Determination of the codes available for HS-PDSCH scheduling


U

When Fair Sharing is enabled, the NodeB has a view of the codes used or reserved
by R99 and then knows which SF16 codes are free.

Largest group of consecutive free SF16

Used or reserved for ccc, E-AGCH/E-RGCH/E-HICH, HS-SCCH

Used or reserved for R99 calls

Free SF16 codes

10

11

12

13

14

15

Figure 19: Exemple of codes occupancy for SF16

Among these free SF16 codes, the largest group of consecutive free SF16 codes will
be selected to allocate HS-PDSCH codes.

Note that Fair Sharing feature also introduces HSDPA CAC at RNC level. So, some
HS-PDSCH codes can be reserved for HSDPA users to guarantee a QoS depending
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 72/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
upon the GBR / minBR of the HSDPA RAB. These reserved codes change
dynamically with traffic (at each HSDPA RB allocation/release) and cannot be
allocated to DCH. It ensures that some SF16 codes are available for HS-PDSCH. The
way these codes are used is under MAC-hs control.

Reconfiguration of the H-BBU


U

Once available HS-PDSCH codes are determined, the H-BBU is reconfigured. When
the Fair Sharing is disabled, the new HS-PDSCH configuration is sent from the RNC
to the NodeB through the PSCR message. When the Fair Sharing is enabled, the new
HS-PDSCH configuration is sent from the CallP CCM to the H-BBU through an
internal PSCR message. This message (NBAP PSCR or internal PSCR gives the
same information, that is to say the number of HS-PDSCH codes and the index of the
first HS-PDSCH code).

ACTIVATION
The feature Fair Sharing and Dynamic Code Tree Management can not be activated
in the same time in a cell because they are incompatible. Before activating one, the
other has to be deactivated.
- iCEM/xCEM
Parameter
Range & Unit
User
Class
Value

hsdpaCodeTreeManagementActivation
Boolean {True, False}
Customer
3
True

Object

BTSEquipmentl

Granularity

BTS

- UCU-III
Parameter
Range & Unit
User
Class
Value

hsdpaCodeTreeManagementActivation
Boolean {True, False}
Customer
3
True

Object

OneBTSEquipmentl

Granularity

OneBTS

The same parameter activates the NodeB part of the feature but resides in different
objects depending upon the NodeB platform:
- If TRUE, HS-PDSCH codes are determined by CCM and HBBU is
dynamically reconfigured.
- If FALSE, available HS-PDSCH codes are determined by the RNC and
NBAP PSCR is directly applied.

Note that the CCM must monitor the code occupancy all the time whatever the feature
activation.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 73/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

8 POWER MANAGEMENT FOR HSDPA


8.1 INTRODUCTION
The HSDPA principle is to allocate the power not used by DCH calls to HSDPA
channels. This implies an accurate power management in order not to impact DCH
calls and to allow the highest data rate on HSDPA channels.
When the cell is HSUPA capable, the new DL channels associated to E-DCH (EAGCH, E-HICH and E-RGCH) request some additional power.
For power computation, described below, this DL HSUPA power is considered as part
of DCH power. Note that the power consumption for DL HSUPA is low (few
percentage of total PA power).
For simplification, in the following paragraph, DCH channels refers only to DCH
channels when HSUPA is not activated and to DCH + DL HSUPA channels when
HSUPA is activated.

8.2 HS-DSCH POWER MANAGEMENT


8.2.1 POWER ALLOCATION
8.2.1.1 RNC LEVEL
First, the RNC reserves power for common channels. Typically, the common channels
power is equal to 20-25% of the maximum cell power noted PMaxCell in the following
figure. This assumes 10% P-CPICH power fraction.
B

Note that the common channels power reserved by RNC supposed 100% activity for
each channel. That led to over-estimation in the power reservation compared to the
actual consumption at the NodeB.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 74/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
PMaxCell
SHO margin
Ptraffic
RNC

PmaxHsdpa
PminHsdpa
HSUPA
OCNS (opt.)
CCCRNC
Figure 20: Power allocation at RNC level

When OCNS is required (for cell loading during acceptance or trial tests), its power is
defined as a percentage of the power not used by common channels such as:
POCNS = (PMaxCell - PCCC) x OCNSpower
B

where OCNSpower = [0 100]%

It is possible (if Fair Sharing is disabled) to reserve a minimum power for HSDPA
noted PminHsdpa that is subtracted from the power of the DCH pool (see the Ptraffic
formula below). This power is defined through the minimumPowerForHsdpa
parameter such as:
B

PminHsdpa = PMaxCell minimumPowerForHSDPA


B

So, the higher this parameter, the lower the minimum power for HSDPA. This power is
reserved for the purpose of the Call Admission Control (CAC) at RNC and can not be
guaranteed at NodeB level if some DCH users need more power. This reservation
limits the DCH bearer admission. By reducing the number of DCH bearers, more
available power for HSDPA can be expected for the mac-hs scheduling. This minimum
power is reserved after OCNS power allocation (if OCNS is activated in the cell) and
may lead to RL reconfiguration failure for HSDPA if there is not enough power left.

Rule: Relationship between OCNS power and minimum power for HSDPA
PminHsdpa < PMaxCell - POCNS - PCCC
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 75/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Note: The activation of OCNS with HSDPA & Multiple S-CCPCH requires
modifications of OCNS default parameters. Refer to section 7.2 for more details.
U

The RNC reserves also some power for the SHO margin that is used for the
admission of the users in soft handover and can not be used for users in first
admission. This power is a percentage of the traffic power:
PSHO = (1 - callAdmissionRatio).Ptraffic
B

With:
Ptraffic = PMaxCell - PCCC * activityFactorCcch - POCNS - Pedch - PminHsdpa
B

When Fair Sharing feature is enabled, there is no need to reserve anymore minimum
power for HSDPA so above calculation becomes:
Ptraffic = PMaxCell PCCC*ActivityFactorCcch - POCNS Pedch
B

Ptraffic is the power available for both DCH and HSDPA allocations (I/B and Streaming).
B

In UA6, ActivityFactorCcch is defined by the parameter activityFactorCcch.


UA5.0-UA6.0 Delta: activityFactorCcch
In UA5.0, ActivityFactorCcch is hard coded to 66%.
In UA6.0, ActivityFactorCcch is defined by the parameter activityFactorCcch.

activityFactorCcch: For the considered cell, common channels activity factor is used
in power reservation for common channels,
Parameter

activityFactorCcch

Range & Unit


User
Class
Value

[0100] %
Customer
3
[iCEM] [xCEM] 66
[UCU-III] 36

Object

FDDCell

Granularity

FDDCell

Pedch is linked to the parameter eagchErgchEhichTotalPower (see [Vol. 4]).


B

This leads to definition of maximum power that the RNC can allocate to HSDPA
channels: PmaxHsdpa. This maximum power is computed at the RNC and given to
NodeB during the cell setup inside the physical shared reconfiguration channel NBAP
message.
B

In UA6.0, the maximum power that the RNC can allocate to HSxPA channels is
defined by:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 76/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
PmaxHspa = PMaxCell maxHspaPowerOffset
B

Parameter
Range & Unit

maxHspaPowerOffset
Integer (dB)
[0 50] step 0.1
Customer
0
0

User
Class
Value

Object

HsdpaCellClass

Granularity

FDDCell

Restriction: maxHspaPowerOffset
In UA6, parameter maxHspaPowerOffset can only be set equal to 0 dB. Other values are not
supported.

UA4.2-UA5.0 Delta: maximum power for HSxPA


Before UA5.0, the maximum power that the RNC could allocate to HSxPA channels was defined and
SHO power was not taken into account anymore because power consumption in common channels
was over-estimated at RNC (due to activity factor at RNC level being hardcoded to 100%) especially if
several S-CCPCH channels were configured. Due to this, the probability to be HSDPA power limited
was high in multi-S-CCPCH scenarios. So, the UA5.0 formula was modified such that:
PmaxHspa = PMaxCell - PCCC * ActivityFactorCcch - POCNS
B

Typically, PmaxHspa was around 60% of PA power in UA4.2 whereas it is around 80% in UA5.0 thanks to
the activity factor on common channels being 66% instead of 100%.
B

From UA5.0, the maximum power is transmitted from the RNC to the NodeB in the
information
element
(IE)
HS-PDSCH_HSSCCH_EAGCH_E-RGCH_and_EHICH_Total_Power
through
the
PHYSICAL
SHARED
CHANNEL
RECONFIGURATION MESSAGE during the cell setup. If it is not present, HSDPA
can be allocated the whole power. The number of HS-PDSCH and HS-SCCH codes
reserved in the cell are also sent through this message, in the IE HSPDSCH_FDD_code_information and HS-SCCH_FDD_code_information respectively
(see the following figure).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 77/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
PHYSICAL SHARED CHANNEL
RECONFIGURATION MESSAGE
during Cell Setup
HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICH
Total Power
HS-PDSCH_FDD_code_information
HS-SCCH_FDD_code_information
Figure 21: Physical shared channel reconfiguration message

8.2.1.2 NODEB LEVEL


iCem/xCem:
U

In a HSDPA cell, a new margin is introduced in order to anticipate power fluctuation on


DCH channel mainly due to power control and then avoid PA overload: DCH margin
(see the following figure). HSDPA channels can not use this margin. If the power for
DCH calls exceeds the DCH power margin then HSDPA will reduce its power to
provide DCH calls with power resource.

PMaxCell

NodeB

PRemain
DCH margin
E-DCH
DCH
OCNS (opt.)

PTotNonHsdpa

PTotNonHsdpaWithMargin

CCCNodeB
Figure 22: Power allocation at NodeB level

Note that the common channel consumption at NodeB level is lower than at RNC level
due to activity factor consideration.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 78/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The power consumed by this DCH margin depends on the dchPowerMargin
parameter. This parameter is a percentage of the non HSDPA power minus the PCPICH power:
PDCHmargin = dchPowerMargin.(PTotNonHsdpa PCPICH)
B

and
PTotNonHsdpa = PDCH + POCNS + PCCC + PE-DCH
B

The dchPowerMargin parameter should be tuned so that the DCH margin is large
enough to manage the power fluctuation on the DCH while ensuring at the same time
that not too much unnecessary power is reserved.

The remaining power PRemain is the power usable by HSDPA:


B

PRemain = PMaxCell PTotNonHsdpaWithMargin


B

and PTotNonHsdpaWithMargin = PTotNonHsdpa + PDCHmargin


B

Note that the common channel power used by the NodeB should be less than the
power reserved by RNC because of time multiplexing of several common channels.
UCU III:
U

For UCUIII no such margin exists and its power management is described in detail in
section 8.2.3.3.
X

8.2.1.3 POWER AVAILABLE FOR HSDPA CHANNELS


iCem/xCem:
U

Flexible power management feature consists in using for HSDPA all the remaining
power left by dedicated and common channels according to the RNC upper limit as:
PHSDPA = min(PRemain, PmaxHspa)
B

UCU III:
U

HSDPA power (used for HS-PDSCH and HS-SCCH) is bounded by an upper limit,
given by the RNC in the NBAP PHYSICAL SHARED CHANNEL
RECONFIGURATION message (PmaxHsdpa).
B

8.2.2 POWER MEASUREMENTS


The computation of the available HSDPA power requires some power measurements.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 79/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UCU III:
U

The radio measures each 2ms the overall transmitted power of the Node B and
reports these measurements to the MAC-hs scheduler (after some filtering). This
measurement is then used to estimate the available HSDPA power in the next 2ms.
This is the estimated remaining power left over by DL common channels, R99 DL
channels as well as E-DCH DL signaling channels as described.
Its maximum value is limited by the minimum of the amplifier capability and the power
signaled in the NBAP PHYSICAL SHARED CHANNEL RECONFIGURATION
message.

8.2.2.1 TRANSMITTED CARRIER POWER


iCem/xCem:
U

The transmitted carrier power PTotCell (see the following figure) is the total cell power
consumed by all codes. This transmitted carrier power is measured and
communicated within the NodeB every 100ms through a Power Management
Message (PMM) ATM cell.
B

8.2.2.2 AVERAGED HSDPA POWER


iCem/xCem:
U

The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes
PTotHsdpa (see the following figure) is computed and updated every TTI. An exponential
averaging is applied, whose coefficient is chosen to be coherent with the PMM
measurement. Every TTI, the following processing must then be done:
B

PTotHsdpa(TTI) = Rho.PTotHsdpa(TTI 1) + (1 Rho).PInstHsdpa(TTI)


B

where PInstHSDPA corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor (Rho = 0.9775 hardcoded). PTotHSDPA should be
initialized with the instantaneous value.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 80/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
PMaxCell

PMaxCell

Power
consumed by
all codes

NodeB

NodeB

HSDPA

PTotCell

Power
consumed by
non HSDPA
codes

PTotHsdpa

PTotCell

Figure 23: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)

Note that power consumed by non HSDPA codes includes, in this release, the
downlink HSUPA channels.

8.2.2.3 TOTAL NON HSDPA POWER


iCem/xCem:
U

The total power not used by HSDPA (PTotNonHsdpa) is then computed over the last
period by subtracting the total HSDPA power from the total cell power:
B

PTotNonHsdpa = PTotCell - PTotHsdpa


B

This measurement is reported (see the following figure) from the NodeB to the RNC
through a COMMON MEASUREMENT message in the element information (IE)
Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, EAGCH, E-RGCH or E-HICH transmission defined as a percentage of the max cell
power. This measurement is used by the RNC CAC on DCH (only for HSxPA cells)
instead of Transmitted Carrier Power measurement (this latest continues to be
reported and is still used for non-HSDPA cells). The measurement period is 100ms
but the report periodicity (for these two measurements) toward RNC is typically much
higher.and is configurable via OMC.

COMMON MEASUREMENT

Transmitted carrier power of all codes not used for HSPDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission
Figure 24: Common measurement
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 81/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Restriction: Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, EAGCH, E-RGCH or E-HICH transmission
In UA6.0, the NodeB will not remove the E-DCH contribution to the power measurement, leading to
slightly overestimate the R99 contribution and impact DCH call admission control. This effect can be
attenuated by increasing DCH admission threshold on power for HSUPA cells (see [R05] for details)
X

8.2.2.4 AVAILABLE HSDPA POWER


iCem/xCem:
U

The available power for HSDPA for the next 100ms period can then be computed. It
corresponds to the difference between the maximum available power in the cell
PMaxCell and the total non HSDPA power with DCH margin PTotNonHsdpaWithMargin. It is
bounded by PmaxHspa:
B

PHSDPA = min(PMaxCell - PTotNonHsdpaWithMargin , PmaxHspa)


B

with PTotNonHsdpaWithMargin = (1+ DchPowerMargin/100) * (PTotNonHsdpa - PCPICH) + PCPICH


B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 82/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
The following flowchart summarize this measurement process:

Update transmitted HSDPA


power (PTotHsdpa) any TTI

N
ATM cell received ?

PMM ATM cell reception any 100ms

Recovery in the ATM payload of the


Transmitted Carrier Power of the
corresponding cell PTotCell

PTotHsdpa

PTotCell

Computation of the Transmitted carrier


power on non HSDPA channels
PTotNonHsdpa = PTotCell - PTotHsdpa

PTotNonHsdpa

Assume a margin on the non HSDPA power.


PRem = PMaxCell PTotNonHsdpaWithMargin
Computation of the total HSDPA power available :
PHSDPA = min(PRem, PMaxHsdpa)

PHSDPA
Transmit PTotNonHsdpa every
100ms to CallP (common
measurement process)

Use PHSDPA as scheduler input


until next refresh

Figure 25: Power measurement process

8.2.2.5 HS-DSCH REQUIRED POWER


iCem/xCem:
U

A new common measurement is computed and periodically sent from NodeB to RNC
(as done for the Total Transmitted Carrier Power of all codes not used for HS-DSCH
and HS-SCCH). This measurement is the HS-DSCH Required Power. It corresponds
to the total power needed to ensure the GBR for corresponding flows of a given cell. A
value per SPI is reported.
U

Parameter
Range & Unit
User
Class
Value

hsdschReqPwReportingPeriod
[103600000] step : 10ms
Customer
3
10000 (10s)

Object

NBAPMeasurement

Granularity

MeasurementConfClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 83/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
hsdschReqPwReportingPeriod defines the reporting period for HS-DSCH Required
Power Common Measurement.
Engineering Recommendation: hsdschReqPwReportingPeriod
hsdschReqPwReportingPeriod value is chosen in order to have a tradeoff between RNC load and
QoS.
From a RNC load point of view, 10 seconds is a suitable value (mainly for heavily loaded RNC).
For RNC with a low load, hsdschReqPwReportingPeriod can be decreased (down to 2 seconds) in
order to provide some KPI improvements due to CAC being based on more accurate information.

Parameter
Range & Unit
User
Class
Value

Object
hsdschReqPwFilterCoeff
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19]
Customer
Granularity
3
3

NBAPMeasurement
MeasurementConfClass

hsdschReqPwFilterCoeff is the filtering coefficient to be applied to the common


measurements HS-DSCH Required Power.

iCEM: To derive this measurement:


U

Contribution of each flow configured in GBR is first estimated over the whole
100ms period

Then required power of all the flows with a configured GBR is aggregated per SPI.

The required power for a given flow takes into account both HS-SCCH and HSPDSCH contribution. The idea is to evaluate the total transmitted power on both
channels when the UE was scheduled with associated number of transmitted bits.
Power needed to achieve the GBR with such conditions can then be derived. In case
the UE is not scheduled during the measurement period, the estimation is done based
on averaged reported CQI instead.

xCEM: The required transmit power for a GBR queue is approximately the average
power per payload bit multiplied by the number of bits guaranteed in the measurement
interval.
U

While the guaranteed number of bits in the measurement interval can be determined
precisely, the average TX power per bit can only be approximated. It depends on the
channel conditions (CQI), on the quality of the HS-SCCH and HS-PDSCH power
estimation, on the scheduler strategy (many small MAC-hs PDUs or some large ones),
on the selected TBS (overhead of header bits and padding), on the number of
retransmissions. A good approximation might be the cumulated TX power of all HSD
transmissions done during the measurement interval divided by the cumulated number
of payload bits contained in those HSD transmissions.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 84/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UCU-III: For this measurement, the MAC-hs scheduler shall maintain an additional
cumulative counter for the HSDPA transmit power used for GBR queues. This counter
is increased by the transmit power used for the HS-PDSCH and HS-SCCH channels,
whenever a MAC-hs PDU is transmitted which contains data from a GBR priority
queue. The existing counter for the total HSD transmit power is not changed, i.e. it
contains the HSDPA transmit power for non-GBR as well as for GBR queues.
U

The MAC-hs scheduler shall include in the measurement report of the HSDPA
transmitted carrier power both values, the total HSDPA transmit power as well as the
HSDPA transmit power used for just GBR queues.
There is a new OAM parameter introduced namely addGBRTransmitPower, in order
to select which of the 2 measurement value shall be reported to the RNC, the
Transmitted carrier power of all non-HS channels or the Transmitted carrier power
of all non-HS channels and all GBR HS-channels. Depending on the setting of this
OAM parameter, the measurement controller ignores the GBR HSDPA Tx power or
adds it to the value of the Transmitted carrier power of all non-HS channels.

Parameter
Range & Unit
User
Class
Value

addGBRTransmitPower
Boolean {True, False}
Customer
3
False

Object

OneBTSEquipment

Granularity

OneBTSCell

Restriction: addGBRTranmsitPower = False


In UA6.0, RNC doesnt expect the Transmitted carrier power of all non-HS channels to include GBR
HS-channel power, so this OneBTS/UCU-III specific parameter should always be kept False.

8.2.3 HSDPA POWER DISTRIBUTION


8.2.3.1 HS-SCCH POWER
The available power for HSDPA PHSDPA is shared between HS-SCCH and HS-DSCH
channels (see the following figure).
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 85/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HS-DSCH

PHsdpa

NodeB

HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 26: Power distribution between HS-DSCH and HS-SCCH channels

A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
PHS-SCCH < PHSDPA
B

If not, the scheduler will try to schedule another user.

The power allocated to HS-SCCH is explained in section dedicated to the feature HSSCCH power control.

8.2.3.2 HS-DSCH POWER


The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH transport
channel:
PTemp = PHSDPA PHS-SCCH
B

On the one hand, HSDPA UE needs to have a power reference in order to adapt its
reported CQI to the radio link condition (in the same radio condition, the reported CQI
will be higher if more power is used to transmit the HS-DSCH channel). As specified
by 3GPP ([R02]), UE has to compute its CQI in order to assure a BLER first
transmission equal to 10% by assuming that NodeB sends its HS-DSCH with the
following reference power:
X

PHS-DSCH reference[dBm] = PP-CPICH[dBm] + [dB] + (CQIreported)[dB]


B

Note that CQI computation by the UE is totally independent from the HS-DSCH
scheduling by the NodeB, since UE has no information concerning CQI processed and
algorithms used by the NodeB. That is why UE reports a CQI even if this UE is not
scheduled by the NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 86/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
On the other hand, NodeB computes a modified CQI (noted CQIprocessed or AMC) to
ensure a transmission with a given BLER target (cf section 6.1) assuming a downlink
power equals to:
B

PHS-DSCH[dBm] = PP-CPICH[dBm] + [dB] + (CQIprocessed)[dB]


B

where

PP-CPICH is the power of the P-CPICH channel,

is the measurement power offset

is the reference power offset given by the reference tables of CQI [R02].

The power PHS-DSCH is defined by a power offset compared to the P-CPICH power.
This power offset corresponds to the measurementPowerOffset parameter. The
mobile is able to compute this reference power thanks to the P-CPICH power
measurement
and
to
the
measurementPowerOffset
parameter.
The
measurementPowerOffset parameter is sent from the RNC to the NodeB through the
HS-DSCH
FDD
INFORMATION
message
during
the
Radio
Link
Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HSPDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration
(see the following figure). In case this parameter is not present in the setup message,
the configuration must then be rejected.
B

HS-DSCH FDD
INFORMATION
during Radio Link
Setup/Reconfiguration

DOWNLINK HS-PDSCH
INFORMATION
during Radio Bearer
Setup/Reconfiguration

measurementPowerOffset
Figure 27: measurementPowerOffset transmission

In fact, this power can be seen as the HS-DSCH power required by the mobile
corresponding to its reported CQI. From a NodeB point of view, this power is the
maximum power that can be allocated to one HSDPA user even if more power could
be used (Note that for CQI lower than 5 the allocated power may be higher see the
column Power offset of Table 1 and Table 2).
X

Note that the reference power offset is the one corresponding to the processed CQI
(CQIprocessed) and not the reported CQI (CQIreported). See CQI section for more details.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 87/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.2.3.3 HS-PDSCH POWER
iCEM:
U

The HS-DSCH power is equally distributed between all the physical channels HSPDSCH:
PHS-PDSCH[dBm] = PHS-DSCH[dBm] - 10.log(#codes)
B

xCEM/UCU III:
U

The SNR estimation of one HS-PDSCH depends on the available power for one HSPDSCH. Assuming that the power is uniformly distributed over all codes (NHS-PDSCH)
that are available for HSDPA, the available power for one HS-PDSCH (for user u from
the ranking list) is:
B

PavailableHS-PDSCH(u) = (PHSDPA PHS-SCCH(u)) / NHS-PDSCH


B

Where:
-

PHSDPA is the power that is available for HSDPA

PHS-SCCH(u) is the allocated power for HS-SCCH channel of user u

NHS-PDSCH is the number of HS-PDSCH codes computed as below.

If more than one user to be scheduled for the next TTI, then NHS-PDSCH is equal to the
total number of HS-PDSCH codes (Ntotal). Else, NHS-PDSCH is the minimum between the
total number of HS-PDSCH codes and the UE capability (Nue capability) in other words,
the maximum number of HS-PDSCH that a UE of a given category can manage:
B

NHS-PDSCH = min(Ntotal; Nue capability)


B

For UCU III, Ntotal is the number of HS-PDSCH codes configured by the NodeB due to
Fairsharing being activated by default.
B

For xCem, Ntotal is:


B

Ntotal = min(Nconfigured; SumNue capability)


B

Where:
-

Nconfigured is the number of HS-PDSCH codes configured (internal or


external PSCR message).

SumNue capability is the sum of the UE capability of the


numberOfHsScchCodes first users at the top of the ranking list of
the previous TTI.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 88/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH

PHS-DSCH

HS-SCCH

PHS-SCCH

Dch Margin
R99
CCC
Figure 28: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH

Note that a user can be scheduled only if its available HS-PDSCH power PavailableHSPDSCH(u) is positive, otherwise the next user of the ranking list shall be selected.
B

Available HSDPA power and available number of HS-PDSCH codes have to be


updated after a user u has been scheduled by reducing the total resources by the
resources allocated to user u:
PHSDPA New = PHSDPA PHS-DSCH(u) PHS-SCCH(u)
B

NHS-PDSCH New = NHS-PDSCH nHS-PDSCH(u)


B

Before starting to schedule users, scheduler needs to know the total power it can use
for HSDPA according to R99 traffic usage. As with iCEM, total power usable by the
scheduler may be limited by the RNC (see PmaxHsdpa computation in section 8.2.1.1).
B

At nodeB level, with xCEM, a minimum percentage of power for HSDPA can be
defined through the parameter hsdpaMinAmpUsage. A percentage of the cell power
can also be taken into account to compute the remaining power (power not used by
non HSDPA channels) through hsdpaAmpUsage. Then, the total power usable for
HSDPA is:
PHSDPA total =
B

min(max(hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin;
B

hsdpaMinAmpUsage.Pmax); PmaxHsdpa)
B

where:
-

PTotNonHsdpaWithMargin is the power used by non HSDPA channels with DCH


margin (see section 8.2.1.2 for more details).
B

Pmax is the maximum power of the cell.

PmaxHsdpa is maximum power for HSDPA computed by RNC and sent to


NodeB through NBAP message (see section 8.2.1.1)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 89/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Pmax
hsdpaAmpUsage.Pmax

HSDPA

PHSDPA
= hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin

Dch Margin
R99

PTotNonHsdpaWithMargin

CCC
Figure 29: hsdpaAmpUsage parameter

Parameter
Range & Unit
User
Class
Value

hsdpaAmpUsage
[0100] %
Customer
3
100

Object

HsdpaConf

Granularity

BTSCell

Parameter
Range & Unit
User
Class
Value

hsdpaMinAmpUsage
[0100] %
Customer
3
0

Object

HsdpaConf

Granularity

BTSCell

UCU III:
U

HSDPA power is allocated dynamically, that is to say that HSDPA will use all the
remaining power so that the amplifier capability can be fully exploited and more power
can be allocated to HSDPA if no R99 calls are active. However, this allocated power is
not reserved for HSDPA. The power control functionality of R99 in the Node B is not
aware what amount of power has been allocated to HSDPA. If not all the HSDPA
power is allocated or if no HSDPA users are active, this power can be utilized for R99
channels. On the other side, power being allocated to HSDPA channels does not limit
the R99 power. The inner loop R99 power control is unaffected.
The principle of dynamic power allocation is shown in the figure below.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 90/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Amplifier Capability

R99 Power

HSDPA Power
Overhead Power
Figure 30: Dynamic Power Allocation

The NodeB dynamic power allocation allocates the power to HSDPA until the amplifier
capability is reached. The OMC-B parameter hsdpaAmpUsage allows limiting the
overall power being consumed by common channel, R99 and HSDPA. Currently the
default value is set to 80% of the amplifier capability, i.e. to 32 watts for a 40 watts
amplifier.
Also the minimal power for HSDPA allocated by dynamic power allocation can be
controlled in the OMC-B by the parameter hsdpaMinAmpUsage. The default is
currently set to 10%, i.e. if R99 power consumption is high no power may be left to
HSDPA. Setting this value to a non-zero value (x > 0) allocates at least x% of the
amplifier power to HSDPA. This helps to avoid stalling of the HS-DSCH throughput if
the R99 load is large.
As the traffic load in downlink direction increases, the demanded power for HSDPA
and R99 may exceed the amplifier capability of the Node B. This can happen if the
R99 and the common channel power exceed the amplifier capability. In order to
maintain signal quality of existing calls and to prevent the amplifier from overheating,
the Node B applies Aggregate Overload Control (AOC). AOC acts on R99 and
HSDPA signals in the same way. P-CPICH is not affected by AOC scaling. With
dynamic power allocation, the occurrence of amplifier overload is not expected in
normal circumstances since the HSDPA power is adjusted according to the R99 load.
If the default value of hsdpaAmpUsage is increased, AOC as described below may be
activated to prevent the amplifier from overheating. Therefore it is not recommended
to increase the value beyond default of 80%.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 91/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

hsdpaAmpUsage
[0100] %
Customer
3
80

Object

OneBTSEquipment

Granularity

OneBTSCell

Parameter
Range & Unit
User
Class
Value

hsdpaMinAmpUsage
[0100] %
Customer
3
10

Object

OneBTSEquipment

Granularity

OneBTSCell

8.2.4 POWER MANAGEMENT


This section concerns only the iCem platform. The HSDPA UE requests to the NodeB
a CQI corresponding to a reference power PHS-DSCH. The power effectively available at
NodeB level can be lower than this requested power. Then power adjustments are
needed. Other resource limitations such as codes limitation can also lead to
adjustment of the HS-DSCH power. The following section presents how the scheduler
manages the HS-DSCH power according to the available resources.
B

8.2.4.1 FIRST TRANSMISSION


The transport formats are always based on the CQI mapping tables. Two different CQI
correspond to different transport formats with the same power to reach the same
performance level, but could also correspond to two different powers with the same
transport format. A step of 1dB is considered to go from one CQI to the next one.

The transport format is determined according to the processed CQI, CQIprocessed. In


case of a lack of resources (codes or power), the applied CQI, CQIapplied, is then
modified according to the previous rule to take this into account. It is done in four
steps:
B

Power limitation management,

Codes limitation management,

Lack of MAC-d PDU in buffer or transport block size limitation (multi-cell per
H-BBU for instance),

Optimization of CQI according to MAC-d PDU size.

The whole process is described in the following figure:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 92/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UE selected
Ptemp = PHSDPA PHS-SCCH
PHS-DSCH = PP-CPICH +

RP = round(10.log(Ptemp / PHS-DSCH))
CQI1 = CQIprocessed + RP

RP = 0

CQI1 = CQIprocessed

ncodes = f(CQI1)

UE not scheduled

RC = 0

CQI2 = CQI1

N
Select the highest CQI (CQI2) which number
of codes equals the remaining number of
codes
RC = CQI2 CQI1

Enough PDU available ?


TrBlk size manageable ?

N
Select the highest CQI (CQI3)
fulfilling both criteria

RO = 0
CQI3 = CQI2

Code limitation
management

nCodes <
nCodesRemain ?

CQI1 > 0 ?

Other limitation
management

PHS-DSCH < Ptemp ?

Power limitation
management

PHS-DSCH = PP-CPICH + + (CQIprocessed)

CQIapplied = f(CQI3, MAC-d PDU size)


RCqi = CQIapplied CQI3

CQI optimization
management

RO = CQI3 CQI2

PHS-DSCH = PP-CPICH + + (CQI3) + RP + RC + RO + RCqi


PHS-DSCH = min(PTemp, PHS-DSCH)
PRemain = PTemp PHS-DSCH
[nCodes, nPDU] = f(CQIapplied)

UE scheduled

Figure 31: HS-DSCH power management for 1st transmission


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 93/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.2.4.1.1 POWER LIMITATION
In case there doesnt remain enough power to transmit data corresponding to the
processed CQI to a selected UE, the transport format is modified in order to reduce its
power (Ptemp refers to the available power at NodeB level and PHS-DSCH to the needed
power by the UE). The excess power, corresponding to the total needed power minus
the maximum allowed power, is computed (RP). This value, expressed in dB, then
directly indicates the number of CQI levels one should decrease in order to remain at
the same level of performance. In case the resulting value is not valid CQI (0), the
UE is not scheduled; otherwise the new configuration is the one considered for the
next step. Note that in case the initial processed CQI is such that the associated
reference power adjustment () is non-zero (depending on UE category and
associated CQI mapping table given in [R02]), the CQI decrease (as described in the
previous figure) must not be considered for such user in that instance.
B

8.2.4.1.2 CODES LIMITATION


If the resulting configuration, corresponding to the derived CQI from the previous step
(CQI1), leads to a number of necessary HS-PDSCH codes higher than the remaining
ones, the CQI is also reduced in order to reach the exact number of remaining codes.
A power offset equal (in dB) to the difference between the input and output CQI is then
applied (1dB per CQI rule). Note that if this power reduction leads to a power less than
the minimum manageable by the H-BBU, it is then set to this minimum power.
B

8.2.4.1.3 OTHER LIMITATIONS

Less available PDUs than required

In case there are less MAC-d PDU available in the buffer than what would have
allowed the scheduler to transmit relative to the derived CQI from previous steps
(CQI2), the configuration is then chosen to match to the lowest CQI (CQI3) that
enables to transmit this number of PDU (see the following figure). The power must, of
course, be decreased accordingly with the same rules as before.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 94/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Mac-hs transport block(CQI2)
Mac-d PDU

21

320

16

320

16

Padding

Mac-hs transport block(CQI3)


Mac-d PDU

21

320

16

320

16

Padding

Figure 32: MAC-hs transport block adaptation according to the number of MAC-d PDU to
transmit

Limited processing resource

The processing resource may be limited in the H-BBU pool configuration for instance.
All transport block sizes may not be handled. In case the one corresponding to the last
processed CQI is not manageable, the CQI is reduced to the highest one that fits with
the available resources. The power is also decreased accordingly.

8.2.4.1.4 CQI OPTIMIZATION ACCORDING TO MAC-D PDU SIZE


A last optimization is considered according to the resulting CQI from previous steps
(CQI3). Indeed, the MAC-d PDU size may not allow all CQI to be used or may lead to
an un-optimized solution. According to the MAC-d PDU size, the rules described
below must apply:
B

For MAC-d PDU size of 336 bits:

CQI 0: means that the mobile considers it is out of range. In such case no
data for this specific user is scheduled by the MAC-hs

CQI 1 to 4: in this case, the MAC-hs consider the mobile has reported a CQI
5. The scheduler relies on a power adjustment on HS-PDSCH and on the
HARQ repetitions to cope with low radio link quality (+1 dB per CQI value
rule).

CQI 5 is processed normally.

CQI 6, 7 (and resp. 9): in this case the MAC-hs considers the mobile has
reported a CQI 5 (resp. 8) to minimize padding. The scheduler decreases the
power requirement on HS-PDSCH (-1dB/CQI rule).

CQI 10 to 30: are processed as described in Table 1, decreasing power


requirements by 1 dB per CQI when the UE is addressed using a lower MCS
than the reported CQI (because of power shortage or because UE capabilities
are reached)
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 95/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
For MAC-d PDU size of 656 bits:

CQI 0: means that the mobile considers it is out of range. In such a case no
data for this specific user is scheduled by the MAC-hs

CQI 1 to 7: in this case, the MAC-hs consider the mobile has reported a CQI
8. The scheduler relies on a power adjustment on HS-PDSCH and on the
HARQ repetitions to cope with low radio link quality (+1 dB per CQI value
rule).

CQI 8, 11, 13 are processed normally.

CQI 9, 10 (and resp. 12 or 14 or 20): in this case the MAC-hs considers the
mobile has reported a CQI 8 (resp. 11 or 13 or 19) to minimize padding. The
scheduler lowers the power requirement on HS-PDSCH (-1dB/CQI).

CQI 15 to 30 (except 20): are processed as described in Table 2, decreasing


power requirements by 1 dB per CQI when the UE is addressed using a lower
MCS than the reported CQI (because of power shortage or because UE
capabilities are reached)
X

8.2.4.1.5 HS-DSCH POWER EVOLUTION


The above sections dealt with the situation where resource limitation can impact CQI
handling. However in UA5.0 and previous releases, implemented power management
may also lead to some unused power in NodeB in some situations (especially in mono
UE and high CQI situations).
The purpose of this UA6.0 feature is to improve the power management in NodeB
such that not to leave unused power in the situations where the remaining power can
be allocated to the UEs increasing their applied MCS.This feature only concerns iCEM
because the power management in xCEM is different and this behaviour is already
incorporated in its scheduler.
The scheduler first performs a preliminary scheduling, and resource allocation as in
UA5.0, serving priority queues (QID) up to their post BLER adjustment CQI, as shown
in Figure 31. This guarantees a minimum performance level on a par with UA5.0.
X

If there are any remaining resources (power, codes and CPU) left after the first
scheduling stage, a second resource allocation is carried. Remaining resources are
allocated first to the QID on top of the list of already scheduled QID in the TTI. If there
are remaining resources, these are allocated to next QID and so on. The reallocation
of resources is performed as following:

1 dB increase in power is associated to 1 CQI increase, up to the maximum MCS


of the UE (maxCQIcategory). We also do not increase the CQI if we are already
stuck at the maximum CQI.

This process is iterated, until there are no more remaining resources to allocate to
QIDs, or nor more QIDs to serve.

If the remaining power is less than 1 dB, it is allocated to the QID if it leads to
MCS increase.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 96/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter Settings
Parameter
Range & Unit
User
Class
Value

hsdpaFullPowerUsage
Boolean {True, False}
Customer
3
True

Object

HsdpaConf

Granularity

BTSCell

Engineering Recommendation: hsdpaFullPowerUsage


The recommendation is to enable the feature Power Evolution by setting hsdpaFullPowerUsage to
True.
Nevertheless, the expected gain of this feature depends on :
- the value of the P-CPICH power and the measurementPowerOffset (P-CPICH power +
measurementPowerOffset defines the maximum power for a HS-DSCH).
- the number of HSDPA users scheduled per TTI.

The gain will be higher when the maximum power for a HS-DSCH is low and when only one user is
scheduled per TTI.

8.2.4.2 RETRANSMISSION
iCem:
U

The same AMC as first transmission is applied for retransmissions, i.e. same transport
block size, number of HS-PDSCH codes and modulation. Besides, in UA4.2 the same
power was also applied if possible.
The purpose of the feature HSDPA performance enhancement Power adaptation
for HARQ retransmissions is to adapt the power of retransmissions to new radio
conditions, in order to improve decoding probability while saving power when possible.
In case of erroneous CQI decoding for the initial transmission, it also allows to recover
retransmissions.
A power offset with respect to initial transmission is computed and depends on CQI
variation or retransmission index. It is a linear function of the CQI difference:
Power_offsetdB = (CQI1st CQIret)*Step Const.
B

Step is positive real number; it helps handling the erroneous CQI and allows
consuming right power according to new conditions. Const illustrates the gain
brought by redundancy versions re-combining and should be positive; a negative
value could also be set to enforce first retransmission to be decoded while consuming
maybe unnecessary power.
Default current values provided by studies are: Step = 0.5; Const = 3.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 97/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Note that the CQI of the first transmission corresponds to the reported one (including
DeltaCqi adjustment) and not the applied one. Indeed, it is important to compensate
radio condition variations so reported CQI illustrates this. Once the offset is computed,
it is applied on top of the applied power of the first transmission as scheduler rules
should have adapted the transport format and related power in order to keep constant
the QoS.

To activate this feature, it is proposed to use the harqType parameter as well.


4 values are currently defined: MIR/PIR/CC/DR (see definition in [Vol. 2])
corresponding to 1/2/3/4.
X

As the power adaptation is independent of the HARQ type selected, 4 new values are
defined to activate or not power adaptation with any HARQ Type. The following coding
is then performed:
- If harqType < 10, no power adaptation
- If harqType 10, power adaptation is activated and harqType = harqType-10
The fourth new following values are then introduced:

MIRwithPowerAdaptation (11)

PIRwithPowerAdaptation (12)

CCwithPowerAdaptation (13)

DRwithPowerAdaptation (14)

Note that Step and Const cannot be changed as theres no available parameter at
OMC-B.

Parameters Settings:
Parameter
Range & Unit

Object
HsdpaConf
harqType
[mirType, pirType, ccType, drType, MIRWithPowerAdaptation,
PIRWithPowerAdaptation, CCWithPowerAdaptation,
DRWithPowerAdaptation]
Customer
Granularity
BTSCell
3
mirType

User
Class
Value

xCem:
U

As explained in [R05], the TFRC selection is done through a Look Up Table (LUT).
The MAC-hs scheduler uses a different LUT for first transmission and retransmissions
(and for MAC-d PDU size of 336 bits and 656 bits). In case of HARQ retransmission,
the transport block size is not changed from the initial transmission ([R05])
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 98/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.2.4.3 MULTI-USERS PER TTI
Once a user has been chosen to be scheduled at the next TTI, the MAC-hs scheduler
checks that there is enough remaining power for the HS-SCCH. If it is not the case
then it tries to schedule a different user. After HS-SCCH power has been allocated,
the scheduler computes the remaining power that can be used for HS-DSCH (as
described in the previous section). Once a user has been scheduled, the scheduler
will try to serve another user in the same TTI with the power that remains (PRemain in
the following figure), provided there is still a free HS-SCCH code for this TTI.
B

PRemain

NodeB

HS-DSCH
HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 33: Remaining power for multi-users per TTI scheduling

Note: When several HSDPA users are scheduled in the same time interval and when
all the PA is used (due to R99 users or due to high measurementPowerOffset
value), HS-SCCH blocking may appear if HS-SCCH power allocated for one user is
not constant between two TTI (because HS-SCCH and HS-PDSCH are not aligned in
time (2-slots delay)). In this case, one of the users has not enough power for its HSSCCH and cannot be scheduled anymore. In order to avoid this issue, a power check
has been introduced since UA5.0 in order to be sure to have enough power for the
HS-SCCH.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 99/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.3 HS-SCCH POWER MANAGEMENT
iCem:
U

The aim of this feature is to adjust, according to the radio condition, the power
allocated to HS-SCCH in order

to save power for data or other UE,

to have a good detection probability of HS-SCCH

HS-SCCH power control is not a true power control mechanism but rather a power
mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is
derived from the reported CQI (noted CQIreported), not from CQI adapted by the NodeB
in anyway, in order to adapt the transmission power to actual reported radio
conditions. This is configured in a table that gives a power offset relative to P-CPICH
for each CQI such as:
B

PHS-SCCH = PP-CPICH + hsScchPcOffset(CQIreported)


B

where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each
CQI (see the following figure).

CQIreported

hsScchPcOffset relative to PCPICH Power

hsScchPcOffset(1)

hsScchPcOffset(2)

.
30

hsScchPcOffset(30)

Table 7: HS-SCCH power offset table according the reported CQI

Disabling the power control consists in setting all hsScchPcOffset to the same value.
The following figure summarizes the HS-SCCH power control:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 100/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
CQIReported

CQ

hsScchPcOffset(CQIReported)

PHS-SCCH = PP-CPICH + hsScchPcOffset(CQIReported)


Figure 34: HS-SCCH power control overview

Rule: Dependency between hsScchPcOffset and measurementPowerOffset


The hsScchPcOffset parameters depend on the CQI reported by the UE to the NodeB. However the
UE computes his CQI according to the measurementPowerOffset parameter which defines the
reference power. Then hsScchPcOffset parameters have to be linked to a
measurementPowerOffset value. If the measurementPowerOffset increases of 1dB, the
hsScchPcOffset table has to be shifted by 1 unit.
Here is a table summarizing hsScchPcOffset values according to measurementPowerOffset :
hsScchPcOffset

CQI

MPO = 5 dB

MPO = 6 dB

MPO = 7 dB

MPO = 8 dB

MPO = 9 dB

-3

-3

-3

0
0

-5

-3

-3

10

-5

-5

-3

-3

11

-5

-5

-5

-3

-3

12

-8

-5

-5

-5

-3

13

-8

-8

-5

-5

-5

14

-8

-8

-8

-5

-5

15

-8

-8

-8

-8

-5

16

-8

-8

-8

-8

-8

17

-8

-8

-8

-8

-8

18

-8

-8

-8

-8

-8

19

-8

-8

-8

-8

-8

20

-8

-8

-8

-8

-8

21

-8

-8

-8

-8

-8

22

-8

-8

-8

-8

-8

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 101/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
23

-8

-8

-8

-8

-8

24

-8

-8

-8

-8

-8

25

-8

-8

-8

-8

-8

26

-8

-8

-8

-8

-8

27

-8

-8

-8

-8

-8

28

-8

-8

-8

-8

-8

29

-8

-8

-8

-8

-8

30

-8

-8

-8

-8

-8

xCEM/UCU III:
U

Once a user has been selected from the ranking list, the scheduler computes the
power needed (to have a good probability of detection) for the HS-SCCH channel of
this user.
With xCEM, the transmit power of HS-SCCH for each scheduled user is calculated so
that the SNR of the HS-SCCH at UE side shall be equal to hsscchSnr.
Parameter
Range & Unit
User
Class
Value

hsscchSnr
[-5.019.0] dB (step .1)
Customer
3
1

Object

HsdpaConf

Granularity

BTSCell

Note that for the first implementation of the xCem, the recommendation for
hsscchSnr was 5dB in order to avoid a too low HS-SCCH power for high CQI since
no minimum power was defined. Today, a minimum power is defined for HS-SCCH
(see below), allowing to reduce the value of hsscchSnr.

With UCU III, the transmit power of HS-SCCH for each scheduled user is calculated
so that the SNR of the HS-SCCH at UE side shall be equal to hssccSnr.

The computation of the HS-SCCH power is based on the most recent SNRMAP,dB from
CQI SNR mapping for each user, taking into account that HS-SCCH uses an
SF128 :
B

PHS-SCCH = hsscchSnr + PP-CPICH + SNRMAP,dB 10.log10(128/16) + 5dB


B

Where:
-

PP-CPICH is the transmitted power of the P-CPICH (in dBm).

is the measurement power offset.

Note that for xCem (not applicable for UCU III):


-

the maximum value for HS-SCCH power is P-CPICH power + 2dB

the minimum value for HS-SCCH power is P-CPICH power - 8dB

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 102/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.4 PARAMETERS SETTINGS AND RECOMMENDATIONS
The following section gives the properties of the parameters described previously.

Parameter
Range & Unit
User
Class
Value

dchPowerMargin
Integer (%)
[0 100]
Customer
3
20

Object

HsdpaConf

Granularity

BTSCell

Engineering Recommendation: dchPowerMargin versus cell load


The recommended value for dchPowerMargin is set to 20% for high cell load. At low load, 10% could
be used due to smaller power fluctuation.

Parameter
Range & Unit
User
Class
Value

Object
HsdpaConf
hsScchPcOffset
List[1..30]
[-28.0..28.0] dB
Customer
Granularity
BTSCell
3
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -3.0 -3.0 -5.0 -5.0 -5.0 -8.0 -8.0 -8.0 -8.0 8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0

Rule: hsScchPcOffset relationship with pCpichPower & MaxTxPower


For each value of the list of hsScchPcOffset, the following relationship must be verified:
HsScchPcOffset + pCpichPower maxTxPower 35 dB

Engineering Recommendation: Power consumed by HS-SCCH codes


The number of HS-SCCH codes numberOfHsScchCodes defines the number of UE that could be
scheduled during a TTI. When a UE is scheduled, the HS-SCCH channel requires up to about 10% of
PA power. If n UE are scheduled during a TTI, n*10% of PA power is needed.

Parameter
Range & Unit
User
Class
Value

minimumPowerForHsdpa
Integer (dB)
[0.0 50.0]
Customer
0
Unset or 50.0 (= 50.0dB)

Object

HsdpaCellClass

Granularity

FDDCell

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 103/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Engineering Recommendation: minimumPowerForHsdpa
The recommendation is that no power has to be reserved for HSDPA. Two solutions are possible:
1) minimumPowerForHsdpa = 50dB so that the minimum power reserved for HSDPA is very
low (ex : PminHsdpa = PMaxCell minimumPowerForHsdpa = 45dBm 50dB = -5dBm = 0.3mW).
B

2) minimumPowerForHsdpa = unset so that no minimum power is reserved for HSDPA.

Rule: Minimum value for parameter minimumPowerForHsdpa


If the minimum value of this parameter is used in order to reserve entire power for HSDPA (which is
not recommended), there will be a conflict between power allocated to common channels and power
reserved for HSDPA (see details about power reservation formula in chapter 8.2.1.1). Also, there will
be not enough power in the cell to setup an SRB. This will forbid any HSDPA call establishments.
U

In order to allow HSDPA calls, following formula has to be used to compute the minimum value for this
parameter:
minimumPowerForHsdpaMin = Pccc + PSRB
B

See [R01] for details about power reservation for CCs and SRBs.
X

Parameter
Range & Unit

measurementPowerOffset
Integer (0.5 dB)
[-12..26]
Customer
3
15 (= 7.5dB)

User
Class
Value

Object

HsdpaUserService

Granularity

HsdpaUserService[0..14]

Engineering Recommendation: measurementPowerOffset


measurementPowerOffset parameter defines the reference power used by the UE to compute its
CQI and the maximum power that the NodeB can allocated to one UE. The value 7.5 dB allows to
allocate up to about 60% of PA power (PA = 45dBm and Cpich power = 35dBm) for the HS-DSCH
channel. A lower value favours the scheduling of 2 UE per TTI by limiting the power per HSDPA user.
For first deployments, the probability to have 2 UE scheduled in the same TTI will be low. Then with
this value, the HSDPA user throughput is not limited by power.
It is recommend to avoid setting the measurementPowerOffset to a too high value to avoid power
limitation but high enough to optimize the HSDPA capacity, the following rule should be taken into
account:
0.8.PA > Log2lin(pcpichPower + measurementPowerOffset)
This rule allows to respect the following BTS check:
PHS-DSCH = PP-CPICH + measurementPowerOffset <= MaxTxPower
B

If this condition is not satisfied then the HSDPA call is not setup

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 104/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Rule: [iBTS] Power checks at NodeB level
iBTS:
U

Internally to the NodeB, several power checks are performed in order to guarantee that power settings
are compliant with NodeB capabilities. To avoid any issue, HSxPA power settings must fulfill the
following rules.

HSDPA rules:
U

(1) PHS-SCCH(CQI) PmaxHspa whatever the CQI


B

(2) Pccc + PHS-SCCH(CQI) Max Tx Power whatever the CQI


With, for the considered cell Fx, Max Tx Power (Fx) =Min { maxTxPower (Fx) ; Max Dl Power
Capability (Fx) } (cf. Vol.7, section related to the feature 29808 - Multi-Carrier PA Power Pooling).
B

(3) PHS-SCCH(CQI) Max Tx Power - 35 dB


B

(4) Max Tx Power 35dB PmaxHspa Max Tx Power


B

E-DCH rules (these rules apply to each E-DCH UE):


U

(5) Pccc + PHS-SCCH(CQI) + eAgchPower + eHichPower + eRgchPower Max Tx Power whatever the
CQI
B

(6) PE AGCH Max Tx Power - 35 dB


With PE AGCH being the power allocated to the considered E-AGCH channel.
B

(7) PE HICH signature Max Tx Power - 35 dB


With PE HICH signature being the power allocated to the E-HICH signature of the considered user.
B

(8) PE RGCH signature Max Tx Power - 35 dB


With PE RGCH signature being the power allocated to the E-RGCH signature of the considered user.
B

With
(9) PHS-SCCH(CQI) = PP-CPICH + hsScchPcOffset(CQI)
B

(10) Pccc = PP-CPICH + max {Pccpch, (PP-sch+PS-sch)}


B

Note that above formulas are expressed in linear scale, except (3), (4), (6), (7), (8), (9) which are
expressed in logarithmic scale.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 105/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
8.5 UA6 MANAGEMENT OF UL POWER PROFILES DEPENDING
ON WHETHER HSDPA IS MAPPED ON THE DL
8.5.1 INTRODUCTION
When performing high data rate downlink transfer on HSDPA (e.g. HSDPA Category 8
UE with 656 bits MAC-d PDU performing DL FTP), the application-level UL ACKs
must reach the application server with short delay and at a regular pace, i.e. without
bursts. Indeed, if a burst of application-level UL ACKs (e.g. TCP UL ACKs) is received
by the server, the server may transmit on downlink a large amount of data at the same
time. If this data transmitted on downlink excesses the core network bandwidth, DL
application-level packets are lost, which leads to application-level retransmissions.
Such application-level retransmissions may have an significant impact on DL
throughput and user experience.
Regarding the case of a call with HSDPA in the downlink and DCH in the uplink, it has
been observed that bursts of application-level UL ACKs occur when UL radio quality is
degraded (UL radio BLER higher than target BLER) even for a short period of time.
Indeed, if UL radio quality is degraded, UL RLC retransmissions occur. Since RNC
waits for retransmitted RLC-PDUs before transmitting data to the server (InSequence-Delivery mechanism), such UL RLC retransmissions results in a burst of
application-level UL ACKs sent to the server.
Regarding the case of a call with HSDPA in the downlink and E-DCH in the uplink, it
has also been observed that bursts of application-level UL ACKs occur when UL radio
QoS is degraded (average NHARQ number of HARQ retransmissions higher than
target NHARQ) even for a short period of time. Indeed, if UL radio quality is degraded,
UL HARQ retransmissions occur, leading to MAC-es PDUs arriving in disorder at
RNC. Since RNC performs reordering of MAC-es PDUs (as of 3GPP), such UL HARQ
retransmissions result in a burst of application-level UL ACKs sent to the server.
B

[iCEM] [xCEM] [UCU-III]


In UA6, Management of UL power profiles depending on whether HSDPA is mapped
on the DL sub-feature of UA6 34246 Power Control Enhancements feature allows
improving UL radio quality for calls with HSDPA high data rate in the downlink, thus
avoiding the issue of bursts of application-level UL ACKs, which improves DL
throughput and user experience. Note that this sub-feature applies to both Global
Market and USA market.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 106/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
UA5.1-UA6 Delta: Management of UL power profile for HSDPA calls

In UA5.1, the management of UL power profile (lower bound for UL SIR Target) for HSDPA
calls was handled by UA5.1.2 High quality UL R99 RAB for High HSDPA DL data rate (34652)
feature.

In UA6, the management of UL power profile (initial value, lower bound and upper bound for UL
SIR Target) for HSDPA calls is handled by Management of UL power profiles depending on
whether HSDPA is mapped on the DL sub-feature of UA6 34246 Power Control
Enhancements feature. Management of UL power profiles sub-feature of UA6 34246
includes all the functionalities of UA5.1.2 34652 regarding the upper bound for UL SIR Target,
and introduces the same concept for the initial value and the lower bound.

Remark: The set of parameters used by each of above two features is different.
U

For DL FTP data transfer, UL radio quality strongly impacts the TCP layer when UL
TCP ACKs are delayed or lost. Hence, Management of UL power profiles subfeature brings important improvement to DL throughput and user experience in this
case.
And for DL UDP streaming, UL radio quality is less impacting compared with DL FTP
data transfer, because high layer acknowledgement of data received by the mobile is
not performed. However, Management of UL power profiles may improve the
transmission of UDP signaling in the uplink, thus bringing some improvement on user
experience.

8.5.2 FEATURE DESCRIPTION


For the HSDPA UE categories (e.g. HSDPA Category 8 UE) specified by the operator,
and when in HSDPA call (i.e. when a PS HS-DSCH DL RB is established),
Management of UL power profiles depending on whether HSDPA is mapped on the
DL sub-feature of UA6 34246 Power Control Enhancements allows using a specific
set of parameters for UL SIR Target initial value, lower bound and upper bound:
initialSirTargetHsdpa, minSirTargetHsdpa and maxSirTargetHsdpa. These
parameters can be set per UL service.
Note that in UA6, the default set of parameters (i.e. when in DL R99 call) for UL SIR
Target initial value, lower bound and upper bound is: initialSirTarget, minSirTarget
and maxSirTarget. These parameters can be set per UL service.
Management of UL power profiles sub-feature can be activated/deactivated at cell
cluster level, via eligibleUeCategoryForSirTargetHsdpa parameter under
PowerConfClass object.

CONDITIONS FOR APPLYING HSDPA-SPECIFIC UL POWER PROFILE


For a given call, system applies the HSDPA-specific UL power profile (i.e.
initialSirTargetHsdpa, minSirTargetHsdpa, maxSirTargetHsdpa) corresponding to
the currently established UL service if the following conditions are true:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 107/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Current call is an HSDPA call (i.e. a PS HS-DSCH DL RB is established).

HSDPA UE Category is eligible for Management of UL power profiles subfeature.


Eligible HSDPA UE Categories can be set via
eligibleUeCategoryForSirTargetHsdpa parameter.
The method for setting eligible HSDPA UE Categories is described in 8.5.3.
X

8.5.3 PARAMETERS SETTINGS AND RECOMMENDATIONS


eligibleUeCategoryForSirTargetHsdpa: Sets the HSDPA UE Categories that are
eligible for Management of UL power profiles depending on whether HSDPA is
mapped on the DL sub-feature of UA6 34246, i.e. HSDPA UE Categories for which
an HSDPA-specific UL power profile is applied.
Parameter

eligibleUeCategoryForSirTargetHsdpa

Object

PowerConfClass

Granularity
Range & Unit

PowerConfClass
Bit string (64 bits), N/A

User & Class

Customer, 3

Value

0000000000000000000000000000000000000000000000000000001111000000

Engineering Recommendation: eligibleUeCategoryForSirTargetHsdpa


This parameter defines the HSDPA UE Categories eligible for Management of UL power profiles
sub-feature. Having defined bit #0 as the LSB (least significant bit) i.e. the bit at the right edge of the
bit string, bit #0 corresponds to Category 1 and bit #11 corresponds to Category 12.
Meaning of each bit (from bit #0 to bit #11) is as follows:
0: corresponding HSDPA UE Category is not eligible
1: corresponding HSDPA UE Category is eligible
It is recommended to activate HSDPA-specific UL power profiles for HSDPA UE Categories 7 to 10.
Hence, bits #6 to #9 should be set to 1.

initialSirTargetHsdpa: For HSDPA calls and if HSDPA UE Category is eligible for


Management of UL power profiles sub-feature of UA6 34246, UL SIR Target used
for the initialization of UL OLPC algorithm.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 108/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter

initialSirTargetHsdpa

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

UlUsPowerConf instance

initialSirTargetHsdpa value

PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K

4.7

PS_384K_IBxSRB_3_4K
Other instances

Same value as initialSirTarget

minSirTargetHsdpa: For HSDPA calls and if HSDPA UE Category is eligible for


Management of UL power profiles sub-feature of UA6 34246, lower bound for UL
SIR Target in the UL OLPC algorithm.
Parameter

minSirTargetHsdpa

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

UlUsPowerConf instance

minSirTargetHsdpa value

PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K

4.7

PS_384K_IBxSRB_3_4K
Other instances

Same value as minSirTarget

maxSirTargetHsdpa: For HSDPA calls and if HSDPA UE Category is eligible for


Management of UL power profiles sub-feature of UA6 34246, upper bound for UL
SIR Target in the UL OLPC algorithm.
Parameter

maxSirTargetHsdpa

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

For all UlUsPowerConf instances: Same value as maxSirTarget

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 109/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

9 OTHER FEATURES
9.1 HSDPA AND E-DCH SERVICE INDICATOR (32520)
This feature allows the mobile to display an indication when it is under HSDPA or
HSDPA and HSUPA coverage: The cell capability is broadcast on SYSINFO message
(SIB5) with value HSDPA/E-DCH Capable.
Thanks to this feature, the end-user can be made aware that he is within
HSDPA/HSUPA coverage, and can then decide whether to use or not services that
require high bandwidths.
Parameters available for this feature:
isHsxpaServiceIndicatorEnabled allows to enable/disable the feature at
RNC level
Parameter
Range & Unit
User
Class
Value

isHsxpaServiceIndicatorEnabled
False, True
Customer
3
True

Object

RadioAccessService

Granularity

RNC

hsdpaServiceIndicatorMethod allows to enable/disable at cell level the


broadcast of the HSDPA CellIndicator flag within SIB 5
Parameter
Range & Unit
User
Class
Value

hsdpaServiceIndicatorMethod
ON, OFF, AUTO
Customer
3
Auto

Object

FDDCell

Granularity

FDDCell

edchServiceIndicatorMethod allows to enable/disable at cell level the


broadcast of the E-DCH CellIndicator flag within SIB 5
Parameter
Range & Unit
User
Class
Value

edchServiceIndicatorMethod
ON, OFF, AUTO
Customer
3
Auto

Object

FDDcell

Granularity

FDDCell

Once the feature is activated at RNC level, three operating modes are possible for
each cell indicator (HSDPA and HSUPA), all combinations between HSDPA and
HSUPA being allowed:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 110/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
OFF: the hsdpaServiceIndicator (or respectively the edchServiceIndicator )
information is not broadcasted in SYSINFO message.
ON: if feature is enabled at RNC level, the hsdpaServiceIndicator (or
respectively the edchServiceIndicator) information is always broadcasted on
SYSINFO, with value HSDPA_CAPABLE (or respectively EDCH_CAPABLE).
This information is broadcasted to the UE even if the corresponding service
(HSDPA (or respectively E-DCH)) is not operational on the corresponding cell.
AUTO, if the feature is enabled at RNC level, hsdpaServiceIndicator (or
respectively the edchServiceIndicator) information is broadcasted to the UE
indicating the current state of the corresponding service: HSDPA_CAPABLE if
service is operational, HSDPA_NOT_CAPABLE otherwise (or respectively
EDCH_CAPABLE if service is operational, EDCH_NOT_CAPABLE otherwise)

9.2 HSDPA PERFORMANCE ENHANCEMENT (29819)


This feature consists in improving HSDPA performance thanks to several different
sub-features quite independent from each other:

Optimization of transport block sizes.

Optimal redundancy version.

Power adaptation for HARQ retransmissions.

HS-DPCCH detection based on CQI.

Configurable CQI adjustment according to BLER target algorithm

Enhanced HS-DPCCH demodulation (mainly in high speed condition)

All these sub-features have already been described in the previous sections except
the last one:

Enhanced algorithms for DCH demodulation on H-BBU


This feature consists in improving HS-DPCCH demodulation mainly in high speed
configurations. Solutions developed for the DCH have partially been introduced on the
H-BBU in UA4.2. The purpose of this item then is to include (from UA5.0) the
remaining part of such enhanced algorithms.
The solution is based on delayed channel estimation technique, but a trade-off
between taking into account the next slots for demodulation and limiting the delay
impacts on ACK/NACK and CQI information delivery to scheduler is considered. The
integrality of next slot will then not be taken into account but only the first pilot bit in
specific case.

The enhanced demodulation algorithm for high speed feature is activated thanks to
the bit 2 of the RxDemodulation parameter (see also section 6.1):
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 111/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
-

bit 2 = 0 OFF - enhanced demodulation for high speed UE is deactivated

bit 2 = 1 ON - enhanced demodulation for high speed UE is activated

The algorithm is deactivated by default. As the parameter is class 0, it then cannot be


changed online.
U

9.3 HSDPA OCNS (34195)


9.3.1 HSDPA OCNS PRINCIPLE
OCNS for HSDPA (HSDPA-OCNS) simulates virtual HSDPA users on the air
interface. The main purpose of HSDPA-OCNS is to create load in the HSDPA
scheduler that will assign resources for virtual (OCNS) users, and therefore will need
to schedule these virtual users together with the real users. Namely load on both
HSDPA scheduler and air interface transmit power can be generated by HSDPAOCNS. This HSDPA-OCNS functionality would be of use in lab testing for
measurements and optimization when testing the HSDPA scheduler with real users,
particularly when there are limited HSDPA test terminals.

An HSDPA-OCNS setup can be requested by an operator from an user interface in


OMC-R WIPS in a similar way as in R99 OCNS. The request is passed to RNC, which
then replay it to Node B and the scheduler will finally assign resources for the virtual
users in HSPDA-OCNS.

A R99 OCNS channel can co-exist along side a HSDPA OCNS channel.

Node B (particularly the HSDPA scheduler) is responsible to provide resources for the
virtual users simulated by HSDPA-OCNS channel. A software resides in the Node B
and is used when HSDPA-OCNS is switched on. This software generates virtual users
inside the HSDPA scheduler so that the scheduler algorithm can schedule the virtual
users together with the real ones, it will assign downlink resources to the virtual users
in the same way as it does for real users. Since the scheduler requires feedback (such
as CQI) from mobiles in order to decide the required resources per user, the software
could generate the required feedback per HSDPA-OCNS user and feed it back to the
scheduler if the feedback information (e.g. CQI) is not specified by the operator. Each
HSDPA-OCNS user will be then assigned certain resources and NodeB will transmit
data (also generated by the software) in the downlink. The software then has the
following main actions:

1. Scheduler should add virtual users as many as HSDPA-OCNS channels


setup by RNC. The number of virtual users shall not exceed the limit imposed
by call admission or allowed H-RNTI's up to 16.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 112/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
2. Generate constant data to be transmitted every TTI (2ms) in the downlink by
the virtual HSDPA-OCNS users. The data pattern will be fixed for each
simulated user. It also depends upon the UE category, MAC-hs window size,
number of active Users in the cell, and other parameters, if the UE can be
scheduled in each TTI or not.
3. Simulate feedback from the terminal received in the uplink direction. The
feedback contains a CQI value, which can be fixed all the time the HSDPAOCNS is active or it can be randomly generated. If CQI factor specified via an
user interface in OMC is zero then the CQI should be randomly generated
following a uniform distribution, if CQI specified by an operator is not zero,
then a fixed CQI factor should be used all the time.
4. Scheduler will generate its own dummy values for ACK and NACK according
to ACK/NACK ratio defined in percentage by the user input.
5. Scheduler will receive UE capability number as part of input parameters just
like normal HSDPA user.
6. Number of MAC-d PDUs will also be provided through input parameters,
which will be mapped to a maximum transport block size within scheduler.
7. NodeB software will also receive channel activity time for each HSDPA-OCNS
channel. This is a duration provided in minutes and once the timer expires of a
channel NodeB would de-activate that particular channel.
8. Scheduler should treat these virtual users as much as possible as normal
HSDPA users, and therefore assign resources.
9. Associated data and control channels for each virtual user should be
transmitted in the same way as a real user.
Each HSDP-OCNS channels should be active for the time duration specified by the
user.

The Baseband Channel Elements in the Node B handles any HSDPA-OCNS user as if
it was a real user in the downlink. Therefore an HSDPA-OCNS user will require the
same amount of downlink resources as a real user in terms of Channel Elements.
Please note that with HSDPA-OCNS there is no associated uplink HSDPA channel
such as HS-DPCCH and no traffic on the Iub either. As a result NodeB has to
generate dummy values for CQI and ACK/NACK to simulate uplink HSDPA channel
and also for MAC-d PDU queue size.

9.3.2 HSDPA OCNS PARAMETERS


Parameter

CQI

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Real Type: 0...30 in step of 1

User & Class

Customer

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 113/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Value

User defined
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI = 0, then random values between
range 1 and 30 shall be used by the scheduler from a generating function.

If 1< CQI <30 then a constant CQI value should be generated all the time and passed
to the scheduler. A fixed CQI value means that the scheduler would try to assign
resources based on the CQI value enter by the user. If the CQI value demands more
resources than available for a given TTI, then the OCNS user will not be scheduled for
that TTI.

Parameter

Mean CQI

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Real Type: 0...30 in step of 1

User & Class

customer

Value

User defined

Parameter

Filter Coefficient

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Integer Type: 110 in step of 1

User & Class

customer

Value

User defined
Filter coefficient (for an IIR filter) and Mean CQI, will be used in this random CQI
generator and hence are only applicable when CQI = 0.

NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI=0, then random value between
range 1 and 30 shall be used by the scheduler according to the generating function
defined below. The randomly generated CQI values have a mean value of Mean
CQI.

The generated CQI values are for 2 second duration. The generated CQI are re-used
for the subsequent 2 second intervals.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 114/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Start

Initialisation
Seed = 4096;
count=0;
Mean=20
filt_coef=1;
a=(0.5)^(filt_coef/2);
X(count)=1;

Input values for initial


parameters 'Mean' and 'filt_coef'
are set by higher layer.

count = count+1
Z = rand()
X(count)=X(count-1)xZ

Generate Uniform Random


Number 'Z' between (0 and 1).
Mulitply previuous 'Z' to latest
'Z' and repeat this process for
input 'Mean' number of times.

No

if (count =Mean)
YES

Take the negative of


natural log of X

This block performs IIR filter


operation to provide time
correlated output.
It can be disabled by setting
filt_coef = 0;

Y= -log(X)

Loop back to furnish the next


CQI value untill simulation time
expires.

Y = (1-a)*Y_previous + a*Y;

if Y<1
Y=1;
elseif Y>30
Y=30;
else
Y=Y;
end

Restricting the final CQI value


between 1 and 30.
Value less than 1 should be
truncated to 1 and value larger
than 30 should clipped to 30.

CQI = 31-Y;

Figure 35: Algorithm for CQI Generating Function


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 115/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter

ACK/NACK ratio

Object

OCNS

Granularity
Range & Unit

FDDCell
Integer Type: 0100% in 1% step

User & Class

customer

Value

User defined
NodeB scheduler shall generate ACK or NACK every TTI. ACK/NACK will be
generated according to ratio defined by the user in percentage. This parameter
indicates the percentage of number of positive and negative acknowledgements as
input to NodeB scheduler. This would be used to trigger re-transmission by the
scheduler.

0% means all transport blocks are negatively acknowledged (NACK) by UE, 100%
means all transport blocks are positively acknowledged by UE, i.e. no retransmission
is required. If the ratio is lower, the throughput would also be lower.

Parameter

Maximum Number of MAC-d PDU

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Integer Type: 0100

User & Class

Customer

Value

User defined

in step of 1

NodeB shall provide the maximum number of MAC-d PDU per TTI. This parameter is
then mapped to a certain transport block size to be transmitted over the air. This
parameter is related to amount traffic coming into the NodeB from higher layer. If zero,
it means that there is no data to transmit.

Parameter

UE Capability Number

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Integer Type: 112

User & Class

customer

Value

User defined
NodeB shall use UE Capability Number in the scheduler as received in the OCNS
channel setup message. This parameter will be used by the scheduler to assign the
resources accordingly. For example if UE capability number is 12 then scheduler will
use QPSK modulation only for data transmission.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 116/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter

Channel Activity Time

Object

OCNSHSDPA

Granularity
Range & Unit

FDDCell
Integer Type: 0144
minutes.

User & Class

customer

Value

User defined

in step of 1, where 1 represents 10

NodeB shall use Channel Activity Time to determine the time at which a particular
channel shall be deleted (or stopped). This parameter defines the time duration for
which a particular HSDPA-OCNS channel shall be ON. The minimum channel enabled
time is 0. This denotes a special case whereby the NodeB will disable the timer and let
the channel run until the OMC-R user locks/de-activates the object and hence causes
the channel to be deleted.

Note: The NodeB would determine the stop time for each channel based on the
channel activity time and the time it has received the HSDPA-OCNS channel setup
command.

Parameter

Cell ID

Object

HSDPAOCNS

Granularity
Range & Unit

FDDCell
Integer Type:

User & Class

customer

Value

User defined
Cell ID is a user input for HSDPA OCNS operation and is selected by the operator
from available cells from a user interface at OMC-R WIPS.

Parameter

proprietaryHSDPAOCNSActivation

Object

FDDCell

Granularity
Range & Unit

FDDCell
False / True

User & Class

Customer & Class 3

Value

False
proprietaryHSDPAOCNSActivation is used to turned HSDPA OCNS on or off.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 117/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
9.4 IU USER TRAFFIC CONFORMANCE
For HS-DSCH (HSDPA) and E-DCH traffic (HSUPA), the RNC implements a traffic
conformance mechanism on the Iu interface to ensure that the user traffic never
exceeds the maximum bit rate negotiated at RAB establishment. This is only
applicable in downlink/uplink.
This mechanism is optional and can be activated at RNC level (applicable to HSxPA
Service).

9.4.1 FEATURE APPLICABLE


In UA4.2, an HSDPA RAB is allocated in the following conditions:

1) the UE is HSDPA capable (release 5 compatible cat 1-12),

2) the primary cell supports HSDPA ,

3) the UE is requesting Interactive or Background Service

The HSDPA DL channel is given regardless of the MaxBitRate in the Core RAB
A R5 UE user that has a subscription in the HLR of MaxBitRate=64K or 384K or 2M
will be given with the same HSDPA DL channel and will benefit of throughputs up to
1.2M ( UE cat12)
If a subscriber (whatever MaxBitRate in HLR ) inserts its SIM into a HSDPA UE , it will
have access to a throughput that is only limited by the UE ( cat12=>1.4Megs,
cat6=>3.4Megs)
In UA5.0, a PS E-DCH RAB is allocated if:

1) the UE is eligible to E-DCH (must indicate support for R6 or later release in


the Access stratum indicator and E-DCH capability in UE Radio Access
Capability IE). E-DCH UE categories have been defined by 3GPP according
to their radio capabilities (cat 1 to 6: Spec 25.306)

2) the primary cell supports E-DCH,

3) the UE is requesting Interactive or Background Service.

Coupled with the usage of HSDPA to carry the DL traffic, HSUPA has been designed
to carry only a best effort traffic (i.e. interactive/background traffic on E-DCH); in other
word an HSUPA leg is always associated to an HSDPA leg.

9.4.2 ALGORITHM
This capability is based on a token bucket algorithm as specified in [R04].
X

This algorithm is used to verify that traffic packets submitted by the Core Network to a
UMTS bearer do not exceed the requested Max value. It uses the following two
parameters (r and b) for the traffic contract and one variable (TBC) for the internal
usage.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 118/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

r: token rate, (corresponds to the monitored Maximum bit rate).

b: bucket size, (the upper bound of TBC, corresponds to bounded burst size).

TBC (Token bucket counter): the number of remaining tokens at any time.

Figure 36: Traffic Conformance Algorithm

Each Time a packet of length Li arrives, the value of TBC is checked. If TBC is large
enough (b Li), meaning that the packet fits into the buffer, the traffic is considered as
conformant and the packet is accepted (as L1 and L2 in picture above), otherwise it is
deleted (as L3).
The value of TBC increases at a rate of r by time unit, and does not exceed b. The
RNC will actually updates TBC each time it receives a packet, by dT*r where dT is the
difference of time between the reception of the current packet and the previous
packet.
In the scope of HSxPA implementation, this algorithm is used to make sure users do
not exceed the original QoS contract.
Note : the bandwidth limit used in the algorithm is actually the RAB Maximum Bitrate,
bounded by a provisonable parameter MaximumTokenGenerationRate. This is useful
in case the Core Network has not be configured appropriately. The bucket size b is
equal to the provisionable parameter BucketBufferTime * MBR.
U

9.4.3 PARAMETERS
The following three parameters are used to activate and configure the Iu User traffic
Conformance Feature:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 119/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Parameter
Range & Unit

sourceConformanceActivation is used to activate/inhibit the Iu conformance


algorithm for downlink HSxPA user data.

sourceConformanceActivation Object
DlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : On if the operator wants to limit UE throughput

User
Class
Value

Parameter
Range & Unit

sourceConformanceActivation Object
UlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : On if the operator wants to limit UE throughput

User
Class
Value

Parameter
Range &
Unit
User
Class
Value

maximumTokenGenerationRate is the Absolute Max threshold and is only


used in the case the MaxBitRate of the Core RAB is greater than this
parameter.

maximumTokenGenerationRate
Integer (kBytes/s)
[1..2000]
Customer
3
Default: 500

Object

DlSourceConformanceInformation

Granularity

RNC

Note: The default value corresponds to ~4Mbits/s. If the operator wants that none
user benefits of cat6 Qos (only Cat12) , it can be set to 1.4 M/s=175kbytes/s
U

Parameter
Range &
Unit
User
Class
Value

maximumTokenGenerationRate
Integer (kBytes/s)
[1..2000]
Customer
3
Default: 500

Object

UlSourceConformanceInformation

Granularity

RNC

bucketBufferTime is linked to the Bucket Size such as Bucket Size =


MBR(bounded by TokenGenerationRate) * bucketBuffetTime. The maximum
bucket size is the max burst allowed by the bucket algorithm .The greater this
value is, the "slower" the algorithm will reject frames.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 120/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management
Parameter
Range & Unit
User
Class
Value

Parameter
Range & Unit
User
Class
Value

bucketBufferTime
Integer (ms)
[10..30000] step = 10
Customer
3
Default: 3750

Object

DlSourceConformanceInformation

Granularity

RNC

bucketBufferTime
Integer (ms)
[10..30000] step = 10
Customer
3
Default: 500

Object

UlSourceConformanceInformation

Granularity

RNC

9.4.4 FEATURE BEHAVIOUR


The feature monitors each user throughput and deletes IU SDUs that overpass
threshold given Core RAB or RNC provisioned absolute threshold
When Sequence Number loss is detected, TCP layer slows down (reduces window )
so that sender throughput is decreased.
HSDPA subscribers will have access to the full UE Cat12 throughput when in HSDPA
cell. If the HSDPA subscriber goes into R99 area it has PS384K R99 channel.
Provisioning to be changed: The Downlink MaxBitRate in the HLR needs increased for
HSDPA subscribers to 1.4 Megs ( case cat12 and 3.4M if cat6 is allowed)
R99 subscribers keep their MaxBitRate to 384K in HLR . A R99 subscriber using a
HSDPA capable UE in a HSDPA cell will have a HSDPA channel being limited to
384K throughput ( value from Core RAB)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 121/122

HSxPA Parameters Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 3 : HSDPA Principles, Scheduling and Resource


Management

Z END OF DOCUMENT Y

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 122/122

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

V03.10
02/OCT/2009

HSXPA PARAMETERS USER GUIDE

E-DCH PRINCIPLES, SCHEDULING AND RESOURCE


MANAGEMENT

Alcatel-Lucent Proprietary

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

CONTENTS
1

INTRODUCTION............................................................................................................................5
1.1

OBJECT ....................................................................................................................................5

1.2

SCOPE OF THIS DOCUMENT .......................................................................................................5

RELATED DOCUMENTS ..............................................................................................................8


2.1

HPUG VOLUMES ......................................................................................................................8

2.2

REFERENCE DOCUMENTS ..........................................................................................................8

E-DCH ACTIVATION .....................................................................................................................9

POWER MANAGEMENT FOR E-DCH .......................................................................................10


4.1

UL POWER MANAGEMENT .......................................................................................................10

4.1.1
UL load management....................................................................................................10
4.1.1.1
totalRotMax............................................................................................................... 12
4.1.2
RSEPS measurements .................................................................................................15
4.1.3
UL load estimation in presence of urban noise.............................................................17
4.1.4
High UL RSSI alarm......................................................................................................18
4.2
DL POWER MANAGEMENT .......................................................................................................20
4.2.1
At RNC ..........................................................................................................................20
4.2.2
At NodeB .......................................................................................................................20
4.2.2.1
E-DCH DL channels power settings......................................................................... 21
4.2.2.2
E-DCH DL channels configuration ........................................................................... 23
5

E-DCH SCHEDULING CONFIGURATION .................................................................................28


5.1

2MS TTI ..................................................................................................................................28

5.2

UE CATEGORIES .....................................................................................................................28

5.3

{E-TFCI; TBS} TABLE .............................................................................................................30

5.4

{REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLE .....................................................31

5.5

FRAME PROTOCOL ON IUB ......................................................................................................41

5.6

MISCELLANEOUS ....................................................................................................................42

MAC-E SCHEDULER ICEM ........................................................................................................47


6.1

UL LOAD FINE PREDICTION ......................................................................................................47

6.2

CONSIDERATION OF SELF-INTERFERENCE IN UL LOAD PREDICTION ..........................................48

6.3

OVERLOAD DETECTION: RTWP ALARM .....................................................................................50

6.4

GRANT COMPUTATION .............................................................................................................51

6.5

MAC-E SCHEDULER ................................................................................................................53

6.6

ACTIVITY MONITORING.............................................................................................................55

6.7

PRIORITY INFO IN MAC-E SCHEDULER .......................................................................................56

6.8

IUB CONGESTION HANDLING FOR E-DCH.................................................................................58

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 1/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


6.8.1
6.8.2
6.8.3
7

UL iub congestion detection..........................................................................................59


UL iub congestion reporting by RNC ............................................................................61
UL iub congestion management in edch scheduler......................................................62

MAC-E SCHEDULER XCEM.......................................................................................................64


7.1

MAC-E SCHEDULER INPUTS ....................................................................................................64

7.2

SCHEDULING GRANT ...............................................................................................................66

7.3

OVERLOAD ALGORITHM ...........................................................................................................68

7.4

ACTIVITY MONITORING.............................................................................................................68

7.5

GENERATION OF AG & RG......................................................................................................70

7.6

PRIORITY INFO IN MAC-E SCHEDULER........................................................................................71

7.7

MAC-E NON SCHEDULED MODE ................................................................................................73

7.8

IUB CONGESTION HANDLING FOR E-DCH.................................................................................74


7.8.1
7.8.2
7.8.3
7.8.4

ul iub congestion detection............................................................................................75


ul iub congestion reporting ............................................................................................75
ul iub congestion management by edch scheduler.......................................................75
ibts local congestion control ..........................................................................................76

IU USER TRAFFIC CONFORMANCE ........................................................................................78

POWER CONTROL FOR E-DCH................................................................................................79


9.1

UL OUTER-LOOP POWER CONTROL FOR E-DCH .....................................................................79

9.1.1
E-DCH UL OLPC in UA5...............................................................................................79
9.1.2
UA6 34249 EUL Capacity Optimized HARQ Operation .............................................80
9.1.2.1
Principle of E-DCH UL OLPC ................................................................................... 80
9.1.2.2
UA6 34249 Feature description................................................................................ 84
9.1.2.3
Parameter settings and recommendations............................................................... 90
9.2
POWER CONTROL OF E-DCH DL CHANNELS ......................................................................... 101
9.2.1
UA5.1/xCEM E-DCH DL control channels Power Control (33481) ......................... 101
9.2.1.1
Introduction ............................................................................................................. 101
9.2.1.2
Feature description................................................................................................. 101
9.2.1.3
Parameter settings and recommendations............................................................. 103
9.2.2
UA6/xCEM E-DCH DL control channels Power Control (33481) ............................ 106
9.2.2.1
Feature description................................................................................................. 106
9.2.2.2
Parameter settings and recommendations............................................................. 107
9.2.2.3
Other recommendations ......................................................................................... 109
10

SRB ON HSPA DURING CALL ............................................................................................... 110


10.1

E-DCH ONLY CONFIGURATION ............................................................................................. 110

10.2

RAB ASSIGNMENT ............................................................................................................... 113

10.3

MOBILITY MANAGEMENT ...................................................................................................... 114

10.4

RATE ADAPTATION ............................................................................................................... 114

10.5

DEFENSE ON FAILURE .......................................................................................................... 115

11

COMPRESSED MODE:............................................................................................................ 117

12

ONEBTS PARAMETERS ......................................................................................................... 119


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 2/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

TABLES
Table 1: UE categories
29
Table 2: Quantization for E-DPDCH (from 3GPP TS 25.213)
34
Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset} table
35
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table
36
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table 36
Table 6: xCEM/2ms TTI/2xSF2+2xSF4 recommended {Reference E-TFCI; Reference Power Offset}
36
table
Table 7: UCU-III recommended {Reference E-TFCI; Reference Power Offset} table
37
Table 8: Primary Cell HSUPA Category according to Primary Cell E-DPDCH SF capability and
39
selected E-DCH TTI
Table 9: EdpchParameters instance according to Target HSUPA UE Category and selected E-DCH
40
TTI
Table 10: Grant Index values
51
Table 11: Scheduling Priority iCEM
56
Table 12: E-DCH SPI
58
Table 13: Scheduling Priority xCEM
71
TU

UT

TU

UB

UB

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

UT

TU

TU

TU

UT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 3/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

FIGURES
Figure 1: Noise Rise vs. UL Load .................................................................................................................... 11
Figure 2: Example of uplink load (thermal noise/R99/E-DCH) .................................................................... 12
Figure 3: Power allocation at RNC level ......................................................................................................... 20
Figure 4: {E-TFCI; Transport Block Size} tables for 10ms TTI, as defined in 3GPP TS 25.321 ............ 31
Figure 5: E-DPDCH Power vs. Transport Block Size ................................................................................... 33
Figure 6: UA6 E-DCH parameters model at OMC-R .................................................................................... 38
Figure 7: reserved0 bit configuration ............................................................................................................... 44
Figure 8: RTWP exceeding margin.................................................................................................................. 50
Figure 9: Iub BW limitation iCEM ..................................................................................................................... 59
Figure 10: Uplink Iub Congestion iCEM .......................................................................................................... 60
Figure 11: Uplink Iub DeCongestion iCEM ..................................................................................................... 61
Figure 12: TNL Congestion Indication iCEM .................................................................................................. 62
Figure 13: GRF updating GRF iCEM .............................................................................................................. 63
Figure 14: Uplink Iub Congestion xCEM......................................................................................................... 74
Figure 15: TNL Congestion Indication xCEM ................................................................................................. 75
Figure 16: Local congestion control mechanism ........................................................................................... 76
Figure 17: E-DCH UL OLPC general principle............................................................................................... 80
Figure 18: Cell State computation ................................................................................................................... 86
Figure 19: UL OLPC in case of SRB on E-DCH ............................................................................................ 87
Figure 20: HFI Reception Scenario computation........................................................................................... 88
Figure 21: UA6 34249 RAN model for PS_EDCH and SRB_EDCH UL RBs ...................................... 91
Figure 22: UA6 34249 RAN model for E-DCH UL services and misc. ....................................................... 92
TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

TU

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

UT

UT

TU

TU

TU

TU

UT

UT

TU

TU

UT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 4/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

1 INTRODUCTION
1.1 OBJECT
The objective of this volume (UA6 HPUG [Vol.4]) is to describe from an engineering
point of view E-DCH principle, scheduling and resource management aspects in
Alcatel-Lucent UTRAN release UA06. This includes a system description,
configuration aspect and engineering recommendations.
X

1.2 SCOPE OF THIS DOCUMENT


The following features are described in this volume:
PM ID

Feature Title

Release

Global
Market

USA
Marke
t

UA5.0

Yes

Yes

[xCEM] Activated by default.

UA5.1

Yes

Yes

isUlOuterPCActivated (for UL
services with E-DCH)

UA5.1

Yes

Yes

UA5.1

Yes

No

Activation flag

isEdchAllowed, edchActivation
29840

UA5.1
33481

34172

34221

33327
33332
33336
33367

E-DCH Step1
(HSUPA)
E-DCH DL control
channels Power
Control
Remark: UA6 version
of the feature also
exists (see below).
E-DPDCH
Retransmissions for
DPCCH SIR
Adaptation
U

[iCEM] [xCEM]
edchResourceActivation
[iCEM] Feature not applicable.

Self-interference in
MAC-e Scheduler

[iCEM]
rotOrthogonalityEstimation
[xCEM] [UCU-III]
Feature not applicable.

MAC-e Scheduler
enhancements
Iub bandwidth
limitation for E-DCH

edchSpiRelativeWeight

UA6.0

Yes

No

isEdchBandwidthlimitationAllowe
d

UA6.0

Yes

No

HSUPA UE
categories 4 to 6
HSPA congestion
detection &
notification

isEdchTti2msAllowed

UA6.0

Yes

Yes

UA6.0

Yes

No

No activation flag.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 5/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


[iCEM] Feature not applicable.

UA6
33481

E-DCH DL control
channels Power
Control

[xCEM]
eagchPowerControlActivated,
eagchPowerControlModeXcem

UA6.0

Yes

Yes

[UCU-III]
eagchPowerControlActivated
[iCEM] Feature not applicable.
33581

34134
34175

SRB on E-DCH
during call

[xCEM] [UCU-III]
isSrbOnEdchAllowedWhenTrbOnEdch

UA6.0

Yes

Yes

High RSSI Node-B


Alarm
UA06 HSPA
Capacity Evolutions

RssiHighAlarmThreshold

UA6.0

Yes

No

No activation flag.

UA6.0

Yes

No

UA6.0

Yes

Yes

UA6.0

Yes

No

UA6.0

No

Yes

UA6.0

No

Yes

UA6.0

No

Yes

UA6.0

Yes

No

UA6.0

Yes

No

[iCEM] Adaptive NHARQ Target


mechanism disabled.
B

34249

EUL Capacity
Optimized HARQ
operation

[xCEM] [UCU-III]
No activation flag.
Feature can be restricted to UA5.1
mode by applying specific
parameter settings.

34167

Defence mechanism
for UE not supporting
CM with HSPA

isEdchCmFallbackAllowed

34229

IFHHO
Enhancements

isInterFreqHandoverOverIurAllowed

Voice + HSUPA
Remark: UA6 34438
feature only applies
to USA Market.
However, voice +
HSUPA multi-service
is available for both
Global Market and
USA Market.
OneBTS
Interoperability Parity
iBTS Local EDCH
Congestion Control
U

34438

34373
75786

[iCEM][UCU-III]
Feature not applicable
[xCEM]
edchCMActivation

81112

UL load estimation
in presence of
urban noise

[iCEM][UCU-III]
Feature not applicable

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 6/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


[xCEM]
maxEdchCommonChannelPower

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 7/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol.1] Introduction
[Vol.2] HSxPA Overview
[Vol.3] HSDPA Principles, Scheduling and Resource Management
[Vol.4] E-DCH Principles, Scheduling and Resource Management
[Vol.5] Call Management
[Vol.6] Mobility
[Vol.7] Deployment Scenarios

2.2 REFERENCE DOCUMENTS


[R01] UMT/DCL/DD/0020

UTRAN Parameters User Guide UA6.0

[R02] UMT/IRC/APP/014654

HSxPA Engineering Guide UA5.x

[R03] 3GPP TS 25.212

Multiplexing and channel coding (Release6)

[R04] UMT/SYS/DD/018827

E-DCH System Specification

[R05] 3GPP TS 25.321

MAC protocol specification

[R06] 3GPP TS 25.213

Spreading and modulation (FDD)

[R07] 3GPP TS 25.427


DCH data streams

UTRAN Iub/Iur interface user plane protocol for

[R08] UMT/BTS/INF/016135
Planning Guide

Micro NodeB & 9314 Pico NodeB Feature

[R09] 3GPP TS 25.331

RRC protocol specification

[R10] 3GPP TS 34.108


Common test environments for User Equipment
(UE); Conformance testing
[R11] 3GPP TS 25.215

Physical layer - Measurements (FDD)

[R12] 3GPP TS 25.214

Physical layer procedures (FDD)

[R13] UMT/IRC/APP/021071
Engineering

Guidelines for 9313 Micro NodeB Configuration

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 8/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

3 E-DCH ACTIVATION
In order to activate E-DCH on a given cell, the following activation flags must all be set
to True.
Parameter
Range & Unit
User
Class
Value
Parameter
Range & Unit
User
Class
Value

Object

RadioAccessService

Customer
3
True

Granularity

RNC

edchActivation

Object

FDDCell

Granularity

Cell

Object

BTSCell

Granularity

Cell

isEdchallowed
False, True

False, True

Customer
2
True
[iCEM] [xCEM]

Parameter
Range & Unit
User
Class
Value

edchResourceActivation
False, True

Customer
0
True

[UCU-III] No activation flag under OneBTSEquipment object path.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 9/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

4 POWER MANAGEMENT FOR E-DCH


4.1 UL POWER MANAGEMENT
This section UL Power Management only deals with the management of uplink load.
Regarding uplink power control algorithm (UL Outer-Loop Power Control or UL OLPC)
for E-DCH, please refer to section 9.1 of this volume.
X

4.1.1 UL LOAD MANAGEMENT


The uplink load management is a key step towards E-DCH deployment. Indeed the
uplink should be correctly estimated and allocated for R99 and E-DCH traffic.
As for HSDPA, the R99 traffic has the priority over E-DCH traffic. Therefore the uplink
load unused by R99 is allocated for E-DCH scheduling.
The UL load is computed based on the Node B thermal noise that is the RTWP when
there is no UL traffic (RTWPref).
B

UL load = 1 RTWPref/ RTWP = 1 1/Noise Rise


B

RTWPref depends on several factors such as NodeB configuration, cable length, TMA
usage or not, temperature. Therefore, a self learning algorithm has been implemented
that keeps tracking this parameter every day based on the average of the minimum
samples of RTWP observation. This algorithm is activated by default.
B

[iCEM] [xCEM]
Parameter
Range & Unit
User
Class
Value

isRtwpReferenceSelfLearning

Object

BTSEquipment

Granularity

Cell

False, True

Customer
3
True

Note that the reference RTWP is not transmitted to the RNC. Therefore the non EDCH RTWP transmitted through NBAP common message assumed a default value
for the thermal noise: NBAP RTWPnon E-DCH = -106.1 + RoTnon-EDCH
B

Parameter
Range & Unit
User
Class
Value

rtwpReference

Object

BTSCell

Granularity

Cell

[-115.0..-50.0] step:0.1 dBm

Customer
3
-106.1

The parameter rtwpReference is the reference of RTWP when the BTS does not
receive any radio signal for this cell. If the parameter isRtwpReferenceSelfLearning
is set to TRUE, this parameter is only used to initiate the RTWP self learning feature.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 10/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The noise rise is expressed as:
Noise rise = RTWP/RTWPref
B

Noise Rise vs. UL load


20
18
16

Noise Rise (dB)

14
12
10
8
6
4
2
0

0.1

0.2

0.3

0.4

0.5
UL load

0.6

0.7

0.8

0.9

Figure 1: Noise Rise vs. UL Load


The maximum allowable UL load should not be set too high. It should not be set to a
too low value in order no to impact the E-DCH capacity. A correct value is between
50% and 85% (i.e. 3 and 8 dB noise rise).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 11/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Max allowed UL load
Available
UL load for
E-DCH
scheduling

RSSI

CS64

PS64
CS12.2
CS12.2
Thermal Noise
Figure 2: Example of uplink load (thermal noise/R99/E-DCH)

Two parameters are used to set the maximum allowed UL radio load:
rtwpMaxCellLoadNonEdch (under BTSCell object) and totalRotMax (under
FDDCell object).
rtwpMaxCellLoadNonEdch : Parameter used to set the maximum allowed non EDCH UL radio load, for UL Radio Load CAC at NodeB mechanism described in
UPUG [R01], Vol.6, section 5.10. As mentioned in [R01], rtwpMaxCellLoadNonEdch
is taken into account by the system only if UL Radio Load CAC at NodeB
mechanism has been activated, i.e. only if rtwpMaxCellLoadCacActivation (under
BTSCell) has been set to true.
X

Parameter
Range & Unit
User
Class
Value

rtwpMaxCellLoadNonEdch
[0..100] (%)
Customer
3
50

Object

BTSCell

Granularity

Cell

4.1.1.1 totalRotMax
[iCEM] [xCEM]
Parameter used to set the maximum allowed total UL radio load, for E-DCH
scheduling purpose. Basically, the MAC-e scheduler allocates grants so that the total
UL radio load remains below and close to totalRotMax. Note that totalRotMax value
is specified in terms of UL noise rise (also referred as RoT Rise over Thermal
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 12/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


noise), so unit is dB. As a reminder, UL radio load and RoT are equivalent quantities
that are linked together by the formula given at the beginning of this section. For more
information on E-DCH scheduling mechanisms, please refer to section 6 (iCEM) and
section 7 (xCEM).
X

Parameter

totalRotMax

Range & Unit


User
Class
Value

Decimal [0.0 ... 20.0] step 0.1, dB


Customer
2 or 3
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8

Object

FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams

Granularity

Cell

Please refer to UPUG Vol.6 for further details regarding these two distinguish
parameter class utilisation.

Engineering Recommendation: [iCEM] [xCEM] totalRotMax setting


For iBTS, in case E-DCH is activated on R99+HSPA shared carrier, it is recommended to set
totalRotMax to 6 dB in order to avoid potential impact of high UL radio load on UL R99 calls
QoS.
In case E-DCH is activated on HSPA dedicated carrier, it is recommended to set totalRotMax
to 8 dB in order to allow higher maximum E-DCH cell throughput.

[UCU-III]
Regarding OneBTS this parameter is used to determine the maximum noise rise to
ensure uplink coverage. The maximum target uplink load for the cell is set internally in
the OneBTS to 85%. If this maximum level of interferences is exceeded, then the
MAC-e scheduler will reduce its target load for E-DCH to reduce the total uplink cell
load. Thus, it is recommended to set this parameter to 15 dB.
Parameter
Range & Unit
User
Class
Value

totalRotMax
[0..20] step:0.1 (db)
Customer
2
15

Object

FDDCell

Granularity

Cell

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 13/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Rule: Coherency between rtwpMaxCellLoadNonEdch and totalRotMax
The maximum allowed non E-DCH UL radio load (set via rtwpMaxCellLoadNonEdch parameter)
must be set lower than or equal to the maximum allowed total UL radio load (set via totalRotMax
parameter). Hence, rtwpMaxCellLoadNonEdch and totalRotMax must be set so that the following
relationship is fulfilled:

rtwpMaxCel lLoadNonEd ch 1

1
10

totalRotMa x / 10

If above relationship is not fulfilled, then maximum allowed non E-DCH UL radio load for UL Radio
Load CAC at NodeB mechanism is considered by NodeB as equal to the maximum allowed total UL
radio load, i.e. 1-1/(10 totalRotMax / 10).
P

Rule: totalRotMax
The maximum allowed total UL radio load in terms of UL noise rise (or RoT) should be set lower than
or equal to 8dB (which corresponds to an UL radio load of 84.2%).
totalRotMax 8 (for iBTS only -> not for OneBTS)
If above rule is not respected, there is a high probability to face system instability regarding UL noise
rise fluctuation, such as important and frequent peaks of UL noise rise (i.e. UL RSSI peaks).

Note that there is the referenceRtwp parameter in FDDCell (whereas rtwpReference


is in BTSCell) that is only used internally by the NodeB in order to compute the
difference between the RTWP max (= referenceRtwp + totalRotmax) and the RTWP
min (=referenceRtwp). So, his value is not meaningful but to be coherent
referenceRtwp is equal to rtwpReference.

The non E-DCH RTWP is estimated and averaged over 100 ms period. It is based on
the RTWP estimation minus the E-DCH contribution:

RTWPnonE DCH = RTWP RTWPE DCH


Engineering Recommendation: Uplink Inner-Loop Power Control algorithm
PowerCtrlAlgo = Algo1
in RNC / RadioAccessService / DedicatedConf / PowerCtrlConf / UlInnerloopConf

Parameter
Range & Unit
User
Class
Value

isRtwpAdjustmentForRnc

Object

BTSEquipment

Granularity

Cell

False, True

Customer
3
True

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 14/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter

referenceRtwp

Range & Unit


User
Class
Value
Parameter

[-112.0..-70.0] step:0.1, dBm


Customer
2
-106.1
referenceRtwp

Range & Unit


User
Class
Value

[-112.0..-70.0] step:0.1, dBm


Customer
2 or 3
-106.1

Object

FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams

Granularity

Cell

Object

FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams

Granularity

Cell

Please refer to UPUG Vol.6 (totalRotMax description) for further details regarding
these two distinguish parameter class utilisation.

When the RSEPS measurements are deactivated, this parameter indicates if the BTS
does a correction of the RTWP before reporting it to RNC in the NBAP COMMON
MEASUREMENT REPORT. If the parameter is set to TRUE, the correction is:
-106.1 + (Rtwp_measured - rtwpReferenceOrSelfLearned).
Example: isRtwpReferenceSelfLearned is set to TRUE. The selfLearned
rtwpReference is measured by the BTS to -105dBm. The BTS read a RTWP of 100dBm --> The BTS will report: -106.1 + (-100 + 105) = -101.1 dBm (instead of -100)

4.1.2 RSEPS MEASUREMENTS


A new NBAP common measurement is introduced in UA6 to improve the UL load
reporting for the UL load iRM.
When the RSEPS (Received Scheduled Edch Power Share) measurements are
deactivated, the BTS reports only the RTWP measurements as in UA5.
If we activate the RSEPS measurements, the RNC configures NBAP common
measurements to report periodically

Total_RTWP

Reference_RTWP

On top of this measurement, the RNC configures RSEPS measurements to report


periodically (with the same period as RTWP)

Edch power ratio

With this new measurement the RTWP NBAP measurements become 3GPP
compliant as there is no more need to adjust the RTWP at the BTS level to report the
non edch power (UA5 behavior).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 15/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The RNC is now able to compute the non edch load for iRM UL load as follow:
Before RSEPS activation:
U

Non_Edch_Rot is sent by NodeB and Non_Edch_Ul_Load is retrieved in RNC:


Non_Edch_Ul_Load=1-10^(-Non_Edch_RoT /10)
After RSEPS activation:
U

Total_RTWP, Reference_RTWP and


Non_Edch_Ul_Load is retrieved in RNC:

RSEPS

are

sent

by

NodeB

and

Non_Edch_Ul_Load=Total_Ul_Load RSEPS[ratio]
Where
Total_Ul_Load=1-10^(-Total_RoT/10)
Total_Rot=Total_RTWP[dBm]-Reference_RTWP[dBm].
Note that:

When the RSEPS measurements are activated, the UL RSSI counter


(#303) will start reporting the Total_RTWP, whereas if the RSEPS are
deactivated (UA5 behavior) this counter will correspond simply to
-106.1+Non_Edch_RoT.

The activation of RSEPS measurement may increase slightly the TMU


load and the impact depends on the used RTWP reporting periodicity.

The
parameters
nbapCommonMeasRsepsFilterCoef
and
nbapCommonMeasRsepsReportingPeriod are not used anymore and
the RSEPS measurements are configured with the same filter coefficient
and periodicity as RTWP measurements based on the parameters
nbapCommonMeasRtwpFilterCoef
and
nbapCommonMeasRtwpReportingPeriod (please refer to [R01] for
details about these parameters).

To activate RSEPS, besides using the dedicated parameter


isNbapCommonMeasRsepsAllowed, the activation of the UL Radio
Load is mandatory, i.e.:
isUlRadioLoadColourEnabled
(located
under
RadioAccessService / DedicatedConf / NodeBConfClass)

RNC

and
isUplinkRadioLoadEnabled (located under RNC RadioAccessService)
have to be set to the value True (please refer to [R01] for details about
these parameters).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 16/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range & Unit
User
Class
Value

isNbapCommonMeasRsepsAllowed

Object

NodeB

Granularity

BTS

False,true

Customer
3
True
[UCU-III]

OneBTS for the moment does not support RSEPS, but only a special measurement of
RTWP which is derived from the non-EDCH load. This measurement is equivalent to
RTWP provided in UA5.1. Therefore, the RSEPS measurement is deactivated:
isNbapCommonMeasRsepsAllowed set to False.

4.1.3 UL LOAD ESTIMATION IN PRESENCE OF URBAN NOISE


Following 850MHz/900MHz trials, it has been highlighted that urban noise (old cars,
trucks, ..) generates big spikes in the UMTS bandwidth leading to an increase of the
received power by the BTS and thus a biased UL load estimation impacting the
HSUPA scheduling (E-DCH users are de-granted).
This feature is mainly intended for 900/850MHz early deployments, but it can also be
used for 2100MHz networks in polluted spectrum and for customers complaining
about the self tuned RTWPref reliability for noise rise evaluation.
B

A new measurement method is then put in place and this method can be selected
(instead of the actual RTWP method) at cell level by using the
BTSEquipment/BTSCell/EdchConf

maxEdchCommonChannelPower
parameter (this old unused parameter is re-used for this specific purpose in this
version due to late introduction of this feature).
As it is know, with the current method the radio load is based on the following
equation:
UL load = 1 RTWPref/ RTWP
B

In the presence of urban noise, external interference (e.g. GSM) or in case of


unreliable RTWPref, a new measurement method is recommended. The estimated
total load is calculated as follows (computed on the different UL contributors
distributed over the xCEM card):
Lest,total = {Lest,s + Lest,ns + Cpeer-servingLest,ps,C + Lest,DCH + Lest,HS-DPCCH} x (1 + Loc) where:
B

Lest,s is the estimated load portion for the serving users


B

Lest,ns is the estimated load portion for the non-serving users


B

Lest,ps,C is the estimated load portion for the peer-serving cell C


B

Lest,DCH is the estimated DCH load for all users


B

Lest,HS-DPCCH is the estimated load portion for HS-DPCCH


B

Loc is the other-cell interference factor accounting for the load impact from
users which have no active radio link in the cell
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 17/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The value of Loc is obtained from the already mentioned parameter:
BTSEquipment/BTSCell/EdchConf maxEdchCommonChannelPower
B

This parameter represents 100 + the proportion of power due to other external cells of
the specified cell. Values below 100 indicates deactivation of the feature (values from
[+100.0...+200.0] will activate the feature) and Mac-e scheduler will use RTWP values
for UL Load estimation.
Parameter
Range & Unit
User
Class
Value

Object
maxEdchCommonChannelPower
Decimal [-35.0 +200.0] step:0.1, none
Customer
Granularity
3
0

EdchConf
BTSCell

Remark: The parameter setting, in order to ensure ISO functionality on release


upgrade, shall be set to: maxEdchCommonChannelPower = 0 (initial value).
U

This new UL load estimation can be applicable to any frequency band (2100 MHz,
900/850 MHz). However it could be acceptable that the feature is applied by default
only to 850/900 MHz and excludes 2100 MHz for which the RTWP based method
could be kept unchanged.

This feature is applicable only to Node B configurations (iBTS) where the whole traffic
of one carrier is handled by one and only one xCEM (absence of inter modem board
messaging in UA06 prevents usage of UL load estimation based on SIR values for
carriers having cells or UL contributors distributed over multiple modem boards). Note
that for any other supported configurations, e.g. iCEM and xCEM mixity this feature
is not applicable as it is not possible to guarantee that following a failure, no iCEM will
be allocated for the frequency for which this feature is activated.

[iCEM][UCU-III]
This feature is dedicated to iBTS xCEM only.

4.1.4 HIGH UL RSSI ALARM


The UL load is a key resource for Edch and its highly recommended to check the UL
RSSI before Edch activation and ensure that there is no HW or external interferer that
may impact the Edch performance.
To help the customer to detect UL RSSI issues that could happen after the activation
of HSUPA (HW problems, external interference or simply high UL load due to high
R99 traffic), a new NodeB alarm is introduced in UA6 to warn the customer when the
measured UL RSSI, on the main or diversity path, is higher than a configurable
threshold RssiHighAlarmThreshold during more than 30x100ms. The operator can
then detect the UL RSSI issues as soon as they appear and launch the corrective
actions to limit the impact on the network QoS.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 18/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


This feature could be deactivated by setting the parameter RssiHighAlarmThreshold
to unset.
Parameter
Range & Unit
User
Class
Value

RssiHighAlarmThreshold

Object

BTSEquipment

Granularity

Cell

[-150dBm, -50dBm], 0.1dB

Customer
3
unset

In case of high UL RSSI alarm activation, the threshold could be set to 10dB above
Noise level (i.e. 90% Ul load). A normal noise level value measured in the TRM should
be in the range [-107.5dBm, -104.5dBm] so the alarm threshold could be set to
-94.5dBm to cover all the range.

[UCU-III]
Feature dedicated to iBTS only

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 19/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


4.2 DL POWER MANAGEMENT
4.2.1 AT RNC
At RNC level, some power is reserved for E-DCH downlink channels in the same
manner as the RNC level power reservation performed for common control channels.
The aim of this power reservation at RNC level for E-DCH DL channels is to perform
CAC of DL DCH traffic, i.e. this power is not allowed to be used by DL DCH traffic at
CAC (as it is the case for the power reserved at RNC level for CCC channels).
In the following figure showing power allocation at RNC level, the power reserved for
E-DCH DL channels is represented in light blue (E-DCH).

SHO margin

PMaxCell

RNC

Ptraffic
PminHsdpa

Max Power for HS-DSCH


& HS-SCCH, E-AGCH,
E-HICH and E-RGCH
to be transmitted
to the NodeB

E-DCH
OCNS (opt.)
CCCRNC
Figure 3: Power allocation at RNC level
The amount of power reserved for E-DCH DL channels at RNC level can be set via
eagchErgchEhichTotalPower parameter.
Parameter
Range & Unit
User
Class
Value

eagchErgchEhichTotalPower
Decimal [0.0 50.0] step:0.1, dBm
Customer
0
10

Object

EdchCellClass

Granularity

EdchCellClass

4.2.2 AT NODEB
At the NodeB, power is allocated in priority to CCC channels, E-DCH DL channels and
DCH DL traffic. The remaining power is then allocated to HSDPA DL channels (i.e.
HS-SCCH and HS-DSCH).
Remark: At NodeB, there is no upper limit for E-DCH DL channels total Tx power.
maxEdchCommonChannelPower parameter under EdchConf, which was originally
created for this purpose, is ignored by the system.
U

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 20/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


When the E-DCH serving NodeB sends an E-AGCH, E-RGCH or E-HICH command to
an E-DCH UE, the power allocated to E-AGCH or to the considered E-RGCH or EHICH signature is fixed for iCEM, and updated every 2ms (in order to match E-AGCH
and E-RGCH/E-HICH sub-frame length of 2ms) for xCEM and UCU-III. Regarding
non-serving NodeB, E-DCH DL channels power control is only possible for xCEM and
UCU-III, and only under certain conditions for xCEM. Please refer to section 9.2.2 for
more information on E-DCH DL channels power control in UA6/xCEM.
X

4.2.2.1 E-DCH DL CHANNELS POWER SETTINGS


This section gives engineering recommendations regarding E-DCH DL channels
power settings for iCEM, xCEM and UCU-III.

[iCEM]
On iCEM, E-DCH DL channels are not power controlled; their transmit power is fixed
and can be set via eagchPower, ehichPowerSignature and ergchPowerSignature
parameters. Note that on iCEM, E-RGCH is only used for the purpose of sending
Down RG commands to non-serving UEs when the ratio of UL noise rise generated
by non-serving radio links to total E-DCH UL noise rise exceeds
targetNonServingToTotalEDCHPowerRatio threshold. Please refer to [Vol.6],
section 3.3.2 for more information on handling of non-serving radio links and more
generally on E-DCH Macro Diversity in UA6.
X

Restriction: On iCEM, E-DCH DL channels power control is not supported


On iCEM, E-DCH DL channels are not power controlled; their transmit power is fixed and can be set
via eagchPower, ehichPowerSignature and ergchPowerSignature parameters.

eagchPower: Power offset for one E-AGCH channel, relative to the CPICH power.
Parameter
Range & Unit
User
Class
Value

eagchPower
Signed [-35.0 15.0] step:0.1, dB
Customer
3
-2.5

Object

EdchConf

Granularity

BTSCell

Remark: Only one mobile can be addressed per E-AGCH channel and per TTI.
U

ehichPowerSignature: Power offset for one E-HICH signature, relative to CPICH


power.
Parameter
Range & Unit
User
Class
Value

ehichPowerSignature
Signed [-35.0 15.0] step:0.1, dB
Customer
3
-8.0

Object

EdchConf

Granularity

BTSCell

Remark: On iCEM, up to 15 E-HICH signatures may be used on the same E-HICH/ERGCH channel (instead of 40 as of 3GPP) since the maximum number of E-DCH
radio links that can handle one E-BBU is 15.
U

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 21/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


ergchPowerSignature: Power offset for one E-RGCH signature, relative to the
CPICH power. Note that on iCEM, E-RGCH is only used for the purpose of sending
Down RG commands to non-serving UEs when the ratio of UL noise rise generated
by non-serving radio links to total E-DCH UL noise rise exceeds
targetNonServingToTotalEDCHPowerRatio threshold.
In addition, even if UA6 E-DCH Macro Diversity (32076) feature has not been
activated yet, ergchPowerSignature must be set greater than a certain value (which
depends on PA maximum power and CPICH Tx power) for NodeB internal power
check to succeed. According to NodeB internal power check rules described in [Vol.3]
section 8.4, ergchPowerSignature must be set so that the following equation is
verified:
X

pcpichPower + ergchPowerSignature maxTxPower - 35.0 dB


If UA6 E-DCH Macro Diversity (32076) feature is activated, it is recommended to set
ergchPowerSignature to -8 dB to favor a proper detection of the E-RGCH commands
by the UEs.
Parameter
Range & Unit
User
Class
Value

ergchPowerSignature
Signed [-35.0 15.0] step:0.1, dB
Customer
0
-8 dB

Object

EdchConf

Granularity

BTSCell

Engineering Recommendation: ergchPowerSignature setting


Even if UA6 E-DCH Macro Diversity (32076) feature has not been activated yet,
ergchPowerSignature must be set greater than a certain value (which depends on PA maximum
power and CPICH Tx power) for NodeB internal power check to succeed.
Basing on NodeB internal power check rules described in [Vol.3] section 8.4, it is recommended to
set ergchPowerSignature to [maxTxPower - pcpichPower - 35.0 + 3.0].
X

Hence, for the usual case of maxTxPower = 45dBm, pcpichPower = 35dBm, it is recommended
to set ergchPowerSignature to -22.0dB.
If UA6 E-DCH Macro Diversity (32076) feature is activated, it is recommended to set
ergchPowerSignature to -8dB.
Remark: In above Engineering Recommendation, the term +3.0 is introduced so that,
even if pcpichPower is set to a value lower than usual (e.g. for lab test purpose), in a
certain extend it is not required to modify ergchPowerSignature value.
U

For information, the following iCEM-specific parameters are also present in UA6 RAN
Model (under EdchConf) but ignored by the system. Their default value (Fixed)
should not be changed.
Rule: eagchPowerControlMode, ehichPowerControlMode, ergchPowerControlMode setting
eagchPowerControlMode, ehichPowerControlMode, ergchPowerControlMode under EdchConf
(iCEM-specific parameters) should not be set to a value different from the default one, i.e. Fixed.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 22/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


[xCEM]
On xCEM, power control of E-AGCH, E-RGCH and E-HICH is supported via E-DCH
DL control channels Power Control (33481) feature. Note that this feature was
originally introduced in UA5.1 but has been improved in UA6. Please refer to section
9.2 for a detailed description of the mechanism and parameters involved in this
feature.
X

[UCU-III]
On UCU-III, power control of E-AGCH, E-RGCH and E-HICH is supported via UA6 EDCH DL control channels Power Control (33481) feature. Please refer to section 9.2
for a detailed description of the mechanism and parameters involved in this feature.
X

4.2.2.2 E-DCH DL CHANNELS CONFIGURATION


This section gives engineering recommendations regarding the number of codes to
configure per cell for each type of E-DCH DL channel for iCEM, xCEM and UCU-III.
Note that, in UA6, for iCEM and xCEM, the maximum number of codes configurable
for each type of E-DCH DL channel is part of UA6 34175 UA06 xCEM HSPA
Capacity Evolutions feature.

maxNrOfEagch: Number of E-AGCH channels (i.e. SF 256 OVSF codes) reserved


per cell.
HT

TH

Parameter

maxNrOfEagch

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Integer [1 8], N/A

User & Class

Customer, 0

Value

1
Remarks:
U

[iCEM] On iCEM, up to 3 E-AGCH channels can be configured per cell. However,


since the maximum number of E-DCH radio links that can handle one E-BBU on
iCEM is 15, depending on the expected E-DCH traffic on the considered zone, it
may not be useful to send several E-AGCH commands at the same time, and on
the other hand saving DL code resource could benefit to DL traffic. Consequently,
for iCEM, if low E-DCH traffic is expected, it is recommended to set
maxNrOfEagch = 1.
HT

TH

[xCEM] [UCU-III] On xCEM, up to 3 E-AGCH channels can be configured per cell.


On OneBTS UCU-III, up to 4 E-AGCH channels can be configured per cell.
However, since on xCEM and UCU-III AG commands are only sent for activation
and deactivation of the granting process of a given user, depending on expected
E-DCH traffic on the considered zone, it may not be useful to send several EAGCH commands at the same time, and on the other hand saving DL code
resource could benefit to DL traffic. Consequently, for xCEM and UCU-III, if low EDCH traffic is expected, it is recommended to set maxNrOfEagch = 1.
HT

TH

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 23/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Restriction: [iCEM] [xCEM] maxNrOfEagch


In UA6/iBTS (for both iCEM and xCEM), up to 3 E-AGCH channels can be configured per cell.
However, maxNrOfEagch parameter can be set to a value up to 8.
If maxNrOfEagch is set to a value higher than 3, the iBTS returns an NBAP Physical Shared Channel
Reconfiguration (PSCR) Failure message to the RNC. In this case, the RNC then tries to configure the
shared channels on the considered cell, but without E-DCH service. In other words, in UA6/iBTS,
setting maxNrOfEagch to a value higher than 3 causes to loose E-DCH service on all the cells for
which this setting applies.

Rule: [iCEM] [xCEM] maxNrOfEagch


In UA6/iBTS (for both iCEM and xCEM), please follow the following rule for maxNrOfEagch:
maxNrOfEagch 3.

maxNrOfErgchEhich: Number of E-HICH/E-RGCH channels (i.e. SF 128 OVSF


codes) reserved per cell.
Parameter

maxNrOfErgchEhich

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Integer [1 8], N/A

User & Class

Customer, 0

Value

[iCEM] 1
[xCEM] 4
[UCU-III] 4
Remarks:
U

As of 3GPP, up to 40 [E-HICH+E-RGCH] signatures can be sent simultaneously


to multiple mobiles via one E-HICH/E-RGCH channel, i.e. on the same OVSF
code.

[iCEM] On iCEM, since the maximum number of E-DCH radio links that can
handle one E-BBU is 15, one E-RGCH/E-HICH channel per cell is sufficient.
Consequently, for iCEM, in order to save DL code resource, it is recommended to
set maxNrOfErgchEhich = 1.

[xCEM] On xCEM, up to 4 E-RGCH/E-HICH channels can be configured per cell.


Assuming one E-RGCH Common signature allocated per E-RGCH/E-HICH
channel (set via edchNumCommonRgPerCode, see Vol.6, section 3.3.2), and

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 24/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


knowing that xCEM allocates one pair of {E-HICH; Dedicated E-RGCH} signatures
per E-DCH radio link, one E-RGCH/E-HICH channel can support up to 19 E-DCH
radio links.
In order to maximize the possible number of simultaneous E-DCH users per cell, it
is recommended to set maxNrOfErgchEhich = 4. However, depending on
expected E-DCH traffic on the considered zone, maxNrOfErgchEhich value
could be decreased to save DL code resource.

[UCU-III] On OneBTS UCU-III, up to 4 E-RGCH/E-HICH channels (i.e. OVSF


codes) can be configured per cell. In order to maximize the possible number of
simultaneous E-DCH users per cell, it is recommended to set
maxNrOfErgchEhich = 4.

[xCEM] [UCU-III]
Remark on maximum number of E-DCH users per cell:
U

As explained above, assuming that one E-RGCH Common signature is allocated per
E-RGCH/E-HICH channel, one E-RGCH/E-HICH channel can support up to 19 E-DCH
radio links. Accordingly, setting maxNrOfErgchEhich = 4 theoretically enables up to
76 E-DCH radio links per cell.
For xCEM, a maximum of 128 E-DCH radio links can be supported per cell from a
hardware point of view (up to 128 E-DCH radio links are supported per xCEM board,
hence per cell assuming there is no E-DCH radio link established on the other cells
supported by the same board). This means that setting maxNrOfErgchEhich = 4
actually enables up to 76 E-DCH radio links per cell.
For UCU-III, a maximum of 64 E-DCH radio links can be supported per cell from a
hardware point of view (up to 64 E-DCH radio links are supported per cell regardless
to the number of UCU-III boards, but a maximum of 3 x 64 = 192 E-DCH radio links
can be supported per NodeB with 3 UCU-III boards). This means that setting
maxNrOfErgchEhich = 4 actually enables up to 64 E-DCH radio links per cell.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 25/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Engineering Recommendation: [iCEM] [xCEM] maxNrOfErgchEhich


On iCEM, since the maximum number of E-DCH radio links that can handle one E-BBU is 15, one
E-RGCH/E-HICH channel per cell is sufficient. Consequently, for iCEM, in order to save DL code
resource, it is recommended to set maxNrOfErgchEhich = 1.
On xCEM, up to 4 E-RGCH/E-HICH channels (i.e. OVSF codes) can be configured per cell. For
xCEM, in order to maximize the possible number of simultaneous E-DCH users per cell, it is
recommended to set maxNrOfErgchEhich = 4. However, depending on expected E-DCH traffic on
the considered zone, maxNrOfErgchEhich value could be decreased to save DL code resource.

Configuration method:
U

Use two specific EdchCellClass instances (one for iCEM and one for xCEM).

For the EdchCellClass instance related to each type of board (iCEM and xCEM), set
maxNrOfErgchEhich to above-specified value.

Make each cell (FDDCell object) point toward the appropriate EdchCellClass instance,
according to the type of board that handles E-DCH traffic for this cell.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 26/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Restriction: [iCEM] [xCEM] maxNrOfErgchEhich
In UA6, for iCEM, up to 3 E-RGCH/E-HICH channels can be configured per cell.
In UA6, for xCEM, up to 4 E-RGCH/E-HICH channels can be configured per cell.
However, maxNrOfErgchEhich parameter can be set to a value up to 8.
In UA6/iBTS (for both iCEM and xCEM), if maxNrOfErgchEhich is set to a value higher than 4, the
NodeB returns an NBAP PSCR Failure message to the RNC. In this case, the RNC then tries to
configure the shared channels on the considered cell, but without E-DCH service. In other words, in
UA6/iBTS, setting maxNrOfErgchEhich to a value higher than 4 for xCEM causes to loose E-DCH
service on all the cells for which this setting applies.

Remarks for UA6/iCEM:


U

As explained above, since the iCEM can handle 15 E-DCH radio links at maximum, it is useless
to configure more than one E-RGCH/E-HICH channel per cell.

As long as maxNrOfErgchEhich is set to a value lower than or equal to 4, the NodeB does not
return an NBAP PSCR Failure message to the RNC, i.e. there is no risk of loosing E-DCH
service.

If maxNrOfErgchEhich is set to a value lower than 4, the exact number of E-RGCH/E-HICH


channels (i.e. SF 128 OVSF codes) specified via maxNrOfErgchEhich parameter is
configured. If maxNrOfErgchEhich is set to 4, only 3 E-RGCH/E-HICH channels are
configured.

Rule: [iCEM] [xCEM] maxNrOfErgchEhich


In UA6/iBTS (for both iCEM and xCEM), please follow the following rule for maxNrOfErgchEhich:
maxNrOfErgchEhich 4

Restriction: 9313 Micro NodeB & 9314 Pico NodeB support only 1 E-AGCH and 1 E-RGCH/EHICH
As a consequence, in the edchCellClass used to configure a Micro/Pico Nodeb cell, the parameters
maxNrOfEagch and maxNrOfErgchEhich must be set to 1.
See [R13] for more information on the 9313 Micro NodeB.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 27/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

5 E-DCH SCHEDULING CONFIGURATION


For a given E-DCH user, before beginning an E-DCH call (i.e. transfer of data in the
uplink on E-DCH), some tables describing the configuration of E-DCH scheduling are
transmitted by the RNC to both the NodeB and the UE. The following two sections
describe the aim and settings for {Transport Block Size index; Transport Block Size}
table and {Reference E-TFCI; Reference Power Offset} table.

5.1 2MS TTI


The 2ms TTI is supported in UA6 only by the xCEM board.
When 2ms TTI is activated on xCEM, by setting the parameters
isEdchTti2msAllowed under RadioAccessService and EdchCellClass to True, a
UE supporting 2ms TTI (i.e. CAT2 , 4 and 6) will be configured with 2ms TTI using a
special ETFC table. In this case, 8 HARQ processes are used. The NB scheduler
uses the same scheduling period for both 2ms and 10ms TTI UEs and is able to grant
up to 5 users with 2ms TTI on 1 E-AGCH 10ms frame (i.e. 1 UE per 2ms sub frame).
Parameter
Range & Unit
User
Class
Value

Object

RadioAccessService

Customer
3
True

Granularity

RNC

isEdchTti2msAllowed

Object

EdchCellClass

Granularity

EdchCellClass

isEdchTti2msAllowed

Parameter
Range & Unit
User
Class
Value

True,False

True,False

Customer
3
True

Remark: In UA6, ttiType parameter under EdchConf is ignored by the system.


U

For 2ms TTI UEs, the NB will report 1 FP each 2ms.


If the UE is not supporting 2ms TTI or if the 2ms TTI is deactivated, the UE will be
configured with 10ms TTI.
For mobility, the RNC will reconfigure the TTI during the eDCH call based cell
capabilities and mobility scenarios (for more details refer to mobility chapter).

5.2 UE CATEGORIES
As the SF2 and 2msTTI are supported only by the xCEM, the UE categories 4, 5 and
6 are supported only by the xCEM in UA6 whereas the iCEM board keeps the same
capabilities as in UA5 (i.e UE CAT 4, 5 and 6 are not supported by iCEM).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 28/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Terminal
Category

Maximum
Number
of Codes

Minimum
SF

Category 1

SF 4

Category 2

SF 4

Category 3

SF 4

Category 4

SF 2

Category 5

SF 2

Category 6

SF 2

TTI
[ms]

Maximum
MAC-e
PDU Size
[Bits]

Maximum
Date Rate at
MAC-e layer
[Mbps]

10
10/
2
10
10/
2
10
10/
2

7110
14484/
2798
14484
20000/
5772
20000
20000/
11484

0.71
1.45/
1.40
1.45
2.00/
2.89
2.00
2.00/
5.74

Maximum
RLC
Throughput
[Mbps]
0.67
1.38/
1.28
1.38
1.89/
2.72
1.89
1.89/
5.44

Throughput @
ATM layer
(+30% protocol
headers)
[Mbps]
0.87
1.79/
1.66
1.79
2.45/
3.53
2.45
2.45/
7.07

Note: When 4 codes are transmitted in parallel, 2 codes shall be transmitted with SF2 and the other 2 with SF4

Table 1: UE categories

In UA6, the RNC configures the ETFCI table according to UE category and cell
capabilities (i.e. TTI type).

In order to optimize performance for HSUPA UE Categories 4 and 6, it is


recommended to set the uplink Timer Status Prohibit RLC attribute (for the cases
where E-DCH is established in UL) as follows.
Parameter

prohibitedStatusTimer

Object

UlRlcAckMode

Granularity

RNC, RlcConfClass

Range & Unit

Enum {10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170,
180, 190, 200, 210, 220, 230, 240, 250, 260, 270, 280, 290, 300, 310, 320, 330,
340, 350, 360, 370, 380, 390, 400, 410, 420, 430, 440, 450, 460, 470, 480, 490,
500, 510, 520, 530, 540, 550, 600, 650, 700, 750, 800, 850, 900, 950, 1000}
Ms

User & Class

Customer, 3

Value

For PS_HSDSCH_EDCH_IB_AM and SRB_EDCH_AMUM_UL instances of


RlcConfClass: 30
[UCU-III]
For the OneBTS UCU-III, only 10ms TTI is supported and minimum SF equal to 2SF2
in UA6 (i.e. cat 2, 4, and 6 on 2ms TTI are not supported). UCU-III supports up to
category 5, on 10 ms TTI only. It does not support category 6 (it would be managed
like a category 4 on 10ms TTI).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 29/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


5.3 {E-TFCI; TBS} TABLE
A {E-TFCI; Transport Block Size} table defines for each E-TFCI (E-DCH Transport
Format Combination Indicator) a corresponding Transport Block Size. Four {E-TFCI;
TBS} tables are defined in 3GPP TS25.321 [R05]: two tables corresponding to 10ms
TTI (i.e. 10ms TTI E-DCH TBS Table 0 and 10ms TTI E-DCH TBS Table 1) and
two tables corresponding to 2ms TTI (i.e. 2ms TTI E-DCH TBS Table 0 and 2ms TTI
E-DCH TBS Table 1). In UA6, all four tables are available, i.e. for each E-DCH TTI
type either one of the two corresponding tables may be configured.
X

As shown below in Figure 4, Table 0 has an exponential increase and Table 1 has a
linear increase. The choice of the {E-TFCI; Transport Block Size} table is linked with
the {Reference E-TFCI; Reference Power Offset} table, described in next section.
X

Regarding 10ms TTI, 128 E-TFCIs are defined for 10ms TTI E-DCH TBS Table 0,
and 121 E-TFCIs are defined for 10ms TTI E-DCH TBS Table 1. For both iCEM and
xCEM, it is strongly recommended to use 10ms TTI E-DCH TBS Table 1.
Regarding 2ms TTI, 128 E-TFCIs are defined for 2ms TTI E-DCH TBS Table 0, and
126 E-TFCIs are defined for 2ms TTI E-DCH TBS Table 1. For the xCEM (for which
2ms TTI is available), it is strongly recommended to use 2ms TTI E-DCH TBS Table
1.
Parameter
Range & Unit
User
Class
Value

Object
EdpchParameters
edchTfciTableIndex
Enum {2msTtiTable0, 2msTtiTable1, 10msTtiTable0, 10msTtiTable1}, N/A
Customer
Granularity RNC
0
EdpchParameters instance related to 10ms TTI: 10msTtiTable1
EdpchParameters instance related to 2ms TTI: 2msTtiTable1

Rule: edchTfciTableIndex setting


For 10ms TTI and 2ms TTI, it is strongly recommended to use respectively 10ms TTI E-DCH TBS
Table 1 and 2ms TTI E-DCH TBS Table 1.
This can be done by setting edchTfcsTableIndex = 10msTtiTable1 under each instance of
EdpchParameters related to 10ms TTI, and by setting edchTfcsTableIndex = 2msTtiTable1
under each instance of EdpchParameters related to 2ms TTI.

Restriction: edchTfciTableIndex Table 0 (2msTtiTable0 and 10msTtiTable0) must not be used


3GPP standard recommends the Table 1 for PS data.
The Table 0 is optimized for VoIP (which is is not used in UA06). Moreover the Table 0 is not adapted
to
the
UA6.0
EDCH
parameter
settings
(referenceEtfci/referenceEtfciPowerOffset,
ergch2IndexStepThreshold and ergch3IndexStepThreshold, )
As a consequence the Table 0 must not be used.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 30/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Figure 4: {E-TFCI; Transport Block Size} tables for 10ms TTI,


as defined in 3GPP TS 25.321

5.4 {REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLE


INPUTS OF E-TFC SELECTION ALGORITHM AT UE
When receiving a grant, in order to select the appropriate E-TFC the UE applies the ETFC Selection algorithm specified in 3GPP TS25.321 [R05]. The inputs of the E-TFC
Selection algorithm are:
X

Serving_Grant (also referred as SG):


Serving_Grant is the grant value deduced by the mobile from an E-AGCH or ERGCH command. Basically, Serving_Grant defines the largest E-TFC that the
mobile is allowed to use.

{E-TFCI; TBS} table:


The aim of this table has been described in section 5.3. For a given E-DCH call,
the same table is configured both at NodeB side and at UE side.
X

{E-TFCI; Power Offset} table:


This table defines for each E-TFCI a corresponding Power Offset (i.e. value
indicating the power ratio E-DPDCH / UL DPCCH, also referred as ed/c). For a
given E-DCH call, the same table is configured both at NodeB side and at UE
side.
B

E-DCH MAC-d flow-specific power offset:


Power offset assigned to each MAC-d flow of the considered E-DCH call.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 31/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


In UA5, since only one E-DCH MAC-d flow is supported per E-DCH call, there is
no need to configure MAC-d flow-specific power offsets. However, a value may be
specified for the unique MAC-d flow present via edchMacdPowerOffset
parameter (sometimes also referred as harq) under EdchUserService.
Recommended value is 0.
B

In UA6, up to two MAC-d flows one for user data and one for UL SRB are
supported on E-DCH for iBTS xCEM and OneBTS UCU-III. Each MAC-d flow can
be assigned a MAC-d flow-specific power offset, which value can be set per UL
RB (i.e. different MAC-d flow-specific power offset values can be set for
PS_EDCH and SRB_EDCH UL RBs). For a given UL RB, the MAC-d flow-specific
power offset is set via edchMacdPowerOffsetEdchTti10 (for 10ms E-DCH TTI)
and edchMacdPowerOffsetEdchTti2 parameter (for 2ms E-DCH TTI).

Amount of data to transmit on E-DCH in UE buffer

Available UE power

Number slots in next 10ms E-DCH TTI affected by a Compressed Mode gap.

E-DCH Minimum Set E-TFCI:


Unique E-TFCI value, configured at UE (and NodeB) via RRC (and NBAP) at EDCH call establishment. 3GPP TS 25.321 [R05] specifies that, within the limit
allowed by Serving_Grant, when UE is power-limited, UE is allowed to override
the E-TFCI limitation based on available UE Tx power criterion, up to E-DCH
Minimum Set E-TFCI value. In UA5, E-DCH Minimum Set E-TFCI IE is sent to UE
only if the board handling the E-DCH call is an xCEM. E-DCH Minimum Set ETFCI value is set via edchMinSetEtfci parameter under EdchParameters.
Please refer to 7.2 for a detailed description of edchMinSetEtfci parameter.
X

RETRIEVING FULL {E-TFCI; PO} TABLE BASING ON REFERENCE VALUES


Regarding the {E-TFCI; TBS} table, since its contents is fully standardized, the only
quantity provided to UE is the table type (e.g. 10ms TTI E-DCH TBS Table 1). On
the other hand, the {E-TFCI; Power Offset} table is not standardized; i.e.
operator/vendor can fully customize the table. In order to avoid too much signaling
when configuring the {E-TFCI; TBS} table both at NodeB and at UE side, the RNC
only sends a few reference couples of values which constitute: the {Reference ETFCI; Reference Power Offset} table. The {Reference E-TFCI; Reference Power
Offset} table is a subset of the whole {E-TFCI; Power Offset} table. The whole table is
retrieved both at NodeB and at UE side by using the extrapolation formula specified in
3GPP TS 25.214 [R12], section 5.1.2.5B.2.
X

Figure 5 shows the principle of retrieving the whole {E-TFCI; Power Offset} table
basing on the {Reference E-TFCI; Reference Power Offset} table. X-axis represents
TBS, and Y-axis represents Power Offset in dB.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 32/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


E-DPDCH power vs. transport block size

E-DPDCH power relativ to DPCCH (dB)

30

25

20

15

10

0.2

0.4

0.6

0.8
1
1.2
TB size (bits)

1.4

1.6

1.8

2
4

x 10

Reference signaled E-TFCI


Figure 5: E-DPDCH Power vs. Transport Block Size

Again, in order to avoid too much signaling when configuring the {Reference E-TFCI;
Reference Power Offset} table both at NodeB and at UE side, the RNC sends coded
values (after quantization) for the Reference Power Offsets (i.e. power ratio E-DPDCH
/ UL DPCCH, also referred as ed/c). The coded values for Power Offsets are
specified in 3GPP TS 25.213 [R06], Table 1B.1, and recalled below for convenience.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 33/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Signaled values for E-DPDCH
B

Quantized amplitude ratios


Aed =ed/c
168/15
150/15
134/15
119/15
106/15
95/15
84/15
75/15
67/15
60/15
53/15
47/15
42/15
38/15
34/15
30/15
27/15
24/15
21/15
19/15
17/15
15/15
13/15
12/15
11/15
9/15
8/15
7/15
6/15
5/15
B

29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

Table 2: Quantization for E-DPDCH (from 3GPP TS 25.213)


B

{REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLES USED IN UA6


Below two parameters are used to define the different {Reference E-TFCI; Reference
Power Offset} tables within the RNC.
Parameter
Range & Unit
User
Class
Value

Object
ReferenceEtfciConfList
referenceEtfci
Integer [0 127], N/A
Customer
Granularity
RNC
0
See below Table 3, Table 4, Table 5, Table 6 and Table 7

Parameter
Range & Unit
User
Class
Value

Object
ReferenceEtfciConfList
referenceEtfciPowerOffset
Integer [0 29], N/A
Customer
Granularity
RNC
0
See below: Table 3, Table 4, Table 5, Table 6 and Table 7

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 34/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


UA5.1 UA6 Delta: [iCEM] [xCEM] {Reference E-TFCI; Reference Power Offset} table

Due to the introduction of 2ms E-DCH TTI in UA6/xCEM, new {Reference E-TFCI; Reference
Power Offset} tables (corresponding to 2ms TTI cases) are introduced in UA6.

Regarding 10ms TTI, as for UA5.1, due to the specific implementation and behavior of xCEM EDCH functions, the recommended {Reference E-TFCI; Reference Power Offset} table is
different for iCEM and xCEM.

The four recommended tables for iBTS (i.e. iCEM, 10ms TTI on xCEM, 2ms TTI with
E-DPDCH min SF of 2xSF2 on xCEM, 2ms TTI with E-DPDCH min SF of
2xSF2+2xSF4 on xCEM) and the recommended table for OneBTS, as well as the
recommended configuration method are described below.

[iCEM] [xCEM]
U

Reason for using board-specific {Ref E-TFCI; Ref PO} tables (10ms TTI case):
U

Regarding 10ms TTI, due to the specific implementation and behavior of xCEM EDCH functions, the recommended {Reference E-TFCI; Reference Power Offset} table
is different for iCEM and xCEM. In particular, for xCEM, in order to avoid UL load
divergence issues due to user self-interference for high data rate transmission in
channel profiles with bad orthogonality, the strategy is to allow higher UL DPCCH
power (set via maxSirTarget parameter) while using smaller E-DPDCHs / UL DPCCH
power ratio (set via {Reference E-TFCI; Reference Power Offset} table), compared
with iCEM. Please refer to section 9.1.2.3.4 for more information on the recommended
setting for maxSirTarget for E-DCH calls.
X

For iCEM, the recommended {Reference E-TFCI; Reference Power Offset} table is as
follows.
ReferenceEtfciConfList

referenceEtfci

referenceEtfciPowerOffset

11

11

15

85

22

95

23

96

24

Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset} table

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 35/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


For xCEM with 10ms, the recommended {Reference E-TFCI; Reference Power Offset}
table is as follows.
ReferenceEtfciConfList

referenceEtfci

referenceEtfciPowerOffset

10

25

16

51

18

106

19

Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table

For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
ReferenceEtfciConfList

referenceEtfci

referenceEtfciPowerOffset

13

14

83

20

Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table

For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2+2xSF4, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
ReferenceEtfciConfList

referenceEtfci

referenceEtfciPowerOffset

13

14

58

15

91

18

98

21

Table 6: xCEM/2ms TTI/2xSF2+2xSF4 recommended {Reference E-TFCI; Reference Power


Offset} table

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 36/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


[UCU-III]
For the OneBTS UCU-III, the recommended {Reference E-TFCI; Reference Power
Offset} table is as follows.
ReferenceEtfciConfList

referenceEtfci

referenceEtfciPowerOffset

10

13

25

17

Table 7: UCU-III recommended {Reference E-TFCI; Reference Power Offset} table

Each instance of EdpchParameters object includes (among other parameters) one


{Ref E-TFCI; Ref PO} table; this table is defined by all the ReferenceEtfciConfList
instances under the considered EdpchParameters instance.

{REF E-TFCI; REF PO} TABLE SELECTION MECHANISM


In UA5, at the establishment of an E-DCH call, the {Ref E-TFCI; Ref PO} table
configured by RNC (both at UE side and NodeB side) is selected according to the
following elements:

HSUPA Category of the considered UE,

Type of board (iCEM or xCEM) handling E-DCH for the E-DCH serving cell
(known by E-DPDCH SF capability of the E-DCH serving cell).

Remark: The reason why cell E-DPDCH SF capability is taken into account in {Ref ETFCI; Ref PO} table selection mechanism is to make possible the use of a different
table for a cell served by an iCEM and a cell served by an xCEM. Indeed, the optimal
table is different for iCEM and xCEM. The RNC does not have the direct knowledge of
the type of board (iCEM or xCEM) serving a given cell. However, the RNC has the
knowledge of the E-DPDCH SF capability of a given cell. Since the SF capability for
iCEM (2xSF4) is different than for the xCEM (2xSF2), by looking at the SF capability
of a given cell the RNC can know the type of board that serves it.
U

In UA5, at the establishment of an E-DCH call, the requested UL service (e.g. E-DCH
stand-alone or E-DCH + CS AMR NB) is not taken into account in {Reference E-TFCI;
Reference Power Offset} table selection mechanism. In UA6, an enhancement has
been brought to {Ref E-TFCI; Ref PO} table selection mechanism, which consists into
taking into account the requested UL service (as well as HSUPA UE Category and
type of board handling E-DCH for the E-DCH serving cell). This is achieved by using
multiple EdpchInfoClass instances, as shown in Figure 6. In addition, in UA6, the
requested type of E-DCH TTI (i.e. 10ms or 2ms) is also taken into account in the table
selection mechanism.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 37/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


UA5.1 UA6 Delta: {Reference E-TFCI; Reference Power Offset} table selection mechanism
In UA6, an enhancement has been brought to {Reference E-TFCI; Reference Power Offset} table
selection mechanism, which consists into taking into account the requested UL service (as well as
HSUPA UE Category and type of board handling E-DCH for the E-DCH serving cell). In addition, in
UA6, the requested type of E-DCH TTI (i.e. 10ms or 2ms) is also taken into account.

In UA6, the parameters model at OMC-R (i.e. at RNC) is defined as follows.


RadioAccessService

EdpchInfoClass

EdpchParameters

ReferenceEtfciConfList

UlUserService

UlRbSetConf

DedicatedConf

EdchTfcConf

EdchUserService

EdchParameters

EdchCellClass

ReferenceEtfciConfList

Figure 6: UA6 E-DCH parameters model at OMC-R


Once the EdpchInfoClass instance has been selected according to the requested UL
service, under this EdpchInfoClass instance, one instance of EdpchParameters
object is selected by RNC among 9 available instances. Each instance of
EdpchParameters object includes (among other parameters) one {Ref E-TFCI; Ref
PO} table. The parameters and the {Ref E-TFCI; Ref PO} table under the selected
EdpchParameters instance will be used to configure the considered E-DCH call. The
EdpchParameters instance is selected as follows.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 38/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Primary Cell E-DPDCH


SF Capability

Step 1. Primary Cell HSUPA Category is computed basing on the E-DPDCH SF


capability of the primary cell and the E-DCH TTI selected for the E-DCH call,
according to the following table.

SF64
SF32
SF16
SF8
SF4
2xSF4
2xSF2
2xSF2+2xSF4

Selected E-DCH TTI


10ms
2ms
16
16
16
16
16
16
16
16
1
2
3
2
5
4
16
16

Table 8: Primary Cell HSUPA Category according to Primary Cell EDPDCH SF capability and selected E-DCH TTI
Remarks:
U

Value 16 for Primary Cell HSUPA Category is a special value, used so that
Target HSUPA UE Category is not driven by Primary Cell HSUPA Category in
Step 2 of EdpchParameters instance selection algorithm (see Step 2 below).

For the case where the Primary Cell E-DPDCH SF Capability reported by the
NodeB is 2xSF2+2xSF4 but with isSrbOnEdchAllowedWhenTrbOnEdch
parameter set to False (i.e. UA6 33581 SRB on E-DCH during Call disabled),
the Primary Cell E-DPDCH SF Capability used in the {Ref E-TFCI; Ref PO} table
selection mechanism (in Step 1 of EdpchPararmeters instance selection
algorithm) is forced to 2xSF2.

Step 2. Target HSUPA UE Category is computed as the minimum (mathematical


minimum, not most restrictive) between Primary Cell HSUPA Category and
HSUPA UE Category.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 39/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Target HSUPA
UE Category

Step 3. EdpchParameters instance is selected among the 9 available instances,


basing on the computed Target HSUPA UE Category and the E-DCH TTI
selected for the considered E-DCH call, according to the following table.

1
2
3
4
5
6

Selected E-DCH TTI


10ms
2ms
UECategory1EdchTti10ms N/A
UECategory2EdchTti10ms UECategory2EdchTti2ms
UECategory3EdchTti10ms N/A
UECategory4EdchTti10ms UECategory4EdchTti2ms
UECategory5EdchTti10ms N/A
UECategory6EdchTti10ms UECategory6EdchTti2ms

Table 9: EdpchParameters instance according to Target HSUPA UE


Category and selected E-DCH TTI

{REF E-TFCI; REF PO} TABLE SETTING AT OMC


Engineering Recommendation:
Configuration of {Reference E-TFCI; Reference Power Offset} tables via instances of
EdpchParameters objects.
[iCEM] [xCEM]
For all EdpchInfoClass instances:

Set iCEM recommended table (Table 3) for the following EdpchParameters instances:
UECategory1EdchTti10ms
UECategory2EdchTti10ms
UECategory3EdchTti10ms

Set xCEM/10ms TTI recommended table (Table 4) for the following EdpchParameters
instances:
UECategory4EdchTti10ms
UECategory5EdchTti10ms
UECategory6EdchTti10ms

Set xCEM/2ms TTI/2xSF2 recommended table (Table 5) for the following EdpchParameters
instances:
UECategory2EdchTti2ms
UECategory4EdchTti2ms

Set xCEM/2ms TTI/2xSF2+2xSF4 recommended table (Table 6) for the following


EdpchParameters instance:
UECategory6EdchTti2ms

[UCU-III]
For all EdpchInfoClass instances, set UCU-III recommended table (Table 7) for all
EdpchParameters instances.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 40/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


{REF E-TFCI; REF PO} TABLE RECONFIGURATION
The {Reference E-TFCI; Reference Power Offset} table (as well as other E-DCH call
attributes) may be reconfigured while in E-DCH call, for one of the following reasons.

Primary Cell change:


Please refer to [Vol.6] (Mobility), section 3.3.2, of this document.
X

UL Radio Bearer reconfiguration:


While in E-DCH call (i.e. at least one PS UL RB is established on E-DCH
transport
channel),
if
current
UL
service
changes
(e.g.
UlUserService/PS_EDCHxSRB_3_4K

/PS_EDCHxSRB_EDCH),
the
EdpchInfoClass instance is reselected accordingly. Then E-DCH call attributes
are reconfigured (both at UE side and NodeB side). The reconfiguration is done
towards Node B via NBAP Radio Link Reconfiguration and towards UE via Radio
Bearer Reconfiguration procedures.

5.5 FRAME PROTOCOL ON IUB


UNBUNDLING MODE
When E-DCH is configured with TTI of 10ms, the NodeB sends to the RNC one IUB
EDCH FP Data Frame, containing one MAC-e PDU, each 10ms.
[xCEM]
When E-DCH is configured with TTI of 2ms, the NodeB may send data to the RNC in
either bundling mode (which consists in NodeB sending data every 10ms TTI and
bundling several 2-ms TTI together) or unbundling mode (which consists in NodeB
sending E-DCH FP Data Frame every 2ms). In UA6, only unbundling mode is
supported.
isEdchFpBundlingModeForEdchTti2msAllowed: when a RAB is mapped on EDCH with a TTI 2ms, this flag specifies if the NodeB shall bundle the E-DCH FP frame
of 2ms into an FP frame of 10ms (this parameter is specific xCEM).
Parameter
Range & Unit
User
Class
Value

isEdchFpBundlingModeForEdchTti2msAllowed
Boolean (True, False)
Customer
3
False

Object

NodebConfClass

Granularity

NodebConfClass

Restriction: In UA06, for E-DCH configured with TTI of 2ms, xCEM only supports unbundling
mode, which consists in NodeB sending E-DCH FP Data Frame every 2ms
The parameter isEdchFpBundlingModeForEdchTti2msAllowed must be set to False.

EDCH FP CRC PAYLOAD PRESENCE


The RNC performs a validation of the payload section of the Iub E-DCH data frames
(payload CRC check).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 41/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The NodeB are required (through NBAP signaling at E-DCH call establishment) to
include the payload CRC in each E-DCH data frames.
This payload CRC check is activated at the RNC by default. The parameter
isEdchFpCrcPayloadPresence is defined in the OMC-R model but it is unused.

5.6 MISCELLANEOUS
POWER OFFSET FOR SCHEDULING INFO
As explained above in 5.4, Power Offsets (i.e. E-DPDCH/UL DPCCH power ratio, also
referred as ed/c), are configured via the {Reference E-TFCI; Reference Power
Offset} table. However, for the specific case of a MAC-e PDU with stand-alone
Scheduling Information (SI) field (i.e. no user data transmitted), a specific Power
Offset value is applied instead of the value specified by the table (according to 3GPP
TS 25.331 [R09], see Power Offset for Scheduling Info IE). The value in dB for this
specific Power Offset is set via powerOffsetForSchedInfo parameter.
X

[iCEM] [xCEM]
The following parameter is used for 10ms TTI:
Parameter
Range & Unit
User
Class
Value

powerOffsetForSchedInfo
Integer [0 6], dB
Customer
3
6

Object

EdchCellClass

Granularity

EdchCellClass

The following parameter is used for 2ms TTI:


Parameter
Range & Unit
User
Class
Value

powerOffsetForSchedInfoEdchTti2ms
Integer [0 6], dB
Customer
3
3

Object

EdchCellClass

Granularity

EdchCellClass

[UCU-III]
Parameter
Range & Unit
User
Class
Value

powerOffsetForSchedInfo
Integer [0 6], dB
Customer
3
0

Object

EdchCellClass

Granularity

EdchCellClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 42/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


PLnon-max
PL stands for Puncturing Limit. PLmax and PLnon-max quantities are used as inputs in
the algorithm (implemented both at NodeB side and at UE side) computing for each ETFCI the required number of E-DPDCH(s) and their SF (see 3GPP TS 25.212 [R03]).
B

PLmax value is specified in 3GPP TS 25.212 [R03], section 4.8.4.1.


B

On the other hand, PLnon-max value is not specified by 3GPP. In UA5, PLnon-max value
could not be modified by the customer (hard-coded parameter). In UA6, PLnon-max
value can be set via plNonMax parameter under EdpchParameters.
B

plNonMax: Used to set the value of PLnon-max. plNonMax parameter value must be
specified as plNonMax = 25 * PLnon-max .
B

Parameter
Range & Unit
User
Class
Value

plNonMax
Integer [11 25], 25 * PLnon-max
Customer
3
EdpchParameters instance

Object

EdpchParameters

Granularity

RNC

UECategory1EdchTti10ms

[iCEM] [xCEM] 25
(corresponds to PLnon-max = 1)

plNonMax value

UECategory2EdchTti10ms

UECategory3EdchTti10ms

[UCU-III] 18
(corresponds to PLnon-max = 0.72)
B

UECategory4EdchTti10ms
18 (corresponds to PLnon-max = 0.72)

UECategory5EdchTti10ms

UECategory6EdchTti10ms
UECategory2EdchTti2ms

20 (corresponds to PLnon-max = 0.8)

UECategory4EdchTti2ms

UECategory6EdchTti2ms
Remark: Similarly to {Reference E-TFCI; Reference Power Offset} table, the PLnon-max
value used for a given UE is selected according to type of board handling E-DCH for
the E-DCH serving cell, HSUPA UE Category, E-DCH TTI type and UL service.
U

UL ILPC ALGORITHM SELECTION


The Uplink Inner Loop Power Control procedure is performed by the NodeB to control
the UE Transmit Power, by sending TPC (Transmit Power Control) commands to the
UE. Please refer to UA6 UPUG [R01], Vol.9, section 2 for details on this procedure.
X

Two ILPC algorithms are defined by the 3GPP standard: the Algo1 and the Algo2. The
Algo1 is the Alcatel-Lucent recommended algorithm for all cases, except for
UeCategory4 TTI2ms and UeCategory6 TTI2ms calls. For these EDCH calls, the
Algo2 is the most suitable: it ensures stable performance because it is less reactive to
power variations (TPC rate is 300 command/s with algo2 while it is 1500 commands/s
with algo1).
The granularity of the parameter powerCtrlAlgo (refer to UPUG Vol.9 for further
details regarding this parameter) is the group of cells, not the type of calls, hence it
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 43/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


does not allow to force the use of the Algo2 only for the UeCategory4 TTI2ms and
UeCategory6 TTI2ms calls.
In order to achieve the proper algorithm selection, the parameter Reserved0 in the
Radio Access Service, is used. The figure below recalls the usage of the Reserved0
parameter, 1st byte and 4th byte, for EDCH configuration purpose.
P

Note the 2nd byte and 3rd byte are also used, respectively to control the execution time
of the reconfiguration from cell_DCH to Cell_FACH (refer to UPUG Vol.11 for further
details) and to differentiate US Market RNC from Global Market RNC.
P

bit number

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

16

15

14

13

12

11

10

Reserved0

The bits 24 and 25 are used for UL


ILPC Algorithm selection for
UeCat4 TTI2ms and UeCat6
TTI2ms EDCH calls. See below.

The bit 16 is used to


distinguish Global
Market (value 0) and
US Market (value 1)

The bit 8 is used to control


the execution time of the
reconfiguration from
cell_DCH to Cell_FACH

The bits 0, 1 and 2


are used for SRB on
EDCH activation. See
section 10.1 in Vol4.

Figure 7: reserved0 bit configuration

Reserved0 bit 24, bit 25 (4th byte)


P

The bit 24 and the bit 25 are used to select the UL ILPC algo2 for EDCH UeCategory4
call and UeCategory6 call, when it is in TTI2ms cell:

Reserved0 bit 24: SRB UL ILPC algorithm selection for UeCategory4 call
when it is in TTI2ms cell
o

Bit 24 = 0: Use default Algo1 for EDCH UeCategory4 call when it is in


TTI2ms cell

Bit 24 = 1: Use Algo2 for EDCH UeCategory4 call when it is in


TTI2ms cell

Reserved0 bit 25: SRB UL ILPC algorithm selection for UeCategory6 call
when it is in TTI2ms cell
o

Bit 24 = 0: Use default Algo1 for EDCH UeCategory6 call when it is in


TTI2ms cell

Bit 24 = 1: Use Algo2 for EDCH UeCategory6 call when it is in


TTI2ms cell

Parameter
Range & Unit

Reserved0 bit 24
Bit: 0 or 1 Kind of Boolean

Object

RadioAccessService

User
Class
Value

Customer
3-a2
1

Granularity

RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 44/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range & Unit

Reserved0 bit 25
Bit: 0 or 1 Kind of Boolean

Object

RadioAccessService

User
Class
Value

Customer
3-a2
1

Granularity

RNC

Rule: UL ILPC Algo2 must be used for EDCH UECategory4 call and EDCH UECategory6 call
when the cell is TTI2ms
In order to force the use of UL ILPC Algo2 for EDCH UeCategory4 call and EDCH UECategory6 call,
when the cell is TTI2ms, the bit 24 and the bit 25 of the parameter Reserved0 must be set to 1.
Note that the bit 24 and the bit 25 have no effect when the cell is TTI10ms: in this case the UL ILPC
Algo1 is used regardless of their values.

Engineering Recommendation: reserved0 typical settings


Hereafter are the typical values to be used to support high bit-rate in UL:
Reserved0
Market

Value

Meaning
1 byte is 0x00: refer to the section 10.1 in Vol4.
2nd byte is 0x05: refer to the UA6 UPUG [R01], Vol.11
3rd byte is 0x00: used to easily identify a Global Market RNC
4th byte is 0x03: UL ILPC Algo2 is used for UeCategory4 TTI2ms calls
and for UeCategory6 TTI2ms calls.
1st byte is 0x07: refer to the section 10.1 in Vol4.
2nd byte is 0x12: refer to the UA6 UPUG [R01], Vol.11
3rd byte is 0x01: used to easily identify a US Market RNC
4th byte is 0x00: The default UL ILPC Algo1 is used (anyway, the 4th byte
is ignored because TTI 2ms is not supported on UCU-III.)
st
P

Global
Market

50332928

US Market

70151

E-DCH Mac-d Flow Power Offset


As it has been explained in 5.4, the E-DCH Mac-d Flow Power Offset, also referred to
as harq, is a power offset to be applied on E-DPDCH, relatively to DPCCH. It is
signaled at UE (and Nodeb) via RRC (and NBAP) at E-DCH call establishment.
X

The UE applies the E-DCH Mac-d Flow Power Offset on top of transport block size
specific power offset when actually transmitting data on E-DPDCHs. In UA6.0, the EDCH Mac-d Flow Power Offset is configurable per EDCH RB (typically an E-DCH
Mac-d Flow Power Offset is configurable for PS_EDCH RB and another one is
configurable for SRB_EDCH).
Both UE and Nodeb use the E-DCH Mac-d Flow Power Offset for the calculation of
the TPR (Traffic to Pilot power Ratio), according to the formula in 3GPP TS 25.214
[R12], section 5.1.2.5B.2.
X

E-DCH Mac-d Flow Power Offset value is set via edchMacdPowerOffsetEdchTti10


(this parameter is used when the call is configured on TTI10ms), and
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 45/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


edchMacdPowerOffsetEdchTti2 (this parameter is used when the call is configured
on TTI2ms) under UlRbSetConf/EdchParameters.

edchMacdPowerOffsetEdchTti10:

The

recommended

value

for

edchMacdPowerOffsetEdchTti10 is 0.
Parameter
Range & Unit
User
Class
Value

edchMacdPowerOffsetEdchTti10

Object

EdchParameters

Granularity

UlRbSetConf

[0..6] step:1

Customer
0
0

[XCEM] edchMacdPowerOffsetEdchTti2: when the E-DCH TTI is 2ms, two EDCH Mac-d flows may be established (the one bearing the PS EDCH, and
potentially the one bearing the SRB EDCH), so it might be useful to specify an
offset for each Mac-d flow in order to get different probability of retransmission.

Parameter
Range & Unit
User
Class
Value

edchMacdPowerOffsetEdchTti2

Object

EdchParameters

Granularity

UlRbSetConf

[0..6] step:1

Customer
0
For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 0

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 46/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

6 MAC-E SCHEDULER ICEM


6.1 UL LOAD FINE PREDICTION
In UA5.0 the UL load estimation model is configured for the worst case (frequency
reuse factor of 0.6) leading to very pessimistic estimation of UL load in case of low
extra-cell interference and consequently low HSUPA cell throughput.
A self tuning mechanism was implemented in UL load prediction algorithm in UA5.0.2
to tune automatically the UL load prediction model according to the radio environment.
The basic principle is to adapt a margin into the prediction function in order to modify
the prediction of ROT increase based on measurements. The overall process for load
management will then be the following one:
1) based on E-DCH contribution for the current RTWP period, and RoT_Non_Edch
estimated during previous RTWP period, compute the expected ROT with the
prediction function: ROT_predict
2) Comparing RoT_predict to ROT effectively measured (RoT_meas = RTWPRTWP_ref) will allow to tune the margin.

The scheduler will then allocate new E-TFCI based on the updated prediction function.

Two new parameters are introduced to activate and configure the UL load fine
prediction.

rotPredictionCorrection is a flag used to activate/deactivate the UL load fine


prediction.
Parameter
Range & Unit
User
Class
Value

rotPredictionCorrection

Object

EdchConf

Granularity

BTS

Off, On

Customer
3
ON

rotMarginPrediction is the adjustment of the prediction margin of the RoT (Rise of


Thermal). This parameter is only used if parameter: rotPredictionCorrection is set to
ON. This parameter is specific iCEM.
Parameter
Range & Unit
User
Class
Value

rotMarginPrediction

Object

EdchConf

Granularity

BTS

[0..10]

Customer
3
5

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 47/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Rule: rotMarginPrediction
rotMarginPrediction corresponds to the UL load prediction model correction step x 100 (i.e. a
rotMarginPrediction set to 3 correspond to a step of 0.03).
This parameter setting is a trade off between time of convergence and fluctuation of RoT_meas close
to RoT_max.
According to system simulation results, 0.05 is an optimal value.

6.2 CONSIDERATION OF SELF-INTERFERENCE IN UL LOAD


PREDICTION
INTRODUCTION
As explained below in section 6.4, the iCEM MAC-e scheduler located in the NodeB
needs as an input the uplink load available for the E-DCH traffic of the considered cell.
Regarding the iCEM, in order to estimate, at each TTI, the UL load available for EDCH, the following actions are performed within the NodeB:
X

Derivation, every 24 hours, of the thermal noise level (RTWPref) at the BTS, via
thermal noise level self-learning algorithm (c.f. section 4.1.1), basing on
measurements at the BTS
B

Derivation, every 100ms, of the Received Total Wide-band Power (RTWP),


basing on measurements at the BTS

Estimation, every E-DCH TTI (i.e. 10ms since only 10ms TTI is supported on
iCEM), of the current total UL load. This action is also often referred as UL load
prediction. The accuracy of this estimation has an important impact on the
performance of the MAC-e scheduler.

In section 6.1 has already been presented an enhancement UL Load Fine


Prediction introduced in UA5.0.2 to the module which estimates every E-DCH TTI
the current total UL load. The main objective of this enhancement is to take into
account the current level of UL extra-cell interference, when estimating current total
UL load.
X

Another enhancement Self-interference in MAC-e Scheduler (34221) feature is


introduced in UA5.1, for the iCEM, to the module which estimates every E-DCH TTI
the current total UL load. The main objective of UA5.1/iCEM 34221 feature is to take
into account the part of self-interference in the UL signal of E-DCH users, when
estimating current total UL load.

FEATURE DESCRIPTION
Remark: UA5.1 34221 feature applies only to the iCEM board.
U

Actually, for channel profiles with large delay spread, orthogonality between the
different UL codes of a same user is not perfect. In other words, when focusing on a
given UL code (e.g. the DPCCH) of a user, some part of the energy of other UL codes
(e.g. E-DPDCHs) of the same user is seen as interference.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 48/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Before the introduction of UA5.1/iCEM 34221 feature, since this self-interference
phenomenon was not taken into account when estimating current total UL load, the
computed UL load available for E-DCH could be over-estimated (compared to the
actual UL load available for E-DCH). Consequently, especially for channel profiles with
bad orthogonality, the grants allocated could be too large, which could lead to UL
overload and thus de-grant of E-DCH users (iCEM defense mechanism against UL
overload is described in section 6.3).
X

The principle of UA5.1/iCEM Self-interference in MAC-e Scheduler (34221) feature is


the following. When estimating current total UL load every TTI, the contribution of
each E-DCH user to the total UL load is computed. With 34221, a new quantity
which indicates the orthogonality degree in the UL propagation channel of the
considered user, is computed and taken into account when estimating the contribution
of this E-DCH user to the total UL load. For a given E-TFC used by the considered
user, the consideration of leads to increase the contribution of the considered user
when its UL propagation channel has bad orthogonality, and to decrease it when its
UL propagation channel has good orthogonality.
Remarks:
U

In UA5.1/iCEM 34221, since the estimation of the orthogonality degree is not


accurate when the received signal from the considered user is low, a correction is
applied to the computed . This correction has for effect to consider an
orthogonality degree better than the orthogonality degree actually estimated. In
other words, this correction on consists in decreasing the impact of the feature
on the estimation of the contribution of a given E-DCH user to the total UL load,
when the received power from this user is low.

The improvement on the accuracy of the estimation of current total UL load


brought by UA5.1/iCEM 34221 is only used by the MAC-e scheduler in the
NodeB. The quantity RTWPnon E-DCH sent every 100ms from the NodeB to the RNC
via NBAP (c.f. section 4.1.1) does not benefit from this improvement.
B

Restriction: RTWPnon E-DCH sent to the RNC does not benefit from UA5.1/iCEM 34221 feature
B

The improvement on the accuracy of the estimation of current total UL load brought by 34221 is only
used by the MAC-e scheduler in the NodeB. The quantity RTWPnon E-DCH sent every 100ms from the
NodeB to the RNC via NBAP does not benefit from this improvement.
B

EXPECTED BENEFITS OF UA5.1/iCEM 34221 FEATURE


With the introduction of UA5.1/iCEM 34221, the self-interference phenomenon is
taken into account when estimating current total UL load, which leads to a more
accurate estimation of the UL load available for E-DCH performed each E-DCH TTI.
Consequently, when 34221 is activated, especially for channel profiles with bad
orthogonality and for E-DCH users having a high bit rate, the grants allocated by the
MAC-e scheduler tend to be smaller, which leads to less occurrences of UL overload,
thus less de-grant of E-DCH users. Hence, with 34221, an improved average E-DCH
cell throughput and an improved stability of the network radio UL load are expected.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 49/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


In some specific cases, the throughput of an E-DCH user transmitting at high bit rate
may be degraded with the activation of 34221. However, the average E-DCH cell
throughput should increase so this should not be an issue.

ACTIVATION OF UA5.1/iCEM 34221 FEATURE


UA5.1/iCEM Self-interference in MAC-e Scheduler (34221) feature can be activated
via rotOrthogonalityEstimation activation flag under EdchConf object.
Parameter
Range & Unit
User
Class
Value

rotOrthogonalityEstimation
Enum {Off, On}, N/A
Customer
3
On

Object

EdchConf

Granularity

BTSCell

6.3 OVERLOAD DETECTION: RTWP ALARM


The non E-DCH RTWP is estimated and averaged over 100 ms period. It is based on
the RTWP estimation minus the E-DCH contribution:

RTWPnonE DCH = RTWP RTWPE DCH


When the RTWP exceeds the maximum allowed RTWP (totalRoTMax) by more than
the RTWP margin and during a period of at least rtwpTimeDetection, all E-DCH UE
are de-granted.

rtwpTimeDetection

RoT
ALARM
rtwpMargin

totalRoTMax

OK
OK
Time
Figure 8: RTWP exceeding margin
Parameter
Range & Unit
User
Class
Value

rtwpMargin

Object

BTSCell

Granularity

Cell

[0.5..2.0] step:0.5 dB

Customer
3
2 dB

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 50/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range & Unit
User
Class
Value

rtwpTimeDetection

Object

BTSCell

Granularity

Cell

[100..400] step:100 ms

Customer
3
400 ms

6.4 GRANT COMPUTATION


E-DCH scheduling is performed through E-AGCH signaling. The E-AGCH contains the
grant information for one given user. The grant is the maximum allowed power
transmitted on the E-DPDCH. Note that this takes also into account multiple physical
E-DPDCH (2xSF4).
The grant index value belongs to the following table from [R03]:
X

Absolute Grant Value


(168/15)2x6
(150/15)2x6
(168/15)2x4
(150/15)2x4
(134/15)2x4
(119/15)2x4
(150/15)2x2
(95/15)2x4
(168/15)2
(150/15)2
(134/15)2
(119/15)2
(106/15)2
(95/15)2
(84/15)2
(75/15)2
(67/15)2
(60/15)2
(53/15)2
(47/15)2
(42/15)2
(38/15)2
(34/15)2
(30/15)2
(27/15)2
(24/15)2
(19/15)2
(15/15)2
(11/15)2
(7/15)2
ZERO_GRANT*
INACTIVE*
P

Index
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

Table 10: Grant Index values

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 51/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Once the grant is signaled, the E-DPDCH power should not exceed the grant
information:

n. ed2 < signaled grant value


Where n stands for the number of E-DPDCH physical channels.
The HSUPA scheduler monitors the available UL load. An average value of the UL
RTWP is available once every 100 ms.
The grant sent to each UE is computed by the MAC-e scheduler based on:

UL load available for HSUPA

Number for E-DCH UE asking for grant allocation

Scheduling Information transmitted by each UE. The scheduling information


are
transmitted
periodically
on
the
E-DPDCH
according
to
periodicityOfSchedInfoGrant
and
periodicityOfSchedInfoNoGrant,
depending on whether the UE is granted or not (please refer to section 7.4. for
further details about these two parameters). They contain the following
information:
o

Total E-DCH buffer status (TEBS, 5 bits)

Highest priority logical channel ID (HLID, 4 bits)

Highest priority logical channel buffer status (HLBS, 4 bits)

UE transmission power headroom (UPH, 5 bits):


Power ratio of maximum allowed UE transmit power to DPCCH pilot
bit transmit power.

Happy bit: this bit is transmitted on the E-DPCCH and represents the UE
state according to his current max grant notification.

E-BBU capacity limitations.

The resulting maximum grant allocation is the minimum of all grant allocations
provided by each of the step described above and is sent on one E-AGCH (RNTI and
Grant info).

Parameter
Range & Unit
User
Class
Value

Parameter
Range & Unit
User
Class
Value

happyBitDelay

Object

EdchCellClass

Granularity

RNC,
EdchCellClass

Enum {2, 10, 20, 50, 100, 200, 500, 1000}

Customer
3
50

happyBitDelayEdchTti2ms

Object

EdchCellClass

Granularity

EdchCellClass

Enum {2, 10, 20, 50, 100, 200, 500, 1000}

Customer
3
10

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 52/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


6.5 MAC-E SCHEDULER
The MAC-e scheduling (located in the E-BBU in the Node B) of the different E-DCH
users of the cell is done by providing absolute grants (E-AGCH channel) when the cell
is the serving cell of the call. Each UE will adapt its throughput on E-DPDCH
according to the grants it has received, by selecting an E-TFC in the E-TFCS that is
compatible with the power granted.
The grants are computed by the scheduler to provide some fairness between users.
They are limited by the fact that the global uplink interferences level from must not go
above a certain threshold (totalRotMax over which the system might become
instable and might diverge) and by the BTS processing capabilities dedicated to EDCH. The main target of the scheduler is to grant UEs so that the total UL load of the
cell stays near the target load (totalRotMax), but not above. If the uplink load gets
above this limit, then the scheduler will reduce the grants of the E-DCH links. In case
of radio overload (due to other traffics: CCH, DCH, inter-cell interferences and other
interferences), the grants of E-DCH users get down to 0 (ZERO_GRANT) in order to
avoid radio divergence. The radio overload condition is defined by the fact that the UL
load is above the RTWPlimit (totalRotMax + rtwpMargin) during a certain time
(rtwpTimeDetection). If the UL load is below the limit then the E-DCH UEs may be
granted more.
When the grant allocated to a given E-DCH UE is modified, the MAC-e scheduler
reevaluates the contribution of this UE to the total uplink load. The MAC-e scheduler
computes grants of all users so that the total uplink load stays close to the target total
uplink load (set via totalRotMax) without exceeding it.
In case grants are reduced, this will reduce the load of the system and will free
resources for other E-DCH users. However the UE which grants have been reduced
will continue using former grants for ongoing H-ARQ retransmissions, meaning that
resources cannot be reallocated immediately to other users.
RATE SCHEDULING
In UA6/iCEM, only one type of E-DCH scheduling is supported: Rate Scheduling.
Parameter
Range & Unit
User
Class
Value

Object
edchSchedulerAlgorithm
Enum {roundRobinSlidingWindow, rateScheduling}
Customer
Granularity
3
rateScheduling

BTSEquipment
Cell

In UA6/iCEM, with Rate Scheduling, all E-DCH active users (having data to transmit)
are transmitting (having grants) simultaneously. They share resources in a fair way
and the general principle being that:

hardware resources are shared equally between all active cells (containing at
least one active user)

hardware resources assigned to an active cell are shared equally between all
active users of this cell

the cell load (apart from R99 part) is shared equally between all active users
of this cell

Grants are modified when:

the number of active user changes (one becomes active or one becomes
inactive)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 53/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

R99 uplink radio load has changed significantly

Periodically, each T_Threshold_TTI (100ms) for UEs that are granted above
the fairness index. In UA5.1 this timer is accessible via OMC and can be
modified by the customer. The new parameter name in UA5.1 is
edchRateSchedulerOptimisationTimer.

Periodically each 500ms

For more details, see [R04].


X

Parameter
Range & Unit
User
Class
Value

edchRateSchedulerOptimisationTimer
[10..50] step 4. Unit=TTI
Customer
3
10

Object

BTSEquipment

Granularity

BTS

edchRateSchedulerOptimisationTimer is period over which UE can be granted


more as its nominal quantum.
DEFENSE MECHANISMS AGAINST E-AGCH BAD DETECTION
It may happen that a UE performing an E-DCH call does not detect, or wrongly
decodes an E-AGCH command intended to this UE. The consequence of this is that
the considered UE may not transmit data although it has been granted, or use an ETFCI that is not appropriate (too high or too low) regarding the grant it has been
allocated.
If the UE uses an E-TFCI too high regarding the grant it has been allocated, NodeB
cannot decode data sent by UE on E-DCH, since for this UE hardware resources have
not been reserved at NodeB for such large E-TFC. For this specific case, the wrongly
detected E-AGCH should be resent as soon as possible in order to avoid useless EDCH transmissions (since not decoded by NodeB) that cause UL interference for
other users.
If the UE uses an E-TFCI too low regarding the grant it has been allocated, NodeB
normally decodes data sent by UE on E-DCH, but E-DCH user throughput is degraded
compared to what it could have been if UE had correctly decoded the E-AGCH
command.
In UA5/iCEM, the following defense mechanisms against E-AGCH bad detection have
been implemented in the MAC-e scheduler.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 54/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


ImpleE-AGCH bad detection case
Action taken by MAC-e scheduler
mentation (detection is done on reception of
E-DPCCH at NodeB)
Release
UA5.0

UA5.0

UA5.1

UE uses an E-TFCI higher than


the maximum E-TFCI allowed
according to current grant
computed by MAC-e scheduler
for this UE.

For a given UE, each time any of beside cases is


detected (on reception of E-DPCCH at NodeB), an EAGCH error counter is incremented for this UE. The EAGCH error counter is reset if UE happens to use an
E-TFCI different than the one used when E-AGCH
error was detected. If the counter reaches a certain
UE sends a MAC-e PDU that only limit (7), an E-AGCH Alarm is raised for this UE.
includes
SI
(no
payload),
MAC-e scheduler then resends E-AGCH commands
although MAC-e scheduler has
(the same command that has been sent previously but
granted this UE with a grant
not detected or wrongly decoded) to UEs for which an
different than Zero Grant.
E-AGCH alarm has been raised.
Happy Bit received from UE is set
to unhappy, while UE uses an ETFCI lower than [the maximum ETFCI allowed according to current
grant computed by MAC-e
scheduler for this UE] -3.

Remark: For the case when UE uses an E-TFCI higher


than the maximum E-TFCI allowed (and only for this
case), after the E-AGCH error counter has reached the
limit (i.e. after E-AGCH Alarm has been raised), the EAGCH channel is preempted (with regards to already
planned E-AGCH commands) in order to resend the EAGCH command as soon as possible.
U

6.6 ACTIVITY MONITORING


With the iCEM, the UE is considered as inactive when the NodeB does not receive
any Scheduling Information (SI) during a period set via siActivityTimer parameter.
This parameter is accessible in OMC from UA5.1 on and can be modified by the
customer
Scheduling Information transmitted by each UE. The scheduling information are
transmitted periodically on the E-DPDCH according to periodicityOfSchedInfoGrant
and periodicityOfSchedInfoNoGrant (depending on whether the UE is granted or
not) when the UE is using 10ms TTI (always the case when E-DCH is handled on
iCEM for the E-DCH serving cell). When the UE is using 2ms TTI (may only happen
when E-DCH is handled on xCEM for the E-DCH serving cell),
periodicityOfSchedInfoGrantEdchTti2ms
and
periodicityOfSchedInfoNoGrantEdchTti2ms are applied (please refer to section
7.4. for further details about the previous parameters).
Scheduling Information (SI) contains the following information:
o

Total E-DCH buffer status (TEBS, 5 bits)

Highest priority logical channel ID (HLID, 4 bits)

Highest priority logical channel buffer status (HLBS, 4 bits)

UE transmission power headroom (UPH, 5 bits):


Power ratio of maximum allowed UE transmit power to DPCCH pilot
bit transmit power.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 55/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The resulting maximum grant allocation is the minimum of all grant allocations
provided by each of the step described above and is sent on one E-AGCH (RNTI and
Grant info).
Parameter
Range & Unit
User
Class
Value

siActivityTimer (iCEM-specific)
Integer [8 48] (step: 4). TTI.
Customer
3
12

Object

BTSEquipment

Granularity

BTSEquipment

Rule: siActivityTimer
The siActivityTimer should be set according to the following rule:
siActivityTimer*TTI > max(periodicityOfSchedInfoNoGrant, periodicityOfSchedInfoGrant).

6.7 PRIORITY INFO IN MAC-E SCHEDULER


It is possible to configure and signal 16 SPI (Scheduling Priority Indicator) values to
NodeB. However, only 4 priority levels are supported. An internal mapping shall be
performed e.g.
Highest Priority

Lowest Priority

Scheduling Priority

Internal priority level

15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

Prio_Level_Gold
Prio_Level_Silver
Prio_Level_Bronze

Prio_Level_Other

Table 11: Scheduling Priority iCEM


Since only 4 behaviors are possible but 16 SPI values available, the operator shall
ensure that only the highest SPI values are used.
Similarly to MAC-hs scheduler, the MAC-e scheduler support relative weighting
according to SPI in order to obtain relative throughput when UEs are under same
radio and traffic conditions.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 56/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Internal metrics for fair processing (fair index and average consumption per UE of
shared resources) take SPI into account to allow more service to high priority UEs
than low ones of the same serving cell at iso radio and traffic conditions.
A weighting vector (1 by 4) edchSpiRelativeWeight will be provisioned at OMC-B to
configure the relative weight of the SPIs in similar way to HSDPA. This parameter is
common for both iCEM and xCEM.
Parameter
Range & Unit
User
Class
Value

edchSpiRelativeWeight

Object

EdchConf

[1..16][0..100]

Customer
Granularity
BTSCell
0
100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100

OAM must check after reception of this table the following items:
-

Values of weights from SPI = 11 to SPI = 0 are set to 100

Values from SPI = 15 to SPI = 12 are set with decreasing values:


1 E-DCHSpiRelativeWeight [SPI = 12]
E-DCHSpiRelativeWeight [SPI = 13]
E-DCHSpiRelativeWeight [SPI = 14]
E-DCHSpiRelativeWeight [SPI = 15] 100

[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS. Please refer to
section 11 for details.

edchSpi: For each E-DCH call, the Core Network provides in RANAP RAB
Assignment message the following QoS attributes: Traffic Class, ARP (Allocation
Retention Priority), THP (Traffic Handling Priority). edchSpi parameter, which is
located under RadioAccessService TrafficClassBasedQos ArpBasedQos
ThpBasedQos, is used to assign to each {Traffic Class, ARP, THP} combination an
E-DCH SPI (Scheduling Priority Indicator). edchSpi parameter is used in the same
way for iCEM, xCEM and UCU-III cases.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 57/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Table 12: E-DCH SPI


Parameter
Range & Unit
User
Class

edchSpi
[0 15]
Customer
3

Value

Depends on customer strategy

Object

ThpBasedQos

Granularity

RNC,
TrafficClassBasedQos,
ArpBasedQos,
ThpBasedQos

6.8 IUB CONGESTION HANDLING FOR E-DCH


In UA5/iCEM, regarding E-DCH traffic, there is no specific handling of uplink
congestion on the Iub. Indeed, in UA5, grant reduction by iCEM MAC-e scheduler on
reception of UL Iub congestion indication from RNC is not supported.
In UA5/iCEM, tests showed that at least 2 E1 per NodeB are required in order to avoid
E-DCH Data Frame loss on Iub when several E-DCH users are transferring
simultaneously. In other words, in UA5/iCEM, at least 2 E1 per NodeB are required in
order to reach the maximum E-DCH aggregate throughput per E-BBU (i.e. 2.1 Mbps
at MAC-e level).
In UA6 the feature Iub Bandwidth Limitation for E-DCH (iCEM) (33332.2) is
introduced in order to take into account the UL Iub congestion in the edch scheduler
and limit the UL radio and HW resources to the available Iub BW for Edch (Iub BW not
used by R99 traffic).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 58/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


For a correct functioning of this feature it is necessary the interaction with feature
HSPA congestion detection & notification (33367).

The iub BW limitation for Edch is performed in three main steps

UL iub congestion detection by the RNC

Iub congestion indication to NB

Iub BW congestion management by Edch scheduler

RNC

HSUPA Throughput
Node B
TNL congestion notification to NodeB

Iub
HSUPA BW limitation by Node B

HSUPA congestion detection by RNC

Figure 9: Iub BW limitation iCEM

This
feature
can
be
activated/deactivated
at
isEdchBandwidthlimitationAllowed under BTSEquipment.
Parameter
Range & Unit
User
Class
Value

NodeB

isedchBandwidthlimitationAllowed
False,True
Customer
3
True

level

via

the

flag

Object

BTSEquipment

Granularity

BTSEquipment

6.8.1 UL IUB CONGESTION DETECTION


The UL Iub congestion is detected by the RNC via UL frame loss detection.

The NB includes a FSN in every E-DCH Data Frame. If FSNn > FSNn-1+1, P frames
are missing and might be lost, but it could also be due to IP de-sequencing issue.
B

If the parameter DeSequencingWaitTimer is not 0, the RNC starts a timer equal to


DeSequencingWaitTimer, and wait up to its expiry before the MAC-d flow is marked
as congested.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 59/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


If all the P missing frames are received during that interval, the MAC-d flow is NOT
marked as congested, the timer is stopped. In that case, the last received frame is the
new FSNn, and the nominal algorithm is resumed.
B

Note that only one timer is running; when this timer runs, no frame loss can be
detected for the succeeding frames, this is simpler and it is not felt as a critical issue,
the main point being to avoid wrong frame loss detection.

If at least one frame is missing at the expiry of the timer, then the MAC-d flow is
marked as congested frame loss, the FSNn is assigned with the last received frame,
and the nominal algorithm is resumed.
B

Figure 10: Uplink Iub Congestion iCEM

Parameter
Range & Unit
User
Class
Value

nFramesBeforeEdchCongestion
0..255
Customer
NA
1

Object

RNC INode

Granularity

Inode

Parameter
Range & Unit
User
Class
Value

deSequencingWaitTimer
0..100
Customer
NA
0

Object

RNC INode

Granularity

Inode

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 60/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


With 10ms TTI, when N succeeding E-DCH UL Data Frames have their successive
FSN Nn = Nn-1+1, the leg is marked as non-congested. N is controlled by the
parameter nFramesBeforeEdchDeCongestion.
B

With 2ms TTI in non-bundling mode, the


nFramesBeforeEdchDeCongestion multiplied by 5.

algorithm

uses

parameter

Figure 11: Uplink Iub DeCongestion iCEM

In case of macro diversity, each RL monitors the congestion independently of the


other RL of that UE, and when a RL enters or leaves congestion state, a TNL
congestion is sent only on the congested RL.
Parameter
Range & Unit
User
Class
Value

nFramesBeforeEdchDeCongestion
0..255
Customer
NA
50

Object

RNC INode

Granularity

Inode

6.8.2 UL IUB CONGESTION REPORTING BY RNC


The RNC regularly sends a TNL Congestion Indication message to NB for the Mac-d
flow marked as congested until decongestion is detected.

The repetition timer is configurable through the parameter congestionControlPeriod.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 61/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range & Unit
User
Class
Value

congestionControlPeriod
0..2550 in step of 10ms
Customer
NA
40

Object

RNC INode

Granularity

Inode

When a congested Mac-d flow becomes non-congested, the RNC sends one TNL
Congestion indication message with cause No TNL Congestion.

Figure 12: TNL Congestion Indication iCEM

6.8.3 UL IUB CONGESTION MANAGEMENT IN EDCH


SCHEDULER
Every edch congestion control period the NB updates a Global Reduction Factor:

If TNL Congestion status is received during ECC period, the GRF is


decreased by a corresponding reduction step

If no TNL Congestion Indications are received or only No Congestion status


during the ECC period, the GRF is increased by an increase step.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 62/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Figure 13: GRF updating GRF iCEM

Parameter
Range & Unit
User
Class
Value

edchBLSupervisionTimer
10..1000 in step of 10ms
Customer
3
80

Object

BTSEquipment

Granularity

BTS

Parameter
Range & Unit
User
Class
Value

edchBLStepReductionFrameLoss
0..100 in %
Customer
3
1

Object

BTSEquipment

Granularity

BTS

Parameter
Range & Unit
User
Class
Value

edchBLStepIncrease
0..100 in %
Customer
3
1

Object

BTSEquipment

Granularity

BTS

The iCEM scheduler reduces the UL codec limitation by GRF where the codec
limitation is calculated as follow

CDC_size_Max = min(2.1Mbps,edchBLIubBandwidth)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 63/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

7 MAC-E SCHEDULER XCEM


The task of the scheduler is to fairly distribute the available E-DCH load among the EDCH users while keeping the uplink load within a limit UL load configured by RNC.
The resources are allocated essentially via relative grants (RGs) and also via absolute
grants (AG) for activation and deactivation.
The MAC-e scheduler runs every 40ms (corresponding to a HARQ round trip time for
10ms TTI).
The MAC-e scheduler considers following inputs:
-

Cell resources: CE processing, maximum RoT, Target Non-Serving E-DCH


to Total E-DCH Power Ratio

Measurements: RTWP, E-DCH load

UE status: UE category, SI

From these inputs the scheduler will derive the scheduling grants. Overload
management as well as AG and RG sending is described below.

7.1 MAC-E SCHEDULER INPUTS


NodeB resources
- E-DCH processing resources are pooled across cells handled by one
xCEM. This is configured via edchMaxThroughputXcem which indicates
the maximum throughput in kbps for EDCH traffic (MAC-e layer), that can be
used.
Remark: This parameter limits the throughput @ MAC-e level. A correct
extrapolation as to be done in order to achieve the desired throughput @
Application level, otherwise a throughput below license agreement can
occur. Also, due to scheduler rules and some particular parameter settings,
a lower SG (lower than the expected one) can be given to the UESo it is
important to chose carefully the correct value for this parameter (e.g. for a
Cat5 UE, if the edchMaxThroughputXcem = 1920kbps, the Application
throughput will be equal to 1300kbps, but for a edchMaxThroughputXcem
= 2400kbps the Application throughput reaches the expected value of
1700kbps).
U

[UCU-III]
For OneBTS there is no man-made restriction of the E-DCH processing
resources possible.
- The Maximum Target Received Total Wide Band Power is sent over
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message. It
is derived from OMC-R parameters FDDCelltotalRotMax and
FDDCellrtwpReference. RTWPref will be adjusted according to selflearned RTWP value in the NodeB, as well as the resulting RoT.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 64/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


- The Target Non-serving E-DCH to Total E-DCH Power Ratio is sent over
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message. It
is derived from OMC-R parameters FDDCell targetNonServingToTotalEdchPoweRatio (see Vol.6 for further details regarding this parameter).
The target UL load Ltarget is derived and is defined as the most restricting criterion
among above limitations.
B

The following parameters (except the first one which is xCEM only) are common to
iCEM, xCEM and UCU-III (please refer to section 4.1.1 for further details).
X

Parameter
Range & Unit
User
Class
Value

edchMaxThroughputXcem
[480..7680] step:480 kbps
Customer
3
7680

Object

Parameter
Range & Unit
User
Class
Value

isRtwpReferenceSelfLearning

Object

BTSEquipment

Granularity

Cell

Parameter
Range & Unit
User
Class
Value

Parameter
Range & Unit
User
Class
Value

BTSEquipment

Granularity

HsXpaResource
TU

UT

False, True

Customer
3
True

Object

BTSCell

Customer
3
-106.1

Granularity

Cell

totalRotMax
[0..20] step:0.1 (db)
Customer
2
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8

Object

FDDCell

Granularity

Cell

rtwpReference
[-115.0..-50.0] step:0.1 dBm

Measurements
- RTWP is reported every 100ms to the MAC-e scheduler.
[UCU-III]
Every 2ms for OneBTS.
- [xCEM][UCU-III], estimates every 10ms the average total UL load LE-DCH
generated by E-DCH serving users, non-serving users and peer-serving
users.
B

- The total UL load (E-DCH or not) Ltotal is also generated according to RTWP
measurements allowing to derive the Lnon E-DCH = Ltotal LE-DCH.
B

[UCU-III]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 65/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Ltotal will be generated according to Ec/Io and TPR measurements.
B

- The available E-DCH load is then derived and corresponds to Lavailable, E-DCH =
Ltarget - Lnon E-DCH. If Lavailable, E-DCH <= 0, then the cell is overloaded.
B

UE specific information
- Happy bit status
- Scheduling information
- Reference scheduling grant SGref, i, taken from previous scheduling interval
B

- Average transport block size i.e. PHY throughput

7.2 SCHEDULING GRANT


The resources allocation is done in two steps. First, the MAC-e scheduler computes
the requested transport block for all serving UEs depending on the happy bit status
and whether SI was received, and derives a hypothetical load if all requests were
satisfied. Once the hypothetical load is computed, the MAC-e scheduler shall check if
the hypothetical load is kept within the available load. If Lhypothetical <= Lavailable, AG
and/or RG are sent to UEs. Otherwise, the MAC-e scheduler shall reduce the target
grants.
B

Calculate request and target grant


If a UE reports happy bit = 1, the same TB as derived in previous scheduling interval
shall be kept. Otherwise, the requested TB, TBrequested, shall be set next TB in 10ms
TTI E-DCH Transport Block Size Table 1 (see 5.3 for more information on {E-TFCI;
TBS} table) supporting 1 more MAC-d PDU.
B

[xCEM]
If an SI is received while UE is not granted, the MAC-e scheduler assumes for initial
grant computation that TBrequested = TB(EdchconfedchInitialTBIndexXxx).
edchInitialTBIndex10msTTI and edchInitialTBIndex2msTTI parameters are used to
set the E-TFCI to be used for initial grant sent to UE via AG command.
B

[iCEM]
Regarding iBTS, edchInitialTBIndexXxx parameters are taken into account by the
system only if the board handling the E-DCH call is an xCEM. As explained in 5.4, for
iBTS, RNC detects the type of board handling E-DCH traffic for the considered cell via
the E-DPDCH SF capability of the considered cell.
X

If the board handling the E-DCH call is an iCEM, edchInitialTBIndexXxx parameters


are ignored by the system. For iCEM, differently from xCEM, this initial grant is sent to
UE via RRC signaling and not via AG command. A hard-coded value is used for the
initial grant (SG=14 which corresponds to E-TFCI 7 if UE is alone on the E-BBU,
SG=38 which corresponds to no grant wait for AG command if UE is not alone on
the E-BBU).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 66/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


[UCU-III]
For the OneBTS, the equivalent to edchInitialTBInde10msTTI is an internal NodeB
parameter.

The requested TB is converted to a target grant SGtarget, i for each UE i and the total
UL load Lhypothetical is computed. If Lhypothetical <= Lavailable, all the requests can be fulfilled
and the MAC-e scheduler proceeds with AG and/or RG sending.
B

Otherwise, the MAC-e scheduler reduces the requested grants.


Parameter
Range & Unit
User
Class
Value

Object

EdchConf

Customer
0
52

Granularity

BTSCell

edchInitialTBIndex2msTTI

Object

EdchConf

Granularity

BTSCell

edchInitialTBIndex10msTTI
[0..127] step 1

Parameter
Range & Unit
User
Class
Value

[0..127] step 1

Customer
0
8
Hypothetical overload

Lhypothetical > Lavailable: this condition corresponds to hypothetical overload situation


posterior to update of requested TB of all UEs.
B

Each UE i is ranked according to the UE throughput and a scheduling weight SWi


depending on the UEs SPI.
B

The MAC-e scheduler first check if the interference created by non-serving UEs
compared to the total E-DCH interference is smaller than or equal to Target Nonserving E-DCH to Total E-DCH Power Ratio set by RNC. If this is not the case, the
MAC-e scheduler shall first reduce non-serving UEs by sending DOWN command.
The MAC-e scheduler shall also check whether the interference created by the peerserving RL is smaller than or equal to EdchconfedchSofterHoLimit (see Vol.6 for
details regarding this parameter) threshold. If this is not the case, the MAC-e
scheduler shall further reduce the peer-serving RLs by sending DOWN command.

E-DCH Minimum Set E-TFCI


As it has been explained in 5.4, E-DCH Minimum Set E-TFCI is a unique E-TFCI
value, configured at UE (and NodeB) via RRC (and NBAP) at E-DCH call
establishment. 3GPP TS 25.321 [R05] specifies that, within the limit allowed by
Serving_Grant, when UE is power-limited, UE is allowed to override the E-TFCI
limitation based on available UE Tx power criterion, up to E-DCH Minimum Set ETFCI value. In addition, according to [R05], the applicability of E-DCH Minimum Set ETFCI is restricted to the case when no UL DCH transport channel is configured in
parallel of the E-DCH transport channel, and to the case when UL DCH transport
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 67/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


channel(s) is (are) configured in parallel of the E-DCH transport channel but the size
of the TF currently selected on this (these) UL DCH channel(s) is 0 bit.
In UA5, E-DCH Minimum Set E-TFCI IE is sent to UE (and NodeB) only if the
board handling the E-DCH calls is an xCEM. As explained in 5.4, RNC detects the
type of board handling E-DCH traffic for the considered cell via the E-DPDCH SF
capability of the considered cell.
X

E-DCH Minimum Set E-TFCI value is set via edchMinSetEtfci parameter under
EdpchParameters.
Parameter
Range & Unit
User
Class
Value

edchMinSetEtfci

Object

EdpchParameters

[0..127] step:1

Customer
Granularity
0
EdpchParameters instances related to 10ms TTI: 7
EdpchParameters instances related to 2ms TTI: 3

EdpchInfoClass

7.3 OVERLOAD ALGORITHM


Lavailable <= 0: this condition corresponds to actual overload situation. In this case, the
B

MAC-e scheduler de-grants all the UEs and sends RG = DOWN command.
Note that the parameters rtwpMargin and rtwpTimeDetection are not used for xCEM
overload algorithm.
The xCEM overload algorithm is trigged when the average non E-DCH load, estimated
based on the last received RTWP measurement, is higher than the E-DCH Max load
corresponding to RoT_max setting.

7.4 ACTIVITY MONITORING


When a UE has not sent data for a certain amount of time, the MAC-e scheduler
sends an AG = ZERO to deactivate the UE in order to save resources. A UE is
considered as inactive either because no data has been received on E-DPDCH or
only SI has been transmitted during a given period.
A UE that is in inactive state needs to send an SI to obtain a scheduling grant. The
MAC-e scheduler sends an AG in this case.
The SI reporting is activated for 10ms and 2ms TTi through the following flags
Parameter
Range & Unit
User
Class
Value

isEdchSchedulingInfoReportingAllowed
False,True
Customer
3
True

Object

EdchParameters

Granularity

UlRbSetConf

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 68/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range &
Unit
User
Class
Value

isEdchSchedulingInfoReportingEdchTti2msAllowed
False,True

Object

EdchParameters

Customer
3
True

Granularity

UlRbSetConf

The two following parameters are common to iCEM and xCEM. However, the
siActivityTimer is specific to iCEM. The xCEM has an equivalent parameter called
edchInactivityTimerXcem.
Parameter
Range & Unit
User
Class
Value

edchInactivityTimerXcem
[0..20000ms] step 40
Customer
3
1440

Object

EdchConf

Granularity

BTScell

Object

EdchCellClass

Granularity

EdchCellClass

iBTS (setting for periodicityOfSchedInfoGrant):


Parameter
Range & Unit
User
Class
Value

periodicityOfSchedInfoGrant
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50

Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoGrant.
U

Parameter
Range & Unit
User
Class
Value

periodicityOfSchedInfoGrantEdchTti2ms
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50

Object

EdchCellClass

Granularity

EdchCellClass

Object

EdchCellClass

Granularity

EdchCellClass

iBTS (setting for periodicityOfSchedInfoNoGrant):


Parameter
Range & Unit
User
Class
Value

periodicityOfSchedInfoNoGrant
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50

Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoNoGrant.
U

Parameter
Range & Unit
User
Class
Value

periodicityOfSchedInfoNoGrantEdchTti2ms
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50

Object

EdchCellClass

Granularity

EdchCellClass

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 69/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


7.5 GENERATION OF AG & RG
Generation of absolute scheduling grants
-

AG = ZERO is sent when inactivity is detected.

After reception of SI trigger, AG is sent with the next valid value with AG >=

SGtarget.
B

Generation of relative scheduling grants


-

If SGtarget,i > SGref,i, set RGi = UP".

If SGtarget,i = SGref,i, set RGi = "HOLD".

If SGtarget,i < SGref,i, set RGi = "DOWN".

[iCEM] [xCEM] (ergch2IndexStepThreshold & ergch3IndexStepThreshold


settings)
Parameter
Range & Unit
User
Class
Value

ergch2IndexStepThreshold
[0..37] step 1
Customer
0
20

Object

EdpchParameters

Granularity

RNC

Parameter
Range & Unit
User
Class
Value

ergch3IndexStepThreshold
[0..37] step 1
Customer
0
16

Object

EdpchParameters

Granularity

RNC

ergch2IndexStepThreshold and ergch3IndexStepThreshold are configurable per


EdpchParameters class, so we can have specific values per UE category and TTi
type.
Rule: ergch2IndexStepThreshold and ergch3IndexStepThreshold
Following rule must be fulfilled:
ergch3IndexStepThreshold ergch2IndexStepThreshold

[UCU-III]
The ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set
different for OneBTS for UA06. They have to be aligned with the used reference ETFCI and reference power offset settings. Our recommendation is:
ergch2IndexStepThreshold=18, ergch3IndexStepThreshold=15

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 70/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


7.6 PRIORITY INFO IN MAC-E SCHEDULER
It is possible to configure and signal 16 SPI values to NodeB. However, only 4 priority
levels are supported. An internal mapping shall be performed e.g.
Highest Priority

Lowest Priority

Scheduling Priority

Internal priority level

15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

Prio_Level_Gold
Prio_Level_Silver
Prio_Level_Bronze

Prio_Level_Other

Table 13: Scheduling Priority xCEM


Since only 4 behaviors are possible but 16 SPI values available, the operator shall
ensure that only the highest SPI values are used.
Similarly to MAC-hs scheduler, the MAC-e scheduler support relative weighting
according to SPI in order to obtain relative throughput when UEs are under same
radio and traffic conditions.
The principle of SPI management on xCEM is the following:
The MAC-e scheduler de-grants the UE with lowest priority and updates the
hypothetical load and repeats the procedure as long as Lhypothetical > Lavailable. Each UE
will be de-granted by 1 step at the maximum.
B

When average throughput for MAC-d flow#i is lower than serviceMinRate


(configured per Scheduling Priory Level) the MAC-e scheduler shall increase the
rank until the average throughput is equal to the serviceMinRate. The resources
are taken from the MAC-d flows that have an average throughput higher than their
serviceMinRate and especially those with an average throughput higher than
their serviceMaxRate. In overload situation, UEs in bad RF conditions will remain
with throughput lower than serviceMinRate. However, this behavior can be
overruled by adjusting the serviceBFactor and serviceKFactor to allow UE with
bad RF conditions to achieve serviceMinRate.

When average throughput for MAC-d flow#i is higher than serviceMaxRate


(configured per Scheduling Priory Level) the MAC-e scheduler shall decrease the
rank until resources are given to those with average throughput lower than
serviceMinRate.

When the average throughput is between serviceMinRate and serviceMaxRate, a


given {UE, MAC-d flow} will be ranked higher if RF conditions are better. {UE, MAC-d
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 71/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


flow} with same RF conditions, but different SPI, will be ranked considering
edchSpiRelativeWeight.
All these parameter values are dependent of the operators strategy.
Parameter
Range & Unit
User
Class
Value

Object

EdchServiceParameterSet

Customer
3
40 (default value)

Granularity

BTSCell

serviceMaxRate

Object

EdchServiceParameterSet

Customer
3
300 (default value)

Granularity

BTSCell

serviceBfactor

Object

EdchServiceParameterSet

Customer
3
7 (default value)

Granularity

BTSCell

serviceKfactor

Object

EdchServiceParameterSet

serviceMinRate
[0..10000]

Parameter
Range & Unit
User
Class
Value

[0..10000]

Parameter
Range & Unit
User
Class
Value

[1..30]

Parameter
Range & Unit
User
Class
Value
Remark:
U

[1..30]

Customer
Granularity
BTSCell
3
7 (default value)
This mode can be disabled by setting the serviceBfactor equal to 1 for all the SPI.

A weighting vector (1 by 4) edchSpiRelativeWeight will be provisioned at OMC-B to


configure the relative weight of the SPIs in similar way to HSDPA. This parameter is
common for both iCEM and xCEM.
Parameter
Range & Unit
User
Class
Value

edchSpiRelativeWeight

Object

EdchConf

[1..16][0..100]

Customer
Granularity
BTSCell
0
100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100
(default value)
Remark: This mode can be disabled by setting all the weight values equal to 100.
U

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 72/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


OAM must check after reception of this table the following items:
-

Values of weights from SPI = 11 to SPI = 0 are set to 100

Values from SPI = 15 to SPI = 12 are set with decreasing values:


1 E-DCHSpiRelativeWeight [SPI = 12]
E-DCHSpiRelativeWeight [SPI = 13]
E-DCHSpiRelativeWeight [SPI = 14]
E-DCHSpiRelativeWeight [SPI = 15] 100

Regarding edchSpi parameter, please see section 6.7 for a detailed description.
X

[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS. Please refer to
section 11 for details.

7.7 MAC-E NON SCHEDULED MODE


[iCEM] The Mac-e non scheduled mode is not supported by the iCEM.
[xCEM] The Mac-e non scheduled mode is supported by the xCEM and its used to
carry SRB on Edch in order to maximize the Edch performances when using
2SF2+2SF4 in case of UE CAT6.
[UCU-III] The Mac-e non scheduled mode is supported by the UCU-III and it is used to
carry SRB on EDCH. Note that SRB on Edch is supported for all UE categories.
When the non scheduled mode is selected by the RNC to carry the SRB, it sends the
maximum MAC-e PDU size to be used by the UE for non scheduled data to both UE
(through RRC message) and BTS (through NBAP message). The UE is then allowed
to send data (SRB signaling data) in the limit of resources allocated by the RNC
without of asking of a grant before.
The maximum Mac-e PDU size for non scheduled data is configured so that the UE
can send 1 PDU (DCCH) per TTI.
Parameter
Range &
Unit
User
Class
Value

maxMacePduContentsSizeForNonScheduledMode

Object

EdchParameters

Granularity

UlRbSetConf

[1..1096]

Customer
3
162

The non scheduled mode is only used when the SRB over edch is activated.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 73/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter

isSrbOnEdchAllowedWhenTrbOnEdch

Range & Unit


User
Class
Value

True,False

Customer
3
True

Object

RadioAccessService

Granularity

RNC

7.8 IUB CONGESTION HANDLING FOR E-DCH


In UA6 the feature Iub Bandwidth Limitation for E-DCH (xCEM) (33332.1) is
introduced in order to take into account the UL Iub congestion in the edch scheduler
and limit the UL radio and HW resources to the available Iub BW for Edch (Iub BW not
used by R99 traffic).

For a correct functioning of this feature it is necessary the interaction with feature
HSPA congestion detection & notification (33367).

The iub BW limitation for Edch is performed in three main steps

UL iub congestion detection by the RNC

Iub congestion indication to NB

Iub BW congestion management by Edch scheduler

The Iub congestion detection and reporting are common to both xCEM and iCEM.

HSUPA Throughput

RNC

Node B
TNL congestion notification to NodeB

Iub
HSUPA BW limitation by Node B

HSUPA congestion detection by RNC

Figure 14: Uplink Iub Congestion xCEM

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 74/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


7.8.1 UL IUB CONGESTION DETECTION
The Ul Iub congestion detection is the same for iCEM and xCEM. You can refer to
6.8.1 for the feature description.

7.8.2 UL IUB CONGESTION REPORTING


The Ul Iub congestion detection is the same for iCEM and xCEM. You can refer to
6.8.2 for the feature description.

7.8.3 UL IUB CONGESTION MANAGEMENT BY EDCH SCHEDULER


Every edch congestion control period the NB updates a Global Reduction Factor:

If TNL Congestion status is received during ECC period, the GRF is


decreased by a corresponding reduction step

If no TNL Congestion Indication is received or only No Congestion status


during the ECC period, the GRF is increased by an increase step.

Figure 15: TNL Congestion Indication xCEM

The xCEM scheduler reduces the UL load limit by GRF.

The same parameters are applicable for both iCEM and xCEM boards (refer to 6.8.3).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 75/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


7.8.4 iBTS LOCAL CONGESTION CONTROL
In UA6 theres another feature (75786) that allows the iBTS to adjust EDCH
throughput in Uplink according to AAL2 condition. More specifically:

EDCH throughput will be progressively decreased on xCEM when the IBTS


detects a loss of AAL2 cells in uplink

EDCH throughput will be progressively increased on xCEM when the iBTS did not
detect any AAL2 cells lost in uplink for a minimum period of time.

Figure 16: Local congestion control mechanism


The feature reacts the following way:
1. Hardware/microcode detects the AAL2 UL overflow
2. Platform software performs fault confirmation (leaky bucket mechanism) and
report the fault to OAM CCM
3. OAM CCM informs all xCEM of AAL2 congestion when activation parameter
edchCMActivation is set to TRUE
4. When xCEM manages EDCH, xCEM reduces or increases EDCH throughput
according to congestion indication from OAM CCM
5. OAM CCM reports an alarm to OMC-B only if the AAL2 overflow condition is still
present despite the xCEM congestion control mechanism for EDCH.
The local congestion feature (75786) uses the same mechanism to control the
congestion than feature 33332 Iub congestion control for e-DCH. The interaction
between both features is that the BTS considers congestion of E-DCH when either it
has been detected locally (75586) or remotely (33367). To do so, the congestion
control mechanism uses the minimum value between:

Load limit (overload)

GRF (Global Reduction Factor)

As a result, features 33332 and 75786 can be managed at the same time.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 76/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


This feature can be activated/deactivated using the parameter edchCMActivation
that was already defined but is currently unused. The name of this parameter is
provisory and in UA7 it will change for a different definitive name.
object
parameter name
class
Definition

Range
unit
Initial values

BtsEquipment
edchCMActivation
3
This parameter is used to activate the feature Local EDCH
Congestion Control in the BTS
When set to TRUE, the BTS control the EDCH throughput based on
ATM cell that are locally dropped in the BTS
When set to FALSE, this feature is deactivated
Boolean (True, false)
None
False

Remark: The feature is managed the same way in all cases when user plan for EDCH
is managed on ATM external AAL2 VCC, i.e:
U

ATM over PCM (IMA or no IMA)


ATM over PCM with multiple IMA Group
Hybrid IUB for the ATM leg

[iCEM]
This feature is not applicable.
[UCU-III]
This feature is not applicable, but a similar mechanism can be achieved based on the
Iub Overload Control. The only difference is the generation of the Iub overload
indicator which is done by means of ATM queue fill levels.
The Node B periodically informs the MAC-e scheduler about the Iub status. A
congestion event is reported if the low priority UL queue size (at AAL2 PVC level, ATM
Adaptation Layer 2 Permanent Virtual Circuit) crosses a certain HIGH threshold
(tunable @ NodeB) and the PVC is not in congested state. A congestion release event
is reported if the queue size crosses a LOW threshold (tunable @ NodeB) and the
PVC is not in uncongested state.
.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 77/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

8 IU USER TRAFFIC CONFORMANCE


For HS-DSCH (HSDPA) and E-DCH traffic (HSUPA), the RNC implements a traffic
conformance mechanism on the Iu interface to ensure that the user traffic never
exceeds the maximum bit rate negotiated at RAB establishment. This is only
applicable in downlink/uplink.
This mechanism is optional and can be activated at RNC level (applicable to HSxPA
Service).
Please refer to Volume 3 for further details about the functioning of this feature.
Restriction: Mechanisme not optimised for the UpLink
Since the algorithm is implemented only @ RNC level, the scheduler behaviour is strongly affected
and the taxes of retransmission are high due to the discarded packets coming at the RNC. The
expected limitation of the UpLink UE throughput may not be correctly achieved with the activation of
this feature (for the E-DCH part).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 78/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

9 POWER CONTROL FOR E-DCH


9.1 UL OUTER-LOOP POWER CONTROL FOR E-DCH
This section deals with E-DCH-specific parts of uplink Outer-Loop Power Control
mechanism. For a detailed description of uplink power control mechanisms in general
(i.e. UL Inner-Loop Power Control and UL OLPC for R99 UL transport channels type),
please refer to UA6 UPUG [R01], Vol.9, section 2.
X

9.1.1 E-DCH UL OLPC IN UA5


[iCEM] [xCEM]
Regarding the iBTS, this section gives the historical background of the uplink OuterLoop Power Control (UL OLPC) algorithm for E-DCH.

In UA5.0, the UL OLPC algorithm was not handling E-DCH specifically. Indeed, the
link quality of the E-DCH transport channel was not monitored and thus not taken into
account in the UL OLPC. In UA5.0, for E-DCH calls, it was possible though to benefit
from UL OLPC, by performing UL OLPC basing on the link quality of the non-E-DCH
transport channel(s) established. However due to some auto-interference and RSSI
divergence problems, in UA5.0 it was recommended to disable the UL OLPC for EDCH calls, by setting minSirTarget and maxSirTarget to the same value for the UL
services that include an E-DCH RB.

In UA5.1, an UL OLPC algorithm that handles E-DCH specifically was introduced in


order to maintain a constant link quality on the E-DCH transport channel, whatever the
fluctuations of radio conditions.
For DCH channels, the UL OLPC algorithm in the RNC adjusts the UL DPCCH SIR
Target (SIR definition is available in [R11]) to be used by the NodeBs for Inner-Loop
Power Control so that the BLER of each DCH channel is maintained close to its
specific BLER Target. The BLER of each DCH channel is derived by the RNC basing
on the CRC Indicator (CRCI) of the selected UL DCH data frame.
X

For E-DCH, the principle of UL OLPC is similar, but the quality criterion for adjusting
the UL SIR Target is different. For E-DCH, the quality criterion for adjusting the UL
SIR Target is the measured number of HARQ retransmissions on the E-DCH channel.
The RNC adjusts the UL SIR Target so that the average number of HARQ
retransmissions converges toward a target number of HARQ retransmissions (refered
as NHARQ Target below in this document). The RNC knows the actual number of
HARQ retransmissions that was necessary for decoding a given MAC-e PDU at
NodeB, thanks to a specific Information Element N of HARQ Retransmissions sent
by the NodeB through Iub FP. The N of HARQ Retransmissions IE is enclosed in each
E-DCH UL Data Frame sent by NodeB to RNC over Iub.
B

In UA5.1, this UL OLPC algorithm newly capable of taking into account E-DCH link
quality was introduced via UA5.1 34172 E-DPDCH Retransmissions for DPCCH SIR
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 79/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Adaptation feature. For the sake of simplicity, the target number of HARQ
retransmissions (NHARQ Target) used in this algorithm was fixed. For a detailed
description of UA5.1 34172, please refer to UA5.x HSxPA Engineering Guide [R02].
B

Simulations results showed that, for a given cell, the optimal NHARQ Target value
depends on the number of E-DCH active UEs in the cell and the total UL radio load. In
UA6, E-DCH UL OLPC is improved by introducing an adaptive target number of
HARQ retransmissions, via UA6 34249 EUL Capacity Optimized HARQ Operation
feature.
B

9.1.2 UA6 34249 EUL CAPACITY OPTIMIZED HARQ


OPERATION
9.1.2.1 PRINCIPLE OF E-DCH UL OLPC
This section describes the principle of UL OLPC for E-DCH with Alcatel-Lucent
implementation. For a description of the specific aspects introduced by UA6 34249
feature, please refer to section 9.1.2.2.
X

E-DCH UL OLPC GENERAL PRINCIPLE (UA5.1 AND UA6)


The general principle of UL OLPC for E-DCH with Alcatel-Lucent implementation,
common to UA5.1 and UA6, is summarized in below figure.

Computation of SIR Target

SIR Target

NodeB 1

(according to all Partial SIR Targets):


If at least 1 Partial SIR Target
increased since previous update:
SIR Tg = max { Partial SIR Targets }

UL OLPC Master

NodeB 2

Partial
SIR Target

Partial
SIR Target

Partial
SIR Target

UL OLPC
Machine

UL OLPC
Machine

UL OLPC
Machine

CRCI of UL
DCH 1

CRCI of UL
DCH 2

(DCH 1)

(DCH 1)

(DCH 2)

(DCH 2)

(E-DCH)

(E-DCH)

Else:
SIR Tg = min { Partial SIR Targets }
Update triggering:
Periodically
On event, i.e. if 1 Partial SIR Tg
increased more than a threshold
since previous update.

From UA5.1 (34172 feature):

N of HARQ
Radio quality on E-DCH taken
Retransmissions IE

as an input for UL OLPC

Computation of Partial SIR Target (E-DCH case):


Update frequency: On reception of Iub E-DCH Data Frame by RNC, i.e. every 10ms or 2ms.
Parameter (UA5.1) or
Parameter
Computation method:
set of parameters (UA6).
Partial SIR Tg (k+1) = Partial SIR Tg (k) + Step . (NHARQ NHARQ Target) From UA6, NHARQ Target
adapts to #active E-DCH
known from
users and UL Radio Load
N of HARQ Retransmissions IE Color.

Figure 17: E-DCH UL OLPC general principle

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 80/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


The UL OLPC algorithm takes into account the link quality of each UL transport
channel established (of DCH and/or E-DCH type) for the considered user, so that
finally the link quality of each UL transport channel fulfils a target link quality specified
separately for each channel. This algorithm is often referred as multiple reference
transport channel UL OLPC algorithm.
Regarding the DCH transport channels, for each channel, a target BLER is set to a
value tunable by the customer, and the BLER is monitored by an UL OLPC Machine
dedicated to this channel. The BLER of each DCH is derived by the RNC basing on
the CRC Indicator (CRCI) of the selected UL DCH data frame (the NodeB computes a
CRCI for each transport block it receives from the air interface and sends it to the
RNC through Iub-FP. In addition, several data frames transporting the same user data
can be sent by the different NodeBs having a link with the mobile; hence the CRCI
retained by the RNC is the CRCI carried by the UL DCH data frame selected by the
RNC). A Partial UL SIR Target is derived each TTI (TTI period depends on the DCH
channel considered) by the UL OLPC Machine of each DCH channel, so that BLER on
a DCH channel would converge toward its target BLER if this Partial UL SIR Target
were applied as the UL SIR Target. In other words, the multiple Partial UL SIR
Targets derived by the UL OLPC Machines are used in the end by the UL OLPC
algorithm in order to derive the actual global UL SIR Target.
The way the multiple Partial UL SIR Targets are used in the UL OLPC algorithm is as
follows. Both on event and periodically, an update of the UL SIR Target, i.e. the
quantity that drives the UL OLPC for the user, is triggered. The UL SIR Target is
derived by a central entity called UL OLPC Master, according to the current value of
all Partial UL SIR Targets. Finally, the UL SIR Target derived by the UL OLPC Master
is applied, i.e. it is sent to the NodeBs having a link with the mobile. In the same time,
the UL SIR Target is also communicated to all the UL OLPC Machines present and
used as the initial Partial UL SIR Target for the next UL SIR Target update period.
Regarding the E-DCH transport channel, a dedicated UL OLPC Machine is created,
and its role is again to derive a Partial SIR Target so that the link quality on the E-DCH
channel would converge toward its target link quality if this Partial UL SIR Target were
applied as the UL SIR Target.
The main difference with respect to UL OLPC for DCH transport channels is that, for
the E-DCH channel, the quantity monitored is not the BLER but the number of HARQ
retransmissions instead, and the link quality target is not a target BLER but a target
average number of HARQ retransmissions. This is possible since the information
concerning the number of HARQ retransmissions (for each MAC-e PDU correctly
received or at HARQ failure detection) is sent by the NodeB to the RNC through Iub
FP, via the N of HARQ Retransmissions IE enclosed in E-DCH UL Data Frames.

Remark on usage of SRB TF1x0 for E-DCH calls:


U

In UA5.0 and early UA5.1/iCEM, for stand-alone E-DCH calls (i.e. E-DCH + SRB in
uplink, no multi-service), the format used for the UL SRB for the SRB inactivity periods
(i.e. no signaling data transmitted) was TF1x0 (i.e. transport format that forces the
transmission of a CRC even when there is no signaling data to transmit), instead of
the usual TF0x148 format. This allowed continuous monitoring of the radio quality
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 81/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


(BLER) of the UL DCH transport channel holding the SRB, thus continuous updating
of UL SIR Target even when there is no activity on E-DCH and no or few UL signaling
activity (signaling activity is generally low, e.g. around 5%).
However, in early UA5.1/iCEM, tests showed that in most of the cases, the usage of
SRB TF1x0 for stand-alone E-DCH calls makes UL SIR Target decrease gradually
down to minSirTarget when there is no activity on E-DCH. This allowed saving some
UE Tx power and some UL load, but the gain is small because during inactivity
periods on E-DCH the only power-consuming UL physical channel is UL DPCCH. On
the other hand, the usage of SRB TF1x0 for stand-alone E-DCH calls lead to
substantial degradation of radio quality on E-DCH (i.e. NHARQ measured > NHARQ
Target) just after traffic on E-DCH started again. Indeed, when traffic on E-DCH
started again, UL SIR Target was well below the value required to achieve the target
radio quality on E-DCH.
B

For above reasons, effective from UA5.1.0.3, it has been decided to remove SRB
TF1x0 for stand-alone E-DCH calls (i.e. E-DCH + SRB in uplink, no multi-service), and
use instead the usual TF0x148 format. Then, as a consequence, for a stand-alone EDCH call in uplink (i.e. no voice or video telephony in parallel), it is not possible to
monitor continuously the radio quality when there is no activity on E-DCH, which
means that UL SIR Target almost stays at the level it was when activity on E-DCH
stopped. Test showed that this allows improving E-DCH radio quality for the case of
sporadic UL traffic (e.g. UL pings).

PARTIAL UL SIR TARGET COMPUTATION


The Partial UL SIR Target associated to the E-DCH channel is derived within the UL
OLPC Machine associated to the E-DCH channel. Each time the RNC receives an EDCH Data Frame for the user considered (remark: from UA6, since E-DCH SHO is
supported, if UE is in E-DCH SHO then one E-DCH Data Frame among several
frames carrying the same data is selected at RNC), it updates the Partial UL SIR
Target associated to the E-DCH channel of this user, as follows:
Partial UL SIR Target (k+1)
= Partial UL SIR Target (k) + ulSirStep * (NHARQ - NHARQ Target)
B

With:

ulSirStep: Parameter that impacts the amplitude of each change in the Partial
UL SIR Target associated to the E-DCH transport channel.
Remark: ulSirStep is different from ulUpSirStep parameter, which is used for
the derivation of Partial UL SIR Target associated to transport channels of
DCH type. The formula giving Partial UL SIR Target is different for DCH.
Please refer to UA6 UPUG [R01], Vol.9, section 2.3.4 for the formula giving
Partial UL SIR Target for the DCH case.
U

NHARQ: Number of HARQ retransmissions that occurred for a given MAC-e


PDU, as indicated by the N of HARQ Retransmissions IE enclosed in the EDCH Data Frame. If UE is in E-DCH SHO, NHARQ: is the number of HARQ
retransmissions that occurred for a given MAC-e PDU between UE and the
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 82/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


NodeB from which comes the selected E-DCH Data Frame corresponding to
this MAC-e PDU.
Remark:
U

In UA5.1, when an HARQ Failure Indication (see 3GPP TS 25.427 [R07] for
detailed information on the different cases of E-DCH HFI) is reported by the EDCH Serving NodeB, NHARQ was taken equal to the maximum allowed number
of HARQ retransmissions.
HX

In UA6, when an HFI is reported by the E-DCH Serving NodeB (as of 3GPP,
only the E-DCH serving NodeB can send HFI messages), a specific correction
is applied to Partial UL SIR Target, i.e. above formula does not apply. See
section 9.1.2.2.3 for more information on HFI handling in E-DCH UL OLPC.
X

NHARQ Target: Target average number of HARQ retransmissions, set via


nHarqRetransTargetSx parameters (see section 9.1.2.2.2 for more
information on nHarqRetransTargetSx parameters, which are introduced in
UA6).
B

Remarks regarding above formula:


U

In above formula, (NHARQ - NHARQ Target) can be negative, null or positive.

From UA5.0, a Fast Convergence Mechanism has been introduced in the UL


OLPC Machines associated to DCH channels. The aim of this enhancement is to
make faster the convergence of UL SIR Target just after a new UL RB
establishment. This Fast Convergence Mechanism does not apply to the UL
OLPC Machine associated to the E-DCH transport channel, i.e. above formula is
not impacted by this mechanism. Please refer to UA6 UPUG [R01], Vol.9, section
2.3.4, for a detailed description of this mechanism.

UL SIR TARGET UPDATE TIMING


Updates for the UL SIR Target are triggered both on event and periodically. For the on
event updates, the triggering event is when the increase of one of the Partial SIR
Targets since the last UL SIR Target update exceeds a threshold set via
updateThreshold parameter. For periodical updates, the update period is given by
the following formula:
Update Period [ms] = ulUpdatePeriod * max{ TTIs of user ref. Tr. channels } [ms]
With ulUpdatePeriod being the parameter indicating the period between two UL SIR
Target periodical updates (number of TTIs i.e. integer; specified per UL service).

UL SIR TARGET COMPUTATION


The UL OLPC Master updates the UL SIR Target as follows.

If at least the Partial SIR Target of one of the transport channels has
increased since previous update:
UL SIR Target = max{ Partial SIR Targets }

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 83/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Else:
UL SIR Target = min{ Partial SIR Targets }

The RNC sends the new UL SIR Target computed as explained above to NodeB(s)
each time there is an on event or periodical update. Note that regarding the periodical
updates, in UA5.x the UL SIR Target was sent to NodeB(s) only when it was different
from its previous value, whereas in UA6 the UL SIR Target is sent to NodeB(s) at
each periodical update regardless of the UL SIR Target value.

9.1.2.2 UA6 34249 FEATURE DESCRIPTION


9.1.2.2.1 FEATURE AIM AND PRINCIPLE
In UA6, the uplink Outer-Loop Power Control (UL OLPC) for E-DCH is improved by
introducing an adaptive target number of HARQ retransmissions, via UA6 34249 EUL
Capacity Optimized HARQ Operation feature. This mechanism allows adapting the
target number of HARQ retransmissions (NHARQ Target) according to current number
of E-DCH users and UL radio load. In other words, this mechanism allows adapting
the required Eb/N0 at NodeB to current UL cell load condition, in order to optimize the
usage of UL radio load resource between all users, thus improving E-DCH
performance.
B

The key enhancements of UA6 34249 with respect to UA5.1 E-DCH UL OLPC (UA5.1
34172 feature) are as follows.

Introduction of an adaptive target number of HARQ retransmissions (NHARQ


Target). NHARQ Target is adapted according to:
B

Current number of active E-DCH users in the cell


(see definition of active E-DCH users below in 9.1.2.2.2)
X

Current UL Radio Load Color


(derived from the non E-DCH UL radio load of the cell)

Restriction: [iCEM] Adaptive NHARQ Target mechanism disabled


B

Due to the limited E-DCH decoding capacity of the iCEM board (i.e. 2.1Mbps @MAC-e), in case of
multiple E-DCH UEs per cell, E-DCH user throughput is rather limited by board E-DCH decoding
capacity than available UL radio load. In case of multiple E-DCH UEs per cell, lab tests showed that
targeting a higher number of HARQ retransmissions is useless and may even degrade
performance.
Hence, when E-DCH is handled by an iCEM, NHARQ Target is not adapted according to current
number of active E-DCH users and UL Radio Load Color. Precisely, adaptive NHARQ Target
mechanism is disabled by always forcing Cell State is to S1 (see section 9.1.2.2.2 for details on
adaptive NHARQ Target mechanism). This can be done by using an hard-coded parameter:
cellrrm_c[0].data.spare[0] = 1. (RNC rebuilt is necessary)
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 84/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Introduction of a Fast Decrease mechanism for Partial SIR Target(s)


related to MAC-d flow(s) carried on E-DCH. This mechanism allows a faster
convergence of the UL SIR Target when UE is in good radio conditions.

E-DCH UL OLPC algorithm made suitable for:

E-DCH macro diversity (introduced in UA6)

Both TRB and SRB on E-DCH (SRB on E-DCH introduced in UA6)

Both 10ms and 2ms E-DCH TTI (2ms E-DCH TTI introduced in UA6
for the xCEM)

When in E-DCH SHO, processing of HARQ Failure Indication (HFI) messages


received at RNC into several HFI Reception Scenarios, which are used for:
o

Correction of Partial SIR Target(s) of E-DCH MAC-d flow(s)

UL/DL Imbalance Detection mechanism:


Counter intended for Engineering teams to detect UL/DL imbalance
issues (not directly related to UL OLPC)

9.1.2.2.2 PARTIAL UL SIR TARGET COMPUTATION


CELL STATE
In UA6, in order to adapt NHARQ Target value according to current number of E-DCH
users and UL radio load of the considered cell, for each cell, a state (Cell State)
specific to UA6 34249 feature is computed and updated. Note that at a given instant,
the same NHARQ Target value is used for all the E-DCH UEs for which the considered
cell is the E-DCH serving cell.
B

Cell State, which can take three different values S1, S2 and S3, is computed basing
on the following inputs:

Current number of active E-DCH users in the cell.


For UA6 34249, active E-DCH users refers to UEs currently having an E-DCH
radio link established with the considered cell (hence these UEs are in Cell_DCH
RRC state), and for which this cell is the E-DCH serving cell.

Current UL Radio Load Color.


The UL Radio Load Color is derived from the non E-DCH UL radio load of the cell.
For a detailed description of the calculation of UL Radio Load Color, please refer
to UA6 UPUG [R01], Vol.6, section 5.4.1.
X

Below figure shows how Cell State is determined according to the current number of
active E-DCH users and UL Radio Load Color of the cell. Note that maxNumActiveEdchUsersPerCellForS1 and maxNumActiveEdchUsersPerCellForS2 parameters
are used to set the thresholds for Cell State change on number of active E-DCH
users criterion.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 85/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Number of
active
E-DCH users

S3

maxNumActiveEdchUsersPerCellForS2

S2

maxNumActiveEdchUsersPerCellForS1

S1
0

green

UL Radio
Load Color
yellow

red

Figure 18: Cell State computation


The Partial SIR Target related to the E-DCH transport channel (note: in case of SRB
on E-DCH, there are two Partial SIR Targets related to E-DCH, see below paragraph
SRB ON E-DCH CASE) is computed as it was explained in section 9.1.2.2.1. With
UA6 34249 feature, NHARQ Target, which is used as an input to compute the Partial
SIR Target related to the E-DCH transport channel, can take three different values
depending on the current Cell State:
X

Cell State = S1 NHARQ Target = nHarqRetransTargetS1


B

Cell State = S2 NHARQ Target = nHarqRetransTargetS2


B

Cell State = S3 NHARQ Target = nHarqRetransTargetS3


B

FAST DECREASE MECHANISM


UA6 34249 introduces a Fast Decrease mechanism for Partial SIR Target(s) related
to MAC-d flow(s) carried on E-DCH. This mechanism allows a faster convergence of
the UL SIR Target when UE is in good radio conditions. The principle of this
mechanism is as follows.
For the considered MAC-d flow carried on E-DCH, if more than
edchNrOfConsecutiveZeroHarqReTxThreshold MAC-es PDUs are received at the
RNC without any HARQ retransmission or HFI (HARQ Failure Indication), then the
Fast Decrease mechanism is triggered, i.e. the Partial SIR Target related to this
MAC-d flow is updated according to a specific formula (different from the usual
formula given in 9.1.2.2.1):
X

Partial UL SIR Target (k+1) = Partial UL SIR Target (k) + edchSirStepFastDecrease


Once the triggering condition for Fast Decrease mechanism has been fulfilled, the
Partial SIR Target of the considered MAC-d flow is updated according to above
specific formula at each consecutive E-DCH Data Frame received without any HARQ
retransmission or HFI. Fast Decrease mechanism is cancelled as soon as an E-DCH
Data Frame is received with at least one HARQ retransmission or with an HFI, and the
Partial SIR Target is then updated according to the usual formula.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 86/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


SRB ON E-DCH CASE
In UA6, with the introduction of 33581 SRB on E-DCH during Call feature, in some
cases the UL SRB is carried on the E-DCH transport channel along with the UL TRB.
Please refer to section 10 for a detailed description of UA6 33581.
X

In case of SRB on E-DCH, two MAC-d flows are carried on E-DCH: the UL SRB MACd flow, and the UL TRB MAC-d flow. Regarding the UL OLPC, two UL OLPC
Machines are built for E-DCH. Each one of the two UL OLPC Machines computes
separately the Partial SIR Target related to the MAC-d flow it is related to. This is
shown in below figure.

SIR Target

NodeB 1

UL OLPC Master
NodeB 1

Partial
SIR Target

Partial
SIR Target

UL OLPC
Machine

UL OLPC
Machine

(E-DCH SRB)

(E-DCH SRB)
N of HARQ
Retransmissions IE

(E-DCH TRB)

(E-DCH TRB)
N of HARQ
Retransmissions IE

Figure 19: UL OLPC in case of SRB on E-DCH

Note that for the case of SRB on E-DCH, there are two sets of
nHarqRetransTargetSx parameters, one for the SRB and one for the TRB MAC-d
flow, thus making it possible to set the target number of HARQ retransmissions NHARQ
Target for each Cell State separately for the SRB and for the TRB MAC-d flow.
B

In order to guarantee good link quality for the UL SRB, for the SRB MAC-d flow it is
recommended to set NHARQ Target to a low and same value for all Cell States (see
section 9.1.2.3.3 for more details on this recommendation).
B

9.1.2.2.3 HFI HANDLING


When the UE is in E-DCH SHO, the analysis at RNC of HARQ Failure Indication (HFI)
messages received from the E-DCH serving NodeB and the E-DCH Data Frames
correctly received from the serving and non-serving NodeB(s) allows adapting the
Partial SIR Target(s) of E-DCH MAC-d flow(s) according to the type of E-DCH SHO
scenario detected.

HFI RECEPTION SCENARIOS DETERMINATION


At the RNC, the HFI messages received from the E-DCH serving NodeB and the EDCH Data Frames correctly received from the serving and non-serving NodeB(s) are
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 87/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


processed to determine an E-DCH SHO scenario (HFI Reception Scenario). HFI
Reception Scenario determination is done as follows.

Periodically, basing on HFI messages received from the E-DCH serving NodeB
and the E-DCH Data Frames correctly received from the serving and non-serving
NodeB(s) during the last HFI monitoring period), an HFI Reception Scenario is
determined among 4 possible scenarios HFI 0, HFI 1, HFI 2 and HFI 3.
Remark: As of 3GPP (see TS 25.427 [R07]), only the E-DCH serving NodeB can
report HFI messages to the RNC.
U

The HFI monitoring period is set via edchOlpcSamplingPeriodTti10ms and


edchOlpcSamplingPeriodTti2ms parameters.

During the HFI monitoring period, the following internal counters are incremented:

Nb HFI frames

Nb valid frames from serving NodeB

Total nb valid frames after frame selection

At the end of the HFI monitoring period, the following two quantities are computed:
o

HFI Ratio = Nb HFI frames / Total nb valid frames after frame


selection
HFI Ratio quantity reflects the link quality of the E-DCH radio link(s)
established between the considered UE and the serving NodeB

Serving Ratio = Nb valid frames from serving NodeB / Total nb valid


frames after frame selection
Serving Ratio quantity reflects the relative link quality of the E-DCH
radio link(s) established between the considered UE and the serving
NodeB, with respect to the link quality of the E-DCH radio link(s)
established between the considered UE and non-serving NodeB(s).

Below figure shows how HFI Reception Scenario is determined according to current
HFI Ratio and Serving Ratio quantities. Note that edchOlpcServingRatioThreshold
and edchOlpcHfiRatioThreshold parameters are used to set the thresholds for HFI
Reception Scenario determination based on Serving Ratio criterion and HFI Ratio
criterion, respectively.

Serving Ratio
edchOlpcServingRatioThreshold
0

HFI 0

HFI 1

HFI 3

HFI 2
HFI Ratio
edchOlpcHfiRatioThreshold

Figure 20: HFI Reception Scenario computation

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 88/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


PARTIAL UL SIR TARGET COMPUTATION
E-DCH SHO case:
U

When the UE is in E-DCH SHO (inter-NodeB SHO, not softer HO), at the end of each
HFI monitoring period, the Partial SIR Target related to the E-DCH transport channel
is updated. In case of SRB on E-DCH, the same correction is applied to both Partial
SIR Targets of SRB and TRB. The Partial SIR Target is updated as follows.
Partial UL SIR Target (k+1)
= Partial UL SIR Target (k) + edchSirStepHfi [HFI Reception Scenario]
With edchSirStepHfi being a parameter which contains a sequence of three values
selected according to the HFI Reception Scenario detected HFI 1, HFI 2 and HFI 3.
Note that HFI 0 corresponds to the normal E-DCH SHO scenario, i.e. only few or no
HFI are received from the serving NodeB, and in most cases when an HFI is received
the corresponding MAC-e PDU is not decoded by the non-serving NodeB(s).

No E-DCH SHO case:


U

When the UE is not in E-DCH SHO (but UE may be in E-DCH softer HO), at the end
of each HFI monitoring period, the Partial SIR Target is updated as in above formula,
but the correction applied is always taken equal to edchSirStepHfi [HFI 1], regardless
to the current HFI Reception Scenario.

9.1.2.2.4 UL/DL IMBALANCE DETECTION MECHANISM


UA6 34249 introduces an UL/DL Imbalance Detection mechanism which consists
into incrementing a performance counter RNC counter VS.EdchLinkImbalance
based on the detection at RNC of MAC-e PDUs correctly decoded by a non-serving
NodeB but not decoded by the serving NodeB. This counter helps network
engineering teams to detect UL/DL imbalance issues, without having to perform a
drive test. Note that UL/DL Imbalance Detection mechanism is part of UA6 34249
since its implementation is partially similar to the implementation of HFI Reception
Scenario detection, but this mechanism is not directly related to UL OLPC.
The principle of this mechanism is as follows.

Each time a consecutive MAC-e PDU is decoded by a non-serving NodeB but not
decoded by the serving NodeB (i.e. if the quality of the E-DCH radio link(s) of the
serving NodeB is poor compared to the quality of the E-DCH radio link(s) of nonserving NodeB(s)), internal counter Nb Consecutive Good Frames Not Received
on Serving NodeB is incremented.

As soon as a MAC-e PDU is correctly decoded by the serving NodeB, Nb


Consecutive Good Frames Not Received on Serving NodeB is reset to 0.

If Nb Consecutive Good Frames Not Received on Serving NodeB internal counter


exceeds a certain threshold set via edchLinkBalanceThreshold parameter, then
VS.EdchLinkImbalance RNC counter is incremented.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 89/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Remarks:
U

In case of SRB on E-DCH, each one of the two MAC-d flows is treated
independently for counting consecutive MAC-e PDUs decoded by a non-serving
NodeB but not decoded by the serving NodeB

VS.EdchLinkImbalance counter is relevant only for periods with no congestion


on Iub. Indeed, if one of the Iub interfaces related to a NodeB involved in the EDCH call is congested, the E-DCH Data Frames carried on this Iub interface
cannot arrive in the same timeframe as the E-DCH Data Frames with the same
data carried on other Iub interface(s), so it is not possible to check for radio UL/DL
imbalance at RNC basing on the received E-DCH Data Frames.

9.1.2.3 PARAMETER SETTINGS AND RECOMMENDATIONS


9.1.2.3.1 FEATURE ACTIVATION
Activation of E-DCH UL OLPC:
U

The conditions for E-DCH UL OLPC to be enabled (i.e. for the UL OLPC algorithm to
take into account radio quality of the E-DCH transport channel) are as follows.

For
UL
services
with
E-DCH,
isUlOuterPCActivated
(under
UlOuterLoopPowerCtrl object) must be set to True. Note that the
recommendation in UA6 UPUG [R01] is to set isUlOuterPCActivated to True
for all UL services (except SRB_CellFACH and TRBxSRB_CellFACH for which UL OLPC does
not apply).
X

For the UL services with E-DCH, the E-DCH transport channel must be set as a
reference channel for the driving of UL OLPC. This can be done by making sure
that an instance of ReferenceUlRbSetList with referenceUlRbSetConfId set to
UlRbSetConf/PS_EDCH exists for all UL services with E-DCH. If such instance
of ReferenceUlRbSetList does not exist, it must be created.

For the UL services with E-DCH, minSirTarget and maxSirTarget (under


UlUsPowerConf) must be set to different values (with minSirTarget <
maxSirTarget).

E-DCH UL OLPC can be disabled by following one of the two methods below.

Method 1 (UL OLPC active when in E-DCH call but E-DCH radio link quality not
taken into account):
U

For the UL services including an E-DCH UL RB, remove the E-DCH transport
channel from the list of reference transport channels driving the UL OLPC
algorithm.

Method 2 (UL OLPC locked when in E-DCH call):


U

For the UL services including an E-DCH UL RB, set minSirTarget =


maxSirTarget.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 90/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Activation of adaptive NHARQ Target algorithm:
U

UB

UB

In order to enable the ability to adapt the target number of HARQ retransmissions
NHARQ Target according to current number of E-DCH users and UL radio load, the
parameters
nHarqRetransTargetS1,
nHarqRetransTargetS2
and
nHarqRetransTargetS1 must be set to different values.
B

It is recommended to set these parameters so that the following rule is verified:


nHarqRetransTargetS1 nHarqRetransTargetS2 nHarqRetransTargetS3

On the other hand, in order to disable the ability to adapt NHARQ Target according
to current number of E-DCH users and UL radio load, the parameters
nHarqRetransTargetS1, nHarqRetransTargetS2 and nHarqRetransTargetS1
must be set to the same value.
B

9.1.2.3.2 UA6 RAN MODEL


Note that all the parameters of UA6 34249 feature are at OMC-R, i.e. under the RNC
objects and parameters tree.
Below figure shows the RAN model (i.e. parameters and objects tree) for the
parameters defined for PS_EDCH and SRB_EDCH UL radio bearers.
RNC
RadioAccessService

parameter : same or similar parameter already present in UA5.1


parameter : new parameter from UA6
Object :
new object from UA6

UlRbSetConf/
PS_EDCH
SRB_EDCH

DynamicParameterForEdchTti10ms

[iCEM] [xCEM]
DynamicParameterForEdchTti10ms object:
Only present under UlRbSetConf/PS_EDCH

DynamicParameterForEdchTti2ms
ulSirStep
updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepFastDecrease
edchOlpcHfiRatioThreshold
edchOlpcServingRatioThreshold
edchSirStepHfi
edchLinkBalanceThreshold
NHarqRetransTarget 3
NHarqRetransTarget 3
nHarqRetransTargetS1
nHarqRetransTargetS2
nHarqRetransTargetS3

3 instances of
NHarqRetransTarget object:
one instance per OLS.

Figure 21: UA6 34249 RAN model for PS_EDCH and SRB_EDCH UL RBs

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 91/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Below figure shows the RAN model for the parameters defined per UL service
(including E-DCH UL services) and for other parameters.
parameter : same or similar parameter already present in UA5.1
parameter : new parameter from UA6
Object :
new object from UA6

Parameters defined for E-DCH UL services


(PS_EDCHxSRB_3_4K and
all multi-services with E-DCH)

Other parameters

RNC

RNC

RadioAccessService

RadioAccessService

DedicatedConf

DedicatedConf
15

PowerConfClass

EdchCellClass

EdchRncConf
edchOlpcSamplingPeriodTti10ms
edchOlpcSamplingPeriodTti2ms
15

maxNumActiveEdchUsersPerCellForS1
maxNumActiveEdchUsersPerCellForS2
UlUsPowerConf/

UlUserService/

PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K

initialSirTarget
minSirTarget
maxSirTarget

PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K

UlOuterLoopPowerCtrl
isUlOuterPCActivated
ulUpdatePeriod

Figure 22: UA6 34249 RAN model for E-DCH UL services and misc.

9.1.2.3.3 PARAMETERS DEFINED FOR PS_EDCH AND SRB_EDCH UL


RBs
ulSirStep: Impacts the amplitude of each change in the Partial SIR Target related to a
given UL DCH transport channel or the E-DCH transport channel. Note that the
formula giving Partial SIR Target is different for DCH and for E-DCH.
Parameter

Range & Unit

ulSirStep
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
RNC, UlRbSetConf, E-DCH TTI type
Decimal [0.005 0.300] step: 0.005, dB

User & Class

Customer, 3

Value

For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH:


DynamicParameterForEdchTti10ms: 0.025
DynamicParameterForEdchTti2ms: 0.01

Object
Granularity

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 92/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


updateThreshold: Used for the triggering of on event updates of the UL SIR Target.
When the increase of one of the Partial SIR Targets exceeds the updateThreshold
value configured for this type of UL RB, an UL SIR Target update is triggered.
Parameter

Range & Unit

updateThreshold
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
RNC, UlRbSetConf, E-DCH TTI type
Integer [0 255], 0.1dB

User & Class

Customer, 3

Value

For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH: 1


(corresponds to 0.1dB)

Object
Granularity

edchNrOfConsecutiveZeroHarqReTxThreshold: Threshold (in terms of number of


consecutive received MAC-es PDUs that did not require any HARQ retransmission
and for which no HFI was received) used to trigger Fast Decrease mechanism for
the Partial SIR Target related to the considered E-DCH MAC-d flow.
Parameter

edchNrOfConsecutiveZeroHarqReTxThreshold

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Integer [0 1024], N/A

User & Class

Customer, 3

Value

200
edchSirStepFastDecrease: Step size used for Partial SIR Target update when Fast
Decrease mechanism has been triggered.

Parameter

edchSirStepFastDecrease

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Signed [-0.300 0.000] step 0.005, dB

User & Class

Customer, 3

Value

-0.02

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 93/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


edchOlpcHfiRatioThreshold: Threshold applying to the HFI Ratio (Nb HFI frames /
Total nb valid frames after frame selection) quantity computed at the end of each HFI
monitoring period. In order to determine the current HFI Reception Scenario, a
comparison is done between HFI Ratio and edchOlpcHfiRatioThreshold.
Parameter

edchOlpcHfiRatioThreshold

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Integer [0 100], %

User & Class

Customer, 3

Value

[iCEM] [xCEM] 100


[UCU-III] 10
edchOlpcServingRatioThreshold: Threshold applying to the Serving Ratio (Nb
valid frames from serving NodeB / Total nb valid frames after frame selection) quantity
computed at the end of each HFI monitoring period. In order to determine the current
HFI Reception Scenario, a comparison is done between Serving Ratio and
edchOlpcServingRatioThreshold.

Parameter

edchOlpcServingRatioThreshold

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Integer [0 100], %

User & Class

Customer, 3

Value

[iCEM] [xCEM] 0
[UCU-III] 50
edchSirStepHfi: Sequence containing the step size values for Partial SIR Target
update each time HFI Reception Scenario is updated. The 3 values of the sequence
correspond to {HFI 1, HFI 2, HFI 3}.

Parameter

edchSirStepHfi

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

List of decimal [0.000 1.000] step 0.005, dB

User & Class

Customer, 3

Value

[iCEM] [xCEM] {0; 0; 0}


[UCU-III] {0.15; 0.1; 0.2}

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 94/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


edchLinkBalanceThreshold: Regarding UL/DL Imbalance Detection mechanism,
threshold (in terms of consecutive frames not decoded by the serving NodeB but
decoded by a non-serving NodeB) used to trigger increment of
VS.EdchLinkImbalance RNC counter.
Setting edchLinkBalanceThreshold to 1024 disables UL/DL Imbalance Detection
mechanism (i.e. disables VS.EdchLinkImbalance counter).
Parameter

edchLinkBalanceThreshold

Object

DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Integer [0 1024], N/A

User & Class

Customer, 3

Value

200
nHarqRetransTargetS1: NHARQ Target (i.e. target number of HARQ retransmissions)
value used for UL OLPC when Cell State = S1. In addition, for SRB on E-DCH case,
for the SRB MAC-d flow, NHARQ Target is always taken equal to
nHarqRetransTargetS1 (independently from current Cell State).
B

Parameter

nHarqRetransTargetS1

Object

NHarqRetransTarget

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Decimal [0.00 12.00], step 0.01 N/A

User & Class

Customer, 3

Value

For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.07
DynamicParameterForEdchTti2ms: 0.04
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04
nHarqRetransTargetS2: NHARQ Target value used for UL OLPC when Cell State = S2.
B

Parameter

nHarqRetransTargetS2

Object

NHarqRetransTarget

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Decimal [0.00 12.00], step 0.01 N/A

User & Class

Customer, 3

Value

For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.25
DynamicParameterForEdchTti2ms: 1.2
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 95/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


nHarqRetransTargetS3: NHARQ Target value used for UL OLPC when Cell State = S3.
B

Parameter

nHarqRetransTargetS3

Object

NHarqRetransTarget

Granularity

RNC, UlRbSetConf, E-DCH TTI type

Range & Unit

Decimal [0.00 12.00], step 0.01 N/A

User & Class

Customer, 3

Value

For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.85
DynamicParameterForEdchTti2ms: 1.5
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04

Rule: nHarqRetransTargetSx

For each E-DCH TTI type, the target average number of HARQ retransmissions NHARQ Target
specified by nHarqRetransTargetSx parameters must be consistent with the maximum allowed
number of HARQ retransmissions set by edchHarqMaxRetransEdchTti10 (for 10ms E-DCH
TTI) and edchHarqMaxRetransEdchTti2 (for 2ms E-DCH TTI).

For each E-DCH TTI type, nHarqRetransTargetSx must be filled in with the same value for all
three instances of NHarqRetransTarget (there is one NHarqRetransTarget instance per OLS
Olympic Level Service).

Engineering Recommendation: nHarqRetransTargetSx for SRB on E-DCH case


As explained in 9.1.2.2.2, for the case of SRB on E-DCH, there are two sets of
nHarqRetransTargetSx parameters, one for the UL SRB MAC-d flow and one for the UL TRB
MAC-d flow. For the SRB MAC-d flow, in order to guarantee short transmission delay,
it is recommended to set NHARQ Target to a low and same value for all Cell States, as indicated
below.
X

Under UlRbSetConf/SRB_EDCH, set:


nHarqRetransTargetS1 = nHarqRetransTargetS1 = nHarqRetransTargetS3
= small value (e.g. 0.04)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 96/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.1.2.3.4 PARAMETERS DEFINED PER UL SERVICE
isUlOuterPCActivated: Enables or disables UL OLPC for a specific UL service (i.e.
per instance of UlUserService). This is a security that allows avoiding power control
message on Iub in case of congestion and saving RNC capacity.
Parameter

isUlOuterPCActivated

Object

UlOuterLoopPowerCtrl

Granularity

RNC, UlUserService

Range & Unit

Boolean {False, True}, N/A

User & Class

Customer, 3

Value

For all UlUserService instances*: True


* Except SRB_CellFACH and TRBxSRB_CellFACH for which UL OLPC does not apply

ulUpdatePeriod: Period between two UL SIR Target periodical updates, in number of


largest TTI (i.e. value is an integer) among the transport channels referenced for the
considered UL service.
Parameter

ulUpdatePeriod

Object

UlOuterLoopPowerCtrl

Granularity
Range & Unit

RNC, UlUserService
Integer [0 255], N/A

User & Class

Customer, 3

Value

For UlUserService instances with PS_EDCHxSRB_3_4K: 25


(corresponds to 1s for E-DCH standalone with SRB on UL DCH, since in this case
largest TTI is the SRB TTI (40ms))
For UlUserService/PS_EDCHxSRB_EDCH:
[xCEM] 250 (corresponds to 500ms since in this case largest TTI is the TTI of the
E-DCH transport channel (2ms))
initialSirTarget: UL SIR Target used for the initialization of UL OLPC algorithm.

Parameter

initialSirTarget

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

For UlUsPowerConf instances with PS_EDCH:


[iCEM] 6.5
[xCEM] 7.5
[UCU-III] 7.0

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 97/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


minSirTarget: Lower bound for UL SIR Target in the UL OLPC algorithm.
Parameter

minSirTarget

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

For UlUsPowerConf instances with PS_EDCH:


[iCEM] [xCEM] 3.0
[UCU-III] 0.0
maxSirTarget: Upper bound for UL SIR Target in the UL OLPC algorithm, for 10ms EDCH TTI case. For 2ms E-DCH TTI case, the upper bound for UL SIR Target is taken
as maxSirTarget + Max Sir Target Offset 2ms.
Max Sir Target Offset 2ms is a hard-coded offset introduced because the required UL
SIR for 2ms E-DCH TTI is substantially higher compared to 10ms E-DCH TTI.
For UeCategory4 2ms calls, Max Sir Target Offset 2ms value is 2.6 dB.
For UeCategory6 2ms calls (with SRB on EDCH), Max Sir Target Offset 2ms value is
2.1 dB.

Parameter

maxSirTarget

Object

UlUsPowerConf

Granularity
Range & Unit

PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB

User & Class

Customer, 3

Value

For UlUsPowerConf instances with PS_EDCHxSRB_3_4K:


[iCEM] 6.7
[xCEM] 8.2
[UCU-III] 8.0
For UlUsPowerConf/PS_EDCHxSRB_EDCH:
[xCEM] 8.4

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 98/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Engineering Recommendation:
[iCEM] [xCEM] initialSirTarget and maxSirTarget settings for E-DCH calls
As mentioned in section 5.4, due to specificities in iCEM and xCEM E-DCH functions, and due to
the fact that specific {Reference E-TFCI; Reference Power Offset} tables are set for iCEM and
xCEM, for E-DCH calls, it is strongly recommended to set initialSirTarget and maxSirTarget
parameters to below specified board-specific values.
X

For UlUsPowerConf instances with PS_EDCHxSRB_3_4K, it is recommended to set


initialSirTarget and maxSirTarget as follows, according to the type of board that handles E-DCH
traffic for the considered cell.

E-DCH handled by iCEM: initialSirTarget = 6.5dB maxSirTarget = 6.7dB

E-DCH handled by xCEM: initialSirTarget = 7.5dB maxSirTarget = 8.2dB

(Note: E-DCH UeCategory4 on TTI 2ms, an hard-coded offset of 2.6 dB is applied on top of the
configured maxSirTarget, leading to an actual maxSirTarget of 10.8 dB)
For UlUsPowerConf instance PS_EDCHxSRB_EDCH, it is recommended to set initialSirTarget
and maxSirTarget as follows.

initialSirTarget = 7.5dB maxSirTarget = 8.4 dB

(Note: E-DCH UeCategory6 on TTI 2ms and SRB over EDCH, an hard-coded offset of 2.1 dB is
applied on top of the configured maxSirTarget, leading to an actual maxSirTarget of 10.5 dB)
Configuration method:
U

Use two specific PowerConfClass instances (one for iCEM and one for xCEM).

For the PowerConfClass instance related to each type of board (iCEM and xCEM), set
initialSirTarget and maxSirTarget to above-specified values.

Make each cell (FDDCell object) point toward the appropriate PowerConfClass instance,
according to the type of board that handles E-DCH traffic for this cell.
Reason for using board-specific initialSirTarget and maxSirTarget values for E-DCH
calls:
U

The choice of using board-specific initialSirTarget and maxSirTarget values for EDCH calls is linked with the choice of using board-specific {Reference E-TFCI;
Reference Power Offset} tables. Please refer to section 5.4 for the reason for using
board-specific {Reference E-TFCI; Reference Power Offset} tables.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 99/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.1.2.3.5 OTHER PARAMETERS
maxNumActiveEdchUsersPerCellForS1: Maximum number of active E-DCH users
(i.e. E-DCH serving radio links with RRC state = Cell_DCH) per cell for Cell State =
S1.
Parameter

maxNumActiveEdchUsersPerCellForS1

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Integer [0 64] N/A

User & Class

Customer, 3

Value

2
maxNumActiveEdchUsersPerCellForS2: Maximum number of active E-DCH users
per cell for Cell State = S2.

Parameter

maxNumActiveEdchUsersPerCellForS2

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Integer [0 64] N/A

User & Class

Customer, 3

Value

4
edchOlpcSamplingPeriodTti10ms: HFI monitoring period (for 10ms E-DCH TTI
case), i.e. period within which internal counters related to HFI reception are
incremented, and after which HFI Ratio and Serving Ratio quantities are computed.

Parameter

edchOlpcSamplingPeriodTti10ms

Object

EdchRncConf

Granularity

RNC

Range & Unit

Integer [0 500] step: 10, ms

User & Class

Customer, 3

Value

100
edchOlpcSamplingPeriodTti2ms: HFI monitoring period (for 2ms E-DCH TTI case).

Parameter

edchOlpcSamplingPeriodTti2ms

Object

EdchRncConf

Granularity

RNC

Range & Unit

Integer [0 500] step: 10, ms

User & Class

Customer, 3

Value

20

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 100/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.2 POWER CONTROL OF E-DCH DL CHANNELS
9.2.1 UA5.1/XCEM E-DCH DL CONTROL CHANNELS POWER
CONTROL (33481)
9.2.1.1 INTRODUCTION
On iCEM, E-DCH DL channels are not power controlled. On the other hand, on xCEM,
power control of E-DCH DL channels (E-AGCH, E-RGCH and E-HICH) is supported
from UA5.1 via E-DCH DL control channels Power Control (33481) feature. Note that
this feature was originally introduced in UA5.1 but has been improved in UA6. Please
refer to section 9.2.2 for a description of UA6 evolution of the feature.
X

An overview of handling of E-DCH DL channels power and a description of the


parameters specific to iCEM board has been done in section 4.2.2 of this volume. In
below sections are described the mechanism and parameters of 33481 that are
already present in UA5.1 version of the feature.
X

9.2.1.2 FEATURE DESCRIPTION


As a reminder, this section and the following one only apply to UA5.1/xCEM. In
UA5.1/xCEM, there is no activation flag for UA5.1 33481 feature, which means that
power control of E-DCH DL channels is activated by default. Activation flags are
introduced in UA6.

E-AGCH
Power control of E-AGCH channel is enabled and derived within the NodeB according
to the following formula.

PE AGCH (k ) = PEDCH (k ) + POE AGCH


With:

k: Time (2ms sub-frame index)

PE AGCH(k): Power allocated to the considered E-AGCH channel

PE DCH(k): E-DCH DL channels base power. This is a unique power value derived
within the xCEM according to the algorithm presented below; it is used as a base
for derivation of E-AGCH power (and also E-HICH and E-RGCH when power
control of those channels is enabled).

POE AGCH : Power offset of E-AGCH relative to E-DCH DL channels base power.
Can be set to the desired value via eagchPowerOffset under EdchConf (See
section 9.2.1.3 for a detailed description of this parameter).

E-HICH
Power control of E-HICH channel is enabled and derived within the NodeB according
to the following formula. As a reminder, E-RGCH and E-HICH commands share a
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 101/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


same physical channel (E-RGCH/E-HICH) and are addressed to the wished user by
using specific signatures.

PEHICH signature (k ) = PEDCH (k ) + POEHICH signature


With:

PE HICH signature(k): Power allocated to the E-HICH signature of considered user

POE-HICH signature : Power offset of E-HICH signature relative to E-DCH DL channels


base power. In UA5.1, value is hard-coded to -12 dB.

E-RGCH
Power control of E-RGCH channel is enabled and derived within the NodeB according
to the following formula.

PERGCH signature (k ) = PEHICH signature (k ) + POERGCH / EHICH


With:

PE RGCH signature(k): Power allocated to the E-HICH signature of considered user

PE HICH signature(k): Power allocated to the E-HICH signature of considered user,


computed as explained above.

POE-RGCH / E-HICH: Power offset of E-RGCH signature relative to E-HICH signature


power. Can be set to the desired value via PowerOffsetErgchServingNoSho
under EdchConf (See section 9.2.1.3 for a detailed description of this parameter).

COMPUTATION OF E-DCH DL CHANNELS BASE POWER PE DCH(k)


B

E-DCH DL channels base power PE DCH(k), which is used as a base for derivation of EAGCH power, may be derived according to three different methods or a combination
of these methods. The three methods for the computation of E-DCH DL channels
base power are:
B

Method based on DL DPCH channel power:


PE DCH(k) is derived by adding an offset* to the power of the DL DPCH channel of
the considered user.
B

Method based on DL Inner-Loop Power Control (ILPC) commands:


PE DCH(k) is derived by starting from a given initial power Pinit E DCH and then update
the power basing on the DL ILPC commands received from the considered
mobile. An offset* is also applied.
B

Method based on received CQI


PE DCH(k) is derived basing on the last CQI received from the considered mobile.
Since some time can elapse between the last CQI reception and current time, this
method also makes use of the DL ILPC commands received during this interval of
time. An offset* is also applied.
B

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 102/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


* In above 3 methods, the applied offset may be updated over time in order to
ensure that some long term statistics are taken into account, thus improving the
accuracy of PE DCH(k).
B

The following formula gives the final expression of PE DCH(k). This formula reflects a
generalized approach that combines above three methods. The advantage of this
generalized approach is that it enables optimizing 33481 feature performance
according to the environment considered, through the appropriate choice of weighting
factors 1 and 2.
B

PEDCH (k ) = 0.05 2 PE1DCH (k ) + (1 0.05 2 ) PE2DCH (k )


With :
PE1DCH (k ) = 1 PE1DCH (k 1) + 1 PTPC (k ) + (1 1 ) PDPCH (k )
k

2
EDCH

(k ) = PCQI ( transmitted by UE at time j ) + PTPC (l )


l= j

UA5.1 FEATURE IMPLEMENTATION


In above formula giving E-DCH DL channels base power PE DCH(k), weighting factors
1 and 2 as well as factor are set via NodeB parameters that not accessible to the
customer. In UA5.1, for simplicity purpose, the implementation of E-DCH DL control
channels Power Control (33481) feature is limited to the method based on received
CQI. In addition, DL ILPC commands are not taken into account. In other words,
implementation of 33481 in UA5.1 is based on above formula with 2=0 and =0.
B

9.2.1.3 PARAMETER SETTINGS AND RECOMMENDATIONS


pMinDlEDCH:
Power Control of E-DCH DL channels enabled:
Lower bound for E-DCH DL channels base power PE DCH(k). Value is relative to
CPICH Tx power.
U

Power Control of E-DCH DL channels disabled:


Power offset of E-HICH signature at serving NodeB, relative to CPICH Tx power.
U

Parameter

pMinDlEDCH

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-35.0 15.0] step 0.1, dB

User & Class

Customer, 3

Value

-25.0

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 103/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


pMaxDlEDCH: Upper bound for E-DCH DL channels base power PE DCH(k). Value is
relative to CPICH Tx power.
B

Parameter

pMaxDlEDCH

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-35.0 15.0] step 0.1, dB

User & Class

Customer, 3

Value

-15.0

eagchPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to E-DCH DL channels base power PE DCH(k).
U

Power Control of E-DCH DL channels disabled:


Power offset of E-AGCH relative to CPICH Tx power.
U

Parameter

eagchPowerOffset

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-45.0 65.0] step 0.1, dB

User & Class

Customer, 3

Value

Power Control of E-DCH DL channels enabled: 10.0


Power Control of E-DCH DL channels disabled: -4.0
U

powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to EHICH signature power of considered RL.
Remarks:
- For serving NodeB, only dedicated RG commands are used (at a given time, same
command is transmitted on all radio links).
- powerOffsetERGCHServingNoSHO applies to both E-DCH serving RL and E-DCH
non-serving RLs of serving NodeB (NoSHO has no specific meaning).
U

Parameter

powerOffsetERGCHServingNoSHO

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

1.5
For information, the following parameters are also present in the RAN Model, but
ignored by the system:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 104/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter

eagchPowerOffset

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

4.00

Parameter

eagchPowerOffsetEdchTti2ms

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

4.00

Parameter

ergchPowerOffset

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

-4.00

Parameter

ergchPowerOffsetEdchTti2ms

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

-4.00

Parameter

ehichPowerOffset

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

-4.00

Parameter

ehichPowerOffsetEdchTti2ms

Object

EdchCellClass

Granularity

EdchCellClass

Range & Unit

Signed [-32.00 31.75] step: 0.25, dB

User & Class

Customer, 0

Value

-4.00

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 105/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.2.2 UA6/XCEM E-DCH DL CONTROL CHANNELS POWER
CONTROL (33481)
9.2.2.1 FEATURE DESCRIPTION

UA6 E-DCH DL control channels Power Control (33481) feature


Restriction: Supported on xCEM (not supported on iCEM)
Aim: Save DL power by performing TPC of E-DCH DL ch. (same as UA5.1 33481)
y Increase of available NodeB power
y Reduction of DL intra-cell and extra-cell interference

Key enhancements Vs. UA5.1:


Power Control of E-DCH DL channels made suitable for:
y E-DCH Macro Diversity (introduced in UA6):
Support of E-RGCH and E-HICH Power Control for E-DCH non-serving radio links.
y Both 10ms and 2ms E-DCH TTI (introduced in UA6):
Introduction of an additional fixed power offset for 2ms E-DCH TTI.

New computation method for E-DCH DL channels base power PE-DCH (k)
In UA6, PE-DCH (k) computation is based either on one of following methods, or on a
combination of following methods:
- CQI received at NodeB (as in UA5.1)
- DL DPCH channel Tx power
- DL Inner-Loop Power Control (ILPC) commands (not used in final implementation)

Introduction of E-HICH Outer-Loop correction mechanism:


(not used in final implementation)

Correction on top of PE-DCH (k) computed basing on E-HICH bad detection by UE.
Benefits to all E-DCH RLs of the E-DCH serving NodeB.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 106/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.2.2.2 PARAMETER SETTINGS AND RECOMMENDATIONS
9.2.2.2.1 UA6 RAN MODEL
All below parameters are xCEM specific (i.e. not used by iCEM).
BTSEquipment

RNC

BTSCell

012

RadioAccessService

EdchConf

00

EdchRncConf 00

pMinDlEDCH
pMaxDlEDCH
eagchPowerControlModeXcem
eagchPowerOffset
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset

00

eagchPowerControlActivated

parameter : same or similar parameter


already present in UA5.1
parameter : new parameter from UA6
Object :
new object from UA6

Remark: powerOffsetERGCHServingSHO
parameter is also introduced in UA6 RAN Model
(under EdchConf). However, this parameter is
ignored by the system.

9.2.2.2.2 PARAMETERS
eagchPowerControlActivated: Flag enabling Power Control for all E-DCH DL
channels (E-AGCH, E-HICH and E-RGCH), at RNC level.
Parameter

eagchPowerControlActivated

Object

EdchRncConf

Granularity

RNC

Range & Unit

Boolean {False, True}, N/A

User & Class

Customer, 3

Value

True
eagchPowerControlModeXcem: Flag enabling Power Control for all E-DCH DL
channels, at cell level.

Parameter

eagchPowerControlModeXcem

Object

EdchConf

Granularity

BTSCell

Range & Unit

Boolean {Fixed, Dynamic}, N/A

User & Class

Customer, 3

Value

Dynamic

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 107/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


ehichErrorProbability: Target E-HICH error rate in E-HICH Outer-Loop correction
mechanism.
Parameter

ehichErrorProbability

Object

EdchConf

Granularity

BTSCell

Range & Unit

Integer [1 255], 0.1%

User & Class

Customer, 3

Value

10 (corresponds to 1%)
minPowerCorrection: In E-HICH Outer-Loop correction mechanism, maximum
correction that can be applied to E-DCH DL channels base power PE-DCH (k).
B

Parameter

minPowerCorrection

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

0.0

maxPowerCorrection: In E-HICH Outer-Loop correction mechanism, minimum


correction that can be applied to E-DCH DL channels base power PE-DCH (k).
B

Parameter

maxPowerCorrection

Object

EdchConf

Granularity

BTSCell

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

0.0
Remarks:
U

Current recommendation is to disable E-HICH Outer-Loop correction mechanism


by setting minPowerCorrection = maxPowerCorrection.

nonServingEHICHPowerOffset: Please refer to [Vol.6], section 3.3.2.2 of this


document.
X

commonERGCHPowerOffset: Please refer to [Vol.6], section 3.3.2.2 of this


document.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 108/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


9.2.2.3 OTHER RECOMMENDATIONS

Granularity for parameter settings:


All parameters are settable per cell
(except eagchPowerControlActivated i.e. feature activation flag at RNC).

UA6 33481 is fully tunable per cell.

Board-specific parameters:
All parameters above-listed in Parameters setting are xCEM-specific.
Remark on E-HICH signature power for iCEM:
For both the E-DCH serving RL and non-serving RLs (of serving NodeB and non-serving NodeB(s) ),
E-HICH signature power is fixed to a unique value by ehichPowerSignature under EdchConf.
Remark on E-RGCH signature power for iCEM:
For E-DCH non-serving RLs of non-serving NodeB(s), E-RGCH signature power is fixed to a unique
value by ergchPowerSignature under EdchConf.

Remark on E-HICH and E-RGCH power for the serving NodeB:


It is not possible to set E-HICH (E-RGCH) power to a given value (e.g. 0) for E-DCH
non-serving RLs of the serving NodeB.
Indeed, for a given user, E-HICH (E-RGCH) signature for E-DCH non-serving RLs of serving NodeB is
transmitted with the same power as E-HICH (E-RGCH) signature for the E-DCH serving RL.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 109/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

10 SRB ON HSPA DURING CALL


10.1 E-DCH ONLY CONFIGURATION
The objective of the feature is to achieve higher bit-rate in the uplink for E-DCH cat 6
UE using PS RAB only. 3GPP specifications mandate that in order to use
2 SF2 + 2 SF4 in uplink, there should be no DPDCH used simultaneously. Therefore,
SRB shall be mapped to E-DCH so that the UE could reach up to 5 Mbps in the uplink.
Note: It is mandatory that the 2SF2+2SF4 configuration is only possible when the max
number of DPDCH is 0, i.e. SRB must be configured on E-DCH (UL DPDCH not
present) and not on DCH.
Furthermore, to reach this bit-rate, 2 ms TTI on E-DCH is necessary. SRB will be
mapped on E-DCH only if the 2 ms TTI is usable.
This feature is only supported by xCEM.

[UCU-III]
It will be possible to extend the SRB on E-DCH as soon as all TRB are mapped on EDCH in the uplink, whatever the minSF and whatever the TTI value of the E-DCH
configuration.. OneBTS does not support 2ms TTI. UCU-III supports up to category 5,
on 10 ms TTI only. It does not support category 6 (it would be managed like a
category 4 on 10ms TTI).

DL

UL

L3

SRB

TRB

L2 - Trsp

DCH-FP

HS-DSCH FP

E-DCH FP E-DCH FP

HS-DPCCH

E-DPCCH

E-DPDCH

L1

DPCCH/DPDCH HS-SCCH

HS-PDSCH

E-HICH DPCCH

SRB

TRB

In order to achieve right DL inner loop power control algorithm, the SRB DCH is used.
In order to achieve right UL inner loop power control algorithm, UL DPCCH is used.
In order to achieve right UL outer loop power control, feature PM 34249 EUL Capacity
Optimized HARQ Operation is needed. It may be not sufficient as there is no more 1x0
transport format in the Uplink.
In order to achieve right DL outer loop power control, 1x0 shall be used on the SRB
DPDCH when there is no data to be sent from SRB.
Restriction:
SRB over E-DCH is not supported during E-DCH FP over Iur, a fallback on DCH is applied in uplink for
SRB, in case the drift RNC controls the primary cell (mobile is considered as a category 4).
E-DCH FP over Iur is introduced by the feature 30744 allowing the SRNC to manage RABs mapped
over E-DCH in UL when a Drift DRNC controls the Primary Cell, thus allowing inter-RNC mobility for
E-DCH.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 110/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


PARAMETERS
First, the feature flag activation.
Parameter
Range &
Unit
User
Class
Value

isSrbOnEdchAllowedWhenTrbOnEdch
TRUE/FALSE None

Object

RadioAccessService

Customer
3-a2
FALSE

Granularity

RNC

Parameter
Range &
Unit
User
Class
Value

srbQos.srbSpi
Integer [0..15]

Object

RadioAccessService

Customer
3-a2
15

Granularity

RNC

isSrbOnEdchAllowedWhenTrbOnEdch

Enable the possibility to map SRB on E-DCH in the UL for Cat 6 UE, while the call is
handling RAB(s) over E-DCH

srbQos.srbSpi

SPI used for SRB on E-DCH during a call


Reserved0 bit 0, bit 1, bit 2
Three activation flags are added to the model, in the radio access service:

Reserved0 bit 0: reserved0 Bit 0: SRB on E-DCH for all E-DCH


categories
o

Bit 0 = 0: E-DCH cat 6 UE only

Bit 0 = 1: All E-DCH categories

Reserved0 bit 1: reserved0 Bit 1: SRB on E-DCH for all NodeB minSF
o

Bit 1 = 0: 2 SF2 + 2 SF4 minSF only.

Bit 1 = 1: All NodeB minSF

Reserved0 bit 2 : reserved0 Bit 2: SRB on E-DCH for all E-DCH TTI
o

Bit 2 = 0: 2 ms TTI only and 2 ms supported on NodeB

Bit 2 = 1: 2 ms and 10 ms allowed

Parameter
Range & Unit

Reserved0 bit 0
Bit: 0 or 1 Kind of Boolean

Object

RadioAccessService

User
Class
Value

Customer
3-a2
0

Granularity

RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 111/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Parameter
Range & Unit

Reserved0 bit 1
Bit: 0 or 1 Kind of Boolean

Object

RadioAccessService

User
Class
Value

Customer
3-a2
0

Granularity

RNC

Parameter
Range & Unit

Reserved0 bit 2
Bit: 0 or 1 Kind of Boolean

Object

RadioAccessService

User
Class
Value

Customer
3-a2
0

Granularity

RNC

The following datafill rules are presented:

Rule:
As a reminder, a cell is a 2 ms E-DCH TTI capable if:

FDDCellEdchTti2msec flag is set to TRUE by the operator

The NodeB has reported a NBAP Audit Response message or a NBAP


Resource Status Indication including the support of the 2 ms E-DCH TTI
capability.

The 34.108 [R09] E-DCH configuration is selected, chapter 6.10.2.4.6.2.1.1.1.2, MACd flow#2 parameters for UL: [max bit rate depending on UE category and TTI] SRBs
for E-DCH
X

Higher layer
RLC

MAC

Layer 1

NOTE:

RAB/Signaling RB
SRB #1
SRB #2
SRB #3
Logical channel type
DCCH
DCCH
DCCH
RLC mode
UM
AM
AM
Payload sizes, bit
136
128
128
Max data rate, bps
Depends on UE category and TTI
AMD PDU header, bit
8
16
16
MAC-es multiplexing
4 logical channel multiplexing
MAC-d PDU size, bit
144
MAC-e/es header fixed 18
part, bit
TrCH type
E-DCH
TTI
10 ms (alt. 2 ms) (NOTE)
Coding type
TC
CRC, bit
24
The support of 2 ms TTI depends on the UE category.
The SRB will be mapped on E-DCH using the non-schedule traffic.

SRB #4
DCCH
AM
128
16

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 112/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

The following system restrictions are presented:

Restriction:
Nevertheless, facing iBTS limitation on iCEM, parameter reserved0 Bit 2 shall never be set to 1 if
there at least a iCEM on a NodeB where E-DCH is activated.
Finally, as the oneBTS does not support 2 ms TTI for E-DCH, every reference to the 2 ms TTI is not
applicable for some customers.

The engineering recommendations on parameter value are presented as the


following:

Engineering Recommendation: reserved0 Bit 0,1,2 typical settings


Hereafter are the typical values to be used on the different customers to support high bit-rate in UL:
Global Market
Model Configuration
reserved0 Bit 0
reserved0 Bit 1
reserved0 Bit 2

Value
0
0
0

Model Configuration
reserved0 Bit 0
reserved0 Bit 1
reserved0 Bit 2

Meaning
Cat 6 UE only
2 SF2 + 2 SF4 minSF only
2 ms TTI only and 2 ms supported on NodeB
US Market
Value
Meaning
1
All UE Categories
1
Whatever minSF
1
For all NodeB; For all TTI

Remark: Refer to section 5.6 of this volume for further details regarding the reserved0 parameter.
U

Finally, as a reminder, the following are the usual settings that are required for a smooth operation of
the feature:

The parameter enabledForRabMatching located under


RNC/RadioAccessService/UlUserService/PS_EDCHxSRB_EDCH must be set to
TRUE to ensure that the RAB matching algorithm would select SRB over E-DCH
when the call is eligible for such configuration.

The parameter isAlwaysOnAllowed located under


RNC/RadioAccessService/UlUserService/PS_EDCHxSRB_EDCH must be set to
TRUE to ensure a good functioning of the Always-On algorithm for calls with SRB
over E-DCH.

10.2 RAB ASSIGNMENT


Some transitions shall be considered in the two ways. These are:
RAB addition or RAB release based on RAB assignment:
U

SRB on DCH/DCH <==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 113/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


SRB on FACH ==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH <==> SRB on DCH/DCH + 2 TRB
PS on HSDPA/DCH
SRB on FACH + TRB PS on FACH ==> SRB on DCH/DCH + 2 TRB PS on
HSDPA/DCH
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH <==> SRB on DCH/DCH + TRB
PS on HSDPA/E-DCH + TRB CS on DCH/DCH
RAB setup through incoming relocation:
U

Incoming relocation ==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH

10.3 MOBILITY MANAGEMENT


Upon new primary cell selection, upon E-DCH TTI configuration change, SRB
configuration may be reconfigured from/to E-DCH. It shall be noted that those
transitions may also apply simultaneously with inter-frequency HO.
The transitions shall be considered in the two ways. These are:
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (2 ms) <==> SRB on DCH/DCH +
TRB PS on HSDPA/E-DCH (10 ms) (GM)
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (2 ms) <==> SRB on DCH/DCH +
TRB PS on HSDPA/DCH (GM)
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (2 ms) <==> SRB on DCH/DCH +
TRB PS on DCH/DCH (GM)
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (10 ms) <==> SRB on DCH/DCH
+ TRB PS on HSDPA/DCH (US MARKET)
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (10 ms) <==> SRB on DCH/DCH
+ TRB PS on DCH/DCH (US MARKET)

10.4 RATE ADAPTATION


SRB configurations are not eligible to rate adaptation. E-DCH configurations are only
eligible to Always-On
SRB on E-DCH can be a target configuration when the call is coming from
CELL/URA_PCH or CELL_FACH state:
The transitions shall be considered in the two ways. These are:
SRB on CELL_FACH + TRB on CELL_FACH <==> SRB on DCH/E-DCH + TRB PS
on HSDPA/E-DCH (2 ms) (GM)
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/EDCH (2 ms) (GM)
SRB on CELL_FACH + TRB on CELL_FACH <==> SRB on DCH/E-DCH + TRB PS
on HSDPA/E-DCH (10 ms) (US MARKET)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 114/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/EDCH (10 ms) (US MARKET)

10.5 DEFENSE ON FAILURE


As the decision for SRB over E-DCH is based on the Cell & UE capabilities only, there
are no new specific failure cases that need to be added to the RNC NodeB behavior.
Based on HSPA to DCH fallback feature (PM32602), the fallback scenarios are:
Incoming RAB CAC failure towards E-DCH/HSDPA: DCH fallback.
Intra RNC HHO CAC failure towards E-DCH/HSDPA: DCH fallback.
Intra-frequency mobility CAC failure towards E-DCH/HSDPA: DCH fallback.
Always-on upsize CAC failure towards E-DCH/HSDPA: DCH fallback.
Please refer to HSPA to DCH fallback feature (PM32602, to see what transition is
performed when the DCH fallback is also failed: Iu-PS release or iMCTA algorithm.
There is not fallback from TTI 2 ms to TTI 10 ms foreseen.

Even if the SRB over e-DCH is tagged as an xCEM only feature, there are two
scenarios where the unidirectional DCH must be supported on iCEM and CEM
boards:

Call reconfiguration. This use case happens when the call is already
established on a NodeB that is composed by at least one iCEM (or CEM) and
one xCEM. The DCH SRB part is currently handled by the iCEM (or CEM)
board and the traffic TRB is currently handled by the xCEM. Upon whatever
event, the RNC decides to reconfigure the call with SRB on E-DCH and TRB
on E-DCH & HSDPA. If the reconfiguration on the TRB would not be an issue,
the successful reconfiguration of the SRB requires that the iCEM (or CEM)
does support the unidirectional DCH SRB.

Mobility. This use case happens when the call is already configured with SRB
on E-DCH and when the UE is entering a NodeB containing at least an iCEM
(or CEM). When the RNC will perform a RL setup to extend the DCH active
set, the DCH configuration will be a DL unidirectional DCH for SRB 3.4 kbps
and an UL DPCCH (only).

The mobility use case is the most important one. The RNC has no DCH fallback
procedure on a RL setup failure. Therefore if the NodeB would refuse unidirectional
DCH due to a non supported configuration that will probably end in a call drop. This is
applicable for CEM and iCEM.
The call reconfiguration use case will be covered by the DCH fallback algorithm if the
reconfiguration fails. But as the mix of iCEM (or CEM) with xCEM will occur on site
and as the CCM load balancing may establish the DCH part of the call on a D-BBU on
the iCEM (or CEM), the iCEM (or CEM) shall support the unidirectional DCH in order
to increase the possibility for SRB on E-DCH on the network.
The requirements to support unidirectional DCH on CEM and iCEM are:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 115/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

It is applicable to a DL SRB 3.4 kbps only

RL restore and RL failure messages remain based on SIR only

Reconfiguration of the DCH:


o

13.6 UL/DL ==> 3.4 DL only

3.4 UL/DL <==> 3.4 DL only

UL DPCCH Slot Format remains 0

iCEM or CEM capacity not degraded

On the HSDPA side, the channelization code of the HS-DPCCH will change according
to chapter 4.3.1.2.2 of [R06].
X

Nmax-dpdch
(as defined in subclause 4.2.1)
0
1
2,4,6
3,5
B

Channelisation code chs


B

C ch,256,33
Cch,256,64
Cch,256,1
Cch,256,32
B

PARAMETERS (Modified)
In the MO UlRbSetConf, one value of enum shall be renamed in order to cope with
its actual usage: Value 13 shall be renamed into SRB_ON_HSPA.
Transport characteristic that shall be used for the UlRbSetConf:
Parameter
Range &
Unit
User
Class
Value

UlRbSetConf
cacTransportInfoList[].cacTransportInfoInstanceCharacteristic Object
AMR_12_2(0), AMR_10_2(1), AMR_7_95(2), AMR_7_4(3), AMR_6_7(4), AMR_5_9(5),
AMR_5_15(6), AMR_4_75(7), INTERACTIVE_1ST_THP(8), INTERACTIVE_2ND_THP(9),
INTERACTIVE_3RD_THP(10), INTERACTIVE_THP_UNSPECIFIED(11), BACKGROUND(12),
SRB_ON_HSPA(13), SRB_ON_DCH(14), UNSPECIFIED(15)
Customer
Granularity RNC
3-a2
Refer to PM 34202 & PM 33579

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 116/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

11 COMPRESSED MODE:
[iCEM] [xCEM]
Compressed Mode can be used for E-DCH calls with iBTS.

On E-DCH, compressed frames are obtained by MAC-e adequate scheduling. MAC-e sets restrictions
so that only a sub-set of the allowed TFCs are used in a compressed frame. The maximum number of
bits that will be delivered to the physical layer during the compressed radio frame is then known and a
transmission gap can be generated.
The principle in UE is the following: the Serving Grant calculated at each TTI with the E-AGCH and
ERGCH
commands is scaled down with the following formula
Sg = Sg * (Nc/15) where
- Sg is the Serving Grant,
- Sg the modified Serving Grant and
- Nc the non-DTX slots due to uplink Compressed mode in the 10 ms TTI
Then, the maximum amount of data from the MAC-d flows is quantized to the next smaller supported
E-TFC based on the Sg
The compressed mode is managed as usual on the associated DCH (SF/2 method).
For the E-DCH part, the compressed mode gaps are taken into account by the MAC-e scheduler,
leading to a minimal degradation of throughput (feature 33480 E-DCH Compressed Mode UA05.1):
- The UE is able to transmit on the E-DPDCH during compressed mode but using a different
transport format in order not to transmit during uplink gaps. These frames can be decoded by the
BTS, except if the UE applies a SF/2 format (this can be prevented by using adequate E-TFCI
tables). In case the UE chooses the SF/2 format the Node B will ACK the frame but not decode it.
The purpose of this ACK is to avoid retransmissions (that would not be decoded either) and RLC
will retransmit the lost PDUs.
- The retransmissions of a NACKed frame for which the first transmission was affected by a gap uses
the same format that the initial transmission. The BTS is also able to decode these frames except in
case of SF/2 format.
- The BTS may address the UE on E-AGCH or E-HICH or E-RGCH during downlink gaps. However
due to the fact that we use a TTI of 10ms information are repeated 5 times during the TTI, we can
expect that the UE may be able to decode these information.
Note : in case the UE does not properly apply the right format for compressed frames (non 3GPP
compliant behaviour) the Node B will not be able to decode these frames, leading to NACKs these
frames (and their retransmissions) and RLC retransmissions. In this case, tests showed that there is a
substantial degradation of E-DCH user throughput, but CM and measurements are performed as
usual by the mobile, and mobility is achieved while maintaining the E-DCH call (i.e. no call drop)..]
Handling of NodeBs and UEs with missing compressed mode capability for E-DCH (FRS34167
UA06):

[UCU-III]
In networks with OneBTS the parameter
RadioAccessService.isEdchCmFallbackAllowed must be set to value 'allowedAlways' such that
EDCH calls are reconfigured to uplink DCH if Compressed Mode is needed.
Legacy UEs: Some non-standards conforming UEs do not support compressed mode in combination
with E-DCH. If the UE has indicated in the UE Capability Information that it does not support
compressed mode with E-DCH2 or compressed mode activation for E-DCH fails then a reconfiguration
to uplink DCH is performed and compressed mode is activated with the DCH configuration. The
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 117/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


downlink is kept on HSDPA. The RNC stores the information about the failed compressed mode
activation in the UE context. If compressed mode needs to be activated again at a later time when the
UE is on E-DCH again, then the RNC does not try to activate compressed mode with E-DCH, but
directly reconfigures to DCH and
then activates compressed mode.

[iCEM] [xCEM]
In networks with iBTS the parameter RadioAccessService.isEdchCmFallbackAllowed
should be set to value 'ueDependent' to enable the automatic fallback to DCH. If it is assumed that all
UEs support E-DCH with compressed mode and no fallback to DCH should be triggered for
compressed mode activation then the parameter can be set to value 'never'.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 118/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

12 ONEBTS PARAMETERS
The following tables are listed for parameters that are unique to the UA06 OneBTS
NodeB (USA market), and are under OAM object OneBTSEquipment.

[UCU-III]
eAGCHPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to E-DCH DL channels base power PE DCH(k).
U

Power Control of E-DCH DL channels disabled:


Power offset of E-AGCH relative to CPICH Tx power.
U

Parameter

eAGCHPowerOffset

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-45.0 65.0] step 0.1, dB

User & Class

Customer, 3

Value

10.0
eHICHErrorProbability: Target E-HICH error rate for E-HICH Outer-Loop correction
mechanism.

Parameter

eHICHErrorProbability

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Integer [1 255], 0.1%

User & Class

Customer, 3

Value

10 (corresponds to 1%)
deltaDownServingCellNoHO: If a ACK was sent on E-HICH and the next associated
UL block is a fresh transmission, then the E-HICH was received correctly and the
correction value is decreased by this value.

Parameter

deltaDownServingCellNoHO

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Integer [1 1000], 0.01dB

User & Class

Customer, 3

Value

20 (corresponds to 0.2dB)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 119/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


maxPowerCorrection: Upper bound for power offset of E-HICH signature relative to
E-DCH DL channels base power PE-DCH (k).
B

Remark: Current recommendation is to disable E-HICH Outer-Loop correction


mechanism by setting minPowerCorrection = maxPowerCorrection.
U

Parameter

maxPowerCorrection

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

-3.0
minPowerCorrection: Lower bound for power offset of E-HICH signature relative to
E-DCH DL channels base power PE-DCH (k).
B

Parameter

minPowerCorrection

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

-3.0

powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to EHICH signature power of considered RL.
Remarks:
- For serving NodeB, only dedicated RG commands are used (at a given time, same
command is transmitted on all radio links).
- powerOffsetERGCHServingNoSHO applies to both E-DCH serving RL and E-DCH
non-serving RLs of serving NodeB (NoSHO has no specific meaning).
U

Parameter

powerOffsetERGCHServingNoSHO

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-12.8 12.7] step 0.1, dB

User & Class

Customer, 3

Value

1.5
powerOffsetERGCHServingSHO: This parameter is ignored by the system.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 120/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


pMaxDlEDCH: Upper bound for E-DCH DL channels base power PE DCH(k). Value is
relative to CPICH Tx power.
B

Parameter

pMaxDlEDCH

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-35.0 15.0] step 0.1, dB

User & Class

Customer, 3

Value

6.0

pMinDlEDCH: Lower bound for E-DCH DL channels base power PE DCH(k). Value is
relative to CPICH Tx power.
B

Parameter

pMinDlEDCH

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Range & Unit

Signed [-35.0 15.0] step 0.1, dB

User & Class

Customer, 3

Value

-18.0

edchServiceParameterSet1: This parameter set defines the OAM parameters,


which are valid for the interactive "gold" service class, i.e. with highest priority
Parameter
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value

edchServiceParameterSet1
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
15
serviceMinRate
Integer: {0,1,..,10000}
40 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
300 [kbps]
serviceBFactor
Integer: {0,1,..,30}
7
serviceKFactor
Integer: {0,1,..,30}
7

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 121/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


edchServiceParameterSet2: This parameter set defines the OAM parameters,
which are valid for the interactive "silver" service class, i.e. with medium priority.
Parameter
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value

edchServiceParameterSet2
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
14
serviceMinRate
Integer: {0,1,..,10000}
25 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
200 [kbps]
serviceBFactor
Integer: {0,1,..,30}
10
serviceKFactor
Integer: {0,1,..,30}
7

Object

OneBTSEquipment

Granularity

OneBTSEquipment

edchServiceParameterSet3: This parameter set defines the OAM parameters,


which are valid for the interactive "bronze" service class, i.e. with lowest priority.
Parameter
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value

edchServiceParameterSet3
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
13
serviceMinRate
Integer: {0,1,..,10000}
10 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
14
serviceKFactor
Integer: {0,1,..,30}
7

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 122/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management


edchServiceParameterSet4: This parameter set defines the OAM parameters,
which are valid for the background service class.
Parameter
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value

edchServiceParameterSet4
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
12
serviceMinRate
Integer: {0,1,..,10000}
0 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
15
serviceKFactor
Integer: {0,1,..,30}
7

Object

OneBTSEquipment

Granularity

OneBTSEquipment

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 123/124

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 4 : E-DCH Principle, Scheduling and Resource Management

Z END OF DOCUMENT Y

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 124/124

UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0

HSXPA PARAMETERS USER GUIDE

CALL MANAGEMENT

Alcatel-Lucent Proprietary

V03.10
02/OCT/2009

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

CONTENTS
1

INTRODUCTION............................................................................................................................5
1.1

OBJECT ....................................................................................................................................5

1.2

SCOPE OF THIS DOCUMENT .......................................................................................................5

RELATED DOCUMENTS ..............................................................................................................7


2.1

HPUG VOLUMES ......................................................................................................................7

2.2

REFERENCE DOCUMENTS ..........................................................................................................7

MULTI-CARRIER MANAGEMENT ...............................................................................................9


3.1

OVERVIEW................................................................................................................................9

3.2

RRC TRAFFIC SEGMENTATION ................................................................................................11

3.3

IMCTA ..................................................................................................................................17

HSXPA CAC ................................................................................................................................18


4.1

RAB MATCHING ......................................................................................................................18

4.2

ADMISSION PHASE ..................................................................................................................20

4.2.1
RNC CAC ......................................................................................................................20
4.2.2
Node-B CAC..................................................................................................................36
4.3
HSPA TO DCH FALLBACK .......................................................................................................37
4.3.1
4.3.2
5

FALLBACK MECHANISM:............................................................................................37
PARAMETERS SETTINGS AND RECOMMENDATIONS: ..........................................38

RLC RECONFIGURATION PROCEDURE .................................................................................39


5.1

HSDPA CASE ........................................................................................................................39

5.2

HSUPA CASE ........................................................................................................................41

MULTI-RAB HANDLING .............................................................................................................44


6.1

MULTI-RAB HANDLING ON HSDPA .........................................................................................44

6.1.1
Principles.......................................................................................................................44
6.1.2
Multi-RAB Combination Configuration (HSDPA) ..........................................................45
6.2
MULTI-RAB HANDLING ON HSUPA .........................................................................................48
6.2.1
6.2.2
7

Principles.......................................................................................................................48
Restriction on combination Streaming + HSUPA..........................................................48

CALL SETUP (DATAFLOW).......................................................................................................49


7.1

INITIAL CONNECTION PHASE:....................................................................................................49

7.2

RAB ALLOCATION PHASE: .......................................................................................................50

CALL RELEASE (DATAFLOW)..................................................................................................52


8.1

IU RELEASE CASE ....................................................................................................................52

8.2

RAB RELEASE CASE ...............................................................................................................52

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 1/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


9

RRM ALGORITHMS ....................................................................................................................54


9.1

ALWAYS-ON............................................................................................................................54

9.1.1
Mechanism ....................................................................................................................54
9.1.2
New RRC states............................................................................................................54
9.1.3
Activation & ModeS.......................................................................................................56
9.1.3.1
Activation .................................................................................................................. 56
9.1.3.2
Modes ....................................................................................................................... 59
9.1.3.3
Multiservice with HSDPA (HSDPA+CS & HSDPA+STR) ........................................ 62
9.1.3.4
Upsize....................................................................................................................... 62
9.1.3.5
Reminder for timer usage ......................................................................................... 63
9.1.4
Parameters Settings and Recommendations ...............................................................65
9.2
IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING .......................................................66
9.3

IRM CAC/IRM PRE-EMPTION INTERWORKING ..........................................................................67

9.4

RB ADAPTATION INTERWORKING .............................................................................................68

9.5

UA6.0 PREEMPTION INTERWORKING .......................................................................................68


9.5.1
9.5.2
9.5.3
9.5.4
9.5.5

Description ....................................................................................................................68
Feature Dependencies..................................................................................................69
CAC Failures .................................................................................................................70
Other backup mechanisms ...........................................................................................71
Activation flags ..............................................................................................................72

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 2/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

TABLES
Table 1: HSDPA RB Configuration and system behavior
Table 2: HSUPA RB Configuration and system behavior
Table 3: Summary of RNC detection regarding RRC Traffic Segmentation
Table 4: RRC Connection Request and suitable layer
Table 5: iMCTA Priority Table
Table 6 : Target Bit Rate
Table 7 : Corrective factor for power reservation
Table 8 : Corrective factor for codes reservation
Table 9: Always-on timer usage (URA/Cell_PCH states not used)
Table 10: Always-on timer usage (URA/Cell_PCH states are used)
TU

UT

TU

UT

TU

TU

8
9
14
15
17
22
23
25
63
64
UT

UT

UT

TU

TU

UT

UT

UT

UT

TU

TU

TU

TU

UT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 3/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

FIGURES
Figure 1: Example of multi-layer structure ...................................................................................................... 10
Figure 2 : HS-DSCH power reservation at call admission ........................................................................... 23
Figure 3 : HS-PDSCH codes reservation at call admission ......................................................................... 26
Figure 4: Example of biggest pool of free SF16 ............................................................................................ 26
Figure 5: HSxPA Call setup / initial connection (Cell_DCH) ........................................................................ 49
Figure 6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 50
Figure 7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 51
Figure 8: Call release (RAB release case) ..................................................................................................... 53
Figure 9: AO state transitions ........................................................................................................................... 56
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none)............ 60
Figure 11: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates = none) ........... 61
Figure 12: Always-on for HSDPA/E-DCH (releaseOnly mode) ................................................................... 62
Figure 13: UA6.0 Pre-emption global view ..................................................................................................... 69
Figure 14: UA6.0 Pre-emption feature dependencies .................................................................................. 70
Figure 15: Pre-emption and other congestion management procedures .................................................. 72
TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

TU

UT

UT

TU

TU

UT

TU

UT

TU

UT

UT

UT

UT

TU

TU

TU

TU

UT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 4/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.

description,

configuration

aspect

and

engineering

1.2 SCOPE OF THIS DOCUMENT


The following features are described in the document:

PM ID

Feature Title

Activation flag

27930

HSDPA Service

N/A

27935

Multi-Carrier
HSDPA
traffic
segmentation

isRedirectionForTrafficSegmen
tation

Always-on
HSDPA

isAlwaysOnAllowed

27942

On

Release

Global
market

US
Market

UA4.2

Yes

Yes

UA4.2

Yes

Yes

UA4.2

Yes

Yes

UA4.2

Yes

Yes

UA5.0

Yes

Yes

UA5.0

Yes

Yes

UA5.0

Yes

Yes

isRedirectionBasedOnEstablis
hmentCause

HSDPA Radio
Bearer
Multi-Services
Handling On
HSUPA
Multi-RAB Handling
on HSDPA

N/A

HSDPA to DCH
fallback

edchToDchFallbackPermission

32602
34168

STSR2+1

N/A

UA5.1

Yes

No

29804

GBR on HSDPA

isGbrOnHsdpaAllowed
(used
only to map Streaming on
HSDPA)

UA6.0

Yes

Yes

33320

New RAB and


combinations for
UA06

UA6.0

Yes

Yes

27945
30741
29797

N/A

isMultiRabOnHsdpaAllowed

edchToDchFallbackSteps

N/A

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 5/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


RNC:
isHsxpaR99ResourcesSharing
OnCellAllowed
U

NodeB:
U

33694

Fair Sharing of
Resources HSDPA vs DCH

[iCEM] [xCEM]
BTSEquipment::hsdpaCodeTre
eManagementActivation

UA6.0

Yes

Yes

UA6.0

No

Yes

UA6.0

Yes

Yes

[UCU-III]
OneBTSEquipment::hsdpaCod
eTreeManagementActivation
isThreeRabAllowed
isMpdpExtendedRabCombsAll
owed
34170

3 PDP Support

mpdpInactivityIuRelease
isMpdpExtendedRabCombsAll
owed

84900

Traffic
Segmentation
between HSPA
Layers by RRC
Redirection

layerPreferredForR99

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 6/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios

2.2 REFERENCE DOCUMENTS


[R01] UMT/DCL/DD/0020

UTRAN Parameters User Guide

[R02] UMT/BTS/INF/016135
Planning Guide

Micro NodeB & 9314 Pico NodeB Feature

[R03] UMT/SYS/DD/018826

Call Admission Control (Radio)

[R04] UMT/IRC/APP/0164

Iub transport Engineering Guide

[R05] UMT/IRC/APP/025147

CEM Capacity Enineering guide

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 7/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


HSxPA only applies to the PS domain meaning that all the CS domain RABs are
supported on dedicated channels (DCH).
From UA6.0, Utran supports the Traffic Classes Streaming, Interactive & Background
on HSDPA. And, the TC Streaming is only served on DCH if the end-to-end latency
requirements are too stringent or if the requested GBR is too high.

RB Configuration

System behavior

All RABs DCH


available in HSDPA
Cell

Supported: no impact coming from HSDPA.

PS I/B on HSDPA

Supported (from UA4.2)

(PS I/B+PS I/B) on


HSDPA

Supported (from UA5.0)

PS Streaming on
HSDPA

Not supported on HSDPA channel is mapped on DCH

Speech on DCH +
PS I/B on HSDPA

Supported (from UA5.0)

CSD/DCH + PS I/B
on HSDPA

Supported (from UA5.0)

Speech on DCH +
(PS+PS) on
HSDPA

Supported (from UA5.0)

(PS I/B+PS
Streaming) on
HSDPA

Supported (from UA6.0)

All RAB combinations existing in this release are available on DCH in an


HSDPA cell (either for a mobile that does not support HSDPA or for a RAB
combination that is not supported on HSDPA)

Table 1: HSDPA RB Configuration and system behavior

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 8/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


RB Configuration

System behavior

All
RABs
DCH
available in HSUPA
Cell

Supported: no impact coming from HSDPA. All RAB combinations existing in


this release are available on DCH in an HSDPA cell (either for a mobile that
does not support HSDPA or for a RAB combination that is not supported on
HSDPA)

PS I/B on HSUPA

Supported

(PS I/B+PS I/B) on


HSDPA

Not supported on HSUPA channel is mapped on DCH

Speech on DCH + PS
I/B on HSUPA
Speech on DCH +
(PS+PS) on HSUPA
CSD/DCH + PS I/B on
HSDPA

Supported

Not supported on HSUPA channel is mapped on DCH


Supported

Table 2: HSUPA RB Configuration and system behavior

3 MULTI-CARRIER MANAGEMENT
3.1 OVERVIEW
To increase the network capacity, operators may deploy multi-layer configurations with
several layers structures:

Multi-layers with equal coverage,

Hot spots micro or pico cells,

Moreover, the introduction of HSUPA since UA5.x networks is also progressive with
hot spots and there is a real need to redirect R99/R4 and HSDPA/HSUPA capable
mobiles (R5, R6) towards the appropriate layer.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 9/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


2G

FDD2

HSUPA

FDD1 HSDPA only

Figure 1: Example of multi-layer structure

Since UA5.x, several features are used in order to distribute the traffic between the
different layers including 2G (GSM, CDMA):

RRC Traffic Segmentation allows redirecting UE at RRC connection


establishment based on their release and/or on the Traffic Class sent to RNC
in RRC Connection Request message. It also allows redirecting UE to the
preffered layer based on type of service.

Hierarchical Cell Structure (HCS), newly introduced in UA5.0, allows


prioritizing cell layers for mobiles in idle mode, Cell_FACH and
URA/Cell_PCH connected modes. The cell reselection algorithm also takes
into account UE speed so that fast moving UEs can be placed in large cells
to avoid excessive cell reselections.

Intelligent Multi-Carrier Traffic Allocation (iMCTA), newly introduced in UA5.0,


eventually allows redirecting UE to another layer when in Cell_DCH
connected mode:
o

In case of coverage gap,

In case of RAB establishment failure,

After Service Type change, Intra-frequency mobility or Always-On


upsize.

For both HCS and iMCTA, please refer to:

UTRAN Parameters User Guide,[R01], in order to have a complete view of


mechanism and setting.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 10/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


3.2 RRC TRAFFIC SEGMENTATION
In case HSxPA is deployed on one frequency layer on top of the R99 layer, it shall be
possible to redirect UEs on the proper frequency layer at call setup depending on its
capabilities and requested establishment cause:

an HSxPA capable UE (R5/R6) camping on a R99 cell is re-directed to the


HSxPA layer;

similarly, a R99/R4 UE camping on a HSxPA cell can be redirected to the R99


layer;

This feature impacts the choice of the target cell and the frequency layer at the call
establishment. The main benefits are to allow HSxPA capable mobiles to benefit from
HSxPA service and to avoid loading the HSxPA layer with R99/R4 mobiles.

In case HSxPA is deployed on both layers (allowing both layers to carry HSPA traffic),
it is possible to prefer some of the HSPA capable layers for R99 traffic:

R99 service originated on non-preffered cell will be redirected to the preferred


cell;

HSxPA service originated on preffered cell will be redirected to the nonpreferred cell;

This algorithm is enhanced in UA6.0, i.e. RNC still makes the difference between
R99/R4 UEs and the other ones (i.e. R5 or R6). But it is now able to find preferred
HSxPA cells for R99 traffic. This enhancement is only applicable if the originating cell
and operational twin cell is enabled for HSDPA (parameter hsdpaActivation).

TRAFFIC SEGMENTATION MECHANISM:


Redirection is only performed by RNC at RRC connection establishment phase based
on the twin-cell configuration (redirection during the call is performed with iMCTA,
cf.[R01]). Such feature can be activated using isRedirectionForTrafficSegmentation
activation flag.
X

Emergency calls are never redirected and are served on the layer selected by the
mobile to limit the probability of call setup failure.

TRAFFIC SEGMENTATION CRITERIA:


Three filtering can be operated in order to execute the redirection on the suitable
layer:

First criterion is based on the Access Stratum Release Indication IE in the


RRC Connection Request message for the identification of the R99/R4
mobiles versus the R5/R6 mobiles.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 11/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

Second optional criterion is based on the Establishment Cause IE in the RRC


Connection Request message to distinguish the calls I/B potentially served on
HSxPA from the others.
This filtering is not necessarily representative of the service setup
during the life time of the RRC connection (for example, UE may
establish RRC connection in order to perform a CS call and then
establish a HSxPA I/B RAB on the same RRC connection).

Third optional criterion is based on preffered layer to distinguish the R99


services potentially served on preferred layer from the others. For all cells with
layerPreferredforR99 = TRUE the RNC shall assume HSPA Cell Capability =
DCH. For all cells with layerPreferredforR99 = FALSE the RNC shall assume
HSPA Cell Capability = HSPA.
o

When to decide if a RRC connection should be redirected to DCH


(R99) layer, function check layerPreferredforR99 for both cells, in
addition to the existing criterias. Only when both twin cells are
configured as HSPA capable, layerPreferredforR99 is checked. If
the current cell does not prefer R99 but the twin cell does, redirect is
selected. Otherwise, the current behavior is unchanged;

When to decide if a RRC connection should be redirected to HSPA


layer, function check layerPreferredforR99 for both cells, in addition
to the existing criterias. Only when both twin cells are configured as
HSPA capable, layerPreferredforR99 is checked. If the current cell
prefers R99 but the twin cell does not, redirect is selected. Otherwise,
the current behavior is unchanged;

TRAFFIC SEGMENTATION PROCEDURE:


When receiving RRC Connection Request message, RNC identifies:

The UE Release via the Access Stratum Release indicator IE, knowing that:
o

R99/R4 mobiles do not support HSxPA configuration;

Sending this IE is not mandatory for R99/R4 mobiles as per 3GPP;

The requested service via the Establishment Cause IE knowing that traffic
class Conversational can not be served on HSxPA layer. This filtering is
optional depending on the setting of the parameter
isRedirectionBasedOnEstablishmentCause;

And check layerPreferredforR99 for both cells; In case both cells have the
same layerPreferredForR99 value (FALSE or TRUE), RNC may try to
disregard layerPreferredForR99;

So, based on the information of Access Stratum Release indicator, Establishment


Cause IE and preferred layer, the RNC can start the redirection.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 12/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


The redirection consists in indicating the target frequency in the RRC Connection
Setup message via the Frequency Info IE, frequency corresponding to the twin cells.
UE will send the RRC Connection Setup Complete towards the twin cell on the right
layer.
Basically, UTRAN determines the target cell and performs RRC establishment on this
cell. At the time of RRC establishment UTRAN has no information if the target cell has
sufficient coverage at the UE location, no measurement information is available and
the redirection is performed in blind mode. Therefore, only co-located cells are
considered for redirection. But also for co-located cells there is a certain risk that the
UE is not able to establish the call on the target cell. In case of failure the UE comes
back to the originating cell and repeat the RRC establishment request; UTRAN then
accepts the repeated request (except CAC failure case).

The following table depicts the decision taken by RNC depending on the value of the
following parameters:

isRedirectionForTrafficSegmentation

isRedirectionBasedOnEstablishmentCause

layerPreferredForR99

Originating cell
hsdpaActivation == TRUE
isRedirectionForTrafficSegmentation == TRUE and

FddCell.

isRedirectionBasedOnEstablishmentCause

InterFreqHHO
parameters

FALSE

TRUE

layerPreferredForR99

layerPreferredForR99

(rnc_com_i100)

FALSE

layerPreferredForR99

Twin cell

hsdpaActivation == TRUE

FALSE

N/A(note)

TRUE

FALSE

TRUE

R99 mobile is
not directed

R99 mobile is not


directed

R5+ mobile is
re-directed to
HSPA twin cell

R5+ mobile with


establishment cause
Streaming,
Interactive,
Background, or
Originating Subscribed
Traffic Call is re-directed
to HSPA cell, and

N/A(note)

R5+ mobile with


establishment cause
other than the above is
not re-directed

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 13/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

TRUE

R99 mobile is
re-directed to
non-HSPA cell

R99 mobile is re-directed


to non-HSPA cell

R5+ mobile is
not directed
N/A(note)

R5+ mobile with


establishment cause
Conversational is
redirected to non-HSPA
cell, and

N/A(note)

R5+ mobile with


establishment cause other
than the above is not redirected.

Table 3: Summary of RNC detection regarding RRC Traffic Segmentation

Hereafter the static mapping between the Establishment cause sent by the mobile in
the RRC Connection Request and the suitable layer pointed by RNC:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 14/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Cause

Suitable layer

Originating Conversational Call

DCH

Originating Streaming Call

DCH or HSxPA*

Originating Interactive Call

HSxPA

Originating Background Call

HSxPA

Originating Subscribed traffic Call

HSxPA

Terminating Conversational Call

DCH

Terminating Streaming Call

DCH or HSxPA*

Terminating Interactive Call

HSxPA

Terminating Background Call


Emergency Call
Inter-RAT cell re-selection

DCH or HSxPA
(i.e. no re-direction)

Registration

HSxPA

Detach

DCH or HSXPA
(i.e. no re-direction)

Call re-establishment CS case


Call re-establishment PS case
Terminating High Priority
Signalling
Terminating Low Priority
Signalling
Terminating cause unknown

Request for access following a request for


service expressed by the mobile user

Request for access, following a paging


indication received by the mobile.

HSxPA
DCH or HSxPA
(i.e. no re-direction)
DCH or HSxPA
(i.e. no re-direction)

Inter-RAT cell change order

Originating High Priority


Signalling
Originating Low Priority
Signalling

Meaning

HSxPA
DCH or HSXPA
(i.e. no re-direction)

Speech emergency mobile originated call


User location registration following an intersystem cell reselection
User location registration following an intersystem cell change commanded by the
source system
Request for user registration, following a
mobile power-on
Request for user de-registration, following a
mobile power-off
Access request for signalling exchange
(e.g. SMS)

Access requested for service reestablishment (due to loss of radio


connection)
DCH or HSXPA
Routing Area update due to "directed
(i.e. no re-direction) signalling call re-establishment" RRC release
DCH or HSXPA
(i.e. no re-direction) Access request for network initiated signalling
exchange (e.g. SMS)
DCH or HSXPA
(i.e. no re-direction)
DCH or HSXPA
This cause is received when no paging cause
(i.e. no re-direction)
is provided from the Core Network.
DCH or HSXPA
(i.e. no re-direction)

Table 4: RRC Connection Request and suitable layer


(*) The RANAP Transfer Delay and the requested GBR (threshold=256kbps**) is
used as criteria for selection of the Transport channel type. Requested GBR criterion
has precedence over Transfer delay criterion.
(**) 386 kbps if feature #33320 New RAB and combinations for UA06 is available &
activated

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 15/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


PARAMETERS:
isRedirectionForTrafficSegmentation: This parameter is used by RRC traffic
segmentation feature, in order to redirect mobiles to the adequate layer according to
the UE release indicator.
Parameter
Range & Unit
User
Class
Value

isRedirectionForTrafficSegmentation
Boolean
{True, False}
Customer
3
TRUE

Object

InterFreqHhoFddCell

Granularity

FDDCell

isRedirectionBasedOnEstablishmentCause: This parameter is used by the traffic


segmentation feature in order to take into the establishment cause if the redirection
algorithm.
Parameter
Range & Unit
User
Class
Value

isRedirectionBasedOnEstablishmentCause
Boolean
{True, False}
Customer
3
TRUE

Object

InterFreqHhoFddCell

Granularity

FDDCell

layerPreferredForR99: Traffic segmentation on RRC establishment can be used to


separate R99 and HSPA traffic onto different layers. For specific network
configurations it can be useful to allow several layers to carry HSPA traffic but still to
prefer some of the HSPA capable layers for R99 traffic. Especially, this is useful if R99
carriers get unavailable e.g. due to automatic carrier switch-off. This parameter is only
applicable if the originating cell and all operational twin cells (parameter twinCellList)
are enabled for HSDPA (parameter hsdpaActivation). In this case this parameter
decides whether the cell should preferably carry R99 or HSPA traffic. TRUE: This cell
is the preferred R99 layer; FALSE: This cell is not the preferred R99 layer, thus it is for
HSPA layer.
Parameter
Range & Unit
User
Class
Value

Object
FddCell
layerPreferredForR99*
Boolean
{True, False}
Customer
Granularity FDDCell
3
Depending on topology (for further details please refer to Volume 7)
*Note: In UA6 parameter reserved1 (bit 0) under FDDCell is used for
layerPreferredForR99. In future releases, layerPreferredForR99 will be taken care
of by feature 75069.

Restriction:
In UA6 RRC Traffic Segmentation does not distinguish HSDPA-capable and HSUPA-capable cells.
Such segmentation is then performed by iMCTA Service after RAB is established.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 16/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


twinCellId indicates the FDD Cell Id of the twin cell which RRC connection may be
redirected to. Twin-cells must be co-localized cells, i.e. they must belong to the same
sector (applicable for STSR2, STSR1+1 and STSR2+1); however, a twin cell can be
absent from the neighborhood of the FDD cell.
Parameter
Range & Unit
User
Class
Value

twinCellId
Decimal
Customer
3
N/A

Object

InterFreqHhoFddCell

Granularity

FDDCell

3.3 IMCTA
iMCTA is an algorithm allowing to allocate traffic across 3G and 2G layers; it is
invoked at the following events:

an alarm condition is reached, so-called iMCTA Alarm

CAC failure at RAB establishment/release, so-called iMCTA CAC

after a successful RAB establishment/release, an Always-On upsize or a


Primary Cell change, to move the call to a more appropriate carrier, so-called
iMCTA Service

Once triggered, iMCTA requests UE to perform either inter-frequency or inter-system


measurements, following the analysis of:

3G and 2G neighborhoods

UE and FDD HSxPA capabilities

The priority for each carrier of the requested service type, through Priority
Table as depicted hereafter:

Priority Table
CS

CS conv.

CS streaming

speech

PS

PS

CS speech +

streaming

I/B

other

FDD1

P2

P1

P1

P1

P2

P2

FDD2

P3

P2

P2

P2

P1

P1

2G

P1

PNA

P3

P3

P3

P3

Table 5: iMCTA Priority Table


iMCTA eventually triggers HHO towards one of the reported cell depending on the
originating and target cell loads, the capabilities of the reported cell

iMCTA Alarm and CAC are not specific to HSxPA as they do not distinguish R99 from
R5/R6 mobiles.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 17/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


HSxPA specific mechanisms are part of iMCTA Service as it fully allows to allocate
traffic on different layers based on mobile and FDD HSxPA-capabilities and through 3
different Priority tables:

Service Priority Table for HSUPA

Service Priority Table for HSDPA

Service Priority General Table (i.e. for R99 mobiles)

4 HSXPA CAC
4.1 RAB MATCHING
Any PS RAB request with Interactive or Background traffic class is matched to the
HSDPA/HSUPA Radio Bearer configuration if the mobile is HSDPA/HSUPA capable
and the primary cell of the active set supports HSDPA/HSUPA.
U

If the HSUPA is not supported in the cell (but the HSDPA is present), the request
is mapped on: UL DCH/DL HSDPA.

If neither HSUPA nor HSDPA are supported in the cell, the request is mapped on:
UL/DL DCH (iRM CAC is performed).

Any PS RAB with Streaming traffic class is matched to the HSDPA RB configuration if:
U

- the mobile is HSDPA capable,


- the primary cell of the active set supports HSDPA
- GBR feature is enabled (isGbrOnHsdpaAllowed = True)
- DL GBR = 0
If the DL GBR is higher than 0, the following conditions has also to be checked:
- transfer delay > transportTypeSelectionTransferDelayThreshold (If
RANAP GBR > 256kbps*, call is always mapped on to HS-DSCH regardless
of CN transfer delay. * 384kbps if feature 33320 New RAB and combinations
for UA06 is enabled. See [R01] for more details)
X

Parameter
Range & Unit

transportTypeSelectionTransferDelayThreshold
Integer [0 65536] seconds

Object

HsdpaRncConf

User
Class
Value

Customer
3
0

Granularity

RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 18/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Engineering Recommendation: transportTypeSelectionTransferDelayThreshold
In UA6.0, this parameter is not useful. That is why the recommendation is to set his value to 0. In this
case, the mapping of a PS Streaming RAB on HSDPA is independent on the CN transfer delay. Then,
the conditions to map a PS Streaming on HSDPA are:
- the mobile is HSDPA capable,
- the primary cell of the active set supports HSDPA
- GBR feature is enabled (isGbrOnHsdpaAllowed = True)

Anyway, if needed, customer has the possibility to base the mapping of Streaming Rab on R99 or HSDSCH according to this parameter.

Parameter
Range &
Unit
User
Class
Value

isGbrOnHsdpaAllowed
Boolean
{True, False}
Customer
3
True (customer dependant)

Object

RadioAccessService

Granularity

RNC

Note that the parameter is only used to allow or not the mapping of PS Streaming Rab
on HS-DSCH. This parameter activates no GBR algorithm. GBR algorithms (introduce
with the feaure 29804 GBR on HSDPA) are enabled by default:
- NodeB: New mac-hs scheduler behavior when the mac-hs GBR IE is
received (higher priority for mac-hs GBR users and computation of the HSDSCH required power)
- RNC: Computation of the mac-hs GBR used by the Fair Sharing feature and
eventually sent to the NodeB

For
PS
Streaming
on
HSDPA
and
PS
I/B
on
HSDPA
when
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = True, the RNC sends to the
NodeB the Mac-hs GBR IE (corresponding to the Target Bit Rate, see 4.2.1 for more
details). At reception of this IE, the mac-hs scheduler activates a new behavior
allowing to
X

schedule with a higher priority the mac-hs GBR users (see [Vol. 3] for more
details).

report from the NodeB to the RNC the power needed to guarantee the mac-hs
GBR (this information is reported through the new NBAP commom measurement
HS-DSCH required power). This HS-DSCH required power will be used by the
RNC to update its power reservation and then will be used by the RNC CAC
algorithms.

Then HSDPA users can be separate in 2 groups:


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 19/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


-

GBR users : HSDPA users for which the scheduler has received a mac-hs GBR IE
(Streaming
users
or
PS
I/B
users
if
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = True)

Non GBR users : HSDPA users for which no mac-hs GBR IE has been sent to the
NodeB

Note that the mac-hs GBR IE is sent only if his value is different from 0 (except in case
of mac-hs GBR reconfiguration: in the case a mac-hs GBR IE = 0 can be sent to the
NodeB in order to update the scheduler view).

4.2 ADMISSION PHASE


As today, this mechanism is triggered by the reception of RAB Assignment Request
and follows the RAB matching process.

In the previous releases, the specific CAC admission process in the RNC for
HSDPA/HSUPA is based on the number of simultaneous authorized users per cell to
limit the degradation of the quality of service. So, iRM CAC is not played for
HSDPA/HSUPA RAB. In UA6.0, thanks to the Fair Sharing feature and GBR feature,
some resources (power and codes) can be reserved for HSDPA in order to guarantee
a certain QoS. In this case, the CAC for HSDPA is no more based on the number of
HSDPA users but based on the available resources (as for DCH).

4.2.1 RNC CAC


The feature Fair Sharing is divided in 2 parts:

One part of the Fair Sharing algorithm is located at RNC level and manages
the HSDPA CAC (this section describes this part of the Fair Sharing
algorithm)

The other part of Fair Sharing algorithm is located at NodeB level and
manages dynamically the HS-PDSCH codes allocation according to the R99
traffic (see [Vol. 3] for more details).
X

For more details, see [R03].


X

In UA6.0, if the Fair Sharing is disabled, the RNC CAC is based on the number of
HSDPA
users
as
in
the
previous
releases
(isHsxpaR99ResourcesSharingOnCellAllowed
=
False):
Any
PS
Interactive/Background RAB request is admitted on HSDPA until the maximum
number of simultaneous users allowed on HSDPA is reached for the cell. Unlike the
iRM CAC performed for the RB mapped on DCH channels, the admission on HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 20/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


does not take into account any other criterion such as RF power. After this, for E-DCH,
any PS I/B RAB request is admitted on E-DCH, provided that the considered cell
supports E-DCH. If HSDPA CAC fails, then both the uplink and the downlink are fallbacked to DCH. In case of RNC CAC failure (maximum number of HSDPA or HSUPA
users), the HSPA to DCH Fallback mechanism is triggered (see Section 4.3).
X

The RNC also performs the admission on the associated DCHs:

Regarding DL SRB admission, CAC is performed as usual

Regarding UL SRB admission, CAC is performed as usual

Regarding UL DCH admission, CAC is performed as usual.

In UA6.0, if Fair Sharing is enabled (isHsxpaR99ResourcesSharingOnCellAllowed


= True), HSDPA RNC CAC may be based on resource consumption (power and
codes) in order to guarantee a given HSDPA QoS to each HSDPA user (ranap GBR
or minBR). In this case (Fair Sharing enabled), HSxPA-to-DCH fallback is not allowed
when CAC occurs for shared resources (DL OVSF codes or DL power)(see [R01] for
more details).
X

The aim of the Fair Sharing feature is to

share resources between R99 users and HSDPA users in a fair way
(resources may be reserved for HSDPA users according to their needs
according to the service to establish and bitrate to achieve)

limit the number of HSDPA users according to the load of the system so that
each one can benefit from a certain level of QoS

allow deploying new services on HSDPA that are no more best effort but
needs a guaranteed QoS (like streaming)

Fair Sharing consists in reserving an amount of resources (power and codes) for each
established HSDPA RAB which is a function of the bitrate needed for the service.
The bitrate uses to compute the resources needed for HSDPA users depends on the
service:I/B services or Streaming service and is called Target Bitrate.

Target Bitrate
U

The target bitrate is equal to :

a mac-hs GBR

or to the parameter minHsDschReservationForCac if the mac-hs GBR is


null

TargetBitRate = Mac-hs GBR or = minHsDschReservationForCac if Mac-hs GBR = 0

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 21/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


This mac-hs GBR is derived from the RANAP GBR for streaming services and from
minBrForHsdpa for I/B services and includes the radio protocols overheads):

GBR is the minimum between the Ranap MBR

and the ranap GBR for PS Streaming

and minBrForHsdpa for PS I/B

PS Streaming on HSDPA : GBR = min(Ranap GBR; Ranap MBR)


PS IB on HSDPA : GBR = min(minBrForHsdpa; Ranap MBR)

the mac-hs GBR includes the radio protocols overheads

Mac-hs GBR = ceil(GBR x HeaderFactor)


With HeaderFactor = (RlcHeaderSize + MacdHeaderSize + RlcPduSize) / RlcPduSize

For minBrForHsdpa = 0 (PS I/B) or RANAP GBR = 0 (PS Streaming), the operator
can choose to reserve a minimum amount of resources defined by the parameter
minHsDschReservationForCac.

Type of service

Target Bit Rate

PS STR RAB with RANAP GBR > 0

min(RANAP GBR; RANAP MBR) + RLC/MAC headers

PS STR RAB with RANAP GBR = 0

minHsDschReservationForCac

PS I/B RAB with minBr > 0

min(minBrForHsdpa, RANAP MBR) + RLC/MAC headers

PS I/B RAB with minBr = 0

minHsDschReservationForCac

Table 6 : Target Bit Rate

Power reservation
U

At call admission, power is reserved for each RB mapped on HS-DSCH. The


reservation is done or updated each time a MAC-d flow is setup, deleted or
reconfigured or on mobility of the serving HS-DSCH cell.

The power to reserve at call admission for this HS-DSCH RAB is derived from the
target bitrate and from the table DlTxPowerEstimation:
power = Pcpich + dlTxPowerEstimation(TargetBitRate)

The parameter dlTxPowerEstimation defines the power to reserve for several


reference bitrates ([64kbps; 128kbps; 256kbps; 384kbps; 1000kbps; 2000kbps;

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 22/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


4000kbps]). If the fair bitrate is between two reference bitrates then the RNC will
perform a linear interpolation between these two values.
And finally, this reserved power can be weighted by a parameter
(initialActivityFactorForIb) in order to take into account the activity factor of the PS
I/B MAC-d flows:
Type of service

Corrective factor

PS STR RAB with


None

RANAP GBR
PS I/B RAB with

initialActivityFactorForIb

minBr > 0
PS I/B RAB with

initialActivityFactorForIb

minBr = 0

Table 7 : Corrective factor for power reservation

HS-DSCH power reservation


Target Bit Rate
dlTxPowerEstimation
Power reserved for PS
Streaming on HSDPA
initialActivityFactorForIb
Power reserved for
PS I/B on HSDPA

Figure 2 : HS-DSCH power reservation at call admission

For non GBR mac-d flows (see 4.1 for definition of non GBR user), the power
reservation will not change until the resources are released.
X

For GBR mac-d flows (see 4.1 for definition of non GBR user), the power is updated
periodically by a self-tuning mechanism (thanks to NBAP HSDSCH Required Power
common measurement).
X

As mentioned in 4.1, the operator has the choice to consider a PS I/B user as a machs GBR user (same behavior as a PS Streaming user). For that, the mac-hs GBR has
to be different from 0 (minBrForHsdpa > 0) and the parameter
isDlPowerSelfTuningForPsIbAllowed has to be set to True. This configuration
allows the scheduler to really try to enforce this mac-hs GBR.
X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 23/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

Then, a GBR mac-d flow corresponds either to a Streaming RAB or to a PS I/B RAB if
a
minBrForHsdpa
has
been
defined
(non
null)
and
isDlPowerSelfTuningForPsIbAllowed is True.

The NBAP HS-DSCH Required Power common measurement is configured by the


CRNC at cell setup when Fair Sharing is activated in the cell and is reported as soon
as a Mac-hs GBR IE is received by the NodeB. The NBAP HS-DSCH Required Power
for GBR measurement is sent by the NodeB to the RNC to inform the RNC that it
needs a certain amount of power to guarantee the GBR of all GBR MAC-d flows of a
given priority level (SPI). This measurement is given per SPI (corresponds to the HSDSCH and HS-SCCH power needed to ensure the GBR of all MAC-d flows having this
SPI). This measurement corresponds to the power needed to satify the Mac-hs GBR
knowing the current throughput and the current power consumption (basically HSDSCH required power = current power consumption / current throughput * Mac-hs
GBR)
U

During the CAC, RNC has to check that the power used by R99 traffic and reserved
HSDPA users (GBR and non-GBR) is lower than the traffic power:
R99 used + HSDPA Required Power (GBR) + HSDPA Reserved Power (non GBR)
< Ptraffic

with Ptraffic = maxTxPower Pccc - Psho Pocns Pedch

Pccc is the power reserved the common control channel taking into account
an activity factor defined by the parameter ActivityFactorCCH (in FDDCell).

Psho is the power reserved for SHO admission.

Pocns is the power reserved for OCNS

Pedch is the power reserved for the DL channels related to E-DCH defined by
the parameter eagchErgchEhichTotalPower.

When Fair Sharing feature is enabled, the iRM power color is based on the self-tuned
R99 power (as in previous releases) and on the self-tuned HSDPA GBR required
power (NBAP measurement) plus the power reserved for HSDPA non-GBR users
(reservation depends on the number of HSDPA users and their minBR). Note that PS
I/B users are also self-tuned (i.e. handled as mac-hs GBR) if
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = TRUE

Codes reservation
U

At call admission, some codes are reserved for each RB mapped on HS-DSCH. The
reservation is done or updated each time a MAC-d flow is setup, deleted or
reconfigured or on mobility of the serving HS-DSCH cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 24/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

As for power, the number of codes to reserve for this HS-DSCH RAB is directly
proportional to the target bitrate:
For ue category 11 and 12:
Nb of SF16 codes = target bitrate / ovsfCodesThroughputQpskUE [1xSF16]
For ue category 1 to 10:
Nb of SF16 codes = target bitrate / ovsfCodesThroughput16QamUE [1xSF16]

Parameters ovsfCodesThroughputQpskUE and ovsfCodesThroughput16QamUE


give the bitrate that can be achieved with one HS-PDSCH code (1xSF16). Two
different parameters have been defined in order to be able to take into account the
gain brought by ue categories using the 16 QAM modulation.

Note that the number of reserved HS-PDSCH codes is rounded globally for all the
HSDPA users. For ex : if ovsfCodesThroughputQpskUE = 200kbps per SF16 and 2
HSDPA users with minBrForHsdpa = 250kbps, the number of reserved HS-PDSCH
codes will be ceil(250/200 + 250/200) = ceil(1.25 + 1.25) = 3 and not
ceil(1.25)+ceil(1.25) = 4.

RNC applies an over-reservation factor :


Type of service

Corrective factor

PS STR RAB with

reservationFactorOnCodesForGbrTraffic

RANAP GBR
PS I/B RAB with

reservationFactorOnCodesForGbrTraffic

minBr > 0

and initialActivityFactor

PS I/B RAB with

initialActivityFactor

minBr = 0

Table 8 : Corrective factor for codes reservation

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 25/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


HS-PDSCH codes reservation
Target Bit Rate
ovsfCodesThroughputXXUe
XX = QPSK or 16QAM

reservationFactorOnCodesForGbrTraffic
Codes reserved for PS
Streaming on HSDPA
initialActivityFactorForIb
Codes reserved for PS I/B
on HSDPA if minBr = 0
reservationFactorOnCodesForGbrTraffic
Codes reserved for PS I/B
on HSDPA if minBr > 0

Figure 3 : HS-PDSCH codes reservation at call admission

During the CAC, the RNC has to check if the number of HS-PDSCH codes reserved is
lower or equal to the biggest pool of SF16 not used by control channels (including
CCC, HS-SCCH, DL HSUPA) and R99:

For an HS-DSCH MAC-d flow the call admission will accept it if :


SizeBiggestSF16Pool - n >= 0
where
- n is the updated n including the incoming HS-DSCH RB (or reconfigured
RB)
- SizeBiggestSF16Pool represents the number of SF16 codes of the biggest
pool of free SF16 (free means not allocated or blocked by DCH, CCH, SCCPCH, HS-SCCH, E-AGCH, E-RGCH/E-HICH) as illustrated below

Figure 4: Example of biggest pool of free SF16

For a DCH, as in UA05, the first free code in the tree will be allocated. However the
RNC will verify that after the allocation of this code the following condition is still
verified:
SizeBiggestSF16Pool - n >= 0
where
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 26/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


- n is the number of SF16 reserved for HSDPA users
- SizeBiggestSF16Pool represents the number of SF16 codes of the biggest
pool of free SF16 after the allocation of this new R99 code
In case of RNC CAC failure, pre-emption can be triggered thanks to the feature 33322
Pre-emption process for DCH and HSDPA/HSUPA (see [R01] for more details)
X

Parameters:
U

maximumNumberOfUsers is used for the HSDPA CAC done by the RNC. The
number of users is per cell. By default this parameter is set to 100 (when the value
is set to 100 the RNC CAC is deactivated, i.e. Node-B performs the Call
Admission Control). Note that even if maximumNumberOfUsers is different from
100, RNC CAC based on the number of HSDPA users is deactivated when Fair
Sharing feature is enabled (isHsxpaR99ResourcesSharingOnCellAllowed =
True). If maximumNumberOfUsers = 0 (not recommended), CAC failure
happens when HSDPA call try to be admitted, leading to trigger a HSDPA to DCH
fallback.

Parameter
Range & Unit

maximumNumberOfUsers
Integer [0 100] N/A

Object

HsdpaCellClass

User
Class
Value

Customer
3
100

Granularity

RNC

Parameter
Range & Unit
User
Class
Value

Parameter
Range & Unit
User
Class
Value

isHsxpaR99ResourcesSharingOnCellAllowed
Boolean {True; False}
Customer
2
True

Object

FDDCell

Granularity

Cell

edchMaxUsersPerCell is an obsolete parameter (under EdchCellClass) that


was created for RNC CAC of E-DCH purpose. RNC CAC of E-DCH has been
abandoned. edchMaxUsersPerCell has no effect.

The limitation of the number of E-DCH users is entirely controlled through the BTS
parameter edchMaxNumberUserEbbu.

edchMaxNumberUserNodeB (under BTSEquipment) as become also obsolete.


Until its removal from OAM model, it is recommended to keep the value of this
parameter to 0.
edchMaxNumberUserEbbu
[0..128]
Customer
3
15

Object

BTSEquipment

Granularity

BTS

Please refer to [R05] for a detailed description of these parameters.


X

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 27/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Rule: Fair Sharing activation
Fair Sharing feature is divided in two algorithms: one algorithm at RNC level managing the HSDPA
CAC and one algorithm at NodeB level managing the osvf codes tree. The two algoritms need to be
activated together in order to have a correct behavior:
Flag(RNC; NodeB) = (True; True) =
(isHsxpaR99ResourcesSharingOnCellAllowed; hsdpaCodeTreeManagementActivation)

From the RNC point of view, when isHsxpaR99ResourcesSharingOnCellAllowed = True:


-

At cell setup, RNC sends to NodeB a PSCR message with the HS-PDSCH codes
configuration that the mac-hs scheduler has to use. This PSCR message considers that 15
HS-PDSCH codes can be used by the mac-hs scheduler

The RNC considers that all the codes not used by R99 or reserved for HSDPA are free

At cell setup, only ccc are reserved (no R99 and HSDPA call)

No other PSCR message is sent after cell setup

From the NodeB point of view, when hsdpaCodeTreeManagementActivation = True:


-

At cell setup, the NodeB receives from the RNC a PSCR message. The number of HS-PDSCH
codes configured according to this PSCR depends on the RNC algorithm (Fair Sharing : 15;
DCTM : 12 with the recommended setting; 5 or 10 if Fair Sharing and DCTM are disabled)

After the cell setup, the number of HS-PDSCH codes available by the scheduler is updated
according the R99 admission or release thanks to the Fair Sharing algorithm

If a new PSCR message is received (in case of DCTM enabled), the scheduler will used this
information to know how many HS-PDSCH codes are available

If (True; True) then the behavior is correct


If (False; False) then the behavior is correct
If (True; False) then the scheduler is not abled to update his view of the ovsf codes tree occupancy
and configured 15 HS-PDSCH codes whatever the R99 calls admitted by the RNC. This leads to a
conflict between R99 codes allocated by the RNC and the HS-PDSCH codes used by the scheduler. In
this case, an increase of the bler can be observed
If (False, True) then the NodeB is able to update his view of the ovsf codes tree occupancy and is able
to manage the reception of PSCR message. This configuration should not lead to any issue but is not
an recommendation configuration (NodeB Fair Sharing algo is not designed to receive several PSCR)

Note that the DCTM feature and RNC Fair Sharing algorithm are totally exclusive

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 28/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range & Unit
User
Class
Value

FDDCell
isDlPowerSelfTuningForPsIbOnHsdpaEnabled Object
Boolean {True; False}
Customer
Granularity
Cell
3
True to consider PS I/B users as a GBR users (power reservation updated
periodically and higher priority of scheduling), False otherwise.

Rule: isDlPowerSelfTuningForPsIbOnHsdpaEnabled
When this flag is set to True, the HSDPA power reserved by the RNC is updated thanks to the NBAP
common measurement HS-DSCH required power reported by the NodeB.
This message informs the RNC of the power needed to guarantee the GBR. Basically, the estimation
of this required power to guarantee the GBR is done by the scheduler knowing the current throughput
and the current HSDPA power consumed by the NodeB.
Considering a constant power consumption for HSDPA (in general, equal to Pcpich + MPO for a single
HSDPA user), the HS-DSCH required power will increase when the current throughput will decrease.
Then, the cell capacity can be reduced when the ue is in bad RF conditions (low throughput).

Parameter
Range &
Unit
User
Class
Value

minBrForHsdpa
[0..2048] kb/s

Object

ThpBasedQos

Customer
3
Default values (see the table below)

Granularity

RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 29/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Engineering Recommendation: minBrForHsdpa
The value of minBrForHsdpa (one value per TC/ARP/THP) depends on the customer strategy.

1- Default recommendation:
U

Traffic Class

ARP

THP

Target Bit Rate

1
Conversational

3
1
Streaming

N/A

2
N/A

3
1

Interactive

minBrForHsdpa = 16 kbps

minBrForHsdpa = 8 kbps

minBrForHsdpa = 8 kbps

minBrForHsdpa = 16 kbps

minBrForHsdpa = 8 kbps

minBrForHsdpa = 8 kbps

minBrForHsdpa = 16 kbps

minBrForHsdpa = 8 kbps

minBrForHsdpa = 8 kbps

1
Background

2
3

minBrForHsdpa = 4 kbps
N/A

minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps

The minBrForHsdpa is also used by the Transport feature Enhanced QoS to manage the transport
congestion. This default recommendation is the recommendation for Enhanced QoS.

2- No resource reservation:
U

The simpler way to reserve nothing for HSDPA should be to set minBrForHsdpa to 0kb/s.
Nevertheless, set 0kb/s can lead to HSDPA call drop in case of transport congestion. That is why the
minimum value for minBrForHsdpa is 4kb/s (to avoid any HSDPA call drop in case of transport
congestion). With 4kb/s, the resources reserved are low. But to really reserve nothing for HSDPA
(best effort), the recommendation is to set :
reservationFactorOnCodesForGbrTraffic = 0%
initialActivityFactorForIb = 0%
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = False

3- Resources reservation with differentiation:


U

Different type of differentiation can be used by the operator according to their strategy:
-

differentiation per OLS (ARP):

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 30/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Traffic Class

ARP

THP

Target Bit Rate

1
Conversational

3
1
Streaming

N/A

2
N/A

3
1

Interactive

minBrForHsdpa = 128 kbps

minBrForHsdpa = 128 kbps

minBrForHsdpa = 128 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 4 kbps

minBrForHsdpa = 4 kbps

3
1
Background

minBrForHsdpa = 4 kbps
minBrForHsdpa = 128 kbps

N/A

minBrForHsdpa = 100 kbps


minBrForHsdpa = 4 kbps

differentiation per Traffic Class:


Traffic Class

ARP

THP

Target Bit Rate

1
Conversational

3
1
Streaming

N/A

2
N/A

3
1

Interactive

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 100 kbps

1
Background

2
3

minBrForHsdpa = 4 kbps
N/A

minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps

differentiation per service (THP):

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 31/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Traffic Class

ARP

THP

Target Bit Rate

1
Conversational

3
1
Streaming

N/A

2
N/A

3
1

Interactive

minBrForHsdpa = 128 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 4 kbps

minBrForHsdpa = 128 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 4 kbps

minBrForHsdpa = 128 kbps

minBrForHsdpa = 100 kbps

minBrForHsdpa = 4 kbps

1
Background

2
3

minBrForHsdpa = 4 kbps
N/A

minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps

Note that the values used in these tables for minBrForHsdpa and especially 128kb/s and 100kb/s are
given as an example. These values can be tuned according to a tradeoff between QoS and capacity.
The value 4kb/s means that very low resources are reserved (as explained, it is not recommended to
set 0kb/s to avoid any HSDPA call drop due to transport congestion management)

Note that if the customer wants to define the minBrForHsdpa per OLS, then OLS has to be enabled
thanks to the parameter activateOls (in RadioAccessService).

Engineering Recommendation: minBrForHsdpa vs EBR


minBrForHsdpa is used by Fair Sharing feature (for RNC CAC) but also by Iub congestion
management algorithm.

From a transport point of view, minBrForHsdpa is the throughput allowed during a transport
congestion state. In order to be in line with the EBR value (EBR is used for transport CAC),
minBrForHsdpa should be lower or equal to EBR (if EBR > 0).

Note that the minBrForHsdpa is respected during Iub congestion regardless of the setting for the
enhancedQualityOfService flag (used to enabled the feature Enhanced QoS. See [R04] for more
details on this feature).
X

The parameter minHsDschReservationForCac is used only when minBrForHsdpa


is null.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 32/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range &
Unit
User
Class
Value

minHsDschReservationForCac
[0..1024] kb/s

Object

HsxpaR99ResourcesSharingCellClass

Customer
3
Max value of minBrForHsdpa

Granularity

RNC

Engineering Recommendation: minHsDschReservationForCac


minHsDschReservationForCac is only used when minBrForHsdpa = 0 or ranap GBR = 0 .
As explained in the Engg recommendation for minBrForHsdpa, minBrForHsdpa has to be different
from 0 in order to avoid any HSDPA call drop in case of transport management. Then, the
minHsDschReservationForCac parameter should not be used, except in case of Iur mobility.

In case of Iur mobility:


-

if isDlPowerSelfTuningForPsIbOnHsdpaEnabled = True, then the mac-hs GBR IE is sent


from the SRNC to the DRNC and the DRNC reserves codes and power according to this machs GBR IE (mac-hs GBR is derived from minBrForHsdpa for PS IB or from RANAP GBR for
PS Streaming)

if isDlPowerSelfTuningForPsIbOnHsdpaEnabled = False, then the mac-hs GBR IE is not


sent from the SRNC to the DRNC and the DRNC reserves codes and power according to the
parameter minHsDschReservationForCac. In this case, in order to avoid QoS degradation
during the Iur mobility, the recommendation is to set minHsDschReservationForCac to the
higher value of minBrForHsdpa.

Parameter
Range &
Unit
User
Class
Value

dlTxPowerEstimation
[1..7][-35.0..15.0] step:0.1dB

Object

HsxpaR99ResourcesSharingCellClass

Customer
Granularity RNC
3
-35.0,-35.0,-35.0,-35.0,-35.0,-35.0,-35.0 (7 values corresponding to [64kbps; 128kbps;
256kbps; 384kbps; 1000kbps; 2000kbps; 4000kbps])

Engineering Recommendation: dlTxPowerEstimation


With the default value (-35dB), the power reserved at call admission is very low.
Anyway, this power will be updated for mac-hs GBR (PS I/B or PS Streaming) users thanks to the HSDSCH required power sent by the NodeB to the RNC.
For non mac-hs GBR (PS I/B only) users, the power reserved is never updated during the call. So, in
order to reserve a more realistic amount of power, dlTxPowerEstimation can be set with the
following values :
dlTxPowerEstimation = [-5, -3, -2, -2, -2, -2, -2]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 33/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range &
Unit
User
Class
Value

ovsfCodesThroughputQpskUe
[1..15][0..14400] kb/s

Parameter
Range &
Unit
User
Class
Value

ovsfCodesThroughput16QamUe
[1..15][0..14400] kb/s

Object

HsxpaR99ResourcesSharingCellClass

Customer
Granularity RNC
3
200,0,0,0,0,0,0,0,0,0,0,0,0,0,0 (the value n gives the bitrate for n SF16 codes. Only first
value is meaningful (1xSF16))
Object

HsxpaR99ResourcesSharingCellClass

Customer
Granularity RNC
3
300,0,0,0,0,0,0,0,0,0,0,0,0,0,0 (the value n gives the bitrate for n SF16 codes. Only first
value is meaningful (1xSF16)).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 34/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Engineering Recommendation: ovsfCodesThroughputxxxUe
The aim of the parameter ovsfCodesThroughput16QamUe is to take into account the statistic gain
brought by the usage of 16-QAM modulation. If this gain has not been estimated, this parameter is set
to the same value as ovsfCodesThroughputQpskUe (meaning that no gain is brought by 16QAM
modulation).
Nevertheless, as ovsfCodesThroughput16QamUe represents a gain brought by 16QAM compared
to QPSK modulation, the following rule has to be check :
ovsfCodesThroughputQpskUe <= ovsfCodesThroughput16QamUe
Thanks to Live results based on the HSDPA cell throughput, the number of HS-PDSCH codes used
and the percentage of 16QAM, the recommendation is to set ovsfCodesThroughput16QamUe to
300kb/s.

Note that if ovsfCodesThroughputxxxUe is equal to 0kb/s per SF16, then a hard-coded value will be
used. This value is hard-coded to 200kb/s per SF16.
For example:
If (ovsfCodesThroughputQpskUe = 0 ; ovsfCodesThroughput16QamUe = 0) then
ThPerSf16 = 200kb/s (hard-coded) for QPSK ue
ThPerSf16 = 200kb/s (hard-coded) for 16Qam ue
If (ovsfCodesThroughputQpskUe = 100 ; ovsfCodesThroughput16QamUe = 0) then
ThPerSf16 = 100kb/s for QPSK ue
ThPerSf16 = 200kb/s (hard-coded) for 16Qam ue
If (ovsfCodesThroughputQpskUe = 0 ; ovsfCodesThroughput16QamUe = 100) then
ThPerSf16 = 200kb/s (hard-coded) for QPSK ue
ThPerSf16 = 100kb/s for 16Qam ue
If (ovsfCodesThroughputQpskUe = 100 ; ovsfCodesThroughput16QamUe = 300) then
ThPerSf16 = 100kb/s for QPSK ue
ThPerSf16 = 300kb/s for 16Qam ue

Parameter
Range &
Unit
User
Class
Value

reservationFactorOnCodesForGbrTraffic
[0..500] %

Object

HsxpaR99ResourcesSharingCellClass

Customer
Granularity RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 35/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range &
Unit
User
Class
Value

initialActivityFactorForIb
[0..100] %

Object

HsxpaR99ResourcesSharingCellClass

Customer
Granularity RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value

Engineering Recommendation: Corrective factors


The corrective factors reservationFactorOnCodesForGbrTraffic and initialActivityFactorForIb are
used to tune the resources reservation:
- If these 2 parameters are set to 0%, no resource is reverved during the RNC CAC.
- For GBR traffics, there is no feedback from Node B regarding the OVSF codes required to
ensure GBR. Then, by setting reservationFactorOnCodesForGbrTraffic with a value higher
than 100%, it is possible to over-estimate the codes reservation.
- For PS IB, the activity factor can be taken into account in order to reduce the codes and
power reservation at call admission (note that for PS IB considered as a MAC-HS GBR, the
power reservation is updated if the flag isDlPowerSelfTuningForPsIbOnHsdpaEnabled is
set to True). This activity fator is derived from the parameter initialActivityFactorForIb (for
streaming, 100% activity is considered)

Up to 15 instances of HsxpaR99ResourcesSharingCellClass can be used. Instance


is selected throught the following pointer:
Parameter
Range & Unit
User
Class
Value

hsxpaR99ResourcesSharingId
N.A.
Customer
3
Pointer

Object

FDDCell

Granularity

Cell

4.2.2 NODE-B CAC


Once the RNC CAC passed, the Node-B is requested for CEM resources allocation
through Radio Link Reconfiguration procedure (see call setup call flow in the section
7)
X

The CEM resources are split between HSDPA and HSUPA:


- HSDPA resources are handled by H-BBU function (see[R05])
X

- HSUPA resources are handled by E-BBU function (see [R05])


X

Each of these modules has some capacity limitations and this capacity is limited
through some sets of parameters (see [R05]).
X

If one of the E-BBU or H-BBU limit is reached, the BTS will send a RL Reconfiguration
Failure (meaning NodeB CAC failure)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 36/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


In case of BTS CAC failure (not enough HSDPA or HSUPA resources), the HSPA to
DCH fallback mechanism is triggered (see section 4.3))
X

Note that the NodeB CAC is unchanged whatever the Fair Sharing activation.

4.3 HSPA TO DCH FALLBACK


HSPA to DCH fallback feature allows establishing or reconfiguring the PS I/B RAB into
DCH in case of HSDPA or HSUPA CAC failure (see section 4.2). The following
HSxPA CAC failure scenarios trigger such a fallback:
X

RAB assignment (to establish or to release)

IU release

Primary Cell change

Inter-RNC UE involved Hard Handover

Alarm Hard Handover

Restriction:
HSPA to DCH fallback at Always-On upsize is not supported. However, fallback at Always-on upsize
is triggered when a second RAB is being established (either CS or PS).

RNC tries and remaps a call establish fall-backed to DCH RAB onto HSDPA or
HSUPA in the following cases:

RAB assignment (to establish or to release a second RAB)

Primary Cell change

Inter-RNC (UE involved or not) HHO

In case HSPA to DCH fallback is disabled, any HSxPA CAC failure leads to an IU-PS
Release procedure (except if backup mechanisms like iMCTA or pre-emption feature
for HSxPA are activated. See [1] Vol14).
Note that HSPA to DCH fallback is only processed when RNC is acting as Serving
RNC. When acting as Drift RNC, any HSPA CAC failure leads to a RNSAP Radio Link
Reconfiguration or Setup Failure.
U

4.3.1 FALLBACK MECHANISM:


In case of HSPA CAC failure, i.e. lack of resources, HSPA to DCH fallback feature
allows reconfiguring UL and/or DL into DCH as if UE was not HSUPA and/or HSDPA
capable, mainly based on failure causes:

Internal to RNC: maximum number of HSDPA or HSUPA users

External to RNC: NBAP or RNSAP failure causes

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 37/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

For the HSxPA CAC failure scenarios mentioned above, when RNC receives NBAP
RadioLinkReconfigurationFailure, DCH fallback is systematically triggered whatever
the NBAP cause (even for NodeB_resource_unavailable). However, when receiving a
cause that gives specific information on UL or DL, RNC directly takes the good
decision, depending on the different permissions presented below.

HSDPA is directly reconfigured into DCH whereas 2 steps can be provisioned for
HSUPA through edchToDchFallbackSteps parameter:

MonoStep to directly reconfigure HSUPA into DCH

MultiStep to try and reconfigure first into HSDPA (and then into DCH in case
of HSDPA CAC failure)

HSDPA or HSUPA to DCH fallbacks can be activated through


hsdpaToDchFallbackPermission or edchToDchFallbackPermission parameters:

NoFallBack: feature is deactivated

RabAssignment: fallback only occurs at RAB assignment procedure and IU


release

Mobility: fallback only occurs at Primary Cell change and HHO

AnyCase corresponds to both RabAssignment and Mobility scenarios

Note: In case of NBAP RadioLinkReconfigurationFailure with cause


NodeB_resource_unavailable, fallback may lead to a second NBAP
RadioLinkReconfigurationFailure when such failure is due to lack of DCH resources
(UL DCH for instance).
In such a case, counter VS.RadioLinkReconfigurationPrepareUnsuccess for screening
RadioLinkReconfigurationFailure will be pegged twice for the same RAB Assignment
procedure.

4.3.2 PARAMETERS SETTINGS AND RECOMMENDATIONS:


hsdpaToDchFallbackPermission: This parameter defines the scope where a
Fallback on DCH is tried when a failure occurred due HSDPA CAC resource shortage.
Parameter
Range & Unit
User
Class
Value

Object
hsdpaToDchFallbackPermission
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
AnyCase

RadioAccessService
RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 38/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


edchToDchFallbackPermission: This parameter defines the scope where a Fallback
on DCH is tried when a failure occurred due HSUPA CAC resource shortage.
Parameter
Range & Unit
User
Class
Value

Object
edchToDchFallbackPermission
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
AnyCase

RadioAccessService
RNC

edchToDchFallbackSteps: This parameter defines whether a fallback on DCH is


Multi-steps (i.e. first fallback attempt to HSDPA and then to DCH) or Mono-step (i.e.
direct fallback to DCH).
Parameter
Range & Unit
User
Class
Value

edchToDchFallbackSteps
Enum
{MonoStep, MultiStep}
Customer
3
MultiStep

Object

RadioAccessService

Granularity

RNC

Engineering Recommendation: hsdpaToDchFallBackPermission and


edchToDchFallBackPermission
Both permissions should be set to AnyCase in order to improve Accessibility and Retainability.

5 RLC RECONFIGURATION PROCEDURE


5.1 HSDPA CASE
It is possible to trigger an RLC reconfiguration after a channel type switching between
DCH and HS-DSCH. This reconfiguration is optional and is useful to tune the RLC
settings (like timers) to the characteristics of the transport channel. It only applies to
the RB corresponding to the PS I/B RAB (so only RLC AM parameters) and RLC PDU
size cannot be changed.

When it is associated to a RB Reconfiguration procedure (due to mobility or AlwaysOn), it is done simultaneously with the transport channel reconfiguration (synchronous
reconfiguration).

When it is associated to a RB addition/deletion (due to RAB assignment/release, with


PS I/B RAB already established and not affected), it cannot be performed
simultaneously with the RB addition/deletion (because it is not possible to reconfigure
the rlc pdu size of an existing RB). It is performed afterwards as a stand-alone
procedure, using a RB Reconfiguration procedure. It is possible to use either a
synchronous or an asynchronous procedure.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 39/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

The summary of RLC Reconfiguration procedure events during HSDPA related


transitions are presented hereafter; however, note that all deltaCfn parameters
below are only used when Enhanced Dynamic Delta CFN feature is disabled, i.e.
when isSrlrDeltaCfnOptimized is set to False (cf. [R01]).
X

dch hs-dsch:
U

case of mobility to or from a non-HSDPA cell:

o
U

RLC Reconfiguration is simultaneously performed with the


synchronized RB Reconfiguration procedure via the parameter
deltaCfnForHsdpaChannelTypeSwitching and is conditioned to the
activation
flag
value
isRLCReconfigurationForChannelTypeSwitching
o

case of addition/release CS/PS when PS HSDPA is on-going:


U

RLC Reconfiguration is performed in a synchronous way after the RB


Reconfiguration to setup the new transport channel information. The
RLC
reconfiguration
is
triggered
via
the
parameter
deltaCfnForHsdpaRLCReconfiguration
(if
deltaCfnForHsdpaRLCReconfiguration=0, the rlc reconfiguration
becomes an a-synchronous procedure).

fach hs-dsch:
U

RLC Reconfiguration is simultaneously performed with the a-synchronized RB


Reconfiguration procedure and is conditioned to the activation flag value
isRLCReconfigurationForChannelTypeSwitching.

hs-dsch hs-dsch:
U

No RLC Reconfiguration because the transport channel keeps unchanged but the
establishment of the radio link on the new primary cell supporting HSDPA needs a
synchronized RB reconfiguration via the parameter deltaCfnForHsdpaMobility.
Restriction:

DL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC
entities so lose all PDUs under transmission).

The RNC RLC Queue Size is never reconfigured. The implication is that if a R5 mobile is
performing the RAB Assignment procedure in non-HSDPA cell, the RLC Queue Size of the
resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is
subsequently transitioned to a HSDPA cell.

Parameters:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 40/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


isRLCReconfigurationForChannelTypeSwitching:
Activation
of
the
RLC
reconfiguration after a channel type switching related to release or addition of another
RAB.
Parameter
Range & Unit
User
Class
Value

isRLCReconfigurationForChannelTypeSwitching
Boolean
{True, False}
Customer
3
True

Object

HsdpaRncConf

Granularity

RNC

deltaCfnForHsdpaMobility: Delta CFN used for HS-DSCH creation when primary


cell is changed.
Parameter
Range & Unit
User
Class
Value

deltaCfnForHsdpaMobility
Integer
[0..255] (x10ms)
Customer r
3
45

Object

HsdpaRncConf

Granularity

RNC

deltaCfnForHsdpaChannelTypeSwitching: Delta CFN used for SRLR due to


channel type switching between DCH and HS-DSCH
Parameter
Range & Unit
User
Class
Value

deltaCfnForHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
80

Object

HsdpaRncConf

Granularity

RNC

deltaCfnForHsdpaRLCReconfiguration: Delta CFN used for RLC reconfiguration


when done in stand-alone (0 means asynchronous reconfiguration).
Parameter
Range & Unit
User
Class
Value

deltaCfnForHsdpaRLCReconfiguration
Integer
[0..255] (x10ms)
Customer
3
0

Object

HsdpaRncConf

Granularity

RNC

5.2 HSUPA CASE


It is possible to trigger an RLC reconfiguration after an uplink channel type switching
between DCH/RACH and E-DCH. This reconfiguration is optional and is useful to tune
the RLC settings (like timers) to the characteristics of the transport channel. It only
applies to the RB corresponding to the PS I/B RAB (so only RLC AM parameters) and
RLC PDU size and RLC queue size cannot be changed.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 41/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


In case a channel type switching is also performed in the downlink (HS-DSCH <->
DCH/FACH) a bi-directional reconfiguration is performed. If there is no channel type
switching in the downlink, then a mono-directional reconfiguration is performed.
In case of E-DCH to RACH transition on Always-On downsize, the RLC parameters
used for the reconfiguration are the ones of the reference DCH radio bearer. This is
needed in case the UE further moves to a primary cell that is not E-DCH capable and
is then upsized (to DCH), it will use RLC parameters suited for this radio bearer (since
no RLC reconfiguration is done on the RACH->DCH uplink reconfiguration). In case
the UE stays with an E-DCH-capable primary cell, RLC will be reconfigured to E-DCH
values on the upsizing from RACH to E-DCH.

When it is associated to a RB Reconfiguration procedure (due to mobility or AlwaysOn), it is done simultaneously with the transport channel reconfiguration (synchronous
reconfiguration).

When it is associated to a RB addition/deletion (due to RAB assignment/release, with


PS I/B RAB already established and not affected), it cannot be performed
simultaneously with the RB addition/deletion because it is not possible to reconfigure
an existing RB. It is performed after as a stand-alone procedure, using a RB
Reconfiguration procedure. It is possible to use either a synchronous or an
asynchronous procedure.

Restriction:

UL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC
entities so lose all PDUs under transmission).

The UE RLC Queue Size is never reconfigured. The implication is that if a R6 mobile is
performing the RAB Assignment procedure in non-E-DCH cell, the RLC Queue Size of the
resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is
subsequently transitioned to a e-DCH cell.

Parameters:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 42/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


isRlcReconfigurationForChannelTypeSwitchingEdch: Activation of the
reconfiguration during a channel type switching between DCH and E-DCH.
Parameter
Range &
Unit
User
Class
Value

isRLCReconfigurationForChannelTypeSwitchingEdch
Boolean
{True, False}
Customer
3
True

RLC

Object

EdchRncConf

Granularity

RNC

deltaCfnForEdchAndHsdpaMobility: Delta CFN used for HSDPA + E-DCH mobility


when primary cell is changed and HSDPA + E-DCH is following the primary cell.
Parameter
Range & Unit
User
Class
Value

deltaCfnForEdchAndHsdpaMobility
Integer
[0..255] (x10ms)
Customer
3
45

Object

EdchRncConf

Granularity

RNC

deltaCfnForEdchChannelTypeSwitching: Delta CFN used for SRLR due to channel


type switching of E-DCH only. (HSDPA configuration is not impacted in this case,
otherwise use deltaCfnForEdchAndHsdpaChannelTypeSwitching)
Parameter
Range & Unit
User
Class
Value

deltaCfnForEdchChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
150

Object

EdchRncConf

Granularity

RNC

deltaCfnForEdchAndHsdpaChannelTypeSwitching: Delta CFN used for SRLR due


to channel type switching of both HSDPA and E-DCH.
Parameter
Range &
Unit
User
Class
Value

deltaCfnForEdchAndHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
80

Object

EdchRncConf

Granularity

RNC

deltaCfnForEdchRlcReconfiguration: Delta CFN used for RLC reconfiguration when


done in stand-alone (0 means asynchronous reconfiguration).
Parameter
Range & Unit
User
Class
Value

deltaCfnForEdchRlcReconfiguration
Integer
[0..255] (x10ms)
Customer
3
150

Object

EdchRncConf

Granularity

RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 43/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Engineering Recommendation: deltaCfnForEdchXXX
Values shown above for deltaCfnForEdchXXX are the default ones. These parameters are not used
when Enhanced Dynamic Delta CFN feature is active (isSrlrDeltaCfnOptimized set to True), which is
the recommended configuration. If the feature is disabled, optimization of these parameters may be
necessary.

6 MULTI-RAB HANDLING
6.1 MULTI-RAB HANDLING ON HSDPA
6.1.1 PRINCIPLES
The feature Multi-Rab Handling on HSDPA allows to handle the following
configurations:

CS speech DCH + PS i/b HSDPA

CSD DCH + PS i/b HSDPA

PS i/b HSDPA + PS i/b HSDPA [+CS speech]

PS i/b HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCU-III only)

PS streaming DCH + PS i/b HSDPA [+CS speech]

PS streaming HSDPA + PS i/b HSDPA [+CS speech]

PS streaming HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCUIII only)

These configurations have to be handled in any transitions cases:

RAB Assign

RAB Release

Incoming Relocation

Mobility HSDPA<-> DCH Cell

Always On Upsize

Etc.

Note:
U

When having a multiple PS RABs over HSDPA, each RAB is mapped to a


separate HS-DSCH MAC-d flow towards the NodeB

Always On Step 2 applies for Multi-RAB HSDPA configurations (no Step 1).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 44/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


6.1.2 MULTI-RAB COMBINATION CONFIGURATION (HSDPA)
Firstly, a main activation flag allows to enable all multi RAB combinations using
HSDPA (PS MUX on HSDPA and PS HSDPA + other):

Parameter
Range &
Unit
User
Class
Value

isMultiRabOnHsdpaAllowed
Boolean
{True, False}
Customer
3
True

Object

RadioAccessService

Granularity

RNC

Note: when the feature is deactivated, then the resulting DlUserService will be
mapped on DCH only.
U

Secondly, an activation flag for 3 PDP contexts (3 x I/B or 2 I/B + 1x Streaming) is


used to restrict the number of PS RABs in the RNC. This will over-ride any settings of
three RABs in HSDPACombinationList described below.
Parameter
Range &
Unit
User
Class
Value

isThreeRabAllowed
Boolean
{True, False}
Customer
3
False for GM, True for US Market

Object

RadioAccessService

Granularity

RNC

DlUserService instances corresponding to Combinations including HSDPA shall be


enabled for the RAB Matching (parameter enabledForRabMatching in
DlUserService)

Rule:
When the multi-RAB on HSDPA is activated, it is recommended to ensure that the related
DlUserService are enabled for RAB Matching:

Speech + HSDPA

CSD + HSDPA

PS Streaming (DCH or HSDPA) + HSDPA

Speech + PS Streaming (DCH or HSDPA) + HSDPA

For each DlUserService, it is required to configure the allowed transitions from 1


single PS HSDSCH to PS + PS HSDPA Configuration:

The only DluserService supporting PS HSDPA Mux are:


o

PS HSDPA only

CS Speech + PS HSDPA

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 45/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

When the DluserService includes 1 PS Streaming on DCH, then PS HSDPA


Mux is not allowed

For each DluserService:

4 HSDPACombinationList must be configured, corresponding to the number


of PS HSDSCH supported by this service:
o

HSDPACombinationList/0 no PS I/B on HSDPA

HSDPACombinationList/1 1 PS I/B on HSDPA supported with


this DluserService

HSDPACombinationList/2 2 PS I/B on HSDPA supported with


this DluserService

HSDPACombinationList/3 3 PS I/B on HSDPA supported with


this DluserService

2
HSDPACombinationEntry
must
be
configured
per
HSDPACombinationList, corresponding to the number of PS Streaming over
HSDPA Supported with this DlUserService:
o

HSDPACombinationEntry/0 no PS Streaming on HSDPA

HSDPACombinationEntry/1 PS Streaming over HSDPA is


supported with this DlUserService

The flag allowed in HSDPACombinationEntry determines if the related configuration


is supported.

US Market (isThreeRabAllowed = True)

Global Market (isThreeRabAllowed = False)

HSDPACombinationEntry

HSDPACombinationList

Allowed

/0

/0

TRUE

TRUE

/0

/1

FALSE

FALSE

/1

/0

FALSE

FALSE

/1

/1

FALSE

FALSE

For DlUserServices

Meaning

All DluserService
without HSDSCH

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 46/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


/2

/0

FALSE

FALSE

/2

/1

FALSE

FALSE

/3

/0

FALSE

FALSE

/3

/1

FALSE

FALSE

/0

/0

FALSE FALSE

CS_64K +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

FALSE FALSE

CS_64K +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

TRUE

CS_64K +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

FALSE FALSE

CS_64K +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

TRUE

CS_64K +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

CS_64K +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

CS_64K +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

FALSE

CS_64K +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

CS_AMR +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

TRUE

TRUE

CS_AMR +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

TRUE

CS_AMR +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

TRUE

TRUE

CS_AMR +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

TRUE

TRUE

CS_AMR +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE

TRUE

CS_AMR +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE

TRUE

CS_AMR +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

FALSE

CS_AMR +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

CS_AMR +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

TRUE

TRUE

CS_AMR +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

TRUE

CS_AMR +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

TRUE

TRUE

CS_AMR +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

TRUE

TRUE

CS_AMR +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

CS_AMR +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

CS_AMR +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

FALSE

CS_AMR +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

CS_AMR + PS_xxK_STR +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

FALSE

CS_AMR + PS_xxK_STR +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

CS_AMR + PS_xxK_STR +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

CS_AMR + PS_xxK_STR +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

CS_AMR + PS_xxK_STR +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

TRUE

CS_64KxPS_HSDSCH
xSRB_3_4K

CS_AMR_NBxPS_HSD
SCHxSRB_3_4K

CS_AMR_WBxPS_HS
DSCHxSRB_3_4K

TRUE
CS_AMR_NBxPS_xxK_
STRxPS_HSDSCHxSR
B_3_4K

TRUE
CS_AMR_WBxPS_xxK
_STRxPS_HSDSCHxS
RB_3_4K

/3

/1

FALSE

FALSE

CS_AMR + PS_xxK_STR +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

PS_xxK_STR +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

FALSE FALSE

PS_xxK_STR +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

PS_xxK_STR +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

FALSE FALSE

PS_xxK_STR +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

FALSE FALSE

PS_xxK_STR +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

PS_xxK_STR +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

PS_xxK_STR +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

PS_xxK_STR +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE FALSE

PS_39_2K_VoIP +

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

FALSE FALSE

PS_39_2K_VoIP +

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

PS_39_2K_VoIP +

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

TRUE
PS_xxK_STRxPS_HSD
SCHxSRB_3_4K

FALSE

TRUE

PS_39_2K_VoIPxPS_H
SDSCHxSRB_3_4K

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 47/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


/1

/1

FALSE FALSE

PS_39_2K_VoIP +

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/2

/0

FALSE FALSE

PS_39_2K_VoIP +

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE FALSE

PS_39_2K_VoIP +

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE FALSE

PS_39_2K_VoIP +

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE FALSE

PS_39_2K_VoIP +

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/0

/0

FALSE

FALSE

0xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/0

/1

TRUE

TRUE

0xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/1

/0

TRUE

TRUE

1xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/1

/1

TRUE

TRUE

1xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

PS_HSDSCHxSRB_3_
4K

/2

/0

TRUE

TRUE

2xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/2

/1

FALSE

TRUE

2xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

/3

/0

FALSE

TRUE

3xPS_HSDSCH_IB +

0xPS_HSDSCH_STR +

SRB_3_4K

/3

/1

FALSE

FALSE

3xPS_HSDSCH_IB +

1xPS_HSDSCH_STR +

SRB_3_4K

6.2 MULTI-RAB HANDLING ON HSUPA


6.2.1 PRINCIPLES
Unlike multi service on HSDPA, there is no activation flag to enable or disable the
multi RAB on HSUPA.
The activation is to be done thought the parameter enabledForRabMatching in
UluserService Object for the following instances:

Speech + E-DCH

CSD + E-DCH

PS Streaming + E-DCH

Speech + PS Streaming + E-DCH

Note: if the related UlUserServcie are not allowed to be used by the RAB Matching,
there is no fallback on DCH, implying RAB Assignment Failure during RB
Setup.
U

6.2.2 RESTRICTION ON COMBINATION STREAMING + HSUPA


UE Radio Access Capabilities specification (TS 25.306) includes UE UL DPCH
Capability with simultaneous E-DCH information, which defines the modification of
transmission capabilities in uplink in terms of DPCH in case an E-DCH is configured
simultaneously.
TS 25.306 indicates that UE can only support a maximum of 64kbps on DCH with a
simultaneous E-DCH configuration Hence the following combination is not supported
(ie. no automatic fallback to 64kbps on DCH) :

PS Streaming UL:128kbps+PS I/B (E-DCH)

Corresponding combination with CS is not supported either.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 48/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


As a consequence, there will be a failure if the RNC attempts to establish the previous
combination.
To workaround this issue, it is possible to fallback all (CS+)PS Streaming + PS I/B
combinations to DCH.
This workaround is not activated by default but there is a flag to activate it,
isMonoDirectionalHsdpaRabAllowed (RadioAccessService). When set to False,
the combinations (CS+)PS Streaming + PS I/B HSDPA are fallbacked on (CS+)PS
Streaming + PS I/B DCH.

7 CALL SETUP (DATAFLOW)


7.1 INITIAL CONNECTION PHASE:
There is nothing specific to HSDPA/HSUPA in this phase.
In the scenario of a mobile being redirected due to the traffic segmentation feature, the
target frequency is indicated in the RRC Connection Setup (frequency info IE) but the
call flow is the same.

UE

Node B

RNC

RRC/ RACH / RRC connection Request

SGSN
The RRC Connection Request message initiated
by the UE contains the establishment cause.

NBAP/ RL Setup Request)


NBAP / RL Setup

RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,


RRC state = CELL_DCH, [frequency info])
RRC/ RACH / RRC Connection Setup Complete

The RRC Connection Setup message contains the


signalling bearers (DCCH) definition. A UTRAN
Radio Network Temporary Identity is also
allocated to the UE.
The target RRC state is set to CELL_DCH by the
RNC
If the mobile is redirected for traffic segmentation
reason then frequency info is included

In addition to the initial NAS message, the Initial Direct Transfer message
also contains the CN domain identity, used by the RNC to route the NAS
message to the relevant CN domain (i.e. CS or PS)
RRC/ RACH / Initial Direct Transfer (Activate PDP Context Request, PS domain)

SCCP/ Connection Request (Initial UE msg (Activate PDP Context Request))


SCCP/ Connection Confirm
The initial UE message is piggybacked in the
SCCP connection resquest

Figure 5: HSxPA Call setup / initial connection (Cell_DCH)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 49/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


7.2 RAB ALLOCATION PHASE:
In this phase, only the NBAP Radio Link Reconfiguration procedure and RRC Radio
Bearer Reconfiguration are modified because of HSDPA. Same dataflow is presented
below for HSUPA (showing RL Reconfiguration modification for E-DCH))

UE

Node B

RNC

SGSN

The UE is authenticated by the SGSN


GMM/ Authentication and Ciphering
GMM/ Authentication and Ciphering
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:

UIA1 for integrity

UEA1 for ciphering


RANAP/ Security Mode Command

RRC/ Security Mode Command

"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete

RANAP/ Security Mode


The Radio Access Bearer assignment procedure

RANAP/ RAB Assignment Request (RAB param, binding Id)

NBAP/ Radio Link Reconfiguration Request (


HS-DSCH Radio Link)

A HS-DSCH Radio Link is created as well as the


associated DCH

NBAP/ Radio Link Reconfiguration Ready (HS-SCCH codes allocated)


FP/ DL Synchronisation (CFN)

The DCH is synchronised

FP/ UL Synchronisation (ToA)


NBAP/ Radio Link Reconfiguration Commit (
CFN)
RRC/ RB Setup (DCCH + DTCH,
HS-DSCH information)

The UE is provided with the new radio link


configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration

RRC/ RB Setup Complete

RANAP/ RAB Assignment Response


The RAB is now established. the mobile is now waiting for end-to-end
service accept.
SM/ Activate PDP Context

Figure 6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 50/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


UE

Node B

RNC

SGSN

The UE is authenticated by the SGSN


GMM/ Authentication and Ciphering
GMM/ Authentication and Ciphering
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:

UIA1 for integrity

UEA1 for ciphering


RANAP/ Security Mode Command (UIAx, UEAy)

RRC/ Security Mode Command

"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete

RANAP/ Security Mode


The Radio Access Bearer assignment procedure

RANAP/ RAB Assignment Request (RAB param, binding Id)


NBAP/ Radio Link Reconfiguration Prepare (
E-DPCH info, E-DCH FDD info, E-DCH mac-d flow to add, Serving
E-DCH RL, E-DCH RL indication=E-DCH, E-DCH Specific Info.)

The Radio Link is reconfigured to add the EDPCH in uplink in the serving cell. (The HSDSCH part is not shown)

NBAP/ Radio Link Reconfiguration Ready (E-DCH FDD info Response, E-DCH FDD DL
Control Channel

NBAP/ Radio Link Reconfiguration Commit (


CFN)
RRC/ RB Setup (E-DCH info, E-RNTI,
CFN)

The UE is provided with the new radio link


configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration

RRC/ RB Setup Complete

RANAP/ RAB Assignment Response


The RAB is now established. the mobile is now waiting for end-to-end
service accept.
SM/ Activate PDP Context

Figure 7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 51/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

8 CALL RELEASE (DATAFLOW)


The call release is initiated either by the mobile or the network through a PDP context
de-activation procedure, or by the RNC (Always-On step 2) through Iu Release
Request.
Depending on the Core Network implementation, the UTRAN is released, either using
an Iu release or a RAB release procedure.

8.1 IU RELEASE CASE


In such a case, the UTRAN resource release is requested by the Core Network
through an Iu Release Command message.
On reception of this message:

the RRC connection is released

the HSDPA and associated HSUPA or UL DCH are released. A Radio Link
Deletion request is sent to each of the BTS being part of the active set,
including the BTS which supports the HS-DSCH.

8.2 RAB RELEASE CASE


In such a case the UTRAN resource release is requested by the Core Network
through an RAB Assignment Request (cause RAB to release) message.
On reception of this message, as illustrated in the following picture:

the RNC attempts a Radio Link Reconfiguration to remove the HSDPA MAC-d
flow from the cell supporting it and

a RB Release removes the HSDPA RB.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 52/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


UE

Node B

RNC

SGSN

GMM/ Deactivate PDP context


GMM/ Deactivate PDP context
The SGSN asks for the release of the corresponding RAB.
In this example, this is the only RAB supported by the mobile
RANAP/ RAB Assignment request (RAB to release)

The radio link is re-configured (only primary cell).


NBAP/ Radio Link Reconfiguration Prepare
(remove HSDPA MAC-d flow)
NBAP/ Radio Link Reconfiguration Ready
NBAP/ Radio Link Reconfiguration Commit
([activation CFN])

RRC/ RB Release (remove HSDPA ; [activation CFN])


RRC/ RB Release Complete
RANAP/ RAB Assignment request response
If isRABRelMgtAllowed is set to "false", the RNC requests for a
global Iu Release.
RANAP/ Iu Release Request
Release of radio bearer and RRC connection

RANAP/ Iu Release Command

RRC/ RRC Connection Release


RRC/ RRC Connection Release Complete
NBAP/ Radio Link Deletion
NBAP/ Radio Link Deletion

All the RLs of the active set are deleted (so


may imply several Node Bs)
RANAP/ Iu Release Complete
SCCP/ Released

Figure 8: Call release (RAB release case)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 53/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

9 RRM ALGORITHMS
9.1 ALWAYS-ON
9.1.1 MECHANISM
The Always-on mechanism applies to HSDPA in DL and E-DCH in UL the same way
as for R99 DCH radio bearers. Only Interactive/Background QoS traffic classes are
eligible to Always-on.
Note: Always-on does not apply if the Signaling Indication parameter of the RAB
Assignment Request associated with the Interactive RAB has been set to signaling.
In this case (example: Video Streaming signaling like RTSP protocol, or VoIP
signaling like SIP protocol), the RB will not be downsized nor released by Always-on.

Always-on allows to optimize radio resource usage for bursty traffic (low activity
factor), but at the same time shall take into account the limitation in terms of
simultaneous connected users on the traffic shared channels:

In DL, HSDPA CAC (see 4.2).

In UL, E-DCH CAC, (see 4.2)

The monitoring of user activity at RLC level (DTCH) for both UL and DL is the same as
for R99. Nevertheless, some new parameters appear. Lets introduce them in the next
chapters.

9.1.2 NEW RRC STATES


In UA05, all RRC states are supported. The two new PCH states are useful for PS
data subscribers who can fallback to one of these states when they are completely
inactive.
The advantage of using the CELL_PCH and URA_PCH states are:

no dedicated physical channel is allocated to the UE, hence the users have no
impact on the cell capacity and only consume RRC context resource.

users benefit from a quicker re-establishment time compared to from idle


mode while the UE battery consumption is equivalent to the idle mode.

Always-on controls a user session by introducing three states (see Figure 9: AO state
transitions):
X

Normal Mode: In this state the session is operating with the original
RB that was allocated at call admission or reconfigured by other PS
Call Management features (RB Adaptation, iRM Scheduling, iRM
Preemption). For a session to be maintained in this state, the user
traffic must remain above a predefined threshold: if it falls and stays

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 54/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


below this threshold during a given period of time, the RAB is
downsized. A session is returned to this state, from Idle mode or
downsized mode, if:

User traffic is resumed (from Idle, CELL_PCH or URA_PCH


states)

User traffic exceeds


CELL_FACH state).

A new call (CS or PS) is established

pre-defined

threshold

(from

Downsized Mode: In this state the session is operating with a


downgraded (from a bandwidth perspective) RB compared to the one
that was originally allocated by the RAB Matching Algorithm. A
session is downgraded to the downsized mode from the normal mode
if user traffic falls and stays below a pre-defined threshold for a given
period. This downsized state contains the following two sub-steps:

AO Step 1, for the case where CELL_FACH is used (PS8 is


no more supported as an Always ON downsized configuration
from UA5 except for multiservices RAB)

AO Step 2, for the case where CELL_PCH or URA_PCH is


used.

Idle Mode: In this state the session has released all its radio
resources and the RRC context, but the PDP context is still
maintained by the Core Network. A session is downgraded to Idle
mode if there has been no user traffic for a given (provisionable)
period of time. This state is also known as AO Step 3 (and was
previously referred to as AO Step 2).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 55/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


The simplified state transitions are shown in Figure 9.
X

Normal mode

AO Step 1

AO Step 2

AO Step 3

Release
(Tinactivity expiry)

Downsizing
(Tdownsize expiry)

URA_PCH
Normal
mode

Idle
mode

CELL_FACH
Upsizing
(Traffic
resuming)

CELL_PCH
Downsized mode

RB R-establishment
(Traffic resuming)
(Tinactivity expiry)

Figure 9: AO state transitions


For more details on Always ON transitions, see UPUG [R01]
X

9.1.3 ACTIVATION & MODES


9.1.3.1 ACTIVATION
Always-on has to be activated for HSDPA and E-DCH. Several parameters are to be
set:

Parameter
Range & Unit

First, Always-on has to be activated on RNC :


isAlwaysOnAllowed
Boolean
{True, False}
Customer
3
False (de-activate the feature)
True (activate the feature)

User
Class
Value

Object

AlwaysOnConf

Granularity

RNC

Then, Always-on has to be activated on user service:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 56/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range & Unit

isAlwaysOnAllowed
Boolean
{True, False}
Customer
3
See table below

User
Class
Value

Object

DlUserService

Granularity

DlUserService

DlUserService
CS_64KxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_64K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_128K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_256K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_HSDSCHxSRB_3_4K
PS_16K_STRxPS_HSDSCHxSRB_3_4K
PS_64K_STRxPS_HSDSCHxSRB_3_4K
PS_128K_STRxPS_HSDSCHxSRB_3_4K
PS_256K_STRxPS_HSDSCHxSRB_3_4K
PS_HSDSCHxSRB_3_4K

Parameter
Range & Unit

isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True
True
True

The suitable Always-on mode has to be set on RB configuration:


Object
isAlwaysOnAllowed
Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
Customer
Granularity
3
See table below

User
Class
Value

DlRbSetConf
PS_HSDSCH_IB
PS_HSDSCH_IB_MUX

DlRbSetConf

DlRbSetConf

isAlwaysOnAllowed
degraded2AlwaysOnOnly
releaseOnly

Rule: Eligibility of RbSetConf to Step 2 mechanism


Multi-service calls are not allowed to the 2 steps Always-on mechanism. Hence for the
PS_HSDSCH_IB_MUX,
the
parameter
isAlwaysOnAllowed
shall
not
be
set
to
degraded2AlwaysOnOnly, but to releaseOnly.

For E-DCH, the corresponding parameters are:


Parameter
Range & Unit
User
Class
Value

UlUserService

isAlwaysOnAllowed
Boolean
{True, False}
Customer
3
See table below

Object

UlUserService

Granularity

UlUserService

isAlwaysOnAllowed

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 57/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


UlUserService
CS_64KxPS_EDCHxSRB_3_4K
CS_AMR_NBxPS_16K_STRxPS_EDCHxSRB_3_4K
CS_AMR_NBxPS_32K_STRxPS_EDCHxSRB_3_4K
CS_AMR_NBxPS_128K_STRxPS_EDCHxSRB_3_4K
CS_AMR_NBxPS_EDCHxSRB_3_4K
PS_16K_STRxPS_EDCHxSRB_3_4K
PS_32K_STRxPS_EDCHxSRB_3_4K
PS_128K_STRxPS_EDCHxSRB_3_4K
PS_EDCHxSRB_3_4K
Parameter
Range & Unit

isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True

Object
isAlwaysOnAllowed
Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
Customer
Granularity
3
See table below

User
Class
Value

UlRbSetConf
PS_EDCH

UlRbSetConf

UlRbSetConf

isAlwaysOnAllowed
degraded2AlwaysOnOnly

Rule: Always-on Step 2 applicability to Streaming RAB


The RNC shall not send RAB Release or Iu Release with cause "User Inactivity" for Streaming RAB.
For that reason, associated PS I/B (DCH or HSDSCH) which are used for the signalling should not be
downsized/released by Always-on.

Parameter
Range & Unit
User
Class
Value

The new RRC states are activated by the operator:


Object
Radio Access Service
PchRrcStates
Enumeration
{none, UraPchEnabled, CellPchEnabled, UraAndCellPchEnabled}
Customer
Granularity
3
UraAndCellPchEnabled

Engineering Recommendation: PchRrcStates


The problematic of URA size (equal to 1 cell in case of CELL_PCH) is similar to RANAP paging,
except that an UTRAN generated paging involves less processing that a CN generated paging since
no RANAP message are sent on Iu. Hence the optimal URA size corresponds to the RNC coverage
(we recommend to avoid splitting LAC/RAC across RNC borders)
If the URA/Cell_PCH states are not activated (PchRrcStates = none), then the Step 2 and Step 3
described above are replaced by only one step (named Step 2 in the previous UA releases).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 58/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


For more details on RRC states configuration see UPUG [R01]
X

9.1.3.2 MODES
The following modes are possible :

Downsize / Release (3 steps) : PchRrcStates none

When Cell/URA_PCH states are activated, Always-on mechanism is using 3 steps


for the downsize part:
o

Step 1: The user is first downsized after a period T1 of low activity (or
inactivity). The associated timer for HSDPA and E-DCH is a new
parameter timerT1ForHsdpaAndEdch for UL E-DCH / DL HSDPA
and existing parameter timerT1ForHsdpa for UL DCH / DL HSDPA

Step 2: The user is further downsized after a period T2 of inactivity.


There is one timer per target downsized state. Hence the new
parameters fachToCellPchTimer and fachToUraPchTimer

Step 3: In URA_PCH or CELL_PCH the user does not have a DTCH


assigned, hence it is not possible to measure activity at RLC/MAC
level. The user is released after a period T3 of inactivity. As the
decision can be taken in either the Cell FACH, URA_PCH or
Cell_PCH state, there is one timer per source state. Hence the
algorithm uses the new parameters cellPchToIdleTimer /
uraPchToIdleTimer.

The transition between the CELL_PCH and the URA_PCH is independent of


Always-on mechanism and relies on signalling volume criteria. After receiving
nbOfCellUpdatesFromCellPchToUraPch cell updates procedures with
cause cell reselection (and before expiration of cellPchToIdleTimer or
upsize procedure), the RNC triggers a state change of the UE to URA_PCH
If the URA/Cell_PCH states are not activated (PchRrcStates = none), then
the Step 2 and Step 3 described above are replaced by only one step (named
Step 2 in the previous releases):
o

Step 2 (old): The user is released after a period T2 of inactivity.


The associated timer for HSDPA and E-DCH is the existing
parameter: timerT2

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 59/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Always-on (degraded2AlwaysOnOnly, PchRrcStates none)
Activity (UL or DL)

Low activity /
Inactivity
Downsize
(step 1)

Downsize
(step 2)

Downsize
(step 3)

Inactivity

HSDPA + UL DCH
HSDPA + E-DCH

CELL FACH

CELL PCH / URA PCH

Downsize timer
Step 1
(timerT1ForHsdpa,
timerT1ForHsdpaAndEDch)

Downsize
timer
Step 2
(fachToCellPchTimer,
fachToUraPchTimer)

Downsize
timer
Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)

Traffic UL/DL
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none)

The downsize condition is the same as for R99.


When downsizing to CELL_FACH, if no resource are available (CAC failure on
FACH), the call is released (as in R99).
When Cell/URA_PCH states are activated and Always-on mode is set to
releaseOnly, there are 2 possibilities:

PS I/B Mux : as they are not supported on CELL_FACH, they


have to be configured in releaseOnly mode (no step 1) but they
will benefit from Cell/URA_PCH states ate expiration of T2 timer;

PS I/B Single : to be able to go through Cell/URA_PCH states, the


PS I/B Single has to be configured in degraded2AlwaysOn mode
(then going through Step1, Step2 and Step3 states). If set to
releaseOnly, the RB will be released at expiration of T2.

Downsize / Release (2 steps) : PchRrcStates = none

When Cell/URA_PCH states are not activated, Always-on mechanism may use 1
or 2 steps for the downsize part (behaviour as before UA5.0)
In this mode, the Always-on feature first downsize the user to Always-on
CELL_FACH and perform the release in a second time.
The timers used are:
o timerT1ForHsdpa in case of HSDPA only
o timerT1ForHsdpaAndEdch in case HSDPA & DCH are both activated.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 60/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management

Always-on (degraded2AlwaysOnOnly, PchRrcStates = none)


Activity (UL or DL)

Low activity /
Inactivity

Downsize
Release
Inactivity

HSDPA + UL DCH
HSDPA + E-DCH

Downsized RB (CELL_FACH)

Downsize
timer
(timerT1ForHsdp
timerT1ForHsdpaAndEDch)

Release timer
(timerT2)

Traffic UL/DL

Figure 11: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates =


none)

Release only (1 step)

In this mode, the Always-on feature directly releases the user after a period T2 of
inactivity. The timers used are:
o timerT2ForHsdpa in case of HSDPA only
o timerT2ForHsdpaAndEdch in case HSDPA & DCH are both activated.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 61/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Always-on (releaseOnly)
Activity (UL or DL)

Low activity

Inactivity
Release

HSDPA + UL DCH
HSDPA + E-DCH
t
Release timer
(timerT2ForHsdpa
timerT2ForHsdpaAndEDch)

Traffic UL/DL

Figure 12: Always-on for HSDPA/E-DCH (releaseOnly mode)

Note : for PS I/B Mux, the releaseOnly mode is mandatory as PS I/B Mux is not
supported on FACH and does not lead to release but there is a direct transition from
CELL_DCH to CELL_PCH or URA_PCH mode (if activated).

9.1.3.3 MULTISERVICE WITH HSDPA (HSDPA+CS & HSDPA+STR)


In case of I/B multi PS services supported in HSDPA (HSDPA PS Mux), after a period
T2 of inactivity, the user is transferred in Cell/URA_PCH state (if activated) and after
an additional T3 of inactivity the call is released. If Cell/URA_PCH states are not
active, the call is released after T2 timer.
In case of HSDPA multi-service (HSDPA+CS or HSDPA+STR), the Always-on Step 1
is not applied (no downsize to CS+PS 8) and the PS I/B is released after T2 (no
downsize to Cell/URA_PCH can be performed due to CS part).
The T2 timer used is: timerT2ForHsdpa (UL
timerT2ForHsdpaAndEdch (UL E-DCH / DL HSDPA)

DCH

DL

HSDPA)

or

9.1.3.4 UPSIZE
For Always-on upsize, the mechanism and the parameters are the same as for R99.
When upsizing to HSDPA or E-DCH and no resource are available (in case of CAC
failure), the call will be released.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 62/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


9.1.3.5 REMINDER FOR TIMER USAGE
In the following tables, the D is used ton indicate degraded2AlwaysOn mode and the
R stands for the releaseOnly mode.

First case when PchRrcStates = none :


PS I/B + SRB
Always-on mode

T1 ( => CELL_FACH)

T2 ( => Idle)

timerT1ForHsdpa
timerT1ForHsdpaAndEDch

timerT2

NA

timerT2ForHsdpa
timerT2ForHsdpaAndEDch

Always-on mode

T1 ( =>CELL_FACH)

T2 ( => Idle)

timerT2ForHsdpa

Always-on mode

T1 ( => CS + PS8)

T2 ( => CS)

NA

timerT2ForHsdpa (1)
timerT2ForHsdpaAndEDch

HSDPA / E-DCH

PS I/B Mux+ SRB

HSDPA / DCH
CS + PS I/B (Mux) + SRB

D
HSDPA / E-DCH

(1)

HSDPA / DCH (Mux)

timerT2ForHsdpa (1)
timerT2ForHsdpaAndEDch

NA

P
P

(1)
P

Table 9: Always-on timer usage (URA/Cell_PCH states not used)


PS Component released, CS remaining.
CS +PS I/B R99 is downsized towards PS 8k and not CELL_FACH
PS I/B (DCH or HSDPA) is released and PS Streaming is remaining (but Always-on is not
applied to the associated PS I/B RAB if the Signaling Indication IE is set to "signaling")
PS I/B (DCH or HSDPA) is released and CS and PS Streaming component are remaining
(but Always-on is not applied to the associated PS I/B RAB if the Signaling Indication IE is
set to "signaling")

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 63/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Second case when x_PCH is activated (PchRrcStates none):
PS I/B + SRB
Always On
Mode

T1 (=> CELL_FACH)

T2 (=> Cell/URA_PCH)

T3 (=> Idle)

timerT1ForHsdpa
fachToCellPchTimer/
timerT1ForHsdpaAndEdch fachToUraPchTimer

cellPchToIdleTimer/
uraPchToIdleTimer

NA

timerT2forHsdpa
timerT2forHsdpaAndEdch

HSDPA / E-DCH
NA

PS I/B Mux+ SRB


Always On
Mode

HSDPA / DCH

T1 (=> CELL_FACH)

T2 (=> Cell/URA_PCH)

tDchPchMpdpForHsdpaAndDc
h (1)

T3 (=> Idle)

uraPchToIdleTimer/
cellPchToIdleTimer

CS + PS I/B (Mux) + SRB


Always On
Mode

T1 (=> CS+PS8)

T2 (=> CS + PS 0)

T3 (=> Idle)

timerT2ForHsdpa
timerT2ForHsdpaAndEDch

uraPchToIdleTimer/
cellPchToIdleTimer

NA

timerT2ForHsdpa
timerT2ForHsdpaAndEDch

timerT2ForHsdpaAndDch

uraPchToIdleTimer/
cellPchToIdleTimer

HSDPA / E-DCH

HSDPA / DCH
(Mux)

Table 10: Always-on timer usage (URA/Cell_PCH states are used)

(1) The PS I/B Multiplexed (on DCH or on HSDSCH) go directly to CELL_PCH or


URA_PCH after T2, without performing downsize step 1, in case PCH states are
enabled.
U

(2) PS Component released, CS remaining


(3) PS I/B (DCH or HSDPA) is released and PS Streaming is remaining (but Alwayson is not applied to the associated PS I/B RAB if the Signaling Indication IE is set to
"signaling"). PS I/B on HSPA is never downsized towards PS I/B 8 kbps.
(4) PS I/B (DCH or HSDPA) is released and CS and PS Streaming component are
remaining (but Always-on is not applied to the associated PS I/B RAB if the Signaling
Indication IE is set to "signaling").

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 64/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Restriction:
The Always-on configuration has to be consistent in UL & DL (same Always-on mode), otherwise the
downsize can not be triggered by the RNC.

9.1.4 PARAMETERS SETTINGS AND RECOMMENDATIONS


The timers timerT1ForHsdpa and timerT1ForHsdpaAndEdch are used when the
Always-on mode on RbSetConf is set to degraded2AlwaysOn.

timerT1ForHsdpa is used for DL HSDPA / UL DCH

timerT1ForHsdpaAndEdch is used fro DL HSDPA / UL E-DCH

Parameter

timerT1ForHsdpa,
timerT1ForHsdpaAndEdch
[10..3600000] (ms)
Customer
3
10000

Range & Unit


User
Class
Value

Object

AlwaysOnTimer

Granularity

OLS

Engineering Recommendation: timerT1ForHsdpa, timerT1ForHsdpaAndEdch


10000 (i.e. 10 s) is the recommended value, to allow relative early transition to CELL_FACH if UE is
inactive. This avoids UE processing waste on HS-SCCH decoding if inactive. Delay for transition from
CELL_FACH to CELL_DCH is fast (< 600 ms) in case the user becomes active again.

The timers fachToCellPchTimer and fachToUraPchTimer are used when the


Always-on mode on RbSetConf is set to degraded2AlwaysOn and PchRrcStates
none.

Parameter
Range & Unit
User
Class
Value

fachToCellPchTimer is used for transition from CELL_FACH to CELL_PCH


when
PchRrcStates
=
CellPchEnabled
or
PchRrcStates
=
UraAndCellPchEnabled

fachToUraPchTimer is used for transition from CELL_FACH to URA_PCH


when PchRrcStates = UraPchEnabled
fachToCellPchTimer,
fachToUraPchTimer
[1..3600] (s)
Customer
3
10

Object

AlwaysOnTimer

Granularity

OLS

The timers timerT2ForHsdpa & timerT2ForHsdpaAndEdch are only used in case


the Always-on mechanism is configured to release the call without going through the
downsized state (releaseOnly for DL HSDPA and UL E-DCH / UL DCH).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 65/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


Parameter
Range & Unit
User
Class
Value

timerT2ForHsdpa,
timerT2ForHsdpaAndEdch
[10..10800000] (ms)
Customer
3
10000

Object

AlwaysOnTimer

Granularity

OLS

Note: The timerT2ForMultiRabHsdpa was used in UA5.x, since Ua6 this timer is replaced by
TimerT2ForHsdpa

The uraPchToIdleTimer and the cellPchToIdleTimer are used for the downsizing
respectively from URA_PCH and CELL_PCH to Idle state.
Parameter
Range & Unit
User
Class
Value

uraPchToIdleTimer,
cellPchToIdleTimer
[1..7200] (min)
Customer
3
60

Object

AlwaysOnTimer

Granularity

OLS

Engineering Recommendation: uraPchToIdleTimer, cellPchToIdleTimer


The recommended value of those timers is highly dependent on the call model (ratio of PS data call
with bursty nature) and is determined from the maximum number of users in X_PCH, which is an RNC
CallP dimensioning constant. Beyond a certain timer duration, we can consider that the subscriber will
not resume its data session anymore, and it is legitim to release the radio resources.

Parameter
Range & Unit
User
Class
Value

nbOfCellUpdatesFromCellPchToUraPch
[1..65535]
Customer
3
1

Object

RadioAccessService

Granularity

RNC

Engineering Recommendation:
As soon as the mobility is detected, the user is moved to URA_PCH. Static users will stay in
CELL_PCH state and will be able to be paged only on their cell (location known at cell level in
CELL_PCH state while location is known at URA level in URA_PCH state).

9.2 IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING


HSxPA links are not eligible to iRM scheduling downgrade/upgrade procedures.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 66/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


9.3 IRM CAC/IRM PRE-EMPTION INTERWORKING
HSDPA links are not eligible to iRM CAC/iRM Preemption (UA4.1 algorithm)
procedures since the throughput adaptation is provided by the MAC-hs scheduler i.e.
the more users multiplexed on HS-DSCH, the less users will be allocated high bit
rates.

However, as it is possible to reserve some power for HSDPA users, this power shall
be consider as consumed in cell color calculation for the HSDPA cells.
In the same way, OVSF codes reserved for HS-PDSCH and HS-SCCH are
considered to be used in the cell color calculation.

In UA6.0, when the feature Fair Sharing is activated, OVSF codes load is computed
following the usual formula:

Code _ Load = 1

1
NumberOfFr eeCodesPerSpreadingF actor n * SF / 16
*
NumberOfSp readingFactors All _ SF
SF
Where n*SF/16 represents the codes that are reserved for HSDPA users at SF level
(n being a number of SF16 codes).

UA5.x-UA6.0 Delta: Code Load


In UA5.0, the OVSF codes load is computed in different ways depending on the activation of the feature
Dynamic Code tree management :

when feature Dynamic Code tree management is deactivated, the formula used is the following:

Code _ Load = 1

NumberOfFreeCodesPerSpreadingFactor
1
*
NumberOfSpreadingFactors All _ SF
SF

Where SF=4, 8, 16, 32, 64, 128 and 256 (NumberOfSpreadingFactors=7).

when the feature Dynamic Code tree management is activated (see [Vol. 3] for details), the code load is
computed according to the following formula:
X

Code _ Load = 1

1
*
NumberOfSpreadingFactors All _ SF

NumberOfFreeCodesPerSpreadingFactor

+ Ceil ( NumberOfSF16CodesAllocatedToHsPdsch SF
16

Ceil (minNumberOfHsPdschCodes SF

16
SF

Where Ceil(x), is the function that rounds to the nearest integer equal or greater than x (because SF/16 can be
fractional).

Then, in UA5.0, there is a fixed number of SF 16 codes reserved for HSDPA (minNumberOfPdschCodes).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 67/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


These codes are considered as used (static) by the iRM Cell Color calculation even if there is no on-going
transmission on HSDPA channel. With the Fair-sharing feature, there is no more codes reserved statically to
HSDPA but there is a full sharing of OVSF codes ressource between R99 and HSDPA, leading to a better
efficiency of the OVSF codes ressource usage. The iRM thresholds may then have to be retuned.

Moreover, the iRM thresholds can be tuned independently from the HSDPA
configuration.
The operator may tune iRM thresholds so that color turns yellow before stealing HSDSCH codes and red before having stolen all HS-DSCH codes.
For more details see UTRAN Parameters Used Guide [R01]
X

On the Iub, the Iub load color takes into account the actual traffic on the link on a
selected set of VCC QoS, so may include or not HSDPA traffic according to operators
provisioning.

9.4 RB ADAPTATION INTERWORKING


HSxPA links are not eligible to RB Adaptation procedures.

Note: the RB Adaptation is applied independently on the UL link in case of UL DCH


with DL HSDPA.
U

9.5 UA6.0 PREEMPTION INTERWORKING


9.5.1 DESCRIPTION
The UA6.0 preemption mechanism is applicable for R99 DCH calls as well as for
HSDPA / E-DCH calls.
The full description of the feature is provided in the UPUG UA6.0, Volume 14 Load
Management.
The preemption is triggered on CAC failures and allows freeing some resources by
downgrading or releasing some current users in order to admit incoming services with
higher priority.
The following figure gives an overview of the concepts used in the UA6.0 algorithm:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

Page 68/74

HSxPA Parameters User Guide


UMT/IRC/APP/016664

03.10 / EN
EXTERNAL

02/Oct/2009
Standard

Volume 5 : Call Management


NodeB DL radio resources not available
NodeB UL radio resources not available

Dedicated

NodeB resources not available


RNC DL code resources not available
RNC DL power resources not available

Eligible CAC
Failures

Shared

1 Steps / 2 Steps

Eligible
Services

R99

Preemption
RAB Assignment

Queuing allowed

RRC connection request

HSUPA

HSDPA

Inter-Frequency intraRNC Radio Link setup

Speech

; Preemption

Video telephony

Capability

CS Streaming

Always-on Upsize
Radio Link Addition

Emergency Call

PS Streaming
Queuing not

Signaling PS Interactive

allowed

PS Interactive

(IMCTA CAC, iMCTA


Alarm)
Incoming relocation does not trigger

; Preemption
Vulnerability
; Priority (*)

PS Background

Eligible
pro