HPUG UA7 Preliminary External V04.05 Jun10

HSxPA Parameters User Guide
Document number: UMT/IRC/APP/016664

Document issue: V04.05
Document status: Preliminary
Date: 04/J un/2010
External Document

UMT/IRC/APP/016664 V04.05
HSXPA PARAMETERS USER GUIDE UA7 04/JUN/2010

Copyright 2010 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.alcatel-
lucent.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. Alcatel-
Lucent assumes no responsibility for inaccuracies contained herein.
Alcatel-Lucent Proprietary


CONTENTS
1 INTRODUCTION
2 HSXPA OVERVIEW
3 HSDPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
4 HSUPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
5 CALL MANAGEMENT
6 MOBILITY
7 DEPLOYMENT SCENARIOS



HSXPA PARAMETERS USER GUIDE
1 INTRODUCTION


HSxPA Parameters User Guide 04.05 / EN 04/Jun/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/23
CONTENTS
1 INTRODUCTION..........................................................................................................................10
1.1 OBJ ECT..................................................................................................................................10
1.2 SCOPE OF THIS DOCUMENT .....................................................................................................11
1.3 AUDIENCE FOR THIS DOCUMENT ..............................................................................................11
1.4 NOMENCLATURE.....................................................................................................................12
1.5 RELATED DOCUMENTS ............................................................................................................14
2 PARAMETERS ORGANIZATION...............................................................................................15
3 ABBREVIATIONS AND DEFINITIONS.......................................................................................17
3.1 ABBREVIATIONS......................................................................................................................17
3.2 DEFINITIONS...........................................................................................................................22

Page 2/23
PUBLICATION HISTORY
05/06/2010
Issue 04.05 / EN,
Updates:
In Volume 3:
Clarification concerning activation of feature 75998 (detailing on feature
support per type of controller board and iso-functional behaviour with
hsdpaWindowsObserveTime set to 100ms)
Inclusion of section 9.6 dedicated to description of feature 97431 HSDPA
OLS Differentiation at Node B Level
Clarification of numberOfHsPdschCodes when Fair sharing or DCTM is
activated and use of activityFactorCcch in OCNS and HSDPA power
calculations
Clarified HS-DSCH required power reports unit of measurement and its flow
In Volume 4:
Note introduced concerning the settings for the parameter
maxEdchCommonChannelPower
In Volume 5:
Restriction note introduced concerning the utilisation of the feature GBR with
the feature HSDPA OLS Differentiation at NodeB Level
Clarification regarding the Mac-hs GBR formula when the HSDPA call
operates in flexible RLC mode.
In Volume 6:
Update on communication for feature 34475; feature 34475 is a globalization
of 33480
Remove Section 8 EXAMPLE OF INTER-FREQUENCY AND INTER-
SYSTEM SCENARIO from HPUG
Update on definition for parameters isHsdpaHhoWithMeasAllowed and
isEdchHhoWithMeasAllowed
Introduction of the parameter isNbapCr1462Supported
Miscellaneous clarifications (terminology) regarding the feature E-DCH
Macro-Diversity
In Volume 7:
Update on iMCTA strategy for different topologies; Speech calls always
rescue to GSM
Update on HSxPA requirements for Load Balancing configurations, including
Fair Sharing reservation on codes recommendation
Page 3/23

26/03/2010
Issue 04.04 / EN,
Updates:
In Volume 1:
History update
In Volume 3:
Clarification concerning the DCTM activation
Update of the "Pre-requisites to reach the maximum throughput with 64QAM"
Removal of the UA6 restriction concerning the setting of
maxHspaPowerOffset (from UA7, other value than 0dB can be used)
Clarification of section Transport Block Size Optimization concerning the
iCem and xCem applicability
Clarification concerning the selection of the UL SIR Target parameters
min/max/initialSirTargetEdch2ms or min/max/initialSirTargetHsdpa or
min/max/initialSirTarget
Update of the server configuration (socket buffer size) for maximum HSDPA
throughput.
Modification of the range and format of rlcRetransmissionBufferInBytes
Clarification of the recommendation for prohibitedStatusTimer in the object
DlRlcAckFlexibleMode (10s)
In Volume 4:
Modification of the recommended value for gRakeActivation
Description of the enablePeriodicSirTargetUpdate for the UL SIR target
update mechanism
Add the recommended value for happyBitDelay on UCU-III.
Clarification for the nHarqRetransTargetSx and
maxNumActiveEdchUsersPerCellForSx: dependant on several factors.
Editorial modification: the recommended values for UL SIR Targets are
removed in order to avoid duplication in both HPUG and UPUG.
In Volume 5:
Remove section 3 MULTI-CARRIER MANAGEMENT; the content of this
section is transferred to UPUG
In Volume 6:
Update concerning the suspend time offset: suspendTimeOffset parameter
is replaced with iubSuspendTimeOffset and iurSuspendTimeOffset
Update of the feature 34475 Compressed Mode in MAC-e: globalization for
US Market of the feature 33480.
Page 4/23
New section added 5 INTER-CARRIER MANAGEMENT FOR HSXPA
In Volume 7:
UCU-III capabilities added
Following sentence deleted Note that HSUPA mobiles working at 900MHz
are not available because there are in UA7 900MHz UE doing HSUPA
New sections added to the document:
FOUR CARRIER DEPLOYMENT SCENARIOS
UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ
TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION
CPICH DESIGN CHOICES
Remove section STSR2 VERSUS STSR 1+1

13/11/2009
Issue 04.03 / EN,
Updates:
In Volume 1:
History update
Clarification of the nomenclature concerning the green frame (green frame
can be used to explain differences between 2 consecutive or non consecutive
releases)
In Volume 2:
New recommended value for cqiPowerOffset
In Volume 3:
New recommended value for serviceBFactor and serviceMaxRate
Update of the recommendation concerning the Pre-requisites to reach the
maximum throughput with 64QAM
Clarification of the HS-DSCH allocated power (factor) in case of 64QAM
Correct the parameter name of HSDPA_packet_error_rate_target (not
HSDPA_packet_error_rate_target)
Clarification concerning the UCUIII parameters (they are tunable parameters)
Clarification concerning the Engineering Recommendation: Maximum
HSDPA throughput
Additional information provided on implemented solution for feature PM75998
Radio Measurement Frequency Increase: Tx Power
Feature 34388 Layer 2 Enhancements. Correction regarding the
recommended value of DlRlcQueueSizeForUeCat, clarification regarding the
rule for maxIubHsDschFrameSize
Page 5/23
In Volume 4:
Introduction of the parameter locFrequencyReuseFactor
Better explanation was introduced concerning the parameters:
edchBLSupervisionTimer, edchBLStepReductionFrameLoss,
edchBLStepIncrease and edchBLIubBandwidth.
Update was done to section 7.1: MAC-E Scheduler Inputs - Measurements
Feature 34249 EUL Capacity Optimized HARQ Operation. The deactivation
of the feature for the iCEM is no longer done through a patch MIB, it is
deactivated by default.
Feature 33481 E-DCH DL control channels Power Control. Correction
regarding the activation flags: the parameter agchPowerControlActivated is
not an activation flag. This parameter is an obsolete parameter.
Feature 34633 E-DCH Mac-e throughput of 10Mbps. Correction regarding
the recommended value for edchMaxThroughputXcem (it shall automatic
instead of 7680).
Feature 34441 2ms TTI on OneBTS. Changes used to describe the
implementation of the 2ms TTI on OneBTS (using the UCU-III) including new
E-TFCI tables and other parameter settings specific to this platform.
In Volume 5:
Clarification of the recommendation concerning
transportTypeSelectionTransferDelayThreshold
Clarification of the minBrForHsdpa recommendation concerning the flag
activateOls
Section 3.2.2 Call Type added a note for UA6-UA7 Delta: Causes no longer
available for redirection
Section 3.2 iMCRA, deleted all references to old UA6 parameters
isRedirectionForTrafficSegmentation and
isRedirectionBasedOnEstablishmentCause and TwinCellId
Section 3.2.9 Parameters, updated definition for TwinCellList to include CRe
00192926 - Twin cell collocated or not update;
In Volume 6:
Update concerning the suspendTimeOffset parameter.
Feature 34475 Compressed Mode in MAC-e including DL E-DCH
transmission
In Volume 7:
Feature 29808 Multi-Carrier PA power pooling. Clarification regarding the
supported radio configurations and the rules regarding CEM pool.

Page 6/23
23/09/2009
Issue 04.02 / EN,
Updates:
In Volume 1:
History update
In Volume 2:
harqNbMaxRetransmissionsXcem parameter changed from class 2 to
class 3
UA5 restrictions removed and 64-QAM HS-DSCH UE category added
In Volume 3:
hsdpaSchedulerWeightingFactorXcem,
hsdpaBlerTargetUpperLimitXcem, hsdpaBlerTargetLowerLimitXcem,
hsdpaUECategoryThroughputWeightingXcem, minimumPowerForHsdpa
and maxHspaPowerOffset parameters changed from class 0 to class 3
Parameter name changed from isRlcReconfigAllowedForR99 in UA6.0 to
is2ndRrcRbReconfNeededForQC7200 in UA7.0.
Feature 34388 Layer 2 Enhancements: Flexible RLC and MAC-ehs: new
recommendation for hsdschSlowStartPeriod (recovery from burst cases),
rlcRetransmissionBufferInKbytes.
New recommendation for eligibleUeCategoryForHighPerformance,
isHighPerformancePduSizeReconfAllowed,
eligibleUeCategoryForSirTargetHsdpa (the Release7 UE Cat 13, 14, 17
and 18 are eligible)
New value concerning the TBS applied from maximum MCS for Category
10 and xCem
Update of the Engineering Recommendation concerning the maximum
HSDPA throughput for UE Cat.10
Update of the parameter settings for maximumTokenGenerationRate and
bucketBufferTimeSapied from maximum MCS for UE category 14
In Volume 4:
edchInitialTBIndex10msTTI, edchInitialTBIndex2msTTI,
edchSpiRelativeWeight, ergchPowerSignature,
eagchErgchEhichTotalPower, eagchPowerOffset,
eagchPowerOffsetEdchTti2ms, ehichPowerOffset,
ehichPowerOffsetEdchTti2ms, ergchPowerOffset and
ergchPowerOffsetEdchTti2ms parameters changed from class 0 to class 3.
Update to the feature 75786 iBTS Local Congestion Control. Change made
on the activation flag parameters name: from edchCMActivation (UA6 and
UA7.0) to edchLocalCongestionControlActivation (UA7.1).
New parameters available, in replacement of spare parameters or for
miscellaneous EDCH enhancements: isSrbOnEdchForAllEdchCategory,
Page 7/23
isSrbOnEdchForAllMinSf, isSrbOnEdchForAllEdchTti,
eligibleUeCategoryForSirTargetEdch2ms, initialSirTargetEdch2ms,
minSirTargetEdch2ms, maxSirTargetEdch2ms,
maxMacePduContentsSizeForNonScheduledModeTti2,
maxMacePduContentsSizeForNonScheduledModeTti10,
isTpcAlgo2ForEdchCat4, isTpcAlgo2ForEdchCat6,
NHarqRetransTarget2msCat4 and NHarqRetransTarget2msCat4
Feature 34633 e-DCH MAC-e Throughput increase to 10Mbps
Feature 34393 Advanced Receiver for High UL Data Rate
New recommendation for maxNrOfErgchEhich
In Volume 5:
Introduction of the feature 34018 - Multiple PS I/B on HSUPA
CR00187250 update related to iMCRA feature;
Update of the ue categories using the parameter
ovsfCodesThroughput16QamUE
In Volume 6:
targetNonServingToTotalEdchPowerRatio parameter changed from class
2 to class 3
Introduction of the new UA7.0/UA7.1 parameter
reserved0/isRnsapCr1357Support under NeighbouringRNC.
Feature 34388 Layer 2 Enhancements: Flexible RLC and MAC-ehs: clarify
the interaction between MAC-ehs and SRNS Relocation UE not involved.
In Volume 7:
isPowerPoolingActivated and paOverbookingRatio parameters changed
from class 0 to class 3

31/07/2009
Issue 04.01 / EN, Preliminary
Updates:
In Volume 1:
History update
In Volume 2:
None
In Volume 3:
Introduction of the feature 34388 Layer 2 Enhancements: Flexible RLC and
MAC-ehs (section 5.5)
Clarification of the recommendation concerning the Mac-d PDU size for Cat.6
and 12
Page 8/23
Introduction of the feature 34386 64 QAM for HSDPA
Range of serviceMaxRate, serviceMinRate, serviceHighRate,
serviceLowRate corrected
New recommendation for serviceHighRate
Class of numberOfHsPdschCodes and numberOfHsScchCodes corrected
New recommendation for hsdpaSchedulerAlgorithmXcem
Update of the TBS applied from maximum MCS for UE Category 10 with
flexible Mac-d pdu and 656 bits Mac-d pdu and for UE Category 14
Update of recommendation concerning the Pre-requisites to reach the
maximum throughput with 64QAM
In Volume 4:
None
In Volume 5:
Restructuration made for chapter named RRC TRAFFIC SEGMENTATION;
Chapter renamed to iMCRA.
Description of 75069 iMCRA - Intelligent Multi-Carrier RRC Connection
Allocation
Recommended value for dlTxPowerEstimation corrected
In Volume 6:
Description of the mobility cases involving a RB reconfiguration from/to MAC-
ehs
In Volume 7
None

Page 9/23
FIGURES
Figure 1: Static and Configuration Parameters 15

Page 10/23
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 load is delivered to address the needs of all Alcatel-Lucent
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 neither Micro Node B nor 9314 Pico
Node B. For the list of features supported on these products please refer to 33341
Alcatel-Lucent 9313 Micro Node B and 33342 Alcatel-Lucent 9314 Pico Node B
descriptions.
Page 11/23
1.2 SCOPE OF THIS DOCUMENT
Features behaviour 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 behaviour or the feature is specific to iCEM.
Tag [xCEM] indicates that the behaviour 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 behaviour or the feature is specific to [UCU-
III].
No tag indicates that the behaviour or the feature is common for all the
boards.

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 [R03]
- Volume 8: Capacity refer to [R04]
- Volume 9: Product recommendations refer to [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 [R06] for more information on features available for UA7.

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 Alcatel-
Lucent NodeB products.
See [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:
RF engineering
Page 12/23
UTRAN Data fill
Trials and FOA

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 Object
Range & Unit
User
Class
Granularity
Value

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 data fill rules are presented as the following:
Rule:

The system restrictions are presented as the following:
Restriction:

The engineering recommendations on parameter value are presented as the
following:
Engineering Recommendation:

The difference between Release N and Release N-x are presented as the
following:
UAN-x-UAN Delta:

Page 13/23
Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o N.A.: Not Applicable.
o N.S.: Not Significant.
o O.D.: Operator Dependant (depends on operator network specific
configuration. Example: addressing parameters).

Page 14/23
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/ 025020 UA07 Feature Planning Guide
[R07] UMT/BTS/INF/016135 Micro NodeB & 9314 Pico NodeB Feature
Planning Guide

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.

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

Page 15/23

RNC
OMC WPS
Static
Non-Static
WPS Templates
Manufacturer
Customer
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).
Page 16/23
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).
o Class 1: new parameter value is taken into account on the next RNC restart.
This class is no longer valid.
o 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).
o 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 establishment, SRLR).
Class 3-B: new value is taken into account for next call.

Page 17/23
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
CE Channel Element
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
ECC E-DCH Congestion Control
E-DCH Enhanced DCH (also referred as HSUPA or EUL)
E-DPCCH Enhanced Dedicated Physical Control Channel
E-DPDCH Enhanced Dedicated Physical Data Channel
Page 18/23
E-HICH Enhanced Hybrid ARQ Indicator Channel
E-RGCH Enhanced Relative Grant Channel
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
G-RAKE Generalized rake receiver
GRF Global Reduction Factor
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
iMCRA intelligent Multiple Carrier Re-direction Algorithm
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
Page 19/23
NAS Non Access Stratum
NBAP NodeB Application Part
NDS Non-Delay Sensitive
OAM Operations, Administration and Maintenance
OLPC Outer-Loop Power Control
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
Page 20/23
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
RSCP Received Signal Code Power
RSN Retransmission Sequence Number
RSSI Received Signal Strength Indicator
RTWP Received Total Wideband Power
SCCP Signalling 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 Signalling Radio Bearer
SRLR Synchronous Radio Link Reconfiguration
SS7 Signalling 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
Page 21/23
UL Uplink
UM Unacknowledged Mode
URA UTRAN Registration Area
UTRAN Universal Terrestrial Radio Access Network
VCC Virtual Channel Connection
VP Virtual Path

Page 22/23
3.2 DEFINITIONS

Page 23/23

END OF DOCUMENT

2 HSXPA OVERVIEW

HSxPA Parameters Guide 04.05 / EN 04/Jun/2010
Volume 2 : HSxPA Overview
Page 1/37
CONTENTS
1 INTRODUCTION............................................................................................................................4
1.1 OBJ ECT....................................................................................................................................4
1.2 SCOPE OF THIS DOCUMENT .......................................................................................................4
2 RELATED DOCUMENTS..............................................................................................................5
2.1 HPUG VOLUMES......................................................................................................................5
2.2 REFERENCE DOCUMENTS..........................................................................................................5
3 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......................................................................................................... 18
3.1.3.3 State of HARQ Processes........................................................................................ 20
3.1.3.4 Choice of the HARQ type......................................................................................... 22
3.1.4 Fast scheduling.............................................................................................................25
3.2 HSUPA (E-DCH)...................................................................................................................27
3.2.1 Transport and physical channels ..................................................................................27
3.2.1.1 Uplink channels ........................................................................................................ 28
3.2.1.2 Downlink channels.................................................................................................... 31
3.2.2 UA7 implementation of E-DCH.....................................................................................34
4 UE CATEGORIES........................................................................................................................35
4.1 HSDPA.................................................................................................................................35
4.2 HSUPA.................................................................................................................................36

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

Page 3/37
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 throughput or BLER versus radio conditions for different modulation................ 16
Figure 14: RV parameters assignment algorithm.......................................................................................... 20
Figure 15: ACK/NACK/DTX management for HARQ processes ................................................................ 21
Figure 16: Dynamic selection of HARQ type.................................................................................................. 24
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

Page 4/37
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 description, configuration aspect and engineering
recommendations.

This document gives an overview of the HSxPA.

Page 5/37
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)
Planning Guide
[R08] UMT/IRC/APP/007147 UMTS BTS Product Engineering Information
[R09] UMT/IRC/APP/014654 HSxPA Engineering User Guide UA5.x
[R10] UMT/SYS/DD/013319 HSDPA System Specification

3 SYSTEM OVERVIEW
HSDPA
[R01] 3GPP has standardized HSDPA in Release 5 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:

Power Power
Control Control
Data Power
Unused Power Data
Unused
Same Throughput

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:

Rate Rate
Adaptation Adaptation 100% Power
100%

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.
Page 6/37
HS-DSCH
Associated
Uplink
Signaling
Associated
Downlink
Signaling
DCCH DTCH DTCH MAC Control MAC Control CCCH CTCH BCCH PCCH MAC Control
RRC (RNC)
RRC (RNC)
RLC (RNC)
RLC (RNC)
Page 7/37
HS-PDSCH
FACH
S-CCPCH
FACH
S-CCPCH
RACH
PRACH
RACH
PRACH
DSCH
PDSCH
DSCH
PDSCH
DCH
DPCH
CPCH
PCPCH
CPCH
PCPCH
PCH
S-CCPCH
PCH PCH
S-CCPCH HS-DPCCH HS-SCCH
MAC-c/sh
(C-RNC)
MAC-c/sh
(C-RNC)
DCH
DPDCH/DPCCH
R99 L1: Channel Coding / Multiplexing (NodeB)
R99 L1: Channel Coding / Multiplexing (NodeB)
R5 L1: HSDPA (NodeB)
R5 L1: HSDPA (NodeB)
MAC-d
(S-RNC)
MAC-hs
(NodeB)
MAC-hs
(NodeB)

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.
Page 8/37
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:
Fast scheduling
Fast retransmission mechanism (HARQ)

Macrodiv TTI Modulation
Channel
coding
Power
control
HARQ
Fast
scheduling
Fast link
adaptation
HSDPA
Not
supported
2 ms
only
QPSK and
16QAM
Turbo No Supported Supported Supported
HSUPA Supported
2 ms,
10 ms
BPSK and
QPSK
Turbo Yes Supported
Supported
but less
reactive
Supported
but less
reactive
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.


PHY PHY
EDCH FP EDCH FP
Iub UE NodeB
Uu
DCCH DTCH
TNL TNL
DTCH DCCH
MAC-e
SRNC
MAC-d
MAC-e
MAC-d
MAC-es /
MAC-e
MAC-es
Iur
TNL TNL
DRNC

Figure 5: Protocol Architecture of E-DCH

Associated
Downlink
Signalling
E-DCH
MAC-d
FACH RACH
DCCH DTCH DTCH
DSCH DCH DCH
MAC Control
USCH
( TDD only )
CPCH
( FDD only )
CTCH BCCH CCCH SHCCH
( TDD only )
PCCH
PCH FACH
MAC-c/sh
USCH
( TDD only )
DSCH
MAC-hs
HS-DSCH
Associated
Uplink
Signalling
Associated
Downlink
Signalling

MAC-es /
MAC-e
Associated
Uplink
Signalling

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.

Page 9/37
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 HS-
SCCH 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

Page 10/37
The following figure summarizes the different channels needed for a HSDPA call:

NodeB
HSDPA UE
HS-PDSCH for data (I/B) traffic HS-PDSCH for data (I/B) traffic
Page 11/37
HSDPA channels HSDPA channels
HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-DPCCH Feedback information HS-DPCCH Feedback information
Associated DPCH for data, speech + SRB traffic 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:

HS-SCCH#2
ACK ACK ACK
7,5 slots
HS-SCCH#1
HS-PDSCH
N_acknack_transmit = 2
2 ms
HS-DPCCH
2 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. value 0 is
QPSK and value 1 is 16QAM or 64-QAM (distinction between 16-QAM and
64-QAM is explained in [R10])
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.

Page 12/37
Data
Slot #0 Slot #1 Slot #2
1 HS-SCCH subframe =2ms
T
slot
=2560 chips =40 bits

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

M= 2 for QPSK
(960 coded bits per TTI)
M = 4 for 16QAM
M = 6 for 64QAM
Data
Slot #0 Slot #1 Slot #2
1 HS-PDSCH subframe =2ms
Tslot =2560 chips =M*10*2
k
bits (k =4, SF16)

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 HS-
DPCCH (SF =256), roughly 7.5slots after HS-PDSCH frame, containing (see the
following figure):
The HARQ Ack/Nack;
The CQI (Channel Quality Indication).

Page 13/37
CQI
Subframe #0 Subframe #i Subframe #4
1 radio frame =10ms
Tslot =2560 chips
=10 bits
ACK/NACK
2.Tslot =5120 chips
=20 bits

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 ackNackRepetitionFactor Object HsdpaUserService
Range & Unit [1..4]
User Customer
Class 3
Granularity HsdpaUserService[0..14]

Value 1

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.

[R04] The CQI is only sent in some specific subframes, as specified in 6A.1.1,
depending on the following parameters:
The CQI feedback cycle: k,
The repetition factor of CQI: N_cqi_transmit.

Parameter cqiRepetitionFactor Object HsdpaUserService
Range & Unit [1..4]
User Customer
Class 3
Value 1

Page 14/37
Page 15/37
Parameter cqiFeedbackCycleK Object HsdpaUserService
Range & Unit Enum {0, 2, 4, 8, 10, 20, 40, 80, 160}ms
User Customer
Class 3
Value 2

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

Parameter cqiPowerOffset Object HsdpaUserService
Range & Unit [0..8]
User Customer
Class 3
Value 6

Parameter ackPowerOffset Object HsdpaUserService
Range & Unit [0..8]
User Customer
Class 3
Value 6

Parameter nackPowerOffset Object HsdpaUserService
Range & Unit [0..8]
User Customer
Class 3
Value 7

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 as it will result in RLC or worst case TCP retransmissions.

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). The capabilities of the UE in term of modulation depend on their
category:
- categories 11 and 12 support only QPSK,
- categories lower or equal to 10 support QPSK and 16QAM
- categories 13, 14, 17, 18 support QPSK, 16QAM and 64QAM
16QAM modulation allowing higher bit rate than QPSK and 64QAM modulation
allowing higher bit rate than 16QAM. The following figures illustrate the gain (in term of
throughput or BLER) according to the modulation:

QPSK
QPSK
QPSK
16QAM
16QAM
-20 -15 -10 -5 0 5
0
100
200
300
400
500
600
700
800
Ior/Ioc (dB)
T
h
r
o
u
g
h
p
u
t

(
k
b
p
s
)
AMC Il lustration
QPSK
QPSK
QPSK
16QAM
16QAM
QPSK
QPSK
QPSK
16QAM
16QAM
-20 -15 -10 -5 0 5
0
100
200
300
400
500
600
700
800
Ior/Ioc (dB)
T
h
r
o
u
g
h
p
u
t

(
k
b
p
s
)
AMC Il lustration

Figure 13: Example of throughput or BLER versus radio conditions for different modulation

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

[iCEM]
Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Number of HARQ Processes 2 2 3 3 6 6 6 6 6 6 3 6
Table 2: Number of processes per UE category for iCEM
Page 16/37
Page 17/37
[xCEM][UCU-III]
Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Number of HARQ Processes 2 3 3 4 6 6 6 6 6 6 3 6
Table 3: 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:
[iCEM]:
Parameter harqNbMaxRetransmissions Object HsdpaConf
Range & Unit [131] decimal
User Customer
Class 3
Granularity BTSCell
Value 7

[xCEM]
Parameter harqNbMaxRetransmissionsXcem Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 7

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

[iCEM][xCEM]:
The two following parameters are common for iCEM and xCEM (RNC parameters):
Parameter discardTimer Object HsdpaUserService
Range & Unit 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
User Customer
Class 3
Value 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-date MAC-hs SDUs from the HSDPA Priority Queues

Page 18/37
Parameter timerT1 Object HsdpaUserService
Range & Unit Enum [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, 400] ms
User Customer
Class 3
Value 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.
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 HS-
SCCH (see section 3.1.1.1). The coding tables of Xrv are given hereafter:

Xrv (Value) s r b
0 1 0 0
1 0 0 0
2 1 1 1
3 0 1 1
4 1 0 1
5 1 0 2
6 1 0 3
7 1 1 0
Table 4: RV coding for 16QAM

Page 19/37
Xrv (Value) s r
0 1 0
1 0 0
2 1 1
3 0 1
4 1 2
5 0 2
6 1 3
7 0 3
Table 5: 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).
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).

New transmission ?
Xrv = Trv[0]
k = 0
Y
N
DTX indication ? Xrv(n) = Xrv(n-1)
Y
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

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

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

Page 20/37
ACK/NACK/DTX ?
HARQ process assigned
by the scheduler
Y
Update of RV parameters
Data transmission
Wait for ACK/NACK
reception
Insertion of DTX
indication
Reset HARQ process
Remove Mac-d PDU
Update structures
Nret = Nret +1
Nret > Nret_max ?
Wait for
retransmission
NACK
DTX
N
WACK state
NACK/DTX state
ACK

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
Page 21/37
Page 22/37
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
[iCEM]
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 non-
systematic 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)

i 1 2 3 4 5 6 7 8
Xrv(QPSK) 0 2 5 6 1 3 4 7
Xrv(16QAM) 6 2 1 5 0 3 4 7
Table 6: RV update table in the MIR case (Trv[i])

i 1 2 3 4 5 6
Xrv(QPSK) 0 2 4 6
Xrv(16QAM) 6 2 5 0 4 7
Table 7: 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
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 8: 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 2
nd
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 2
nd
RM stage in the first retransmission.
More in detail, during the Rate Matching step, following variables are computed:
N
DATA
: total number of radio bits, i.e. the number of HS-PDSCH codes times
the modulation order (2 or 4) times 960 bits.
N
IR
: 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.
Page 23/37
N
SYS
: number of systematic bits (not equal to transport block size).
N
P1
and N
P2
: number of parity bits 1 and 2 after 1
st
RM step.
N
RM1
=N
SYS
+N
P1
+N
P2

N
PUNC2
=N
RM1
- N
DATA
: number of bits punctured by 2
nd
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 1
st
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 1
st
retransmission
occurs.

Parameters Settings:
[Vol. 3] See .

[xCEM]
The HARQ type selection is done through the parameter harqTypeXcem:
Page 24/37
Page 25/37
Parameter harqTypeXcem Object HsdpaConf
Range & Unit [ccType, irType]
User Customer
Class 3
Granularity BTSCell
Value irType

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

i 1 2 3 4
Xrv(QPSK) 0 2 5 6
Xrv(16QAM) 6 2 1 5
Xrv(64QAM) 6 2 1 5
Table 9: RV update table in the IR case (Trv[i])

[xCEM] only:
i 1 2 3 4
Xrv(QPSK) 0 0 0 0
Xrv(16QAM) 0 4 5 6
Xrv(16QAM) 0 4 5 6
Table 10: RV update table in the CC case (Trv[i])

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.
Page 26/37
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).
- 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 E-
RGCH)

E
-
D
P
C
C
H
E
-
D
P
D
C
H
E
-
H
I
C
H
E
-
H
I
C
H
E
-
A
G
C
H
E
-
A
G
C
H
E
-
R
G
C
H
E
-
R
G
C
H

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
Page 27/37
Page 28/37
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
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 edchHarqMaxRetransEdchTti10 Object EdchParameters
Range & Unit Integer [0 ..15], N/A
User Customer
Class 3
Granularity RNC,
UlRbSetConf
Value [iCEM] [xCEM] 4
[UCU-III] 3

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 edchHarqMaxRetransEdchTti2 Object EdchParameters
Range & Unit Integer [0 ..7], N/A
User Customer
Class 3
Granularity RNC,
UlRbSetConf
Value [xCEM] 7
[UCU-III] 7

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]):

Data, N
data
bits
Slot #1 Slot #14 Slot #2 Slot #i Slot #0
T
slot
=2560 chips, N
data
=10*2
k
bits (k=07)
T
slot
=2560 chips
1 subframe =2 ms
1 radio frame, T
f
=10 ms
E-DPDCH E-DPDCH
E-DPCCH 10 bits

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 Bits/Slot
Ndata
0 15 256 150 30 10
1 30 128 300 60 20
2 60 64 600 120 40
3 120 32 1200 240 80
4 240 16 2400 480 160
5 480 8 4800 960 320
6 960 4 9600 1920 640
7 1920 2 19200 3840 1280
Table 11: E-DPDCH slot formats

Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Sub frame Bits/Slot
N
data
0 15 256 150 30 10
Table 12: E-DPCCH slot formats

E-DCH multicode transmission is possible only for SF =4 and SF =2.
Page 29/37
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]:

I+jQ
S
e-dpch

c
ed,1
ed,1
E-DPDCH
1
iq
ed,1
c
ed,k
ed,k
E-DPDCH
k
iq
ed,k
c
ed,K
ed,K
E-DPDCH
N
iq
ed,K
c
ec
ec
E-DPCCH

iq
ec
.
.
.
.
.
.
.
.

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

S
dpch,n

I+jQ
S
dpch

S
hs-dpcch

S
S
e-dpch

Spreading
Spreading
Spreading
DPCCH
DPDCHs
HS-DPCCH
E-DPDCHs
E-DPCCH

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:
Page 30/37
Page 31/37
Parameter deltaEdpcch Object EdpchParameters
Range & Unit Integer [0 8], N/A
User Customer
Class 0
Granularity RNC, EdpchInfoClass
Value 4

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

20
10
DPCCH E

8 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 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:

=
20
10
DPCCH E
c ec

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:

Slot #1 Slot #14 Slot #2 Slot #i Slot #0
T
slot
=2560 chips
1 subframe =2 ms
1 radio frame, T
f
=10 ms
E-AGCH 20 bits

Figure 21: E-AGCH frame structure
Page 32/37

An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one E-
AGCH 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
(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 E-
HICH 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 b
i,0
, b
i,1
, , b
i,39
transmitted in slot I (see Figure 22: E-HICH frame
structure) is given by:

b
i,j
=a C
ss,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 0 0
DOWN -1 -1
Table 14: Relative grant information (E-RGCH)

The orthogonal signature sequences C
ss,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.
The following figure illustrates the structure of the E-HICH:

Slot #14
T
slot
= 2560 chip
b
i,39
b
i,1
b
i,0

Slot #0 Slot #1 Slot #2 Slot #i
1 radio frame, T
f
= 10 ms
1 subframe = 2 ms

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 b
i,0
, b
i,1
, , b
i,39
transmitted in slot i in previous figure is given by :

b
i,j
=a C
ss,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) 0
NACK (RLS containing the serving E-DCH cell) -1
Table 15: ACK/NACK information (E-HICH)

Page 33/37
Page 34/37
The orthogonal signature sequences C
ss,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.

3.2.2 UA7 IMPLEMENTATION OF E-DCH
Below rules and restrictions summarize Alcatel-Lucent implementation of E-DCH in
UA7. The term restriction in this section refers to E-DCH well-known functionalities
that are not available in UA7 release.

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.

UA6.0-UA7.1 Delta: 2 ms E-DCH TTI Support on UCU-III
In UA6, only the 10 ms E-DCH TTI is supported in UCU-III. In UA7.1 both 10 ms and 2 ms E-DCH TTI
are supported in UCU-III.

Page 35/37
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
Maximum number
of HS-DSCH codes
received
Minimum
inter-TTI
interval
Maximum number of bits of an HS-
DSCH transport block received within
an HS-DSCH TTI
Total number of
soft channel bits

Category 1 5 3 7298 19200
Category 2 5 3 7298 28800
Category 3 5 2 7298 28800
Category 4 5 2 7298 38400
Category 5 5 1 7298 57600
Category 6 5 1 7298 67200
Category 7 10 1 14411 115200
Category 8 10 1 14411 134400
Category 9 15 1 20251 172800
Category 10 15 1 27952 172800
Category 11 5 2 3630 14400
Category 12 5 1 3630 28800
Category 13 15 1 35280 259200
Category 14 15 1 42192 259200
Category 15 15 1 23370 345600
Category 16 15 1 27952 345600
Category 17 15 1 35280 259200
Category 18 15 1 42192 259200
Category 19 - - - -
Category 20 - - - -
Table 16: HSDPA UE categories (3GPP TS25.306)

UEs of Categories 11 and 12 supports QPSK only, while Categories 13, 14, 17 and 18
support full set of modulations [QPSK, 16-QAM, 64-QAM].
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.

Page 36/37
4.2 HSUPA
For HSUPA, the following UE categories have been specified in 3GPP [R05]:

E-DCH
category
Maximum
number of
E-DCH
codes
transmitted

Minimum
spreading
factor
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
Category 1 1 SF4 10 ms TTI
only
7110 -
Category 2 2 SF4 10 ms and
2 ms TTI
14484 2798
only
14484 -
2 ms TTI
20000 5772
only
20000 -
2 ms TTI
20000 11484
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 UA7 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).
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:
o Category 3: 1380 kb/s
5.76 Mbits/s for TTI =2 ms
And a maximum RLC throughput of:

[UCU-III]
For UA6 UCU-III in OneBTS, only 10ms TTI is supported and minimum SF equal to
2SF2 in UA7 (i.e. cat 2, 4, and 6 on 2ms TTI are not supported). Hence UCU-III
supports up to category 5, on 10 ms TTI only. It does not support category 6 (and it
would be managed like a category 4 on 10ms TTI).
For UA7.1 the UCU-III supports both the 10ms and 2ms TTIs on cat 2, 4 and 6 UEs
Category 6 UEs with 2 SF2 and 2 SF 4 codes are also supported.
Page 37/37

END OF DOCUMENT

3 HSDPA PRINCIPLES, SCHEDULING & RESOURCE
MANAGEMENT


Volume 3: HSDPA Principles, Scheduling & Resource Management
Page 1/151
CONTENTS
1 INTRODUCTION............................................................................................................................6
1.1 OBJ ECT....................................................................................................................................6
2.1 HPUG VOLUMES......................................................................................................................9
3 HSDPA ACTIVATION..................................................................................................................10
4 SCHEDULER...............................................................................................................................10
4.1 ALGORITHM............................................................................................................................10
4.1.1 [iCEM]............................................................................................................................10
4.1.2 [xCEM] [UCU III]............................................................................................................12
4.1.2.1 UL processing........................................................................................................... 12
4.1.2.2 CQI SNR mapping and SNR SE mapping...................................................... 12
4.1.2.3 HARQ process and priority queue selection............................................................ 12
4.1.2.4 User ranking............................................................................................................. 13
4.1.2.5 SNR estimation for HS-PDSCH................................................................................ 13
4.1.2.6 TFRC selection......................................................................................................... 13
4.2 SCHEDULER TYPES .................................................................................................................16
4.2.1 [iCEM]............................................................................................................................16
4.2.2 [xCEM] [UCU III]............................................................................................................17
4.3 QOS MANAGEMENT.................................................................................................................19
4.3.1 [iCEM]............................................................................................................................19
4.3.2 [xCEM]...........................................................................................................................22
4.4 UE CATEGORY MANAGEMENT..................................................................................................30
4.4.1 [iCEM]............................................................................................................................30
4.4.2 [xCEM]...........................................................................................................................31
4.5 HSDPA USER SCHEDULING.....................................................................................................31
4.5.1 [iCEM]............................................................................................................................31
4.5.2 [xCEM]...........................................................................................................................32
5 TFRC MANAGEMENT ................................................................................................................33
5.1 MAC-D PDU SIZE MANAGEMENT .............................................................................................33
5.2 656 PDU QUALCOMM UE BUG WORKAROUND .........................................................................40
5.3 TRANSPORT BLOCK SIZE OPTIMIZATION...................................................................................42
5.4 TFRC SELECTION...................................................................................................................48
5.4.1 Flexible Modulation (34102) iCem only......................................................................48
5.4.2 64 QAM for HSDPA (34386) xCem only....................................................................50
5.4.2.1 Description................................................................................................................ 50
5.4.2.2 Configuration............................................................................................................ 52
5.4.2.3 Parameters settings.................................................................................................. 53
5.5 LAYER 2 ENHANCEMENTS: FLEXIBLE RLC AND MAC-EHS .........................................................58
Page 2/151
5.5.1 Flexible RLC and MAC-ehs...........................................................................................58
5.5.2 IUB Frame protocol.......................................................................................................66
6 CQI & MAC-HS BLER MANAGEMENT......................................................................................68
6.1 CQI PROCESSING...................................................................................................................68
6.2 CQI ADJ USTMENT ACCORDING TO BLER.................................................................................69
6.3 HS-DPCCH PRESENCE DETECTION ........................................................................................76
7 OVSF CODES..............................................................................................................................79
7.1 CELL CONFIGURATION ............................................................................................................79
7.2 HSDPA CODE ALLOCATION....................................................................................................80
7.2.1 Dynamic Code Tree Management................................................................................81
7.2.2 Fair Sharing...................................................................................................................91
8 POWER MANAGEMENT FOR HSDPA ......................................................................................94
8.1 INTRODUCTION .......................................................................................................................94
8.2 HS-DSCH POWER MANAGEMENT............................................................................................94
8.2.1 Power allocation............................................................................................................94
8.2.1.1 RNC level.................................................................................................................. 94
8.2.1.2 NodeB level .............................................................................................................. 98
8.2.1.3 Power available for HSDPA channels...................................................................... 99
8.2.2 Power measurements ...................................................................................................99
8.2.2.1 Transmitted carrier power....................................................................................... 100
8.2.2.2 Averaged HSDPA power........................................................................................ 100
8.2.2.3 Total non HSDPA power ........................................................................................ 101
8.2.2.4 Available HSDPA power......................................................................................... 101
8.2.2.5 HS-DSCH Required Power .................................................................................... 102
8.2.3 HSDPA power distribution.......................................................................................... 105
8.2.3.1 HS-SCCH power .................................................................................................... 105
8.2.3.2 HS-DSCH power .................................................................................................... 106
8.2.3.3 HS-PDSCH power.................................................................................................. 107
8.2.4 Power management................................................................................................... 112
8.2.4.1 First transmission................................................................................................... 112
8.2.4.1.1 Power limitation.................................................................................................. 114
8.2.4.1.2 Codes limitation.................................................................................................. 114
8.2.4.1.3 Other limitations.................................................................................................. 114
8.2.4.1.4 CQI optimization according to MAC-d PDU size................................................ 115
8.2.4.1.5 HS-DSCH Power evolution................................................................................. 116
8.2.4.2 Retransmission....................................................................................................... 117
8.2.4.3 Multi-users per TTI ................................................................................................. 118
8.3 HS-SCCH POWER MANAGEMENT......................................................................................... 119
8.4 PARAMETERS SETTINGS AND RECOMMENDATIONS ................................................................ 122
8.5 UA6 MANAGEMENT OF UL POWER PROFILES DEPENDING ON WHETHER HSDPA IS MAPPED ON
THE DL 125
8.5.1 Introduction................................................................................................................. 125
8.5.2 Feature Description.................................................................................................... 126
8.5.3 Parameters Settings and Recommendations ............................................................ 128
9 OTHER FEATURES ................................................................................................................. 130
9.1 HSDPA AND E-DCH SERVICE INDICATOR (32520)............................................................... 130
9.2 HSDPA PERFORMANCE ENHANCEMENT (29819) ................................................................. 131
Page 3/151
9.3 HSDPA OCNS (34195)...................................................................................................... 132
9.3.1 HSDPA OCNS principle............................................................................................. 132
9.3.2 HSDPA OCNS parameters........................................................................................ 133
9.4 IU USER TRAFFIC CONFORMANCE ........................................................................................ 137
9.4.1 Feature applicable...................................................................................................... 138
9.4.2 Algorithm.................................................................................................................... 138
9.4.3 Parameters................................................................................................................. 139
9.4.4 Feature Behaviour...................................................................................................... 141
9.5 RADIO MEASUREMENT FREQUENCY INCREASE: TX POWER.................................................... 141
9.5.1 Feature OVERVIEW and Potential Benefits .............................................................. 142
9.5.2 Solution Description................................................................................................... 142
9.5.2.1 Averaged HSDPA power........................................................................................ 143
9.5.2.2 Total Non HSDPA Power ....................................................................................... 143
9.5.2.3 Available HSDPA Power ........................................................................................ 143
9.5.2.4 Report of Total Non HSDPA Power from CEM to CCM......................................... 144
9.5.3 Parameter Settings .................................................................................................... 144
9.6 HSDPA OLS DIFFERENTIATION AT NODE B LEVEL ............................................................... 147
9.6.1 Feature Overview....................................................................................................... 147
9.6.2 Solution Description................................................................................................... 148
9.6.3 Feature Activation and Parameters ........................................................................... 148

Page 4/151
TABLES
Table 1: CQI mapping table for 336 bits MAC-d PDU size 43
Table 2: CQI mapping table for 656 bits MAC-d PDU size 44
Table 3: Max hsdschInterval value 45
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size 47
Table 5: Necessary throughput per HSDPA UE category (assuming Maximum TBS per TTI) 47
Table 6: Iub bandwidth per number of E1 links 48
Table 7: HS-PDSCH Slot formats 52
Table 8: HS-SCCH power offset table according the reported CQI 120

Page 5/151
FIGURES
Figure 1: MAC-hs scheduler overview............................................................................................................ 11
Figure 2: TFRC selection algorithm used by the xCEM/ UCU-III................................................................ 15
Figure 3 : Example of Scheduling Weight for different value of serviceBFactor....................................... 24
Figure 4: Example of Scheduling Weight for different value of serviceKFactor........................................ 25
Figure 5: Parameters to configure the feature MAC-d PDU size 656 bits.............................................. 38
Figure 6: Conditions to invoke the feature 79164.......................................................................................... 41
Figure 7: Padding bits in the MAC-hs PDU.................................................................................................... 42
Figure 8: Codes limitation................................................................................................................................. 49
Figure 9: Code boost......................................................................................................................................... 50
Figure 10: CQI mapping tables ........................................................................................................................ 51
Figure 11 : Benefits of flexible RLC and Mac-ehs versus fixed RLC and Mac-hs.................................... 60
Figure 12 : RB congestion control Object Tree.............................................................................................. 66
Figure 13: CQI Processing................................................................................................................................ 69
Figure 14 : BLER Target according to the CQI and the UE category for the different BLER Ajustement
algorithm...................................................................................................................................................... 71
Figure 15: CQI adjustment to BLER algorithm............................................................................................... 72
Figure 16: HS-DPCCH synchronization algorithm........................................................................................ 77
Figure 17: R99, HSDPA & HSUPA Common Channels codes allocation................................................. 80
Figure 18: HS-PDSCH codes pre-emption or re-allocation......................................................................... 83
Figure 19: Number of HS-PDSCH codes pre-empted.................................................................................. 83
Figure 20: Number of HS-PDSCH codes re-allocated.................................................................................. 84
Figure 21: Illustration of the HS-PDSCH re-allocation blocking.................................................................. 84
Figure 22: Exemple of codes occupancy for SF16....................................................................................... 92
Figure 23: Power allocation at RNC level....................................................................................................... 95
Figure 24: Physical shared channel reconfiguration message.................................................................... 97
Figure 25: Power allocation at NodeB level ................................................................................................... 98
Figure 26: Transmitted carrier power (on the left) and averaged HSDPA power (on the right) ........... 100
Figure 27: Common measurement................................................................................................................ 101
Figure 28: Power measurement process...................................................................................................... 102
Figure 29: Measurement flow of HS-DSCH required power...................................................................... 105
Figure 30: Power distribution between HS-DSCH and HS-SCCH channels........................................... 105
Figure 31: measurementPowerOffset transmission.................................................................................... 107
Figure 32: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH....... 108
Figure 33: hsdpaAmpUsage parameter........................................................................................................ 110
Figure 34: Dynamic Power Allocation........................................................................................................... 111
Figure 35: HS-DSCH power management for 1st transmission................................................................ 113
Figure 36: MAC-hs transport block adaptation according to the number of MAC-d PDU to transmit. 115
Figure 37: Remaining power for multi-users per TTI scheduling.............................................................. 119
Figure 38: HS-SCCH power control overview.............................................................................................. 120
Figure 39: Selection of OLPC UL SIR Target parameters by the RNC ................................................... 127
Figure 40: Algorithm for CQI Generating Function...................................................................................... 135
Figure 41: Traffic Conformance Algorithm.................................................................................................... 139

Page 6/151
1 INTRODUCTION
1.1 OBJECT
recommendations.

The following features are described in the document:
PM ID Feature Title Activation flag Release
Global
market
US
Market
27931
HSDPA Flexible
resources Mgt
N/A
UA4.2 Yes Yes
27932 HSDPA Step 1
hsdpaActivation
hsdpaResourceActivation
isHsdpaAllowed
UA4.2 Yes Yes
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
N/A
UA5.0 Yes Yes
29800
Dynamic DL Code
Tree Mgt For
HSDPA
isHsPdschDynamicManagementAllowed
isCellHsPdschDynamicManagementActive
(from UA6.0)
UA5.0 Yes Yes
29807
MAC-hs scheduler
improvement
hsdpaSchedulerAlgorithm
hsdpaSchedulerWeightingFactor
hsdpaUeCategoryThroughputWeighting
hsdpaSpiRelativeWeight
UA5.0 Yes Yes
32520
HSDPA and E-DCH
Service Indicator
isHsxpaServiceIndicatorEnabled
hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod
UA5.0 Yes Yes
29819
HSDPA
Performance
Enhancement
hsdpaCqiBlerAdjustmentAlgo
ueCategory1..12
harqType
UA5.0 Yes No
Page 7/151
Global
market
US
Market
rxDemodulation
34340
UE cat.8 max.
throughput with PDU
656 & RLC
reconfiguration
isDynamicMacdPduSizeManagementAllowed
eligibleUeCategoryForHighPerformance
minimumUserMbrForHighPerformance
maxCellRadius (only in UA5.1)
UA5.1 Yes No
27350
xCEM hardware
introduction
N/A
UA5.1 Yes No
34652
High quality UL R99
RAB for High
HSDPA DL data rate
N/A

UA5.1 Yes Yes
29799
MAC-d PDU size
Management for
HSDPA
isHsdpaCellHighPerformance (from UA6)
isHighPerformancePduSizeReconfAllowed
UA6.0 Yes Yes
29804 GBR on HSDPA
isGbrOnHsdpaAllowed (used only to map
Streaming on HSDPA)
UA6.0 Yes Yes
33390
Dynamic BLER
Adjustment
hsdpaCqiBlerAdjustmentAlgo
hsdpaCqiBlerAdjustmentAlgorithmxCEM
UA6.0 Yes No
33391
HS-DSCH Power
Adjustment
Evolution
hsdpaFullPowerUsage
UA6.0 Yes No
33694
Fair Sharing of
Resources - HSDPA
vs DCH
RNC:
isHsxpaR99ResourcesSharingOnCellAllowed
NodeB:
BTSEquipment::hsdpaCodeTreeManagementAc
tivation (iCEM/xCEM)
OneBTSEquipment::hsdpaCodeTreeManageme
ntActivation (UCU-III)
UA6.0 Yes Yes
34102
HSDPA Flexible
Modulation
hsdpaFlexibleModulationVsCodeActivation
UA6.0 Yes No
34195
Support OCNS with
HSDPA
proprietaryHSDPAOCNSActivation
UA6.0 No Yes
79164
Qualcomm issue
with 656 PDU size
workaround
is2ndRrcRbReconfNeededForQC7200
UA6.0 Yes Yes
34388
Layer 2
Enhancement:
Flexible RLC and
MAC-ehs
isMacEhsAllowed (scope RNC)
isMacEhsAllowed (scope FDDCell)
UA7.0 Yes Yes
34386 64 QAM for HSDPA
isDl64QamAllowed UA7.0 Yes Yes
Page 8/151
Global
market
US
Market
isDl64QamOnRncAllowed
is64QamAllowedForUeCategory
75998
Radio Measurement
Frequency Increase:
Tx Power
hsdpaWindowsObserveTime
isDchPowerMarginAdaptive
UA7.1 Yes No
97431
HSDPA OLS
Differentiation at
Node B Level
N/A (creation of optional object)
UA7.1 Yes No

Page 9/151
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

[R03] 3GPP TS25.306 UE Radio Access capabilities
[R04] 3GPP TS 23.107 Quality of Service (QoS) concept and
architecture
Planning Guide
[R07] UMT/IRC/APP/0164 Iub Transport Engineering Guide

Page 10/151
3 HSDPA ACTIVATION
HSDPA is activated through several activation flags at RNC, FDDCell and BTSCell
level:
Parameter isHsdpaAllowed Object RadioAccessService
Range & Unit
False, True
User Customer
Class 3
Granularity RNC
Value True

Parameter hsdpaActivation Object FDDCell
Range & Unit
False, True
User Customer
Class 2
Granularity Cell
Value True

Parameter hsdpaResourceActivation Object BTSCell
Range & Unit
False, True
User Customer
Class 2
Granularity Cell
Value 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.

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.

Page 11/151

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)

Page 12/151
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 1
st
TX BLER of
10% and a transmitted power for the HS-DSCH equal to the following reference
power:
P
HS-DSCH reference
[dBm] =P
P-CPICH
[dBm] +[dB] +(CQI
reported
)[dB]
where
- P
P-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].

Contrary to iCEM, xCEM/UCU-III does not directly use the CQI. The received CQI
information is mapped to SNR values (SNR
MAP,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.

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.

Page 13/151
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.

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 SNR
MAP,dB
derived from CQI (see previously) and on
the available power per HS-PDSCH code:
SNR
dB
=SNR
MAP,dB
+P
availableHS-PDSCH
P
cpich
+(ack,nack)
- SNR
MAP,dB
is the last SNR value mapped on CQI assuming a HS-
DSCH power of P
cpich
+ ( being the measurementPowerOffset/2 ).
- P
availableHS-PDSCH
is the power available per HS-PDSCH code. (see
section 8.2.3.3 for more details)
- (ack,nack) is a correction factor used to ensure that the 1
st
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)
This SNR
dB
is then mapped to a SE and used for TFRC selection.

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 HS-
PDSCH codes n
HS-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:
TBS / n
HS_PDSCH
SE with maximal TBS and minimal n
HS_PDSCH

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 16-
Page 14/151
QAM. 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

[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 (SE
cum
=SE
current
+SE
cum
).

[xCEM]
The spectral efficiency is SE =min(SE
current
; SE
cum
).

The power allocated for the HS-DSCH of the user i is:
P
HS-DSCH
(i) =P
availableHS-PDSCH
x n
HS_PDSCH

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:
P
HS-DSCH
(i) =P
availableHS-PDSCH
x n
HS_PDSCH
x factor

) (
) / (
SE SNR
W B SNR
factor =

Where:
- B is the Transport Block Size selected by the scheduler
- W is the number of HS-PDSCH codes selected by the scheduler

For very high throughput (when 64QAM modulation is used), the allocated power is
reduced by using factor = 0.62 (2dB) in order to avoid EVM issue. This power
reduction is triggered when:

Page 15/151
n
HS_PDSCH
=15 and B >=37896
or n
HS_PDSCH
=14 and B >=35280

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

For more details on power management, see section 8.2.3.3.

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:
CQI
SNR (dB)
SNR of one HS-PDSCH (linear)
SE
SE
TFRC
S
N
R

(
d
B
)
S
N
R

o
f

o
n
e

H
S
-
P
D
S
C
H

(
d
B
)
S
N
R

o
f

o
n
e

H
S
-
P
D
S
C
H

(
l
i
n
e
a
r
)
S
E
PowerHsPdschAvailable_dBm
PowerCpich_dBm
MPO
DeltaAckNack
CQI
UE Cat.
Log2lin
Modulation Capability
Number of HS-PDSCH available
max. MAC-hs Payload
Modulation
Number of HS-PDSCH
MAC-hs PDU Size
CQI
SNR (dB)
SNR of one HS-PDSCH (linear)
SE
SE
TFRC
S
N
R

(
d
B
)
S
N
R

o
f

o
n
e

H
S
-
P
D
S
C
H

(
d
B
)
S
N
R

o
f

o
n
e

H
S
-
P
D
S
C
H

(
l
i
n
e
a
r
)
S
E
PowerHsPdschAvailable_dBm
PowerCpich_dBm
MPO
DeltaAckNack
CQI
UE Cat.
Log2lin
Modulation Capability
Number of HS-PDSCH available
max. MAC-hs Payload
Modulation
Number of HS-PDSCH
MAC-hs PDU Size

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

Page 16/151
4.2 SCHEDULER TYPES
4.2.1 [iCEM]
As explained in [R05], the RF cost function noted C1 is based on the following
principles:

- Alcatel-Lucent Proportional Fair:
cost
T
=.cost
T-1
+(1 - ).(nb_bits_transmitted / nb_bits_optimum(CQI) )
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).

- Classical Proportional Fair:
cost
T
=CQIav
T
/ CQIinst
T
with CQIav
T
= * CQIav
T-1
+(1 - ) * CQIinst
T

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 hsdpaSchedulerWeightingFactor Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 5

The selection of any of these scheduler types can be changed on line through a
customer class 3 parameter: hsdpaSchedulerAlgorithm.
Parameter hsdpaSchedulerAlgorithm Object HsdpaConf
Range & Unit [alcatel-Lucent, proportionalFair] Enum
User Customer
Class 3
Granularity BTSCell
Value proportionalFair

Page 17/151
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] [UCU III]
[xCEM]
Two schedulers are supported and can be selected through the parameter
hsdpaSchedulerAlgorithmXcem:
Parameter hsdpaSchedulerAlgorithmXcem Object HsdpaConf
Range & Unit [CRmax, proportionalThroughput] Enum
User Customer
Class 3
Granularity BTSCell
Value CRmax

Engineering Recommendation: hsdpaSchedulerAlgorithmXcem
When the xCem has been introduced, the recommended scheduler was the proportionalThroughput in
order to be iso-functional with the iCem scheduler (proportionalFair).
Nevertheless, there is no behaviour difference between the two xCem schedulers when the QoS is
disabled. The behavior differences appear when the QoS is enabled:
- proportionalThroughput allows a relative differentiation between users
- CRmax allows a absolute differentiation between users

The choice of the xCem scheduler depends mainly of the customer strategy in term of QoS.
Nevertheless, the CRmax scheduler is more appropriate to have a GBR-like behavior and offer more
flexibility than proportionalThroughput. That is the reason why the CRmax is the recommended
scheduler in UA7.

Note that to be really able to guarantee a GBR, the Fair Sharing feature is needed.

The cost of each priority queue is computed differently with CRmax and
proportionalThroughput:
Cost
propTh
=(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
Cost
propTh
=(1/(ServiceBFactor(u,q)*100)) * J (u,q) / CR(u,q) for GBR MAC-d flows
when R <serviceMinRate
Cost
CRmax
=SW(u,q) . J (u,q) / CR(u,q) for all MAC-d flow types
Page 18/151
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.
- J ob 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
- Channel rate CR(u) is the spectral efficiency (SE) times the number
of available HSDPA codes

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.

[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,
Page 19/151
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.

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

Page 20/151
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
avoid wasting resources by artificially restraining some UEs while other UEs suffer
very bad radio conditions).

Parameters:
Parameter hsdpaSpiRelativeWeight Object HsdpaConf
Range & Unit [1..16][1..100] List of Decimal
User Customer
Class 3
Granularity BTSCell
Value 2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32

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

Page 21/151
The setting of SPI (common for iCem and xCem) is done in RNC /
RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos:
Parameter Spi Object ThpBasedQos
Range & Unit [0..15]
User Customer
Class 3
Granularity RNC
Value Depends on customer strategy

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. 1).
Notes:
[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:
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
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).

Page 22/151
Parameters:
Parameter hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi Object HsdpaConf
Range & Unit [1..16][1..11] List of Decimal
User Customer
Class 3
Granularity BTSCell
Value [8, .., 8] (default value)

Parameter hsdpaGbrNbUePerTtiForgettingFactor Object HsdpaConf
Range & Unit [1..11] Decimal
User Customer
Class 3
Granularity BTSCell
Value 8 (default value)

Parameter hsdpaGbrNbNeededTtiForgettingFactor Object HsdpaConf
User Customer
Class 3
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
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
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.
Page 23/151
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

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

If R serviceMinRate:
ctor serviceKFa
Rate serviceMin Rate serviceMax
Rate serviceMin R
=

If R <serviceMinRate:
ctor serviceKFa
Rate serviceMin Rate serviceMax
R Rate serviceMin
/ 1

=

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

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:

Page 24/151
Pr ior it y Weight ing (Rmin = 40 kbps, Rmax = 60 kbps)
0
1
2
3
4
5
6
7
20 30 40 50 60 70 80
Dat a Rat e [ kbps]
P
r
i
o
r
i
t
y
B =7, K =7 B = 5, K = 7 B =3, K =7 B =1, K = 7

Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)
K_factor=7
0,01
0,1
1
10
100
1000
0 10 20 30 40 50 60 70 80
Data Rate (kbps)
S
c
h
e
d
u
l
i
n
g

W
e
i
g
h
t

(
l
o
g
)
B=7
B=5
B=3
B=1

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

Page 25/151
Pr ior it y Weight ing (Rmin = 40 kbps, Rmax = 60 kbps)
0
1
2
3
4
5
6
7
20 30 40 50 60 70 80
Dat a Rat e [ kbps]
P
r
i
o
r
i
t
y
B =7, K =7 B =7, K =5 B =7, K =3 B = 7, K =1

Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)
B_factor=7
0,01
0,1
1
10
100
1000
0 10 20 30 40 50 60 70 80
Data Rate (kbps)
S
c
h
e
d
u
l
i
n
g

W
e
i
g
h
t

(
l
o
g
)
K=7
K=5
K=3
K=1

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

Page 26/151
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

Parameters:
The parameters used by the schedulers are the following ones:
Parameter hsdpaSchedulerWeightingFactorXcem Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 8

Parameter serviceBFactor Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 1

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 serviceKFactor Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 7

Parameter serviceMaxRate Object HsdschServiceParameterSet
Range & Unit [010000] decimal kb/s
User Customer
Class 3
Granularity BTSCell
Value 300

Parameter serviceMinRate Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 40

Page 27/151
Parameter serviceHighRate Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 80 for PS Streaming and 300 for PS I/B

Parameter serviceLowRate Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 0

Parameter serviceFilterFactor Object HsdschServiceParameterSet
User Customer
Class 3
Granularity BTSCell
Value 8

The parameters in the object HsdschServiceParameterSet allow defining the priority
of only one SPI. 16 instances of HsdschServiceParameterSet have been created.
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

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
Page 28/151
[UCU III]
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:

Parent Object Instance Name Default [Unit] Remark
SchedulingPriorityLevel
=15
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
HsdschServiceParameterSet HSDSCHServiceParameterSet1
ServiceKFactor =7
Parameter set
for scheduling
priority 15.
Can be
configured at
OMC
=14
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
Parameter set
for scheduling
priority 14.
Can be
configured at
OMC
=13
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
Parameter set
for scheduling
priority 13.
Can be
configured at
OMC
=12 Parameter set
for scheduling
Page 29/151
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
configured at
OMC
=11
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
Parameter set
for scheduling
priority 11.
Can be
configured at
OMC
=10
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
Parameter set
for scheduling
priority 10.
Can be
configured at
OMC
=10
ServiceMinRate =0
[kbps]
ServiceMaxRate =300
[kbps]
ServiceLowRate =0
[kbps]
ServiceHighRate =10
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =7
ServiceKFactor =7
Parameter set
for scheduling
priority 9. Can
be configured
at OMC
HsdschServiceParameterSet HSDSCHServiceParameterSetUc
ServiceMinRate =0
[kbps] Parameter set
for scheduling
Page 30/151
ServiceMaxDelay =0
[ms]
ServiceBFactor =1
ServiceKFactor =1
configured at
OMC
ServiceMinRate =126
[kbps]
ServiceMaxRate =130
[kbps]
ServiceMaxDelay =0
[ms]
ServiceBFactor =5
HsdschServiceParameterSet HSDSCHServiceParameterSetFt
ServiceKFactor =13
Parameter set
for scheduling
priority 10.
Can not be
configured at
OMC

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

Page 31/151
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 hsdpaUeCategoryThroughputWeighting Object HsdpaConf
Range & Unit [ueCategoryEquity, ueCategoryProportionality] Enum
User Customer
Class 3
Granularity BTSCell
Value ueCategoryProportionality

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:
Parameter hsdpaUeCategoryThroughputWeightingXcem Object HsdpaConf
Range & Unit [ueCategoryEquity, ueCategoryProportionality] Enum
User Customer
Class 3
Granularity BTSCell
Value ueCategoryProportionality

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

Page 32/151
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 (CQI
processed
0, min inter TTI distance,
AckNack repetition factor, one HARQ process available, UE not already scheduled for
retransmissions).

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.

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):
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 CQI
applied
in Section 8
Power Management.
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.
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.

Page 33/151
5 TFRC MANAGEMENT
5.1 MAC-D PDU SIZE MANAGEMENT
This section is only applicable to the case where MAC-hs/fixed MAC-d PDU size
format is used for the call. For the case where MAC-ehs/flexible Mac-d PDU size is
used, refer to the section 5.5
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)
For example, the maximum theorical HSDPA user throughput should be around 5Mb/s for 336 bits or
10Mb/s for 656 bits MAC-d PDU size assuming the following parameters: 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.

Page 34/151

Engineering Recommendation: prohibitedStatusTimer and PollingTimer
Engineering recommendation is to set :
DlRlcAckMode/prohibitedStatusTimer to 30ms
DlRlcAckFlexibleMode/prohibitedStatusTimer to 10ms
DlRlcAckMode/PollingTimer and DlRlcAckFlexibleMode/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 /
Page 35/151
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 (8.5Mbps with
UE Cat.9, 10.8Mbps with UE Cat.10 or 19Mbps with UE Cat.14):
- MAC-d PDU size =656 bits or flexible pdu especially for Cat.10 and 14
- 1 dedicated H-BBU per HSDPA cell
- At least 6 E1 (Iub/Iur) for UE Cat.9, 8 E1 for UE Cat.10 or Hybrid Iub for UE Cat.14 (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 :
o RWIN (TCP window) =146kB for UE Cat.9/10 or 350kB for UE Cat.14
o DlRlcQueueSizeForUeCat =256 RLC SDU for Cat.9/10 or 512 for Cat.14
o prohibitedStatusTimer =30ms (could be reduced to 10 ms for demo purpose)
- Socket Buffer Size =200000 Bytes (Server configuration) at minimum; 16777216 Bytes
(2
24
) is the value commonly used.

See [R07] for more details on Hybrid Iub configuration.

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.
Page 36/151
- 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, 10, 13, 14, 17 and 18.
The Release7 UE Cat 13, 14, 17 and 18, although they may use MAC-ehs/flexible
Mac-d PDU size (refer to the section 5.5), must also be made eligible to 656 bits MAC-
d PDU size in order to properly handle the cases where MAC-ehs/flexible Mac-d PDU
size can not apply.
Parameter eligibleUeCategoryForHighPerformance Object HsdpaRncConf
Range & Unit BitString 64 bits (0=not eligible, 1=eligible)
User Customer
Class 3
Granularity RNC
Value 0000000000000000000000000000000000000000000000110011001111000000

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. In order to
have categories 13, 14, 17 and 18 eligible to 656 bits, bits #12, #13, #16 and #17 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.

Page 37/151
Parameter minimumUserMbrForHighPerformance Object HsdpaRncConf
Range & Unit Integer [0.. 16 000 000] bit/s
User Customer
Class 3
Granularity RNC
Value 0 (customer dependant)

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 isHsdpaCellHighPerformance Object FDDCell
Range & Unit Boolean {True; False}
User Customer
Class 3
Granularity Cell
Value True

Parameter isDynamicMacdPduSizeManagementAllowed Object RadioAccessService
Range &
Unit
Boolean
{True, False}
User Customer
Class 3
Granularity RNC
Value True

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 if 29797 (multi-service on HSDPA) is enabled
(isMultiRabOnHsdpaAllowed =True).

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.

Page 38/151
Parameter isHighPerformancePduSizeReconfAllowed Object HsdpaRncConf
Range & Unit BitString 64 bits (0=not eligible, 1=eligible), one bit per UE Categorie (Cat. 1 on the
right)
User Customer
Class 3
Granularity RNC
Value 0000000000000000000000000000000000000000000000110011001111000000

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 2
nd
RAB has
the same Mac-d PDU size that the 1
st
one in UA5.1 whereas in UA6.0, the Mac-d PDU size of a 2
nd

RAB can be different)

The following flowchart summarizes the parameters configuration:
isHsdpaCellHighPerformance
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
PDU size reconf. is not allowed
(except in some special cases)
PDU size reconf. is allowed
False
0
> MBR
False
True
1
< MBR
True
0
1
sduRetransmitAfterPduSizeChange
isHsdpaCellHighPerformance
336 bits is used on RNC 336 bits is used on RNC
336 bits is used for Cat.n 336 bits is used for Cat.n
336 bits is used for this ue 336 bits is used for this ue
for this cell
for this cell
for this cell
for this cell
PDU size reconf. is allowed PDU size reconf. is allowed
False
0
> MBR
False
True
1
< MBR
True
0
1
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 HS-
DSCH. 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.

Page 39/151
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).

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

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

Page 40/151
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 sduRetransmitAfterPduSizeChange Object DlRlcAckMode
Range & Unit [none, notTransmitted, notFullyTransmitted, notFullyAcknowledged] Enum
User Customer
Class 3
Granularity RlcConfClass
Value 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]).
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.
Page 41/151
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.
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 activation flag for this feature is
Parameter
is2ndRrcRbReconfNeededForQC7200
Object RadioAccessService
Range & Unit {True, False}, Boolean
User Customer
Class 3
Granularity RNC
Value True

UA6.0-UA7.0 Delta: isRlcReconfigAllowedForR99 parameter name change
After UA6.0, the parameter isRlcReconfigAllowedForR99 will use the name
is2ndRrcRbReconfNeededForQC7200.

Page 42/151
5.3 TRANSPORT BLOCK SIZE OPTIMIZATION
[iCEM]
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).

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.

These new tables are activated via the following class 3 OMC-B parameters:
Parameter ueCategoryX
X =[1..12]
Object HsdpaUeCategoryTransportBlockOptimisation
User Customer
Class 3
Granularity BTSCell
Value True for all UE categories

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.

320 16 21 320 16 Padding
Mac-d SDU = Mac-d PDU
Mac-hs SDU
Mac-hs PDU = 1TTI
RLC SDU
320 16
Page 43/151
UE Category support
[iCEM]
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
Transport Block Size
CQI
Default Optimised Max capability
Number
of
MAC-d
PDU
Modulation
Number
of
HS-
PDSCH
codes
Power offset
Applicable
for
UE
category
1 377 365 1 QPSK 1 +4 dB 1 12
2 377 365 1 QPSK 1 +3 dB 1 12
3 377 365 1 QPSK 1 +2 dB 1 12
4 377 365 1 QPSK 1 +1 dB 1 12
5 377 365 1 QPSK 1 0dB 1 12
6 377 365 1 QPSK 1 -1 dB 1 12
7 377 365 1 QPSK 2 -2 dB 1 12
8 792 699 2 QPSK 2 0dB 1 12
9 792 699 2 QPSK 2 -1 dB 1 12
10 1262 1036 3 QPSK 3 0dB 1 12
11 1483 1380 4 QPSK 3 0dB 1 12
12 1742 1711 5 QPSK 3 0dB 1 12
13 2279 2046 6 QPSK 4 0dB 1 12
14 2583 2404 7 QPSK 4 0dB 1 12
15 3319 3090 9 QPSK 5 0dB 1 12
16 - 30 3440 3440 10 QPSK 5 16 - CQI 11 12
16 3565 3440 10 16-QAM 5 0dB 1 10
17 4189 4115 12 16-QAM 5 0dB 1 10
18 4664 4420 13 16-QAM 5 0dB 1 10
19 5287 5101 15 16-QAM 5 0dB 1 10
20 5887 5782 17 16-QAM 5 0dB 1 10
21 6554 6438 19 16-QAM 5 0dB 1 10
22 7168 7168 21 16-QAM 5 0dB 1 10
23 - 30 7168 7168 21 16-QAM 5 22 - CQI 1 6
23 9719 9546 28 16-QAM 7 0dB 7 10
24 11418 11216 33 16-QAM 8 0dB 7 10
25 14411 14155 42 16-QAM 10 0dB 7 10
26 - 30 14411 14155 42 16-QAM 10 25 - CQI 7 8
26 17237 17237 51 16-QAM 12 0dB 9 10
27 - 30 17237 17237 51 16-QAM 12 26 - CQI 9
27 - 30 20251 60 16-QAM 15 27 - CQI 9
27 - 30 21754 21754 64 16-QAM 15 27 - CQI 10
Table 1: CQI mapping table for 336 bits MAC-d PDU size

Page 44/151
Mac-d PDU size = 656 bits
Transport Block Size
CQI
Default Optimised Max capability
Number
of
MAC-d
PDU
Modulation
Number
of
HS-
PDSCH
codes
Power offset
Applicable
for
UE
category
1 792 686 1 QPSK 2 +7dB 1 - 12
2 792 686 1 QPSK 2 +6dB 1 - 12
3 792 686 1 QPSK 2 +5dB 1 - 12
4 792 686 1 QPSK 2 +4dB 1 - 12
5 792 686 1 QPSK 2 +3dB 1 - 12
6 792 686 1 QPSK 2 +2dB 1 - 12
7 792 686 1 QPSK 2 +1dB 1 - 12
8 792 686 1 QPSK 2 0dB 1 - 12
9 792 686 1 QPSK 2 -1dB 1 - 12
10 792 686 1 QPSK 3 -2dB 1 - 12
11 1483 1356 2 QPSK 3 0dB 1 - 12
12 1742 1356 2 QPSK 3 -1dB 1 - 12
13 2279 2010 3 QPSK 4 0dB 1 - 12
14 2279 4 QPSK 4 -1dB 1 - 12
14 2677 4 QPSK 4 0dB 1 - 12
15 3319 3319 5 QPSK 5 0dB 1 - 12
16 3319 3319 5 QPSK 5 -1dB 1 - 12
17 - 30 3319 3319 5 QPSK 5 15 - CQI 11 - 12
17 4189 3970 6 16-QAM 5 0dB 1 - 10
18 4664 4664 7 16-QAM 5 0dB 1 - 10
19 5287 5287 8 16-QAM 5 0dB 1 - 10
20 5287 5287 8 16-QAM 5 -1dB 1 - 10
21 6554 5993 9 16-QAM 5 0dB 1 - 10
22 7168 6673 10 16-QAM 5 0dB 1 - 10
23 - 30 7168 6673 10 16-QAM 5 22 - CQI 1 - 6
23 - 30 7298 11 16-QAM 5 23 - CQI 1 - 6
23 9719 9210 14 16-QAM 7 0dB 7 - 10
24 11418 11216 17 16-QAM 8 0dB 7 - 10
25 14411 13904 21 16-QAM 10 0dB 7 - 10
26 - 30 14411 13904 21 16-QAM 10 25 - CQI 7 - 8
26 17237 17237 26 16-QAM 12 0dB 9 - 10
27 - 30 17237 17237 26 16-QAM 12 26 - CQI 9
27 - 30 20251 30 16-QAM 15 27 - CQI 9
27 - 30 21754 21754 33 16-QAM 15 27 - CQI 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.

Page 45/151
[iCEM] [xCEM]
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:
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)

For iCEM:
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:
- 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
Parameter ueCategoryX
X =[1..12]
Object HsdpaMaxUeCategoryCapabilityActivation
Range & Unit True, False
User Customer
Class 3
Granularity BTSCell
Value True for all UE categories

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
MAC-d PDU
size
Maximum number
of
MAC-d PDU
hsdschInterval
max (ms)
336 42 90
7 8 14411
656 21 190
336 60 60
9 20251
656 30 130
336 64 60
10 21754
656 33 120
Table 3: Max hsdschInterval value

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

Page 46/151
For iCEM, the recommendation for hsdschInterval is 50ms.
Parameter hsdschInterval Object HsdpaConf
Range & Unit [10500] ms step =10
User Customer
Class 3
Granularity BTSCell
Value 50ms

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
- or when the MAC-hs flow control algorithm determines at the end of the HS-
DSCH 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 table below:
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 7298 22 7168 21
7 to 8 14411 25 14155 42
9 20251 27 20251 60
10 27952
27 (iCEM)
29 (xCEM)
21754 (iCEM)
23792 (xCEM)
64 (iCEM)
70 (xCEM)
11 to 12 3630 16 3440 10
MAC-d PDU size = 656 bits
Ue
category
Maximum HS-DSCH
TBS per TTI
Maximum
MCS
TBS applied from
maximum MCS
Max MAC-d
PDUs
1 to 6 7298 23 7298 11
7 to 8 14411 25 13904 21
9 20251 27
20251 (iCEM)
19891 (xCEM)
30
10 27952
27 (iCEM)
30 (xCEM)
21754 (iCEM)
26490 (xCEM)
33 (iCEM)
40 (xCEM)
11 to 12 3630 15 3319
5

Page 47/151
MAC-d PDU size = flexible
Ue
category
Maximum HS-DSCH
TBS per TTI
Maximum
MCS
TBS applied from
maximum MCS
Max MAC-d
PDUs
1 to 6 7298 23 7152 N/A
7 to 8 14411 25 13940 N/A
9 20251 27 19904 N/A
10 and 16 27952 30 26504 N/A
11 to 12 3630 15 3576 N/A
13, 17 and
19
35280
30
30
27464 with 16QAM
35280 with 64QAM
N/A
14, 18 and
20
42192
30
30
27464 with 16QAM
39984 with 64QAM
N/A
15 23370 28 22968 N/A
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:
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 (assuming Maximum TBS per TTI)

Page 48/151
Table 6: Iub bandwidth per number of E1 links

5.4 TFRC SELECTION
[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,
16QAM and 64QAM (when the feature 34386 64 QAM for HSDPA is enabled) can
be used whatever the number of HS-PDSCH codes.

UA6.0-UA7.0 Delta: Modulation
In UA6.0, the scheduler can only use the QPSK and the 16QAM modulation.
In UA7.0, with the introduction of the xCem feature 34386 64 QAM for HSDPA, the scheduler is able
to use the 64QAM modulation in order to reach higher throughput

[iCEM]
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. 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.

5.4.1 FLEXIBLE MODULATION (34102) iCEM ONLY
This feature consists in choosing the modulation (QPSK or 16-QAM) which is the most
efficient regarding the situation (HS-PDSCH 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:
E1 1 E1
(Kbps)
2 E1
(Kbps)
3 E1
(Kbps)
4 E1
(Kbps)
5 E1
(Kbps)
6 E1
(Kbps)
7 E1
(Kbps)
8 E1
(Kbps)
IuB
bandwidth
1 920 3840 5760 7680 9600 11520 13440 15360
Page 49/151
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
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.

Mapping
tables
- Number of remaining codes
- ue category
- mac-d PDU size
- Modulation =16QAM
- TBS
- Power offset
Mapping
tables
- ue category
- mac-d PDU size
- Modulation =16QAM
- TBS
- 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.
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
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
for category 10). Based on these inputs, TFRC will be selected to maximize the
throughput.
Page 50/151

Mapping
tables
- mac-d PDU size
- ue category
- Modulation =QPSK
- TBS
Mapping
tables
- mac-d PDU size
- ue category
- Modulation =QPSK
- TBS

Figure 9: Code boost

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

Activation
Parameter hsdpaFlexibleModulationVsCodeActivation Object HSDPAConf
Range & Unit Boolean {True, False}
User Customer
Class 3
Granularity BTSCell
Value True

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

5.4.2 64 QAM FOR HSDPA (34386) xCEM ONLY
5.4.2.1 DESCRIPTION
From UA7, the xCem scheduler can use the 64QAM modulation to transmit the HS-
DSCH channel for the UE supporting the 64QAM modulation.

The 64QAM usage allows to increase the HSDPA throughput in two cases:
- Case without code limitation: 64QAM allows higher peak throughputs in very
good radio conditions (21.6 Mbps on the physical layer in the DL instead of
14.4 Mbps with 16QAM)
- Case with code limitation: 64QAM can also be used in code limited situations
to increase the data rate for users in good radio conditions.

The usage of the 64QAM modulation needs some system modifications:
New UE categories
New CQI mapping tables
New Look Up Tables
Page 51/151
New format for the HS-SCCH
New slot format for the HS-PDSCH
Mac-ehs configuration

New UE categories
New UE categories have been introduced in order to support the 64QAM modulation:
- Category 13 and 14 (64-QAM capable only),
- Category 17 and 18 (64-QAM or MIMO capable)
Since MIMO is not supported in UA7, UE category 17 and 18 are handled respectively
as category 13 and 14. Note that these UE categories are MAC-ehs capable.

New CQI mapping tables
64QAM modulation allows bigger Transport Blocks (TB) than before and hence a new
TB Size table is introduced, allowing TB sizes of up to 42192 bits (21.1Mb/s @ mac-
hs):
I D G D 18
H C F C 17
I D N/A D 16
H C N/A C 15
N/A G D 14
N/A F C 13
N/A E 11 and 12
N/A D 10
N/A C 9
N/A B 7 and 8
N/A A 1-6
In case of dual
transport block
type A CQI
reports
In case of type B or single
transport block type A
CQI reports
MIMO configured 64QAM
configured
64QAM/MIMO not
configured
Used CQI mapping table Category
I D G D 18
H C F C 17
I D N/A D 16
H C N/A C 15
N/A G D 14
N/A F C 13
N/A E 11 and 12
N/A D 10
N/A C 9
N/A B 7 and 8
N/A A 1-6
In case of dual
transport block
type A CQI
reports
In case of type B or single
transport block type A
CQI reports
MIMO configured 64QAM
configured
64QAM/MIMO not
configured
Used CQI mapping table Category

Figure 10: CQI mapping tables

These new CQI mapping tables (defined in [R02]) are used to translate the CQI values
into a recommended maximum TB size and a modulation scheme (allowing the
64QAM capable UE to propose the usage of TFRC including 64QAM). With a high
CQI value (good channel quality) the UE can indicate that 64QAM can be used.

The maximum Transport Block Sizes allow thanks to mac-ehs and 64QAM are given
in Table 4.

Page 52/151
New Look Up Tables
New LUT are used to allow scheduler selecting the higher TB size for 64QAM
modulation format.

New format for the HS-SCCH
As described in Vol.2, the HS-SCCH channel contains several control information
including the modulation scheme.
The current HS-SCCH format allows only to select 2 types of modulation: QPSK and
16QAM. That is why the HS-SCCH format is modified in order to be able to select 3
types of modulation: QPSK, 16QAM and 64QAM: If 64-QAM has been configured for
the HS-DSCH, the modulation scheme information bit can only tell the UE whether
QPSK is used (value 0) or not (value 1). The choice between 16-QAM or 64-QAM is
known from the last bit of channelization code set information (see Vol.2 for more
information concerning the HS-SCCH format).

New slot format for the HS-PDSCH
As explained in Vol.2, a new slot format is introduced for the 64QAM modulation (960
bits/slot):
960 960 2880 16 240 1440 2(64QAM)
640 640 1920 16 240 960 1(16QAM)
320 320 960 16 240 480 0(QPSK)
Ndata Bits/
Slot
Bits/ HS-DSCH
subframe
SF Channel Symbol
Rate (ksps)
Channel Bit
Rate (kbps)
Slot format #i
960 960 2880 16 240 1440 2(64QAM)
640 640 1920 16 240 960 1(16QAM)
320 320 960 16 240 480 0(QPSK)
Ndata Bits/
Slot
Bits/ HS-DSCH
subframe
SF Channel Symbol
Rate (ksps)
Channel Bit
Rate (kbps)
Slot format #i

Table 7: HS-PDSCH Slot formats

The theoretical peak data rate with 64-QAM is therefore 15 codes x 2880 bits / 2 ms =
21,6Mbit/s (physical channel bit rate), which have to be compared to the 14,4Mbit/s
peak rate available with 16-QAM.

Mac-ehs configuration
Mac-ehs has to be configured in order to allow the usage of 64QAM because the
selection of the modulation scheme is done in the MAC-ehs as part of the Transport
Format Resource Combination (TFRC) selection function (Note that the MAC-ehs can
be configured by the RNC without allowing the usage of 64QAM). See 5.5 for more
details on Mac-ehs.

5.4.2.2 CONFIGURATION
The 64QAM modulation is configured if the following conditions are fulfilled:
- The NodeB is 64QAM capable: The NodeB indicates to the RNC its 64QAM
capability through the SixtyfourQAM DL Capability IE in the NBAP Audit Response
or Resource Status Indication messages
Page 53/151
- The UE is 64QAM capable: The UE informs the RNC of its capabilities in the RRC
Connection Setup Complete message:
- MAC-ehs support IE concerning the support of the MAC-ehs/RLC flexible
size feature (3GPP R7).
- HS-DSCH physical layer category extension IE corresponding to the HS-
DSCH category supported by the UE when Mac-ehs is configured (If the Mac-
ehs is not configured, the SRNC doesnt use this IE but the HS-DSCH
physical layer category IE, corresponding to the HS-DSCH category
supported by the UE when MAC-ehs is not configured)
- The NodeB is allowed to used the 64QAM:
RadioAccessService.isDl64QamOnRncAllowed =True
FDDCell.isDl64QamAllowed =True
Mac-ehs enabled
- The UE category is allowed to used the 64QAM:
HsdpaRncConf. is64QamAllowedForUeCategory = 1 for all the UE
categories supporting 64QAM, that is to say 13,14,17,18

If all these conditions are fulfilled, then the NodeB will send the new HS-SCCH to
inform the UE of the modulation used (QPSK, 16QAM or 64QAM).

In case of call mobility toward a cell where HSDPA is enabled by iCEM (64 QAM is
only supported by xCEM), a reconfiguration disabling 64QAM is triggered and vice
versa. On iCEM UE category 13 and above are handled as category 10.
Mobility of a 64-QAM capable UE between two 64-QAM capable serving cell is
supported.
64 QAM is not supported over Iur (as mac-ehs). ALU SRNC will reconfigure the call to
MAC-hs when the serving cell moves under the control of a DRNC. ALU DRNC will
not advertive MAC-ehs and 64-QAM support over the Iur. If a SRNC decides to use
MAC-ehs and/or 64-QAM over the Iur, ALU DRNC will refuse the configuration.

5.4.2.3 PARAMETERS SETTINGS
Parameter isDl64QamOnRncAllowed Object RadioAccessService
User Customer
Class 3B
Granularity RNC
Value True

Page 54/151
Parameter isDl64QamAllowed Object FDDCell
User Customer
Class 3B
Granularity FDDCell
Value True

Parameter is64QamAllowedForUeCategory Object HsdpaRncConf
Range & Unit BitString 64 bits (0=not allowed, 1=allowed)
User Customer
Class 3B
Granularity RNC
Value 00000000000000000000000000000000000000000000000110011000000000000
1 for all the UE categories supporting 64QAM, that is to say 13,14,17,18

Note that the following parameters are not used in this release:
RemoteFDDCell.isDl64QamAllowed
NeighbouringRNC.isIurDlQam64Allowed
NeighbouringRNC.isIncoming3Gto3GWithIur64QAMAllowed

Page 55/151
Engineering Recommendation: 64 QAM modulation and number of available HS-PDSCH
The maximum throughput by using 64QAM modulation is reached when the maximum number of HS-
PDSCH codes are available (max throughput obtained with 15 HS-PDSCH).
The maximum number of HS-PDSCH codes can be obtained when the Fair Sharing feature is enabled
(up to 15 HS-PDSCH) but depends also on the codes configuration (number of S-CCPCH, number of
HS-SCCH, number of E-HICH/ERGCH, number of E-AGCH).

The following configuration allows to have up to 15 HS-PDSCH codes (Mono-S-CCPCH, 2 HS-SCCH,
1 E-HICH/E-RGCH, 1 E-AGCH):
SF8 SF16 SF32 SF64 SF128 SF256
0 P-CPICH
1 P-CCPCH +SCH
2 AICH
3 PICH
4
5
6
7
8
9
10
11
12
13
14 E-AGCH
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2 HS-PDSCH #14
3 HS-PDSCH #13
4 HS-PDSCH #12
5 HS-PDSCH #11
6 HS-PDSCH #10
7 HS-PDSCH #9
8 HS-PDSCH #8
9 HS-PDSCH #7
10 HS-PDSCH #6
11 HS-PDSCH #5
12 HS-PDSCH #4
13 HS-PDSCH #3
14 HS-PDSCH #2
15 HS-PDSCH #1
5
6
7
HS-PDSCH #15
1
2
3
4
10
11
13
7
14
15
7
E-HICH +E-RGCH
1
2
4
8
9
3
6
12
S-CCPCH #1
3
1
2
4
5
HS-SCCH #1
3
6
HS-SCCH #2
0
1
1
2
0
0
0
0
5

If the number of S-CCPCH or HS-SCCH or E-HICH/E-RGCH or E-AGCH is higher, the maximum
number of available HS-PDSCH codes will be lower than 15 and then the maximum throughput will
not be reachable due to code limitation.

Page 56/151
Engineering Recommendation: Pre-requisites to reach the maximum throughput with 64QAM
The following pre-requisites are needed to reach the maximum throughput with 64QAM:
Domain Pre-requisite Comment
1-
Feature
UTRAN Licensing feature (34454)
configured to allow max
throughput

2-
Software
SGSN R6 and GGSN R6 No need to have SGSN R7 or GGSN R7
3-
Hardware
Hybrid Iub or Native IP Iub (xCcm
on NodeB and GIGe on RNC
needed)
In order to achieve high throughput, ATM BW (8 E1s) is not sufficient and
Hybrid Iub is recommended.
3-
Hardware
RNC Packet server : DCPS or
PSFP
DCPS (Dual Core Packet Server) allows to support higher throughput than
PSFS in the RNC but nevertheless PSFP is enough (PSFP can support up to
2 R7 ue using 64QAM at the max throughput in 2 different BTS with the
same PMC-RAB (worst case))
4- Setting Maximum number of HS-PDSCH
codes (15)
Fair Sharing enabled (Dyn codes mgt part):
BTSEquipment / hsdpaCodeTreeManagementActivation =True
FDDCell / isHsxpaR99ResourcesSharingOnCellAllowed =True

1 SF16 used for ccc including multiple S-CCPCH, HS-SCCH and DL
HSUPA codes (for ex: 1 S-CCPCH +2 HS-SCCH +1 E-AGCH +1 E-
HICH/E-RGCH)
4- Setting Avoid PA power saturation PA power saturation leads to a unstable CQI at 30 impacting the throughput.
A "backoff power" of -2dB is yet implemented to avoid this issue by reducing
the allocated power.
If needed, maxHspaPowerOffset can also be changed to reduce the
available power (PmaxHsdpa =Phsdpa =Pcell - maxHspaPowerOffset)
4- Setting UL bearer allowing:
- throughput high enough to
acknownledge the high DL
throughput
- UL BLER around 0%
HSUPA with 10ms TTI (2ms TTI is not mandatory)
or UL 384 (if rab adaptation is disabled) with minSirTargetHsdpa =4.7dB
4- Setting Correct L2I setting RadioAccessService / HsdpaRncConf / DlRlcQueueSizeForUeCat =512
RLC SDU for Cat.14
RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode /
prohibitedStatusTimer =10ms
4- Setting Correct ATM setting RadioAccessService/ HsdpaRncConf /
minimumHsdschCreditPerTtiInBytes =2296
RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize =1520
Maximum value for txQueueLimit of Access Node according the ATM card
4- Setting Correct Hybrid Iub setting RadioAccessService/ HsdpaRncConf /
minimumHsdschCreditPerTtiInBytes =1456
RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize =1472
4- Setting Correct Iub congestion
management setting
If not correctly set, the throughput can fluctuate very strongly and we couldnt
get more than 2 or 3Mbps max (some time less than 1M)

RNC/ RNCEquipment / INode / EM / RncIn / Cm / activation =
discardAndBackPressure
RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolCellColor =
enabled
RNC/ RNCEquipment / INode / EM / RncIn / Cm /
bwPoolQosBackPressureThreshold =0,0,95,95
RNC/ RNCEquipment / INode / EM / RncIn / Cm /
bwPoolQosDiscardThreshold =0,0,350,500
RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa congDRTAllowed
=enabled (no impact on performances
Page 57/151
RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa congFSNAllowed
=enabled (no impact on performances)
5- RF High CQI Throughput becomes higher for Cat.14 compared to Cat.10 when CQI >23
6- Traffic Low cell load In order to have no resource limitation
7- Core Correct Ethernet switch (PSAX,
Omniswitch) configuration

7- Core Correct FTP server configuration If the FTP server has a limited configuration and could not be changed, high
throughput could be achieved by establishing 2 (or more) FTP sessions in
parallel
7- Core Correct GGSN configuration In order to avoid any DL throughput limitation
7- Core Correct SGSN configuration In order to avoid any DL throughput limitation
7- Core Correct User Equipment and PC
client configuration
In order to avoid any DL throughput limitation
7- Core Correct VPN and Firewall
configuration
In order to avoid any DL throughput limitation
7- Core No Maximum Bit Rate (MBR)
limitation
Ranap MBR higher than the max throughput and Iu Source Conformance
disabled (If Source Conformance is On, the RNC will limit the HSDPA
throughput to min(MBR;maximumTokenGenerationRate))

The following pre-requisites are needed in order to be able to use 64QAM :
Domain Pre-requisite Comment
1-
Feature
34386 "34386 64
QAM for HSDPA "
enabled
RadioAccessService / isDl64QamOnRncAllowed =TRUE
HsdpaRncConf / is64QamAllowedForUeCategory =1 for Cat. 13,14,17,18
FDDCell / isDl64QamAllowed =TRUE
1-
Feature
34388 "L2
improvements :
flexible RLC & MAC-
ehs" enabled
64QAM can be configured only if MAC-ehs is configured first
MAC-ehs is a pre-requisite for 64-QAM (MAC-ehs is an enhancement of MAC-hs
protocol that allows higher throughputs thanks to flexible RLC PDU size (and thus
bigger), relaxing UE processing constraints and RLC window blocking issues). The
events leading to de-configure MAC-ehs shall also lead to de-configure 64QAM.

RadioAccessService / isMacehsAllowed =TRUE
FddCell / isMacehsAllowed =TRUE
2-
Software
RNS upgraded in UA7
3-
Hardware
3GPP R7 UE
3-
Hardware
xCEM with iBTS and
UCUIII with oneBTS

Page 58/151
5.5 LAYER 2 ENHANCEMENTS: FLEXIBLE RLC AND MAC-EHS
The UA7.0 feature 34388 Layer 2 Enhancements: flexible RLC and Mac-ehs allows
to support the high HS-DSCH data rate offered by Rel7 UEs (category 13, 14, 15, 16,
17, 18).
It overcomes the RLC window blocking issues (thanks to bigger PDUs) and the UE
processing limits (RLC reassembly) (less PDU to reassemble).
The protocols involved in this feature are
the Mac-ehs (at Nodeb), the RLC (at RNC and UE sides) : see section 5.5.1
and the IUB Frame Protocol (at RNC and Nodeb) : see section 5.5.2
This feature is applicable only for xCEM and UCU-III.

5.5.1 FLEXIBLE RLC AND MAC-EHS
MAC-ehs: enhanced MAC-hs layer. MAC-ehs brings the possibility to handle MAC-d
PDU of variable size, to multiplex MAC-d PDU from different priority queues in the
same MAC-ehs PDU (not used in this release) and to segment MAC-d PDUs over
multiple MAC-ehs PDUs (and hence minimize padding at MAC-ehs level).
A MAC-ehs PDU is composed of one or several reordering PDU, where:
Reordering PDU is a set of reordering SDUs belonging to the same priority
queue
Reordering SDU is a complete MAC-d PDU (ie. MAC-ehs SDU) or a
segmented MAC-d PDU
In this release, a MAC-ehs PDU is composed of only one reordering PDU.
MAC-ehs supports up to 26 MAC-d PDUs per MAC-ehs frame.

Flexible RLC: instead of using fixed RLC PDU sizes (320 bits or 640 bits), the size of
a RLC PDU can vary up to a maximum size (internal to the RNC) which is determined
based on the data rate offered over the radio.
When a call is configured with MAC-ehs, each RLC AM entity may operate in either
fixed size mode (pre-Rel7) or flexible size mode (Rel7).
With RLC flexible mode, the SRNC may determine the size of the RLC PDU
independently of the other RLC PDU, respecting a maximum PDU size (which can be
up to 1500 bytes, i.e. a complete SDU. 1500 bytes is the maximum size of an IP
packet, as defined by the IP protocol). It permits to use big PDU sizes, thus avoiding
RLC blocking situations. It also permits to avoid adding padding to the data to fit the
PDU size.
Alcatel-Lucent SRNC will always segment the SDU to this maximum PDU size. It will
build a PDU smaller than this maximum size only if the SDU (or the last segment of
the SDU) is smaller than this maximum PDU size. Alcatel-Lucent SRNC will not
concatenate segments of two different SDUs in the same PDU as there is nearly no
Page 59/151
interest to do so (there is no padding to add). It will also not piggyback a STATUS
PDU into an AMD (Aknowledge Mode Data) PDU.
In case of reconfiguration to DCH or HS-DSCH/MAC-hs, the RB using RLC flexible
mode needs to be reconfigured to fixed mode, implying an RLC one-sided re-
establishment of the downlink.
In case reconfiguration from HS-DSCH/MAC-hs or DCH to HS-DSCH/MAC-ehs, the
RB can be reconfigured to RLC flexible mode, without need for RLC re-establishment
(because Alcatel-Lucent SRNC uses LI=7 bits for both fixed and flexible modes).
However, if LI=15 bits is used for flexible mode (by modifying a static parameter in the
RNC) then an RLC one-sided re-establishment is needed. (LI stands for Length
Indicator, this field in a PDU specifies the end of an SDU within the PDU).
Refer to the Volume 6 for more details on the mobility scenarios involving
reconfiguration from HS-DSCH/MAC-hs or DCH to HS-DSCH/MAC-ehs and reversely.
As the PDU size is variable, the polling method based on the number of PDU sent
becomes meaningless. It is superseded by a new method based on a number of bytes
sent (fresh data or retransmitted data). This is controlled by the parameter
nbrOfBytesBetweenPolling in DlRlcAckFlexibleMode.
The benefit of the flexible RLC and MAC-ehs are illustrated in the next picture.
Page 60/151
Figure 11 : Benefits of flexible RLC and Mac-ehs versus fixed RLC and Mac-hs
Pad.
Pad.
Mac-hs
header
MAC-hs SDU
User Payload
RLC SDU
RLC PDU (fixed size)
MAC-d PDU
MAC-hs PDU
Transport Block Size (based on TRFC selection)
Mac-hs
header
Mac-ehs
header
Reordering SDU 1
User Payload
RLC SDU
RLC PDU (flexible size)
MAC-d PDU
= Mac-ehsSDU
MAC-ehs
PDU
Transport Block Size (based on TRFC selection)
Mac-ehs
header
MAC-d PDU 1 MAC-d PDU 2 MAC-d PDU 3

Reordering SDU 2
Reordering PDU
(1)
(2)
(3)
(1)
(2)
(3)
(1) The RLC SDU segmentation into fixed size RLC PDUs may lead to padding in RLC PDU
(2) The Transport Block Size is the result of the TRFC selection algorithm. A non negligible number of
padding bits may be required to fit the Transport Block Size.
(3) In case of very bad radio condition, the selected Transport Block Size may be too small to contain a
fixed-size MAC-d PDU: the UE is not scheduled
(1) No need for padding as RLC PDU size can be adjusted to fit exactly the size of the RLC SDU
(2) Padding bits are reduced as MAC-ehs can segment a MAC-d PDU in case it cannot fit into the selected
Transport Block
(3) Even if very bad radio conditions when the MAC-ehs transport block cannot fit an RLC PDU, a UE can
be scheduled thanks to segmentation at MAC-ehs level

Page 61/151
Selection criteria:
The selection of Mac-ehs is done on a per call basis.
MAC-ehs (known also as flexible MAC-d PDU size format on NBAP/RNSAP) is
selected if the following conditions are fulfilled:

The UA7.0 feature 34388 Layer 2 Enhancements : flexible RLC and Mac-ehs
is active (isMacehsAllowed at RNC level is TRUE)
UE supports MAC-ehs (as per UE capabilities)
Node B handling the serving cell support MAC-d PDU flexible size format (as
per Node B capability given in NBAP HS-DSCH MAC-d PDU Size Capability
IE), ie. HSDPA is handled by [xCEM] or [UCU-III]
The serving cell is controlled by SRNC (i.e., not by a drift RNC)
isMacehsAllowed at FDDCell level is TRUE for the serving cell (and for all
unlocked- HSDPA cells of the same carrier of the same Node B)

In this case, MAC-ehs is used and all radio-bearers are mapped on MAC-ehs
reordering queues. The selection of the RLC mode (fixed or flexible) is done on a per
radio bearer basis.
If the RB is mapped on HS-DSCH and if MAC-ehs/flexible MAC-d PDU size format is
selected for the call, the SRNC will use RLC flexible size for this RB in the following
cases:
RAB is PS I/B. The used maximum PDU size will be the one specified by the
parameter macehsMaximumPduSizePsIb in HsdpaRncConf.
RAB is PS Streaming and parameter isRlcFlexibleSizeForPsStrAllowed in
HsdpaRncConf is TRUE. The used maximum PDU size will be the one
specified by parameter macehsMaximumPduSizePsStr in HsdpaRncConf.

Parameters:
The feature Layer 2 Enhancements (Flexible RLC and Mac-ehs) is activated as
Parameter isMacehsAllowed Object RadioAccessService
User Customer
Class 3
Granularity RNC
Value True

Parameter isMacehsAllowed Object FDDCell
User Customer
Class 3
Granularity FDDCell
Value True

Page 62/151
Note that the following parameters are defined since UA7.0 but not used.
isMacehsAllowed in the object NeighboringRNC
isMacehsCapable in the object RemoteFDDCell
isMacEhsAllowedForUeCategory in HsdpaRncConf

The selection of the RLC mode (flexible or fixed) for a PS Streaming Radio Bearer of a
call using Mac-ehs format, is driven by the parameter
isRlcFlexibleSizeForPsStrAllowed
Parameter isRlcFlexibleSizeForPsStrAllowed Object HsdpaRncConf
User Customer
Class 3
Granularity RNC
Value True

The maximum MAC-d PDU size to be used by the RLC layer at RNC side, when
operating in flexible mode, is configurable through two parameters (one for PS I/B
Radio Bearer, one for PS Str Radio Bearer). Its minimum value is 42 bytes -
corresponding to 336 bits, its maximum value is 1504 bytes limited by the 3GPP
standards.

The maximum MAC-d PDU size for a PS I/B Radio Bearer, is configured with
parameter macehsMaximumPduSizePsIb.
Parameter macehsMaximumPduSizePsIb Object HsdpaRncConf
Range & Unit [42..1504] unit : bytes
User Customer
Class 3
Granularity RNC
Value 378

The maximum MAC-d PDU size for a PS Streaming Radio Bearer, is configured with
parameter macehsMaximumPduSizePsStr
Parameter macehsMaximumPduSizePsStr Object HsdpaRncConf
Range & Unit [42..1504] unit : bytes
User Customer
Class 3
Granularity RNC
Value 378

Engineering Recommendation: maximum MAC-d PDU size when RLC operates in flexible mode
Although the configurable maximum MAC-d PDU size may be up to 1504 bytes, it is recommended to
configure it to 378 bytes, in order to cope with PS ciphering constraints (when MAC-d PDU size gets
bigger than 378 bytes, the efficiency of the ciphering degrades).

Page 63/151
dlRlcQueueSizeForUeCat defines the size of the buffers in the RNC. It configures the
number of incoming SDUs that RLC can hold in order to wait for transmission
(irrespective of RLC mode being fixed or flexible). The value dlRlcQueueSize in the
DlRbSetConf/PS_HSDSCH_xxx are not used. Instead the value from
HsdpaRncConf/DlRlcQueueSizeForUeCat table is used.
Parameter dlRlcQueueSizeForUeCat Object HsdpaRncConf
Range & Unit List of 24 elements (one per Ue Category) in the range [0..2048]; unit : number
of RLC SDUs
User Customer
Class 3
Granularity RNC
Value (256,256,256,256,256,256,256,256,256,256,256,256,512,512,256,256,512,
512,256,256,256,256,256,256)
i.e 256 for all UE categories except 13, 14, 17, 18, 512 for UE categories 13,
14, 17, 18

UA6-UA7 Delta: DL RLC queue size for HSDPA RB
In UA6, the DL RLC queue size for the HSDPA RB was specified through the parameter
dlRlcQueueSize in DlRbSetConf/PS_HSDSCH_xxx. To cope with the limited range of this parameter
[1..128], the value was internally doubled by the software. The recommended value was 128, giving an
effective value of 256.
In UA7, the DL RLC queue size for the HSDPA RB is specified, for each UE category, through the
parameter dlRlcQueueSizeForUeCat in HsdpaRncConf. This parameter has a larger range [1..2048].
The recommended value is 256 except for the high rate capable UEs (categories 13, 14, 17, 18) for
which the recommended value is 512.
Note: the parameter dlRlcQueueSize in DlRbSetConf remains applicable for all RB other than HSDPA
RB.

rlcRetransmissionBufferInKbytes defines the size of the RLC
retransmission/reassembly buffer (internal RNC User Plane software limit). It is used
for both RLC fixed mode and RLC flexible mode). It is defined as a function of the
MBR.
Parameter rlcRetransmissionBufferInKbytes Object HsdpaRncConf
Range & Unit List of 16 elements as a function of the MBR.
1st element applies for MBR rate 4000 kBytes/s;
2nd applies for 4000kBytes/s <MBR rate 8000kBytes/s and so on.
Each element is in the range [1..1500]; unit : kBytes.
Only the first element is used, as the UTRAN does not use MBR rate higher
than 4000 kBytes/s
User Customer
Class 3
Granularity RNC
Value 500,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128

maxIubHsDschFrameSize defines the maximum size of an Iub HS-DSCH Frame
excluding all headers and tails of the transport layer protocol such as ATM or IP
headers. (This parameter is not introduced by the feature 34388, but its range is
modified).
Page 64/151
Parameter maxIubHsDschFrameSize Object HsdpaRncConf
Range & Unit [1..1520] ; unit : bytes
User Customer
Class 3
Granularity RNC
Value 1472 on Hybrid Iub
1520 on ATM

Rule: maxIubHsDschFrameSize
The maximum Iub Hs-Dsch Frame size depends on the type of transport on IUB.
IUB over ATM: it is recommended to configure maxIubHsDschFrameSize to 1520 bytes, which
corresponds to the 3GPP maximum MAC-d PDU size (1504 bytes) +the maximum HS-DSCH FP
header (16 bytes).
IUB over IP: The configuration of the parameter maxIubHsDschFrameSize shall be consistent with
the configuration of the MTU (Maximum Transmit Unit, i.e the maximum size of an IP packet).
Considering that the MTU is 1500 bytes on most IP networks, maxIubHsDschFrameSize must be
configured to 1472 bytes, which corresponds to the MTU (1500 bytes) - IP header (20 bytes) - UDP
header (8 bytes).
This value ensures that no fragmented datagrams are transmitted to the NodeB, hence it allows
avoiding IP re-assembly at NodeB side so that the performances are optimized.
In addition it shall be considered that as soon as IP is activated on one Iub interface OR one Iur
interface of a given RNC, the maximum HS-DSCH frame size in this RNC
(MaxIubHsDschFrameSize ) must be configured to MTU - 20 (IP header) - 8 (UDP header).

minimumHsdschCreditPerTtiInNumberOfPdus defines the minimum number of
RLC PDUs to schedule per TTI for Fixed RLC mode; it does not apply in congestion
recovery case.
Parameter minimumHsdschCreditPerTtiInNumberOfPdus Object HsdpaRncConf
Range & Unit [1..255], unit : nb of PDU
User Customer
Class 3
Granularity RNC
Value 14

minimumHsdschCreditPerTtiInBytes defines the minimum number of bytes to
schedule per TTI for Flexible RLC mode; it does not apply in congestion recovery
case.
Parameter minimumHsdschCreditPerTtiInBytes Object HsdpaRncConf
Range & Unit [42..8191] ; unit : bytes
User Customer
Class 3
Granularity RNC
Value 1456 on Hybrid Iub
2296 on ATM

Page 65/151
hsdschCreditCapInNominalRatePercentage defines the upper HS-DSCH credit
limit in term of percentage of the nominal rate. It is used internally by the RNC to
compute the inflated rate in congestion recovery or idle-to-burst scenarios.
Parameter hsdschCreditCapInNominalRatePercentage Object HsdpaRncConf
Range & Unit [100..1000] ; step 10 ; unit : %
User Customer
Class 3
Granularity RNC
Value 400

Under RlcConfClass, the object DlRlcAckFlexibleMode gathers the configuration of
the RLC AM flexible mode. It contains almost the same set of parameters than the
object DlRlcAckMode (used for RLC AM fixed mode), the differences consist in: the
removal of the parameter minimumTransmissionWindowSize and the addition of
the parameter nbrOfBytesBetweenPolling. The other parameters in the object
DlRlcAckFlexibleMode are described in UPUG Volume 3.

The parameter nbrOfBytesBetweenPolling specifies the interval in number of bytes
between pollings (pollings from transmitter to receiver).
Parameter nbrOfBytesBetweenPolling Object DlRlcAckFlexibleMode
Range & Unit
User Customer
Class 3
Granularity RlcConfClass
Value 10000

Reconfiguration of existing PS RB during PS RB Setup/Release:
New PS RAB assignment cases:
When a first RB has been established with RLC flexible mode and there is an
incoming RAB ASSIGNMENT that needs to fallback the call to MAC-hs or all RB to
DCH (like CAC failure or iMCTA handover to a non MAC-ehs cell), the first RB must
be reconfigured to RLC fixed mode.
In UA07.0/UA07.1, the RAB ASSIGNMENT of the 2nd RAB will fail.
When a first RB is already established on DCH (for any reason) and there is an
incoming RAB assignment which dictates to select RLC flexible mode: In
UA07.0/UA07.1, this 2nd RAB establishment is only possible on DCH;
When the UE is in CELL-FACH state, (and there is an incoming RAB assignment
which authorizes to switch to CELL-DCH and to select RLC flexible mode): In
UA07.0/UA07.1, this second RAB establishment and switch to CELL-DCH state is
only allowed towards either Mac-hs (2 flows of 336) or DCH (336-Mux);
PS RAB release cases:
When several RBs are established on DCH (for any reason) and the incoming RAB
release allows transitioning the remaining RBs to RLC flexible/MAC-ehs:
In UA07.0/UA07.1, transition to MAC-ehs is not possible and it is replaced by possible
transitions to MAC-hs or fallback to DCH.
Page 66/151
5.5.2 IUB FRAME PROTOCOL
HS-DSCH Data Frame type 2 is introduced, with the following specificities: the MAC-d
PDUs of a given size are grouped in a given block, and the Logical Channel Id IE is
provided to support MAC-ehs Logical Channel mapping. HS-DSCH Capacity
Allocation type 2 is introduced, with the following specificity: the credits requested by
the Nodeb are given in number of bytes (instead of in number of MAC-d PDU).
HS-DSCH Data Frame type 2 and HS-DSCH Capacity Allocation type 2 are used
when the Mac-ehs is used for the UE (regardless of the RLC mode fixed or flexible).
The feature 34388 Layer 2 Enhancements: flexible RLC and Mac-ehs also introduces
some enhancements in the IUB Flow Control mechanism.
Xoff, Xoff timer expiry, Xon with slow start is kept unchanged
The slow-start parameters (slow-start curve, activation) are configurable
through the object RadioAccessService/RbCongestionControl
The slow start is extended to the Idle-to-Burst case (in addition to the
Congestion Recovery case), when new data arrive from the Core Network
after an idle period. The definition of the idle period is defined as a static
parameter in the RNC and is provisioned to be 20ms.
The unused credits are redistributed on top of the nominal rate (they were lost
in UA6.0).

The objects in the RAN model used to configure the Rb Congestion Control are shown
in the figure below.
Figure 12 : RB congestion control Object Tree

Radio Access
Service
RNC
RbCongestionControl
HsDschSlowStart dchSlowStart
HsDschSlowStart
HsDschSlowStart
HsDschSlowStart
Page 67/151
The parameter dchSlowStartActivation activates the congestion control for DCH RB.
Parameter dchSlowStartActivation Object RbCongestionControl
User Customer
Class 3
Granularity Radio Access Service
Value True

The parameter hsdschSlowStartActivation activates the congestion control for
HSDPA RB.
Parameter hsdschSlowStartActivation Object RbCongestionControl
User Customer
Class 3
Granularity Radio Access Service
Value True

Four HsDschSlowStart instances are created by default, they store the slow start
parameters for four scenarios: respectively Fixed RLC Recovery from Burst,
Flexible RLC Recovery from Burst, Fixed RLC Recovery from Congestion,
Flexible RLC Recovery from Congestion.

The parameter hsdschSlowStartPeriod gives the slow start period for HS-DSCH
Parameter hsdschSlowStartPeriod Object HsDschSlowStart
Range & Unit [0..20] step 2, unit ms
User Customer
Class 3
Granularity HsDschSlowStart
Value HsDschSlowStart/burstFixed : 0
HsDschSlowStart/burstFlexible : 0
HsDschSlowStart/congestionFixed : 20
HsDschSlowStart/congestionFlexible : 20
Note: the value 0 for hsdschSlowStartPeriod disables the slow start mechanism

It is not recommended to activate the Recovery from Burst slow start at RNC level,
because the Rate Adaptative Flow Control (RAFC) at Nodeb level ensures an
adequate behaviour in case of burst. The value 0 for the two instances burstFixed and
burstFlexible deactivates the slow start mechanism at RNC level.
The parameter hsdschSlowStartRate defines the slow-start ramp-up rate in
percentage from minBR/GBR to the inflated rate. The inflated rate is the nominal rate
plus unused credits from the previous part of the scheduling interval.
Page 68/151
Parameter hsdschSlowStartRate Object HsDschSlowStart
Range & Unit List of up to 10 values in the range [0%..100%], step 10, unit %
User Customer
Class 3
Granularity HsDschSlowStart
Value HsDschSlowStart/burstFixed :
HsDschSlowStart/burstFlexible :
empty list
HsDschSlowStart/congestionFixed :
HsDschSlowStart/congestionFlexible :
list of 10 elements: 10,20,30,40,50,60,70,80,90,100

One dchSlowStart instance is created; it stores the Recovery from Congestion slow
start parameters.

The parameter dchSlowStartPeriod gives the slow-start period (applicable only to
DCH in Congestion Recovery mode)
Parameter dchSlowStartPeriod Object DchSlowStart
Range & Unit [0..20] step 10, unit ms
User Customer
Class 3
Granularity DchSlowStart
Value 20
Note: the value 0 for dchSlowStartPeriod disables the slow start mechanism.

The parameter dchSlowStartRate defines the slow-start ramp-up rate in percentage
from GBR to the nominal rate (applicable only to DCH in Congestion Recovery mode).
Parameter dchSlowStartRate Object DchSlowStart
Range & Unit List of 2 values in the range [0%..100%], step 10, unit %
User Customer
Class 3
Granularity DchSlowStart
Value 0, 50

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 CQI
reported
) is directly used by the scheduler.

Page 69/151
HS-DPCCH demodulation
and CQI decoding
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)
CQI
reported
CQI
processed
HS-DPCCH demodulation
and CQI decoding
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)
CQI
reported
CQI
processed

Figure 13: 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 (CQI
reported
) 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 CQI
processed
in this document)
constitutes the input of both flow control and scheduler algorithms (except HS-SCCH
power control).

6.2 CQI ADJUSTMENT ACCORDING TO BLER
[iCEM]
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 OMC-
B 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:
Page 70/151
hsdpaBlerTargetUpperLimit: defines the Upper BLER target.
hsdpaBlerTargetLowerLimit: defines the Lower BLER target.
hsdpaBlerTargeMediumLimit: defines the Medium BLER target.
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:
o 0: deactivated.
o 1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no
possible parameterization, for iso-functional introduction.
o 2: outerLoopLikeAlgo. It corresponds to the UA5.x algorithm, allowing
a single BLER target.
o 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.

Page 71/151
Algorithm
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 is set to
hsdpaBlerObservationWindow (OMC-B parameter).
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

et lowBlerT
et lowBlerT downStep
et lerT upStepLowB
arg 100
arg
arg

=

et T mediumBler
et T mediumBler downStep
et umBlerT upStepMedi
arg 100
arg
arg

=

et highBlerT
et highBlerT downStep
et BlerT upStepHigh
arg 100
arg
arg

=

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:

hsdpaCqiBlerAdjustmentAlgo 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
outerLoopLikeAlgo Cat.x
blerRangeBasedAlgo Cat.x
highBlerTarget =hsdpaBler TargetUpperLimi t
mediumBlerTarget =hsdpaBler Tar getMediumLimi t
lowBlerTarget =hsdpaBlerTargetLower Limit
Bler Target <30% (in practice around 10%)
Bler Target =hsdpaBlerTargetUpperLi mit
cqiThLow
cqiThHigh
dynamicOuterLoopAlgo

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

Page 72/151
Following steps are then performed:
Anytime feedback information is received from a scheduled UE, DeltaCqiCur
is updated:
o If ACK, DeltaCqiCur is increased by UpStep
o If NACK, DeltaCqiCur is decreased by DownStep
o 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 15: CQI adjustment to BLER algorithm

Page 73/151
Parameters:
Parameter hsdpaCqiBlerAdjustmentAlgo Object HSDPAConf
Range & Unit [deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo,
dynamicOuterLoopAlgo]
User Customer
Class 3
Granularity BTSCell
Value dynamicOuterLoopAlgo

Parameter hsdpaAdjustBlerToChannelVariation Object HSDPAConf
Range & Unit [TRUE, FALSE]
User Customer
Class 3
Granularity BTSCell
Value FALSE

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 hsdpaBlerTargetUpperLimit Object HSDPAConf
Range & Unit [1..99] %
User Customer
Class 3
Granularity BTSCell
Value 30

Parameter hsdpaBlerTargetLowerLimit Object HSDPAConf
User Customer
Class 3
Granularity BTSCell
Value 1

Parameter hsdpaBlerTargetMediumLimit Object HSDPAConf
User Customer
Class 3
Granularity BTSCell
Value 20

Rule: Coherence between various BLER targets
Following interdependency rule should be observed on the values of hsdpaBlerTargetLowerLimit,
hsdpaBlerTargetMediumLimit and hsdpaBlerTargetUpperLimit:
hsdpaBlerTargetLowerLimit <=hsdpaBlerTargetMediumLimit <=hsdpaBlerTargetUpperLimit

Page 74/151
Parameter hsdpaBlerObservationWindow Object HSDPAConf
Range & Unit [1..100] Decimal (TTIs)
User Customer
Class 3
Granularity BTSCell
Value 10

Parameter hsdpaBlerStepSize Object HSDPAConf
Range & Unit [0.1..1.0] step:0.1
User Customer
Class 3
Granularity BTSCell
Value 0.1

[xCEM]
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 hsdpaCqiBlerAdjustmentAlgorithmXcem Object HsdpaConf
Range & Unit [deactivated, constBlerTarget, dynamicHarqTxTarget] Enum
User Customer
Class 3
Granularity BTSCell
Value constBlerTarget

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.

Page 75/151
Restriction: dynamicHarqTxTarget
For hsdpaCqiBlerAdjustmentAlgorithmXcem, only 2 values are supported :
- deactivated,
- constBlerTarget
The value dynamicHarqTxTarget should not be selected since this algorithm is not supported.

The parameter hsdpaBlerTargetUpperLimitXcem is used when constBLERTarget
is selected and determines which limit is used as target for HSDPA packet error rate.
Parameter hsdpaBlerTargetUpperLimitXcem Object HsdpaConf
Range & Unit [199] %
User Customer
Class 3
Granularity BTSCell
Value 15

Parameter hsdpaBlerTargetLowerLimitXcem Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 1
The parameter hsdpaBlerTargetLowerLimitXcem is not used.

[UCU III]
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 15%
(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:

arget et_error_t HSDPA_pack 1
arget et_error_t HSDPA_pack
_down_step HSDPA_SINR
_up_step HSDPA_SINR
=

Parameter HSDPA_SINR_down_step Object None
(tunable
parameter)
Range & Unit [0512] & each step is equal to 0.001 dB
User -
Class 0
Granularity NodeB
Value 400 (meaning 0.4 dB)

Page 76/151
Parameter HSDPA_packet_error_rate_target Object None
(tunable
parameter)
Range & Unit [0...100] %
User -
Class 0
Granularity NodeB
Value 15%

Parameter HSDPA_SINR_max_factor Object None
(tunable
parameter)
Range & Unit [-200,,330] & each step is equal to 0.1 dB
User -
Class 0
Granularity NodeB
Value 20 (meaning 2dB)

Parameter HSDPA_SINR_min_factor Object None
(tunable
parameter)
Range & Unit [-400,,200] & each step is equal to 0.1 dB
User -
Class 0
Granularity NodeB
Value -10 (meaning -1dB)

Note that these four parameters are internal NodeB tunable parameters (can not be
modified through OAM)

6.3 HS-DPCCH PRESENCE DETECTION
[iCEM]
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.
Page 77/151
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
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 16: 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.
Page 78/151
Parameter RxDemodulation Object BTSEquipmentl
User Customer
Class 0
Granularity BTS
Value 4

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 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:
RxDemodulation value
common Layer1 UL
enhancement
HS-DPCCH presence
detection
Enhanced
demodulation for high
speed UE
3 OFF OFF OFF
2 ON OFF OFF
1 OFF ON OFF
7 OFF OFF ON
5 OFF ON ON
6 ON OFF ON
0 ON ON OFF
4 ON ON ON

Page 79/151
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).

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) from top of the OVSF code tree

Multiple S-CCPCH feature allows to use up to 3 S-CCPCH (1
st
S-CCPCH on
SF
64,1
, 2
nd
S-CCPCH on SF
128,4
, 3
rd
S-CCPCH on SF
128,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.

The number of HS-PDSCH codes reserved at cell setup is defined by the
numberOfHsPdschCodes parameter in case feature 33694 Fair Sharing is
not enabled. With feature 33694 activated, RNC ignores this parameter and
sets up all codes as being available for HSDPA at cell setup, except the ones
already reserved by common control channels. If instead feature 29800
Dynamic DL Codes Tree Management for HSDPA is activated, the number
of HS-PDSCH codes is still initially defined by the above parameter but codes
for HSDPA traffic can later be updated dynamically by the RNC according to
the number of free OVSF codes.
Page 80/151
The following figures illustrate the different S-CCPCH Channel configurations
described above:
Configuration with 3 S-CCPCH Configuration with 2 S-CCPCH Configuration with 1 S-CCPCH Configuration with 3 S-CCPCH Configuration with 2 S-CCPCH Configuration with 1 S-CCPCH

Figure 17: 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:
- Reservation of the HS-PDSCH codes is static and the number of HS-
PDSCH 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.
DCTM enabled
(Fair Sharing has to be
disabled)
- 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.
- 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.
Page 81/151
Fair Sharing is enabled
(DCTM has to be
disabled):
- 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 CE module 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 channels 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
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 to SF16 via the
spreadingFactorLevelForOvsfMonitoring parameter.

HS-PDSCH codes pre-emption
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)
OR

Page 82/151
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
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 HS-
PDSCH codes in order to have numCodesForDchAfterReallocation free OVSF
codes.

Page 83/151
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
Yes
No
HS-PDSCH codes pre-emption is triggered
If threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nf of free SF8 codes ==0
>threshCodesToTriggerReallocation
No
Yes
Yes
HS-PDSCH codes reallocation is triggered
R99 code allocation or release
RNC checks the number of free SFx
<threshCodesToTriggerStealing
Yes
No
If threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nf of free SF8 codes ==0
>threshCodesToTriggerReallocation
No
Yes
Yes

Figure 18: HS-PDSCH codes pre-emption or re-allocation

If ((old Number of free SF8 codes ==0)
AND
((threshCodesToTriggerStealing * SF8/SFMonitoring) 1))
Number of HS-PDSCH codes stolen is such as:
New Nb of free SF8 codes >0
#FreeOvsfCodesSfx numCodesForDchAfterStealing
Yes
No
AND
#FreeOvsfCodesSfx numCodesForDchAfterStealing
Yes
No

Figure 19: Number of HS-PDSCH codes pre-empted
Page 84/151
AND
Number of HS-PDSCH codes re-allocated is such as:
Yes
No
FreeOvsfCodesSfx numCodesForDchAfterReallocation
AND
Yes
No
FreeOvsfCodesSfx numCodesForDchAfterReallocation

Figure 20: 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 HS-
PDSCH.

S
F
2
5
6
S
F
1
2
8
S
F
6
4
S
F
3
2
S
F
1
6
S
F
8
S
F
4
S
F
2
5
6
S
F
1
2
8
S
F
6
4
S
F
3
2
S
F
1
6
S
F
8
S
F
4
0
1
0
0
2
3
1
0
1
0
0
2
3
1
4
5
2
1
6
7
3
4
5
2
1
6
7
3
8
9
4
2
10
11
5
8
9
4
2
10
11
5
12
13
6
3
14
15
7
12
13
6
3
14
15
7
HS-PDSCH (4 for ex)
Free OVSF codes
R99 codes
Common channels
(3 S-CCPCH) +2 HS-SCCH
Reallocation of a 5th HS-PDSCH
code is impossible because of the
R99 code even if the number of
free codes triggers the reallocation

Figure 21: Illustration of the HS-PDSCH re-allocation blocking
Page 85/151
The isHsPdschDynamicManagementAllowed parameter allows the activation of the
Dynamic Code Tree Mgt feature:
Parameter isHsPdschDynamicManagementAllowed Object RadioAccessService
Range & Unit [false, true]
User Customer
Class 3
Granularity RNC
Value False

The following parameter is used in UA6.0 to activate the DCTM feature at FDDCell
level:
Parameter isCellHsPdschDynamicManagementActive Object HsdpaCellClass
Range & Unit [false, true]
User Customer
Class 0
Granularity CellClass
Value False

Engineering Recommendation: DCTM activation
Since UA6, recommendation is to use Fair Sharing feature to control HSDPA code allocation (up to 15
HS-PDSCH, no more need to keep a margin, better reactivity). Then the DCTM activation flags have
to be set to False:
isHsPdschDynamicManagementAllowed =False
or
isCellHsPdschDynamicManagementActive =False

Note that to activate the DCTM, the 2 activation flags have to be set to True:
isHsPdschDynamicManagementAllowed =True
and
isCellHsPdschDynamicManagementActive =True

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 de-
activation and is not equal to numberOfHsPdschCodes. In order to reinitialize the number of HS-
PDSCH to numberOfHsPdschCodes, we need either to lock/unlock the cell or to disable the feature
at FDDCell level (parameter being class 0).

Page 86/151
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 numberOfHsPdschCodes Object HsdpaCellClass
User Customer
Class 0
Value 5

Parameter numberOfHsScchCodes Object HsdpaCellClass
Range & Unit [1..4]
User Customer
Class 0
Value 2

Engineering Recommendation: numberOfHsPdschCodes & numberOfHsScchCodes
When DCTM and Fair Sharing features are de-activated:
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.
numberOfHsPdschCodes =5 for shared carrier or 10 for dedicated carrier in order to keep the same
behavior as in UA4.2 (which is based on static reservation of pool of codes for HSDPA use)

When either of the above features are 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 code needed is low) for HSUPA centric or VoIP mapped on HSxPA services

Page 87/151
Parameter maxNumberOfHsPdschCodes Object HsPdschDynamicManagement
User Customer
Class 3
Value 15

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 left in anticipation of R99 call and codes for SRB associated with
HSDPA calls. Nevertheless, there is no reason to limit this value.

Parameter minNumberOfHsPdschCodes Object HsPdschDynamicManagement
User Customer
Class 3
Value 1

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 1
No impact on HSDPA Cat12 user 5
Minimum HDSPA throughput (at least throughput of 1 PS384) 2

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.
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
Page 88/151
Parameter spreadingFactorLevelForOvsfMonitoring Object HsPdschDynamicManagement
Range &
Unit
[16, 32, 64, 128, 256]
User Customer
Class 3
Value 16

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 numCodesForDchAfterReallocation Object HsPdschDynamicManagement
Range &
Unit
[1..255]
User Customer
Class 3
Value 2

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
Parameter numCodesForDchAfterStealing Object HsPdschDynamicManagement
User Customer
Class 3
Value 2

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 threshCodesToTriggerReallocation Object HsPdschDynamicManagement
Range &
Unit
[1..255]
User Customer
Class 3
Value 2

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 threshCodesToTriggerStealing Object HsPdschDynamicManagement
User Customer
Class 3
Value 2

Page 89/151
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.

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 RAB 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 minTimeBeforeReallocationOfHsPdsch Object HsPdschDynamicManagement
Range &
Unit
[0..3600] Decimal (s)
User Customer
Class 3
Value 0

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.

Page 90/151
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.

Rule: Coherence between the parameters
To have normal feature behaviour:
numCodesForDcfhAfterReallocation <=threshCodesToTriggerReallocation
numCodesForDchAfterStealing >=threshCodesToTriggerStealing

To avoid ping-pong:
numCodesForDchAfterReallocation >=threshCodesToTriggerStealing
numCodesForDchAfterStealing <=threshCodesToTriggerReallocation

To be in line with monitoring line
numCodesForDchAfterReallocation <=spreadingFactorLevelForOvsfMonitoring
numCodesForDchAfterStealing <=spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerReallocation <=spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerStealing <=spreadingFactorLevelForOvsfMonitoring

To be coherent at cell setup
minNumberOfHsPdschCodes <=numberOfHsPdschCodes
numberOfHsPdschCodes <=maxNumberOfHsPdschCodes

Page 91/151
Engineering Recommendation: OCNS configuration
OCNS code allocation is done before HSDPA configuration and it may lead to a conflict as HS-
PDSCH 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
(Customer Class 2)
Default value Recommended value Range
RNC / NodeB / FDDCell
OCNSActivation False - Enum [False; True]
OCNSSpreadingFactor SF8 SF256 Enum [SF4 SF256]
RNC / NodeB / FDDCell / OCNSChannelsParameters
OCNSPower 100% - Integer [0100]
OCNSChannelizationCodeNumber 7
8 with 1 S-CCPCH
10 with 2 S-CCPCH
12 with 3 S-CCPCH
Integer [0511]

Note that in UA6.0, the feature OCNS for HSDPA has been introduced for US market. See 9.3 for
more details.

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)
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
Page 92/151
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
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, HS-
SCCH, 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
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.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Used or reserved for ccc, E-AGCH/E-RGCH/E-HICH, HS-SCCH
Used or reserved for R99 calls
Free SF16 codes
x
x
x
Largest group of consecutive free SF16
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Used or reserved for ccc, E-AGCH/E-RGCH/E-HICH, HS-SCCH
Used or reserved for R99 calls
Free SF16 codes
x
x
x
x
x
x
Largest group of consecutive free SF16

Figure 22: 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
upon the GBR / minBR of the HSDPA RAB. These reserved codes change
dynamically with traffic (at each HSDPA RB allocation/release) and cannot be
Page 93/151
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
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 hsdpaCodeTreeManagementActivation Object BTSEquipmentl
User Customer
Class 3
Granularity BTS
Value True

[UCU III]
Parameter hsdpaCodeTreeManagementActivation Object OneBTSEquipmentl
User Customer
Class 3
Granularity OneBTS
Value True

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.
Page 94/151
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 (E-
AGCH, 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 as P
MaxCell
in the following
figure). This assumes 10% P-CPICH power fraction.
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 till UA4.2.
We define Pccc as the power configured for common control channels (through
pcpichPower, pschPowerRelativeToPcpich, sschPowerRelativeToPcpich,
bchPowerRelativeToPcpich, sccpchPowerRelativeToPcpich,
aichPowerRelativeToPcpich and pichPowerRelativeToPcpich)

Page 95/151
P
maxHsdpa
CCC
RNC
SHO margin
R
N
C
OCNS (opt.)
P
minHsdpa
P
MaxCell
HSUPA
P
traffic
P
maxHsdpa
CCC
RNC
SHO margin
R
N
C
OCNS (opt.)
P
minHsdpa
P
MaxCell
HSUPA
P
traffic

Figure 23: 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:
P
OCNS
=(P
MaxCell
- P
CCC
*activityFactorCcch) x OCNSpower

where OCNSpower =[0 100]%

It is possible (if Fair Sharing is disabled) to reserve a minimum power for HSDPA
noted P
minHsdpa
that is subtracted from the power of the DCH pool (see the P
traffic

formula below). This power is defined through the minimumPowerForHsdpa
parameter such as:
P
minHsdpa
=P
MaxCell
minimumPowerForHSDPA

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
P
minHsdpa
<P
MaxCell
- P
OCNS
- P
CCC
*activityFactorCcch

Note: The activation of OCNS with HSDPA & Multiple S-CCPCH requires
modifications of OCNS default parameters. Refer to section 7.2 for more details.
Page 96/151
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:
P
SHO
=(1 - callAdmissionRatio).P
traffic

With:
P
traffic
=P
MaxCell
- P
CCC
*activityFactorCcch - P
OCNS
- P
edch
- P
minHsdpa

When Fair Sharing feature is enabled, there is no need to reserve anymore minimum
power for HSDPA so above calculation becomes:
P
traffic
=P
MaxCell
P
CCC
*ActivityFactorCcch - P
OCNS
P
edch

P
traffic
is the power available for both DCH and HSDPA allocations (I/B and Streaming).

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
Object FDDCell
User Customer
Class 3
Granularity FDDCell
[UCU-III] 36

P
edch
is linked to the parameter eagchErgchEhichTotalPower (see [Vol. 4]).

This leads to definition of maximum power that the RNC can allocate to HSDPA
channels: P
maxHsdpa
. This maximum power is computed at the RNC and given to
NodeB during the cell setup inside the physical shared reconfiguration channel NBAP
message.

In UA6.0, the maximum power that the RNC can allocate to HSxPA channels is
defined by:
P
maxHspa
=P
MaxCell
maxHspaPowerOffset

Page 97/151
Parameter maxHspaPowerOffset Object HsdpaCellClass
Range & Unit Integer (dB)
[0 50] step 0.1
User Customer
Class 3
Granularity FDDCell
Value 0

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:
P
maxHspa
=P
MaxCell
- P
CCC
* ActivityFactorCcch - P
OCNS

Typically, P
maxHspa
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%.

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_E-
HICH_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 HS-
PDSCH_FDD_code_information and HS-SCCH_FDD_code_information respectively
(see the following figure).

PHYSICAL SHARED CHANNEL
RECONFIGURATION MESSAGE
duringCell Setup
HS-PDSCH_FDD_code_information
HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICH
Total Power
HS-SCCH_FDD_code_information
HS-PDSCH_FDD_code_information
HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICH
Total Power
HS-SCCH_FDD_code_information

Figure 24: Physical shared channel reconfiguration message

Page 98/151
8.2.1.2 NODEB LEVEL
[iCEM] [xCEM]
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.

P
Remain
P
TotNonHsdpaWithMargin
CCC
NodeB
DCH margin
DCH N
o
d
e
B
OCNS (opt.)
P
MaxCell
P
TotNonHsdpa
E-DCH
P
Remain
P
CCC
NodeB
DCH margin
DCH N
o
d
e
B
OCNS (opt.)
P
MaxCell
P
TotNonHsdpa
E-DCH

Figure 25: 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.
The power consumed by this DCH margin depends on the dchPowerMargin
parameter. This parameter is a percentage of the non HSDPA power minus the P-
CPICH power:
P
DCHmargin
=dchPowerMargin.(P
TotNonHsdpa
P
CPICH
)
and
P
TotNonHsdpa
=P
DCH
+P
OCNS
+P
CCC
*activityFactorCcch +P
E-DCH

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.

Page 99/151
The remaining power P
Remain
is the power usable by HSDPA:
P
Remain
=P
MaxCell
P

and
P
=P
TotNonHsdpa
+P
DCHmargin

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]
For UCUIII no such margin exists and its power management is described in detail in
section 8.2.3.3.

8.2.1.3 POWER AVAILABLE FOR HSDPA CHANNELS
[iCEM] [xCEM]
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:
P
HSDPA
=min(P
Remain
, P
maxHspa
)

[UCU III]
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 (P
maxHsdpa
).

8.2.2 POWER MEASUREMENTS
The computation of the available HSDPA power requires some power measurements.

[UCU III]
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.

Page 100/151
8.2.2.1 TRANSMITTED CARRIER POWER
[iCEM] [xCEM]
The transmitted carrier power P
TotCell
(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.

8.2.2.2 AVERAGED HSDPA POWER
[iCEM] [xCEM]
The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes
P
TotHsdpa
(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:
P
TotHsdpa
(TTI) =Rho.P
TotHsdpa
(TTI 1) +(1 Rho).P
InstHsdpa
(TTI)

where P
InstHSDPA
corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor (Rho =0.9775 hardcoded). P
TotHSDPA
should be
initialized with the instantaneous value.

Power
consumed by
all codes
N
o
d
e
B
P
MaxCell
P
TotCell

Power
consumed by
non HSDPA
codes
N
o
d
e
B
P
MaxCell
P
TotCell
HSDPA
P
TotHsdpa

Figure 26: 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.

Page 101/151
8.2.2.3 TOTAL NON HSDPA POWER
[iCEM] [xCEM]
The total power not used by HSDPA (P
TotNonHsdpa
) is then computed over the last
period by subtracting the total HSDPA power from the total cell power:
P
TotNonHsdpa
=P
TotCell
- P
TotHsdpa

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, E-
AGCH, 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 HS-
PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission
COMMON MEASUREMENT
Transmitted carrier power of all codes not used for HS-
PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission

Figure 27: Common measurement

Restriction: Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-
AGCH, 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)

8.2.2.4 AVAILABLE HSDPA POWER
[iCEM] [xCEM]
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
P
MaxCell
and the total non HSDPA power with DCH margin P
. It is
bounded by P
maxHspa
:
P
HSDPA
=min(P
MaxCell
- P
, P
maxHspa
)

Page 102/151
with P
=(1+DchPowerMargin/100) * (P
TotNonHsdpa
- P
CPICH
) +P
CPICH

The following flowchart summarizes this measurement process:
Update transmitted HSDPA
power (P
TotHsdpa
) any TTI
PMM ATM cell reception any 100ms
Y
ATM cel l recei ved ?
Recovery in the ATM payload of the
Transmitted Carrier Power of the
corresponding cell P
TotCell
N
Computation of the Transmitted carrier
power on non HSDPA channels
P
TotNonHsdpa
= P
TotCell
- P
TotHsdpa
P
TotCell
P
TotHsdpa
P
TotNonHsdpa
Assume a margin on the non HSDPA power.
P
Rem
= P
MaxCell
P
Computation of the total HSDPA power available :
P
HSDPA
= min(P
Rem
, P
MaxHsdpa
)
Transmit P
TotNonHsdpa
every
100ms to CallP (common
measurement process)
Use P
HSDPA
as scheduler input
until next refresh
P
HSDPA

Figure 28: Power measurement process

8.2.2.5 HS-DSCH REQUIRED POWER
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 and is expressed in thousandths of the max transmission
power. With PA power pooling enabled, the value for maxTxPower for HSDPA
dedicated carrier is increased by 1+paOverbookingRatio so hs-dsch required power
is reported with respect to this overbooked max transmission power value.

Parameter hsdschReqPwReportingPeriod Object NBAPMeasurement
Range & Unit [103600000] step : 10ms
User Customer
Class 3
Granularity MeasurementConfClass
Value 10000 (10s)

Page 103/151
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 hsdschReqPwFilterCoeff Object NBAPMeasurement
Range & Unit [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19]
User Customer
Class 3
Value 3

hsdschReqPwFilterCoeff is the filtering coefficient to be applied to the common
measurements HS-DSCH Required Power.
[iCEM]
To derive this measurement:
- 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 HS-
PDSCH 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.
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.

Page 104/151
[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.
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 addGBRTransmitPower Object OneBTSEquipment
User Customer
Class 3
Granularity OneBTSCell
Value False

Restriction: addGBRTranmsitPower = False
Since 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.
Page 105/151

Figure 29: Measurement flow of HS-DSCH required power

8.2.3 HSDPA POWER DISTRIBUTION
8.2.3.1 HS-SCCH POWER
The available power for HSDPA P
HSDPA
is shared between HS-SCCH and HS-DSCH
channels (see the following figure).

CCC
DCH margin
P
Hsdpa
DCH N
o
d
e
B
OCNS (opt.)
HS-DSCH
HS-SCCH

Figure 30: Power distribution between HS-DSCH and HS-SCCH channels
Page 106/151
A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
P
HS-SCCH
<P
HSDPA

If not, the scheduler will try to schedule another user.

The power allocated to HS-SCCH is explained in section dedicated to the feature HS-
SCCH 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:
P
Temp
=P
HSDPA
P
HS-SCCH

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:
P
HS-DSCH reference
[dBm] =P
P-CPICH
[dBm] +[dB] +(CQI
reported
)[dB]

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.
On the other hand, NodeB computes a modified CQI (noted CQI
processed
or AMC) to
ensure a transmission with a given BLER target (cf section 6.1) assuming a downlink
power equals to:
P
HS-DSCH
[dBm] =P
P-CPICH
[dBm] +[dB] +(CQI
processed
)[dB]
where
P
P-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 P
HS-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
Page 107/151
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 HS-
PDSCH 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.

DOWNLINK HS-PDSCH
INFORMATION
duringRadio Bearer
Setup/Reconfiguration
HS-DSCH FDD
INFORMATION
duringRadio Link
Setup/Reconfiguration
measurementPowerOffset

Figure 31: 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).
Note that the reference power offset is the one corresponding to the processed CQI
(CQI
processed
) and not the reported CQI (CQI
reported
). See CQI section for more details.

8.2.3.3 HS-PDSCH POWER
[iCEM]
The HS-DSCH power is equally distributed between all the physical channels HS-
PDSCH:
P
HS-PDSCH
[dBm] =P
HS-DSCH
[dBm] - 10.log(#codes)

[xCEM] [UCU III]
The SNR estimation of one HS-PDSCH depends on the available power for one HS-
PDSCH. Assuming that the power is uniformly distributed over all codes (N
HS-PDSCH
)
that are available for HSDPA, the available power for one HS-PDSCH (for user u from
the ranking list) is:
P
availableHS-PDSCH
(u) =(P
HSDPA
P
HS-SCCH
(u)) / N
HS-PDSCH

Page 108/151
Where:
- P
HSDPA
is the power that is available for HSDPA
- P
HS-SCCH
(u) is the allocated power for HS-SCCH channel of user u
- N
HS-PDSCH
is the number of HS-PDSCH codes computed as below.

If more than one user to be scheduled for the next TTI, then N
HS-PDSCH
is equal to the
total number of HS-PDSCH codes (N
total
). Else, N
HS-PDSCH
is the minimum between the
total number of HS-PDSCH codes and the UE capability (N
ue capability
) in other words,
the maximum number of HS-PDSCH that a UE of a given category can manage:
N
HS-PDSCH
=min(N
total
; N
ue capability
)

For UCU III, N
total
is the number of HS-PDSCH codes configured by the NodeB due to
Fairsharing being activated by default.

For xCEM
N
total
is:
N
total
=min(N
configured
; SumN
ue capability
)
Where:
- N
configured
is the number of HS-PDSCH codes configured (internal or
external PSCR message).
- SumN
ue capability
is the sum of the UE capability of the
numberOfHsScchCodes first users at the top of the ranking list of
the previous TTI.

CCC
R99
Dch Margin
HS-SCCH
P
HS-SCCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
P
HS-DSCH
CCC
R99
Dch Margin
HS-SCCH
P
HS-SCCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
P
HS-DSCH

Figure 32: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH

Page 109/151
Note that a user can be scheduled only if its available HS-PDSCH power P
availableHS-
PDSCH
(u) is positive, otherwise the next user of the ranking list shall be selected.
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:

P
HSDPA New
=P
HSDPA
P
HS-DSCH
(u) P
HS-SCCH
(u)
N
HS-PDSCH
New =N
HS-PDSCH
n
HS-PDSCH
(u)

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 P
maxHsdpa
computation in section 8.2.1.1).
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:

P
HSDPA total
=
min(max(hsdpaAmpUsage.P
max
P
;
hsdpaMinAmpUsage.P
max
); P
maxHsdpa
)

where:
- P
is the power used by non HSDPA channels with DCH
margin (see section 8.2.1.2 for more details).
- P
max
is the maximum power of the cell.
- P
maxHsdpa
is maximum power for HSDPA computed by RNC and sent to
NodeB through NBAP message (see section 8.2.1.1)

Page 110/151
CCC
R99
Dch Margin
Pmax
hsdpaAmpUsage.Pmax
P
HSDPA
=hsdpaAmpUsage.Pmax P
HSDPA
P
CCC
R99
Dch Margin
Pmax
hsdpaAmpUsage.Pmax
P
HSDPA
=hsdpaAmpUsage.Pmax P
HSDPA
P

Figure 33: hsdpaAmpUsage parameter

Parameter hsdpaAmpUsage Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 100

Parameter hsdpaMinAmpUsage Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value 0

For UCU III
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.
Page 111/151
Amplifier Capability

R99 Power
HSDPA Power
Overhead Power

Figure 34: 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%.

Page 112/151
Parameter hsdpaAmpUsage Object OneBTSEquipment
User Customer
Class 3
Value 80

Parameter hsdpaMinAmpUsage Object OneBTSEquipment
User Customer
Class 3
Value 10

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 P
HS-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.

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, CQI
processed
. In
case of a lack of resources (codes or power), the applied CQI, CQI
applied
, is then
modified according to the previous rule to take this into account. It is done in four
steps:
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:
Page 113/151
Y
UE selected
P
temp
=P
HSDPA
P
HS-SCCH
P
HS-DSCH
=P
P-CPICH
+ +(CQI
processed
)
P
HS-DSCH
<P
temp
?
P
HS-DSCH
=P
P-CPICH
+
RP
=round(10.log(P
temp
/ P
HS-DSCH
))
CQI
1
=CQI
processed
+
RP
RP
=0
CQI
1
=CQI
processed
CQI
1
>0 ?
n
codes
=f(CQI
1
)
UE not scheduled
Y
N
N
Y n
Codes
<
n
CodesRemain
?
Select the highest CQI (CQI
2
) which number
of codes equals the remaining number of
codes
RC
=CQI
2
CQI
1
N
RC
=0
CQI
2
=CQI
1
Enough PDU available ?
TrBlk size manageable ?
Select the highest CQI (CQI
3
)
fulfilling both criteria
RO
=CQI
3
CQI
2
N

RO
=0
CQI
3
=CQI
2
Y
CQI
applied
=f(CQI
3
, MAC-d PDU size)
RCqi
=CQI
applied
CQI
3
P
HS-DSCH
=P
P-CPICH
+ +(CQI
3
) +
RP
+
RC
+
RO
+
RCqi
P
HS-DSCH
=min(P
Temp
, P
HS-DSCH
)
P
Remain
=P
Temp
P
HS-DSCH
[n
Codes
, n
PDU
] =f(CQI
applied
)
UE scheduled
P
o
w
e
r

l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
C
o
d
e

l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
O
t
h
e
r
l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
C
Q
I

o
p
t
i
m
i
z
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t

Figure 35: HS-DSCH power management for 1st transmission
Page 114/151
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 (P
temp
refers to the available power at NodeB level and P
HS-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.

8.2.4.1.2 CODES LIMITATION
If the resulting configuration, corresponding to the derived CQI from the previous step
(CQI
1
), 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.

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
(CQI
2
), the configuration is then chosen to match to the lowest CQI (CQI
3
) 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.

Page 115/151
320 16 21 Padding
Mac-d PDU
Mac-hs transport block(CQI
2
)
320 16
320 16 21 Padding
Mac-d PDU
Mac-hs transport block(CQI
3
)
320 16

Figure 36: 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
(CQI
3
). 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:
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)
Page 116/151
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)

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 35. This guarantees a minimum performance level on a par with UA5.0.
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.
Page 117/151
Parameter hsdpaFullPowerUsage Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value True

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 activation of PA power pooling feature in case of STSR2 configuration.

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]
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_offset
dB
= (CQI
1st
CQI
ret
)*Step Const.
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.
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
Page 118/151
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.
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.
Parameter harqType Object HsdpaConf
Range & Unit [mirType, pirType, ccType, drType, MIRWithPowerAdaptation,
PIRWithPowerAdaptation, CCWithPowerAdaptation,
DRWithPowerAdaptation]
User Customer
Class 3
Granularity BTSCell
Value mirType

[xCEM]
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])

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
Page 119/151
will try to serve another user in the same TTI with the power that remains (P
Remain
in
the following figure), provided there is still a free HS-SCCH code for this TTI.

CCC
DCH margin
P
Remain
DCH
N
o
d
e
B
OCNS (opt.)
HS-DSCH
HS-SCCH

Figure 37: 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 HS-
SCCH 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.

8.3 HS-SCCH POWER MANAGEMENT
[iCEM]
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 CQI
reported
), not from CQI adapted by the NodeB
in anyway, in order to adapt the transmission power to actual reported radio
conditions.
Page 120/151
This is configured in a table that gives a power offset relative to P-CPICH for each CQI
such as:
P
HS-SCCH
=P
P-CPICH
+hsScchPcOffset(CQI
reported
)

where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each
CQI (see the following figure).
CQI
reported
hsScchPcOffset relative to PCPICH Power
1 hsScchPcOffset(1)
2 hsScchPcOffset(2)
.
30 hsScchPcOffset(30)
Table 8: 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:

C
Q
I
P
HS-SCCH
= P
P-CPICH
+ hsScchPcOffset(CQI
Reported
)
CQI
Reported
hsScchPcOffset(CQI
Reported
)
C
Q
I
P
HS-SCCH
= P
P-CPICH
+ hsScchPcOffset(CQI
Reported
)
CQI
Reported
hsScchPcOffset(CQI
Reported
)

Figure 38: HS-SCCH power control overview

Page 121/151
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
MPO = 5 dB MPO = 6 dB MPO = 7 dB MPO = 8 dB MPO = 9 dB
1 0 0 0 0 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 -3 0 0 0 0
8 -3 -3 0 0 0
9 -5 -3 -3 0 0
10 -5 -5 -3 -3 0
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
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
CQI
30 -8 -8 -8 -8 -8

[xCEM] [UCU III]
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.
Page 122/151
Parameter hsscchSnr Object HsdpaConf
Range & Unit [-5.019.0] dB (step .1)
User Customer
Class 3
Granularity BTSCell
Value 1

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 SNR
MAP,dB
from
CQI SNR mapping for each user, taking into account that HS-SCCH uses an
SF128 :
P
HS-SCCH
=hsscchSnr +P
P-CPICH
+ SNR
MAP,dB
10.log
10
(128/16) +5dB
Where:
- P
P-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

8.4 PARAMETERS SETTINGS AND RECOMMENDATIONS
The following section gives the properties of the parameters described previously.
Parameter dchPowerMargin Object HsdpaConf
Range & Unit Integer (%)
[0 100]
User Customer
Class 3
Granularity BTSCell
Value 20

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.

Page 123/151
Parameter hsScchPcOffset Object HsdpaConf
Range & Unit List[1..30]
[-28.0..28.0] dB
User Customer
Class 3
Granularity BTSCell
Value 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 minimumPowerForHsdpa Object HsdpaCellClass
Range & Unit Integer (dB)
[0.0 50.0]
User Customer
Class 3
Granularity FDDCell
Value Unset or 50.0 (= 50.0dB)

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 : P
minHsdpa
=P
MaxCell
minimumPowerForHsdpa =45dBm 50dB =-5dBm =0.3mW).
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.
In order to allow HSDPA calls, following formula has to be used to compute the minimum value for this
parameter:
minimumPowerForHsdpa
Min
=P
ccc
*activityFactorCcch + P
SRB

See [R01] for details about power reservation for CCs and SRBs.

Page 124/151
Parameter measurementPowerOffset Object HsdpaUserService
Range & Unit Integer (0.5 dB)
[-12..26]
User Customer
Class 3
Value 15 (= 7.5dB)

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:
P
HS-DSCH
=P
P-CPICH
+measurementPowerOffset <=MaxTxPower
If this condition is not satisfied then the HSDPA call is not setup

Page 125/151
Rule: [iBTS] Power checks at NodeB level
iBTS:
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:
(1) P
HS-SCCH
(CQI) P
maxHspa
whatever the CQI
(2) P
ccc
+P
HS-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).
(3) P
HS-SCCH
(CQI) Max Tx Power - 35 dB
(4) Max Tx Power 35dB P
maxHspa
Max Tx Power

E-DCH rules (these rules apply to each E-DCH UE):
(5) P
ccc
+P
HS-SCCH
(CQI) +eAgchPower +eHichPower +eRgchPower Max Tx Power whatever the
CQI
(6) P
E AGCH
Max Tx Power - 35 dB
With P
E AGCH
being the power allocated to the considered E-AGCH channel.
(7) P
E HICH signature
With P
E HICH signature
being the power allocated to the E-HICH signature of the considered user.
(8) P
E RGCH signature
With P
E RGCH signature
being the power allocated to the E-RGCH signature of the considered user.

With following terms
(9) P
HS-SCCH
(CQI) =P
P-CPICH
+hsScchPcOffset(CQI)
(10) P
ccc
=P
P-CPICH
+max {P
ccpch
, (P
P-sch
+P
S-sch
)}
Note that above formulas are expressed in linear scale, except (3), (4), (6), (7), (8), (9) which are
expressed in logarithmic scale.

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
Page 126/151
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 (In-
Sequence-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 N
HARQ
number of HARQ retransmissions higher than
target N
HARQ
) 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.

[iCEM] [xCEM] [UCU-III]
The 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.
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 sub-
feature 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
Page 127/151
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.
Another set of parameters initialSirTargetEdchTti2ms, minSirTargetEdchTti2ms
and maxSirTargetEdchTti2ms is applied to the calls verifying specific conditions as
shown in the flowchart below. Refer to the [Vol. 4] of this document for more details.
Note that 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.
The following flowchart describes how the RNC selects the set of UL SIR Target initial
value, lower bound and upper bound to be applied to a call depending on the call
characteristics and the feature activation.

Figure 39: Selection of OLPC UL SIR Target parameters by the RNC

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:
Current call is an HSDPA call (i.e. a PS HS-DSCH DL RB is established).
The Uplink Radio Bearer is EDCH (the Downlink is HSDPA) AND
The selected EDCH TTI is 2ms AND
The HSUPA UE Category is 1 in eligibleUeCategoryForSirTargetEdch2ms

minSirTargetEdch2ms
initialSirTargetEdch2ms
maxSirTargetEdch2ms
All
conditions
are TRUE
The Downlink Radio Bearer is HSDPA (the Uplink is R99 or HSUPA) AND
The HSDPA UE Category is1 in eligibleUeCategoryForSirTargetHsdpa

minSirTargetHsdpa
initialSirTargetHsdpa
maxSirTargetHsdpa
minSirTarget
initialSirTarget
maxSirTarget
At least one condition is False
All
conditions
are TRUE
At least one condition is False
Call characteristics Chosen OLPC parameters
Page 128/151
HSDPA UE Category is eligible for Management of UL power profiles sub-
feature.
Eligible HSDPA UE Categories can be set via
eligibleUeCategoryForSirTargetHsdpa parameter.
The method for setting eligible HSDPA UE Categories is described in 8.5.3.

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 PowerConfClass
Range & Unit
Bit string (64 bits), N/A
User & Class Customer, 3
Value 0000000000000000000000000000000000000000000000110011001111000000

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,
and for Release7 UE Cat 13, 14, 17, 18 Hence, bits #6 to #9, #12, #13, #16, #17 should be set to 1.

Page 129/151
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.
Parameter initialSirTargetHsdpa
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
UlUsPowerConf instance initialSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
PS_384K_IBxSRB_3_4K
Greater than initialSirTarget in order to
ensure high quality UL RAB when DL is
mapped on HSDPA. Refer to [R01]
Value
Other instances Refer to [R01]

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
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
UlUsPowerConf instance minSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
PS_384K_IBxSRB_3_4K
Greater than minSirTarget in order to
ensure high quality UL RAB when DL is
mapped on HSDPA. Refer to [R01]
Value
Other instances Refer to [R01]

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
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
Value For all UlUsPowerConf instances: Refer to [R01]

Page 130/151
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
isHsxpaServiceIndicatorEnabled
Range & Unit False, True
User Customer
Class 3
Granularity RNC
Value True

hsdpaServiceIndicatorMethod allows to enable/disable at cell level the
broadcast of the HSDPA CellIndicator flag within SIB 5
Parameter
hsdpaServiceIndicatorMethod
Object FDDCell
Range & Unit ON, OFF, AUTO
User Customer
Class 3
Granularity FDDCell
Value Auto

edchServiceIndicatorMethod allows to enable/disable at cell level the
broadcast of the E-DCH CellIndicator flag within SIB 5
Parameter
edchServiceIndicatorMethod
Object FDDcell
Range & Unit ON, OFF, AUTO
User Customer
Class 3
Granularity FDDCell
Value Auto

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:
OFF: the hsdpaServiceIndicator (or respectively the edchServiceIndicator )
information is not broadcasted in SYSINFO message.
Page 131/151
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)
[iCEM]
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):
- bit 2 =0 OFF - enhanced demodulation for high speed UE is deactivated
Page 132/151
- 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.

9.3 HSDPA OCNS (34195)
[UCU-III]
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 HSDPA-
OCNS. 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.
Page 133/151
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 HSDPA-
OCNS 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 FDDCell
Range & Unit
Real Type: 0...30 in step of 1
User & Class Customer
Value User defined

Page 134/151
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 FDDCell
Range & Unit
Real Type: 0...30 in step of 1
User & Class customer
Value User defined

Parameter Filter Coefficient
Object OCNSHSDPA
Granularity FDDCell
Range & Unit
Integer Type: 110 in step of 1
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.

Page 135/151
Initialisation
Seed =4096;
count=0;
Mean=20
filt_coef=1;
a=(0.5)^(filt_coef/2);
X(count)=1;
Start
if Y<1
Y=1;
elseif Y>30
Y=30;
else
Y=Y;
end
count =count+1
Z =rand()
X(count)=X(count-1)xZ
Y=-log(X)
if (count =Mean)
No
YES
CQI =31-Y;
Y =(1-a)*Y_previous +a*Y;
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;
Loop back to furnish the next
CQI value untill simulation time
expires.
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.
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.
Input values for initial
parameters 'Mean' and 'filt_coef'
are set by higher layer.

Figure 40: Algorithm for CQI Generating Function
Page 136/151
Parameter ACK/NACK ratio
Object OCNS
Granularity FDDCell
Range & Unit
Integer Type: 0100% in 1% step
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 FDDCell
Range & Unit
Integer Type: 0100 in step of 1
User & Class Customer
Value User defined
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 FDDCell
Range & Unit
Integer Type: 112
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.

Page 137/151
Parameter Channel Activity Time
Object OCNSHSDPA
Granularity FDDCell
Range & Unit
Integer Type: 0144 in step of 1, where 1 represents 10
minutes.
Value User defined
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 FDDCell
Range & Unit
Integer Type:
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 FDDCell
Range & Unit
False / True
User & Class Customer & Class 3
Value False
proprietaryHSDPAOCNSActivation is used to turned HSDPA OCNS on or off.

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 applicable in
downlink/uplink.
Page 138/151
This mechanism is optional and can be activated at RNC level (applicable to HSxPA
Service).

9.4.1 FEATURE APPLICABLE
An HSDPA RAB is allocated in the following conditions:
1) the UE is HSDPA capable,
2) the primary cell supports HSDPA ,
3) the UE is requesting IB service or STR service (provided feature 29804 is
enabled)
The HSDPA DL channel is given regardless of the MaxBitRate in the Core RAB
For example, 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.4Mbps (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.4Mbps,
cat6=>3.4Mbps)
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].
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.
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.

Page 139/151

Figure 41: 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.

9.4.3 PARAMETERS
The following three parameters are used to activate and configure the Iu User traffic
Conformance Feature:
sourceConformanceActivation is used to activate/inhibit the Iu conformance
algorithm for downlink HSxPA user data.
Page 140/151
Parameter sourceConformanceActivation Object DlSourceConformanceInformation
Range & Unit Enum
{Off, On}
User Customer
Class 3
Granularity RNC
Value Default: Off
Recommended : On if the operator wants to limit UE throughput

Parameter sourceConformanceActivation Object UlSourceConformanceInformation
Range & Unit Enum
{Off, On}
User Customer
Class 3
Granularity RNC
Value Default: Off
Recommended : On if the operator wants to limit UE throughput

maximumTokenGenerationRate is the Absolute Max threshold and is only
used in the case the MaxBitRate of the Core RAB is greater than this
parameter.
Parameter maximumTokenGenerationRate Object DlSourceConformanceInformation
Range &
Unit
Integer (kBytes/s)
[1..2000]
User Customer
Class 3
Granularity RNC
Value 2000

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

Parameter maximumTokenGenerationRate Object UlSourceConformanceInformation
Range &
Unit
Integer (kBytes/s)
[1..2000]
User Customer
Class 3
Granularity RNC
Value 500

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.
Parameter bucketBufferTime Object DlSourceConformanceInformation
Range & Unit Integer (ms)
[10..30000] step =10
User Customer
Class 3
Granularity RNC
Value 3750

Page 141/151
Parameter bucketBufferTime Object UlSourceConformanceInformation
Range & Unit Integer (ms)
[10..30000] step =10
User Customer
Class 3
Granularity RNC
Value 2000

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)

9.5 RADIO MEASUREMENT FREQUENCY INCREASE: TX POWER
The HSDPA cell throughput is MAC-hs scheduler decisions dependant. Efficient block
size selection is linked to the accuracy of multiple informations received by the NodeB
(CQI, Ack, Nack). On top of these air interface reported events, the accurate
estimation of the cell resources available for HS-DSCH is the first step before a
decision is made by the scheduler. When power and code are shared on the same
frequency between DCH and HSDPA, HS-DSCH resources should be real time
adapted since DCH always has the highest priority.
Objective of this feature is to increase the frequency of the PA occupancy for R99 and
other common channels.

Page 142/151
9.5.1 FEATURE OVERVIEW AND POTENTIAL BENEFITS
As per current architecture, measurement and reporting frequency period for total
transmitted power per sector and per frequency equals 10 per second. In case of
shared frequency between HSDPA and R99 channels, the radio resources available
for high speed transmission are changing quickly due to fast inner loop power control
on DCH. Current measured power is a filtered version of the many instantaneous
transmitted power samples. Multiple parameters impact the variations of the radio
resources over time like the number of users and their arrival rate, other cell
interferences statistics and radio environment variation.
If we assume that these resources consumption are random with dispersion changing
over time, the radio resources consumptions becomes close to a normal distribution
and the probability of having an accurate estimation on the real radio resources usage
per 2ms TTI is decreasing if the standard deviation is high.
It is usual, when the metric is the mean, to take a safety margin (DCH Power Margin)
for confidence interval. This margin is necessary to preserve the scheduler
performance, since the standard deviation of the random TX-power process isnt
known, and to avoid overloading (reaching the max). It depends on the variance of the
signal and measurement.
Solution proposed is to shorten the power measurement window and thus, improve
accuracy of downlink power estimation. Increasing the frequency of the information
reported to the scheduler contributes to reducing the margin, since the system is
closer to the real time resources usage. Trade off between reactivity and instability
had to be identified and the simulation results helped in identifying the best
compromise.
As a consequence 10ms was identified to be the best period to reach the optimal cell
performances. This will help in keeping low values for DCH power margin and thereby,
making better use of available power for DL HSDPA channels.
Simulation results indicate probable gains in terms of cell and user thruoughput. In
addition, this feature also provides improvements in PA power overload protection
(increased probability of PA power being under saturation point for different DCH
loading in the cell).

9.5.2 SOLUTION DESCRIPTION
HSDPA power calculation is located the CEM level and the available power for DL
HSDPA channels is calculated every 2ms. Due to change in frequency of reporting of
Tx Power from CCM to CEM, values of filtering coefficients used at Layer 1 for power
calculation need to be modified. Besides, a new algorithm for dynamic calculation of
DCH power margin is introduced.
For further information please consult section 8.2.2.

Page 143/151
9.5.2.1 AVERAGED HSDPA POWER
The value of the filtering coefficient for calculation of exponentially average HSDPA
power used for all HS-PDSCH and HS-SCCH codes is based on a different smoothing
interval, based on new parameter hsdpaWindowsObserveTime.
While before the weighting factor was hardcoded to Rho =0.9775, with the activation
of the feature, the value is calculated as follows:
Ln(Rho) =- SampleDuration / hsdpaWindowsObserveTime
where SampleDuration =2ms (TTI) and hsdpaWindowsObserveTime 100ms, for
feature activation.
If the feature is deactivated, hsdpaWindowsObserveTime = 100ms, and Rho =
0.9775 as before.

9.5.2.2 TOTAL NON HSDPA POWER
The total power not used by HSDPA is computed by subtracting the total HSDPA
power from the total cell power. However, with the activation of this feature, the
reporting is no longer done every 100ms, but instead at a 10ms rate. This means that
another filtering process is used, for the P
TotCell
, using filtering coefficient Alpha:
P
TotCell
(n) =Alpha.P
TotCell
(n 1) +(1 Alpha).P
TotCell
(n)

The formula for Alpha is equivalent as the formula for Rho, with the difference that
SampleDuration =10ms, which is the reporting rate interval from CCM to CEM.
The expression for calculation of PTotNonHsdpa does not change:
P
TotNonHsdpa
=P
TotCell
- P
TotHsdpa

9.5.2.3 AVAILABLE HSDPA POWER
The calculation for the available power for HSDPA does not change, and is given by:
P
HSDPA
=min(P
MaxCell
- P
, P
maxHspa
)

with P
=(1+DchPowerMargin/100) * (P
TotNonHsdpa
- P
CPICH
) +P
CPICH
.

The definition of DchPowerMargin, depends on the setting of flag
isDchPowerMarginAdaptive.

If set to FALSE, the calculation of P
is based on the existing
parameter DchPowerMargin, under the object HsdpaConf. When TRUE, the
DchPowerMargin is calculated dynamically, according to the values defined by
Page 144/151
parameters dchPowerMarginThresholdList and dchPowerMarginList (please see
definition in next section).

9.5.2.4 REPORT OF TOTAL NON HSDPA POWER FROM CEM TO CCM
Even if the periodic reporting of PTotCell from CCM to CEM is reduced to 10ms, the
reporting from CEM to CCM module is still kept at 100ms. This means that the
periodic transmission between BBU and CEM CallP must be adapted, and requires a
new filtering process.
For the HSDPA cell, the non-HSDPA contribution over the previous 10ms interval is
calculated as follows:
P
TotNonHsdpaNew
=P
TotCell
- P
TotHsdpaFiltered

where P
TotHsdpaFiltered
represents the filtered HSDPA power transmitted during the
previous 10ms, calculated using the following expression:
P
TotHsdpaFiltered
(TTI) =Phi.P
TotHsdpaTotFiltered
(TTI 1) +(1 Phi).P
InstHsdpa
(TTI)

where Phi is obtained by the following formula:
Ln(Phi) =- SampleDuration / PMMCellsFrequency

with SampleDuration =2ms (TTI) and PMMCellsFrequency =10ms.

A new exponential average calculation is performed, before transmission to CCM
module, every 100ms:
P
TotNonHsdpa
(n) =Gamma.P
TotNonHsdpa
(n 1) +(1 Gamma).P
TotNonHsdpaNew
(n)

where Gamma is obtained by the following formula:
Ln(Gamma) =- PMMCellsFrequency / ReportingPeriodicity

with PMMCellsFrequency =10ms and ReportingPeriodicity =100ms, which coincides
with the periodicity of the L1 H-BBU measurements (100ms).

9.5.3 PARAMETER SETTINGS
Four new parameters are introduced for activation and configuration of this feature.
hsdpaWindowsObserveTime defines the value that is used for the different
filters used for HSDPA management. Filter that need this parameter are:
Page 145/151
- Filter used to smooth P
TotCell
(HSDPA Cell) received in PMM cells
every 10ms;
TotCell
(R99Cell) received in PMM cells every
10ms;
TotHsdpa
(HSDPA Cell) power, evaluated every
TTI (2ms).
Parameter hsdpaWindowsObserveTime Object BTSEquipment
Range & Unit Decimal (ms)
[10..100] step:10
User Customer
Class 3
Granularity BTS
Value Default: 100

isDchPowerMarginAdaptive Allows the NodeB to automatically compute
and refresh the value of the power margin for R99 DCH power or to use the
value defined in parameter dchPowerMargin. If set to TRUE, the NodeB
computes automatically the R99 DCH power margin using parameters
dchPowerMarginList and dchPowerMarginThresholdList. If set to FALSE,
the NodeB uses the R99 DCH power margin defined by dchPowerMargin
parameter.
Parameter isDchPowerMarginAdaptive Object HsdpaConf
User Customer
Class 3
Granularity BTSCell
Value Default: False

dchPowerMarginThresholdList is an array of 5 elements and defines
threshold values for non-HSDPA power of a cell to be used in calculation of
DCH Power Margin. A single modification flag is used for the whole array
when at least one of the elements is updated. This parameter is taken into
account only if isDchPowerMarginAdaptive is TRUE.
Parameter dchPowerMarginThresholdList Object HsdpaConf
Range & Unit dB
[-35..0] step: 0.1 (for each array element)
User Customer
Class 3
Granularity BTSCell
Value Default: -35.0, -35.0, -35.0, -35.0, -35.0

Note: These values will be used in dynamic calculation of DCH Power Margin (see
parameter dchPowerMarginList)
If
dchPowerMarginThresholdList [0] <=NonHsdpaPowerRelativeToPmax then
dchPowerMargin =dchPowerMarginList [0]
Else if
dchPowerMarginThresholdList [1] <=NonHsdpaPowerRelativeToPmax <
dchPowerMarginThresholdList [0] then
Page 146/151
Else if
Else if
Else if
Else if
NonHsdpaPowerRelativeToPmax <dchPowerMarginThresholdList [4] then

dchPowerMarginList provides values for DCH Power Margins (percentage)
that should be applied while calculating non-HSDPA power of a cell so as to
consider fluctuations due to inner loop power control of DCH channels. This
parameter is taken into account only if isDchPowerMarginAdaptive is TRUE.
Parameter dchPowerMarginList Object HsdpaConf
Range & Unit %
[0..100] step: 1 (for each array element)
User Customer
Class 3
Granularity BTSCell
Value Default: 0, 0, 0, 0, 0, 0

Note: In the previous sections, the feature activation expression has been used. This
should be interpreted as when parameter hsdpaWindowsObserveTime is
different from 100ms.
The 100ms setting for this parameter provides an (almost) iso-functional
behaviour compared to pre-UA7.1 releases, but the PMM cells reporting
period is still 10ms, depending on the controller board.
Parameter fastPMMActivated indicates if the controller board supports
enhanced downlink cell transmit power calculations and reporting of PMM cells
to modem boards every 10ms. If it is set to FALSE, HSDPA L1 should accept
PMM cells at 100ms periodicity, otherwise PMM cells can come at 10ms
intervals. In case the parameter is set to FALSE, all the remaining parameters
described in the sections above have no significance.
This parameter is internally evaluated by Core OAM and has no mapping at
OMC-B (not an OAM parameter) as it only depends on the type of CCM board.
For CCM Alpha, the value will be FALSE, while for iCCM, iCCM2, iCCM3,
x-CCM, x-CCM-U it will be TRUE.

Page 147/151
9.6 HSDPA OLS DIFFERENTIATION AT NODE B LEVEL
This feature introduces a new level of traffic management in the RNC, applicable only
for HSDPA Interactive and Background (QoS = 3) users, when Olympic Level
Service (OLS) differentiation is active in the RNC.
OLS for a user is determined based on the user profile configured in the HLR. The
parameters that determine the OLS level in the RNC are provided through the RAB
ASSIGNMENT REQUEST message as Traffic Class (TC), Traffic Handling Priority
(THP) and Allocation/Retention Priority (ARP). The RNC maps these parameters into
a single OLS level, based in the configuration.
The basic principle of the feature is that when there is enough HSDPA Interactive and
Background traffic on the Iub to cause full utilisation of the provisioned Iub bandwidth
(i.e. Iub congestion), the feature will ensure that users with different OLS levels
achieve different throughputs, with throughput rate ratios for different OLS levels
controlled based on configurable parameters. The feature is applicable for both ATM
and IP transport.
This feature deals with priority handling at transport layer. Additional information is
provided in [R07].

9.6.1 FEATURE OVERVIEW
When cell radio resources are the the limiting factor - while the Iub resources are not a
limitation - the OLS differentiation must be achieved for all users within the same cell.
This level of differentiation is already provided by including configurable weighting
factors per SPI, in the MAC-hs credit allocation algorithm, where there is a direct
mapping between SPI and OLS.
If the Iub resources are the limiting factor (Iub congestion), the OLS differentiation
must continue to be achieved for all users in the same Node B. The distributed
architecture of the Node B (where each cell might be served by a different H-BBU)
makes it difficult for the Node B to apply similar differentiation across all of the
subtending cells while in this condition, so a RNC-centric solution has been adopted,
and implemented in the PMC-PC and PMC-RAB.
The OLS differentiation ensures that as long as all other conditions are equal for two
users (users have equally good radio conditions, use UE equipment of the same
category etc) the amout of bandwidth/throughput during the Iub congestion for each
user depends on OLS level and throughput proportions can be controlled according to
configured weights, regardless of the actual cell in the Node B which serves each
user.
Any difference in the external conditions will affect the performance of OLS
differentiation feature, as the exact ratios between the throughput of Gold, Silver and
Bronze users cannot be guaranteed, but this feature will ensure full Iub utilization
under these conditions. For example, if there is a Gold user with bad radio conditions,
than that user will transmit only acoording to the radio credits allocated by the Node B
and any unused Iub credits that were given to that Gold user will be redistributed to
other HSDPA users, such as the Iub bandwidth is fully utilized.
Page 148/151
Engineering Recommendation: Full differentiation of HSDPA users
To achieve full differentiation, both SPI (by Node B MAC-hs) and OLS differentiation (implemented
by this feature) must be activated.

9.6.2 SOLUTION DESCRIPTION
On the PMC-PC, PM97431 keeps track of the number of Gold, Silver and Bronze OLS
HSDPA I/B connections. Every 50ms a calculation is performed for the Iub credits
based on the information from the previous 50ms:

bA bW B sA sW S gA gW G
Bw qos
cfactor
* * # * * # * * #
3
+ +
=

qos3Bw Iub bandwidth available for QoS3 (provisioned bandwidth minus
what is used by higher priority QoS =0, 1, 2 traffic)
#G, #S, #B Number of Gold, Silver and Bronze OLS HSDPA RABs on Iub
gW, sW, bW Gold, Silver and Bronze OLS weights (more details in feature
activation and parameters section, below)
gA, sA, bA Activity level for all Gold, Silver and Bronze users, measured as
the ratio between what was actually transmitted in the past 50ms and what has
been allocated by the algorithm for all users of that OLS during the past 50ms

Based on the calculation above and the parameter settings, the Iub budget for each
type of OLS user is determined, for the next 50ms:
iubBudgetGold =cfactor * gW
iubBudgetSilver =cfactor * sW
iubBudgetBronze =cfactor * bW
Calculated Iub budgets per user are then passed to PMC-RAB for each HSDPA RAB,
evry 50ms. PMC-RAB must respect these Iub credits in addition to HSDPA credits
allocated by the Node B and must ensure that the total transmitted PDUs will not
exceed the Iub credits for the following 50ms.

9.6.3 FEATURE ACTIVATION AND PARAMETERS
As a pre-requisite, PM97431 requires activation of OLS in the RNC (PM25080 QoS
Differentiation Based on TC, ARP, THP, described in Volume 6 of [R01]).
By default, PM97431 is not active. In UA6.0 and UA7.1 releases, there is the
possibility of controlling the activation of the feature by means of a CDL/Inode
Page 149/151
configuration, visible only internally on the RNC (i.e. not integrated into OAM WPS
model).
A new optional component OlsDifferentiation has been added under the RncInode
component. If the the optional component is not present, the feature is not active. If it
is present, the feature is active.
Under this optional object are included the configurable weights per OLS. Internally,
the following structure will be created:

RNC/n RNCEquipment/n INode/n EM/n
RncIn
OlsDifferentiation
goldWeight
silverWeight
bronzeWeight
RNC/n RNCEquipment/n INode/n EM/n
RncIn
OlsDifferentiation
goldWeight
silverWeight
bronzeWeight

goldWeight is used to describe the targeted relative proportion of the Iub
throughput of a gold OLS I/B HSDPA user relative to silver and bronze OLS
users.
Parameter goldWeight Object OlsDifferentiation
Range & Unit Integer [0..100]
User Customer
Class 3
Granularity RNC
Value Default: 100

silverWeight is used to describe the targeted relative proportion of the Iub
throughput of a silver OLS I/B HSDPA user relative to gold and bronze OLS
users.
Parameter silverWeight Object OlsDifferentiation
User Customer
Class 3
Granularity RNC
Value Default: 40

bronzeWeight is used to describe the targeted relative proportion of the Iub
throughput of a bronze OLS I/B HSDPA user relative to gold and silver OLS
users.
Parameter bronzeWeight Object OlsDifferentiation
User Customer
Class 3
Granularity RNC
Value Default: 10

Page 150/151
Restriction: Activation of feature PM97431 and enhancedQualityOfService flag
Feature PM97431 was developed strictly assuming the condition that enhancedQualityOfService
attribute is disabled. PM97431 and functionality supported when enhancedQualityOfService =
enabled are mutually exclusive.
There is a provisioning check warning in case an operator tries to activate PM97431 when
enhancedQualityOfService = enabled and when tries to set enhancedQualityOfService = enabled
while PM97431 is active.

enhancedQualityOfService activates enhanced QoS features. If set to
"disabled", the pre-UA6.0 congestion management (i.e. HSDPA as best effort
traffic) is available. When set to "enabled", some important behaviors become
available, this may be needed to support UA6 features like Fair Sharing
(Resources reservation with differentiation) and GBR (Streaming on HSDPA).
Parameter enhancedQualityOfService Object RncIn
Range & Unit Enum {disabled, enabled}
User Customer
Class 3
Granularity RNC
Value Default: disabled

Page 151/151

END OF DOCUMENT


4 HSUPA PRINCIPLES, SCHEDULING & RESOURCE
MANAGEMENT


Volume 4: HSUPA Principles, Scheduling & Resource Management
Page 1/132
CONTENTS
1 INTRODUCTION............................................................................................................................6
1.1 OBJ ECT....................................................................................................................................6
2.1 HPUG VOLUMES......................................................................................................................9
3 E-DCH ACTIVATION...................................................................................................................10
4 POWER MANAGEMENT FOR E-DCH .......................................................................................11
4.1 UL POWER MANAGEMENT.......................................................................................................11
4.1.1 UL load management....................................................................................................11
4.1.1.1 totalRotMax............................................................................................................... 13
4.1.2 RSEPS measurements .................................................................................................16
4.1.3 UL load estimation in presence of urban noise.............................................................18
4.1.4 High UL RSSI alarm......................................................................................................20
4.2 DL POWER MANAGEMENT.......................................................................................................21
4.2.1 At RNC..........................................................................................................................21
4.2.2 At NodeB.......................................................................................................................21
4.2.2.1 E-DCH DL channels power settings......................................................................... 22
4.2.2.2 E-DCH DL channels configuration........................................................................... 24
5 E-DCH SCHEDULING CONFIGURATION .................................................................................29
5.1 2MS TTI ..................................................................................................................................29
5.2 UE CATEGORIES.....................................................................................................................29
5.3 {E-TFCI; TBS}TABLE.............................................................................................................31
5.4 {REFERENCE E-TFCI; REFERENCE POWER OFFSET}TABLE .....................................................33
5.5 FRAME PROTOCOL ON IUB......................................................................................................43
5.6 MISCELLANEOUS ....................................................................................................................44
5.6.1 PLNon-Max...................................................................................................................45
5.6.2 UL ILPC Algorithm Selection.........................................................................................46
5.6.3 E-DCH Mac-d Flow Power Offset.................................................................................49
6 MAC-E SCHEDULER iCEM........................................................................................................51
6.1 UL LOAD FINE PREDICTION ......................................................................................................51
6.2 CONSIDERATION OF SELF-INTERFERENCE IN UL LOAD PREDICTION ..........................................52
6.3 OVERLOAD DETECTION: RTWP ALARM.....................................................................................54
6.4 GRANT COMPUTATION.............................................................................................................55
6.5 MAC-E SCHEDULER................................................................................................................56
6.6 ACTIVITY MONITORING.............................................................................................................59
Page 2/132
6.7 PRIORITY INFO IN MAC-E SCHEDULER.......................................................................................59
6.8 IUB CONGESTION HANDLING FOR E-DCH.................................................................................62
6.8.1 UL iub congestion detection..........................................................................................63
6.8.2 UL iub congestion reporting by RNC ............................................................................65
6.8.3 UL iub congestion management in E-DCH scheduler ..................................................66
7 MAC-E SCHEDULER xCEM.......................................................................................................68
7.1 MAC-E SCHEDULER INPUTS ....................................................................................................68
7.2 SCHEDULING GRANT ...............................................................................................................71
7.3 OVERLOAD ALGORITHM...........................................................................................................73
7.4 ACTIVITY MONITORING.............................................................................................................74
7.5 GENERATION OF AG & RG......................................................................................................75
7.6 PRIORITY INFO IN MAC-E SCHEDULER........................................................................................77
7.7 MAC-E NON SCHEDULED MODE ................................................................................................79
7.8 IUB CONGESTION HANDLING FOR E-DCH.................................................................................80
7.8.1 ul iub congestion detection............................................................................................80
7.8.2 ul iub congestion reporting............................................................................................80
7.8.3 ul iub congestion management by E-DCH scheduler...................................................81
7.8.4 ibts local congestion control..........................................................................................81
8 IU USER TRAFFIC CONFORMANCE ........................................................................................84
9 POWER CONTROL FOR E-DCH................................................................................................85
9.1 UL OUTER-LOOP POWER CONTROL FOR E-DCH.....................................................................85
9.1.1 34249 EUL Capacity Optimized HARQ Operation.....................................................85
9.1.1.1 Principle of E-DCH UL OLPC................................................................................... 85
9.1.1.2 UA6 34249 Feature description................................................................................ 89
9.1.1.2.1 Feature aim and principle..................................................................................... 89
9.1.1.2.2 Partial UL SIR Target computation....................................................................... 91
9.1.1.2.3 HFI handling......................................................................................................... 93
9.1.1.2.4 UL/DL Imbalance Detection mechanism............................................................ 95
9.1.1.3 Parameter settings and recommendations............................................................... 96
9.1.1.3.1 Feature activation................................................................................................. 96
9.1.1.3.2 RAN model ........................................................................................................... 97
9.1.1.3.3 Parameters defined for PS_EDCH and SRB_EDCH UL rBs .......................... 98
9.1.1.3.4 Parameters defined per UL service.................................................................... 104
9.1.1.3.5 Other parameters ............................................................................................... 108
9.2 POWER CONTROL OF E-DCH DL CHANNELS......................................................................... 109
9.2.1 E-DCH DL control channels Power Control (33481).................................................. 109
9.2.1.1 Introduction............................................................................................................. 109
9.2.1.2 Feature description................................................................................................. 109
9.2.1.3 Parameter settings and recommendations............................................................. 112
9.2.1.3.1 RAN Model ......................................................................................................... 112
9.2.1.3.2 Parameters......................................................................................................... 112
9.2.1.3.3 other recommendations...................................................................................... 116
10 SRB ON HSPA DURING CALL ............................................................................................... 117
10.1 E-DCH ONLY CONFIGURATION ............................................................................................. 117
10.2 RAB ASSIGNMENT ............................................................................................................... 121
Page 3/132
10.3 MOBILITY MANAGEMENT ...................................................................................................... 122
10.4 RATE ADAPTATION............................................................................................................... 122
10.5 DEFENSE ON FAILURE .......................................................................................................... 123
11 ADVANCED RECEIVER FOR HIGH UL DATA RATE (34393) .............................................. 125
11.1 INTRODUCTION .................................................................................................................... 125
11.2 DESCRIPTION (GAIN, INTERACTIONS).................................................................................... 125
12 ONEBTS PARAMETERS......................................................................................................... 127

Page 4/132
TABLES
Table 1: UE categories 30
Table 2: Quantization for
E-DPDCH
(from 3GPP TS 25.213) 35
Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset}table 36
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset}table 37
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset}table 37
Table 6: xCEM/2ms TTI/2xSF2+2xSF4 recommended {Reference E-TFCI; Reference Power Offset}
table 37
Table 7: UCU-III/10 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset}table
38
Table 8: UCU-III/2 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset}table 38
Table 9: UCU-III/2 ms TTI/2XSF2 +2XSF4 recommended {Reference E-TFCI; Reference Power
Offset}table 38
Table 10: Primary Cell HSUPA Category according to Primary Cell E-DPDCH SF capability and
selected E-DCH TTI 40
Table 11: EdpchParameters instance according to Target HSUPA UE Category and selected E-DCH
TTI 41
Table 12: Grant Index values 55
Table 13: Scheduling Priority iCEM 60
Table 14: Example of E-DCH SPI settings 61
Table 15: Scheduling Priority xCEM 77

Page 5/132
FIGURES
Figure 1: Noise Rise vs. UL Load.................................................................................................................... 12
Figure 2: Example of uplink load (thermal noise/R99/E-DCH).................................................................... 13
Figure 3: Power allocation at RNC level ......................................................................................................... 21
Figure 4: {E-TFCI; Transport Block Size}tables for 10ms TTI, as defined in 3GPP TS 25.321............ 32
Figure 5: {E-TFCI; Transport Block Size}tables for 2ms TTI, as defined in 3GPP TS 25.321.............. 32
Figure 6: E-DPDCH Power vs. Transport Block Size................................................................................... 34
Figure 7: E-DCH parameters model at OMC-R............................................................................................. 39
Figure 8: UA6.0 reserved0 bit configuration................................................................................................... 48
Figure 9: RTWP exceeding margin.................................................................................................................. 54
Figure 10: Iub BW limitation mechanism........................................................................................................ 62
Figure 11: Uplink Iub Congestion detection: frame loss case................................................................... 64
Figure 12: Uplink Iub DeCongestion: frame loss case............................................................................... 65
Figure 13: Structure of the TNL Congestion Indication control frame........................................................ 66
Figure 14: Example of the GRF variation with the congestion status......................................................... 66
Figure 15: Local congestion control mechanism........................................................................................... 81
Figure 16: E-DCH UL OLPC general principle............................................................................................... 86
Figure 17: Cell State computation................................................................................................................... 91
Figure 18: UL OLPC in case of SRB on E-DCH............................................................................................ 93
Figure 19: HFI Reception Scenario computation........................................................................................... 94
Figure 20: 34249 RAN model for E-DCH UL RBs......................................................................................... 97
Figure 21: 34249 RAN model for E-DCH UL services and misc................................................................. 98

Page 6/132
1 INTRODUCTION
1.1 OBJECT
The objective of this volume (UA7 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 UA07. This includes a system description,
configuration aspect and engineering recommendations.

The following features are described in this volume:
Global
Market
USA
Market
29840
E-DCH Step1
(HSUPA)
isEdchAllowed, edchActivation
[iCEM] [xCEM]
edchResourceActivation
UA5.0 Yes Yes
UA5.1
33481
E-DCH DL control
channels Power
Control
Remark: UA6 version
of the feature also
exists (see below).
[iCEM] Feature not applicable.
[xCEM] Activated by default.
UA5.1 Yes Yes
34172
E-DPDCH
Retransmissions for
DPCCH SIR
Adaptation
isUlOuterPCActivated (for UL
services with E-DCH) UA5.1 Yes Yes
34221
Self-interference in
MAC-e Scheduler
[iCEM]
rotOrthogonalityEstimation
[xCEM] [UCU-III]
Feature not applicable.
UA5.1 Yes No
33327
MAC-e Scheduler
enhancements
edchSpiRelativeWeight
UA6.0 Yes No
33332
Iub bandwidth
limitation for E-DCH
isEdchBandwidthLimitationAllowe
d
UA6.0 Yes No
33336
HSUPA UE
categories 4 to 6
isEdchTti2msAllowed
UA6.0 Yes Yes
33367
HSPA congestion
detection &
notification
No activation flag.
UA6.0 Yes No
Page 7/132
UA6
33481
E-DCH DL control
channels Power
Control
[xCEM],
eagchPowerControlModeXcem
[UCU-III]
No activation flag
UA6.0 Yes Yes
33581
SRB on E-DCH
during call
[xCEM] [UCU-III]
isSrbOnEdchAllowed-
WhenTrbOnEdch
UA6.0 Yes Yes
34134
High RSSI Node-B
Alarm
RssiHighAlarmThreshold
UA6.0 Yes No
34175
UA06 HSPA
Capacity Evolutions
No activation flag.
UA6.0 Yes No
34249
EUL Capacity
Optimized HARQ
operation
[iCEM] Adaptive N
HARQ
Target
mechanism disabled.
[xCEM] [UCU-III]
No activation flag.
Feature can be restricted to UA5.1
mode by applying specific
parameter settings.
UA6.0 Yes Yes
34167
Defence mechanism
for UE not supporting
CM with HSPA
isEdchCmFallbackAllowed
UA6.0 Yes Yes
34229
IFHHO
Enhancements
isInterFreqHandover-
OverIurAllowed
UA6.0 No Yes
34438
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.

UA6.0 No Yes
34373
OneBTS
Interoperability Parity

UA6.0 No Yes
75786 iBTS Local E-DCH
Congestion Control
[iCEM][UCU-III]
Feature not applicable
[xCEM]
edchCMActivation
edchLocalCongestionControlActiv
ation
UA6.0 Yes No
81112 UL load estimation in
presence of urban
noise
[iCEM][UCU-III]
[xCEM]
UA6.0 Yes No
Page 8/132
maxEdchCommonChannelPower
LocFrequencyReuseFactor
34393 Advanced Receiver
for High UL Data
Rate
[iCEM]
[xCEM] [UCU-III]
gRakeActivation
UA7.1 Yes Yes
34441 2ms TTI on oneBTS
isEdchTti2msAllowed UA7.1 No Yes
34633 E-DCH Mac-e
throughput of
10Mbps
[iCEM]
[xCEM] [UCU-III]
No activation flag
UA7.1 Yes Yes

Page 9/132
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

[R01] UMT/DCL/DD/0020 UTRAN Parameters User Guide UA7.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 UTRAN Iub/Iur interface user plane protocol for
DCH data streams
Planning Guide
[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)
[R13] UMT/IRC/APP/021071 Guidelines for 9313 Micro NodeB Configuration
Engineering
[R14] UMT/IRC/APP/025147 CEM Capacity Eng'g Guide
[R15] UMT/BTS/DD/026060 EDCH 2ms TTI Support in OneBTS

Page 10/132
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 isEdchAllowed Object RadioAccessService
Range & Unit
False, True
User Customer
Class 3
Granularity RNC
Value True

Parameter edchActivation Object FDDCell
Range & Unit
False, True
User Customer
Class 2
Granularity Cell
Value True

[iCEM] [xCEM]
Parameter edchResourceActivation Object BTSCell
Range & Unit
False, True
User Customer
Class 0
Granularity Cell
Value True

[UCU-III] No activation flag under OneBTSEquipment object path.

Page 11/132
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.

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 (RTWP
ref
).
UL load =1 RTWP
ref
/ RTWP =1 1/Noise Rise
RTWP
ref
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.

[iCEM] [xCEM]
Parameter isRtwpReferenceSelfLearning Object BTSEquipment
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value True

Note that without RSEPS activation (refer to next section ) the reference RTWP is not
transmitted to the RNC. Therefore the non E-DCH RTWP transmitted through NBAP
common message assumed a default value for the thermal noise: NBAP RTWP
non E-
DCH
=-106.1 +RoT
non-EDCH
Parameter rtwpReference Object BTSCell
Range & Unit
[-115.0..-50.0] step:0.1 dBm
User Customer
Class 3
Granularity Cell
Value -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.
Page 12/132
The noise rise is expressed as:
Noise rise = RTWP/RTWP
ref

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 not to impact the E-DCH capacity. A correct value is between
50% and 85% (i.e. 3 and 8 dB noise rise).

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
0
2
4
6
8
10
12
14
16
18
20
UL load
N
o
i
s
e

R
i
s
e

(
d
B
)
Noise Rise vs. UL load
Page 13/132
Thermal Noise
CS12.2
CS12.2
PS64
CS64
Max allowed UL load
Available
UL load for
E-DCH
scheduling
R
S
S
I

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 E-
DCH 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.
Parameter rtwpMaxCellLoadNonEdch Object BTSCell
Range & Unit [0..100] (%)
User Customer
Class 3
Granularity Cell
Value 50

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
Page 14/132
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).

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.

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:
10 /
10
1
1
x totalRotMa
ch lLoadNonEd rtwpMaxCel
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
).

[UCU-III]
In OneBTS this parameter is used to determine the maximum noise rise to ensure
uplink coverage. The maximum E-DCH target load for the cell is set internally in the
OneBTS to 85% by default. In case totalRotMax is exceeded due to interference, the
the MAC-e scheduler will reduce its target load for E-DCH in order to reduce the total
uplink cell load. Thus, it is recommended to set this parameter to 15 dB to make the
likelihood of E-DCH target load roll-back low and preserve the E-DCH capacity as
much as possible.

Page 15/132
Parameter totalRotMax Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit Decimal [0.0 ... 20.0] step 0.1, dB
User Customer
Class 2 or 3
Granularity Cell
Value [iCEM] [xCEM]
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
[UCU-III] 15
Note: Please refer to UPUG Vol.6 for further details regarding the two distinct
parameter classes utilisation.

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:
DCH E DCH nonE
RTWP RTWP RTWP

=

Parameter isRtwpAdjustmentForRnc Object BTSEquipment
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value True

Page 16/132
Parameter referenceRtwp Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit [-112.0..-70.0] step:0.1, dBm
User Customer
Class 2 or 3
Granularity Cell
Value -106.1

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 since UA6 to improve the UL load
reporting for the UL load iRM.
When the RSEPS (Received Scheduled E-DCH 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)
E-DCH 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 E-DCH power (UA5 behavior).

Page 17/132
The RNC is now able to compute the non E-DCH load for iRM UL load as follow:

Before RSEPS activation:
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:
Total_RTWP, Reference_RTWP and RSEPS are sent by NodeB and
Non_Edch_Ul_Load is retrieved in RNC:
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 RNC
RadioAccessService / DedicatedConf / NodeBConfClass)
and
isUplinkRadioLoadEnabled (located under RNC RadioAccessService)
have to be set to the value True (please refer to [R01] for details about
these parameters).

Parameter isNbapCommonMeasRsepsAllowed Object NodeB
Range & Unit
False,true
User Customer
Class 3
Granularity BTS
Value True

Page 18/132
[UCU-III]
OneBTS 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 RTWP
ref
reliability for noise rise evaluation.
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 RTWP
ref
/ RTWP

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):
L
est,total
={L
est,s
+L
est,ns
+
Cpeer-serving
L
est,ps,C
+L
est,DCH
+L
est,HS-DPCCH
}x (1 +L
oc
) where:
L
est,s
is the estimated load portion for the serving users
L
est,ns
is the estimated load portion for the non-serving users
L
est,ps,C
is the estimated load portion for the peer-serving cell C
L
est,DCH
is the estimated DCH load for all users
L
est,HS-DPCCH
is the estimated load portion for HS-DPCCH
L
oc
is the other-cell interference factor accounting for the load impact from
users which have no active radio link in the cell

The value of L
oc
is obtained from the already mentioned parameter:
BTSEquipment/BTSCell/EdchConf maxEdchCommonChannelPower
Page 19/132
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 maxEdchCommonChannelPower Object EdchConf
Range & Unit [-35.0 +200.0] step:0.1, integer
User Customer
Class 3
Granularity BTSCell
Value 120
Note: In case of having 2 BTSCell belonging to the same carrier, if:
BTSCell#a has maxEdchCommonChannelPower <=100 and BTSCell#b has
maxEdchCommonChannelPower >100 (or vice-versa), then:
A warning is triggered demanding the same range (<=100 or >100).
UA6.0 UA7.0 Delta: New parameter locFrequencyReuseFactor
Parameter maxEdchCommonChannelPower will no longer be valid after UA6.0, and it will be
replaced in UA7.0 by the new parameter locFrequencyReuseFactor.

Parameter locFrequencyReuseFactor Object BTSCell
Range & Unit [0 500], step 1, integer
User Customer
Class 3
Granularity Cell
Value 20
Note: Value 0 deactivates the feature.

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.

Page 20/132
4.1.4 HIGH UL RSSI ALARM
The UL load is a key resource for E-DCH and its highly recommended to check the
UL RSSI before E-DCH activation and ensure that there is no HW or external
interferer that may impact the E-DCH 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 since 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.
This feature could be deactivated by setting the parameter RssiHighAlarmThreshold
to unset.
Parameter RssiHighAlarmThreshold Object BTSEquipment
Range & Unit
[-150dBm, -50dBm], 0.1dB
User Customer
Class 3
Granularity Cell
Value 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
Page 21/132
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).
CCC
RNC
SHO margin
P
traffic
R
N
C
OCNS (opt.)
P
minHsdpa
P
MaxCell
Max Power for HS-DSCH
& HS-SCCH, E-AGCH,
E-HICH and E-RGCH
to be transmitted
to the NodeB
E-DCH
CCC
RNC
SHO margin
P
traffic
R
N
C
OCNS (opt.)
P
minHsdpa
P
MaxCell
Max Power for HS-DSCH
& HS-SCCH, E-AGCH,
E-HICH and E-RGCH
to be transmitted
to the NodeB
E-DCH

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 eagchErgchEhichTotalPower Object EdchCellClass
Range & Unit Decimal [0.0 50.0] step:0.1, dBm
User Customer
Class 3
Granularity EdchCellClass
Value 10

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.
Page 22/132
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 E-
HICH 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 for
more information on E-DCH DL channels power control in xCEM and UCU-III.

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.3 for more information on handling of non-serving radio links and more
generally on E-DCH Macro Diversity.
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 eagchPower Object EdchConf
Range & Unit Signed [-35.0 15.0] step:0.1, dB
User Customer
Class 3
Granularity BTSCell
Value -2.5
Remark: Only one mobile can be addressed per E-AGCH channel and per TTI.

ehichPowerSignature: Power offset for one E-HICH signature, relative to CPICH
power.
Parameter ehichPowerSignature Object EdchConf
User Customer
Class 3
Granularity BTSCell
Value -8.0
Remark: On iCEM, up to 15 E-HICH signatures may be used on the same E-HICH/E-
RGCH channel (instead of 40 as of 3GPP) since the maximum number of E-DCH
radio links that can handle one E-BBU is 15.
Page 23/132
ergchPowerSignature: Power offset for one E-RGCH signature, relative to the
CPICH power.
Parameter ergchPowerSignature Object EdchConf
User Customer
Class 3
Granularity BTSCell
Value -8 dB
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.

For information, the following iCEM-specific parameters are also present in the 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.

[xCEM] [UCU-III]
On xCEM and UCU-III, 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 for xCEM 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.

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.
According to NodeB internal power check rules described in [Vol.3] section 8.4, must be set so that
the following equation is verified:
pcpichPower +ergchPowerSignature maxTxPower - 35.0 dB
It is recommended to set ergchPowerSignature to [maxTxPower - pcpichPower - 35.0 +3.0].
E.g: 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 to favor a proper detection of the E-RGCH commands by the UEs.
Page 24/132
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, 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.
Parameter maxNrOfEagch
Object EdchCellClass
Value 1
Remarks:
[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.

[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 E-
AGCH 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 E-
DCH traffic is expected, it is recommended to set maxNrOfEagch =1.

Page 25/132
Restriction: [iCEM] [xCEM] maxNrOfEagch
In 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 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 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
Value [iCEM] 1
[xCEM] 1
[UCU-III] 1
Remarks:
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 signature allocated per E-RGCH/E-HICH channel for
common relative grant to all UEs (set via edchNumCommonRgPerCode, see
Vol.6, section 3.3.3), and 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.
Page 26/132
With the introduction of the feature UA7.0 34386 64 QAM for HSDPA (see
[Vol.3]), a large amount of DL codes are needed to reach high downlink rates
supported by the HSDPA+UEs.
In order to save DL code resources, hence favour the HSDPA+performances, it is
recommended to set maxNrOfErgchEhich =1.
However, depending on the expected E-DCH traffic on the considered zone,
maxNrOfErgchEhich value could be increased up to 4 to maximize the possible
number of simultaneous E-DCH users per cell, but this will be at the expense of
the HSDPA+performances.

[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, maxNrOfErgchEhich could be set to 4.
However, in order to favour the HSDPA+ performances (see above), it is
recommended to set maxNrOfErgchEhich =1.

UA6.0 UA7.0 Delta: [xCEM] [UCUIII] maxNrOfErgchEhich
In UA7.0, it is recommended to set maxNrOfErgchEhich to 1 for xCEM and UCUIII (instead of 4 in
UA6.0), in order to save DL codes hence favour HSDPA+performances.

[xCEM] [UCU-III]
Remark on maximum number of E-DCH users per cell:
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 (or 116 with G-RAKE feature
activated, see section 11) can be supported per cell from a hardware point of view (up
to 128 E-DCH radio links (or 116) 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.

Page 27/132
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
possible to set maxNrOfErgchEhich =4. However, it is recommended to set maxNrOfErgchEhich
to 1 to save DL code resource, hence favour UA7 HSDPA+performances.

Configuration method:
If it is chosen to set different maxNrOfErgchEhich depending on the type of boards:
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.

Page 28/132
Restriction: [iCEM] [xCEM] maxNrOfErgchEhich
From UA6, for iCEM, up to 3 E-RGCH/E-HICH channels can be configured per cell.
From 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 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
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 iCEM:
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 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/E-
HICH
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.
Page 29/132
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. The 2ms TTI is supported
by the UCU-III board in UA7.1.
When 2ms TTI is activated by setting the parameters isEdchTti2msAllowed under
RadioAccessService and EdchCellClass to True, a UE supporting 2ms TTI (i.e.
CAT 2, 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
Parameter isEdchTti2msAllowed Object RadioAccessService
Range & Unit
True,False
User Customer
Class 3
Granularity RNC
Value True

Parameter isEdchTti2msAllowed Object EdchCellClass
Range & Unit
True,False
User Customer
Class 3
Value True
Remark: ttiType parameter under EdchConf is ignored by the system.

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 E-DCH call based on 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). For UA7.1,
Page 30/132
the UCU-III board supports the 2ms TTI for UE categories 2, 4 and 6, and up to 4
codes (2 SF2 +2 SF4) for UE category 6.
Terminal
Category
Maximum
Number
of Codes
Minimum
SF
TTI
[ms]
Maximum
MAC-e
PDU Size
[Bits]
Maximum
Date Rate at
MAC-e layer
[Mbps]
Maximum
RLC
Throughput
[Mbps]
Throughput @
ATM layer
(+30% protocol
headers)
[Mbps]
Category 1 1 SF 4 10 7110 0.71 0.67 0.87
Category 2 2 SF 4
10/
2
14484/
2798
1.45/
1.40
1.38/
1.28
1.79/
1.66
Category 3 2 SF 4 10 14484 1.45 1.38 1.79
Category 4 2 SF 2
10/
2
20000/
5772
2.00/
2.89
1.89/
2.72
2.45/
3.53
Category 5 2 SF 2 10 20000 2.00 1.89 2.45
Category 6 4 SF 2
10/
2
20000/
11484
2.00/
5.74
1.89/
5.44
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

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
Value For PS_HSDSCH_EDCH_IB_AM and SRB_HSDSCH_EDCH_AMUM
instances of RlcConfClass: 30

[UCU-III]
For the OneBTS UCU-III, for UA6 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 (and it would be
managed like a category 4 on 10ms TTI).
For UA7.1, the OneBTS UCU-III supports both 2 and 10 ms TTI for UE categories 2, 4
and 6, and up to 4 codes, 2 SF2 and 2 SF4 E-DPDCH codes for category 6.
Page 31/132
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). All four tables are available, i.e. for each E-DCH TTI type either
one of the two corresponding tables may be configured.
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.
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 iCEM, xCEM
and UCI-III, it is strongly recommended to use 10ms TTI E-DCH TBS Table 1.
Regarding 2ms TTI, as shown in Figure 5, 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. . For UCU-III, (for which 2ms TTI is available in
UA7.1) the same recommendation applies.

Parameter edchTfciTableIndex Object EdpchParameters
Range & Unit Enum {2msTtiTable0, 2msTtiTable1, 10msTtiTable0, 10msTtiTable1}, N/A
User Customer
Class 0
Granularity RNC
Value EdpchParameters instance related to 10ms TTI: 10msTtiTable1
EdpchParameters instance related to 2ms TTI: 2msTtiTable1

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 and UA7). Moreover the Table 0 is
not adapted to the E-DCH parameter settings (referenceEtfci/referenceEtfciPowerOffset,
ergch2IndexStepThreshold and ergch3IndexStepThreshold, )
As a consequence the Table 0 must not be used.
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.
Page 32/132

3GPP TB Table (TTI 10 ms)
0.0E+00
2.0E+03
4.0E+03
6.0E+03
8.0E+03
1.0E+04
1.2E+04
1.4E+04
1.6E+04
1.8E+04
2.0E+04
0 10 20 30 40 50 60 70 80 90 100 110 120
Transport bl ock si ze Index
T
r
a
n
s
p
o
r
t

b
l
o
c
k

s
i
z
e

(
b
i
t
s
)
10ms TtiTable0
10ms TtiTable1

Figure 4: {E-TFCI; Transport Block Size} tables for 10ms TTI,
as defined in 3GPP TS 25.321

3GPP TB Table (TTI 2 ms)
0.0E+00
2.0E+03
4.0E+03
6.0E+03
8.0E+03
1.0E+04
1.2E+04
0 10 20 30 40 50 60 70 80 90 100 110 120
Transport bl ock si ze Index
T
r
a
n
s
p
o
r
t

b
l
o
c
k

s
i
z
e

(
b
i
t
s
)
2ms TtiTable0
2ms TtiTable1

Figure 5: {E-TFCI; Transport Block Size} tables for 2ms TTI,
as defined in 3GPP TS 25.321

Page 33/132
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 E-
TFC Selection algorithm specified in 3GPP TS25.321 [R05]. The inputs of the E-TFC
Selection algorithm are:
Serving_Grant (also referred as SG):
Serving_Grant is the grant value deduced by the mobile from an E-AGCH or E-
RGCH 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.
{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.
E-DCH MAC-d flow-specific power offset:
Power offset assigned to each MAC-d flow of the considered E-DCH call
(sometimes also referred as
harq
).
From UA6 onwards, 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. The offset is
configurable 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).
Note that the offset specified for a given MAC-d flow is used regardless of the
number of MAC-d flows (user data only or user data and signaling) setup for the
call.
Amount of data to transmit on E-DCH in UE buffer
Available UE power
Number of slots in the 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 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, down to E-DCH
Minimum Set E-TFCI value. In UA5, E-DCH Minimum Set E-TFCI IE is sent to UE
Page 34/132
only if the board handling the E-DCH call is an xCEM. From UA6 onwards, this
parameter is also used for the UCU-III. E-DCH Minimum Set E-TFCI value is set
via edchMinSetEtfci parameter under EdpchParameters. Please refer to 7.2 for
a detailed description of edchMinSetEtfci parameter.

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; PO}table both at NodeB and at UE side, the RNC only
sends a few reference couples of values which constitute: the {Reference E-TFCI;
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.
Figure 6 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.
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
x 10
4
0
5
10
15
20
25
30
TB size (bits)
E
-
D
P
D
C
H

p
o
w
e
r

r
e
l
a
t
i
v

t
o

D
P
C
C
H

(
d
B
)
E-DPDCH power vs. transport block size
Reference signaled E-TFCI

Figure 6: E-DPDCH Power vs. Transport Block Size

Page 35/132
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.
Signaled values for
E-DPDCH
Quantized amplitude ratios
A
ed
=
ed
/
c

29 168/15
28 150/15
27 134/15
26 119/15
25 106/15
24 95/15
23 84/15
22 75/15
21 67/15
20 60/15
19 53/15
18 47/15
17 42/15
16 38/15
15 34/15
14 30/15
13 27/15
12 24/15
11 21/15
10 19/15
9 17/15
8 15/15
7 13/15
6 12/15
5 11/15
4 9/15
3 8/15
2 7/15
1 6/15
0 5/15
Table 2: Quantization for
E-DPDCH
(from 3GPP TS 25.213)

{REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLES
Below two parameters are used to define the different {Reference E-TFCI; Reference
Power Offset}tables within the RNC.
Parameter referenceEtfci Object ReferenceEtfciConfList
User Customer
Class 0
Granularity RNC
Value [xCEM] [iCEM] See below Table 3, Table 4, Table 5, Table 6
[UCU-III] See below Table 7, Table 8, Table 9

Page 36/132
Parameter referenceEtfciPowerOffset Object ReferenceEtfciConfList
User Customer
Class 0
Granularity RNC
Value [xCEM] [iCEM] See below: Table 3, Table 4, Table 5, Table 6
[UCU-III] See below Table 7, Table 8, Table 9

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 four recommended tables for OneBTS using the (i.e.
10 ms TTI on UA6.0 on UCU-III, new 10 ms TTI on UA7.1 and 2ms TTI with E-
DPDCH min SF of 2xSF2 on UCU-III, 2ms TTI with E-DPDCH min SF of
2xSF2+2xSF4 on UCU-III), as well as the recommended configuration method are
described below.
UA6 UA7.1 Delta: [UCU-III] {Reference E-TFCI; Reference Power Offset} table
Due to the introduction of 2ms E-DCH TTI support in UA7.1 for UCU-III, new {Reference E-TFCI;
Reference Power Offset}tables (corresponding to 2ms TTI cases) are introduced.

[iCEM] [xCEM]
Reason for using board-specific {Ref E-TFCI; Ref PO}tables (10ms TTI case):
Regarding 10ms TTI, due to the specific implementation and behavior of xCEM E-
DCH 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 of this volume and to [R01] for more information
on the recommended setting for maxSirTarget for E-DCH calls.

For iCEM, the recommended {Reference E-TFCI; Reference Power Offset}table is as
follows.
ReferenceEtfciConfList referenceEtfci referenceEtfciPowerOffset
0 0 2
1 3 11
2 11 15
3 85 22
4 95 23
5 96 24
Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset} table
Page 37/132
For xCEM with 10ms, the recommended {Reference E-TFCI; Reference Power Offset}
table is as follows.
0 3 9
1 5 10
2 25 16
3 51 18
4 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.
0 3 13
1 5 14
2 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
0 3 13
1 5 14
2 58 15
3 91 18
4 98 21
Table 6: xCEM/2ms TTI/2xSF2+2xSF4 recommended {Reference E-TFCI; Reference Power
Offset} table

[UCU-III]
As a reminder, in UA6.0 for the OneBTS UCU-III only the 10 ms TTI is supported. In
UA7.1 the OneBTS UCU-III can now support the 2ms and 10 ms TTIs. Additionally, for
Category 6 UEs, up to 4 SF codes are supported (2SF2 +2SF4).

Page 38/132
The recommended {Reference E-TFCI; Reference Power Offset}table is as follows for
the UCU-III and 10 ms TTI for both UA6.0 and UA7.1.
0 3 10
1 9 13
2 25 17
Table 7: UCU-III/10 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset}
table

For the UCU-III with 2ms TTI and E-DPDCH min SF of 2xSF2, the recommended
0 3 13
1 5 14
2 83 20
Table 8: UCU-III/2 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset}
table

For the UCU-III with 2ms TTI and E-DPDCH min SF of 2xSF2+2xSF4, the
recommended {Reference E-TFCI; Reference Power Offset}table is as follows.
0 3 13
1 5 14
2 58 15
3 91 18
4 98 21
Table 9: UCU-III/2 ms TTI/2XSF2 + 2XSF4 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.

Page 39/132
{REF E-TFCI; REF PO} TABLE SELECTION MECHANISM
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:
The HSUPA Category of the considered UE,
The type of board (iCEM , xCEM or UCU-III) handling E-DCH for the E-DCH
serving cell (known by E-DPDCH SF capability of the E-DCH serving cell).
The requested UL service (e.g. E-DCH stand-alone or E-DCH +CS AMR NB).
This is achieved by using multiple EdpchInfoClass instances, as shown in Figure
7
The requested type of E-DCH TTI (i.e. 10ms or 2ms)

Remark: The reason why cell E-DPDCH SF capability is taken into account in {Ref E-
TFCI; 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 or UCU-III. Indeed,
the optimal table is different for each type of board. The RNC does not have the direct
knowledge of the type of board (iCEM or xCEM or UCU-III) 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 (limited to 2xSF4) is different than for the xCEM or
UCU-III, by looking at the SF capability of a given cell the RNC can know the type of
board that serves it.
The parameters model at OMC-R (i.e. at RNC) is defined as follows.

Figure 7: E-DCH parameters model at OMC-R

RadioAccessService

EdpchInfoClass
EdpchParameters

UlUserService

UlRbSetConf

EdchParameters

ReferenceEtfciConfList

EdchCellClass

DedicatedConf
Page 40/132
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.

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.

Selected E-DCH TTI

10ms 2ms
SF64 16 16
SF32 16 16
SF16 16 16
SF8 16 16
SF4 1 2
2xSF4 3 2
2xSF2 5 4
P
r
i
m
a
r
y

C
e
l
l

E
-
D
P
D
C
H

S
F

C
a
p
a
b
i
l
i
t
y

2xSF2+2xSF4 16 16
Table 10: Primary Cell HSUPA Category according to Primary Cell E-
DPDCH SF capability and selected E-DCH TTI

Remarks:
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. This case applies to both the Global and US
markets.

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.

Page 41/132
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.
Selected E-DCH TTI

10ms 2ms
1 UECategory1EdchTti10ms N/A
2 UECategory2EdchTti10ms UECategory2EdchTti2ms
T
a
r
g
e
t

H
S
U
P
A

U
E

C
a
t
e
g
o
r
y

Table 11: EdpchParameters instance according to Target HSUPA UE
Category and selected E-DCH TTI

UA6 UA7.1 Delta: {Reference E-TFCI; Reference Power Offset} table
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 28 (9 UA6 + 19 UA7) available instances. Although, these new 19 EdpchParameters
instances are not still available to be used.

Page 42/132
{REF E-TFCI; REF PO} TABLE SETTING AT OMC
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
Set xCEM/10ms TTI recommended table (Table 4) for the following EdpchParameters
instances:
Set xCEM/2ms TTI/2xSF2 recommended table (Table 5) for the following EdpchParameters
instances:
Set xCEM/2ms TTI/2xSF2+2xSF4 recommended table (Table 6) for the following
EdpchParameters instance:
[UCU-III]
For all EdpchInfoClass instances for UA6.0, set UCU-III recommended table (Table 7) for all
EdpchParameters instances.
For all EdpchInfoClass instances for UA7.1:
Set UCU-III/10 ms TTI recommended table (Table 7) for the following EdpchParameters
instances:
Set UCU-III/2 ms TTI/2xSF2 recommended table (Table 8) for the following EdpchParameters
instances:
Set UCU-III/2 ms TTI/2xSF2 +2xSF4 recommended table (Table 9) for the following
EdpchParameters instances:

Page 43/132
{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, of this document.
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
E-DCH 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). Only unbundling mode is supported.
isEdchFpBundlingModeForEdchTti2msAllowed: when a RAB is mapped on E-
DCH 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 isEdchFpBundlingModeForEdchTti2msAllowed Object NodebConfClass
Range & Unit Boolean (True, False)
User Customer
Class 3
Granularity NodebConfClass
Value False

Restriction: 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.

Page 44/132
[UCU-III]
From UA7.1 onwards, the UCU-III can support the 2ms TTI. When E-DCH is
configured with TTI of 2ms, the OneBTS using the UCU-III supports unbundling mode
only.

E-DCH FP CRC PAYLOAD PRESENCE
The RNC performs a validation of the payload section of the Iub E-DCH data frames
(payload CRC check).
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.

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.

[iCEM] [xCEM]
The following parameter is used for 10ms TTI:
Parameter powerOffsetForSchedInfo Object EdchCellClass
Range & Unit Integer [0 6], dB
User Customer
Class 3
Value 6

The following parameter is used for 2ms TTI:
Parameter powerOffsetForSchedInfoEdchTti2ms Object EdchCellClass
User Customer
Class 3
Value 3

Page 45/132
[UCU-III]
Parameter powerOffsetForSchedInfo Object EdchCellClass
User Customer
Class 3
Value 0

Since UA7.1, the UCU-III supports the 2 ms TTI. The following parameter is used for
2ms TTI:
Parameter powerOffsetForSchedInfoEdchTti2ms Object EdchCellClass
User Customer
Class 3
Value 3

5.6.1 PLNON-MAX
PL stands for Puncturing Limit. PL
max
and PL
non-max
quantities are used as inputs in
the algorithm (implemented both at NodeB side and at UE side) computing for each E-
TFCI the required number of E-DPDCH(s) and their SF (see 3GPP TS 25.212 [R03]).
PL
max
value is specified in 3GPP TS 25.212 [R03], section 4.8.4.1.
On the other hand, PL
non-max
value is not specified by 3GPP. PL
non-max
value can be set
via plNonMax parameter under EdpchParameters.
plNonMax: Used to set the value of PL
non-max
. plNonMax parameter value must be
specified as plNonMax =25 * PL
non-max
.
Parameter plNonMax Object EdpchParameters
Range & Unit Integer [11 25], 25 * PL
non-max

User Customer
Class 3
Granularity RNC
EdpchParameters instance plNonMax value
[iCEM] [xCEM] 25
(corresponds to PL
non-max
=1)
[UCU-III] 18
(corresponds to PL
non-max
=0.72)
[xCEM] [UCU-III] 18 (corresponds to
PL
non-max
=0.72)
Value
[xCEM] [UCU-III] 20 (corresponds to
PL
non-max
=0.8)
Remark: Similarly to {Reference E-TFCI; Reference Power Offset}table, the PL
non-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.
Page 46/132
UA6.0 UA7.0 Delta: [UCUIII] plNonMax
Since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, 20 is the new recommended value for
plNonMax for category 2, 4 and 6 UEs.

5.6.2 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 UA7 UPUG [R01], Vol.9, section 2 for details on this procedure.
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 E-DCH calls, the
Algo2 is the most suitable: it ensures stable performance because it is less reactive to
power variations (TPC rate is 300 commands/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
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 parameters
isTpcAlgo2ForEdchCat4 and isTpcAlgo2ForEdchCat6 in the Radio Access
Service, are used.
isTpcAlgo2ForEdchCat4: SRB UL ILPC algorithm selection for UeCategory4 call
when it is in TTI2ms cell.
FALSE: Use default Algo1 for E-DCH UeCategory4 call when it is in TTI2ms cell
TRUE: Use Algo2 for E-DCH UeCategory4 call when it is in TTI2ms cell
Parameter isTpcAlgo2ForEdchCat4 Object RadioAccessService
Range & Unit Boolean
User Customer
Class 3-a2
Granularity RNC
Value True

isTpcAlgo2ForEdchCat6: SRB UL ILPC algorithm selection for UeCategory6 call
when it is in TTI2ms cell
FALSE: Use default Algo1 for E-DCH UeCategory6 call when it is in TTI2ms cell
TRUE: Use Algo2 for E-DCH UeCategory6 call when it is in TTI2ms cell
Parameter isTpcAlgo2ForEdchCat6 Object RadioAccessService
User Customer
Class 3-a2
Granularity RNC
Value True

Page 47/132

Rule: UL ILPC Algo2 must be used for E-DCH UECategory4 call and E-DCH UECategory6 call
when the cell is TTI2ms
In order to force the use of UL ILPC Algo2 for E-DCH UeCategory4 call and E-DCH UECategory6 call,
when the cell is TTI2ms, the parameters isTpcAlgo2ForEdchCat4 and isTpcAlgo2ForEdchCat6
must be set to TRUE.
Note that these parameters have no effect when the cell is TTI10ms: in this case the UL ILPC Algo1 is
used regardless of their values.

Recall that since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, care must be
taken to ensure the recommended values for the isTpcAlgo2ForEdchCat4 and
isTpcAlgo2ForEdchCat6 parameters are properly set.

Page 48/132

UA6.0, UA7.0 UA7.1 Delta: Usage of reserved0 in Radio Access Service
In UA6.0, the parameter reserved0 was used as follows :
Figure 8: UA6.0 reserved0 bit configuration
Thus, the reserved0 recommended value (in decimal) was: 50332928 for Global Market and 70151for US
Market.

In UA7.0, the 1
st
and 2
nd
less significant bytes of the parameter reserved0 are freed and replaced by new
parameters. The 1st byte is replaced by isSrbOnEdchForAllEdchCategory, isSrbOnEdchForAllMinSf,
isSrbOnEdchForAllEdchTti (refer to the section 10 in this volume).The 2nd byte is replaced by
reconfigTimeDchFach (refer to [R01] Volume 11).

From UA7.1, the 4th less significant byte of the parameter reserved0 is freed and replaced by new
parameters (isTpcAlgo2ForEdchCat4 and isTpcAlgo2ForEdchCat6, see above).
The 1st and 2nd less significant bytes are re-used for the feature 28528 Multi-Operator Core Network
(MOCN). (refer to [R01] Volume 15)
The 3rd less significant byte remains used as in UA6.0 to distinguish Global Market (bit 16 is set to 0) and
US Market (bit 16 is set to 1)
Refer to the engineering recommendation below.

Engineering Recommendation: reserved0 in Radio Access Service
In UA7.0, the reserved0 recommended value is:
[GM] 50331648 (decimal) 00000011 00000000 00000000 00000000 (binary)
[US MARKET] 65536 (decimal) 00000000 00000001 00000000 00000000 (binary)
In UA7.1, the reserved0 recommended value is:
[GM] 00000000 00000000 xxxxxxxx xxxxxxxx (binary). The first and second less significant bytes
are operator dependant if the feature 28528 Multi-Operator Core Network (MOCN) is configured
(refer to [R01] Volume 15), else they are unused and could be set to 0.
[US MARKET] 65536 (decimal) - 00000000 00000001 00000000 00000000 (binary)

The bits 24 and 25 were used for
UL ILPC Algorithm selection for
UeCat4 TTI2ms and UeCat6
TTI2ms EDCH calls. See below.
The bit 16 was used
to distinguish Global
Market (value 0) and
US Market (value 1)
The bits 0, 1 and
2 were used for
SRB on EDCH
activation.
The bit 8 was used to
control the execution
time of the
reconfiguration from
cell DCH to Cell FACH
bit number 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
Reserved0

Page 49/132
5.6.3 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 to the UE (and the Nodeb) via RRC (and NBAP) at E-DCH call
establishment.
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. The E-DCH Mac-
d Flow Power Offset is configurable per E-DCH 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.
E-DCH Mac-d Flow Power Offset value is set via edchMacdPowerOffsetEdchTti10
(this parameter is used when the call is configured on TTI10ms), and
edchMacdPowerOffsetEdchTti2 (this parameter is used when the call is configured
on TTI2ms) under UlRbSetConf/EdchParameters.
[xCEM] edchMacdPowerOffsetEdchTti10: the recommended value for
edchMacdPowerOffsetEdchTti10 is 0.
Parameter edchMacdPowerOffsetEdchTti10 Object EdchParameters
Range & Unit
[0..6] step:1
User Customer
Class 0
Granularity UlRbSetConf
Value 0

[UCU-III] In the UCU-III, the SRB_EDCH is always present along with the PS
EDCH, so the recommended values for edchMacdPowerOffsetEdchTti10 are 5
and 0 as shown below.
Range & Unit
[0..6] step:1
User Customer
Class 0
Value
For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 5

[xCEM] [UCU-III] edchMacdPowerOffsetEdchTti2: when the E-DCH TTI is 2ms,
two E-DCH 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.
Page 50/132
Range & Unit
[0..6] step:1
User Customer
Class 0
Value
For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 0

Recall that since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, 0 is the
recommended value for the edchMacdPowreOffsetEdchTti2 parameter.
Page 51/132
6 MAC-E SCHEDULER iCEM
6.1 UL LOAD FINE PREDICTION
Previously to UA6 the UL load estimation model was 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 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 = RTWP-
RTWP_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 rotPredictionCorrection Object EdchConf
Range & Unit
Off, On
User Customer
Class 3
Granularity BTS
Value 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 rotMarginPrediction Object EdchConf
Range & Unit
[0..10]
User Customer
Class 3
Granularity BTS
Value 5

Page 52/132
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 E-
DCH, the following actions are performed within the NodeB:
Derivation, every 24 hours, of the thermal noise level (RTWP
ref
) at the BTS, via
thermal noise level self-learning algorithm (c.f. section 4.1.1), basing on
measurements at the BTS
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.
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.
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.
Page 53/132
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).
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:
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 RTWP
non 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.
Restriction: RTWP
non E-DCH
sent to the RNC does not benefit from UA5.1/iCEM 34221 feature
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 RTWP
non E-DCH
sent every 100ms from the
NodeB to the RNC via NBAP does not benefit from this improvement.

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.
Page 54/132
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 rotOrthogonalityEstimation Object EdchConf
Range & Unit Enum {Off, On}, N/A
User Customer
Class 3
Granularity BTSCell
Value On

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:
DCH E DCH nonE
RTWP RTWP RTWP

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

Figure 9: RTWP exceeding margin

Parameter rtwpMargin Object BTSCell
Range & Unit
[0.5..2.0] step:0.5 dB
User Customer
Class 3
Granularity Cell
Value 2 dB

ALARM
totalRoTMax
rtwpMargin
Time
rtwpTimeDetection
OK
OK
RoT
Page 55/132
Parameter rtwpTimeDetection Object BTSCell
Range & Unit
[100..400] step:100 ms
User Customer
Class 3
Granularity Cell
Value 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]:
Absolute Grant Value Index
(168/15)
2
x6 31
(150/15)
2
x6 30
(168/15)
2
x4 29
(150/15)
2
x4 28
(134/15)
2
x4 27
(119/15)
2
x4 26
(150/15)
2
x2 25
(95/15)
2
x4 24
(168/15)
2
23
(150/15)
2
22
(134/15)
2
21
(119/15)
2
20
(106/15)
2
19
(95/15)
2
18
(84/15)
2
17
(75/15)
2
16
(67/15)
2
15
(60/15)
2
14
(53/15)
2
13
(47/15)
2
12
(42/15)
2
11
(38/15)
2
10
(34/15)
2
9
(30/15)
2
8
(27/15)
2
7
(24/15)
2
6
(19/15)
2
5
(15/15)
2
4
(11/15)
2
3
(7/15)
2
2
ZERO_GRANT* 1
INACTIVE* 0
Table 12: Grant Index values

Page 56/132
Once the grant is signaled, the E-DPDCH power should not exceed the grant
information:
2
.
ed
n <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)
o Highest priority logical channel ID (HLID, 4 bits)
o Highest priority logical channel buffer status (HLBS, 4 bits)
o 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. The parameter
happyBitDelay defines the delay to be used by the UE in its procedure to set
the Happy Bit. The happyBitDelay value is signaled to the UE at call setup.
Please refer to the section 7.1 for the description of this parameter.
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).
Please refer to the section 7.1 for the description of these parameters.

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.
Page 57/132
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 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 E-
DCH. 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 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 iCEM, only one type of E-DCH scheduling is supported: Rate Scheduling .
Parameter edchSchedulerAlgorithm Object BTSEquipment
Range & Unit Enum {roundRobinSlidingWindow, rateScheduling}
User Customer
Class 3
Granularity Cell
Value rateScheduling

In 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)
R99 uplink radio load has changed significantly
Periodically, for UEs that are granted above the fairness index (the fairness
index is computed by the scheduler, it represents the grant corresponding to a
fair allocation between active UEs). This periodicity is configurable through the
parameter edchRateSchedulerOptimisationTimer. It is recommended to set
it to 10 TTI (100ms).
Periodically each 500ms
Page 58/132
For more details, see [R04].
edchRateSchedulerOptimisationTimer is the period over which UE can be granted
more than its nominal quantum.
Parameter edchRateSchedulerOptimisationTimer Object BTSEquipment
Range & Unit [10..50] step 4. Unit=TTI
User Customer
Class 3
Granularity BTS
Value 10

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 E-
TFCI 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 E-
DCH 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.
Since UA5/iCEM, the following defense mechanisms against E-AGCH bad detection
have been implemented in the MAC-e scheduler.
Page 59/132
Imple-
mentation
Release
E-AGCH bad detection case
(detection is done on reception of
E-DPCCH at NodeB)
Action taken by MAC-e scheduler
UA5.0 UE uses an E-TFCI higher than
the maximum E-TFCI allowed
according to current grant
computed by MAC-e scheduler
for this UE.
UA5.0 UE sends a MAC-e PDU that only
includes SI (no payload),
although MAC-e scheduler has
granted this UE with a grant
different than Zero Grant.
UA5.1
onwards
Happy Bit received from UE is set
to unhappy, while UE uses an E-
TFCI lower than [the maximum E-
TFCI allowed according to current
grant computed by MAC-e
scheduler for this UE] -3.
For a given UE, each time any of beside cases is
detected (on reception of E-DPCCH at NodeB), an E-
AGCH error counter is incremented for this UE. The E-
AGCH 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
limit (7), an E-AGCH Alarm is raised for this UE.
MAC-e scheduler then resends E-AGCH commands
(the same command that has been sent previously but
not detected or wrongly decoded) to UEs for which an
E-AGCH alarm has been raised.
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 E-
AGCH channel is preempted (with regards to already
planned E-AGCH commands) in order to resend the E-
AGCH command as soon as possible.

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.

Parameter siActivityTimer (iCEM-specific) Object BTSEquipment
Range & Unit Integer [8 48] (step: 4). TTI.
User Customer
Class 3
Granularity BTSEquipment
Value 12

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.):
Page 60/132
Scheduling Priority Internal priority level
Highest Priority 15 Prio_Level_Gold
14 Prio_Level_Silver
13 Prio_Level_Bronze
12
11
10
9
8
7
6
5
4
3
2
1
Lowest Priority 0
Prio_Level_Other
Table 13: 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.
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 edchSpiRelativeWeight Object EdchConf
Range & Unit
[1..16][0..100]
User Customer
Class 0
Granularity BTSCell
Value 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 =15] 100

Page 61/132
[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.

Table Inputs Table Outputs
Traffic Class ARP THP OLS MLP
HSDPA
SPI
E-DCH
SPI
1 Gold
2 Silver Conversational
3 Bronze
Not used Not used
1 Gold 15
2 Silver 14 Streaming
3
N/A.
Bronze
N/A.
13
Not used
1 Gold 8 12 15
2 Gold 7 11 15 1
3 Gold 6 10 15
1 Silver 5 9 14
2 Silver 4 8 14 2
3 Silver 3 7 14
1 Bronze 2 6 13
2 Bronze 2 5 13
Interactive
3
3 Bronze 2 4 13
1 Gold 1 3 12
2 Silver 1 2 12 Background
3
N/A.
Bronze 1 1 12
Table 14: Example of E-DCH SPI settings

Parameter edchSpi Object ThpBasedQos
Range & Unit [0 15]
User Customer
Class 3
Granularity RNC,
TrafficClassBasedQos,
ArpBasedQos,
ThpBasedQos
Value Depends on customer strategy

Page 62/132
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 E-DCH scheduler
and limit the UL radio and HW resources to the available Iub BW for E-DCH (Iub BW
not used by R99 traffic).

In order to perform this mechanism the congestion status should be known, thus a
direct interaction with feature HSPA congestion detection & notification (33367) is
necessary.

The iub BW limitation for E-DCH is performed in three main steps

UL iub congestion detection by the RNC

Iub congestion indication to NB

Iub BW congestion management by E-DCH scheduler

Figure 10: Iub BW limitation mechanism

This feature can be activated/deactivated at NodeB level via the flag
isEdchBandwidthLimitationAllowed under BTSEquipment.
TNL congestion notification to NodeB
HSUPA Throughput
Iub
HSUPA congestion detection by RNC
Node B
RNC
HSUPA BW limitation by Node B
TNL congestion notification to NodeB
HSUPA Throughput
Iub
Node B
RNC
Iub
Node B
RNC
Page 63/132
Parameter isEdchBandwidthLimitationAllowed Object BTSEquipment
Range & Unit False,True
User Customer
Class 3
Value True

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 FSN
n
>FSN
n-1
+1, P frames
are missing and might be lost, but it could also be due to IP de-sequencing issue.
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.
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 FSN
n
, and the nominal algorithm is resumed.
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 FSN
n
is assigned with the last received frame,
and the nominal algorithm is resumed.

Page 64/132

Figure 11: Uplink Iub Congestion detection: frame loss case

Parameter nFramesBeforeEdchCongestion Object RNC INode
Range & Unit 0..255
User Customer
Class NA
Granularity Inode
Value 1

Parameter deSequencingWaitTimer Object RNC INode
Range & Unit 0..100
User Customer
Class NA
Granularity Inode
Value 0

With 10ms TTI, when N succeeding E-DCH UL Data Frames have their successive
FSN N
n
= N
n-1
+1, the leg is marked as non-congested. N is controlled by the
parameter nFramesBeforeEdchDeCongestion.
With 2ms TTI in non-bundling mode, the algorithm uses parameter
nFramesBeforeEdchDeCongestion multiplied by 5.

Page 65/132

Figure 12: Uplink Iub DeCongestion: frame loss case

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 nFramesBeforeEdchDeCongestion Object RNC INode
Range & Unit 0..255
User Customer
Class NA
Granularity Inode
Value 50

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.
Parameter congestionControlPeriod Object RNC INode
Range & Unit 0..2550 in step of 10ms
User Customer
Class NA
Granularity Inode
Value 40

When a congested Mac-d flow becomes non-congested, the RNC sends one TNL
Congestion indication message with cause No TNL Congestion.

Page 66/132

Figure 13: Structure of the TNL Congestion Indication control frame.

6.8.3 UL IUB CONGESTION MANAGEMENT IN E-DCH
SCHEDULER
Every E-DCH congestion control period the NodeB updates a GRF:

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.

Figure 14: Example of the GRF variation with the congestion status

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)
Page 67/132
The following parameter is a timer that controls the periodicity where the NodeB
modifies the reduction factor.
Parameter edchBLSupervisionTimer Object BTSEquipment
Range & Unit [10..1000], step: 10ms
User Customer
Class 3
Granularity BTS
Value 80

The following parameters control the reduction/increase applied to the reduction factor
when frame loss is detected.
When edchBLSupervisionTimer expires, and if the MAC-d flow is marked as
congested because of frame loss, the reduction factor is reduced by
edchBLStepReductionFrameLoss; and if the MAC-d flow is marked as not
congested, the reduction factor is increased by edchBLStepIncrease.
Parameter edchBLStepReductionFrameLoss Object BTSEquipment
Range & Unit 0..100 in %
User Customer
Class 3
Granularity BTS
Value 1

Parameter edchBLStepIncrease Object BTSEquipment
Range & Unit 0..100 in %
User Customer
Class 3
Granularity BTS
Value 1

The operator dependant parameter edchBLIubBandwidth, corresponds to the
maximum bit rate that is supported in the Iub.
Parameter edchBLIubBandwidth Object BTSEquipment
Range & Unit [100..200000], step:100 kbps
User Customer
Class 3
Granularity BTS
Value 200 000 (default value)

Page 68/132
7 MAC-E SCHEDULER xCEM
The task of the scheduler is to fairly distribute the available E-DCH load among the E-
DCH users while keeping the uplink load within a limit 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, "happy bit" and currently used E-TFCI/transport
block size
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 E-DCH traffic (MAC-e layer), that can
be used.
Remark: This parameter limits the throughput at the MAC-e level. A correct
extrapolation has to be done in order to achieve the desired throughput at
the 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 UE. So 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).
[UCU-III]
For OneBTS there is no OAM restriction of the E-DCH processing resources
possible.
The UA7 feature 34633 E-DCH Mac-e throughput of 10Mbps increases the
maximum E-DCH Mac-e throughput from 7.7Mbps (UA6 value) to 10Mbps
for xCEM and UCU-III channel cards in the iBTS and OneBTS, by upgrading
and optimizing the CE firmware code. This feature improves the TTI10ms
Page 69/132
and especially TTI2ms performances. Refer to [R14] for more details. This
enhancement is available with upgrade to UA7 and there is no activation
flag.
- 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. RTWP
ref
will be adjusted according to self-
learned RTWP value in the NodeB, as well as the resulting RoT.
- 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 targetNonServingToTotal-
EdchPoweRatio (see Vol.6 for further details regarding this parameter).

The target UL load L
target
is derived and is defined as the most restricting criterion
among above limitations.
The first parameter is specific to xCEM only, next two are common between iCEM and
xCEM and last one is common among UCU-III, xCEM and iCEM (please refer to
section 4.1.1 for further details).

Parameter edchMaxThroughputXcem Object BTSEquipment
Range & Unit {[480..10080],automatic }step:480kbps
User Customer
Class 3
Granularity HsXpaResource
Value automatic

Parameter isRtwpReferenceSelfLearning Object BTSEquipment
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value True

Parameter rtwpReference Object BTSCell
Range & Unit
[-115.0..-50.0] step:0.1 dBm
User Customer
Class 3
Granularity Cell
Value -106.1

Page 70/132
Parameter totalRotMax Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit Decimal [0.0 ... 20.0] step 0.1, dB
User Customer
Class 2 or 3
Granularity Cell
Value [iCEM] [xCEM]
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
[UCU-III] 15

Measurements
RTWP is reported every 100ms to the MAC-e scheduler.
[xCEM][UCU-III],
Estimates every 10ms the average total UL load L
E-DCH
generated by E-DCH
serving users, non-serving users and peer-serving users.
The total UL load (E-DCH or not) L
total
is also generated according to RTWP
measurements or Ec/I0 and TPR measurements depending on selected
mode, allowing to derive the L
non E-DCH
=L
total
L
E-DCH
.

[UCU-III]
RTWP is reported every 2ms to the MAC-e scheduler for OneBTS.
L
total
will be generated according to Ec/Io and TPR measurements, allowing to
derive the L
non E-DCH
=L
total
L
E-DCH
.

The available E-DCH load is then derived and corresponds to L
available, E-DCH
=L
target
-
L
non E-DCH
. If L
available, E-DCH
<=0, then the cell is overloaded.

UE specific information
- Happy bit status
- Scheduling information
- Reference scheduling grant SG
ref, i
, taken from previous scheduling interval
- Average transport block size i.e. PHY throughput

The parameter happyBitDelay defines the delay to be used by the UE in the
procedure to set the Happy Bit when E-DCH TTI selected is 10ms.
Page 71/132
Parameter happyBitDelay Object EdchCellClass
Range & Unit
Enum {2, 10, 20, 50, 100, 200, 500, 1000}
User Customer
Class 3
Granularity RNC,
EdchCellClass
Value [iCEM][xCEM] 50
[UCU-III] 10

The parameter happyBitDelayEdchTti2ms defines the delay to be used by the UE in
the procedure to set the Happy Bit when E-DCH TTI selected is 2ms.
Parameter happyBitDelayEdchTti2ms Object EdchCellClass
Range & Unit
Enum {2, 10, 20, 50, 100, 200, 500, 1000}
User Customer
Class 3
Value 10

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 L
hypothetical
<=L
available
, AG
and/or RG are sent to UEs. Otherwise, the MAC-e scheduler shall reduce the target
grants.

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, TB
requested
, 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.

[xCEM]
If an SI is received while UE is not granted, the MAC-e scheduler assumes for initial
grant computation that TB
requested
= 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.

Page 72/132
[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.
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).

[UCU-III]
For the OneBTS, the equivalent to edchInitialTBIndex10msTTI and
edchInitialTBIndex2msTTI are internal NodeB tunable parameters.

The requested TB is converted to a target grant SG
target, i
for each UE i and the total
UL load L
hypothetical
is computed. If L
hypothetical
<=L
available
, all the requests can be fulfilled
and the MAC-e scheduler proceeds with AG and/or RG sending.
Otherwise, the MAC-e scheduler reduces the requested grants.
The two following parameters are applicable to iCEM and xCEM boards (not UCU-III).
Parameter edchInitialTBIndex10msTTI Object EdchConf
Range & Unit
[0..127] step 1
User Customer
Class 3
Granularity BTSCell
Value 52

Parameter edchInitialTBIndex2msTTI Object EdchConf
Range & Unit
[0..127] step 1
User Customer
Class 3
Granularity BTSCell
Value 8

Hypothetical overload
L
hypothetical
> L
available
: this condition corresponds to hypothetical overload situation
posterior to update of requested TB of all UEs.
Each UE i is ranked according to the UE throughput and a scheduling weight SW
i

depending on the UEs SPI.
The MAC-e scheduler first checks if the interference created by non-serving UEs
compared to the total E-DCH interference is smaller than or equal to Target Non-
serving 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.
Page 73/132
The MAC-e scheduler shall also check whether the interference created by the peer-
serving 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, down to E-DCH Minimum Set E-
TFCI value. In addition, according to [R05], the applicability of E-DCH Minimum Set E-
TFCI 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
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.
Since UA5.1, 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.
E-DCH Minimum Set E-TFCI value is set via edchMinSetEtfci parameter under
EdpchParameters. From UA6 onwards, this parameter is also used for the UCU-III.
Parameter edchMinSetEtfci Object EdpchParameters
Range & Unit
[0..127] step:1
User Customer
Class 0
Granularity EdpchInfoClass
Value EdpchParameters instances related to 10ms TTI: 7
EdpchParameters instances related to 2ms TTI: 3

7.3 OVERLOAD ALGORITHM
L
available
<= 0: this condition corresponds to actual overload situation. In this case, the
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 triggered 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.

Page 74/132
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 isEdchSchedulingInfoReportingAllowed Object EdchParameters
Range & Unit False,True
User Customer
Class 3
Value True

Parameter isEdchSchedulingInfoReportingEdchTti2msAllowed Object EdchParameters
Range &
Unit
False,True
User Customer
Class 3
Value True

The amount of time with no data from UE, used to consider a UE as inactive, is
configurable through the parameter edchInactivityTimerXcem.
Parameter edchInactivityTimerXcem Object EdchConf
Range & Unit [0..20000ms] step 40
User Customer
Class 3
Granularity BTScell
Value 1440
Note: this parameter is not applicable to iCEM. iCEM has an equivalent parameter
called siActivityTimer.

At call setup, the RNC informs the UE about the periodicity for Scheduling Information
to be used when UE has a grant, and about the periodicity for Scheduling Information
to be used when it has no grant. These values are configurable at the OMC through
the four following parameters.
iBTS (setting for periodicityOfSchedInfoGrant):
Page 75/132
Parameter periodicityOfSchedInfoGrant Object EdchCellClass
Range & Unit EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
User Customer
Class 3
Value 50
Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoGrant.

Parameter periodicityOfSchedInfoGrantEdchTti2ms Object EdchCellClass
User Customer
Class 3
Value 50
Remark: Since UA7.1, the UCU-III supports the 2 ms TTI, so the OneBTS has the
same table shown above, with the same value of 50 ms for
periodicityOfSchedInfoGrantEdchTti2ms.

iBTS (setting for periodicityOfSchedInfoNoGrant):
Parameter periodicityOfSchedInfoNoGrant Object EdchCellClass
User Customer
Class 3
Value 50
Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoNoGrant.

Parameter periodicityOfSchedInfoNoGrantEdchTti2ms Object EdchCellClass
User Customer
Class 3
Value 50
Remark: Since UA7.1, the UCU-III supports the 2 ms TTI, so the OneBTS has the
same table shown above, with the same value of 50 ms for
periodicityOfSchedInfoNoGrantEdchTti2ms.

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 >=
SG
target
.
Generation of relative scheduling grants
- If SG
target,i
>SG
ref,i
, set RG
i
=UP".
Page 76/132
- If SG
target,i
=SG
ref,i
, set RG
i
="HOLD".
- If SG
target,i
<SG
ref,i
, set RG
i
="DOWN".

[iCEM] [xCEM] (ergch2IndexStepThreshold & ergch3IndexStepThreshold
settings)

Parameter ergch2IndexStepThreshold Object EdpchParameters
Range & Unit [0..37] step 1
User Customer
Class 0
Granularity RNC
Value [xCEM] 20 for both 10ms TTI and '2msec TTI' Edpch instances
[UCU-III] 18 for the 10ms TTI Edpch instances

Parameter ergch3IndexStepThreshold Object EdpchParameters
Range & Unit [0..37] step 1
User Customer
Class 0
Granularity RNC
Value [xCEM] 16 for both 10ms TTI and '2msec TTI' Edpch instances

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, due to different reference ETFCI and reference power
offset settings. Our recommendation is: ergch2IndexStepThreshold=18,
ergch3IndexStepThreshold=15.
Since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, the
ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set to the
same values as the xCEM, namely ergch2IndexStepThreshold=20, and
ergch3IndexStepThreshold=16.

Page 77/132
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.:
Scheduling Priority Internal priority level
Highest Priority 15 Prio_Level_Gold
14 Prio_Level_Silver
13 Prio_Level_Bronze
12
11
10
9
8
7
6
5
4
3
2
1
Lowest Priority 0
Prio_Level_Other
Table 15: 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 L
hypothetical
>L
available
. Each UE
will be de-granted by 1 step at the maximum.
- 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.

Page 78/132
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
flow} with same RF conditions, but different SPI, will be ranked considering
edchSpiRelativeWeight.

All these parameter values are dependent of the operators strategy.
Parameter serviceMinRate Object EdchServiceParameterSet
Range & Unit
[0..10000]
User Customer
Class 3
Granularity BTSCell

Parameter serviceMaxRate Object EdchServiceParameterSet
Range & Unit
[0..10000]
User Customer
Class 3
Granularity BTSCell

Parameter serviceBfactor Object EdchServiceParameterSet
Range & Unit
[1..30]
User Customer
Class 3
Granularity BTSCell

Parameter serviceKfactor Object EdchServiceParameterSet
Range & Unit
[1..30]
User Customer
Class 3
Granularity BTSCell
Remark: 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 edchSpiRelativeWeight Object EdchConf
Range & Unit
[1..16][0..100]
User Customer
Class 3
Granularity BTSCell
Value 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.

Page 79/132
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 =15] 100
Regarding edchSpi parameter, please see section 6.7 for a detailed description.

[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 E-DCH in order to maximize the E-DCH performances when using
2SF2+2SF4 in case of UE CAT 6.

[UCU-III] The Mac-e non scheduled mode is supported by the UCU-III and it is used to
carry SRB on E-DCH. Note that SRB on E-DCH 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 asking for a grant beforehand.
The maximum Mac-e PDU size for non scheduled data is configured so that the UE
can send 1 PDU (DCCH) per TTI.
There are two parameters used to set the maximum MAC-e PDU size to be used by
the UE for non scheduled data, one for 10 ms TTI and one for 2 ms TTI.
Parameter maxMacePduContentsSizeForNonScheduledModeTti10 Object EdchParameters
Range &
Unit
[1..1096], integer
User Customer
Class 3
Value 162

Page 80/132
Parameter maxMacePduContentsSizeForNonScheduledModeTti2 Object EdchParameters
Range &
Unit
[1..1096], integer
User Customer
Class 3
Value 162

The non scheduled mode is only used when the SRB over E-DCH is activated (please
refer to section 10 of the current volume).

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 E-DCH scheduler
and limit the UL radio and HW resources to the available Iub BW for E-DCH (Iub BW
not used by R99 traffic).

In order to perform this mechanism the congestion status should be known, thus a
direct interaction with feature HSPA congestion detection & notification (33367) is
necessary.
The iub BW limitation for E-DCH is performed in three main steps

UL iub congestion detection by the RNC

Iub congestion indication to NB

Iub BW congestion management by E-DCH scheduler

The Iub congestion detection and reporting are common to both xCEM and iCEM
(same mechanism is used).

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.
Page 81/132
7.8.3 UL IUB CONGESTION MANAGEMENT BY E-DCH
SCHEDULER
Every E-DCH congestion control period the NB updates a GRF:

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.

The xCEM scheduler reduces the UL load limit by GRF (and not the codec limitation
as for the iCEM case).
The same parameters are applicable for both iCEM and xCEM boards (refer to 6.8.3).

7.8.4 iBTS LOCAL CONGESTION CONTROL
In UA6 theres another feature (75786) that allows the iBTS to adjust E-DCH
throughput in Uplink according to AAL2 condition. More specifically:
E-DCH throughput will be progressively decreased on xCEM when the iBTS
detects a loss of AAL2 cells in uplink
E-DCH 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 15: Local congestion control mechanism

Page 82/132
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 E-DCH, xCEM reduces or increases E-DCH 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 E-DCH.

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
As a result, features 33332 and 75786 can be managed at the same time.

This feature can be activated/deactivated using the parameter edchCMActivation
(currently unused parameter). When set to TRUE, the BTS control the E-DCH
throughput based on ATM cell that are locally dropped in the BTS. When set to
FALSE, this feature is deactivated.
Parameter edchCMActivation Object BTSEquipment
User Customer
Class 3
Granularity BTS
Value True

UA7.0 and UA7.1 Delta: edchCMActivation and edchLocalCongestionControlActivation
different parameter name
The parameter name edchCMActivation, used previously in UA6 & UA7.0 and in a provisory basis,
will now have the name edchLocalCongestionControlActivation for UA7.1.

Parameter edchLocalCongestionControlActivation Object BTSEquipment
User Customer
Class 3
Granularity BTS
Value True

Page 83/132
Remark: The feature is managed the same way in all cases when user plan for E-
DCH is managed on ATM external AAL2 VCC, i.e:
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 at the NodeB) and the PVC is not in congested state. A congestion release
event is reported if the queue size crosses a LOW threshold (tunable at the NodeB)
and the PVC is not in uncongested state.
Page 84/132
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 at the 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).

Page 85/132
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 UA7 UPUG [R01], Vol.9, section 2.

9.1.1 34249 EUL CAPACITY OPTIMIZED HARQ OPERATION
9.1.1.1 PRINCIPLE OF E-DCH UL OLPC
This section describes the principle of UL OLPC for E-DCH with Alcatel-Lucent
implementation.
For a detailed description of the UA5.1 behaviour (34172 E-DPDCH Retransmissions
for DPCCH SIR Adaptation feature), refer to UA5.x HSxPA Engineering Guide [R02].
Since UA6, E-DCH UL OLPC is enhanced with the introduction of UA6 34249 EUL
Capacity Optimized HARQ Operation. For a detailed description of the specific
aspects introduced by this feature, please refer to section 9.1.1.2.

E-DCH UL OLPC GENERAL PRINCIPLE (POST UA5.1)
The general principle of UL OLPC for E-DCH with Alcatel-Lucent implementation is
summarized in below figure.
Page 86/132
NodeB 1
UL OLPC Master
SIR Target
NodeB 2
Partial
SIR Target
(DCH 1)
UL OLPC
Machine
(DCH 1)
CRCI of UL
DCH 1
CRCI of UL
DCH 2
N of HARQ
Retransmissions IE
UL OLPC
Machine
(DCH 2)
Partial
SIR Target
(DCH 2)
Partial
SIR Target
(E-DCH)
From UA5.1 (34172 feature):
Radio quality on E-DCH taken
as an input for UL OLPC
UL OLPC
Machine
(E-DCH)
Update frequency: On reception of Iub E-DCH Data Frame by RNC, i.e. every 10ms or 2ms.
Computation method:
Partial SIR Tg (k+1) = Partial SIR Tg (k) + Step . (N
HARQ
N
HARQ
Target)
known from
N of HARQ Retransmissions IE
Parameter (UA5.1) or
set of parameters (UA6).
From UA6, N
HARQ
Target
adapts to #active E-DCH
users and UL Radio Load
Color.
Computation of Partial SIR Target (E-DCH case):
Parameter
Computation of SIR Target
(according to all Partial SIR Targets):
If at least 1 Partial SIR Target
increased since previous update:
SIR Tg = max { Partial SIR Targets }
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.
NodeB 1
UL OLPC Master
SIR Target
NodeB 2
Partial
SIR Target
(DCH 1)
UL OLPC
Machine
(DCH 1)
CRCI of UL
DCH 1
CRCI of UL
DCH 2
N of HARQ
Retransmissions IE
UL OLPC
Machine
(DCH 2)
Partial
SIR Target
(DCH 2)
Partial
SIR Target
(E-DCH)
From UA5.1 (34172 feature):
Radio quality on E-DCH taken
as an input for UL OLPC
UL OLPC
Machine
(E-DCH)
Update frequency: On reception of Iub E-DCH Data Frame by RNC, i.e. every 10ms or 2ms.
Computation method:
Partial SIR Tg (k+1) = Partial SIR Tg (k) + Step . (N
HARQ
N
HARQ
Target)
known from
N of HARQ Retransmissions IE
Parameter (UA5.1) or
set of parameters (UA6).
From UA6, N
HARQ
Target
adapts to #active E-DCH
users and UL Radio Load
Color.
Computation of Partial SIR Target (E-DCH case):
Parameter
Computation of SIR Target
(according to all Partial SIR Targets):
If at least 1 Partial SIR Target
SIR Tg = max { Partial SIR Targets }
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.

Figure 16: E-DCH UL OLPC general principle
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,
Page 87/132
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:
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
(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. N
HARQ
measured > N
HARQ

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.
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 E-
DCH 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).

Page 88/132
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 E-
DCH 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 * (N
HARQ
- N
HARQ
Target)
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 UA7 UPUG [R01], Vol.9, section 2.3.4 for the formula giving
Partial UL SIR Target for the DCH case.
N
HARQ
: Number of HARQ retransmissions that occurred for a given MAC-e
PDU, as indicated by the N of HARQ Retransmissions IE enclosed in the E-
DCH Data Frame. If UE is in E-DCH SHO, N
HARQ
: is the number of HARQ
retransmissions that occurred for a given MAC-e PDU between UE and the
NodeB from which comes the selected E-DCH Data Frame corresponding to
this MAC-e PDU.
Remark:
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 E-
DCH Serving NodeB, N
HARQ
was taken equal to the maximum allowed number
of HARQ retransmissions.
Since 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.1.2.3 for more information on HFI handling in E-DCH
UL OLPC.
N
HARQ
Target: Target average number of HARQ retransmissions, set via
nHarqRetransTargetSx parameters (see section 9.1.1.2.2 for more
information on nHarqRetransTargetSx parameters, which are introduced in
UA6).
Remarks regarding above formula:
In above formula, (N
HARQ
- N
HARQ
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
Page 89/132
OLPC Machine associated to the E-DCH transport channel, i.e. above formula is
not impacted by this mechanism. Please refer to UA7 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
UL SIR Target =max{Partial SIR Targets }
Else:
UL SIR Target =min{Partial SIR Targets }

UL SIR TARGET SENDING
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 UA6 the UL SIR Target is sent to NodeB(s) at each periodical update even
if it is equal to the last value, while from UA7.1 onwards, a new parameter
enablePeriodicSirTargetUpdate enables or disables the periodic sending of Sir
target when the computed Sir Target is equal to the last value. Refer to [R01] for the
rationale and the description of this enhancement (feature 34246).

9.1.1.2 UA6 34249 FEATURE DESCRIPTION
9.1.1.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 (N
HARQ
Target) according to current number
of E-DCH users and UL radio load. In other words, this mechanism allows adapting
Page 90/132
the required E
b
/N
0
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.
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 (N
HARQ

Target). N
HARQ
Target is adapted according to:
o Current number of active E-DCH users in the cell
(see definition of active E-DCH users below in 9.1.1.2.2)
o Current UL Radio Load Color
(derived from the non E-DCH UL radio load of the cell)
In an unloaded cell, a small number of HARQ retransmissions ensures the best
performance while in a loaded cell, a high number of HARQ retransmissions gives the
the best performance.
Indeed targeting a high number of HARQ retransmissions (i.e targeting a high bler) in
a loaded cell relaxes the UEs power constraint (UEs use lower SIR), making the
global available load higher, allowing in turn the EDCH scheduler to select bigger
transport block size, thus improving the throughput.
With an adaptative N
HARQ
Target, the optimal performances are reached in both cases
(loaded and unloaded cell).

Restriction: [iCEM] Adaptive N
HARQ
Target mechanism disabled
Due to the limited E-DCH decoding capacity of the iCEM board (i.e. 2.1Mbps at 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, N
HARQ
Target is not adapted according to current
number of active E-DCH users and UL Radio Load Color. Precisely, adaptive N
HARQ
Target
mechanism is disabled by always forcing Cell State to S1 (see section 9.1.1.2.2 for details on
adaptive N
HARQ
Target mechanism). The RNC detects the type of board handling E-DCH thanks to
the E-DCH SF Capability per cell reported by the NodeB at startup or audit.

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:
o E-DCH macro diversity (introduced in UA6)
o Both TRB and SRB on E-DCH (SRB on E-DCH introduced in UA6)
o Both 10ms and 2ms E-DCH TTI (2ms E-DCH TTI introduced in UA6
for the xCEM, 2 ms E_DCH TTI introduced in UA7.1 for the UCU-III)
Page 91/132
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)
o UL/DL Imbalance Detection mechanism:
Counter intended for Engineering teams to detect UL/DL imbalance
issues (not directly related to UL OLPC)

9.1.1.2.2 PARTIAL UL SIR TARGET COMPUTATION
CELL STATE
In order to adapt N
HARQ
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 N
HARQ

Target value is used for all the E-DCH UEs for which the considered cell is the E-DCH
serving cell.
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 UA7 UPUG [R01], Vol.6, section 5.4.1.

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 maxNumActive-
EdchUsersPerCellForS1 and maxNumActiveEdchUsersPerCellForS2 parameters
are used to set the thresholds for Cell State change on number of active E-DCH
users criterion.
maxNumActive-
EdchUsers-
PerCellForS1
maxNumActive-
EdchUsers-
PerCellForS2
Number of
active
E-DCH users
UL Radio
Load Color
S1
green yellow red
S2
S3
0
maxNumActive-
EdchUsers-
PerCellForS1
maxNumActive-
EdchUsers-
PerCellForS2
Number of
active
E-DCH users
UL Radio
Load Color
S1
green yellow red
S2
S3
0

Figure 17: Cell State computation
Page 92/132
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.1.2.1. With
UA6 34249 feature, N
HARQ
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:
Cell State =S1 N
HARQ
Target =nHarqRetransTargetS1
Cell State =S2 N
HARQ
Cell State =S3 N
HARQ

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.1.2.1):
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.

SRB ON E-DCH CASE
[GM] Since 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.
[US] For EDCH calls, the UL SRB is always carried on the E-DCH along with the UL
TRB.
In case of SRB on E-DCH, two MAC-d flows are carried on E-DCH: the UL SRB MAC-
d 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.
Page 93/132
NodeB 1
UL OLPC Master
SIR Target
Partial
SIR Target
(E-DCH SRB)
UL OLPC
Machine
(E-DCH SRB)
N of HARQ
Retransmissions IE
Partial
SIR Target
(E-DCH TRB)
N of HARQ
Retransmissions IE
UL OLPC
Machine
(E-DCH TRB)
NodeB 1
NodeB 1
UL OLPC Master
SIR Target
Partial
SIR Target
(E-DCH SRB)
UL OLPC
Machine
(E-DCH SRB)
N of HARQ
Retransmissions IE
Partial
SIR Target
(E-DCH TRB)
N of HARQ
Retransmissions IE
UL OLPC
Machine
(E-DCH TRB)
NodeB 1

Figure 18: 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 N
HARQ

Target for each Cell State separately for the SRB and for the TRB MAC-d flow.
In order to guarantee good link quality for the UL SRB, for the SRB MAC-d flow it is
recommended to set N
HARQ
Target to a low and same value for all Cell States (see
section 9.1.1.3.3 for more details on this recommendation).

9.1.1.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 E-
DCH Data Frames correctly received from the serving and non-serving NodeB(s) are
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.
Page 94/132
The HFI monitoring period is set via edchOlpcSamplingPeriodTti10ms and
edchOlpcSamplingPeriodTti2ms parameters.
During the HFI monitoring period, the following internal counters are incremented:
o Number of HFI frames
o Number of valid frames from serving NodeB
o Total number of valid frames after frame selection
At the end of the HFI monitoring period, the following two quantities are computed:
o HFI Ratio =Number of HFI frames / Total number of 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
o Serving Ratio =Number of valid frames from serving NodeB / Total
number of 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.

edchOlpc-
ServingRatio-
Threshold
edchOlpcHfiRatioThreshold
Serving Ratio
HFI Ratio
HFI 3
0
0
HFI 1
HFI 2
HFI 0
edchOlpc-
ServingRatio-
Threshold
Serving Ratio
HFI Ratio
HFI 3
0
0
HFI 1
HFI 2
HFI 0

Figure 19: HFI Reception Scenario computation

PARTIAL UL SIR TARGET COMPUTATION
E-DCH SHO case:
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.
Page 95/132
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:
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.1.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 non-
serving NodeB(s)), internal counter Number of Consecutive Good Frames Not
Received on Serving NodeB is incremented.
As soon as a MAC-e PDU is correctly decoded by the serving NodeB, Number of
Consecutive Good Frames Not Received on Serving NodeB is reset to 0.
If Number of 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.
Remarks:
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
Page 96/132
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 E-
DCH 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.1.3 PARAMETER SETTINGS AND RECOMMENDATIONS
9.1.1.3.1 FEATURE ACTIVATION
Activation of E-DCH UL OLPC:
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 UA7 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).
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):
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):
For the UL services including an E-DCH UL RB, set minSirTarget =
maxSirTarget.

Activation of adaptive N
HARQ
Target algorithm:
In order to enable the ability to adapt the target number of HARQ retransmissions
N
HARQ
Target according to current number of E-DCH users and UL radio load, the
Page 97/132
parameters nHarqRetransTargetS1, nHarqRetransTargetS2 and
nHarqRetransTargetS1 must be set to different values.
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 N
HARQ
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.

9.1.1.3.2 RAN MODEL
Note that all the parameters of UA6 34249 feature are at OMC-R, i.e. under the RNC
objects and parameters tree.
Next figure shows the RAN model (i.e. parameters and objects tree) for the
parameters defined for E-DCH UL radio bearers (PS_EDCH, SRB_EDCH, ).
UlRbSetConf/
PS_EDCH
PS_EDCH_MUX
SRB_EDCH
UlRbSetConf/
PS_EDCH
PS_EDCH_MUX
SRB EDCH
RNC
RadioAccessService
ulSirStep
updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepFastDecrease
edchOlpcServingRatioThreshold
edchSirStepHfi
edchLinkBalanceThreshold
nHarqRetransTargetS1
DynamicParameterForEdchTti10ms
NHarqRetransTarget 3
3
3
ulSirStep
updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepFastDecrease
edchOlpcServingRatioThreshold
edchSirStepHfi
edchLinkBalanceThreshold
NHarqRetransTargetUeCat4
NHarqRetransTargetUeCat6

3 instances :
one instance
per OLS.

Figure 20: 34249 RAN model for E-DCH UL RBs
Page 98/132
The next figure shows the RAN model for the parameters defined per UL service
(including E-DCH UL services) and for other parameters.
RNC
Parameters defined for E-DCH UL services
(PS_EDCHxSRB_3_4K, PS_EDCHxSRB_EDCH and all
multi-services with E-DCH)
RNC
RadioAccessService
DedicatedConf
PowerConfClass
UlUsPowerConf/
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K

initialSirTarget
minSirTarget
maxSirTarget
initialSirTargetHsdpa
minSirTargetHsdpa
maxSirTargetHsdpa
initialSirTargetEdch2ms
minSirTargetEdch2ms
maxSirTargetEdch2ms
UlOuterLoopPowerCtrl
ulUpdatePeriod
15
UlUserService/
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH

eligibleUeCategoryForSirTargetEdch2ms 15
maxNumActiveEdchUsersPerCellForS1
maxNumActiveEdchUsersPerCellForS2
EdchCellClass
RadioAccessService
DedicatedConf
EdchRncConf
edchOlpcSamplingPeriodTti10ms
edchOlpcSamplingPeriodTti2ms
Other parameters

Figure 21: 34249 RAN model for E-DCH UL services and misc.

9.1.1.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
the E-DCH transport channel. Note that the formula giving Partial SIR Target for E-
DCH is different than the one for DCH.
Page 99/132
Parameter ulSirStep
Object
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit
Decimal [0.005 0.300] step: 0.005, dB
Value For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms: 0.025
DynamicParameterForEdchTti2ms: 0.01

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 updateThreshold
Object
Range & Unit
Integer [0 255], 0.1dB
Value For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH: 1
(corresponds to 0.1dB)

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
Value 200

edchSirStepFastDecrease: Step size used for Partial SIR Target update when Fast
Decrease mechanism has been triggered.
Parameter edchSirStepFastDecrease
Range & Unit Signed [-0.300 0.000] step 0.005, dB
Value -0.02

Page 100/132
edchOlpcHfiRatioThreshold: Threshold applying to the HFI Ratio (Number of HFI
frames / Total number of 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
Range & Unit Integer [0 100], %
[UCU-III] 10

edchOlpcServingRatioThreshold: Threshold applying to the Serving Ratio (Number
of valid frames from serving NodeB / Total number of 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
[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
Range & Unit List of decimal [0.000 1.000] step 0.005, dB
Value [iCEM] [xCEM] {0; 0; 0}
[UCU-III] {0.15; 0.1; 0.2}

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.
Page 101/132
Setting edchLinkBalanceThreshold to 1024 disables UL/DL Imbalance Detection
mechanism (i.e. disables VS.EdchLinkImbalance counter).
Parameter edchLinkBalanceThreshold
Value 200

nHarqRetransTargetS1: N
HARQ
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, N
HARQ
Target is always taken equal to
nHarqRetransTargetS1 (independently from current Cell State).
Parameter nHarqRetransTargetS1
Object NHarqRetransTarget
Granularity RNC, UlRbSetConf, E-DCH TTI type, UE Category
Range & Unit Decimal [0.00 12.00], step 0.01 N/A
Value For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget:0.07
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
See the engineering recommendation Adaptative N
HARQ
below.
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.04

Page 102/132
HARQ
Target value used for UL OLPC when Cell State =S2.
HARQ
below.

HARQ
Target value used for UL OLPC when Cell State =S3.
HARQ
below.

Page 103/132
Engineering Recommendation: PS_EDCH Adaptative N
Harq
Target tuning
The optimal target number of HARQ retransmissions (nHarqRetransTargetSx) and maximum active
EDCH users for cell state S1, S2 and S3 (maxNumActiveEdchUsersPerCellForSx) highly depend
on several aspects:
The EDCH activity factor, ie. at busy hour, ratio of UEs actively transferring at high rate in uplink
vs UEs having sporadic or low rate uplink traffic)
The UE Categories penetration factor (e.g ratio of Cat5 vs Cat6).
The EDCH Mac-e throughput decoding capacity, i.e [xCEM] the full capacity of 10Mbps offered by
the feature 34633 may be restricted due to commercial agreement (Capacity Licencing).
The available maximum UL Load
The limiting factor which is hit first on a given cell (either UL Load or EDCH decoding capacity)
The recommended values provided in this document shall be considered as a guideline and could be
tuned more on the field.

Rule: nHarqRetransTargetSx
For each E-DCH TTI type, the target average number of HARQ retransmissions N
HARQ
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): N
HARQ
Target must be lower
than the maximum number of HARQ retransmissions, else the convergence towards the target
would be impossible.
For E-DCH TTI 10ms (respectively 2ms), nHarqRetransTargetSx must be filled in with the
same value for all three instances of NHarqRetransTarget (respectively
NHarqRetransTarget2msCat4(6)). There is one NHarqRetransTarget (respectively
NHarqRetransTarget2msCat4(6)) instance per OLS Olympic Level Service), however there are
not any required specific settings per OLS.

Page 104/132
Engineering Recommendation: nHarqRetransTargetSx for SRB on E-DCH case
As explained in 9.1.1.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 N
HARQ
Target to a low and same value for all Cell States, as indicated
below.
Under:
[US] UlRbSetConf/SRB_EDCH/ DynamicParameterForEdchTti10ms/NharqRetransTarget:
[GM][US] UlRbSetConf/SRB_EDCH/ DynamicParameterForEdchTti2/NharqRetransTarget2msCat4
[GM][US] UlRbSetConf/SRB_EDCH/ DynamicParameterForEdchTti2/NharqRetransTarget2msCat6
set nHarqRetransTargetS1 =nHarqRetransTargetS1 =nHarqRetransTargetS3 =small value
(e.g. 0.04)

UA6.0, UA7.0 - UA7.1 Delta: N
harq
Target differentiation between E-DCH Cat4 and Cat6
In UA6.0 and UA7.0, the set of three N
Harq
retransmission targets was the same regardless of the E-
DCH UE Category. This set was defined in the object nHarqRetransTarget in the RAN model.
In UA7.1, it is possible to define distinct set of three N
Harq
retransmission targets for TTI10ms,
UeCategory4 TTI2ms and UeCategory6 TTI2ms calls. They are defined respectively in the objects
nHarqRetransTarget, nHarqRetransTarget2msCat4, nHarqRetransTarget2msCat6 in the RAN
model. Indeed the UeCategory4 and UeCategory6, when using TTI2ms, require specific N
Harq

retransmission targets to reach the best performances.

9.1.1.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
Value For all UlUserService instances*: True
* Except SRB_CellFACH and TRBxSRB_CellFACH for which UL OLPC does not apply

Page 105/132
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 RNC, UlUserService
Range & Unit
Integer [0 255], N/A
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] [UCU-III]: 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
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
Value For UlUsPowerConf instances with PS_EDCH: refer to the UPUG [R01]

minSirTarget: Lower bound for UL SIR Target in the UL OLPC algorithm.
Parameter minSirTarget
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB

maxSirTarget: Upper bound for UL SIR Target in the UL OLPC algorithm.
Parameter maxSirTarget
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB

Page 106/132
The E-DCH TTI2ms calls require high SIR Target values to reach the best
performances. A special set of parameters is defined, allowing SIR target
differentiation between E-DCH TTI10ms and 2ms.
eligibleUeCategoryForSirTargetEdch2ms: Eligible UE E-DCH categories for
specific SIR target settings (in case of E-DCH TTI 2ms). The bit 0 corresponds to
category 1, bit 1 corresponds to category 2 and so on.
The recommended setting allows having E-DCH UeCategory2, UeCategory4 and
UeCategory6 eligible for specific SIR settings when they are using TTI2ms.
Parameter eligibleUeCategoryForSirTargetEdch2ms
Object PowerConfClass
Granularity PowerConfClass
Range & Unit
BitString
Value 0000000000101010

initialSirTargetEdch2ms: UL SIR Target used for the initialization of UL OLPC
algorithm, for E-DCH TTI2ms calls eligible to SIR target differentiation between E-
DCH TTI10ms and TTI2ms (parameter eligibleUeCategoryForSirTargetEdch2ms).
Parameter initialSirTargetEdch2ms
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB

minSirTargetEdch2ms: Lower bound for UL SIR Target in the UL OLPC algorithm,
for E-DCH TTI2ms calls eligible to SIR target differentiation between E-DCH TTI10ms
and TTI2ms (parameter eligibleUeCategoryForSirTargetEdch2ms).
Parameter minSirTargetEdch2ms
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB

Page 107/132
maxSirTargetEdch2ms: Upper bound for UL SIR Target in the UL OLPC algorithm,
for E-DCH TTI2ms calls eligible to SIR target differentiation between E-DCH TTI10ms
and TTI2ms (parameter eligibleUeCategoryForSirTargetEdch2ms).
Parameter maxSirTargetEdch2ms
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB

UA6.0 UA7.0 Delta: Specific SIR target for E-DCH TTI2ms
In UA6.0, the specific maximum SIR target required for E-DCH TTI2ms calls was ensured by a
hard-coded internal offset Max Sir Target Offset 2ms, applied on top of the configured
maxSirTarget. For UeCategory4 2ms calls, Max Sir Target Offset 2ms value was 2.6 dB. For
UeCategory6 2ms calls (with SRB on E-DCH), Max Sir Target Offset 2ms value was 2.1 dB.
In UA7.0, a new set of parameters (eligibleUeCategoryForSirTargetEdch2ms,
initialSirTargetEdch2ms, minSirTargetEdch2ms, maxSirTargetEdch2ms) is introduced, making
the specific SIR targets settings for E-DCH TTI2ms fully configurable.

Alternatively, initialSirTargetHsdpa, minSirTargetHsdpa, maxSirTargetHsdpa may
be the set of parameters selected by the RNC for a given HSUPA call. Refer to the
[Vol.3] in this document for the description of the UL SIR Target parameters selection
on a per-call basis.

Page 108/132
Engineering Recommendation: [iCEM] [xCEM] [UCU-III] SIR targets settings
[iCEM] [xCEM] [UCU-III] UL SIR Target parameters initialSirTarget, initialSirTargetHsdpa,
initialSirTargetEdch2ms and maxSirTarget, maxSirTargetHsdpa, maxSirTargetEdch2ms
settings for E-DCH calls.
As mentioned in section 5.4, due to specificities in iCEM, xCEM and UCU-III E-DCH functions, and
due to the fact that specific {Reference E-TFCI; Reference Power Offset}tables are set for iCEM
xCEM and UCU-III, for E-DCH calls, it is strongly recommended to follow the board-specific SIR
targets parameters recommendations for all UlUsPowerConf instances with PS_EDCH. Refer to
the UPUG [R01] for the exhaustive recommended values.

Configuration method:
[GM] In case a network is deployed with iCEM and xCEM boards handling HSUPA calls, 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, or UCU-
III), set the UL OLPC SIR Targets parameters to the board-specific values as recommended
in the UPUG [R01].
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.

9.1.1.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
Range & Unit Integer [0 64] N/A
Value See the engineering recommendation Adaptative N
HARQ

maxNumActiveEdchUsersPerCellForS2: Maximum number of active E-DCH users
per cell for Cell State =S2.
Parameter maxNumActiveEdchUsersPerCellForS2
Value See the engineering recommendation Adaptative N
HARQ

Page 109/132
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
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
Value 20

9.2 POWER CONTROL OF E-DCH DL CHANNELS
9.2.1 E-DCH DL CONTROL CHANNELS POWER CONTROL
(33481)
9.2.1.1 INTRODUCTION
The feature EDCH DL Control Channels Power Control (33481) was originally
introduced in UA5.1 and has been improved in UA6.
It is available on xCEM and UCU-III.
It is not supported on iCEM (E-DCH DL channels are not power controlled).
This feature allows saving some DL power by performing power control of E-DCH DL
channels (E-AGCH, E-RGCH and E-HICH), hence the available NodeB power is
increased and the DL intra-cell and extra-cell interference are reduced.
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.

9.2.1.2 FEATURE DESCRIPTION
As a reminder, this section and the following one only apply to xCEM and UCU-III.

Page 110/132
E-AGCH
Power control of E-AGCH channel is enabled and derived within the NodeB according
to the following formula.
AGCH E DCH E AGCH E
PO k P k P + = ) ( ) (

With:
k: Time (2ms sub-frame index)
P
E AGCH
(k): Power allocated to the considered E-AGCH channel
P
E DCH
(k): E-DCH DL channels base power. This is a unique power value derived
within the xCEM and UCU-III according to the methods 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).
PO
E 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.2 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
same physical channel (E-RGCH/E-HICH) and are addressed to the wished user by
using specific signatures.
signature HICH E DCH E signature HICH E
PO k P k P + = ) ( ) (

With:
P
E HICH signature
(k): Power allocated to the E-HICH signature of considered user
PO
E-HICH signature
: Power offset of E-HICH signature relative to E-DCH DL channels
base power.

E-RGCH
Power control of E-RGCH channel is enabled and derived within the NodeB according
to the following formula.
HICH E RGCH E signature HICH E signature RGCH E
PO k P k P
/
) ( ) ( + =

With:
P
E RGCH signature
(k): Power allocated to the E-RGCH signature of considered user
P
E HICH signature
(k): Power allocated to the E-HICH signature of considered user,
computed as explained above.
PO
E-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).

Page 111/132
COMPUTATION OF E-DCH DL CHANNELS BASE POWER P
E DCH
(k)
E-DCH DL channels base power P
E DCH
(k), which is used as a base for derivation of E-
AGCH 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:
Method based on DL DPCH channel power:
P
E DCH
(k) is derived by adding an offset* to the power of the DL DPCH channel of
the considered user.
Method based on DL Inner-Loop Power Control (ILPC) commands:
P
E DCH
(k) is derived by starting from a given initial power P
init E DCH
and then update
the power basing on the DL ILPC commands received from the considered
mobile. An offset* is also applied.
Method based on received CQI
P
E 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.
* 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 P
E DCH
(k).
The selection of one (or a combination) of the above 3 methods for computing the E-
DCH DL channels base power P
E DCH
(k) is tunable via NodeB parameters not
accessible to the customer.
[xCEM]: the method based on the received CQI is used.
[UCU-III]: the method based on DL DPCH transmit power (from HSDPA leg) is used.

From UA6 onwards, the following enhancements are available:
The feature is made optional on xCEM by the introduction of an activation flag
eagchPowerControlModeXcem. For UCU-III, there is no activation flag, the
feature is activated by default.
The Power Control of E-DCH DL channels is made suitable for:
E-DCH Macro Diversity (introduced in UA6): E-RGCH and E-HICH Power
Control for E-DCH non-serving radio links is supported.
both 10ms and 2ms E-DCH TTI (introduced in UA6): if 2ms E-DCH TTI is
used, an additional fixed power offset is applied on top of the E-DCH DL
channels power.
Introduction of E-HICH Outer-Loop correction mechanism:
(not used in final implementation). A correction on top of P
E DCH
(k) may be added,
computed based on E-HICH bad detection by UE. It benefits to all E-DCH RLs of
the E-DCH serving NodeB. This mechanism is implemented but not used,
Page 112/132
because CQI based algorithm or DL DPCH transmit power based algorithm
provide yet good power levels.

9.2.1.3.1 RAN MODEL
All below parameters are xCEM or UCU-III specific (i.e. not used by iCEM).

9.2.1.3.2 PARAMETERS
For the recommended values on OneBTS UCU-III, please refer to the section 12 in
this volume.
The current section gives recommended values for xCEM.
pMinDlEDCH:
Power Control of E-DCH DL channels enabled:
Lower bound for E-DCH DL channels base power P
E DCH
(k). Value is relative to
CPICH Tx power.
Power Control of E-DCH DL channels disabled:
Power offset of E-HICH signature at serving NodeB, relative to CPICH Tx power.
pMinDlEDCH
pMaxDlEDCH
eagchPowerControlModeXcem
eagchPowerOffset
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset
BTSCell
EdchConf
012
00
pMinDlEDCH
pMaxDlEDCH
eagchPowerOffset
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
powerOffsetERGCHServingNoSHO
deltaDownServingCellNoHO
OneBTSEquipment
Remark: powerOffsetERGCHServingSHO parameter is also present in RAN Model (under
EdchConf and under OneBTSEquipment). However, this parameter is ignored by the system.
BTSEquipment
Page 113/132
Parameter pMinDlEDCH
Object EdchConf
Granularity BTSCell
Value -25.0

pMaxDlEDCH: Upper bound for E-DCH DL channels base power P
E DCH
(k). Value is
relative to CPICH Tx power.
Parameter pMaxDlEDCH
Object EdchConf
Granularity BTSCell
Value -15.0

eagchPowerOffset:
Power offset of E-AGCH relative to E-DCH DL channels base power P
E DCH
(k).
Power offset of E-AGCH relative to CPICH Tx power.
Parameter eagchPowerOffset
Object EdchConf
Granularity BTSCell
Value Power Control of E-DCH DL channels enabled: 10.0
Power Control of E-DCH DL channels disabled: -4.0

powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to E-
HICH 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).
Page 114/132
Parameter powerOffsetERGCHServingNoSHO
Object EdchConf
Granularity BTSCell
Value 1.5

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
Value Dynamic

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%
Value 10 (corresponds to 1%)

minPowerCorrection: In E-HICH Outer-Loop correction mechanism, minimum
correction that can be applied to E-DCH DL channels base power P
E-DCH
(k).
Parameter minPowerCorrection
Object EdchConf
Granularity BTSCell
Value 0.0

maxPowerCorrection: In E-HICH Outer-Loop correction mechanism, maximum
correction that can be applied to E-DCH DL channels base power P
E-DCH
(k).
Page 115/132
Parameter maxPowerCorrection
Object EdchConf
Granularity BTSCell
Value 0.0
Remarks: Current recommendation is to disable E-HICH Outer-Loop correction
mechanism by setting minPowerCorrection =maxPowerCorrection.

nonServingEHICHPowerOffset: Please refer to [Vol.6], section 3.3.3 of this
document.

commonERGCHPowerOffset: Please refer to [Vol.6], section 3.3.3 of this document.

For information, the following parameter is also present in the RAN Model, but ignored
by the system:
.
Parameter eagchPowerControlActivated (not used)
Object EdchRncConf
Granularity RNC
Value True

The following parameters define some power offset values which are sent by the RNC
to the NODEB in NBAP messages at startup, but finally unused by the NodeB
Parameter eagchPowerOffset
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
Value 4.00

Parameter eagchPowerOffsetEdchTti2ms
Value 4.00

Page 116/132
Parameter ergchPowerOffset
Value -4.00

Parameter ergchPowerOffsetEdchTti2ms
Value -4.00

Parameter ehichPowerOffset
Value -4.00

Parameter ehichPowerOffsetEdchTti2ms
Value -4.00

9.2.1.3.3 OTHER RECOMMENDATIONS
Granularity for parameter settings:
All parameters are settable per cell: the feature 33481 is fully tunable per cell.
Board-specific parameters:
All parameters above-listed in Parameters 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:
Page 117/132
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.

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 and UCU-III.

[UCU-III]
It will be possible to extend the SRB on E-DCH as soon as all TRB are mapped on E-
DCH in the uplink, whatever the minSF and whatever the TTI value of the E-DCH
configuration. For UA6.0, the OneBTS does not support 2ms TTI. UCU-III supports up
to category 5, on 10 ms TTI only. It does not support category 6 (and it would be
managed like a category 4 on 10ms TTI). For UA7.1 onwards, the OneBTS supports 2
ms TTI for categry 2, 4 and 6 UEs as well as up to the 2SF2+2SF4 configuration for
category 6.

DL UL
L3 SRB - TRB - - - - SRB TRB
L2 - Trsp DCH-FP - HS-DSCH FP - - - - E-DCH FP E-DCH FP
L1 DPCCH/DPDCH HS-SCCH HS-PDSCH E-HICH DPCCH HS-DPCCH E-DPCCH E-DPDCH

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.
Page 118/132
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 RNC controls the Primary Cell, thus allowing inter-RNC mobility for E-
DCH.

Parameters:
First, the feature flag activation.
Parameter isSrbOnEdchAllowedWhenTrbOnEdch Object RadioAccessService
Range &
Unit
TRUE/FALSE None
User Customer
Class 3-a2
Granularity RNC
Value [True

Parameter srbSpi Object srbQos

User Customer
Class 3-a2
Granularity RNC
Value 15

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
srbSpi
SPI used for SRB on E-DCH during a call. This parameter is located in srbQos under
Radio Access Service.

Three activation flags are added to the model, in the radio access service:
isSrbOnEdchForAllEdchCategory: SRB on E-DCH for all E-DCH categories
o False: E-DCH cat 6 UE only
o True: All E-DCH categories
isSrbOnEdchForAllMinSf: SRB on E-DCH for all NodeB minSF
o False: 2 SF2 +2 SF4 minSF only.
o True: All NodeB minSF
Page 119/132
isSrbOnEdchForAllEdchTti: SRB on E-DCH for all E-DCH TTI
o False: 2 ms TTI only and 2 ms supported on NodeB
o True: 2 ms and 10 ms allowed to use SRB on EDCH

Parameter isSrbOnEdchForAllEdchCategory Object RadioAccessService
User Customer
Class 3-a2
Granularity RNC
Value [xCEM] False
[UCU-III] True

Parameter isSrbOnEdchForAllMinSf Object RadioAccessService
User Customer
Class 3-a2
Granularity RNC
Value [xCEM] False
[UCU-III] True

Parameter isSrbOnEdchForAllEdchTti Object RadioAccessService
User Customer
Class 3-a2
Granularity RNC
Value [xCEM] False
[UCU-III] True

UA6.0 UA7.0 Delta: SRB on EDCH parameters
In UA6.0, the parameters used to configure the HSUPA UE categories, the Minimum SF, and the E-
DCH TTI eligible for SRB on E-DCH were the three first bits of reserved0 in RadioAccessService.
From UA7.0, three parameters are used: isSrbOnEdchForAllEdchCategory,
isSrbOnEdchForAllMinSf, isSrbOnEdchForAllEdchTti in RadioAccessService.

Page 120/132
The following datafill rules are presented:
Rule:
As a reminder, a cell is a 2 ms E-DCH TTI capable if:
isEdchTti2msAllowed flag, in the edchCellClass used by the FddCell, 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, MAC-
d flow#2 parameters for UL: [max bit rate depending on UE category and TTI] SRBs
for E-DCH
Higher layer RAB/Signaling RB SRB #1 SRB #2 SRB #3 SRB #4
Logical channel type DCCH DCCH DCCH DCCH
RLC mode UM AM AM AM
Payload sizes, bit 136 128 128 128
Max data rate, bps Depends on UE category and TTI
RLC
AMD PDU header, bit 8 16 16 16
MAC-es multiplexing 4 logical channel multiplexing
MAC-d PDU size, bit 144
MAC
MAC-e/es header fixed
part, bit
18
TrCH type E-DCH
TTI 10 ms (alt. 2 ms) (NOTE)
Coding type TC
Layer 1
CRC, bit 24
NOTE: The support of 2 ms TTI depends on the UE category.
The SRB will be mapped on E-DCH using the non-schedule traffic.

The following system restrictions are presented:
Restriction:
Nevertheless, facing iBTS limitation on iCEM, parameter isSrbOnEdchForAllEdchTti shall never be
set to 1 if there at least a iCEM on a NodeB where E-DCH is activated.

Page 121/132
The engineering recommendations on parameter value are presented as the
following:

Engineering Recommendation: isSrbOnEdchForAllEdchCategory, isSrbOnEdchForAllMinSf,
isSrbOnEdchForAllEdchTti typical settings
Hereafter are the typical values to be used on the different customers to support high bit-rate in UL:
Global Market [xCEM]
Model Configuration Value Meaning
isSrbOnEdchForAllEdchCategory False Cat 6 UE only
isSrbOnEdchForAllMinSf False 2 SF2 +2 SF4 minSF only
isSrbOnEdchForAllEdchTti False 2 ms TTI only and 2 ms supported on NodeB

US Market [UCU-III]
Model Configuration Value Meaning
isSrbOnEdchForAllEdchCategory True All UE Categories
isSrbOnEdchForAllMinSf True Whatever minSF
isSrbOnEdchForAllEdchTti True For all NodeB; For all TTI

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:
SRB on DCH/DCH <==>SRB on DCH/E-DCH +TRB PS on HSDPA/E-DCH
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
Page 122/132
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:
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)
TRB PS on HSDPA/DCH (GM)
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)
TRB PS on HSDPA/E-DCH (10 ms) (US MARKET)
TRB PS on HSDPA/DCH (US MARKET)
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/E-
DCH (2 ms) (GM)
Page 123/132
on HSDPA/E-DCH (10 ms) (US MARKET)
DCH (10 ms) (US MARKET)
on HSDPA/E-DCH (2 ms) (US MARKET)
DCH (2 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.

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 boards:
Call reconfiguration. This use case happens when the call is already
established on a NodeB that is composed by at least one iCEM and one
xCEM. The DCH SRB part is currently handled by the iCEM 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 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.
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 iCEM.
Page 124/132
The call reconfiguration use case will be covered by the DCH fallback algorithm if the
reconfiguration fails. But as the mix of iCEM 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,
the iCEM 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 iCEM are:
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
o 3.4 UL/DL <==>3.4 DL only
UL DPCCH Slot Format remains 0
iCEM 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].
N
max-dpdch

(as defined in subclause 4.2.1)
Channelisation code c
hs

0 C
ch,256,33

1 C
ch,256,64

2,4,6 C
ch,256,1

3,5 C
ch,256,32

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 cacTransportInfoList[].cacTransportInfoInstanceCharacteristic Object UlRbSetConf
Range &
Unit
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)
User Customer
Class 3-a2
Granularity RNC
Value Refer to PM 34202 & PM 33579
Page 125/132
11 ADVANCED RECEIVER FOR HIGH UL DATA
RATE (34393)
11.1 INTRODUCTION
In UA7.1 this feature will allow NodeB to switch to advanced receiver topology for a
subset of users that are experiencing dispersive channel conditions while providing
high data rates in UL. This capability is introduced through generalized RAKE receiver
technology that allows a typical RAKE structure to be re-configured to approximate an
Equalizer with reception decision based upon minimum mean square error (MMSE)
criteria.
This allows the receiver at the NodeB to overcome the self interference that restricts
the throughput which can be achieved in low mobility environments like VA3 and
PedB3 where non-line of sight multi-path dominates. The objective of this feature is to
reach max UL data rate fighting against ISI and inter OVSF code interference to
achieve a better EbNo as compared to RAKE. The following parameter is used to
activate this feature which is applicable to both xCEM and UCU-III modules.
[xCEM]
Parameter gRakeActivation Object BTSEquipment
Range & Unit
False, True
User Customer
Class 3
Granularity BTSCell
Value False
[UCU-III]
Parameter gRakeActivation Object OneBTSEquipment
Range & Unit
False, True
User Customer
Class 3
Granularity BTSCell
Value False

By default, G-RAKE should be disabled after upgrade.

Restriction: G-RAKE feature is not recommended for Live activation
Due to risk of large performance regression for E-DCH mobility users (>15km/h speed) it is not
recommended to enable this feature in Live in UA7.1. This is applicable to both channel cards.

11.2 DESCRIPTION (GAIN, INTERACTIONS)
This feature is expected to provide most gain when deployed with 16-QAM capability
for HSUPA. However even in UA7.1 with QPSK, it is anticipated that positive effects
will be seen on UL Load and/or HARQ repetition resulting in higher capacity in multi-
UE or better throughput performance for single UE scenarios.
Page 126/132
Furthermore preliminary results do show that G-RAKE provides higher MAC-e
throughput as compared to traditional RAKE especially when using 2msec TTI and
single UE.
Since this features main benefit is reduction of self-interference, Any feature that will
add (non-self) interference cancellation capabilities is likely to reduce gain brought by
feature 34393.
Once activated this feature will work independently of the E-DCH scheduler and will
dynamically select up to three users that can most benefit from being handled by G-
RAKE, every 100 msec. The decision will be made based upon users average data
rate, speed (using Doppler shift) and dispersion index through a hard coded look up
table function. This function will convert these user characteristics into a score
indicating potential benefit from the G-RAKE. A score of 0 makes the user ineligible
for the G-RAKE. This will ensure low speed users experiencing significant temporal
dispersion, while transmitting at low spreading gain (high burst rate) will be selected.
xCEM, in GM market, normally supports 128 10msec TTI E-DCH users. When G-
RAKE is active, number of such users is reduced by 12. So users with IDs 116 to 127
are not allowed in this case. If there are any users that are assigned ID >115 while
the feature is being activated, CE will wait for these users to be released by higher
layers before actually activating the feature.
UCU-III, on the other hand, supports 64 10msec TTI E-DCH users. Due to this reason
same CE capacity limitation does not appear when supporting the G-RAKE in US
market on UCU-III.

Page 127/132
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 offset of E-AGCH relative to E-DCH DL channels base power P
E DCH
(k).
Power offset of E-AGCH relative to CPICH Tx power.
Parameter eAGCHPowerOffset
Object OneBTSEquipment
Granularity OneBTSEquipment
Value 10.0

eHICHErrorProbability: Target E-HICH error rate for E-HICH Outer-Loop correction
mechanism.
Parameter eHICHErrorProbability
Range & Unit Integer [1 255], 0.1%
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
Range & Unit Integer [1 1000], 0.01dB
Value 20 (corresponds to 0.2dB)

Page 128/132
maxPowerCorrection: Upper bound for power offset of E-HICH signature relative to
E-DCH
(k).
Remark: Current recommendation is to disable E-HICH Outer-Loop correction
mechanism by setting minPowerCorrection =maxPowerCorrection.
Parameter maxPowerCorrection
Value -3.0

minPowerCorrection: Lower bound for power offset of E-HICH signature relative to
E-DCH
(k).
Parameter minPowerCorrection
Value -3.0

powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to E-
HICH 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).
Parameter powerOffsetERGCHServingNoSHO
Value 1.5

powerOffsetERGCHServingSHO: This parameter is ignored by the system.

Page 129/132
pMaxDlEDCH: Upper bound for E-DCH DL channels base power P
E DCH
(k). Value is
Parameter pMaxDlEDCH
Value 6.0

pMinDlEDCH: Lower bound for E-DCH DL channels base power P
E DCH
(k). Value is
Parameter pMinDlEDCH
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 edchServiceParameterSet1 Object OneBTSEquipment
Translation schedulingPriorityLevel
Range & Unit Integer: {0,1,..,15}
User Customer
Class 3
Value 15
Translation serviceMinRate
Value 40 [kbps]
Translation serviceMaxRate
Value 300 [kbps]
Translation serviceBFactor
Value 7
Translation serviceKFactor
Value 7

Page 130/132
which are valid for the interactive "silver" service class, i.e. with medium priority.
User Customer
Class 3
Value 14
Value 25 [kbps]
Value 200 [kbps]
Value 10
Value 7

which are valid for the interactive "bronze" service class, i.e. with lowest priority.
User Customer
Class 3
Value 13
Value 10 [kbps]
Value 100 [kbps]
Value 14
Value 7

Page 131/132
which are valid for the background service class.
User Customer
Class 3
Value 12
Value 0 [kbps]
Value 100 [kbps]
Value 15
Value 7

Page 132/132

END OF DOCUMENT

5 CALL MANAGEMENT

Volume 5 : Call Management
Page 1/67
CONTENTS
1 INTRODUCTION............................................................................................................................5
1.1 OBJ ECT....................................................................................................................................5
2.1 HPUG VOLUMES......................................................................................................................7
3 HSXPA CAC..................................................................................................................................9
3.1 RAB MATCHING........................................................................................................................9
3.2 ADMISSION PHASE ..................................................................................................................11
3.2.1 RNC CAC......................................................................................................................11
3.2.2 Node-B CAC..................................................................................................................27
3.3 HSPA TO DCH FALLBACK.......................................................................................................28
3.3.1 FALLBACK MECHANISM:............................................................................................28
3.3.2 PARAMETERS SETTINGS AND RECOMMENDATIONS:..........................................29
4 RLC RECONFIGURATION PROCEDURE .................................................................................30
4.1 HSDPA CASE ........................................................................................................................30
4.2 HSUPA CASE ........................................................................................................................32
5 MULTI-RAB HANDLING.............................................................................................................35
5.1 MULTI-RAB HANDLING ON HSDPA.........................................................................................35
5.1.1 Principles.......................................................................................................................35
5.1.2 Multi-RAB Combination Configuration (HSDPA) ..........................................................36
5.2 MULTI-RAB HANDLING ON HSUPA.........................................................................................39
5.2.1 Principles.......................................................................................................................39
5.2.2 Restriction on combination Streaming +HSUPA..........................................................39
5.2.3 Multiple PS I/B on HSUPA............................................................................................40
6 CALL SETUP (DATAFLOW).......................................................................................................42
6.1 INITIAL CONNECTION PHASE:....................................................................................................42
6.2 RAB ALLOCATION PHASE: .......................................................................................................43
7 CALL RELEASE (DATAFLOW)..................................................................................................45
7.1 IU RELEASE CASE....................................................................................................................45
7.2 RAB RELEASE CASE ...............................................................................................................45
8 RRM ALGORITHMS....................................................................................................................47
8.1 ALWAYS-ON............................................................................................................................47
8.1.1 Mechanism....................................................................................................................47
Page 2/67
8.1.2 New RRC states............................................................................................................47
8.1.3 Activation & ModeS.......................................................................................................49
8.1.3.1 Activation.................................................................................................................. 49
8.1.3.2 Modes....................................................................................................................... 52
8.1.3.3 Multiservice with HSDPA (HSDPA+CS & HSDPA+STR) ........................................ 55
8.1.3.4 Upsize....................................................................................................................... 55
8.1.3.5 Reminder for timer usage......................................................................................... 56
8.1.4 Parameters Settings and Recommendations ...............................................................58
8.2 IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING .......................................................59
8.3 IRM CAC/IRM PRE-EMPTION INTERWORKING ..........................................................................59
8.4 RB ADAPTATION INTERWORKING.............................................................................................61
8.5 UA6.0 PREEMPTION INTERWORKING .......................................................................................61
8.5.1 Description....................................................................................................................61
8.5.2 Feature Dependencies..................................................................................................62
8.5.3 CAC Failures.................................................................................................................63
8.5.4 Other backup mechanisms ...........................................................................................64
8.5.5 Activation flags..............................................................................................................65

Page 3/67
TABLES
Table 1: HSDPA RB Configuration and system behaviour 8
Table 2: HSUPA RB Configuration and system behaviour 9
Table 3 : Target Bit Rate 13
Table 4 : Corrective factor for power reservation 14
Table 5 : Corrective factor for codes reservation 16
Table 6: Always-on timer usage (URA/Cell_PCH states not used) 56
Table 7: Always-on timer usage (URA/Cell_PCH states are used) 57

Page 4/67
FIGURES
Figure 1 : HS-DSCH power reservation at call admission........................................................................... 14
Figure 2 : HS-PDSCH codes reservation at call admission......................................................................... 17
Figure 3: Example of biggest pool of free SF16............................................................................................ 17
Figure 4: HSxPA Call setup / initial connection (Cell_DCH)........................................................................ 42
Figure 5: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 43
Figure 6: HSUPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 44
Figure 7: Call release (RAB release case)..................................................................................................... 46
Figure 8: AO state transitions........................................................................................................................... 49
Figure 9: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none).............. 53
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates =none) ........... 54
Figure 11: Always-on for HSDPA/E-DCH (releaseOnly mode)................................................................... 55
Figure 12: UA6.0 Pre-emption global view..................................................................................................... 62
Figure 13: UA6.0 Pre-emption feature dependencies .................................................................................. 63
Figure 14: Pre-emption and other congestion management procedures .................................................. 65

Page 5/67
1 INTRODUCTION
1.1 OBJECT
recommendations.


Global
market
US
Market
27930 HSDPA Service
N/A UA4.2 Yes Yes
27942
Always-on On
HSDPA
isAlwaysOnAllowed
UA4.2 Yes Yes
27945
HSDPA Radio
Bearer
N/A
UA4.2 Yes Yes
30741
Multi-Services
Handling On
HSUPA
N/A
UA5.0 Yes Yes
29797
Multi-RAB Handling
on HSDPA
isMultiRabOnHsdpaAllowed
UA5.0 Yes Yes
32602
HSDPA to DCH
fallback
edchToDchFallbackPermission
edchToDchFallbackSteps
UA5.0 Yes Yes
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
N/A
UA6.0 Yes Yes
Page 6/67
33694
Fair Sharing of
Resources -
HSDPA vs DCH
RNC:
isHsxpaR99ResourcesSharing
OnCellAllowed
NodeB:
[iCEM] [xCEM]
BTSEquipment::hsdpaCodeTre
eManagementActivation
[UCU-III]
OneBTSEquipment::hsdpaCod
eTreeManagementActivation
UA6.0 Yes Yes
34170 3 PDP Support
isThreeRabAllowed
isMpdpExtendedRabCombsAll
owed
mpdpInactivityIuRelease
isMpdpExtendedRabCombsAll
owed
UA6.0 No Yes
34018
Multiple PS I/B on
HSUPA
isMultiRabOnEdchAllowed
UA7.1 Yes No

Page 7/67
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

Planning Guide
[R03] UMT/SYS/DD/018826 Call Admission Control (Radio)
[R05] UMT/IRC/APP/025147 CEM Capacity Engineering guide

Page 8/67
HSxPA only applies to the PS domain meaning that the entire 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 (more details are presented on Chapter 3.of this
volume)

RB Configuration System behaviour
All RABs DCH
available in HSDPA
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 HSDPA Supported (from UA4.2)
(PS I/B+PS I/B) on
HSDPA
Supported (from UA5.0)
PS Streaming on
HSDPA
Supported on HSDPA (from UA6)
Speech on DCH +
PS I/B on HSDPA
CSD/DCH +PS I/B
on HSDPA
Speech on DCH +
(PS+PS) on
HSDPA
(PS I/B+PS
Streaming) on
HSDPA
Table 1: HSDPA RB Configuration and system behaviour

Page 9/67
RB Configuration System behaviour
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
HSUPA
Supported on HSUPA in UA7.1
Speech on DCH +PS
I/B on HSUPA
Supported
Speech on DCH +
(PS+PS) on HSUPA
Supported on HSUPA in UA7.1
CSD/DCH +PS I/B on
HSUPA
Supported
Table 2: HSUPA RB Configuration and system behaviour

3 HSXPA CAC
3.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.
- 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:
- 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 condition has also to be checked:
- transfer delay > transportTypeSelectionTransferDelayThreshold (If
RANAP GBR >256kbps*, call is always mapped on to HS-DSCH regardless
Page 10/67
of CN transfer delay. * 384kbps if feature 33320 New RAB and combinations
for UA06 is enabled. See [R01] for more details)

Parameter transportTypeSelectionTransferDelayThreshold Object HsdpaRncConf
Range & Unit Integer [0 65536] seconds
User Customer
Class 3
Granularity RNC
Value 0

Engineering Recommendation: transportTypeSelectionTransferDelayThreshold
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)
It is not recommended to use a value different from 0.

Parameter isGbrOnHsdpaAllowed Object RadioAccessService
Range &
Unit
Boolean
{True, False}
User Customer
Class 3
Granularity RNC
Value True (customer dependant)

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 feature 29804 GBR on HSDPA) are enabled by default:
- NodeB: New mac-hs scheduler behaviour when the mac-hs GBR IE is
received (higher priority for mac-hs GBR users and computation of the HS-
DSCH 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 3.2.1 for more
details). At reception of this IE, the mac-hs scheduler activates a new behaviour
allowing to
- Schedule with a higher priority the mac-hs GBR users (see [Vol. 3] for more
details).
Page 11/67
- Report from the NodeB to the RNC the power needed to guarantee the mac-hs
GBR (this information is reported through the new NBAP common 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:
- 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).

3.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).

3.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).

For more details, see [R03].
Page 12/67

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
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 fall-
backed 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 3.3).

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

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 bitrates 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 bitrates needed for the service.
The bitrates uses to compute the resources needed for HSDPA users depend on the
service:I/B services or Streaming service and is called Target Bitrates.

Target Bitrate
The target bitrate is equal to:
Page 13/67
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

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
And with
RlcPduSize =320 bits or 640 bits for calls operating in fixed-RLC mode,
RlcPduSize =macehsMaximumPduSizePsStr for PS Streaming calls on HS-DSCH
operating in flexible-RLC mode,
RlcPduSize =macehsMaximumPduSizePsIb for PS I/B calls on HS-DSCH operating
in flexible-RLC mode

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 3 : Target Bit Rate

Page 14/67
Power reservation
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;
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 mapped on HS-DSCH:

Type of service Correcti ve factor
PS STR RAB with
RANAP GBR
None
PS I/B RAB with
minBr >0
initialActivityFactorForIb
PS I/B RAB with
minBr =0
Table 4 : Corrective factor for power reservation

Figure 1 : HS-DSCH power reservation at call admission

HS-DSCH power reservation
Target Bit Rate
dlTxPowerEstimation
Power reserved for PS
Streaming on HSDPA
Power reserved for
PS I/B on HSDPA
HS-DSCH power reservation
Target Bit Rate
dlTxPowerEstimation
Streaming on HSDPA
Power reserved for
PS I/B on HSDPA
Target Bit Rate
dlTxPowerEstimation
Streaming on HSDPA
Power reserved for
PS I/B on HSDPA
Page 15/67
For non GBR mac-d flows (see 3.1 for definition of non GBR user), the power
reservation will not change until the resources are released.
For GBR mac-d flows (see 3.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).

As mentioned in 3.1, the operator has the choice to consider a PS I/B user as a mac-
hs GBR user (same behaviour 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.

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 HS-
DSCH 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 satisfy the Mac-hs GBR
knowing the current throughput and the current power consumption (basically HS-
DSCH required power =current power consumption / current throughput * Mac-hs
GBR)

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.

Page 16/67
When Fair Sharing feature is enabled, the iRM power colour 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
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.

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 and >12:
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 Correcti ve factor
PS STR RAB with
RANAP GBR
reservationFactorOnCodesForGbrTraffic
PS I/B RAB with
minBr >0
and initialActivityFactorForIb
PS I/B RAB with
minBr =0
Table 5 : Corrective factor for codes reservation
Page 17/67

Figure 2 : 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, S-
CCPCH, HS-SCCH, E-AGCH, E-RGCH/E-HICH) as illustrated below

Figure 3: 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

HS-PDSCH codes reservation
Target Bit Rate
ovsfCodesThroughputXXUe
Codes reserved for PS
Streaming on HSDPA
Codes reserved for PS I/B
on HSDPA if minBr = 0
on HSDPA if minBr > 0
XX = QPSK or 16QAM
HS-PDSCH codes reservation
Target Bit Rate
Streaming on HSDPA
Target Bit Rate
Streaming on HSDPA
XX = QPSK or 16QAM
Page 18/67
where
- 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)

Parameters:
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 maximumNumberOfUsers Object HsdpaCellClass
User Customer
Class 3
Granularity RNC
Value 100

Parameter isHsxpaR99ResourcesSharingOnCellAllowed Object FDDCell
User Customer
Class 2
Granularity Cell
Value True

edchMaxUsersPerCell (under EdchCellClass) that was created for RNC CAC E-
DCH purpose, after UA6.0 becomes an obsolete parameter for Global Market.
RNC CAC of E-DCH has been abandoned. edchMaxUsersPerCell has no effect.
For UA7.0 and the initial UA7.1 release, this parameter is not used for the Global
or US Markets.
The limitation of the number of E-DCH users is entirely controlled through the BTS
parameter edchMaxNumberUserEbbu.
Parameter edchMaxNumberUserEbbu Object BTSEquipment
User Customer
Class 3
Granularity BTS
Value 15

Please refer to [R05] for a detailed description of these parameters.
Page 19/67
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 algorithms need to be
activated together in order to have a correct behaviour:
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 behaviour is correct
If (False; False) then the behaviour is correct
If (True; False) then the scheduler is not able 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

Page 20/67
Parameter isDlPowerSelfTuningForPsIbOnHsdpaEnabled Object FDDCell
User Customer
Class 3
Granularity Cell
Value 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 minBrForHsdpa Object ThpBasedQos
Range &
Unit
[0..2048] kb/s
User Customer
Class 3
Granularity RNC
Value Default values (see the table below)

Page 21/67
Engineering Recommendation: minBrForHsdpa
The value of minBrForHsdpa (one value per TC/ARP/THP) depends on the customer strategy.

1- Default recommendation:
Traffic Class ARP THP Target Bit Rate
1
2
3
1 -
2 -
3 -
1 minBrForHsdpa =16 kbps
Conversational
Streaming
Interactive
Background
1
2
3
N/A
N/A
N/A

The minBrForHsdpa is also used by the Transport feature 97431 - HSDPA OLS Differentiation at
NodeB Level to manage the transport congestion, but a resctriction between the GBR feature and this
transport feature dosent allow to use normally these defaut values. Please refer to the the resctriction
box below for details.

2- No resource reservation:
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:
Different type of differentiation can be used by the operator according to their strategy:
- differentiation per OLS (ARP):
Page 22/67
1
2
3
1 -
2 -
3 -
Background N/A
Interactive
1
2
3
Conversational
N/A
N/A
Streaming

- differentiation per Traffic Class:
1
2
3
1 -
2 -
3 -
Background N/A
N/A
Streaming
Interactive
1
2
3
Conversational
N/A

- differentiation per service (THP):
Page 23/67
1
2
3
1 -
2 -
3 -
Background N/A
N/A
Streaming
Interactive
1
2
3
Conversational
N/A

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 trade-off 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). Otherwise (activateOls =False),
ARP =3 and THP =3 is used.

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 for the feature 97431 - HSDPA OLS Differentiation at NodeB
Level. See [R04] and Volume 3 for more details on this parameter and this feature).

Page 24/67
Restriction: enhancedQualityOfService setting versus feature GBR
When FairSharing/GBR features are activated with at least one minBrForHsdpa using a target bit rate
value (guaranteeing a minimum throughput for a given service) this will oblige
enhancedQualityOfService to be set to Enable, in order that the Iub CAC and congestion
management can be aware of the GBR over the HSDPA traffic. Although, by setting this parameter to
Enable the feature HSDPA OLS Differentiation at NodeB Level cannot be activated simultaneously.

The parameter minHsDschReservationForCac is used only when minBrForHsdpa
is null.
Parameter minHsDschReservationForCac Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[0..1024] kb/s
User Customer
Class 3
Granularity RNC
Value Max value of minBrForHsdpa

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 mac-
hs 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 dlTxPowerEstimation Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[1..7][-35.0..15.0] step:0.1dB
User Customer
Class 3
Granularity RNC
Value -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])

Page 25/67
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 HS-
DSCH 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]

Parameter ovsfCodesThroughputQpskUe Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[1..15][0..14400] kb/s
User Customer
Class 3
Granularity RNC
Value 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))

Parameter ovsfCodesThroughput16QamUe Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[1..15][0..14400] kb/s
User Customer
Class 3
Granularity RNC
Value 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)).

Page 26/67
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
ThPerSf16 =100kb/s for QPSK ue
ThPerSf16 =200kb/s (hard-coded) for 16Qam ue
ThPerSf16 =200kb/s (hard-coded) for QPSK ue
ThPerSf16 =100kb/s for 16Qam ue
ThPerSf16 =100kb/s for QPSK ue
ThPerSf16 =300kb/s for 16Qam ue

Parameter reservationFactorOnCodesForGbrTraffic Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[0..500] %
User Customer
Class 3
Granularity RNC
Value 100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value

Page 27/67
Parameter initialActivityFactorForIb Object HsxpaR99ResourcesSharingCellClass
Range &
Unit
[0..100] %
User Customer
Class 3
Granularity RNC
Value 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 reserved 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 factor is derived from the parameter initialActivityFactorForIb (for
streaming, 100% activity is considered)

Up to 15 instances of HsxpaR99ResourcesSharingCellClass can be used. Instance
is selected through the following pointer:
Parameter hsxpaR99ResourcesSharingId Object FDDCell
Range & Unit N.A.
User Customer
Class 3
Granularity Cell
Value Pointer

3.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
6)
The CEM resources are split between HSDPA and HSUPA:
- HSDPA resources are handled by H-BBU function (see[R05])
- HSUPA resources are handled by E-BBU function (see [R05])

Each of these modules has some capacity limitations and this capacity is limited
through some sets of parameters (see [R05]).
If one of the E-BBU or H-BBU limit is reached, the BTS will send a RL Reconfiguration
Failure (meaning NodeB CAC failure)
Page 28/67
In case of BTS CAC failure (not enough HSDPA or HSUPA resources), the HSPA to
DCH fallback mechanism is triggered (see section 3.3))
Note that the NodeB CAC is unchanged whatever the Fair Sharing activation.

3.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 3.2). The following
HSxPA CAC failure scenarios trigger such a fallback:
RAB assignment (to establish or to release)
IU release
Primary Cell change
Inter-RNC UE involved Hard Handover
Alarm Hard Handover
HSxPA-to-DCH fallback is not allowed when CAC occurs for shared resources.

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.

3.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:
Page 29/67
Internal to RNC: maximum number of HSDPA or HSUPA users
External to RNC: NBAP or RNSAP failure causes

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.

3.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 hsdpaToDchFallbackPermission Object RadioAccessService
Range & Unit Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
User Customer
Class 3
Granularity RNC
Value AnyCase

Page 30/67
edchToDchFallbackPermission: This parameter defines the scope where a Fallback
on DCH is tried when a failure occurred due HSUPA CAC resource shortage.
Parameter edchToDchFallbackPermission Object RadioAccessService
Range & Unit Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
User Customer
Class 3
Granularity RNC
Value AnyCase

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 edchToDchFallbackSteps Object RadioAccessService
Range & Unit Enum
{MonoStep, MultiStep}
User Customer
Class 3
Granularity RNC
Value MultiStep

Engineering Recommendation: hsdpaToDchFallBackPermission and
edchToDchFallBackPermission
Both permissions should be set to AnyCase in order to improve Accessibility and Retainability.

4 RLC RECONFIGURATION PROCEDURE
4.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 Always-
On), 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.
Page 31/67
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]).

dch hs-dsch:
o case of mobility to or from a non-HSDPA cell:
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:
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:
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:
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:
Page 32/67
isRLCReconfigurationForChannelTypeSwitching: Activation of the RLC
reconfiguration after a channel type switching related to release or addition of another
RAB.
Parameter isRLCReconfigurationForChannelTypeSwitching Object HsdpaRncConf
{True, False}
User Customer
Class 3
Granularity RNC
Value True

deltaCfnForHsdpaMobility: Delta CFN used for HS-DSCH creation when primary
cell is changed.
Parameter deltaCfnForHsdpaMobility Object HsdpaRncConf
Range & Unit Integer
[0..255] (x10ms)
User Customer r
Class 3
Granularity RNC
Value 45

deltaCfnForHsdpaChannelTypeSwitching: Delta CFN used for SRLR due to
channel type switching between DCH and HS-DSCH
Parameter deltaCfnForHsdpaChannelTypeSwitching Object HsdpaRncConf
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 80

deltaCfnForHsdpaRLCReconfiguration: Delta CFN used for RLC reconfiguration
when done in stand-alone (0 means asynchronous reconfiguration).
Parameter deltaCfnForHsdpaRLCReconfiguration Object HsdpaRncConf
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 0

4.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.
Page 33/67
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 Always-
On), 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:
isRlcReconfigurationForChannelTypeSwitchingEdch: Activation of the RLC
reconfiguration during a channel type switching between DCH and E-DCH.
Page 34/67
Parameter isRLCReconfigurationForChannelTypeSwitchingEdch Object EdchRncConf
Range &
Unit
Boolean
{True, False}
User Customer
Class 3
Granularity RNC
Value True

deltaCfnForEdchAndHsdpaMobility: Delta CFN used for HSDPA +E-DCH mobility
when primary cell is changed and HSDPA +E-DCH is following the primary cell.
Parameter deltaCfnForEdchAndHsdpaMobility Object EdchRncConf
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 45

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 deltaCfnForEdchChannelTypeSwitching Object EdchRncConf
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 150

deltaCfnForEdchAndHsdpaChannelTypeSwitching: Delta CFN used for SRLR due
to channel type switching of both HSDPA and E-DCH.
Parameter deltaCfnForEdchAndHsdpaChannelTypeSwitching Object EdchRncConf
Range &
Unit
Integer
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 80

deltaCfnForEdchRlcReconfiguration: Delta CFN used for RLC reconfiguration when
done in stand-alone (0 means asynchronous reconfiguration).
Parameter deltaCfnForEdchRlcReconfiguration Object EdchRncConf
[0..255] (x10ms)
User Customer
Class 3
Granularity RNC
Value 150

Page 35/67
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.

5 MULTI-RAB HANDLING
5.1 MULTI-RAB HANDLING ON HSDPA
5.1.1 PRINCIPLES
The feature Multi-Rab Handling on HSDPA allows handling 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] (UCU-
III 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:
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).

Page 36/67
5.1.2 MULTI-RAB COMBINATION CONFIGURATION (HSDPA)
Firstly, a main activation flag allows enabling all multi RAB combinations using
HSDPA (PS MUX on HSDPA and PS HSDPA +other):

Parameter isMultiRabOnHsdpaAllowed Object RadioAccessService
Range &
Unit
Boolean
{True, False}
User Customer
Class 3
Granularity RNC
Value True

Note: when the feature is deactivated, then the resulting DlUserService will be
mapped on DCH only.
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 isThreeRabAllowed Object RadioAccessService
Range &
Unit
Boolean
{True, False}
User Customer
Class 3
Granularity RNC
Value False for GM, True for US Market

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
o CS Speech +PS HSDPA
Page 37/67
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
o HSDPACombinationList/1 1 PS I/B on HSDPA supported with
this DluserService
this DluserService
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
o HSDPACombinationEntry/1 PS Streaming over HSDPA is
supported with this DlUserService

The flag allowed in HSDPACombinationEntry determines if the related configuration
is supported.

Allowed
H
S
D
P
A
C
o
m
b
i
n
a
t
i
o
n
L
i
s
t

H
S
D
P
A
C
o
m
b
i
n
a
t
i
o
n
E
n
t
r
y

G
l
o
b
a
l

M
a
r
k
e
t

(
i
s
T
h
r
e
e
R
a
b
A
l
l
o
w
e
d

=

F
a
l
s
e
)

U
S

M
a
r
k
e
t

(
i
s
T
h
r
e
e
R
a
b
A
l
l
o
w
e
d

=

T
r
u
e
)

For DlUserServices Meaning
/0 /0 TRUE TRUE
/0 /1 FALSE FALSE
/1 /0 FALSE FALSE
/1 /1 FALSE FALSE
/2 /0 FALSE FALSE
/2 /1 FALSE FALSE
All DluserService
without HSDSCH

Page 38/67
/3 /0 FALSE FALSE
/3 /1 FALSE FALSE
/0 /0 FALSE FALSE CS_64K + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_64K + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /0 TRUE TRUE CS_64K + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE
CS_64KxPS_HSDSCH
xSRB_3_4K
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
/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_NBxPS_HSD
SCHxSRB_3_4K
CS_AMR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE
CS_AMR_WBxPS_HS
DSCHxSRB_3_4K
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
/1 /0 TRUE TRUE CS_AMR +PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE
CS_AMR_NBxPS_xxK_
STRxPS_HSDSCHxSR
B_3_4K
CS_AMR +PS_xxK_STR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_AMR +PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE
CS_AMR_WBxPS_xxK
_STRxPS_HSDSCHxS
RB_3_4K
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
/1 /0 TRUE TRUE PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE
PS_xxK_STRxPS_HSD
SCHxSRB_3_4K
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
/1 /0 TRUE TRUE PS_39_2K_VoIP + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /0 FALSE FALSE
PS_39_2K_VoIPxPS_H
SDSCHxSRB_3_4K
PS_39_2K_VoIP + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
Page 39/67
/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
/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
PS_HSDSCHxSRB_3_
4K
3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K

5.2 MULTI-RAB HANDLING ON HSUPA
5.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 done thru 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.

5.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
(i.e. no automatic fallback to 64kbps on DCH) :
PS Streaming UL:128kbps+PS I/B (E-DCH)
Corresponding combination with CS is not supported either.

Page 40/67
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 fall backed on (CS+)PS
Streaming +PS I/B DCH.

5.2.3 MULTIPLE PS I/B ON HSUPA
Multiple PS I/B on HSUPA 34018, will now be possible with the upgrade to UA7.1:
Support of multiple PS I/B RABs on E-DCH requires the support of an additional
MAC-d flow.
This feature aims at providing support of PS I/B+PS I/B and related combinations
with CS on HSUPA
The feature is supported only by the xCEM. This feature is not required for
OneBTS/UCUIII in V7.1
RAB combinations shall be then supported for 2ms and for 10ms TTI as well.

Supports of the following new RBs are now available:
PS+PS on E-DCH
PS I/B (E-DCH) + PS I/B (E-DCH) +SRB (DCH or E-DCH)
CS+PS+PS on E-DCH
CS NB AMR (DCH) + PS I/B (E-DCH)+PS I/B (E-DCH) +SRB (DCH)
CS WB AMR (DCH) + PS I/B (E-DCH)+PS I/B (E-DCH) +SRB (DCH)

New UlRbSetConf PS_EDCH_MUX, shall be defined (already in UA06 model but
still not used) and the existing UlUserService MOs will allow configuring the new RAB
combinations introduced by this feature.
For each UlUserService, an object EdchCombinationList indicates which mux E-
DCH combination is allowed or not (it is checked during RAB matching procedure).

Page 41/67
The parameters related to this feature are already present in the UA06 OAM model,
but not used so far since this feature has been churned out from UA06.
This feature can be activated at RNC level only.
The following parameter, is used as activation flag for the feature E-DCH for multiple
PS I/B.
Parameter isMultiRabOnEdchAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

Engineering Recommendation: interaction between features 34018 and 34170
The 34018 - Multiple PS on E-DCH, shall not be activated if 34170 - 3 PDP Contexts Support in
UTRAN is activated, a check is added. So, the following parameter for the Global Market case, should
be set to:
- isThreeRABAllowed =False
Inversely, for the US Market case, the following parameter should be set to:
- isMultiRabOnEdchAllowed =False

Rule: activation of multi RAB on HSDPA before activation of multi RAB on HSUPA
The isMultiRabOnEdchAllowed can be set to TRUE only if isMultiRabOnHsdpaAllowed is set to
TRUE.

Page 42/67
6 CALL SETUP (DATAFLOW)
6.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.

SGSN NodeB RNC UE
RRC/ RACH / RRC connection Request
SCCP/ Connection Request (Initial UE msg (Activate PDP Context Request))
SCCP/ Connection Confirm
RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,
RRC state = CELL_DCH, [frequency info])
RRC/ RACH / RRC Connection Setup Complete
RRC/ RACH / Initial Direct Transfer (Activate PDP Context Request, PS domain)
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)
The RRC Connection Request message initiated
by the UE contains the establishment cause.
The initial UE message is piggybacked in the
SCCP connection resquest
NBAP/ RL Setup Request)
NBAP / RL Setup

Figure 4: HSxPA Call setup / initial connection (Cell_DCH)

Page 43/67
6.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))

SGSN NodeB RNC UE
SM/ Activate PDP Context
GMM/ Authentication and Ciphering
The UE is authenticated by the SGSN
RANAP/ Security Mode Command
RANAP/ Security Mode
RRC/ Security Mode Command
RRC/ Security Mode Complete
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:
UIA1 for integrity
UEA1 for ciphering
RANAP/ RAB Assignment Response
RANAP/ RAB Assignment Request (RAB param, binding Id)
The Radio Access Bearer assignment procedure
The RAB is now established. the mobile is now waiting for end-to-end
service accept.
RRC/ RB Setup (DCCH + DTCH,
HS-DSCH information)
RRC/ RB Setup Complete
The UE is provided with the new radio link
configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration
NBAP/ Radio Link Reconfiguration Request (
HS-DSCH Radio Link)
NBAP/ Radio Link Reconfiguration Ready (HS-SCCH codes allocated)
A HS-DSCH Radio Link is created as well as the
associated DCH
FP/ DL Synchronisation (CFN)
FP/ UL Synchronisation (ToA)
The DCH is synchronised
RANAP/ Common Id
"Common Id" is used to provide the RNC with the user IMSI
NBAP/ Radio Link Reconfiguration Commit (
CFN)

Figure 5: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)

Page 44/67
SGSN NodeB RNC UE
SM/ Activate PDP Context
The UE is authenticated by the SGSN
RANAP/ Security Mode Command (UIAx, UEAy)
RANAP/ Security Mode
RRC/ Security Mode Command
RRC/ Security Mode Complete
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:
UIA1 for integrity
UEA1 for ciphering
RANAP/ RAB Assignment Response
RANAP/ RAB Assignment Request (RAB param, binding Id)
The Radio Access Bearer assignment procedure
The RAB is now established. the mobile is now waiting for end-to-end
service accept.
RRC/ RB Setup (E-DCH info, E-RNTI,
CFN)
RRC/ RB Setup Complete
The UE is provided with the new radio link
configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration
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.)
NBAP/ Radio Link Reconfiguration Ready (E-DCH FDD info Response, E-DCH FDD DL
Control Channel
The Radio Link is reconfigured to add the E-
DPCH in uplink in the serving cell. (The HS-
DSCH part is not shown)
RANAP/ Common Id
"Common Id" is used to provide the RNC with the user IMSI
NBAP/ Radio Link Reconfiguration Commit (
CFN)

Figure 6: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)

Page 45/67
7 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.

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

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

Page 46/67
SGSN NodeB RNC UE
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)
RANAP/ RAB Assignment request response
NBAP/ Radio Link Reconfiguration Prepare
(remove HSDPA MAC-d flow)
The radio link is re-configured (only primary cell).
RRC/ RRC Connection Release
NBAP/ Radio Link Deletion
NBAP/ Radio Link Deletion
SCCP/ Released
RANAP/ Iu Release Complete
RANAP/ Iu Release Command
If isRABRelMgtAllowed is set to "false", the RNC requests for a
global Iu Release.
RRC/ RRC Connection Release Complete
Release of radio bearer and RRC connection
RANAP/ Iu Release Request
NBAP/ Radio Link Reconfiguration Ready
NBAP/ Radio Link Reconfiguration Commit
([activation CFN])
RRC/ RB Release (remove HSDPA ; [activation CFN])
RRC/ RB Release Complete
All the RLs of the active set are deleted (so
may imply several Node Bs)

Figure 7: Call release (RAB release case)

Page 47/67
8 RRM ALGORITHMS
8.1 ALWAYS-ON
8.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 Signalling Indication parameter of the RAB
Assignment Request associated with the Interactive RAB has been set to signalling.
In this case (example: Video Streaming signalling like RTSP protocol, or VoIP
signalling like SIP protocol), the RB will not be downsized nor released by Always-on.

Always-on allows optimizing 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 3.2).
In UL, E-DCH CAC, (see 3.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.

8.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 8: AO state
transitions):
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 Pre-
emption). For a session to be maintained in this state, the user traffic
must remain above a predefined threshold: if it falls and stays below
Page 48/67
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 a pre-defined threshold (from
CELL_FACH state).
A new call (CS or PS) is established
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).

Page 49/67
The simplified state transitions are shown in Figure 8.

CELL_FACH
CELL_PCH
URA_PCH
Normal
mode
Idle
mode
Downsizing
(Tdownsize expiry)
Release
(Tinactivity expiry)
RB R-establishment
(Traffic resuming)
(Tinactivity expiry)
Upsizing
(Traffic
resuming)
Normal mode AO Step 1 AO Step 2 AO Step 3
Downsized mode

Figure 8: AO state transitions
For more details on Always ON transitions, see UPUG [R01]

8.1.3 ACTIVATION & MODES
8.1.3.1 ACTIVATION
Always-on has to be activated for HSDPA and E-DCH. Several parameters are to be
set:
First, Always-on has to be activated on RNC :
Parameter isAlwaysOnAllowed Object AlwaysOnConf
{True, False}
User Customer
Class 3
Granularity RNC
Value False (de-activate the feature)
True (activate the feature)

Then, Always-on has to be activated on user service:
Page 50/67
Parameter isAlwaysOnAllowed Object DlUserService
{True, False}
User Customer
Class 3
Granularity DlUserService
Value See table below

DlUserService
isAlwaysOnAllowed
CS_64KxPS_HSDSCHxSRB_3_4K
True
CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K
True
True
True
True
CS_AMR_NBxPS_HSDSCHxSRB_3_4K
True
PS_16K_STRxPS_HSDSCHxSRB_3_4K
True
True
True
True
PS_HSDSCHxSRB_3_4K
True

The suitable Always-on mode has to be set on RB configuration:
Parameter isAlwaysOnAllowed Object DlRbSetConf
Range & Unit Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
User Customer
Class 3
Granularity DlRbSetConf

DlRbSetConf isAlwaysOnAllowed
PS_HSDSCH_IB degraded2AlwaysOnOnly
PS_HSDSCH_IB_MUX 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 isAlwaysOnAllowed Object UlUserService
{True, False}
User Customer
Class 3
Granularity UlUserService

Page 51/67
UlUserService
isAlwaysOnAllowed
CS_64KxPS_EDCHxSRB_3_4K
True
CS_AMR_NBxPS_16K_STRxPS_EDCHxSRB_3_4K
True
True
True
True
PS_16K_STRxPS_EDCHxSRB_3_4K
True
True
True
PS_EDCHxSRB_3_4K
True

Parameter isAlwaysOnAllowed Object UlRbSetConf
{disabled, degraded2AlwaysOnOnly, releaseOnly}
User Customer
Class 3

UlRbSetConf isAlwaysOnAllowed
PS_EDCH 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.

The new RRC states are activated by the operator:
Parameter PchRrcStates Object Radio Access Service
{none, UraPchEnabled, CellPchEnabled, UraAndCellPchEnabled}
User Customer
Class 3
Granularity
Value 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).

For more details on RRC states configuration see UPUG [R01]
Page 52/67
8.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
o 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
o 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

Page 53/67

Figure 9: 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:
o 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;
o PS I/B Single: to be able to go through Cell/URA_PCH states, the
PS I/B Single have 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 downsizes the user to Always-on
CELL_FACH and performs 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.
Activity (UL or DL)
Low activity /
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH
CELL FACH
Downsize
timer
Step 2
(fachToCellPchTimer,
fachToUraPchTimer)
t
Always-on (degraded2AlwaysOnOnly, PchRrcStates none)
Downsize
(step 1)
Inactivity
t
Traffic UL/ DL
timerT1ForHsdpaAndEDch)
Downsize timer
Step 1
(timerT1ForHsdpa,
Downsize
(step 2)
CELL PCH/ URA PCH
Downsize
(step 3)
Downsize
timer
Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)
Page 54/67

Activity (UL or DL)
Low activity /
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH
Downsized RB (CELL_FACH)
Release timer
(timerT2)
t
Always-on (degraded2AlwaysOnOnly, PchRrcStates = none)
Downsize
Release
Inactivity
t
Traffic UL/ DL
Downsize
timer
(timerT1ForHsdp

Figure 10: 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.

Page 55/67

Activity (UL or DL) Low activity
Release timer
(timerT2ForHsdpa
t
Always-on (releaseOnly)
Release
Inactivity
t
Traffic UL/ DL
HSDPA + UL DCH
HSDPA + E-DCH

Figure 11: 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).

8.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 DCH / DL HSDPA) or
timerT2ForHsdpaAndEdch (UL E-DCH / DL HSDPA)

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

Page 56/67
8.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)
D
timerT1ForHsdpa
timerT1ForHsdpaAndEDch
timerT2
HSDPA / E-DCH
R NA
timerT2ForHsdpa
PS I/ B Mux+ SRB
Always-on mode T1 ( =>CELL_FACH) T2 ( => Idle)
HSDPA / DCH R timerT2ForHsdpa
CS + PS I/ B (Mux) + SRB
Always-on mode T1 ( => CS + PS8) T2 ( => CS)
D
HSDPA / E-DCH
R
NA
timerT2ForHsdpa
(1)
(1)
HSDPA / DCH (Mux) R NA
timerT2ForHsdpa
(1)
(1)

Table 6: 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 Signalling Indication IE is set to "signalling")
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 Signalling Indication IE is
set to "signalling")

Page 57/67
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)
D
timerT1ForHsdpa
timerT1ForHsdpaAndEdch
fachToCellPchTimer/
fachToUraPchTimer
cellPchToIdleTimer/
uraPchToIdleTimer
HSDPA / E-DCH
R NA NA
timerT2forHsdpa
timerT2forHsdpaAndEdch
PS I/ B Mux+ SRB

Always On
Mode
T1 (=> CELL_FACH) T2 (=> Cell/ URA_PCH) T3 (=> Idle)
HSDPA / DCH R
tDchPchMpdpForHsdpaAndDc
h (1)
uraPchToIdleTimer/
cellPchToIdleTimer
CS + PS I/ B (Mux) + SRB

Always On
Mode
T1 (=> CS+PS8) T2 (=> CS + PS 0) T3 (=> Idle)
D
timerT2ForHsdpa
uraPchToIdleTimer/
cellPchToIdleTimer
HSDPA / E-DCH
R NA
timerT2ForHsdpa
HSDPA / DCH
(Mux)
R timerT2ForHsdpaAndDch
uraPchToIdleTimer/
cellPchToIdleTimer
Table 7: 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.
(2) PS Component released, CS remaining
(3) 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 Signalling Indication IE is set to
"signalling"). 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 Signalling
Indication IE is set to "signalling").

Page 58/67
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.

8.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,
Object AlwaysOnTimer
Range & Unit [10..3600000] (ms)
User Customer
Class 3
Granularity OLS
Value 10000

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.
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
Parameter fachToCellPchTimer,
fachToUraPchTimer
Range & Unit [1..3600] (s)
User Customer
Class 3
Granularity OLS
Value 10

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).
Page 59/67
Parameter timerT2ForHsdpa,
Range & Unit [10..10800000] (ms)
User Customer
Class 3
Granularity OLS
Value 10000
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 uraPchToIdleTimer,
cellPchToIdleTimer
Range & Unit [1..7200] (min)
User Customer
Class 3
Granularity OLS
Value 60

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 certain timer duration, we can consider that the subscriber will
not resume its data session anymore, and it is legitimise to release the radio resources.

Parameter nbOfCellUpdatesFromCellPchToUraPch Object RadioAccessService
Range & Unit [1..65535]
User Customer
Class 3
Granularity RNC
Value 1

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

8.2 IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING
HSxPA links are not eligible to iRM scheduling downgrade/upgrade procedures.

8.3 IRM CAC/IRM PRE-EMPTION INTERWORKING
HSDPA links are not eligible to iRM CAC/iRM Pre-emption (UA4.1 algorithm)
procedures since the throughput adaptation is provided by the MAC-hs scheduler i.e.
Page 60/67
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 colour 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 colour calculation.

In UA6.0, when the feature Fair Sharing is activated, OVSF codes load is computed
following the usual formula:

=
SF All
SF
SF n actor SpreadingF eeCodesPer NumberOfFr
tors readingFac NumberOfSp
Load Code
_
16 / *
*
1
1 _

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:
=
SF All
SF
actor SpreadingF eeCodesPer NumberOfFr
Load Code
_
*
1
1 _
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:

+
=
SF All
SF
SF
des fHsPdschCo minNumberO Ceil
SF
Pdsch ocatedToHs 16CodesAll NumberOfSF Ceil
actor SpreadingF eeCodesPer NumberOfFr
Load Code
_
16
(
16
(
*
1
1 _

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 are a fixed number of SF 16 codes reserved for HSDPA (minNumberOfPdschCodes).
These codes are considered as used (static) by the iRM Cell Colour 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 resource between R99 and HSDPA, leading to a better
efficiency of the OVSF codes resource usage. The iRM thresholds may then have to be retuned.
Page 61/67
Moreover, the iRM thresholds can be tuned independently from the HSDPA
configuration.
The operator may tune iRM thresholds so that colour turns yellow before stealing HS-
DSCH codes and red before having stolen all HS-DSCH codes.
For more details see UTRAN Parameters Used Guide [R01]
On the Iub, the Iub load colour 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.

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

8.5 UA6.0 PREEMPTION INTERWORKING
8.5.1 DESCRIPTION
The UA6.0 pre-emption 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 pre-emption 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:
Page 62/67
Eligible CAC
Failures
Eligible
procedures
Preemption
Eligible
Services
NodeB UL radio resources not available
RNC DL power resources not available
RNC DL code resources not available
NodeB resources not available
NodeB DL radio resources not available
Shared
Dedicated NodeB UL radio resources not available
RNC DL power resources not available
RNC DL code resources not available
NodeB resources not available
NodeB DL radio resources not available
Shared
Dedicated
PS Background
PS Interactive
Signaling PS Interactive
PS Streaming
CS Streaming
Video telephony
Speech
Emergency Call
Preemption
Capability
Preemption
Vulnerability
Priority (*)
PS Background
PS Interactive
Signaling PS Interactive
PS Streaming
CS Streaming
Video telephony
Speech
Emergency Call
Preemption
Capability
Preemption
Vulnerability
Priority (*)
Inter-Frequency intra-
RNC Radio Link setup
(IMCTA CAC, iMCTA
Alarm)
Radio Link Addition
Always-on Upsize
RRC connection request
RAB Assignment
Queuing not
allowed
Queuing allowed
Inter-Frequency intra-
RNC Radio Link setup
(IMCTA CAC, iMCTA
Alarm)
Radio Link Addition
Always-on Upsize
RRC connection request
RAB Assignment
Queuing not
allowed
Queuing allowed
R99
HSUPA HSDPA
(*) + OLS at user level
1 Steps / 2 Steps
Incoming relocation does not trigger
preemption in the target RNC
Incoming relocation does not trigger
preemption in the target RNC

Figure 12: UA6.0 Pre-emption global view

8.5.2 FEATURE DEPENDENCIES
The Fair sharing feature (FRS 33694) activation is mandatory before the activation of the
Pre-emption feature.

Page 63/67
Fair sharing of
resources
33694
GBR on HSDPA
29804
Preemption
33322
Upon CAC Failure
Shared resources (R99 & HSDPA) : OVSF Codes & DL Power
Dedicated resources : CEM (Node B)
Common Call Admission Control between HSDPA and R99 users
for OVSF Codes and DL Power
Min QoS ensured for HSDPA users (PS Streaming & PS I/B)
MinBR & GBR transmitted (optionally) to the Node B
MAC-hs scheduler to ensure the QoS of HSDPA users (MinBR &
GBR)
Power consumption Node B feedback to RNC (needed for fair-
sharing)

Figure 13: UA6.0 Pre-emption feature dependencies

8.5.3 CAC FAILURES
A CAC failure may happen at RNC or at Node B.
At Node B level, the resources used by DCH and HS-DSCH / E-DCH is not shared.
Then, for a Node B CAC failure:
A DCH resource allocation failure will trigger the pre-emption of DCH
user(s): for an UL CAC failure, the pre-empted user(s) may be UL DCH / DL
DCH or UL DCH / DL HS-DPA
A HS-DSCH resource allocation failure will trigger the pre-emption of HS-
DSCH user(s)
A E-DCH resource allocation failure will trigger the pre-emption of E-DCH
user(s)
From UA6.0, at RNC level, with the introduction of the Fair-sharing feature, the OVSF
Codes and DL Power resources are managed as 1 pool shared by DCH and HSDPA
calls.
Example 1 : the incoming user is R5 on a HSDPA capable cell (and not HSUPA
capable)
The CAC failure is DL and at RNC level : the pre-empted users will be either
UL DCH / DL DCH or UL DCH / DL HSDPA
The CAC failure is DL at Node B level : the pre-empted users will be either UL
DCH / DL HSDPA
Page 64/67
The CAC failure is UL : the pre-empted users will be either UL DCH / DL DCH
or UL DCH / DL HSDPA

Example 2 : the incoming user is R5 on a HSDPA capable cell
UL DCH / DL DCH or UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is DL at Node B level : the pre-empted users will be either UL
DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is UL : the pre-empted users will be either UL DCH / DL DCH
or UL DCH / DL HSDPA

Example 2 : the incoming user is R6 on a HSUPA capable cell
UL DCH / DL DCH or UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is DL and at Node B level : the pre-empted users will be either
UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is UL : the pre-empted users will be either UL E-DCH / DL
HSDPA

The list of eligible users is ordered according to service priority and OLS.

8.5.4 OTHER BACKUP MECHANISMS
The potential mechanisms used to save the call are, in the order of triggering :
HsxPA to DCH fallback
iMCTA
Pre-emption

Page 65/67
iMCTA CAC &
Alarm
29415
HSxPA to DCH
fallback
32602
Preemption
33322
Will be triggered first for HSxPA incoming users.
Depending on CAC failure, fallbacks 1 step / 2 steps may be
tried :
DL HSDPA / UL R99
DL DCH / UL DCH
If HSxPA to DCH fallback is activated, iMCTA CAC will not be
triggered upon HSxPA CAC failure.
A incoming HSxPA user will first go through the HSxPA to DCH
fallback algorithm. On R99 failure, iMCTA CAC will be triggered
Preemption will be called as last chance, after HSxPA to DCH
fallback and iMCTA (according to applicability of each
algorithm)

Figure 14: Pre-emption and other congestion management procedures

Note: The HsxPA to DCH fallback is exclusive with Fair-sharing when the CAC failure
is DL Power or OVSF Codes.

8.5.5 ACTIVATION FLAGS
There are different levels of activation for this feature.
The activation by transport type allows activating the feature separately for:
HSDPA
E-DCH
There is no specific flag for DCH: when the feature is activated (at RNC and Cell
level), the pre-emption for DCH is activated by default.

The activation flags by transport type are described below:
Page 66/67
isPreemptionAllowedForHsdpa: This parameter is used to activate/de-
activate pre-emption process for UL DCH/DL HSDPA calls.
Parameter isPreemptionAllowedForHsdpa
Object PreemptionAllowedInfo
Granularity RNC
Range & Unit Boolean: {True, False}
User & Class Customer, Class 3
Value False (De-activate the feature for HSDPA)
True (Activate the feature for HSDPA)

isPreemptionAllowedForEdch: This parameter is used to activate/de-
activate pre-emption process for UL E-DCH / DL HSDPA.
Parameter isPreemptionAllowedForEdch
Object PreemptionAllowedInfo
Granularity RNC
Range & Unit Boolean: {True, False}
User & Class Customer, Class 3
Value False (De-activate the feature for E-DCH)
True (Activate the feature for E-DCH)

Page 67/67

END OF DOCUMENT

6 MOBILITY


Volume 6 : Mobility
Page 1/52
CONTENTS
1 INTRODUCTION............................................................................................................................5
1.1 OBJ ECT....................................................................................................................................5
2.1 HPUG VOLUMES......................................................................................................................7
3 INTRA-FREQUENCY MOBILITY FOR HSXPA ............................................................................8
3.1 MOBILITY OF ASSOCIATED DCH................................................................................................8
3.2 MOBILITY OF HS-DSCH...........................................................................................................8
3.3 MOBILITY OF E-DCH ..............................................................................................................11
3.3.1 Cell addition to DCH AS and Primary Cell change procedures for E-DCH calls..........11
3.3.2 E-DCH Mobility without macro-diversity (32076 not activated).....................................12
3.3.3 E-DCH Macro Diversity Support (32076)......................................................................13
3.3.3.1 Feature description................................................................................................... 13
3.3.3.1.1 Feature aim and principle..................................................................................... 13
3.3.3.1.2 E-DCH active set management............................................................................ 15
3.3.3.1.3 E-DCH call attributes management...................................................................... 16
3.3.3.1.4 E-DCH non-serving radio links management....................................................... 17
3.3.3.2 Parameter settings and recommendations............................................................... 19
3.3.3.2.1 Feature activation................................................................................................. 19
3.3.3.2.2 RAN Model ........................................................................................................... 19
3.3.3.2.3 OMC-R Parameters.............................................................................................. 20
3.3.3.2.4 OMC-B Parameters.............................................................................................. 23
3.4 FULL EVENT SHO SETTING FOR HSXPA..................................................................................24
3.5 INTRA-FREQUENCY MOBILITY OVER IUR ....................................................................................26
3.5.1 HSDPA OVER IUR .......................................................................................................26
3.5.2 HSUPA OVER IUR .......................................................................................................27
3.5.2.1 Iur compliance: Correction of the condition of UL DPDCH Indicator for E-DCH
Operation 31
3.6 INTRA-FREQUENCY INTER-RNC HHO......................................................................................33
4 COMPRESSED MODE WHILE IN HSXPA .................................................................................34
4.1 COMPRESSED MODE IN MAC-HS.............................................................................................34
4.1.1 Feature Description.......................................................................................................34
4.1.2 Compressed Mode Configuration.................................................................................35
4.1.3 Transmission Gap Patterns evaluation.........................................................................36
4.1.4 Compressed frames management................................................................................37
COMPRESSED MODE IN MAC-E.......................................................................................................37
4.2......................................................................................................................................................37
4.3 RNC DEFENSE MECHANISM AGAINST UES NOT SUPPORTING HSDPA OR E-DCH COMPRESSED
MODE 41
5 INTER-CARRIER MANAGEMENT FOR HSXPA .......................................................................43
Volume 6 : Mobility
Page 2/52
6 INTER-FREQUENCY AND INTER-SYSTEM HHO FOR HSXPA...............................................45
6.1 INTER-FREQUENCY MOBILITY FOR HSXPA ..............................................................................46
6.1.1 Inter-Frequency intra-RNC Mobility for HSxPA.............................................................46
6.1.2 Inter-Frequency inter-RNC without Iur Mobility for HSxPA...........................................47
6.1.3 Inter-Frequency inter-RNC with Iur Mobility for HSxPA................................................47
6.1.4 Full Event HHO setting for HSxPA................................................................................48
6.2 INTER-SYSTEM MOBILITY FOR HSXPA.....................................................................................49
6.2.1 3G to 2G Handover.......................................................................................................49
6.2.2 2G to 3G Handover.......................................................................................................49
7 U-PLANE TRAFFIC HANDLING.................................................................................................50

Volume 6 : Mobility
Page 3/52
TABLES
Table 1: SHO Event Recommended Settings Summary 26
Table 2: Summary matrix for E-DCH Compressed Mode support 41
Table 3: HHO Event Recommended Settings Summary 49

Volume 6 : Mobility
Page 4/52
FIGURES
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case) ......................... 10
Figure 2: E-DCH link is deleted and re-established on new Primary Cell (nominal case) ...................... 12
Figure 3: E-DCH macro diversity general principle....................................................................................... 14
Figure 4: OMC-R RAN model for 32076......................................................................................................... 19
Figure 5: OMC-B RAN model for 32076......................................................................................................... 20
Figure 6: Transmission of E-DPDCH (10ms TTI) when in CM operation.................................................. 38

Volume 6 : Mobility
Page 5/52
1 INTRODUCTION
1.1 OBJECT
Mobility algorithms and parameters applicable to HSDPA & E-DCH (HSUPA) system.
recommendations.

Global
market
US
Market
27936
HSDPA Intra-
frequency Mobility
Automatic/Available at Upgrade but
check if
isRLCReconfigurationForChannelType
Switching
UA4.2 Yes Yes
27937
HSDPA Alarm
Mobility - inter RAT:
3G to 2G only and
blind
Automatic/Available at Upgrade
UA4.2 Yes Yes
29802
Inter-frequency Inter-
system HSDPA HHO
isHsdpaHhoWithMeasAllowed
UA5.0 Yes Yes
29817 HSDPA over Iur
isHsdpaAllowed
isHsdpaOverIurAsDrncAllowed
isHsdpaOverIurAsSrncAllowed
UA5.0 Yes Yes
29798
Compressed Mode in
MAC-hs
isGsmCModeActivationAllowed
isInterFreqCModeActivationAllowed
isInterFreqMeasActivationAllowed
isPatternAllowed
UA5.0 Yes Yes
33480
Compressed Mode in
MAC-e Scheduler
[iBTS]
No activation flag.
Compressed Mode for HSPA calls can be
activated/deactivated via
isInterFreqCModeActivationAllowed
and isGsmCModeActivationAllowed
(for DL services with HSDPA).
UA5.1/
UA7.1
Yes
(UA5.1)
Yes
(UA7.1)
Volume 6 : Mobility
Page 6/52
34012
HSDPA over Iur b/w
management
isMacShHsdpaAllowed
UA5.1 Yes Yes
32076
E-DCH Macro
Diversity Support
No activation flag.
Feature can be deactivated by restricting
the E-DCH active set size to one cell (by
setting maxNumberOfRlEdch to 1).
UA6.0 Yes Yes
34167
Defence mechanism
for UEs not
supporting CM with
HSPA
isEdchCmFallbackAllowed
isHSDPACMFallbackAllowed
UA6.0 Yes Yes
34229
Inter Freq HO
Enhancements
isInterFreqHandoverOverIurAllowed
UA6.0 No Yes
30744 HSUPA Over Iur
isEdchAllowed
isEdchOverIurSrncAllowed
isEdchOverIurDrncAllowed
UA6.0 Yes No

Volume 6 : Mobility
Page 7/52
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility
[Vol. 7] Deployment Scenarios

[R03] 3GPP TS 25.321 MAC protocol specification
[R04] 3GPP TS 25.423 RNSAP signalling
[R05] 3GPP TS 25.433 NBAP signalling
Planning Guide

Volume 6 : Mobility
Page 8/52
This section describes the existing mobility procedures for HSxPA calls.
If it is not possible to re-establish HSxPA on the new primary (i.e. CAC failure in the
HS-DSCH RL Reconfiguration consecutive to the primary cell change), HSPA to DCH
fallback mechanism is applied if provisioned (cf. relative section), otherwise RNC
triggers IU-PS Release procedure.
Mobiles can be spread over HSxPA and not-HSxPA layers thanks to several
algorithms:
Idle Mode & HCS feature while in Idle, PCH and Cell FACH states (refer to
UPUG [R01])
RRC Redirection at call establishment (refer to UPUG [R01])
iMCTA while in Cell DCH mode (refer to UPUG [R01])

3 INTRA-FREQUENCY MOBILITY FOR HSXPA
3.1 MOBILITY OF ASSOCIATED DCH
Soft and softer handovers are handled normally on the associated DCHs and the DCH
Active Set is managed as usual.

For more details, see UPUG Vol.12, [R01].

3.2 MOBILITY OF HS-DSCH
As defined by 3GPP, HS-DSCH is established in only one cell so is never in soft
handover. In Alcatel-Lucent implementation, the serving HS-DSCH RL always follows
that of the primary cell.
When a cell is added in the active set without primary cell change (i.e. HS-DSCH still
running on former primary cell), the new radio link is established with DL SRB 3.4
kbps +DL TRB 0 kbps (+another possible DL TRB in case of multi-service).
HSDPA mobility is invoked as long as the target cell is HSDPA capable. When the
primary cell changes:
If the former primary cell is no longer present in the new Active Set (following
an Active Set Update procedure), the HS-DSCH radio link is immediately
released on the old primary cell (NBAP RL Deletion), the RRC Measurement
Control procedure is sent and the new HS-DSCH radio link is setup using a
normal Synchronized RL Reconfiguration procedure (NBAP RL
Reconfiguration on the target NodeB and RRC RB Reconfiguration message)
on the new primary cell.
If the former primary cell remains in the Active Set, the RRC Measurement
Control procedure is sent, then the HS-DSCH RL is deleted on the former
Volume 6 : Mobility
Page 9/52
primary cell and it is re-established under the new one synchronously via the
normal Synchronized RL Reconfiguration procedure (NBAP RL
Reconfiguration on both source and target NodeB and RRC RB
Reconfiguration message. This is shown in the Figure 1 below.
If the new primary cell does not support HSDPA then the RB is reconfigured
to DCH. iRM CAC is performed and if there is a CAC failure, the call is
dropped.
If the new primary cell supports HSDPA while the former did not, then the RB
is reconfigured to HS-DSCH. In case HSDPA CAC failure occurs, fallback to
DCH may occur if provisioned; Fallback to DCH will be blocked if Fair sharing
is activated and CAC occurred due to either power or Code shortage. In this
case iMCTA CAC will take place instead (if provisioned). IU-PS is released
otherwise.
During the reconfiguration, data transfer is suspended by the RNC (not for the whole
reconfiguration time but only for a short time before the synchronized cell change,
please refer to the section 7 for the parameter which control the time when RNC
suspends the traffic). Data that were in the MAC-hs buffer of the former cell are
discarded (except if both cells are managed by the same H-BBU board). User data are
not lost thanks to RLC retransmissions but if the primary cell changes too often; the
data throughput can be impacted.

Volume 6 : Mobility
Page 10/52

Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case)

[GM] In case of TMA usage, externalAttenuationMainDivUL/DL values need to be accurately filled
with cable losses. Otherwise, HSDPA mobility can be highly impacted (UL reception asymmetry for
soft handover).

Starting from the release UA7.0, MAC-ehs (enhanced MAC-hs) may be used for the
call, depending on the capability of the NodeB and the RNC configuration.
If the inter-nodeB mobility (soft HO) involves a source NodeB and a target NodeB with
different MAC-ehs capability, the RB is reconfigured accordingly (from MAC-hs to
MAC-ehs or reversely). Depending on the mobility scenario an RLC one-sided re-
establishment of the downlink may be performed.
For intra-nodeB mobility (softer HO) involving a source cell and a target cell with
different feature activation state (MAC-ehs allowed on one cell, MAC-ehs not allowed
on the other cell), the RB can not be reconfigured accordingly (the NodeB does not
support such kind of reconfiguration). If the source cell has MAC-ehs allowed but not
RNC Node B
source
Node B
target
UE
RB Reconfiguration (Activation CFN)
RL Reconfiguration Ready
Measurement Control (new neighbouring list)
RL Reconfiguration Prepare (HS-DSCH information)
RB Reconfiguration Complete
Primary cell change
RL Reconfiguration Prepare
(MAC-d flow to Delete)
RL Reconfiguration Commit (Activation CFN)
Activation CFN
RL Reconfiguration Commit
(Activation CFN)
Volume 6 : Mobility
Page 11/52
the target cell, the RB is fall backed to DCH. If the target cell has MAC-ehs allowed
but not the source cell, the RB stays with MAC-hs.
Refer to the description of the feature 34388 in the Volume 3 for more details on MAC-
ehs and flexible RLC protocols.

3.3 MOBILITY OF E-DCH
3.3.1 CELL ADDITION TO DCH AS AND PRIMARY CELL
CHANGE PROCEDURES FOR E-DCH CALLS
In the scope of an E-DCH call, the concept of active set (a set of radio links involved in
a specific communication between one UE and the UTRAN) is extended with the
concept of E-DCH active set. The E-DCH active set (E-DCH AS) is the set of cells
which carry the E-DCH radio links for the UE. It is a sub-part of the full active set. The
full active set is noted DCH active set (DCH AS).
When a cell is added in the DCH active set without Primary Cell change (i.e. E-DCH
still running on the Primary Cell, which is different from the cell that has just been
added), the new radio link is established with UL SRB 3.4 kbps +UL TRB 0 kbps (+
another possible UL TRB in case of multi-service).
When the Primary Cell changes to a cell of the same frequency layer, the E-DCH
serving RL follows that of the Primary Cell (via Synchronous Radio Link
Reconfiguration SRLR if the new Primary Cell was in the old DCH AS). HS-DSCH is
reconfigured within the same SRLR procedure. If the E-DCH Macro-Diversity is not
activated, the former Primary Cell RL is reconfigured to DCH.
If it is not possible to establish the E-DCH RB on the new Primary Cell (i.e. E-DCH
CAC failure), then the E-DCH RB is fall-backed to UL DCH via the HSPA to DCH
Fallback mechanism (see [Vol. 5] of this document). If HSPA to DCH Fallback
mechanism is disabled, then the E-DCH RB is released.
When a new Primary Cell is selected, the transport channel type selector is played:
If the old Primary Cell was E-DCH and not the new one, the RB is
reconfigured to DCH.
If the old Primary Cell was not E-DCH but the new one is, the RB is
reconfigured to E-DCH.
If the new Primary Cell is E-DCH and the call was E-DCH, then call is kept on
E-DCH.

Volume 6 : Mobility
Page 12/52

RNC Node B
source
Node B
target
UE
RB Reconfiguration (Activation CFN)
Measurement Control (new neighbouring list)
RL Reconfiguration Prepare (E-DPCH information)
RB Reconfiguration Complete
Primary cell change
RL Reconfiguration Prepare (E-
DCH MAC-d flow to Delete)
RL Reconfiguration Commit (Activation CFN)
Activation CFN
RL Reconfiguration Commit
(Activation CFN)
Figure 2: E-DCH link is deleted and re-established on new Primary Cell (nominal case)

3.3.2 E-DCH MOBILITY WITHOUT MACRO-DIVERSITY (32076
NOT ACTIVATED)
E-DCH Macro Diversity is supported from UA6 via UA6 Macro Diversity Support
(32076) feature (see 3.3.3). This means that, if this feature is not activated, the E-DCH
active set (AS) will never include more than one cell, and in other words that there is
only one E-DCH radio link (RL) established between UE and RAN.
The main characteristics of E-DCH mobility (without macro-diversity) are listed here
below:
The E-DCH active set (AS) includes only 1 cell, i.e. the E-DCH serving cell.
As of 3GPP, the E-DCH serving cell is the same as the HSDPA serving cell. As of
Alcatel-Lucent implementation, the E-DCH serving cell always follows that of the
primary cell.
Softer HO partially supported:
For a given UE, the E-DCH serving NodeB combines all the E-DCH signals
received on the cells in the DCH AS of this NodeB, by Maximum Ratio Combining
(MRC) method.
Volume 6 : Mobility
Page 13/52
E-DCH mobility supported via Hard Hand-Over (HHO):
In case of Primary Cell change, the E-DCH radio link is re-established on the new
Primary Cell via Synchronous RL Reconfiguration (SRLR).
Inter NodeB E-DCH mobility issue when 32076 is not activated :
The uplink Inner-Loop Power Control (UL ILPC) is controlled by the cell with the
best UL path loss, which in some cases might not be the same as the E-DCH
serving cell (i.e. the Primary Cell). Hence, just before Primary Cell change, UL
ILPC may be controlled by the target cell. In this case, UE Tx power is driven
down by the target cell, which leads the UL SIR at current serving NodeB (i.e.
source NodeB) to become too low for E-DPDCH decoding. This results in HARQ
retransmissions on E-DCH and thus E-DCH user throughput degradation.
Since UA6, inter NodeB E-DCH mobility is performed smoothly thanks to UA6
32076 E-DCH Macro Diversity Support feature, which allows decoding E-
DPDCH simultaneously at source NodeB and target NodeB.

3.3.3 E-DCH MACRO DIVERSITY SUPPORT (32076)
3.3.3.1 FEATURE DESCRIPTION
3.3.3.1.1 FEATURE AIM AND PRINCIPLE
Since UA6, the capability of the UTRAN to handle multiple E-DCH radio links
simultaneously for a given UE, i.e. full support of E-DCH softer HO and SHO is
introduced via 32076 E-DCH Macro Diversity Support feature. This feature allows
improving E-DCH user throughput when UE is in inter NodeB SHO condition, by
decoding E-DCH simultaneously on multiple NodeBs and performing frame selection
at RNC. In addition, this feature allows always guaranteeing acceptable radio
conditions for E-DCH serving radio links, by managing the UL noise rise (i.e. UL
interference) generated by E-DCH non-serving
1
radio links.
The main characteristics of 32076 are as follows.
For a given E-DCH call, multiple E-DCH radio links can be decoded
simultaneously by multiple NodeBs.
E-DCH active set:
o For a given E-DCH call, the E-DCH AS is the set of cells for which an
E-DCH radio link is configured
o The E-DCH AS is updated according to DL radio conditions
o The E-DCH AS is included in the DCH AS
For each NodeB involved in the E-DCH call, the E-DCH signals received from a
given UE are combined via Maximum Ratio Combining (MRC) method before

1
For an E-DCH call, E-DCH non-serving radio links designate the E-DCH radio links established on cells
other than the Primary Cell. E-DCH non-serving radio-links may belong either to the same NodeB as the one of
the Primary Cell (serving NodeB) or to other NodeB (non-serving NodeB).
Volume 6 : Mobility
being processed. The combined signals are all the E-DCH signals received on the
cells in the DCH AS of this NodeB.
At a given time, the same RG command and same ACK/NACK information is
transmitted to the UE on all the cells in the E-DCH AS of the E-DCH serving
NodeB.
Iub E-DCH Data Frame selection at RNC:
For a given CFN, multiple Iub E-DCH Data Frames may be received at RNC from
different NodeBs. The first correctly received Data Frame is selected, the others
are discarded.
Management of UL noise rise generated by E-DCH non-serving RLs:
o For each E-DCH cell, the UL noise rise generated by E-DCH non-
serving radio links is monitored
o If the UL noise rise from E-DCH non-serving radio links is too high,
Down RG is sent to non-serving UEs

E-DCH macro diversity general principle is summarized in below figure.
E-DCH serving radio link
E-DCH non-serving RL of serving NodeB
E-DCH non-serving RL
of non-serving NodeB
Cell of E-DCH active set (and of DCH AS)
Cell of DCH AS (but not in E-DCH AS)
E-DCH serving NodeB:
NodeB that includes the E-DCH serving cell
E-DCH serving cell:
Cell that includes the E-DCH serving RL
(i.e. the cell with E-AGCH configured)
E-DCH serving cell = Primary Cell
(ALU impl.)
E-AGCH is transmitted only on the
E-DCH serving cell (3GPP)
All E-DCH signals received from UE are
MRC combined before being processed.
E-RGCH, E-HICH:
Same RG command and same ACK/NACK
information is transmitted to UE on all
cells of the serving NodeB in E-DCH AS.
E-DCH non-
serving NodeB(s):
E-DCH non-serving
NodeB:
NodeB that does not
include the E-DCH
serving cell
All E-DCH signals
received from UE are
MRC combined before
being processed.
E-HICH:
Same E-HICH
information is
transmitted to UE on all
cells of the considered
non-serving
NodeB included in
E-DCH AS.
Only ACK E-HICH
is allowed.
E-RGCH:
Only Down RG
is allowed.
RNC:
Iub E-DCH Data Frame selection:
For a given CFN, multiple E-DCH Data Frames may be
received from different NodeBs. First correctly received
Data Frame is selected, others are discarded.
MAC-es PDU reordering:
MAC-es PDUs may arrive at RNC out of order, due to
possible MAC-e PDU loss on a given HARQ process, and/or
due to E-DCH Macro Diversity.
Iub
Iub
E-DCH
serving
cell
E-DCH serving radio link
E-DCH non-serving RL of serving NodeB
E-DCH non-serving RL
of non-serving NodeB
Cell of E-DCH active set (and of DCH AS)
Cell of DCH AS (but not in E-DCH AS)
NodeB that includes the E-DCH serving cell
E-DCH serving cell:
Cell that includes the E-DCH serving RL
(i.e. the cell with E-AGCH configured)
E-DCH serving cell = Primary Cell
(ALU impl.)
E-AGCH is transmitted only on the
E-DCH serving cell (3GPP)
All E-DCH signals received from UE are
MRC combined before being processed.
E-RGCH, E-HICH:
Same RG command and same ACK/NACK
information is transmitted to UE on all
cells of the serving NodeB in E-DCH AS.
E-DCH non-
serving NodeB(s):
E-DCH non-serving
NodeB:
NodeB that does not
include the E-DCH
serving cell
All E-DCH signals
received from UE are
MRC combined before
being processed.
E-HICH:
Same E-HICH
information is
transmitted to UE on all
cells of the considered
non-serving
NodeB included in
E-DCH AS.
Only ACK E-HICH
is allowed.
E-RGCH:
Only Down RG
is allowed.
RNC:
RNC:
Iub
Iub
E-DCH
serving
cell

Figure 3: E-DCH macro diversity general principle

Page 14/52
Volume 6 : Mobility
Page 15/52
3.3.3.1.2 E-DCH ACTIVE SET MANAGEMENT
The E-DCH active set is managed as follows.
The E-DCH active set may include multiple cells; the E-DCH AS is included in the
DCH AS, and may include up to 4 cells (as of 3GPP)
At E-DCH radio bearer establishment, the E-DCH AS is created and includes only
1 cell: the E-DCH serving cell, i.e. the Primary Cell (Alcatel-Lucent
implementation)
From E-DCH RB establishment, any cell added to the DCH AS is added to the E-
DCH AS as well, provided that the following conditions are fulfilled.
o E-DCH AS is still not full
o The cell to be added supports the current {E-DCH TTI, E-DPDCH minimum
SF, E-DCH HARQ type}configuration of the considered E-DCH call.
All cells removed from the DCH AS and present in the E-DCH AS are also
removed from the E-DCH AS
Event 1J (specific to E-DCH macro diversity):
Definition: The CPICH of a cell that is in DCH AS but not in E-DCH AS (cell B)
becomes better than the CPICH of a cell that is already in E-DCH AS (cell A).
Action triggered: CellA is removed from the E-DCH AS and replaced by cell B
(provided that cell B supports current {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ
type}configuration).
Remark: Event 1J is only configured when the Full-Event Triggered reporting of
measurements mode is used for intra-frequency mobility.
In the Alcatel-Lucent implementation, an Event 1J for Primary Cell replacement is
ignored by the RNC. Indeed, if a cell becomes better than the Primary Cell, an Event
1D (Primary Cell change) will be generated as well: the priority is given to this Event
1D because it may trigger some reconfiguration such as switch from EDCH to DCH
(depending on the new Primary Cell capability), and the processing of the Event 1J
would have been wasteful in this case.
Primary cell change:
When the Primary Cell changes, the E-DCH serving cell is changed to the new
Primary Cell.
o If the new Primary Cell does not support current {E-DCH TTI, E-DPDCH min
SF, E-DCH HARQ type}configuration:
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}configuration
is changed to match E-DCH capabilities of the new Primary Cell.
If {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}
configuration is changed to a more restrictive one (e.g. 10ms TTI
2ms TTI), any cell of the E-DCH AS not supporting this new
configuration is removed from the E-DCH AS.
Volume 6 : Mobility
Page 16/52
A change in the TTI or HARQ type will result in RNC requesting
MAC-e reset, whereby all HARQ data will be flushed leading to
possible RLC re-transmissions
o If the new Primary Cell does not support E-DCH, the E-DCH RB is
reconfigured to UL DCH.

3.3.3.1.3 E-DCH CALL ATTRIBUTES MANAGEMENT
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type} configuration:
For a given E-DCH call, {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}
configuration is common to all E-DCH radio links.
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}configuration is determined
by RNC at the beginning of the E-DCH call, basing on UE and E-DCH serving
NodeB capabilities.
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}configuration must always
match the E-DCH serving cell (i.e. the Primary Cell) capabilities. Consequently, at
Primary Cell change, {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}
configuration is changed to match E-DCH capabilities of the new Primary Cell (if
E-DCH capabilities changed).
{Reference E-TFCI; Reference Power Offset} table:
For a given E-DCH call, the {Ref E-TFCI; Ref PO}table is common to all the E-
DCH radio links.
The {Ref E-TFCI; Ref PO}table is selected by RNC at the beginning of the E-DCH
call, and updated at Primary Cell change, basing on the following attributes of the
call:
o E-DCH TTI (10ms or 2ms)
o E-DPDCH min SF (i.e. highest E-DPDCH SF configuration available for
the E-DCH call, e.g. 2xSF2)
o UL service (e.g. E-DCH stand-alone)

iCEM/xCEM specificities:
[iCEM] [xCEM] For the iBTS, iCEM and xCEM capabilities are different regarding E-
DCH TTI and E-DPDCH min SF. This means that for a given UE moving in a network
with iCEM and xCEM boards handling E-DCH, the E-DCH call attributes depend on
the type of board of the E-DCH serving cell.
Example:
UE: HSUPA Category 5, IR E-DCH HARQ type supported:
iCEM handling E-DCH on E-DCH serving cell:
{10ms TTI, 2xSF4, IR},
{Ref E-TFCI; Ref PO}table of EdpchParameters/UECategory3EdchTti10ms
Volume 6 : Mobility
Page 17/52
xCEM handling E-DCH on E-DCH serving cell:
{10ms TTI, 2xSF2, IR},
{Ref E-TFCI; Ref PO}table of EdpchParameters/UECategory5EdchTti10ms
For more information on the {Ref E-TFCI; Ref PO}table selection mechanism, please
refer to [Vol. 4], section 5.4, {REF E-TFCI; REF PO} TABLE SELECTION
MECHANISM.
[UCU-III] For the OneBTS, all the cells in the network have the same E-DCH
capabilities. Hence, the E-DCH call attributes only depend on the HSUPA UE
Category and do not change during the call unless there is a mixed deployment of
2ms and 10ms TTIs (from UA7.1 UCU-III supports both the 2 ms and 10 ms TTIs).

3.3.3.1.4 E-DCH NON-SERVING RADIO LINKS MANAGEMENT
Decoding of E-DCH non-serving RLs of serving NodeB:
All the E-DCH signals received from the UE are MRC combined before being processed.
Decoding of E-DCH non-serving RLs of non-serving NodeB(s):
[iCEM]
An E-DCH non-serving radio link is decoded only if there is a free Modem/CRCP (i.e.
Modem/CRCP not handling any E-DCH radio link yet), on iCEM E-BBU.
[xCEM] [UCU-III] Basically, E-DCH non-serving radio links are always decoded.
If the board decoding capacity is reached due to high E-DCH traffic:
1/ Decoding of E-DCH non-serving radio links is stopped (MAC-e PDU discard)
2/ If the number of discarded MAC-e PDUs exceeds a certain threshold, a CE
Overload indication is sent to the MAC-e scheduler. This results in a reduction of the
target E-DCH load and thus Down RG commands sent to the E-DCH UEs.
In UA6, the board decoding capacity at MAC-e level is 7.7Mbps for xCEM and 4Mbps
for UCU-III. In UA7, it is improved up to 10Mbps for both xCEM and UCU-III (feature
34633).

Management of UL noise rise generated by E-DCH non-serving RLs:
A cell may host simultaneously the E-DCH serving RL for one (or more) E-DCH user(s)
and the E-DCH non-serving RL for other E-DCH users (referred to as non-serving UEs).
The UL noise rise generated by the non-serving UEs is monitored and controlled in order
to give preference to the serving UEs.
According to the measured ratio of E-DCH Rx power from non-serving radio links to total
E-DCH Rx power, Down RG commands may be sent from this cell to non-serving UEs,
in order to always guarantee acceptable radio conditions for E-DCH serving radio links.
From a cell perspective, the non-serving UE concept refers to two different situations:
either the E-DCH serving RL of this UE belongs to another NodeB, or the E-DCH serving
RL belongs to the same NodeB. In this latter case, the UE is designated as non-serving
peer UE.
Volume 6 : Mobility
[iCEM]
Total
Serving Non
Power Rx DCH E
Power Rx DCH E
>targetNonServingToTotalEDCHPowerRatio If

With
E DCH Rx Power
Non Serving
: E-DCH power received at NodeB antenna of the
considered cell from non-serving radio links (of both non-serving UEs and
non-serving peer UEs).
E DCH Rx Power
Total
: Total E-DCH power received at NodeB antenna of the
considered cell from all radio links (serving and non-serving).
Then Down RG commands are sent from this cell to non-serving UEs:
o Common RG are used for UEs for which this cell is not under the serving
NodeB
o Dedicated RG are used for UEs for which this cell is under the serving
NodeB (non-serving peer UEs)

[xCEM] [UCU-III]
Total
NodeB Serving Non of RLs Serving Non
Power Rx DCH E
Power Rx DCH E
If >
targetNonServingToTotalEDCHPowerRatio

With
E DCH Rx Power
Non Serving RLs of Non Serving NodeB
: E-DCH power received at
NodeB antenna of the considered cell from non-serving radio links (the RL of
non-serving peer UEs are not considered here).
Then common Down RG commands are sent from this cell to non-serving UEs (the
non-serving peer UEs are not considered here)

If
Total
NodeB Serving of RLs Serving Non
Power Rx DCH E
Power Rx DCH E
>edchSofterHoLimit
With
E DCH Rx Power
Non Serving RLs of Serving NodeB
: E-DCH power received at NodeB
antenna of the considered cell from non-serving radio links (only the RL of the
non-serving peer UEs are considered here).
Then dedicated Down RG commands are sent from this cell to non-serving peer
UEs.

Page 18/52
Volume 6 : Mobility
3.3.3.2.1 FEATURE ACTIVATION
UA6 32076 E-DCH Macro Diversity Support is activated by setting the maximum E-DCH
active set size to a value higher than 1, via maxNumberOfRlEdch parameter under
EdchRncConf object.
Remark:
maxNumberOfRlEdch parameter granularity is RNC, which means that 32076 can be
activated/deactivated at RNC level (cannot be activated/deactivated per cluster of cells).

3.3.3.2.2 RAN MODEL
Below figure shows the RAN model (i.e. parameters and objects tree) at OMC-R.
RNC
RadioAccessService
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1J Allowed
DedicatedConf
MeasurementConfClass
FullEventRepCritShoMgtEvent1J
amountRep1J
maxNbReportedCells1J
repActThresh1J
repInterval1J
FullEventHoConfShoMgtEvent1J
HoConfClass
FullEventHoConfShoMgt
hysteresis1J
timeToTrigger1J
NodeB
FDDCell
targetNonServingToTotalEdchPowerRatio
15 15
UsHoConf/
PsHSDPA
CsSpeechPlusHSDPA
FullEventRepCritShoMgt
Number
of
instances
(indicated
when > 1)
EdchRncConf
maxNumberOfRlEdch
OMC-R
NodeBConfClass
15
iubEdchDelayVariation

Figure 4: OMC-R RAN model for 32076

[xCEM] [UCU-III]
Below figure shows the RAN model at OMC-B.
Page 19/52
Volume 6 : Mobility
Remark: All below parameters only apply to xCEM or UCU-III (i.e. not used by iCEM).
OMC-B
BTSEquipment
BTSCell
EdchConf
edchSofterHoLimit
nonServingEHICHPowerOffset
edchNumCommonRgPerCode
OneBTSEquipment
eDCHSofterHOLimit
eDCHNumCommonRGPerCode
Figure 5: OMC-B RAN model for 32076

3.3.3.2.3 OMC-R PARAMETERS
isEdchRlAddOrSetupDefenseAllowed: Flag enabling to try to add a given cell in
DCH AS just after failing to add this cell in DCH AS and E-DCH AS simultaneously.
Parameter isEdchRlAddOrSetupDefenseAllowed
Granularity RNC
Value True

isRrcEdchEvent1JAllowed: Flag enabling the configuration of Event 1J , when Full-
Event Triggered reporting of measurements mode is used for intra-frequency mobility.
Parameter isRrcEdchEvent1JAllowed
Granularity RNC
Value True

targetNonServingToTotalEdchPowerRatio:
[iCEM] (E-DCH handled by iCEM on considered cell):
Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna of considered cell)
from non-serving RLs] to [total E-DCH Rx power].
[xCEM] [UCU-III] (E-DCH handled by xCEM or UCU-III on considered cell):
Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna of considered cell)
from non-serving RLs of non-serving NodeB(s)] to [total E-DCH Rx power].
Page 20/52
Volume 6 : Mobility
Page 21/52
Parameter targetNonServingToTotalEdchPowerRatio
Object FDDCell
Granularity FDDCell
Value 25

maxNumberOfRlEdch: Maximum E-DCH active set size (i.e. maximum number of E-
DCH RLs allowed per UE). Used to activate/deactivate 32076 E-DCH Macro Diversity
Support (maxNumberOfRlEdch =1: feature deactivated).
Parameter maxNumberOfRlEdch
Object EdchRncConf
Granularity RNC
Value 4

iubEdchDelayVariation: Delay on Iub for MAC-es re-ordering function in RNC. Same
value (in number of E-DCH TTIs) applies for both 10ms and 2ms E-DCH TTI.
Parameter iubEdchDelayVariation
Object NodeBConfClass
Granularity NodeBConfClass
Range & Unit Integer [1 255], Number of E-DCH TTIs
[UCU-III] 3

hysteresis1J: Hysteresis used when detecting Event 1J .
Parameter hysteresis1J
Object FullEventHoConfShoMgtEvent1J
Granularity HoConfClass, UsHoConf
Range & Unit Decimal [0.0 7.5] step 0.5, dB
Value 3.0

timeToTrigger1J: Duration for which Event 1J condition must be satisfied before
triggering the transmission of a Measurement Report.
Volume 6 : Mobility
Page 22/52
Parameter timeToTrigger1J
Object FullEventHoConfShoMgtEvent1J
Granularity HoConfClass, UsHoConf
Range & Unit Enum {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,
5000}, ms
Value 100

amountRep1J: Amount of periodical reports, after an Event 1J Measurement Report
has been triggered.
Parameter amountRep1J
Object FullEventRepCritShoMgtEvent1J
Range & Unit Enum {1, 2, 4, 8, 16, 32, 64, Infinity}, N/A
Value Infinity

maxNbReportedCells1J: Maximum number of reported cells for Event 1J
Measurement Report.
Parameter maxNbReportedCells1J
[UCU-III] 6

repActThresh1J: Minimum number of cells in E-DCH AS in order for Event 1J to be
detected.
Parameter repActThresh1J
Value 2

repInterval1J: Interval between two periodical reports, after an Event 1J
Measurement Report has been triggered.
Volume 6 : Mobility
Page 23/52
Parameter repInterval1J
Range & Unit Enum {0, 250, 500, 1000, 2000, 4000, 8000, 16000}, ms
Value 500

3.3.3.2.4 OMC-B PARAMETERS
[xCEM] [UCU-III]
edchSofterHoLimit: Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna
of considered cell) from non-serving RLs of serving NodeB] to [total E-DCH Rx power].
Parameter [xCEM] edchSofterHoLimit
[UCU-III] eDCHSofterHOLimit
Object [xCEM] EdchConf
[UCU-III] OneBTSEquipment
Granularity [xCEM] BTSCell
Value 40

[xCEM] nonServingEHICHPowerOffset: For E-DCH RLs of non-serving NodeB, with
fixed E-HICH power mode (i.e. different boards handling HSPA and R99), power
offset of E-HICH signature relative to CPICH Tx power.
Parameter nonServingEHICHPowerOffset
Object EdchConf
Granularity BTSCell
Value 0.0

edchNumCommonRgPerCode: Number of signatures per E-RGCH/E-HICH channel
reserved for common RG commands.
Volume 6 : Mobility
Page 24/52
Parameter [xCEM] edchNumCommonRgPerCode
[UCU-III] eDCHNumCommonRGPerCode
Value 1

commonERGCHPowerOffset: For E-DCH RLs of non-serving NodeB(s), power
offset of E-RGCH signature relative to CPICH Tx power.
Remark: For non-serving NodeB, only common RG commands are used.
Parameter commonERGCHPowerOffset
Value 0.0

3.4 FULL EVENT SHO SETTING FOR HSXPA
As presented in details in UPUG Vol. 12, [R01], mobility setting is now defined per
mobilityServiceType:
UA5-UA6 Delta: UsHoConf is now defined per mobilityServiceType
Before UA6, UsHoConf used to be defined per DlUserService, i.e. one mobility profile could be
defined for each RAB.
From UA6, in order to ease the setting, UsHoConf is now defined per mobilityServiceType, a
parameter allowing several DlUserServices to be assigned to the same mobility setting.

mobilityServiceType: this parameter defines the mobility service type that
matches with each DlUserService. It is used as UsHoConf index id. The ones
related to HSDPA are underlined.
Volume 6 : Mobility
Page 25/52

Previous ETP (Engineering Test Plan) leads to specific SHO setting for standalone
HSDPA UsHoConf (with respect to DCH recommendation depicted in UPUG Vol. 12,
[R01]).
cpichEcNoReportingRange1A = 3.5 dB
cpichEcNoReportingRange1B = 5.5 dB
hysteresis1D = 6dB (i.e. 3 dB delta between both P-CPICH Ec/No)
timeToTrigger1D = 1280 ms

The following rule has applied since UA5 regarding HSDPA multi-service UsHoConfs:
Rule: SHO setting for HSDPA multi-service UsHoConfs
A specific rule must be defined for the SHO settings of the HSDPA multi-service UsHoConfs:
Applicable to reportingRange 1A, 1B, 1E and 1F
DCH setting shall be applied to HSDPA multi-service UsHoConfs

The following table summarizes the recommended parameters set, when Full Event
for SHO is used (refer to UPUG Vol. 12, [R01], for the exhaustive list of value per
mobilityServiceType).
Parameter mobilityServiceType Object DlUserService
Range & Unit Enum
{Signalling, CsSpeech, CsSpeechPlusHSDPA, CsSpeechPlusPsIbLowBR,
CsSpeechPlusPsIbHighBR, CsSpeechPlusPsStrLowBR,
CsSpeechPlusPsStrHighBR, CsStreaming, CsConversational,
CsConversationalPlusPsIbLowBR, CsConversationalPlusPsIbHighBR,
CsConversationalPlusHSDPA, PsHSDPA, PsIbLowBR, PsIbHighBR,
PsIbLowBRPlusHSDPA, PsStrLowBR, PsStrHighBR,
PsStrLowBRPlusHSDPA, PsStrHighBRPlusHSDPA}
User Customer
Class 3
Granularity RadioAccessService
Value Refer to UPUG Vol. 12, [R01], for the exhaustive mapping of DlUserService
and mobilityServiceType.
Volume 6 : Mobility
Page 26/52
mobilityServiceType
E
v
e
n
t

Parameter Object
PsHSDPA
Others with
HSDPA
cpichEcNoReportingRange1A
3.5 dB 4.5 dB 1A
timeToTrigger1A
FullEventHOConfShoMgtEvent1A
200 ms
cpichEcNoReportingRange1B
5.5 dB 7.5 dB 1B
timeToTrigger1B
FullEventHOConfShoMgtEvent1B
1280 ms
hysteresis1C 7.5 dB 1C
timeToTrigger1C
FullEventHOConfShoMgtEvent1C
320 ms
hysteresis1D 6 dB 6 dB
timeToTrigger1D 1280 ms 640 ms
1D
useCioFor1D
FullEventHOConfShoMgtEvent1D
False
isEvent1EUsed FullEventHOConfShoMgt False
cpichEcNoThresholdUsedFreq1E -11 dB (N.S.)
1E
timeToTrigger1E
FullEventHOConfShoMgtEvent1E
100 ms (N.S.)
isEvent1FUsed FullEventHOConfShoMgt True
cpichEcNoThresholdUsedFreq1F -15 dB
1F
timeToTrigger1F
FullEventHOConfShoMgtEvent1F
640 ms
Table 1: SHO Event Recommended Settings Summary

3.5 INTRA-FREQUENCY MOBILITY OVER IUR
3.5.1 HSDPA OVER IUR
HSDPA over Iur capability is required in both SRNC and DRNC to allow the handling
of the configuration, maintenance and release of active HSDPA calls over Iur. In
HSDPA mode, the SRNC configures one radio link to the UE with HS-DSCH specific
information.
As a SRNC:
o The decision to configure an existing RL over Iur with HSDPA is taken
when the primary cell selection results with a cell belonging to a
neighbouring RNC. The request is sent to the neighbouring RNC using a
RNSAP Radio Link Reconfiguration Prepare message with HS-DSCH
information. The UE is configured accordingly.

Volume 6 : Mobility
Page 27/52
As a DRNC:
o In an Alcatel-Lucent - Alcatel-Lucent case, an existing radio link is
configured to HSDPA when the DRNC receives a RNSAP Radio Link
Reconfiguration Prepare message with HS-DSCH IEs.
o In a non Alcatel-Lucent - Alcatel-Lucent case, an HSDPA configuration
occurs when the DRNC receives a RNSAP Radio Link Setup Request or
a Radio Link Reconfiguration Prepare message with HS-DSCH IEs.

From UA5.1, HSDPA over Iur has been fully supported with a correct management of
Iub congestion taking into account HSDPA traffic coming from Iur. Refer to [R07] for
further details on Iub congestion management.
Restriction: HSDPA over Iur with non Alcatel-Lucent RNC
HSDPA over Iur is not guaranteed when facing non Alcatel-Lucent RNC (for details refer to [R02]).
Therefore, in such cases, on Alcatel-Lucent serving RNC, the neighbour RNC should be provisioned
as non HSDPA capable, unless successful IOT has been performed with the other vendor.

Starting from the release UA7.0, MAC-ehs (enhanced MAC-hs) may be used for the
call (refer to the description of the feature 34388 in the Volume 3 for more details).
However, MAC-ehs is not supported over IUR: in case of HSDPA mobility over IUR, if
the RB was using MAC-ehs, the RB is reconfigured to MAC-hs.
In the case of SRNS relocation - UE not involved (Inter RNC mobility with IUR), the
RB remains configured with MAC-hs, regardless of the MAC-ehs capability of the
target cell. It may be reconfigured to MAC-ehs at the next inter-nodeB mobility
occasion towards a MAC-ehs capable cell.
In the case of SRNS relocation - UE involved (Inter RNC mobility without IUR), the RB
is configured accordingly to the MAC-ehs capability of the target cell.

3.5.2 HSUPA OVER IUR
From UA6.0, HSUPA over Iur is supported with the introduction of the feature 30744
(feature only available for Global Market). HSUPA over Iur capability is required in
both SRNC and DRNC to allow the handling of the configuration, maintenance and
release of active HSUPA calls over Iur.
If the HSUPA over Iur is not supported or deactivated on SRNC or DRNC, the system
will behave similarly as in UA5: While HSUPA running, if the primary cell goes under
the control of a DRNC then the SRNC will consider that the new primary is not E-DCH
capable and, as such, will perform an UL Transport Channel type switching to DCH
whereas DL HS-DSCH is properly reconfigured over Iur (in case HSDPA over Iur is
provisioned); In UA6 if E-DCH over IuR is not supported then no non-serving (non-
primary) E-DCH link will be established over IuR.
Volume 6 : Mobility
Page 28/52
When HSUPA over Iur is supported and activated on both SRNC and DRNC, the
mobility between serving cells (under SRNC) and drift cells (under DRNC) is handled
by the SRNC, in the same way as intra RNC edch mobility, based on the primary cell
edch capabilities and the target drift cell edch capabilities in terms of
Edch support
TTI capabilities (2ms or 10ms)
Min SF capabilities
Note that the edch capabilities for drift cells that are declared as neighbours to the
border serving cells (i.e. known by the SRNC) are configured under RemoteFddCell.
When the Iur is well dimensioned, its recommended to set the edch capabilities,
under remoteFddCell object, in line with the real cell capabilities otherwise, we can
use these parameters to downgrade the drift cell capabilities in order to limit the edch
traffic over Iur or to deactivate completely the edch over Iur toward some specific drift
cells. We can for example limit the edch over Iur to CAT3 by setting the TTI
capabilities to 10ms and Min SF capabilities to 2SF4 even if the drift cell is 2ms
capable and supporting 2SF2+2SF4.
In case of HSUPA over Iur, the DRNC is responsible for the Iub edch bandwidth
limitation management for the drift BTS
The DRNC detects the edch congestion based on edch frame loss as
described in HPUG volume 4.
The DRNC discard the TNL congestion messages received from the SRNC.

Restriction:
In UA6.0, the Iur edch bandwidth limitation is not supported thats why its highly
recommended to activate the SRNS relocation in case of limited Iur capacity so that the Iur
resources will be released as soon as the call moves completely to the DRNC.
Also, E-DCH to E-DCH inter-freq mobility over Iur cases is not supported. UE involved
relocation is triggered by the SRNC instead of inter-freq mobility over Iur.
Finally, PM30744 does not support SRB over E-DCH, a fallback on DCH applies in uplink for
SRB, in case drift RNC controls the primary cell

PARAMETERS:
isHsdpaOverIurAsSrncAllowed: This parameter allows RNC to
enable/disable HSDPA over Iur when acting as a Serving RNC.
Parameter isHsdpaOverIurAsSrncAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

Volume 6 : Mobility
Page 29/52
isEdchOverIurSrncAllowed: This parameter allows RNC to enable/disable
HSUPA over Iur when acting as a Serving RNC.
Parameter isEdchOverIurSrncAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

isHsdpaOverIurAsDrncAllowed: This parameter allows RNC to
accept/reject HSDPA reconfiguration over Iur when acting as a Drift RNC.
Parameter isHsdpaOverIurAsDrncAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

isEdchOverIurDrncAllowed: This parameter allows RNC to accept/reject
HSUPA reconfiguration over Iur when acting as a Drift RNC.
Parameter isEdchOverIurDrncAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

isMacShHsdpaAllowed: this parameter activates the creation of a MAC-hs
entity on a drift RNC when supporting PS RAB over Iur. It is recommended to
set it to True on each RNC that is supposed to act as DRNC for HSDPA RAB.
When set to False, the behaviour is the same as UA5.0.
Parameter isMacShHsdpaAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value True

Rule: isMacShHsdpaAllowed=True when isHsdpaOverIurAsDrncAllowed=True
In case isHsdpaOverIurAsDrncAllowed is set to True, the parameter isMacShHsdpaAllowed under
RadioAccessService must also be set to True so as to have Iub bandwidth limitation processing
HSDPA traffic over Iur, cf. [R07].

Volume 6 : Mobility
Page 30/52
isHsdpaAllowed: This parameter under NeighbouringRNC defines the
HSDPA capabilities of neighbouring RNC to which Iur link is provisioned.
Parameter isHsdpaAllowed Object NeighbouringRNC
{True, False}
User Customer
Class 3
Granularity RNC
Value True

isEdchAllowed: This parameter under NeighbouringRNC defines the
HSUPA capabilities of neighbouring RNC to which Iur link is provisioned.
Parameter isEdchAllowed Object NeighbouringRNC
{True, False}
User Customer
Class 3
Granularity RNC
Value True

isHsdpaAllowed: This parameter under RemoteFddCell defines the HSDPA
capabilities of an UMTS neighbouring cell belonging to another RNC..
Parameter isHsdpaAllowed Object RemoteFddCell
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value True
See also the following rule.

EdchMinSfCapabilities: This parameter under RemoteFddCell defines the
HSUPA capabilities of an UMTS neighbouring cell belonging to another RNC.
Parameter edchMinSfCapabilities Object RemoteFddCell
Range & Unit
Sf8, sf4, 2sf4, 2sf2, 2sf2and2sf4
User Customer
Class 3
Granularity Cell
Value Depends on remote cell capabilities. Default value: 2sf4.

isEdchAllowed: This parameter under RemoteFddCell defines the HSUPA
capabilities of an UMTS neighbouring cell belonging to another RNC.
Parameter isEdchAllowed Object RemoteFddCell
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value True
See also the following rule.

Volume 6 : Mobility
Page 31/52
isEdchTti2msAllowed: This parameter under RemoteFddCell defines the
HSUPA capabilities of an UMTS neighbouring cell belonging to another RNC.
Parameter isEdchTti2msAllowed Object RemoteFddCell
Range & Unit
False, True
User Customer
Class 3
Granularity Cell
Value Depends on remote cell capabilities. True.

When a cell belonging to a DRNC is added in the active set, it sends to the SRNC its
neighbourhood in RNSAP RadioLinkAdditionResponse or RadioLinkSetupResponse
messages, together with primary scrambling code and HSxPA capabilities using HS-DSCH
Support and edch Support Indicator.
Such indicator allows SRNC to learn the capability of a cell that does NOT belong to
SRNC; it also allows SRNC to update the capability of a cell depending on its real status
(HSxPA activated or not) and depending on what is provisioned on DRNC.

3.5.2.1 IUR COMPLIANCE: CORRECTION OF THE CONDITION OF UL
DPDCH INDICATOR FOR E-DCH OPERATION
in UA7.0 a new parameter, Reserved0 under NeighbouringRNC, is introduced to
allow 3GPP [R04] Rel-7 CR1357 Iur compliance.
Parameter Reserved0 Object NeighbouringRNC
Range & Unit [0..2147483647], decimal
User Customer
Class 3
Granularity RNC
Value See engineering recommendation below

This parameter has to be set carefully in order to avoid Iur IOT issues with other
vendors RNCs and also to not block the RNSAP RL setup for unidirectional DL DCH
only case.

UA7.0-UA7.1 Delta: reserved0 change of name
In UA7.1, the UA7.0 the parameter reserved0, located under NeighbouringRNC, will change the
name to isRnsapCr1357Supported (also located under NeighbouringRNC). The settings used by
reserved0, 0 or 1, will be now treated by this new parameter as False or True, respectively.

Parameter isRnsapCr1357Supported Object NeighbouringRNC
User Customer
Class 3
Granularity RNC

In 3GPP [R04] Rel-6, RNSAP RADIO LINK SETUP REQUEST message, the UL
DPDCH Indicator for E-DCH Operation IE with the condition of C-EDCHInfo shall be
present when E-DPCH Information IE is present.
Volume 6 : Mobility
Page 32/52
In 3GPP [R04] Rel-7 CR1357, the UL DPDCH Indicator for E-DCH Operation IE can
be present without the presence of E-DPCH Information IE (since UL DPDCH
Indicator for E-DCH Operation IE is the only IE in NBAP RADIO LINK SETUP
REQUEST to indicate if UL DPDCH should be present).
For UA6 DRNC or other vendors RNC which support only 3GPP [R04] Rel-6 baseline,
when receiving a RNSAP RADIO LINK SETUP REQUEST message including UL
DPDCH Indicator for E-DCH Operation IE, but without E-DPCH Information IE (e.g.
unidirectional DCH only case), UA6 DRNC should reply RNSAP RADIO LINK SETUP
FAILURE since it is compliant to 3GPP [R04] Rel-6 Spec.

For a DRNC UA7.0, receiving a RNSAP message compliant with 3GPP [R04] Rel-7
CR1357, the DRNC shall overwrite the NBAP message to be sent in order to follow
UA06 Iub behaviour (since 3GPP [R05] Rel-7 CR1462 is not support in UA7.0, but it
will be supported in UA7.1).

Engineering Recommendation: New parameters introduced in UA7.0/UA7.1 concerning the
RNSAP messages
For SRNC UA7.0/UA7.1:
If DRNC is Rel-6 (or earlier), reserved0 / isRnsapCr1357Supported =0 / False
If DRNC is Rel-7 (or latter), reserved0 / isRnsapCr1357Supported =1 / True (3GPP [R04]
Rel-7 CR1357 support)
If DRNC is Rel-7 (or latter), reserved0 / isRnsapCr1357Supported =0 / False (3GPP [R04]
Rel-7 CR1357 no support)

After UA7.1 introduction, Alcatel-Lucent UTRAN will fully support not only CR1357
[R04] but also CR1462 [R05]. Another parameter is then introduced:
Parameter isNbapCr1462Supported Object NodeB
User Customer
Class 3
Granularity BTS

If NodeB version is Rel-6 (or earlier), UL DPDCH Indicator for E-DCH Operation IE
shall be sent when E-DPCH Information IE is present (UA6 NodeB will apply this
Check rule)
If NodeB version is Rel-7 (or latter), UL DPDCH Indicator for E-DCH Operation IE can
be present without the presence of E-DPDCH information IE
Two new flags can then be set:
Engineering Recommendation: New parameter introduced in UA7.1 concerning the NBAP
messages
If NodeB is Rel-6 (or earlier), isNbapCr1462Supported =False
If NodeB is Rel-7 (or latter), isNbapCr1462Supported =True

[UCU-III] These compliances are also valid for the OneBTS.
Volume 6 : Mobility
Page 33/52
3.6 INTRA-FREQUENCY INTER-RNC HHO
This feature has been introduced in UA6 in order to allow intra-frequency mobility
between the source and the target RNC, when there is no operational Iur interface
between both of them. When this feature is enabled, handover is performed through
RANAP Relocation procedure, as for the well known 3G-3G HHO.

This intra-frequency mobility case applies to the following situations:
Iur is NOT provisioned between both RNCs (e.g. due to IOT reasons between
different manufacturers or during swap process)
Iur is provisioned between both RNCs but interface is momentarily down.

isHsdpaHhoWithMeasAllowed: when set to FALSE, no compressed mode is
activated for HSDPA (RNC does not take care of UE event reports for Inter
Frequency when the call is on HSDPA). From UA6, this parameter is used for
2 different purposes:
o When set to False, this parameter prevents any Intra-RNC HHO from
HSDPA, and only the 2 following transitions can then occur for DL
Transport Channel:
DCH to HSDPA
DCH to DCH
o When set to False, this parameter also prevents any Intra-frequency
Inter-RNC HHO from HSDPA.
Parameter isHsdpaHhoWithMeasAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value TRUE

isEdchHhoWithMeasAllowed: when set to FALSE, no compressed mode is
activated for HSDPA (RNC does not take care of UE event reports for Inter
Frequency when the call is on HSDPA). From UA6, this parameter is used for
2 different purposes:
o When set to False, this parameter prevents any Intra-RNC HHO from
E-DCH, and only the 2 following transitions can then occur for UL
Transport Channel:
DCH to E-DCH
DCH to DCH
o When set to False, this parameter also prevents any Intra-frequency
Inter-RNC HHO from E-DCH.
Volume 6 : Mobility
Page 34/52
Parameter isEdchHhoWithMeasAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value TRUE

isHsdpaHhoWithMeasAllowed and isEdchHhoWithMeasAllowed must be set to TRUE otherwise
KPI would be impacted and call drop may happen.

Refer to UPUG UA7, [R01], for complete details on the feature.

4 COMPRESSED MODE WHILE IN HSXPA
In this section, the term of D-BBU , H-BBU and E-BBU are used. These
terms are only applicable to iCEM meaning that each service (DCH, HSDPA, E-DCH)
is managed by a dedicated BBU. In case of xCEM/UCU-III board, all the services are
managed by the same M-BBU.
4.1 COMPRESSED MODE IN MAC-HS
The feature Compressed mode in MAC-hs consists in taking into account the
existence of the DL&UL compressed frames (i.e. both compressed slots and
transmission gaps) as un-scheduling criterion for the connected HSDPA user in CM
period. Thus, no data re-transmission or transmission is performed by the MAC-hs
scheduler for the UE in CM period during a UL&DL compressed frame. Any re-
transmission as well as transmission of data blocks during the transmission gaps is a
loss of scheduling efficiency while other active UE(s) are potentially eligible to the
MAC-hs scheduler. Informing the MAC-hs with the DL CM pattern to prevent any
waste of scheduling activity on these connected UE maximizes the packet scheduler
efficiency in focusing only on listening UE(s) (i.e. out of the transmission gaps).
The feature allows maximizing the cell HSDPA throughput avoiding in wasting MAC-
hs scheduling resources during compressed frames of connected HSDPA user.
The principle of the CM in MAC-hs can be divided into 3 parts:
Compressed mode configuration
Transmission gap patterns evaluation
Compressed frames management
Note that the first two parts are also applicable to HSUPA.
Volume 6 : Mobility
Restriction: Higher Layer Scheduling (HLS) method not supported with HS-DSCH or E-DCH
HLS has been introduced so that 2 different methods are now supported for the gap creation: SF/2
and HLS.
Note that for any DL configuration with an HS-DSCH or E-DCH, HLS CM method shall not apply.
Refer to [R01] for further details on CM measurements.

Note: isCmHlsAllowedWithEdch and isCmSfo2AllowedWithEdch under
EdchRncConf object have been present in RAN Model since UA5 but are still NOT
used for Compressed Mode purpose.

4.1.2 COMPRESSED MODE CONFIGURATION
The parameters of transmission gap patterns are given by the RNC via the
Transmission Gap Pattern Sequence Info (TGPSI) IE. It is provided either in the RL
Setup procedure (RadioLinkSetupRequest) or in the RL Reconfiguration procedure
(RadioLinkReconfigurationPrepare).
The activation of these patterns is performed via the Activation Pattern Sequence
Info (APSI) provided either in the RL Setup or in the commit message of an SRLR
procedure, or finally via the dedicated procedure Compressed Mode Command.

The configuration of the HS-DSCH for a UE may then occur before or after a single IE
or at the same time of both IEs. In all cases, they must be forwarded to the H-BBU.

As the APSI specifies only the activation CFN for the pattern, H-BBU has to be
informed on the current status of these patterns in order to avoid any ambiguity (in
case that activation CFN for the pattern already started when configuring the HSDPA
part). The additional needed information is:
Current CFN. It corresponds to the current CFN observed on the D-BBU
when reporting this CM status information.
CMCFN. It corresponds to the CFN at which new activations have to be taken
into account (provided in the CM Command message). A specific value
INVALID indicates that the CMCFN already elapsed on D-BBU.
2
Status [Id] . Four states are defined:
o Not started - the activation CFN provided in the APSI (TGCFN)
corresponds to the next CFN with this value unless CMCFN is
provided. In that case, the activation CFN corresponds to the next
CFN with that value after CMCFN (activation occurs at CMCFN if
values are equal).
o On going - the pattern already started. The activation CFN
information is then useless and the position in the pattern must be
recovered thanks to the three included parameters defined below. If

Page 35/52
2
[Id] means that this information must be provided for each configured pattern.
Volume 6 : Mobility
Page 36/52
CMCFN is valid, current patterns have to be stopped at CMCFN if not
finished yet.
o On going + not started this mix state can only be notified if
CMCFN is valid. In that case, the on going pattern is handled as
previously described but must be stopped at CMCFN. Then, the new
APSI is provided and must be taken into account as described in the
not started state.
o Finished the pattern is already finished so the whole activation
information can be ignored. Note that this state is not explicitly
needed as it may also be deduced by the non-presence of pattern Id
in CM status.
Current TGP [Id] (only if on going or on going + not started state). Fits in
the range [0..TGPRC-1].
Position in pattern [Id] (only if on going or on going + not started state).
Fits in the range [0..TGPL-1].
TGPRC [Id] (only if on going or on going + not started state). Range
[0..511].
APSI [Id] (only if not started or on going + not started state).

This information should be provided by the D-BBU in the DBBU Info Response
already sent to provide some synchronization information. This information must
systematically be provided to the H-BBU except in case of RL Setup.

4.1.3 TRANSMISSION GAP PATTERNS EVALUATION
Upon reception of all compressed mode information indicated above, the H-BBU must
then determine if patterns are active or not. If a pattern is active, the current position
within it must then be derived. Once this is performed, the on going evaluation of the
frame status (compressed or not, position of the gaps, etc) must continue as for the
DCH.

To determine the current position in the pattern, the H-BBU needs information of both
the APSI and the CM status. The following rules describe the way of using this
information. These rules must be applied for each pattern independently, either UL or
DL.
The action to perform mainly depends on the reported status:
If the pattern is reported as not started yet on the D-BBU, H-BBU must ensure
it has not started during the time the message has been forwarded from the
D-BBU to the H-BBU If not, no specific action is required except waiting for
the TGCFN. If yes, current position must be computed and the pattern will
then continuously be evaluated.
If the pattern is reported as already started, the H-BBU must then retrieve the
current position (that is not the same as the one reported in the message as
some time elapsed).
Volume 6 : Mobility
Page 37/52
If the pattern is reported as both on-going and not started yet, it means that H-
BBU must retrieve position in current pattern and continue to evaluate it until
CMCFN. Then the new APSI will be taken into account.
Finally, if the pattern is reported as finished, no action is required anymore.

4.1.4 COMPRESSED FRAMES MANAGEMENT
Once the status of each pattern is clarified and position within the pattern determined,
several actions can be performed on the H-BBU.

The H-BBU can decide not to schedule a UE [R02]:
[iCEM] if the HS-SCCH or HS-PDSCH frames overlaps with a 10ms frame
containing a DL gap.
[xCEM][UCU-III] if the HS-SCCH or HS-PDSCH frames overlaps with a 2ms
frame containing a DL gap or if the corresponding ACK/NACK frame would
overlap with an UL gap.

In UL, the compressed mode patterns needs to be consider precisely on a slot basis
to precisely take into account the gap in order to perform properly the channel impulse
response estimation (Anytime an UL frame is compressed, the right DPCCH pilot bits
sequence must be assumed (the number of pilot bits is changed as well as the
pattern). Anytime a slot is not transmitted, the impulse response estimation must not
be performed). This information can also be used in order to properly handle the
ACK/NACK and CQI fields:
If the ACK/NACK overlaps with a transmission gap, it is not transmitted by the
UE. In that case, a DTX must be assumed.
If the CQI sub-frame overlaps with a transmission gap, it is not transmitted by
the UE so it should not be taken into account and the last CQI value should be
assumed.

- In the uplink (iCEM and xCEM/OneBTS), the CQI is not decoded if it falls into an
UL gap or if the reference periods overlaps with a DL gap. The ACK/NACK frame
that overlaps with an UL gap is considered as DTX.

4.2 COMPRESSED MODE IN MAC-E
For information, for the 2ms E-DCH TTI case, the solution specified by 3GPP [R03] for
E-DCH Compressed Mode in the uplink is simple. Indeed, E-DPDCH is not
transmitted at all if an uplink CM gap overlaps partly or fully with the TTI, the
transmission is done over next non-gapped TTI available for the considered HARQ
process.
Volume 6 : Mobility
For the 10ms E-DCH TTI case, the solution is more complex since if E-DPDCH
transmission were stopped for all 10ms TTIs impacted by uplink CM gaps, the E-DCH
throughput for the considered user could be severely degraded.
[R03] For the 10ms E-DCH TTI case, 3GPP specifies that a UE with an E-DCH
transport channel established should continue transmission (if it has been granted)
over E-DCH even during TTIs affected partly by uplink CM gaps. Of course, the UE
should transmit data over E-DCH only during the slots not affected by uplink CM gaps.
As specified in 3GPP [R03], the UE reduces on its own behaviour the Serving Grant
that it uses for E-TFC selection, according to the number of slots within next TTI
affected by uplink CM gaps. In other words, the UE reduces on its own behaviour the
amount of data (compared to the amount of data it could have transmitted with the
grant received from the Node-B) transmitted over a TTI affected by uplink CM gaps.
Hence, the MAC-e scheduler at the Node-B may schedule a UE even though it is
currently doing Compressed Mode on the uplink, and in addition the MAC-e scheduler
does not necessarily have to take into account uplink CM gaps when computing the
grant for the considered UE.
0 1 2 3 4 5 6 11121314 0 1 2 3 4 5 6 7 8 9 10
Tx Gap
DTX
First HARQ transmission HARQ retransmission
10ms E-DCH TTI
0.66ms slot
10ms E-DCH TTI
0 1 2 3 4 5 6 11121314 0 1 2 3 4 5 6 7 8 9 10
Tx Gap
DTX
First HARQ transmission HARQ retransmission
10ms E-DCH TTI
0.66ms slot
10ms E-DCH TTI

Figure 6: Transmission of E-DPDCH (10ms TTI) when in CM operation

With the introduction of 33480 feature (since UA5.1), uplink CM transmission gaps are
taken into account by the MAC-e entity at the Node-B when decoding MAC-e PDUs,
thus enabling decoding of data sent by an E-DCH CM-compliant UE on E-DCH under
the E-DCH Compressed Mode format for E-DCH 10 ms TTI specified by 3GPP [R03].
Remark: A flag for activation/deactivation of 33480 feature is present in the RAN
Model until UA7.0 (edchCMActivation parameter under BTSEquipment object), but
it is not used for the 33480 activation, i.e. 33480 feature is always activated. This flag
is removed in UA7.1. In other words, the Node-B always assumes that E-DCH UE
use the compressed E-DCH format when sending data on E-DCH over a gapped
TTI.
Concerning the downlink, E-AGCH, E-RGCH and E-HICH transmission method when
CM reception gaps occur is not modified (compared to the no CM case).

UPLINK
The solution presented here applies only to E-DCH with 10ms TTI (the solution for E-
DCH with 2ms TTI is simple and is briefly mentioned at the beginning of this section).
As of today, a significant part of the commercial R6 UEs still do not support E-DCH
transmission on 10ms TTI when in CM operation as specified by 3GPP in [R03].
Hence, the following behaviour description has been split in two cases: UE not
Page 38/52
Volume 6 : Mobility
supporting E-DCH Compressed Mode and UE supporting E-DCH Compressed
Mode.

UE NOT SUPPORTING E-DCH COMPRESSED MODE
If for any reason, a UE not supporting E-DCH Compressed Mode is made entering
CM operation while an E-DCH call is established, any MAC-e PDU that is transmitted
over a gapped TTI can not be decoded by the Node-B, since data is corrupted by the
gap. However, since the UE does not support E-DCH Compressed Mode, such MAC-
e PDU is HARQ-retransmitted in a non compressed format. The Node-B assumes the
UE to use the compressed E-DCH format for the HARQ retransmission of a first
transmission affected by CM gaps, it will detect that the UE uses an E-TFCI higher
than expected. Consequently, the Node-B applies the defence mechanism against
bad detection of E-AGCH (cf. [Vol. 4]), i.e. it sends a forced-ACK to the UE (and
retransmits the E-AGCH). This mechanism avoids useless HARQ retransmissions.
RLC retransmission is triggered after a while, and the data included in the lost MAC-e
PDU is finally retrieved. For this case (i.e. UE not supporting E-DCH CM), substantial
E-DCH throughput degradation was observed during lab tests.

UE SUPPORTING E-DCH COMPRESSED MODE
As explained above, for the 10ms E-DCH TTI case, when transmitting data on E-DCH
over a TTI that is affected by uplink CM gaps, the UE reduces on its own behaviour
the Serving Grant that it uses for E-TFC selection, according to the number of slots
affected by uplink CM gaps within the TTI. This is done so that, during a TTI affected
by CM gaps, the maximum number of bits delivered by the UE to the physical layer is
fewer than the number of bits that can be actually supported.
This operation of limitation of E-TFCs set during UL a compressed frame is
done by the UE (and not by the Node-B), i.e. the UE takes the action to reduce by
itself the number of E-TFCs usable according to the UL transmission gaps pattern.
For UL compressed frames, the UE reduces the number of E-TFCs usable according
to the following method. In case of UL compressed frame, the Serving Grant SG
computed each TTI within the UE (according to the received E-AGCH command or E-
RGCH command) is reduced by the UE to SG, according to the number of non-DTX
slots N
c
in the TTI:
SG =SG * (N
c
/15)
Remark: 15 is the total number of slots (1 slot =0.66ms) within one 10ms TTI.
As a result, on the UE side, the amount of data from MAC-d layer for the current TTI is
reduced to fit the highest E-TFC usable by the UE given the reduced serving grant
SG. Then, when sending E-DCH data over the 10ms TTI, the UE maps the MAC-e
PDU only on the slots available (i.e. the slots not affected by CM transmission gaps).
With the introduction of 33480 feature, uplink CM transmission gaps are taken into
account by the MAC-e entity at the Node-B when decoding MAC-e PDUs. As a result,
data sent over E-DCH during TTIs affected by uplink CM gaps is correctly decoded by
the Node-B. For this case (i.e. UE supporting E-DCH CM), expected normal E-DCH
Page 39/52
Volume 6 : Mobility
Page 40/52
throughput degradation due to the usage of compressed MAC-e PDUs was observed
during lab tests.

There is one case for which the Node-B cannot decode data sent over E-DCH during
TTIs affected by uplink CM gaps. As explained above at the beginning of this section,
the UE reduces on its own behaviour the Serving Grant that it uses for E-TFC
selection according to the number of slots affected by uplink CM gaps within the 10ms
TTI. Consequently, in the majority of cases, the spreading factor of the E-TFC finally
selected by the UE is equal to (or greater than) the SF of the E-TFC that would have
been selected purely basing on the grant sent by the Node-B. However, if for any
reason the SF of the E-TFC finally selected by the UE happens to be smaller than the
SF of the E-TFC that would have been selected purely basing on the grant sent by the
Node-B, the Node-B cannot decode the MAC-e PDU. In this case (i.e. SF selected by
the UE smaller than the minimum SF allowed by the Node-B for this UE for current
TTI), the Node-B cannot decode the MAC-e PDU, but instead the Node-B sends a
forced-ACK (i.e. it sends an ACK although it could not decode the MAC-e DPU) in
order to avoid following HARQ retransmissions which it would not be able to decode
as well. RLC retransmission is triggered after a while, and the data included in the lost
MAC-e PDU is finally retrieved.

Concerning the UL DCH associated to the E-DCH, Compressed Mode is handled as
in previous releases, i.e. using Spreading Factor Reduction method (SF=SF/2).

UA6.0-UA7.1 Alcatel-Lucent 939x NodeBs : support of the Compressed Mode in combination
with HSUPA
In UA6 Alcatel-Lucent 939x NodeBs do not support the Compressed Mode in combination with
HSUPA.
From UA7.1 onwards, Alcatel-Lucent 939x NodeBs support the Compressed Mode in
combination with HSUPA in UL.

DOWNLINK
E-AGCH, E-RGCH and E-HICH transmission method when CM reception gaps occur
in the downlink is not modified (compared to the normal case, i.e. no CM on the
downlink). However, this does not mean that E-AGCH, E-RGCH and E-HICH can
never be decoded by the UE when CM reception gaps occur. Indeed, with 10ms TTI,
since E-AGCH is repeated 5 times, E-RGCH and E-HICH is repeated 4 times within
the 10ms DL radio frame, the UE may be able to decode this information, provided
that the DL CM pattern is not too severe.

SUMMARY MATRIX FOR E-DCH COMPRESSED MODE SUPPORT
The following matrix summarizes the four cases of E-DCH Compressed Mode support
by UE and Node-B.
Volume 6 : Mobility
Page 41/52
Node-B support for E-DCH compressed mode

No

[iCEM][xCEM] : pre-UA5.1

Yes

[iCEM][xCEM]: from UA5.1 (33480)

No
CM gaps not taken into account by UE when
transmitting on E-DCH A MAC-e PDU
transmitted over a gapped TTI cannot be
decoded.
However, MAC-e PDU is HARQ-retransmitted in
non-gapped format If TTI used for HARQ
retransmission is not gapped, retransmitted
MAC-e PDU is decoded by Node-B.
Substantial E-DCH throughput degradation.
If UE reports correctly Measurement Control
Failure, a defence mechanism at RNC disables
CM for this UE for the duration of E-DCH call.
CM gaps not taken into account by UE when
transmitting on E-DCH A MAC-e PDU
decoded.
Node-B expects UE to auto-reduce its grant and
UE does not do so (detected by Node-B due to E-
TFC larger than expected) Node-B sends an
HARQ ACK-forced, which avoids HARQ
retransmissions. Data is transmitted later thanks
to RLC.
Substantial E-DCH throughput degradation.
If UE reports correctly Measurement Control
Failure, a defence mechanism at RNC disables
CM for this UE for the duration of E-DCH call.
U
E

s
u
p
p
o
r
t

f
o
r

E
D
C
H

c
o
m
p
r
e
s
s
e
d

m
o
d
e

Yes
CM gaps taken into account by UE when
transmitting on E-DCH Since Node-B is not
aware of gapped format, a MAC-e PDU
decoded.
In addition, MAC-e PDU is HARQ-retransmitted
in gapped format as well it cannot be
decoded.
RLC retransmission triggered after maximum
number of HARQ transmissions reached.
Important E-DCH throughput degradation.
No possibility for network to detect this case.
CM gaps taken into account by UE when
transmitting on E-DCH
Since Node-B is aware of gapped format, a
MAC-e PDU transmitted over a gapped TTI is
decoded.
Normal E-DCH throughput degradation,
due to CM.
Optimal UE power usage when in CM.
Reduction of UL interference.
Table 2: Summary matrix for E-DCH Compressed Mode support

4.3 RNC DEFENSE MECHANISM AGAINST UES NOT
SUPPORTING HSDPA OR E-DCH COMPRESSED MODE
Some non-standards-conforming UEs do not support compressed mode in
combination with HSDPA or with HSUPA.
The Alcatel-Lucent UTRAN has implemented a defence mechanism to handle this
missing UE capability. The operator can choose between following options:
CM Deactivation:
In case a UE reports an RCC Measurement Control Failure at CM activation while
in HSPA call, the RNC deactivates CM at Node-B side for this UE in order to
prevent degradation of HSDPA (or E-DCH) throughput due to UE not supporting
HSDPA (E-DCH) data transmission while in CM.
Volume 6 : Mobility
Page 42/52
As CM cannot get activated and no target cell measurements are possible no
measurement based handover can be executed. Risk of call drop is increased.
UE Dependent Fallback from HSPA to DCH:
In case a UE reports an RCC Measurement Control Failure at CM activation while
in HSPA call, the RNC deactivates CM at the Node-B side for this UE,
reconfigures the call from downlink HSDPA to DCH (or uplink E-DCH to DCH
while keeping the downlink on HSDPA) and then activates CM again.
Some UEs have implemented a special indication in the UE Capability Information
about the missing CM+HSUPA capability
3
. For these UEs no CM activation during
HSUPA call is attempted. Instead UTRAN reconfigures the uplink to DCH
whenever CM is required. With this the fallback procedure is faster and avoids the
temporary mismatch on the physical layer when CM is active in UTRAN and
inactive in the UE.
With this option measurement based handover is possible. Due to the inter-
mediate reconfiguration the measurements are delayed, thus, causing a slightly
increased call drop risk compared to UEs that don't have the CM+HSPA
restriction.
Unconditional Fallback from HSUPA to DCH:
This option is applicable for HSUPA, only. If chosen then UTRAN never attempts
to activate CM for a HSUPA call. Instead UTRAN reconfigures the uplink from
HSUPA to DCH prior to each CM activation.
Whenever the missing CM+HSPA UE capability is detected the RNC creates an
internal context (for the duration of the PDP context) in order to keep memory of this
UE not supporting HSDPA (or E-DCH) data transmission while in CM and thus to
prevent any subsequent CM activation while this UE is in HSDPA (or E-DCH), i.e.
either to reconfigure to DCH prior to CM activation or to disable CM activation as per
parameter setting.

For calls with active CM, reconfiguration from DCH to HSPA or RAB setup on HSPA is
disabled to avoid HSPA setup failures for UEs with missing CM+HSPA capability.
When no CM is needed any longer UTRAN reconfigures the call from DCH to HSPA if
applicable.

3
The E-DCH compressed mode capability indication is not defined by 3GPP. It uses some spare
parameters and is mutually agreed between Alcatel-Lucent and some UE vendors.
Volume 6 : Mobility
Page 43/52
PARAMETERS:
isHSDPACMFallbackAllowed: Enables/disables fallback from HSDPA to DCH if
compressed mode activation failed for a HSDPA call. On DCH the compressed mode
activation is attempted again. The fallback is required for some legacy R5 UEs that
don't support compressed mode for HSDPA calls.
Parameter isHSDPACMFallbackAllowed Object RadioAccessService
User Customer
Class 3
Granularity RNC
Value TRUE

isEdchCmFallbackAllowed: Enables/disables fallback from HSUPA to DCH if
compressed mode is required.
never: Fallback is never attempted. If compressed mode activation fails then the
call is continued without compressed mode. The call may drop if no handover is
possible.
ueDependent: Fallback to DCH is triggered if the UE had indicated in its Radio
Access Capabilities that compressed mode for HSUPA calls is not supported.
Once the uplink is on DCH the compressed mode is activated. The capability
indication is not defined by 3GPP; it is a proprietary approach agreed by some
operators and UE and UTRAN vendors. Fallback is also triggered if the RRC
procedure for compressed mode activation fails for a UE.
allowedAlways: Fallback from E-DCH to DCH is always triggered before
compressed mode gets activated. This setting is required if the network contains
NodeBs that don't support compressed mode with E-DCH.
Parameter isEdchCmFallbackAllowed Object RadioAccessService
Range & Unit Enum {never, ueDependent, allowedAlways}
User Customer
Class 3
Granularity RNC
Value See following recommendation

Engineering Recommendation: Fallback of HSUPA to DCH on CM activation
isEdchCmFallbackAllowed is recommended to set to 'ueDependent'.

5 INTER-CARRIER MANAGEMENT FOR HSXPA
To increase the network capacity and optimise HSxPA throughput, operators may
deploy multi-layer configurations with several layers structures:
Multi-layers based on asymmetric topologies (dedicated layers for HSxPA or
Data traffic separated from dedicated layers for R99 or Conversational traffic),
Multi-layers based on symmetric topologies (shared layers for HSxPA and
R99 traffic),
Volume 6 : Mobility
Page 44/52
Several features are used in order to implement different multi-layers strategies for
HSxPA, providing inter carrier mobility:
Idle Mode & Hierarchical Cell Structure (HCS) allows strategies based on
UEs camping homogeneously on different frequencies or favour specific
carriers or even prioritizing cell layers for mobiles in idle mode, Cell_FACH
and URA/Cell_PCH connected modes. The HCS 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 RRC Connection Allocation (iMCRA) allows
redirecting UE to FDD cells at RRC connection establishment. iMCRA
strategies are based on:
o RRC Redirection based on UE Capabilities allowing redirecting UE
at RRC connection establishment based on their release and/or on
the establishment cause sent to RNC in RRC Connection Request
message. It also allows redirecting UE to the preferred R99 layer.
o RRC Redirection based on Preferred Frequency allowing
redirecting different establishment causes based on service type to
the preferred frequency allocation or allowing redirection to the
lowest loaded frequency based on originating cell load.
o RRC Redirection based on CAC failure allowing redirecting to
another frequency upon SRB CAC failure.
Intelligent Multi-Carrier Traffic Allocation (iMCTA) allowing handover UE
to another layer when in Cell_DCH connected mode:
o In case of coverage gap (iMCTA Alarm),
o In case of RAB establishment failure If call establishment is not
possible because call admission control (CAC) fails establishing the
traffic RAB (TRB) (iMCTA CAC),
o After Service Type change, Intra-frequency mobility or Always-On
upsize based on load condition of source/target cells, call type and
UE/Cell capabilities (iMCTA Service).
For strategies based on HSxPA cell load distribution, in order to have the maximum
HS-PDSCH codes available and to perform HSxPA load balancing, Fair Sharing ( [Vol.
3]) activation is mandatory (retuning of IrmOnCellColourParameters may be needed
for Service, and tuning of fair sharing parameters for CAC);
For details on cell reselection please refer to UPUG Volume 12 [R01].
For details on iMCRA and iMCTA please refer to UPUG Volume 13 [R01].
For details on carrier deployment strategies please refer to [Vol. 7].

Volume 6 : Mobility
Page 45/52
6 INTER-FREQUENCY AND INTER-SYSTEM HHO
FOR HSXPA
CM for Inter-frequency and Inter-system is supported while in HSxPA (cf. previous
section). Inter-frequency and Inter-system measurements can be setup
simultaneously (feature 34224). Therefore, Inter-frequency and Inter-system HHO can
occur following iMCTA Alarm, CAC or Service triggering. The selection between FDD
and 2G Access, or both, is part of iMCTA algorithm, mostly based on UE capabilities,
priority tables and available neighbouring cells (cf. [R01]).

The measurement configuration procedure is the same as for non-HSxPA RAB:
Configuring CM and neighbouring cells to be reported by UE through RRC
Measurement Control messages
Configuring CM in NodeB through NBAP Compressed Mode Command
message

PARAMETERS:
isInterFreqMeasActivationAllowed: This parameter indicates if the inter-frequency
measurement activation is allowed or not in the RNC.
Parameter isInterFreqMeasActivationAllowed Object RadioAccessService
{True, False}
User Customer
Class 3
Granularity RNC
Value TRUE

isInterFreqCModeActivationAllowed: This parameter allows enabling CM activation
for Inter-frequency measurements, per DlUserService.
Parameter isInterFreqCModeActivationAllowed Object DlUserService
{True, False}
User Customer
Class 3

isGsmCModeActivationAllowed: This parameter allows enabling CM activation for
GSM measurements, per DlUserService.
Parameter isGsmCModeActivationAllowed Object DlUserService
{True, False}
User Customer
Class 3

Volume 6 : Mobility
Page 46/52
Engineering Recommendation: CM (inter RAT or inter Freq) activation recommendations
isInterFreqCModeActivationAllowed must be set to True for all DlUserServices dealing with HS-
DSCH
isGsmCModeActivationAllowed must be set to True for all DlUserServices dealing with HS-DSCH
except for:
Standalone HS-DSCH or HS-DSCH mixed with PS Streaming high bit rate since high
throughput will not be maintained on GSM
HS-DSCH mixed with CS conversational because CSD64 not supported on GSM
This setting is also applicable to HSUPA RAB as the parameters are per DlUserService (i.e. HS-
DSCH).
Refer to UPUG Vol. 13, [R01], for the exhaustive list of value per DlUserService.

6.1 INTER-FREQUENCY MOBILITY FOR HSXPA
Any transition is now supported either Intra- or Inter-RNC:
HSxPA to DCH
HSxPA to HSxPA
DCH to HSxPA

All reconfigurations from HSxPA to DCH, DCH to HSxPA and HSxPA to HSxPA are
supported by both iCEM and xCEM, and by UCU-III.

6.1.1 INTER-FREQUENCY INTRA-RNC MOBILITY FOR HSXPA
In case of Intra-RNC HHO, RNC selects the target Transport Channel type based on:
The activation flag of HSDPA HHO feature (isHsdpaHhoWithMeasAllowed)
The activation flag of HSUPA HHO feature (isEdchHhoWithMeasAllowed)
The HSxPA capabilities of the target cell and the mobile
Then, RNC establishes a Radio Link on the target cell and reconfigures the mobile on
the new frequency (with new HS-DSCH and E-DCH information). Previous Radio Link
is released once RNC has received RRC Radio Bearer Reconfiguration Complete
from UE.

PARAMETERS:
For details on parameters isHsdpaHhoWithMeasAllowed and
isEdchHhoWithMeasAllowed please refer to section 3.6.

Volume 6 : Mobility
Page 47/52
If HSxPA is deployed on the same NodeB using 2 dedicated carriers, isHsdpaHhoWithMeasAllowed
and isEdchHhoWithMeasAllowed must be set to TRUE in order to prevent any conflict with iMCTA
Service strategy.

6.1.2 INTER-FREQUENCY INTER-RNC WITHOUT IUR
MOBILITY FOR HSXPA
In case of Inter-RNC mobility, source RNC uses R5 or R6 extensions (depending on
established RAB) in order to indicate in the RRC container:
The HSxPA-capabilities of the mobile
The RAB currently running on Source RNC (either HS-DSCH or E-DCH)
This nominal RRC container allows Target RNC to directly reconfigure the RAB in
HSxPA without any DCH transition.
However, in very specific cases where HSxPA capabilities are missing (e.g. if other
vendors source RNC did not provide the UEs HSxPA-capabilities), Target RNC first
establishes the PS RAB into DCH, requests UEs HSxPA-capabilities through RRC
UE Enquiry Capability procedure and eventually reconfigures the PS RAB into HSxPA
if needed.
Relocation procedures are detailed in [R01]

6.1.3 INTER-FREQUENCY INTER-RNC WITH IUR MOBILITY
FOR HSXPA
If the target cell for inter-frequency hard handover is at a neighbouring RNC to which
an Iur interface is available and the flag isInterFreqHandoverOverIurAllowed: is set
to TRUE in the SRNC towards this neighbouring RNC then inter-frequency hard
handover from DCH to DCH over Iur is to be performed. HSxPA calls will be
reconfigured to DCH before the handover.
Depending on the allocation of the source cell on the old frequency (primary cell of the
current active set) and the target cell on the new frequency there are three principle
inter-frequency hard handover scenarios over Iur to require a preceding HSxPA to
DCH reconfiguration, i.e.
handover from source cell at a DRNC to target cell at the same DRNC
handover from source cell at the SRNC to target cell at a neighbouring RNC
Note: The neighbouring RNC may be an existing DRNC which is already
involved in the active set on the old frequency or will become a new DRNC
otherwise
handover from source cell at a DRNC to target cell at another neighbouring
RNC
Volume 6 : Mobility
Page 48/52
Note, that handover from source cell at a DRNC to target cell at the current SRNC is
not to be considered in this context. This handover can be performed directly from
HSxPA to HSxPA as described in 6.1.1.
After successful DCH to DCH handover over Iur a previous HSxPA call will be
reconfigured back to HSDPA on the new frequency immediately. Reconfiguration back
to HSUPA is not supported in this case, refer to section 3.5.
Typical unsuccessful cases are handled as follows:
If the reconfiguration from HSxPA to DCH ends up with the call remaining on
HSxPA then SRNS relocation may be attempted if allowed.
If the DCH to DCH handover ends up with the call remaining on the old
frequency then SRNS relocation may be attempted if allowed. If the call finally
remains on DCH on the old frequency (i.e SRNS relocation is unsuccessful as
well or not allowed) then a previous HSxPA call will be reconfigured back to
HSxPA on the old frequency by intra frequency mobility.
For description of detailed scenarios and interaction with SRNS relocation please refer
to UTRAN Parameters User Guide, [R01].

PARAMETERS:
isInterFreqHandoverOverIurAllowed: This parameter enables/disables the inter-
frequency hard handover over Iur on a per neighbouring RNC basis
Parameter isInterFreqHandoverOverIurAllowed Object NeighbouringRNC
{True, False}
User Customer
Class 3
Granularity N/A
Value TRUE

6.1.4 FULL EVENT HHO SETTING FOR HSXPA
Specific 2D/2F thresholds must be set to all UsHoConfs that contain HS-DSCH in
order to prevent call drop that may occur due to radio degradation following CM
activation. The following table depicts the Engineering recommendation for HSxPA
whose RSCP thresholds differs from DCH setting presented in UPUG Vol. 13 [R01].
Volume 6 : Mobility
Page 49/52
E
v
e
n
t

Parameter Object
V
a
l
u
e

cpichEcNoThresholdUsedFreq2D
FullEventHOConfHhoMgt -14
cpichRscpThresholdUsedFreq2D
2D
timeToTrigger2D
FullEventRepCritHHOMgt 1280
cpichEcNoThresholdUsedFreq2F
cpichRscpThresholdUsedFreq2F
2F
timeToTrigger2F FullEventRepCritHHOMgt 1280
timerAlarmHOEvent FullEventHOConfHhoMgt 0
Table 3: HHO Event Recommended Settings Summary
.
Note that minimumCpichEcNoValueForHO and minimumCpichRscpValueForHO
(defined per DlUserService) must be set accordingly to 2D thresholds and network
topology in order to prevent abusive successive inter-frequency HHO.

6.2 INTER-SYSTEM MOBILITY FOR HSXPA
6.2.1 3G TO 2G HANDOVER
In case iMCTA has selected 2G as Target Access, RNC configures CM for Inter-
System and UE may report GSM cells while in HSxPA.
Hard Handover is supported by RNC for 3G-2G mobility and is handled the same way
as for R99 calls. Please refer to [R01] for more details.

If UE does not report any neighbouring cell (either Inter-Frequency or Inter-System) or
if the reported signal is lower than the minimum threshold, Blind HO towards 2G may
be triggered if provisioned. This is only applicable for iMCTA Alarm and CAC, not for
iMCTA Service as the latter trigger is for comfort purpose.

6.2.2 2G TO 3G HANDOVER
From the target RNC, this is seen as a new Mobile Originated PS call. The same rules
as the initial admission apply, leading possibly to the allocation of HSxPA to the
incoming UE.

Volume 6 : Mobility
Page 50/52
7 U-PLANE TRAFFIC HANDLING
There are 2 aspects to consider during HSDPA mobility:
1. Traffic handling policy toward the source cell.
This policy is only applicable when the old serving HS-DSCH RL is still part
of the Active Set. At time (Activation Time Suspend Time Offset), the RNC
no longer sends data to the source cell.
Parameter iubSuspendTimeOffset Object NodeBConfClass
[0 255] (x 10ms)
User Customer
Class 3
Granularity RNC
Value 16

Parameter iurSuspendTimeOffset Object NeighbouringRNC
[0 255] (x 10ms)
User Customer
Class 3
Granularity RNC
Value 16

Each time the primary cell change, the HS-DSCH RL is deleted on the
former primary and it is re-established under the new primary, using a
synchronous reconfiguration. During the reconfiguration, data transfer on
HS-DSCH is suspended by the RNC. Suspension is done N radio-frames
before switching activation time. N is given by the parameter
iubSuspendTimeOffset. At expiry of this timer, data that were in the Mac-
hs buffer of the former cell are discarded but no user data is lost thanks to
RLC retransmission. The exception to this is in the case of 2 cells that are
managed by the same BBU: in this scenario, the PDU in the Mac-hs buffer
are not lost, however on-going HARQ retransmissions are lost.

UA6-UA7 Delta: suspendTimeOffset
In UA6, the suspendTimeOffset parameter is defined per RNC.
In UA7, this parameter is replaced by iubSuspendTimeOffset and iurSuspendTimeOffset. These
parameters are defined per NodeB

2. HS-DSCH credit acquisition policy from the target cell.
Based on the following NodeB behaviour specifications:
All HS-DSCH Capacity Requests that are sent to the NodeB before
the starting activation time are silently discarded.
Volume 6 : Mobility
Page 51/52
When the credits are not yet explicitly granted, the NodeB silently
delete HS-DSCH data coming from the RNC (i.e. no HS-DSCH
Capacity Allocation is sent to the RNC).
After the activation time, on the first HS-DSCH Capacity Request with
nonzero BO (Buffer Occupancy), the NodeB immediately replies with
HS-DSCH Capacity Allocation.
In the steady-state (after that first HS-DSCH Capacity Request
message), a Capacity Allocation can be sent at any time (depending
on NodeB buffer occupancy) indicating to the RNC the number of
MAC-d PDUs it can send for the corresponding MAC-d flow with the
associated priority. This is done without needing a Capacity Request
and without evaluation the BO (RNC Buffer Occupancy).

The RNC HS-DSCH initial credit acquisition policy is as followed:
1. If an initial HS-DSCH credit is explicitly returned by the NodeB in the NBAP
RL Reconfiguration Ready message, the RNC will start to use that credit at
the activation time. Otherwise, the RNC will assume that the credits are set to
zero. This is applicable to both intra and inter-NodeB mobility cases.
2. At the activation time, if the HS-DSCH credit is zero and there are outstanding
data to be transmitted, the RNC will initiate the HS-DSCH Capacity Request
toward the target cell in the u-plane nothing will be sent before the activation
time.
Volume 6 : Mobility
Page 52/52

END OF DOCUMENT


7 DEPLOYMENT SCENARIOS


Volume 7 : Deployment Scenarios
Page 1/34
CONTENTS
1 INTRODUCTION............................................................................................................................4
1.1 OBJ ECT....................................................................................................................................4
2.1 HPUG VOLUMES......................................................................................................................5
3 DEPLOYMENT STATUS...............................................................................................................6
4 CARRIER DEPLOYMENT & STRATEGY RECOMMENDATIONS..............................................7
4.1 CELL TOPOLOGIES....................................................................................................................8
4.2 TRAFFIC DISTRIBUTION..............................................................................................................9
4.3 BI CARRIER DEPLOYMENT SCENARIOS ......................................................................................12
4.4 TRI CARRIER DEPLOYMENT SCENARIOS.....................................................................................17
4.5 FOUR CARRIER DEPLOYMENT SCENARIOS .................................................................................22
4.6 UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ..................................................................22
4.7 TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION...................................................................23
4.8 CPICH DESIGN CHOICES...........................................................................................................24
5 FEATURES RELATED TO SPECIFIC DEPLOYMENT SCENARIOS .......................................25
5.1 MULTI-CARRIER PA POWER POOLING (29808) ........................................................................25
5.1.1 Feature description.......................................................................................................25
5.1.1.1 Static PA Power sharing (feature deactivated)......................................................... 25
5.1.1.2 Dynamic PA Power Sharing..................................................................................... 25
5.1.1.3 Supported radio configurations ................................................................................ 28
5.1.2 Parameter settings and recommendations ...................................................................29
5.1.2.1 RAN Model ............................................................................................................... 29
5.1.2.2 OMC-R Parameters.................................................................................................. 29
5.1.2.3 OMC-B Parameters.................................................................................................. 31
5.1.2.4 Other recommendations........................................................................................... 32

Page 2/34
TABLES
TUTable 1: different topologies of carriers with the minimum associated hardwareUT 7
TUTable 2: summary for Cell Reselection, RCC Redirection & Handover strategies per topologyUT 14
TUTable 3: summary for HSDPA & HSUPA requirements per topologyUT 16
TUTable 4: summary for Cell Reselection, RCC Redirection & Handover strategies per topologyUT 19
TUTable 5: summary for HSDPA & HSUPA requirements per topologyUT 21

Page 3/34
FIGURES
TUFigure 1: Examples of applications for traffic distributionUT ............................................................................. 11
TUFigure 2: Examples of overload handling strategies at various cell load levelsUT ........................................ 11
TUFigure 3: Bi carrier deployments scenariosUT .................................................................................................... 12
TUFigure 4: Tri carrier deployments scenariosUT ................................................................................................... 17
TUFigure 5: Example for mixed frequency deployment scenariosUT................................................................... 22
TUFigure 6: Typical scenarios for neighbour declarationUT .................................................................................. 23
TUFigure 7: PA Power overbookingUT ..................................................................................................................... 26

Page 4/34
1 INTRODUCTION
1.1 OBJECT
R99 & HSDPA & E-DCH (HSUPA) multi-layer system deployments. This document
intends to:
Specify the most attractive deployment scenarios for operators;
Provide the most suitable mobility strategy & HSxPA requirements behind
each proposed topology evolution;
This includes a system description, configuration aspect and high level engineering
recommendations.

This document deals with the deployment scenarios.

Page 5/34
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

[R01] UMT/DCL/DD/0020 UTRAN Parameters User Guide UA7
Planning Guide
[R03] UMT/IRC/APP/007147 NodeB Product Engineering Information
UA6&UA7

Page 6/34
This part aims at:
Listing all the topologies that could be faced in UA7,
Providing the UA7 Deployment Engineering Recommendations.
In order to limit only to realistic use cases, selection of the target UA7 topologies had
been based on:
HSxPA & R99 Performance expectations
Capacity usage efficiency
Deployment cost: New Hardware or Optimization activities (Network re-
engineering actions) required
A clean UL radio behaviour and performance is required for correct HSUPA
introduction and associated performance (see XR R[Vol. 4]X). RSSI level and stability is a
good indicator of the UL load estimation.
It is important to ensure an appropriate value for the RSSI indicator. Engineering
optimization shall be considered around UL/DL unbalanced paths, missing cell
declaration in neighbouring, NodeB cabling, external interference sources.

3 DEPLOYMENT STATUS
The aim of this section is to present the minimum hardware required to support the
topologies described in section XR R4X.

The XTable 1X is based on the following considerations (assuming 3 sectors):
UiCemU:
- 1 iCem64 contains 1 BBU that can be configured as D-BBU, H-BBU or E-
BBU
- 1 iCem128 contains 2 BBU that can be configured as D-BBU, H-BBU or E-
BBU (only one E-BBU whatever the number of iCem only one HSUPA
carrier)
- 1 D-BBU is able to manage 1 or 2 carriers (even for HSxPA dedicated
carrier, the D-BBU manage at least the common channels of this carrier). But
for capacity reason, the recommendation is to use at least 2 D-BBU for 2 or 3
carriers.
- 1 H-BBU is able to manage 1 HSDPA carrier
- 1 E-BBU is able to manage 1 HSUPA carrier (only one E-BBU whatever the
number of iCem only one HSUPA carrier)

Page 7/34
UxCemU:
- 1 xCem contains 4 BBU that can be configured as D-BBU (4 max), H-BBU (2
max) or E-BBU (1 max). In case of M-BBU (by default since UA6.0), a BBU
can be used in the same time for R99, HSDPA and HSUPA
- 1 BBU is able to manage up to 2 carriers

UiCcmU:
- The maximum configuration supported by an iCcm is:
- 3 xCem (M) +2 iCem128 (D,D) +1 iCem (D) or
- 3 xCem (M) +1 iCem128 (D,H) +1 iCem (D) or

UxCcmU:
- The maximum configuration supported by an xCcm is:
- 3 xCem +n iCem (no limitation in term of iCem)
- 3 UCU-III (Up to 3 frequencies within up to 3 HSDPA frequencies
and up to 3 HSUPA frequencies)

#carriers F1 F2 F3 Product Minimum iCem Hardware Mi ni mum xCem Hardware
1 carrier R99/HSxPA STSR1 1 iCem128 +1 iCem64 1 xCem
2 carriers R99 HSxPA STSR2, STSR1+1 2 iCem128 1 xCem
2 carriers R99/HSDPA HSxPA STSR2, STSR1+1 2 iCem128 +1 iCem64 1 xCem
2 carriers R99/HSDPA R99/HSxPA STSR2, STSR1+1 2 iCem128 +1 iCem64 1 xCem
2 carriers R99/HSxPA HSxPA STSR2, STSR1+1 Not supported (1 HSUPA carrier) 1 xCem
2 carriers R99/HSxPA R99/HSxPA STSR2, STSR1+1 Not supported (1 HSUPA carrier) 1 xCem
3 carriers R99 HSDPA HSxPA STSR3, STSR2+1 3 iCem128 2 xCem
3 carriers R99 HSxPA HSxPA STSR3, STSR2+1 Not supported (1 HSUPA carrier) 2 xCem
3 carriers R99/HSDPA HSDPA HSxPA STSR3, STSR2+1 3 iCem128 +1 iCem64 2 xCem
3 carriers R99/HSDPA HSxPA HSxPA STSR3, STSR2+1 Not supported (1 HSUPA carrier) 2 xCem
3 carriers R99/HSxPA R99/HSDPA HSxPA STSR3, STSR2+1 Not supported (1 HSUPA carrier) 2 xCem
3 carriers R99/HSxPA R99/HSxPA HSxPA STSR3, STSR2+1 Not supported (1 HSUPA carrier) 2 xCem
3 carriers R99/HSxPA R99/HSxPA R99/HSxPA STSR3, STSR2+1 Not supported (1 HSUPA carrier) 2 xCem

Table 1: different topologies of carriers with the minimum associated hardware

Note that the hardware configuration given in this table is the minimum configuration
to have a nominal behaviour. The recommended configuration has to take into
account the traffic supported for R99, HSDPA and HSUPA.

4 CARRIER DEPLOYMENT & STRATEGY
RECOMMENDATIONS
The following deployment evolutions are not exhaustive and intend to specify the most
attractive scenarios for operators. The deployment scenarios evolution offered on the
Page 8/34
following sections are based on UA7 topologies and are considering that HSUPA can
be introduced where HSDPA is present.
Since UA6 a NodeB (iBTS) can handle up to 4 HSDPA layers and 4 E-DCH layers,
with single frequency per iCEM and two frequencies per xCEM. Deployment scenarios
up to 3 carriers will be detailed. Recommended strategies for Four Frequency
deployments will be based on Tri Frequency deployments by adding additional FDD4
carrier with equivalent topology/strategy as used for FDD2 & FDD3 layers;
The following deployment scenarios evolution will be presented:
Bi Carrier deployments
Tri Carrier deployments
Four Carrier deployments

4.1 CELL TOPOLOGIES
Six cell topologies are considered for the deployment scenarios:

Frequency with R99 traffic:
o Represented in this document by:
o Do not carry any HSxPA traffic

Frequency with Conversational traffic:
o Conversational traffic is carried on a dedicated carrier; may include
CS voice over HSxPA and VoIP in HSxPA;
o Up to 14 or 15 HS-PDSCH codes usable for HSDPA thanks to Fair
Sharing (dynamic codes management part) & more than 1 PCM
generally deployed

Frequency with Data traffic:
o PS R99 and HSxPA traffic are cohabiting on the same frequency
Sharing (dynamic codes management part) & generally 1 PCM
deployed

Frequency with HSxPA traffic:
R99
Conversational
HSxPA
Data
Page 9/34
o HSDPA and HSUPA traffic are cohabiting on the same frequency
Sharing (dynamic codes management part) & more than 1 PCM
generally deployed

Frequency with R99/HSxPA traffic:
o R99, HSDPA and HSUPA traffic are cohabiting on the same
frequency
deployed

Frequency with R99/HSxPA but faType =other:
o R99, HSDPA and HSUPA traffic are cohabiting on the same
frequency
deployed

4.2 TRAFFIC DISTRIBUTION
Traffic distribution can be based on various strategies, e.g. R99/HSDPA/HSUPA
segmentation, CS and PS segmentation or load distribution.

Reselection: UEs in idle, URA_PCH and Cell_FACH state autonomously
select the cell to camp on. For the cell selection strategy the UE uses cell broadcast
information, measured cell level and quality. If a cell gets loaded then its quality gets
worse. This causes the UE to reselect to a lower loaded cell with better quality. In
case of different radio propagation (e.g. GSM/UMTS) unbalanced UE distribution may
occur. Neighbouring relation specific offset parameters can be used to mitigate this
problem and apply a strategy based on UEs camping homogeneously on different
frequencies. Other strategies intend to favour specific carriers. Different strategies can
be use for idle and connected mode.

RRC Redirection: On RRC establishment from idle mode UTRAN has load
information of the originating cell and co-located cells. UTRAN has also capabilities
information of the originating and twin cells and can get from the RRC Connection
Request message the UE capability and the establishment cause. If the load of the
originating cell is higher than of co-located cells or even call establishment is not
R99/HSxPA
other
Page 10/34
possible because call admission control (CAC) fails establishing the signalling Rab
(SRB), then UTRAN could decide to redirect the UE to another frequency or to GSM.
Redirection to GSM is typically applied for CS voice calls in case of CAC failure
establishing the SRB. For lower load conditions redirection is not recommended
because UTRAN has no load information of the GSM cells. Redirection is performed
towards the GSM system without any specific cell information. Therefore, the UE can
determine the most suitable performing an inter-system cell reselection. In case of
redirection to another frequency 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). Advantages of RRC redirection are that compressed mode is not needed and
RAB establishment is done directly on the target cell.

Handover: After call establishment UTRAN has best control when to
handover whom to which target. If call establishment is not possible because call
admission control (CAC) fails establishing the traffic Rab (TRB), then UTRAN could
decide to send the UE to another frequency or to GSM. Handover criteria also include
for example radio quality, load condition of source and target cells, call type and
UE/Cell capabilities. For almost all UEs compressed mode is needed to perform
measurements of other frequencies and of GSM. Blind handover could be used to
avoid compressed mode but usually blind handover is avoided because of high failure
rate. Depending on system configuration and handover criteria a call can get handed
over to other frequencies or to GSM, avoiding congestion across carriers and
spreading traffic equally.

The Reselection, RCC Redirection & Handover strategies cannot be idealised
independently, e.g. favour a specific carrier in idle mode could be somehow not
completely in line with handover load balancing strategy.

The following picture is giving an example of applications. Service segmentation and
Sequential loading are normally achieved by favour a specific carrier on reselection.
Load balancing strategy cope with UEs camping homogeneously on different
frequencies.
Page 11/34

Service segmentation
R99 traffic
HSxPA Traffic
C
opyright
1996 N
orthern T
elecom
Service segmentation
R99 traffic
HSxPA Traffic
C
opyright
1996 N
orthern T
elecom
R99 traffic
HSxPA Traffic
C
opyright
1996 N
orthern T
elecom
Sequential Loading
Load F1 first
C
opyright
1996 N
orthern T
elecom
Load Balancing
Overloaded
cell
C
opyright
1996 N
orthern T
elecom
Non loaded
cell
Overloaded cell
Speech call
GSM
Copyright 1996 Northern Telecom
GSM fallback

Figure 1: Examples of applications for traffic distribution

The following picture provides an idea of load balancing and overload handling
strategies at various cell load levels. In this example, Cell Reselection in Idle Mode
can be used to equally distributing UEs across the different layers; iMCRA can start
load distribution when load on originating cell becomes Yellow; iMCTA Service can
handover calls when load on cell becomes Red and calls can also be handover by
iMCTA CAC to another frequency when experience CAC failure.

Figure 2: Examples of overload handling strategies at various cell load levels

Cell Reselection in Idle mode
Cell Load Color
>= Yellow
Cell Load Color
>= Red
CAC Failure at
RAB Est.
Cell Load CAC Failure at
RRC Setup.
Cell Load Color
>= Green
RRC Redirection of Speech and Packet Calls to Twin Cells
Redirection of Originating Speech Calls to 2G
iMCTA Service HO of Speech Calls to 2G
CAC Failure HO of Speech and Packet
Calls to 3G and 2G
Rejection of RRC
Connection Requests
iMCTA Service HO of Packet Calls to 3G
Cell Reselection in Idle mode
Cell Load Color
>= Yellow
Cell Load Color
>= Red
CAC Failure at
RAB Est.
Cell Load CAC Failure at
RRC Setup.
Cell Load Color
>= Green
RRC Redirection of Speech and Packet Calls to Twin Cells
Redirection of Originating Speech Calls to 2G
iMCTA Service HO of Speech Calls to 2G
CAC Failure HO of Speech and Packet
Calls to 3G and 2G
Rejection of RRC
Connection Requests
iMCTA Service HO of Packet Calls to 3G
Page 12/34
4.3 BI CARRIER DEPLOYMENT SCENARIOS
UA7 Multi-layer Strategy for Bi carrier deployments may include the interworking for
different features like: Cell reselection; Downlink/Uplink iRM; iRM Scheduling;
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA); Intelligent Multi-Carrier
Traffic Allocation (iMCTA); 3G2G Redirection based on cell load; iMCTA Load based
HO developments; IF/IRAT Measurements Evolution; Fair sharing of resources:
HSDPA vs. DCH; GBR on HSDPA; HSPA to DCH fallback; Multi-carrier PA Power
Pooling; Broadcast of SIB4; Broadcast of SIB12; Always-On; Support of 64 UMTS
Neighbours.
ALU propose the following strategies:
Traffic Segmentation based on HSPA capability
Traffic Segmentation based on call type
Load Distribution (recommended for high traffic)

Figure 3: Bi carrier deployments scenarios

The following table is making a summary for Cell Reselection, RCC Redirection &
Handover strategies behind each proposed topology evolution. It is considered that
Cell sizes are equivalent (for Cpich Power recommendations please refer to XR R4.8X).
Segmentation based on call type
Segmentation on HSPA capability
Load Distribution
UMTS FDD1
GSM
UMTS FDD2
Priority for FDD Mobility Priority for FDD Mobility
Fallback GSM
iMCTA Alarm & iMCTA CAC Strategy
R99/HSxPA
HSxPA
Cell Reselection favor F1
RRC Traffic Segmentation R99 & HSxPA
iMCTA Service Segmentation R99 & HSxPA
Conversational
Data
Conversational & Data Flux
Cell Reselection favor F1
iMCTA Service Segmentation CS & PS
other
other
Cell Reselection
Load Distribution
iMCTA Service Load Balancing
UMTS FDD1
GSM
UMTS FDD2
or
R99
HSxPA
or
iMCTA Service Load Balancing
Page 13/34

TOPOLOGY Cell RESELECTION RRC Redirection HANDOVER
Idle Mode: Favour
Conversational carrier on cell
selection/reselection by
keeping the UE on the
originating FDD1 cell that had
been selected by the UE for
access, avoiding redirection for
Conversational Services.
Connected Mode: Disable Inter
Frequency cell reselection;
When UE enters in Cell FACH,
we want him to stay on Data
layer, not select back
Conversational layer.
Use iMCRA with Call Type
Segmentation strategy;
Establishment cause
Conversational redirected to
FA Type Conversational.
Establishment cause
Streaming, Interactive,
Background, High Priority
signalling and Registration:
redirected to FA Type Data.
iMCTA Alarm: Conversational
calls redirected to GSM. Data
with low bits rates calls on FDD2
redirected to GSM.
iMCTA CAC: An inter Rat
handover is preferred over an
inter frequency handover only
when FDD neighbour target cells
are RED (avoiding increasing the
load of a target FDD cell by
choosing the 2G access).
iMCTA Service used to ensure
Conversational calls are re-
directed on FDD1 and Data calls
are re-directed on FDD2
Idle Mode: Favour R99 carrier
on cell selection/reselection
by keeping the UE on the
Speech Services.
Connected Mode: disable Inter
Frequency cell reselection;
When UE enters in Cell FACH,
we want him to stay on HSxPA
layer, not select back R99
layer.
Use iMCRA with UE Capabilities
(traffic segmentation) strategy;
All UEs with establishment cause
"Conversational redirected to
R99 cell.
DCH capable UE with
establishment cause Streaming"
Interactive, Background,
High Priority signalling and
Registration redirected to R99
cell.
HSDPA or HSUPA capable UE with
Interactive, Background ,
Registration redirected to
HSxPA cell.
iMCTA Alarm: Voice calls
redirected to GSM. R99 PS with
low bits rates calls on FDD1
redirected to GSM.
R99 calls are re-directed on FDD1
and HSxPA calls are re-directed
on FDD2.
Idle Mode: Favour R99/HSxPA
carrier on cell
selection/reselection by
keeping the UE on the
Speech Services.
(traffic segmentation) strategy
but with layerPreferredForR99 =
TRUE on FDD1 R99/HSxPA cell;
R99/HSxPA cell.
DCH capable UE with
redirected to GSM. For R99 PS
with low bits rates calls an inter
Rat handover is preferred over an
are RED.
Conversational
Data
R99
HSxPA
R99/HSxPA
HSxPA
Page 14/34
Connected Mode: Activate
Sib4 & Sib12 allowing mobility
from FDD2 to FDD1 layer
avoiding PS R99 traffic flux
from FDD1 to FDD2.
R99/HSxPA cell.
HSxPA cell.
R99 calls are re-directed on FDD1
and HSxPA calls perform load
balancing.

Idle Mode: UEs camping
homogeneously on different
frequencies.
Connected Mode: Reuse Idle
Mode configuration with UEs
camping homogeneously on
different frequencies.
Use iMCRA with Load
Distribution strategy inducing
induce redirection to lowest
loaded frequency if originating
cell has cell colour YELLOW or
RED;
If needed, it may be
recommended to set for feature
34480 the following
configuration (if GSM layer is
present): for Speech and
Emergency calls, a 3G/2G
Redirection is preferred over a
3G/3G redirection only when all
FDD eligible target cells for
redirection are RED.
iMCTA Alarm & CAC: Voice calls
redirected to GSM. For PS an
inter Rat handover is preferred
over an inter frequency handover
only when FDD neighbour target
cells are RED (avoiding increasing
the load of a target FDD cell by
choosing the 2G access);
iMCTA Service used for load
balancing.
Table 2: summary for Cell Reselection, RCC Redirection & Handover strategies per topology

The following table is making a summary for HSxPA requirements behind each
proposed topology evolution.
TOPOLOGY HSDPA & HSUPA Requirements

UCodes mgtU:
- In order to have the maximum HS-PDSCH codes available, Fair Sharing activation is
recommended (even without resources reservation); numberOfHsScchCodes =
3 if the HSDPA traffic is high enough to schedule up to 3 ue per TTI quite
often and if 15 HS-PDSCH codes are not mandatory; 2 otherwise
UPower mgtU:
- PA power pooling activation if STSR2
- Power Evolution activation (applicable only for iCem)
other
other
Conversational
Data
Page 15/34
UUl load mgtU:
totalRotMax = 8dB

UCodes mgtU:
- In order to have the maximum HS-PDSCH codes available, Fair Sharing activation is
recommended (even without resources reservation); numberOfHsScchCodes =
3 if the HSDPA traffic is high enough to schedule up to 3 ue per TTI quite
often and if 15 HS-PDSCH codes are not mandatory; 2 otherwise
UPower mgtU:
UUl load mgtU:
totalRotMax = 8dB

UCodes mgtU:
- In order to have the maximum HS-PDSCH codes available and to perform HSxPA
iMCTA Service load balancing, Fair Sharing activation is mandatory with
numberOfHsScchCodes= 2; it is recommended to:
- Set minBrForHsdpa= 100 for Interactive and Background; create new
hsxpaR99ResourcesSharingId= HsxpaR99ResourcesSharingCellClass/1for both carriers
with new values for: initialActivityFactorForIB=100;
reservationFactorOnCodesForGbrTraffic=100; ovsfCodesThroughputQpskUE= 200;
ovsfCodesThroughput16QAMUE=200;
Nbcodes/user= minBrforHsdpa/ ovsfCodesThroughputxxxxUe[1] -> Nbcodes =
0.5 codes (around 30 users for the 15 ovsfcodes; please note that
ovsfCodesThroughputQpskUE= 200 & ovsfCodesThroughput16QAMUE= 200 only
depends upon the UE category; all HSD capable UEs(except Cat 11 and 12)
will always use the 16QAM parameter);
(Retuning of green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters
may be needed for iMCTA Service, and tuning of fair sharing parameters for iMCTA
CAC).
UPower mgtU:
UUl load mgtU:
totalRotMax = 8dB

UCodes mgtU:
- In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
balancing, Fair Sharing activation is mandatory with numberOfHsScchCodes= 2; it is
recommended to:
R99
HSxPA
R99/HSxPA
HSxPA
other
other
Page 16/34
- Set minBrForHsdpa= 100 for Interactive and Background; create of new
hsxpaR99ResourcesSharingId= HsxpaR99ResourcesSharingCellClass/1for both carriers
may be needed for iMCRA and iMCTA Service, and tuning of fair sharing parameters
for iMCTA CAC).
UPower mgtU:
- No PA power pooling
- No Power Evolution applicable only for iCem
UUl load mgtU:
totalRotMax = 6dB

Table 3: summary for HSDPA & HSUPA requirements per topology

Page 17/34
4.4 TRI CARRIER DEPLOYMENT SCENARIOS
UA7 Multi-layer Strategy for Tri Carrier deployments may include the interworking for
different features like: Cell reselection; Downlink/Uplink iRM; iRM Scheduling;
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA); Intelligent Multi-Carrier
Traffic Allocation (iMCTA); 3G2G Redirection based on cell load; iMCTA Load based
HO developments; IF/IRAT Measurements Evolution; Fair sharing of resources:
HSDPA vs. DCH; GBR on HSDPA; HSPA to DCH fallback; Multi-carrier PA Power
Pooling; Broadcast of SIB4; Broadcast of SIB12; Always-On; Support of 64 UMTS
Neighbours.
ALU propose the following strategies:
Traffic Segmentation based on HSPA capability
Traffic Segmentation based on call type
Load Distribution (recommended for high traffic)

Figure 4: Tri carrier deployments scenarios

The following table is making a summary for Cell Reselection, RCC Redirection &
Handover strategies behind each proposed topology evolution. It is considered that
Cell sizes are equivalent (for Cpich Power recommendations please refer to XR R4.8X).

Cell Reselection
RRC Traffic Segmentation R99 & HSxPA
iMCTA Service Segmentation R99 & HSxPA
Conversational & Data Flux
Cell Reselection
Segmentation based on call type
Segmentation on HSPA capability
Cell Reselection
Load Distribution
Load Distribution
UMTS FDD1
GSM
UMTS FDD2
Priority for FDD Mobility Priority for FDD Mobility
Fallback GSM
iMCTA Alarm & iMCTA CAC Strategy
iMCTA Service Load Balancing iMCTA Service Segmentation CS & PS
other
other
other
Conversational
Data
Data
UMTS FDD3
R99
HSxPA
HSxPA
UMTS FDD1
GSM
UMTS FDD2
UMTS FDD3
or
Page 18/34

TOPOLOGY RESELECTION RRC Redirection HANDOVER
frequencies with small favour
to FDD1 -> objective is
minimizing the amount of
redirections for Conversational
Calls.
Sib4 & Sib12; disable Inter
Frequency cell reselection
FDD1 <> FDD2&FDD3 (when UE
enters in Cell FACH, we want
him to stay on Data layer, not
select back Conversational
layer); UEs camping
homogeneously on FDD2 &
FDD3 frequencies but with
delayed scanning and higher
hysteresis comparing to Idle
Mode.
Use iMCRA with Call Type
Segmentation strategy;
Establishment cause
Conversational redirected to
FA Type Conversational.
Establishment cause
Streaming, Interactive,
Background, High Priority
signalling and Registration:
redirected to FA Type Data.
iMCTA Alarm: Conversational calls
redirected to GSM; For R99 PS with
low bits rates calls an inter Rat
handover is preferred over an inter
frequency handover only when FDD
neighbour target cells are RED.
iMCTA CAC: An inter Rat handover
is preferred over an inter frequency
handover only when FDD neighbour
target cells are RED (avoiding
increasing the load of a target FDD
cell by choosing the 2G access).
Conversational calls are re-directed
on FDD1 and Data calls are re-
directed on FDD2 & FDD3; Also
ensure Load Balancing between
FDD2 & FDD3.

frequencies with small favour
to FDD1 -> objective is
minimizing the amount of
redirections for Voice Calls.
Sib4 & Sib12; disable Inter
Frequency cell reselection
FDD1 <> FDD2&FDD3 (when UE
enters in Cell FACH, we want
him to stay on HSxPA layer,
not select back R99 layer); UEs
FDD2 & FDD3 frequencies but
with delayed scanning and
higher hysteresis comparing to
Idle Mode.
(traffic segmentation) strategy;
R99 cell.
DCH capable UE with
Registration redirected to R99
cell.
HSxPA cells.
redirected to GSM. For R99 PS with
low bits rates calls an inter Rat
handover is preferred over an inter
frequency handover only when FDD
neighbour target cells are RED.
iMCTA CAC: An inter Rat handover
is preferred over an inter frequency
handover only when FDD neighbour
target cells are RED (avoiding
increasing the load of a target FDD
cell by choosing the 2G access).
iMCTA Service used to ensure R99
calls are re-directed on FDD1 and
HSxPA calls are re-directed on
FDD2 & FDD3; Also ensure Load
Balancing between FDD2 & FDD3.

Conversational
Data
Data
R99
HSxPA
HSxPA
Page 19/34

frequencies.
Connected Mode: Reuse Idle
Mode configuration with UEs
different frequencies.
Use iMCRA with Load
Distribution strategy inducing
induce redirection to lowest
loaded frequency if originating
cell has cell colour YELLOW or
RED;
If needed, it may be
recommended to set for feature
34480 the following
configuration (if GSM layer is
present): for Speech and
Emergency calls, a 3G/2G
Redirection is preferred over a
3G/3G redirection only when all
FDD eligible target cells for
redirection are RED.
iMCTA Alarm & CAC: Voice calls
redirected to GSM. For PS an inter
Rat handover is preferred over an
choosing the 2G access);
iMCTA Service used for load
balancing.

Table 4: summary for Cell Reselection, RCC Redirection & Handover strategies per topology
other
other
other
Page 20/34
The following table is making a summary for HSxPA requirements behind each
proposed topology evolution.
TOPOLOGY HSDPA & HSUPA Requirements
UCodes mgtU:
balancing, Fair Sharing activation is mandatory; numberOfHsScchCodes = 3 if the
HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often and if 15 HS-
PDSCH codes are not mandatory 2 otherwise; it is recommended to:
hsxpaR99ResourcesSharingId= HsxpaR99ResourcesSharingCellClass/1for all carriers
CAC)
UPower mgtU:
- PA power pooling activation if STSR2+1
UUl load mgtU:
totalRotMax = 8dB
UCodes mgtU:
balancing, Fair Sharing activation is mandatory; numberOfHsScchCodes = 3 if the
HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often and if 15 HS-
PDSCH codes are not mandatory 2 otherwise; it is recommended to:
Conversational
Data
Data
R99
HSxPA
HSxPA
Page 21/34
CAC)
UPower mgtU:
- PA power pooling activation if STSR2+1
UUl load mgtU:
totalRotMax = 8dB
UCodes mgtU:
balancing, Fair Sharing activation is mandatory with numberOfHsScchCodes= 2; it is
recommended to:
may be needed for iMCRA and iMCTA Service, and tuning of fair sharing parameters
for iMCTA CAC).
UPower mgtU:
- PA power pooling
UUl load mgtU:
totalRotMax = 6dB
Table 5: summary for HSDPA & HSUPA requirements per topology
other
other
other
Page 22/34
4.5 FOUR CARRIER DEPLOYMENT SCENARIOS
Recommended strategies for Four Carrier deployments are based on Tri Frequency
deployments by adding additional FDD4 carrier with equivalent topology/strategy as
used for FDD2 & FDD3 layers. For further details please refer to section XR R4.4X.

4.6 UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ
UMTS 900 or 850 MHz appears as an interesting deployment solution able to increase
HSxPA cell throughput and increase R99 capacity or decrease number of sites
compared to UMTS 2100/1900 MHz thanks to a better radio propagation at 900/850
MHz than 2100/1900 MHz.
Some topologies may consider deploying U1900 or U2100 layers on top of
U850/U900 coverage layers. Some operators are deploying on first carrier U850/U900
solutions providing FDD1 continuous layer with larger coverage in order to extend
UMTS service.
Some other operators deploy U850/U900 carriers mainly in areas where does not
exist U1900/U2100 layers. In this case U850/U900 is deployed to complement the
U1900/U2100 coverage, originating small overlap between different bands. Handover
mobility solution in such scenario may be difficult to manage due to the problematic of
triggering Alarm to rescue calls between layers that have limited overlay and different
exit zones. In these cases, for PS calls, Inter Frequency mobility can be achieved
during cell reselection period when in Cell_FACH/URA_PCH. For CS calls, feature
34224 may be used to activate the simultaneous compressed mode allowing an HHO
to GSM in case of 3G coverage lost.
Usually, the most important constraint to deploy UMTS 900/850 MHz is the frequency
band available by the operator knowing that this frequency band is already used for
GSM network.

Figure 5: Example for mixed frequency deployment scenarios

GSM
U900
GSM GSM GSM
U2100 F0 U2100 F0
GSM
U2100 F0
U2100 F1
GSM
U900
U900
Page 23/34
Previous recommendations provided in sections XR R4.3X and XR R4.4X consider that cell sizes
are equivalent. However, in case deploying U1900 or U2100 layers on top of
U850/U900 coverage layers, it may happen that strategies for Cell
Selection/Reselection and RRC Redirection may be readapted. The following
adaptations may be considered:
Cell Selection/Reselection: qOffset2sn should be tuned when 3G carriers are
on different frequencies (900 or 850 to 1900 or 2100) or when upper layers
are hot spot in order to setup call in preference in more clean layers;
RRC Redirection: RRC Redirection to Twin Cells could be provisioned only
from U1900/U2100 to U850/U900 since FDD1 coverage may be bigger than
upper layer coverage.

4.7 TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION
The following recommendation is based on typical solutions for inter frequency
neighbours declarations. Extension of the number of UMTS FDD Neighbouring cells in
the neighbourhood list in Sib11/12 and in Cell_DCH is limited to:
Up to 32 intra-Frequency UMTS neighbours (including serving cell);
Up to 32 inter-Frequency UMTS neighbours;
Up to 32 inter-RAT GSM neighbours;
However the following conditions will restrict the number of neighbours that can be
specified in SIB:
Usage of qOffset;
Usage of neighbouringCellOffset & gsmCellIndivOffset;
Different values for CellSelectionInfo parameters between neighbouring and
serving cell;

Figure 6: Typical scenarios for neighbour declaration

Please note that iMCTA Alarm mobility should be always triggered towards a
continuous layer; i.e. if FDD3 is not a continuous layer configuration should avoid
GSM
FDD1
FDD2
FDD2
FDD2
FDD3
FDD1
FDD1
FDD2
FDD1
FDD3
FDD1
Page 24/34
iMCTA Alarm mobility from FDD2 towards FDD3; this can be achieved in UA7 by
appropriate configuration for Alarm Priority Tables;

4.8 CPICH DESIGN CHOICES
Normally the mobility in WCDMA requires identical CPICH power for adjacent cells.
But Cpich Power may have different values across collocated carriers in multi layer
topologies.
FDD1 layer is intended to be the layer providing continuity in the network. For that
reason lowering the initial Cpich Power on FDD1 could have impact on current cell
footprints requiring RF re-design &/OR densification. However, coverage can be ruled
by EcNo rather the by RCSP and Cpich Power reduction on FDD1 can be considered
to increase network capacity in case the area is well covered (good site density). But
Cpich Power reduction on FDD1 should be measured in a cluster basis since CPICH
power differences for adjacent cells can be a source of mobility call drop. On
collocated carriers some operators reduce Cpich Power on upper layers providing
more capacity for traffic channels.
The following recommendations are generic and do not consider the complexity of
different STSR configurations. CPICH design choices can rely on:
Choice 1: keep initial CPICH design on FDD1 layer & (CPICH-2dB) on upper
layers FDDx
o This configuration may be suitable for asymmetric topologies relying
on FDD1 R99 & FDDx HSxPA configurations; this way HSDPA
throughput is maximized and service voice continuity guaranteed;
o Performance for RRC Redirection from FDD1 to FDDx cells should be
carefully monitored;
Choice 2: (CPICH-2dB) on FDD1 cells & (CPICH-2dB) on FDDx cells
o This configuration may be suitable for symmetric topologies relying on
FDD1 & FDDx R99/HSxPA configurations; however, this may impact
on current FDD1 cell footprints requiring RF re-design &/OR
densification;
o FDD1 potential mobility issues at cluster border due to unbalanced
CPICH with adjacent FDD1 cells (however a gap up to 2dB should
work and impact on mobility call drop considered negligible);
o If EcNo coverage is guaranteed there should be no risk of HSDPA
throughput degradation;
o Some RSCP related thresholds may be retuned;

Page 25/34
5 FEATURES RELATED TO SPECIFIC
DEPLOYMENT SCENARIOS
5.1 MULTI-CARRIER PA POWER POOLING (29808)
This feature is available since UA6. It applies to the case where NodeB Power
Amplifier (PA) is shared between two carriers: F1, handling R99 traffic, with HSPA
disabled, and F2 handling HSPA (and possibly R99 as well) traffic.
5.1.1.1 STATIC PA POWER SHARING (FEATURE DEACTIVATED)
When the feature is deactivated, the PA power is shared statically between the R99
carrier and the HSPA carrier. The maximum PA power ratio for each carrier is fixed
(the DL power allocated to a given carrier can not exceed the maximum allowed for
this carrier) and must be set so that the sum of ratios does not exceed 100%. If on the
R99 carrier, a part of DL power is not used (i.e. the DL power currently allocated to
this carrier is below its maximum), it is not possible to reallocate this power to the
HSPA carrier. The static sharing of the power implies that users on HSPA carrier can
not benefit from unused power on R99 carrier to achieve higher throughput.
5.1.1.2 DYNAMIC PA POWER SHARING
The feature Multi-carrier PA Power Pooling optimizes the usage of the PA by allowing
dynamic PA power sharing between F1 and F2 (power overbooking over F1, for the
benefit of F2), improving HSDPA performances without impact on R99 traffic.
The maximum PA power ratio for each carrier is fixed (same as with feature
deactivated): the DL power allocated to a given carrier cannot exceed the maximum
allowed for this carrier. But the maximum PA power ratio for each carrier can be set
so that sum of ratios exceeds 100%. If, on F1 (R99 carrier), a part of DL power is not
used, it is possible to reallocate this power to F2 (HSPA carrier).
The feature does not impact the R99 power allocation: although HSDPA traffic may
use an important part of PA power, the R99 traffic has full priority for power allocation.
The feature does not impact the DL CAC and DL iRM (both mechanisms apply to R99
traffic): the DL CAC and DL iRM are based on the maximum PA power ratio set for the
considered carrier.
The figure below shows the benefit of the PA power overbooking.

Page 26/34
Figure 7: PA Power overbooking

The dynamic PA power sharing between the two carriers F1 and F2 consists,
basically, in keeping paRatio(F1) at the same value as before feature activation,
increasing paRatio(F2) w.r.t the value before feature activation, and setting the
maxTxPower for each carrier to a value consistent with the chosen paRatio.

Impact on HSDPA power allocation at RNC and NodeB
The formula describing the HSDPA power allocation at RNC and NodeB are recalled
here for convenience. Please refer to the section 8 in the Volume 3 for more
information.
At RNC:
P B
max Hspa
B (F2) [dBm] =Max Tx Power (F2) [dBm] maxHspaPowerOffset (F2)
Engineering Recommendation: maxTxPower and Multi-Carrier PA Power Pooling
When the Multi-Carrier PA Power Pooling is used, the maxTxPower assigned to each carrier,
noted maxTxPower(Fx), is recommended to have the same ratio as the PA ratio attributed to each
carrier, as shown in the following formula.
maxTxPower(Fx) maxDlPowerCapability(Fx)
With maxDlPowerCapability(Fx) (dBm) =maxPowerAmplification +10*log( paRatio(Fx)/100) +Tx
Losses (dB)
p
a
R
a
t
i
o
(
F
1
)
p
a
R
a
t
i
o
(
F
2
)
R99
HSDPA
GBR,
R99
100%
0%
R99
GBR,
R99
HSDPA
p
a
R
a
t
i
o
(
F
1
)
p
a
R
a
t
i
o
(
F
2
)
Power
not used
P
A

P
o
w
e
r

R
a
t
i
o
Fixed
partitioning
UStatic PA Power sharingU (feature
deactivated):
paRatio must follow the rule:
paRatio (F1) +paRatio (F2) 100%
UDynamic PA Power sharingU :
paRatio can be set as follows:
paRatio (F1) +paRatio (F2) >100%

Page 27/34
At NodeB:
P B
HSDPA
B (F2) [W] =Min {P B
max Hspa
B (F2) [W] ; PA Power - P B
Total Non HSDPA with Margin
B }
with PA Power =Max Power Amplification [W] - Tx Losses
and P B
B = Total non HSDPA power over both carriers
measured at NodeB each COMMON MEASUREMENT period
(includes DCH Margin used to anticipate fast variation of DCH power)
P B
B =
(1+dchPowerMargin/100)x (P B
Total Non HSDPA
B [W] (P CPICH (F1)+(P CPICH (F2))
+(P CPICH (F1)+(P CPICH (F2))
The principle is identical with or without the feature activated: HSDPA takes the
remaining power after power has been allocated to R99 on both carriers. The feature
does not impact R99 power allocation.

Impact on DL CAC and DL iRM
When the Multi-Carrier PA Power Pooling is activated, the DL call admission control
and DL iRM for R99 traffic, performed at the RNC, is slightly revisited to compensate
the increase of the maxTxPower configured for the HSPA carrier.
This is only applicable for the HSPA carrier; the DL call admission control and DL iRM
for the R99 carrier remains the same. Refer to XR R[R01]X for the description of these
features.
The DL CAC and DL iRM algorithms use the PB
traffic
B (maximum DL R99 traffic allowed).
When the feature 29808 is not activated, PB
traffic
B is defined as below (refer to the section
8 in the Volume 3)
PB
traffic
B[W] =Max Tx Power B

B[W] PB
minHsdpa
B[W]
- P CCC. Activity Factor Ccch P E-DCH - P OCNS

When the feature 29808 is activated, the PB
traffic
B formula above remains unchanged on
R99 carrier (F1) but it is redefined on HSPA carrier (F2). Max Tx Power on F2 would
not necessarily reflect the actual maximum power available (especially if high traffic on
F1) due to power overbooking, so PB
traffic
B must be scaled down accordingly, as
indicated in the formula below.
PB
traffic
B(F2)[W]= (PB
maxCell
B(F2)[W]PB
minHsdpa
B(F2)[W]) / (1+paOverbookingRatio/100)
- P CCC(F2). Activity Factor Ccch P E-DCH - P OCNS
paOverbookingRatio must be set as follows:
Max Tx Power (F1) +Max Tx Power (F2) =(1+paOverbookingRatio/100) . PA Power

Page 28/34
5.1.1.3 SUPPORTED RADIO CONFIGURATIONS
The feature 29808 Multi-Carrier PA Power Pooling is available when a PA is shared
between one R99 carrier (HSPA disabled) and one HSPA carrier (this HSPA carrier
may support R99 traffic as well). No dynamic power reallocation is planned between
two HSPA layers.
The following radio configurations support the feature 29808, provided the two rules
below are fulfilled.
STSR2
STSR2+1
STSR2+2
The configuration STSR2 * 6 sectors does not support the feature 29808.

Rule: radio configurations rules for Multi-Carrier PA Power Pooling
URule 1U:
The feature Multi-Carrier PA Power Pooling is activated if there is only a maximum of one carrier
per PA with HSDPA activated and a maximum of one carrier on the same PA without HSDPA
activated. In other words, it is not possible to activate the feature in STSR2 with both carriers with
HSDPA (nor with both carriers without HSDPA).
URule 2U:
The feature Multi-Carrier PA Power Pooling is activated if the cells on the R99 carrier and the cells
on the HSPA carrier which shares the same PA (i.e. their respective local cell groups LCG have the
same frequencyGroupId) also share the same CEM pool (same r99ResourceId).

UIllustration of the Rule 1U:
STSR2+2 configuration, with PA1 (F1: R99_Only + F2: HSDPA) and PA2 (F3:
R99_Only +F4: HSDPA) supports the feature 29808.
STSR2+2 configuration, with PA1 (F1: R99_Only +F2: HSDPA) and PA2 (F3 & F4:
R99 only) does not support the feature 29808.
UIllustration of the Rule 2U:
STSR2+1 configuration, with PA1 (F1: R99_Only +F2: HSDPA) and PA2 (F3: HSDPA
or R99_Only).
The Rule 2 means that the Multi-Carrier PA Power Pooling can be activated only if
CEM pool1 serves F1+F2 and CEM pool2 serves F3.
Concretely, the settings shall be:
Cells belonging to F1 : BTSEquipment/LocalCellGroup frequencyGroupId =0
BTSEquipment/LocalCellGroup r99ResourceId =x
Page 29/34
BTSEquipment/LocalCellGroup r99ResourceId =x
BTSEquipment/LocalCellGroup r99ResourceId =y

5.1.2 PARAMETER SETTINGS AND RECOMMENDATIONS
5.1.2.1 RAN MODEL

RNC
RadioAccessService
DedicatedConf
EdchCellClass HsdpaCellClass
NodeB
FDDCell
maxTxPower
activityFactorCcch
15 32
OMC-R
eagchErgchEhichTotalPower
Number of instances
(indicated when > 1)
minimumPowerForHsdpa
maxHspaPowerOffset
paOverbookingRatio
Class2CellReconfParams
Class3CellReconfParams
OMC-B
BTSEquipment
BTSCell
HsdpaConf
dchPowerMargin
PaResource
maxPowerAmplification
12
isPowerPoolingActivated
paPoolingActivation
paRatio

5.1.2.2 OMC-R PARAMETERS
minimumPowerForHsdpa: For the considered cell, offset relative to Max Tx Power of
this cell used to reserve power for HSDPA non-GBR traffic, regarding DL CAC and DL
iRM of R99 and HSDPA GBR traffic (PB
traffic
B formula). For the detailed description of the
parameter (parameter frame with explicit recommended value, engineering rule),
please refer to XR R[Vol. 3]X, section 8.4.

maxHspaPowerOffset: For the considered cell, offset relative to Max Tx Power of this
cell, used to set the maximum allowed power for HSDPA non-GBR traffic and E-DCH
DL channels (PB
maxHspa
B formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to XR R[Vol. 3]X, section
8.2.1.
Page 30/34
paOverbookingRatio: When 29808 is activated, factor used to scale down available
DL power for R99 and HSDPA GBR traffic (i.e. PB
traffic
B on F2, in order to avoid potential
impact of 29808 on DL CAC and DL iRM in F2.
Regarding the method to determine the appropriate value for paOverbookingRatio
according to paRatio and maxTxPower settings, please refer to XR R5.1.1.2X, Impact on
DL CAC and DL iRM (PB
traffic
B formula with 29808 activated) and XR R5.1.2.4X.
Parameter paOverbookingRatio
Object HsdpaCellClass
Granularity HsdpaCellClass
Value 30

eagchErgchEhichTotalPower: For the considered cell, power reserved for E-DCH
DL channels, regarding DL CAC and DL iRM of R99 and HSDPA GBR traffic (PB
traffic
B
formula). For the detailed description of the parameter (parameter frame with explicit
recommended value), please refer to XR R[Vol. 4]X, section 4.2.
isPowerPoolingActivated: For the case where NodeB PA is shared between two
carriers (F1 for R99 traffic and F2 for HSPA (+R99) traffic), flag enabling dynamic PA
power sharing between F1 and F2, at cell level.
Parameter isPowerPoolingActivated
Object FDDCell
Granularity FDDCell
Value F1: False
F2: True

activityFactorCcch: For the considered cell, common channels activity factor used in
power reservation for common channels, regarding DL CAC and DL iRM of R99 and
HSDPA GBR traffic (PB
traffic
B formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to XR R[Vol. 3]X, section
8.2.1.

maxTxPower:
For the considered cell, used to set maximum allowed Tx power for all DL physical
channels added together (common +traffic), at the reference point. maxTxPower
value takes into account power partitioning between cells served by the considered
PA. For the detailed description of the parameter (parameter frame with explicit
recommended value, engineering recommendation), please refer to UA7 UPUG
XR R[R01]X, Vol.8, section 3.2.1.
Page 31/34
Regarding the method to determine, on a given carrier, the appropriate value for
maxTxPower according to paRatio setting on the same carrier, please refer to
section of this volume.

5.1.2.3 OMC-B PARAMETERS
paPoolingActivation: For the case where NodeB PA is shared between two carriers
(F1 for R99 traffic and F2 for HSPA (+R99) traffic), flag enabling dynamic PA power
sharing between F1 and F2, at NodeB level.
Parameter paPoolingActivation
Object BTSEquipment
Value True

paRatio:
For the case where NodeB PA is shared between multiple carriers, maximum allowed
ratio of PA power for the considered cell. For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to UA7 UPUG XR R[R01]X,
Vol.8, section 3.2.2.
For the case where NodeB PA is shared between two carriers (F1 for R99 traffic and
F2 for HSPA (+R99) traffic), and 29808 is activated, recommended settings for
paRatio are as follows.
F1: paRatio =50%; F2: paRatio =80%

dchPowerMargin: For the considered cell, used to set the DCH Margin (which aims
at anticipating fast variation of DCH power) in computation of maximum allowed power
for HSDPA non-GBR traffic and E-DCH DL channels (PB
maxHspa
B formula). For the
detailed description of the parameter (parameter frame with explicit recommended
value), please refer to XR R[Vol. 3]X, sections 8.
maxPowerAmplification: Maximum allowed PA output power. For the detailed
description of the parameter (parameter frame with explicit recommended value),
please refer to UA6&UA7 NodeB PEI XR R[R03]X, section 9.3.1.

Page 32/34
5.1.2.4 OTHER RECOMMENDATIONS
PA OVERBOOKING RATIO
The PA overbooking ratio should not exceed 130%.
For recall, the PA overbooking ratio is: (Max Tx Power (F1) +Max Tx Power (F2)) / PA
Power
URationaleU:
Assuming that paRatio (F1) is set to 50%, the PA overbooking ratio
theoretical limit is 150% (if operator allows F1 power to be transferred in
totality to F2 when no traffic on F1).
In practice a certain amount of power is always required for F1 (common
channels, ).
The system stability must be guaranteed.
UParameter settings to apply a PA overbooking ratio below 130%U:
paRatio (F1) +paRatio (F2) 130
maxTxPower (Fx): Set according to paRatio (Fx),
as explained above in XR R5.1.1.2X.
paOverbookingRatio :
Set according to Max Tx Power (F1), Max Tx Power (F2) and PA Power,
as explained above in XR R5.1.1.2X.
UExampleU:
Assumptions: MCPA 60W, maxPowerAmplification = fullMode, Tx Losses =
1.3dB, paRatio(F1) =50%, PA overbooking ratio =130%
paRatio (F2) =80%
maxTxPower (F1) =47.8dBm +10*log(50%) -1.3 =43.5dBm
maxTxPower (F2) =47.8dBm +10*log(80%) -1.3 =45.5dBm
paOverbookingRatio =30

CPICH TX POWER SETTING ON F2 (when 29808 is activated)
URecommendationU:
It is recommended to increase CPICH Tx power so that CPICH Tx power to Max Tx
Power(F2) ratio remains the same as before 29808 activation.
UPossible optimizationU:
According to simulations, the optimal CPICH Tx Power on F2 depends on average
extra-cell interference in F2.
Based on the average level of extra-cell interference in F2 (measured via CPICH
Ec/N0 at UE), following optimization may be performed:
Page 33/34
High extra-cell interference
High CPICH Tx Power is required
In this case, it is recommended to apply to the CPICH Tx Power the same
increase as the one applied to maxTxPower.
e.g. pcpichPower (F2) =maxTxPower (F2) - x dB
Low extra-cell interference
CPICH Tx Power may be set to a lower value (in order to save power for
HSDPA traffic), e.g. it may be kept at the same value as before the feature
activation.
e.g. pcpichPower (F2) =50% . PA Power - x dB

Page 34/34

END OF DOCUMENT

END OF DOCUMENT

HPUG UA7 Preliminary External V04.05 Jun10

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

HPUG UA7 Preliminary External V04.05 Jun10

Hochgeladen von

Copyright:

Verfügbare Formate

HSxPA Parameters User Guide

Document number: UMT/IRC/APP/016664

Das könnte Ihnen auch gefallen