HPUG UA08 V05.04 Preliminary Ext

HSxPA Parameters User Guide
Document number:
Document issue:
Document status:
Date:
UMT/IRC/APP/016664
V05.04
UA08.1 Preliminary
16/Mar/2012
External Document

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 1 : Introduction
CONTENTS
1
INTRODUCTION..........................................................................................................12
1.1
OBJECT ..................................................................................................................... 12
1.2
SCOPE OF THIS DOCUMENT .............................................................................................. 13
1.3
AUDIENCE FOR THIS DOCUMENT ........................................................................................ 13
1.4
NOMENCLATURE ........................................................................................................... 14
1.5
RELATED DOCUMENTS .................................................................................................... 16
PARAMETERS ORGANIZATION...................................................................................17
ABBREVIATIONS ........................................................................................................19
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
PUBLICATION HISTORY
16/03/2012
Issue 05.04 / EN,
Updates:
In Volume 1:
History update;
In Volume 2:
Update of information for MIMO UE categories (number of HARQ
processes).
Other format changes and overall spelling/content review.
In Volume 3:
Rewriting
of
engineering
recommendation
minimumHsdschCreditPerTtiInNumberOfPdus
minimumHsdschCreditPerTtiInBytes, following
for
redesign
parameters
and
of feature
PM97431.
Correction of formula for Proportional Throughput scheduler cost, when
R < serviceMinRate.
Inclusion of engineering recommendation on parameter hsdpaAmpUsage
to prevent power spikes and PA alarms due to too high power usage.
Rewriting of Power Measurements section to consider fast PMM
measurements introduced with feature PM75998 (also removal of note stating
change in power measurements reporting period).
Clarification of MAC-d priority queue accessing by schedulers in Dual Cell
configuration.
Detailing of figure presenting relation between RLC PDU, MAC-d SDU/PDU
and MAC-hs SDU/PDU.
Inclusion of engineering recommendation on prohibitedStatusTimer for
networks with high penetration of low-rate capable HSDPA UEs.
Correction of default value for parameter hsdpaSpiRelativeWeight, as
previous one was not relevant in terms of user differentiation.
Description of parameters waitTimeBeforeHspaDeactivation and
waitForResourceReleaseForHsxpaConfiguration and associated setting
recommendations.
Correction of class of parameter hsdpaActivation.
Page 2/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Update value of parameter eligibleUeCategoryForSirTargetHsdpa to
include category 19 and 20 HSDPA UEs.
Removal of contents related to feature PM34465.
Clarification of meaning of letters in CQI mapping tables used for 64-QAM.
Inclusion of subfeature of PM34246 in features list.
Correction of value for parameter isDualCellAllowedForUeCategory.
In Volume 4:
Change recommended values for 82602/R2 thrThresholdForActiveState
and thrThresholdForInactiveState.
Correction regarding the usage of {Reference E-TFCI; Reference Power
Offset} tables instances suffixed with eCEM (they are used)
Correction for feature 30742 MBR Handling in MAC-e Scheduler: it is
applicable to UCU-III. Activation flag updated.
Update regarding consistency rule for edchLoadEstimationAlgorithm
and hspaHardwareAllocation: if the first one is SIR_BASED, the second
one must be xCemOnly in UA7 and iCemNever in UA8.
Update
regarding
consistency
rule
for
edchOlpcInactivitySirDecreaseLimit : it must be bounded with minimum

Sir Target and maximum Sir Target.
Change
the
recommended
value
for
PM121085
parameter
edchOlpcInactivitySirDecreaseLimit
Additional details on the behaviour of PM121085 in case of mobility leading
to imbalance SIR conditions
Change the recommended value for G-Rake activation: it is not
recommended anymore due to lack of benefit observed in the field.
Clarification about the parameter edpchInfoClassId
Clarification about the RLC throughput per EDCH UE Categories
In Volume 5:
Update of RAB combinations allowed for HSDPA and HSUPA.
Additional details on radio conditions for configuration of SRB on HSPA with
F-DPCH.
Inclusion of section with interaction between PM29810 and Always-On
transitions.
Inclusion of section with interactions between PM29810 and Dual Cell
operation.
Page 3/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Addition of RAN path in tables for parameters description for feature
PM82602/R3.
Large update of section on multi-RAB handling on HSxPA, taking into
consideration new RAB combinations available in UA08.1, in particular 3 PDP
context support in GM (PM81449) and Hsdpa / Edch user service profiles.
Change of recommended setting for parameter isThreeRabAllowed for
Global Market.
In volume 6:
Clarification
regarding
the
usage
of
the
parameter
isEdchIurRestrictionEnabled.
Clarification regarding the enhancement 367062 Reconfiguration SRB EDCH
to DCH 3.4kbps in case of loss of EDCH Macro-Diversity for the Uplink SRB.
Update of description of parameter mobilityServiceType, with new
location under HsdpaCombination object.
In volume 7:
Global content review.
Section DEPLOYMENT STATUS updated to clarify the use of x/eCEM
modules.
Section CELL RESELECTION FOR UA08 DEPLOYMENTS revisited/enhanced.
Section IMCRA FOR UA08 DEPLOYMENTS revisited/enhanced.
Section SPECIFIC HANDLING OF NETWORKS WITH MORE THAN 3
CARRIERS revisited/enhanced.
Section
TYPICAL
revisited/enhanced.
SCENARIOS
FOR
NEIGHBOR
DECLARATION
New section introduced named TYPICAL STRATEGY FOR IRAT MOBILITY

New section introduced named TYPICAL STRATEGY FOR SMALL CELLS
MOBILITY
30/09/2011
Issue 05.03 / EN,
Updates:
In Volume 1:
History update;
Update of abbreviations list.
Page 4/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
In Volume 2:
Inclusion of feature PM32520 - HSDPA AND E-DCH Service Indicator;
Correction of reference list;
Restructuring of sections with separated descriptions for iCEM and
xCEM/eCEM, placing some for focus on the latter;
Update of information for MIMO categories (number of HARQ processes and
modulation);
In Volume 3:
Restructuring of sections with separated descriptions for iCEM and
xCEM/eCEM, placing some for focus on the latter;
Removal of description of parameter activityFactorCcch (replaced by
reference to UPUG, on which CAC procedure is described);
Reorganization of section 8 (power management) with inclusion of features
PM75998 and PM29808, moving of sections covering hsdpaAmpUsage and
HS-SCCH power;
Correction of range of maximumTokenGenerationRate parameters for
UL and DL;
Clarifications in description of parameters defining the maximum number of
simultaneous DC-HSDPA users;
Removal of section 9.1 (moved to Volume 2) on feature PM32520 - HSDPA
AND E-DCH Service Indicator;
In Volume 4:
Change recommended value for parameters nHarqRetransTargetS1,
nHarqRetransTargetS2, nHarqRetransTargetS3 for SRB_EDCH
Clarification
regarding
the
NodeB
internal
power
checks
rules
on
eagchPower, ehichPowerSignature and ergchPowerSignature.

Correction for the content of 10ms_2xSF4_xCEM reference power offset
Reorganization of section 4 (Power management for E-DCH) with inclusion
of iCEM specific features for UL load previously described in section 6(Mac-e
scheduler for iCEM).
Change recommended values for edchThrRatioForHarqRetransTarget1,
edchThrRatioForHarqRetransTarget2,
nHarqRetransPowerLimitTarget2.
Removal of parameter guardTimeForNHarqTargetChange
Page 5/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Removal of section 8 (Iu user traffic conformance): MBR feature is now
described in section 6 (MAC-E scheduler).
Reorganization of section 6 (Mac-e scheduler for iCEM) and section 7 (Mac-e
scheduler for xCEM, eCEM, UCU-III): both sections merged into one and focus
done on xCEM, eCEM and UCU-III.
Removal of section 11 OneBTS Parameters: OneBTS Parameters spread in
the relevant sections.
In Volume 5:
Clarifications on criteria used for F-DPCH and SRB on HSPA configuration,
interactions with feature PM33581 and UL power control configuration;
Correction of title of table 9;
Inclusion of old section 2.2 in RAB Matching section (chapter 3.1);
Correction for 125171/125567 E-DCH Enhanced NodeB CAC: the CAC
formula for UCU-III is corrected and the recommended value for credits on
UCU-III is updated.
Addition of a global overview of HSXPA CAC features and restructuring of
sections with separated description for HSDPA CAC and EDCH CAC
Modification of the recommendation for the E-DCH CAC features: RNC EDCH
CAC (34441.1) is not needed as soon as NODEB EDCH CAC (125171/125567
and 82602/R3) are activated.
Clarification for EDCH fallback mechanisms.
In Volume 6:
Section 3.3.5 added to describe SRB over HSDPA to SRB DCH 3.4KBPS
reconfiguration.
In "Figure 3: E-DCH macro diversity general principle", it said "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."
Replaced CFN by TTI in section 3.3.3.1.1.
In section 3.3.3.1.1, added condition the new added cell is not over Iur
when SRB on EDCH is used.
Refined the description and formulas used in sections 3.3.3.1.4, 3.3.3.2.3
and 3.3.3.2.4.
Refined text in section 3.6.
Corrected typo in section 4.3.
Added the definition of TMA in section 3.2.
Page 6/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
In section 3.3.3.2.2 figure 4, the maximum number of HoConfClass instance
is up to 60 in UA8.1; correction made.
In Volume 7:
Section 5.1 on PA Power Pooling has been transferred to Volume 3, as
section 8.6;
New section added: SPECIFIC HANDLING OF NETWORKS WITH MORE
THAN 3 CARRIERS;
Overall content review.
22/07/2011
Issue 05.02 / EN,
Updates:
In Volume 1:
History update.
In Volume 2:
Remove of the parameters related to HS-DPCCH power offset. A dedicated
section for HS-DPCCH power management is created in Volume 3.
In Volume 3:
Creation of a section dedicated to HS-DPCCH power management.
Introduction of feature 82602/R7: Adaptive HS-DPCCH power offset
Update values for minimumHsdschCreditPerTtiInNumberOfPdus and
minimumHsdschCreditPerTtiInBytes parameters when feature PM97431
is active (engineering recommendations added)
Update values for hsdschSlowStartActivation parameter when feature
PM97431 is active (engineering recommendations added)
Update of solution description for PM97431, following redesign of the
feature, and inclusion of description in feature overview section
Correction of range of values allowed for serviceHighRate and
serviceLowRate parameters
Introduction of feature 114637 Dual Cell HSDPA support on OneBTS
Introduction of feature 104832/118154 Dual-Cell HSDPA capacity increase
Page 7/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
In Volume 4:
Introduction of feature 82602/R1: Throughput increase in UE power
limitation
Introduction of feature 82602/R2: Enhanced load criterion for adjusting
HARQ retransmissions
Introduction of feature 121085: UL power saving with EDCH OLPC
Introduction of feature 82602/R4: Optimized Iub Congestion Control
Update edpchParameters name and selection algorithm. The content
(reference etfci, reference power offset) is not changed, only naming is
changed.
Update recommended value for maxNrOfErgchEhich:
recommendation is now to use the maximum value 4.
default
Replacement of some reserved parameters (temporary) with new

permanent parameters
Details added on MAC-e scheduler behaviour in case of overload.
In Volume 5:
Introduction of feature 82602/R3: Improved CAC scheme for 2ms TTI users
Introduction of feature 29810: Fractional DPCH and SRB over HSPA
Introduction of feature 125171/125567 NodeB E-DCH CAC Evolution
Update recommendations for edchMaxLegs2msPerCell
Update RAN model concerning the HSPA combinations: the 3-dimensionsarray HsdpaCombinationList.HsdpaCombinationEntry.allowedList is
replaced with a flat structure HsdpaCombination. Same for Edch.
In Volume 6:
Introduction of feature 104832/118154 Dual-Cell HSDPA capacity increase
(part of the feature dealing with the incoming relocation improvement)
Description of the enhancement reconfiguration of SRB from EDCH to DCH
3.4
Add a note on iurEdchDelayVariation (parameter defined but not used by
the system)
In Volume 7:
Complete and exhaustive reorganisation for Carrier Deployment and
Strategy recommendations section to cope with UA08 functionalities. Some
sections were deleted. New sections were included.
New section added: ONEBTS 6 CARRIER 2NB CONFIGURATION (120426).
Page 8/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
25/03/2011
Issue 05.01 / EN,
Updates:
In Volume 1:
History update.
In Volume 2:
Insertion of the RAN Path for all the parametrer description.
In Volume 3:
Update regarding parameter hsdpaResourceActivation.
Correction
of
the
value
(in
MBit/s)
corresponding
to
parameter
maximumTokenGenerationRate.
Additional clarifications on how parameter enhancedQualityOfService
(congestion management) relates with minBR.
In Volume 4:
Update regarding the parameter edchResourceActivation.
Reorganization and updates in the UL Load Management section.
Reorganization and updates in the Priority Info in MACe Scheduler section.
Correction regarding the maximum number of E-DCH Radio Links supported
by one E-RGCH/E-HICH for the xCEM and eCEM: 18 is the maximum instead
of 19.
Update regarding the maximum number of E-RGCH/E-HICH supported by
the UCU-III: it is now 6 (instead of 4). It is unchanged (4) for the xCEM and
eCEM.
Update feature 125855 E-DCH call retainability improvements.
In Volume 5:
Clarification
regarding
the
parameters
edchMaxUsersPerCell
and
edchMaxLegs2msPerCell.
Page 9/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
In Volume 6:
In Volume 7:
Page 10/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
FIGURES
Figure 1: Static and Configuration Parameters
17
Page 11/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 12/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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].
Tag [eCEM] indicates that the behaviour or the feature is specific to eCEM.
The term OneBTS in this document refers only to those NodeBs equipped with
UCU-III board in the US Market.
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 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 the current UTRAN
release.
Restriction: Pico/Micro NodeB

The Pico/Micro NodeB product is out of scope of this document, thus all engg information, algorithms
description and parameters values provided in this document are strictly related to standard AlcatelLucent NodeB products.
See [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
UTRAN Data fill
Trials and FOA
Page 13/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
1.4 NOMENCLATURE
The parameter names are written in bold italic.
The objects names are written in bold.
The parameters properties are presented as follow:
Parameter
Range & Unit
User
Class
Value
Object
Granularity
The protocol messages are written in CAPITAL LETTERS.
The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.
The data fill rules are presented as the following:
The system restrictions are presented as the following:
The engineering recommendations on parameter value are presented as the

following:
Rule:
Restriction:
Engineering Recommendation:
The difference between Release N and Release N-x are presented as the
following:
UAN-x-UAN Delta:
Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o
N.A.: Not Applicable.
N.S.: Not Significant.
Page 14/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
o
O.D.: Operator Dependant (depends on operator network specific

configuration. Example: addressing parameters).
Page 15/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
CEM Capacity Engineering guide
Product Engineering Information
[R06] UMT/SYS/INF/030972
UA08.1 Feature Planning Guide
[R07] UMT/BTS/INF/016135
Micro NodeB & 9314 Pico NodeB Feature

Planning Guide
Page 16/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
2 PARAMETERS ORGANIZATION
In order to understand the definition and the role of the different parameters, it is
appropriate to explain how these parameters are linked together and grouped within
the RAN model.
For more information on the RAN model, please refer to [R01].
RNC
OMC
WPS
Static
WPS Templates
Customer
Non-Static
Manufacturer
CIQ
OMC
database
System DRF
Figure 1: Static and Configuration Parameters
There are two main kinds of parameters in Alcatel-Lucents system, the static and
configuration parameters.
The static parameters have the following characteristics:
They have a fixed value and cannot be modified at the OMC.
They are part of the network element load.
A new network element needs to be reloaded and built in order to change their values.
The customer cannot modify them.
The configuration parameters have the following characteristics:
They are contained in the OMC database.
They are subdivided in two main types: User / Manufacturer.

o
Customer: Can be modified by the customer at the OMC (at the MMI or with
DRFs).
Page 17/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
o
Manufacturer: They represent system constants defined by the manufacturer.

They do not appear at the MMI neither in the DRFs.
Regardless of the parameter type (customer or manufacturer), the parameters can

have the following classes:
o
Class 0: the value of the parameter is set at the parent object creation.
Currently, most of the objects can only be killed and re-created through a new
MIB built (either btsEquipmentMIB or rncMIB).
Class 1: new parameter value is taken into account on the next RNC restart.
This class is no longer valid.
Class 2: parameters of an object created at the OMC-R (respectively OMC-B)

can only be set when the object and its parent are both locked. The new value
will be taken into account after the object is back to working state
(administrative state set to unlocked).
Class 3: parameters of an object created on the OMCR (respectively OMC-B)

can be modified when the object (and parent object) is unlocked. The new
value is taken into account immediately.
Class 3-A1: new value is immediately taken into account.
Class 3-A2: new value is taken into account upon event reception
(service establishment, SRLR).
Class 3-B: new value is taken into account for next call.
Page 18/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
3 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
DCPS
Dual Core Packed Server
DCTM
Dynamic Code Tree Management
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
Page 19/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
E-DCH
Enhanced DCH (also referred as HSUPA or EUL)
E-DPCCH
Enhanced Dedicated Physical Control Channel
E-DPDCH
Enhanced Dedicated Physical Data Channel
E-HICH
Enhanced Hybrid ARQ Indicator Channel
E-RGCH
Enhanced Relative Grant Channel
E-TFC
E-DCH Transport Format Combination
E-TFCI
E-DCH Transport Format Combination Indicator
EUL
Enhanced Uplink (stands for E-DCH)
EVM
Error Vector Magnitude
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
ISI
Inter-Symbol interference
KPI
Key Performance Indicator
LA
Location Area
LAC
Location Area Code
LCG
Local Cell Group
LUT
Look-Up Table
MAC
Medium Access Control
Page 20/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
MCPA
Multi-Carrier Power Amplifier (also referred as PA)
MCS
Modulation and Coding Scheme
MIB
3GPP: Master Information Block;

Alcatel-Lucent RNC/NodeB: Management Information Base
MMI
Man-Machine Interface
MO
Mobile Originated
MPO
Measurement Power Offset
MT
Mobile Terminated
NACK
Negative Acknowledgement
NAS
Non Access Stratum
NBAP
NodeB Application Part
NDS
Non-Delay Sensitive
OAM
Operations, Administration and Maintenance
OCNS
Orthogonal Channel Noise Simulator
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
PSFP
Packet Server Functional Processor
QAM
Quadrature Amplitude Modulation
QoS
Quality of Service
QPSK
Quadrature Phase Shift Keying
RA
Registration Area
RAB
Radio Access Bearer
Page 21/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
RACH
Random Access Channel
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RAT
Radio Access Technology
RB
Radio Bearer
RG
Relative Grant
RL
Radio Link
RLS
Radio Link Set
RLC
Radio Link Control
RMS
Root Mean Square
RNC
Radio Network Controller
RNC-AN
RNC Access Node
RNC-CN
RNC Control Node
RNC-IN
RNC Interface Node
RNS
Radio Network Subsystem (an RNC and its associated NodeBs)
RoT
Rise over Thermal
RRC
Radio Resource Control
RRM
Radio Resource Management
RSCP
Received Signal Code Power
RSEPS
Received Scheduled E-DCH Power Share
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
SE
Spectral Efficiency
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
Page 22/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
SS7
Signalling System 7
S-SCH
Secondary SCH
STM1
Synchronous Transport Module-1 (155.52 Mbit/s)
SW
Scheduling Weight
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
TPR
Traffic-To-Pilot Ratio
TRB
Traffic Radio Bearer
TrCH
Transport Channel
TRM
Transceiver Module
TS
Technical Specification
TTI
Transmission Time Interval
UBR
Unspecified Bit Rate
UE
User Equipment
UL
Uplink
UM
Unacknowledged Mode
URA
UTRAN Registration Area
UTRAN
Universal Terrestrial Radio Access Network
VCC
Virtual Channel Connection
VP
Virtual Path
WiPS
Wireless Provisioning System
Page 23/24

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Z END OF DOCUMENT Y
Page 24/24
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA08
V05.04
16/MAR/2012
Copyright 2011 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
UMT/IRC/APP/016664
CONTENTS
1
INTRODUCTION
HSXPA OVERVIEW
HSDPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
HSUPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
CALL MANAGEMENT
MOBILITY
DEPLOYMENT SCENARIOS
V05.04
16/MAR/2012
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE
INTRODUCTION
V05.04
16/MAR/2012
UMT/IRC/APP/016664
HSXPA OVERVIEW
V05.04
16/MAR/2012

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 2 : HSxPA Overview
CONTENTS
1
INTRODUCTION............................................................................................................4
1.1
OBJECT ....................................................................................................................... 4
1.2
SCOPE OF THIS DOCUMENT ................................................................................................ 4
RELATED DOCUMENTS .................................................................................................5

2.1
HPUG VOLUMES ............................................................................................................ 5
2.2
REFERENCE DOCUMENTS ................................................................................................... 5
SYSTEM OVERVIEW......................................................................................................6
3.1
HSDPA ....................................................................................................................... 9
3.1.1
Transport and physical channels ............................................................................ 9
3.1.1.1
Downlink channels .......................................................................................... 12
3.1.1.2
Uplink channels............................................................................................... 13
3.1.2
Fast link adaptation ............................................................................................ 16
3.1.3
Fast Retransmission Mechanism (HARQ)............................................................... 17
3.1.3.1
Number of HARQ Processes ............................................................................. 17
3.1.3.2
RV Parameters ................................................................................................ 19
3.1.3.3
State of HARQ Processes ................................................................................. 21
3.1.3.4
Choice of the HARQ type ................................................................................. 23
3.1.4
Fast scheduling .................................................................................................. 26
3.2
HSUPA (E-DCH) ........................................................................................................ 28
3.2.1
Transport and physical channels .......................................................................... 28
3.2.1.1
Uplink channels............................................................................................... 30
3.2.1.2
Downlink channels .......................................................................................... 33
3.2.2
UA7 implementation of E-DCH ............................................................................. 36
3.3
HSDPA AND E-DCH SERVICE INDICATOR ........................................................................... 36
4
UE CATEGORIES .........................................................................................................38
4.1
HSDPA ..................................................................................................................... 38
4.2
HSUPA ..................................................................................................................... 39
Page 1/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
TABLES
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1: HSUPA / HSDPA comparison

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1: R99 principle................................................................................................................. 6
2: HSDPA principle ............................................................................................................ 6
3: HSDPA layer2/layer1 flows ............................................................................................. 7
4: MAC-hs entity on UTRAN side......................................................................................... 7
5: Protocol Architecture of E-DCH ....................................................................................... 9
6: UE side MAC architecture ............................................................................................... 9
7: Transport channel configuration (without HSUPA) .......................................................... 10
8: HSDPA channels and associated R99 channels ............................................................... 11
9: HSDPA channels for HSDPA-DC operation...................................................................... 11
10: Timing relationship at NodeB between physical channels............................................... 12
11: HS-SCCH structure..................................................................................................... 13
12: HS-PDSCH structure .................................................................................................. 13
13: HS-DPCCH structure .................................................................................................. 14
14: HS-DPCCH ACK/NACK structure for dual cell/carrier calls............................................... 14
15: HS-DPCCH CQI mapping for dual cell/carrier calls......................................................... 15
16: Example of throughput or BLER versus radio conditions for different modulation............. 17
17: RV parameters assignment algorithm .......................................................................... 21
18: ACK/NACK/DTX management for HARQ processes........................................................ 22
19: Dynamic selection of HARQ type ................................................................................. 26
20: HSUPA channels and associated R99 channels ............................................................. 29
21: E-DPCCH / E-DPDCH frame structure .......................................................................... 31
22: E-DPDCH/E-DPCCH multiplexing on I/Q ....................................................................... 32
23: Uplink physical channels multiplexing .......................................................................... 32
24: E-AGCH frame structure ............................................................................................. 33
25: E-HICH frame structure.............................................................................................. 35
Page 3/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
recommendations.
system
description,
configuration
aspect
and
engineering

This document gives an overview of the HSxPA system.
Page 4/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
UMTS BTS Product Engineering Information
[R09] UMT/SYS/DD/013319
HSDPA System Specification
[R10] UMT/BTS/DD/027736
eCEM/eCEM-U CCM OAM High Level Design
Page 5/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
3 SYSTEM OVERVIEW
HSDPA
3GPP has standardized HSDPA in Release 5 [R01] in order to increase maximum user
throughput for downlink packet data (streaming, interactive and background traffic
classes) and decrease downlink packet transmission delay. This Release 5 is fully
compatible with the previous Release 99 (R99).
In R99, data are transmitted on a dedicated channel with a given user throughput and
a downlink transmitted power controlled according to the radio conditions:
Same Throughput
Unused
Power
Control
Unused Power
Data
Data Power
Figure 1: R99 principle
In HSDPA, data are transmitted on a shared channel by using all the available power
and by controlling the downlink user throughput according to the radio conditions:
100%
Rate
Adaptation
100% Power
Figure 2: HSDPA principle
Typically, a user in good radio conditions will receive his data with a high bit rate
whereas a user in bad radio conditions will receive his data with a lower bit rate.
The efficiency of this rate adaptation is due to a new MAC entity, the MAC-hs layer,
located in the NodeB (see the two following figures), near the physical channel, which
allows a high reactivity in the resource allocation according to the RF conditions
Page 6/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

changes. This MAC-hs layer manages the scheduling of users and the retransmissions
of packets.
RRC
RRC(RNC)
(RNC)
RLC
RLC(RNC)
(RNC)
PCCH BCCH CCCH
MAC Control
CTCH
MAC Control
MAC Control
MAC-hs
MAC-hs
(NodeB)
(NodeB)
DCCH DTCH
DTCH
MAC-d
(S-RNC)
MAC-c/sh
MAC-c/sh
(C-RNC)
(C-RNC)
Associated
Downlink
Signaling
HS-DSCH
Associated
Uplink
Signaling
PCH
R5
R5L1:
L1:HSDPA
HSDPA(NodeB)
(NodeB)
HS-SCCH
HS-PDSCH
HS-DPCCH
FACH
RACH
CPCH
DSCH
DCH
DCH
R99
R99L1:
L1:Channel
ChannelCoding
Coding/ /Multiplexing
Multiplexing(NodeB)
(NodeB)
S-CCPCH
S-CCPCH
PRACH
PCPCH
PDSCH
DPCH
DPDCH/DPCCH
Figure 3: HSDPA layer2/layer1 flows
Figure 4: MAC-hs entity on UTRAN side
HSDPA benefits are based on:
New transport and physical channels.
Fast link adaptation.
Page 7/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Fast retransmission mechanism (HARQ).
Fast scheduling.
Efficient load sharing between anchor and supplementary carriers
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,
16QAM,
64QAM
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.
Page 8/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
DTCH DCCH
DCCH DTCH
MAC-d
MAC-d
MAC-es
MAC-es /
MAC-e
MAC-e
MAC-e EDCH FP
PHY
UE
PHY
Uu
EDCH FP
TNL
TNL
NodeB
Iub
TNL
TNL
DRNC
Iur
SRNC
Figure 5: Protocol Architecture of E-DCH
PC CH BCCH CC CH CTCH SHCC H

( T D D only )
M A C C o ntro l D C C H
DTCH
D TC H
M A C -d
M A C -es /
M A C -e
E -D C H
A sso c ia te d
D o w nlink
S igna lling
A sso c ia te d
U p link
S igna lling
M A C -c/sh
M A C -hs
H S -D S C H
A sso c ia ted
A sso c ia te d
D o w nlink
U p link
S igna lling
S igna lling
PCH
FA C H
FA C H R A C H
C PCH U SCH U SCH D SCH D SC H
DCH
( FD D only ) ( T D D only ) ( T D D only )
Figure 6: UE side MAC architecture
3.1 HSDPA
3.1.1 TRANSPORT AND PHYSICAL CHANNELS
In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on
the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are sent on
a HS-DSCH (High Speed Downlink Shared CHannel) which is mapped on one or
several HS-PDSCH (High Speed Physical Downlink Shared CHannel). Users are
multiplexed on the HS-DSCH channel in time and code. Transmission is based on
shorter sub-frames of 2ms (TTI) instead of 10ms in R99.
Page 9/40
DCH

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

In downlink, the HS-PDSCH channels 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 (or E-DPDCH if HSUPA is used, please
refer to section 3.2),
One HS-DSCH for the DL traffic.
Figure 7: Transport channel configuration (without HSUPA)
Page 10/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following figure summarizes the different channels needed for a HSDPA call:
HS-PDSCH for data (I/B) traffic

HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-DPCCH Feedback information
HSDPA channels
NodeB
HSDPA UE
Associated DPCH for data, speech + SRB traffic
Figure 8: HSDPA channels and associated R99 channels
The maximum bit rate that can be achieved in the UL can be the bottleneck for the
maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP
acknowledgements due to low bandwidth in the UL will limit the DL throughput, even
if the RF conditions would allow more.
From UA04.2, the RB adaptation feature is supported. This feature dynamically adapts
the UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from
8kbps up to 384kbps, but 8kbps is not recommended to be activated (configured as
eligible). Therefore, although UL:8 DL:[max bit rate for low UE categories] 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.
From UA7.1.2, dual cell HSDPA will target DC capable UE using two schedulers on
adjacent carrier cells with following L1 channels on each cell.
Figure 9: HSDPA channels for HSDPA-DC operation

Page 11/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following flowchart describes the timing relations between the different physical
channels:
2 ms
HS-SCCH#1
HS-SCCH#2
2 slots
HS-PDSCH
N_acknack_transmit = 2
HS-DPCCH
ACK
ACK
ACK
7,5 slots
Figure 10: 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 64QAM is explained in [R09])
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/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Tslot = 2560 chips = 40 bits
Data
Slot #0
Slot #2
Slot #1
1 HS-SCCH subframe = 2ms
Figure 11: HS-SCCH structure
A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been
assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this
slot #0, other information are given in slots #1 and 2): the mobile receives a
transport block on one or several HS-PDSCH (see the following figure).
Tslot = 2560 chips = M*10*2k bits (k = 4, SF16)
Data
Slot #0
Slot #1
Slot #2
M= 2 for QPSK
(960 coded bits per TTI)
M = 4 for 16QAM
M = 6 for 64QAM
1 HS-PDSCH subframe = 2ms
Figure 12: 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 HSDSCH 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.5 slots after HS-PDSCH frame, containing (see the following
figure):
The HARQ Ack/Nack;
The CQI (Channel Quality Indication).
Page 13/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Tslot = 2560 chips
= 10 bits
ACK/NACK
Subframe #0
2.Tslot = 5120 chips

= 20 bits
CQI
Subframe #i
Subframe #4
1 radio frame = 10ms

Figure 13: HS-DPCCH structure
For dual cell calls, DC capable UE have to combine the ACK/NACK and CQI for the two carriers
on to the above physical channel structure of HS-DPCCH, which is common between the two
carriers. 3GPP came up with the following mapping for performing this combination:
Figure 14: HS-DPCCH ACK/NACK structure for dual cell/carrier calls
Page 14/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 15: HS-DPCCH CQI mapping for dual cell/carrier calls
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
RAN Path
Range & Unit
User
Class
Value
ackNackRepetitionFactor
Object
RNC / RadioAccessService / HsdpaUserService
[1..4]
Customer
Granularity
3-a2
HsdpaUserService
HsdpaUserService[0..14]
1
Note: Because of 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][eCEM]

Only value no repetition (ackNackRepetitionFactor = 1) is allowed, since xCEM and eCEM
support only this value.
The CQI is only sent in some specific subframes, as specified in [R04] 6A.1.1,
depending on the following parameters:
The CQI feedback cycle: k,
The repetition factor of CQI: N_cqi_transmit.
Page 15/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
cqiRepetitionFactor
Parameter
RAN Path
Range & Unit
User
Class
Value
cqiFeedbackCycleK
Object
[1..4]
Customer
Granularity
3-a2
HsdpaUserService
1
Object
Enum {0, 2, 4, 8, 10, 20, 40, 80, 160} ms
Customer
Granularity
3-a2
HsdpaUserService
Restriction: cqiFeedbackCycleK and [xCEM][eCEM]

Since UA7.1.2, new CQI information transmission (cqiFeedbackCycleK) has been limited to
maximum of 20msec apart, irrespective of whether DC feature PM81204 is enabled or not and the
OAM available range.
Rule: cqiRepetitionFactor and cqiFeedbackCycleK

These parameters have to respect the following rule:
cqiRepetitionFactor cqiFeedbackCycleK / 2
Note that cqiFeedbackCycleK = 0 is not supported.
Please refer to Volume 3 for a description of the HS-DPCCH power management.
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 terms of modulation depend on their
category:
-
categories 11 and 12 support only QPSK,
categories lower or equal to 10, 15, 16, 21 and 22 support QPSK and 16QAM
(categories 15 and 16 support MIMO)
categories 13, 14, 17, 18, 23 and 24 support QPSK, 16QAM and 64QAM
(categories 17 and 18 support MIMO)
Page 16/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

16QAM modulation achieves higher bit rate than QPSK and 64QAM modulation allows
even higher bit rate than 16QAM. The following figures illustrate the gain (in terms of
throughput or BLER) according to the modulation:
AMC Illustration
800
QPSK
QPSK
QPSK
16QAM
16QAM
700
Throughput (kbps)
600
500
400
300
200
100
0
-20
-15
-10
-5
Ior/Ioc (dB)
Figure 16: 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]:
[xCEM][eCEM]
Ue Category
10
11
12
Number of HARQ Processes
Ue Category
13
14
15
16
17
18
19
20
21
22
23
24
12
12
12
12
12
12
Table 2: Number of processes per UE category for xCEM and eCEM

Page 17/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[UCU-III]
Ue Category
10
11
12
Ue Category
13
14
15
16
17
18
Table 3: Number of processes per UE category for UCU-III
[iCEM]
Ue Category
10
11
12
Table 4: Number of processes per UE category for iCEM
Category 21 to 24 have 12 processes when configured with dual cell call (6 for each
cell) else these also have 6 processes for single carrier HSDPA calls.
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:
[xCEM][eCEM]
Parameter
RAN Path
Range & Unit
User
Class
Value
harqNbMaxRetransmissionsXcem
BTSEquipment / BTSCell / HsdpaConf
[131] decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
7
[UCU-III]
For UCU-III, the maximum number of retransmissions is set to 10.
[iCEM]:
Parameter
RAN Path
Range & Unit
User
Class
Value
harqNbMaxRetransmissions
[131] decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
7
[iCEM][xCEM][eCEM]:
Page 18/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The two following parameters are common for iCEM, xCEM and eCEM (RNC
parameters):
Parameter
RAN Path
Range & Unit
User
Class
Value
discardTimer
Object
HsdpaUserService
Enum [20; 40; 60; 80; 100; 120; 140; 160; 180 ; 200; 250; 300; 400; 500; 750;
1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500] ms
Customer
Granularity
3-a2
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
timerT1
Object
HsdpaUserService
Enum [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, 400] ms
Customer
Granularity
3-a2
100
This parameter is used by the NodeB to stop the re-transmission of the corresponding
MAC-hs PDU (but ignored by the iCEM).
[UCU-III]
For UCU-III, the discard timer is set to 2000 msec and timerT1 is at 200 msec.
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:
Page 19/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Xrv (Value)
Table 5: RV coding for 16QAM
Xrv (Value)
Table 6: 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
Page 20/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

be sent again (this ensure no systematic bits are lost, because all blocks may
not be self-decodable).
Y
New transmission ?
Xrv = Trv[0]
k=0
N
DTX indication ?
Xrv(n) = Xrv(n-1)
N
k=k+1
Xrv(n) = Trv[k mod Nmax]
Nmax = 1 (CC)
= 4 (PIR - QPSK)
= 6 (PIR 16QAM)
= 8 (MIR)
Figure 17: RV parameters assignment algorithm
An update table is defined per HARQ type as described in section 3.1.3.4.
3.1.3.3 STATE OF HARQ PROCESSES

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

HARQ process assigned
by the scheduler
Update of RV parameters
Data transmission
Wait for ACK/NACK

reception
ACK
WACK state
DTX
ACK/NACK/DTX ?
Insertion of DTX
indication
NACK
Reset HARQ process
Remove Mac-d PDU
Update structures
Nret = Nret +1
Nret > Nret_max ?
N
NACK/DTX state
Wait for
retransmission
Figure 18: 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 22/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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

[xCEM][eCEM]
The HARQ type selection is done through the parameter harqTypeXcem:
harqTypeXcem
Parameter
RAN Path
Range & Unit
User
Class
Value

[ccType, irType]
Customer
3
Object
HsdpaConf
Granularity
BTSCell
irType
The following tables give according to [R03] the redundancy version and constellation
depending on the modulation:
Xrv(QPSK)
Xrv(16QAM)
Xrv(64QAM)
Table 7: RV update table in the IR case (Trv[i])
[xCEM] [eCEM]:
i
Xrv(QPSK)
Xrv(16QAM)
Xrv(64QAM)
Table 8: RV update table in the CC case (Trv[i])
[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:
Page 23/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
The Chase Combining option corresponds to the first redundancy version

always applied for all (re)transmissions.
The PIR indicates that for all redundancy versions, the systematic bits must
be transmitted (blocks are self-decodable). Only the RV with s = 1 must be
taken into account.
The MIR corresponds to a sequence where both systematic and nonsystematic bits can be punctured. All possible redundancy versions are
assumed and it corresponds to default version.
Each HARQ type is characterized by its update table Trv (see tables below):
Xrv(QPSK)
Xrv(16QAM)
Table 9: RV update table in the MIR case (Trv[i])
Xrv(QPSK)
Xrv(16QAM)
Table 10: 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).
Page 24/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 11: RV updates tables when harqType set to Dynamic Redundancy

The principle is that incremental redundancy is only selected when required, i.e. as
soon as punctured bits by the 2nd Rate Matching stage AND total number of softbits
per HARQ process the UE can handle are higher than the number of transmitted bits.
Otherwise, chase combining is sufficient. In case of IR, it is only necessary to
puncture systematic bits (FIR) in case it is not possible to transmit all parity bits
punctured by the 2nd RM stage in the first retransmission.
More in detail, during the Rate Matching step, following variables are computed:
NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes times
the modulation order (2 or 4) times 960 bits.
NIR: total number of softbits per HARQ process the UE can handle. It only
depends on the UE category and the number of allocated HARQ processes.
NSYS: number of systematic bits (not equal to transport block size).
NP1 and NP2: number of parity bits 1 and 2 after 1st RM step.
NRM1 = NSYS + NP1 + NP2
NPUNC2 = NRM1 - NDATA: number of bits punctured by 2nd RM stage.
These values are then used to select the right HARQ type as explained by the
following figure:
Page 25/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 19: Dynamic selection of HARQ type
Note: As the RV of the 1st transmission is identical whatever the HARQ type is,
previous variables should then be stored during the rate matching of the first
transmission. The HARQ Type only needs to be determined when 1st retransmission
occurs.
Parameters Settings:
See [Vol. 3].
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.
[xCEM][eCEM]
The aim of the scheduler is to share the resources between the different HSDPA
users. xCEM and eCEM schedulers work in the following steps:
-
To select a limited number of users from those which are ready for
transmission in the current TTI (the number of users per TTI being
Page 26/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

limited by the number of HS-SCCH configured and by the available
resources mainly in terms 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 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 xCEM and eCEM, 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.
Since UA7.1.2, xCEM and eCEM will also be able to serve Release 8 capable UE
simultaneously on two adjacent carriers to improve inter-dual cell load sharing and
double the throughput over all the radio conditions. Two independent schedulers (one
for each cell) are fed from common priority queue for a given user.
[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 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).
The main concepts of the scheduler are:
Retransmissions are of higher priority than new transmissions and should be

scheduled first.
The Queue ID (QId) is chosen according the Scheduling Priority Indicator (SPI
or CmCH-PI) and the radio condition based on CQI.
The transport blocks should always be optimized according to the transmitted

CQI when possible (if enough codes and power are available and if theres no
CPU limitation).
No queue ID should be left starving, i.e. the scheduler should always allocate
even a small part of radio resources to all users (even those with low priority
and bad CQI).
From UA5.0, the MAC-hs scheduler has been enhanced (29807 MAC-hs scheduler
improvement) in order to support 2 MAC-hs scheduler types (Classical Proportional
Fair, ALU Proportional Fair,) and manage SPI.
Page 27/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
3.2 HSUPA (E-DCH)

3.2.1 TRANSPORT AND PHYSICAL CHANNELS
HSUPA proposed the following set of new physical channels:
E-DPCCH carries the UL signaling information
E-DPDCH carries the data traffic
E-HICH (Hybrid ARQ Indicator Channel) in DL to indicate if the UL

transmission are well received (ACK/NACK channel)
E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) in

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
H
PD
C
E-
HI
CH
EA
GC
ERG
H
CH
ED
E-
DP
CC
Figure 20: HSUPA channels and associated R99 channels

A specific E-DCH transport channel is defined. As the classical DCH transport channel
it allows to offer transport services to higher layers. The E-DCH transport channel is
characterized by:
Only for UL
Two possible TTI : 10ms and 2ms
Transport block size and Transport Block set size are free attributes of the
transport format.
Possibility of HARQ process with retransmission procedures applied at NodeB.

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

Remark: In UA6, only Incremental Redundancy type of E-DCH HARQ is
supported. harqType parameter under EdchConf is ignored by the system,
(as in UA5), and there is no related parameter at RNC level (UA5
harqRvConfiguration parameter under EdchUserService has been
removed).
Turbo coding with rate 1/3 is used
CRC is 24 bits length
E-TFCI (Transport Format Combination Indication) indicates which format is

currently used for the UL transmission
Page 29/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range & Unit
User
Class
Value
Object
EdchParameters
RNC / RadioAccessService / UlRbSetConf / EdchParameters
Integer [0 ..15], N/A
Customer
Granularity
RNC,
UlRbSetConf
3-a1
[iCEM] [xCEM] [eCEM] [UCU-III] 3
Engineering Recommendation: edchHarqMaxRetransEdchTti10

Formerly it was recommended to set edchHarqMaxRetransEdchTti10 to 4 for iCEM and xCEM.
The Live Networks results show that 3 is sufficient, hence 3 is now the recommended value for all the
boards. Note that UCU-III is using 3 since forever.
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
RAN Path
Range & Unit
User
Class
Value
Object
EdchParameters
Integer [0 ..7], N/A
Customer
Granularity
RNC,
UlRbSetConf
3-a1
[xCEM] [eCEM] 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]):
Page 30/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

E-DPDCH
Data, Ndata bits

Tslot = 2560 chips, Ndata = 10*2k bits (k=07)
E-DPCCH
10 bits
Tslot = 2560 chips
Slot #0
Slot #1
Slot #2
Slot #i
Slot #14
1 subframe = 2 ms
1 radio frame, Tf = 10 ms
Figure 21: 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
0
1
2
3
4
5
6
7
Channel Bit Rate

(kbps)
15
30
60
120
240
480
960
1920
SF
Bits/ Frame
Bits/ Subframe
256
128
64
32
16
8
4
2
150
300
600
1200
2400
4800
9600
19200
30
60
120
240
480
960
1920
3840
Bits/Slot
Ndata
10
20
40
80
160
320
640
1280
Table 12: E-DPDCH slot formats

Slot Format #i
Channel Bit Rate (kbps)
SF
Bits/ Frame
Bits/ Sub frame
15
256
150
30
Bits/Slot
Ndata
10
Table 13: E-DPCCH slot formats
E-DCH multicode transmission is possible only for SF = 4 and SF = 2.

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

ced,1
ed,1
iqed,1
ced,k
ed,k
iqed,k
E-DPDCH1
.
.
.
.
E-DPDCHk
.
.
.
.
ced,K
ed,K
iqed,K
cec
ec
iqec
I+jQ
Se-dpch
E-DPDCHN
E-DPCCH
Figure 22: E-DPDCH/E-DPCCH multiplexing on I/Q
DPCCH
DPDCHs
Sdpch
Spreading
Sdpch,n
Shs-dpcch
HS-DPCCH
Spreading
E-DPDCHs
E-DPCCH
I+jQ
S
Se-dpch
Spreading
Figure 23: 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 32/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

deltaEdpcch
Object
EdpchParameters
RNC / RadioAccessService / EdpchInfoClass / EdpchParameters
Integer [0 8], N/A
Customer
Granularity
RNC, EdpchInfoClass
3-a2
Parameter
RAN Path
Range & Unit
User
Class
Value
4
The correspondence between the index and the amplitude is specified by 3GPP [R06]:
Quantized amplitude ratios for
Signalling values for E-DPCCH
E DPCCH
10 20
8
7
6
5
4
3
2
1
0
30/15
24/15
19/15
15/15
12/15
9/15
8/15
6/15
5/15
Table 14: E-DPCCH power offset index vs. amplitude
The value of ec is based on the power offset E-DPCCH signalled by higher layers. The
formula to apply is:
ec = c 10
E DPCCH
20
3.2.1.2 DOWNLINK CHANNELS

The E-DCH Absolute Grant Channel (E-AGCH) is a fixed rate (30 kbps, SF=256)
downlink physical channel carrying the uplink E-DCH absolute grant. The next figure
illustrates the frame and sub-frame structure of the E-AGCH:
E-AGCH
20 bits
Tslot = 2560 chips
Slot #0
Slot #1
Slot #2
Slot #i
Slot #14
1 subframe = 2 ms
1 radio frame, Tf = 10 ms
Figure 24: E-AGCH frame structure

Page 33/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one EAGCH frame. The transmission over one E-AGCH sub-frame and over one E-AGCH
frame shall be used for UEs for which E-DCH TTI is set to respectively 2 ms and
10 ms. 6 bits are used to code Access Grant values. One 16 bits CRC (xored by UE id)
is attached to the AG value to form one 22 bits word. A rate 1/3 convolution coding
(constraint length 9) is then used leading to a total of 90 protected bits. A specific
puncturing scheme is then applied to finally select a 60 bits sequences (30 bits are
removed). With this kind of mechanisms only one UE can be touched at each E-DCH
TTI.
The E-DCH Relative Grant Channel (E-RGCH) is a fixed rate (SF=128)

dedicated downlink physical channel carrying the uplink E-DCH relative
grants. The structure of the E-RGCH is the same than the one used for EHICH channel.
A relative grant is transmitted using 3, 12 or 15 consecutive slots and in each slot a

sequence of 40 ternary values is transmitted. The 3 and 12 slot duration shall be used
on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is in the
E-DCH serving radio link set and for which the E-DCH TTI is respectively 2 and 10 ms.
The 15 slot duration shall be used on an E-RGCH transmitted to UEs for which the cell
transmitting the E-RGCH is not in the E-DCH serving radio link set.
The sequence bi,0, bi,1, , bi,39 transmitted in slot I (see Figure 25: E-HICH frame
structure) is given by:
bi,j = a Css,40,m(i),j
In a serving E-DCH radio link set, the relative grant a is set to +1, 0, or -1 and in a
radio link not belonging to the serving E-DCH radio link set, the relative grant a is set
to 0 or -1.
The relative grant (RG) command is mapped to the relative grant value as described
in the table below:
Command
RG Value (serving E-DCH RLS)
RG Value (other radio links)
UP
+1
not allowed
HOLD
DOWN
-1
-1
Table 15: Relative grant information (E-RGCH)
The orthogonal signature sequences Css,40, m(i) and the index m(i) in slot i are chosen
in the same tables than those used for E-HICH ACK/NACK indicators. The E-RGCH
signature sequence index l is given by higher layers.
In each cell, the E-RGCH and E-HICH assigned to a UE shall be configured with the
same channelisation code (SF 128).
Page 34/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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:
b i,0
b i,1
b i,39
T slot = 2560 chip
S lot #0
S lot #1
S lot #2
S lot #i
Slot #14
1 subfram e = 2 m s
1 radio fram e, T f = 10 m s
Figure 25: E-HICH frame structure
A hybrid ARQ acknowledgement indicator is transmitted using 3 or 12 consecutive

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

In a radio link set containing the serving E-DCH radio link set, the hybrid ARQ
acknowledgement indicator a is set to +1 or 1, and in a radio link set not containing
the serving E-DCH radio link set the hybrid ARQ indicator a is set to +1 or 0.
The ACK/NACK command is mapped to the HARQ acknowledgement indicator as
described in the table below.
Command
HARQ acknowledgement indicator
ACK
+1
NACK (RLSs not containing the serving E-DCH cell)
NACK (RLS containing the serving E-DCH cell)
-1
Table 16: ACK/NACK information (E-HICH)
The orthogonal signature sequences Css,40,m(i) and the index m(i) are given in specific
tables. The E-HICH signature sequence index l is given by higher layers.
Page 35/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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. From UA7.1 onwards, both 10ms and 2ms
E-DCH TTI are supported in UCU-III.
3.3 HSDPA AND E-DCH SERVICE INDICATOR

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
Object
RadioAccessService
RAN Path
Range & Unit
User
Class
Value
RNC / RadioAccessService
False, True
Customer
3-a1
True
Granularity
RNC
Page 36/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
hsdpaServiceIndicatorMethod allows to enable/disable at cell level the broadcast

of the HSDPA CellIndicator flag within SIB 5.
Parameter
hsdpaServiceIndicatorMethod
Object
FDDCell
RAN Path
Range & Unit
User
Class
Value
RNC / NodeB / FDDCell

ON, OFF, AUTO
Customer
3-a1
Auto
Granularity
FDDCell
edchServiceIndicatorMethod allows to enable/disable at cell level the broadcast of

the E-DCH CellIndicator flag within SIB 5.
Parameter
edchServiceIndicatorMethod
Object
FDDcell
RAN Path
Range & Unit
User
Class
Value

ON, OFF, AUTO
Customer
3-a1
Auto
Granularity
FDDCell
Once the feature is activated at RNC level, three operating modes are possible for
each cell indicator (HSDPA and HSUPA), all combinations between HSDPA and HSUPA
being allowed:
OFF: the hsdpaServiceIndicator (or respectively the edchServiceIndicator )
information is not broadcasted in SYSINFO message.
ON: if feature is enabled at RNC level, the hsdpaServiceIndicator (or
respectively the edchServiceIndicator) information is always broadcasted on
SYSINFO, with value HSDPA_CAPABLE (or respectively EDCH_CAPABLE). This
information is broadcasted to the UE even if the corresponding service
(HSDPA (or respectively E-DCH)) is not operational on the corresponding cell.
AUTO, if the feature is enabled at RNC level, hsdpaServiceIndicator (or
respectively the edchServiceIndicator) information is broadcasted to the UE
indicating the current state of the corresponding service: HSDPA_CAPABLE if
service is operational, HSDPA_NOT_CAPABLE otherwise (or respectively
EDCH_CAPABLE if service is operational, EDCH_NOT_CAPABLE otherwise)
Page 37/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
(64QAM, 16QAM, QPSK), MAC-HS transport block size, etc.
HS-DSCH
category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
Category
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Maximum number
of HS-DSCH codes
received
Minimum
inter-TTI
interval
5
5
5
5
5
5
10
10
15
15
5
5
15
15
15
15
15
15
15
15
15
15
15
15
3
3
2
2
1
1
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
1
1
Maximum number of bits of

an HS-DSCH transport block
received within
an HS-DSCH TTI
7298
7298
7298
7298
7298
7298
14411
14411
20251
27952
3630
3630
35280
42192
23370
27952
35280
42192
35280
42192
23370
27952
35280
42192
Total number
of soft
channel bits
19200
28800
28800
38400
57600
67200
115200
134400
172800
172800
14400
28800
259200
259200
345600
345600
259200
259200
518400
518400
345600
345600
518400
518400
Table 17: HSDPA UE categories (3GPP TS25.306)
UEs of Categories 11 and 12 supports QPSK only, while Categories 13, 14, 17, 18, 23
and 24 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 38/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
4.2 HSUPA
For HSUPA, the following UE categories have been specified in 3GPP [R05]:
Maximum
number of
E-DCH
codes
transmitted
Minimum
spreading
factor
Category 1
SF4
Category 2
SF4
Category 3
SF4
Category 4
SF2
Category 5
SF2
Category 6
SF2
E-DCH
category
Support
for 10 and
2 ms TTI
E-DCH
Maximum number of
bits of an E-DCH
transport block
transmitted within a
10 ms E-DCH TTI
Maximum number of
bits of an E-DCH
transport block
transmitted within a
2 ms E-DCH TTI
7110
14484
2798
14484
20000
5772
20000
20000
11484
10 ms TTI
only
10 ms and
2 ms TTI
10 ms TTI
only
10 ms and
2 ms TTI
10 ms TTI
only
10 ms and
2 ms TTI
NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Table 18: HSUPA UE categories (3GPP TS25.306)

[xCEM] [eCEM]
In UA7 SF2 and 2msTTI are supported by the xCEM and eCEM (UE categories 4, 5
and 6 are supported) whereas the iCEM board keeps the same capabilities as in UA5
(i.e UE Cat 2, 4, 5 and 6 are not supported).
In terms of bit rate, we can expect a maximum MAC-e throughput of:
2.0 Mbits/s for TTI = 10 ms

And a maximum RLC throughput of:
Category 3: 1380 kb/s
5.76 Mbits/s for TTI = 2 ms

And a maximum RLC throughput of:
o
[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 39/40

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Z END OF DOCUMENT Y
Page 40/40
UMT/IRC/APP/016664
V05.04
16/MAR/2012
HSDPA PRINCIPLES, SCHEDULING & RESOURCE

MANAGEMENT

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
CONTENTS
1
INTRODUCTION............................................................................................................6
1.1
OBJECT ....................................................................................................................... 6
1.2
RELATED DOCUMENTS ...............................................................................................10

2.1
HPUG VOLUMES .......................................................................................................... 10
2.2
REFERENCE DOCUMENTS ................................................................................................. 10
HSDPA ACTIVATION ...................................................................................................11
SCHEDULER ................................................................................................................15
4.1
ALGORITHM ................................................................................................................ 15
4.1.1
[xCEM] [eCEM] [UCU III] .................................................................................... 15
4.1.1.1
UL processing ................................................................................................. 15
4.1.1.2
CQI SNR mapping and SNR SE mapping ................................................... 15
4.1.1.3
HARQ process and priority queue selection........................................................ 16
4.1.1.4
User ranking ................................................................................................... 16
4.1.1.5
SNR estimation for HS-PDSCH .......................................................................... 17
4.1.1.6
TFRC selection ................................................................................................ 17
4.1.2
[iCEM] ............................................................................................................... 19
4.2
SCHEDULER TYPES ........................................................................................................ 21
4.2.1
[xCEM] [eCEM] [UCU III] .................................................................................... 21
4.2.2
[iCEM] ............................................................................................................... 23
4.3
QOS MANAGEMENT ....................................................................................................... 24
4.3.1
[xCEM][eCEM] ................................................................................................... 24
4.3.2
[UCU III] ........................................................................................................... 30
4.3.3
[iCEM] ............................................................................................................... 32
4.4
UE CATEGORY MANAGEMENT ............................................................................................ 35
4.4.1
[xCEM][eCEM] ................................................................................................... 35
4.4.2
[iCEM] ............................................................................................................... 36
4.5
HSDPA USER SCHEDULING.............................................................................................. 37
4.5.1
4.5.2
5
[xCEM][eCEM] ................................................................................................... 37
[iCEM] ............................................................................................................... 37
TFRC MANAGEMENT ...................................................................................................39

5.1
MAC-D PDU SIZE MANAGEMENT ....................................................................................... 39
5.2
656 PDU QUALCOMM UE BUG WORKAROUND ...................................................................... 46
5.3
TRANSPORT BLOCK SIZE OPTIMIZATION.............................................................................. 47
5.4
TFRC SELECTION ......................................................................................................... 53

5.4.1
Flexible Modulation iCem only........................................................................... 54
5.4.2
64 QAM for HSDPA xCem/eCem/UCU-III only .................................................... 56
5.4.2.1
Description ..................................................................................................... 56
5.4.2.2
Configuration .................................................................................................. 58
Page 1/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

5.5
5.4.2.3
Parameters settings......................................................................................... 59
DUAL CELL HSDPA OPERATION XCEM/ECEM/UCU-III ........................................................ 63
5.5.1
Overview ........................................................................................................... 63
5.5.2
Configuration ..................................................................................................... 64
5.5.3
InterAction & Mobility ......................................................................................... 65
5.5.4
Parameter settings ............................................................................................. 66
5.5.5
NodeB impact .................................................................................................... 69
5.6
LAYER 2 ENHANCEMENTS: FLEXIBLE RLC AND MAC-EHS.......................................................... 73
5.6.1
5.6.2
6
Flexible RLC and MAC-ehs ................................................................................... 74

IUB Frame protocol ............................................................................................ 83
CQI & MAC-HS BLER MANAGEMENT...........................................................................87

6.1
CQI PROCESSING ......................................................................................................... 87
6.2
CQI ADJUSTMENT ACCORDING TO BLER............................................................................. 88
6.3
HS-DPCCH PRESENCE DETECTION .................................................................................... 95
OVSF CODES .............................................................................................................100

7.1
CELL CONFIGURATION...................................................................................................100
7.2
HSDPA CODE ALLOCATION ............................................................................................101

7.2.1
7.2.2
Dynamic Code Tree Management........................................................................102

Fair Sharing ......................................................................................................112
POWER MANAGEMENT FOR HSDPA .........................................................................115

8.1
INTRODUCTION ...........................................................................................................115
8.2
HS-DSCH POWER MANAGEMENT .....................................................................................115

8.2.1
Power allocation ................................................................................................115
8.2.1.1
RNC level ..................................................................................................... 115
8.2.1.2
NodeB level .................................................................................................. 118
8.2.1.3
Power available for HSDPA channels ............................................................... 119
8.2.2
Power measurements ........................................................................................120
8.2.2.1
Transmitted carrier power.............................................................................. 120
8.2.2.2
Averaged HSDPA power................................................................................. 121
8.2.2.3
Total non HSDPA power................................................................................. 122
8.2.2.4
Available HSDPA power ................................................................................. 123
8.2.2.5
Report of Total Non-HSDPA Power from CEM to CCM ....................................... 125
8.2.2.6
Parameter Settings with Fast PMM Measurements............................................ 126
8.2.2.7
HS-DSCH Required Power .............................................................................. 128
8.2.3
HSDPA power distribution ..................................................................................131
8.2.3.1
HS-SCCH power ............................................................................................ 131
8.2.3.1.1 HS-SCCH Power Control ............................................................................. 132
8.2.3.2
HS-DSCH power ............................................................................................ 134
8.2.3.3
HS-PDSCH power .......................................................................................... 136
8.2.4
Power management...........................................................................................139
8.2.4.1
First transmission .......................................................................................... 139
8.2.4.1.1 Power limitation ........................................................................................ 141
8.2.4.1.2 Codes limitation......................................................................................... 141
8.2.4.1.3 Other limitations........................................................................................ 141
8.2.4.1.4 CQI optimization according to MAC-d PDU size............................................. 142
8.2.4.1.5 HS-DSCH Power evolution .......................................................................... 143
8.2.4.2
Retransmission ............................................................................................. 144
Page 2/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.3
8.2.4.3
Multi-users per TTI........................................................................................ 146
PARAMETERS SETTINGS AND RECOMMENDATIONS .................................................................146
8.4
HS-DPCCH POWER MANAGEMENT ...................................................................................149
8.4.1
Overview ..........................................................................................................149
8.4.2
Adaptive HS-DPCCH power offset........................................................................151
8.4.2.1
feature description ........................................................................................ 151
8.4.2.2
parameters settings and recommendations...................................................... 151
8.4.2.2.1 feature activation ...................................................................................... 151
parameters ......................................................................................................... 151
8.4.2.2.2 ................................................................................................................... 151
8.5
UA6 MANAGEMENT OF UL POWER PROFILES DEPENDING ON WHETHER THE DL IS MAPPED ON DCH OR
HSDPA 153
8.5.1
Introduction......................................................................................................153
8.5.2
Feature Description ...........................................................................................154
8.5.3
Parameters Settings and Recommendations.........................................................155
8.6
MULTI-CARRIER PA POWER POOLING ................................................................................157
8.6.1
Feature description............................................................................................157
8.6.1.1
Static PA Power sharing (feature deactivated).................................................. 157
8.6.1.2
Dynamic PA Power Sharing ............................................................................ 157
8.6.1.3
Supported radio configurations....................................................................... 160
8.6.2
Parameter settings and recommendations ...........................................................161
8.6.2.1
RAN Model ................................................................................................... 161
8.6.2.2
OMC-R Parameters........................................................................................ 162
8.6.2.3
OMC-B Parameters ........................................................................................ 163
8.6.2.4
Other recommendations ................................................................................ 164
9
OTHER FEATURES .....................................................................................................166

9.1
HSDPA PERFORMANCE ENHANCEMENT ..............................................................................166
9.2
HSDPA OCNS ...........................................................................................................167
9.2.1
HSDPA OCNS principle .......................................................................................167
9.2.2
HSDPA OCNS parameters...................................................................................168
9.3
IU USER TRAFFIC CONFORMANCE .....................................................................................173
9.3.1
Feature applicable .............................................................................................173
9.3.2
Algorithm..........................................................................................................173
9.3.3
Parameters .......................................................................................................175
9.3.4
Feature Behaviour .............................................................................................176
9.4
HSDPA OLS DIFFERENTIATION AT NODE B LEVEL ...............................................................176
9.4.1
Feature Overview ..............................................................................................177
9.4.2
Feature Activation and Parameters......................................................................178
9.5
PROPRIETARY RLC SDU DISCARDING POLICY FOR RAB ON HSDPA ..........................................180
Page 3/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
TABLES
Table
Table
Table
Table
Table
Table
Table
1:
2:
3:
4:
5:
6:
7:
CQI mapping table for 336 bits MAC-d PDU size

CQI mapping table for 656 bits MAC-d PDU size
Max hsdschInterval value
Maximum Transport Block Size used according to UE category and MAC-d PDU Size
CQI Mapping Tables
HS-PDSCH Slot formats
HS-SCCH power offset table according to the reported CQI
49
50
52
53
57
58
133
Page 4/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
FIGURES
Figure 1: MAC-hs scheduler overview (xCEM/eCEM/UCUIII) .......................................................... 15
Figure 2: TFRC selection algorithm used by the xCEM/eCEM/UCU-III ............................................. 19
Figure 3: MAC-hs scheduler overview (iCEM) ............................................................................... 20
Figure 4 : Example of Scheduling Weight for different values of serviceBFactor............................... 26
Figure 5: Example of Scheduling Weight for different values of serviceKFactor................................ 27
Figure 6: Parameters to configure the feature MAC-d PDU size 656 bits....................................... 44
Figure 7: Conditions to invoke the feature 79164 ......................................................................... 47
Figure 8: Padding bits in the MAC-hs PDU ................................................................................... 48
Figure 9: Codes limitation .......................................................................................................... 54
Figure 10: Code boost ............................................................................................................... 55
Figure 11 : Benefits of flexible RLC and Mac-ehs versus fixed RLC and Mac-hs................................ 76
Figure 12 : Slow start mechanism ............................................................................................... 83
Figure 13 : RB congestion control Object Tree ............................................................................. 84
Figure 14: CQI Processing.......................................................................................................... 87
Figure 15 : BLER Target according to the CQI and the UE category for the different BLER Ajustement
algorithm ........................................................................................................................... 90
Figure 16: CQI adjustment to BLER algorithm .............................................................................. 91
Figure 17: HS-DPCCH synchronization algorithm .......................................................................... 97
Figure 18: R99, HSDPA & HSUPA Common Channels codes allocation .......................................... 101
Figure 19: HS-PDSCH codes pre-emption or re-allocation............................................................ 104
Figure 20: Number of HS-PDSCH codes pre-empted ................................................................... 104
Figure 21: Number of HS-PDSCH codes re-allocated................................................................... 105
Figure 22: Illustration of the HS-PDSCH re-allocation blocking ..................................................... 105
Figure 23: Exemple of codes occupancy for SF16 ....................................................................... 113
Figure 24: Power allocation at RNC level ................................................................................... 116
Figure 25: Physical shared channel reconfiguration message....................................................... 118
Figure 26: Power allocation at NodeB level ................................................................................ 118
Figure 27: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)........ 121
Figure 28: Common measurement ............................................................................................ 122
Figure 29: hsdpaAmpUsage parameter...................................................................................... 124
Figure 30: Power measurement process .................................................................................... 126
Figure 31: Measurement flow of HS-DSCH required power .......................................................... 131
Figure 32: Power distribution between HS-DSCH and HS-SCCH channels...................................... 131
Figure 33: HS-SCCH power control overview.............................................................................. 133
Figure 34: measurementPowerOffset transmission ..................................................................... 136
Figure 35: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH......... 137
Figure 36: Dynamic Power Allocation ........................................................................................ 138
Figure 37: HS-DSCH power management for 1st transmission ..................................................... 140
Figure 38: MAC-hs transport block adaptation according to the number of MAC-d PDU to transmit . 142
Figure 39: Remaining power for multi-users per TTI scheduling .................................................. 146
Figure 40: Selection of OLPC UL SIR Target parameters by the RNC ............................................ 154
Figure 41: PA Power overbooking ............................................................................................. 158
Figure 42: Algorithm for CQI Generating Function ...................................................................... 170
Figure 43: Traffic Conformance Algorithm ................................................................................. 174
Page 5/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
1 INTRODUCTION
1.1 OBJECT
This includes a
recommendations.
system
description,
configuration
aspect
and
engineering

The term OneBTS in this document refers only to those NodeBs equipped with UCUIII board in the US Market.
The following features are described in the document:

PM ID
27931
Feature Title
HSDPA Flexible
resources Mgt
Activation flag
N/A
Release
Global
US
market Market
UA4.2
Yes
Yes
UA4.2
Yes
Yes
N/A
UA4.2
Yes
Yes
N/A
UA5.0
Yes
Yes
N/A
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
hsdpaActivation
27932
HSDPA Step 1
hsdpaResourceActivation
isHsdpaAllowed
27939
29809
29813
HS-SCCH Power
Control
UE Cat 7 & 8
Support
UE Cat 9 & 10
Support
isHsPdschDynamicManagementAllowed
29800
Dynamic DL Code
Tree Mgt For
isCellHsPdschDynamicManagementActive
HSDPA
(from UA6.0)
hsdpaSchedulerAlgorithm
hsdpaSchedulerWeightingFactor
29807
MAC-hs scheduler
improvement
hsdpaUeCategoryThroughputWeighting
hsdpaSpiRelativeWeight
32520
HSDPA and EDCH Service

Indicator
isHsxpaServiceIndicatorEnabled
hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod
Page 6/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
Feature Title
Activation flag
Release
Global
US
market Market
hsdpaCqiBlerAdjustmentAlgo
29819
HSDPA
Performance
Enhancement
ueCategory1..12
harqType
UA5.0
Yes
No
UA5.1
Yes
No
UA5.1
Yes
No
UA5.1
Yes
Yes
UA6.0
Yes
Yes
UA6.0
Yes
Yes
rxDemodulation
isDynamicMacdPduSizeManagementAllowed
34340
27350
34652
UE cat.8 max.
throughput with
PDU 656 & RLC
reconfiguration
eligibleUeCategoryForHighPerformance
minimumUserMbrForHighPerformance
maxCellRadius (only in UA5.1)
xCEM hardware
N/A
introduction
High quality UL
R99 RAB for High N/A
HSDPA DL data
rate
29799
MAC-d PDU size

Management for
HSDPA
isHsdpaCellHighPerformance (from UA6)
isHighPerformancePduSizeReconfAllowed
isGbrOnHsdpaAllowed (used only to map
29804
GBR on HSDPA
33390
Dynamic BLER
Adjustment
hsdpaCqiBlerAdjustmentAlgorithmxCEM
UA6.0
Yes
No
33391
HS-DSCH Power
Adjustment
Evolution
hsdpaFullPowerUsage
UA6.0
Yes
No
UA6.0
Yes
Yes
hsdpaFlexibleModulationVsCodeActivation
UA6.0
Yes
No
proprietaryHSDPAOCNSActivation
UA6.0
No
Yes
Streaming on HSDPA)
RNC:
isHsxpaR99ResourcesSharingOnCellAllowed
33694
Fair Sharing of
Resources HSDPA vs DCH
NodeB:
BTSEquipment::hsdpaCodeTreeManagement
Activation (iCEM/xCEM)
OneBTSEquipment::hsdpaCodeTreeManagem
entActivation (UCU-III)
34102
34195
HSDPA Flexible
Modulation
Support OCNS
with HSDPA
Page 7/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
Feature Title
79164
Qualcomm issue
with 656 PDU
size workaround
29808
Multi-Carrier PA
Power Pooling
Subfeature
of 34246
34388
Activation flag
is2ndRrcRbReconfNeededForQC7200
paPoolingActivation (scope BTSEquipment)
isPowerPoolingActivated (scope FDDCell)
Management of
UL Power Profiles
Depending
eligibleUeCategoryForSirTargetHsdpa
on whether the
DL is Mapped on
DCH or HSDPA
Layer 2
isMacEhsAllowed (scope RNC)
Enhancement:
Flexible RLC and isMacEhsAllowed (scope FDDCell)
MAC-ehs
Release
Global
US
market Market
UA6.0
Yes
Yes
UA6.0
Yes
No
UA6.0
Yes
Yes
UA7.0
Yes
Yes
UA7.0
Yes
Yes
UA7.1
Yes
No
UA7.1
Yes
No
UA7.1.2
Yes
No
Yes
Yes
isDl64QamAllowed
34386
75998
97431
64 QAM for
HSDPA
Radio
Measurement
Frequency
Increase: Tx
Power
HSDPA OLS
Differentiation at
Node B Level
isDl64QamOnRncAllowed
is64QamAllowedForUeCategory
hsdpaWindowsObserveTime
isDchPowerMarginAdaptive
N/A (creation of optional object OlsDiff under
RncIn)
isHsdpaDualCellActivated (scope FDDCell)

isHsdpaDualCellAllowed (scope RNC)
81204
Dual Cell HSDPA

Operation
isDualCellAllowedForUeCategory
hsdpaPlusPreferredMode
dualCellActivation (scope BTSCell)
[iCEM]
113511
Hsdpa aggregate Feature not applicable

throughput
[xCEM] [UCU-III]
40Mbps
No activation flag
80051
74681
eCEM-u
Introduction
eCEM
Introduction
[GM]
UA7.1.2
[US]
UA7.1.3
No activation flag
UA7.1.3
Yes
No
No activation flag
UA7.1.3
Yes
No
Page 8/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
Feature Title
Activation flag
Release
Global
US
market Market
dualCellHsdpaMaxNumberUserXcem
dualCellHsdpaMimoMaxNumberUserEcem
Dual-Cell HSDPA
dualCellHsdpaMaxNumberUserUcu
user number
104832/118
increase / Dual154
isMultiServiceForDualCellAllowed
Cell HSDPA
capacity increase isMultiRabForDualCellHsdpaAllowed
UA08.1
Yes
Yes
UA08.1
Yes
Yes
UA08.1
No
Yes
UA08.1
No
Yes
isAluTimerBasedSduDiscard
82602/R7
114637
34465
Adaptive HSuseAdaptiveHsDpcchPowerOffset
DPCCH power
offset
Dual Cell HSDPA
Same as feature 81204
support for
OneBTS
THP ARP
Dynamic
Allocation in the No activation flag
Priority Mapping
Table on OneBTS
Page 9/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

[R02] 3GPP TS 25.214
[R03] 3GPP TS25.306
UE Radio Access capabilities
[R04] 3GPP TS 23.107
Quality of Service (QoS) concept and architecture
[R05] UMT/SYS/DD/013319
Planning Guide
Iub Transport Engineering Guide
NodeB Product Engineering Information
CEM Capacity Eng'g Guide
IP Iub
UTRAN Operational Engineering Method Native
Page 10/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
3 HSDPA ACTIVATION
HSDPA is activated through several activation flags at RNC, FDDCell and BTSCell level.
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsdpaAllowed
False, True
Customer
3-b
Object
RadioAccessService
Granularity
RNC
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaActivation
Parameter
RAN Path
hsdpaResourceActivation
Range & Unit

User
Class
Value

False, True
Customer
3
Object
FDDCell
Granularity
Cell
True
Object
BTSEquipment / BTSCell / Class0CemParams
False, True
Customer
Granularity
0 or 3-a1 (please see release delta
below)
BTSCell
Cell
True
Page 11/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UA7.1-UA08.1 Delta: hsdpaResourceActivation parameter evolution
The parameter hsdpaResourceActivation is used to activate the allocation of HSDPA resource for a
BTSCell. HSDPA can be allocated on an iCEM board or other boards like xCEM and eCEM. The
parameter hspaHardwareAllocation (refer to [R09] for more details) indicates whether HSDPA
resources shall be allocated on iCEM or not for a specific RfCarrier.
In order to be able to manage HSDPA for a cell, an iCEM needs to be loaded with the hBBU load.
Changing the load (from dBBU to hBBU) requires an iCEM reset. As a result, it is not possible to
manage parameter hsdpaResourceActivation without service impact.
In case of xCEM and eCEM, these boards are multimode, which means that they are able to manage
at the same time R99, HSDPA and EDCH services for the same cell, and it is possible to handle a state
change of HSDPA from disabled to enabled (and vice-versa) without affecting the R99 service of the
cell. As a result it is possible to manage parameter hsdpaResourceActivation online, without
service impact.
In order to manage the parameter as class 0 for iCEM and class 3 for x/eCEM, the parameter
hsdpaResourceActivation is replaced by two parameters (with the same name) in different
locations from UA08.1 onwards:

The BTS selects the right set of parameters, depending on the value of parameter isICemAllowed,
as follows:
If isICemAllowed = True, use BTSEquipment / BTSCell / Class0CemParams parameters

If isICemAllowed = False, use BTSEquipment / BTSCell / Class3CemParams parameters
isICemAllowed is a new parameter (class 3) that is introduced to indicate whether

iCEM boards are manageable by iBTS or not. Depending on the setting of this
parameter, hsdpaResourceActivation can be managed or not as class 3.
Parameter
RAN Path
Range & Unit
User
Class
Value
isICemAllowed
Object
BTSEquipment
BTSEquipment
False, True
Customer
3-a1
Depends on BTS configuration
Granularity
Cell
Parameter hspaHardwareAllocation allows adjusting the CEM allocation for a given

RF carrier onto iCEM or eCEM/xCEM.
Page 12/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
hspaHardwareAllocation
Object
RfCarrier
BTSEquipment / RfCarrier
Enum {icemOnly, ecemxCemOnly, ecemXcemPreference, icemPreference}
Customer
Cell
Granularity
3-a2
Depends on BTS configuration
Rule: Relation between isICemAllowed and hspaHardwareAllocation parameters

If isICemAllowed is set to False, hspaHardwareAllocation cant be set to iCemOnly.
From UA08.1 onwards, the activation of HSDPA (respectively E-DCH) can be done
online, as the parameter class of hsdpaActivation (respectively edchActivation)
has been changed to 3.
This kind of procedure (HSDPA/E-DCH activation and deactivation) should be
performed in the field when traffic load in the cell is very low, to increase the
probability of activation/deactivation success and also reduce the impact on existing
calls.
In order to avoid service impact (call drop) during HSPA activation and deactivation,
the following parameters are introduced, to control the normal release of the on-going
calls:
waitForResourceReleaseForHsxpaConfiguration defines the waiting time
before triggering resource (OVSF codes) release in order to configure HSDPA
and/or EDCH in the cell.
Parameter
RAN Path
Range & Unit
User
Class
Value
waitForResourceReleaseForHsxpaConfiguration
{[0 .. 1440], infinite} minutes (0 means immediately)
Customer
3
Default: infinite
Please read Engineering Recommendation below
Object
FDDCell
Granularity
Cell
waitTimeBeforeHspaDeactivation defines the waiting time before triggering

HSDPA and/or EDCH deactivation in the cell.
Parameter
RAN Path
Range & Unit
User
Class
Value
waitTimeBeforeHspaDeactivation
Object
{[0 .. 1440], infinite} minutes (0 means immediately)
Customer
Customer
3
Default: infinite
Please read Engineering Recommendation below
FDDCell
Customer
Page 13/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: Setting for waitForResourceReleaseForHsxpaConfiguration
and waitTimeBeforeHspaDeactivation parameters
In
order
to
avoid
service
impact
(call
drop)
during HSPA activation, the parameter

waitForResourceReleaseForHsxpaConfiguration should be set to a high value (few hours during
maintenance window time) so that RNC can activate HSPA only when all calls that are using required
HSPA resources are normally released.
In order to avoid service impact (call drop) during HSPA deactivation, the parameter
waitTimeBeforeHspaDeactivation should be set to a high value (few hours during maintenance
window time) so that RNC can deactivate HSPA only when all HSPA PRLs in the cell are normally
released.
Page 14/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
4 SCHEDULER
4.1 ALGORITHM
4.1.1 [xCEM] [eCEM] [UCU III]
The following sections describe the algorithm used by xCEM/eCEM/UCU-III to
schedule several HSDPA users. In case there is a difference in terms of behaviour
among the three, it will be highlighted in the description.
Step 1
UL processing for all users
ACK/NACK/CQI Reception
Start, i = 0
Step 2
CQI SINR
mapping for all users
Step 5
Calculation of av. power and SNR
for HS-DSCH for user ui
Get user ui of
Scheduling List
Step 4
Calculation of Tx Power for
HS-SCCH for all users
Step 3
Selection of HARQ process
per user
Step 6
Get SE and TFRC for
for user ui
No
Mark as eligible user
for excess power
End of List,
End of Resources
or End of scheduler
processing time?
i = i+1
Step 7
Update available power
and available codes
Mark as non-eligible
user for excess power
No
SE > SE_Threshold
or
TBS > TBS_Threshold?
Yes
Yes
Is excess power enabled?

Yes
No
Step 8
Allocate Excess Resources over
all scheduled users that are marked as
eligible for excess power
Step 9
Allocate OVSF codes
to HS-DSCH and HS-SCCH
Assemble MAC-hs PDU
Assign IE for HS-SCCH
End
Figure 1: MAC-hs scheduler overview (xCEM/eCEM/UCUIII)
4.1.1.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.1.2 CQI SNR MAPPING AND SNR SE MAPPING

According to the 3GPP ([R02]), the UE has to report a CQI assuming a 1st TX BLER of
10% and a transmitted power for the HS-DSCH equal to the following reference
power:
PHS-DSCH reference[dBm] = PP-CPICH[dBm] + [dB] + (CQIreported)[dB]
Page 15/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Where:
-
PP-CPICH is the power of the P-CPICH channel,
is the measurement power offset
is the reference power offset given by the reference tables of CQI [R02].
Contrary to iCEM, xCEM/eCEM/UCU-III does not directly use the CQI. The received
CQI information is mapped to SNR values (SNRMAP,dB) depending on UE category. The
TFRC selection is then based on a second mapping between this SNR and the Spectral
Efficiency (SE). The SE defines the number of bits per HS-PDSCH code per TTI that
can be transmitted for a given symbol SNR and SF = 16 (assuming 10% MAC-hs bler)
in an AWGN channel.
4.1.1.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. This behavior has been modified
since release 8 whereby HSDPA-DC capable UE support 2 simultaneous HARQ
processes within the same 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
is expected.
4.1.1.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/eCEM scheduler also creates a user
ranking list by sorting users by increasing cost (first scheduled is the one with the
lowest cost).
The xCEM/eCEM scheduler will try to schedule users one after the other according to
this ranked list (first user in the ranking list will be scheduled 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/eCEM and cRmax, unconstrained and
fairThroughput for UCU-III) and if MAC-d flow is GBR enabled. See sections 4.2.1 and
4.3.1 for more details.
Page 16/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

4.1.1.5 SNR ESTIMATION FOR HS-PDSCH
For the user selected from the ranking list, the scheduler estimates the SNR of one
HS-PDSCH code based on the SNRMAP,dB derived from CQI (see previously) and on the
available power per HS-PDSCH code:
SNRdB = SNRMAP,dB + PavailableHS-PDSCH Pcpich + (ack,nack)
-
SNRMAP,dB is the last SNR value mapped on CQI assuming a HS-DSCH

power of Pcpich + ( being the measurementPowerOffset/2 ).
PavailableHS-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 1st Tx BLER

or residual BLER after N transimissions is achieved. (ack,nack) is
increased or decreased depending whether a ACK or a NACK is
received (see section 6.1 for more details).
This SNRdB is then mapped to a SE and used for TFRC selection.
4.1.1.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/eCEM/UCU-III scheduler
will select from a look up table the TFRC (transport block size B, number of HS-PDSCH
codes W and modulation). The Look-Up Table (LUT) is made such that the selected
TFRC corresponds to the higher transport block size and the lower number of HSPDSCH so that the spectral efficiency of this TFRC is lower than the SE computed
previously:
B / W SE with maximal B and minimal W
Modulation is selected in order to use resources most efficiently. If SE is low then
QPSK is preferred, whereas 16-QAM is used when SE is high and UE supports 16QAM. This xCEM/eCEM/UCU-III behavior (QPSK and 16-QAM can be used whatever
the number of HS-PDSCH codes) is related to the feature PM34102, which introduces
similar behavour in iCEM.
With the introduction of feature PM34386 64QAM for HSDPA, new CQI mapping
tables are also defined which translate the CQI values into a recommended maximum
TB size and a modulation scheme. By a high CQI value (good channel quality) the UE
can indicate that 64QAM can be used.
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
Page 17/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The maximal Hsdpa aggregate
considered. Feature PM113511
UCU-III and per xCEM or eCEM
before this feature. In UA08.1
60000 Kbps in case of eCEM-u.
throughput capacity achievable by the board is also

enables a maximal HSDPA aggregate throughput per
in UA7.1.3 up to 39600 Kbps while it was 28800 Kbps
feature PM118155 further extends this capability to
[xCEM][eCEM] This maximal capacity can be further controlled (limited) by the

parameter hsdpaMaxThroughputXcem. See [R09] for more details on this
parameter.
In case of an HARQ retransmission, the scheduler will not use the instantaneous SE
but the cumulated SE over all the transmissions of this HARQ process, allowing to
account for IR or CC gains (SEcum = SEcurrent + SEcum).
The power allocated for the HS-DSCH of the user i is:
PHS-DSCH(i) = PavailableHS-PDSCH x W
This power is also weighted by the term factor because if B/W is smaller than SE, it
means that less power is needed to achieve the same error rate:
PHS-DSCH(i) = PavailableHS-PDSCH x W x factor
factor =
SNR ( B / W )
SNR ( SE )
Where:
-
B is the Transport Block Size selected by the scheduler
W is the number of HS-PDSCH codes selected by the scheduler
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:
W = 15 and B >= 37896
or
W = 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.
Page 18/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following drawing summarizes the algorithm used by the xCEM/eCEM/UCU-III to
select the TFRC of a UE:
SNR (dB)
Log2lin
Number of HS-PDSCH
MAC-hs PDU Size
SE
SNR of one HS-PDSCH (linear)
SE
SE
CQI
SNR of one HS-PDSCH (linear)
SNR (dB)
SNR of one HS-PDSCH (dB)
Modulation
TFRC
CQI
UE Cat.
PowerHsPdschAvailable_dBm
PowerCpich_dBm
MPO
DeltaAckNack
Modulation Capability
Number of HS-PDSCH available
max. MAC-hs Payload
Figure 2: TFRC selection algorithm used by the xCEM/eCEM/UCU-III
4.1.2 [iCEM]
As described in the figure below, MAC-hs scheduling consists of choosing the MAC-d
flow (QId) to serve.
Page 19/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 3: MAC-hs scheduler overview (iCEM)
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 Proportional Fair and Classical Proportional
Fair schedulers.
The resulting cost is a function of these two costs, and is different according to the
scheduler type. For Alcatel-Lucent Proportional Fair scheduler, the resulting cost is
equal to C1+C2, while for the Classical Proportional Fair, the resulting cost is 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 20/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
4.2 SCHEDULER TYPES

4.2.1 [xCEM] [eCEM] [UCU III]
[xCEM][eCEM]
Two schedulers are supported and can be selected through the parameter
hsdpaSchedulerAlgorithmXcem:
hsdpaSchedulerAlgorithmXcem
Parameter
RAN Path
Range & Unit
User
Class
Value

[CRmax, proportionalThroughput] Enum
Customer
3
Object
HsdpaConf
Granularity
BTSCell
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 offers more
flexibility than proportionalThroughput. That is the reason why the CRmax is the recommended
scheduler.
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:
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for
GBR MAC-d flows when R serviceMinRate
CostpropTh = (1/(SPIweight(u,q)*100)) * J(u,q) / CR(u,q) for GBR MAC-d flows when
R < serviceMinRate
CostCRmax = SW(u,q) . J(u,q) / CR(u,q) for all MAC-d flow types
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
Page 21/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

get the bit rate. The scheduling weight can be controlled by the OMC
parameters serviceMinRate, serviceMaxRate, serviceBFactor
and serviceKFactor. These QoS parameters are shared by the two
schedulers serving a common HSDPA-DC user through two carriers.
-
Job size J(u,q) represents the average throughput of the priority

queue (this throughput is smoothed, using an exponential filtering, by
the OAM parameter hsdpaSchedulerWeightingFactorXcem for
xCEM and eCEM 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. The average channel rates and associated
user throughputs associated with two carriers shall be accumulated
for the single user HSDPA-DC operation. The combined user
throughput shall be used by both schedulers for the user ranking, i.e.
the same DC user will be in the two independent user ranking list of
each cell.
Note that the cost functions for Proportional Throughput and CRmax are strictly the
same when the QoS is disabled. To disable the QoS :
-
With
Proportional
Throughput,
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.1 for more details on QoS management for xCEM and eCEM.
[UCU-III]
Three different scheduling modes are offered, and are called CRMax, Unconstrained
and Fair Throughput. CRMax is the default setting, and with this mode the handling
of different traffic classes and scheduling priorities is supported. The Unconstrained
mode as well as the Fair Throughput mode do not take traffic class into account, i.e.
all calls are handled equally as far as the scheduling priorities are concerned.
The Unconstrained mode assigns the priorities per user in the MAC-hs purely based
on the instantaneous RF conditions. Rate constraints are not taken into account. This
mode yields the highest cell throughput at the expense of reduced user throughput at
cell edge.
The Fair Throughput mode assigns the priorities per user in the MAC-hs based on the
hardcoded minimal and maximal rate constraints of 126 kbps and 130 kbps,
respectively. This means that the priority of a user is increased or decreased if its
measured throughput is below or above the given rate constraints. The minimal and
the maximal rates are not guaranteed. They are only applied to weight the user
priorities according to their measured throughput.
Page 22/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.2.2 [iCEM]
As explained in [R05], the RF cost function noted C1 is based on the following
principles:
- Alcatel-Lucent Proportional Fair:
costT = .costT-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:
costT = CQIavT / CQIinstT with CQIavT = * CQIavT-1 + (1 - ) * CQIinstT

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.
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
Where
reported (considered before CQI BLER adjustment).
Parameters:
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaSchedulerWeightingFactor
[18] decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
5
The selection of any of these scheduler types can be changed on line through a
customer class 3 parameter: hsdpaSchedulerAlgorithm.
Page 23/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaSchedulerAlgorithm
[alcatel-Lucent, proportionalFair] Enum
Customer
3
Object
HsdpaConf
Granularity
BTSCell
proportionalFair
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.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:
-
CRmax and Proportional Throughput for xCEM and eCEM
CRmax for UCU-III
Alcatel-Lucent Proportional Fair and Classical Proportional Fair

schedulers for iCEM
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 the QoS management in order to avoid that users with high priority are scheduled first even if
experiencing bad RF conditions.
4.3.1 [xCEM][eCEM]
The two xCEM/eCEM schedulers manage the QoS differently:
-
With proportionalThroughput: a relative weight is applied on each SPI

via hsdpaSpiRelativeWeight (same parameter as in the iCEM case)
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, the measured throughput
R is compared with the following threshold per SPI and then
appropriate user ranking is applied as per section 4.2.1, which
includes the use of serviceBFactor, again defined per SPI:
Page 24/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
serviceMinRate = MAC-hs GBR serviceLowRate.
With CRmax: for a given SPI, the priority of the queue is increased
(or decreased) through the 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 that are
used to increase and decrease the priorities:
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.
the
larger
if serviceBFactor is set to 1, 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 follows:

SW(u,q) = serviceBFactor
Where the term depends on whether the measured MAC-d throughput R is lower or
higher than serviceMinRate:
If R serviceMinRate:
R serviceMinRate
serviceMaxRate serviceMinRate
serviceKFactor
If R < serviceMinRate:
serviceMinRate R
serviceMaxRate serviceMinRate
1 / serviceKFactor
MAC-d flows, with CRmax algorithm, serviceMinRate and

serviceMaxRate are not taken from OMC-B but fixed by MAC-hs according to MAChs GBR (NBAP) with margins coming from OMC-B:
For
GBR
serviceMinRate = MAC-hs GBR - serviceLowRate

and
serviceMaxRate = MAC-hs GBR + serviceHighRate.

The basic conduct of the scheduler is to ensure a throughput at least equal to
serviceMinRate to all GBR users, by taking resources away from non-GBR users or
those with throughput above serviceMaxRate.
Page 25/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The scheduler reduces the rank of those users and the freed resources are given to
the GBR users with throughput below serviceMinRate. If there are enough
resources, bit rates higher than serviceMaxRate can be provided.
In case of overload, i.e. when not all requests for all GBR users can be fulfilled, some
users wont be able to get up to serviceMinRate throughput. These ones are
selected based on their Scheduling Weight and RF conditions.
Users with throughput between the two thresholds defined above are ranked
according to their RF conditions and Scheduling Weight. In particular, users
experiencing a better radio environment are ranked higher, while the ratio of
Scheduling Weights provides the relation between throughputs for users under the
same RF conditions.
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 (note that Priority Weight = 1 / Scheduling
Weight):
Priority W eighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7
B = 5, K = 7
B = 3, K = 7
B = 1, K = 7
7
6
Priority
5
4
3
2
1
0
20
30
40
50
60
70
80
Data Rate [kbps]
Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)

K_factor=7
1000
Scheduling Weight (log)
100
B=7
10
B=5
B=3
1
B=1
0
10
20
30
40
50
60
70
80
0,1
0,01
Data Rate (kbps)
Figure 4 : Example of Scheduling Weight for different values of serviceBFactor

Page 26/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Priority W eighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7
B = 7, K = 5
B = 7, K = 3
B = 7, K = 1
7
6
Priority
5
4
3
2
1
0
20
30
40
50
60
70
80
Data Rate [kbps]
Schedule Weighting (Rmin = 40 kbps, Rmax = 60 kbps)

B_factor=7
1000
Scheduling Weight (log)
100
K=7
10
K=5
K=3
1
K=1
0
10
20
30
40
50
60
70
80
0,1
0,01
Data Rate (kbps)
Figure 5: Example of Scheduling Weight for different values 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 Proportional Throughput (xCEM and eCEM) or Proportional Fair (iCEM)
schedulers, CRmax scheduler can apply different Scheduling Weights 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 27/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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/eCEM: 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
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaSchedulerWeightingFactorXcem
[18] decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
8
serviceBFactor
Object
HsdschServiceParameterSet
BTSEquipment / BTSCell / HsdpaConf / HsdschServiceParameterSet
[130] decimal
Customer
Granularity BTSCell
3
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
RAN Path
Range & Unit
User
Class
Value
serviceKFactor
Object
[130] decimal
Customer
Granularity BTSCell
3
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceMaxRate
7
Object
[010000] decimal kb/s
Customer
Granularity BTSCell
3
300
Page 28/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
serviceMinRate
Object
Customer
Granularity BTSCell
3
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceHighRate
Object
Customer
Granularity BTSCell
3
40
80 for PS Streaming and 300 for PS I/B
Engineering Recommendation: serviceHighRate

Concerning the parameter serviceHighRate, the recommendation is to set a medium value (80kb/s)
for all GBR flows. This recommendation allows to guarantee a tighter control of the throughput
around the Ranap GBR for Streaming traffic class (SPI = 15 .. 13) and PS I/B traffic class with
minimum bit rate constraint (SPI = 11 .. 4) while at the same time allowing the resources to be
distributed efficiently between simultaneous active users
To summarize:
serviceHighRate = 80kb/s for PS Streaming and 300kb/s for PS I/B
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceLowRate
Object
Customer
Granularity BTSCell
3
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceFilterFactor
0
Object
[111] decimal
Customer
Granularity BTSCell
3
8
The parameters in the object HsdschServiceParameterSet allow defining the
priority of only one SPI. 16 instances of HsdschServiceParameterSet have been
created.
Note: Before UA6.0, only 6 HsdschServiceParameterSet were defined. So, the
mapping between SPI and HsdschServiceParameterSet was done using parameter
schedulingPriorityLevel (in HsdschServiceParameterSet). From UA6.0
onwards, 16 HsdschServiceParameterSet have been defined (one per SPI). So,
Page 29/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

the parameter schedulingPriorityLevel does not exist from UA6.0 onwards since it
is not useful anymore.
4.3.2 [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
HSDSCHServiceParameterSet1
Default [Unit]
Remark
SchedulingPriorityLevel
= 15
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
= 14
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
= 13
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
[kbps]
Parameter set
for scheduling
priority 15. Can
be configured
at OMC
Parameter set
for scheduling
priority 14. Can
be configured
at OMC
Parameter set
for scheduling
priority 13. Can
be configured
at OMC
Page 30/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
= 12
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
= 11
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
= 10
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
=9
ServiceMinRate = 0
[kbps]
[kbps]
ServiceLowRate = 0
[kbps]
Parameter set
for scheduling
priority 12. Can
be configured
at OMC
Parameter set
for scheduling
priority 11. Can
be configured
at OMC
Parameter set
for scheduling
priority 10. Can
be configured
at OMC
Parameter set
for scheduling
priority 9. Can
be configured
at OMC
Page 31/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
HSDSCHServiceParameterSetUc
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
ServiceMinRate = 0
[kbps]
ServiceMaxRate =
1000 [kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 1
Parameter set
for
Unconstrained.
Can not be
configured at
OMC
ServiceKFactor = 1
HSDSCHServiceParameterSetFt
ServiceMinRate = 126
[kbps]
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 5
Parameter set
for Fair
Throughput.
Can not be
configured at
OMC
ServiceKFactor = 13
Note : Scheduling modes Fair Throughput and Unconstrained service parameters sets are also introduced,
which are read only in the OMC-U reflecting the parameters hard coded in the UCU III .
4.3.3 [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 32/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 the throughput of an UE in priority queue #3 if CQI were 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
RAN Path
Range & Unit
User
Class
Value
hsdpaSpiRelativeWeight
[1..16][1..100] List of Decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100
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 33/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The setting of SPI (common for iCEM, xCEM and eCEM) is done in RNC /
RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos:
Spi
Parameter
RAN Path
Object
ThpBasedQos
RNC / RadioAccessService / TrafficClassBasedQos / ArpBasedQos /
ThpBasedQos
[0..15]
Customer
Granularity
RNC
3
Range & Unit

User
Class
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] [eCEM]
Supports differentiation on all 16 SPI
[UCU III]
Supports QOS differentiation only on 7 different priorities. In deployments with UCUIII, the RNC mapping of QOS to SPI will use a more restricted set of SPI.
GBR Handling in iCEM:

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
Page 34/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

(moreover, GBR flows for which it is absolutely not possible to guarantee their GBR
even by allocating them all resources are put at the end of the list of GBR flows).
Parameters:
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi
[1..16][1..11] List of Decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
[8, .., 8] (default value)
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaGbrNbUePerTtiForgettingFactor
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaGbrNbNeededTtiForgettingFactor

[1..11] Decimal
Customer
3
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
8 (default value)

[1..11] Decimal
Customer
3
8 (default value)
Note that the parameter HsdpaGbrIncreaseFactorForMobility in HsdpaConf is not
used.
4.4 UE CATEGORY MANAGEMENT

4.4.1 [xCEM][eCEM]
UE categories also add some bias in the way virtual buffer are filled, as described
above. The impact depends on the value of the OMC-B parameter
hsdpaUeCategoryThroughputWeightingXcem. It defines the way balance is
performed between different categories when one of them is limited by the transport
block size. For instance, different categories have different maximum MCS and
associated TBS.
Two behaviours are then defined according to the value of the parameter:
ueCategoryEquity: UE categories will reach the same throughput in average,

when in the same RF conditions, defined by Spectral Efficiency.
ueCategoryProportionality: UEs throughput will depend on their category.
Page 35/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

It must be noted that this parameter is only applicable when SPI management is
activated. Hence, it is disabled in case serviceBFactor is equal to 1 for all SPI.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaUeCategoryThroughputWeightingXcem
Object

[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
3
HsdpaConf
BTSCell
ueCategoryProportionality
In case of UCU-III this behaviour is set by default through a NodeB tunable to provide
similar result to ueCategoryEquity setting in xCEM and eCEM.
4.4.2 [iCEM]
For the iCEM case, the behaviour is similar, and controlled by parameter
hsdpaUeCategoryThroughputWeighting, in case a category 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.
Like in the previous case, two behaviours are possible:
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.
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).
As mentioned before this parameter is only effective when SPI management is
activated. It is disabled in case of all hsdpaSpiRelativeWeights [SPI] are equal to
100.
Page 36/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaUeCategoryThroughputWeighting
Object
[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
3
HsdpaConf
BTSCell
ueCategoryProportionality
4.5 HSDPA USER SCHEDULING

4.5.1 [xCEM][eCEM]
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 xCEM/eCEM, 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.
With iCEM, retransmissions are always transmitted before first transmissions.
4.5.2 [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.
A user can only be considered as candidate if it is allowed to receive some data in the
current TTI, i.e. if several criteria are respected (CQIprocessed 0, min inter TTI
distance, AckNack repetition factor, one HARQ process available, UE not already
scheduled for retransmissions).
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.
Page 37/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 CQIapplied 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.
Page 38/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5 TFRC MANAGEMENT
5.1 MAC-D PDU SIZE MANAGEMENT
This section mainly deals with MAC-hs/fixed MAC-d PDU size however
recommendations about MAC-ehs/flexible MAC-d PDU size management are also
made. For more detailed discussion on MAC-ehs/flexible Mac-d PDU size, 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 evaluated at 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.
Engineering Recommendation: prohibitedStatusTimer and uplink Status traffic

In networks with high penetration of low-rate capable mobiles (HSDPA category 6 and category 12), it
might be beneficial increasing prohibitedStatusTimer (from 30ms to 70ms). This will avoid too
much uplink status traffic and will reduce the number of spurious retransmissions.
Page 39/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: prohibitedStatusTimer and PollingTimer
Engineering recommendation is to set :
For Cat6, Cat8, Cat10 and generally speaking the UEs using Fixed RLC PDU size:
DlRlcAckMode/prohibitedStatusTimer to 30ms.
For Cat13 to Cat24 using Flexible RLC PDU size:

DlRlcAckFlexibleMode/prohibitedStatusTimer to 10ms
Therotically all categories of UE are able to operate with Flexible RLC PDU, provided they run
with Rel7 or above software. In practice, in the field, the UEs operating with Flexible RLC PDU
are the high-rate capable UE (e.g Cat14 and Cat24).
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 40/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 , 19Mbps with UE Cat.14 or 37Mbps with UE Cat.24):
-
MAC-d PDU size = 656 bits or flexible pdu especially for Cat.10, 14 and 24
1 dedicated M-BBU per HSDPA cell & 1 dedicated xCEM / eCEM per HSDPA dualcarrier cells
for Cat 24
At least 6 E1 (Iub/Iur) for UE Cat.9, 8 E1 for UE Cat.10 or Hybrid/ Native IP Iub for UE
Cat.14 and 24 (Hybrid/ Native IP Iub is recommended to avoid potential IUB limitations) in
mono-user case and Core Network has to be dimensioned to support data bursts with IuPS BW of 100Mbps
UL service: HSUPA
UL RLC BLER measured ~ 0%
TCP/RLC setting :
RWIN (TCP window) = 146kB for UE Cat.9/10 or 350kB for UE Cat.14 or 700.8kB for
UE Cat. 24
DlRlcQueueSizeForUeCat = 256 RLC SDU for Cat.9/10 or 512 for Cat.14 and Cat. 24
prohibitedStatusTimer = 30ms (reduced to 10 ms for Flexible RLC)
Socket Buffer Size = 200,000 Bytes (Server configuration) at minimum or 730,000 Bytes
for Cat. 24; 16777216 Bytes (224) is the value commonly used, which is large enough in
every instance.
See [R07] for more details on Hybrid/ Native IP Iub configuration.
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.
Page 41/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

-
minimumUserMbrForHighPerformance to configure 656 bits if MBR (RANAP

Maximum BitRate) value is above this parameter.
isHsdpaCellHighPerformance to restrict primary cell to 336 bits.
Moreover isDynamicMacdPduSizeManagementAllowed flag allows activating or

deactivating the feature at RNC level.
Reconfiguration of the MAC-d PDU size during the call, e.g in case of HSPA mobility
towards
a
cell
configured
differently,
is
allowed
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 to 20 and 21 to 24.
Release7 UE Cat 13, 14, 17 and 18 and Release8 UE Cat 19 to 24, although they
should 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
RAN Path
Range & Unit
User
Class
Value
Object
RNC / RadioAccessService / HsdpaRncConf
BitString 64 bits (0=not eligible, 1=eligible)
Customer
Granularity
3
HsdpaRncConf
RNC
0000000000000000000000000000000000000000111111110011001111000000
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 and
so on.
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
Integer [0.. 16 000 000] bit/s
Customer
3
Object
HsdpaRncConf
Granularity
RNC
0 (customer dependent)
Page 42/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
isHsdpaCellHighPerformance
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range &
Unit
User
Class
Value

Boolean {True; False}
Customer
3
Object
FDDCell
Granularity
Cell
True
Boolean
{True, False}
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
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.
Parameter
RAN Path
Range &
Unit
User
Class
Value
isHighPerformancePduSizeReconfAllowed Object
HsdpaRncConf
BitString 64 bits (0=not eligible, 1=eligible), one bit per UE Categorie (Cat. 1 on the
right)
Customer
Granularity
RNC
3
0000000000000000000000000000000000000000111111110011001111000000
Page 43/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following flowchart summarizes the parameters configuration:
True
1
< MBR
isHsdpaCellHighPerformance
False
0
> MBR
False
True
336 bits is used on RNC

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

for this cell
isHighPerformancePduSizeReconfAllowed
1
PDU size reconf. is allowed
PDU size reconf. is not allowed

(except in some special cases)
sduRetransmitAfterPduSizeChange
Figure 6: 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.
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
Page 44/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 used 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 stands for
whether the SDUs and which kind of SDUs shall be resegmented after PDU size
change. Following values are possible:
None: no SDUs in the RNC RLC SDU buffer shall be resegmented. In this
case, all already received SDUs are discarded, which may cause high layer
packet loss.
NotTransmitted: only the not transmitted SDUs shall be re-segmented with

new RLC PDU size and transmitted. The others are discarded, which may
cause high layer packet loss.
NotFullyTransmitted: the not transmitted and partially transmitted SDUs shall

be resegmented with new RLC PDU size and retransmitted. The others are
discarded, which may cause high layer packet loss.
NotFullyAcknowledged: the not transmitted and partially transmitted SDUs,

and 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. No SDUs are discarded. In this case, the
PDU size change does not cause high layer packet loss.
Parameter
RAN Path
Range & Unit
User
Class
Value
sduRetransmitAfterPduSizeChange
Object
DlRlcAckMode
RNC / RadioAccessService / RlcConfClass / DlRlcAckMode
[none, notTransmitted, notFullyTransmitted, notFullyAcknowledged] Enum
Customer
Granularity
RlcConfClass
3
notFullyAcknowledged
UE capabilities handling: Along with 34340 (and according to the flag
isDynamicMacdPduSizeManagementAllowed), when a MAC-d flow is setup for a
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]).
Page 45/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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

In summary, this feature allows the activation of a workaround for a Qualcomm
chipset bug which occurs when UE transitions from URA_PCH/Cell_FACH to Cell_DCH
and at the same time the PDU size is reconfigured to 656 bits.
There is a bug on some Qualcomm E-DCH R6 UEs in relation to 656 PDU. If the UE
goes into URA_PCH state and then out again via FACH to DCH, the E-DCH throughput
is throttled to around 100kbps.
It is related to combined RLC reconfiguration and PDU size change during FACH to
DCH transition. UE does not apply the DCH parameters for UL RLC hence reducing the
UL throughput.
In general, any RRC Radio Bearer Reconfiguration which concurrently changes the UL
RLC parameters and DL PDU size to 656 bits will cause the problem.
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.
Page 46/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 7: Conditions to invoke the feature 79164

The activation flag for this feature is:
Parameter
is2ndRrcRbReconfNeededForQC7200
RAN Path
Range & Unit
User
Class
Value
{True, False}, Boolean
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
True
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).
Page 47/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Mac-hs
Mac- SDU
MAC-hs PDU
MAC-hs SDU
MAC-hs SDU
RLC PDU = MAC-d SDU = MAC-d PDU
21
320
16
320
16
320
16
320
16
320
16
Padding
Figure 8: 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
RAN Path
Range & Unit
User
Class
Value
ueCategoryX
Object
HsdpaUeCategoryTransportBlockOptimisation
X = [1..12]
BTSEquipment / BTSCell / HsdpaConf / HsdpaUeCategory /
HsdpaUeCategoryTransportBlockOptimisation
Customer
Granularity BTSCell
3
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.
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):
Page 48/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Mac-d PDU size = 656 bits
Transport Block Size
CQI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
14
15
16
17 - 30
17
18
19
20
21
22
23 - 30
23 - 30
23
24
25
26 - 30
26
27 - 30
27 - 30
27 - 30
Number
of
Modulation
Default Optimised Max capability MAC-d
PDU
792
792
792
792
792
792
792
792
792
792
1483
1742
2279
2279
3319
3319
3319
4189
4664
5287
5287
6554
7168
7168
686
686
686
686
686
686
686
686
686
686
1356
1356
2010
2677
3319
3319
3319
3970
4664
5287
5287
5993
6673
6673
7298
9719
11418
14411
14411
17237
17237
9210
11216
13904
13904
17237
17237
21754
21754
20251
1
1
1
1
1
1
1
1
1
1
2
2
3
4
4
5
5
5
6
7
8
8
9
10
10
11
14
17
21
21
26
26
30
33
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
Number
of
HSPDSCH
codes
2
2
2
2
2
2
2
2
2
3
3
3
4
4
4
5
5
5
5
5
5
5
5
5
5
5
7
8
10
10
12
12
15
15
Applicable
for
Power offset
UE
category
+7dB
+6dB
+5dB
+4dB
+3dB
+2dB
+1dB
0dB
-1dB
-2dB
0dB
-1dB
0dB
-1dB
0dB
0dB
-1dB
15 - CQI
0dB
0dB
0dB
-1dB
0dB
0dB
22 - CQI
23 - CQI
0dB
0dB
0dB
25 - CQI
0dB
26 - CQI
27 - CQI
27 - CQI
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
1 - 12
11 - 12
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1-6
1-6
7 - 10
7 - 10
7 - 10
7-8
9 - 10
9
9
10
Table 2: CQI mapping table for 656 bits MAC-d PDU size
Note that with MAC-d PDU size = 656 bits, the minimum number of HS-PDSCH codes
that can be managed is 2 if the feature Flexible Modulation (see section 5.4) is
disabled. If Flexible Modulation is enabled, even 1 HS-PDSCH code can be managed
with a MAC-d PDU of 656 bits.
Page 50/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[iCEM] [xCEM][eCEM]
Based on Figure 8: 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 / TTI
Th_rlc = Nb_of_MAC-d_pdu * (MacdPduSize-16) / TTI
For iCEM:
Some UE categories are limited to a maximum TBS (see [Vol. 2]). So, above a certain
CQI, TBS does not increase anymore but power is reduced by 1dB per CQI. Moreover,
for a given CQI, TBS can have different values:
Parameter
RAN Path
Range & Unit
User
Class
Value
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
ueCategoryX
Object
HsdpaMaxUeCategoryCapabilityActivation
X = [1..12]
BTSEquipment / BTSCell / HsdpaConf / HsdpaUeCategory /
HsdpaMaxUeCategoryCapabilityActivation
True, False
Customer
Granularity BTSCell
3
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
1-6
7298
78
14411
20251
MAC-d PDU
size
336
656
336
656
336
656
Maximum number
of
MAC-d PDU
21
11
42
21
60
30
hsdschInterval
max (ms)
190
370
90
190
60
130
Page 51/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE
category
Maximum
Transport
Block Size
10
21754
11 - 12
3630
MAC-d PDU
size
336
656
336
656
Maximum number
of
MAC-d PDU
64
33
10
5
hsdschInterval
max (ms)
60
120
400
810
Table 3: Max hsdschInterval value

A value too high for hsdschInterval parameter will lead to reduce throughput.
For iCEM, the recommendation for hsdschInterval is 50ms.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdschInterval
[10500] ms step = 10
Customer
3
Object
HsdpaConf
Granularity
BTSCell
50ms
For xCEM and eCEM:
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 HSDSCH 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 HSDSCH interval the necessity (at most each 80ms). The HS-DSCH interval is 80
ms and an infinite repetition period is used, allowing to not resend a
CAPACITY ALLOCATION each 80ms if it is not needed.
As described above, if the MCS selected corresponds to a Transport Block Size that
exceeds what the UE can support according to its category then a lower MCS is
selected and the power requirements are lowered by -1dB/CQI. This is described in
the table below:
Page 52/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

MAC-d PDU size = 336 bits
UE
category
Maximum HSDSCH TBS per TTI
Maximum
MCS
TBS applied from

maximum MCS
Max MAC-d
PDUs
1 to 6
7 to 8
9
7298
14411
20251
22
25
27
7168
14155
20251
21
42
60
10
27952
27 (iCEM)
29 (xCEM)
21754 (iCEM)
23792 (xCEM)
64 (iCEM)
70 (xCEM)
11 to 12
3630
16
3440
10
UE
category
1 to 6
7 to 8
9
10
11 to 12
MAC-d PDU size = 656 bits

Maximum HSMaximum
TBS applied from
DSCH TBS per TTI
MCS
maximum MCS
7298
23
7298
14411
25
13904
20251 (iCEM)
20251
27
19891 (xCEM, eCEM)
27 (iCEM)
21754 (iCEM)
27952
30 (xCEM,
26490 (xCEM, eCEM)
eCEM)
3630
UE
category
1 to 6
7 to 8
9
10, 16 and
22
11 to 12
13, 17, 19
and 23
14, 18, 20
and 24
15 and 21
15
3319
MAC-d PDU size = flexible

Maximum HSMaximum
TBS applied from
DSCH TBS per TTI
MCS
maximum MCS
7298
23
7152
14411
25
13940
20251
27
19904
27952
30
3630
15
30
30
30
30
28
35280
42192
23370
27464
35280
27464
39984
Max MAC-d
PDUs
11
21
30
33 (iCEM)
40 (xCEM,
eCEM)
5
Max MAC-d
PDUs
N/A
N/A
N/A
26504
N/A
3576
with 16QAM
with 64QAM
with 16QAM
with 64QAM
22968
N/A
N/A
N/A
N/A
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU
Size
5.4 TFRC SELECTION

[xCEM][eCEM]
TFRC (modulation, number of HS-PDSCH and Transport Block Size) is determined as
described in 4.1.1.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.
Page 53/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[iCEM]
Previously to UA6.0, there was no flexibility between modulation and number of HSPDSCH codes (QPSK used with 1, 2, 3, 4 and 5 HS-PDSCH and 16QAM used with 5
codes or more). 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 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 request:
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 than or equal to 5) and the MAC-d PDU size. Based on
these inputs TFRC will be selected to maximize the throughput.
- Number of remaining codes
Mapping
tables
- Modulation = 16QAM
- ue category
- TBS
- mac-d PDU size
- Power offset
Figure 9: Codes limitation

Page 54/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
- Number of remaining codes
Mapping
tables
- Modulation = QPSK
- TBS
- mac-d PDU size

- ue category
Figure 10: Code boost
Note that the code boost is not applicable for Cat.1-6 and 12 (max nb of codes = 5)
Activation
hsdpaFlexibleModulationVsCodeActivation
Parameter
RAN Path
Range & Unit
User
Class
Value

Boolean {True, False}
Customer
3
Object
HSDPAConf
Granularity
BTSCell
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
Page 55/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.4.2 64 QAM FOR HSDPA xCEM/eCEM/UCU-III ONLY

5.4.2.1 DESCRIPTION
From UA7.x, the xCEM/eCEM/UCU-III schedulers can use the 64QAM modulation to
transmit the HS-DSCH channel for the UE supporting the 64QAM modulation.
The 64QAM usage allows increasing 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
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)
- Category 19 and 20 (64-QAM and MIMO capable)
In this release MIMO is supported in demo mode only and is not to be deployed so
UE categories 17/ 19 and 18/ 20 are handled respectively as category 13 and 14. Note
that all 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 @ machs). Note that UE Cat 19 to 24 will be handled as equivalent UE Categories, according
to table 4, in section 5.3.
Page 56/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Category
64QAM/MIMO not
configured
Used CQI mapping table

MIMO configured
64QAM
configured
In case of type B or single In case of dual
transport block type A
transport block
CQI reports
type A CQI
reports
N/A
1-6
7 and 8
N/A
N/A
10
N/A
11 and 12
N/A
13
N/A
14
N/A
15
N/A
16
N/A
17
18
Table 5: CQI Mapping Tables
Note: The letters above correspond to a specific CQI mapping table, including the
transport block size, number of HS-PDSCH codes, modulation, etc.
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 allowed thanks to mac-ehs and 64QAM are given
in table 4 (section 5.3).
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 only allows selecting 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).
Page 57/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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):
Slot format #i Channel Bit Channel Symbol
Rate (kbps)
Rate (ksps)
0(QPSK)
480
240
1(16QAM)
960
240
2(64QAM)
1440
240
SF Bits/ HS-DSCH
subframe
16
960
16
1920
16
2880
Bits/
Slot
320
640
960
Ndata
320
640
960
Table 6: 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.6 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
- 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 HSDSCH category supported by the UE when Mac-ehs is configured (If the Macehs 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
Page 58/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

- The UE category is allowed to use the 64QAM:
HsdpaRncConf. is64QamAllowedForUeCategory = 1 for all the UE
categories supporting 64QAM, that is to say 13, 14, 17 to 20, 23 and 24
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 and eCEM), 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 MACehs and/or 64-QAM over the Iur, ALU DRNC will refuse the configuration.
5.4.2.3 PARAMETERS SETTINGS

Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
isDl64QamOnRncAllowed
True, False
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
True
isDl64QamAllowed
True, False
Customer
3-a2
Object
FDDCell
Granularity
FDDCell
True
is64QamAllowedForUeCategory
Object
BitString 64 bits (0=not allowed, 1=allowed)
Customer
Granularity
3
HsdpaRncConf
RNC
0000000000000000000000000000000000000000110011110011000000000000
1 for all the UE categories supporting 64QAM, that is to say
13,14,17,18,19,20,23 and 24
Page 59/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Note that the following parameters are not used in this release:
RemoteFDDCell.isDl64QamAllowed
NeighbouringRNC.isIurDlQam64Allowed
NeighbouringRNC.isIncoming3Gto3GWithIur64QAMAllowed
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 HSPDSCH 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/E-RGCH, 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
0
1
0
2
1
3
0
4
2
5
1
6
3
7
0
8
4
9
2
10
5
11
1
12
6
13
3
14
7
15
0
16
8
17
4
18
9
19
2
20
10
21
5
22
11
23
1
24
12
25
6
26
13
27
3
28
14
29
7
30
15
31
2
1
3
4
2
5
6
3
7
8
4
9
10
5
11
12
6
13
14
7
15
P-CPICH
P-CCPCH + SCH
AICH
PICH
S-CCPCH #1
HS-SCCH #1
HS-SCCH #2
E-HICH + E-RGCH
E-AGCH
HS-PDSCH #15
HS-PDSCH #14
HS-PDSCH #13
HS-PDSCH #12
HS-PDSCH #11
HS-PDSCH #10
HS-PDSCH #9
HS-PDSCH #8
HS-PDSCH #7
HS-PDSCH #6
HS-PDSCH #5
HS-PDSCH #4
HS-PDSCH #3
HS-PDSCH #2
HS-PDSCH #1
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 60/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: Pre-requisites to reach 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
PSFP (Packed Server Functional Processor) 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 Fair Sharing enabled (Dyn codes mgt part):
codes (15)
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.
maxHspaPowerOffset can also be changed to reduce the available
power (PmaxHsdpa = Phsdpa = Pcell - maxHspaPowerOffset), but it is
not likely to be needed, thanks to implemented backoff power.
4- Setting
UL bearer allowing:
- throughput high enough to
acknownledge the high DL
throughput
- UL RLC 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.13, 14, 17 to 20, 23 and 24
RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode /
prohibitedStatusTimer = 10ms
4- Setting
Correct ATM setting
RadioAccessService/ HsdpaRncConf /
4- Setting
Correct Hybrid Iub setting
RadioAccessService/ HsdpaRncConf /
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)
minimumHsdschCreditPerTtiInBytes = 2296
RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1520
Maximum value for txQueueLimit of Access Node according the ATM card
RNC/ RNCEquipment / INode / EM / RncIn / Cm / activation =

discardAndBackPressure
RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolCellColor =
enabled
RNC/ RNCEquipment / INode / EM / RncIn / Cm /
bwPoolQosBackPressureThreshold and
bwPoolQosDiscardThreshold = see [R10]
Page 61/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa
congDRTAllowed = disabled
RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa
congFSNAllowed = enabled (this one has no impact on performances, it
is a requirement to get means of troubleshooting and investigations)
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
7- Core
Correct User Equipment and PC

client configuration
7- Core
Correct VPN and Firewall

configuration
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 to 20, 23
and 24
FDDCell / isDl64QamAllowed = TRUE
1- Feature
34388 "L2
improvements :
flexible RLC & MACehs" 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 or eCEM with

iBTS and UCUIII with
oneBTS
Page 62/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.5 DUAL CELL HSDPA OPERATION xCEM/eCEM/UCU-III

5.5.1 OVERVIEW
UA7.1.2 feature Dual Cell HSDPA Operation (HSDPA-DC) introduces 3GPP Rel8 HS+
functionality whereby R8 capable UE is able to achieve twice the throughput as
compared to Rel7 UE under similar radio and resource conditions. This allows
reaching peak applicative throughput of 37Mbps while providing better user
experience even at cell edge.
This is achieved by scheduling simultaneously through two cells of common sector
that are on adjacent carriers within same UMTS band and share same antenna
connection. One carrier (cell) designated as Anchor (serving) carries all the normal
traffic and common channels (UL and DL) involved in HSDPA call, while other
supplementary carrier (secondary serving cell) only sends HS-PDSCH and HS-SCCH as
an additional data pipe line to the UE
An added advantage is the ability to provide dynamic load sharing between these two
cells on a per TTI basis which matches the bursty traffic demand with the available
on-air capacity available creating best network utilization.
The usage of the HSDPA-DC implies system modifications:
New UE categories
New ACK/NACK & CQI mapping for the HS-DPCCH
Feature Dual Cell HSDPA Operation (HSDPA-DC) is supported from UA08.1 in US

Market (feature 114637).
New UE categories
New UE categories have been introduced in order to support the HSDPA-DC:
- Category 21 and 22 (16-QAM and DC capable),
- Category 23 and 24 (64-QAM and DC capable)
So to achieve peak throughput it is recommended to use higher UE category like 24
New ACK/NACK & CQI mapping for the HS-DPCCH

As explained in Vol.2, a new mapping is introduced to provide the capability to send
ACK/NACK and CQI information for the two carriers on a common HS-DPCCH physical
channel since UL is only supported on Anchor carrier
Page 63/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.5.2 CONFIGURATION
HSDPA-DC is configured if the following conditions are fulfilled:
- The local cell is HSDPA-DC capable: The NodeB indicates to the RNC its cells
DC capability through Multi Cell Capability Info IE in the NBAP Audit Response or
Resource Status Indication messages by setting Multi Cell Capable" for the Local
Cell and populating the SecondaryServingCellList with valid secondary serving cell
- The UE is HSDPA-DC capable: The UE informs the RNC of its capabilities in the
RRC Connection Setup Complete message:
- multiCellSupport IE is set to TRUE (3GPP Rel8)
- HS-DSCH physical layer category extension2 IE corresponding to the HSDSCH category supported by the UE when HSDPA-DC and MAC-ehs are
configured
- The UTRAN is allowed to use HSDPA-DC:

RadioAccessService.isHsdpaDualCellAllowed = True
FDDCell.isHsdpaDualCellActivated = True
BTSCell/HsdpaConf.dualCellActivation = True
MAC-ehs (see section 5.6), HSDPA and E-DCH are enabled on both cells
UA7-UA08 Delta: Parameter hsdpaPlusPreferredMode evolution
In UA7 hsdpaPlusPreferredMode was an activation parameter for HSDPA-DC: it was required to be
set to dualCellPreferred in order to perform DC calls.
In UA08, it is used under certain conditions, jointly with
hsdpaUserCountDynamicPreferenceDcMimo, as a selector between HSDPA-DC and MIMO. The
selection algorithm is described in section 5.5.4.
- The UE category is allowed to use HSDPA-DC:

HsdpaRncConf.isDualCellAllowedForUeCategory = 1 for all the HSDPA-DC
capable UE categories, that is to say 21 to 24
- The Configuration passes various OAM checks:

FDDCell.tCell and FDDCell.dualCellId parameters match for the respective
cells defined under dual cell configuration
If all these conditions are fulfilled, then RNC will place a HSDPA-DC call on the dualcell
by sending appropriate RRC and NBAP reconfiguration messages to the UE and NodeB
respectively, provided that the HW capacity and Call Admission Control requirements
are satisfied.
Page 64/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.5.3 INTERACTION & MOBILITY

Note that 64-QAM activation is not mandatory pre-requisite for HSDPA-DC but only
desirable in order to achieve higher throughput. Alcatel-Lucent UTRAN allows any
combination of 64 QAM and 16 QAM/QPSK between anchor and supplementary
carrier. One cell which is serving for one DC UE, can be secondary serving for another
DC UE at the same time. This allows for highest level of flexibility and most efficient
capacity usage.
The following mono and multi-RAB combinations are eligible for Dual Cell HSDPA:
Single PS I/B RAB: SRB DCH + PS I/B HSPA; SRB HSPA + PS I/B HSPA
Multiple PS I/B RAB, when isMultiRabForDualCellHsdpaAllowed is TRUE:

SRB DCH + n PS I/B HSPA; SRB HSPA + n PS I/B HSPA
A PS Streaming RAB is also eligible for HSDPA-DC, at the condition it is

associated with a PS I/B RAB.
The multi-service calls (CS+PS), the standalone PS Streaming over HSDPA, the
standalone SRB over HSPA and the PS I/B RAB with the signalling indicator set to
SIGNALLING are not eligible for HSDPA-DC and will be setup as legacy HSDPA call.
Note: The flag isMultiServiceForDualCellAllowed intends to enable/disable the
multi-service calls (CS+PS) on HSDPA-DC, however it must remain FALSE as this
combination is not supported.
UA7-UA08 Delta: RAB eligible for Dual Cell HSDPA

In UA7, only single PS I/B RAB mapped to HSDPA/HSUPA is eligible for HSDPA-DC call else any multiRAB or multi-service call will be setup as legacy HSDPA call.
Starting from UA08.1, with the feature 104832/118154 Dual Cell HSDPA capacity increase, the
eligibility for HSDPA-DC is extended to some multi-RAB combinations as listed just above.
In case of call mobility toward a cell where HSDPA/HSUPA is handled by iCEM

(HSDPA-DC is only supported by xCEM and eCEM), a reconfiguration towards legacy
HSDPA is triggered and vice versa. On iCEM UE category 13 are handled as category 9
and UE category 14 and above are handled as category 10.
Mobility of a HSDPA-DC capable UE between two HSDPA-DC capable cells is
supported. Legacy mobility procedures (like SHO and HHO) are supported based on
the serving cell only. The secondary serving cell does not belong to the active set of
the UE.
HSDPA-DC is not supported over Iur (as MAC-ehs). Alcatel-Lucent SRNC will
reconfigure the call to MAC-hs and legacy HSDPA when the serving cell moves under
the control of a DRNC. Alcatel-Lucent DRNC will not advertise MAC-ehs and HSDPADC support over the Iur. If a SRNC decides to use MAC-ehs and/or HSDPA-DC over
the Iur, Alcatel-Lucent DRNC will reject the configuration with cause Multi Cell
operation not supported".
Page 65/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.5.4 PARAMETER SETTINGS

The following parameter enables/disables the support of HSDPA Dual Cell operation
within the RNC
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsdpaDualCellAllowed
True, False
Customer
3-b
Object
RadioAccessService
Granularity
RNC
True
This parameter enables/disables the support of Dual Cell per UE category within the
RNC. Bit 0 corresponds to HSDPA category 1. Bit 63 corresponds to category 64
Parameter
RAN Path
Range & Unit
User
Class
Value
isDualCellAllowedForUeCategory
Object
BitString 64 bits (0=not allowed, 1=allowed)
Customer
Granularity
3-b
HsdpaRncConf
RNC
0000000000000000000000000000000000000000111100000000000000000000
1 for all the UE categories supporting HSDPA-DC, that is to say 21 to 24
This parameter enables/disables some multirab combinations eligibility for Dual Cell
HSDPA. When this flag is set to FALSE, the RNC provides the same functionalities than
the ones introduced in 81204. When set to TRUE, it allows supporting multirab
combination introduced by 118154.
Parameter
RAN Path
Range & Unit
User
Class
Value
isMultiRabForDualCellHsdpaAllowed
True, False
Customer
3
Object
RadioAccessService
Granularity
RNC
True
This parameter is for future use and will enable/disable the support of multi-service
call on Dual Cell HSDPA. Currently it is not supported and the parameter must remain
FALSE.
Parameter
RAN Path
Range & Unit
User
Class
Value
isMultiServiceForDualCellAllowed
True, False
Customer
3
Object
RadioAccessService
Granularity
RNC
False
These parameters activate / deactivate the support of HSDPA Dual Cell operation at
cell level.
Page 66/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

isHsdpaDualCellActivated
Parameter
RAN Path
Range & Unit
User
Class
Value

True, False
Customer
3-b
Object
FDDCell
Granularity
FDDCell
Object
HsdpaConf
Granularity
BTSCell
Object
OneBTSCell
Granularity
Cell
True
[xCEM][eCEM]
dualCellActivation
Parameter
RAN Path
Range & Unit
User
Class
Value

True, False
Customer
0
True
[UCU-III]
dualCellActivation
Parameter
RAN Path
Range & Unit
User
Class
Value
OneBTSEquipment / OneBTSCell
True, False
Customer
0
True
Following allows the operator, if all the conditions are satisfied for both features, to
choose between MIMO mode and HSDPA Dual Cell operation within the RNC. Since
MIMO is supported in a demo mode, it is recommended to keep this parameter set to
dualCellPreferred.
hsdpaPlusPreferredMode
Parameter
RAN Path
Range & Unit
User
Class
Value

none, dualCellPreferred, mimoPreferred
Customer
3-b
Object
FDDCell
Granularity
FDDCell
dualCellPreferred
The following defines a dynamic preference between DC-HSDPA users and MIMO
users at cell level when hsdpaPlusPreferredMode= NONE, according to the algorithm
described just after.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaUserCountDynamicPreferenceDcMimo
[1..128]
Customer
3
Object
FDDCell
Granularity
FDDCell
Page 67/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

IF
THEN
The UE is both MIMO capable and DC-HSDPA capable AND if criteria to establish the
call as DC-HSDPA and as MIMO are both met
hsdpaPlusPreferredMode is used as selector between DC-HSDPA or MIMO

IF hsdpaPlusPreferredMode = dualCellPreferred THEN DC-HSDPA is chosen
IF hsdpaPlusPreferredMode = mimoPreferred THEN MIMO is chosen
ELSE
IF hsdpaPlusPreferredMode = none THEN

IF number of active (Cell_DCH state) legacy HSDPA+64QAM+MIMO+DC users in the
cell is less than hsdpaUserCountDynamicPreferenceDcMimo THEN DC-HSDPA
is chosen ELSE MIMO is chosen
hsdpaPlusPreferredMode is ignored.
This parameter indicates the cell with the adjacent frequency to the anchor cell. It is
used to identify the secondary serving cell supporting the HSDPA Dual Cell operation
Parameter
RAN Path
Range & Unit
User
Class
Value
dualCellId
Undefined & List of AsciiString
Customer
3-b
Object
FDDCell
Granularity
FDDCell
See Rule
Rule: dualCellId and HSDPA-DC

In order to allow RNC to configure dual cell HSDPA operation, the two local cells that are physically
and logically configured to share same antenna connection, via antennaConnection and common
timing via tCell, should also have correct dualCell ID configured in MIB, which matches the logical Cell
Id received from RSI or Audit response message of the given NodeB.
The following parameters represent the maximum number of simultaneous DC-HSDPA

users (and MIMO users combined, for eCEM) allowed per xCEM, eCEM and UCU-III
board. Each DC-HSDPA user takes two resources (as well as MIMO user on eCEM),
e.g. if value 15 is given, actually 30 resources will be taken from board and thus,
number of legacy HSDPA users would be 128 30. There is also a corresponding
internal limit (not configurable) for each of these parameters, which can take the
maximum value of 15. If the value of these parameters is greater than the internal
limit, the kept value is the MIN(parameter, internal limit). For the internal limit, 0
means that no DC-HSDPA user is allowed by software and hardware.
Parameter
RAN Path
Range & Unit
User
Class
Value
dualCellHsdpaMaxNumberUserXcem
BTSEquipment
[1..42]
Customer
3
Object
BTSEquipment
Granularity
BTS
15
Page 68/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

dualCellHsdpaMimoMaxNumberUserEcem
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
[1..64]
Customer
3
Object
BTSEquipment
Granularity
BTSCell
15
dualCellHsdpaMaxNumberUserUcu
Parameter
RAN Path
Range & Unit
User
Class
Value
OneBTSEquipment
[1..42]
Customer
3
Object
OneBTSEquipment
Granularity
BTS
15
5.5.5 NODEB IMPACT

As per 3GPP, time alignment error which is defined as the delay between the signals
from the two cells at the antenna ports, shall not exceed Tc (i.e. 65nsec), where Tc
denotes the chip duration. Such stringent requirement stipulates use of configurations
where both dual cells follow same transmit path:
STSR2
STSR3
STSR2+1 or STSR2+2, generally speaking STSRx+y where the paired dual cells
are both on the x carriers or both on the y carriers.
STSR1+1, and STSRx+y where the dual cells follow different transmit path (one of
the paired dual cells is on a x carrier and the other is on a y carrier) is also
supported provided it satisfies the conditions described in the table below.
These conditions are checked by the BTS at startup. If the BTS checks fail, an Alarm
<CONFIGURATION FILE INCONSISTENT WITH HARDWARE> is sent and the BTS is
not built, meaning it is fully not operational.
Page 69/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Supported Hardware
NodeB radio configurations
iTRM / MCPA
xTRM / MCPA
TRDU
CPRI RRH
STSR2 or STSR3 or STSRx+y

where pair of cells supporting
Yes with 2 iTRM
Yes
Yes
Yes
Dual Cell operation follow same
Tx paths
A pair of MCPA
A pair of TRDU
STSR1+1 or STSRx+y where
supporting DCYes with same supporting DCpair of cells supporting Dual
HSDPA share the power MCPA
HSDPA share the Yes with TWIN PA RRH
Cell operation does not follow
same APN Alcatel (*)
same APN Alcatel
same Tx paths
Part Number
Part Number
(*) HSDPA-DC is supported in case of mixity between xTRM and xTRM-2. HSDPA-DC
operation is not supported in case of mixity between xTRM and iTRM, i.e in a
configuration STSR2+1, where xTRM is used on the F1+F2 Tx Path and iTRM is used
on the F3 Tx path, F1 (or F2) can not be paired with F3 for Dual Cell operation.
UA7-UA08 Delta: Support of Dual Cell HSDPA on NodeB configurations

In UA7, with TRDU or RRH, the carriers operating in DC mode had to be transmitted by the same RRH
or TRDU (i.e STSRx+y with RRH or TRDU did not support Dual Cell).
Starting from UA08.1, with the feature 104832/118154 Dual Cell HSDPA capacity increase, in case of
BTS using a Twin PA RRH or TRDU, DC-HSDPA operation is supported whatever the mapping of the
carriers across the PA.
For more information on the STSR2, STSR3, STSRx+y concepts, refer to [R08].
Timing alignment is needed when DC-HSDPA cells in one sector are served by two
different Tx paths. The delay calculations and compensations are ensured digitally via
the xCEM and xTRM modules.
The maximum number of simultaneous Dual Cell HSDPA users per board is
configurable (when this value is reached, the next DC capable UE will be configured
with legacy HSDPA call). The maximum value is 15 for all types of board (xCEM,
eCEM, UCU-III).
Note: OA&M maximum range shows higher value than 15 (42 for xCEM, 64 for eCEM,
42 for UCU-III) but the NodeB has an internal limit to 15. The effective maximum
number is minimum (15, OA&M parameter value).
1 DC-HSDPA user is counted as 2 HSDPA connections, among 128 available. This
means the numbers of simultaneous SC-HSDPA users and DC-HSDPA users satisfies
the following condition:
(Number of SC-HSDPA Users + (2 * Number of DC-HSDPA Users)) <= 128
Page 70/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UA7-UA08 Delta: Maximum number of simultaneous Dual Cell HSDPA users per board
In UA7, maximum number of HSDPA-DC users is limited to 4 per board.
Starting from UA08.1, with the feature 104832/118154 Dual Cell HSDPA capacity increase, this
number is configurable and can be up to 15 DC-HSDPA users per board.
There will be one common priority queue (and MAC-ehs entity) shared between the
carriers but separate MAC-ehs PDUs for different carriers. Also independent scheduler
and HARQ entity for each carrier/ cell will be implemented which restricts the MAC-d
SDU count to 13 per MAC-ehs PDU to satisfy 3GPP restriction.
Two schedulers are aware if the GBR is being achieved for a given user by using the
aggregate throughput that is being served for that user but resulting user ranking is
performed on individual cell basis. All QoS related parameters are shared by both
cells.
Even though both schedulers are independent and use separate HARQ entities,
Alcatel-Lucent
recommends
configuring
same
scheduler
type
(HsdpaSchedulerAlgorithmXcem) between the two cells.
NBAP common measurements (including HS-DSCH Required Power) are reported
independently for each cell.
Rule: interaction between Dual Cell and MAC-Hs GBR
When Dual Cell is configured, isDlPowerSelfTuningForPsIbOnHsdpaEnabled shall be the same
for both carriers: either both to TRUE to make MAC-Hs GBR working properly for DC PS I/B calls, or
both to FALSE (if the operator does not wish to ensure Mac-hs GBR).
Refer to [Vol. 5] for the description of isDlPowerSelfTuningForPsIbOnHsdpaEnabled parameter.
Both schedulers share the same MAC-d priority queue, associated with the anchor cell,
for one user. The schedulers shall not access the common priority queue at the same
time, to avoid duplication of TB information on air, but can do so in the same TTI.
Page 71/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: Pre-requisites to reach the maximum throughput with
HSDPA-DC
The following pre-requisites are needed to reach the maximum throughput with HSDPA-DC:
Domain
1- Feature
Pre-requisite
xCEM/eCEM board capacity
and UTRAN Licensing
configured to allow max
throughput
Comment
Feature 113511 is recommended to be activated to enable 39.6Mbps HSDPA
capability in xCEM and eCEM else xCEM and eCEM will limit the overall
throughput to 28.8Mbps. eCEM can even go up to 60Mbps (using feature
PM89411 - eCEM 128 HSUPA 2ms TTI connections, described in [R09]).
For NodeB with xCCM/eCCM configured with MDA-GE:
hsdpaMaxThroughputXcem = automatic or 39600

hsdpaMaxThroughputEcem = automatic or 61200
For NodeB with xCCM/eCCM configured with MDA-E1 (FE on motherboard):
hsdpaMaxThroughputXcem = 34200.
hsdpaMaxThroughputEcem = 34200.
1- Feature
64-QAM and MAC-ehs

enabled
RadioAccessService / isDl64QamOnRncAllowed = TRUE

HsdpaRncConf / is64QamAllowedForUeCategory = 1 for Rel8 UE Cat 23 &
24
FDDCell / isDl64QamAllowed = TRUE
RadioAccessService / isMacehsAllowed = TRUE
FddCell / isMacehsAllowed = TRUE
2- Software
SGSN R7 and GGSN R6
3- Hardware
Hybrid Iub or Native IP Iub

(xCCm on NodeB and GIGe
on RNC needed)
In order to achieve high throughput, Hybrid/ Native IP Iub is recommended

with MDA-GE interface on xCCM. Nevertheless, ATM (iCCM) are also supported
3- Hardware
RNC Packet server : DCPS
DCPS (Dual Core Packet Server) allows to support higher throughput
3- Hardware
3GPP R8 UE
xCEM or eCEM with iBTS
HSDPA-DC is supported on xCEM from UA7.1.2, xCEM and eCEM from UA7.1.3
for iBTS
4- Setting
Maximum number of HSPDSCH 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
UL bearer allowing:
- throughput high enough
to acknownledge the high
DL throughput
- UL RLC BLER around 0%
HSUPA with 10ms or 2msec TTI is the only supported RAB in UL
4- Setting
Correct L2I setting
RadioAccessService / HsdpaRncConf / DlRlcQueueSizeForUeCat = 512 RLC

SDU for Cat.21 to 24
RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode /
prohibitedStatusTimer = 10ms
RadioAccessService / HsdpaRncConf / macEhsMaximumPduSizePsIb = 506
Bytes
4- Setting
Correct Hybrid/ Native IP

Iub setting
RadioAccessService/ HsdpaRncConf / minimumHsdschCreditPerTtiInBytes

= 1456
RadioAccessService / HsdpaRncConf /
Page 72/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdschCreditCapInNominalRatePercentage = 100%
4- Setting
Correct Iub congestion

management setting
If not correctly set, the throughput can fluctuate very strongly. The
recommended settings are available in [R10].
5- RF
High CQI
To assign 64-QAM modulation for highest spectral efficiency
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 4 (or more) FTP sessions in
parallel
7- Core
Correct GGSN configuration
7- Core
Correct SGSN configuration
7- Core
Correct User Equipment

and PC client configuration
7- Core
Correct VPN and Firewall

configuration
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))
Engineering Recommendation: hsdpaMaxThroughputXcem and
hsdpaMaxThroughputEcem
Generally speaking, the automatic value is recommended (assuming, of course, it complies with the
commercial agreement!). See [R09] for more details.
However, for NodeB with xCCM/eCCM equipped with MDA-E1 (Fast Ethernet on motherboard), the
value 34200 is recommended, in order not to exceed the limit of the xCCM with FE connection.
5.6 LAYER 2 ENHANCEMENTS: FLEXIBLE RLC AND MAC-EHS

UA7.0 feature 34388 Layer 2 Enhancements: flexible RLC and Mac-ehs is mandatory
to support the high HS-DSCH data rate offered by Rel7 UEs (categories 13 to 18) and
Rel8 UEs (categories 19 to 24).
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
Page 73/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
the Mac-ehs (at Nodeb), the RLC (at RNC and UE sides) : see section 5.6.1
and the IUB Frame Protocol (at RNC and Nodeb) : see section 5.6.2
This feature is applicable for xCEM, eCEM and UCU-III.
5.6.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 onwards).
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, defined by the MTU, in most IP networks. 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. From UA7.1.2 Alcatel-Lucent SRNC
will not concatenate segments of two different SDUs in the same PDU unless LI is set
to 15 bits as explained below. 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 reestablishment 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).
Page 74/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

However,
if
LI=15
bits
is
used
for
flexible
mode
(by
modifying
isLiForFlexibleRlcActivated to TRUE) 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 vice-versa.
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.
IF
THEN
ELSE
Parameter
RAN Path
Range & Unit
User
Class
Value
isLiForFlexibleRlcActivated = True (recommended)

RNC uses the value of (macEhsMaximumPduSizePsIb / Str) to determine the
required LI (i.e. 7 vs 15 bits). LI will be set to 15 bits for RLC PDU size over 126
bytes.
RNC RLC does not support LI and 7Bit is used to configure the UE RLC LI only
(consistent with UA 7.0 behavior).
isLiForFlexibleRlcActivated
Object
True, False
Customer
Granularity
3
HsdpaRncConf
RNC
True
Rule: isLiForFlexibleRlcActivated and HSDPA Dual Cell operation

The parameter isLiForFlexibleRlcActivated must be True to reach optimum HSDPA Dual Cell
throughput (feature 81204).
The benefit of the flexible RLC and MAC-ehs are illustrated in the next picture.
Page 75/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
RLC SDU
User Payload
RLC PDU (fixed size)
(1)
Pad.
MAC-d PDU
Mac-hs
MAC-hs PDU header
Pad.
MAC-hs SDU
Mac-hs
header
(2)
Transport Block Size (based on TRFC selection)
(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
RLC SDU
User Payload
RLC PDU (flexible size)
(1)
MAC-d PDU
= Mac-ehsSDU
MAC-ehs
PDU
MAC-d PDU 1
Mac-ehs
header
Reordering SDU 1
MAC-d PDU 2
Reordering SDU 2
MAC-d PDU 3
Mac-ehs
header
(2)
Reordering PDU
(3)
Transport Block Size (based on TRFC selection)

(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
Figure 11 : Benefits of flexible RLC and Mac-ehs versus fixed RLC and Mac-hs
Page 76/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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], [eCEM] 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
RAN Path
Range & Unit
User
Class
Value
isMacehsAllowed
True, False
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
True
Page 77/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

isMacehsAllowed
Parameter
RAN Path
Range & Unit
User
Class
Value

True, False
Customer
3-a2
Object
FDDCell
Granularity
FDDCell
True
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
RAN Path
Range & Unit
User
Class
Value
isRlcFlexibleSizeForPsStrAllowed
Object
True, False
Customer
Granularity
3
HsdpaRncConf
RNC
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
RAN Path
Range & Unit
User
Class
Value
macehsMaximumPduSizePsIb
Object
[42..1504] unit : bytes
Customer
Granularity
3
HsdpaRncConf
RNC
506
The maximum MAC-d PDU size for a PS Streaming Radio Bearer, is configured with
parameter macehsMaximumPduSizePsStr.
Page 78/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
macehsMaximumPduSizePsStr
Object
[42..1504] unit : bytes
Customer
Granularity
3
HsdpaRncConf
RNC
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 506 bytes (for PS I/B) and 378 bytes (for PS Streaming), in order to cope with PS
ciphering constraints (when MAC-d PDU size gets too big, the efficiency of the ciphering degrades).
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
RAN Path
Range &
Unit
User
Class
Value
dlRlcQueueSizeForUeCat
Object
HsdpaRncConf
List of 24 elements (one per Ue Category) in the range [0..2048];
unit : number of RLC SDUs
Customer
Granularity
RNC
3
(256,256,256,256,256,256,256,256,256,256,256,256,512,512,256,256,512,512,512,512,
512,512,512,512)
i.e 256 for all UE categories except 13, 14, 17 to 24, 512 for UE categories 13, 14, 17 to
24
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
RAN Path
Range & Unit
User
Class
Value
rlcRetransmissionBufferInKbytes
Object
HsdpaRncConf
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.
Customer
Granularity
RNC
3
500,1500,1500, 1500, , 1500
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 79/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

maxIubHsDschFrameSize
Object
[1..1520] ; unit : bytes
Customer
Granularity
3
Parameter
RAN Path
Range & Unit
User
Class
Value
HsdpaRncConf
RNC
1472 on Hybrid or Native IP Iub

1520 on ATM
1472 if ATM NodeBs and IP NodeBs coexist under the same RNC
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
RAN Path
Range & Unit
User
Class
Value
minimumHsdschCreditPerTtiInNumberOfPdus
[1..255], unit : nb of PDU
Customer
3
Object
HsdpaRncConf
Granularity
RNC
14
minimumHsdschCreditPerTtiInBytes defines the minimum number of bytes to
schedule per TTI for Flexible RLC mode; it does not apply in congestion recovery
case.
Page 80/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

minimumHsdschCreditPerTtiInBytes
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[42..8191] ; unit : bytes
Customer
Granularity
3
HsdpaRncConf
RNC
1456 on Hybrid or Native IP Iub

2296 on ATM
1456 if ATM NodeBs and IP NodeBs coexist under the same RNC
Engineering Recommendation: Setting for minimumHsdschCreditPerTtiInNumberOfPdus

and minimumHsdschCreditPerTtiInBytes when feature PM97431 is active
For networks with large Iub capacity on Iub (with overbooking on congestion management) settings
for parameters minimumHsdschCreditPerTtiInNumberOfPdus and
minimumHsdschCreditPerTtiInBytes should remain unchanged from the ones specified above.
In case of networks with limited buffering capacity on Iub (no overbooking on congestion
management) and in order not to have deviations from the nominal throughput ratios, the RNC will
have to be configured with:
minimumHsdschCreditPerTtiInNumberOfPdus = 1
This will impact the Iub usage efficiency. The Iub will be fully used but will carry more FP headers that
are not contributing to the end user throughput. As such, there will be performance compromise for
customers to be able to manage the OLS weight on the Iub.
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
RAN Path
Range & Unit
User
Class
Value
hsdschCreditCapInNominalRatePercentage
[100..1000] ; step 10 ; unit : %
Customer
3
Object
HsdpaRncConf
Granularity
RNC
100
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).
Page 81/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
nbrOfBytesBetweenPolling
Object
DlRlcAckFlexibleMode
RNC / RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode
Customer
3
Granularity
RlcConfClass
10000
Reconfiguration of existing PS RB during PS RB Setup/Release:
Delta {UA7.0, UA7.1} - UA7.1.2: sub-feature 34388.5

From UA7.1.2 onwards, the restrictions regarding the reconfiguration of an existing (or remaining) PS
Radio Bearer during a second PS RB Setup (or Release, respectively) are removed thanks to the
feature 34388.5. This sub-feature allows the existing (or remaining) RBs to perform a reconfiguration
between RLC fixed and RLC flexible mode, also between HSDPA 336 and 656 bits, concurrently with a
RAB Assignment (Setup or Release) operation, for Rel'6 or greater UEs.
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, and the first RB
stays not modified.
From UA7.1.2, the first RB is reconfigured to RLC fixed mode, and the 2nd RAB is
successfully added.
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.
From UA7.1.2, the transition towards RLC flexible/Mac-ehs mode for both RBs is
allowed.
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).
From UA7.1.2, the transition towards RLC flexible/MAC-ehs becomes possible.
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 82/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

From UA7.1.2, transition to MAC-ehs or fallback to DCH is allowed (no fallback to
MAC-hs is allowed).
5.6.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).
Throughput
The algorithm is pictured in the following figure.
Inflated rate, bounded by [MinimumHsdschCreditPerTti;

hsdschCreditCapInNominalRatePercentage * Nominal Rate]
Accumulated credits
from earlier part of
the interval
Nominal rate
Slow Start rate

Inactivity or
Congestion
Slow Start Period

Interval N
Interval N+1
Figure 12 : Slow start mechanism
Page 83/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The objects in the RAN model used to configure the Rb Congestion Control are shown
in the figure below.
RNC
Radio Access
Service
RbCongestionControl
HsDschSlowStart
dchSlowStart
HsDschSlowStart
HsDschSlowStart
HsDschSlowStart
Figure 13 : RB congestion control Object Tree
The parameter dchSlowStartActivation activates the congestion control for DCH

RB.
Parameter
RAN Path
Range & Unit
User
Class
Value
dchSlowStartActivation
Object
RNC / RadioAccessService / RbCongestionControl
True, False
Customer
Granularity
3
RbCongestionControl
Radio Access Service
True
The parameter hsdschSlowStartActivation activates the congestion control for
HSDPA RB.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdschSlowStartActivation
Object
RNC / RadioAccessService / RbCongestionControl
True, False
Customer
Granularity
3
RbCongestionControl
True
In case of PM97431 activation, it is recommended setting this parameter to
False.
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.
Page 84/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The parameter hsdschSlowStartPeriod gives the slow start period for HS-DSCH
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdschSlowStartPeriod
Object
HsDschSlowStart
RNC / RadioAccessService / RbCongestionControl / HsDschSlowStart
[0..20] step 2, unit ms
Customer
Granularity
HsDschSlowStart
3
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdschSlowStartRate
Object
HsDschSlowStart
RNC / RadioAccessService / RbCongestionControl / HsDschSlowStart
List of up to 10 values in the range [0%..100%], step 10, unit %
Customer
Granularity
HsDschSlowStart
3
HsDschSlowStart/burstFixed and HsDschSlowStart/burstFlexible :
empty list
HsDschSlowStart/congestionFixed and 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
RAN Path
Range & Unit
User
Class
Value
dchSlowStartPeriod
Object
DchSlowStart
RNC / RadioAccessService / RbCongestionControl / DchSlowStart
[0..20] step 10, unit ms
Customer
Granularity
DchSlowStart
3
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).
Page 85/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
dchSlowStartRate
Object
DchSlowStart
RNC / RadioAccessService / RbCongestionControl / DchSlowStart
List of 2 values in the range [0%..100%], step 10, unit %
Customer
Granularity
DchSlowStart
3
0, 50
Page 86/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6 CQI & MAC-HS BLER MANAGEMENT

6.1 CQI PROCESSING
The HS-DPCCH channel contains the CQI computed by the mobile from P-CPICH
power measurements. This CQI after demodulation and decoding by the NodeB
(noted CQIreported) is directly used by the scheduler.
HS-DPCCH demodulation
and CQI decoding
CQIreported
CQI adjustment based on BLER
(to reach a BLER target)
and HS-DPCCH activity (in order to deactivate
deficient UE by artificially setting its CQI to 0)
CQIprocessed
Figure 14: CQI Processing
Two algorithms have been introduced to handle bad UE behaviors that would disrupt
the system. Note that in the nominal case, these algorithms should not have any
impact.
The purpose of these algorithms is respectively to:
Adjust the received CQI (CQIreported) in order to maintain an acceptable BLER

on first transmission.
Isolate a deficient UE which never responds (constant DTX detection).
Both algorithms are processed just after the CQI report and can be processed in any
order. The resulting CQI from both steps (referred as CQIprocessed in this document)
constitutes the input of both flow control and scheduler algorithms (except HS-SCCH
power control).
Page 87/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.2 CQI ADJUSTMENT ACCORDING TO BLER

[iCEM]
The CQI adjustement according to BLER algorithm supports 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 parameters:
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.
1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no

possible parameterization, for iso-functional introduction. It is 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
2: outerLoopLikeAlgo. It corresponds to the UA5.x algorithm, allowing

defining and converging towards a specific BLER target (and not a
range).
3: dynamicOuterLoopAlgo. It corresponds to the UA6.0 evolution,

with dynamic BLER target switching. Three sets 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 is the computation and use of an offset (noted DeltaCqi) to apply
on reported CQI in order to keep the BLER on first transmission within an acceptable
range. The way and the frequency this variable is updated is as follows:
- 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 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.
Page 88/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

- Anytime a CQI is received, the offset is applied and the resulting value constitutes
the entry point of the scheduler.
Algorithm
The algorithm is 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
period. nbAckNack
hsdpaBlerObservationWindow (OMC-B parameter).
to
the
update
is
set
to
DownStep
(<0) is the step to update DeltaCqiCur when a NACK is received.
UpStep
(>0) is the step to update DeltaCqiCur when an ACK is received. And
upStepLowBlerT arg et =
downStep lowBlerT arg et

100 lowBlerT arg et
upStepMediumBlerT arg et =
upStepHighBlerT arg et =
downStep mediumBlerT arg et

100 mediumBlerT arg et
downStep highBlerT arg et

100 highBlerT arg et
With dynamicOuterLoopAlgo variant (the recommended one), 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:
Page 89/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

cqiThHigh
cqiThLow
CQI
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Cat.12
Cat.1-6
Cat.7-10
Cat.x
Bler Target = hsdpaBlerTargetUpperLimit
Cat.x
Bler Target < 30% (in practice around 10%)
dynamicOuterLoopAlgo
outerLoopLikeAlgo
blerRangeBasedAlgo
highBlerTarget = hsdpaBlerTargetUpperLimit
mediumBlerTarget = hsdpaBlerTargetMediumLimit
lowBlerTarget = hsdpaBlerTargetLowerLimit
Figure 15 : BLER Target according to the CQI and the UE category for the different BLER
Ajustement algorithm
Following steps are then performed:
Anytime feedback information is received from a scheduled UE, DeltaCqiCur is

updated:
o
If ACK, DeltaCqiCur is increased by UpStep
If NACK, DeltaCqiCur is decreased by DownStep
If DTX, no update (as in UA4.2)
Any CountCqi ACK/NACK information received, DeltaCqi is updated. The

rounded valued of DeltaCqiCur, bounded by limits (5), is added to DeltaCqi.
DeltaCqi variation between two updates is limited to 5 (CQI) because the wide range
of OMC-B parameters may lead to an algorithm divergence for certain set of values
(e.g. large update period with a big step).
Page 90/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 16: CQI adjustment to BLER algorithm
Parameters:
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo,
dynamicOuterLoopAlgo]
Customer
Granularity
3
HsdpaConf
BTSCell
dynamicOuterLoopAlgo
hsdpaAdjustBlerToChannelVariation
[TRUE, FALSE]
Customer
3
Object
HsdpaConf
Granularity
BTSCell
FALSE
Page 91/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: hsdpaCqiBlerAdjustmentAlgo
BLER Target algo (dynamicOuterLoopAlgo) brings 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
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerTargetUpperLimit
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerTargetLowerLimit
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerTargetMediumLimit

[1..99] %
Customer
3
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
30

[1..99] %
Customer
3

[1..99] %
Customer
3
20
Rule: Coherence between various BLER targets

Following interdependency rule should be observed on the values of hsdpaBlerTargetLowerLimit,
hsdpaBlerTargetMediumLimit and hsdpaBlerTargetUpperLimit:
hsdpaBlerTargetLowerLimit <= hsdpaBlerTargetMediumLimit <= hsdpaBlerTargetUpperLimit
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerObservationWindow
[1..100] Decimal (TTIs)
Customer
3
Object
HsdpaConf
Granularity
BTSCell
10
Page 92/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdpaBlerStepSize
Parameter
RAN Path
Range & Unit
User
Class
Value

[0.1..1.0] step:0.1
Customer
3
Object
HsdpaConf
Granularity
BTSCell
0.1
[xCEM][eCEM]
With xCEM/eCEM, 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.
constBlerTarget algorithm, MAC-hs BLER is managed as with iCEM

outerLoopLikeAlgo algorithm, except that the offset (ack,nack) is applied on SNR of
With
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/eCEM
loosely targets the constant BLER or packet error rate for first transmission and may
allow it to deviate from the target to optimize throughput.
When the feature is deactivated no control is performed on HARQ transmissions error
and the reported CQI is applied to select the transport block, in order to reach a
HARQ BLER on first transmission of less than 10%. With constBlerTarget algorithm
the control loop is performed to reach a target hsdpaBlerTargetUpperLimitXcem
BLER on first HARQ transmission.
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 and eCEM as:
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaCqiBlerAdjustmentAlgorithmXcem
Object

[deactivated, constBlerTarget, dynamicHarqTxTarget] Enum
Customer
Granularity
3
HsdpaConf
BTSCell
constBlerTarget
Page 93/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Restriction: dynamicHarqTxTarget
For hsdpaCqiBlerAdjustmentAlgorithmXcem, only 2 values are supported :
-
deactivated,
constBlerTarget
The value dynamicHarqTxTarget should not be selected since this algorithm is not supported.
parameter
hsdpaBlerTargetUpperLimitXcem
is
used
when
constBLERTarget is selected and determines which limit is used as target for HSDPA
The
packet error rate.

Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerTargetUpperLimitXcem
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaBlerTargetLowerLimitXcem

[199] %
Customer
3
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
15

[199] %
Customer
3
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:
HSDPA_SINR_up_step
HSDPA_packet_error_target
=
HSDPA_SINR_down_step 1 HSDPA_packet_error_target
Page 94/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
HSDPA_SINR_down_step
RAN Path
Range & Unit
User
Class
Value
None (tunable parameter)

[0512] & each step is equal to 0.001 dB
0
400 (meaning 0.4 dB)
Parameter
HSDPA_packet_error_rate_target
RAN Path
Range & Unit
User
Class
Value

[0...100] %
0
15%
Parameter
HSDPA_SINR_max_factor
RAN Path
Range & Unit
User
Class
Value

[-200,,330] & each step is equal to 0.1 dB
0
20 (meaning 2dB)
Parameter
HSDPA_SINR_min_factor
RAN Path
Range & Unit
User
Class
Value

[-400,,200] & each step is equal to 0.1 dB
0
Object
None
(tunable
parameter)
Granularity
NodeB
Object
None
(tunable
parameter)
Granularity
NodeB
Object
None
(tunable
parameter)
Granularity
NodeB
Object
None
(tunable
parameter)
Granularity
NodeB
-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

[xCEM][eCEM]
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.
Page 95/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

It is necessary for Compressed Mode in MAC-hs feature to introduce a detection
algorithm on CQI.
A user is eligible for scheduling only when a sufficient quality for that user has been
detected: a CQI > 0 has been received for the current TTI and synchronization on the
associated HS-DPCCH of that user has been detected.
This algorithm manages two states: HSDPA Synchronized
Synchronized. The main principles of the algorithm are as follows:
and
HSDPA-Not
The initial state is considered as not synchronized (HSD_OUT_SYNC), i.e.

nothing has been yet received on HS-DPCCH.
To acquire the synchronization on the HS-DPCCH (HSD_IN_SYNC), N

successive CQI must be detected.
Once in that HSD_IN_SYNC state, CQI are taken into account in the MAC-hs.
In case of DTX, the last decoded value is kept.
If M successive expected CQI are not detected (DTX), then the UE falls into
the HSD_OUT_SYNC state.
During that HSD_OUT_SYNC state, the UE must not be scheduled anymore.

CQI still remains to be detected and 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.
Page 96/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 17: HS-DPCCH synchronization algorithm
The synchronisation on HS-DPCCH algorithm is activated by default and the

parameters are hard-coded:
A UE is considered in sync if N=2 consecutive subframes on the associated

HS-DPCCH are in sync.
A UE is considered out of sync if M=8 consecutive subframes on the

associated HS-DPCCH are out of sync.
Note: The HS-DPCCH in sync status is reported each subframe of 2ms by the CE.
Since the HS-DPCCH TTI has a length of 5 subframes, 5 consecutively reported status
values have the same value. The above criterion then means that a UE is in sync if
one TTI is in sync and out of sync if two consecutive TTI are out of sync.
[iCEM]
For iCEM, 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 97/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RxDemodulation
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
[0..2147483647] Decimal
Customer
0
Object
BTSEquipmentl
Granularity
BTS
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:
Enhanced
common Layer1 UL
HS-DPCCH presence
enhancement
detection
OFF
OFF
OFF
ON
OFF
OFF
OFF
ON
OFF
OFF
OFF
ON
OFF
ON
ON
ON
OFF
ON
ON
ON
OFF
ON
ON
ON
RxDemodulation value
demodulation for high

speed UE
Page 98/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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).
Page 99/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 (1st S-CCPCH on

SF64,1, 2nd S-CCPCH on SF128,4, 3rd S-CCPCH on SF128,5). Then the common
channels take the equivalent of a SF32 in mono-S-CCPCH mode, a SF32 + a
SF128 in bi-S-CCPCH mode and a SF32 + 1SF64 in tri-S-CCPCH mode.
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 100/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following figures illustrate the different S-CCPCH Channel configurations described
above:
Configuration with 1 S-CCPCH
Figure 18: R99, HSDPA & HSUPA Common Channels codes allocation
7.2 HSDPA CODE ALLOCATION

In UA6.0, OVSF codes reservation for the HS-PDSCH channels can be managed
statically or dynamically according to the activation or deactivation of the features
DCTM (implemented from UA5.0) and Fair Sharing (implemented in UA6.0):
DCTM disabled
and
Fair Sharing disabled:
DCTM enabled
(Fair Sharing has to
be disabled)
- Reservation of the HS-PDSCH codes is static and the number of HSPDSCH codes is defined by the parameter numberOfHsPdschCodes.
- HSDPA codes configuration is sent during the cell setup from RNC to
NodeB through the Physical Shared Channel Reconfiguration message
and these codes can not be used or pre-empted for other services.
- This message contains the number of HS-PDSCH and the index of the
first one knowing that HS-PDSCH codes are reserved at the bottom of
the OVSF tree.
- Reservation of HS-PDSCH codes is dynamic and depends on the R99
traffic.
- Codes not used by R99 can be used for HS-PDSCH channels.
- Nevertheless, some codes needed to be kept free in order to anticipate
the admission of a R99 call.
- 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 101/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nb of free SF8 codes == 0
(Cond.2)
Page 102/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

As SFMonitoring can not be lower than SF16, the second condition (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-allocates some HSPDSCH codes in order to have numCodesForDchAfterReallocation free OVSF
codes.
Number of free OVSF codes after re-allocation:
#FreeOvsfCodesSfx numCodesForDchAfterReallocation
(Cond.5)
OR
Page 103/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

New Nb of free SF8 codes > 0 if
((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing *
SF8/SFMonitoring) 1))
(Cond.6)
The second condition (Cond.6) allows to guarantee at least one SF8 if needed.
The HS-PDSCH codes are re-allocated from the bottom to the top of the OVSF tree
and the maxNumberOfHsPdschCodes parameter guarantees a maximum number
of HS-PDSCH codes that can be re-allocated.
The following flowcharts summarize the DCTM algorithm:

R99 code allocation or release
RNC checks the number of free SFx
If #FreeOvsfCodesSfx
< threshCodesToTriggerStealing
No
Yes
If threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nf of free SF8 codes == 0
No
Yes
If #FreeOvsfCodesSfx
> threshCodesToTriggerReallocation
Yes
HS-PDSCH codes pre-emption is triggered
HS-PDSCH codes reallocation is triggered
Figure 19: HS-PDSCH codes pre-emption or re-allocation
HS-PDSCH codes pre-emption is triggered
If ((old Number of free SF8 codes == 0)

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

#FreeOvsfCodesSfx numCodesForDchAfterStealing
Figure 20: Number of HS-PDSCH codes pre-empted
Page 104/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

HS-PDSCH codes reallocation is triggered
If ((old Number of free SF8 codes == 0)

AND
((threshCodesToTriggerStealing * SF8/SFMonitoring) 1))
No
Yes
Number of HS-PDSCH codes re-allocated is such as:

New Nb of free SF8 codes > 0
Number of HS-PDSCH codes re-allocated is such as:

FreeOvsfCodesSfx numCodesForDchAfterReallocation
Figure 21: 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 reallocation 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 reduced by setting appropriate value for the minimum codes for HSPDSCH.
SF256
SF128
SF64
SF32
SF16
SF8
SF4
0
0
Common channels
(3 S-CCPCH) + 2 HS-SCCH
0
2
1
3
R99 codes
4
2
5
1
Free OVSF codes
6
3
7
8
4
9
2
10
5
11
Reallocation of a 5th HS-PDSCH

code is impossible because of the
R99 code even if the number of
free codes triggers the reallocation
12
6
13
3
14
HS-PDSCH (4 for ex)
7
15
Figure 22: Illustration of the HS-PDSCH re-allocation blocking

Page 105/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The isHsPdschDynamicManagementAllowed parameter allows the activation of
the Dynamic Code Tree Mgt feature:
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsPdschDynamicManagementAllowed
[false, true]
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
False
The following parameter is used in UA6.0 to activate the DCTM feature at FDDCell
level:
Parameter
RAN Path
Range & Unit
User
Class
Value
isCellHsPdschDynamicManagementActive
Object
RNC / RadioAccessService / DedicatedConf / HsdpaCellClass
[false, true]
Customer
Granularity
0
HsdpaCellClass
CellClass
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
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).
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
Page 106/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
numberOfHsPdschCodes
Object
HsdpaCellClass
[1..15]
Customer
Granularity
CellClass
0
Parameter
RAN Path
Range & Unit
User
Class
Value
numberOfHsScchCodes
Object
HsdpaCellClass
[1..4]
Customer
Granularity
CellClass
0
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
Parameter
RAN Path
Range & Unit
User
Class
Value
maxNumberOfHsPdschCodes Object
HsPdschDynamicManagement
RNC / RadioAccessService / DedicatedConf / HsdpaCellClass /
[1..15]
Customer
Granularity CellClass
3
15
Page 107/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
minNumberOfHsPdschCodes
Parameter
RAN Path
Object
[0..15]
Customer
3
Range & Unit

User
Class
Value
Engineering Recommendation: minNumberOfHsPdschCodes

This parameter allows to guarantee a minimum QoS for HSDPA and depends on the operator
strategy:
Operator strategy
Recommended value
Full flexibility of the feature
No impact on HSDPA Cat12 user
Minimum HDSPA throughput (at least throughput of 1 PS384)
Engineering Recommendation: minNumberOfHsPdschCodes and MAC-d PDU size

As explained in 5.3, with iCem, the minimum number of HS-PDSCH that can be managed by the
scheduler with a MAC-d PDU size of 656 bits is 2 if the feature Flexible Modulation is disabled.
If only one HS-PDSCH code is configured (due to minNumberOfHsPdschCodes = 1 and very high
R99 traffic), the NodeB sends Capacity Allocation with 0 credits. To avoid that,
minNumberOfHsPdschCodes can be set to a value higher or equal to 2 if the MAC-d PDU is 656
bits and if Flexible Modulation is disabled.
The number of OVSF codes of SFX in the tree is monitored at each OVSF code
allocation or deallocation. The X corresponds to the parameter called
spreadingFactorLevelForOvsfMonitoring
Parameter
RAN Path
Range &
Unit
User
Class
Value
spreadingFactorLevelForOvsfMonitoring Object
RNC / RadioAccessService / DedicatedConf / HsdpaCellClass / HsPdschDynamicManagement
[16, 32, 64, 128, 256]
Customer
3
Granularity
CellClass
16
Page 108/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range &
Unit
User
Class
Value
numCodesForDchAfterReallocation Object
[1..255]
Customer
3
Granularity
CellClass
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
numCodesForDchAfterStealing
Parameter
RAN Path
Object
[1..255]
Customer
3
2
Range & Unit

User
Class
Value
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
RAN Path
Range &
Unit
User
Class
Value
threshCodesToTriggerReallocation Object
[1..255]
Customer
3
Granularity
CellClass
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
RAN Path
Range & Unit
User
Class
Value
threshCodesToTriggerStealing Object
[1..255]
Customer
3
2
Page 109/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: numCodesForDchAfterX & threshCodesToTriggerX
Parameters numCodesForDchAfterX & threshCodesToTriggerX allow defining the number of
free OVSF codes 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 have to be set so that the
number of free codes is 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 is 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 (spreadingFactorLevelForOvsfMonitoring = SF16 and
numCodesForDchAfterReallocation = numCodesForDchAfterStealing =
threshCodesToTriggerReallocation = threshCodesToTriggerStealing = 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
minTimeBeforeReallocationOfHsPdsch
triggered,
the
RNC
starts
timer during which reallocation is
forbidden but stealing is allowed

Parameter
RAN Path
Range &
Unit
User
Class
Value
minTimeBeforeReallocationOfHsPdsch Object
RNC / RadioAccessService / DedicatedConf / HsdpaCellClass / HsPdschDynamicManagement
[0..3600] Decimal (s)
Customer
3
Granularity
CellClass
Page 110/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: minTimeBeforeReallocationOfHsPdsch
Increasing this parameter leads to decrease the number of PSCR for reallocation but HSDPA
throughput may be degraded if some free SF16 are not reallocated because of this timer. That is why
its value is 0.
Note: The number of free OVSF codes is re-evaluated for each R99 code release or
allocation
except
at
timer
expiry.
When
the
timer
minTimeBeforeReallocationOfHsPdsch is expired, RNC will check automatically
the threshold compared to the number of free OVSF codes without waiting for a R99
code release or reallocation.
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 111/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 HSPDSCH 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
False
SF8
SF256
Range

OCNSActivation
OCNSSpreadingFactor
Enum [False; True]

Enum [SF4 SF256]
RNC / NodeB / FDDCell / OCNSChannelsParameters

OCNSPower
100%
Integer [0100]
8 with 1 S-CCPCH
OCNSChannelizationCodeNumber
10 with 2 S-CCPCH
Integer [0511]
12 with 3 S-CCPCH
Note that in UA6.0, the feature OCNS for HSDPA has been introduced for US market. See 9.2 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).
Up to UA6.0, the HS-PDSCH codes configuration is managed by the RNC. Indeed, the
RNC sent the PSCR message to the NodeB to configure (at cell setup) or reconfigure
(according to the R99 traffic if DCTM is ON) the HS-PDSCH codes usuable by the
scheduler.
From 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
time of the R99 codes usage and then is able to compute which remaining codes can
be used for HS-PDSCH.
Page 112/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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, HSSCCH, E-AGCH)
Dedicated channels (DPCH, E-RGCH, E-HICH)
So, at each NBAP Radio Link Setup, Addition, Reconfiguration, Deletion, the Node B
rebuilds dynamically an image of the tree to determine which SF16 codes are not
blocked/allocated to DCH and can be used as HS-PDSCH by the MAC-hs scheduler.
Determination of the codes available for HS-PDSCH scheduling

When Fair Sharing is enabled, the NodeB has a view of the codes used or reserved by
R99 and then knows which SF16 codes are free.
Largest group of consecutive free SF16
Used or reserved for ccc, E-AGCH/E-RGCH/E-HICH, HS-SCCH
Used or reserved for R99 calls
Free SF16 codes
10
11
12
13
14
15
Figure 23: 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 HSPDSCH 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 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.
Page 113/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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

Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaCodeTreeManagementActivation
BTSEquipment
Customer
3
Object
BTSEquipmentl
Granularity
BTS
True
[UCU III]
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaCodeTreeManagementActivation
OneBTSEquipment
Customer
3
Object
OneBTSEquipmentl
Granularity
OneBTS
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 114/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 (little
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 PMaxCell 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 115/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PMaxCell
SHO margin
Ptraffic
RNC
PmaxHsdpa
PminHsdpa
HSUPA
OCNS (opt.)
CCCRNC
Figure 24: Power allocation at RNC level
When OCNS is required (for cell loading during acceptance or trial tests), its power is
defined as a percentage of the power not used by common channels such as:
POCNS = (PMaxCell - PCCC*activityFactorCcch) x OCNSpower
where OCNSpower = [0 100]%
It is possible (if Fair Sharing is disabled) to reserve a minimum power for HSDPA
noted PminHsdpa that is subtracted from the power of the DCH pool (see the Ptraffic
formula below). This power is defined through the minimumPowerForHsdpa
parameter such as:
PminHsdpa = PMaxCell 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
PminHsdpa < PMaxCell - POCNS - PCCC*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 116/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The RNC reserves also some power for the SHO margin that is used for the admission
of the users in soft handover and can not be used for users in first admission. This
power is a percentage of the traffic power:
PSHO = (1 - callAdmissionRatio).Ptraffic
With:
Ptraffic = PMaxCell - PCCC*activityFactorCcch - POCNS - Pedch - PminHsdpa
When Fair Sharing feature is enabled, there is no need to reserve anymore a

minimum power for HSDPA so the above calculation becomes:
Ptraffic = PMaxCell PCCC*ActivityFactorCcch - POCNS Pedch
Ptraffic is the power available for both DCH and HSDPA allocations (I/B and Streaming).
ActivityFactorCcch is defined by the parameter activityFactorCcch. For additional

information on this parameter, please refer to [R01], Volume 8.
Pedch is linked to the parameter eagchErgchEhichTotalPower (see [Vol. 4]).
This leads to definition of maximum power that the RNC can allocate to HSDPA
channels: PmaxHsdpa. This maximum power is computed at the RNC and given to NodeB
during the cell setup inside the physical shared reconfiguration channel NBAP
message.
The maximum power that the RNC can allocate to HSxPA channels is defined by:
PmaxHspa = PMaxCell maxHspaPowerOffset
Parameter
RAN Path
Range & Unit
User
Class
Value
maxHspaPowerOffset
Object
HsdpaCellClass
Decimal (dB)
[0 50] step 0.1
Customer
Granularity
FDDCell
3
0
From UA5.0, the maximum power is transmitted from the RNC to the NodeB in the
information
element
(IE)
HS-PDSCH_HSSCCH_EAGCH_E-RGCH_and_EHICH_Total_Power through the PHYSICAL SHARED CHANNEL RECONFIGURATION
MESSAGE during the cell setup. If it is not present, HSDPA can be allocated the whole
power. The number of HS-PDSCH and HS-SCCH codes reserved in the cell are also
Page 117/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

sent through this message, in the IE HS-PDSCH_FDD_code_information and HSSCCH_FDD_code_information respectively (see the following figure).
PHYSICAL SHARED CHANNEL

RECONFIGURATION MESSAGE
during Cell Setup
HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICH
Total Power
HS-PDSCH_FDD_code_information
HS-SCCH_FDD_code_information
Figure 25: Physical shared channel reconfiguration message
8.2.1.2 NODEB LEVEL

In a HSDPA cell, a new margin is introduced in order to anticipate power fluctuation
on DCH channel mainly due to power control and then avoid PA overload: DCH margin
(see the following figure). HSDPA channels can not use this margin. If the power for
DCH calls exceeds the DCH power margin then HSDPA will reduce its power to provide
DCH calls with power resource.
PMaxCell
NodeB
PRemain
DCH margin
E-DCH
DCH
OCNS (opt.)
PTotNonHsdpa
PTotNonHsdpaWithMargin
CCCNodeB
Figure 26: Power allocation at NodeB level
Page 118/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 PCPICH power:
PDCHmargin = dchPowerMargin.(PTotNonHsdpa PCPICH)
and
PTotNonHsdpa = PDCH + POCNS + PCCC*activityFactorCcch + PE-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.
The remaining power PRemain is the power usable by HSDPA:
PRemain = PMaxCell PTotNonHsdpaWithMargin
and
PTotNonHsdpaWithMargin = PTotNonHsdpa + PDCHmargin
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

Flexible power management feature consists in using for HSDPA all the remaining
power left by dedicated and common channels according to the RNC upper limit as:
PHSDPA = min(PRemain, PmaxHspa)
[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
(PmaxHsdpa).
Page 119/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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.
8.2.2.1 TRANSMITTED CARRIER POWER

The transmitted carrier power PTotCell (see the following figure) is the total cell power
consumed by all codes. From UA7.1, with feature PM75998 introduction, this
transmitted carrier power is measured and communicated within the NodeB every
10ms through a Power Management Message (PMM) ATM cell.
The HSDPA cell throughput is MAC-hs scheduler decisions dependent. Efficient block
size selection is linked to the accuracy of multiple pieces of information 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 feature PM75998 is to increase the frequency of the PA occupancy for
R99 and other common channels.
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 DCH 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.
HSDPA power calculation is located at 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.
Page 120/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.2.2.2 AVERAGED HSDPA POWER
The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes PTotHsdpa
(see the following figure) is computed and updated every TTI. An exponential
averaging is applied, whose coefficient is chosen to be coherent with the PMM
measurement. Every TTI, the following processing must then be done:
PTotHsdpa(TTI) = Rho.PTotHsdpa(TTI 1) + (1 Rho).PInstHsdpa(TTI)
where PInstHSDPA corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor. PTotHSDPA should be initialized with the
instantaneous value.
The value of the filtering coefficient for calculation of exponentially averaged 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.
PMaxCell
PMaxCell
Power
consumed by
all codes
PTotCell
NodeB
NodeB
HSDPA
Power
consumed by
non HSDPA
codes
PTotHsdpa
PTotCell
Figure 27: Transmitted carrier power (on the left) and averaged HSDPA power (on the
right)
Note that power consumed by non HSDPA codes includes the downlink HSUPA
channels.
Page 121/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.2.2.3 TOTAL NON HSDPA POWER
The total power not used by HSDPA (PTotNonHsdpa) is then computed over the last period
by subtracting the total HSDPA power from the total cell power. However, with the
activation of fast PMM measurements (PM75998) the reporting is no longer done
every 100ms, but instead with a 10ms period. This means that another filtering
process is used, for the PTotCell, using filtering coefficient Alpha:
PTotCell(n) = Alpha.PTotCell(n 1) + (1 Alpha).PTotCell(n)
The formula for Alpha is equivalent to 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:
PTotNonHsdpa = PTotCell - PTotHsdpa
This measurement is reported (see the following figure) from the NodeB to the RNC
through a COMMON MEASUREMENT message in the information element (IE)
Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, EAGCH, E-RGCH or E-HICH transmission defined as a percentage of the max cell
power. This measurement is used by the RNC CAC on DCH (only for HSxPA cells)
instead of Transmitted Carrier Power measurement (the latter continues to be
reported and is still used for non-HSDPA cells). The measurement period used for the
calculation is 10ms but the report periodicity (for these two measurements) toward
RNC is typically much higher and is configurable via OMC.
COMMON MEASUREMENT
Transmitted carrier power of all codes not used for HSPDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission
Figure 28: Common measurement
Restriction: Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-
AGCH, E-RGCH or E-HICH transmission

The NodeB does not remove the E-DCH contribution to the power measurement, leading to a slight
overestimation of the R99 contribution and to an impact DCH call admission control. This effect can be
attenuated by increasing DCH admission threshold on power for HSUPA cells (see [R05] for details)
Page 122/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.2.2.4 AVAILABLE HSDPA POWER
The available power for HSDPA for the next 10ms period can then be computed. It
corresponds to the difference between the maximum available power in the cell PMaxCell
and the total non HSDPA power with DCH margin PTotNonHsdpaWithMargin. It is bounded by
PmaxHspa:
PHSDPA = min(PMaxCell - PTotNonHsdpaWithMargin , PmaxHspa)
with PTotNonHsdpaWithMargin = (1+ DchPowerMargin/100) * (PTotNonHsdpa - PCPICH) + PCPICH
The
definition
of
DchPowerMargin,
depends
on
the
setting
of
flag
isDchPowerMarginAdaptive.
If set to FALSE, the calculation of PTotNonHsdpaWithMargin is based on the existing
parameter dchPowerMargin, under the object HsdpaConf. When TRUE, the
DchPowerMargin is calculated dynamically, according to the values defined by
parameters dchPowerMarginThresholdList and dchPowerMarginList.
Before starting scheduling users, the scheduler needs to know the total power it can
use for HSDPA according to R99 traffic usage. The total power usable by the
scheduler may be limited by the RNC (see PmaxHsdpa computation in section 8.2.1.1).
At nodeB level, with xCEM or eCEM, a minimum percentage of power for HSDPA can
be defined through the parameter hsdpaMinAmpUsage. A percentage of the cell
power can also be taken into account to compute the remaining power (power not
used by non HSDPA channels) through hsdpaAmpUsage. Then, the total power
usable for HSDPA is:
PHSDPA total = min(max(hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin;

hsdpaMinAmpUsage.Pmax); PmaxHsdpa)
where:
-
PTotNonHsdpaWithMargin is the power used by non HSDPA channels with DCH

margin (see section 8.2.1.2 for more details).
Pmax is the maximum power of the cell.
PmaxHsdpa is maximum power for HSDPA computed by RNC and sent to

NodeB through NBAP message (see section 8.2.1.1)
In case the feature 29808 Multi-Carrier PA power pooling is activated, the

formula is modified by adding a third limiting value, in order not to impact
the R99 traffic in the R99 cell in the case it demands more power than the
PA power pooling overbooking mechanism would have left. However, on
the
HSPA
cell,
the
concept
of
hsdpaAmpUsage
and
Page 123/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdpaMinAmpUsage still applies, as a percentage of Pmax (maximum
power of the HSPA cell), where Pmax, takes into account the overbooking
factor of the HSPA cell defined by the parameter paRatio. See [Vol. 7] for
the full description of the feature 29808.
PHSDPA total feature 29808 activated= min( max(hsdpaAmpUsage.Pmax HSDPAcell
PTotNonHsdpaWithMargin HSDPAcell; hsdpaMinAmpUsage.Pmax HSDPAcell); PmaxHsdpa
HSDPAcell; PA Power PTotNonHsdpaWithMargin R99cell and HSDPAcell )
Pmax
hsdpaAmpUsage.Pmax
HSDPA
PHSDPA
= hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin
Dch Margin
R99
PTotNonHsdpaWithMargin
CCC
Figure 29: hsdpaAmpUsage parameter
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaAmpUsage
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaMinAmpUsage

[0100] %
Customer
3
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
100

[0100] %
Customer
3
Page 124/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: hsdpaAmpUsage and dchPowerMargin
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.
This may not always be sufficient to prevent power spikes above maxTxPower, which may result in
PA alarms due to too high power usage. In such cases, one possible solution is decreasing
hsdpaAmpUsage parameter to 95%, that brings no noticeable impact on HSDPA throughput and it
is more efficient than increasing dchPowerMargin.
8.2.2.5 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 from
UA7.1, 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:
PTotNonHsdpaNew = PTotCell - PTotHsdpaFiltered
where PTotHsdpaFiltered represents the filtered HSDPA power transmitted during the
previous 10ms, calculated using the following expression:
PTotHsdpaFiltered(TTI) = Phi.PTotHsdpaTotFiltered(TTI 1) + (1 Phi).PInstHsdpa(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:
PTotNonHsdpa(n) = Gamma.PTotNonHsdpa(n 1) + (1 Gamma).PTotNonHsdpaNew(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).
Page 125/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following flowchart summarizes the measurement process:
Update transmitted HSDPA

power (PTotHsdpa ) every TTI
N
ATM cell received ?
PMM ATM cell reception every 10ms
Recovery in the ATM payload of the

Transmitted Carrier Power of the
corresponding cell PTotCell
PTotHsdpa
PTotCell
Computation of the Transmitted carrier

power on non HSDPA channels
PTotNonHsdpa = PTotCell - PTotHsdpa
PTotNonHsdpa
Assume a margin on the non HSDPA power.

PRem = PMaxCell PTotNonHsdpaWithMargin
Computation of the total HSDPA power available :
PHSDPA = min(PRem , PMaxHsdpa)
PHSDPA
Transmit PTotNonHsdpa every
100ms to CallP (common
measurement process)
Use PHSDPA as scheduler input

until next refresh
Figure 30: Power measurement process
8.2.2.6 PARAMETER SETTINGS WITH FAST PMM MEASUREMENTS

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. Filters that need this parameter
are:
- Filter used to smooth PTotCell (HSDPA Cell) received in PMM cells every
10ms;
- Filter used to smooth PTotCell (R99Cell) received in PMM cells every
10ms;
- Filter used to smooth PTotHsdpa (HSDPA Cell) power, evaluated every
TTI (2ms).
Page 126/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdpaWindowsObserveTime
Parameter
RAN Path
Range & Unit
BTSEquipment
Decimal (ms)
[10..100] step:10
Customer
3
User
Class
Value
Object
BTSEquipment
Granularity
BTS
Recommended: 40 [iCEM][xCEM][eCEM]
Internally adjusted for [UCU-III]
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.
isDchPowerMarginAdaptive
Parameter
RAN Path
Range & Unit
User
Class
Value

Customer
3
Object
HsdpaConf
Granularity
BTSCell
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
RAN Path
Range & Unit
User
Class
Value
dchPowerMarginThresholdList
Object
dB
[-35..0] step: 0.1 (for each array element)
Customer
Granularity
3
HsdpaConf
BTSCell
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
Else if
Else if
Page 127/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Else if
Else if
NonHsdpaPowerRelativeToPmax < dchPowerMarginThresholdList [4] then
Parameter
RAN Path
Range & Unit
User
Class
Value
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.
dchPowerMarginList
%
[0..100] step: 1 (for each array element)
Customer
3
Object
HsdpaConf
Granularity
BTSCell
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.
8.2.2.7 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
Page 128/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range & Unit
User
Class
Value
hsdschReqPwReportingPeriod
Object
NBAPMeasurement
RNC / RadioAccessService / DedicatedConf / MeasurementConfClass /
NBAPMeasurement
[103600000] step : 10ms
Customer
Granularity
MeasurementConfClass
3
10000 (10s)
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
RAN Path
Range & Unit
User
Class
Value
hsdschReqPwFilterCoeff
Object
NBAPMeasurement
NBAPMeasurement
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19]
Customer
Granularity
3
3
hsdschReqPwFilterCoeff is the filtering coefficient to be applied to the common
measurements HS-DSCH Required Power.
[xCEM] [eCEM]
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
Page 129/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

transmissions done during the measurement interval divided by the cumulated
number of payload bits contained in those HSD transmissions.
[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.
[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 values 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
RAN Path
Range & Unit
User
Class
Value
addGBRTransmitPower
OneBTSEquipment
Customer
3
Object
OneBTSEquipment
Granularity
OneBTSCell
False
Restriction: addGBRTransmitPower = 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 130/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 31: 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 PHSDPA is shared between HS-SCCH and HS-DSCH
channels (see the following figure).
HS-DSCH
PHsdpa
NodeB
HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 32: Power distribution between HS-DSCH and HS-SCCH channels
Page 131/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
PHS-SCCH < PHSDPA
If not, the scheduler will try to schedule another user.
The power allocated to HS-SCCH is explained in section dedicated to the feature HSSCCH power control.
8.2.3.1.1 HS-SCCH POWER CONTROL

The aim of this feature (PM27939) is to adjust, according to the radio condition, the
power allocated to HS-SCCH in order to:
save power for data or other UE,
have a good detection probability of HS-SCCH.
[xCEM] [eCEM] [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 or eCEM, the transmit power of HS-SCCH for each scheduled user is
calculated so that the SNR of the HS-SCCH at UE side is equal to hsscchSnr.
hsscchSnr
Parameter
RAN Path
Range & Unit
User
Class
Value

[-5.019.0] dB (step .1)
Customer
3
Object
HsdpaConf
Granularity
BTSCell
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 is equal to hssccSnr.
The computation of the HS-SCCH power is based on the most recent SNRMAP,dB from
CQI SNR mapping for each user, taking into account that HS-SCCH uses an SF128 :
PHS-SCCH = hsscchSnr + PP-CPICH + SNRMAP,dB 10.log10(128/16) + 5dB
Where:
-
PP-CPICH is the transmitted power of the P-CPICH (in dBm).
is the measurement power offset.
5dB is only applicable to xCEM, eCEM and UCU-III uses a fade-margin

LUT to determine this value
Page 132/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

-
the maximum value for HS-SCCH power is P-CPICH power + 2dB
the minimum value for HS-SCCH power is P-CPICH power - 8dB
The above limits are applicable to xCEM, eCEM and UCU-III.
[iCEM]
HS-SCCH power control is not a true power control mechanism but rather a power
mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is
derived from the reported CQI (noted CQIreported), not from CQI adapted by the NodeB
in any way, in order to adapt the transmission power to actual reported radio
conditions.
This is configured in a table that gives a power offset relative to P-CPICH for each CQI
such as:
PHS-SCCH = PP-CPICH + hsScchPcOffset(CQIreported)
where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each
CQI (see the following table).
CQIreported
hsScchPcOffset relative to PCPICH Power
hsScchPcOffset(1)
hsScchPcOffset(2)
.
30
hsScchPcOffset(30)
Table 7: HS-SCCH power offset table according to 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:
hsScchPcOffset(CQIReported)
CQ
I
CQIReported
PHS-SCCH = PP-CPICH + hsScchPcOffset(CQIReported)

Figure 33: HS-SCCH power control overview
Page 133/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 by 1dB, the
hsScchPcOffset table has to be shifted by 1 unit.
Here is a table summarizing hsScchPcOffset values according to measurementPowerOffset :
hsScchPcOffset
CQI
MPO = 5 dB
MPO = 6 dB
MPO = 7 dB
MPO = 8 dB
MPO = 9 dB
-3
-3
-3
-5
-3
-3
10
-5
-5
-3
-3
11
-5
-5
-5
-3
-3
12
-8
-5
-5
-5
-3
13
-8
-8
-5
-5
-5
14
-8
-8
-8
-5
-5
15
-8
-8
-8
-8
-5
16
-8
-8
-8
-8
-8
17
-8
-8
-8
-8
-8
18
-8
-8
-8
-8
-8
19
-8
-8
-8
-8
-8
20
-8
-8
-8
-8
-8
21
-8
-8
-8
-8
-8
22
-8
-8
-8
-8
-8
23
-8
-8
-8
-8
-8
24
-8
-8
-8
-8
-8
25
-8
-8
-8
-8
-8
26
-8
-8
-8
-8
-8
27
-8
-8
-8
-8
-8
28
-8
-8
-8
-8
-8
29
-8
-8
-8
-8
-8
30
-8
-8
-8
-8
-8
8.2.3.2 HS-DSCH POWER

The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH transport
channel:
PTemp = PHSDPA PHS-SCCH
Page 134/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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:
PHS-DSCH reference[dBm] = PP-CPICH[dBm] + [dB] + (CQIreported)[dB]
where
PP-CPICH is the power of the P-CPICH channel,
is the measurement power offset
is the reference power offset given by the reference tables of CQI [R02].
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.
[iCEM] On the other hand, NodeB computes a modified CQI (noted CQIprocessed or
AMC) to ensure a transmission with a given BLER target (cf section 6.1) assuming a
downlink power equals to:
PHS-DSCH[dBm] = PP-CPICH[dBm] + [dB] + (CQIprocessed)[dB]
[xCEM][eCEM][UCU-III] The xCEM/eCEM/UCU-III does not compute a modified

CQI, it rather maps the reported CQI to SNR values (SNRMAP,dB) and uses it in later
step of the algorithm to calculate PHS-DSCH
The power PHS-DSCH reference is defined by a power offset compared to the P-CPICH
power. This power offset corresponds to the measurementPowerOffset parameter.
The mobile is able to compute this reference power thanks to the P-CPICH power
measurement and to the measurementPowerOffset parameter. The
measurementPowerOffset parameter is sent from the RNC to the NodeB through
the HS-DSCH FDD INFORMATION message during the Radio Link
Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HSPDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration (see
the following figure). In case this parameter is not present in the setup message, the
configuration must then be rejected.
Page 135/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

HS-DSCH FDD
INFORMATION
DOWNLINK HS-PDSCH
INFORMATION
during Radio Link

Setup/Reconfiguration
during Radio Bearer

Setup/Reconfiguration
measurementPowerOffset
Figure 34: measurementPowerOffset transmission
In fact, this power can be seen as the HS-DSCH power required by the mobile
corresponding to its reported CQI.
[iCEM] 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 (CQIprocessed) and not the reported CQI (CQIreported). 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 HSPDSCH:
PHS-PDSCH[dBm] = PHS-DSCH[dBm] - 10.log(#codes)
[xCEM] [eCEM] [UCU III]

The SNR estimation of one HS-PDSCH depends on the available power for one HSPDSCH. Assuming that the power is uniformly distributed over all codes (NHS-PDSCH)
that are available for HSDPA, the available power for one HS-PDSCH (for user u from
the ranking list) is:
PavailableHS-PDSCH(u) = (PHSDPA PHS-SCCH(u)) / NHS-PDSCH
Where:
-
PHSDPA is the power that is available for HSDPA
PHS-SCCH(u) is the allocated power for HS-SCCH channel of user u
NHS-PDSCH is the number of HS-PDSCH codes computed as below.
Page 136/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

If more than one user is to be scheduled for the next TTI, then NHS-PDSCH is equal to
the total number of HS-PDSCH codes (Ntotal). Else, NHS-PDSCH is the minimum between
the total number of HS-PDSCH codes and the UE capability (Nue capability) in other
words, the maximum number of HS-PDSCH that a UE of a given category can
manage:
NHS-PDSCH = min(Ntotal; Nue capability)
For UCU III, Ntotal is the number of HS-PDSCH codes configured by the NodeB due to
Fair Sharing being activated by default.
For xCEM and eCEM

Ntotal is:
Ntotal = min(Nconfigured; SumNue capability)
Where:
-
Nconfigured is the number of HS-PDSCH codes configured (internal or

external PSCR message).
SumNue
capability
is
the
sum
of
the
UE
capability
of
the
numberOfHsScchCodes first users at the top of the ranking list of

the previous TTI.
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-SCCH
PHS-DSCH
PHS-SCCH
Dch Margin
R99
CCC
Figure 35: Available power per HS-PDSCH code used to compute the SNR of one HSPDSCH
Note that a user can be scheduled only if its available HS-PDSCH power PavailableHSis positive, otherwise the next user of the ranking list shall be selected.
PDSCH(u)
Available HSDPA power and available number of HS-PDSCH codes have to be updated
after a user u has been scheduled by reducing the total resources by the resources
allocated to user u:
PHSDPA New = PHSDPA PHS-DSCH(u) PHS-SCCH(u)
NHS-PDSCH New = NHS-PDSCH nHS-PDSCH(u)
Page 137/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
Amplifier Capability
R99 Power
HSDPA Power
Overhead Power
Figure 36: 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
Page 138/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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%.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaAmpUsage
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaMinAmpUsage
OneBTSEquipment
[0100] %
Customer
3
Object
OneBTSEquipment
Granularity
OneBTSCell
Object
OneBTSEquipment
Granularity
OneBTSCell
80
OneBTSEquipment
[0100] %
Customer
3
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 PHS-DSCH. The power effectively available at
NodeB level can be lower than this requested power. Then power adjustments are
needed. Other resource limitations such as codes limitation can also lead to
adjustment of the HS-DSCH power. The following section presents how the scheduler
manages the HS-DSCH power according to the available resources.
8.2.4.1 FIRST TRANSMISSION

The transport formats are always based on the CQI mapping tables. Two different
CQI correspond to different transport formats with the same power to reach the same
performance level, but could also correspond to two different powers with the same
transport format. A step of 1dB is considered to go from one CQI to the next one.
The transport format is determined according to the processed CQI, CQIprocessed. In
case of a lack of resources (codes or power), the applied CQI, CQIapplied, is then
modified according to the previous rule to take this into account. It is done in four
steps:
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 139/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE selected
Ptemp = PHSDPA PHS-SCCH
PHS-DSCH = PP-CPICH +
RP = round(10.log(Ptemp / PHS-DSCH))
CQI1 = CQIprocessed + RP
RP = 0
CQI1 = CQIprocessed
ncodes = f(CQI1)
UE not scheduled
RC = 0
CQI2 = CQI1
N
Select the highest CQI (CQI2) which number
of codes equals the remaining number of
codes
RC = CQI2 CQI1
Enough PDU available ?

TrBlk size manageable ?
Y
RO = 0
CQI3 = CQI2
Select the highest CQI (CQI3)

fulfilling both criteria
Code limitation
management
nCodes <
nCodesRemain ?
CQI1 > 0 ?
Other limitation
management
PHS-DSCH < Ptemp ?
Power limitation
management
PHS-DSCH = PP-CPICH + + (CQIprocessed)
CQIapplied = f(CQI3, MAC-d PDU size)

RCqi = CQIapplied CQI3
CQI optimization
management
RO = CQI3 CQI2
PHS-DSCH = PP-CPICH + + (CQI3) + RP + RC + RO + RCqi

PHS-DSCH = min(PTemp, PHS-DSCH)
PRemain = PTemp PHS-DSCH
[nCodes, nPDU] = f(CQIapplied)
UE scheduled
Figure 37: HS-DSCH power management for 1st transmission

Page 140/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.2.4.1.1 POWER LIMITATION
In case there doesnt remain enough power to transmit data corresponding to the
processed CQI to a selected UE, the transport format is modified in order to reduce its
power (Ptemp refers to the available power at NodeB level and PHS-DSCH to the needed
power by the UE). The excess power, corresponding to the total needed power minus
the maximum allowed power, is computed (RP). This value, expressed in dB, then
directly indicates the number of CQI levels one should decrease in order to remain at
the same level of performance. In case the resulting value is not valid CQI (0), the
UE is not scheduled; otherwise the new configuration is the one considered for the
next step. Note that in case the initial processed CQI is such that the associated
reference power adjustment () is non-zero (depending on UE category and
associated CQI mapping table given in [R02]), the CQI decrease (as described in the
previous figure) must not be considered for such user in that instance.
8.2.4.1.2 CODES LIMITATION

If the resulting configuration, corresponding to the derived CQI from the previous step
(CQI1), leads to a number of necessary HS-PDSCH codes higher than the remaining
ones, the CQI is also reduced in order to reach the exact number of remaining codes.
A power offset equal (in dB) to the difference between the input and output CQI is
then applied (1dB per CQI rule). Note that if this power reduction leads to a power
less than the minimum manageable by the H-BBU, it is then set to this minimum
power.
8.2.4.1.3 OTHER LIMITATIONS
Less available PDUs than required
In case there are less MAC-d PDU available in the buffer than what would have
allowed the scheduler to transmit relative to the derived CQI from previous steps
(CQI2), the configuration is then chosen to match to the lowest CQI (CQI3) that
enables to transmit this number of PDU (see the following figure). The power must, of
course, be decreased accordingly with the same rules as before.
Page 141/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Mac-hs transport block(CQI2)
Mac-d PDU
21
320
16
320
16
Padding
Mac-hs transport block(CQI3)

Mac-d PDU
21
320
16
320
16
Padding
Figure 38: MAC-hs transport block adaptation according to the number of MAC-d PDU to
transmit
Limited processing resource
The processing resource may be limited in the H-BBU pool configuration for instance.
All transport block sizes may not be handled. In case the one corresponding to the
last processed CQI is not manageable, the CQI is reduced to the highest one that fits
with the available resources. The power is also decreased accordingly.
8.2.4.1.4 CQI OPTIMIZATION ACCORDING TO MAC-D PDU SIZE

A last optimization is considered according to the resulting CQI from previous steps
(CQI3). Indeed, the MAC-d PDU size may not allow all CQI to be used or may lead to
an un-optimized solution. According to the MAC-d PDU size, the rules described below
must apply:
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 142/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 (PM33391) is to improve the power management in
NodeB such as 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 and eCEM is different and
this behaviour is already incorporated in their 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 37. 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 out. 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 follows:
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 143/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdpaFullPowerUsage
Parameter
RAN Path
Range & Unit
User
Class
Value

Customer
3
Object
HsdpaConf
Granularity
BTSCell
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_offsetdB = (CQI1st CQIret)*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.
Page 144/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Note that the CQI of the first transmission corresponds to the reported one
(including DeltaCqi adjustment) and not the applied one. Indeed, it is important to
compensate radio condition variations so reported CQI illustrates this. Once the offset
is computed, it is applied on top of the applied power of the first transmission as
scheduler rules should have adapted the transport format and related power in order
to keep constant the QoS.
To activate this feature, it is proposed to use the harqType parameter as well.
4 values are currently defined: MIR/PIR/CC/DR (see definition in [Vol. 2])
corresponding to 1/2/3/4.
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 four 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
RAN Path
Range & Unit
User
Class
Value
harqType
Object
HsdpaConf

[mirType, pirType, ccType, drType, MIRWithPowerAdaptation,
PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation]
Customer
Granularity
BTSCell
3
mirType
[xCEM] [eCEM]
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]).
In the event of sudden degradation of radio conditions, the algorithm will select a
lower PDU size, than the one provided as an input (the one from the initial
transmission).
In case of retransmissions and multiple active users it can happen that the number of
available codes does not allow retransmitting the transport block size, when previously
scheduled users already consumed too many codes. In this case the output of the
TFRC LUT for retransmissions will indicate that retransmission is not possible in this
particular TTI.
Page 145/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.2.4.3 MULTI-USERS PER TTI
Once a user has been chosen to be scheduled at the next TTI, the MAC-hs scheduler
checks that there is enough remaining power for the HS-SCCH. If it is not the case
then it tries to schedule a different user. After HS-SCCH power has been allocated, the
scheduler computes the remaining power that can be used for HS-DSCH (as described
in the previous section). Once a user has been scheduled, the scheduler will try to
serve another user in the same TTI with the power that remains (PRemain in the
following figure), provided there is still a free HS-SCCH code for this TTI.
PRemain
NodeB
HS-DSCH
HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 39: 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 HSSCCH. This mechanism is implemented in iCEM, xCEM and eCEM.
8.3 PARAMETERS SETTINGS AND RECOMMENDATIONS

The following section gives the properties of the parameters described previously.
Parameter
RAN Path
Range & Unit
User
Class
Value
dchPowerMargin
Integer (%)
[0 100]
Customer
3
20 [iCEM][xCEM][eCEM]
Object
HsdpaConf
Granularity
BTSCell
Page 146/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: dchPowerMargin versus cell load [iCEM][xCEM][eCEM]
The recommended value for dchPowerMargin is set to 20% for high cell load. At low load, 10%
could be used due to smaller power fluctuation.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsScchPcOffset
List[1..30]
[-28.0..28.0] dB
Customer
3
Object
HsdpaConf
Granularity
BTSCell
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
RAN Path
Range & Unit
User
Class
Value
minimumPowerForHsdpa
Object
HsdpaCellClass
RAN / RadioAccessService / DedicatedConf / HsdpaCellClass
Integer (dB)
[0.0 50.0]
Customer
Granularity
FDDCell
3
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 : PminHsdpa = PMaxCell minimumPowerForHsdpa = 45dBm 50dB = -5dBm =
0.3mW).
2) minimumPowerForHsdpa = unset so that no minimum power is reserved for HSDPA.
Page 147/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 not be 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:
minimumPowerForHsdpaMin = Pccc*activityFactorCcch + PSRB

See [R01] for details about power reservation for CCs and SRBs.
Parameter
RAN Path
Range & Unit
User
Class
Value
measurementPowerOffset
Object
Integer (0.5 dB)
[-12..26]
Customer
Granularity
3
HsdpaUserService
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 allocate to one UE. The value 7.5 dB allows to
allocate up to about 60% of PA power (PA = 45dBm and Cpich power = 35dBm) for the HS-DSCH
channel. A lower value favours the scheduling of 2 UE per TTI by limiting the power per HSDPA user.
For first deployments, the probability to have 2 UE scheduled in the same TTI will be low. Then with
this value, the HSDPA user throughput is not limited by power.
It is recommend to avoid setting the measurementPowerOffset to a too high value to avoid power
limitation but high enough to optimize the HSDPA capacity, the following rule should be taken into
account:
0.8.PA > Log2lin(pcpichPower + measurementPowerOffset)
This rule allows to respect the following BTS check:
PHS-DSCH = PP-CPICH + measurementPowerOffset <= MaxTxPower
If this condition is not satisfied then the HSDPA call is not setup
Page 148/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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) PHS-SCCH(CQI) PmaxHspa whatever the CQI
(2) Pccc + PHS-SCCH(CQI) Max Tx Power whatever the CQI
With, for the considered cell Fx, Max Tx Power (Fx) =Min { maxTxPower (Fx) ; Max Dl Power
Capability (Fx) } (cf. Vol.7, section related to the feature 29808 - Multi-Carrier PA Power Pooling).
(3) PHS-SCCH(CQI) Max Tx Power - 35 dB
(4) Max Tx Power 35dB PmaxHspa Max Tx Power
E-DCH rules (these rules apply to each E-DCH UE):

(5) Pccc + PHS-SCCH(CQI) + eAgchPower + eHichPower + eRgchPower Max Tx Power whatever the
CQI
(6) PE AGCH Max Tx Power - 35 dB
With PE AGCH being the power allocated to the considered E-AGCH channel.
(7) PE HICH signature Max Tx Power - 35 dB
With PE HICH signature being the power allocated to the E-HICH signature of the considered user.
(8) PE RGCH signature Max Tx Power - 35 dB
With PE RGCH signature being the power allocated to the E-RGCH signature of the considered user.
With following terms

(9) PHS-SCCH(CQI) = PP-CPICH + hsScchPcOffset(CQI)
(10) Pccc = PP-CPICH + max {Pccpch, (PP-sch+PS-sch)}
Note that above formulas are expressed in linear scale, except (3), (4), (6), (7), (8), (9) which are
expressed in logarithmic scale.
8.4 HS-DPCCH POWER MANAGEMENT

8.4.1 OVERVIEW
The Transmit power of HS-DPCCH is based on DPCCH power with a configured
power offset.
Three configurable power offsets are defined for: CQI, HARQ ACK and HARQ NACK..
Page 149/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
cqiPowerOffset
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[0..8]
Customer
Granularity
3-a2
[iCEM] [xCEM] [eCEM] 6
[UCU-III] 4
Object
[0..8]
Customer
Granularity
3-a2
[UCU-III] 4
HsdpaUserService
ackPowerOffset: This parameter indicates the power offset used in the UL

between the HS-DPCCH slots carrying HARQ ACK information and the
associated DPCCH.
ackPowerOffset
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
cqiPowerOffset: This parameter indicates the power offset used in the UL

between the HS-DPCCH slots carrying CQI information and the associated
DPCCH.
HsdpaUserService
nackPowerOffset: This parameter indicates the power offset used in the UL

between the HS-DPCCH slots carrying HARQ NACK information and the
associated DPCCH.
nackPowerOffset
Object
[0..8]
Customer
Granularity
3-a2
[UCU-III] 5
HsdpaUserService
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.
Page 150/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
8.4.2 ADAPTIVE HS-DPCCH POWER OFFSET

8.4.2.1 FEATURE DESCRIPTION
With feature PM82602/R7, a new mechanism is introduced to dynamically set the HSDPCCH power offset based on the active set size.
The aim of this feature is to save UL power resources when only one RL is configured
and then more uplink load remains available for E-DCH.
Two different HS-DPCCH power offsets are defined:
One power offset in case the active set size > 1 the already defined HSDPCCH power offsets shall be applied: cqiPowerOffset, ackPowerOffset,
nackPowerOffset.
One power offset in case the active set size = 1 new HS-DPCCH power
offsets shall be applied: cqiPowerOffsetOneLeg, ackPowerOffsetOneLeg,
nackPowerOffsetOneLeg.
Note: Some UEs are not able to decode the optional IE for UL HS-DPCCH deltaACK,
deltaNACK and CQI in ACTIVE SET UPDATE message, which results in these UEs
replying with an ACTIVE SET UPDATE FAILURE message. To overcome this, the RNC
will send a second ACTIVE SET UPDATE message without the optional IEs, meaning
that feature PM82602/R7 wont apply to these UEs, the active set update will be done
in two steps. This has no impact on call drop rate, although some degradation in the
success rate for the active set update procedure is expected.
A negative impact on throughput may be observed. When the Active Set size is equal
to 1, lowering the power offset of ACK/NACK/CQI will increase HSDPA HARQ BLER,
which may affect throughput. The magnitude of the decrease will depend on the
channel profile.
8.4.2.2 PARAMETERS SETTINGS AND RECOMMENDATIONS

8.4.2.2.1 FEATURE ACTIVATION
The feature 82602/R7 is activated by setting useAdaptiveHsDpcchPowerOffset
parameter to True.
8.4.2.2.2 PARAMETERS
useAdaptiveHsDpcchPowerOffset: This parameter enables or disables the

dependance of the HS-DPCCH power offset for CQI, HARQ ACK and HARQ
NACK on the number of radio legs in the DCH active set.
Page 151/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
useAdaptiveHsDpcchPowerOffset
Object
FDDCell

False, True
Customer
3-a2
True
Granularity
Cell
cqiPowerOffsetOneLeg: This parameter indicates the power offset used in

the UL between the HS-DPCCH slots carrying CQI information and the
associated DPCCH in case the adaptive feature is enabled and only one radio
leg is in the DCH active set.
cqiPowerOffsetOneLeg
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[0 .. 8], step 1
Customer
Granularity
3-a2
3
HsdpaUserService
RNC
ackPowerOffsetOneLeg: This parameter indicates the power offset used in

the UL between the HS-DPCCH slots carrying HARQ ACK information and the
ackPowerOffsetOneLeg
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[0 .. 8], step 1
Customer
Granularity
3-a2
3
HsdpaUserService
RNC
nackPowerOffsetOneLeg: This parameter indicates the power offset used in

the UL between the HS-DPCCH slots carrying HARQ NACK information and the
Parameter
RAN Path
Range & Unit
User
Class
Value
nackPowerOffsetOneLeg
Object
[0 .. 8], step 1
Customer
Granularity
3-a2
4
HsdpaUserService
RNC
Page 152/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
8.5 UA6 MANAGEMENT OF UL POWER PROFILES DEPENDING

ON WHETHER THE DL IS MAPPED ON DCH OR HSDPA
8.5.1 INTRODUCTION
When performing high data rate downlink transfer on HSDPA (e.g. HSDPA Category 8
UE with 656 bits MAC-d PDU performing DL FTP), the application-level UL ACKs must
reach the application server with short delay and at a regular pace, i.e. without
bursts. Indeed, if a burst of application-level UL ACKs (e.g. TCP UL ACKs) is received
by the server, the server may transmit on downlink a large amount of data at the
same time. If this data transmitted on downlink exceeds the core network bandwidth,
DL application-level packets are lost, which leads to application-level retransmissions.
Such application-level retransmissions may have a significant impact on DL
throughput and user experience.
Regarding the case of a call with HSDPA in the downlink and DCH in the uplink, it has
been observed that bursts of application-level UL ACKs occur when UL radio quality is
degraded (UL radio BLER higher than target BLER) even for a short period of time.
Indeed, if UL radio quality is degraded, UL RLC retransmissions occur. Since RNC
waits for retransmitted RLC-PDUs before transmitting data to the server (InSequence-Delivery mechanism), such UL RLC retransmissions result in a burst of
application-level UL ACKs sent to the server.
Regarding the case of a call with HSDPA in the downlink and E-DCH in the uplink, it
has also been observed that bursts of application-level UL ACKs occur when UL radio
QoS is degraded (average NHARQ number of HARQ retransmissions higher than
target NHARQ) even for a short period of time. Indeed, if UL radio quality is degraded,
UL HARQ retransmissions occur, leading to MAC-es PDUs arriving in disorder at RNC.
Since RNC performs reordering of MAC-es PDUs (as of 3GPP), such UL HARQ
retransmissions result in a burst of application-level UL ACKs sent to the server.
[iCEM] [xCEM] [eCEM] [UCU-III]

The Management of UL power profiles depending on whether the DL is mapped on
DCH or HSDPA 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 depending
on whether the DL is mapped on DCH or HSDPA 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 depending on whether
the DL is mapped on DCH or HSDPA may improve the transmission of UDP signaling
in the uplink, thus bringing some improvement on user experience.
Page 153/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 the DL is mapped on DCH
or HSDPA sub-feature of UA6 34246 Power Control Enhancements allows using a
specific set of parameters for UL SIR Target initial value, lower bound and upper
bound: initialSirTargetHsdpa, minSirTargetHsdpa and maxSirTargetHsdpa.
These parameters can be set per UL service.
initialSirTargetEdchTti2ms,
minSirTargetEdchTti2ms and maxSirTargetEdchTti2ms is applied to the calls
Another
set
of
parameters
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 40: Selection of OLPC UL SIR Target parameters by the RNC

Page 154/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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).
HSDPA UE Category is eligible for Management of UL power profiles subfeature.

Eligible HSDPA UE Categories can be set via
eligibleUeCategoryForSirTargetHsdpa parameter.
The method for setting eligible HSDPA UE Categories is described in 8.5.3.
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 the DL is
mapped on DCH or HSDPA sub-feature of UA6 34246, i.e. HSDPA UE Categories for
which an HSDPA-specific UL power profile is applied.
Parameter
eligibleUeCategoryForSirTargetHsdpa
RAN Path
RNC / RadioAccessService/ DedicatedConf / PowerConfClass
Object
PowerConfClass
Granularity
Range & Unit
PowerConfClass
Bit string (64 bits), N/A
User & Class
Customer, 3
Value
0000000000000000000000000000000000000000000011110011001111000000
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, 19 and 20. Hence, bits #6 to #9, #12, #13, #16, #17,
#18 and #19 should be set to 1.
Page 155/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
RNC / RadioAccessService/ DedicatedConf / PowerConfClass / UlUsPowerConf
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
UlUsPowerConf instance
initialSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K
PS_384K_IBxSRB_3_4K
Greater than initialSirTarget in order to

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

ensure high quality UL RAB when DL is
mapped on HSDPA. Refer to [R01]
Other instances
Refer to [R01]
PS_128K_IBxSRB_3_4K
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
RAN Path
Object
UlUsPowerConf
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
For all UlUsPowerConf instances: Refer to [R01]
Page 156/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
8.6 MULTI-CARRIER PA POWER POOLING

This feature applies in the case when 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.
8.6.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.
8.6.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 157/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
paRatio (F2)
HSDPA
GBR,
R99
Power
not used
Fixed
partitioning
R99
HSDPA
paRatio (F1)
paRatio (F2)
paRatio (F1)
PA Power Ratio
100%
GBR,
R99
R99
0%
Static PA Power sharing (feature
deactivated):
paRatio must follow the rule:
paRatio (F1) + paRatio (F2) 100%
Dynamic PA Power sharing :

paRatio can be set as follows:
paRatio (F1) + paRatio (F2) > 100%
Figure 41: 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.
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)
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
max Hspa
(F2) [dBm] = Max Tx Power (F2) [dBm] maxHspaPowerOffset (F2)
Page 158/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

At NodeB:
P HSDPA (F2) [W] = Min { PMaxCell (F2) PTotNonHsdpaWithMargin
Power - P Total Non HSDPA with Margin (F1+F2) }
(F2)
; P
max Hspa
(F2) [W] ; PA
with
PmaxCell(F2) : the maximal power the HSPA cell is configured for. It takes into
account the PA power pooling overbooking factor defined through
paRatio(F2).
[xCEM][eCEM] PMaxCell(F2) is possibly adjusted through the parameters
hsdpaAmpUsage and hsdpaMinAmpUsage.
PA Power = Max Power Amplification [W] - Tx Losses
P Total Non HSDPA with Margin (F1+F2) = 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
Total Non HSDPA with Margin (F1 + F2)
(1+dchPowerMargin/100)x (P Total Non HSDPA [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 [R01] for the description of these
features.
The DL CAC and DL iRM algorithms use the Ptraffic (maximum DL R99 traffic allowed).
When the feature 29808 is not activated, Ptraffic is defined as below:
Ptraffic [W] = Max Tx Power [W] PminHsdpa [W]

- P CCC. Activity Factor Ccch P E-DCH - P OCNS
When the feature 29808 is activated, the Ptraffic 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 Ptraffic must be scaled down accordingly, as
indicated in the formula below.
Page 159/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Ptraffic (F2)[W]= (PmaxCell (F2)[W]PminHsdpa (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
8.6.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

Rule 1:
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).
Rule 2:
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).
Illustration of the Rule 1:

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.
Page 160/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Illustration of the Rule 2:
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

BTSEquipment/LocalCellGroup r99ResourceId = x

BTSEquipment/LocalCellGroup r99ResourceId = y
8.6.2 PARAMETER SETTINGS AND RECOMMENDATIONS

8.6.2.1 RAN MODEL
OMC-R
RNC
NodeB
RadioAccessService
Number of instances
(indicated when > 1)
DedicatedConf
HsdpaCellClass 32
EdchCellClass 15
minimumPowerForHsdpa
maxHspaPowerOffset
paOverbookingRatio
eagchErgchEhichTotalPower
FDDCell
isPowerPoolingActivated
maxTxPower
activityFactorCcch
OMC-B
BTSEquipment
paPoolingActivation
BTSCell
paRatio
PaResource 12
maxPowerAmplification
HsdpaConf
dchPowerMargin
Page 161/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

8.6.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 (Ptraffic formula). For the detailed description of
the parameter (parameter frame with explicit recommended value, engineering rule),
please refer to section 8.3.
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 EDCH DL channels (PmaxHspa formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to section 8.2.1.
paOverbookingRatio: When 29808 is activated, factor used to scale down available

DL power for R99 and HSDPA GBR traffic (i.e. Ptraffic 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 8.6.1.2, Impact on
DL CAC and DL iRM (Ptraffic formula with 29808 activated) and 8.6.2.4.
Parameter
RAN Path
Range & Unit
User
Class
Value
paOverbookingRatio
Object
RadioAccessService / DedicatedConf / HsdpaCellClass
Integer [1 100], %
Customer
Granularity
3
HsdpaCellClass
FDDCell
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 (Ptraffic
formula). For the detailed description of the parameter (parameter frame with explicit
recommended value), please refer to [Vol. 4], 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
RAN Path
Range & Unit
User
Class
Value
isPowerPoolingActivated
Boolean {False, True}, N/A
Customer
3
F1: False
F2: True
Object
FDDCell
Granularity
FDDCell
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
Page 162/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

HSDPA GBR traffic (Ptraffic formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to [R01], Volume 8.
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 [R01], Volume 8,
section 3.2.1.
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.
8.6.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
RAN Path
Range & Unit
User
Class
Value
paPoolingActivation
BTSEquipment
Customer
0
Object
BTSEquipment
Granularity
BTS
True (if R99 layer + HSxPA layer)

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 [R01], Volume 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 (PmaxHspa formula). For the
detailed description of the parameter (parameter frame with explicit recommended
value), please refer to section 8.2.
Page 163/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

maxPowerAmplification: Maximum allowed PA output power. For the detailed
description of the parameter (parameter frame with explicit recommended value),
please refer to [R08], section 9.3.1.
8.6.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
Rationale:
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.
Parameter settings to apply a PA overbooking ratio below 130%:
paRatio (F1) + paRatio (F2) 130

maxTxPower (Fx) set according to paRatio (Fx), as explained above in
8.6.1.2.
paOverbookingRatio set according to Max Tx Power (F1), Max Tx Power

(F2) and PA Power, as explained above in 8.6.1.2.
Example:
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)

Recommendation:
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.
Page 164/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Possible optimization:
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:
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 165/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9 OTHER FEATURES
9.1 HSDPA PERFORMANCE ENHANCEMENT
[iCEM]
This feature consists in improving HSDPA performance thanks to several different subfeatures 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 is then 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
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.
Page 166/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9.2 HSDPA OCNS

[UCU-III]
9.2.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 relays 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 with a HSDPA OCNS channel.
Node B (particularly the HSDPA scheduler) is responsible for providing 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 as many virtual users 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).
2. Generate constant data to be transmitted every TTI (2ms) in the downlink by
the virtual HSDPA-OCNS users. The data pattern will be fixed for each
simulated user. It also depends upon the UE category, MAC-hs window size,
number of active Users in the cell, and other parameters, if the UE can be
scheduled in each TTI or not.
3. Simulate feedback from the terminal received in the uplink direction. The
feedback contains a CQI value, which can be fixed all the time the HSDPAOCNS is active or it can be randomly generated. If CQI factor specified via an
user interface in OMC is zero then the CQI should be randomly generated
following a uniform distribution, if CQI specified by an operator is not zero,
then a fixed CQI factor should be used all the time.
Page 167/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 of a
channel expires, NodeB de-activates 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 HSDPA-OCNS channel should be active for the time duration specified by the
user.
The Baseband Channel Elements in the Node B handle 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 HSDPCCH 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.2.2 HSDPA OCNS PARAMETERS

Parameter
cqiValue
RAN Path
RNC / NodeB / FDDCell / OcnsHsdpa
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Real Type: 0...30, in step of 1
User & Class
Customer
Value
User defined
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI = 0, then random values
between range 1 and 30 shall be used by the scheduler from a generating function.
If 1< CQI <30 then a constant CQI value should be generated all the time and
passed to the scheduler. A fixed CQI value means that the scheduler would try to
assign resources based on the CQI value enter by the user. If the CQI value demands
more resources than available for a given TTI, then the OCNS user will not be
scheduled for that TTI.
Page 168/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
meanCqi
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Real Type: 0...30, in step of 1
User & Class
customer
Value
User defined
Parameter
filtCoeff
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Integer Type: 110, in step of 1
User & Class
customer
Value
User defined
Filter coefficient (for an IIR filter) and Mean CQI, will be used in this random CQI
generator and hence are only applicable when CQI = 0.
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI=0, then random value between
range 1 and 30 shall be used by the scheduler according to the generating function
defined below. The randomly generated CQI values have a mean value of Mean
CQI.
The generated CQI values are for 2 second duration. The generated CQI are re-used
for the subsequent 2 second intervals.
Page 169/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 42: Algorithm for CQI Generating Function

Page 170/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
ackNackRatio
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Integer Type: 0100% in 1% step
User & Class
Customer
Value
User defined
NodeB scheduler shall generate ACK or NACK every TTI. ACK/NACK will be generated
according to ratio defined by the user in percentage. This parameter indicates the
percentage of number of positive and negative acknowledgements as input to NodeB
scheduler. This would be used to trigger re-transmission by the scheduler.
0% means all transport blocks are negatively acknowledged (NACK) by UE, 100%
means all transport blocks are positively acknowledged by UE, i.e. no retransmission is
required. If the ratio is lower, the throughput would also be lower.
Parameter
numMacdPdu
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Integer Type: 0100
User & Class
Customer
Value
User defined
in step of 1
NodeB shall provide the maximum number of MAC-d PDU per TTI. This parameter is
then mapped to a certain transport block size to be transmitted over the air. This
parameter is related to amount traffic coming into the NodeB from higher layer. If
zero, it means that there is no data to transmit.
Parameter
ueCapabilityInfo
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Integer Type: 112
User & Class
Customer
Value
User defined
NodeB shall use UE Capability Number in the scheduler as received in the OCNS
channel setup message. This parameter will be used by the scheduler to assign the
resources accordingly. For example if UE capability number is 12 then scheduler will
use QPSK modulation only for data transmission.
Page 171/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
channelActivityTime
RAN Path
Object
OcnsHsdpa
Granularity
User & Class
FDDCell
Integer Type: 0144, in step of 1, where 1
represents 10 minutes.
Customer
Value
User defined
Range & Unit
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
RAN Path
Object
OcnsHsdpa
Granularity
Range & Unit
FDDCell
Integer Type:
User & Class
Customer
Value
User defined
Cell ID is a user input for HSDPA OCNS operation and is selected by the operator
from available cells from a user interface at OMC-R WIPS.
Parameter
proprietaryHSDPAOCNSActivation
RAN Path
Object
FDDCell
Granularity
Range & Unit
FDDCell
False / True
User & Class
Customer, 3
Value
False
proprietaryHSDPAOCNSActivation is used to turned HSDPA OCNS on or off.
Page 172/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9.3 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 mechanism is
optional and can be activated at RNC level (applicable to HSxPA Services).
Restriction: Iu User traffic conformance UpLink limitation
This mechanism is applicable for both downlink and uplink. But as explained in vol.4 (please refer to
Traffic Conformance section), this mechanism is not recommended for the uplink case. However, a
better mechanism was introduced during the UA7.1.2 release and it is higly recommended to be used
instead of this one (please refer to the same vol.4 section for more details).
9.3.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.
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.8Mbps, cat6
3.6Mbps, cat8 7.2Mbps, etc).
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: 3GPP specification TS25.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.3.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
Page 173/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
Figure 43: 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 update 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.
Page 174/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9.3.3 PARAMETERS
The following three parameters are used to activate and configure the Iu User traffic
Conformance Feature:
sourceConformanceActivation
is used to activate/inhibit
conformance algorithm for downlink HSxPA user data.
the
Iu
Parameter
RAN Path
Range &
Unit
User
Class
Value
sourceConformanceActivation Object
DlSourceConformanceInformation
RNC / RadioAccessService / SourceConformanceConf / DlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : On, if the operator wants to limit UE throughput.
Parameter
RAN Path
Range &
Unit
User
Class
Value
sourceConformanceActivation Object
UlSourceConformanceInformation
RNC / RadioAccessService / SourceConformanceConf / UlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : Off. E-DCH MBR available, from UA7.1.2 onwards.
maximumTokenGenerationRate is the absolute maximum threshold and

is only used in the case the MaxBitRate of the Core RAB is greater than this
parameter.
Parameter
RAN Path
Range &
Unit
User
Class
Value
maximumTokenGenerationRate Object
RNC / RadioAccessService / SourceConformanceConf / DlSourceConformanceInformation
Integer (kBytes/s)
[1..32000]
Customer
Granularity RNC
3
2000
Note: The default value corresponds to ~16Mbits/s. For example, if the operator
wants that no user benefits of a throughput above category 12, it can be set to
1.8 Mbit/s = 225kbytes/s.
Parameter
RAN Path
Range &
Unit
User
Class
Value
maximumTokenGenerationRate Object
RNC / RadioAccessService / SourceConformanceConf / UlSourceConformanceInformation
Integer (kBytes/s)
[1..32000]
Customer
Granularity RNC
3
500
Page 175/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
RAN Path
Range &
Unit
User
Class
Value
Parameter
RAN Path
Range &
Unit
User
Class
Value
bucketBufferTime
Object
RNC / RadioAccessService / SourceConformanceConf /
Integer (ms)
[10..30000] step = 10
Customer
Granularity RNC
3
3750
bucketBufferTime
Object
RNC / RadioAccessService / SourceConformanceConf /
Integer (ms)
[10..30000] step = 10
Customer
Granularity RNC
3
2000
9.3.4 FEATURE BEHAVIOUR

The feature monitors each user throughput and deletes IU SDUs that exceeds
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 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 to be
increased for HSDPA subscribers according to the UE categories available, in order not
to limit user throughput from the Core Network side, but only through RNC source
conformance. For instance 1.4Mbit/s (case cat12) or 3.4 Mbit/s if cat6 is allowed).
R99 subscribers keep their MaxBitRate to 384Kbit/s 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 ASSIGNMENT REQUEST).
9.4 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)
Page 176/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

and Allocation/Retention Priority (ARP). The RNC maps these parameters into a single
OLS level, based on 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.4.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,
then that user will transmit only acording 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 that the Iub bandwidth is fully utilized.
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.
Page 177/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The algorighm is based on a virtual buffer in the Iub that evaluates the amount of
data that is buffered on the Iub transport network and from which a reference credit
is derived on a 10ms basis.
The OLS user budget is calculated based on the reference credit, in order to ensure
proportionality between the throughputs for the several OLS levels:
Bronze User credit = reference credit
Silver User credit = silverWeight / bronzeWeight * reference credit
Gold User credit = goldWeight / bronzeWeight * reference credit
This is managed at MAC-d level as a maximum credit to be used for the period for
each OLS user, and it is recomputed every 10ms.
9.4.2 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. A new optional component OlsDiff has been added
under the RncIn component. If 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
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.
goldWeight
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
RNC / RNCEquipment / INode / EM / RNCIn / OlsDiff
Integer [0..100]
Customer
Granularity
3
OlsDifferentiation
RNC
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.
Page 178/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

silverWeight
Object
Integer [0..100]
Customer
Granularity
3
Parameter
RAN Path
Range & Unit
User
Class
Value
OlsDifferentiation
RNC
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.
bronzeWeight
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
Integer [0..100]
Customer
Granularity
3
OlsDifferentiation
RNC
Default: 10
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 he tries to set enhancedQualityOfService =
enabled while PM97431 is active.
enhancedQualityOfService activates enhanced QoS features and is necessary to guarantee a

throughput defiend by GBR for streaming bearers and minBrForHsdpa for Interactive/Background
bearers over Iub.
enhancedQualityOfService activates enhanced QoS features. If set to

"disabled", the pre-UA6.0 congestion management (i.e. HSDPA as best effort
traffic) is available.
Parameter
RAN Path
Range & Unit
User
Class
Value
enhancedQualityOfService
Object
RNC / RNCEquipment / INode / EM / RNCIn
Enum {disabled, enabled}
Customer
Granularity
3
RncIn
RNC
Default: disabled
Note: At RNC transport level, when enhancedQualityOfService = disabled, the
minBR is not taken into consideration by the Congestion Management algorithm
when congestion occurs for QoS3 traffic (UA5-like behaviour). This parameter must be
set to enabled when the Congestion Management has to take into consideration the
GBR for streaming services and minBrForR99 for Interactive/Background bearers.
Page 179/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9.5 PROPRIETARY RLC SDU DISCARDING POLICY FOR RAB

ON HSDPA
The feature 104832/118154 Dual Cell HSDPA capacity increase implements, among
other enhancements described in section 5.5, an Alcatel-Lucent proprietary RLC SDU
discarding policy for RAB on HSDPA.
In practice, the effective DL HSDPA throughput is often changing, due to an
increasing number of users, traffic burst from other users, mobility to lowerthroughput cell, reconfiguration from Dual Cell to Single Cell,
In such case, the user will suffer more and more delay due to the large amount of
outstanding-data-to-be-transmitted in the RLC queue.
A workaround on this latency issue can be put in place thanks to a timer-based RLC
discarding mechanism: all RLC SDU that stay too long in the RLC SDU queue are
discarded. This would have a double benefit
1) TCP from the GGSN would receive NACK: TCP would throttle down
2) The RLC SDU queue would be cleaned up: new data from Core would reach the UE
faster.
These parameters enable/disable the support of Alcatel Lucent Proprietary RLC SDU
discarding mechanism. If isAluTimerBasedSduDiscard is set to true then RLC
SDUs
that
have
not
been
transmitted
to
lower
layers
upon
aluTimerBasedSduDiscard expiry are discarded.
This mechanism is applicable only to HSDPA RAB, hence it may be configured only for
the
two
following
RlcConfClass:
PS_HSDSCH_EDCH_STR_AM
and
PS_HSDSCH_EDCH_IB_AM.
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
isAluTimerBasedSduDiscard
Object
RNC / RadioAccessService / RlcConfClass
False, True
Customer
Granularity
3
RlcConfClass
RlcConfClass
False
aluTimerBasedSduDiscard
Object
DLRlcAckMode
RNC / RadioAccessService / RlcConfClass / DlRlcAckMode and
[2000-15000] ms with granularity of 500 ms
Customer
Granularity
RlcConfClass
3
2000
Page 180/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Rule: Proprietary timer-based RLC SDU discard mechanism
Due to non-obvious evidences of DL latency problem in the field, it is currently not recommended to
activate this mechanism. It is recommended to set isAluTimerBasedSduDiscard to FALSE.
Page 181/182

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Z END OF DOCUMENT Y
Page 182/182
UMT/IRC/APP/016664
V05.04
16/MAR/2012
HSUPA PRINCIPLES, SCHEDULING & RESOURCE

MANAGEMENT

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
CONTENTS
1
INTRODUCTION............................................................................................................6
1.1
OBJECT ....................................................................................................................... 6
1.2
RELATED DOCUMENTS ...............................................................................................10

2.1
HPUG VOLUMES .......................................................................................................... 10
2.2
REFERENCE DOCUMENTS ................................................................................................. 10
E-DCH ACTIVATION....................................................................................................11
POWER MANAGEMENT FOR E-DCH ............................................................................13

4.1
UL POWER MANAGEMENT ............................................................................................... 13
4.1.1
UL load management.......................................................................................... 13
4.1.1.1
UL load measurements .................................................................................... 14
4.1.1.1.1 RTWP measurement .................................................................................... 14
4.1.1.1.2 RSEPS ........................................................................................................ 15
4.1.1.2
Maximum UL load settings ............................................................................... 17
4.1.1.2.1 rtwpMaxCellLoadNonEdch setting.................................................................. 17
4.1.1.2.2 totalRotMax setting...................................................................................... 18
4.1.2
UL load estimation for E-DCH .............................................................................. 20
4.1.2.1
RTWP based method ....................................................................................... 20
4.1.2.2
SIR based method........................................................................................... 20
4.1.2.2.1 PM33612: UL load estimation in presence of urban noise for multiple cem ..... 20
4.1.2.2.2 PM81112: UL load estimation in presence of urban noise ............................ 23
4.1.3
UL load Alarms................................................................................................... 23
4.1.3.1
PM34134 High UL RSSI alarm........................................................................... 23
4.1.3.2
Overload detection: RTWP alarm ...................................................................... 24
4.1.4
UL load prediction for ICEM ................................................................................. 25
4.1.4.1.1 UL load fine prediction ................................................................................. 25
4.1.4.1.2 Consideration of self-interference in UL load prediction ................................... 26
4.2
DL POWER MANAGEMENT ............................................................................................... 28
4.2.1
At RNC .............................................................................................................. 28
4.2.2
At NodeB ........................................................................................................... 29
4.2.2.1
E-DCH DL channels power settings ................................................................... 30
4.2.2.2
E-DCH DL channels configuration ..................................................................... 32
5
E-DCH SCHEDULING CONFIGURATION......................................................................38

5.1
2MS TTI ..................................................................................................................... 38
5.2
UE CATEGORIES ........................................................................................................... 39
5.3
{E-TFCI; TBS} TABLE .................................................................................................. 40
5.4
{REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLE ...................................................... 42
5.5
FRAME PROTOCOL ON IUB .............................................................................................. 54
5.6
MISCELLANEOUS ........................................................................................................... 55
Page 1/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

5.6.1
5.6.2
5.6.3
6
PLNon-Max ........................................................................................................ 56
UL ILPC Algorithm Selection ................................................................................ 58
E-DCH Mac-d Flow Power Offset .......................................................................... 59
MAC-E SCHEDULER.....................................................................................................61
6.1
MAC-E SCHEDULER INPUTS ............................................................................................. 61
6.2
SCHEDULING GRANT ...................................................................................................... 64
6.3
OVERLOAD ALGORITHM .................................................................................................. 67
6.4
ACTIVITY MONITORING................................................................................................... 68
6.5
GENERATION OF AG & RG.............................................................................................. 71
6.6
PRIORITY INFO IN MAC-E SCHEDULER .................................................................................. 74
6.7
MAC-E NON SCHEDULED MODE.......................................................................................... 81
6.8
IUB CONGESTION HANDLING FOR E-DCH ............................................................................ 82
6.8.1
HSUPA PM33332 Iub bandwidth limitation and PM33367 congestion detection &
notification ...................................................................................................................... 82
6.8.1.1
Congestion reporting by RNC ........................................................................... 86
6.8.1.2
UL Iub congestion management in E-DCH scheduler .......................................... 86
6.8.2
PM75786 iBTS local E-DCH congestion control ...................................................... 88
6.8.3
PM82602/R4 Optimized Iub Congestion Control .................................................... 91
6.8.3.1
Feature decription ........................................................................................... 91
6.8.3.1.1 Feature overview......................................................................................... 91
6.8.3.1.2 Iub congestion detection.............................................................................. 91
6.8.3.2
Parameters settings and recommendations........................................................ 91
6.8.3.2.1 Feature activation........................................................................................ 91
6.8.3.2.2 Parameters ................................................................................................. 91
6.9
IU USER TRAFFIC CONFORMANCE ...................................................................................... 93
6.9.1
7
PM30742 MBR handling in the HSUPA scheduler ................................................... 93
POWER CONTROL FOR E-DCH ....................................................................................95

7.1
UL OUTER-LOOP POWER CONTROL FOR E-DCH ................................................................... 95

7.1.1
Principle of E-DCH UL OLPC................................................................................. 95
7.1.2
PM34249 EUL capacity optimized HARQ operation................................................. 99
7.1.2.1
Feature description.......................................................................................... 99
7.1.2.1.1 feature aim and principle ............................................................................. 99
7.1.2.1.2 Partial UL SIR Target computation .............................................................. 101
7.1.2.1.3 HFI handling ............................................................................................. 104
7.1.2.1.4 UL/DL Imbalance Detection mechanism .................................................... 105
7.1.2.2
Parameter settings and recommendations ....................................................... 106
7.1.2.2.1 Feature activation...................................................................................... 106
7.1.2.2.2 RAN model ............................................................................................... 107
7.1.2.2.3 Parameters defined for PS_EDCH and SRB_EDCH UL rB .......................... 109
7.1.2.2.4 Parameters defined per UL service .............................................................. 117
7.1.2.2.5 Other parameters ...................................................................................... 120
7.1.3
PM121085: UL power saving with E-DCH OLPC ....................................................121
7.1.3.1
Feature description........................................................................................ 121
7.1.3.1.1 Feature overview....................................................................................... 121
7.1.3.1.2 Fast descrease mechanism ......................................................................... 122
7.1.3.1.3 Behaviour in case of imbalance SIR condition............................................... 123
7.1.3.2
Parameters settings and recommendations...................................................... 124
Page 2/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.1.3.2.2 RAN MODEL.............................................................................................. 124
7.1.3.2.3 Parameters ............................................................................................... 124
7.1.4
82602/R1: Throughput increase in UE power limitation.........................................126
7.1.4.1
7.1.4.1.2 UE power limitation detection ..................................................................... 126
7.1.4.1.3 User throughput measurement ................................................................... 127
Number of target HARQ retransmissions assignement............................................. 128
7.1.4.1.4 ................................................................................................................... 128
7.1.4.2
Parameters settings and recommendations...................................................... 130
7.1.4.2.2 RAN model ............................................................................................... 130
7.1.4.2.3 Parameters ............................................................................................... 132
7.1.5
82602/R2: Enhanced load criterion for adjusting HARQ retransmissions .................134
7.1.5.1
7.1.5.1.2 Throughput measurement.......................................................................... 135
7.1.5.1.3 user activity detection................................................................................ 135
7.1.5.2
Parameters setting and recommendations ....................................................... 135
7.1.5.2.2 RAN model ............................................................................................... 135
7.1.5.2.3 Parameters ............................................................................................... 136
7.2
POWER CONTROL OF E-DCH DL CHANNELS ........................................................................138
7.2.1
PM33481 E-DCH DL control channels Power Control .............................................138
7.2.1.1
Introduction.................................................................................................. 138
7.2.1.2
7.2.1.3
Parameter settings and recommendations ....................................................... 141
7.2.1.3.1 RAN Model................................................................................................ 141
7.2.1.3.2 Parameters ............................................................................................... 141
7.2.1.3.3 Other recommendations............................................................................. 147
8
SRB ON HSPA DURING CALL ....................................................................................148

8.1
PM33581 SRB ON E-DCH............................................................................................148
8.2
RAB ASSIGNMENT........................................................................................................152
8.3
MOBILITY MANAGEMENT ................................................................................................153
8.4
RATE ADAPTATION .......................................................................................................154
8.5
DEFENSE ON FAILURE....................................................................................................154
8.6
PM125855 E-DCH CALL RETAINABILITY IMPROVEMENT........................................................156

8.6.1
8.6.2
8.6.3
R1: using 10 ms TTI for CS+EDCH combination ...................................................156

R2: using 10ms TTI and SRB on DCH in Poor Radio Condition ...............................157
R3: using 10ms TTI and SRB on DCH in high UL Radio Cell load............................159
PM34393 ADVANCED RECEIVER FOR HIGH UL DATA RATE.....................................161

9.1
INTRODUCTION ...........................................................................................................161
9.2
DESCRIPTION (GAIN, INTERACTIONS) ...............................................................................161
Page 3/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
TABLES
Table
Table
Table
Table
Table
Table
Table
Table
Table
1:
2:
3:
4:
5:
6:
7:
8:
9:
UE categories
Quantization for E-DPDCH (from 3GPP TS 25.213)
iCEM recommended {Reference E-TFCI; Reference Power Offset} table
xCEM recommended {Reference E-TFCI; Reference Power Offset} table
eCEM recommended {Reference E-TFCI; Reference Power Offset} table
UCU-III recommended {Reference E-TFCI; Reference Power Offset} table
Grant Index values
Scheduling Priority xCEM/eCEM
Example of E-DCH SPI settings
39
45
47
48
49
50
71
75
77
Page 4/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1: UL load contributors .................................................................................................... 13

2: Max UL load setting ..................................................................................................... 17
3: RTWP exceeding margin .............................................................................................. 24
4: Power allocation at RNC level ....................................................................................... 29
5: {E-TFCI; Transport Block Size} tables for 10ms TTI, as defined in 3GPP TS 25.321........... 41
6: {E-TFCI; Transport Block Size} tables for 2ms TTI, as defined in 3GPP TS 25.321............. 42
7: E-DPDCH Power vs. Transport Block Size....................................................................... 44
8: E-DCH parameters model at OMC-R .............................................................................. 51
9: Iub BW limitation mechanism ....................................................................................... 82
10: Uplink Iub Congestion detection: frame loss case ...................................................... 83
11: Uplink Iub DeCongestion: frame loss case................................................................. 85
12: Structure of the TNL Congestion Indication control frame.............................................. 86
13: Example of the GRF variation with the congestion status............................................... 87
14: Local congestion control mechanism ........................................................................... 89
15: E-DCH UL OLPC general principle ................................................................................ 96
16: Cell State computation ............................................................................................. 102
17: UL OLPC in case of SRB on E-DCH ............................................................................ 103
18: HFI Reception Scenario computation ......................................................................... 105
19: 34249 RAN model for E-DCH UL RBs ......................................................................... 108
20: 34249 RAN model for E-DCH UL services and misc. .................................................... 109
21: PM121085 "Fast Decrease" mechanism ..................................................................... 122
22: OMC-R model.......................................................................................................... 124
23: UE Power limitation detection ................................................................................... 127
24: Number of Target HARQ retransmissions assignement................................................ 129
25: OMC-R model (1/2) ................................................................................................. 130
26: OMC-R model (2/2) ................................................................................................. 131
27: OMC-R model.......................................................................................................... 136
Page 5/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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:
PM ID
Feature Title
Activation flag
Release
Global
Market
USA
Market
UA5.0
Yes
Yes
UA5.1
Yes
Yes
UA5.1
Yes
Yes
UA5.1
Yes
No
UA6.0
Yes
No
UA6.0
Yes
No
isEdchAllowed, edchActivation
29840
33481
34172
E-DCH Step1
(HSUPA)
E-DCH DL control
channels Power
Control
Remark: UA6
version of the
feature also
exists (see
below).
E-DPDCH
Retransmissions
for DPCCH SIR
Adaptation
edchResourceActivation
[iCEM] Feature not applicable.
[xCEM] [eCEM] Activated by
default.
isUlOuterPCActivated (for UL
services with E-DCH)
[iCEM]
34221
Self-interference
in MAC-e
Scheduler
rotOrthogonalityEstimation
[xCEM] [eCEM] [UCU-III]
Feature not applicable.
[xCEM] [eCEM]
33327
33332
MAC-e Scheduler
enhancements
edchSpiRelativeWeight
Iub bandwidth
limitation for EDCH
isEdchBandwidthLimitationAllo
wed
[iCEM]
Feature not applicable.
Page 6/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
33336
33367
Feature Title
HSUPA UE
categories 4 to 6
support
HSPA congestion
detection &
notification
Activation flag
isEdchTti2msAllowed
No activation flag.
Release
Global
Market
USA
Market
UA6.0
Yes
Yes
UA6.0
Yes
No
UA6.0
Yes
Yes
UA6.0
Yes
Yes
UA6.0
Yes
No
UA6.0
Yes
No
UA6.0
Yes
Yes
UA6.0
Yes
Yes
UA6.0
No
Yes
UA6.0
No
Yes

33481
E-DCH DL control
channels Power
Control
[xCEM] [eCEM]
eagchPowerControlModeXcem
[UCU-III]
No activation flag
33581
34134
34175
SRB on E-DCH
during call
High RSSI NodeB Alarm

UA06 HSPA
Capacity
Evolutions
RssiHighAlarmThreshold
isSrbOnEdchAllowedWhenTrbO
nEdch
No activation flag.
[iCEM] Adaptive NHARQ Target
mechanism disabled.
34249
34167
34438
34373
EUL Capacity
Optimized HARQ
operation

No activation flag.
Feature can be restricted to UA5.1
mode by applying specific
parameter settings.
Defence
mechanism for
UE not
supporting CM
with HSPA
Voice + HSUPA
Remark: UA6
34438 feature
only applies to
USA Market.
However, voice +
HSUPA multiservice is
available for both
Global Market
and USA Market.
OneBTS
Interoperability
Parity
isEdchCmFallbackAllowed
Page 7/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
75786
Feature Title
iBTS Local E-DCH
Congestion
Control
Activation flag
[iCEM][UCU-III]
Feature not applicable
Release
Global
Market
USA
Market
UA6.0
Yes
No
UA6.0
Yes
No
[xCEM] [eCEM]
edchCMActivation
edchLocalCongestionControlAc
tivation
81112
34441
34633
33612
34393
74681
80051
30742
UL load
estimation in
presence of
urban noise
[xCEM] [eCEM]
2ms TTI on
oneBTS
E-DCH Mac-e
throughput of
10Mbps
isEdchTti2msAllowed
UA7.1
No
Yes
[iCEM]
UA7.1
Yes
Yes
UA7.1.2
Yes
No
UA7.1.2
Yes
Yes
No activation flag.
UA7.1.3
Yes
No
No activation flag.
UA7.1.3
Yes
No
[xCEM] [eCEM] [UCUIII]
UA7.1.2
Yes
Yes
useOptimizedEdchHarqRetrans
AtCellEdge
UA08.1
Yes
Yes
useEnhancedUserActivityDetec
tion
UA08.1
Yes
Yes
locFrequencyReuseFactor
[iCEM]

No activation flag
UL load
estimation in
presence of
urban noise for
multiple CEM
[xCEM] [eCEM]
Advanced
Receiver for High
UL Data Rate
(with Doppler
measurements)
eCEM
Introduction
eCEM-u
Introduction
MBR handling in
the HSUPA
scheduler
edchLoadEstimationAlgorithm
[iCEM]
gRakeActivation
[iCEM]
isEdchMbrInfoToNodebAllowed
[iCEM]
82602/
R1
82602/
R2
Throughput
increase in UE
Power limitation
Enhanced load
criterion for
adjusting the
HARQ
retransmissions
Page 8/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Activation flag
Release
Global
Market
USA
Market
Optimized Iub
congestion
control
UL Power saving
with OLPC
useOptimizedEdchIubCongesti
onControl
UA08.1
No
Yes
isEdchFastSirTargetDecreaseAl
lowed
UA08.1
Yes
Yes
E-DCH Call
Retainability
Improvements
multiRabSmartEdchResourceU
sageActivation
UA08.1
Yes
Yes
PM ID
Feature Title
82602/
R4
121085
125855
PSRabBadRadioSmartEdchRes
ourceUsageActivation
maxColorForCac2ms
maxNumActiveUsersForCac2m
s
Page 9/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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

[R02] 3GPP TS 25.212
Multiplexing and channel coding (Release6)
[R03] UMT/SYS/DD/018827
E-DCH System Specification
[R04] 3GPP TS 25.321
MAC protocol specification
[R05] 3GPP TS 25.213
Spreading and modulation (FDD)
[R06] 3GPP TS 25.427

DCH data streams
UTRAN Iub/Iur interface user plane protocol for
Planning Guide
[R08] 3GPP TS 25.331
RRC protocol specification
[R09] 3GPP TS 34.108

Common test environments for User Equipment
(UE); Conformance testing
[R10] 3GPP TS 25.215
Physical layer - Measurements (FDD)
[R11] 3GPP TS 25.214
Engineering
Guidelines for 9313 Micro NodeB Configuration
CEM Capacity Eng'g Guide
[R14] UMT/BTS/DD/026060
EDCH 2ms TTI Support in OneBTS
[R15] UMT/BTS/DD/027736
Page 10/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
RAN Path
Range & Unit
User
Class
Value
isEdchAllowed
Parameter
RAN Path
Range & Unit
User
Class
Value
edchActivation
False, True
Customer
3
Object
RadioAccessService
Granularity
RNC
Object
FDDCell
Granularity
Cell
True

False, True
Customer
2
True
Parameter
RAN Path
Range & Unit
User
Class
Value
edchResourceActivation
Object
False, True
Customer
Granularity
0 or 3 (please see release delta
below)
BTSCell
Cell
True
Page 11/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UA7.1-UA08.1 Delta: edchResourceActivation parameter evolution
The parameter edchResourceActivation is used to activate the allocation of EDCH resource for a
BTSCell. EDCH can be allocated on an iCEM board or other boards like xCEM and eCEM. The parameter
hspaHardwareAllocation (refer to vol.3 for parameter description and [R13] for more details)
indicates whether EDCH resources shall be allocated on iCEM or not for a specific RfCarrier.
In order to be able to manage EDCH for a cell, an iCEM needs to be loaded with the eBBU load.
Changing the load (from dBBU to eBBU) requires an iCEM reset. As a result, it is not possible to
manage parameter edchResourceActivation without service impact.
In case of xCEM and eCEM, these boards are multimode, which means that they are able to manage at
the same time R99, HSDPA and EDCH services for the same cell, and it is possible to handle a state
change of EDCH from disabled to enabled (and vice-versa) without affecting the R99 service of the
cell. As a result it is possible to manage parameter edchResourceActivation online, without service
impact.
In order to manage the parameter as class 0 for iCEM and class 3 for x/eCEM, the parameter
edchResourceActivation is replaced by two parameters (with the same name) in different locations
from UA08.1 onwards:
BTSEquipment / BTSCell / Class0CemParamsBTSEquipment / BTSCell / Class3CemParams
The BTS selects the right set of parameters, depending on the value of parameter isICemAllowed, as
follows (refer to vol.3 for more details concerning this parameter):
If isICemAllowed = True, use BTSEquipment / BTSCell / Class0CemParams parameters

If isICemAllowed = False, use BTSEquipment / BTSCell / Class3CemParams parameters
[UCU-III] No activation flag under OneBTSEquipment object path.
Page 12/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 7.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 figure below represents the different contributors to the uplink load:
RTWPref+ totalRotMax
E-DCH Traffic
Max cell load
Cell load
RTWPref
R99 Traffic
+
Interference
Thermal Noise
Figure 1: UL load contributors
Page 13/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

4.1.1.1 UL LOAD MEASUREMENTS
The NodeB measures RTWP, E-DCH load and non E-DCH load.
Before UA06, the NodeB transmitted only the RTWP measurement for non E-DCH
traffic to the RNC.
Starting from UA06, a new measurement mechanism is introduced: RSEPS (Received
Scheduled E-DCH Power Share) that allows the NodeB to transmit the E-DCH power
ratio to RNC.
4.1.1.1.1 RTWP MEASUREMENT

Every 100ms period, the NodeB estimates the Received Total Wideband Power
(RTWP) based on measurements at the BTS.
The UL load is computed based on the Node B thermal noise that is the RTWP when
there is no UL traffic (RTWPref).
UL load = 1 RTWPref/ RTWP = 1 1/Noise Rise
RTWPref depends on several factors such as NodeB configuration, cable length, TMA
usage or not, temperature. Therefore, a self learning algorithm has been implemented
that keeps tracking this parameter every day based on the average of the minimum
samples of RTWP observation. This algorithm is activated by default.

Parameter
RAN Path
Range & Unit
User
Class
Value
isRtwpReferenceSelfLearning
BTSEquipment
False, True
Customer
3
Object
BTSEquipment
Granularity
BTS
True
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
rtwpReference
BTSEquipment / BTSCell
[-115.0..-50.0] step:0.1 dBm
Customer
3
Object
BTSCell
Granularity
Cell
-106.1
There is then a referenceRtwp parameter at FDDCell level that is only used
internally by the RNC in order to retrieve the RoT value, received from the NodeB (this
Page 14/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

value is not meaningful but to be coherent is better to set referenceRtwp is equal to
rtwpReference).
Without RSEPS activation, 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:
RTWPnon E-DCH = -106.1 + RoTnon-EDCH
Parameter
RAN Path
Range & Unit
User
Class
Value
referenceRtwp
Object
FDDCell

[-112.0..-70.0] step:0.1, dBm
Customer
3
-106.1
Granularity
Cell
The following parameter isRtwpAdjustmentForRnc, indicates if the BTS does a

correction of the RTWP before reporting it to RNC (only when RSEPS is not activated)
in the NBAP COMMON MEASUREMENT REPORT. If the parameter is set to TRUE, the
correction is:
RTWPnon E-DCH= -106.1 + (RTWPnon E-DCH_measured rtwpReferenceOrSelfLearned)
For example, when setting isRtwpReferenceSelfLearned to True, and measuring a
selfLearned rtwpReference equal to -105dBm and a RTWP of -100dBm, this means
that the BTS will report to the RNC: -106.1 + (-100 + 105) = -101.1 dBm.
Parameter
RAN Path
Range & Unit
User
Class
Value
isRtwpAdjustmentForRnc
BTSEquipment
False, True
Customer
3
Object
BTSEquipment
Granularity
BTS
True
4.1.1.1.2 RSEPS
A new NBAP common measurement is introduced from UA6 onwards 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.
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)
Page 15/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
E-DCH power ratio
As specified by 3GPP 25.215 ([R10]), RSEPS is defined as a quotient: sum of all

scheduled E-DPCCH and E-DPDCH power contributions divided by the received total
RTWP.
With this new measurement the RTWP NBAP measurements become 3GPP compliant
as there is no more need to adjust the RTWP at the BTS level to report the non EDCH power.
The RNC computes the non E-DCH load for iRM UL load as follows:
Without RSEPS activation:

Non_Edch_RTWP is sent by NodeB and Non_Edch_Ul_Load is retrieved in RNC:
Non_Edch_Ul_Load=1-10^(-Non_Edch_RoT /10)
Where:
Non_Edch_Rot=Non_Edch_RTWP +106.1
With 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 slightly increase 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.:
Page 16/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

isUlRadioLoadColourEnabled (under RNC / RadioAccessService /
DedicatedConf / NodeBConfClass)
and
isUplinkRadioLoadEnabled (under RNC / RadioAccessService)

have to be set to the value True (please refer to [R01] for details about
these parameters).
isNbapCommonMeasRsepsAllowed
Parameter
RAN Path
Range & Unit
User
Class
Value
RNC / NodeB
False,True
Customer
3
Object
NodeB
Granularity
BTS
True
[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
UserServiceProfile
in UA5.1.
4.1.1.2 MAXIMUM UL LOAD SETTINGS

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).
Two
parameters
are
used
to set the maximum allowed UL radio load:

rtwpMaxCellLoadNonEdch (under BTSCell object) and totalRotMax (under
FDDCell object).
Figure 2: Max UL load setting
4.1.1.2.1 RTWPMAXCELLLOADNONEDCH SETTING

The parameter rtwpMaxCellLoadNonEdch is 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.
Page 17/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
rtwpMaxCellLoadNonEdch
[0..100] (%)
Customer
3
Object
BTSCell
Granularity
Cell
70
Engineering Recommendation: [iCEM] [xCEM] [eCEM] rtwpMaxCellLoadNonEdch

setting
The settings of rtwpMaxCellLoadNonEdch should depend on the ratio between E-DCH and
UL R99 traffic.
When UL R99 is preponderant (which is the case for the moment in many networks), higher
thresholds are recommended in order not to block R99 traffic too soon.
As soon as E-DCH traffic starts to increase, the threshold can be reduced to handle more EDCH traffic. It is recommended to use 70, in order to be more coherent between the UL Load
CAC recommendation and the UL Radio Load iRM transition recommendation
(yellow2RedUlRadioLoadThreshold=65), knowing that UL cell color only reflects ULR99 traffic).
Engineering Recommendation: CAC on rtwpMaxCellLoadNonEdch

It is not recommended to activate the CAC on rtwpMaxCellLoadNonEdch when the UL load
estimation (refer to section 4.1.2) is based on RTWP as in this case the non E-DCH load
estimation is not very accurate and this could lead to R99 traffic being blocked too early.
4.1.1.2.2 TOTALROTMAX SETTING

The Parameter totalRotMax is 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 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.
Page 18/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: [iCEM] [xCEM] [eCEM] 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:
rtwpMaxCellLoadNonEdch 1
1
10
totalRotMax / 10
If above relationship is not fulfilled, then maximum allowed non E-DCH UL radio load for UL Radio
Load CAC at NodeB mechanism is considered by NodeB as equal to the maximum allowed total UL
radio load, i.e. 1-1/(10 totalRotMax / 10).
Rule: Maximum value for 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).
[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 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 19/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
Range & Unit
User
Class
Value
totalRotMax
Decimal [0.0 ... 20.0] step 0.1, dB
Customer
3
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
[UCU-III] 15
Object
FDDCell
Granularity
Cell
4.1.2 UL LOAD ESTIMATION FOR E-DCH

4.1.2.1 RTWP BASED METHOD
With the RTWP_based method, the radio load estimation is based on the following
equation:
LTotal = 1 RTWPRef / RTWP

4.1.2.2 SIR BASED METHOD
With the SIR based method, the radio load estimation is based on the sum of the
WCDMA users (R99 + HSxPA) load contributions.
The SIR bases method was first introduced in UA06 by the the feature PM81112:UL
load estimation in presence of urban noise, which is available only until UA7.1.
For UA7.1.2 onwards, PM81112 is converted to PM33612: UL load estimation in
presence of urban noise for multiple CEM
4.1.2.2.1 PM33612: UL LOAD ESTIMATION IN PRESENCE OF URBAN NOISE

FOR MULTIPLE CEM
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 cells suffering from a high level of RTWP despite
low/medium traffic (external interference). It can also be useful when the self tuned
RTWPref is not reliable.
A new measurement method is then put in place: SIR_based method, based on the
sum of the WCDMA users (R99 + HSxPA) load contribution.
Page 20/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The SIR_based method is recommended for urban noise situations. So, the new
approach will be based on several SIR values computed from different UL contributors
distributed over the xCEM or eCEM card.
The estimated total load is then calculated as follows:
LTotal = i (E c
I 0 )i xTPR i =
SIR
i
UL
allUE
This global formula can be represented in more detail by the portions of the several
contributors:
Lest, total = {Lest, s + Lest, ns + Cpeer-serving Lest, ps, C + Lest, DCH + Lest, HS - DPCCH} x (1 + Loc)
Lest,s is the estimated load portion for the serving users
Lest,ns is the estimated load portion for the non-serving users. The non-serving
users are the users for that the the cell does not act as the serving cell, the
serving cell being outside the NodeB.
Lest,ps,C is the estimated load portion for the peer-serving users of peer-serving
cell C. The peer-serving users are the users for that the cell does not act as
the serving cell but the serving cell is inside the NodeB.
Lest,DCH is the estimated DCH load for all users
Lest,HS-DPCCH is the estimated load portion for HS-DPCCH
Loc is the other-cell interference factor accounting for the load impact from
users which have no active radio link in the cell
The Loc value can be tuned using the following parameter:
Parameter
RAN Path
Range & Unit
User
Class
Value
locFrequencyReuseFactor
[0 100], integer
Customer
3
Object
BTSCell
Granularity
Cell
20 (see engineering recommendation below)
Page 21/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: [xCEM], [eCEM] locFrequencyReuseFactor setting
Based on some simulations results, it is recommended to set locFrequencyReuseFactor to the
value of 20 but it is possible to reduce it to 10 in case the operator wants to maximize the E-DCH
load available (to reach highest throughput with SIR_based estimation).
Another important parameter used by this feature is the activation flag. The
parameter edchLoadEstimationAlgorithm is used for this intention (meaning that
it will be responsible for choosing the UL load estimation algorithm, based either on
RTWP or SIR).
Parameter
RAN Path
Range & Unit
User
Class
Value
edchLoadEstimationAlgorithm
BTS Equipment / RfCarrier
{RTWP_BASED, SIR_BASED}, N/A
Customer
0
Object
RfCarrier
Granularity
BTS
SIR_BASED
This parameter will be activated per RfCarrier and it is a class0.
Important to know is also the restriction considering board mixity cases. So, for any
supported configuration iCEM and xCEM mixity this feature is not applicable.
Restriction: iCEM/xCEM mixity

Due to the absence of inter board messaging between iCEM on one hand and xCEM/eCEM on the other
hand, it will not be possible to apply this feature in a scenario of iCEM/xCEM(or eCEM) mixity.
However the feature 33612 makes possible the inter board messaging between xCEM
and eCEM in order to exchange the different load portions between boards, so the
feature is available when using multi baseband board NodeB configurations (multiple
xCEM and/or multiple eCEM per carrier).
Finally, in order to be able to activate this feature, the following rule must be
respected.
Compatibility Rule: edchLoadEstimationAlgorithm / hspaHardwareAllocation parameters
setting
If edchLoadEstimationAlgorithm is set to SIR_based, hspaHardwareAllocation under
RfCarrier must be set to xcemOnly (in UA7) or to iCemNever (from UA08 onwords), otherwise you
will have a MIB Build KO. For more details concerning this parameters please refer to volume 3 and
[R13].
[iCEM] : This feature is not available on iCEM.

[UCU-III] : UCU-III uses by default the same UL Load estimation mechanism (SIR
based, with Loc value set to 20%) as the one introduced by this feature (this feature
extends the UCU-III behaviour to the xCEM and eCEM; for this reason the feature is
Page 22/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

tagged as [GM] only). For UCU-III, the mechanism is tunable (activation flag and Loc
value) through OneBTS parameters not accessible to the customer.
4.1.2.2.2 PM81112: UL LOAD ESTIMATION IN PRESENCE OF URBAN NOISE

The feature PM81112 is the predecessor of the feature PM33612 and it is available
only until UA7.1. For UA7.1.2 onwards, PM81112 is converted to PM33612.
The main difference between these two feature is the fact that from UA7.1.2 onwards,
it is possible to activate UL Load Estimation when using multi baseband board NodeB
configurations. With PM33612, multiple xCEM and eCEM can now support the
frequency for which the feature is being activatedPM81112, doesnt not support this
achievement.
The PM81112 feature is only applicable to NodeB configurations (iBTS) where the
whole traffic of one carrier is handled by one and only one xCEM (absence of inter
modem board messaging during UA06, UA7.0 and UA7.1 prevented the usage of UL
load estimation based on SIR values for carriers having cells or UL contributors
distributed over multiple modem boards).
Restriction (up to UA7.1): One xCEM per carrier only

With feature 81112 only one xCEM can support the frequency for which the feature is activated.
Again, note that this restriction is lifted from UA7.1.2 onwards thanks to the feature 33612.
Parameter locFrequencyReuseFactor is used as the contribution load from the

other cells, and is also used as the activation flag, up to UA7.1
(edchLoadEstimationAlgorithm is available only from UA7.1.2). Therefore, up to
UA7.1 the feature activation is possible at BTSCell level (class3 parameter) and not at
RfCarrier level.
4.1.3 UL LOAD ALARMS

4.1.3.1 PM34134 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.
Page 23/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

This
feature
could
be
deactivated
by
setting
the
parameter
RssiHighAlarmThreshold to unset.
Parameter
RAN Path
Range & Unit
User
Class
Value
RssiHighAlarmThreshold
Object
BTSCell
Granularity
Cell
[-150dBm, -50dBm], 0.1dB
Customer
3
unset
In case of high UL RSSI alarm activation, the threshold could be set to 10dB above
Noise level (i.e. 90% Ul load). A normal noise level value measured in the TRM should
be in the range [-107.5dBm, -104.5dBm] so the alarm threshold could be set to
-94.5dBm to cover all the range.
[UCU-III]
Feature available for iBTS only
4.1.3.2 OVERLOAD DETECTION: RTWP ALARM

The non E-DCH RTWP is estimated and averaged over 100 ms period. It is based on
the RTWP estimation minus the E-DCH contribution:
RTWPnonE DCH = RTWP RTWPE DCH

When the RTWP exceeds the maximum allowed RTWP (totalRoTMax) by more than
the RTWP margin and during a period of at least rtwpTimeDetection, all E-DCH UE
are de-granted.
rtwpTimeDetection
RoT
ALARM
rtwpMargin
totalRoTMax
OK
Time
Figure 3: RTWP exceeding margin
Page 24/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
rtwpMargin
Parameter
RAN Path
Range & Unit
User
Class
Value
rtwpTimeDetection
4.1.4
[0.5..2.0] step:0.5 dB
Customer
3
Object
BTSCell
Granularity
Cell
Object
BTSCell
Granularity
Cell
2 dB
[100..400] step:100 ms
Customer
3
400 ms
UL LOAD PREDICTION FOR ICEM

[iCEM] This section is applicable only to iCEM.
4.1.4.1.1 UL LOAD FINE PREDICTION

[iCEM]
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 = RTWPRTWP_ref) will allow to tune the margin.
The scheduler will then allocate new E-TFCI based on the updated prediction function.
Two new parameters are introduced to activate and configure the UL load fine
prediction.
Page 25/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

rotPredictionCorrection is a flag used to activate/deactivate the UL load fine
prediction.
rotPredictionCorrection
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment / BTSCell / EdchConf

Off, On
Customer
3
Object
EdchConf
Granularity
Cell
ON
rotMarginPrediction is the adjustment of the prediction margin of the RoT (Rise
over Thermal). This parameter is only used if parameter: rotPredictionCorrection is set
to ON. This parameter is specific iCEM.
rotMarginPrediction
Parameter
RAN Path
Range & Unit
User
Class
Value

[0..10]
Customer
3
Object
EdchConf
Granularity
Cell
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.
4.1.4.1.2 CONSIDERATION OF SELF-INTERFERENCE IN UL LOAD

PREDICTION
[iCEM]
INTRODUCTION
As explained further in section 6.1, the iCEM MAC-e scheduler located in the NodeB
needs as an input the uplink load available for the E-DCH traffic of the considered cell.
Regarding the iCEM, in order to estimate, at each TTI, the UL load available for EDCH, the following actions are performed within the NodeB:
Derivation, every 24 hours, of the thermal noise level (RTWPref) at the BTS, via
thermal noise level self-learning algorithm (c.f. section 4.1.1), based on
measurements at the BTS
Derivation, every 100ms, of the Received Total Wide-band Power (RTWP), based
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 to as UL
Page 26/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

load prediction. The accuracy of this estimation has an important impact on the
performance of the MAC-e scheduler.
In section 4.1.4.1.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.
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 4.1.3.2.
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.
Page 27/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
The improvement on the accuracy of the estimation of current total UL load

brought by UA5.1/iCEM 34221 is only used by the MAC-e scheduler in the NodeB.
The quantity RTWPnon E-DCH sent every 100ms from the NodeB to the RNC via
NBAP (c.f. section 4.1.1) does not benefit from this improvement.
Restriction: RTWPnon
feature
E-DCH
sent to the RNC does not benefit from UA5.1/iCEM 34221
The improvement on the accuracy of the estimation of current total UL load brought by 34221 is
only used by the MAC-e scheduler in the NodeB. The quantity RTWPnon E-DCH sent every 100ms from
the NodeB to the RNC via NBAP does not benefit from this improvement.
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.
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
RAN Path
Range & Unit
User
Class
Value
rotOrthogonalityEstimation
Enum {Off, On}, N/A
Customer
3
Object
EdchConf
Granularity
Cell
On
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).
Page 28/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

In the following figure showing power allocation at RNC level, the power reserved for
E-DCH DL channels is represented in light blue (E-DCH).
SHO margin
PMaxCell
RNC
Ptraffic
PminHsdpa
Max Power for HS-DSCH

& HS-SCCH, E-AGCH,
E-HICH and E-RGCH
to be transmitted
to the NodeB
E-DCH
OCNS (opt.)
CCCRNC
Figure 4: 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
RAN Path
Range & Unit
User
Class
Value
eagchErgchEhichTotalPower
Object
EdchCellClass
RNC / RadioAccessService / DedicatedConf / EdchCellClass
Decimal [0.0 50.0] step:0.1, dBm
Customer
Granularity
EdchCellClass
3
[UCU-III] 0
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. HSSCCH 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.
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 ERGCH/E-HICH sub-frame length of 2ms) for xCEM, eCEM and UCU-III. Regarding nonserving NodeB, E-DCH DL channels power control is only possible for xCEM, eCEM and
UCU-III, and only under certain conditions for xCEM and eCEM. Please refer to section
7.2 for more information on E-DCH DL channels power control in xCEM, eCEM and
UCU-III.
Page 29/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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, eCEM and UCU-III.
[iCEM]
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.
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 nonserving
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.
eagchPower: Power offset for one E-AGCH channel, relative to the CPICH power.
eagchPower
Parameter
RAN Path
Range & Unit
User
Class
Value

Signed [-35.0 15.0] step:0.1, dB
Customer
3
Object
EdchConf
Granularity
Cell
-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
RAN Path
Range & Unit
User
Class
Value
ehichPowerSignature
Signed [-35.0 15.0] step:0.1, dB
Customer
3
Object
EdchConf
Granularity
Cell
-8.0
Remark: On iCEM, up to 15 E-HICH signatures may be used on the same E-HICH/ERGCH channel (instead of 40 as of 3GPP) since the maximum number of E-DCH radio
links that can handle one E-BBU is 15.
Page 30/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

ergchPowerSignature: Power offset for one E-RGCH signature, relative to the
CPICH power.
Parameter
RAN Path
Range & Unit
User
Class
Value
ergchPowerSignature
Object
EdchConf

Signed [-35.0 15.0] step:0.1, dB
Customer
3
-8 dB
Granularity
Cell
Engineering Recommendation: eagchPower, ehichPowerSignature and

ergchPowerSignature setting
These three parameters are only used by the iCEM. The other types of boards use a different
mechanism (see feature 33481). However in all cases it is recommended to set these parameters
to their recommended value, so that the NodeB internal power checks successfully passes.
Even if UA6 E-DCH Macro Diversity (32076) feature has not been activated yet (i.e E-RGCH not
used yet by the iCEM), 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, it 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 (i.e iCEM makes use of the E-RGCH), it
is recommended to set ergchPowerSignature to -8dB to favor a proper detection of the E-RGCH
commands by the UEs.
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), to 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,
setting
ehichPowerControlMode,
ergchPowerControlMode
eagchPowerControlMode, ehichPowerControlMode, ergchPowerControlMode under

EdchConf (iCEM-specific parameters) should not be set to a value different from the default one,
i.e. Fixed.
Page 31/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

On xCEM, eCEM 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 7.2 for a detailed description of the mechanism and
parameters involved in this feature.
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, eCEM and UCUIII. Note that, for iCEM and xCEM (and from UA7.1.3 eCEM), 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.
maxNrOfEagch
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
EdchCellClass
Integer [1 8], N/A
Customer
Granularity
EdchCellClass
0
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] [eCEM] [UCU-III] On xCEM and eCEM, 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, eCEM 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,
eCEM and UCU-III, if low E-DCH traffic is expected, it is recommended to set
maxNrOfEagch = 1.
Page 32/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Restriction: [iCEM] [xCEM] [eCEM] maxNrOfEagch
For iCEM, xCEM and eCEM, 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 NodeB 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
NodeBs using iCEM, xCEM and eCEM, setting maxNrOfEagch to a value higher than 3 causes to lose
E-DCH service on all the cells for which this setting applies.
Rule: [iCEM] [xCEM] [eCEM] maxNrOfEagch

For iCEM, xCEM and eCEM, 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.
maxNrOfErgchEhich
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
EdchCellClass
Integer [1 8], N/A
Customer
Granularity
EdchCellClass
0
[iCEM] 1
[xCEM] 4
[eCEM] 4
[UCU-III] 4
Please check the engineering recommendation below concerning
maxNrOfErgchEhich as a function of the E-DCH traffic.
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][eCEM][UCU-III]
With xCEM and eCEM, up to 4 E-RGCH/E-HICH channels can be configured per
cell. Moreover for each pool of 40 signatures, 4 (hard-coded) are used for
common relative grant. Knowing that the board allocates one pair of {E-HICH;
Dedicated E-RGCH} signatures per E-DCH radio link, it means one E-RGCH/EHICH
channel
can
support
up
to
18
E-DCH
radio
links.
With UCU-III, up to 6 E-RGCH/E-HICH channels can be configured per cell.
Moreover, the number of signatures reserved for common relative grant is set via
edchNumCommonRgPerCode. Assuming it is set to 1 (see Vol.6, section
Page 33/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

3.3.3), it means one E-RGCH/E-HICH channel can support up to 19 E-DCH radio
links.
In order to maximize the possible number of simultaneous E-DCH users per cell,
maxNrOfErgchEhich can be set up to 4 for the [xCEM][eCEM] and 6 for the
[UCU-III].
However such OVSF code consumption for E-RGCH/E-HICH may reduce the
number of OVSF codes available for HS-DSCH channels (hence may impact the
HSDPA+ performances), but the impact is quite limited as shown in the following
table. This table lists the main options regarding the cell DL channels
configuration (refer also to [Vol.3], section 7 OVSF Codes, for detailed pictures of
DL code tree). It shows how the number of E-RGCH/E-HICH channels impacts (or
not) the DL OVSF codes available for HS-DSCH.
DL codes configuration (examples)
Mono S-CCPCH,
numberOfHsScchCodes = 2,
maxNrOfEagch = 1,
Fair sharing (no DL codes reserved for R99),
no OCNS
Bi S-CCPCH,
maxNrOfEagch = 1,
no OCNS
Tri S-CCPCH,
maxNrOfEagch = 1,
no OCNS
Chosen
maxNrOfErgchEhich
Resulting
number of DL
OVSF codes
available for
HS-DSCH
15
[xCEM][eCEM] (2..4)
14
[UCU-III] (2..6)
[xCEM][eCEM] (1..4)
14
[UCU-III] (1..6)
[xCEM][eCEM] (1..4)
14
[UCU-III] (1..6)
In these examples, the number of E-RGCH/E-HICH channels is critical only in

Mono S-CCPCH case, where moving from 1 E-RGCH/E-HICH channel to more than
1 reduces the number of DL HS-DSCH codes. In Bi S-CCPCH or Tri S-CCPCH, the
number of DL HS-DSCH codes is yet only 14, regardless of the number E-RGCH/EHICH channels.
Page 34/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UA6/UA7 UA08 Delta: recommended value for maxNrOfErgchEhich
In the previous releases, the default recommended value for maxNrOfErgchEhich was 1, in order to
save DL code resources, hence optimize the HSDPA+ performances. Indeed with the introduction of
the HSDPA+ features (see [Vol.3]), a large amount of DL codes are needed to reach high downlink
rates supported by the HSDPA+ UEs, e.g Cat14 UE, Cat24 UE.
Now, with the dramatic increase of the EDCH connections (smartphones), the default recommended
value becomes 4; the minimum value 1 shall rather be an exotic value used to preserve 15 HSDSCH codes for max DL throughput DL demo. Note that most of the networks are using bi-sccpch,
so even with only 1 E-RGCH/E-HICH code, it is impossible to get 15 codes for HS-DSCH.
Refer to the Engineering Recommendation: [iCEM] [xCEM] [UCU-III] [eCEM]

maxNrOfErgchEhich configuration method below.

Remark on maximum number of E-DCH users per cell:
As explained above, one E-RGCH/E-HICH channel can support up to 18 E-DCH radio
links for the [xCEM][eCEM] and 19 for the [UCU-III].
A maximum of 128 E-DCH radio links (or 116 with G-RAKE feature activated, see
section 9) can be supported per cell from a hardware point of view (up to 128 E-DCH
radio links (or 116) are supported per xCEM, eCEM and UCU-III 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 72 (4 x 18)
E-DCH radio links per cell for xCEM and eCEM; setting maxNrOfErgchEhich = 6
actually enables up to 114 (6 x 19) E-DCH radio links per cell for UCU-III.
Note that overall NodeB configuration must also be taken into account to determine
the effective E-DCH capacity. Please refer to the description of the feature
34441.1/34441.2 EDCH CAC in [Vol.5].
Page 35/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: [iCEM] [xCEM] [eCEM] [UCU-III] maxNrOfErgchEhich
1- iCEM maxNrOfErgchEhich recommendation
On iCEM, since the maximum number of E-DCH radio links that can handle one E-BBU is 15, one ERGCH/E-HICH channel per cell is sufficient. Consequently, for iCEM, in order to save DL code
resource, it is recommended to set maxNrOfErgchEhich = 1.
2- xCEM, eCEM, UCU-III maxNrOfErgchEhich recommendation

Up to 4 for the [xCEM][eCEM] and 6 for the [UCU-III] E-RGCH/E-HICH channels (i.e. OVSF codes)
can be configured per cell. This value maximizes the possible number of simultaneous E-DCH users
per cell.
By default, it is recommended to set maxNrOfErgchEhich = 4.
maxNrOfErgchEhich may be optimized based on the monitored number of E-DCH radio links.
The table below shows the recommended maxNrOfErgchEhich as a function of the E-DCH traffic.
Maximum number of simultaneous EDCH Radio Link established on the cell
Recommended maxNrOfErgchEhich
[xCEM][eCEM]
[UCU-III]
Unknown
Unknown
4 (default value)
[0..18]
[0..19]
[19..36]
[20..38]
[37..54]
[39..57]
> 55
[58..76]
[77..95]
>95
3- Configuration method:
If it is chosen to set different maxNrOfErgchEhich depending on the type of boards or depending
on the E-DCH traffic:
Use specific EdchCellClass instances (e.g one for iCEM and one for xCEM / eCEM, one for
low E-DCH traffic area and one for dense E-DCH traffic area).
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, or the E-DCH traffic
area it belongs to.
Page 36/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Restriction: [iCEM] [xCEM] [eCEM] maxNrOfErgchEhich
From UA6, for iCEM, up to 3 E-RGCH/E-HICH channels can be configured per cell.
From UA6, for xCEM (and from UA7.1.3 eCEM), up to 4 E-RGCH/E-HICH channels can be
configured per cell.
However, maxNrOfErgchEhich parameter can be set to a value up to 6.
In NodeBs using iCEM, xCEM and eCEM, 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,
setting maxNrOfErgchEhich to a value higher than 4 for xCEM and eCEM causes to lose 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 losing 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] [eCEM] maxNrOfErgchEhich

In NodeBs using iCEM, xCEM and eCEM, please follow the following rule for maxNrOfErgchEhich:
maxNrOfErgchEhich 4
Restriction: 9313 Micro NodeB & 9314 Pico NodeB support only 1 E-AGCH and 1 ERGCH/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 [R12] for more information on the 9313 Micro NodeB.
Page 37/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 (and from UA7.1.3 by the
eCEM). It is not supported by the iCEM whatever the release and the activation
parameter will be ignored by the system. 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
RAN Path
Range & Unit
User
Class
Value
isEdchTti2msAllowed
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchTti2msAllowed
True,False
Customer
3
Object
RadioAccessService
Granularity
RNC
True
Object
EdchCellClass
True,False
Customer
Granularity
EdchCellClass
3
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).
Page 38/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.2 UE CATEGORIES
As the SF2 and 2msTTI are supported only by the xCEM and eCEM, the UE categories
4, 5 and 6 are supported only by the xCEM and eCEM 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, 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]
Category 1
SF 4
Category 2
SF 4
Category 3
SF 4
Category 4
SF 2
Category 5
SF 2
Category 6
SF 2
10
10/
2
10
10/
2
10
10/
2
7110
14484/
2798
14484
20000/
5772
20000
20000/
11484
Maximum
Data Rate
at MAC-e
layer
[Mbps]
0.71
1.45/
1.40
1.45
2.00/
2.89
2.00
2.00/
5.74
Maximum
RLC
Throughput
[Mbps]
0.67
1.38/
1.28
1.38
1.89/
2.72
1.89
1.89/
5.44
Throughput
@ ATM layer
(+30%
protocol
headers)
[Mbps]
0.87
1.79/
1.66
1.79
2.45/
3.53
2.45
2.45/
7.07
Note: When 4 codes are transmitted in parallel, 2 codes shall be transmitted with SF2 and the other 2 with SF4
Table 1: UE categories
Note: In the table just above, the RLC Throughput and the throughput at ATM layer
(the two last columns) are basic extrapolations made from the thoeritical Data rate at
Mac-e layer. They do not take into consideration normal radio properties such as Mace retransmissions. For this reason, the RLC throughput and throughput at ATM in the
table above are over-estimated and only intend to provide a rough estimation.
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
RAN Path
Range & Unit
User
Class
Value
prohibitedStatusTimer
Object
UlRlcAckMode
RNC / RadioAccessService / RlcConfClass / UlRlcAckMode
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
Customer
Granularity
RlcConfClass
3
For PS_HSDSCH_EDCH_IB_AM and SRB_HSDSCH_EDCH_AMUM instances
of RlcConfClass: 30
Page 39/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[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.
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 [R04]: 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 EDCH 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 5, 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 6, 128 E-TFCIs are defined for 2ms TTI EDCH 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
RAN Path
Range & Unit
User
Class
Value
edchTfciTableIndex
Object
EdpchParameters
Enum {2msTtiTable0, 2msTtiTable1, 10msTtiTable0, 10msTtiTable1}, N/A
Customer
Granularity
EdpchInfoClass
3
EdpchParameters instance related to 10ms TTI: 10msTtiTable1
EdpchParameters instance related to 2ms TTI: 2msTtiTable1
Rule: edchTfciTableIndex setting

For 10ms TTI and 2ms TTI, it is strongly recommended to use respectively 10ms TTI E-DCH TBS
Table 1 and 2ms TTI E-DCH TBS Table 1.
This can be done by setting edchTfcsTableIndex = 10msTtiTable1 under each instance of
EdpchParameters related to 10ms TTI, and by setting edchTfcsTableIndex = 2msTtiTable1
under each instance of EdpchParameters related to 2ms TTI.
Page 40/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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.
3GPP TB Table (TTI 10 ms)

2.0E+04
Transport block size (bits)
1.8E+04
1.6E+04
1.4E+04
1.2E+04
10ms TtiTable0
1.0E+04
10ms TtiTable1
8.0E+03
6.0E+03
4.0E+03
2.0E+03
0.0E+00
0
10 20 30 40 50 60 70 80 90 100 110 120

Transport block size Index
Figure 5: {E-TFCI; Transport Block Size} tables for 10ms TTI,

as defined in 3GPP TS 25.321
Page 41/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

3GPP TB Table (TTI 2 ms)
Transport block size (bits)
1.2E+04
1.0E+04
8.0E+03
2ms TtiTable0
6.0E+03
2ms TtiTable1
4.0E+03
2.0E+03
0.0E+00
0
10 20 30 40 50 60 70 80 90 100 110 120

Transport block size Index
Figure 6: {E-TFCI; Transport Block Size} tables for 2ms TTI,

as defined in 3GPP TS 25.321
5.4 {REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLE

INPUTS OF E-TFC SELECTION ALGORITHM AT UE
When receiving a grant, in order to select the appropriate E-TFC the UE applies the ETFC Selection algorithm specified in 3GPP TS25.321 [R04]. 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 ERGCH command. Basically, Serving_Grant defines the largest E-TFC that the
mobile is allowed to use.
{E-TFCI; TBS} table:

The aim of this table has been described in section 5.3. For a given E-DCH call,
the same table is configured both at NodeB side and at UE side.
{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).
Page 42/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 eCEM 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 EDCH 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 [R04] 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 only if the
board handling the E-DCH call is an xCEM or eCEM. 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 6.2
for a detailed description of edchMinSetEtfci parameter.
RETRIEVING FULL {E-TFCI; PO} TABLE BASED 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 [R11], section 5.1.2.5B.2.
Figure 7 shows the principle of retrieving the whole {E-TFCI; Power Offset} table
based on the {Reference E-TFCI; Reference Power Offset} table. X-axis represents
TBS, and Y-axis represents Power Offset in dB.
Page 43/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

E-DPDCH power vs. transport block size
E-DPDCH power relativ to DPCCH (dB)
30
25
20
15
10
0.2
0.4
0.6
0.8
1
1.2
TB size (bits)
1.4
1.6
1.8
2
4
x 10
Reference signaled E-TFCI

Figure 7: E-DPDCH Power vs. Transport Block Size
Again, in order to avoid too much signaling when configuring the {Reference E-TFCI;
Reference Power Offset} table both at NodeB and at UE side, the RNC sends coded
values (after quantization) for the Reference Power Offsets (i.e. power ratio E-DPDCH
/ UL DPCCH, also referred as ed/c). The coded values for Power Offsets are
specified in 3GPP TS 25.213 [R05], Table 1B.1, and recalled below for convenience.
Page 44/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Signaled values for E-DPDCH
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
Quantized amplitude ratios

Aed =ed/c
168/15
150/15
134/15
119/15
106/15
95/15
84/15
75/15
67/15
60/15
53/15
47/15
42/15
38/15
34/15
30/15
27/15
24/15
21/15
19/15
17/15
15/15
13/15
12/15
11/15
9/15
8/15
7/15
6/15
5/15
Table 2: Quantization for E-DPDCH (from 3GPP TS 25.213)
{REFERENCE E-TFCI; REFERENCE POWER OFFSET} TABLES
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.
Below two parameters are used to define the different {Reference E-TFCI; Reference
Power Offset} tables within the RNC.
Page 45/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
referenceEtfci
Object
ReferenceEtfciConfList
RNC / RadioAccessService / EdpchInfoClass / EdpchParameters /
Integer [0 127], N/A
Customer
Granularity
EdpchInfoClass
3
[iCEM] See below Table 3
[xCEM] See below Table 4
[eCEM] See below Table 5
[UCU-III] See below Table 6
referenceEtfciPowerOffset
Object
RNC / RadioAccessService / EdpchInfoClass / EdpchParameters /
Integer [0 29], N/A
Customer
Granularity
EdpchInfoClass
3
[iCEM] See below Table 3
[xCEM] See below Table 4
[eCEM] See below Table 5
[UCU-III] See below Table 6
The parameter nodebType is one of the elements used in the EdpchParameters
selection algorithm (see later in this section).
Parameter
RAN Path
Range & Unit
User
Class
Value
nodebType
Object
RNC / NodeB
Enumerate {iBTS, micro_picoBTS, oneBTS}
Customer
Granularity
2
Depends on deployed H/W
NodeB
NodeB
An important aspect concerns the creation of new ReferenceEtfciConfList

instances:
Restriction: ReferenceEtfciConfList creation
When creating new ReferenceEtfciConfList instances for the introduction of new eferenceEtfci
and referenceEtfciPowerOffset parameter settings, a MIB rebuild RNC is needed.
The recommended tables for iBTS (iCEM, xCEM and eCEM) and the recommended
tables for OneBTS on UCU-III, as well as the recommended configuration method are
described below.

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 and
eCEM E-DCH functions, the recommended {Reference E-TFCI; Reference Power
Page 46/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Offset} table is different for iCEM and xCEM / eCEM. In particular, for xCEM / eCEM, 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 EDPDCHs / UL DPCCH power ratio (set via {Reference E-TFCI; Reference Power Offset}
table), compared with iCEM. Please refer to section 7.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.
Table Name
10ms_1xSF4_iCEM
10ms_1xSF4_iCEM
10ms_1xSF4_iCEM
10ms_1xSF4_iCEM
10ms_1xSF4_iCEM
10ms_1xSF4_iCEM
10ms_2xSF4_iCEM
10ms_2xSF4_iCEM
10ms_2xSF4_iCEM
10ms_2xSF4_iCEM
10ms_2xSF4_iCEM
10ms_2xSF4_iCEM
referenceEtfci
referenceEtfciPowerOffset
0
1
2
3
4
5
0
1
2
3
4
5
0
3
11
85
95
96
0
3
11
85
95
96
2
11
15
22
23
24
2
11
15
22
23
24
Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset} table
Page 47/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For xCEM, the recommended {Reference E-TFCI; Reference Power Offset} table is as
follows.
Table Name
2ms_2xSF2+2xSF4_xCEM
2ms_2xSF2+2xSF4_xCEM_656PDU
2ms_2xSF2_xCEM
2ms_2xSF2_xCEM
2ms_2xSF2_xCEM
2ms_2xSF4_xCEM
2ms_2xSF4_xCEM
2ms_2xSF4_xCEM
10ms_1xSF4_xCEM
10ms_1xSF4_xCEM
10ms_1xSF4_xCEM
10ms_1xSF4_xCEM
10ms_1xSF4_xCEM
10ms_2xSF2_xCEM
10ms_2xSF2_xCEM
10ms_2xSF2_xCEM
10ms_2xSF2_xCEM
10ms_2xSF2_xCEM
10ms_2xSF4_xCEM
10ms_2xSF4_xCEM
10ms_2xSF4_xCEM
10ms_2xSF4_xCEM
10ms_2xSF4_xCEM
10ms_2xSF4_xCEM
ReferenceEtfciConfList referenceEtfci referenceEtfciPowerOffset

0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
0
1
2
0
1
2
3
4
0
1
2
3
4
0
1
2
3
4
0
1
2
3
4
5
3
5
59
69
72
80
91
98
3
5
59
69
72
80
91
98
3
5
83
3
5
83
3
5
25
51
106
3
5
25
51
106
3
5
25
51
106
0
3
11
85
95
96
13
14
15
16
16
17
18
21
13
14
15
16
16
17
18
21
13
14
20
13
14
20
9
10
16
18
19
9
10
16
18
19
9
10
16
18
19
2
11
15
22
23
24
Table 4: xCEM recommended {Reference E-TFCI; Reference Power Offset} table
Page 48/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For eCEM, the recommended {Reference E-TFCI; Reference Power Offset} table is as
follows:
Table Name
2ms_2xSF2+2xSF4_eCEM
2ms_2xSF2+2xSF4_eCEM_656PDU
2ms_2xSF2_eCEM
2ms_2xSF2_eCEM
2ms_2xSF2_eCEM
2ms_2xSF4_eCEM
2ms_2xSF4_eCEM
2ms_2xSF4_eCEM
10ms_1xSF4_eCEM
10ms_1xSF4_eCEM
10ms_1xSF4_eCEM
10ms_1xSF4_eCEM
10ms_1xSF4_eCEM
10ms_2xSF2_eCEM
10ms_2xSF2_eCEM
10ms_2xSF2_eCEM
10ms_2xSF2_eCEM
10ms_2xSF2_eCEM
10ms_2xSF4_eCEM
10ms_2xSF4_eCEM
10ms_2xSF4_eCEM
10ms_2xSF4_eCEM
10ms_2xSF4_eCEM
10ms_2xSF4_eCEM

0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
0
1
2
0
1
2
3
4
0
1
2
3
4
0
1
2
3
4
0
1
2
3
4
5
3
5
59
69
72
80
91
98
3
5
59
69
72
80
91
98
3
5
83
3
5
83
3
5
25
51
106
3
5
25
51
106
3
5
25
51
106
0
3
11
85
95
96
13
14
15
16
16
17
18
21
13
14
15
16
16
17
18
21
13
14
20
13
14
20
9
10
16
18
19
9
10
16
18
19
9
10
16
18
19
2
11
15
22
23
24
Table 5: eCEM recommended {Reference E-TFCI; Reference Power Offset} table
Page 49/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[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).
The recommended {Reference E-TFCI; Reference Power Offset} table is as follows for
the UCU-III.
Table Name
2ms_2xSF2+2xSF4_UCU3
2ms_2xSF2+2xSF4_UCU3_656PDU
2ms_2xSF2_UCU3
2ms_2xSF2_UCU3
2ms_2xSF2_UCU3
2ms_2xSF4_UCU3
2ms_2xSF4_UCU3
2ms_2xSF4_UCU3
10ms_1xSF4_UCU3
10ms_1xSF4_UCU3
10ms_1xSF4_UCU3
10ms_2xSF2_UCU3
10ms_2xSF2_UCU3
10ms_2xSF2_UCU3
10ms_2xSF4_UCU3
10ms_2xSF4_UCU3
10ms_2xSF4_UCU3

0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
0
1
2
3
5
59
69
72
80
91
98
3
5
59
69
72
80
91
98
3
5
83
3
5
83
3
9
25
3
9
25
3
9
25
3
9
25
13
14
15
16
16
17
18
21
13
14
15
16
16
17
18
21
13
14
20
13
14
20
10
13
17
10
13
17
10
13
17
10
13
17
Table 6: UCU-III recommended {Reference E-TFCI; Reference Power Offset} table
{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:
Page 50/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
The HSUPA Category of the considered UE,
The type of NodeB (indicated

micro_picoBTS, oneBTS,
For iBTS NodeB case, the type of board handling E-DCH for the E-DCH serving
cell: iCEM , xCEM or eCEM (the E-DPDCH SF capability of the E-DCH serving cell,
sent by the NodeB at startup, allows to differentiate iCEM and xCEM/eCEM; the
MIMO capability allows to differentiate xCEM and eCEM).
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 8
The requested type of E-DCH TTI (i.e. 10ms or 2ms)
by the
parameter
nodebType): iBTS,
Remark: The reason why cell E-DPDCH SF capability is taken into account in {Ref ETFCI; Ref PO} table selection mechanism is to make possible the use of a different
table for a cell served by an iCEM and a cell served by an xCEM, eCEM 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, xCEM, eCEM 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, eCEM or UCU-III, by looking at the SF capability of a given cell, and
additionally looking at the type of NodeB indicated through the parameter
nodebType, 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.
RadioAccessService
UserServiceProfile
EdpchInfoClass
UlUserService
UlRbSetConf
DedicatedConf
edchUserServiceProfile
EdpchParameters
EdchParameters
EdchCombination
EdchCellClass
Figure 8: E-DCH parameters model at OMC-R

Page 51/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The EdpchInfoClass is selected according to the edpchInfoClassId parameter.
This identifier edpchInfoClassId can be found on the object UlUserService and,
optionally, on the new UA08 optional object EdchCombination. If
edpchInfoClassId is set under the optional object EdchCombination, it is used. If it
is unset under the optional object EdchCombination, then the one under
RNC/RadioAccessService/UlUserService is used.
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 all 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. Nodeb type and board type is determined based on the parameter
nodebType, the E-DPDCH SF capability and the MIMO capability of the primary cell.
Step 2. EDCH TTI is computed based on the primary cell configuration (2msTti
enabled or not) and the HSUPA UE Category.
Step 3. EDCH SF is computed as the minimum value between the UE E-DPDCH SF
capability and the primary cell E-DPDCH SF capability.
Remarks:
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 is forced to 2xSF2. This case applies to both the Global and
US markets.
The combination of these three steps ends with the selection of relevant table
instance, e.g 10ms_2xSF2_xCEM, 10ms_2xSF2_UCU3,
UA6, UA7 UA08 Delta: {Reference E-TFCI; Reference Power Offset} table
Before UA08 release, the available and used EdpchInfoClass instances are the ones with name
beginning with UECategory (e.g UECategory4EdchTti2ms, )
From UA08 release onwards, a different naming is adopted: the available and used
EdpchInfoClass instances are the ones with name made of <EDCH TTI>_<EDCH SF>_<Board>
The instances with 656PDU are not available to be used.
{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.
Page 52/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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.
{Typical values for AG index, SG index and E-TFCI}

Some examples of values for SG index, E-TFCI and TBS computed by the UE are
presented below. They are derived from the standard 3GPP 25.321 and from the
recommended settings, in particular the settings for the edpchParameters and
edchInitialTBIndex2msTTI. Of course the values would be different in case other
settings are used.
These examples are shown because they correspond to some interesting specific
situations.
o
Active 2msTTI Cat6 UE during an overload situation. The transport block size that
the UE is allowed to use is derived from the parameter edchMinSetEtfci
configured for 2ms.
SG = 13; E-TFCI = 3; TBS = 354 bits; number of Mac-d PDU = 1.
Active 10msTTI Cat5 UE during an overload situation. The transport block size
that the UE is allowed to use is derived from the parameter edchMinSetEtfci
configured for 10ms.
SG = 12; ETFCI = 7; TBS = 690 bits; number of Mac-d PDU = 2.
E-DCH 2msTTI Cat6 call setup. The UE will be given an initial Transport Block size
that it is allowed to use, allowing it to start the data transmission without need for
explicit grant request through standalone SI.
SG = 16; E-TFCI = 8; TBS = 690 bits; number of Mac-d PDU = 2.
E-DCH 10msTTI Cat5 call setup. The UE will be given an initial Transport Block
size that it is allowed to use, allowing it to start the data transmission without
need for explicit grant request through standalone SI.
SG = 22; E-TFCI = 52 (on iBTS); TBS = 6774 bits; number of Mac-d PDU =
20.
An inactive UE requires to becomes active and send a standalone SI, in a normal

load situation.
AG = 1, E-TFCI = 0; TBS = 18 bits; number of Mac-d PDU = 0.
Page 53/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.5 FRAME PROTOCOL ON IUB

UNBUNDLING MODE
When E-DCH is configured with TTI of 10ms, the NodeB sends to the RNC one IUB EDCH FP Data Frame, containing one MAC-e PDU, each 10ms.
[xCEM] [eCEM]
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 EDCH with a TTI 2ms, this flag specifies if the NodeB shall bundle the E-DCH FP frame
of 2ms into an FP frame of 10ms (this parameter is specific xCEM).
Parameter
RAN Path
Range &
Unit
User
Class
Value
isEdchFpBundlingModeForEdchTti2msAllowed
Object
RNC / RadioAccessService / DedicatedConf / NodeBConfClass
Boolean (True, False)
NodebConfClass
Customer
3
NodebConfClass
Granularity
False
Restriction: For E-DCH configured with TTI of 2ms, xCEM and eCEM only support
unbundling mode, which consists in NodeB sending E-DCH FP Data Frame every 2ms
The parameter isEdchFpBundlingModeForEdchTti2msAllowed must be set to False.
[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 is 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.
Page 54/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 [R08], see Power Offset for Scheduling Info IE). The value in dB for this
specific Power Offset is set via powerOffsetForSchedInfo parameter.

The following parameter is used for 10ms TTI:
Parameter
RAN Path
Range & Unit
User
Class
Value
powerOffsetForSchedInfo
Object
Integer [0 6], dB
Customer
Granularity
3
EdchCellClass
EdchCellClass
6
The following parameter is used for 2ms TTI:
Parameter
RAN Path
Range & Unit
User
Class
Value
powerOffsetForSchedInfoEdchTti2ms
Object
Integer [0 6], dB
Customer
Granularity
3
EdchCellClass
EdchCellClass
3
[UCU-III]
Parameter
RAN Path
Range & Unit
User
Class
Value
powerOffsetForSchedInfo
Object
Integer [0 6], dB
Customer
Granularity
3
EdchCellClass
EdchCellClass
0
Since UA7.1, the UCU-III supports the 2 ms TTI. The following parameter is used for
2ms TTI:
Parameter
RAN Path
Range & Unit
User
Class
Value
powerOffsetForSchedInfoEdchTti2ms
Object
Integer [0 6], dB
Customer
Granularity
3
EdchCellClass
EdchCellClass
Page 55/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5.6.1 PLNON-MAX
PL stands for Puncturing Limit. PLmax and PLnon-max quantities are used as inputs in
the algorithm (implemented both at NodeB side and at UE side) computing for each ETFCI the required number of E-DPDCH(s) and their SF.
The standard 3GPP TS 25.212 [R02] section 4.8.4.1 gives the following definition:
The maximum amount of puncturing that can be applied is

1-PLnon-max if the modulation scheme or the number of code channels is less
than the maximum allowed by the UE capability and restrictions imposed by UTRAN.
1-PLmax if the modulation scheme and the number of code channels equals
to the maximum allowed by the UE capability and restrictions imposed by UTRAN.
PLmax value is specified by 3GPP.
On the other hand, PLnon-max value is not specified by 3GPP. PLnon-max value can be set
via plNonMax parameter under EdpchParameters.
plNonMax: Used to set the value of PLnon-max. plNonMax parameter value must be
specified as plNonMax = 25 * PLnon-max .
Page 56/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
plNonMax
Object
EdpchParameters
Integer [11 25], 25 * PLnon-max
Customer
Granularit EdpchInfoClass
y
3
EdpchParameters instance
plNonMax value
All 10ms iCEM and mpico instances:

10ms_1xSF4_iCEM
10ms_1xSF4_mpico
10ms_2xSF4_iCEM
10ms_2xSF4_mpico
25 (corresponds to PLnon-max = 1)
All 10ms xCEM, eCEM and UCU3

instances:
10ms_1xSF4_UCU3
10ms_1xSF4_eCEM
10ms_1xSF4_xCEM
10ms_2xSF2_UCU3
10ms_2xSF2_eCEM
10ms_2xSF2_xCEM
10ms_2xSF4_UCU3
10ms_2xSF4_eCEM
10ms_2xSF4_xCEM
18 (corresponds to PLnon-max = 0.72)
All 2ms instances:

2ms_2xSF2_UCU3
2ms_2xSF2_eCEM
2ms_2xSF2_xCEM
2ms_2xSF4_UCU3
2ms_2xSF4_eCEM
2ms_2xSF4_mpico
2ms_2xSF4_xCEM
20 (corresponds to PLnon-max = 0.8)
Remark: Similarly to {Reference E-TFCI; Reference Power Offset} table, the PLnon-max
value used for a given UE is selected according to type of board handling E-DCH for
the E-DCH serving cell, HSUPA UE Category, E-DCH TTI type and UL service.
Page 57/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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
RAN Path
isTpcAlgo2ForEdchCat4
Range & Unit
Boolean
User
Class
Value
Customer
3
Object
RadioAccessService
Granularity
RNC
RNC RadioAccessService
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
isTpcAlgo2ForEdchCat6
Parameter
RAN Path
RNC RadioAccessService
Range & Unit
Boolean
User
Class
Value
Customer
3
Object
RadioAccessService
Granularity
RNC
True
Page 58/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
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 [R11],
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] [eCEM] edchMacdPowerOffsetEdchTti10: the recommended value

for edchMacdPowerOffsetEdchTti10 is 0.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchMacdPowerOffsetEdchTti10
Object
EdchParameters
[0..6] step:1
Customer
Granularity
UlRbSetConf
3
0
Page 59/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
[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.
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
EdchParameters
[0..6] step:1
Customer
Granularity
UlRbSetConf
3
For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 5
[xCEM] [eCEM] [UCU-III] edchMacdPowerOffsetEdchTti2: when the EDCH 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.
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
EdchParameters
[0..6] step:1
Customer
Granularity
UlRbSetConf
0
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 60/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6 MAC-E SCHEDULER
The task of the E-DCH 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. Each
UE will adapt its throughput on E-DPDCH according to the grants it has received, by
selecting an E-TFC in the E-TFCS that is compatible with the power granted.
The 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.
The terminology used in this section to describe the scheduler algorithm (e.g Ltarget,
Lhypothetical, Lavailable) is inherited from the new generation of modem (xCEM, eCEM and
UCU-III). However the concept behind is applicable for the old generation (iCEM) as
well. Differences, if any, are highlighted with the usual notation.
6.1 MAC-E SCHEDULER INPUTS

NodeB resources
- E-DCH processing resources are pooled across cells handled by one
modem board.
[xCEM][eCEM]
For xCEM and eCEM the processing resources can be configured accordingly
with the license agreement via edchMaxThroughputXcem and
edchMaxThroughputEcem which indicates the maximum throughput in
kbps for E-DCH traffic (MAC-e layer), that can be used. Refer to [R13] for
more details on these parameters.
Remark: These parameters limit 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 =
Page 61/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
[iCEM] 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
and especially TTI2ms performances. Refer to [R13] 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
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message.
derived
from
OMC-R
parameters
FDDCelltotalRotMax
FDDCellrtwpReference. RTWPref will be adjusted according to
learned RTWP value in the NodeB, as well as the resulting RoT.
over
It is
and
self-
- 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-EdchPowerRatio (see Vol.6 for further
details regarding this parameter).
- The IUB congestion status is locally evaluated by the NodeB and the
resulting IUB overload indicator is sent to the scheduler. For iBTS, this is
covered by the feature 75786 iBTS Local E-DCH Congestion Control and
available for xCEM and eCEM, not for iCEM, while for the OneBTS it is
included as baseline behaviour and does not require specific activation flag.
- The IUB congestion status may also be remotely evaluated (by the RNC) and
sent to the NodeB which computes the resulting GRF (Global Reduction
Factor). For iBTS, this is covered by the feature 33332 Iub bandwidth
limitation and 33367 congestion detection & notification. For the OneBTS
only the local detection is used.
[xCEM][ecem][UCU-III]
The target UL load Ltarget is derived and is defined as the most restricting criterion
among above limitations. This is summarized with the following formula:
Ltarget = min{Llimit,rtwp, Llimit,ovld, Llimit, iBTS capacity, GRF}
Llimit,rtwp is the E-DCH load limit derived from UL Load measurements (see section 4.1.1
in this volume). Llimit,ovld and GRF are the E-DCH load limits derived from the IUB
congestion status. Llimit, iBTS capacity is the E-DCH load limit derived from the iBTS
capacity configuration (license agreement), not applicable to UCU-III.
Page 62/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[iCEM] The iCEM computes the limit based on the RTWP and the GRF. The two other
criteria are not implemented.
Measurements
The scheduler perfoms UL Load evaluation based on the received RTWP
measurements and the configured UL Load evaluation method. The measurements
processing is fully described in the section 4.1.1 in this volume.
The available E-DCH load is then derived and corresponds to
Lavailable= Ltarget - Lnon E-DCH.
If Lavailable > 0, then the scheduler will calculate the scheduling grant as described in
the section 6.2
If Lavailable <= 0, then the cell is overloaded and the scheduler will apply the overload
algorithm as described in the section 6.3
[iCEM]
The radio overload condition is defined by the fact that the UL Load is above the
RTWPlimit
(totalRotMax
(rtwpTimeDetection).
Note
rtwpMargin)
that
the
during
parameters
certain
rtwpMargin
time
and
rtwpTimeDetection are not used for xCEM, eCEM or UCU-III overload algorithm.
UE specific information
- 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 6.4.
for further details about these two parameters). They contain the following
information:
o
Total E-DCH buffer status (TEBS, 5 bits)
Highest priority logical channel ID (HLID, 4 bits)
Highest priority logical channel buffer status (HLBS, 4 bits)
UE transmission power headroom (UPH, 5 bits):

Power ratio of maximum allowed UE transmit power to DPCCH pilot
bit transmit power.
- Happy bit: this bit is transmitted on the E-DPCCH and represents the UE
state according to his current max grant notification. 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.
- Reference scheduling grant SGref, i, taken from previous scheduling interval
Page 63/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

- 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 selected E-DCH TTI is 10ms.
Parameter
RAN Path
Range & Unit
User
Class
Value
happyBitDelay
Object
Enum {2, 10, 20, 50, 100, 200, 500, 1000}
Customer
Granularity
3
[iCEM][xCEM][eCEM] 50
[UCU-III] 10
EdchCellClass
RNC,
EdchCellClass
The parameter happyBitDelayEdchTti2ms defines the delay to be used by the UE

in the procedure to set the Happy Bit when selected E-DCH TTI is 2ms.
Parameter
RAN Path
Range & Unit
User
Class
Value
happyBitDelayEdchTti2ms
Object
Enum {2, 10, 20, 50, 100, 200, 500, 1000}
Customer
Granularity
3
EdchCellClass
EdchCellClass
10
6.2 SCHEDULING GRANT

The resource allocation is done in two steps. First, the MAC-e scheduler computes the
requested transport block for all serving UEs depending on the happy bit status and
whether SI was received, and derives a hypothetical load if all requests were satisfied.
Once the hypothetical load is computed, the MAC-e scheduler shall check if the
hypothetical load is kept within the available load. If Lhypothetical Lavailable, AG and/or
RG are sent to UEs. Otherwise, the MAC-e scheduler shall reduce the target grants.
Calculate request and target grant

If a UE reports happy bit = 1, the same TB as derived in previous scheduling interval
shall be kept. Otherwise, the requested TB, TBrequested, shall be set to 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] [eCEM]
If an SI is received while UE is not granted, the MAC-e scheduler assumes for initial
grant computation that TBrequested = TB(EdchconfedchInitialTBIndexXxx).
edchInitialTBIndex10msTTI and edchInitialTBIndex2msTTI parameters are
used to set the E-TFCI to be used for initial grant sent to UE via AG command.
Page 64/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

[iCEM]
Regarding iBTS, edchInitialTBIndexXxx parameters are taken into account by the
system only if the board handling the E-DCH call is an xCEM or eCEM. 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 and eCEM,
this initial grant is sent to UE via RRC signaling and not via AG command. A hardcoded 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
edchInitialTBIndex2msTTI are internal NodeB tunable parameters.
and
The requested TB is converted to a target grant SGtarget, i for each UE i and the total
UL load Lhypothetical is computed. If Lhypothetical Lavailable, all the requests can be fulfilled
and the MAC-e scheduler proceeds with AG and/or RG sending.
Otherwise, the MAC-e scheduler reduces the requested grants.
The two following parameters are applicable to iCEM, xCEM and eCEM boards (not
UCU-III).
Parameter
RAN Path
Range & Unit
User
Class
Value
edchInitialTBIndex10msTTI
Object
EdchConf

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

[0..127] step 1
Customer
3
Granularity
Cell
Hypothetical overload
Lhypothetical > Lavailable: 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 SWi
depending on the UEs SPI.
Page 65/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 Nonserving E-DCH to Total E-DCH Power Ratio set by RNC. If this is not the case,
the MAC-e scheduler shall first reduce non-serving UEs by sending DOWN
command. The MAC-e scheduler shall also check whether the interference created by
the 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 [R04] 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 [R04], 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 or eCEM. As explained in 5.4,
RNC detects the type of board handling E-DCH traffic for the considered cell via the EDPDCH 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
RAN Path
Range & Unit
User
Class
Value
edchMinSetEtfci
Object
EdpchParameters
[0..127] step:1
Customer
Granularity
EdpchInfoClass
3
EdpchParameters instances related to 10ms TTI: 7
EdpchParameters instances related to 2ms TTI: 3
RATE SCHEDULING (iCEM only)
In iCEM, only one type of E-DCH scheduling is supported: Rate Scheduling.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchSchedulerAlgorithm
Object
BTSEquipment
Enum {roundRobinSlidingWindow, rateScheduling}
Customer
Granularity
3
[iCEM] rateScheduling
[xCEM][eCEM][UCU-III] Not applicable
BTSEquipment
BTS
Page 66/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
For more details, see [R03].
edchRateSchedulerOptimisationTimer is the period over which UE can be
granted more than its nominal quantum.
edchRateSchedulerOptimisationTimer
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
[10..50] step 4. Unit=TTI
Customer
3
[iCEM] 10
[xCEM][eCEM][UCU-III] Not applicable
Object
BTSEquipment
Granularity
BTS
6.3 OVERLOAD ALGORITHM

Lavailable <= 0: this condition corresponds to actual overload situation. In this case,
the MAC-e scheduler reduces the E-DCH traffic in order to overcome the overload
situation. For this, the MAC-e scheduler immediately proceeds with the following
actions:
It reduces the SG to SGmin,i for all EDCH serving users. SGmin,i is the Scheduling
Grant corresponding to the TB(edchMinSetEtfci).
It sends RG DOWN to non-serving groups of users if the non-serving load is

greater than 0.
Page 67/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
If a user has no SG from previous scheduling period, then it does not allocate
any grant for this user.
However it does not block AG commands, meaning a new user (at EDCH RAB
setup) or a user becoming active after an inactivity period may acquire a
grant through AGCH. The interest of this is to provide such UE with a
minimum grant avoiding letting it stucked in a zero grant situation that
might eventually ends with a call drop, or at least a too drastic reduction of
the traffic. Besides, for a user with E-DCH macro-diversity, these AGCH - sent
by the MAC-e scheduler running on the serving cell should help counter-act
the potential downgrant from the MAC-e scheduler(s) running on the nonserving cells.
Note that the AGCH not blocked during the overload situation is a mechanism
introduced from UA7.1.3.8 onwards. In previous releases, the AGCH was blocked for
users wishing to become active after an inactivity period (though initial grant at Rab
Setup or FACH to DCH transition was still allocated). Moreover for iBTS, in case of
extreme overload, SGmin,i was even overwritten with 0 instead of the one
corresponding to edchMinSetEtfci. These extra-protection mechanisms have been
removed since they were too conservative and led to too many blocking situations
(a.k.a zero grant issue).
For the xCEM, eCEM and UCU-III, the 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. For xCEM and eCEM, the E-DCH Max load is
the one derived from the totalRotMax, while for UCU-III it is set internally to 85%
by default. Note that limits other than this Llimit,rtwp are also taken into consideration
(Llimit,ovld, Llimit, iBTS capacity, GRF), as previously explained in the section 6.1.
[iCEM] The overload is defined by the fact that the UL load is above the RTWPlimit
(totalRotMax + rtwpMargin) during a certain time (rtwpTimeDetection). The
scheduler downgrants the UE through AG commands until the load reduces.
6.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.
Page 68/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range &
Unit
User
Class
Value
isEdchSchedulingInfoReportingAllowed
Object
False,True
Customer
Granularity
3
EdchParameters
UlRbSetConf
True for scheduled mode E-DCH RB: PS_EDCH and PS_EDCH_MUX

False for non-scheduled mode E-DCH RB: SRB_EDCH
isEdchSchedulingInfoReportingEdchTti2msAllowed
Object
EdchParameters
Granularity
UlRbSetConf

False,True
Customer
3
True for scheduled mode E-DCH RB: PS_EDCH and PS_EDCH_MUX,

False for non-scheduled mode E-DCH RB: SRB_EDCH
The amount of time with no data from UE, used to consider a UE as inactive, is
configurable through the parameter edchInactivityTimerXcem for xCEM and
eCEM, and through the parameter siActivityTimer for iCEM.
Parameter
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
edchInactivityTimerXcem
Object
EdchConf

[0..20000ms] step 40
Customer
3
[xCEM][eCEM] 1440
Granularity
Cell
siActivityTimer (iCEM-specific)
BTSEquipment
Integer [8 48] (step: 4). TTI.
Customer
3
Object
BTSEquipment
Granularity
BTS
12
Rule: siActivityTimer
The siActivityTimer should be set according to the following rule:
siActivityTimer*TTI > max(periodicityOfSchedInfoNoGrant, periodicityOfSchedInfoGrant).
Page 69/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Similar parameter is used for UCUIII, but it is an internal NodeB tunable parameter
(cannot be modified through OAM), and its value by default is 1440ms.
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):
Parameter
RAN Path
Range & Unit
User
Class
Value
periodicityOfSchedInfoGrant
Object
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
Granularity
3
EdchCellClass
EdchCellClass
50
Remark: OneBTS has the same table shown above, but a default value of 100 ms
for periodicityOfSchedInfoGrant.
Parameter
RAN Path
Range & Unit
User
Class
Value
periodicityOfSchedInfoGrantEdchTti2ms
Object
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
Granularity
3
EdchCellClass
EdchCellClass
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
RAN Path
Range & Unit
User
Class
Value
periodicityOfSchedInfoNoGrant
Object
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
Granularity
3
EdchCellClass
EdchCellClass
100
Remark: OneBTS has the same table shown above with the same default value of
100 ms for periodicityOfSchedInfoNoGrant.
Parameter
RAN Path
Range & Unit
User
Class
Value
periodicityOfSchedInfoNoGrantEdchTti2ms
Object
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
Granularity
3
EdchCellClass
EdchCellClass
100
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 100 ms for
periodicityOfSchedInfoNoGrantEdchTti2ms.
Page 70/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.5 GENERATION OF AG & RG

The scheduler allocates resources either by sending Absolute Grant (AG) over E-AGCH
channel or Relative Grant (RG) over E-RGCH channel.
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 [R02]:
Absolute Grant Value
(168/15)2x6
(150/15)2x6
(168/15)2x4
(150/15)2x4
(134/15)2x4
(119/15)2x4
(150/15)2x2
(95/15)2x4
(168/15)2
(150/15)2
(134/15)2
(119/15)2
(106/15)2
(95/15)2
(84/15)2
(75/15)2
(67/15)2
(60/15)2
(53/15)2
(47/15)2
(42/15)2
(38/15)2
(34/15)2
(30/15)2
(27/15)2
(24/15)2
(19/15)2
(15/15)2
(11/15)2
(7/15)2
ZERO_GRANT*
INACTIVE*
Index
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Table 7: Grant Index values
Once the grant is signaled, the E-DPDCH power should not exceed the grant
information:
n. ed2 < signaled grant value

Where n stands for the number of E-DPDCH physical channels.
Page 71/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The E-RGCH can give relative grants for several UEs simultaneously since it is made of
20 E-RGCH signatures, one signature addresses one UE or a group of UE (common
signature). Refer to [Vol.2] for more information on the E-RGCH structure.
The resources are allocated essentially via RG. AG is used only at call setup and for
activation and deactivation.
Generation of absolute scheduling grants
-
AG = ZERO is sent when inactivity is detected.
After reception of SI trigger, AG is sent with the next valid value with AG
SGtarget.
Generation of relative scheduling grants
-
If SGtarget,i > SGref,i, set RGi = UP".
If SGtarget,i = SGref,i, set RGi = "HOLD".
If SGtarget,i < SGref,i, set RGi = "DOWN".
[iCEM] For iCEM, the AGCH is always the channel used to give resource to the UE, i.e
AG is not only used at call setup or when the UE activity resumes, but each time iCEM
grants a UE. iCEM uses RG only for the management of the non-serving UE.
DEFENSE MECHANISMS AGAINST E-AGCH BAD DETECTION

It may happen that a UE performing an E-DCH call does not detect, or wrongly
decodes an E-AGCH command intended to this UE. The consequence of this is that
the considered UE may not transmit data although it has been granted, or use an ETFCI that is not appropriate (too high or too low) regarding the grant it has been
allocated.
If the UE uses an E-TFCI too high regarding the grant it has been allocated, NodeB
cannot decode data sent by UE on E-DCH, since for this UE hardware resources have
not been reserved at NodeB for such large E-TFC. For this specific case, the wrongly
detected E-AGCH should be resent as soon as possible in order to avoid useless EDCH transmissions (since not decoded by NodeB) that cause UL interference for other
users.
If the UE uses an E-TFCI too low regarding the grant it has been allocated, NodeB
normally decodes data sent by UE on E-DCH, but E-DCH user throughput is degraded
compared to what it could have been if UE had correctly decoded the E-AGCH
command.
Page 72/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following defense mechanism is implemented: if the received E-TFCI is above the
one the scheduler was expecting from a given UE, the scheduler at the next
scheduling interval, sends to this UE an AG corresponding to a grant just below or
equal the computed SGtarget,i.
[iCEM]
Since UA5/iCEM, the following defense mechanisms against E-AGCH bad detection
have been implemented in the MAC-e scheduler.
ImpleE-AGCH bad detection case
mentation (detection is done on reception
Release
of E-DPCCH at NodeB)
UA5.0
UA5.0
UA5.1
onwards
Action taken by MAC-e scheduler
UE uses an E-TFCI higher than

the maximum E-TFCI allowed
according to current grant
computed by MAC-e scheduler
for this UE.
For a given UE, each time any of beside cases is

detected (on reception of E-DPCCH at NodeB), an EAGCH error counter is incremented for this UE. The EAGCH error counter is reset if UE happens to use an ETFCI different than the one used when E-AGCH error
was detected. If the counter reaches a certain limit
UE sends a MAC-e PDU that (7), an E-AGCH Alarm is raised for this UE.
only includes SI (no payload),
MAC-e scheduler then resends E-AGCH commands
although MAC-e scheduler has
(the same command that has been sent previously but
granted this UE with a grant
not detected or wrongly decoded) to UEs for which an
different than Zero Grant.
E-AGCH alarm has been raised.
Happy Bit received from UE is

set to unhappy, while UE uses
an E-TFCI lower than [the
allowed
maximum
E-TFCI
according to current grant
computed by MAC-e scheduler
for this UE] -3.
Remark: For the case when UE uses an E-TFCI higher

than the maximum E-TFCI allowed (and only for this
case), after the E-AGCH error counter has reached the
limit (i.e. after E-AGCH Alarm has been raised), the EAGCH channel is preempted (with regards to already
planned E-AGCH commands) in order to resend the EAGCH command as soon as possible.
[iCEM] [xCEM] [eCEM] (ergch2IndexStepThreshold &
ergch3IndexStepThreshold settings)
Parameter
RAN Path
Range & Unit
User
Class
Value
ergch2IndexStepThreshold
Object
EdpchParameters
[0..37] step 1
Customer
Granularity
EdpchInfoClass
3
[xCEM][eCEM] 20 for both 10ms TTI and '2msec TTI' Edpch instances
[UCU-III] 18 for the 10ms TTI Edpch instances
Page 73/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

ergch3IndexStepThreshold
Object
EdpchParameters
[0..37] step 1
Customer
Granularity
EdpchInfoClass
3
[xCEM][eCEM] 16 for both 10ms TTI and '2msec TTI' Edpch instances
Parameter
RAN Path
Range & Unit
User
Class
Value
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
ms
TTI.
For
this
TTI,
the
ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set to

the same values as the xCEM or eCEM, namely ergch2IndexStepThreshold=20,
and ergch3IndexStepThreshold=16.
6.6 PRIORITY INFO IN MAC-E SCHEDULER

It is possible to configure and signal 16 SPI (Scheduling Priority Indicator) values to
NodeB. From UA7 onwards, 6 priority levels (instead of the previous 4) will be
supported. An internal mapping shall be performed (e.g.):
Page 74/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Highest Priority
Lowest Priority
Scheduling Priority
Internal priority level
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Prio_Level_1
Prio_Level_2
Prio_Level_3
Prio_Level_4
Prio_Level_5
Prio_Level_Other
Table 8: Scheduling Priority xCEM/eCEM

Since only 6 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 supports 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 6) 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 iCEM, xCEM, and eCEM.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchSpiRelativeWeight
[1..16][0..100]
Customer
3
Object
EdchConf
Granularity
Cell
100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100

Remark: This mode can be disabled by setting all the weight values equal to 100.
Page 75/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

OAM must check after reception of this table the following items:
-
Values of weights from SPI = 9 to SPI = 0 are set to 100
Values from SPI = 15 to SPI = 10 are set with decreasing values:

1 E-DCHSpiRelativeWeight [SPI = 10]
E-DCHSpiRelativeWeight [SPI = 11]
E-DCHSpiRelativeWeight [SPI = 15] 100
The parameter edchSpi provides the RNC E-DCH Scheduling Priority Indicator
(E-DCH SPI) associated to a given TrafficClassBasedQoS/ARPBasedQoS/THPBasedQoS
instances combination (in other words, for each E-DCH call, the Core Network
provides in RANAP RAB Assignment message the following QoS attributes: TC - Traffic
Class, ARP - Allocation Retention Priority, THP - Traffic Handling Priority). This
information is then used in the E-DCH scheduler (at NodeB level) to prioritize the
different MAC-d flows.
edchSpi parameter is used in the same way for iCEM, xCEM, eCEM and UCU-III
cases.
Parameter
RAN Path
Range & Unit
User
Class
edchSpi
Object
ThpBasedQos
RNC / RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos
[0 15]
Customer
Granularity
TrafficClassBasedQos,
ArpBasedQos,
3
Value
Depends on customer strategy
ThpBasedQos
Page 76/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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

Note: Streaming over HSUPA feature is still not available.
The principle of SPI management on xCEM and eCEM is the following (not
applicable to iCEM):
The MAC-e scheduler de-grants the UE with lowest priority and updates the
hypothetical load and repeats the procedure as long as Lhypothetical > Lavailable. Each UE
will be de-granted by 1 step at the maximum.
-
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 77/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range & Unit
User
Class
Value
serviceMinRate
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceMaxRate
Parameter
RAN Path
Range & Unit
User
Class
Value
serviceBfactor
Object
EdchServiceParameterSet
BTSEquipment / BTSCell / EdchConf / EdchServiceParameterSet
[0..10000]
Customer
Granularity
Cell
3
40 (default value)
Object
[0..10000]
Customer
Granularity
Cell
3
300 (default value)

Object
[1..30]
Customer
Granularity
Cell
3
7 (default value)
Parameter
serviceKfactor
Object
RAN Path
Range & Unit
[1..30]
User
Customer
Granularity
Cell
Class
3
Value
7 (default value)
Remark: This mode can be disabled by setting the serviceBfactor equal to 1 for all the
SPI.
[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS.
The following set of parameters is available.
edchServiceParameterSet1: This parameter set defines the OAM parameters,

which are valid for the interactive "gold" service class, i.e. with highest priority
Page 78/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
schedulingPriorityLevel
serviceMinRate
serviceMaxRate
serviceBFactor
serviceKFactor
RAN Path
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
OneBTSEquipment / EDCHServiceParameterSet1
Integer: {0,1,..,15}
Customer
Granularity
BTS
3
Object
EDCHServiceParameterSet1
15
serviceMinRate
Integer: {0,1,..,10000}
40 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
300 [kbps]
serviceBFactor
Integer: {0,1,..,30}
serviceKFactor
Integer: {0,1,..,30}

which are valid for the interactive "silver" service class, i.e. with medium priority.
Parameter
serviceMinRate
serviceMaxRate
serviceBFactor
serviceKFactor
RAN Path
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Integer: {0,1,..,15}
Customer
Granularity
BTS
3
Object
14
serviceMinRate
Integer: {0,1,..,10000}
25 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
200 [kbps]
serviceBFactor
Integer: {0,1,..,30}
10
serviceKFactor
Integer: {0,1,..,30}
Page 79/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

which are valid for the interactive "bronze" service class, i.e. with lowest priority.
Parameter
serviceMinRate
serviceMaxRate
serviceBFactor
serviceKFactor
RAN Path
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Integer: {0,1,..,15}
Customer
Granularity
BTS
3
Object
13
serviceMinRate
Integer: {0,1,..,10000}
10 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
14
serviceKFactor
Integer: {0,1,..,30}

which are valid for the background service class.
Parameter
serviceMinRate
serviceMaxRate
serviceBFactor
serviceKFactor
RAN Path
Translation
Range & Unit
User
Class
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Translation
Range & Unit
Value
Integer: {0,1,..,15}
Customer
Granularity
BTS
3
Object
12
serviceMinRate
Integer: {0,1,..,10000}
0 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
15
serviceKFactor
Integer: {0,1,..,30}
Page 80/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.7 MAC-E NON SCHEDULED MODE

[iCEM] The Mac-e non scheduled mode is not supported by the iCEM.
[xCEM][eCEM] The Mac-e non scheduled mode is supported by the xCEM and eCEM
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
RAN Path
Range &
Unit
User
Class
Value
Parameter
RAN Path
Range &
Unit
User
Class
Value
maxMacePduContentsSizeForNonScheduledModeTti10
Object
EdchParameters
Granularity
UlRbSetConf

[1..1096], integer
Customer
3
162
maxMacePduContentsSizeForNonScheduledModeTti2
Object
EdchParameters
Granularity
UlRbSetConf

[1..1096], integer
Customer
3
162
The non scheduled mode is only used when the SRB over E-DCH is activated (please
refer to section 8 of the current volume).
Page 81/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.8 IUB CONGESTION HANDLING FOR E-DCH
6.8.1 HSUPA PM33332 IUB BANDWIDTH LIMITATION AND

PM33367 CONGESTION DETECTION & NOTIFICATION
In UA6 the feature Iub Bandwidth Limitation for E-DCH (xCEM and iCEM) (PM33332)
is introduced in order to take into account the UL Iub congestion in the E-DCH
scheduler through remote detection by the RNC, and limit the UL radio and HW
resources to the available Iub BW for E-DCH (Iub BW not used by R99 traffic).
With UA7.1.3, this feature is also available with the eCEM.
This feature is not applicable to UCU-III, for which another feature based on local
congestion detection is available (see the next section).
In order to perform this mechanism the congestion status should be known, thus a
direct interaction with feature HSPA congestion detection & notification (PM33367) 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
HSUPA Throughput
RNC
Node B
TNL congestion notification to NodeB
Iub
HSUPA BW limitation by Node B
HSUPA congestion detection by RNC
Figure 9: Iub BW limitation mechanism
This
activated/deactivated at NodeB level

isEdchBandwidthLimitationAllowed under BTSEquipment.
Parameter
RAN Path
Range & Unit
User
Class
Value
feature
can
be
isEdchBandwidthLimitationAllowed
BTSEquipment
False,True
Customer
3
via
the
flag
Object
BTSEquipment
Granularity
BTS
True
Page 82/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The Iub congestion detection and reporting done at the RNC side are common to
xCEM, eCEM and iCEM (same mechanism is used).
The UL Iub congestion is detected by the RNC via UL frame loss detection.
The NB includes a FSN in every E-DCH Data Frame. If FSNn > FSNn-1+1, P frames are
missing and might be lost, but it could also be due to IP de-sequencing issue.
If the parameter DeSequencingWaitTimer is not 0, the RNC starts a timer equal
to DeSequencingWaitTimer, and waits up to its expiry before the MAC-d flow is
marked as congested.
If all the missing frames are received during that interval, the MAC-d flow is NOT
marked as congested, the timer is stopped. In that case, the last received frame is the
new FSNn, and the nominal algorithm is resumed.
Note that only one timer is running; when this timer runs, no frame loss can be
detected for the succeeding frames, this is simpler and it is not felt as a critical issue,
the main point being to avoid wrong frame loss detection.
If at least one frame is missing at the expiry of the timer, then the MAC-d flow is
marked as congested frame loss, the FSNn is assigned with the last received frame,
and the nominal algorithm is resumed.
Figure 10: Uplink Iub Congestion detection: frame loss case
Page 83/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
nFramesBeforeEdchCongestion
Parameter
RAN Path
Range & Unit
User
Class
Value
deSequencingWaitTimer
Object
RNC / RNCEquipment / INode / EM / RncIn / Cm / Edch
0..255
Customer
Granularity
3
Edch
INode
1
Object
0..100
Customer
Granularity
3
Edch
INode
0
However, these two last mentioned parameters, in an IP scenario must have different
values:
Parameter
RAN Path
Range & Unit
User
Class
Value
nFramesBeforeEdchCongestion
Object
0..255
Customer
Granularity
3
Edch
INode
3
This new setting is more appropriate to prevent congestion detection due to packet
loss when IP is used.
Parameter
RAN Path
Range & Unit
User
Class
Value
deSequencingWaitTimer
Object
0..100
Customer
Granularity
3
Edch
INode
10
This new setting is more appropriate in preventing interpreting an IP packet deordering, as a packet loss.
With 10ms TTI, when N succeeding E-DCH UL Data Frames have their successive FSN
Nn = Nn-1+1, the leg is marked as non-congested. N is controlled by the parameter
nFramesBeforeEdchDeCongestion.
With
2ms
TTI
in
non-bundling
mode,
the
algorithm
uses
parameter
nFramesBeforeEdchDeCongestion multiplied by 5.
Page 84/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 11: 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
RAN Path
Range & Unit
User
Class
Value
nFramesBeforeEdchDeCongestion
Object
0..255
Customer
Granularity
3
Edch
INode
50
Again, when in an IP scenario the value for this parameter must change:
Parameter
RAN Path
Range & Unit
User
Class
Value
nFramesBeforeEdchDeCongestion
Object
0..255
Customer
Granularity
3
Edch
INode
10
When an IP network configuration is used, if nFramesBeforeEdchCongestion is
set to 1 (instead of 3), as soon as theres some sporadic packet loss, a very fast
passage to a congestion state will occur without easy ending; also, by leaving
nFramesBeforeEdchDeCongestion to 50 (and not 10), the congestion state will be
very hard to terminate: the impact over the uplink throughput will be considerable.
Page 85/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

6.8.1.1 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
RAN Path
Range & Unit
User
Class
Value
congestionControlPeriod
Object
0..2550 in step of 10ms
Customer
Granularity
3
Edch
INode
40
When a congested Mac-d flow becomes non-congested, the RNC sends one TNL
Congestion indication message with cause No TNL Congestion.
Figure 12: Structure of the TNL Congestion Indication control frame.
6.8.1.2 UL IUB CONGESTION MANAGEMENT IN E-DCH SCHEDULER

Every E-DCH congestion control (ECC) period the NB updates a Global Reduction
Factor (GRF), in %, as follows:
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.
Page 86/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 13: Example of the GRF variation with the congestion status
[xCEM][eCEM] The xCEM or eCEM scheduler computes the target UL load Ltarget as
the minimum value between GRF and other restricting criteria described in the section
6.1
[UCU-III] As already mentioned, this mechanism is not applicable to UCU-III. The
GRF is always 100%.
[iCEM] 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)
The same parameters are applicable for iCEM, xCEM, and eCEM boards and listed
below.
The following parameter is a timer that controls the periodicity where the NodeB
modifies the reduction factor.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchBLSupervisionTimer
BTSEquipment
[10..1000], step: 10ms
Customer
3
Object
BTSEquipment
Granularity
BTS
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.
Page 87/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
edchBLStepReductionFrameLoss
Parameter
RAN Path
Range & Unit
User
Class
Value
edchBLStepIncrease
BTSEquipment
0..100 in %
Customer
3
Object
BTSEquipment
Granularity
BTS
Object
BTSEquipment
Granularity
BTS
BTSEquipment
0..100 in %
Customer
3
1
The operator-dependent parameter edchBLIubBandwidth, corresponds to the
maximum bit rate that is supported in the Iub.
edchBLIubBandwidth
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
[100..200000], step:100 kbps
Customer
3
Object
BTSEquipment
Granularity
BTS
200 000 (default value)
6.8.2 PM75786 iBTS LOCAL E-DCH CONGESTION CONTROL

In UA6 theres another feature (PM75786) 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 or eCEM when the

iBTS detects a loss of AAL2 cells in its uplink buffers
E-DCH throughput will be progressively increased on xCEM or eCEM when the

iBTS did not detect any AAL2 cells lost in its uplink buffers for a minimum period
of time.
Page 88/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Figure 14: Local congestion control mechanism

The feature reacts the following way:
1. Hardware/microcode detects the AAL2 UL overflow
2. Platform software performs fault confirmation (leaky bucket mechanism) and
reports the fault to OAM CCM
3. OAM CCM informs all xCEM or eCEM of AAL2 congestion when activation
parameter edchCMActivation is set to TRUE
4. When xCEM or eCEM manages E-DCH, xCEM or eCEM 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 or eCEM congestion control mechanism for E-DCH.
The local congestion feature (PM75786) uses the same mechanism to control the
congestion than feature PM33332 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 (PM75586) or remotely (PM33367). To do so, the
congestion control mechanism uses the minimum value between:
Load limit (overload): Llimit,ovld
GRF
As a result, features PM33332 and PM75786 can be managed at the same time.
This
feature
can
be
activated/deactivated
using
the
parameter
edchLocalCongestionControlActivation. When set to TRUE, the BTS controls the

E-DCH throughput based on ATM cell that are locally dropped in the BTS. When set to
FALSE, this feature is deactivated.
Page 89/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
edchLocalCongestionControlActivation
BTSEquipment
Customer
3
Object
BTSEquipment
Granularity
BTS
True
Remark: The feature is managed the same way in all cases when user plane for EDCH 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
Restriction: Local Congestion must be disabled on Native IP

Local Congestion was designed to monitor all emission queues, but to always stop Edch data. For
example, if the data in the CS queue Emission Priority 1 (EP1) exceeds the queue's Peak
Information Rate (PIR), Local Congestion will stop UL Edch traffic in EP5. This issue is still present
even for UA7.1.2. This is expected to be corrected in a near release. An alternative for this situation
is using the feature PM33332.
[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 congested state.
Page 90/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.8.3 PM82602/R4 OPTIMIZED IUB CONGESTION CONTROL

6.8.3.1 FEATURE DECRIPTION
6.8.3.1.1 FEATURE OVERVIEW

Without 82602/R4 feature, when the E-DCH overload control mechanism is triggered
in Iub congestion situation, some non-serving users get a non-serving RG DOWN,
meaning that users from another NodeB are reduced although the Iub of their NodeB
maybe not congested. This increases the amount of data sent over Iub and then
increases the congestion.
With 82602/R4 feature, the Iub congestion control is optimized through:
Not sending RG DOWNs to non serving users when the Iub at the NodeB is
congested
Discarding the MAC-es/is PDUs from scheduled MAC-d flows received from
non serving legs
6.8.3.1.2 IUB CONGESTION DETECTION

[UCU-III]
The detection of Iub congestion at NodeB is based on the Iub Overload Control. The
generation of the Iub overload indicator 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.

In
order
to
activate
82602/R4
feature,
the
parameter
useOptimizedEdchIubCongestionControl shall be set to TRUE.
[UCU-III]
Page 91/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Parameter
useOptimizedEdchIubCongestionControl : This parameter enables

disables the optimized Iub congestion control scheme for E-DCH on oneBTS.
useOptimizedEdchIubCongestionControl
Range & Unit False, true

User
Customer
Class
3
Value
True
Object
OneBTSEquipment
Granularity
OneBTSEquipment
or
[xCEM, eCEM]
This feature is not applicable to xCEM and eCEM in UA08.1. It will be supported in a
future release.
Page 92/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
6.9 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.
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: Mechanism 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).
However, a new feature released during UA7.1.2 allows this functionality to be

available. Please refer to the feature PM30742 mentioned below for more details.
6.9.1 PM30742 MBR HANDLING IN THE HSUPA SCHEDULER

The algorithm is implemented at NodeB level.
RNC CallP handles the MBR received in RANAP message and sends it to NodeB in
NBAP messages which then will limit the scheduling grants, not allowing UE data rates
bigger than EDCH MBR. Hence, the UE generated UL data rate shall be limited below
MBR.
Therefore, the EDCH MBR provided by the RNC for PS I/B, is calculated as follows:
EDCH MBR = Min{Max MACesRate, Max UECapabilityRate}

Max UECapabilityRate: Maximum physical data rate given by UE category and applied TTI [kbps]
Max MACesRate = ceil{MACes PDUSize/TTI}
[kbps]
TTI = Transmission Time Interval [ms]
MACes PDU
Size
MBR TTI
= ceil
MACd PDU Size + MACes
RLC PDU Size
HeaderSize
+ SI Size
MBR: Maximum Bit Rate received from RANAP [kbps]

RLC PDUSize: For PS I/B the Packet Data Unit size in the Radio Link Control is 320 [bits]
MACd PDUSize: For PS I/B the Packet Data Unit size in the MACd layer is 336 [bits]
MACesHeaderSize: MACes header size is 18 in case of 1x PS RAB and 36 in case of 2xPS RAB [bits]
Page 93/163
[bits]

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

SISize: The scheduling indicator size will be fixed to 18 [bits]
In case of multi EDCH PS RABs, the MACes PDUSize for each RAB shall be separately taken and
the minimum size taken for calculation of MACesRate
Note: The MBR feature is designed to limit the maximum bit rate on physical layer
without considering the HARQ BLER. So the effective rate is lower than MBR in case of
high BLER on E-DCH, especially in highly loaded cells where nHARQ Retrans Target is
equal to 1.5.
Rule: 10ms TTI must always be used when the requested MBR is equal or
below 384Kbit/s for PS I/B EDCH call:
Tests have shown that traffic cannot be initiated when uplink MBR rate is below 128k
for PS I/B EDCH calls. The adopted solution was to limit the call to 10ms TTI, allowing
this way to go down until an MBR of 32kbit/s. Since the limit of 384kbit/s is in parity
with the max DCH rate and it is possible to be reached with 10ms TTI, this value was
chosen to force the use of 10ms TTI (as soon as the MBR is equal or below 384
kbps).
Theres an activation flag using a class3 parameter with a temporary name. See
below:
Parameter
RAN Path
Range & Unit
User
Class
Value
Enumeration (false, true)
Customer
3
Object
RadioAccessService
Granularity
RNC
True
UA7 UA08 Delta: reserved2.byte3.bit1 is replaced with isEdchMbrInfoToNodebAllowed

In UA7, in order to activate the feature 30742, the reserved2.byte3.bit1 was used (the parameter
configuration would be byte3-byte2-byte1-byte0 and byte3 would be equal to bit7-bit6-bit5-bit4-bit3bit2-bit1-bit0, where bit1 was to be set to 1 for activation).
Now the parameter isEdchMbrInfoToNodebAllowed is used.
[iCEM]
This feature is not applicable to iCEM.
Page 94/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
7 POWER CONTROL FOR E-DCH

7.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.
7.1.1 PRINCIPLE OF E-DCH UL OLPC

This section describes the principle of UL OLPC for E-DCH with Alcatel-Lucent
implementation.
UL OLPC for E-DCH has been first introduced in UA5.1 (34172 E-DPDCH
Retransmissions for DPCCH SIR Adaptation feature).
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 7.1.2.
In UA08.1, the E-DCH UL OLPC is further enhanced through the introduction of the
following new features:
PM121085 (UL Power Saving with EDCH OLPC): the fast decrease
mechanism which was part of PM34249 is improved. Refer to section 7.1.3
for a detailed description of the fast decrease mechanism.
82602/R1 (throughput increase in UE power limitation): this feature

introduces a new mechanism that increases the number of target HARQ
retransmissions for power limited users (i.e. users at cell edge). Refer to
section 7.1.4 for a detailed description of this feature.
82602/R2 (enhanced load criterion for adjusting HARQ retransmissions):

this feature is an enhancement to PM34249 as it introduces a new way of
counting active users. Refer to section 7.1.5 for a detailed description of this
feature.
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 the figure below.
Page 95/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Computation of SIR Target
SIR Target
NodeB 1
(according to all Partial SIR Targets):

If at least 1 Partial SIR Target
increased since previous update:
SIR Tg = max { Partial SIR Targets }
UL OLPC Master
NodeB 2
Partial
SIR Target
Partial
SIR Target
Partial
SIR Target
UL OLPC
Machine
UL OLPC
Machine
UL OLPC
Machine
CRCI of UL
DCH 1
CRCI of UL
DCH 2
(DCH 1)
(DCH 1)
(DCH 2)
(DCH 2)
(E-DCH)
(E-DCH)
Else:
SIR Tg = min { Partial SIR Targets }
Update triggering:
Periodically
On event, i.e. if 1 Partial SIR Tg
increased more than a threshold
since previous update.
From UA5.1 (34172 feature):
N of HARQ
Radio quality on E-DCH taken
Retransmissions IE
as an input for UL OLPC
Computation of Partial SIR Target (E-DCH case):

Update frequency: On reception of Iub E-DCH Data Frame by RNC, i.e. every 10ms or 2ms.
Parameter (UA5.1) or
Parameter
Computation method:
set of parameters (UA6).
Partial SIR Tg (k+1) = Partial SIR Tg (k) + Step . (NHARQ NHARQ Target) From UA6, NHARQ Target
adapts to #active E-DCH
known from
users and UL Radio Load
N of HARQ Retransmissions IE Color.
Figure 15: 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 to 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 based 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
Page 96/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

applied, i.e. it is sent to the NodeBs having a link with the mobile. In the same time,
the UL SIR Target is also communicated to all the UL OLPC Machines present and
used as the initial Partial UL SIR Target for the next UL SIR Target update period.
Regarding the E-DCH transport channel, a dedicated UL OLPC Machine is created, and
its role is again to derive a Partial SIR Target so that the link quality on the E-DCH
channel would converge toward its target link quality if this Partial UL SIR Target were
applied as the UL SIR Target.
The main difference with respect to UL OLPC for DCH transport channels is that, for
the E-DCH channel, the quantity monitored is not the BLER but the number of HARQ
retransmissions instead, and the link quality target is not a target BLER but a target
average number of HARQ retransmissions. This is possible since the information
concerning the number of HARQ retransmissions (for each MAC-e PDU correctly
received or at HARQ failure detection) is sent by the NodeB to the RNC through Iub
FP, via the N of HARQ Retransmissions IE enclosed in E-DCH UL Data Frames.
Remark on usage of SRB TF1x0 for E-DCH calls:

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 led to substantial
degradation of radio quality on E-DCH (i.e. NHARQ measured > NHARQ Target) just after
traffic on E-DCH started again. Indeed, when traffic on E-DCH started again, UL SIR
Target was well below the value required to achieve the target radio quality on EDCH.
For above reasons, effective from UA5.1.0.3, it has been decided to remove SRB
TF1x0 for stand-alone E-DCH calls (i.e. E-DCH + SRB in uplink, no multi-service), and
use instead the usual TF0x148 format. Then, as a consequence, for a stand-alone EDCH call in uplink (i.e. no voice or video telephony in parallel), it is not possible to
monitor continuously the radio quality when there is no activity on E-DCH, which
means that UL SIR Target almost stays at the level it was when activity on E-DCH
stopped. Test showed that this allows improving E-DCH radio quality for the case of
sporadic UL traffic (e.g. UL pings).
Page 97/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PARTIAL UL SIR TARGET COMPUTATION
The Partial UL SIR Target associated to the E-DCH channel is derived within the UL
OLPC Machine associated to the E-DCH channel. Each time the RNC receives an EDCH Data Frame for the user considered (remark: from UA6, since E-DCH SHO is
supported, if UE is in E-DCH SHO then one E-DCH Data Frame among several frames
carrying the same data is selected at RNC), it updates the Partial UL SIR Target
associated to the E-DCH channel of this user, as follows:
Partial UL SIR Target (k+1) =
= Partial UL SIR Target (k) + ulSirStep * (NHARQ - NHARQ Target)
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.
NHARQ: Number of HARQ retransmissions that occurred for a given MAC-e

PDU, as indicated by the N of HARQ Retransmissions IE enclosed in the EDCH Data Frame. If UE is in E-DCH SHO, NHARQ: is the number of HARQ
retransmissions that occurred for a given MAC-e PDU between UE and the
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 [R06] for
detailed information on the different cases of E-DCH HFI) is reported by the
E-DCH Serving NodeB, NHARQ was taken equal to the maximum allowed
number of HARQ retransmissions.
H
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 7.1.2.1.3 for more information on HFI handling in E-DCH UL OLPC.
NHARQ Target: Target average number of HARQ retransmissions, set via

nHarqRetransTargetSx parameters (see section 7.1.2.1.2 for more
information on nHarqRetransTargetSx parameters, which are introduced in
UA6).
Remarks regarding above formula:
In above formula, (NHARQ - NHARQ Target) can be negative, null or positive.
From UA5.0, a Fast Convergence Mechanism has been introduced in the UL

OLPC Machines associated to DCH channels. The aim of this enhancement is to
make faster the convergence of UL SIR Target just after a new UL RB
establishment. This Fast Convergence Mechanism does not apply to the UL
OLPC Machine associated to the E-DCH transport channel, i.e. above formula is
Page 98/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
increased since previous update:
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).
7.1.2 PM34249 EUL CAPACITY OPTIMIZED HARQ OPERATION

7.1.2.1.1 FEATURE AIM AND PRINCIPLE

In UA6, the uplink Outer-Loop Power Control (UL OLPC) for E-DCH is improved by
introducing an adaptive target number of HARQ retransmissions, via UA6 34249 EUL
Capacity Optimized HARQ Operation feature. This mechanism allows adapting the
target number of HARQ retransmissions (NHARQ Target) according to current number
Page 99/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

of E-DCH users and UL radio load. In other words, this mechanism allows adapting
the required Eb/N0 at NodeB to current UL cell load condition, in order to optimize the
usage of UL radio load resource between all users, thus improving E-DCH
performance.
The key enhancements of UA6 34249 with respect to UA5.1 E-DCH UL OLPC (UA5.1
34172 feature) are as follows.
Introduction of an adaptive target number of HARQ retransmissions

(NHARQ Target). NHARQ Target is adapted according to:
o
Current number of active E-DCH users in the cell

(see definition of active E-DCH users below in 7.1.2.1.2)
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 adaptive NHARQ Target, the optimal performances are reached in both cases
(loaded and unloaded cell).
Restriction: [iCEM] Adaptive NHARQ 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, NHARQ Target is not adapted according to current
number of active E-DCH users and UL Radio Load Color. Precisely, adaptive NHARQ Target
mechanism is disabled by always forcing Cell State to S1 (see section 7.1.2.1.2 for details on
adaptive NHARQ 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)
Both TRB and SRB on E-DCH (SRB on E-DCH introduced in UA6)
Page 100/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

o
Both 10ms and 2ms E-DCH TTI (2ms E-DCH TTI introduced in UA6
for the xCEM and eCEM, 2 ms E_DCH TTI introduced in UA7.1 for the
UCU-III)
When in E-DCH SHO, processing of HARQ Failure Indication (HFI)

messages received at RNC into several HFI Reception Scenarios, which
are used for:
o
Correction of Partial SIR Target(s) of E-DCH MAC-d flow(s)
UL/DL Imbalance Detection mechanism:

Counter intended for Engineering teams to detect UL/DL imbalance
issues (not directly related to UL OLPC)
7.1.2.1.2 PARTIAL UL SIR TARGET COMPUTATION

CELL STATE
In order to adapt NHARQ Target value according to current number of E-DCH users and
UL radio load of the considered cell, for each cell, a state (Cell State) specific to UA6
34249 feature is computed and updated. Note that at a given instant, the same NHARQ
Target value is used for all the E-DCH UEs for which the considered cell is the E-DCH
serving cell.
Cell State, which can take three different values S1, S2 and S3, is computed based
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 maxNumActiveEdchUsersPerCellForS1
and
maxNumActiveEdchUsersPerCellForS2
parameters are used to set the thresholds for Cell State change on number of active
E-DCH users criterion.
Page 101/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Number of
active
E-DCH users
S3
S2
S1
0
green
UL Radio
Load Color
yellow
red
Figure 16: Cell State computation

The Partial SIR Target related to the E-DCH transport channel (note: in case of SRB
on E-DCH, there are two Partial SIR Targets related to E-DCH, see below paragraph
SRB ON E-DCH CASE) is computed as it was explained in section 7.1.2.1. With UA6
34249 feature, NHARQ Target, which is used as an input to compute the Partial SIR
Target related to the E-DCH transport channel, can take three different values
depending on the current Cell State:
Cell State = S1 NHARQ Target = nHarqRetransTargetS1

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 7.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.
Page 102/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 8 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 the figure
below.
SIR Target
NodeB 1
UL OLPC Master
NodeB 2
Partial
SIR Target
Partial
SIR Target
UL OLPC
Machine
UL OLPC
Machine
(E-DCH TRB)
(E-DCH SRB)
(E-DCH SRB)
(E-DCH TRB)
N of HARQ
Retransmissions IE
N of HARQ
Retransmissions IE
Figure 17: UL OLPC in case of SRB on E-DCH
Note
that
for
the
case
of
SRB
on
E-DCH,
there
are
two
sets
of
nHarqRetransTargetSx parameters, one for the SRB and one for the TRB MAC-d
flow, thus making it possible to set the target number of HARQ retransmissions NHARQ
Target for each Cell State separately for the SRB and for the TRB MAC-d flow.
It is recommended to set NHARQ Target for the SRB MAC-d flow to the same value for
all Cell States. This value shall ensure a good link quality for the UL SRB: it shall be
chosen so that it gives similar residual RLC Bler as the one of the SRB mapped on UL
DCH. It shall also ensure a proper functioning of the UL OLPC: it must not be too low
in order to avoid the UL SRB to systematically force the UL SIR Target to a high value
that would not be necessarily needed. The UL TRB shall remain the main driver for
the UL OLPC SIR Target convergence (see section 7.1.2.2.3 for more details on this
recommendation).
Page 103/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.1.2.1.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, based 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 [R06]), only the E-DCH serving NodeB can
report HFI messages to the RNC.
The HFI monitoring period is set via edchOlpcSamplingPeriodTti10ms and

edchOlpcSamplingPeriodTti2ms parameters.
During the HFI monitoring period, the following internal counters are
incremented:
Number of HFI frames
Number of valid frames from serving NodeB
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
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
Page 104/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Reception Scenario determination based on Serving Ratio criterion and HFI Ratio
criterion, respectively.
Serving Ratio
edchOlpcServingRatioThreshold
0
HFI 0
HFI 1
HFI 3
HFI 2
HFI Ratio
edchOlpcHfiRatioThreshold
Figure 18: 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.
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 of
the current HFI Reception Scenario.
7.1.2.1.4 UL/DL IMBALANCE DETECTION MECHANISM

UA6 34249 introduces an UL/DL Imbalance Detection mechanism which consists in
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
Page 105/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UL/DL Imbalance Detection mechanism is part of UA6 34249 since its
implementation is partially similar to the implementation of HFI Reception Scenario
detection, but this mechanism is not directly related to UL OLPC.
The principle of this mechanism is as follows.
Each time a consecutive MAC-e PDU is decoded by a non-serving NodeB but not
decoded by the serving NodeB (i.e. if the quality of the E-DCH radio link(s) of the
serving NodeB is poor compared to the quality of the E-DCH radio link(s) of nonserving NodeB(s)), internal counter 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
VS.EdchLinkImbalance counter is relevant only for periods with no congestion

on Iub. Indeed, if one of the Iub interfaces related to a NodeB involved in the EDCH call is congested, the E-DCH Data Frames carried on this Iub interface
cannot arrive in the same timeframe as the E-DCH Data Frames with the same
data carried on other Iub interface(s), so it is not possible to check for radio
UL/DL imbalance at RNC based on the received E-DCH Data Frames. The
congestion status on IUB can be checked with the counters VS.ULCongTimeATM,
VS.ULCongTimeIP, or VS. eDCHBLReductionFactor.
7.1.2.2 PARAMETER SETTINGS AND RECOMMENDATIONS

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
Page 106/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 either of the two following methods.
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 NHARQ Target algorithm:
In order to enable the ability to adapt the target number of HARQ retransmissions
NHARQ Target according to current number of E-DCH users and UL radio load, the
parameters
nHarqRetransTargetS1,
nHarqRetransTargetS2
and
nHarqRetransTargetS1 must be set to different values.
It is recommended to set these parameters so that the following rule is verified:
nHarqRetransTargetS1 nHarqRetransTargetS2
On the other hand, in order to disable the ability to adapt NHARQ Target according to
current number of E-DCH users and UL radio load, the parameters
nHarqRetransTargetS1, nHarqRetransTargetS2 and nHarqRetransTargetS1
must be set to the same value.
7.1.2.2.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, ).
Page 107/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC
RadioAccessService
UlRbSetConf/
UlRbSetConf/
PS_EDCH
PS_EDCH
PS_EDCH_MUX
PS_EDCH_MUX
SRB EDCH
SRB_EDCH
DynamicParameterForEdchTti10ms
ulSirStep
updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepHfi
edchLinkBalanceThreshold
NHarqRetransTarget 3
3 instances :
one instance
per OLS.
ulSirStep
updateThreshold
edchSirStepHfi
NHarqRetransTargetUeCat4 3 nHarqRetransTargetS2
NHarqRetransTargetUeCat6 3 nHarqRetransTargetS1
Figure 19: 34249 RAN model for E-DCH UL RBs
The next figure shows the RAN model for the parameters defined per UL service
(including E-DCH UL services) and for other parameters.
Page 108/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameters defined for E-DCH UL services
Other parameters
(PS_EDCHxSRB_3_4K, PS_EDCHxSRB_EDCH and all

multi-services with E-DCH)
RNC
RNC
RadioAccessService
RadioAccessService
DedicatedConf
EdchRncConf
DedicatedConf
edchOlpcSamplingPeriodTti10ms
PowerConfClass 15
eligibleUeCategoryForSirTargetEdch2ms
EdchCellClass 15
UlUsPowerConf/
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K
initialSirTarget
minSirTarget
maxSirTarget
initialSirTargetHsdpa
minSirTargetHsdpa
maxSirTargetHsdpa
UlUserService/
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
UlOuterLoopPowerCtrl
ulUpdatePeriod
UlUsPowerConfTti2ms
initialSirTargetEdch2ms
minSirTargetEdch2ms
maxSirTargetEdch2ms
Figure 20: 34249 RAN model for E-DCH UL services and misc.
7.1.2.2.3 PARAMETERS DEFINED FOR PS_EDCH AND SRB_EDCH UL RB

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 EDCH is different than the one for DCH.
Page 109/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
ulSirStep
Object
RNC / RadioAccessService / UlRbSetConf / DynamicParameterForEdchTti10ms/
RAN Path
Granularity
Range & Unit
UlRbSetConf
Decimal [0.005 0.300] step: 0.005, dB
User & Class
Customer, 3
Value
For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH:

DynamicParameterForEdchTti10ms: 0.025
DynamicParameterForEdchTti2ms: 0.01
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
RAN Path
Granularity
Range & Unit
UlRbSetConf
Integer [0 255], 0.1dB
User & Class
Customer, 3
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
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
User & Class
Customer, 3
Value
200
Page 110/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

edchSirStepFastDecrease: Step size used for Partial SIR Target update when Fast
Decrease mechanism has been triggered.
Parameter
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
Signed [-0.300 0.000] step 0.005, dB
User & Class
Customer, 3
Value
-0.02
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
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
Integer [0 100], %
User & Class
Customer, 3
Value
[iCEM] 100
[xCEM] [eCEM] [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
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
Integer [0 100], %
User & Class
Customer, 3
Value
[iCEM] 0
[xCEM] [eCEM] [UCU-III] 50
Page 111/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

edchSirStepHfi: Sequence containing the step size values for Partial SIR Target
update each time HFI Reception Scenario is updated. The 3 values of the sequence
correspond to {HFI 1, HFI 2, HFI 3}.
Parameter
edchSirStepHfi
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
List of decimal [0.000 1.000] step 0.005, dB
User & Class
Customer, 3
Value
[iCEM] {0; 0 ;0}

[xCEM] [eCEM] [UCU-III] {0.15; 0.1; 0.2}
{UA6, UA7} UA08.1 Delta: HFI Handling for Global Market

In previous releases, it was recommended to keep the HFI handling deactivated for xCEM and eCEM
because these boards were impacted by an E-DPCCH false detection issue leading to an abnormal
volume of HFI occurrences.
From now this issue is solved, and the HFI handling is recommended to be activated for xCEM and
eCEM, with similar settings as the ones used on UCU-III.
edchOlpcHfiRatioThreshold = 10
edchOlpcServingRatioThreshold = 50
edchSirStepHfi = {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.
Setting edchLinkBalanceThreshold to 1024 disables UL/DL Imbalance Detection
mechanism (i.e. disables VS.EdchLinkImbalance counter).
Parameter
Object
RAN Path

Granularity
UlRbSetConf
Range & Unit
User & Class
Customer, 3
Value
200
Page 112/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

nHarqRetransTargetS1: NHARQ Target (i.e. target number of HARQ retransmissions)
value used for UL OLPC when Cell State = S1. In addition, for SRB on E-DCH case, for
the SRB MAC-d flow, NHARQ Target is always taken equal to nHarqRetransTargetS1
(independently from current Cell State).
Parameter
Object
NHarqRetransTarget
NHarqRetransTarget2msCat4
RAN Path
RNC / RadioAccessService / UlRbSetConf / DynamicParameterForEdchTti10ms /

NHarqRetransTarget
Granularity
UlRbSetConf
Range
Unit
&
Decimal [0.00 12.00], step 0.01 N/A
User
Class
&
Customer, 3
Value
For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget:0.07
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
See the engineering recommendation Adaptive NHARQ below.

For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 2
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:2
Page 113/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

nHarqRetransTargetS2: NHARQ Target value used for UL OLPC when Cell State =
S2.
Parameter
Object
NHarqRetransTarget
RAN Path

NHarqRetransTarget
Granularity
UlRbSetConf
Range & Unit
Decimal [0.00 12.00], step 0.01 N/A
User & Class
Customer, 3
Value
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.25

DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4: 2
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6: 2
Page 114/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

nHarqRetransTargetS3: NHARQ Target value used for UL OLPC when Cell State =
S3.
Parameter
Object
NHarqRetransTarget
RAN Path

NHarqRetransTarget
Granularity
UlRbSetConf
Range & Unit
Decimal [0.00 12.00], step 0.01 N/A
User & Class
Customer, 3
Value
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.85

Engineering Recommendation: PS_EDCH Adaptive NHarq 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, i.e. 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 and eCEM] the full capacity of 10Mbps
offered by the feature 34633 may be restricted due to commercial agreement (Capacity
Licensing).
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.
Page 115/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Rule: nHarqRetransTargetSx
For each E-DCH TTI type, the target average number of HARQ retransmissions NHARQ Target
specified by nHarqRetransTargetSx parameters must be consistent with the maximum
allowed number of HARQ retransmissions set by edchHarqMaxRetransEdchTti10 (for 10ms
E-DCH TTI) and edchHarqMaxRetransEdchTti2 (for 2ms E-DCH TTI): NHARQ 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.
Engineering Recommendation: nHarqRetransTargetSx for SRB on E-DCH case

As explained in 7.1.2.1.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, it is recommended to set NHARQ Target to the 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 = nHarqRetransTargetS2 = nHarqRetransTargetS3 = 2
{UA6, UA7} UA08.1 Delta: nHarqRetransTargetSx for SRB on E-DCH case

In previous releases, it was recommended to set nHarqRetransTargetSx for the SRB on E-DCH to a low
value (e.g 0.04), in order to guarantee good link quality.
This low value is not suitable anymore: it would prevent the UL OLPC working properly by maintaining
the UL SIR Target near its maximum even when the UL TRB does not require it (e.g when UL TRB is
inactive). Higher value for SRB on E-DCH nHarqRetransTargetSx is now considered to be good enough
for the link quality and much better for a proper UL OLPC behavior, helping to better control the Uplink
Load.
So it is possible to define distinct sets of three NHarq 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 NHarq retransmission targets to reach the best performances
Page 116/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.1.2.2.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
RAN Path
RNC / RadioAccessService / UlUserService / UlOuterLoopPowerCtrl
Granularity
UlUserService
Range & Unit
User & Class
Customer, 3
Value
For all UlUserService instances*: True

* Except SRB_CellFACH and TRBxSRB_CellFACH for which UL OLPC does not apply
ulUpdatePeriod: Period between two UL SIR Target periodical updates, in number

of largest TTI (i.e. value is an integer) among the transport channels referenced for
the considered UL service.
Parameter
ulUpdatePeriod
Object
RAN Path
RNC / RadioAccessService / UlUserService / UlOuterLoopPowerCtrl
Granularity
Range & Unit
UlUserService
User & Class
Customer, 3
Value
For UlUserService instances with PS_EDCHxSRB_3_4K: 25

(corresponds to 1s for E-DCH standalone with SRB on UL DCH, since in this case
largest TTI is the SRB TTI (40ms))
For UlUserService/PS_EDCHxSRB_EDCH:
[xCEM] [eCEM] [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
Object
UlUsPowerConf
RAN Path
RNC / RadioAccessService / DedicatedConf / PowerConfClass / UlUsPowerConf
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
For UlUsPowerConf instances with PS_EDCH: refer to the UPUG [R01]
Page 117/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

minSirTarget: Lower bound for UL SIR Target in the UL OLPC algorithm.
Parameter
minSirTarget
Object
UlUsPowerConf
RAN Path
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
maxSirTarget: Upper bound for UL SIR Target in the UL OLPC algorithm.

Parameter
maxSirTarget
Object
UlUsPowerConf
RAN Path
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value

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
RAN Path
RNC / RadioAccessService / DedicatedConf / PowerConfClass
Granularity
Range & Unit
PowerConfClass
BitString
User & Class
Customer, 3
Value
0000000000101010
Page 118/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

initialSirTargetEdch2ms: UL SIR Target used for the initialization of UL OLPC
algorithm, for E-DCH TTI2ms calls eligible to SIR target differentiation between EDCH TTI10ms and TTI2ms (parameter eligibleUeCategoryForSirTargetEdch2ms).
Parameter
initialSirTargetEdch2ms
Object
UlUsPowerConf
RAN Path
RNC / RadioAccessService / DedicatedConf / PowerConfClass / UlUsPowerConf /

UlUsPowerConfTti2ms
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
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
Object
UlUsPowerConf
RAN Path

UlUsPowerConfTti2ms
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value
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
Object
UlUsPowerConf
RAN Path

UlUsPowerConfTti2ms
Granularity
Range & Unit
Signed [-8.2 17.3] step: 0.1, dB
User & Class
Customer, 3
Value

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 119/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: [iCEM] [xCEM] [eCEM] [UCU-III] SIR targets settings
SIR Target parameters initialSirTarget,
initialSirTargetHsdpa, initialSirTargetEdch2ms and maxSirTarget, maxSirTargetHsdpa,
maxSirTargetEdch2ms settings for E-DCH calls.
[iCEM]
[xCEM]
[eCEM]
[UCU-III]
UL
As mentioned in section 5.4, due to specificities in iCEM, xCEM, eCEM 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, eCEM and UCU-III, for E-DCH calls, it is strongly recommended to follow the boardspecific 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/eCEM boards handling HSUPA
calls, use two specific PowerConfClass instances (one for iCEM and one for xCEM/eCEM).
For the PowerConfClass instance related to each type of board (iCEM and xCEM/eCEM, 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.
7.1.2.2.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
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Integer [0 64] N/A
User & Class
Customer, 3
Value
2 (See also the engineering recommendation Adaptive NHARQ)

maxNumActiveEdchUsersPerCellForS2: Maximum number of active E-DCH
users per cell for Cell State = S2.
Parameter
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Integer [0 64] N/A
User & Class
Customer, 3
Value
4 (See also the engineering recommendation Adaptive NHARQ)
Page 120/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
Object
EdchRncConf
RAN Path
RNC / RadioAccessService / EdchRncConf
Granularity
RNC
Range & Unit
Integer [0 500] step: 10, ms
User & Class
Customer, 3
Value
100
edchOlpcSamplingPeriodTti2ms: HFI monitoring period (for 2ms E-DCH TTI

case).
Parameter
Object
EdchRncConf
RAN Path
Granularity
RNC
Range & Unit
Integer [0 500] step: 10, ms
User & Class
Customer, 3
Value
20
7.1.3 PM121085: UL POWER SAVING WITH E-DCH OLPC


PM121085 improves the Fast Decrease mechanism which was part of PM34249 from
UA6.
The initial Fast Decrease mechanism (part of PM34249) doesnt take into account
the inactivity case. Thus, the SIR target for a MAC-d flow remains unchanged when
no MAC-es PDUs are received.
This leads to UL physical control channels like DPCCH and HS-DPCCH getting
transmitted at power levels higher than required and therefore causing UL power
waste.
With PM121085, a new SIR Fast Decrease mechanism will be triggered following a
certain inactivity period.
Inactivity is defined by non reception of MAC-d PDUs for a call, on all the existing
MAC-d flows, including E-DCH, SRB and DCH RABs.
Page 121/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
SIR
Active
user
Inactivity period
before triggering
SIR decrease
Inactive
user
Fast SIR decrease following

inactivity detection period
time
SIR limited to an
optimum value
Figure 21: PM121085 "Fast Decrease" mechanism
7.1.3.1.2 FAST DESCREASE MECHANISM

The UL SIR Target values of all existing MAC-d flows shall be preserved to their latest
values from last activity period before triggering the Fast Decrease process.
Traffic inactivity must persist for a configurable period of time before applying the fast
decreased
power.
This
can
be
configured
using
the
parameter
eDCHOlpcInactivityTimeThreshold.
The decrease of UL SIR Target due to inactivity is limited to an optimum value so that
it does not adversely impact the performance of UL physical control channels. This
can be configured using the parameter eDCHOlpcInactivitySIRDecreaseLimit.
Then, once inactivity is detected, the UL SIR target is set directly to
eDCHOlpcInactivitySIRDecreaseLimit.
Partial_UL_Target_SIR(i) = eDCHOlpcInactivitySIRDecreaseLimit
Finally, the preserved UL SIR Target values of all existing MAC-d flows shall be
restored following detection of activity, i.e. receipt of MAC-d PDUs at RNC on any
MAC-d flow. Initial power (saved right before fast decrease process) is reinstated as
soon as traffic resumes, on any of the RAB.
Page 122/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.1.3.1.3 BEHAVIOUR IN CASE OF IMBALANCE SIR CONDITION
An Enhancement has been introduced to cope with imbalance SIR situation that may
occur in case of lack of macro-diversity for SRB over eDCH due for instance to
limitations imposed by mixity of baseband cards or to mixity of inter-NodeB radio links
where SRB over EDCH could not be configured.
The inactivity mode is de-activated upon detection of imbalance SIR condition and
re-activated once imbalance SIR conditions disappear.
The implementation of the enhancement has been done in 2 steps across releases
with in UA08.1.1.3, a solution with mobility restrictions and from UA08.1.2.1 the
complete solution
With the first step implemented in UA08.1.1.3, the mobility behavior is as following:
In case of Intra-RNC SHO with SRB over EDCH before and after SHO for all
RLs: the Inactivity mode remains active during and after SHO if already
active or can be activated subsequently during the call if conditions meet.
In case of Intra-NodeB Softer HO (SRB is either over EDCH 10ms / 2ms or

DCH before and after SrHO for all RLs): the Inactivity mode remains active
during and after SrHO if already active or can be activated subsequently
during the call if conditions meet.
In case of HHO or Primary Cell Change: the Inactivity mode is deactivated

(pre-saved SIR Target are restored) following reconfiguration but can be
activated during the call if conditions meet.
In case of Intra-RNC SHO with SRB over DCH before and after SHO for all RLs
or SHO from SRB EDCH to SRB R99 or from SHO SRB R99 to SRB EDCH: the
inactivity mode is deactivated after SHO for the rest of the call duration
In case of CAC failure for EDCH 2ms during mobility, iCEM mixity or Inter-RNC
SHO: the inactivity mode is deactivated after SHO for the rest of the call
duration
From UA08.1.2.1, the mobility behavior is as following:
In case of Intra-RNC SHO (SRB is over EDCH 10ms/2ms or DCH before and
after SHO for all RLs): the Inactivity mode can remain active during SHO if
already active or can be activated subsequently during the call if conditions
meet.
In case of Intra-NodeB Softer HO (SRB is either over EDCH 10ms / 2ms or

DCH before and after SrHO for all RLs): the Inactivity mode remains active
during and after SrHO if already active or can be activated subsequently
In case HHO, Primary Cell Change: the Inactivity mode is deactivated (presaved SIR Target are restored) following reconfiguration but can be activated
In case of Intra-RNC SHO from SRB EDCH to SRB R99 or from SHO SRB R99
to SRB EDCH: the Inactivity mode is deactivated after SHO but can be
activated subsequently during the call if conditions meet.
Page 123/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
In case of CAC failure for EDCH 2ms during mobility, iCEM mixity or Inter-RNC
SHO: the Inactivity mode is deactivated after SHO but can be activated
subsequently during the call if conditions meet.

In
order
to
activate
the
feature
PM121085,
isEdchFastSirTargetDecreaseAllowed shall be set to TRUE.
the
parameter
7.1.3.2.2 RAN MODEL

RNC
isEdchFastSirTargetDecreaseAllowed
UlRbSetConf
EdchRncConf
eDCHOlpcInactivityTimeThreshold
eDCHOlpcInactivitySIRDecreaseLimit
DynamicParameterForEdchTti10m
edchNrOfConsecutiveZeroHarqReTxThreshold edchNrOfConsecutiveZeroHarqReTxThreshold
Figure 22: OMC-R model
isEdchFastSirTargetDecreaseAllowed
(RadioAccessService.reserved0.
bit0): Enables/Disables the fast SIR target decrease mechanism. This parameter
is set to False by default.
Parameter eDCHOlpcInactivityTimeThreshold
Range &
False, True
Unit
User
Customer
Class
3
Value
True
Object
EdchRncConf
Granularity RNC
Page 124/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
eDCHOlpcInactivityTimeThreshold (RadioAccessService.reserved0.bit12
bit11.........bit1 ): Defines the time period of simultaneous data inactivity on all
configured DCH / EDCH MAC-d flows required to trigger fast decrease of SIR
Target.
Parameter eDCHOlpcInactivityTimeThreshold
Range &
[0..30] step 0.01, seconds
Unit
User
Customer
Class
3
Value
0.5
Object
EdchRncConf
Granularity RNC
eDCHOlpcInactivitySIRDecreaseLimit
RadioAccessService.reserved0
bit22 bit21.........bit13 : Defines the value of UL SIR Target used by EDCH
OLPC as a result of fast decrease in SIR Target in one step due to simultaneous
inactivity on all DCH / EDCH MAC-d flows exceeding the time threshold. This
parameter is set to 3 by default.
Parameter eDCHOlpcInactivitySIRDecreaseLimit
Range &
[0..10] step 0.1, dB
Unit
User
Customer
Class
3
Value
5
Object
EdchRncConf
Granularity RNC
Engineering Recommendation: eDCHOlpcInactivitySIRDecreaseLimit setting

It is recommended not to set eDCHOlpcInactivitySIRDecreaseLimit lower than the
recommended value. The link may drop in case this parameter is set to a too low value.
A consistency with respect to the minimum and maximum Sir Target settings must also be ensured:
Minimum Sir Target <= edchOlpcInactivitySirDecreaseLimit <= Maximum Sir Target
Note: The minimum and maximum Sir Target are the ones defined by one of the parameters
minSirTarget, minSirTargetHsdpa, minSirTargetEdchTti2ms and maxSirTarget, maxSirTargetHsdpa,
maxSirTargetEdchTti2ms. Refer to [Vol.3] Selection of OLPC UL SIR Target parameters by the
RNC for additional information about which one is used.
Page 125/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
7.1.4 82602/R1: THROUGHPUT INCREASE IN UE POWER

LIMITATION

In UA08.1, the feature 82602/R1 is introduced in order to enhance the throughput for
power limited users (i.e. users at cell edge) through the increase of the default
number of HARQ target transmission to reduce the SIR target and thus enable higher
TFC selection.
Before UA08.1, the increase of the number of HARQ target transmission was already
implemented in loaded situation (PM34249), the enhancement expected from
82602/R1 will apply to users at cell edge in unloaded situation.
7.1.4.1.2 UE POWER LIMITATION DETECTION

Detection of power limited users is done based on the measurement events 6A and 6B
that are configured by RNC.
Event 6A:
The measurement event 6A is triggered when the UE transmit power becomes larger
than an absolute threshold:
P_absolute6A = max(Pmax - ueOffsetFromMaxPwr6A, -50)
Event 6B:
The measurement event 6B is triggered when the UE transmit power becomes less
than an absolute threshold:
P_absolute6B = max(Pmax - ueOffsetFromMaxPwr6B, -50)
Pmax is the UE's maximum power derived from the maximum allowed UE transmit
power by the network (OAM parameter UlUsPowerConf.maxAllowedUlTxPower) and
the UE power class:
Pmax = Min(UlUsPowerConf.maxAllowedUlTxPower, Pmax,UE)
Pmax,UE is the maximum UE power derived from the UE power class and is got from
the IE UE radio access capability /IE RF capability FDD signaled in the RRC
Connection Setup Complete message:
If
If
If
If
UE
UE
UE
UE
power
power
power
power
class
class
class
class
==
==
==
==
1,
2,
3,
4,
Pmax,UE=
Pmax,UE=
Pmax,UE=
Pmax,UE=
33dBm
27dBm
24dBm
21dBm
If measurement event 6A is received: S_POWER_LIMITATION is set to TRUE

Otherwise, if measurement event 6B is received: S_POWER_LIMITATION is set to
FALSE.
Page 126/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE Power
Event 6A and
S_POWER_LIMITATION=TRUE
Pmax
ueOffsetFromMaxPwr6A
P_absolute6A
ueOffsetFromMaxPwr6B
P_absolute6B
Event 6B and S_POWER_LIMITATION=FALSE
Figure 23: UE Power limitation detection
7.1.4.1.3 USER THROUGHPUT MEASUREMENT

At detection of an event 6A, a user throughput ratio is calculated in order to update
the number of target HARQ retransmissions. Calculation of this ratio is performed
following these steps:
-
At each averageWindow, the throughput Ri of logical channel i is determined as

follows:
Ri =
Nbits,
MAC-es/is PDU,i
N bits , MAC es / is PDU ,i

averageWindow
is the number of bits contained in the received MAC-es or MAC-is PDU at
RNC of logical channel i during period averageWindow less the transmission sequence number
(TSN) header and segmentation status (SS) header in case of MAC-is PDU
At each averageWindow the average throughput Rave,i of logical channel i shall be

updated as follows:
Rave,i (n) = f Ri + (1 f ) Rave,i (n 1)
Page 127/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The filter factor f shall be set to OAM parameter filterFactorMacdThr and n denotes
the actual averageWindow interval.
The initial value of Rave,i shall be set to Ri
-
The maximum possible throughput is determined as follows:
Rmax =
TBmax
TTI
TBmax is the maximum number of bits of an E-DCH transport block (this MAC-e/i PDU
size depends on the UE category and the TTI)
-
Finally, the throughput ratio:
rthr =
R
iL
ave ,i
Rmax
L is the set containing all the logical channels of a UE carrying streaming or

interactive/background traffic over E-DCH.
7.1.4.1.4 NUMBER OF TARGET HARQ RETRANSMISSIONS ASSIGNEMENT

If S_POWER_LIMITATION = TRUE, the number of target HARQ retransmissions
MOLPC, target is chosen depending on the actual throughput ratio rthr :
If (rthr <= edchThrRatioForHarqRetransTarget1) AND

edchThrRatioForHarqRetransTarget2 + hyst2_thr_ratio):
(rthr
>
MOLPC,target = max(nHarqRetransPowerLimitTarget1, Last Actual Num HARQ ReTx Target)
Else if (rthr > edchThrRatioForHarqRetransTarget1 + hyst1_thr_ratio):
M OLPC,target = Last Actual Num HARQ ReTx Target
Target)
Else if (rthr <= edchThrRatioForHarqRetransTarget2) :
M OLPC,target = max(nHarqRetransPowerLimitTarget2, Last Actual Num HARQ ReTx
Else do nothing
The Last Actual Num HARQ ReTx Target contains the actual number of target HARQ
transmissions according to the standard OLPC algorithm 34249 "EUL Capacity
Optimized HARQ Operation", driven by the serving cells OLPC state change. The EDCH OLPC algorithm is taking the maximum between 82602 / R1 and 34249.
Page 128/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The hysteresis hyst1_thr_ratio and hyst2_thr_ratio are internal RNC parameters, not
visible by the operator, defined in order to avoid ping-pong effect when the
throughput ratio is very close to the throughputs ratio boundaries
edchThrRatioForHarqRetransTarget1 or edchThrRatioForHarqRetransTarget2.
rthr
100%
M OLPC,target = Last Actual Num HARQ ReTx

Target (34249)
edchThrRatioForHarqRetransTarget1
hyst1_thr_rati
M OLPC,target = max(nHarqRetransPowerLimitTarget1,
Last Actual Num HARQ ReTx Target (34249))
hyst2_thr_rati
M OLPC,target = max(nHarqRetransPowerLimitTarget2,
Last Actual Num HARQ ReTx Target(34249))
0%
Figure 24: Number of Target HARQ retransmissions assignement
Page 129/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary


In
order
to
activate
the
feature
82602/R1,
the
parameter
useOptimizedEdchHarqRetransAtCellEdge shall be set to TRUE.
7.1.4.2.2 RAN MODEL

The figures below shows the RAN model at OMC-R.
RNC
RadioAccessService
EdpchInfoClass
EdpchParameters
filterFactorMacdThr
nHarqRetransPowerLimitTarget1
NodeB
FDDCell
useOptimizedEdchHarqRetransAtCellEdge
Figure 25: OMC-R model (1/2)
Page 130/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC
RadioAccessService
DedicatedConf
filterFactorUeTxPower
UePowerLimitMgtEvent6A
timeToTrigger6A
UePowerLimitMgtEvent6B
timeToTrigger6B
HspaTrafficActivityDetectionConf
averageWindow
Figure 26: OMC-R model (2/2)
Page 131/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
useOptimizedEdchHarqRetransAtCellEdge: enables or disables the increase
of the number of target HARQ transmissions when the E-DCH UE is in power

limitation
Parameter
useOptimizedEdchHarqRetransAtCellEdge
Range & Unit
False, true
User
Customer
Class
Value
True
Granularity
RNC
power. It is used to determine the absolute power for the UE measurement event
6A (absolute power = UEs maximum power - ueOffsetFromMaxPwr6A).
Range & Unit

User
Class
Value
[0..83] dB
Customer
3
5
Object
Granularity
RNC
ueOffsetFromMaxPwr6B : Represents an offset in dB from the UEs maximum

power. It is used to determine the absolute power for the UE measurement event
6B (absolute power = UEs maximum power - ueOffsetFromMaxPwr6B).
Parameter
Range & Unit

User
Class
Value
[0..83] dB
Customer
3
8
FDDCell
ueOffsetFromMaxPwr6A : Represents an offset in dB from the UEs maximum
Parameter
Object
Object
Granularity
RNC
filterFactorMacdThr : Filter factor for the MAC-d throughput which is used to

determine the switching points for the change of the number of target HARQ
retransmissions in case of UE power limitation
Parameter
filterFactorMacdThr
Range & Unit

User
Class
Value
[0..100] %
Customer
3
15
Object
Granularity
EdpchParameters
RNC
Page 132/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

edchThrRatioForHarqRetransTarget1 : Throughput ratio for switching the
number of target HARQ retransmissions to value nHarqRetransPowerLimitTarget1
Parameter
Range & Unit

User
Class
Value
[0..100] %
Customer
3
45 for 10ms TTI UEs, 40 for 2ms TTI Cat4 UEs, 30 for
2ms TTI cat6 UEs
Object
Granularity
EdpchParameters
RNC
edchThrRatioForHarqRetransTarget2 : Throughput ratio for switching the
number of target HARQ retransmissions to value nHarqRetransPowerLimitTarget2.

Parameter
Range & Unit [0..100] %

User
Customer
Class
3
Value
25 for 10ms TTI UEs, 24 for 2ms TTI Cat4 UEs, 17 for
2ms TTI cat6 UEs
Object
Granularity
EdpchParameters
RNC
nHarqRetransPowerLimitTarget1 : Number of target HARQ retransmissions
when the UE is in power limitation and its throughput ratio falls below
edchThrRatioForHarqRetransTarget1.
Parameter
Range & Unit
[0.00..12.00] step 0.01
User
Customer
Class
Value
Object
Granularity
EdpchParameters
RNC
1.2 for 10ms TTI UEs, 1.2 for 2ms TTI Cat4 UEs, 1.3
for 2ms TTI cat6 UEs
nHarqRetransPowerLimitTarget2 : Number of target HARQ retransmissions

when the UE is in power limitation and its throughput ratio falls below
Parameter
Range & Unit

User
Class
Value
[0.00..12.00] step 0.01

Customer
3
2.4 for 10ms TTI UEs, 3.0 for 2ms TTI Cat4 UEs, 3 for
2ms TTI cat6 UEs
Object
Granularity
EdpchParameters
RNC
Page 133/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
timeToTrigger6A: Time-to-trigger value for UE measurement event 6A
Parameter
timeToTrigger6A
Range & Unit

User
Class
Value
0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms
Customer
Granularity RNC
3
120
Object
timeToTrigger6B: Time-to-trigger value for UE measurement event 6B
Parameter
timeToTrigger6B
Range & Unit

User
Class
Value
0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms
Customer
Granularity RNC
3
120
Object
filterFactorUeTxPower: Filter factor for UE internal measurement UE

transmitted Power
Parameter
filterFactorUeTxPower
Range & Unit

User
Class
Value
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19

Customer
3
4
Object
Granularity
RNC
7.1.5 82602/R2: ENHANCED LOAD CRITERION FOR ADJUSTING

HARQ RETRANSMISSIONS

82602/R2 is in fact an enhancement to the feature 34249 EDCH adaptive HARQ
Control. It introduces a new way of counting active users:
Without 82602/R2, a serving E-DCH user is counted as active if he has established an
E-DCH serving radio link and is in CELL_DCH state.
With 82602/R2, a serving E-DCH user is counted as active if he exceeds a certain data
rate.
Page 134/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.1.5.1.2 THROUGHPUT MEASUREMENT
Throughput measurement is done in the U-Plane.
The throughput Rj,i of each MAC-d flow i for each eligible user j (serving E-DCH user
in CELL_DCH) shall be measured over a certain measurement window:
averageWindow.
The measurement throughput values of all MAC-d flows of user j have to be
accumulated as follows:
Rj =
iL j
j ,i
Where Lj is the set containing the MAC-d flows of user j carrying streaming or
interactive/background traffic over E-DCH.
Remarq: The two sub-features 82602/R1 and 82602/R2 setup a single E-DCH
thoughput measurement in the U-Plane which would trigger two separate actions
(verify cell edge throughput crossings in power limited situations for R1 and verify
user activity status for R2). The parameter averageWindow is common to the two
sub-features 82602/R1 and 82602/R2.
7.1.5.1.3 USER ACTIVITY DETECTION

An E-DCH user j is reported as "inactive" when its measured throughput Rj by UPlane falls below OAM parameter thrThresholdForInactiveState for a duration of
timeToTriggerForInactiveState and the user was in "active" state before.
An E-DCH user j is reported as "active" when its measured throughput Rj by U-Plane
rises above OAM parameter thrThresholdForActiveState and the user was in
"inactive" state before.
The initial activity state for an EDCH user is inactive.
7.1.5.2 PARAMETERS SETTING AND RECOMMENDATIONS

In
order
to
activate
the
feature
82602/R2,
the
parameter
useEnhancedUserActivityDetection shall be set to TRUE.
7.1.5.2.2 RAN MODEL

The figure below shows the RAN model at OMC-R:
Page 135/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC
RadioAccessService
DedicatedConf
HspaTrafficActivityDetectionConf
averageWindow
EdchTrafficActivity
thrThresholdForActiveState
thrThresholdForInactiveState
timeToTriggerForInactiveState
NodeB
FDDCell
useEnhancedUserActivityDetection
Figure 27: OMC-R model
Parameter
useEnhancedUserActivityDetection : enables or disables the enhanced

algorithm for detection of active E-DCH users which works on U-Plane data rate
measurements
useEnhancedUserActivityDetection
Range & Unit False, True

User
Customer
Class
3
Value
True
Object
FDDCell
Granularity
RNC
thrThresholdForActiveState : Throughput threshold for counting an E-DCH

user as active. If the measured UE's data rate at MAC-es layer is above this
threshold, then the user is switched to active state (input for feature 34249).
Parameter thrThresholdForActiveState
Range & Unit [0..5440] kbps
User
Customer
Class
3
Value
64
Object
Granularity
EdchTrafficActivity
RNC
Page 136/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Parameter
thrThresholdForInactiveState: Throughput threshold for counting an E-DCH

user as inactive. If the measured UE's data rate at MAC-es layer falls below this
threshold for a duration of timeToTriggerForInactiveState, then the user is
switched to inactive state (input for feature 34249).
thrThresholdForInactiveState
Object
Range & Unit [0..5440] kbps

User
Customer
Class
3
Value
32
Granularity
EdchTrafficActivity
RNC
Note: With these thresholds for active and inactive states, a UE doing HTTP DL is
counted as inactive in UL. (UL carries only the http requests and the TCP ACKs for
the DL data).
Parameter
averageWindow: Common average window size to be used in both E-DCH and

HS-DSCH traffic detection, for both inactivity/activity detection trigger. Also used
for throughput calculation in sub-feature R1 of feature 82602.
averageWindow
Object HspaTrafficActivityDetectionConf
Range & Unit [100...1000], step 10, ms

User
Customer
Granularity
Class
3
Value
300
Parameter
RNC
timeToTriggerForInactiveState: Time-to-trigger value before going to inactive

state. If the measured UE's data rate at MAC-es layer falls below
thrThresholdForInactiveState for this duration, then the user is switched to
inactive state.
The internal algorithm is actually counting the number of windows for which the
user is inactive as floor (timeToTriggerForInactiveState / averageWindow).
timeToTriggerForInactiveState
Range & Unit [400...5000], step 200 ms

User
Customer
Class
3
Value
1000
Object
Granularity
EdchTrafficActivity
RNC
Page 137/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
7.2 POWER CONTROL OF E-DCH DL CHANNELS

7.2.1 PM33481 E-DCH DL CONTROL CHANNELS POWER CONTROL
7.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, eCEM 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
the sections below are described the mechanism and parameters of 33481.

As a reminder, this section and the following one only apply to xCEM, eCEM and UCUIII.
E-AGCH
Power control of E-AGCH channel is enabled and derived within the NodeB according
to the following formula.
PE AGCH (k ) = PEDCH ( k ) + POE AGCH

With:
k: Time (2ms sub-frame index)
PE AGCH(k): Power allocated to the considered E-AGCH channel
PE DCH(k): E-DCH DL channels base power. This is a unique power value derived
within the xCEM, eCEM 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).
POE AGCH : Power offset of E-AGCH relative to E-DCH DL channels base power. Can
be set to the desired value via eagchPowerOffset under EdchConf (See
section 7.2.1.3.2 for a detailed description of this parameter).
Page 138/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
PEHICH signature (k ) = PEDCH (k ) + PO EHICH signature

With:
PE HICH signature(k): Power allocated to the E-HICH signature of considered user
POE-HICH signature : Power offset of E-HICH signature relative to E-DCH DL channels

base power. Can be set to the desired value via minPowerCorrection under
EdchConf (See section 7.2.1.3 for a detailed description of this parameter).
E-RGCH
Power control of E-RGCH channel is enabled and derived within the NodeB according
to the following formula.
PERGCH signature (k ) = PEHICH signature (k ) + POERGCH / EHICH

With:
PE RGCH signature(k): Power allocated to the E-RGCH signature of considered user
PE HICH signature(k): Power allocated to the E-HICH signature of considered user,

computed as explained above.
POE-RGCH
/ E-HICH:
Power offset of E-RGCH signature relative to E-HICH signature

power. Can be set to the desired value via PowerOffsetErgchServingNoSho
under EdchConf (See section 7.2.1.3 for a detailed description of this
parameter).
COMPUTATION OF E-DCH DL CHANNELS BASE POWER PE DCH(k)

E-DCH DL channels base power PE DCH(k), which is used as a base for derivation of EAGCH power, may be derived according to three different methods or a combination
of these methods. The three methods for the computation of E-DCH DL channels base
power are:
Method based on DL DPCH channel power:
PE DCH(k) is derived by adding an offset* to the power of the DL DPCH channel of

the considered user.
Method based on DL Inner-Loop Power Control (ILPC) commands:
PE DCH(k) is derived by starting from a given initial power Pinit E DCH which is then
updated according to the DL ILPC commands received from the considered
mobile. An offset* is also applied.
Page 139/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Method based on received CQI
PE
DCH(k) is derived based 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 the three methods above, the applied offset may be updated over time in
order to ensure that some long term statistics are taken into account, thus
improving the accuracy of PE DCH(k).
The selection of one (or a combination) of the above 3 methods for computing the EDCH DL channels base power PE DCH(k) is tunable via NodeB parameters not accessible
to the customer.
[xCEM] [eCEM]: 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 and eCEM 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 (hard-coded) power offset is applied on top of the EDCH DL channels power, in order to increase the Tx Power in case of 2ms.
Introduction
of
E-HICH
Outer-Loop
correction
mechanism:
(not used in final implementation). A correction on top of PE 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, because
CQI based algorithm or DL DPCH transmit power based algorithm provide good
enough power levels, making this correction mechanism useless.
Page 140/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.2.1.3.1 RAN MODEL

All parameters below are xCEM, eCEM or UCU-III specific (i.e. not used by iCEM).
BTSEquipment
BTSCell 012
EdchConf 00
pMinDlEDCH
pMaxDlEDCH
eagchPowerOffset
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset
OneBTSEquipment
pMinDlEDCH
pMaxDlEDCH
eagchPowerOffset
minPowerCorrection
maxPowerCorrection
deltaDownServingCellNoHO
Remark: powerOffsetERGCHServingSHO parameter is also present in RAN Model (under

EdchConf and under OneBTSEquipment). However, this parameter is ignored by the system.
pMinDlEDCH:
Power Control of E-DCH DL channels enabled:
Lower bound for E-DCH DL channels base power PE DCH(k). Value is relative to CPICH
Tx power.
Power Control of E-DCH DL channels disabled (not applicable to UCU-III):
Power offset of E-HICH signature at serving NodeB, relative to CPICH Tx power.
Page 141/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
pMinDlEDCH
Object
[xCEM] [eCEM] EdchConf

[UCU-III] OneBTSEquipment
RAN Path
[xCEM][eCEM] BTSEquipment / BTSCell / EdchConf

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-35.0 15.0] step 0.1, dB
User & Class
Customer, 3
Value
[xCEM] [eCEM] -25.0

[UCU-III] -22
pMaxDlEDCH: Upper bound for E-DCH DL channels base power PE DCH(k). Value is
relative to CPICH Tx power.
Parameter
pMaxDlEDCH
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-35.0 15.0] step 0.1, dB
User & Class
Customer, 3
Value
[xCEM] [eCEM] -15.0

[UCU-III] -1
eagchPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to E-DCH DL channels base power PE DCH(k).
Power Control of E-DCH DL channels disabled (not applicable to UCU-III):
Power offset of E-AGCH relative to CPICH Tx power.
Page 142/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
eagchPowerOffset
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-45.0 65.0] step 0.1, dB
User & Class
Customer, 3
Value
[xCEM] [eCEM]
Power Control of E-DCH DL channels enabled: 10.0
Power Control of E-DCH DL channels disabled: -4.0
[UCU-III]
7
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
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-12.8 12.7] step 0.1, dB
User & Class
Customer, 3
Value
1.5
Page 143/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

ehichErrorProbability: Target E-HICH error rate in E-HICH Outer-Loop correction
mechanism.
Parameter
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Integer [1 255], 0.1%
User & Class
Customer, 3
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 PE-DCH (k). Also
used when the E-HICH Outer-Loop correction is deactivated, as a fixed offset with
respect to the E-DCH DL channels base power PE-DCH (k).
Parameter
minPowerCorrection
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-12.8 12.7] step 0.1, dB
User & Class
Customer, 3
Value
[xCEM] [eCEM] 0.0

[UCU-III] 3.0
maxPowerCorrection: In E-HICH Outer-Loop correction mechanism, maximum

correction that can be applied to E-DCH DL channels base power PE-DCH (k).
Parameter
maxPowerCorrection
Object

RAN Path

Granularity
[xCEM][eCEM] Cell
[UCU-III] OneBTS
Range & Unit
Signed [-12.8 12.7] step 0.1, dB
User & Class
Customer, 3
Value
[xCEM] [eCEM] 0.0

[UCU-III] 3.0
Remarks: Current recommendation is to disable E-HICH Outer-Loop correction
mechanism by setting minPowerCorrection = maxPowerCorrection.
Page 144/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

deltaDownServingCellNoHO (UCU-III only): If a ACK was sent on E-HICH and the
next associated UL block is a fresh transmission, then the E-HICH was received
correctly and the correction value is decreased by this value.
Parameter
deltaDownServingCellNoHO
Object
OneBTSEquipment
RAN Path
OneBTSEquipment
Granularity
OneBTS
Range & Unit
Integer [1 1000], 0.01dB
User & Class
Customer, 3
Value
20 (corresponds to 0.2dB)
eagchPowerControlModeXcem: Flag enabling Power Control for all E-DCH DL

channels, at cell level. Applicable for xCEM and eCEM. Reminder: for UCU-III, the EDCH DL channels power control is activated by default.
Parameter
Object
EdchConf
RAN Path
Granularity
Cell
Range & Unit
Boolean {Fixed, Dynamic}, N/A
User & Class
Customer, 3
Value
Dynamic
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
RAN Path
Granularity
RNC
Range & Unit
User & Class
Customer, 3
Value
True
Page 145/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
4.00
Parameter
eagchPowerOffsetEdchTti2ms
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
4.00
Parameter
ergchPowerOffset
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
-4.00
Parameter
ergchPowerOffsetEdchTti2ms
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
-4.00
Page 146/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
ehichPowerOffset
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
-4.00
Parameter
ehichPowerOffsetEdchTti2ms
Object
EdchCellClass
RAN Path
Granularity
EdchCellClass
Range & Unit
Signed [-32.00 31.75] step: 0.25, dB
User & Class
Customer, 3
Value
-4.00
7.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 nonserving NodeB(s) ), E-HICH signature power is fixed to a unique value by
ehichPowerSignature under EdchConf.
Remark on E-RGCH signature power for iCEM:
For E-DCH non-serving RLs of non-serving NodeB(s), E-RGCH signature power is fixed
to a unique value by ergchPowerSignature under EdchConf.
Remark on E-HICH and E-RGCH power for the serving NodeB:
It is not possible to set E-HICH (E-RGCH) power to a given value (e.g. 0) for E-DCH
non-serving RLs of the serving NodeB. Indeed, for a given user, E-HICH (E-RGCH)
signature for E-DCH non-serving RLs of serving NodeB is transmitted with the same
power as E-HICH (E-RGCH) signature for the E-DCH serving RL.
Page 147/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
8 SRB ON HSPA DURING CALL

8.1 PM33581 SRB ON E-DCH
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 (25.213 Table 0) mandate that in order to
use 2SF2 + 2SF4 in uplink, there should be no UL DPDCH used simultaneously.
Therefore, SRB shall be mapped to E-DCH and not to DCH, so that the 2SF2+2SF4
configuration is possible and the UE could reach high rate in the uplink.
Furthermore, to reach this bit-rate, 2 ms TTI on E-DCH is necessary. For the iBTS,
SRB will be mapped on E-DCH only if the 2 ms TTI is usable.
This feature is only supported by xCEM, eCEM and UCU-III.
Before activating SRB on E-DCH an important rule must be respected, otherwise
accessibility and retainability issues may occur:
Rule: SRB on EDCH and Macro Diversity interaction
The SRB on EDCH should be activated with PM32076 Macro Diversity feature. The benefit of macrodiversity is to provide a good UL quality in case of unbalance between UL and DL. This attribute is
essential for a good performance of the SRB when mapped over EDCH.
[UCU-III]
It is 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
L2 - Trsp
DCH-FP
HS-DSCH FP
E-DCH FP E-DCH FP
L1
DPCCH/DPDCH
HS-SCCH
HS-PDSCH
E-DPCCH
E-DPDCH
E-HICH DPCCH HS-DPCCH
SRB
TRB
In order to achieve right DL inner loop power control algorithm, the SRB DCH is used.
In order to achieve right UL inner loop power control algorithm, UL DPCCH is used.
In order to achieve right UL outer loop power control, feature PM 34249 EUL Capacity
Optimized HARQ Operation is needed.
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.
Page 148/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Another important information concerns the utilization of SRB on EDCH over Iur,
where some limitations occur (see restriction box below).
Refer also to [Vol.5] Enhancement 367062 and [Vol.6] E-DCH over Iur IOT, for
additional information on the handling of an EDCH call when one leg is over IUR.
Restriction: SRB on EDCH over Iur
SRB over E-DCH FP is not supported 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 EDCH. Refer to [Vol.6] for the description of the feature 30744.
Parameters:
First, the feature flag activation.
Parameter
RAN Path
Range &
Unit
User
Class
Value
isSrbOnEdchAllowedWhenTrbOnEdch
Object
RadioAccessService
Granularity
RNC
TRUE/FALSE None
Customer
3-a2
True
srbSpi
Parameter
RAN Path
RNC / RadioAccessService / SrbQos
Range & Unit
Integer [0..15]
User
Class
Value
Customer
3-a2
15
Object
srbQos
Granularity
RNC
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.
Page 149/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

o True: All NodeB minSF
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
RAN Path
isSrbOnEdchForAllEdchCategory
Range & Unit
Boolean
User
Class
Value
Object
RadioAccessService
Customer
3-a2
[xCEM] [eCEM] False
[UCU-III] True
Granularity
RNC
Parameter
RAN Path
isSrbOnEdchForAllMinSf
Object
RadioAccessService
Range & Unit
Boolean
User
Class
Value
Customer
3-a2
[xCEM] [eCEM] False
[UCU-III] True
Granularity
RNC
Parameter
RAN Path
isSrbOnEdchForAllEdchTti
Object
RadioAccessService
Range & Unit
Boolean
User
Class
Value
Customer
3-a2
[xCEM] [eCEM] False
[UCU-III] True
Granularity
RNC
Page 150/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 [R08] E-DCH configuration is selected, chapter 6.10.2.4.6.2.1.1.1.2, MACd flow#2 parameters for UL: [max bit rate depending on UE category and TTI] SRBs
for E-DCH
Higher layer
RLC
MAC
Layer 1
NOTE:
RAB/Signaling RB
SRB #1
SRB #2
SRB #3
Logical channel type
DCCH
DCCH
DCCH
RLC mode
UM
AM
AM
Payload sizes, bit
136
128
128
Max data rate, bps
Depends on UE category and TTI
AMD PDU header, bit
8
16
16
MAC-es multiplexing
4 logical channel multiplexing
MAC-d PDU size, bit
144
MAC-e/es header fixed 18
part, bit
TrCH type
E-DCH
TTI
10 ms (alt. 2 ms) (NOTE)
Coding type
TC
CRC, bit
24
The support of 2 ms TTI depends on the UE category.
The SRB will be mapped on E-DCH using the non-schedule traffic.
SRB #4
DCCH
AM
128
16
The following system restrictions are presented:
Restriction:
Nevertheless, facing iBTS limitation on iCEM, parameter isSrbOnEdchForAllEdchTti shall never be
set to 1 if there is at least one iCEM on a NodeB where E-DCH is activated.
Page 151/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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] [eCEM]
Model Configuration
Value
Meaning
isSrbOnEdchForAllEdchCategory False Cat 6 UE only
False 2 SF2 + 2 SF4 minSF only
False 2 ms TTI only and 2 ms supported on NodeB
US Market [UCU-III]
Model Configuration
Value
Meaning
isSrbOnEdchForAllEdchCategory True All UE Categories
True Whatever minSF
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.
8.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/E-DCH +
2 TRB PS on HSDPA/E-DCH (feature 34018 / 116250)
SRB on FACH + TRB PS on FACH ==> SRB on DCH/E-DCH + 2 TRB PS on
HSDPA/E-DCH (feature 34018 / 116250)
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
Page 152/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RAB setup through incoming relocation:
Incoming relocation ==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH
Macro Diversity for Uplink SRB as a criterion for selection of SRB over
EDCH:
The above transitions specify the basic rules followed by the RNC in order to setup the
SRB over EDCH or over DCH at RAB assignment. In addition, the RNC also evaluates
the Macro-Diversity status for the uplink SRB and it favours the configuration (either
SRB over E-DCH or SRB over DCH) which allows the Uplink SRB to benefit from
macro-diversity gain.
Example:
SRB on DCH/DCH on several cells; some cells not 2ms capable <==> SRB on DCH/
DCH + TRB PS on HSDPA/E-DCH (2ms)
Refer to the section Reconfiguration SRB E-DCH to DCH 3.4kbps in [Vol.6] and to
the section EDCH Call Management summary in [Vol.5] of this document for more
details.
8.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] (the new primary cell is only 10ms capable).
TRB PS on HSDPA/DCH [GM] (the new primary cell is only HSDPA/DCH capable).
TRB PS on DCH/DCH [GM] (the new primary cell is only DCH/DCH capable).
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (10 ms) <==> SRB on DCH/DCH
+ TRB PS on HSDPA/DCH [US] (the new primary cell is only HSDPA/DCH capable).
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (10 ms) <==> SRB on DCH/DCH
+ TRB PS on DCH/DCH [US] (the new primary cell is only DCH/DCH capable).
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH (2 ms) <==> SRB on DCH/E-DCH
+ TRB PS on HSDPA/E-DCH (10 ms) [US] (the new primary cell is only 10ms
capable).
TRB PS on HSDPA/DCH [US] (the new primary cell is only HSDPA/DCH capable).
TRB PS on DCH/DCH [US] (the new primary cell is only DCH/DCH capable).
Page 153/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Macro Diversity for Uplink SRB as a criterion for selection of SRB over
EDCH:
The above transitions specify the basic rules followed by the RNC to setup the SRB
over EDCH or over DCH at new primary cell selection.
Moreover, when a non-serving cell is added, the RNC evaluates the Macro-Diversity
status for the uplink SRB and it may decide to reconfigure the SRB from EDCH to DCH
in case this helps keeping macro-diversity gain for the uplink SRB.
Refer to the section Reconfiguration SRB E-DCH to DCH 3.4kbps in [Vol.6] and to
the section EDCH Call Management summary in [Vol.5] of this document for more
details.
8.4 RATE ADAPTATION

SRB configurations are not eligible to rate adaptation. E-DCH configurations are only
eligible to Always-On
SRB on E-DCH can be a target configuration when the call is coming from
CELL/URA_PCH or CELL_FACH state:
The transitions shall be considered in the two ways. These are:
SRB on CELL_FACH + TRB on CELL_FACH <==> SRB on DCH/E-DCH + TRB PS on
HSDPA/E-DCH (2 ms) [GM]
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/EDCH (2 ms) [GM]
HSDPA/E-DCH (10 ms) [US]
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/EDCH (10 ms) [US]
HSDPA/E-DCH (2 ms) [US]
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/EDCH (2 ms) [US]
8.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.
Page 154/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 and eCEM 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
(or eCEM). The DCH SRB part is currently handled by the iCEM board and the
traffic TRB is currently handled by the xCEM (or eCEM). Upon whatever event,
the RNC decides to reconfigure the call with SRB on E-DCH and TRB on EDCH & 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 refused unidirectional DCH
due to a non supported configuration, that would probably end in a call drop. This is
applicable for iCEM.
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 (or eCEM) 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
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 [R05].
Page 155/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Nmax-dpdch
(as defined in subclause 4.2.1)
0
1
2,4,6
3,5
Channelisation code chs

C ch,256,33
Cch,256,64
Cch,256,1
Cch,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:
Paramete
r
RAN Path
Range &
Unit
User
Class
Value
cacTransportInfoList[].cacTransportInfoInstanceC
haracteristic
Object
CacTransportInfoLis
t
RNC / RadioAccessService / UlRbSetConf / CacTransportInfoList

AMR_12_2(0), AMR_10_2(1), AMR_7_95(2), AMR_7_4(3), AMR_6_7(4), AMR_5_9(5),
AMR_5_15(6), AMR_4_75(7), INTERACTIVE_1ST_THP(8), INTERACTIVE_2ND_THP(9),
INTERACTIVE_3RD_THP(10), INTERACTIVE_THP_UNSPECIFIED(11), BACKGROUND(12),
SRB_ON_HSPA(13), SRB_ON_DCH(14), UNSPECIFIED(15)
Customer
Granularity UlRbSetConf
3-a2
Refer to PM 34202 & PM 33579
8.6 PM125855 E-DCH CALL RETAINABILITY IMPROVEMENT

PM125855 is introduced to prevent CS retainability degradation when PS RAB is on EDCH 2ms TTI and SRB over E-DCH and also to minimize performance degradion for
PS only RAB when it is on 2ms TTI and SRB over EDCH in a poor radio condition or a
cell is overloaded. This feature has three requirements (sub-features):
R1: using 10ms TTI for CS + EDCH RAB combination
R2: using 10MS TTI and SRB over DCH in poor radio condition
R3: using 10MS TTI and SRB over DCH in high UL radio cell load
8.6.1 R1: USING 10 MS TTI FOR CS+EDCH COMBINATION

PM125855 R1 is introduced to minimize the risk on CS call drop due to E-DCH 2ms
TTI and SRB over E-DCH. When receiving a RAB Assignment Request for new PS
RAB(s), if a CS RAB is already set up, the RNC shall select 10 ms TTI if setting up EDCH. When receiving a RAB Assignment Request for a new CS RAB, if PS RAB(s) is
already set up on E-DCH using 2ms TTI, the RNC shall reconfigure E-DCH to use 10
ms TTI. Similarly, when a CS RAB is established from Cell_FACH state, or PS traffic is
resumed from PS0/0 + CS, RNC shall select 10ms TTI for E-DCH.
As long as a CS+PS RAB combination exists, the TTI shall remain 10 ms. This includes
during the handover or relocation procedure. If the CS RAB is removed, the
remaining PS RAB(s) is reconfigured to 2 ms TTI if no other constrains forbid it.
Page 156/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameters:
Parameter
RAN Path
Description
Range & Unit
multiRabSmartEdchResourceUsageActivation
Object
EdchRncConf
RNC / RadioAccessService/EdchRncConf
Enables multi RAB sub feature of the Smart phone EDCH resource usage feature.
In UA08, a reserved bit is used for this flag: RadioAccessService.reserved1 bit22.
TRUE/FALSE
Customer
3
Parameter
Description
multiRabSmartEdchResourceUsageActivation Object
FDDCell
Enables multi RAB sub feature of the Smart phone EDCH resource usage feature at
cell level.
In UA08, a reserved bit is used for this flag: FDDCell.reserved0 bit8.
TRUE/FALSE
True
Range & Unit

User
Class
Value
Customer
3
Granularity
Cell
True
Parameter
Description
Range & Unit
User
Class
Value
Granularity
RNC
User
Class
Value
multiRabSmartEDCHResourceUsageActivation Object
RemoteFDDCell
cell level.
In UA08, a reserved bit is used for this flag: RemoteFDDCell.reserved0 bit8.
TRUE/FALSE
Customer
3
Granularity
Cell
True
8.6.2 R2: USING 10MS TTI AND SRB ON DCH IN POOR RADIO
CONDITION
The object of this sub-feature is to prevent EDCH calls from dropping in poor RF
conditions. The basic idea is to avoid E-DCH drop by selecting 10ms TTI for E-DCH PS
RAB and SRB on DCH if the RF condition is poor, which is defined by recent RACH
measurement
result
of
CPICH
Ec/N0
value
being
less
than
poorPsEcNoThresholdForTtiSelection.
This value is reported from UE in IE Measured Results on RACH in the several RRC
messages: RRC Connection Request, Direct Transfer, Measurement report, and Cell
update. RNC uses the value of serving cell (or target serving cell in handover cases)
to decide the RF condition in the following cases:
Establish new PS RAB(s) and UE is in SRB DCH state without a CS RAB.
Direct transition from PCH to DCH state with PS only RAB combination becase
of either AO upsize due to activity resume or a new PS RAB need to be
added.
Change of primary cell of E-DCH RAB
Page 157/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Radio Bearer Reestablishment (RRE) procedure of the EDCH RAB
hard handover of the EDCH RAB
If the RF condition is poor on serving or target cell, RNC select 10ms TTI for E-DCH
PS RAB and SRB over DCH.
Parameters:
The feature activation flags.
Parameter
RAN Path
Description
Range & Unit
PSRabBadRadioSmartEdchResourceUsageActivation
Enables single PS RAB or multi PS RAB bad radio conditions sub feature of the Smart
phone EDCH resource usage feature.
In UA08, a reserved bit is used for this flag: RadioAccessService.reserved1 bit23.
TRUE/FALSE
Customer
3
Parameter
Description
User
Class
Value
EdchRncConf
RNC / RadioAccessService/EdchRncConf
User
Class
Value
Range & Unit
Object
Granula
rity
RNC
True
Object
FDDCell
cell levele.
In UA08, a reserved bit is used for this flag: FDDCell.reserved0 bit9.
TRUE/FALSE
Customer
3
Granularit
y
Cell
True
Following is the threshold RNC uses to decide if UE is in poor radio condition. Note
RNC internally uses formula (value - 240) / 10 to convert the setting to db. For
example, the value should set to 110 for a value of -13 db.
Parameter
RAN Path
poorEcNoThresholdForTtiSelection
Object
EdchRncSmartphoneConf
RNC / RadioAccessService / EdchRncConf / EdchRncSmartphoneConf
Description
Threshold for RNC to decide if UE is in bad radio condition.

In UA08, a reserved bit is used for this flag: RadioAccessService -> reserved1 bit
[15..8].
[-24.0..0.0] step:0.1 dB
Range & Unit

User
Class
Value
Customer
3
Granularity
RNC
-13 db
Page 158/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
8.6.3 R3: USING 10MS TTI AND SRB ON DCH IN HIGH UL RADIO
CELL LOAD
This sub-feature introduces a new E-DCH 2ms CAC algorithm, which takes into
account of two criteria: cell UL radio cell color and the number of active E-DCH users
in the cell.
IF ( UL radio cell Color >= maxColorForCac2ms ) &&

(the
number
of
Active
maxNumActiveUsersForCac2ms)
E-DCH
users
in
the
cell
>
Select SRBonDCH and EDCH_10ms TTI

ELSE
Continue with current E-DCH SRB/TTI selection algorithm
ENDIF
RNC determines the UL radio cell color based on existing criteria of non-EDCH UL
RSSI value reported from NodeB in common measurement report. The UL radio cell
color is only the DCH color, regardless of RSEPS (Received Scheduled E-DCH Power
Share, iBTS only) activated or not. To activate the calculation of the cell color based
on
the
UL
radio
load,
both
isUplinkRadioLoadEnabled
and
isUlRadioLoadColourEnabled need to be set to TRUE.The number of active E-DCH
users are managed by PM82602 R2 (based on MAC-es PDU throughput). It requires
that useEnhancedUserActivityDetection be set to true (enable 82602 R2).
This algorithm is evaluated whenever TTI and SRB re-evaluation is triggered.
E-DCH PS call setup
AO upsize from PCH or FACH to DCH state
Mobility cases: PRL, HHO, SRNS Relocation
PS RAB addition or release
CS RAB release
Post ASU reconfiguration
Page 159/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameters:
Parameter
maxColorForCac2ms
Description
This parameter defines the Maximum UL Radio load color for accepting new 2ms TTI
E-DCH PS RAB in CAC algorithm (in addition with the control of number of current
active E-DCH users)
In UA08, reserved value is used: FDDCell.reserved5 bits [24,25]
{anyColor(0), yellow(1), red(2), black(3)}
Range & Unit
0:
1:
2:
3:
Object
FDDCell.edchResource
any UL load color checking for EDCH CAC algo1

apply 125855 R3 >= "YELLOW" (YELLOW, RED or BLACK colors)
apply 125855 R3 >= "RED" (RED or BLACK colors)
apply 125855 R3 = "BLACK"
The value anyColor is used to bypass the UL radio load color condition (considering
only the number of active EDCH users).
User
Class
Value
Parameter
Description
Range & Unit
User
Class
Value
Customer
3
Granularity
Cell
red(2)
maxNumActiveUsersForCac2ms
Object
FDDCell.edchResource
This parameter defines the Maximum number of current active E-DCH users for
accepting new 2ms TTI E-DCH PS RAB in CAC algorithm (in addition with the UL radio
load color criterium).
In UA08, reserved bits are used: FDDCell.reserved5 bits [23..16]
[0..128] INTEGER
'0 will be used as a specific value to disable this part of algorithm (bypass checking
E-DCH active user number). 128 disables 125855 R3, i.e., bypass both UL radio load
checking and active user number checking.
Customer
Granularity Cell
3
0 (== disabled)
Page 160/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9 PM34393 ADVANCED RECEIVER FOR HIGH UL

DATA RATE
9.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 (GRAKE)
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
(vehicular) and PB3 (pedestrian) 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.
UA7.1 - UA7.1.2 Delta: GRAKE performance

In UA7.1, due to risk of large performance regression (namely throughput degradation) for E-DCH high
mobility users (>15km/h speed), it was not recommended to enable this feature until UA7.1.2. With
the arriving of the UA7.1.2 release, a fix has been introduced, whereby channel element module is able
to measure the speed of the UE through Doppler shift and hence not assign GRAKE for users moving
faster than 15km/h. This speed limit has been determined by means of empirical measurements and
simulations
Rule: GRAKE allocation/de-allocation

In order to have GRAKE allocated, its essential to fulfill the 15km/h criterion and to have a MAC-e
throughput superior to 2Mbps (cat5 UE will have no gain); also to be able to profit from GRAKE, only
the users under the ideal dispersive scenarios (mainly VA3 and PB3) will be chosen.
9.2 DESCRIPTION (GAIN, INTERACTIONS)

This feature is expected to provide most gain when deployed with 16-QAM capability
for HSUPA. However lab results do show that GRAKE provides higher MAC-e
throughput as compared to traditional RAKE especially when using 2msec TTI and
single UE even with QPSK.
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.
Page 161/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
GRAKE, 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 GRAKE. A score of 0 makes the user ineligible
for the GRAKE. This will ensure low speed users experiencing significant temporal
dispersion, while transmitting at low spreading gain (high burst rate) will only be
selected.
Normally it is possible to support 128 10msec TTI E-DCH users. When GRAKE is
active, the 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.
Currently in the Live networks, the feature could not show benefit, as it implies to
fulfill complex conditions like speed and dispersion. It is not recommended to activate
it due to lack of conclusive performance results.
[xCEM][eCEM]
The following parameter is used to activate this feature.
Parameter
RAN Path
Range & Unit
User
Class
Value
gRakeActivation
BTSEquipment
False, True
Customer
3
Object
BTSEquipment
Granularity
BTS
False
[UCU-III]
From Layer1 DSP perspective, the number of E-DCH users supported by UCU-III is the
minimum between the DSP memory limit (102 users when max number of Harq
retransmissions is 3) and 128 minus 12 (116 users, 12 being the cost for supporting
GRAKE). Due to this reason same CE capacity limitation does not appear when
supporting the GRAKE in US market: the number of E-DCH users supported by UCUIII would be 102 regardless of the GRAKE activation status.
The following parameter is used to activate this feature for the UCU-III module:
Parameter
RAN Path
Range & Unit
User
Class
Value
gRakeActivation
OneBTSEquipment
False, True
Customer
3
Object
OneBTSEquipment
Granularity
BTS
False
[iCEM]
Page 162/163

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Z END OF DOCUMENT Y
Page 163/163
UMT/IRC/APP/016664
CALL MANAGEMENT
V05.04
16/MAR/2012

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 5 : Call Management
CONTENTS
1
INTRODUCTION............................................................................................................6
1.1
OBJECT ....................................................................................................................... 6
1.2

2.1
HPUG VOLUMES ............................................................................................................ 8
2.2
HSXPA CAC ...................................................................................................................9

3.1
RAB MATCHING ............................................................................................................. 9
3.2
ADMISSION PHASE ........................................................................................................ 12
3.2.1
RNC CAC ........................................................................................................... 13
3.2.1.1
HSDPA CAC .................................................................................................... 13
3.2.1.2
EDCH CAC ...................................................................................................... 30
3.2.2
Node-B CAC ....................................................................................................... 36
3.2.2.1
HSDPA CAC .................................................................................................... 37
3.2.2.2
EDCH CAC ...................................................................................................... 37
3.3
HSPA TO DCH FALLBACK ............................................................................................... 44
3.3.1
3.3.2
3.3.3
3.3.4
4
FALLBACK MECHANISM....................................................................................... 45
Fallback for E-DCH ............................................................................................. 47
Fallback for HSDPA DUAL CELL call ...................................................................... 48
PARAMETERS SETTINGS AND RECOMMENDATIONS.............................................. 49
RLC RECONFIGURATION PROCEDURE .......................................................................50

4.1
HSDPA CASE .............................................................................................................. 50
4.2
HSUPA CASE .............................................................................................................. 52
MULTI-RAB HANDLING ..............................................................................................55

5.1
MULTI-RAB HANDLING ON HSDPA................................................................................... 55
5.1.1
Principles ........................................................................................................... 55
5.1.2
Multi-RAB Combination Configuration (HSDPA)...................................................... 55
5.2
MULTI-RAB HANDLING ON HSUPA................................................................................... 60
5.2.1
5.2.2
5.2.3
6
Principles ........................................................................................................... 60
Restriction on combination Streaming + HSUPA .................................................... 61
PM34018 Multiple PS I/B on HSUPA ..................................................................... 61
CALL SETUP (DATAFLOW) ..........................................................................................68

6.1
INITIAL CONNECTION PHASE: ........................................................................................... 68
6.2
RAB ALLOCATION PHASE: ............................................................................................... 69
CALL RELEASE (DATAFLOW) ......................................................................................71

7.1
IU RELEASE CASE .......................................................................................................... 71
Page 1/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

7.2
8
RAB RELEASE CASE ....................................................................................................... 71

RRM ALGORITHMS .....................................................................................................73
8.1
ALWAYS-ON ................................................................................................................ 73
8.1.1
Mechanism ........................................................................................................ 73
8.1.2
New RRC states.................................................................................................. 73
8.1.3
Activation & ModeS ............................................................................................ 75
8.1.3.1
Activation ....................................................................................................... 75
8.1.3.2
Modes ............................................................................................................ 78
8.1.3.3
Multiservice with HSDPA (HSDPA+CS & HSDPA+STR) ........................................ 81
8.1.3.4
Upsize ............................................................................................................ 81
8.1.3.5
Reminder for timer usage ................................................................................ 82
8.1.4
Parameters Settings and Recommendations.......................................................... 84
8.2
IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING ....................................................... 85
8.3
IRM
8.4
RB ADAPTATION INTERWORKING ...................................................................................... 86
8.5
UA6.0 PREEMPTION INTERWORKING ................................................................................. 87

8.5.1
8.5.2
8.5.3
8.5.4
8.5.5
CAC/IRM PRE-EMPTION INTERWORKING ...................................................................... 86
Description ........................................................................................................ 87
Feature Dependencies ........................................................................................ 87
CAC Failures ...................................................................................................... 88
Other backup mechanisms .................................................................................. 89
Activation flags................................................................................................... 90
F-DPCH AND SRB OVER HSPA ....................................................................................92

9.1
STRATEGY, IMPLEMENTATION AND FEATURE BENEFITS ............................................................ 92
9.2
BACKGROUND INFORMATION ............................................................................................ 93
9.2.1
Overview of F-DPCH ........................................................................................... 93
9.2.2
Frame Structure and Slot Formats........................................................................ 94
9.2.3
F-DPCH Timings ................................................................................................. 95
9.2.4
Synchronisation.................................................................................................. 96
9.3
FEATURE DESCRIPTION .................................................................................................. 98
9.3.1
F-DPCH Code Allocation ...................................................................................... 98
9.3.2
Power Control ...................................................................................................100
9.3.3
NOde B Capability .............................................................................................101
9.3.4
Criteria for SRB Mapping on HSPA.......................................................................101
9.3.5
SRB on HSPA in RRC Connection, RAB Establishment and RAB Release ..................104
9.3.5.1
RRC Connection ............................................................................................ 104
9.3.5.2
RAB Establishment ........................................................................................ 104
9.3.5.3
RAB Release ................................................................................................. 105
9.3.6
SRB on HSPA in Mobility.....................................................................................105
9.3.6.1
Active Set Management ................................................................................. 105
9.3.6.2
Outer Loop Power Control and DCH Active Set................................................. 106
9.3.6.3
Primary Cell Change ...................................................................................... 107
9.3.6.4
Radio Conditions ........................................................................................... 107
9.3.6.5
Mixity Management ....................................................................................... 108
9.3.6.6
Iur Management ........................................................................................... 108
9.3.7
SRB on HSPA in Always-On ................................................................................108
9.3.8
Radio Configuration and Resource Management...................................................109
9.3.9
Synchronisation.................................................................................................111
9.3.10 Interaction with Dual Cell Operation....................................................................112
9.4
PARAMETERS ..............................................................................................................112
Page 2/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

10
EDCH CALL MANAGEMENT SUMMARY......................................................................118
Page 3/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
TABLES
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
1: HSDPA RB Configuration and system behaviour

2 : Target Bit Rate
3 : Corrective factor for power reservation
4 : Corrective factor for codes reservation
5: Always-on timer usage (URA/Cell_PCH states not used)
6: Always-on timer usage (URA/Cell_PCH states are used)
7: F-DPCH slot formats (#1 and #2 formats are not used)
8: RRC establishment causes for SRB on HSPA configuration
9: RL Configuration with F-DPCH
10: SRB reconfiguration and SIR Target update
11: SRB on HSPA with F-DPCH and Always-On transitions
12: HS-DSCH radio bearers consumption model
9
15
16
19
82
83
95
103
105
106
109
111
Page 4/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1 : Fair Sharing algorithm prior to Dual Cell operation ........................................................ 16

2 : HS-DSCH power reservation at call admission ............................................................... 17
3 : HS-PDSCH codes reservation at call admission .............................................................. 19
4: Example of biggest pool of free SF16 ............................................................................ 20
5: HSxPA Call setup / initial connection (Cell_DCH) ............................................................ 68
6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ..................... 69
7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)...................... 70
8: Call release (RAB release case)..................................................................................... 72
9: AO state transitions ..................................................................................................... 75
10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none) ............ 79
11: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates = none) ............ 80
12: Always-on for HSDPA/E-DCH (releaseOnly mode)......................................................... 81
13: UA6.0 Pre-emption global view ................................................................................... 87
14: UA6.0 Pre-emption feature dependencies .................................................................... 88
15: Pre-emption and other congestion management procedures.......................................... 90
16: F-DPCH multiplexing .................................................................................................. 93
17: Rel.6 F-DPCH frame structure ..................................................................................... 94
18: DL DPCH frame structure ........................................................................................... 95
19: F-DPCH timings ......................................................................................................... 96
20: Timing adjustment procedure ..................................................................................... 97
21: Transport channel synchronisation procedure............................................................... 97
22: Node synchronisation procedure ................................................................................. 98
23: Position of the TPC bits for one given OVSF code ......................................................... 98
24: F-DPCH code allocation mechanism............................................................................. 99
Page 5/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
1 INTRODUCTION
1.1 OBJECT
This includes a
recommendations.
system
description,
configuration
aspect
and
engineering

PM ID
27930
HSDPA Service
27942
Always-on
HSDPA
27945
30741
29797
32602
34168
Release
Global
market
US
Market
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA5.0
Yes
Yes
isMultiRabOnHsdpaAllowed
UA5.0
Yes
Yes
edchToDchFallbackPermissio
n
UA5.0
Yes
Yes
UA5.1
Yes
No
UA6.0
Yes
Yes
UA6.0
Yes
Yes
Feature Title
N/A
On
HSDPA Radio
Bearer
Multi-Services
Handling On
HSUPA
Multi-RAB Handling
on HSDPA
HSDPA to DCH
fallback
STSR2+1
Activation flag
isAlwaysOnAllowed
N/A
N/A
edchToDchFallbackSteps
N/A
isGbrOnHsdpaAllowed
29804
GBR on HSDPA
only to
HSDPA)
33320
New RAB and

combinations for
UA06
N/A
map
(used
Streaming on
Page 6/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

PM ID
Feature Title
Activation flag
Release
Global
market
US
Market
UA6.0
Yes
Yes
UA6.0
No
Yes
UA7.1
Yes
No
Yes
Yes
RNC:
isHsxpaR99ResourcesSharing
OnCellAllowed
NodeB:
33694
Fair Sharing of
Resources - HSDPA
vs DCH
BTSEquipment::hsdpaCodeTre
eManagementActivation
[UCU-III]
OneBTSEquipment::hsdpaCod
eTreeManagementActivation
isThreeRabAllowed
isMpdpExtendedRabCombsAll
owed
34170
3 PDP Support
mpdpInactivityIuRelease
isMpdpExtendedRabCombsAll
owed
34018
Multiple PS I/B on
HSUPA
isMultiRabOnEdchAllowed
edchMaxLegs2msPerCell
[GM]
UA7.1.2
34441.1
34441.2
CAC algorithm
evolution
edchMaxUsersPerCell
80051
eCEM-u
Introduction
No activation flag
UA7.1.3
Yes
No
74681
eCEM Introduction
No activation flag
UA7.1.3
Yes
No
UA08.1
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
[US]
UA7.1.3
useImprovedBtsCacFor2msTti
Users
82602/
R3
Improved CAC
scheme for 2ms
TTI users
29810
Fractional DPCH
and SRB over HSPA
isSrbOverHspaEnabled
UA08.1
125171
/125567
E-DCH Enhanced
NodeB CAC
BTSEquipment ::reserved2
Byte 0 and 1
UA7.1.3
116250
/81449
New RAB
Combinations
(Multi-PDP
Enhancements)
N/A
UA08.1
useImprovedCacFor2msTtiUs
ers
UA08.1
Page 7/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

Planning Guide
[R03] UMT/SYS/DD/018826
Call Admission Control (Radio)
CEM Capacity Engineering guide
Page 8/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
3 HSXPA CAC
3.1 RAB MATCHING
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 section 3 of this
volume).
RB Configuration
System behaviour
Supported: no impact coming from HSDPA.
All RABs DCH available

in HSDPA Cell
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
(PS I/B + PS I/B + PS

I/B) on HSDPA
Supported (from UA6 in US and from UA08.1 in GM).
PS Streaming on HSDPA
Supported (from UA6).
(PS Streaming + PS I/B)

on HSDPA
Speech on DCH + PS
I/B on HSDPA
Speech on DCH + (PS +

PS) on HSDPA
Supported (from UA6.0 in US).

PS + PS) on HSDPA
Supported (from UA6.0 in US and from UA08.1 in GM).
CSD/DCH + PS I/B on
HSDPA
Table 1: HSDPA RB Configuration and system behaviour
Page 9/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RB Configuration
System behaviour
Supported: no impact coming from HSUPA.
All RABs DCH available

in HSUPA Cell
All RAB combinations existing in this release are available on DCH in an

HSUPA cell (either for a mobile that does not support HSUPA or for a RAB
combination that is not supported on HSUPA).
PS I/B on HSUPA
(PS I/B + PS I/B) on

HSUPA
(PS I/B + PS I/B + PS

I/B) on HSUPA
Speech on DCH + PS
I/B on HSUPA
Supported (from UA6).

PS) on HSUPA

PS + PS) on HSUPA
CSD/DCH + PS I/B on
HSUPA
Supported.
Table 2: HSUPA RB Configuration and system behaviour
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 of
CN transfer delay.
Page 10/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

* 384kbps if enabled through feature 33320 New RAB and combinations for
UA06. See [R01] for more details)
transportTypeSelectionTransferDelayThreshold
Parameter
RAN Path
Range & Unit
Integer [0 65536] seconds
User
Class
Value
Customer
3
Object
HsdpaRncConf
Granularity
RNC
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.
isGbrOnHsdpaAllowed
Parameter
RAN Path
Range & Unit
Boolean
{True, False}
Customer
3
User
Class
Value
Object
RadioAccessService
Granularity
RNC
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 HSDSCH required power)
- RNC: Computation of the mac-hs GBR used by the Fair Sharing feature and
eventually sent to the NodeB
For
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 section 3.2 for
more details). At reception of this IE, the mac-hs scheduler activates a new behaviour
allowing to
-
PS
Streaming
on
HSDPA
and
Schedule with a higher priority the mac-hs GBR users (see [Vol. 3] for more
details).
Page 11/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

-
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

The CAC admission process for HSDPA/HSUPA is triggered each time there is a need
to check for HSDPA/HSUPA resources availability: at RAB Assignment, at incoming
Relocation, during Mobility, and at Always-On Upsize.
Several mechanisms are available, at the RNC side and at the NodeB side, each of
them offering ways to control the HSDPA/E-DCH resources allocation based on
different criteria.
The Fair sharing feature (33694) controls the HSDPA admission based on the DL
power and DL code consumption, and ensures a fair sharing of resources allocation
between HSDPA and DCH.
Another basic mechanism exists (baseline), at the RNC side, using the number of
simultaneous authorized HSDPA users per cell; however this mechanism and the Fair
Sharing are mutually exclusive as it makes no sense to restrict the number of HSDPA
users as far as the DL resources are well controlled by the Fair Sharing mechanism.
The RNC E-DCH CAC (34441.1/34441.2) controls the E-DCH admission based on
the number of simultaneous authorized E-DCH users per cell, and performs as well a
specific control for E-DCH TTI2ms admission.
The enhanced NODEB E-DCH CAC (125171/125567) ([GM]) also checks the
number of E-DCH users before admitting a new one, based on the maximum number
of possible E-DCH users per modem board. It also offers a way to control the use of
E-DCH TTI2ms through the concept of E-DCH credits, helping optimizing the modem
board resources: in the xCEM, the 2ms usage is more expensive than the 10ms (for
eCEM, the cost is similar), so above a certain amount (configurable) of consumed
credit, it is preferable to use 10ms.
Page 12/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The Improved CAC scheme for 2ms TTI users (82602/R3) at the NODEB side
aims also at controlling the admission of an E-DCH TTI2ms user, this time based on
the modem CE decoding processing limit.
For [GM], the NODEB also controls the number of HSDPA/E-DCH users by enforcing
the Capacity Licencing or Pseudo-Capacity Licencing (16746) rules based on
tokens purchased by the operator. See [R05] for more details on this feature.
These mechanisms are all together compatible with each other (with the exception of
the baseline HSDPA maximumNumberOfUsers not working when Fair Sharing is
activated). However, for E-DCH, comparing the RNC E-DCH CAC (34441.1/34441.2)
and the CAC mechanisms available at NodeB side (enhanced NODEB E-DCH CAC
(125171/125567) and Improved CAC scheme for 2ms TTI users (82602/R3), it is
recommended to use only the latter (NodeB ones) since it is by nature better adapted
to accurately control the modem E-DCH resource usage than an algorithm running at
the RNC side.
Upon CAC failure detected by either of the above mechanisms, the RNC takes the
appropriate action depending on the features activated (HSPA to DCH fallback, iMCTA
on CAC, ). Regarding E-DCH, the action also depends on the nature of the rejected
Radio Link (i.e serving or non-serving).
All these CAC mechanisms and the actions taken upon a CAC failure are described in
details in the sub-sections below.
Finally it is to be noted that the iRM CAC as described in [R01] does not apply to
HSDPA/EDCH RAB; it applies only to DCH.
Engineering Recommendation: if E-DCH CAC is activated, also activate the Enhancement

367062
The E-DCH CAC features, when they force adding a failed E-DCH non-serving RL to the DCH active set
only, while the SRB is over E-DCH for the serving RL, may weaken the retainability of the call due to
the loss of the SRB Macro-Diversity.
It is recommended to activate the enhancement 367062 at the same time as the activation of the EDCH CAC features. This enhancement reconfigures the SRB from E-DCH to DCH 3.4kbps when the
loss of SRB Macro-Diversity is detected.
3.2.1 RNC CAC

3.2.1.1 HSDPA 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).
Page 13/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For more details, see [R03].
From 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 and that the E-DCH CAC is successful. 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.
From
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.
Page 14/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Target Bitrate
The target bitrate is equal to:
a mac-hs GBR
or to the parameter minHsDschReservationForCac if the mac-hs GBR is

null
TargetBitRate = Mac-hs GBR or = minHsDschReservationForCac if Mac-hs GBR = 0
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
Table 2 : Target Bit Rate
Page 15/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For HSDPA-DC call, the target bit rate is divided equally between the serving and
secondary serving cell before being used in the power and code based RNC CAC for
each cell independently as per UA6 functionality. This is shown in the figure below. If
CAC fails on secondary serving cell then call is reconfigured to legacy HSDPA call on
serving cell only, else serving cell CAC can cause existing mitigation to take place like
iMCTA CAC or Pre-emption (if configured).
F air Sharing A lg orithm Prior to D ua l Cell operation
no
no
0
isminBRused
yes
=0 ?
minBR Min()
( TC, THP,
ARP)
F air bitrate / 2 is used on

the anchor
servin cell to derive
the needed code & power
fair bitrate = min (MBR, minBR)
yes
/2
fair bitrate =
F air bitrate / 2 is used on

the secondary cell to
derive the needed code &
power
MBR
Figure 1 : Fair Sharing algorithm prior to Dual Cell operation
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
Corrective factor
PS STR RAB with RANAP GBR
None
initialActivityFactorForIb
Table 3 : Corrective factor for power reservation

Page 16/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

HS-DSCH power reservation
Target Bit Rate
dlTxPowerEstimation
Power reserved for PS
Streaming on HSDPA
Power reserved for
PS I/B on HSDPA
Figure 2 : HS-DSCH power reservation at call admission
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 machs 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
isDlPowerSelfTuningForPsIbOnHsdpaEnabled 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
isDlPowerSelfTuningForPsIbOnHsdpaEnabled 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 HSDSCH required power = current power consumption / current throughput * Mac-hs
GBR)
Page 17/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

During the CAC, RNC has to check that the power used by R99 traffic and reserved
HSDPA users (GBR and non-GBR) is lower than the traffic power:
R99 used + HSDPA Required Power (GBR) + HSDPA Reserved Power (non GBR)
< Ptraffic
with Ptraffic = maxTxPower Pccc - Psho Pocns Pedch
Pccc is the power reserved the common control channel taking into account
an activity factor defined by the parameter ActivityFactorCCH (in FDDCell).
Psho is the power reserved for SHO admission.
Pocns is the power reserved for OCNS
Pedch is the power reserved for the DL channels related to E-DCH defined by
the parameter eagchErgchEhichTotalPower.
When Fair Sharing feature is enabled, the iRM power 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]
ovsfCodesThroughputQpskUE
and
ovsfCodesThroughput16QamUE give the bitrate that can be achieved with one
Parameters
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 RNC uses the ovsfCodesThroughput16QamUE to
estimate the code consumption of 16 QAM capable UE as well as the one of 64 QAM
capable UE.
Page 18/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Note that the number of reserved HS-PDSCH codes is rounded globally for all the
HSDPA users. For ex : if ovsfCodesThroughputQpskUE = 200kbps per SF16 and 2
HSDPA users with minBrForHsdpa = 250kbps, the number of reserved HS-PDSCH
codes will be ceil(250/200 + 250/200) = ceil(1.25 + 1.25) = 3 and not
ceil(1.25)+ceil(1.25) = 4.
RNC applies an over-reservation factor:

Type of service
Corrective factor
PS STR RAB with RANAP GBR
reservationFactorOnCodesForGbrTraffic
and initialActivityFactorForIb
Table 4 : Corrective factor for codes reservation
HS-PDSCH codes reservation

Target Bit Rate
ovsfCodesThroughputXXUe
XX = QPSK or 16QAM
Codes reserved for PS
Streaming on HSDPA
Codes reserved for PS I/B
on HSDPA if minBr = 0
Codes reserved for PS I/B
on HSDPA if minBr > 0
Figure 3 : HS-PDSCH codes reservation at call admission
During the CAC, the RNC has to check if the number of HS-PDSCH codes reserved is
lower or equal to the biggest pool of SF16 not used by control channels (including
CCC, HS-SCCH, DL HSUPA) and R99:
For an HS-DSCH MAC-d flow the call admission will accept it if:
SizeBiggestSF16Pool - n >= 0
where
- n is the updated n including the incoming HS-DSCH RB (or reconfigured RB)
Page 19/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

- SizeBiggestSF16Pool represents the number of SF16 codes of the biggest
pool of free SF16 (free means not allocated or blocked by DCH, CCH, SCCPCH, HS-SCCH, E-AGCH, E-RGCH/E-HICH) as illustrated below
Figure 4: Example of biggest pool of free SF16
For a DCH, as in UA05, the first free code in the tree will be allocated. However the
RNC will verify that after the allocation of this code the following condition is still
verified:
SizeBiggestSF16Pool - n >= 0
where
- 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
RAN Path
maximumNumberOfUsers
Object
HsdpaCellClass
Range & Unit
Integer [0 100]
User
Class
Value
Customer
3
N/A
Granularity
RNC
100
Page 20/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
isHsxpaR99ResourcesSharingOnCellAllowed
Customer
2
Object
FDDCell
Granularity
Cell
True
Page 21/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 22/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
isDlPowerSelfTuningForPsIbOnHsdpaEnabled
Object
FDDCell
Customer
Granularity
Cell
3
True to consider PS I/B users as a GBR users (power reservation updated
periodically and higher priority of scheduling), False otherwise.
Rule: isDlPowerSelfTuningForPsIbOnHsdpaEnabled
When this flag is set to True, the HSDPA power reserved by the RNC is updated thanks to the NBAP
common measurement HS-DSCH required power reported by the NodeB.
This message informs the RNC of the power needed to guarantee the GBR. Basically, the estimation of
this required power to guarantee the GBR is done by the scheduler knowing the current throughput
and the current HSDPA power consumed by the NodeB.
Considering a constant power consumption for HSDPA (in general, equal to Pcpich + MPO for a single
HSDPA user), the HS-DSCH required power will increase when the current throughput will decrease.
Then, the cell capacity can be reduced when the ue is in bad RF conditions (low throughput).
Parameter
RAN Path
Range & Unit
User
Class
Value
minBrForHsdpa
Object
ThpBasedQos
RNC / RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos
[0..2048] kb/s
Customer
Granularity RNC
3
Default values (see the table below)
Page 23/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
minBrForHsdpa = 16 kbps
1
Background
2
3
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 restriction between the GBR feature and this
transport feature doesnt allow to use normally these defaut values. Please refer to the restriction box
below for details.
2- No resource reservation:
The simpler way to reserve nothing for HSDPA PS I/B 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
Page 24/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

3- Resources reservation with differentiation:
Different type of differentiation can be used by the operator according to their strategy:
-
differentiation per OLS (ARP):

Traffic Class
ARP
THP
Target Bit Rate
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
3
1
Background
N/A

differentiation per Traffic Class:

Traffic Class
ARP
THP
Target Bit Rate
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
1
Background
2
3
N/A
Page 25/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

-
differentiation per service (THP):

Traffic Class
ARP
THP
Target Bit Rate
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
1
Background
2
3
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. See [R04] and Volume 3 for more details on this parameter and
this feature).
Page 26/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range &
Unit
User
Class
Value
minHsDschReservationForCac Object
HsxpaR99ResourcesSharingCellClass
RNC / RadioAccessService / DedicatedConf / HsxpaR99ResourcesSharingCellClass
[0..1024] kb/s
Customer
3
Granularity
RNC
Max value of minBrForHsdpa
Engineering Recommendation: minHsDschReservationForCac
minHsDschReservationForCac is only used when minBrForHsdpa = 0 or ranap GBR = 0 .

As explained in the engineering 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 (NeighbourRNC)= True, then the machs GBR IE is sent from the SRNC to the DRNC. 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). The DRNC will disregard the GBR information if
parameter isDlPowerSelfTuningForPsIbOnHsdpaEnabled (FDDCell in drift RNC) and the
traffic class is Interactive/Background. In this case minHsDschReservationForCac is used
instead, for resource reservation.
If isDlPowerSelfTuningForPsIbOnHsdpaEnabled (NeighbourRNC)= False, then the machs 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. This is
independent of the setting of parameter isDlPowerSelfTuningForPsIbOnHsdpaEnabled
(FDDCell in drift RNC).
In case of CAC failure in the DRNC, the SRNC cannot determine whether the failure occurs on a
shared resource or not (because the RNSAP causes are not detailed enough). The DRNC will use the
cause DL Radio Resources Not Available. So in case of failure from the DRNC, the SRNC will try to
fallback to DCH if the RB was on HS-DSCH.
Page 27/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range &
Unit
User
Class
Value
dlTxPowerEstimation
Object
[1..7][-35.0..15.0] step:0.1dB
Customer
3
Granularity
RNC
-35.0,-35.0,-35.0,-35.0,-35.0,-35.0,-35.0 (7 values corresponding to [64kbps; 128kbps;

256kbps; 384kbps; 1000kbps; 2000kbps; 4000kbps])
Engineering Recommendation: dlTxPowerEstimation

With the default value (-35dB), the power reserved at call admission is very low.
Anyway, this power will be updated for mac-hs GBR (PS I/B or PS Streaming) users thanks to the HSDSCH required power sent by the NodeB to the RNC.
For non mac-hs GBR (PS I/B only) users, the power reserved is never updated during the call. So, in
order to reserve a more realistic amount of power, dlTxPowerEstimation can be set with the
following values :
dlTxPowerEstimation = [-5, -3, -2, -2, -2, -2, -2]
Parameter
RAN Path
Range &
Unit
User
Class
Value
ovsfCodesThroughputQpskUe Object
[1..15][0..14400] kb/s
Parameter
ovsfCodesThroughput16Qam
Ue
RAN Path
Range &
Unit
User
Class
Value

[1..15][0..14400] kb/s
Customer
3
Granularity
RNC
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))
Customer
3
Object
Granularity
RNC
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 28/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range &
Unit
User
Class
Value
reservationFactorOnCodesFor
GbrTraffic
Object
HsxpaR99ResourcesSh
aringCellClass
[0..500] %
Customer
Granularity
RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa
value
Page 29/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range &
Unit
User
Class
Value
Object
[0..100] %
Customer
Granularity RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value
Engineering Recommendation: Corrective factors

The corrective factors reservationFactorOnCodesForGbrTraffic and initialActivityFactorForIb
are used to tune the resources reservation:
- If these 2 parameters are set to 0%, during the RNC CAC, no code resource is reserved
(neither for PS Streaming nor for PS I/B) and no power resource is reserved (for PS I/B).
- 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
RAN Path
Range & Unit
User
Class
Value
hsxpaR99ResourcesSharingId
N.A.
Customer
3
Object
FDDCell
Granularity
Cell
Pointer
3.2.1.2 EDCH CAC

From [GM] UA7.1.2 / [US] UA7.1.3, the call admission is enhanced in RNC with a CAC
for E-DCH users (feature [GM]34441.1/[US]34441.2).
RNC maintains the total number of simultaneous serving E-DCH legs and non-serving
E-DCH legs per cell (2ms as well as 10ms TTI). If a new E-DCH radio link is setup in
this cell, the RNC ensures that the current total number of simultaneous serving EDCH legs and non-serving E-DCH legs remains below the CAC threshold for E-DCH
legs, edchMaxUsersPerCell.
In a second step, for a 2ms E-DCH radio link case, the RNC also ensures this current
total number remains below the edchMaxLegs2msPerCell threshold.
Page 30/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The use of these thresholds is against the total number of E-DCH legs, and not only
the number of E-DCH legs by TTI.
In other words, for admitting a 2ms TTI E-DCH leg to a cell, the total current number
of E-DCH legs (2ms and 10 ms TTI E-DCH legs) in the cell must be below the 2ms TTI
threshold (edchMaxLegs2msPerCell).
For admitting a 10ms TTI E-DCH leg to a cell, the total current number of E-DCH legs
(2ms and 10ms TTI E-DCH legs) in the cell must be below the overall E-DCH
threshold (edchMaxUsersPerCell)
Thus, the value of edchMaxLegs2msPerCell could be set equal to, or slightly less than
edchMaxUsersPerCell to have a large percentage of the overall E-DCH legs as 2ms TTI
legs.
The following examples show the impact of the total number of E-DCH legs and these
parameter settings.
Example 1:
edchMaxUsersPerCell
Incoming 2ms TTI Leg*
Current number of E-DCH legs <
Current # of
E-DCH legs
(2ms & 10ms)
Result: admit incoming 2ms TTI leg
Current number of E-DCH legs <
Result: admit
* serving RL in the SRNC
incoming 10ms TTI leg
Page 31/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Example 2:
edchMaxUsersPerCell
Current # of
E-DCH legs
(2ms & 10ms)
Current number of E-DCH legs >=

edchMaxLegs2msPerCell and <
edchMaxUsersPerCell
Result: admit incoming 2ms TTI leg as

10ms TTI leg

edchMaxLegs2msPerCell and <
edchMaxUsersPerCell
Result: admit incoming 10ms TTI leg
Example 3:
edchMaxUsersPerCell
Current # of
E-DCH legs
(2ms & 10ms)

edchMaxLegs2msPerCell and =
edchMaxUsersPerCell
Result: do NOT admit incoming 2ms TTI

leg, set up as UL DCH

edchMaxLegs2msPerCell and =
edchMaxUsersPerCell
Result: do NOT admit incoming 10ms TTI

leg, set up as UL DCH
All E-DCH radio links of a call towards the same NodeB are counted only as one link
(indeed 3GPP defines that all E-DCH radio links towards the same NodeB must be
combined). Thus for a call, a new E-DCH radio link will always be admitted if it is
added to an existing E-DCH Radio Link Set (set of E-DCH radio links towards the same
NodeB).
An E-DCH UE is counted as follows.
For a NodeB which has the serving E-DCH radio link for this user, the user is
counted as one user whatever the number of non-serving E-DCH radio links
this user has towards this NodeB. This user is counted against the E-DCH
serving cell.
For a NodeB which has only non-serving E-DCH radio link(s) for this user, the
user is counted as one user against the E-DCH non-serving cell having the
highest EDCH CAC threshold edchMaxUsersPerCell.
Page 32/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For the DRNC case, when the CAC for E-DCH users fails, the DRNC sends back an
RNSAP RL Setup/Addition/Reconfiguration failure message with cause set to either
"Requested Configuration not supported" (in case the check against
edchMaxUsersPerCell fails) or E-DCH TTI2ms not supported (in case the check
against edchMaxLegs2msPerCell fails).
The parameter edchMaxUsersPerCell defines the maximum number of

simultaneous serving and non-serving EDCH legs per cell (including both 10ms TTI
and 2ms TTI).
Parameter
RAN Path
Range & Unit
User
Class
Value
edchMaxUsersPerCell
Object
[1..128]
Customer
Granularity
3
[iCEM] : 15
[xCEM][eCEM] : 18 x maxNrOfErgchEhich
[UCU-III] : 19 x maxNrOfErgchEhich
EdchCellClass
EdchCellClass
Note: the parameter maxNrOfErgchEhich controls the maximum number of downlink

E-HICH/E-RGCH channels (i.e. SF 128 OVSF codes) reserved per cell. Since one ERGCH/E-HICH channel can support up to 18 E-DCH radio links for the [xCEM][eCEM]
and 19 for the [UCU-III], the maximum number of these downlink channels will affect
the maximum number of E-DCH radio links in a cell. Refer to [Vol. 4] for more
information on this parameter.
As an example, and to clarify the relationship between edchMaxUsersPerCell, and
maxNrOfErgchEhich:
If maxNrOfErgchEhich is set to 1, edchMaxUsersPerCell should be set to values less
than or equal to 18 for the [xCEM][eCEM] and 19 for the [UCU-III].
The parameter edchMaxLegs2msPerCell defines the maximum number of

simultaneous serving and non-serving EDCH legs per cell (2ms and 10ms TTI E-DCH
legs) for 2ms EDCH RL admission.
Page 33/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
Object
[1..128]
Customer
Granularity
3
[iCEM] Not applicable
[xCEM][eCEM] 128
[UCU-III] see below
EdchCellClass
EdchCellClass
Engineering Recommendation: edchMaxLegs2msPerCell for Global Market

[xCEM][eCEM]
edchMaxLegs2msPerCell recommended value is 128.

It is recommended not to use the threshold edchMaxLegs2msPerCell to control the 2ms TTI
admission: as it works on a cell basis at RNC side, and considering that the RNC has no way to know
how the cells are distributed over the modem boards within the NodeB, this threshold may lead to
CAC decisions not reflecting neither the real modem capacity limit nor the real modem decoding
capacity limit. That is why it is recommended to let it not active (i.e set it to its maximum value 128)
and rather use the features 125171/125567 E-DCH enhanced NODEB CAC and 82602/R3 Improved
CAC scheme for 2ms TTI users.
Page 34/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: edchMaxLegs2msPerCell for US Market
[UCU-III]
The maximum overall number of EDCH users is defined as the minimum between the L1 memory
capacity (102 EDCH users for a maximum of 4 HARQ transmissions configured for 10ms TTI) and 128
GRake UL cost = 116 (GRake UL cost is 12 if G-Rake is activated, 0 otherwise).
Consequently the maximum value for edchMaxUsersPerCell is 102 per UCU-III card (for a
maximum of 4 HARQ transmissions configured for 10ms TTI), including potentially 3 G-Rake users.
The maximum number of 2ms TTI legs per UCU-III card is 32 (including 3 G-Rake users) with 4 HARQ
transmissions. The maximum setting supported on a cell for maxNrOfErgchEhich is 4.
Additionally, each UCU-III can support at most 3 HSxPA schedulers per board. The HSxPA schedulers
are not pooled and one scheduler can support only 1 FDD Cell (the UCU-III cards are grouped into
Modem Groups, which must also be taken into account when looking at UCU-III usage as a maximum
of 6 cells can be assigned to a Modem Group, and a Modem Group can have up to 12 UCU-IIIs). For
the case of 1 to 3 UCU-IIIs supporting up to 3 HSxPA schedulers (for e.g. up to 3 cells), not taking
into account any UCUs going out of service, and assuming only 1 Modem Group, possible
configurations would look like this (Maximum values may not offer best per user, or best per cell
throughput, and using 102 as the overall maximum number of E-DCH legs supported):
# of
UCU# of
Number of
III in
Cells
Max per cell value for
Cells per
NodeB
in
maxNrOfErgchEhich edchMaxLegs2msPerCell edchMaxUsersPerCell
UCU-III
Modem NodeB
Group
1
3
3
1
10
19
2
3
2, 1*
3
15
57
3
3
1
4
30
76
*Two cells would be supported by one UCU, with the one remaining cell supported by the other UCU.
This table just showed several examples of the UCU-III board and parameter setting dependencies.
There might be other considerations as well, for example, UCU-III cards resetting or going out of
service, which was not covered in the above table.
Here below is the description of the recommendation that was valid in the previous
releases for xCEM and eCEM, before the availability of 125171/125567 and 82602/R3
features. It could be re-used if for some reasons, the operator is willing to make use
of this threshold.
Page 35/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UA7/UA08.1 Delta: edchMaxLegs2msPerCell in Global Market
[xCEM][eCEM]
edchMaxLegs2msPerCell recommended values in previous releases:

The optimal value was not easy to determine as it depends on the number of cells mapped on the
board and the balance of EDCH traffic among the cells mapped on the board.For the iBTS, we
recommended to set the threshold, at minimum, as the maximum board capacity (in term of 2msTti
users) divided by the number of EDCH cells mapped on the board. A margin might to be added to this
minimum value, especially in case of unbalanced traffic between cells mapped on the board. At
maximum, it was to be set equal to edchMaxUsersPerCell.
[xCEM]: 32/number of EDCH cells per xCEM ~ edchMaxLegs2msPerCell edchMaxUsersPerCell
[eCEM]:128/number of EDCH cells per eCEM ~ edchMaxLegs2msPerCell edchMaxUsersPerCell
Number of EDCH cells per xCEM or eCEM
One
Two
Three
Four
Five
Six
[xCEM] edchMaxLegs2msPerCell (at minimum)
32
16
10
64
42
32
25
21
[eCEM] edchMaxLegs2msPerCell (at minimum) 72(*)
(*):assuming that maxNrOfErgchEhich is set to 4 allowing 72 EDCH users per cell

In the current release, it is recommended to deactivate the control of 2ms admission based on this
threshold, i.e set edchMaxLegs2msPerCell to 128, and to activate the features 125171/125567 EDCH enhanced NODEB CAC and 82602/R3 Improved CAC scheme for 2ms TTI users.
Call handling after an E-DCH CAC failure:

The call handling after an E-DCH CAC failure depends on the configured E-DCH
fallback permissions, the nature of the rejected RL (serving or non-serving). Refer to
the section 3.3.2 for the description of the call handling.
3.2.2 NODE-B CAC

Once the RNC CAC passed, the Node-B is requested for CEM or UCU-III resources
allocation through Radio Link Reconfiguration procedure (see call setup call flow in the
section 6) or through Radio Link Setup or Radio Link Addition procedures (see mobility
with E-DCH Macro-Diversity description in the [Vol. 6] of this document).
If the resource allocation fails, the BTS will send a RL Reconfiguration/Setup/Addition
Failure. The main possible NBAP failure causes used to notify the RNC about CAC
failures are:
If E-DCH CAC fails and HSDPA CAC passes : UL Radio Resources Not
Available or Not enough user plane processing resources for specific 2msTTI
CAC failure
If both E-DCH CAC and HSDPA CAC fail : NodeB Resources Not Available
Page 36/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
If E-DCH CAC passes but HSDPA CAC fails : DL Radio Resources Not
Available
The Node-B CAC mechanisms are described below.
3.2.2.1 HSDPA CAC
3.2.2.1.1 CAC BASED ON THE NUMBER OF HSDPA USERS PER BOARD

Each of the modem board (iCEM, xCEM, eCEM, UCU-III) is committed to handle a
certain amount of HSDPA users. The number of users is constantly monitored and a
new incoming one fails the admission contol in case the limit is reached.
Additionally for iBTS (iCEM, xCEM and eCEM boards), some sets of parameters are
used to limit the capacity accordingly to the commercial agreement established with
the customer. The CEM resources management is fully described in [R05] CEM
Capacity Engineering Guide.
Finally, note that contrarily to the RNC CAC based on the maximum number of
authorized HSDPA users, not triggered if the Fair Sharing is activated, at NodeB side,
the CAC based on the maximum number of users is unchanged whatever the Fair
Sharing activation status may be.
3.2.2.1.2 HSDPA RESOURCE COST FOR HSDPA DUAL CELL UE

With feature PM81204 activated, NodeB shall consider each HSDPA-DC call consuming
two HS-DSCH radio-links and hence the hardware resources are reduced by a half.
Two NodeB CAC failure cases can be considered:
Case 1: RL Reconfiguration Prepare fails on NodeB because no resource on serving
cell. NodeB responds with Reconfiguration failure with cause UL or DL resources not
available or NodeB resources not available. RNC will probably fallback to R99 or
initiate iMCTA or Pre-emption
Case 2: RL Reconfiguration Prepare fails on NodeB because no resource on secondary
cell. NodeB responds with Reconfiguration failure with cause Multi-cell operation not
available. RNC will again send Reconfiguration Prepare to establish HSDPA call on
single cell (= serving cell in previous RL message)
3.2.2.2 EDCH CAC

In the same way as for HSDPA, the NodeB ensures that the maximum number of
EDCH users per board is not exceeded: it checks for hardware limit as well as (for
[GM]) the limit granted by the commercial agreement.
In addition, enhanced CAC mechanisms for 2ms TTI users are also available.
3.2.2.2.1 125171/125567 E-DCH ENHANCED NODEB CAC [GM]

[xCEM][eCEM]
With these features introduced in UA7.1.3 latest loads and UA08.1, the NodeB EDCH
CAC takes into account the mixity of 2msTTI and 10msTTI users.
Page 37/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

An EDCH 2msTTI user cost is higher than a 10msTTI; the 2ms cost factor depends on
the board: 4 times higher for xCEM, no extra cost compared to 10msTTI for eCEM
(from UA08 onwards).
The NodeB updates the EDCH resources consumption accordingly. At call admission
control, the two following equations shall be verified to pass the admission:
(1) For 10msTTI or 2msTTI user admission control
[xCEM] m10ms + 4*n2ms xCemMaxEdchUsers
[eCEM] m10ms + 1*n2ms eCemMaxEdchUsers
(2) Only for 2msTTI user admission control
[xCEM] m10ms + 4*n2ms maxNbEdchCreditsForXcem
[eCEM] m10ms + 1*n2ms maxNbEdchCreditsForEcem
Where:
m10ms is the current number of 10ms TTI users
n2ms is the current number of 2ms TTI users
xCemMaxEdchUsers, eCemMaxEdchUsers are the maximum number of EDCH users in xCEM and eCEM. It is hard-coded to 128. It can be less (128
G-Rake UL Cost) if G-rake feature (34393) is activated.
G-Rake UL Cost is 12.
maxNbEdchCreditsForXcem, maxNbEdchCreditsForEcem are OMC parameters

defined to limit the number of 2msTTI users and preserved the capacity of
the board in term E-DCH users (2ms + 10ms).
If the check (1) fails the NodeB rejects the request with cause UL radio resources not
available.
If the check (2) fails the NodeB rejects the request with cause Not enough user plane
processing resources.
This NodeB EDCH CAC algorithm maximizes the usage of 2ms TTI in case of low to
medium traffic while maximizing the usage of 10ms TTI in case of heavy traffic.
The parameters below are used to configure the credits to limit the number of E-DCH
2ms TTI users. They are defined in temporary fields; they will be replaced with
correctly named parameters later.
The parameter maxNbEdchCreditsForXcem (BTSEquipment::reserved2 byte0)
defines the maximum number of credits allowed on xCEM.
Page 38/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
reserved2 (byte 0)
BTSEquipment
[0..128], integer
Customer
3
Object
BTSEquipment
Granularity
BTS
See engineering rule below.

100 : recommended value
[1..80]: not for use (lab only)
[81..99]: not recommended (too many 2ms to 10ms fallback)
[100..112]: allowed range for fine tuning
[113..127]: not optimized (too many EDCH to DCH fallback)
0 or 128: feature deactivated. 0 is interpreted by the Enhanced NodeB CAC
feature as 128, giving a maximum number of 2ms TTI users = 128/4 = 32
The parameter maxNbEdchCreditsForEcem (BTSEquipment::reserved2
byte1) defines the maximum number of credits allowed on eCEM.
Parameter
RAN Path
Range & Unit
User
Class
Value
reserved2 (byte 1)
BTSEquipment
[0..128], integer
Customer
3
Object
BTSEquipment
Granularity
BTS
0 or 128 (feature deactivated). 0 is interpreted by the Enhanced NodeB CAC

feature as 128, giving a maximum number of 2ms TTI users = 128/1 = 128.
Example: on xCEM, if the maxNbEdchCreditsForXcem is set to 128, it means 32
2msTTI can be admitted and then no more EDCH users are admitted (neither
10msTTI nor 2msTTI); the RNC can fallback the 33th user to DCH. If the
maxNbEdchCreditsForXcem is set to 100, it means 25 2msTTI can be admitted
and 28 more EDCH users as 10ms (either true 10msTTI users or 2ms-fallbacked to
10ms).
[UCU-III]
The feature is not applicable.
The UCU-III limits the number of 2ms TTI users to 32 and limits the overall number of
EDCH users to 102, like in previous releases. There is no check based on credits in
case of TTI mixture, e.g. it is possible to setup 32 2ms users plus a certain amount of
10ms users.
Note: at one moment, the unused parameterOneBTSEquipment::tPreempt was
considered to handle CAC in case of TTI mixture but this has been abandoned. In the
current release this parameter must remain 0.
Page 39/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: 125171/125567 Enhanced NodeB EDCH CAC : 2ms credits
settings
[xCEM]
The credits are configured through BTSEquipment::reserved2 byte 0.
It is recommended to set the credits to 100 (i.e 25 2ms connections maximum per board).
This value 100 may be further tuned based on observations as follows:
Criteria for tuning the credits below 100 (and always above 80) :
If the maximum number of EDCH connections per board is below the H/W limit or the S/W licence and
however some UEs have been fallbacked to DCH, it means the credits are too high and may be
slightly decrease.
However the decrease below 100 must be performed with caution with respect to the possible NBAP
overhead generated by a too important volume of 2ms to 10ms fallbacks; 80 shall be considered as
the extreme lower bound.
Criteria for tuning the credits above 100 :
If the maximum number of EDCH connections per board reaches the H/W limit or the S/W licence,
higher values for credits may be tried in order to reach the best functional point, the best trade-off
between the amount of 2ms to 10ms fallbacks and the number of EDCH connections.
Simulations show that above 112 the EDCH to DCH fallback may start reappearing, so it is
recommended not to go above 112 (28 2ms connections per board), although this is not a strict upper
limit, as it depends on the call model.
Equivalence of credits :
Another rule to fulfil is to limit the credits delta across different contiguous sites to 12 (the two bounds
of the recommended range [100;112]) not more, in order to limit the asymmetry of the active set
(some EDCH RL and some DCH RL).
Restricted values :
It is forbidden to set credits below 80 (i.e below 20 2ms connections per board). All values below 80
shall be used only for functional tests in a lab. They are not allowed in the field.
The values between 80 and 100, although not forbidden, are not recommended. They may eventually
be considered in some extreme call models situations (situations where the EDCH to DCH fallback are
huge with the feature OFF).
[eCEM]
The credits are configured through BTSEquipment::reserved2 byte 1.
Considering the eCEM extended capacity compared to the xCEM, and considering the 2ms has no
extra-cost compared to the 10ms, there is no need to limit the number of 2ms with the credits. It is
recommended to keep the feature deactivated (credits 0 or 128).
[UCU-III]
Feature not applicable. Keep OneBTSEquipment::tPreempt to 0.
Page 40/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

3.2.2.2.2 PM82602/R3 IMPROVED CAC SCHEME FOR 2MS TTI USERS

3.2.2.2.2.1 FEATURE DESCRIPTION
With 82602/R3, the CAC scheme for 2ms TTI users is improved by taking into account
the CE resource status in terms of decoding rate.
A new indicator is introduced in NodeB to indicate CE resource limitation. When its
raised, the NodeB rejects a 2 ms TTI E-DCH call attempt with a specific cause value
Not enough User Plane Processing Resources in NBAP response. If this NodeB is
under a DRNC, this cause mapped into E-DCH TTI2ms not supported in the RNSAP
response.
Decoding rate limit

[xCEM]
If HsupaCellParams::EdchMaxThroughput = MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit =
absoluteRequestedDecodingRateLimitForCACXCem
Else, if HsupaCellParams::EdchMaxThroughput MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = relativeRequestedDecodingRateLimitForCAC*
HsupaCellParams::EdchMaxThroughput
[eCEM]
If HsupaCellParams::EdchMaxThroughput = MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit =
absoluteRequestedDecodingRateLimitForCACECem
Else, if HsupaCellParams::EdchMaxThroughput MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = relativeRequestedDecodingRateLimitForCAC*
HsupaCellParams::EdchMaxThroughput
HsupaCellParams::EdchMaxThroughput is the maximum MAC-e/i throughput per
xCEM/eCEM board defined by the resource allocation algorithm.

[UCU-III]
The total requested decoding rate limit per UCU board shall be directly configured as:
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCAC
Page 41/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

CE Overload detection
- If Total_requested_decoding_rate > Requested_decoding_rate_limit
=> Resource_limit_ind = TRUE
- If Total_requested_decoding_rate <= Requested_decoding_rate_limit
=> Resource_limit_ind = FALSE ; after a guard timer of 1s is elapsed
The actual total requested decoding rate shall be determined per baseband board at
each EDCH scheduling interval as follows:
Total_Requested_decoding_rate = TBsum / EDCH_scheduling_interval
Where:
TBsum comprises all transport block sizes TBi and TBj for all serving users ui and all
non-serving users uj served by one baseband board that are received within the time
EDCH_scheduling_interval regardless whether a valid E-DPDCH scheduler data packet
was received or not.
EDCH_scheduling_interval is the time between two runs of the E-DCH scheduler. It is
hard-coded to 40ms.
CAC Scheme
If 82602/R3 is enabled, the NodeB shall maintain a combined state:
Block_2msTTI_users for each radio cell: Block_2msTTI_users =
Resource_limit_ind
If Block_2msTTI_users = TRUE:
On reception of NBAP Radio Link Reconfiguration Prepare message

for 2 ms TTI, the Node B shall respond with a NBAP Radio Link
Reconfiguration Failure message with cause Not enough User Plane
Processing Resources
On reception of NBAP Radio Link Setup/Addition request message for

2 ms TTI, the Node B shall respond with a NBAP Radio Link
Setup/Addition Failure message with cause Not enough User Plane
Processing Resources
The CAC check shall be performed at RNC in following cases:
Establishment of a new 2ms TTI E-DCH radio link in this cell during E-DCH
setup
Transition from DCH to 2ms TTI E-DCH
Radio link addition with 2ms TTI E-DCH or 2ms TTI E-DCH serving cell
change
Reconfiguration from CELL_FACH or URA_PCH to CELL_DCH state with 2ms
TTI E-DCH
Page 42/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

3.2.2.2.2.2 PARAMETERS SETTINGS AND RECOMMENDATIONS

The feature is activated by setting these parameters to TRUE:
At NodeB: useImprovedCacFor2msTtiUsers
At RNC: useImprovedBtsCacFor2msTtiUsers
useImprovedBtsCacFor2msTtiUsers
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
NodeBConfClass
False, True
Customer
Granularity
RNC
3
True
[eCEM, xCEM]
useImprovedCacFor2msTtiUsers
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
False, True
Customer
3
Object
BTSEquipment
Granularity
BTS Equipment
Object
OneBTSEquipment
Granularity
OneBTSEquipment
True
[UCU-III]
Parameter
RAN Path
Range & Unit
User
Class
Value
OneBTSEquipment
False, True
Customer
3
True
[XCem]
absoluteRequestedDecodingRateLimitForCACXCem: This parameter gives

the absolute CE decoding rate limit requested by all E-DCH radio links connected
to a xCEM board. This is used for the CAC scheme for 2ms TTI users for iBTS.
Parameter
RAN Path
Range & Unit
User
Class
Value
absoluteRequestedDecodingRateLimitForCACXCem
BTS Equipment
[0 .. 33500], kbps
Customer
3
Object
BTSEquipment
Granularity
BTSEquipment
9600
[eCem]
Page 43/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

absoluteRequestedDecodingRateLimitForCACECem: This parameter gives the
absolute CE decoding rate limit requested by all E-DCH radio links connected to a
eCEM board. This is used for the CAC scheme for 2ms TTI users for iBTS.
Parameter
RAN Path
Range & Unit
User
Class
Value
absoluteRequestedDecodingRateLimitForCACECem
BTS Equipment
[0 .. 33500], kbps
Customer
3
Object
BTSEquipment
Granularity
BTSEquipment
28800
[eCEM, xCEM]
relativeRequestedDecodingRateLimitForCAC:
CE decoding rate limit

relative to the maximum BTS licensed capacity. This is used for the CAC scheme
for 2ms TTI users for iBTS in case of the maximum CE decoding rate is restricted
by the BTS capacity licensing feature. . This is used for the CAC scheme for 2ms
TTI users for iBTS.
relativeRequestedDecodingRateLimitForCAC
Parameter
RAN Path
Range & Unit
User
Class
Value
BTSEquipment
[0 .. 100], %
Customer
3
Object
BTSEquipment
Granularity
BTSEquipment
95
[UCU-III]
absoluteRequestedDecodingRateLimitForCAC: This parameter gives the

absolute CE decoding rate limit requested by all E-DCH radio links connected to
an UCU-III board. This is used for the CAC scheme for 2ms TTI users for
oneBTS.
Parameter
RAN Path
Range & Unit
User
Class
Value
absoluteRequestedDecodingRateLimitForCAC
OneBTSEquipment
[0 .. 33500], kbps
Customer
3
Object
OneBTSEquipment
Granularity
9600
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
Page 44/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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

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).
The restriction with mono-RAB configuration is partially lifted in UA7.1.2 (GM) and UA7.1.3 (US
Market) with feature PM34441.1, on which the fallback from EDCH 2ms/HS-DSCH to EDCH 10ms/HSDSCH is supported. In addition, fallback from E-DCH / HS-DSCH to DCH / HS-DSCH is also possible
with this feature.
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.
Note that HSPA to DCH fallback feature offers also the possibility to fallback the EDCH from 2msTTI to 10msTTI (not necessarily to DCH). This possibility has been
introduced with the features 34441.1/34441.2 RNC EDCH CAC, 125171/125567 E-DCH
enhanced NODEB CAC and 82602/R3 Improved CAC scheme for 2ms TTI users.
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 one of these combinations as if UE was not
HSUPA and/or HSDPA capable.
Fallback to DL DCH / UL DCH
Fallback to DL HSDPA / UL DCH
Fallback to DL HSDPA / UL E-DCH 10ms (a.k.a E-DCH 2ms to 10ms fallback)
The decision is taken based on two types of failure causes:

Page 45/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Internal to RNC: maximum number of HSDPA or HSUPA users
External to RNC: NBAP or RNSAP failure causes.
The RNC classifies the external failure causes into three categories: the DL-specific
failure causes (e.g DL Radio Resources Not Available), the UL-specific failure causes
(e.g UL Radio Resources Not Available) and the non-direction-specific causes (e.g
NodeB resources not available).
When the RNC receives NBAP or RNSAP RadioLinkReconfigurationFailure or
RadioLinkSetupFailure with a cause that gives specific information on UL or DL, it
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 HSDPA/HSUPA into DL DCH/UL DCH
MultiStep to try and reconfigure first into HSDPA/UL DCH (and then into DL
DCH/UL DCH in case of HSDPA CAC failure)
MultiStep gives also the permission, for an E-DCH 2ms call which did not
pass the CAC, to try and reconfigure first into HSDPA/E-DCH 10ms (and then
into HSDPA/UL DCH in case E-DCH 10ms did not succeed, and finally to DL
DCH/UL DCH in case of HSDPA CAC failure).
The handling of the fallback for the E-DCH part is detailed in the section 3.3.2 below.
HSDPA
or
DCH
fallbacks
can
be
activated
through
hsdpaToDchFallbackPermission or edchToDchFallbackPermission parameters:
HSUPA
to
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 or RadioLinkSetupFailure

with cause NodeB_resource_unavailable, fallback may lead to a second NBAP
RadioLinkReconfigurationFailure or RadioLinkSetupFailure when such failure is due to
lack of DCH resources (UL DCH for instance).
In such a case, the counter VS.RadioLinkReconfigurationPrepareUnsuccess for
screening RadioLinkReconfigurationFailure (or VS.RadioLinkSetupUnsuccess for
screening RadioLinkSetupFailure) will be pegged twice for the same RAB Assignment
or the same Mobility procedure.
Page 46/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
3.3.2 FALLBACK FOR E-DCH

In case of E-DCH CAC failure, and if the RNC setting gives the appropriate permission,
the RNC selects a fallback configuration that optimizes as much as possible the UL
resources usage, based on the failure cause.
The possible fallback configurations for E-DCH has been implemented on top of the
feature HSPA to DCH fallback, in order to manage efficiently the E-DCH CAC
introduced in UA7 (34441.1/34441.2 RNC EDCH CAC) and in UA8 (125171/125567
E-DCH Enhanced NODEB CAC ([GM] only) and 82602/R3 improved CAC scheme for
2ms TTI users).
Note that the decision depends on the nature of the E-DCH Radio Link which is
rejected, E-DCH Serving Radio Link or E-DCH non-serving Radio Link.
Fallback the call from E-DCH to UL DCH
When the E-DCH CAC for the E-DCH Serving Radio Link is failed for one of the
following reason, the decision is to attempt a fallback of the call to UL DCH:
Internal failure in the RNC due to maximum number of EDCH users limit
reached (threshold edchMaxUsersPerCell)
NBAP failure with UL-specific failure cause UL radio resources not available
NBAP failure with non-direction-specific failure cause
RNSAP failure with cause Requested Configuration not supported.
Fallback the call from E-DCH 2ms to E-DCH 10ms

For an E-DCH 2ms call, when the E-DCH CAC for the E-DCH Serving Radio Link is
failed for one of the following reason, the decision is to attempt a fallback of the call
from E-DCH 2ms to E-DCH 10ms:
Internal failure in the RNC due to maximum number of EDCH 2ms admission
limit reached (threshold edchMaxLegs2msPerCell)
NBAP failure with failure cause Not enough user plane processing resources
RNSAP failure with cause E-DCH TTI2ms not supported
If this fails too, the RNC fallbacks the call to UL DCH.

Fallback an E-DCH non-serving Radio Link to UL DCH
When the E-DCH CAC fails for a non-serving E-DCH Radio Link setup on event1A,
whatever the failure cause is, the decision is to retry to include the Radio Link in the
DCH activeset but not in the E-DCH activeset.
A drawback of adding a failed non-serving E-DCH radio link to the DCH active set only
is the loss of the macro-diversity gain for the SRB established over E-DCH. This is
corrected by the enhancement 367062 which reconfigure the SRB from E-DCH to DCH
after the completion of the non-serving RL setup. Refer to [Vol. 6] for details about
CR Id 367062.
Fallback the call from E-DCH 2ms to E-DCH 10ms when the E-DCH nonserving Radio Link can not be admitted as 2ms
Page 47/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

From UA08.1.2 onwards, an enhancement known as 82602/R3 Enhancement allows
(re)-configuring the call to 10ms when a non-serving RL does not pass the 2ms
admission. This enhancement is available during a reconfiguration triggered by a RB
setup, a Primary Radio Link change and an IU release. It is not run during a RL setup
triggered by an event1A.
All these decisions are possible only in case the setting gives the appropriate
permission, as already mentioned.
The E-DCH to DCH fallback and the E-DCH 2ms to E-DCH 10ms fallback
decision is controlled by edchToDchFallbackPermission and by
edchToDchFallbackSteps. If it is not permitted, the call will be rejected
instead of being fall-backed to UL DCH. If the step is MonoStep, the call will
be directly fall-backed to DL DCH/UL DCH.
The non-serving RL addition in the DCH active set defense mechanism is

controlled by the flag isEdchRLAddOrSetupDefenseAllowed (see [Vol.
6]). If it is not allowed, the non-serving RL will not be established.
Refer also to the enhancement 367062 in [Vol. 6], to the feature 125855 in [Vol. 4],
and to the summary in the section 10 of the current volume.
3.3.3 FALLBACK FOR HSDPA DUAL CELL CALL

An HSDPA Dual Cell call requires HSDPA resources on two cells, the anchor cell and
the supplementary cell.
In case of internal RNC CAC failure (DL Power, DL code) for the supplementary cell,
the RNC establishes the call as a Single Cell call.
In case of Node-B CAC failure, if the CAC fails on the supplementary cell, the RNC
fallback the call from Dual Cell to Single Cell and tries again. If the CAC fails on the
anchor cell, the RNC fallback the call from Dual Cell to DCH and tries again.
Finally, note that the pre-emption feature may be attempted as a last chance to save
the call, in case the fallback did not succeed (refer to section 8.5 in this volume and to
[R01] (UPUG) for more details. Note that at the pre-emption queue level, there is not
yet the notion of shall the call be DC or SC, since this will be decided later when the
rab matching will check if the conditions are satisfied or no to put this call on DC or
SC.
Page 48/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

hsdpaToDchFallbackPermission: This parameter defines the scope where a
Fallback on DCH is tried when a failure occurred due HSDPA CAC resource shortage.
Parameter
RAN Path
Range & Unit
User
Class
Value
hsdpaToDchFallbackPermission
Object
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
RadioAccessService
RNC
AnyCase
edchToDchFallbackPermission: This parameter defines the scope where a
Fallback on DCH is tried when a failure occurred due HSUPA CAC resource shortage.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchToDchFallbackPermission
Object
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
RadioAccessService
RNC
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
RAN Path
Range & Unit
User
Class
Value
edchToDchFallbackSteps
Enum
{MonoStep, MultiStep}
Customer
3
Object
RadioAccessService
Granularity
RNC
MultiStep
Engineering Recommendation: hsdpaToDchFallBackPermission and
edchToDchFallBackPermission
Both permissions should be set to AnyCase in order to improve Accessibility and Retainability.
Page 49/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 AlwaysOn), it is done simultaneously with the transport channel reconfiguration
(synchronous reconfiguration).
When it is associated to a RB addition/deletion (due to RAB assignment/release, with

PS I/B RAB already established and not affected), if the UE is Rel5, this cannot be
performed simultaneously with the RB addition/deletion (because it is not possible to
reconfigure the rlc pdu size of an existing RB for these Rel5 UEs). 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. If the UE is Rel6
or greater, it is possible to perform a RLC reconfiguration (e.g between RLC fixed and
RLC flexible mode, also between HSDPA 336 and 656 bits), concurrently with a RAB
Assignment (Setup or Release) operation. See also [Vol. 3], sub feature 34388.5 for
more details.
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).
Page 50/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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:
isRLCReconfigurationForChannelTypeSwitching:
Activation of the RLC

reconfiguration after a channel type switching related to release or addition of another
RAB.
Parameter
RAN Path
Range & Unit
User
Class
Value
isRLCReconfigurationForChannelTypeSwitching
Boolean
{True, False}
Customer
3
Object
HsdpaRncConf
Granularity
RNC
True
deltaCfnForHsdpaMobility: Delta CFN used for HS-DSCH creation when primary
cell is changed.
Parameter
RAN Path
Range & Unit
User
Class
Value
deltaCfnForHsdpaMobility
Object
Integer
[0..255] (x10ms)
Customer
Granularity
3
HsdpaRncConf
RNC
45
Page 51/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

deltaCfnForHsdpaChannelTypeSwitching: Delta CFN used for SRLR due to
channel type switching between DCH and HS-DSCH
Parameter
RAN Path
Range & Unit
User
Class
Value
deltaCfnForHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
Object
HsdpaRncConf
Granularity
RNC
80
deltaCfnForHsdpaRLCReconfiguration: Delta CFN used for RLC reconfiguration
when done in stand-alone (0 means asynchronous reconfiguration).
Parameter
RAN Path
Range & Unit
User
Class
Value
deltaCfnForHsdpaRLCReconfiguration
Integer
[0..255] (x10ms)
Customer
3
Object
HsdpaRncConf
Granularity
RNC
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.
In case a channel type switching is also performed in the downlink (HS-DSCH <->
DCH/FACH) a bi-directional reconfiguration is performed. If there is no channel type
switching in the downlink, then a mono-directional reconfiguration is performed.
In case of E-DCH to RACH transition on Always-On downsize, the RLC parameters
used for the reconfiguration are the ones of the reference DCH radio bearer. This is
needed in case the UE further moves to a primary cell that is not E-DCH capable and
is then upsized (to DCH), it will use RLC parameters suited for this radio bearer (since
no RLC reconfiguration is done on the RACH->DCH uplink reconfiguration). In case
the UE stays with an E-DCH-capable primary cell, RLC will be reconfigured to E-DCH
values on the upsizing from RACH to E-DCH.
When it is associated to a RB Reconfiguration procedure (due to mobility or AlwaysOn), it is done simultaneously with the transport channel reconfiguration
(synchronous reconfiguration).
When it is associated to a RB addition/deletion (due to RAB assignment/release, with

PS I/B RAB already established and not affected), it cannot be performed
Page 52/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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 an e-DCH cell.
Parameters:
isRlcReconfigurationForChannelTypeSwitchingEdch: Activation of the RLC
reconfiguration during a channel type switching between DCH and E-DCH.
Parameter
RAN Path
Range &
Unit
User
Class
Value
isRLCReconfigurationForChannelTypeSwitchingEdch
Boolean
{True, False}
Customer
3
Object
EdchRncConf
Granularity
RNC
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
RAN Path
Range & Unit
User
Class
Value
deltaCfnForEdchAndHsdpaMobility
Object
Integer
[0..255] (x10ms)
Customer
Granularity
3
EdchRncConf
RNC
45
Page 53/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
RAN Path
Range & Unit
User
Class
Value
deltaCfnForEdchChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
Object
EdchRncConf
Granularity
RNC
150
deltaCfnForEdchAndHsdpaChannelTypeSwitching: Delta CFN used for SRLR
due to channel type switching of both HSDPA and E-DCH.
Parameter
RAN Path
Range &
Unit
User
Class
Value
deltaCfnForEdchAndHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
Object
EdchRncConf
Granularity
RNC
80
deltaCfnForEdchRlcReconfiguration: Delta CFN used for RLC reconfiguration
when done in stand-alone (0 means asynchronous reconfiguration).
Parameter
RAN Path
Range & Unit
User
Class
Value
deltaCfnForEdchRlcReconfiguration
Integer
[0..255] (x10ms)
Customer
3
Object
EdchRncConf
Granularity
RNC
150
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.
Page 54/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
5 MULTI-RAB HANDLING
5.1 MULTI-RAB HANDLING ON HSDPA
5.1.1 PRINCIPLES
The feature Multi-RAB
configurations:
Handling
on
HSDPA
allows
handling
the
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]
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]
following
These configurations have to be handled in any transitions cases:
RAB Assignment
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).
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):
Page 55/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range &
Unit
User
Class
Value
isMultiRabOnHsdpaAllowed
Boolean
{True, False}
Customer
3
Object
RadioAccessService
Granularity
RNC
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 HsdpaCombination described below.
Parameter
RAN Path
Range &
Unit
User
Class
Value
isThreeRabAllowed
Boolean
{True, False}
Customer
3
Object
RadioAccessService
Granularity
RNC
True
DlUserService instances corresponding to Combinations including HSDPA shall be
enabled for the RAB Matching (parameter enabledForRabMatching in
DlUserService).
Parameter
RAN Path
Range & Unit
User
Class
Value
enabledForRabMatching
Object
RNC / RadioAccessService / DlUserService
Boolean
{False, True}
Customer
Granularity
3
DlUserService
DlUserService
True
Rule:
When the multi-RAB on HSDPA is activated, it is recommended to ensure that the related
DlUserServices are enabled for RAB Matching:
Speech + HSDPA
CSD + HSDPA
PS Streaming (DCH or HSDPA) + HSDPA
Speech + PS Streaming (DCH or HSDPA) + HSDPA
Page 56/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For each DlUserService, it is required to configure the allowed transitions from a
single PS HSDSCH to PS + PS HSDPA Configuration:
The only DlUserService supporting PS HSDPA Mux are:

o
PS HSDPA only
CS Speech + PS HSDPA
When the DlUserService includes 1 PS Streaming on DCH, then PS HSDPA

Mux is not allowed
For each DlUserService, one link hsdpaUserServiceProfileId to an object

HsdpaUserServiceProfile must be configured.
Each HsdpaUserServiceProfile contains all the 16 possible combinations (16
objects HsdpaCombination), easily identified thanks to an explicit user friendly
label, each one of these combinations can be "allowed" or not.
The labels for the 16 combinations are listed here below:
NO_HSPA_RAB
1_PS_IB
2_PS_IB
3_PS_IB
1_PS_STR
1_PS_IB_1_PS_STR
2_PS_IB_1_PS_STR
3_PS_IB_1_PS_STR
1_CONV
1_PS_IB_1_CONV
2_PS_IB_1_CONV
3_PS_IB_1_CONV
1_PS_STR_1_CONV
1_PS_IB_1_PS_STR_1CONV
2_PS_IB_1_PS_STR_1_CONV
The RAN model and relationships between DlUserService and HsdpaUserServiceProfile

is presented in the figure below.
Page 57/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC
RadioAccessService
DlUserService
UserServiceProfiles
hsdpaUserServiceProfileId
1..20
HsdpaUserServiceProfiles
16 combinations, each
of them with an explicit
naming and a flag
allowed True or False
16
HsdpaCombination
Similar model and combinations exist for Edch, please refer to the section 5.2 in this
volume.
The flag allowed in each HsdpaCombination determines if the related combination
is supported by the DlUserService.
Since features PM34378 (VOIP) and PM36247 (CS over HSPA) are not yet available,
following service configuration table shows all combinations involving 1_CONV on
HSDPA not allowed.
Global Market (isThreeRabAllowed = False)
US Market (isThreeRabAllowed = True)
NO_HSPA_RAB
TRUE
TRUE
1_PS_IB
FALSE
FALSE
2_PS_IB
FALSE
FALSE
FALSE
HsdpaCombination
HsdpaUserServiceProfiles
allowed
3_PS_IB
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
For DlUserServices
All DlUserServices without HS-DSCH
Meaning
NO_HSDPA
Combination supported by DlUserService:
[NO_HSDPA_RAB]
Page 58/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
TRUE
2_PS_IB
TRUE
TRUE
3_PS_IB
TRUE
TRUE
1_PS_STR
TRUE
FALSE
1_PS_IB_1_PS_STR
TRUE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
CSD_ON_DCH_plus_HSDPA
All DlUserServices with CSD on DCH plus HSDPA
(e.g CS_64KxPS_HSDSCHxSRB_3_4K)
[1 PS IB ON HSDPA] (GM)
CSV_ON_DCH_plus_HSDPA
All DlUserServices with CS Voice on DCH plus HSDPA
(e.g CS_AMR_NBxPS_HSDSCHxSRB_3_4K,
CS_AMR_WBxPS_HSDSCHxSRB_3_4K)
Combinations supported by DlUserService:
[1 PS IB ON HSDPA]
[2 PS IB ON HSDPA]
[3 PS IB ON HSDPA]
[1 PS STR ON HSDPA] (GM)
[1 PS IB and 1 PS STR ON HSDPA]

(GM)
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
All DlUserServices with CS Voice and PS Streaming on DCH

plus HSDPA
(e.g CS_AMR_NBxPS_xxK_STRxPS_HSDSCHxSRB_3_4K,
CS_AMR_WBxPS_xxK_STRxPS_HSDSCHxSRB_3_4K)
CSV_AND_PS_STR_ON_DCH_plus_HSDPA
Page 59/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
TRUE
2_PS_IB
TRUE
TRUE
3_PS_IB
TRUE
TRUE
1_PS_STR
TRUE
FALSE
1_PS_IB_1_PS_STR
TRUE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
All DlUserServices with PS Streaming on DCH plus HSDPA

(e.g PS_xxK_STRxPS_HSDSCHxSRB_3_4K)
PS_STR_ON_DCH_plus_HSDPA
HSDPA_plus_SRB_ON_DCH_OR_HSPA
and
HSDPA_plus_SRB_ON_HSPA
All DlUserServices with HSDPA plus SRB on DCH or HSPA
(e.g PS_HSDSCHxSRB_3_4K, PS_HSDSCHxSRB_HSDSCH)
Combinations supported by DlUserService:
[1 PS IB ON HSDPA]
[2 PS IB ON HSDPA]
[3 PS IB ON HSDPA]
[1 PS STR ON HSDPA] (GM)
[1 PS IB and 1 PS STR ON HSDPA]

(GM)
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 through 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 UlUserService is not allowed to be used by the RAB Matching,
there is no fallback on DCH, implying RAB Assignment Failure during RB Setup.
Page 60/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
Object
RNC / RadioAccessService / UlUserService
Boolean
{False, True}
Customer
Granularity
3
User
Class
Value
UlUserService
UlUserService
True
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.
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 PM34018 MULTIPLE PS I/B ON HSUPA

Multiple PS I/B on HSUPA (PM34018) is available from UA7.1 onwards:
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
RAB combinations shall be then supported for 2ms and for 10ms TTI as well.
Page 61/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Supports of the following new RBs are 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 and the existing

UlUserService MOs will allow configuring the new RAB combinations introduced by
this feature.
For each UlUserService, a profile EdchUserServiceProfile containing
EdchCombination indicates which mux E-DCH combination is allowed or not (it is
checked during RAB matching procedure).
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
RAN Path
Range & Unit
User
Class
Value
isMultiRabOnEdchAllowed
Boolean
{True, False}
Customer
3
Object
RadioAccessService
Granularity
RNC
True
UA7/UA08.1 Delta: Interaction between features PM34018 and PM34170

Prior to UA08.1, features PM34018 - Multiple PS on E-DCH and PM34170 - 3 PDP Contexts Support in
UTRAN were mutually exclusive. A WIPS check was added and only one of these features could be
active (PM34018 for GM and PM34170 for US Market).
In UA08.1 decision has been made that feature PM116250/PM81449 - New RAB Combinations (MultiPDP Enhancements) will merge both features for Global Market and US Market.
For activation in UA08.1 both PM34170 and PM34018 feature flags can be enabled for GM and US. The
UA07 MIB cross-checking for the two feature activation at the same time has been removed.
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 62/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Finally, theres another parameter that gives the allowed EDCH configuration in terms
of supported PS RAB for each traffic class.
So, for each UlUserService, one link edchUserServiceProfileId to an object
EdchUserServiceProfile must be configured.
Each EdchUserServiceProfile contains all the 16 possible combinations (16 objects
EdchCombination), easily identified thanks to an explicit user friendly label, each
one of these combinations can be "allowed" or not.
The labels for the 16 combinations are listed here below:
NO_HSPA_RAB
1_PS_IB
2_PS_IB
3_PS_IB
1_PS_STR
1_PS_IB_1_PS_STR
2_PS_IB_1_PS_STR
3_PS_IB_1_PS_STR
1_CONV
1_PS_IB_1_CONV
2_PS_IB_1_CONV
3_PS_IB_1_CONV
1_PS_STR_1_CONV
The RAN model and relationships between UlUserService and EdchUserServiceProfile

is presented in the figure below.
Page 63/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

RNC
RadioAccessService
UlUserService
1
UserServiceProfiles
EdchUserServiceProfileId
1..20
EdchUserServiceProfiles
16 combinations, each
of them with an explicit
naming and a flag
allowed True or False
16
EdchCombination
Similar model and combinations exist for HSDPA. Please refer to the section 5.1 in this
volume.
The flag allowed in each EdchCombination determines if the related combination
is supported by the UlUserService.
Parameter
RAN Path
Range & Unit
User
Class
Value
allowed
Object
EdchCombination
RNC / RadioAccessService / UserServiceProfiles / EdchUserServiceProfiles /
EdchCombination
{True/False}, Boolean
Customer
Granularity
RNC
3
False for all combinations with 1_CONV
For other combinations, see table below.
Since features PM34378 (VOIP) and PM36247 (CS over HSPA) are not yet available,
following service configuration table shows all combinations involving 1_CONV on
HSUPA not allowed.
Page 64/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
US Market (isThreeRabAllowed = True)
Global Market (isThreeRabAllowed = False)
EdchCombination
EdchUserServiceProfiles
allowed
NO_HSPA_RAB
TRUE
TRUE
1_PS_IB
FALSE
FALSE
2_PS_IB
FALSE
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
TRUE
2_PS_IB
TRUE
FALSE
FALSE
3_PS_IB
TRUE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
For UlUserServices
Meaning
NO_HSPA
All UlUserServices without EDCH
Combination supported by UlUserService:
[NO HSPA RAB]
CSD_ON_DCH_plus_EDCH
All UlUserServices with CSD on DCH plus EDCH
(e.g CS_64KxPS_EDCHxSRB_3_4K)
All UlUserServices with CS Voice on DCH plus EDCH

(e.g CS_AMR_NBxPS_EDCHxSRB_3_4K,
CS_AMR_WBxPS_EDCHxSRB_3_4K)
[1 PS IB ON EDCH] (GM)
CSV_ON_DCH_plus_EDCH
Combinations supported by UlUserService:
[1 PS IB ON EDCH]
Page 65/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
FALSE
2_PS_IB
FALSE
FALSE
3_PS_IB
FALSE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
NO_HSPA_RAB
FALSE
FALSE
1_PS_IB
TRUE
TRUE
2_PS_IB
TRUE
FALSE
3_PS_IB
TRUE
FALSE
1_PS_STR
FALSE
FALSE
1_PS_IB_1_PS_STR
FALSE
FALSE
2_PS_IB_1_PS_STR
FALSE
FALSE
3_PS_IB_1_PS_STR
FALSE
FALSE
1_CONV
FALSE
FALSE
1_PS_IB_1_CONV
FALSE
FALSE
2_PS_IB_1_CONV
FALSE
FALSE
3_PS_IB_1_CONV
FALSE
FALSE
1_PS_STR_1_CONV
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
All UlUserServices with CS Voice and PS Streaming on DCH

plus EDCH
(e.g CS_AMR_NBxPS_xxK_STRxPS_EDCHxSRB_3_4K,
CS_AMR_WBxPS_xxK_STRxPS_EDCHxSRB_3_4K)
All UlUserServices with PS Streaming on DCH plus EDCH

(e.g PS_xxK_STRxPS_EDCHxSRB_3_4K)
CSV_AND_PS_STR_ON_DCH_plus_EDCH
PS_STR_ON_DCH_plus_EDCH
EDCH_plus_SRB_ON_DCH_OR_HSPA
and
EDCH_plus_SRB_ON_EDCH_ONLY
All UlUserServices with EDCH plus SRB on DCH or HSPA
(e.g PS_EDCHxSRB_3_4K, PS_EDCHxSRB_EDCH)
Combinations supported by UlUserService:
[1 PS IB ON EDCH]
Page 66/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Engineering Recommendation: Concerning UlRbSetConf/PS_EDCH_MUX
Apart from all the parameters already mentioned previously related with this feature PM34018,
regarding UlRbSetConf/PS_EDCH_MUX conf and all the objects under it (CacTransportInfoList,
DynamicParameterForEdchTti2ms, DynamicParameterForEdchTti10ms, EdchParameters),
all the other non mentioned parameters, should use the values applied by the client under
UlRbSetConf/PS_EDCH conf.
Engineering Recommendation: Concerning Always-On and RAB Matching

For a optimal performance of the feature PM34018, its recommended to set the following parameters
to the following values:
enableForRabMatching under UlRbSetConf to True

enableForRabMatching under UlUserService to True
isAlwaysOnAllowed under UlUserService to True
isAlwaysOnAllowed under UlRbSetConf to releaseOnly
Parameter
RAN Path
Range & Unit
User
Class
Value
RNC / RadioAccessService / UlRbSetConf
Boolean
{False,True}
Customer
3
Object
Granularity
UlRbSetConf
UlRbSetConf
True
Same parameter exists also for DlRbSetConf. For more details concerning this
parameter and the others mentioned above in the recommendation box, please check
the others sections of this current vol.5.
Rule: Transition Cell_DCH Cell_PCH

If the transition Cell_DCH => Cell_PCH is used, then the same parameters changes mentioned above
in the Engineering Recommendation box for alwaysOn and rabMatching must be applied to the
equivalent
parameters
under
UlRbSetConf/TRB_CellFACH_MUX
and
UlUserService/TRBxSRB_CellFACH_MUX. It may be good idea to perform this change even without
Cell_DCH => Cell_PCH usage. No harm will come from this
[iCEM] [UCU-III]
The feature is supported only by xCEM and eCEM. This feature is not required for
OneBTS/UCUIII and also not possible with iCEM.
Page 67/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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.
UE
Node B
RNC
RRC/ RACH / RRC connection Request
SGSN
The RRC Connection Request message initiated
by the UE contains the establishment cause.
NBAP/ RL Setup Request)

NBAP / RL Setup
RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,

RRC state = CELL_DCH, [frequency info])
RRC/ RACH / RRC Connection Setup Complete
The RRC Connection Setup message contains the

signalling bearers (DCCH) definition. A UTRAN
Radio Network Temporary Identity is also
allocated to the UE.
The target RRC state is set to CELL_DCH by the
RNC
If the mobile is redirected for traffic segmentation
reason then frequency info is included
In addition to the initial NAS message, the Initial Direct Transfer message
also contains the CN domain identity, used by the RNC to route the NAS
message to the relevant CN domain (i.e. CS or PS)
RRC/ RACH / Initial Direct Transfer (Activate PDP Context Request, PS domain)
SCCP/ Connection Request (Initial UE msg (Activate PDP Context Request))

SCCP/ Connection Confirm
The initial UE message is piggybacked in the
SCCP connection resquest
Figure 5: HSxPA Call setup / initial connection (Cell_DCH)
Page 68/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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))
UE
Node B
RNC
SGSN
The UE is authenticated by the SGSN

GMM/ Authentication and Ciphering
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:
UIA1 for integrity
UEA1 for ciphering

RANAP/ Security Mode Command
RRC/ Security Mode Command
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete
RANAP/ Security Mode

The Radio Access Bearer assignment procedure
RANAP/ RAB Assignment Request (RAB param, binding Id)
NBAP/ Radio Link Reconfiguration Request (

HS-DSCH Radio Link)
A HS-DSCH Radio Link is created as well as the

associated DCH
NBAP/ Radio Link Reconfiguration Ready (HS-SCCH codes allocated)

FP/ DL Synchronisation (CFN)
The DCH is synchronised
FP/ UL Synchronisation (ToA)

NBAP/ Radio Link Reconfiguration Commit (
CFN)
RRC/ RB Setup (DCCH + DTCH,
HS-DSCH information)
The UE is provided with the new radio link

configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration
RRC/ RB Setup Complete
RANAP/ RAB Assignment Response

The RAB is now established. the mobile is now waiting for end-to-end
service accept.
SM/ Activate PDP Context
Figure 6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)
Page 69/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE
Node B
RNC
SGSN
The UE is authenticated by the SGSN

The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:
UIA1 for integrity
UEA1 for ciphering

RANAP/ Security Mode Command (UIAx, UEAy)
RRC/ Security Mode Command
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete
RANAP/ Security Mode

The Radio Access Bearer assignment procedure
RANAP/ RAB Assignment Request (RAB param, binding Id)

NBAP/ Radio Link Reconfiguration Prepare (
E-DPCH info, E-DCH FDD info, E-DCH mac-d flow to add, Serving
E-DCH RL, E-DCH RL indication=E-DCH, E-DCH Specific Info.)
The Radio Link is reconfigured to add the EDPCH in uplink in the serving cell. (The HSDSCH part is not shown)
NBAP/ Radio Link Reconfiguration Ready (E-DCH FDD info Response, E-DCH FDD DL
Control Channel
NBAP/ Radio Link Reconfiguration Commit (

CFN)
RRC/ RB Setup (E-DCH info, E-RNTI,
CFN)
The UE is provided with the new radio link

configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration
RRC/ RB Setup Complete
RANAP/ RAB Assignment Response

The RAB is now established. the mobile is now waiting for end-to-end
service accept.
SM/ Activate PDP Context
Figure 7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)
Page 70/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 71/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE
Node B
RNC
SGSN
GMM/ Deactivate PDP context

GMM/ Deactivate PDP context
The SGSN asks for the release of the corresponding RAB.
In this example, this is the only RAB supported by the mobile
RANAP/ RAB Assignment request (RAB to release)
The radio link is re-configured (only primary cell).

NBAP/ Radio Link Reconfiguration Prepare
(remove HSDPA MAC-d flow)
NBAP/ Radio Link Reconfiguration Ready
NBAP/ Radio Link Reconfiguration Commit
([activation CFN])
RRC/ RB Release (remove HSDPA ; [activation CFN])

RRC/ RB Release Complete
RANAP/ RAB Assignment request response
If isRABRelMgtAllowed is set to "false", the RNC requests for a
global Iu Release.
RANAP/ Iu Release Request
Release of radio bearer and RRC connection
RANAP/ Iu Release Command
RRC/ RRC Connection Release

RRC/ RRC Connection Release Complete
NBAP/ Radio Link Deletion
NBAP/ Radio Link Deletion
All the RLs of the active set are deleted (so

may imply several Node Bs)
RANAP/ Iu Release Complete
SCCP/ Released
Figure 8: Call release (RAB release case)
Page 72/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 9: 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 Preemption). For a session to be maintained in this state, the user traffic
must remain above a predefined threshold: if it falls and stays below
this threshold during a given period of time, the RAB is downsized. A
Page 73/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

session is returned to this state, from Idle mode or downsized mode,
if:
User traffic is resumed (from Idle, CELL_PCH or URA_PCH

states)
User traffic exceeds

CELL_FACH state).
A new call (CS or PS) is established
pre-defined
threshold
(from
Downsized Mode: In this state the session is operating with a

downgraded (from a bandwidth perspective) RB compared to the one
that was originally allocated by the RAB Matching Algorithm. A
session is downgraded to the downsized mode from the normal mode
if user traffic falls and stays below a pre-defined threshold for a given
period. This downsized state contains the following two sub-steps:
AO Step 1, for the case where CELL_FACH is used (PS8 is no

more supported as an Always ON downsized configuration
from UA5 except for multiservices RAB)
AO Step 2, for the case where CELL_PCH or URA_PCH is

used.
Idle Mode: In this state the session has released all its radio
resources and the RRC context, but the PDP context is still maintained
by the Core Network. A session is downgraded to Idle mode if there
has been no user traffic for a given (provisionable) period of time.
This state is also known as AO Step 3 (and was previously referred
to as AO Step 2).
Page 74/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The simplified state transitions are shown in Figure 9.
Normal mode
AO Step 1
AO Step 2
AO Step 3
Release
(Tinactivity expiry)
Downsizing
(Tdownsize expiry)
URA_PCH
Normal
mode
Idle
mode
CELL_FACH
Upsizing
(Traffic
resuming)
CELL_PCH
Downsized mode
RB R-establishment
(Traffic resuming)
(Tinactivity expiry)
Figure 9: AO state transitions

For more details on Always ON transitions, see UPUG [R01]
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:
Parameter
RAN Path
Range & Unit
User
Class
Value
First, Always-on has to be activated on RNC :
isAlwaysOnAllowed
Object
RNC / RadioAccessService / AlwaysOnConf
Boolean
{True, False}
Customer
Granularity
3
AlwaysOnConf
RNC
False (de-activate the feature)

True (activate the feature)
Page 75/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Then, Always-on has to be activated on user service:
isAlwaysOnAllowed
Parameter
RAN Path
Range & Unit
Object
Boolean
{True, False}
Customer
Granularity
3
User
Class
Value
User
Class
Value
DlUserService
See table below
DlUserService
CS_64KxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_HSDSCHxSRB_3_4K
PS_16K_STRxPS_HSDSCHxSRB_3_4K
PS_HSDSCHxSRB_3_4K
Parameter
RAN Path
Range & Unit
DlUserService
isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True
True
True
The suitable Always-on mode has to be set on RB configuration:
isAlwaysOnAllowed
Object
RNC / RadioAccessService / DlRbSetConf
Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
Customer
Granularity
3
DlRbSetConf
DlRbSetConf
See table below
DlRbSetConf
PS_HSDSCH_IB
PS_HSDSCH_IB_MUX
isAlwaysOnAllowed
degraded2AlwaysOnOnly
releaseOnly
Rule: Eligibility of RbSetConf to Step 2 mechanism

Multi-service calls are not allowed to the 2 steps Always-on mechanism. Hence for the
PS_HSDSCH_IB_MUX,
the
parameter
isAlwaysOnAllowed shall not be set to
degraded2AlwaysOnOnly, but to releaseOnly.
Page 76/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For E-DCH, the corresponding parameters are:
Parameter
RAN Path
Range & Unit
User
Class
Value
isAlwaysOnAllowed
Object
RNC / RadioAccessService / UlUserService
Boolean
{True, False}
Customer
Granularity
3
User
Class
Value
UlUserService
See table below
UlUserService
CS_64KxPS_EDCHxSRB_3_4K
CS_AMR_NBxPS_16K_STRxPS_EDCHxSRB_3_4K
PS_16K_STRxPS_EDCHxSRB_3_4K
PS_EDCHxSRB_3_4K
Parameter
RAN Path
Range & Unit
UlUserService
isAlwaysOnAllowed
isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True
Object
RNC / RadioAccessService / UlRbSetConf
Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
Customer
Granularity
3
UlRbSetConf
UlRbSetConf
See table below

UlRbSetConf
PS_EDCH
PS_EDCH_MUX
isAlwaysOnAllowed
degraded2AlwaysOnOnly
releaseOnly
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.
Page 77/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
The new RRC states are activated by the operator:
PchRrcStates
Object
RadioAccessService
Enumeration
{none, UraPchEnabled, CellPchEnabled, UraAndCellPchEnabled}
Customer
Granularity
3
Parameter
RAN Path
Range & Unit
User
Class
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]
Rule: PchRrcStates = UraPchEnabled or UraAndCellPchEnabled
If URA_PCH state is activated (PchRrcStates = UraPchEnabled or UraAndCellPchEnabled), then the
Enhanced URA_PCH Paging feature (PM108388) should also be activated. For more details on
eURA_PCH Paging feature see UPUG [R01].
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
Step 2: The user is further downsized after a period T2 of inactivity.

There is one timer per target downsized state. Hence the new
parameters fachToCellPchTimer and fachToUraPchTimer
Step 3: In URA_PCH or CELL_PCH the user does not have a DTCH

assigned, hence it is not possible to measure activity at RLC/MAC
level. The user is released after a period T3 of inactivity. As the
decision can be taken in either the Cell FACH, URA_PCH or Cell_PCH
state, there is one timer per source state. Hence the algorithm uses
the new parameters cellPchToIdleTimer / uraPchToIdleTimer.
Page 78/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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
Always-on (degraded2AlwaysOnOnly, PchRrcStates none)

Activity (UL or DL)
Low activity /
Inactivity
Downsize
(step 1)
DL DCH / UL DCH
DL HSDPA / UL DCH
DL HSDPA / UL E-DCH
Downsize
(step 2)
Inactivity
CELL FACH
Downsize timer
Step 1 (timerT1,
timerT1ForHsdpa,
timerT1ForHsdpaAndEDch)
Downsize
timer
Step 2
(fachToCellPchTimer,
fachToUraPchTimer)
Downsize
(step 3)
Inactivity
CELL PCH / URA PCH
Idle
No dedicated radio resource,

only RRC context
Downsize
timer
Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)
Traffic UL/DL
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates

none)
The downsize condition is the same as for R99.

When downsizing to CELL_FACH, if no resource are available (CAC failure on
FACH), the call is released (as in R99).
When Cell/URA_PCH states are activated and Always-on mode is set to
releaseOnly, there are 2 possibilities:
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;
Page 79/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.
Always-on (degraded2AlwaysOnOnly, PchRrcStates = none)
Activity (UL or DL)
Low activity /
Inactivity
Downsize
Release
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH
Downsized RB (CELL_FACH)
Downsize
timer
(timerT1ForHsdp
Release timer
(timerT2)
Traffic UL/DL
Figure 11: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates

= none)
Release only (1 step)
In this mode, the Always-on feature directly releases the user after a period T2 of
inactivity. The timers used are:
o timerT2ForHsdpa in case of HSDPA only
o timerT2ForHsdpaAndEdch in case HSDPA & DCH are both activated.
Page 80/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Always-on (releaseOnly)
Activity (UL or DL)
Low activity
Inactivity
Release
HSDPA + UL DCH
HSDPA + E-DCH
t
Release timer
(timerT2ForHsdpa
Traffic UL/DL
Figure 12: Always-on for HSDPA/E-DCH (releaseOnly mode)
Note: for PS I/B Mux, the releaseOnly mode is mandatory as PS I/B Mux is not
supported on FACH and does not lead to release but there is a direct transition from
CELL_DCH to CELL_PCH or URA_PCH mode (if activated).
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).
T2 timer used is: timerT2ForHsdpa (UL
timerT2ForHsdpaAndEdch (UL E-DCH / DL HSDPA).
The
DCH
DL
HSDPA)
or
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 resources are available (in case of CAC
failure) the call may be fallback to DCH (feature 32602).
Page 81/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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)
timerT1ForHsdpa
timerT1ForHsdpaAndEDch
timerT2
NA
timerT2ForHsdpa
Always-on mode
T1 ( =>CELL_FACH)
T2 ( => Idle)
HSDPA / E-DCH
PS I/B Mux+ SRB
HSDPA / DCH
timerT2ForHsdpa
UL E-DCH / DL HSDPA
timerT2ForHsdpaAndEdch
CS + PS I/B (Mux) + SRB

Always-on mode
T1 ( => CS + PS8)
T2 ( => CS)
NA
timerT2ForHsdpa (1)
NA
timerT2ForHsdpa (1)
D
HSDPA / E-DCH
R
HSDPA / DCH (Mux)
(1)
(1)
Table 5: 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 82/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Second case when x_PCH is activated (PchRrcStates none):
PS I/B + SRB
Always On
Mode
T1 (=> CELL_FACH)
T2 (=> Cell/URA_PCH)
timerT1ForHsdpa
fachToCellPchTimer/
timerT1ForHsdpaAndEdch fachToUraPchTimer
NA
T3 (=> Idle)
cellPchToIdleTimer/
uraPchToIdleTimer
HSDPA / E-DCH
timerT2forHsdpa
timerT2forHsdpaAndEdch
cellPchToIdleTimer/
uraPchToIdleTimer
PS I/B Mux+ SRB

Always On
Mode
T1 (=> CELL_FACH)
T2 (=> Cell/URA_PCH)
tDchPchMpdpForHsdpaAndDc
h (1)
HSDPA / DCH
R
UL E-DCH / DL
HSDPA
;
tDchPchMpdpForHsdpaAndEd
ch
T3 (=> Idle)
uraPchToIdleTimer/
cellPchToIdleTimer
CS + PS I/B (Mux) + SRB

Always On
Mode
T1 (=> CS+PS8)
T2 (=> CS + PS 0)
T3 (=> Idle)
timerT2ForHsdpa
uraPchToIdleTimer/
cellPchToIdleTimer
NA
timerT2ForHsdpa
timerT2ForHsdpaAndDch
uraPchToIdleTimer/
cellPchToIdleTimer
HSDPA / E-DCH
HSDPA / DCH
(Mux)
Table 6: 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 83/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

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.

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,
RAN Path
Range & Unit
User
Class
Value
RNC / RadioAccessService / AlwaysOnConf / AlwaysOnTimer

[10..3600000] (ms)
Customer
Granularity
OLS
3
Object
AlwaysOnTimer
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
RAN Path
Range & Unit
User
Class
Value

[1..3600] (s)
Customer
Granularity
OLS
3
Object
AlwaysOnTimer
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 84/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
timerT2ForHsdpa,
RAN Path
Range & Unit
User
Class
Value

[10..10800000] (ms)
Customer
Granularity
OLS
3
Object
AlwaysOnTimer
10000
Note: The timerT2ForMultiRabHsdpa was used in UA5.x. From UA6 onwards 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
RAN Path
Range & Unit
User
Class
Value

[1..7200] (min)
Customer
Granularity
OLS
3
Object
AlwaysOnTimer
182
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
RAN Path
Range & Unit
User
Class
Value
nbOfCellUpdatesFromCellPchToUraPch
[1..65535]
Customer
3
Object
RadioAccessService
Granularity
RNC
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.
Page 85/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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.
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.
When the feature Fair Sharing is activated, OVSF codes load is computed following
the usual formula:
Code _ Load = 1
1
NumberOfFreeCodesPerSpreadingFactor n * SF / 16
*
NumberOfSpreadingFactors All _ SF
SF
Where n*SF/16 represents the codes that are reserved for HSDPA users at SF level (n
being a number of SF16 codes).
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 HSDSCH 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.
Page 86/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 [R01], volume 14.
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:
NodeB DL radio resources not available
NodeB UL radio resources not available
Dedicated
NodeB resources not available

RNC DL code resources not available
RNC DL power resources not available
Eligible CAC
Failures
Shared
1 Steps / 2 Steps
Eligible
Services
R99
Preemption
RAB Assignment
Queuing allowed
RRC connection request
HSUPA
HSDPA
Inter-Frequency intraRNC Radio Link setup
Speech
; Preemption
Video telephony
Capability
CS Streaming
Always-on Upsize
Radio Link Addition
Emergency Call
; Preemption
PS Streaming
Queuing not
Signaling PS Interactive
allowed
PS Interactive
Vulnerability
; Priority (*)
PS Background
(IMCTA CAC, iMCTA

Alarm)
Incoming relocation does not trigger
Eligible
procedures
(*) + OLS at user level
preemption in the target RNC
Figure 13: 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 87/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

33322
Upon CAC Failure
Preemption
Shared resources (R99 & HSDPA) : OVSF Codes & DL Power

Dedicated resources : CEM (Node B)
33694
Fair sharing of
resources
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)
29804
GBR on HSDPA
Power consumption Node B feedback to RNC (needed for fairsharing)
Figure 14: 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 HSDSCH 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 88/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
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 89/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Will be triggered first for HSxPA incoming users.
32602
HSxPA to DCH
fallback
Depending on CAC failure, fallbacks 1 step / 2 steps may be

tried :
DL HSDPA / UL R99
DL DCH / UL DCH
29415
iMCTA CAC &
Alarm
33322
Preemption
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 15: 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 90/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
isPreemptionAllowedForHsdpa: This parameter is used to activate/deactivate pre-emption process for UL DCH/DL HSDPA calls.
Parameter
isPreemptionAllowedForHsdpa
Object
PreemptionAllowedInfo
Granularity
RNC
RAN Path
RNC / RadioAccessService / PreemptionAllowedInfo
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/deactivate pre-emption process for UL E-DCH / DL HSDPA.
Parameter
isPreemptionAllowedForEdch
Object
PreemptionAllowedInfo
Granularity
RNC
RAN Path
RNC / RadioAccessService / PreemptionAllowedInfo
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 91/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9 F-DPCH AND SRB OVER HSPA

F-DPCH was introduced in 3GPP Rel.6 mainly to support higher VoIP over HSDPA
capacity, but it may also be used for other services mapped on HSDPA. Enhancements
were approved in 3GPP Rel.7 to ease the implementation and improve the efficiency
in soft handover.
In W-CDMA Rel.5 HSDPA the fraction of the base station power used for signalling is
relatively high for low bit rate services such as VoIP, and a possible solution is using
fractional dedicated channel (F-DPCH) which is a new physical channel that only
carries the UE specific TPC bits. This allows removing the mandatory presence of a
dedicated physical channel (OVSF) for each data only HSDPA user and consequently
reduce the code and power resources usage.
Up to 10 users can share a single SF256 code instead of being allocated a regular
SF256 dedicated DCH (however, for typical interactive and background applications
with few concurrent users, the savings are minimal). Apart from releasing resources
for data transport, a result of the change to F-DPCH is that signalling will become
faster.
Based on the SRB RAB matching algorithm, the SRB will be mapped onto an UL and
DL transport channel (the uplink E-DCH is always used in conjunction with the HSDSCH in the downlink). Mapping the SRB over HSPA allows for reducing the RRC
messages transfer delay with an expected benefit in term of call setup duration and
RB reconfiguration time.
SRB will consume more instantaneous power resources when mapped over HSDPA,
but as the SRB activity is low, the impact on HSDPA performance is not expected to
be significant.
SRB over HSDPA does not benefit from macro diversity.
9.1 STRATEGY, IMPLEMENTATION AND FEATURE BENEFITS

F-DPCH feature is implemented based on 3GPP Rel.7 requirements (enhanced FDPCH), which includes a full management of macro-diversity with optimised F-DPCH
code saving efficiency. Consequently, the F-DPCH support is available for Rel.7 UEs,
while Rel.6 UEs will still be allocated a DCH.
SRB over HSPA and F-DPCH are configured simultaneously:
F-DPCH is used when there is no DL DPCH, so the SRB is required to be
mapped on HS-DSCH to allow F-DPCH;
SRB is mapped on HSPA if and only if F-DPCH is used (this is a design
choice to avoid too many configurations);
If a DCH is configured for any service reason, then the SRB shall be
mapped on DCH.
Page 92/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The F-DPCH channel selection with SRB over HSPA is made at RRC Connection
establishment phase.
F-DPCH is intended to provide codes saving, although these are not expected to
largely improve the cell and users throughput, because best effort data traffic as
HSDPA is typically running in a power limited regime. SRB on HSDPA management is
an enabler to take advantage of F-DPCH and thus to target OVSF code saving in DL.
SRB on HSDPA provides enhanced user experience with reduction time for PS
establishment, reconfiguration and PDP context activation. Mapping the SRB over
HSPA allows for reducing the RRC messages transfer delay with an expected benefit in
term of call setup duration and RB reconfigurations time.
9.2 BACKGROUND INFORMATION

9.2.1 OVERVIEW OF F-DPCH
Fractional DPCH introduces a new dedicated physical channel which has only control
information (DPCCH), so the control information is limited to TPC bits only (TFCI bits
are not required as there is no DPDCH). Pilot bits have also been removed and DPCH
synch estimation is performed on the TPC bits.
This new channel leaves space for up to 10 users to be multiplexed onto one SF256
code:
CPICH
F-DPCH for UE5
TF-DPCH(UE5)
Tx Off TPC
Tx Off
256 chips
1 slot = 2560 chips
F-DPCH for UE4
TF-DPCH(UE4)
Tx Off TPC
Tx Off
256 chips
1 slot = 2560 chips
Bit stream sent by the

Node B on the OVSF code
TPC
UE1
TPC
UE2
TPC
UE3
TPC
UE4
TPC
UE5
TPC
UE6
TPC
UE7
TPC
UE8
TPC TPC
UE9 UE10
Figure 16: F-DPCH multiplexing
Users are multiplexed on the same OVSF code by using different time offsets, defined
by TF-DPCH and this scheme is repeated every slot (TF-DPCH represents the shift of the
F-DPCH frame towards the P-CCPCH frame). In DL, on this code, the Node B
transmits the TPC bits of UE 1, then TPC of UE2, etc.
Page 93/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Because there is no DCH transmission (no DPDCH), the application of F-DPCH requires
SRB to be carried over HSDPA.
In 3GPP Rel.6, the possibility of allocating up to 10 UEs per F-DPCH channel is
managed by using different F-DPCH timing offsets for each UE. However, due to
macro diversity, there is a potential conflict between UEs for the allocation of an FDPCH because the timing offsets of the next radio-links of the active set cannot be
freely chosen (the different radio-links must be aligned within a time window of 148
chips at the UE). This induces a complex allocation scheme on the UTRAN side and
drastically lowers the F-DPCH OVSF code efficiency.
The enhanced solution in 3GPP Rel.7 (eF-DPCH) includes the following improvements:
TPC command combining requirement has been relaxed (there is no need
to align all F-DPCH information sent to one UE on all its Radio Links;
Introduction of a new F-DPCH slot format table with slot formats from 0 to
9 to take benefit from the above condition.
With the enhanced F-DPCH, if two UEs are allocated the same F-DPCH frame offset
(due to macro diversity) then they can share the same F-DPCH channel by using
different slot formats. At UE level the TPC combination with F-DPCH of different RL
with different F-DPCH slot formats is now possible (TPC bits from different radio links
may be received during a large time window).
9.2.2 FRAME STRUCTURE AND SLOT FORMATS

The structure of the F-DPCH frame is shown below (Rel6 F-DPCH or e-FDPCH):
Tx Off
(NOFF1 bits)
TPC
(NTPC bits)
Tx Off
(NOFF2 bits)
TSlot = 2560 chips
Slot #0 Slot #1
Slot #i
Slot#14
1 Radio Frame: Tf = 10ms
Figure 17: Rel.6 F-DPCH frame structure
It is similar to the one of the DL DPCH frame, with empty DPDCH (no data bits) and
no TFCI and pilots bits in the DPCCH:
Page 94/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

DPDCH
DPCCH
Data 1
(NData1 bits)
TPC
(NTPC bits)
DPDCH
TFCI
(NTFCI bits)
DPCCH
Data 2
(NData2 bits)
Pilot
(NPilot bits)
TSlot = 2560 chips, 10 * 2k bits (k = 0 .. 7)
Slot #0 Slot #1
Slot #i
Slot#14
1 Radio Frame: Tf = 10ms
Figure 18: DL DPCH frame structure
The slot formats of eF-DPCH are defined as below:

Slot Format Channel Bit Channel Symbol
#i
Rate (kbps)
Rate (ksps)
Spreading
Factor
Bits / Slot
NOFF1
Bits / Slot
NTPC
Bits / Slot
NOFF2
Bits / Slot
1.5
256
20
16
1.5
256
20
14
1.5
256
20
12
1.5
256
20
10
1.5
256
20
10
1.5
256
20
12
1.5
256
20
14
1.5
256
20
16
1.5
256
20
18
1.5
256
20
18
Table 7: F-DPCH slot formats (#1 and #2 formats are not used)
With eF-DPCH, the position of the TPC bits in the slot depends on the slot format
(NOFF1). In comparison, F-DPCH Rel.6 uses only slot format #0 and each user is
assigned a time offset (F-DPCH Frame Offset) which defines the position of the TPC
bits.
From a Node B perspective, a Node B that is able to manage Rel.7 F-DPCH is also able
to manage Rel.6 F-DPCH, as Rel.6 F-DPCH is seen as a Rel.7 F-DPCH that is
configured with slot format #0.
9.2.3 F-DPCH TIMINGS

The F-DPCH timing offset of the radio link is defined by TF-DPCH and the DL DPCH
timing offset is defined by TDPCH . Both are expressed in chips and define the offset
to the beginning of the P-CCPCH frame, with a granularity of 256 chips:
The DPCH timing may be different for different DPCHs, but the offset from
the P-CCPCH frame timing is a multiple of 256 chips, i.e. TDPCH = Tn * 256
chip, Tn {0, 1, 2, , 149};
Page 95/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The F-DPCH timing may be different for different F-DPCHs, but the offset
from the P-CCPCH frame timing is a multiple of 256 chips, i.e. TF-DPCH = Tp
* 256 chip, Tp {0, 1, 2, , 149}.
Even though with F-DPCH there is no DL DPCH, the CFN is still needed (for SRLR and
CM activation) and this defines the start of the UL DPCCH (the UE starts the emission
of the UL DPCCH frame 1024 chips after reception of DPCH/F-DPCH frame), UL HSDPCCH and UL E-DPCCH/E-DPDCH.
On the Node B side, TF-DPCH is signalled on NBAP to define the start of the F-DPCH
frame (Chip Offset IE) and, in case of 3GPP Rel.7, the slot format is also signalled (FDPCH Slot Format IE), and defines the transmission time of the TPC bits in the FDPCH frame.
Primary SCH
Secondary SCH
CPICH
P-CCPCH
nth DPCH
pth F-DPCH
Radio Frame with SFN mod2 = 0
Radio Frame with SFN mod2 = 1
TDPCH
TF-DPCH
10ms
10ms
Figure 19: F-DPCH timings
9.2.4 SYNCHRONISATION
For R99 channels (DCH and CCH), the SRNC determines for each frame in downlink
the CFN when the frame should be sent on the radio, meaning that it has to send
the frame to the Node B sometime before the CFN is actually transmitted on the radio
interface. This is the Transport channel synchronisation procedure.
This procedure allows:
Getting the variable part of the downlink delay (transport, time-drifting
between RNC and Node B clocks);
Page 96/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Get the fixed part of the downlink delay (radio processing time).
To achieve this, the Node B manages a receiving window and informs the RNC to
increase or decrease its anticipation (TIMING ADJUSTMENT frame) when the Node B
receives a frame outside of its receiving window (either too late or too soon).
147
148
149
150
151
152
153
154
CFN
SRNC
DL DATA FRAME
[CFN = 150]
TIMING ADJUSTMENT
[TOA = -5.250ms]
CFN
Node B
147
148
149
150
151
152
153
154
TOA
Receiving Window
Figure 20: Timing adjustment procedure

The RNC can also use the DL SYNCHRONISATION frame to achieve the same effect
(no need to send a DATA frame). In this case, SRNC tells which CFN it is targeting
and Node B answers by the delta (0.125ms granularity) between the reception time of
the DL SYNCHRONISATION frame and the time of the targeted CFN. This can be used
once the radio link has been setup before data is sent to the Node B, or to maintain
the synchronisation when there is no data to transmit. The interest is also to get
precise information about the Node B CFN (not only when data are received outside
the Node B receiving window).
147
148
149
150
151
152
153
154
CFN
SRNC
DL SYNCHRONISATION
[CFN = 151]
UL SYNCHRONISATION
[TOA = 5.750ms]
CFN
Node B
147
148
149
150
151
152
153
154
TOA
Receiving Window
Figure 21: Transport channel synchronisation procedure

There is another possibility to get the synchronisation between the RNC and the Node
B, which is the Node Synchronisation procedure (used in case for the F-DPCH and SRB
on HSPA configuration).
The aim of this procedure is to get the SFN synchronisation (and not the CFN one),
from which the RNC can derive the CFN. It is important to perform the node
synchronisation on the right transport bearer because transport delays have to be
taken into account.
SRNC sends a DL NODE SYNCHRONISATION frame with a timestamp T1 (RFN) and
the Node B answers by an UL NODE SYNCHRONISATION frame, indicating the time of
Page 97/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

reception T2 (BFN) and saying at which time (T3) the answer was sent (time
resolution is 0.125 ms). Based on T1 and T2, the RNC will be able to calculate the
Current CFN and derive the Activation CFN. The addition of the two paths, (T2 - T1) +
(T4-T3) provides the Round Trip Delay.
4094
T1
4095
T4
RFN
SRNC
DL NODE
SYNCHRONISATION
[T1 = 40941.250]
UL NODE SYNCHRONISATION
[T1 = 40941.250, T2 = 1492.500, T3 = 1505.000]
BFN
Node B
147
148
149
T2
150
T3
151
152
153
154
Figure 22: Node synchronisation procedure
9.3 FEATURE DESCRIPTION

9.3.1 F-DPCH CODE ALLOCATION
F-DPCH uses SF=256 and requires a special handling because a code used for F-DPCH
may be shared by up to 10 users, the constraint being that the TPC bits of the
different users that are sharing the same code shall not be transmitted at the same
time by the Node B.
The transmission time of the TPC bits for one user depends on the F-DPCH frame
offset (defines the beginning of the frame versus SFN=0) and the F-DPCH slot format
(defines the position of the TPC bits inside the F-DPCH frame).
It is important to notice that two different users may use the same slot format as long
as their F-DPCH frame offsets are different.
CPICH
CPICH
TF-DPCH(UE0)
UE0
UE1
NOFF1
TF-DPCH(UE1)
NOFF1
TPC
TPC
NOFF2
NOFF1
NOFF2
NOFF1
TPC
TPC
NOFF2
NOFF2
Pos #0 Pos #1 Pos #2 Pos #3 Pos #4 Pos #5 Pos #6 Pos #7 Pos #8 Pos #9 Pos #0 Pos #1 Pos #2 Pos #3 Pos #4 Pos #5 Pos #6 Pos #7 Pos #8 Pos #9 Pos
Slot Duration = 2560 chips
Figure 23: Position of the TPC bits for one given OVSF code
Page 98/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The allocation of OVSF codes is done by the CRNC in several steps:
1) Find an OVSF code where it is possible to allocate the F-DPCH for this user;
2) Select a position in this OVSF code;
3) Determine the F-DPCH slot format from the position that has been allocated.
When a code is needed to a new F-DPCH user, the CRNC shall find the first SF256
code from CCh,256,0 that fulfils the following conditions:
C1 The OVSF code is free (not allocated or blocked);
C2 The OVSF code is already allocated to one or more F-DPCH users, is
not full (has less than 10 F-DPCH users) and contains a free slot format
entry allowed for the new user.
When an F-DPCH call is released, the OVSF code shall be released (become free) if
there are no other remaining F-DPCH calls using the same code.
The advantage of such algorithm is that F-DPCH users will be grouped on the top of
the tree and will not be spread anywhere in the OVSF code tree, as it would
dramatically reduce the throughput of HSDPA users with the Fair Sharing of Resources
feature (this is the main interest of condition C1).
If the allocation fails (no SF256 code is found) then the establishment of the RAB or
RRC connection will be refused (it is not necessary a retry on DCH, as no code will be
found either).
Start From First Code
Position in OVSF code:

Bitmap (10 bits): 1 = free, 0 = allocated
0000000000 if code already allocated to
non F-DPCH or blocked
NOK: go to next
OVSF code
=0
AND
=1
OK: allocate one of

the possible positions
Positions that are allowed for this call:

Bitmap (10 bits): 1 = allowed, 0 = forbidden
eF-DPCH: 1111111111 (all allowed)
Rel.6 F-DPCH: 1111111111 (all allowed, if no macro diversity)
Rel.6 F-DPCH: xxxxxxxxxx (one allowed, if macro-diversity)
Figure 24: F-DPCH code allocation mechanism
For each OVSF code used for F-DPCH, the CRNC shall manage a bitmap of 10 entries
where each entry represents one position of the TPC bits for a UE in one radio link,
Page 99/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

specifically the time offset versus P-CCPCH, which depends on the F-DPCH frame
offset and slot format.
Selecting different entries for different users means that the Node B will transmit the
TPC bits for these users at different times, as required. Position #0 corresponds to the
TPC bits being sent right after the start of the P-CCPCH frame, position #1
corresponds to the TPC bits sent 256 chips (2 bits) after the P-CCPCH, and so on.
Note: Macro diversity case for Rel.6 F-DPCH

In case of macro diversity, for a Rel.6 F-DPCH call, there is a constraint when
selecting the entry in the bitmap, because TPC bits shall be received within a certain
time window at the UE (128 chips), thus the TF-DPCH of the different radio links
cant be chosen arbitrarily.
For Rel.6 F-DPCH the position of the TPC bits is 256 chips after the beginning of the
slot (equivalent to slot format #0), the position in the bitmap that shall be allocated to
the radio link is constrained and equals to (TF-DPCH + 256) / 256 modulo 10.
This means that the bitmap with the positions that are allowed for the call will be 0 for
all bits but one, that will be equal to 1: bitmap (allowed positions) = 1 for bit (TF-DPCH
+ 256) / 256 modulo 10.
The CRNC must then select and OVSF code in which this entry is free.
9.3.2 POWER CONTROL

TPC commands received by the UE from different radio links (in case of soft
handover) during the combining period (1 slot = 2560 chips) are combined to derive
one single TPC command per slot. The TPC combining period starts 512 chips after
the beginning of the F-DPCH slot.
For Rel.6 F-DPCH, the TPC commands received from different radio links shall be
aligned in time (by setting an adequate frame offset) as for R99 DPCH, thus the
UTRAN does not have the possibility to determine freely the frame offset of each radio
link.
This constraint is lifted by Rel.7 in the sense that the TPC bits can be moved (by the
slot format) without modifying the frame offset.
When in softer handover operation the radio links composing the radio link set (RLS)
may be shifted by up to 512 chips, 2 TPC symbols, at the Tx (because of RRH or
because 256 chip rounding operation on NBAP).
The TPC bits, for the same slot, may be received on different TPC combining periods
in the UE. TPC symbols received by the UE in a given combining period from the same
Node B may be different, whereas they should be the same.
At the Tx level, the Node B generates one TPC symbol updated once per slot at the
beginning of symbol #2 of the latest radio link, common to all radio links of the RLS
so, to avoid this situation, TPC commands shall not be sent on TPC symbols #2 or #3
(slot formats #1 or #2).
Page 100/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The situation to avoid is TPC commands generated in the same period (delimited by
symbol #2 of the latest radio link at Tx) being received in different combining periods
at the UE (delimited by symbol #2 of the latest radio link at Rx).
Alcatel-Lucent RNC will never make use of slot formats #1 and #2 and it will remove
the corresponding positions in the bitmap (allowed positions), prior to OVSF code
selection. However, this does not mean that only 8 users can be multiplexed on a
single code, as other users may use this space through a suitable manipulation of
TF-DPCH and slot format.
9.3.3 NODE B CAPABILITY

F-DPCH is managed by xCEM, UCUIII and eCEM and it is not managed on iCEM. The
eF-DPCH capability is reported by the Node B for each local cell/local cell group in the
NBAP RESOURCE STATUS INDICATION and NBAP AUDIT RESPONSE messages (FDPCH Slot Format Capability IE = Slot Format Capable).
A call can be mapped to both xCEM and iCEM for the management of DCH but, as
there is no call migration (change of CEM board) during the call, it is important to map
on xCEM all the calls that might be later reconfigured to F-DPCH if F-DPCH is not used
at RADIO LINK SETUP. For that, the RNC will inform the BTS that a call is eligible to
F-DPCH by setting the optional F-DPCH Slot Format IE (value 0) in the NBAP RADIO
LINK SETUP message, even if F-DPCH is not configured.
When receiving this, the Node B will preferentially map the call on an xCEM, but if
there is not enough capacity it will map it on an iCEM (in this case, if later on the call
is reconfigured to F-DPCH by the RNC, the Node B will fail the reconfiguration with
cause F-DPCH not supported and the RNC will reconfigure the SRB to DCH but keep
TRB on HSPA).
Alcatel-Lucent RNC will only consider eF-DPCH capability (Rel.7) but not the Rel.6 FDPCH capability so, if a Node B reports only the Rel.6 F-DPCH capability the RNC will
ignore it and will never map calls on F-DPCH for this Node B.
The OneBTS will ignore the optional F-DPCH Slot Format IE (value 0) in the NBAP
RADIO LINK SETUP message if F-DPCH is not configured as a subsequent
reconfiguration from DPCH to F-DPCH is supported.
9.3.4 CRITERIA FOR SRB MAPPING ON HSPA

The criteria for the SRB to be mapped on HSPA are the following (these are applicable
to all the cells of the active set):
MAC-ehs must be selected for the call.
The UE supports F-DPCH, which is indicated in the RRC CONNECTION
REQUEST message in the following information elements:
o
Support for F-PDCH IE = True
UE Capability Indication IE = HS-DSCH+E-DCH;
Page 101/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

o
Access Stratum Release Indication IE = Rel-7 (or later).
F-DPCH is configured on all cells of the active set through OAM parameter
isSrbOverHspaEnabled set to True in objects RadioAccessService,
FDDCell, NeighbouringRNC and RemoteFDDCell (for the cases of
NeighbouringRNC and RemoteFDDCell this attribute is not used for UA08,
as there is no F-DPCH support over Iur)
Radio conditions are good enough:
o
For call setup, these are based on Measured Results on RACH IE in

the RRC CONNECTION REQUEST message;
The value is either RSCP or Ec/No, according to the configuration and
is compared to new thresholds srbOverHspaRscpThreshold and
srbOverHspaEcNoThreshold (hysteresis is also introduced through
parameters
srbOverHspaRscpHysteresis
and
srbOverHspaEcNoHysteresis);
For other triggers, radio conditions are verified each time
measurements are received from the serving cell, either event
triggered or periodic (as for RACH, the value is compared with the
respective threshold);
If the radio conditions are below threshold hysteresis, the SRB is
reconfigured on DCH.
Parameters are introduced in RadioAccessService object to enable/disable

SRB on HSPA per traffic class (in case of multi-service, SRB on HSPA is
allowed if it is enabled on each service individually):
o
isSrbOverHspaEnabledForPsIb;
isSrbOverHspaEnabledForPsConversational;
isSrbOverHspaEnabledForPsStreaming;
isSrbOverHspaEnabledForCs;
isSrbOverHspaEnabledForSignaling.
The establishment cause is checked, in case of an RRC connection

procedure not used for other triggers and SRB will be mapped on
HSPA according to the following table. Configurations for conversational
services are not supported in UA08.1, either on Cs or Ps domain.
Streaming configurations are not specified, implemented nor tested, so
also not supported. All these cases are marked in pink in the table below.
Page 102/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Establishment Cause in RRC CONNECTION REQUEST
SRB over HSPA at RRC Connection Setup
Originating Conversational Call
Yes (Domain = Ps and isSrbOverHspaEnabledForPsConversational = True

or Domain = Cs and isSrbOverHspaEnabledForCs = True)
Originating Streaming Call
No (even if isSrbOverHspaEnabledForPsStreaming = True)
Originating Interactive Call
Yes (isSrbOverHspaEnabledForPsIb = True)
Originating Background Call
Originating Subscribed Traffic Call
No
Terminating Conversational Call
Yes (Domain = Ps and isSrbOverHspaEnabledForPsConversational = True

or Domain = Cs and isSrbOverHspaEnabledForCs = True)
Terminating Streaming Call
No (even if isSrbOverHspaEnabledForPsStreaming = True)
Terminating Interactive Call
Terminating Background Call
Emergency Call
No
Inter-RAT Cell Reselection
No
Inter-RAT Cell Change Order
No
Registration Detach
No
Originating High Priority Signalling
Yes (isSrbOverHspaEnabledForSignaling = True)
Originating Low Priority Signalling
Call Reestablishment
No
Terminating High Priority Signalling
Terminating Low Priority Signalling
Terminating Unknown
No
MBMS Reception
No
MBMS Point to Point RB Request
No
Table 8: RRC establishment causes for SRB on HSPA configuration

All these criteria (last one only applicable to RRC connection phase) are
applied each time there is a change in the call:
o
RRC connection setup;
RAB establishment, release and modification;
Mobility;
Always-On;
Reception of Measurement Reports.
Note: Interaction with feature PM33581 SRB on E-DCH during the call
Feature PM33581 is no longer applicable for eligible to F-DPCH calls. This means
that SRB DCH/E-DCH configuration will not be used if the call is eligible to F-DPCH
(for this case, the configuration will be SRB on HSPA).
When the call is eligible to F-DPCH, the SRB can only be reconfigured between
HS_DSCH/E-DCH and DCH/DCH. For calls that are not eligible to F-DPCH, the SRB
can change between DCH/E-DCH and DCH/DCH.
This scenario is possible in case of activation of feature at cluster level. Since the
activation of the feature is done at RNC and cell level, through flags
isSrbOverHspaEnabled (under RadioAccessService) and isSrbOverHspaEnabled
(under FDDCell), respectively, it is possible that there will be a mix of cells in the RNC
with the activation flag ON and OFF.
As such, it may happen that some UEs that are F-DPCH capable wont benefit of SRB
on EDCH in the cells on which the activation flags are OFF.
Page 103/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
9.3.5 SRB ON HSPA IN RRC CONNECTION, RAB ESTABLISHMENT

AND RAB RELEASE
9.3.5.1 RRC CONNECTION
At call setup, upon reception of RRC CONNECTION REQUEST message, the RNC
checks the different criteria and, if all the conditions are fulfilled, the call is fully
established on F-DPCH/HSPA, for the F-DPCH capable UEs of 3GPP Rel-7 or later
(indicated in RRC CONNECTION REQUEST message).
As the UE category is not known at this stage, the call is established on E-DCH using
10ms TTI (lowest category 11 for HSDPA and category 1 for E-DCH is assumed).
After reception of RRC CONNECTION SETUP COMPLETE the UE category is checked
(Physical Channel Capability in UE Radio Access Capability IE) and if the E-DCH
category is 2, 4 or 6, the UE will be reconfigured to 2ms TTI at next RAB
establishment, if possible. If the HSDPA category is not 11 (default used/assumed),
then at the next RAB establishment the UE will also be reconfigured.
9.3.5.2 RAB ESTABLISHMENT

At RAB establishment phase, the RAB to be established is checked and, according to
the flags that enable or not the RAB support of F-DPCH, the RAB is established on
HSPA with SRB also on HSPA.
The following rules are applied:
An emergency call will always keep the SRB on DCH configuration;
If the RAB to be established does not support F-DPCH according to the
OAM parameters, the SRB is reconfigured to DCH;
MAC-ehs must have been selected for the call, otherwise the SRB is
reconfigured to DCH;
If the cell and the UE support 2ms TTI, the E-DCH part of the call is
reconfigured to 2ms TTI;
If the HSDPA category is not 11 the actual UE category shall be signalled to
the Node B through a RADIO LINK RECONFIGURATION PREPARE.
The eligible RAB combinations for SRB on HSPA are the following:
Standalone SRB over E-DCH/HS-DSCH;
PS I/B over HSPA with SRB over E-DCH/HS-DSCH;
PSI/B + PS I/B over HSPA with SRB over E-DCH/HS-DSCH;
PSI/B + PS I/B + PS I/B over HSPA with SRB over E-DCH/HS-DSCH.
Page 104/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

9.3.5.3 RAB RELEASE
If the SRB is on HSPA, a RAB release does not lead to any change in SRB
configuration. If the SRB is on DCH and the RAB released is the last one on DCH, the
criteria are checked to see whether SRB can be configured on HSPA and, if possible,
the reconfiguration to SRB on HSPA is done in the same procedure than the RAB
release.
The following transitions have to be considered:
SRB on DCH + TRB on DCH (to be released) SRB on HSPA (2ms or
10ms)
SRB on DCH + TRB on DCH (to be released) + TRB on HSPA SRB on
HSPA + TRB on HSPA (2ms or 10ms)
If the SRB was set on DCH at call setup, it may have been set on an iCEM that does
not support F-DPCH. In that case, the reconfiguration will fail in the Node B and
fallback to DCH is done.
9.3.6 SRB ON HSPA IN MOBILITY

9.3.6.1 ACTIVE SET MANAGEMENT
With F-DPCH there is no DCH, but the notion of DCH active set is kept, so a cell that
is in the DCH active set but not in the E-DCH active set will have only an F-DPCH in
downlink and a DPCCH in uplink.
This does not allow a UE to take benefit of diversity, but allows the possibility of
making measurements on these cells and potentially save a call. It may happen in the
following circumstances:
The E-DCH active set is full, but not the DCH active set;
The serving cell is a 2ms TTI and a new link which does not support 2ms
TTI is added to the DCH active set (if the last link in the E-DCH active set
is released the call is reconfigured to DCH, taking benefit of all links in the
DCH active set).
With F-DPCH the active set configuration is the following:
Configuration
Primary RL configuration
RL of E-DCH active set
configuration
RL of the DCH active set
configuration
Traffic
Traffic UL / Traffic DL
Traffic UL / No traffic DL
No traffic UL / No traffic DL
Physical Channels
UL: DPCCH / E-DPCCH / E-DPDCH
DL: F-DPCH / HS-SCCH / HS-PDSCH
UL: DPCCH / E-DPCCH / E-DPDCH
DL: F-DPCH
UL: DPCCH
DL: F-DPCH
Table 9: RL Configuration with F-DPCH

Page 105/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The notion of F-DPCH active set is not useful because if F-DPCH is established, all
radio links are in F-DPCH (F-DPCH active set will be always be equal to the union of
the DCH active set and E-DCH active set).
9.3.6.2 OUTER LOOP POWER CONTROL AND DCH ACTIVE SET

As there is no DCH with F-DPCH, there is no DCH FP, so the OLPC command to drive
the SIR Target of the UL DPCCH shall be sent by the RNC on E-DCH FP. For the Node
Bs not having E-DCH FP (only containing cells in the DCH active set, with DL F-DPCH /
UL DPCCH configuration) no data traffic is sent through this Node B hence the RNC
has no possibility of updating the SIR Target by OLPC commands and there is a risk
that the NodeB sends TPC_down.
To avoid this issue, RNC configures a SIR Target to MAX_SIR_TARGET value for the
DCH radio links when call is configured with F-DPCH (the Node B will always send
TPC_up, which will be ignored by the UE if another Node B sends TPC_down).
The RNC is connected to one of the 3 following possible NodeB configurations:
Configuration 1 (the Node B handles E-DCH radio links only) - the SIR
Target value is retrieved from the UL AsConf parameter;
Configuration 2 (the Node B handles DCH radio links only) the SIR Target
value is configured with the MAX_SIR_TARGET value;
Configuration 3 (the Node B handles E-DCH and DCH radio links
simultaneously) - the SIR Target value is retrieved from the UL AsConf
parameter
For Configuration 3 two possible sub-cases can be considered:
E-DCH radio link addition on a Node B only handling DCH radio links:
o
MAX_SIR_TARGET is kept until the next radio link

reconfiguration procedure is triggered;
During the next reconfiguration procedure, the SIR Target
value is retrieved from UL AsConf parameter and provided to
the Node B.
DCH radio link addition on a Node B only handling E-DCH radio links:
o
The SIR Target value from UL AsConf parameter is kept.
In case of SRB reconfiguration (HSPA to DCH and vice-versa):

Reconfiguration
SRB on HSPA to SRB
on DCH
Configuration 2
Configuration 3
SIR Target is reconfigured with

No action
the value retrieved from
No action
UlAsConf parameter
SRB on DCH to SRB

on HSPA
Configuration 1
No action
SIR Target is reconfigured with

the MAX_SIR_TARGET value
No action
Table 10: SRB reconfiguration and SIR Target update

Page 106/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Note: UlAsConf power control parameters for SRB on HSPA configuration are
retrieved from SRB_EDCH or PS_EDCHxSRB_EDCH objects. Please refer to [R01],
volume 9.
9.3.6.3 PRIMARY CELL CHANGE

In case of change of primary cell change (event 1D) a reconfiguration is triggered to
move the primary radio link to a new cell and the old primary radio link remains on
the active set. When SRB is on HSPA, the primary cell change implies a
reconfiguration of the radio links (HSDPA to be established on new primary cell and to
be deleted from the previous one).
9.3.6.4 RADIO CONDITIONS

As previously mentioned, SRB can be configured on HSPA only if radio conditions
based either on CPICH RSCP or Ec/No are good enough (higher than thresholds
defined through OAM parameters). The radio conditions are obtained from RACH (in
RRC CONNECTION SETUP message) or in any MEASUREMENT REPORT triggered
during the call (no new event is required for this purpose).
For management of event triggered measurements, the following rule is used:
The event is analysed first:
o
If the event consideration leads to a configuration without SRB on HSPA,

apply the event result only (for example, addition of radio link that does
not support F-DPCH);
If the event consideration leads to a configuration on which SRB on HSPA is
possible, the radio conditions are checked as part of SRB on HSPA criteria
(example: deletion of the last radio link not supporting F-DPCH).
In case of primary cell change, the radio conditions to consider are the ones from the
new primary cell.
If there is no the newest radio measurement reported for the primary cell, the stored
radio measurement which was got from the latest measurement report will be used. If
no radio measurement can be obtained for the primary cell, SRB will not be
configured on HSPA with F-DPCH:
For RRC Connection procedure, the RRC CONNECTION REQUEST message
includes the measurement information on RACH which is used to compare with
the parameters. If redirection occurs during RRC connection procedure, no radio
measurement for target cell is reported and SRB will not be configured on HSPA
with F-DPCH.
For Always-On upsize from Cell_FACH to Cell_DCH with UE measurement report
4A or internal RNC measurement report (DL traffic resuming), no radio
measurement is reported and the stored radio condition before downsize to
Cell_FACH will be used for radio condition checking.
Page 107/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For Always-On upsize from Cell_PCH/URA_PCH or RRC connection re-establishment with
UE sending Cell Update message, if measurement information elements exist in the
message, the radio condition is checked, otherwise, SRB will not be configured on HSPA.
For 3G to 3G incoming relocation, if no radio measurement for target cell is

present SRB wont be configured on HSPA.
9.3.6.5 MIXITY MANAGEMENT

If the UE sends a MEASUREMENT REPORT to add a radio link and this link does not
support F-DPCH, the SRB is reconfigured on DCH prior to the active set update
procedure. On the contrary, if the UE sends a MEASUREMENT REPORT to delete a
radio link that was not supporting F-DPCH, and all the radio links left support F-DPCH,
the active set update procedure is done and the SRB will be reconfigured immediately.
If the SRB was set on DCH at call setup, it may have been set on an iCEM that does
not support F-DPCH, so in this case the reconfiguration will fail at the Node B and the
call will stay on DCH (for the radio link in this Node B) or a fallback to DCH will be
triggered on the radio link in other Node B.
9.3.6.6 IUR MANAGEMENT

F-DPCH is not managed over Iur, so SRB on HSPA configuration is not supported in
this interface.
F-DPCH information is available in RNSAP messages RADIO LINK SETUP REQUEST,
RADIO LINK ADDITION REQUEST, RADIO LINK RECONFIGURATION PREPARE and
PHYSICAL CHANNEL RECONFIGURATION REQUEST, so any request coming from a
serving RNC containing the F-DPCH Information IE will be refused with cause F-DPCH
not supported (this rejection is managed by the Alcatel-Lucent RNC, upon reception
of the request from the peer RNC).
All cells controlled by a drift RNC are considered as non F-DPCH capable, thus
adding a cell controlled by a drift RNC in the active set, the SRNC should act as if the
new cell is not F-DPCH capable and reconfigure SRB on DCH.
9.3.7 SRB ON HSPA IN ALWAYS-ON

As the Always-On procedure applies to PS I/B bearers on DCH and HSPA, it is also
applicable when the SRB is mapped on HSPA.
This means that the following transitions are supported:
Cell_FACH (SRB + TRB) Cell_DCH (SRB/HSPA + TRB/HSPA)
Cell_PCH/URA_PCH Cell_DCH (SRB/HSPA + TRB/HSPA).
This is not applicable for standalone SRB, even when on HSPA.
Page 108/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

The following table lists the interaction scenarios between Always-On procedure and
SRB on HSPA with F-DPCH.
Scenario
Description
UE is on CELL_DCH state, with TRB (1 PS
Always-On downsize from Cell_DCH to Cell_FACH
I/B) and SRB on E-DCH/HS-DSCH with
1 PS I/B on F-DPCH (pre-condition)
F-DPCH. Low measured data traffic. UE is

downsized to CELL_FACH state.
UE is on CELL_DCH state, with TRB (2 or 3
Always-On downsize from Cell_DCH to Cell_PCH/URA_PCH

2 or 3 PS I/B on F-DPCH (pre-condition)
PS I/B mux RAB) and SRB on E-DCH/HSDSCH with F-DPCH. Low measured data
traffic. UE is downsized from Cell_DCH to
Cell_PCH/URA_PCH directly.
A PS I/B call has been downsized to
CELL_FACH. Reception of internal RNC
measurement report (DL traffic resume) or
RRC measurement report with event 4A
Always-On upsize from Cell_FACH to Cell_DCH
triggers an Always-On upsize. Transition
1 PS I/B on F-DPCH (post-condition)
from Cell_FACH to Cell_DCH occurs. All

conditions are fulfilled for F-DPCH. The PS
I/B is reconfigured to E-DCH/HSDPA and
SRB is reconfigured to E-DCH/HSDPA with
F-DPCH.
2 or 3 PS I/B mux RAB call has been
downsized
to
CELL_PCH/URA_PCH.
Reception of internal RNC measurement

report (DL traffic resume) or RRC cell
Always-On upsize from Cell_PCH/URA_PCH to Cell_DCH
2 or 3 PS I/B on F-DPCH (post-condition)
update
with
cause
uplink
data
transmission triggers an Always-On upsize.

A
direct
transition
from
Cell_PCH
to
Cell_DCH occurs. All conditions are fulfilled

for F-DPCH. The 2 PS I/B mux RAB call is
reconfigured to E-DCH/HSDPA and SRB is
reconfigured to HSPA with F-DPCH.
Table 11: SRB on HSPA with F-DPCH and Always-On transitions
9.3.8 RADIO CONFIGURATION AND RESOURCE MANAGEMENT

Even though SRB might be mapped on HS-DSCH/E-DCH without F-DPCH, no such
configuration has been defined in 3GPP specifications, so in order to avoid IOT
problems with some mobiles (most likely bugs because configuration not tested), it
has been decided to mandate F-DPCH when mapping SRB on HSPA).
Page 109/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

For the DL, there is one dedicated priority queue per SRB and all these priority queues
are mapped onto one HS-DSCH MAC-d flow. The Scheduling Priority of these priority
queues are determined in the following way:
From
OAM
configuration
for
SRB#1
(through
parameter
srbOverHsdpaSpi);
The SPI of SRB#2, SRB#3 and SRB#4 are deduced by the RNC:
SPI(SRB#2) = SPI(SRB#1) 1, SPI(SRB#3) = SPI(SRB#1) 2 and
SPI(SRB#4) = SPI(SRB#1) 3
Parameter srbOverHsdpaSpi should be set to a high value as it is not
desirable having low priority for the SRB on HS-DSCH to avoid SRB traffic
delay and possible call drops
For the UL, SRB will be configured in non-scheduled mode (with max PDU size defined
by parameters maxMacePduContentsSizeForNonScheduledModeTti2 and
maxMacePduContentsSizeForNonScheduledModeTti10) and will use one EDCH MAC-d flow.
MAC-e non scheduled mode is used to carry SRB on E-DCH. So far it was used only
when using 2SF2+2SF4 in case of UE category 6. Now it may be used in all new cases
of SRB mapped over EDCH, introduced by the feature SRB over HSPA.
For the physical channels, F-DPCH is used in DL and DPCCH is used in UL (they are
necessary to perform the power control).
The cell resource management introduced by feature PM33694 Fair Sharing of
Resources HSDPA vs DCH is applicable for the new SRB on HSDPA.
If Fair Sharing of Resources is activated:
Power and codes resource management applies as defined by PM33694 for
SRB configured over HSDPA;
Regarding the cell resource management that is done internally in RNC, the
SRB contribution on power and code consumption is taken into account as
for any other TRB on HSDPA;
The new parameters srbOverHsdpaGbr and initialActivityFactorSrb are used
to estimate the power and code needed for this SRB on HSDPA;
The consumption model of HS-DSCH radio bearers has evolved accordingly:
Type of Service
Target Bit Rate
PS Streaming RAB with RANAP
MAC-hs GBR = min (RANAP GBR, RANAP
GBR > 0
MBR)
(only for codes reservation)
PS Streaming RAB with RANAP

GBR = 0
Corrective Factor
(only for codes reservation)
PS I/B RAB with minBR > 0
MAC-hs GBR = min (minBrForHsdpa,
and
RANAP GBR)
initialActivityFactorForIb (for power

reservation only this parameter is used)
Page 110/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Type of Service
Target Bit Rate
Corrective Factor
PS I/B RAB with minBR = 0
PS RAB with no Traffic Class
0 (no target bit rate)
No corrective factor
SRB with MO defined GBR > 0
srbOverHsdpaGbr
initialActivityFactorSrb
Table 12: HS-DSCH radio bearers consumption model
If Fair Sharing is not activated:

There is no specific resource reserved for SRB on HSDPA;
The CAC for HSDPA calls is based on a comparison between the current
number of HSDPA users and a maximum configurable number of HSDPA
users;
The number of HSDPA users is not incremented for this new SRB on
HSDPA.
9.3.9 SYNCHRONISATION
CFN synchronization is necessary for the purpose of SRLR and Compressed Mode
activation procedures.
For the F-DPCH and SRB on HSPA configuration, since there is no DCH transport
bearer at call setup or during the call, so the CFN synchronisation cant be obtained
on dedicated transport channel DL or UL synchronisation. The adopted solution is to
obtain CFN by performing DL Node Synchronisation over the HS-DSCH channel for
SRB.
The synchronisation procedure will take place every time the SRB is established on
HSPA, either at initial setup (RRC establishment) or following a reconfiguration. This
procedure
is
periodical,
with
the
period
defined
by
parameter
nodeSynchroPeriodForFdpch.
Parameters nodeSyncRetryPeriod and nodeSyncMaxNumOfRetries allow
handling the communication failure between the RNC and the Node B during the initial
DL NODE SYNCHRONISATION procedure. If the UL NODE SYNCHRONISATION
message is not received by the RNC after nodeSyncRetryPeriod it will retry up to
nodeSyncMaxNumOfRetries times (there is no recovery mechanism).
After DL Node Synchronisation over HS-DSCH channel for SRB, the RNC is able to
calculate the current CFN, which depends on the Frame Offset and a running average
of the timing difference between the RNC and the Node B (smoothing factor defined
by parameter nodeSynchOffsetSmoothingCoefficient).
In case of synchronised radio link reconfiguration (done in parallel by RNC, Node B
and UE), given the current CFN, the activation CFN can be calculated by (CFN + Delta
CFN) mod256. The Delta CFN will bypass the adjustment algorithm implemented by
feature PM30171.2 Enhanced Delta CFN, as this algorithm is based on the
assumption of SRB on DCH, which have a 10ms (13.6) or 40ms (3.4) TTIs.
Page 111/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

On HS-DSCH the TTI is 2ms and a lot of PDUs can be sent at a time, so the need to
add this extra guard is negligible and a new one is used, defined by
deltaCfnForSynchronousReconfOverIubForFdpch parameter.
If the activation CFN is not computed properly, the UE may not apply the
reconfiguration at the same time than the Node B (but one CFN cycle after, ie. 2.56
seconds) because the RADIO LINK RECONFIGURATION COMMIT message will arrive
before at the Node B than the RADIO BEARER RECONFIGURATION message at the
UE.
In some situations, this only delays the completion of the procedure but in other
situations, this can result in a call drop (if physical channels configuration is changed,
in case of compressed mode activation, or when there is a HS-DSCH serving cell
change).
9.3.10 INTERACTION WITH DUAL CELL OPERATION

PM81204 introduces dual cell operation in UA7.1.2 with some restrictions (only
applicable for mono PS I/B). The mono PS I/B + SRB on HSPA with F-DPCH on dual
cell will be supported.
From UA08.1 onwards, with the introduction of PM104832/PM118154, dual cell is
configured concurrently with F-DPCH and is also applicable to multi-service, including
the following combinations:
CS over DCH + PS over HSPA;
(CS over DCH +) PS over HSPA + PS over HSPA;
(CS over DCH +) PS over HSPA + PS over HSPA + PS over HSPA.
The F-DPCH is configured only on the anchor cell.
In case of standalone SRB over HSPA, dual cell operation shall not be configured to
avoid excessive connection consumptions on the baseband resources.
9.4 PARAMETERS
isSrbOverHspaEnabled is used to activate the support of SRB on HSPA with FDPCH at cell level and at RNC level (depending on the MO). In case of modification,
the new value of this parameter will be taken into account at next F-DPCH setup, in
case of the cell parameter (at RNC, the new value will be taken into account for the
next call).
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
FDDCell

Customer
3-a2
True, for feature activation
Granularity
FDD Cell
Page 112/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
Object
RadioAccessService
Customer
3-b
True, for feature activation
Granularity
RNC
isSrbOverHspaEnabledForPsIb indicates if SRB on HSPA with F-DPCH is allowed

for configurations with PS I/B.
Parameter
RAN Path
Range & Unit
User
Class
Value
isSrbOverHspaEnabledForPsIb
Object
Customer
Granularity
3-a2
True, for feature activation with PS I/B configurations
RadioAccessService
RNC
isSrbOverHspaEnabledForPsConversational indicates if SRB on HSPA with FDPCH is allowed for configurations with PS Conversational (not relevant in UA08.1
context).
Parameter
RAN Path
Range & Unit
User
Class
Value
isSrbOverHspaEnabledForPsConversational
Object
RadioAccessService
Customer
3-a2
False
Granularity
RNC
isSrbOverHspaEnabledForPsStreaming indicates if SRB on HSPA with F-DPCH is

allowed for configurations with PS Streaming. As streaming calls are not in the scope
of PM120940, and the streaming configuration is not specified, not implemented nor
tested, this parameter should be set to False.
Parameter
RAN Path
Range & Unit
User
Class
Value
isSrbOverHspaEnabledForPsStreaming
Object
RadioAccessService
Customer
3-a2
False
Granularity
RNC
isSrbOverHspaEnabledForSignaling indicates if SRB on HSPA with F-DPCH is

allowed for configurations with signalling only.
Parameter
RAN Path
Range & Unit
User
Class
Value
isSrbOverHspaEnabledForSignaling
Object
Customer
Granularity
3-a2
True, for feature activation with signaling configurations
RadioAccessService
RNC
Page 113/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

isSrbOverHspaEnabledForCs indicates if SRB on HSPA with F-DPCH is allowed for
configurations with CS.
Parameter
RAN Path
Range & Unit
User
Class
Value
isSrbOverHspaEnabledForCs
Object
RadioAccessService
Customer
3-a2
False
Granularity
RNC
srbOverHsdpaSpi provides the RNC HSDPA Scheduling Priority Indicator (HSDPA

SPI) for SRB #1 for F-DPCH calls (SPI for SRB #2,3,4 are calculated by RNC as
srbOverHsdpaSpi 1, srbOverHsdpaSpi 2 and srbOverHsdpaSpi 3,
respectively).
Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHsdpaSpi
Object
SrbQos

Integer [3 .. 15], step 1
Customer
3-a2
15, for high priority
Granularity
RNC
srbOverHsdpaGbr provides the guaranteed bit rate for SRB on HSDPA for F-DPCH
calls.
Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHsdpaGbr
Object
SrbQos

Bits/s [0 .. 256000], step 1
Customer
3-a2
13600
Granularity
RNC
initialActivityFactorSrb is used to take into account the activity factor of the SRB,
when the SRB is configured on HSDPA.
Parameter
RAN Path
Range & Unit
User
Class
Value
initialActivityFactorSrb Object
% [0 .. 100], step 1
Customer
Granularity
RNC
3-a2
10
srbOverHspaRscpThreshold and srbOverHspaEcNoThreshold define the RSCP
and Ec/No thresholds above which the radio conditions are good enough to support
SRB on HSPA (only one is used). If the CPICH RSCP (resp. CPICH Ec/No)
measurement received from UE (in any RRC message) is above the respective
threshold, the radio conditions are good enough to have the SRB in HSPA with FDPCH.
Page 114/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHspaRscpThreshold
Object
RNC / RadioAccessService / DedicatedConf/ MeasurementConfClass
dBm [-120 .. -25], step 1
Customer
Granularity RNC
3-a2
-100
Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHspaEcNoThreshold
Object
dB [-24 .. 0], step 1
Customer
Granularity RNC
3-a2
-12
srbOverHspaRscpHysteresis and srbOverHspaEcNoHysteresis are applied to

the respective thresholds for defining when the radio conditions are not good enough
to support SRB on HSPA (only one is used).
If the CPICH RSCP (resp. CPICH Ec/No) measurement received from UE (in any RRC
message) is below srbOverHspaRscpThreshold - srbOverHspaRscpHysteresis
(resp. srbOverHspaEcNoThreshold - srbOverHspaEcNoHysteresis), the radio
condition are not good enough to keep the SRB in HSPA with F-DPCH and the SRB
should be configured on DCH.
Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHspaRscpHysteresis Object
dB [0 .. 7.5], step 0.5
Customer
Granularity RNC
3-a2
4
Parameter
RAN Path
Range & Unit
User
Class
Value
srbOverHspaEcNoHysteresis Object
dB [0 .. 7.5], step 0.5
Customer
Granularity RNC
3-a2
2
nodeSynchroPeriodForFdpch defines the period between node synchronisation
procedures to acquire CFN synchronisation (for F-DPCH calls). Node synchronization
procedure to acquire the CFN synchronization (when SRB is on HSPA) is executed
periodically and this attribute defines the period between 2 successive node
synchronization procedures.
Page 115/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
RAN Path
Range & Unit
User
Class
Value
nodeSynchroPeriodForFdpch
Object
NodeSyncParams
RNC / RadioAccessService / HsdpaRncConf / NodeSyncParams
s [1 .. 100], step 1
Customer
Granularity
RNC
3-a2
10
nodeSyncRetryPeriod defines the time interval to wait before sending a retry DL
NODE SYNCHRONISATION
procedure.
Parameter
RAN Path
Range & Unit
User
Class
Value
frame
during
initial
node
synchronization
failure
nodeSyncRetryPeriod
Object
NodeSyncParams
ms [10 .. 1000], step 1
Customer
Granularity
RNC
3-a2
100
nodeSyncMaxNumOfRetries defines the maximum number of retries for Node

Synchronisation that can be attempted
Synchronisation failure procedure.
Parameter
RAN Path
Range & Unit
User
Class
Value
on
HS-DSCH
during
initial
Node
nodeSyncMaxNumOfRetries
Object
NodeSyncParams
Integer [5 .. 100], step 1
Customer
Granularity
RNC
3-a2
5
nodeSynchOffsetSmoothingCoefficient is the smoothing coefficient used for the
Node Synchronisation procedures for F-DPCH, to allow acquisition of CFN
synchronisation.
Parameter
RAN Path
Range & Unit
User
Class
Value
nodeSynchOffsetSmoothingCoefficient Object
NodeSyncParams
1/128 [0 .. 128], step 1
Customer
Granularit RNC
y
3-a2
32 (32/128 = 1/4)
deltaCfnForSynchronousReconfOverIubForFdpch indicates the delay to add to
the CFN to determine the activation time of any SRLR when SRB are on HSPA.
Page 116/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

Parameter
deltaCfnForSynchronousReconfOverIub
ForFdpch
RAN Path
Range & Unit
User
Class
Value

Radio Frames [0 .. 255], step 1
Customer
3-a2
18
Object
NodeSyncParams
Granularity
RNC
Page 117/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
10 EDCH CALL MANAGEMENT SUMMARY

As soon as E-DCH is involved for a call, the UTRAN shall take decisions in two main
areas: which E-DCH TTI (10ms or 2ms) and which SRB mapping (over DCH or over EDCH) shall be selected ?
Of course the criteria to make the decisions are first the UE capabilities and the
UTRAN configuration (cell capabilities), but not only. Three features related to the
2ms CAC admission and two features related to the call retainability optimization
participate in the decision.
These features and enhancements are briefly listed here after, with their main
parameters, and are more described in this document. The reader is invited to refer to
the specific sections for their complete description.
Feature 33581 SRB on EDCH
o
isSrbOnEdchForAllEdchCategory
Feature 30742 MBR Handling in the HSUPA scheduler

o
Enhancement concerning EDCH over IUR IOT issue

o
isEdchIurRestrictionEnabled
Feature 34441.1 and 34441.2 EDCH CAC algorithm evolution in the RNC
o
edchMaxUsersPerCell
Feature 82602/R3 CAC algorithm evolution for 2ms TTI users

o
useImprovedBtsCacFor2msTtiUsers
Feature 125567 Enhanced NodeB EDCH CAC ([GM] only)

o
maxNbEdchCreditsForXcem (BTSEquipment::reserved2 byte 0)
maxNbEdchCreditsForEcem (BTSEquipment::reserved2 byte1)
Enhancement 367062 Reconfiguration SRB E-DCH to DCH 3.4kbps

o
isSrbOnEdchEligibleOnE1A (RNC->RadioAccessService::reserved1
Byte2 bit2)
isSrbOnEdchEligibilityReEvaluated (RNC->RadioAccessService::
reserved1 Byte2 bit3)
Feature 125855 E-DCH call retainability improvement

Page 118/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

o
multiRabSmartEdchResourceUsageActivation
maxColorForCac2ms and maxNumActiveUsersForCac2ms
The key drivers for the UTRAN decisions are: the ability of the call to keep macrodiversity for the Uplink SRB, the multi-services (CS+PS) situation and the current radio
conditions and uplink radio load level.
The table below shows the different call states resulting from the UTRAN decisions,
for a HSUPA Category 6 UE (assuming it is not F-DPCH capable). The UTRAN
decisions depend on the above features activation.
For a UE which is HSUPA Category 6 and F-DPCH capable, the same transitions apply,
except the ones associated with the feature 125855 R2 and R3: in the current release,
when a call is set up on HSPA through PM29810, it overrules the 125855 R2 and R3
OAM parameters and forces the usage of SRB over E-DCH.
Page 119/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

UE is HSUPA Category 6 and not F-DPCH capable
PS I/B + SRB
Call type
RL
SRB
TRB
PS EDCH SRB EDCH

TTI2ms
Serving
EDCH
EDCH
Non-Serving
EDCH
EDCH
Serving
EDCH
EDCH
Non-Serving
DL only
PS EDCH SRB DCH

TTI2ms
Serving
DCH
EDCH
Non-Serving
DCH
EDCH
PS EDCH SRB DCH

TTI2ms
Serving
DCH
EDCH
Non-Serving
DCH
Serving
DCH
EDCH
Non-Serving
DCH
EDCH
Serving
DCH
EDCH
Non-Serving
DCH
Serving
EDCH
EDCH
Non-Serving
EDCH
EDCH
Serving
EDCH
EDCH
Non-Serving
DL Only
PS EDCH SRB EDCH

TTI2ms
PS EDCH SRB DCH

TTI10ms
PS EDCH SRB DCH

TTI10ms
PS EDCH SRB EDCH

TTI10ms
PS EDCH SRB EDCH

TTI10ms
Comment
Full Macro-Diversity
The UE still operates as a Category6. It has no
Macro-Diversity for the Uplink TRB nor Uplink
SRB. This is not recommended. The activation of
the enhancement 367062 helps avoiding this
state.
The UE is downgraded to a Category4. It keeps
full Uplink Macro-Diversity, over EDCH for the
TRB and over DCH for the SRB.
Uplink Macro-Diversity at least for the SRB (over
DCH).
full Uplink Macro-Diversity, over EDCH for the
TRB and over DCH for the SRB.
Uplink Macro-Diversity at least for the SRB (over
DCH).
[US] only. The UE is downgraded to a Category5.
It keeps full Uplink Macro-Diversity, over EDCH
for the TRB and over DCH for the SRB.
[US] only. The UE is downgraded to a Category5.
It has no Macro-Diversity for the Uplink TRB nor
Uplink SRB. This is not recommended. The
activation of the enhancement 367062 helps
avoiding this state.
PS I/B + CS + SRB
Transport type
SRB
TRB PS
TRB CS
PS EDCH SRB DCH TTI2ms + CS
DCH
EDCH
DCH
PS EDCH SRB DCH TTI10ms + CS
DCH
EDCH
DCH
Comment
SRB is always over DCH in the case of
CS+PS. Only the EDCH TTI is
questionable. It is not recommended to
keep the TTI 2ms. The activation of the
feature 125855 / R1 allows reconfiguring
the TTI to 10ms.
The picture below highlights the main transitions from one state to the other and give
the criteria for the decisions.
The decision criteria and the associated final states are the following:
At PS setup:
1. Criteria: nothing specific (normal case) -> The call is setup with TTI 2ms and
SRB over EDCH.
2. Criteria: specific RF conditions detected (125855 ON):
o
Bad RF conditions (125855/R2).
High UL RTWP and high number of active EDCH users (125855/R3)
Page 120/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

-> The call is setup with TTI 10ms and SRB over DCH.
3. Criteria: EDCH 2ms TTI CAC reject by one of the following feature:
o
Features 34441.1, 82602/R3
Feature 125567 ([GM] only)
-> The call is setup with TTI 10ms. The SRB is over DCH for [GM] and over
EDCH for [US].
4. Criteria: Low RANAP UL MBR requested (<= 384kbps) (feature 30742 ON).
-> The call is setup with TTI 10ms. The SRB is over DCH for [GM] and over
EDCH for [US].
5. Criteria: the feature SRB over EDCH is disabled -> The call is setup with TTI
2ms and SRB over DCH.
At PS setup with multiple RL:

6. Criteria: nothing specific (normal case) -> The call is setup with TTI 2ms and
the SRB is over EDCH for all RL.
7. Criteria: the capabilities of the non serving RL is less than the one of the
Serving RL (not 2ms capable or not EDCH capable) and the enhancement
367062 is OFF -> The call is setup with TTI 2ms and the SRB is over EDCH
for the serving RL. The non-serving RL is placed into the DCH active set.
8. Criteria: the capabilities of the non serving RL is less than the one of the
Serving RL (not 2ms capable or not EDCH capable) and the enhancement
367062 is ON -> The call is setup with TTI 2ms and the SRB is over DCH for
all RL.
9. Criteria: the EDCH 2ms TTI CAC rejects the non-serving RL (features 34441.1
or 82602/R3, or feature 125567, the latter being [GM] only) -> the call is
setup with TTI 10ms. The SRB is either kept over DCH, for [GM], or
reconfigured
over
EDCH,
for
[US],
for
all
RL.
Note: This transition is available from UA08.1.2 onwards (not in the early
UA08.1.1) and known as 82602/R3 Enhancement. This transition is not
controlled by any flags. Before UA08.1.2, the call was setup with TTI2ms and
SRB over EDCH, and the non-serving RL was placed into the DCH active set
(shown with <UA08.1.2 in the graph).
At non-serving RL Setup/Addition (event 1A):

(The transitions are suffixed with + in the graph).
10. Criteria: nothing specific (normal case) -> The non-serving RL is setup with
TTI 2ms and SRB over EDCH.
11. Criteria: the non serving RL can not enter the EDCH active set for one of the
following reason, and the enhancement 367062 is OFF.
o
Capabilities of the non serving RL is less than the one of the Serving RL
(e.g not 2ms capable or not EDCH capable)
Page 121/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

o
EDCH 2ms TTI CAC rejected (features 34441.1 or 82602/R3, or feature

125567, the latter being [GM] only).
Non-serving RL is over IUR.
-> The call remains with TTI 2ms and SRB remains over EDCH for the Serving
RL. The non-serving RL is placed into the DCH active set.
12. Criteria: the non serving RL can not enter the EDCH active set for the same
reasons as above, but this time the enhancement 367062 is ON -> The call
remains with TTI 2ms and the SRB is either kept (if the initial state is PS
EDCH SRB DCH TTI2ms) or reconfigured (if the initial state is PS EDCH SRB
EDCH TTI2ms) over DCH for the Serving RL, and the non-serving RL has also
SRB over DCH (Macro-Diversity for the SRB is ensured). For IUR, a sub-case
exists: if the Drift cell is 2ms capable, then the call can recover full MacroDiversity (over EDCH for TRB and over DCH for SRB).
13. Criteria: specific IUR case, with neighboring RNC not EDCH allowed and the
enhancement for IOT compatibility ON (isEdchIurRestrictionEnabled = TRUE)
-> The call is completely reconfigured over DCH in Uplink before the RL
addition.
14. Criteria: for some reason the call was originally setup as 10ms with SRB over
DCH -> An RL Addition does not reconfigure the call to 2ms: the non-serving
RL is setup with the same properties as the serving RL, so 10ms with SRB
over DCH.
15. Criteria: for some reason the call was originally setup as 10ms with SRB over
EDCH (this is applicable to [US] market only) -> An RL Addition does not
reconfigure the call to 2ms: the non-serving RL is setup as the serving RL, so
10ms with SRB over EDCH.
At non-serving RL Deletion (event 1B):

(The transitions are suffixed with - in the graph).
Generally speaking, the non-serving RL deletion transitions are symmetric to the
corresponding non-serving RL addition transition.
There is one exception: with 367062 ON, if the RL addition triggered a reconfiguration
of the SRB over DCH (transition 12+), the deletion does not trigger the
reconfiguration back: the SRB remains over DCH (refer to the description of the
Enhancement 367062). Refer to 12- in the graph.
Also, if at PS Setup with two RL, the non-serving RL was rejected as 2ms, forcing the
reconfiguration of the call to 10ms (transition 9, available from UA08.1.2 onwards, not
in the early UA08.1.1, and known as 82602/R3 Enhancement), then the subsequent
RL deletion of the non-serving RL does not trigger a reconfiguration to 2ms: the call
remains with 10ms. Refer to 14- and 15- in the graph.
At CS Addition:
16. Criteria: the feature 125855/R1 OFF -> The SRB is reconfigured over DCH
(this is always the case for CS+PS calls) but the TTI remains 2ms.
Page 122/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

17. Criteria: the feature 125855/R1 ON -> The SRB is reconfigured over DCH (this
is always the case for CS+PS calls) and the TTI is reconfigured as 10ms
At CS Deletion:
When the CS is removed, the Tti is reconfigured to 2ms when no other constraint
forbids it, such as CAC (refer to 16- and 17- in the graph).
At RB Re-establishment after RL Failure (CELL_FACH Cell_Update/Cell_Update
Confirm):
18. TTI10ms is selected. The SRB is configured over DCH for the Global Market,
and over EDCH for the US Market. The next change of Primary Radio Link will
give the possibility to come back with TTI2ms.
19. Criteria: RB Re-establishment after RL Failure is triggered and specific RF
conditions are detected (125855/R2 ON) -> in addition to be TTI10ms
because of RRE, the SRB will be configured over DCH for the US Market. Note
that for Global Market the SRB is de facto over DCH, because of the usage of
10ms, regardless of the RF conditions.
At Serving Cell change (Primary Radio Link Change)
The TTI and/or SRB reconfiguration may also occurred during the mobility, when the
serving cell is changed: the conditions are re-evaluated on the new serving cell.
20. Criteria: normal case (nothing specific) -> the call remains with TTI 2ms and
SRB over EDCH.
21. Criteria: the call is TTI 10ms for the serving RL and the non-serving RL
because the serving RL did not pass the 2ms TTI CAC (features 34441.1 or
82602/R3, or feature 125567, the latter being [GM] only). Then the nonserving RL becomes the new serving RL. The former one (now the new nonserving RL) still fails the 2ms CAC. -> The call is kept with TTI 10ms. In
Global Market which only allows SRB over EDCH for 2ms TTI Cat6, the SRB is
de facto configured over DCH. In the US Market which allows SRB over EDCH
for
all
EDCH
TTI,
the
SRB
is
configured
over
EDCH.
This transition is available from UA08.1.2 onwards, not in the early UA08.1.1,
it is known as 82602/R3 Enhancement. It is not controlled by any flag.
Before UA08.1.2, the call would have been reconfigured with TTI2ms and SRB
over EDCH, and the non-serving RL would have been placed into the DCH
active set (shown with <UA08.1.2 in the graph).
The colors used in the picture are:

Dark Blue for EDCH TTI 2ms with SRB over EDCH
Light Blue for EDCH TTI 2ms with SRB over DCH
Dark Green for EDCH TTI 10ms with SRB over EDCH
Light Green for EDCH TTI 10ms with SRB over DCH
Page 123/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary

SRB only
SRB only
SRB
SRB
DCH
DCH
Serving RL
DCH
Serving RL
Non-Serving RL
+PS
+PS
2
3 [GM]
3 [US]
CELL FACH
Re-estab
4 [GM]
17-
16-
PS EDCH SRB EDCH TTI2ms

Serving RL
SRB
TRB
EDCH
EDCH
4 [US]
PS EDCH SRB DCH TTI10ms
SRB
SRB
TRB
EDCH
EDCH
Serving RL
TRB
DCH EDCH
18 [GM]
18 [US]
Serving RL

SRB
Serving RL
TRB
DCH EDCH
19
+RL/-RL
10-
11-
15- [US]
14-
13-
+RL/-RL
12-
+CS
11+
10+

Serving RL
Non-Serving RL
SRB
TRB
EDCH
EDCH
EDCH
EDCH
12+ (IUR)

Serving RL
Non-Serving RL
SRB
TRB
EDCH
DL DCH/UL -
EDCH
-
12+
SRB
Serving RL
Non-Serving RL
TRB
SRB
DCH EDCH
DCH EDCH
Serving RL
Non-Serving RL
14+
SRB
Serving RL
Non-Serving RL
Serving RL
13+ (IUR)
Non-Serving RL
16+
SRB
TRB PS
DCH
TRB
DCH
DCH
EDCH
EDCH

Serving RL
Non-Serving RL
[GM]
SRB
TRB
EDCH
EDCH
EDCH
EDCH
[US]

+CS
SRB
TRB CS
DCH EDCH
SRB
17+

+CS
Serving RL
15+ [US]
TRB
DCH DCH
DCH DCH
12+
<UA08.1.2
PS DCH SRB DCH
TRB
DCH EDCH
DCH
-
Serving RL
TRB PS
DCH EDCH
TRB CS
DCH
21 < UA08.1.2
21

20
Serving RL
Non-Serving RL
SRB
TRB
EDCH
EDCH
EDCH
EDCH

Serving RL
Non-Serving RL
SRB
TRB
DCH
DCH
EDCH
EDCH
[GM]
21
[US]

Serving RL
Non-Serving RL
SRB
TRB
EDCH
EDCH
EDCH
EDCH
Page 124/125

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Z END OF DOCUMENT Y
Page 125/125
UMT/IRC/APP/016664
MOBILITY
V05.04
16/MAR/2012

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
CONTENTS
1
INTRODUCTION............................................................................................................5
1.1
OBJECT ....................................................................................................................... 5
1.2

2.1
HPUG VOLUMES ............................................................................................................ 7
2.2
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..................................................................................................... 10
3.3.1
Cell addition to DCH AS and Primary Cell change procedures for E-DCH calls ........... 10
3.3.2
E-DCH Mobility without macro-diversity (32076 not activated)................................ 11
3.3.3
E-DCH Macro Diversity Support (32076) ............................................................... 12
3.3.3.1
Feature description.......................................................................................... 12
3.3.3.1.1 Feature aim and principle............................................................................. 12
3.3.3.1.2 E-DCH active set management ..................................................................... 14
3.3.3.1.3 E-DCH call attributes management................................................................ 15
3.3.3.1.4 E-DCH non-serving radio links management................................................... 16
3.3.3.2
Parameter settings and recommendations ......................................................... 18
3.3.3.2.1 Feature activation........................................................................................ 18
3.3.3.2.2 RAN Model.................................................................................................. 18
3.3.3.2.3 OMC-R Parameters ...................................................................................... 19
3.3.3.2.4 OMC-B Parameters ...................................................................................... 22
3.3.4
Reconfiguration SRB E-DCH to DCH 3.4kbps ......................................................... 24
3.3.5
Reconfiguration SRB HSDPA to DCH 3.4kbps ........................................................ 26
3.4
FULL EVENT SHO SETTING FOR HSXPA .............................................................................. 26
3.5
INTRA-FREQUENCY MOBILITY OVER IUR ............................................................................... 28
3.5.1
HSDPA OVER IUR ............................................................................................... 28
3.5.2
HSUPA OVER IUR ............................................................................................... 29
3.5.2.1
Iur compliance: Correction of the condition of UL DPDCH Indicator for E-DCH
Operation 34
3.6
INTRA-FREQUENCY INTER-RNC HHO................................................................................. 37
4
COMPRESSED MODE WHILE IN HSXPA......................................................................41

4.1
COMPRESSED MODE IN MAC-HS ....................................................................................... 41
4.1.1
Feature Description ............................................................................................ 41
4.1.2
Compressed Mode Configuration.......................................................................... 42
4.1.3
Transmission Gap Patterns evaluation .................................................................. 43
4.1.4
Compressed frames management ........................................................................ 43
4.2
COMPRESSED MODE IN MAC-E ......................................................................................... 44
4.3
RNC DEFENSE MECHANISM AGAINST UES NOT SUPPORTING HSDPA OR E-DCH COMPRESSED MODE .. 48
Page 1/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
5
INTER-CARRIER MANAGEMENT FOR HSXPA .............................................................51
INTER-FREQUENCY AND INTER-SYSTEM HHO FOR HSXPA.......................................53

6.1
INTER-FREQUENCY MOBILITY FOR HSXPA........................................................................... 54
6.1.1
Inter-Frequency intra-RNC Mobility for HSxPA ....................................................... 54
6.1.2
Inter-Frequency inter-RNC without Iur Mobility for HSxPA...................................... 55
6.1.3
Inter-Frequency inter-RNC with Iur Mobility for HSxPA........................................... 56
6.1.4
Full Event HHO setting for HSxPA ........................................................................ 57
6.2
INTER-SYSTEM MOBILITY FOR HSXPA................................................................................ 58
6.2.1
6.2.2
7
3G to 2G Handover............................................................................................. 58
2G to 3G Handover............................................................................................. 58
U-PLANE TRAFFIC HANDLING....................................................................................59
Page 2/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
TABLES
Table 1: SHO Event Recommended Settings Summary
Table 2: Summary matrix for E-DCH Compressed Mode support
Table 3: HHO Event Recommended Settings Summary
28
48
57
Page 3/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
1:
2:
3:
4:
5:
6:
HS-DSCH link is deleted and re-established on new primary (nominal case)........................ 9

E-DCH link is deleted and re-established on new Primary Cell (nominal case) ................... 11
E-DCH macro diversity general principle ........................................................................ 13
OMC-R RAN model for 32076 ....................................................................................... 18
OMC-B RAN model for 32076........................................................................................ 19
Transmission of E-DPDCH (10ms TTI) when in CM operation .......................................... 45
Page 4/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
1 INTRODUCTION
1.1 OBJECT
Mobility algorithms and parameters applicable to HSDPA & E-DCH (HSUPA) system.
This includes a
recommendations.
system
description,
configuration
aspect
and
engineering

PM ID
Feature Title
Activation flag
Automatic/Available
check if
at
Upgrade
27936
HSDPA Intrafrequency Mobility
Automatic/Available at Upgrade
27937
HSDPA
Alarm
Mobility
inter
RAT: 3G to 2G only
and blind
29802
Inter-frequency
Inter-system
HSDPA HHO
isHsdpaHhoWithMeasAllowed
Releas
e
Global
market
US
Market
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.1/
Yes
(UA5.1)
Yes
(UA7.1)
but
isRLCReconfigurationForChannelTyp
eSwitching
isHsdpaAllowed
29817
HSDPA over Iur
isHsdpaOverIurAsDrncAllowed
isHsdpaOverIurAsSrncAllowed
isGsmCModeActivationAllowed
29798
Compressed Mode
in MAC-hs
isInterFreqCModeActivationAllowed
isInterFreqMeasActivationAllowed
isPatternAllowed
[iBTS]
No activation flag.
33480
Compressed Mode
in MAC-e Scheduler
Compressed Mode for HSPA calls can be

activated/deactivated via
UA7.1
and isGsmCModeActivationAllowed
Page 5/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 Preliminary
Volume 6 : Mobility
PM ID
Feature Title
Activation flag
Releas
e
Global
market
US
Market
UA5.1
Yes
Yes
UA6.0
Yes
Yes
UA6.0
Yes
Yes
UA7.1
Yes
No
UA6.0/
UA7.1.3
Yes
(UA6.0)
Yes
(UA7.1.
3)
(for DL services with HSDPA).

34012
HSDPA over Iur

b/w management
isMacShHsdpaAllowed
No activation flag.
32076
34167
34229
E-DCH Macro
Diversity Support
Feature can be deactivated by restricting

the E-DCH active set size to one cell (by
setting maxNumberOfRlEdch to 1).
Defence
mechanism for UEs
not supporting CM
with HSPA
Inter Freq HO
Enhancements
isHSDPACMFallbackAllowed
isInterFreqHandoverOverIurAllowed
30744
HSUPA Over Iur
isEdchAllowed
isEdchOverIurSrncAllowed
isEdchOverIurDrncAllowed
74681
eCEM Introduction
No activation flag.
UA7.1.3
Yes
No
eCEM-u
Introduction
SRNS relocation
improvement for
Dual Cell (sub
feature of Dual Cell
HSDPA capacity
increase)
Reconfiguration
SRB E-DCH to DCH
3.4kbps
No activation flag.
UA7.1.3
Yes
No
UA08.1
Yes
Yes
UA08.1
Yes
Yes
80051
104832/
118154
367062
(CR Id)
No activation flag.
reserved1 Byte2 bit2

Page 6/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility
[Vol. 7] Deployment Scenarios

[R02] UMT/SYS/DD/013319
[R03] 3GPP TS 25.321
MAC protocol specification
[R04] 3GPP TS 25.423
RNSAP signalling
[R05] 3GPP TS 25.433
NBAP signalling
Planning Guide
[R08] UMT/BTS/DD/027736
Page 7/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
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.
Page 8/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
RNC
Node B
source
Node B
target
UE
Primary cell change
Measurement Control (new neighbouring list)
RL Reconfiguration Prepare (HS-DSCH information)

RL Reconfiguration Ready
RL Reconfiguration Prepare
(MAC-d flow to Delete)
RL Reconfiguration Commit (Activation CFN)
RL Reconfiguration Commit
(Activation CFN)
RB Reconfiguration (Activation CFN)
Activation CFN
RB Reconfiguration Complete
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case)
[GM] In case of TMA (Tower Mounted Amplifier) 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.
Page 9/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 reestablishment 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
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.
Page 10/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
If the new Primary Cell is E-DCH and the call was E-DCH, then call is kept on
E-DCH.
RNC
Node B
source
Node B
target
UE
Primary cell change
Measurement Control (new neighbouring list)
RL Reconfiguration Prepare (E-DPCH information)

RL Reconfiguration Prepare (EDCH MAC-d flow to Delete)
RL Reconfiguration Commit (Activation CFN)
RL Reconfiguration Commit
(Activation CFN)
RB Reconfiguration (Activation CFN)
Activation CFN
RB Reconfiguration Complete
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 EDCH 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.
Page 11/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
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.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
The E-DCH AS is updated according to DL radio conditions
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).
Page 12/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
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 TTI, 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 nonserving radio links is monitored
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 nonserving NodeB(s):

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)
Iub
Cell of DCH AS (but not in E-DCH AS)

E-DCH
serving
cell
E-DCH serving NodeB:

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.
Iub
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.
Figure 3: E-DCH macro diversity general principle

Page 13/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 EDCH 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.
o The new added cell is not over IUR when SRB over E-DCH is used.
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.
Page 14/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
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 EDCH capabilities changed).
The mapping of Uplink SRB over E-DCH or over DCH may change during the call
upon certain events. Refer to the section 3.3.4 for more information.
{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 EDCH 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)
E-DPDCH min SF (i.e. highest E-DPDCH SF configuration available for the

E-DCH call, e.g. 2xSF2)
UL service (e.g. E-DCH stand-alone)
iCEM, xCEM and eCEM specificities:

[iCEM] [xCEM] [eCEM] For the iBTS, iCEM, xCEM and eCEM 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, xCEM and eCEM 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:
Page 15/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
iCEM handling E-DCH on E-DCH serving cell:

{10ms TTI, 2xSF4, IR},
{Ref E-TFCI; Ref PO} table of EdpchParameters/UECategory3EdchTti10ms
xCEM/eCEM 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] [eCEM] [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 xCEM, eCEM 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 Load from non-serving radio links to available
E-DCH Load, 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.
The E-DCH Load ratios below are computed when E-DCH Load
available.
requested
> E-DCH Load
Page 16/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
[iCEM]
If
E DCH Load Non Serving

E DCH Load Available
> targetNonServingToTotalEDCHPowerRatio
With
E DCH Load 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 Load Available : 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:
Common RG are used for UEs for which this cell is not under the serving
NodeB
Dedicated RG are used for UEs for which this cell is under the serving
NodeB (non-serving peer UEs)

If
E DCH Load Non Serving RLs of Non Serving NodeB

>
targetNonServingToTotalEDCHPowerRatio
With
E DCH Load 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 nonserving 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
E DCH Load Non Serving RLs of Serving NodeB

> edchSofterHoLimit
With
E DCH Load 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 nonserving peer UEs are considered here).
Then dedicated Down RG commands are sent from this cell to non-serving peer
UEs.
Page 17/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility

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.
OMC-R
RNC
RadioAccessService
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed
DedicatedConf
HoConfClass 60
UsHoConf /
PsHSDPA
CsSpeechPlusHSDPA
NodeB
FDDCell
targetNonServingToTotalEdchPowerRatio
EdchRncConf
maxNumberOfRlEdch
Number
of
instances
(indicated
when > 1)
15
FullEventHoConfShoMgt
FullEventRepCritShoMgt
FullEventHoConfShoMgtEvent1J
hysteresis1J
timeToTrigger1J
FullEventRepCritShoMgtEvent1J
amountRep1J
maxNbReportedCells1J
repActThresh1J
repInterval1J
NodeBConfClass 15
iubEdchDelayVariation
Figure 4: OMC-R RAN model for 32076
Page 18/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Below figure shows the RAN model at OMC-B.
Remark: All below parameters only apply to xCEM, eCEM or UCU-III (i.e. not used by
iCEM).
OMC-B
BTSEquipment
OneBTSEquipment
BTSCell
eDCHSofterHOLimit
EdchConf
edchSofterHoLimit
edchNumCommonRgPerCode
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
RAN Path
Object
RadioAccessService
Granularity
RNC
Range & Unit
User & Class
Customer, 3-a2
Value
True
isRrcEdchEvent1JAllowed: Flag enabling the configuration of Event 1J, when FullEvent Triggered reporting of measurements mode is used for intra-frequency
mobility.
Parameter
isRrcEdchEvent1JAllowed
RAN Path
Object
RadioAccessService
Granularity
RNC
Range & Unit
User & Class
Customer, 3-b
Value
True
Page 19/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
targetNonServingToTotalEdchPowerRatio:
[iCEM] (E-DCH handled by iCEM on considered cell):
Maximum allowed ratio of [E-DCH Load (at NodeB antenna of considered cell) from
non-serving RLs] to [available E-DCH Load].
[xCEM] [eCEM] [UCU-III] (E-DCH handled by xCEM, eCEM or UCU-III on
considered cell):
Maximum allowed ratio of [E-DCH Load (at NodeB antenna of considered cell) from
non-serving RLs of non-serving NodeB(s)] to [available E-DCH Load].
Parameter
targetNonServingToTotalEdchPowerRatio
RAN Path
Object
FDDCell
Granularity
FDDCell
Range & Unit
Integer [0 100], %
User & Class
Customer, 3-a1
Value
25
maxNumberOfRlEdch: Maximum E-DCH active set size (i.e. maximum number of EDCH RLs allowed per UE). Used to activate/deactivate 32076 E-DCH Macro Diversity
Support (maxNumberOfRlEdch = 1: feature deactivated).
Parameter
maxNumberOfRlEdch
RAN Path
Object
EdchRncConf
Granularity
RNC
Range & Unit
Integer [1 4], N/A
User & Class
Customer, 3-a2
Value
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
RAN Path
Object
NodeBConfClass
Granularity
NodeBConfClass
Range & Unit
Integer [1 255], Number of E-DCH TTIs
User & Class
Customer, 3-a1
Value

[UCU-III] 3
Note: a similar parameter iurEdchDelayVariation exists (object NeighbouringRNC)
but it is unused by the system and it can be set to 0.
Page 20/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
hysteresis1J: Hysteresis used when detecting Event 1J.
Parameter
hysteresis1J
RAN Path
RNC / RadioAccessService / DedicatedConf / HoConfClass / UsHoConf /

FullEventHOConfShoMgt / FullEventHOConfShoMgtEvent1J
Object
Granularity
HoConfClass, UsHoConf
Range & Unit
Decimal [0.0 7.5] step 0.5, dB
User & Class
Customer, 3-a2
Value
3.0
timeToTrigger1J: Duration for which Event 1J condition must be satisfied before

triggering the transmission of a Measurement Report.
Parameter
timeToTrigger1J
RAN Path
RNC / RadioAccessService / DedicatedConf / HoConfClass / UsHoConf /

FullEventHOConfShoMgt / FullEventHOConfShoMgtEvent1J
Object
Granularity
HoConfClass, UsHoConf
Range & Unit
Enum {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,
5000}, ms
User & Class
Customer, 3-a2
Value
100
amountRep1J: Amount of periodical reports, after an Event 1J Measurement Report

has been triggered.
Parameter
amountRep1J
RAN Path

FullEventRepCritShoMgt / FullEventRepCritShoMgtEvent1J
Object
Granularity
Range & Unit
Enum {1, 2, 4, 8, 16, 32, 64, Infinity}, N/A
User & Class
Customer, 3-a2
Value
Infinity
Page 21/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
maxNbReportedCells1J: Maximum number of reported cells for Event 1J
Measurement Report.
Parameter
maxNbReportedCells1J
RAN Path

Object
Granularity
Range & Unit
Integer [1 6], N/A
User & Class
Customer, 3-a2
Value

[UCU-III] 6
repActThresh1J: Minimum number of cells in E-DCH AS in order for Event 1J to be

detected.
Parameter
repActThresh1J
RAN Path

Object
Granularity
Range & Unit
Integer [2 4], N/A
User & Class
Customer, 3-a2
Value
repInterval1J: Interval between two periodical reports, after an Event 1J

Measurement Report has been triggered.
Parameter
repInterval1J
RAN Path

Object
Granularity
Range & Unit
Enum {0, 250, 500, 1000, 2000, 4000, 8000, 16000}, ms
User & Class
Customer, 3-a2
Value
16000
It is recommended to set repInterval1J to an high value, e.g the highest possible
value, in order to limit unneeded RRC signalling (repetitions of event1J) in the cases
where the event1J (and its repetitions) is intentionally ignored by the RNC: typically
an event1J for Primary Cell replacement, see 3.3.3.1.2, or an event1J for replacement
of a Radio Link hosted on a cell with different E-DCH capabilities than the Primary
Cell).
3.3.3.2.4 OMC-B PARAMETERS

Page 22/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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] [eCEM] edchSofterHoLimit

[UCU-III] eDCHSofterHOLimit
RAN Path
[xCEM] [eCEM] BTSEquipment / BTSCell / EdchConf

Object

Granularity
[xCEM] [eCEM] BTSCell

Range & Unit
Integer [0 100], %
User & Class
Customer, 3
Value
40
[xCEM] [eCEM] 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
RAN Path
Object
EdchConf
Granularity
BTSCell
Range & Unit
Signed [-35.0 15.0] step 0.1, dB
User & Class
Customer, 3
Value
0.0
edchNumCommonRgPerCode: Number of signatures per E-RGCH/E-HICH channel

reserved for common RG commands.
Parameter
[xCEM] [eCEM] edchNumCommonRgPerCode

[UCU-III] eDCHNumCommonRGPerCode
RAN Path

Object

Granularity

Range & Unit
Integer [0 4], N/A
User & Class
Customer, 3
Value
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.
Page 23/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Parameter
RAN Path

Object

Granularity

Range & Unit
Signed [-35.0 15.0] step 0.1, dB
User & Class
Customer, 3
Value
0.0
3.3.4 RECONFIGURATION SRB E-DCH TO DCH 3.4KBPS

An UA08 enhancement (CR Id 367062) allows the Uplink SRB reconfiguration from EDCH to DCH 3.4kbps when the E-DCH Macro-Diversity becomes impossible for the
SRB.
Indeed it may happen that the non-serving radio links of an E-DCH call can not have
the SRB mapped over E-DCH while the serving E-DCH radio link do have the SRB
mapped over E-DCH.
Typically this situation may happen in case of contiguous cells having different E-DCH
capabilities, e.g 2msTti capable cell contiguous with 10msTti capable cell, Nodeb
equipped with xCEM contiguous with Nodeb equipped with iCEM, in case of IUR
interface between the cells (SRB over E-DCH not being supported over IUR), in case
of E-DCH CAC failures preventing a non-serving radio link to be added in the E-DCH
active set, in case of E-DCH active set being full while the DCH active set is not,
In these cases where the serving E-DCH radio link has the SRB mapped over E-DCH
and the non-serving radio link(s) can not, the SRB losses the E-DCH macro-diversity
gain and this could lead to call drop.
To reduce this risk as much as possible, the RNC evaluates which mapping for Uplink
SRB (either over E-DCH or over DCH 3.4kbps) would help keeping the diversity gain
and it performs reconfiguration of the SRB from E-DCH to DCH 3.4kbps accordingly.
Non-serving RL Setup/Addition (event 1A)
The following event1A scenarii are covered by this enhancement:
The non-serving RL is not 2ms capable or not E-DCH capable
The non-serving RL does not pass the E-DCH CAC (CAC could be one of the
features 34441.1/34441.2, 125567 or 82602/R3)
The non-serving RL is over IUR
At the end of the non-serving RL setup/addition, the RNC will reconsider if the SRB
over E-DCH still benefits from macro-diversity and if not it will reconfigure the SRB to
DCH 3.4kbps.
It is important to note that the reconfiguration of the SRB is done in a second step
through a Synchronized Radio Link Reconfiguration, meaning the SRB would lack of
Page 24/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Macro-Diversity in the interval between the end of the non-serving RL setup/addition
and the end of the Synchronized Radio Link Reconfiguration. In some special radio
environments (UL/DL unbalanced paths), this may be too late to avoid a drop.
Another important note concerns a subsequent event1B (Radio Link removal): even if
the remaining cells would make possible to map again the SRB over EDCH, the RNC
still maintain the SRB over DCH. This strategy helps avoiding ping-pong and multiple
reconfiguration of the SRB. This is at the benefit of the call retainability but at the
expense of the peak throughput (a UE Category 6 can not achieve peak throughput if
the SRB is not over EDCH). However the SRB may be placed again over EDCH at the
next Primary Cell change.
The
parameter
reserved1
Byte2
bit2,
which
will
be
renamed
isSrbOnEdchEligibleOnE1A in the future, activates the enhancement for event1A
related scenario.
Parameter
RAN Path
Range & Unit
User
Class
Value
0 or 1
Customer
3
Object
RadioAccessService
Granularity
RNC
1
Other scenario:
PS radio bearer setup with multiple RL, one of the non-serving cell is not 2ms
capable or not EDCH capable;
CS Radio bearer release, with remaining PS radio bearer, one of the nonserving cell is not 2ms capable or not EDCH capable.
The RNC re-evaluates if the SRB benefits from macro-diversity; if not it keeps the SRB
over DCH
The reserved1 Byte2 bit3, which will be renamed isSrbOnEdchEligibilityReEvaluated in
the future, activates the enhancement for the above other scenario.
Parameter
RAN Path
Range & Unit
User
Class
Value

0 or 1
Customer
3
Object
RadioAccessService
Granularity
RNC
Page 25/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Engineering Recommendation: Reconfiguration SRB EDCH to DCH 3.4kbps
in case of loss of EDCH Macro-Diversity for the Uplink SRB (Enhancement 367062)
It is recommended to turn both flags to true to improve the EDCH call retainability.
RNC/RadioAccessService reserved1 Byte2 bit2 = 1
RNC/RadioAccessService reserved1 Byte2 bit3 = 1
3.3.5 RECONFIGURATION SRB HSDPA TO DCH 3.4KBPS

Based on the SRB RAB matching algorithm, the SRB will be mapped onto an UL and
DL transport channel. The uplink E-DCH is always used in conjunction with the HSDSCH in the downlink.
As a result, the same conditions triggering the reconfiguration of SRB E-DCH to DCH
3.4KBPS also trigger the reconfiguration of SRB HSDPA to DCH 3.4KBPS (E-DCH active
set is full, capable cell contiguous with 10msTti capable cell, IUR, E-DCH Cac failures).
In addition, SRB HSDPA to SRB DCH 3.4KBPS reconfiguration is triggered when the
radio condition is not good enough to keep the SRB in HSPA with F-DPCH i.e. if the
CPICH RSCP (resp. CPICH Ec/No) measurement received from UE (in any RRC
message) is below srbOverHspaRscpThreshold - srbOverHspaRscpHysteresis (resp.
srbOverHspaEcNoThreshold - srbOverHspaEcNoHysteresis). Refer to Volume 5 section
9.5 for SRB HSDPA parameter description.
3.4 FULL EVENT SHO SETTING FOR HSXPA

As presented in details in UPUG Vol. 12, [R01], mobility setting is 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.
Page 26/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Parameter
mobilityServiceType
RAN Path
Object
DlUserService
HsdpaCombination (optional)
RNC / RadioAccessService / UserServiceProfiles / HsdpaUserServiceProfile /

HsdpaCombination (optional)
Range & Unit
Enum
{Signalling, CsSpeech, CsSpeechPlusHSDPA, CsSpeechPlusPsIbLowBR,
CsSpeechPlusPsIbHighBR, CsSpeechPlusPsStrLowBR, CsSpeechPlusPsStrHighBR,
CsStreaming, CsConversational, CsConversationalPlusPsIbLowBR,
CsConversationalPlusPsIbHighBR, CsConversationalPlusHSDPA, PsHSDPA,
PsIbLowBR, PsIbHighBR, PsIbLowBRPlusHSDPA, PsStrLowBR, PsStrHighBR,
PsStrLowBRPlusHSDPA, PsStrHighBRPlusHSDPA, SpeechOnHSPA,
SpeechPlusDataOnHspa, SignallingOnHSPA, SpeechPlusSignallingOnHSPA,
DataPlusSignallingOnHSPA, SpeechPlusDataPlusSignallingOnHSPA, PsQChatHspa}
Customer
Granularity DlUserService
3
User
Class
Value
Refer to UPUG Vol. 12, [R01], for the exhaustive mapping of DlUserService and
mobilityServiceType.
Note: New HSDPA combinations reuse the mobilityServiceType concept by
duplicating this parameter on the new UA08.1 optional object HsdpaCombination.
If parameter mobilityServiceType is set under the optional object
HsdpaCombination, it is used. If the parameter is unset under the optional object
HsdpaCombination, then the parameter under RNC / RadioAccessService /
DlUserService is used instead.
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).
Page 27/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Event
mobilityServiceType
Parameter
Object
Others
PsHSDPA
with
HSDPA
1A
cpichEcNoReportingRange1A
3.5 dB
4.5 dB
FullEventHOConfShoMgtEvent1A
200 ms
timeToTrigger1A
1B
cpichEcNoReportingRange1B
FullEventHOConfShoMgtEvent1B
5.5 dB
1280 ms
timeToTrigger1B
1C
7.5 dB
hysteresis1C
7.5 dB
FullEventHOConfShoMgtEvent1C
timeToTrigger1C
1D
320 ms
hysteresis1D
FullEventHOConfShoMgtEvent1D
timeToTrigger1D
6 dB
6 dB
1280 ms
640 ms
useCioFor1D
1E
False
isEvent1EUsed
FullEventHOConfShoMgt
cpichEcNoThresholdUsedFreq1E
False
-11 dB (N.S.)
FullEventHOConfShoMgtEvent1E
timeToTrigger1E
1F
100 ms (N.S.)
isEvent1FUsed
FullEventHOConfShoMgt
cpichEcNoThresholdUsedFreq1F
False
-15 dB
FullEventHOConfShoMgtEvent1F
timeToTrigger1F
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.
Page 28/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
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.
HSDPA MAC-ehs and HSDPA-DC (Dual Cell) mobility over IUR:

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. However, after the relocation, the new RNC learns the MAC-ehs support
capabilities of the UE through the UE Capability Enquiry procedure, and it will
reconfigure the call to MAC-ehs at the next inter-nodeB mobility occasion towards a
MAC-ehs capable cell.
The same above principles apply to HSDPA-DC calls, since they require Mac-ehs and
MAC-ehs is not supported over IUR (refer to the description of the feature 81204 in
the Volume 3 for more details). In case an HSDPA-DC call moves over IUR, i.e the
primary cell becomes under a Drift RNC, the call is reconfigured as HSDPA-SC (Single
Cell) and mapped on MAC-hs. However it may recover the DC operation at the next
inter-nodeB mobility occasion towards a DC capable cell.
Refer also to the section 3.6 for HSDPA MAC-ehs and HSDPA-DC SRNS relocation -UE
involved specificities.
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
Page 29/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
release of active HSUPA calls over Iur. From UA7.1.3 onwards, HSUPA over Iur is
supported in the US Market.
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 (nonprimary) E-DCH link will be established over IuR.
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 E-DCH mobility, based on the primary cell
E-DCH capabilities and the target drift cell E-DCH capabilities in terms of
E-DCH support
TTI capabilities (2ms or 10ms)
Min SF capabilities
Note that the E-DCH 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 E-DCH 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 E-DCH over Iur toward some
specific drift cells. We can for example limit the E-DCH 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 E-DCH bandwidth
limitation management for the drift BTS.
The DRNC detects the E-DCH congestion based on E-DCH frame loss as
described in HPUG volume 4.
The DRNC discard the TNL congestion messages received from the SRNC.
Page 30/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Restriction:
In UA6.0, the Iur E-DCH 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 supported the following way with
UA7.1 feature 34229 inter-freq HO enhancements : in case of inter-frequency over Iur
mobility for a call in DCH/HSDPA or E-DCH/HSDPA, system will reuse HSPA to DCH
reconfiguration & DCH to HSPA reconfiguration procedure to perform mobility towards an
HSPA capable cell in the DRNC (please note that HSPA to DCH and DCH to HSPA
reconfiguration will not apply in case of handover from DRNC to SRNC since the SRNC have
knowledge about the HSPA context).
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:
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsdpaOverIurAsSrncAllowed:
This parameter allows

enable/disable HSDPA over Iur when acting as a Serving RNC.
isHsdpaOverIurAsSrncAllowed
Boolean
{True, False}
Customer
3-a2
RNC
Object
RadioAccessService
Granularity
RNC
to
True
isEdchOverIurSrncAllowed: This parameter allows RNC to enable/disable

HSUPA over Iur when acting as a Serving RNC.
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchOverIurSrncAllowed
Object
RadioAccessService
Boolean
{True, False}
Customer
3
[xCEM] [eCEM] True
[UCU-III] False
Granularity
RNC
Page 31/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsdpaOverIurAsDrncAllowed:
This parameter allows RNC

accept/reject HSDPA reconfiguration over Iur when acting as a Drift RNC.
isHsdpaOverIurAsDrncAllowed
Boolean
{True, False}
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
to
True
isEdchOverIurDrncAllowed: This parameter allows RNC to accept/reject

HSUPA reconfiguration over Iur when acting as a Drift RNC.
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchOverIurDrncAllowed
Object
RadioAccessService
Boolean
{True, False}
Customer
3
[xCEM] [eCEM] True
[UCU-III] False
Granularity
RNC
Parameter
RAN Path
Range & Unit
User
Class
Value
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.
isMacShHsdpaAllowed
Boolean
{True, False}
Customer
3-b
Object
RadioAccessService
Granularity
RNC
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].
Page 32/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
isHsdpaAllowed: This parameter under NeighbouringRNC defines the

HSDPA capabilities of neighbouring RNC to which Iur link is provisioned.
Parameter
RAN Path
Range & Unit
User
Class
Value
isHsdpaAllowed
RNC / NeighbouringRNC
Boolean
{True, False}
Customer
3
Object
NeighbouringRNC
Granularity
RNC
True
isEdchAllowed: This parameter under NeighbouringRNC defines the

HSUPA capabilities of neighbouring RNC to which Iur link is provisioned.
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchAllowed
Boolean
{True, False}
Customer
3-a2
Object
NeighbouringRNC
Granularity
RNC
True
isHsdpaAllowed: This parameter under RemoteFddCell defines the

HSDPA capabilities of an UMTS neighbouring cell belonging to another RNC..
isHsdpaAllowed
Object
RNC / UmtsNeighbouring / RemoteFDDCell
Parameter
RAN Path
Range & Unit
User
Class
Value
RemoteFDDCell
False, True
Customer
3-a2
Granularity
Cell
True
See also the following rule.
EdchMinSfCapability: This parameter under RemoteFddCell defines the

HSUPA capabilities of an UMTS neighbouring cell belonging to another RNC.
Parameter
RAN Path
Range & Unit
User
Class
Value
edchMinSfCapability
Object
RemoteFDDCell
Sf8, sf4, 2sf4, 2sf2, 2sf2and2sf4
Customer
3
Granularity
Cell
Depends on remote cell capabilities. Default value: 2sf4.
Page 33/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
isEdchAllowed: This parameter under RemoteFddCell defines the HSUPA

capabilities of an UMTS neighbouring cell belonging to another RNC.
isEdchAllowed
Parameter
RAN Path
Range & Unit
User
Class
Value
Object
RemoteFDDCell
False, True
Customer
3
Granularity
Cell
True
See also the following rule.
isEdchTti2msAllowed: This parameter under RemoteFddCell defines the

HSUPA capabilities of an UMTS neighbouring cell belonging to another RNC.
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchTti2msAllowed
Object
RemoteFDDCell
False, True
Customer
3
Granularity
Cell
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 HSDSCH 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
The parameter isRnsapCr1357Supported under NeighbouringRNC is used to
allow 3GPP [R04] Rel-7 CR1357 Iur compliance.
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.
Parameter
RAN Path
Range & Unit
User
Class
Value
isRnsapCr1357Supported
Customer
3
Object
NeighbouringRNC
Granularity
Neighbouring RNC
See engineering recommendation below

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

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 is
supported in UA7.1).
Engineering Recommendation: New parameter introduced in UA7.1 concerning the
RNSAP messages
For SRNC UA7.0/UA7.1 or latter:
If DRNC is Rel-6 (or earlier), isRnsapCr1357Supported = False
If DRNC is Rel-7 (or latter), isRnsapCr1357Supported = True (3GPP [R04] Rel-7 CR1357
support)
If DRNC is Rel-7 (or latter), isRnsapCr1357Supported = False (3GPP [R04] Rel-7 CR1357
no support)
After UA7.1 introduction, Alcatel-Lucent UTRAN fully supports not only CR1357 [R04]
but also CR1462 [R05]. Another parameter is then introduced:
Parameter
RAN Path
Range & Unit
User
Class
Value
isNbapCr1462Supported
RNC / NodeB
Customer
3
Object
NodeB
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
Page 35/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.

For proper Iur IOT with DRNCs that reject RNSAP Radio Link Reconfigurations if SRB
is setup as downlink DCH only (for example Ericsson RNCs), the RadioAccessService.
isEdchIurRestrictionEnabled has to be set to True when the
NeighbouringRNC.isEdchAllowed is set to False. This parameters combination is used
to trigger a UL DCH fall back for E-DCH calls before adding an Iur link.
This function is mainly used in the [US] Market where this Iur IOT issue is often met.
However nothing prevents using it in the [GM] Market, should such Iur IOT issue
occur.
Parameter
RAN Path
Range & Unit
User
Class
Value
isEdchIurRestrictionEnabled
Customer
3
Object
RadioAccessService
Granularity
RNC
Engineering Recommendation: isEdchIurRestrictionEnabled concerning E-DCH over Iur

IOT
If DRNC rejects RNSAP Radio Link Reconfiguration if SRB is setup as "downlink-DCH-only" (e.g.
Ericsson RNC) set this flag to True
Otherwise set flag to False
This parameter is only checked when NeighbouringRNC.isEdchAllowed is False.
Page 36/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
UA7-UA08.1 Delta: isEdchIurRestrictionEnabled.
Pre-UA7.1.3 release: the behaviour fallback to UL DCH for E-DCH calls before adding an Iur link was
applicable only to the [US] Market. It was governed by a parameter specific to this market.
In UA7.1.3 release: this behaviour is extended to the [GM] market and, for both [GM] and [US], it is
governed by the combination: neighboringRNC.isEdchAllowed = FALSE and
RadioAccessService.reserved2 (byte 3, bit 0) = True
In UA08.1 release: the parameter RadioAccessService.reserved2 (byte 3, bit 0) is replaced with
RadioAccessService.isEdchIurRestrictionEnabled. Again, it is only checked when
NeighbouringRNC.isEdchAllowed is False.
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
o
Parameter
RAN Path
Range & Unit
User
Class
Value
When set to False, this parameter prevents any Inter-Frequency HHO

from HSDPA, and only the 2 following transitions can then occur for
DL Transport Channel:
DCH to HSDPA
DCH to DCH
When set to False, this parameter also prevents any Intra-frequency

Inter-RNC HHO from HSDPA.
isHsdpaHhoWithMeasAllowed
Boolean
{True, False}
Customer
3
Object
RadioAccessService
Granularity
RNC
TRUE
Page 37/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
isEdchHhoWithMeasAllowed: when set to FALSE, no compressed mode is

activated for E-DCH (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
o
Parameter
RAN Path
Range & Unit
User
Class
Value
When set to False, this parameter prevents any Inter-Frequency HHO

from E-DCH, and only the 2 following transitions can then occur for
UL Transport Channel:
DCH to E-DCH
DCH to DCH
When set to False, this parameter also prevents any Intra-frequency

Inter-RNC HHO from E-DCH.
isEdchHhoWithMeasAllowed
Boolean
{True, False}
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
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.
HSDPA MAC-ehs and HSDPA-DC (Dual Cell) intra-frequency inter-RNC HHO:

SRNS relocation - UE involved (Inter RNC mobility without IUR) for HSDPA MAC-ehs
calls (feature 34388) and HSDPA-DC (feature 81204) is supported. The Source RNC
needs to know the release supported by the Target RNC in order to select the proper
Source to Target Transparent Container format and eventually properly encode the
MAC-ehs and HSDPA-DC specific IEs.
Upon relocation, the RB is configured accordingly to the MAC-ehs and HSDPA-DC
capability of the target cell in the Target RNC. Of course, if the Target RNC is running
with an oldest release not compatible with MAC-ehs or Dual Cell, the RB will no longer
be mapped on MAC-ehs or Dual Cell.
The Source RNC knows the release of the Target RNC through the parameter
rncRelInd in the object NeighbouringRNC. This parameter is used for both types of
relocation (UE involved and UE not involved)
Page 38/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Parameter
RAN Path
Range & Unit
User
Class
Value
rncRelInd
R99, R4, R5, R6, R7, R8, R9, R10
Customer
3
Object
NeighbouringRNC
Granularity
Neighbouring RNC
Set the value corresponding to the release supported by the Target RNC
The source RNC determines the 3GPP ASN.1 version for the RRC Source to Target
transparent container as the minimum value between the UE release and the
neighbouring target RNC release indicated by the parameter rncRelInd. Note that the
support of the Rel8 ASN.1 container is introduced by the feature 104832/118154.
If the call has specificities not supported by the 3GPP ASN.1 transparent container
version, the source RNC, prior to relocation reconfigures the call to a suitable
configuration that can be modelled in the transparent container.
Engineering Recommendation: rncRelInd in object NeighbouringRNC

The release of the Target RNC must not be over-estimated, otherwise the SRNS relocation of an
HSDPA call mapped on MAC-ehs may lead to call drop.
Upon SRNS relocation of an HSDPA call mapped on MAC-ehs:
If under the Source RNC, the object NeighbouringRNC representing the Target RNC is missing or if
NeighbouringRNC/rncRelInd under-estimates the release of the Target RNC, then the Source RNC
would proceed to useless call reconfiguration prior to relocation. However the relocation would
succeed anyway.
If the NeighbouringRNC/rncRelInd over-estimates the release of the Target RNC, the Source RNC
would encode MAC-ehs specific IEs in the Rel7 Source to Target Transparent Container that could
not be decoded by the Target RNC, leading to call drop.
UA7-UA08.1 Delta: reserved0 (second byte) in object NeighbouringRNC is replaced with

rncRelInd.
In UA7, the parameter used to configure the release of a neighbouring RNC was the second byte of
reserved0 in the object NeighbouringRNC.
From UA08.1 onwards, it is replaced by the parameter rncRelInd (still in the object
NeighbouringRNC).
Page 39/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
UA7-UA08.1 Delta: the feature 104832/118154 allows resuming immediately HSDPA-DC
operation after a relocation thanks to the Support of 3GPP R8 transparent container.
In UA7, the SRNS ASN Containers for Rel8 is not available. Therefore, the UA7 release does not
support SRNS relocation as a Rel8 UE. SRNS Relocation for HSDPA-DC call will trigger reconfiguration
out of Dual Cell to single cell HSDPA prior to relocation. Since as part of the existing post SRNS
relocation procedures the Target RNC requests the UE capabilities, the possible DC capability will be
considered and lead to a reconfiguration to DC operation on next mobility SHO or HHO.
From UA08.1, the SRNS ASN Containers for Rel8 is supported (feature 104832/118154), allowing
resuming immediately HSDPA-DC operation after a relocation.
Page 40/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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/eCEM/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 retransmission 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.
Restriction: Higher Layer Scheduling (HLS) method not supported with HS-DSCH or EDCH
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.
Page 41/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
Status [Id] 2 . 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).
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
CMCFN is valid, current patterns have to be stopped at CMCFN if not
finished yet.
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.
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].
[Id] means that this information must be provided for each configured pattern.
Page 42/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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).
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][eCEM][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.
Page 43/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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/eCEM/UCU-III), 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.
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.
For the 10ms E-DCH TTI case, 3GPP [R03] 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.
Page 44/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
0.66ms slot
10ms E-DCH TTI
0 1 2 3 4 5 6 Tx Gap 11121314
First HARQ transmission
10ms E-DCH TTI

0 1 2 3 4 5 6 7 8 9 10 DTX
HARQ retransmission
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 EDCH 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 EDCH 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
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 EAGCH (cf. [Vol. 4]), i.e. it sends a forced-ACK to the UE (and retransmits the EAGCH). 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.
Page 45/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 ERGCH command) is reduced by the UE to SG, according to the number of non-DTX
slots Nc in the TTI:
SG = SG * (Nc/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 the 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 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.
Page 46/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
Page 47/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Node-B support for E-DCH compressed mode
UE support for EDCH compressed mode
No
No
Yes
[iCEM][xCEM] : pre-UA5.1
[iCEM][xCEM][eCEM]: from UA5.1 (33480)
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.
CM gaps not taken into account by UE when

transmitting on E-DCH A MAC-e PDU
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 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
Yes gapped format as well it cannot be decoded.
RLC retransmission triggered after maximum
number of HARQ transmissions reached.
Important E-DCH throughput degradation.
Node-B expects UE to auto-reduce its grant and

UE does not do so (detected by Node-B due to ETFC 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.
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.
No possibility for network to detect this case.
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
combination with HSDPA or with HSUPA.
not
support
compressed
mode
in
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 RRC 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.
Page 48/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 intermediate 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.
Page 49/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
RAN Path
Range & Unit
User
Class
Value
isHSDPACMFallbackAllowed
Customer
3-a2
Object
RadioAccessService
Granularity
RNC
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
RAN Path
Range & Unit
User
Class
Value
Object
Enum {never, ueDependent, allowedAlways}
Customer
Granularity
3-a2
RadioAccessService
RNC
See following recommendation
Engineering Recommendation: Fallback of HSUPA to DCH on CM activation
isEdchCmFallbackAllowed is recommended to set to 'ueDependent'.
Page 50/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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),
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:
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.
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.
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),
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),
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.
Page 51/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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].
Page 52/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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 interfrequency measurement activation is allowed or not in the RNC.
Parameter
RAN Path
Range & Unit
User
Class
Value
isInterFreqMeasActivationAllowed
Boolean
{True, False}
Customer
3
Object
RadioAccessService
Granularity
RNC
TRUE
isInterFreqCModeActivationAllowed:
This parameter allows

activation for Inter-frequency measurements, per DlUserService.
Parameter
RAN Path
Range & Unit
User
Class
Value
Boolean
{True, False}
Customer
3
enabling
Object
DlUserService
Granularity
DlUserService
CM
Page 53/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
isGsmCModeActivationAllowed: This parameter allows enabling CM activation for
GSM measurements, per DlUserService.
Parameter
RAN Path
Range & Unit
User
Class
Value
isGsmCModeActivationAllowed
Boolean
{True, False}
Customer
3
Object
DlUserService
Granularity
DlUserService
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. HSDSCH).
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 iCEM, xCEM, eCEM 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
Page 54/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
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, the call configuration information is transported from
the Source RNC to the Target RNC in the RRC Source to Target transparent container.
The source RNC determines the ASN.1 RRC transparent container version to be used
as the minimum between the Target RNC release indicated in the parameter
NeighbouringRNC.rncRelInd and the UE release. The RRC container then contains
information about:
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. Calls originally operating in HSDPA-DC (Dual Cell)
in the source RNC may also directly be setup as HSDPA-DC by the Target RNC without
need for temporary transition to HSDPA-SC (single cell) (feature 104832/118154).
Refer also to the section 3.6 for HSDPA MAC-ehs and HSDPA-DC SRNS relocation -UE
involved description.
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]
Page 55/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
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].
Page 56/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
PARAMETERS:
isInterFreqHandoverOverIurAllowed: This parameter enables/disables the interfrequency hard handover over Iur on a per neighbouring RNC basis
isInterFreqHandoverOverIurAllowed
Parameter
RAN Path
Range & Unit
Boolean
{True, False}
Customer
3
User
Class
Value
Object
NeighbouringRNC
Granularity
N/A
TRUE
6.1.4 FULL EVENT HHO SETTING FOR HSXPA
2D
2F
Parameter
Object
Value
Event
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].
cpichEcNoThresholdUsedFreq2D
FullEventHOConfHhoMgt
-14
cpichRscpThresholdUsedFreq2D
-110
timeToTrigger2D
FullEventRepCritHHOMgt
1280
cpichEcNoThresholdUsedFreq2F
-13
cpichRscpThresholdUsedFreq2F
-108
timeToTrigger2F
FullEventRepCritHHOMgt
1280
timerAlarmHOEvent
Table 3: HHO Event Recommended Settings Summary

.
that
minimumCpichEcNoValueForHO
and
minimumCpichRscpValueForHO (defined per DlUserService) must be set
Note
accordingly to 2D thresholds and network topology in order to prevent abusive

successive inter-frequency HHO.
Page 57/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
Page 58/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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
RAN Path
Range & Unit
User
Class
Value
Parameter
RAN Path
Range & Unit
User
Class
Value
iubSuspendTimeOffset
Object
NodeBConfClass
Integer
[0 255] (x 10ms)
Customer
Granularity
RNC
3-a2
16
iurSuspendTimeOffset
Integer
[0 255] (x 10ms)
Customer
3
Object
NeighbouringRNC
Granularity
RNC
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.
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.
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).
Page 59/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
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.
Page 60/61

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
UA08.1 Preliminary
16/Mar/2012
Volume 6 : Mobility
Z END OF DOCUMENT Y
Page 61/61
UMT/IRC/APP/016664
DEPLOYMENT SCENARIOS
V05.04
16/MAR/2012

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Volume 7 : Deployment Scenarios
CONTENTS
1
INTRODUCTION............................................................................................................4
1.1
OBJECT ....................................................................................................................... 4
1.2

2.1
HPUG VOLUMES ............................................................................................................ 5
2.2
DEPLOYMENT STATUS ..................................................................................................6
CARRIER DEPLOYMENT & STRATEGY RECOMMENDATIONS .......................................8

4.1
TRAFFIC DISTRIBUTION..................................................................................................... 8
4.2
TYPICAL UA7 DEPLOYMENT SCENARIOS .............................................................................. 10
4.3
UA08 DEPLOYMENT SCENARIOS ....................................................................................... 13
4.4
UA08 STRATEGY DEPENDENCIES ...................................................................................... 14
4.5
UA08 STRATEGY OPTIONS AND REQUIREMENTS .................................................................... 16
4.6
UA08 CELL TOPOLOGIES ................................................................................................ 17
4.7
CELL RESELECTION FOR UA08 DEPLOYMENTS ...................................................................... 18
4.8
IMCRA FOR
4.9
UA08 DEPLOYMENTS..................................................................................... 20
4.8.1
4.8.2
4.8.3
bi-frequency Deployments................................................................................... 20
tri-frequency Deployments .................................................................................. 21
four-frequency Deployments ............................................................................... 22
IMCTA FOR UA08 DEPLOYMENTS ..................................................................................... 23
4.10
SPECIFIC HANDLING OF NETWORKS WITH MORE THAN 3 CARRIERS.............................................. 24
4.11
UMTS
4.12
TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION ..................................................................
28
4.13
CPICH DESIGN CHOICES ..................................................................................................
29
4.14
TYPICAL STRATEGY FOR IRAT MOBILITY ............................................................................. 30
4.15
TYPICAL STRATEGY FOR SMALL CELLS MOBILITY .................................................................... 31
4.16
ONEBTS
4.16.1
4.16.2
2100/1900 MHZ VERSUS UMTS 900/850 MHZ ............................................................. 26
6 CARRIER 2NB CONFIGURATION (120426)............................................................... 32
Feature description............................................................................................. 32
feature impacts .................................................................................................. 32
Page 1/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
TABLES
Table
Table
Table
Table
Table
Table
1:
2:
3:
4:
5:
6:
different topologies of carriers with the minimum associated hardware

iMCRA strategy used in UA7 deployments
Bi carrier deployments strategies using iMCRA Step2
Tri carrier deployments strategies using iMCRA Step2
Four carrier deployments strategies using iMCRA Step2
Round-robin
7
12
21
22
23
25
Page 2/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1:
2:
3:
4:
5:
6:
7:
8:
Examples of applications for traffic distribution ................................................................ 9

Examples of overload handling strategies at various cell load levels ................................. 10
Example of Dynamic Segmentation and Load Balancing application ................................. 13
Example of DATA Sequential Loading and CS offloading application ................................. 14
Field example of SIB11 strategy to manage idle mode .................................................... 25
Example for mixed frequency deployment scenarios ....................................................... 26
Typical scenarios for neighbour declaration.................................................................... 28
Typical IRAT mobility scenarios .................................................................................... 31
Page 3/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
1 INTRODUCTION
1.1 OBJECT
The main objective of this document is to describe from an engineering point of view
the R99 & HSDPA & E-DCH (HSUPA) multi-layer system deployments. It also makes
reference to 3G Small Cells deployment and LTE/GSM deployment. This document
intends to:
Specify the most attractive deployment scenarios for operators using UA08
capabilities;
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 4/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 6] Mobility

UTRAN Parameters User Guide UA08
NodeB Product Engineering Information UA08
Page 5/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

This part aims at:
Listing all the topologies that could be faced in UA08.1,
Providing the UA08.1 Deployment Engineering Recommendations.
In order to limit the realistic use cases, selection of the target UA08.1 topologies had
been based on:
HSxPA & R99 Performance expectations
Capacity usage efficiency
Deployment cost: New Hardware or Optimization activities (Network reengineering actions) required
A clean UL radio behaviour and performance is required for correct HSUPA

introduction and associated performance (see [Vol. 4]). 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 4.
The Table 1 is based on the following considerations (assuming 3 sectors):

iCEM:
- 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 EBBU (due to weaker performance of iCEM from HSUPA point of view it is
recommended only one E-BBU per Node-B whatever the number of iCEM
only one HSUPA carrier possible)
- 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 (due to weaker performance of
iCEM from HSUPA point of view it is recommended only one E-BBU per NodeB whatever the number of iCEM only one HSUPA carrier possible)
Page 6/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

x/eCEM:
- 1 xCEM contains 4 M-BBUs. In the default Multimode-BBU configuration,
each BBU can be used in the same time for R99, HSDPA and HSUPA
- each x/eCEM is able to manage up to 2 carriers
iCCM:
- 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)
x/eCCM:
- The maximum capacity configuration supported by an x/eCCM is:
- 5 x/e/iCEM (mixed allowed but not recommended with iCEM)- 3
UCU-III (Up to 3 frequencies within up to 3 HSDPA frequencies and
up to 3 HSUPA frequencies)
#carriers
F1
F2
F3
F4
Product
1 carrier
R99/HSxPA
STSR1
2 carriers
R99
HSxPA
STSR2; STSR1+1
2 carriers
R99/HSxPA
HSxPA
STSR2; STSR1+1
2 carriers
R99/HSxPA
R99/HSxPA
STSR2; STSR1+1
3 carriers
R99
HSxPA
HSxPA
STSR3; STSR2+1
3 carriers
R99/HSxPA
HSxPA
HSxPA
STSR3; STSR2+1
3 carriers
R99/HSxPA
R99/HSxPA
R99/HSxPA
STSR3; STSR2+1
4 carriers
R99
HSxPA
HSxPA
HSxPA
STSR2+2
4 carriers
R99/HSxPA
HSxPA
HSxPA
HSxPA
STSR2+2
4 carriers
R99/HSxPA
R99/HSxPA
R99/HSxPA
R99/HSxPA
STSR2+2
Minimum Hardware
eCEM/xCEM/iCEM
1 eCEM/xCEM; 1 iCEM128 + 1
iCEM64
1 eCEM/xCEM; 2 iCEM128
1 eCEM/xCEM; not recommended
with iCEM only
with iCEM only
with iCEM only
with iCEM only
with iCEM only
with iCEM only
with iCEM only
with iCEM only
Table 1: different topologies of carriers with the minimum associated hardware

As xCEM and eCEM have better performance than iCEM, its recommended to allocate
HSxPA services on xCEM and eCEM. 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.
Please note that up to 6 carriers using two different NodeBs can be defined. For
further details please refer to section 4.16.
Page 7/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
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 offered on the
following sections are based on UA08.1 topologies and are considering that HSUPA
can be introduced where HSDPA is present. Anyway, an initial section will detail the
UA7 typical deployment scenarios, also valid in UA08 context. A Node-B
(iBTS/OneBTS) can handle up to 4 HSDPA layers and 4 E-DCH layers. Deployment
scenarios up to 4 carriers will be detailed. However, please note that up to 6 carriers
using two different NodeBs can be defined.
4.1 TRAFFIC DISTRIBUTION

Traffic distribution can be based on various strategies, e.g. R99/HSDPA/HSUPA
segmentation, CS and PS segmentation or load distribution, or in a mixed solution.
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/LTE) 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 used 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
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 or
LTE. Redirection to LTE may apply to 4G capable UEs. 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 or LTE systems without any
specific cell information. Therefore, the UE can determine the most suitable cell
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
recommended 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
Page 8/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

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. 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.
Redirection in connected mode: Redirection may apply for PS only call
after AO downsize via RRC connection release towards LTE carrier based on load
condition if the UE is LTE capable. Redirection may also apply in case of AO upsize
trigger for Service or CAC with direct DCH transition on target carrier.
The Reselection, Redirections & 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 favouring a specific carrier on reselection. Load balancing
strategy cope with UEs camping homogeneously on different frequencies.
HSxPA Traffic
Copyright 1996 Northern Telecom
Load F1 first
R99 traffic
Non loaded
cell
Sequential Loading
Service segmentation
Overloaded
cell
Load Balancing
Overloaded cell
Speech call
GSM
GSM fallback
Figure 1: Examples of applications for traffic distribution

Page 9/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
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 distribute 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.
Rejection of RRC
Connection Requests
CAC Failure HO of Speech and Packet
Calls to 3G and 2G
iMCTA Service HO of Speech Calls to 2G
Redirection of Originating Speech Calls to 2G
iMCTA Service HO of Packet Calls to 3G
RRC Redirection of Speech and Packet Calls to Twin Cells
Cell Reselection in Idle mode
Cell Load Color
>= Green
Cell Load Color

>= Red
Cell Load Color

>= Yellow
CAC Failure at
RAB Est.
CAC Failure at
RRC Setup.
Cell Load
Figure 2: Examples of overload handling strategies at various cell load levels
4.2 TYPICAL UA7 DEPLOYMENT SCENARIOS

In UA7, iMCRA Step1 and HSPA Load Balancing features provided the possibility to
deploy iMCRA strategies based in the concept of:
Service Segmentation (Service Segmentation is often deployed to ensure

adequate protection for Voice services; it is often associated to Cell
Reselection strategies that favour F1).
o
Added Value
Protect Voice services against noise generated by PS calls.
Keep Voice services in the mobility layer since this kind of

service is more mobility sensitive.
Maximize HSPA throughput on low/medium traffic conditions.
Drawback
Accessibility and retainability for HSPA services is usually of

inferior quality comparing to Load Balancing strategy since
Service Segmentation relies heavily on blind RRC Redirection
Page 10/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

and force HSPA connections to often stay on HSPA layers
even in bad radio conditions.
On high traffic conditions, Voice and HSPA services may have

an asymmetric behaviour in terms of traffic volume and HSPA
throughput may be impacted.
Not recommended to use Service Segmentation based

strategies in case deploying mixed U1900 or U2100 layers on
top of U850/U900 coverage layers. For such deployments the
RRC redirection is critical since strategy relies heavily on blind
RRC Redirection.
Sequential Loading (Due to challenging PS traffic increase, some networks

are migrating to deployment strategies based either on Load Balancing or
Sequential Loading (Service Segmentation based solution running as Load
Balancing during the busy hours); it is often associated to Cell Reselection
strategies that favour F1).
o
Added Value
Protect Voice services against noise generated by PS calls.
Keep Voice services in the mobility layer since this kind of

service is more mobility sensitive.
This solution explores the benefits from both Service

Segmentation and Load Balancing strategies and maximizes
the HSPA throughput in loaded conditions.
Reduce the number of RRC redirections and improve PS

accessibility and retainability comparing to an only Service
Segmentation based strategy..
Drawback
Accessibility and retainability for HSPA services is usually of

inferior quality comparing to Load Balancing strategy since
Sequential Loading still relies heavily on blind RRC Redirection
and may force HSPA connections to stay on HSPA layers even
in bad radio conditions.
Not recommended to use Service Segmentation based

strategies (Sequential Loading in this case) in case deploying
mixed U1900 or U2100 layers on top of U850/U900 coverage
layers. For such deployments the RRC redirection is critical
since strategy relies heavily on blind RRC Redirection.
Load Balancing (Load Balancing strategy becomes widely deployed on

several networks to cope with high traffic scenarios and to deal with mixed
topologies 1900/850 MHz; it is often associated to Cell Reselection strategies
with UEs camping homogenously across different carriers).
o
Added Value
Page 11/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Suitable for capacity oriented purposes. On high traffic

conditions there is a real capacity gain by spreading Voice
and HSPA traffic in a symmetric way across different layers
Suitable in case deploying mixed U1900 or U2100 layers on

top ofU850/U900 coverage layers; for this strategy the RRC
redirection has lower implication since decisions are based on
DL Radio and UL Radio load.
Maximizes the HSPA throughput in loaded conditions.
Reduce considerably the number of RRC redirections ensuring

goods accessibility.
Drawback
Performance for Voice retainability may be worst since CS

traffic on upper layers wont have SHO exit possibility and
may need to perform an alarm HHO with increasing risk of
call drop. However, Networks still relying on GSM coverage
may use this technology to rescue Voice calls from upper
layers using aggressive event2D thresholds.
The following table summarises the iMCRA strategies used in UA7 deployments.
TOPOLOGY
HSxPA
iMCRA Strategy
Traffic Segmentation based on Call Type strategy:
DCH calls are always assigned to F1.
HSxPA
HSPA calls are always assigned to less loaded F2+.
R99
Emergency calls are redirected in case of CAC failure, only.
SEQUENTIAL LOAD strategy:
HSxPA
DCH calls are always assigned to F1.
HSxPA
HSPA calls are load distributed to F2+ if unloaded F2+ cells available.
Else, if F2+ cells are loaded then HSPA establishment in F1 if unloaded.
Else (all cells are loaded) HSPA call establishment in F2+.
R99/HSxPA
Pure LOAD BALANCING strategy:
CS/Data
DCH and HSPA calls are load distributed if twin cell load is lower than originating cell load.
CS/Data
Load distribution starts later for DCH and Streaming calls (when originating cell becomes RED).
CS/Data
Load distribution starts early for HSPA calls (when originating cell becomes YELLOW).
Table 2: iMCRA strategy used in UA7 deployments
Page 12/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
4.3 UA08 DEPLOYMENT SCENARIOS

Decision to deploy Service Segmentation, Sequential Loading or Load Balancing
strategies may depend on customer needs and network context. All different
deployment strategies have valuable applications depending mostly on traffic profile,
network topology, service priorities, and performance objectives or even on network
configuration effort. In UA08.1, iMCRA Step2 feature provides a powerful
programmable RRC redirection action matrix allowing exploring Service Segmentation,
Sequential Loading, Load Balancing and Offloading capabilities by their own or in a
mixed strategy depending on load conditions. Two different strategies are
recommended for deployment in UA08:
Dynamic Segmentation and Load Balancing (Cell Reselection strategy with

UEs camping homogenously across different carriers). Allow exploring the
capabilities from both Service Segmentation and Load Balancing strategies;
Service Segmentation used only if layers unloaded for both CS and DATA services;
Load Balancing used if layers loaded for both CS and DATA services. Main
philosophy:
o
Segmentation for CS Services to F1 layer if F1 unloaded; in

preference, CS Services will run in the layer intended to be the layer
providing continuity in the network.
Segmentation for DATA Services to F2+ layers if F2+ unloaded.
Else, CS and DATA calls are load distributed if twin cells load is lower
than originating cell load.
Observation: RRC Segmentation is only allowed if target layers are

GREEN; Else, RRC Redirection is only decided based on DL Radio and
UL Radio load it is expected that this strategy may work for RRC
Redirections from U850 to U1900; otherwise, RRC Redirection from
U850 can be disable and iMCTA Service used instead.
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
F2+ layers become loaded:
All layers unloaded:
CS/Data
CS/Data
CS/Data
CS/Data
F1 layer become loaded:
CS/Data
All layers loaded:
CS traffic on F1 preferred.
DATA calls are load

distributed to F1
CS and DATA calls are load

distributed;
DATA calls are load

distributed to F2+
CS calls are load distributed

to F2+.
DATA calls are load

distributed to F2+
CS & DATA redirection upon

CAC failure
Conversational Flux
Data Flux
CAC Failure Redirection
Figure 3: Example of Dynamic Segmentation and Load Balancing application
Page 13/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
DATA Sequential Loading and CS offloading (with Cell Reselection strategies

that favour F1). Allow exploring the capabilities from Sequential Loading and
Offloading; Sequential Loading applies for DATA services and Offloading applying
to CS Services.
o
RRC Redirection only from F1 to upper layers (cell reselection favour

F1);
RRC Redirection for CS Services only to offload F1 or upon CAC

failure; in preference, CS Services will run in the layer intended to be
the layer providing continuity in the network;
DATA calls are load distributed to F2+ layers if F2+ unloaded;
If F2+ cells are loaded then DATA establishment in F1 if unloaded.
If all cells are loaded, DATA call establishment in F2+;
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
CS/Data
DATA layers become loaded:
All layers unloaded:
CS/Data
CS/Data
CS/Data
F1 layer become loaded:
CS/Data
All layers loaded:
CS offloading to F2.
DATA calls are load

distributed to F2+
DATA establishment in F1 if
unloaded
DATA calls are load

distributed to F2+ if
unloaded
CS redirection upon CAC

failure.
DATA call establishment in

F2+
Conversational Flux
Data Flux
CAC Failure Redirection
Figure 4: Example of DATA Sequential Loading and CS offloading application
4.4 UA08 STRATEGY DEPENDENCIES

To maximize inter carrier performance there is an associated complexity to configure
several features. The following list pretends to give an overview in the most important
Alcatel-Lucent functionalities that could apply for inter carrier mobility:
Cell reselection (used to favour a specific carrier or putting UEs camping

homogeneously on different frequencies);
Downlink/Uplink iRM (used for cell colour and to build different load profiles
across different carriers);
iRM Scheduling (can be used to downgrade PS384 and avoid compressed

mode);
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA Step1) (used for

traffic segmentation or load balancing at RRC redirection); iMCRA Step1 is
dissociated from iMCRA Step2, e.g. if Step1 enable, Step2 should be disable;
Page 14/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Load Balancing Between HSPA Carriers (improved RRC redirection for traffic
segmentation or load balancing with specific HSDPA downlink load criterion);
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA Step2) (with

several new capabilities for RRC Redirection, including RRC Redirection to
LTE); iMCRA Step2 is dissociated from iMCRA Step1, e.g. if Step2 enable,
Step1 should be disable;
Intelligent Multi-Carrier Traffic Allocation (iMCTA Alarm, CAC and Service)

(used to save calls in coverage and resource shortage and for traffic
segmentation or load balancing);
3G2G Redirection based on cell load (used to offload 3G);
3G to 2G Redirect for Speech Calls (used to save speech calls in case of 3G

resource shortage);
iMCTA Load based HO developments (used to better load balance traffic

between 3G and 2G carriers);
IF/IRAT Measurements Evolution (used to better load balance traffic between

3G and 2G carriers);
iMCTA Enhanced (with several enhancements on iMCTA algorithm, including

blind HO)
Fair sharing of resources: HSDPA vs. DCH (used for HSDPA load balancing
and CAC);
Broadcast of SIB4 & SIB12 (used to set different cell reselection strategy in
connected mode);
Always-On (used to force UEs going into Cell FACH, Cell PCH or URA PCH
mode);
Radio Bearer Rate Adaptation (used to optimize or adapt the handling of

DL/UL PS R99 resources);
Alarm HHO based on UE TX power (used to control UL Load);
RRC Reestablishment (used to avoid compressed mode and provide inter

carrier mobility for PS services);
Pre-emption (used to keep some resources available when the cell becomes
loaded);
CpichPower Settings (used to increase cell capacity and to force some UEs to
reselect to other cells/layers);
Dual Carrier (used to improve the HSDPA carrier load balancing, i.e. radio
resource usage efficiency);
Broadcast of SIB19 (cell reselection between 3G and 4G);
As an example, Operator may need to choose between having the standard iMCTA
functionality relying on GBR or MinBR values different from zero or the iMCRA solution
with HSDPA downlink load criterion with or without MinBR. Another interesting
Page 15/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

example is the decision to rescue PS calls from upper layers to continuous layers using
iMCTA Alarm HHO or functionality RRC Reestablishment. The optimisation of UL Radio
Bearer Rate Adaptation is also a key point on resources optimisation for HSPA calls
and UL load.
4.5 UA08 STRATEGY OPTIONS AND REQUIREMENTS

Several strategy assumptions for UA08 Deployment are considered to simplify the
configuration options for the different deployments scenarios recommended for UA08:
2G<->3G cell reselection strategies rely on 3G preferred. RRC Redirection to

GSM could take around 12s. Using RRC Redirection to GSM is not
recommended for initial deployment and solution for 3G to 2G mobility can
rely often on iMCTA CAC and Service.
4G<->3G cell reselection strategies rely on 4G preferred. In such condition,

most likely an LTE data call on 3G would be requested in areas of
bad/inexistent LTE coverage. This strategy increase the risk of failure on blind
redirection using RRC Redirection to LTE is not recommended for initial
deployment.
By the time of UA08.1 deployment, DL PS DCH traffic is considered negligible;

with such scenario, HSPA Group becomes similar to PS DATA Group; the use
cases will use DATA concept;
Since FDD redirection is only recommended for collocated cells and not
recommended to GSM and LTE, the use of load types with DL IUB Load for
carrier list selection will be avoided (exception may apply if collocated cells
belong to another Node-B).
Use of CEM load criteria depends on hardware site configuration; an xCEM

handles maximum 2 frequencies and up to 6 cells; Very high baseband
capacity solution for HSPA Dual Cell propose 1 xCEM per sector handling the 2
DC cells; Since FDD redirection is only recommended for collocated cells, the
CEM Load criteria for carrier list selection will be avoid (CEM Load criteria will
be used for FDD target selection for DCH and HSxPA).
The most important load criteria for carrier list selection for HSDPA calls is
HSDPA Load;
The most important load criteria for carrier list selection for HSxPA calls is the
HSDPA Load and the UL RX POWER Load (HSUPA load does not impact UL RX
POWER Load calculation; but HSUPA calls should run in preference in cells
with lower UL RX POWER Load).
To minimize the impact of high DL/UL radio load on CS calls QoS, load types
with DL RADIO Load = max (DL POWER and DL OVSF loads) and UL RX
POWER Load should be used in preference for this service;
For pure Load Balancing cases cell reselection used DL measurements for
EcNo meaning that probability to establish the call in the less DL loaded cell is
Page 16/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

high; load types with UL RX POWER Load should be used in preference as
complement for redirection;
DATA Traffic is significantly higher than CS traffic; multi layer deployment can
rely in single CS preferred layer plus x DATA preferred layers.
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.
81213 HSPA load criteria is recommended to be activated in order to manage

load balancing of HSPA I/B traffic with either zero or low GBR or MinBR
values.
For traffic distribution strategies based on the aggregate DCH and/or HSPA Cell Load
Colour it is important to ensure a consistent configuration for iRM/HSPA colour
transition thresholds. iMCRA Step2 introduces the use of load colour black for DCH.
The following load types are used on the aggregate DCH Cell Load Colour calculation:
DL DCH Load = maximum (TX Power; OVSF Code; DL CEM; IuB)
UL DCH Load = maximum (Rx Power; UL CEM)
Aggregate Cell Load = maximum (DL DCH Load; UL DCH Load)
The HSPA load is calculated by:
DL HSPA Load = maximum (HSPA DL Power Colour, HSPA DL Codes Colour).
In UA08.1, iMCRA Step2 supports single and combined load types. iMCRA and iMCTA
relies on the DCH Aggregate Cell Load or on the DL HSPA Load.
Decision to activate the different DCH load calculations is done by a list of iRM
parameters (please refer to UPUG Volume 6 for complete details including
recommended values for different DCH load transitions):
isCEMModelValidForDlColour; isCEMModelValidForUlColour;
isUlRadioLoadColourEnabled; isCEMColourCalculationEnabled;
isDlIubTransportLoadColourCalculationEnabled; isIrmOnCellColourAllowed;
isIrmOnRlConditionAllowed; isUlIrmOnCellColourAllowed;
isUplinkRadioLoadEnabled.
For details on DL HSPA Load Criteria please refer to UPUG Volume 13. The use of this
load criterion implies the activation of UA7.1.2 feature Load Balancing between HSPA
Carriers.
4.6 UA08 CELL TOPOLOGIES

The cell concept (CS/DATA layer and DATA layer) used in this presentation considers
HSxPA is activated in all layers. Two cell topologies are considered for the deployment
scenarios:
Page 17/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Frequency with Data traffic:

o
Represented in this document by:
PS R99 and HSxPA traffic are cohabiting on the same frequency
Up to 14 or 15 HS-PDSCH codes usable for HSDPA thanks to Fair

Sharing (dynamic codes management part)
Data
Frequency with CS/Data traffic:

CS/Data
Represented in this document by:
R99 and HSxPA traffic are cohabiting on the same frequency
Up to 14 or 15 HS-PDSCH codes usable for HSDPA thanks to Fair

Sharing (dynamic codes management part)
4.7 CELL RESELECTION FOR UA08 DEPLOYMENTS

Cell Reselection deployments depend on configuration chosen for iMCRA Load
management:
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.
Configuration based on Dynamic Segmentation and Load Balancing fits with

UEs camping homogenously across different carriers.
Configuration based on DATA Sequential Loading and CS offloading fits with

Cell Reselection strategies that favour F1.
Example of a Cell Reselection strategy that favour F1 CS/DATA layer, avoiding

redirection for CS Services:
qQualMin = qQualMin_idleMode = -18 dB;
qRxLevMin = qRxLevMin_idleMode = -115 dBm;
sInterSearch = 0 on F1 & sInterSearch = 16 on F2;
sSearchRatGsm = 2 on F1 & F2;
Always selecting and camp on F1 by setting qOffset2sn = 50 under

UmtsNeighbouring F1 -> F2;
Page 18/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
If mobile camp on F2 by any reason, it will be forced to reselect F1 by

qOffset2sn = -50 under UmtsNeighbouring F2 -> F1;
Qhyst = 2 providing hysteresis on serving cell;
Always selecting and camp on UMTS by setting qOffset2sn = 50 under

UmtsNeighbouring FDD -> GSM;
2G->3G reselection is only triggered by EcNo measured on 3G cells by setting

FDDQmin = -10 (no restriction based on RSCP); Qsearch_I = Always;
Example of a Cell Reselection strategy with UEs camping homogenously across

different carriers:
qQualMin = qQualMin_idleMode = -18 dB;
qRxLevMin = qRxLevMin_idleMode = -115 dBm;
sInterSearch = 8 on all layers; however, sInterSearch 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;
sSearchRatGsm = 2 on all layers;
Qhyst = 2 providing hysteresis on serving cell;
Do not induce hysteresis while on F1, F2 or F3 by setting qOffset2sn = 0

under UmtsNeighbouring F1 <-> F2 <-> F3; however, 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;
Always selecting and camp on UMTS by setting qOffset2sn = 50 under

UmtsNeighbouring FDD -> GSM;
2G->3G reselection is only triggered by EcNo measured on 3G cells by setting

FDDQmin = -10 (no restriction based on RSCP); Qsearch_I = Always;
Example of a Cell Reselection strategy based on Hierarchical Cell Structure (HCS) with
UEs camping homogenously across different carriers but with F1 offloads to upper
layers:
F2+ Layers with HCS disable and normal settings as detailed on previous cell
reselection strategy examples.
F1 layer with HCS activated and high-mobility NOT detected:
qQualMin= qQualMin_idleMode= -18 dB;
qRxLevMin= qRxLevMin_idleMode= -115 dBm;
sInterSearch= 8 on all layers;
sIntraSearch= 10 on all layers;
sSearchRatGsm= 2 on all layers;
Page 19/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Qhyst2= 2 providing hysteresis on serving cell;
hcsPrio= 1 on F1 layer;
qHcs= 48 decimal = 0 dB
sSearchHcs= 32 dB;
UmtsNeighbouringRelation/ F1 -> F2+ with qOffset2sn= 0 and

UmtsNeighbouringHcsCellParam/ with hcsPrio= 2 and qHcs= 38 = -5 dB;
4.8 IMCRA FOR UA08 DEPLOYMENTS

The following sections will provide the iMCRA Step2 philosophy configuration
proposed for deployment in UA08 including bi-frequency, tri-frequency and fourfrequency topologies. It will not detail parameters configuration to put in place such
philosophies for details on iMCRA Step2 configuration please refer to UPUG UA08
[R01]. For details on configuration options please refer to previous sections.
As stated on section 4.3, two different strategies are recommended for deployment in
UA08: Dynamic Segmentation and Load Balancing and DATA Sequential Loading and
CS offloading. Reference to Dynamic Segmentation and Load Balancing strategy
considers applicability for both CS and PS services. However, a solution using Dynamic
Segmentation for CS only and Load Balancing for both CS and PS can be also
idealized.
4.8.1 BI-FREQUENCY DEPLOYMENTS

Bi-frequency deployments would become the rule in areas where coverage purposes
are still more relevant than load/capacity purposes. In such areas of low/medium
traffic, using strategies to keep CS and PS traffic as much as possible dissociated may
help protecting voice services against noise generated by PS calls and to maximize
HSPA throughput. The following recommendation relies on these considerations.
Page 20/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

iMCRA Strategy
DATA Sequential Loading
DATA layer preferred & DC anchoring
iMCRA Service Traffic Handling:
CS/DATA layer preferred for CS & DATA fallback
1.
CS traffic on F1;
2.
DATA calls are redirected to F2 if Load < RED.
3.
Else, if F2 cell is RED or BLACK then DATA establishment in F1 if load is < RED.
4.
Else (all cells are loaded) DATA call establishment in F2.
5.
F2 anchoring with F1 for Dual Cell capable;
iMCRA CAC Traffic Handling

1.
Offloading to other layers (the carrier with the CAC failure will be filtered out)
Dynamic Segmentation and Load Balancing:

iMCRA Service CS and DATA Traffic Handling:
CS/DATA layer preferred for DATA & DC anchoring

CS/DATA layer preferred for CS
1.
F1 preferred for CS if Load is GREEN;
2.
F2 preferred for DATA if load is GREEN;
3.
Else, CS and DATA calls are load distributed if twin cells load is lower than originating cell load;
4.
iMCRA CAC CS and DATA Traffic Handling

1.
Table 3: Bi carrier deployments strategies using iMCRA Step2
4.8.2 TRI-FREQUENCY DEPLOYMENTS

Tri-frequency deployments would become the rule in areas where load/capacity
purposes are more relevant than coverage purposes. In such areas of relevant traffic,
pure Load Balancing strategies are often more suitable. However, Sequential Load
strategies can still be used if CS calls are considered the key service. The following
recommendation tries anyway to potentiate the Load Balancing approach but still
protecting as much as possible CS services.
Page 21/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

iMCRA Strategy
DATA Sequential Loading and CS offloading
iMCRA Service CS Traffic Handling:
1.
2.
DATA layer preferred for HSxPA

DATA layer preferred for HSDPA & DC & Offloading CS
CS traffic on F1 preferred;
CS/DATA layer preferred for CS & DATA fallback
At high UL Power or DL radio loads on F1, originating

CS is gradually redirected to F2 (80% at RED, 90% at BLACK);
iMCRA Service DATA traffic handling

1.
F2 preferred for HSDPA if Load is GREEN;
2.
F3 preferred for HSxPA if Load is GREEN;
3.
Else, HSPA calls are load distributed to F2+ if load < RED;
4.
Else, if F2+ cells load is RED or BLACK then HSPA establishment in F1 if load is < RED.
5.
Else (all cells are loaded) HSPA call establishment in FDD2+.
6.
iMCRA CAC CS & DATA Traffic Handling:

1.
Offloading to other layers (the carrier with the CAC failure will be filtered out);

CS/DATA layer preferred for HSxPA

CS/DATA layer preferred for HSDPA & DC
1.
2.
F2 preferred for HSDPA if Load is GREEN; else, F3 preferred for HSDPA if load is GREEN;
3.
F3 preferred for HSxPA if Load is GREEN; else, F2 preferred for HSxPA if load is GREEN;
4.
Else, CS and DATA calls are load distributed if twin cells load is lower than originating cell load;
5.

1.
Table 4: Tri carrier deployments strategies using iMCRA Step2
4.8.3 FOUR-FREQUENCY DEPLOYMENTS

Four-frequency deployments would become mandatory in hot spot traffic areas
areas where load/capacity purposes are much more relevant than coverage purposes.
However, the DATA Sequential Loading and CS offloading based strategy become
difficult to fine tune for an increasing number of carriers deployed in the network
(more than 3) due to indeterminist UE behaviour in cell reselection and due to new
connections with higher path loss catch by upper layers with cleaner spectrum. The
following recommendation assumes that in such areas of high traffic, pure Load
Balancing strategy is the only strategy suitable to cope with traffic demand.
Page 22/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

iMCRA Strategy
1.
2.
F2 preferred for HSDPA if Load is GREEN; else, F3 then F4

preferred for HSDPA if load is GREEN;
CS/DATA layer preferred for HSxPA

CS/DATA layer preferred for HSDPA
CS/DATA layer for HSDPA & HSxPA & DC
3.
F3 preferred for HSxPA if Load is GREEN; else, F4 then F2 preferred for HSxPA if load is GREEN;
4.
Else, CS and DATA calls are load distributed if twin cells load is lower than originating cell load.
5.

1.
Table 5: Four carrier deployments strategies using iMCRA Step2
4.9 IMCTA FOR UA08 DEPLOYMENTS

iMCTA Alarm Strategy will be common whatever the UA08.1 deployment scenarios
proposed in iMCRA section :
Field experience shows the benefit of using a single layer (F1 continuous layer
or GSM layer) to rescue calls from upper layers. Furthermore, iMCTA Alarm
should be unidirectional, e.g. from F2 -> F1 and never bidirectional F2 <->
F1. This configuration can be achieved by a proper setting for iMCTA Alarm
table. In a multi-layer configuration this solution will avoid the ping-pong
effect and should contribute to decrease the volume of HHO with also
expected gain for call drop. Main philosophy:
o
F1 with Inter-RAT only if applicable; otherwise no iMCTA Alarm from

F1.
Upper FDD layers with preferred Inter-Frequency mobility if F1

continuous layer have good radio conditions to receive the incoming
call otherwise Inter-RAT mobility (this solution may be achieved using
simultaneous compressed mode capabilities).
iMCTA Alarm HHO only for CS Services since Inter carrier mobility for
PS services may be achieved using feature RRC Reestablishment and
DATA throughput is strongly penalized on GSM layer.
For multiservice CS+PS, calls are kept in 3G since not well handled on
2G. iMCTA Alarm HHO will be avoided for CS+PS Services.
iMCTA Service Strategy will be common whatever the UA08.1 deployment scenarios
proposed in the following sections :
Page 23/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Since all layers carry CS and DATA traffic, iMCTA Service may be used as
backup after iMCRA Redirection based on initial load assessment. It is thus
proposed to configure iMCTA Service for pure load balancing purposes. iMCTA
Service is triggered:
o
After any RAB establishment/release;
Mobility service reason;
iMCTA Service is triggered only when iMCTA cell load is above

configurable cell load (originatingCellColourThreshold under
originatingCellColorThresholdPerService)
RED for CS Services: iMCTA Service is triggered for CS traffic

when iMCTA cell load is RED or BLACK, allowing load to raise up
to RED before starting load distribution for CS services;
RED for PS Services: iMCTA Service is triggered for PS traffic

when iMCTA cell load is RED or BLACK; allowing load to raise up
to RED before starting load distribution for PS services
iMCTA CAC Strategy will be common whatever the UA08.1 deployment scenarios
proposed in the following sections :
For PS Services an FDD layer should be used to rescue the CAC Failure.
For CS Services, an inter Rat handover is preferred over an inter frequency

handover only when FDD neighbour target cells are RED
UA08.1 Feature iMCTA Enhanced brings several new capabilities for iMCTA. Please
refer to UPUG for details on parameters recommendations.
4.10 SPECIFIC HANDLING OF NETWORKS WITH MORE THAN

3 CARRIERS
Some operators want to use up to 6 carriers in a network using two different NodeBs
for capacity enhancement. Recommended strategies for five our six Carrier
deployments are based on four Frequency deployments by adding additional F5
or/and F6 carrier with equivalent topology/strategy as used for F2 &/or F3 &/or F4
layers. For further details please refer to previous sections.
However, 3GPP 25.133 restricts the maximum number of carriers to be supported
simultaneously by the UE to the current carrier plus up to 2 additional FDD carriers. In
multi carrier configurations with 4 or more layers, for a deterministic behaviour it is
recommended to restrict the number of additional FDD carriers to be measured by a
UE to 2.
To avoid impacting the neighbouring relations management (all inter-frequency
neighbours can be defined), the operator should define the inter-frequency neighbour
Page 24/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

list broadcast in SIB11 such that only up to two carriers are contained for cell
reselection. This can be controlled with existing parameters:
sib11AndDchNeighbouringFddCellAlgo: Set to "manual"
sib11OrDchUsage:
o
For cells of carriers to be included in SIB11: Set to "sib11AndDCH"
For cells of carriers not to be included in SIB11: Set to "dchUsage"
The neighbours can be distributed in round robin fashion. Example for 6 carriers:
source carrier
neighbour carriers
f1
f2, f3
f2
f3, f4
f3
f4, f5
f4
f5, f6
f5
f6, f1
f6
f1, f2
Table 6: Round-robin
The following picture provides a field example of SIB11 strategy used to manage the
idle mode behaviour on a 5 frequency topology:
FDD6 (2100)
FDD5 (2100)
Idle Mode/FACH Traffic entering 2100
Traffic entering through
continuous network FDD4 2100 layer
will first try to reselect other 2100 layers
Idle Mode/FACH Traffic entering 850
Traffic entering through
continuous network FDD1 850 layer
will first try to reselect other 850 layer
or cleaner FDD5 2100 layer
FDD4 (2100)
FDD2 (850)
FDD1 (850)
sib11AndDch
(others to DchUsage)
sib11AndDch
(others to DchUsage)
Figure 5: Field example of SIB11 strategy to manage idle mode
In connected mode, a more advanced approach is to dynamically determine the

neighbour carriers for an UE depending on target carrier load. If Measurement based
HO is decided and there are still more than two candidate FDD carriers eligible to be
target layer, RNC only choose 2 carriers for UE measurement; the following parameter
is used:
Page 25/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
carrierPreSelectAlgorithm = carrierLoad or twinCellLoad (please

note that other configurations are possible based on neighbourPriority
and maxCells; the solution based on carrierLoad or twinCellLoad is
based on UPUG recommendation).
4.11 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 F1 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 Inter frequency / Inter RAT Measurements Evolutions 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.
U2100 F1
U2100 F0
U900
U900
GSM
U2100 F0
GSM
GSM
U2100 F0
U900
GSM
GSM
GSM
Figure 6: Example for mixed frequency deployment scenarios
Previous recommendations consider that cell sizes are equivalent. In case deploying
U1900 or U2100 layers on top of U850/U900 coverage layers, and thanks to a better
radio propagation at 900/850 MHz, DL RSCP coverage is improved for 900/850 MHz
layer. This deployment characteristic can be quite appropriate for rural areas to
maximise DL coverage. However, the enhancement on DL coverage may bring extra
interference for the UL spectrum. Some field results do really notice very high UL
noise on 900/850 MHz layers. Several UEs at cell edge may transmit at maximum Tx
Power to overcome the superior path loss created by DL coverage extension. In
consequence, the associated UL interference may increase and other UEs closer to the
Page 26/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

site may be also forced to transmit at higher Tx power. This realistic situation requires
often specific settings for RF, Cell Selection/Reselection, RRC Redirection and iMCTA
to balance the traffic between layers. The following adaptations may be considered
when deploying 900/850 MHz layers mainly in areas with high density of sites (urban
areas):
Confine 900/850 MHz coverage through design optimization of the existing
outdoor radio base stations (Down tilts & azimuth) in order to reduce pilot
pollution. PcpichPower reduction may be also considered.
Cell Selection/Reselection: qOffset2sn may 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; i.e. if the
900/850 MHz band is interfered in UL, U1900/U2100 MHz band may be
favoured for cell reselection in large deployment or hot spot topologies.
RRC Redirection: RRC Redirection to Twin Cells from U1900/U2100 to
U850/U900 and from U850/U900 to U1900/U2100 should be carefully
monitored since DL RSCP and DL EcNo coverage may be considerably
dissimilar across layers. For such deployments the RRC redirection could be
more critical for strategies based on Service Segmentation (including
Sequential Loading) and relying heavily on blind RRC Redirection. For that
reason, it is not recommended to use Service Segmentation based strategies
in case deploying U1900 or U2100 layers on top of U850/U900 coverage
layers. Such deployments may use a strategy based on Load Balancing. For
this strategy the RRC redirection has lower implication since decisions are
based on DL Radio and UL Radio load. However, it is only recommended to
use RRC Redirection from U850/U900 to U1900/U2100 if specific setting for
qRxLevMin is used on U850/U900 layers (e.g. -105; this will avoid RRC
Redirections on cell edge).
iMCTA Service measurement based HO may become an alternative
mechanism to balance traffic across U850/U900 and U1900/U2100 layers
based on load conditions and on UE measurements.
Another important aspect to consider when deploying U850/U900 layers for capacity
purposes is the UE capability. Market penetration for capable UEs on U850/U900
bands should be carefully analysed since it may have significant impact on the traffic
carried by U850/U900 layers. In European networks UEs penetration on those bands
is still not relevant.
Page 27/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
4.12 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 neighbouring 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;
FDD1
FDD3
FDD3
FDD2
FDD2
FDD2
FDD2
FDD1
FDD1
FDD1
FDD1
GSM
Figure 7: Typical scenarios for neighbour declaration
Please note that iMCTA Alarm mobility should be always triggered towards a
continuous layer; i.e. if F3 is not a continuous layer configuration should avoid iMCTA
Alarm mobility from F2 towards F3; this can be achieved by appropriate configuration
for Alarm Priority Tables.
Neighbouring declaration from non continuous upper layers need to be carefully
idealized. Restricting neighbouring declarations from non continuous upper layers only
to twin collocated FDD layers may lead to situations were the respective collocated
twin layers are below qQualMin and UE remains attached to serving cleaner layer. If
neighbouring strategy for cleaner upper layers is not accurate, UE may not find
suitable cells to reselect when making the transition from connected mode to idle
mode, increasing the risk of establishing connections with high path loss. Also, some
operators have tendency to inhibit the cell reselection in connected mode (FACH or
URA_PCH), increasing even more the risk of forcing some UEs to stay attached to the
non continuous layers.
Deploying lower DL frequencies on non continuous upper layers may also increase the
risk of accessibility issues. UE entering 3G coverage will start scanning FDD
frequencies by the increasing DL Frequency band, e.g. FDD07 first, then FD10, then
Page 28/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

FDD11, then FDD12. As an example, if FDD07 is deployed on a non continuous layer,
this layer will start catching important traffic coming from the GSM (through IRAT
Reselection). And if FDD07 neighbouring relations strategy is not optimal, UE may
remain attached to FDD07 cleaner layer increasing the risk of establishing connections
with high path loss. In such cases it is recommended either not to declare those
frequencies on the other IRAT networks or extending the neighbouring relations and
limit cell selection/reselection thresholds (qQualMin/qRxLevMin) on such non
continuous upper layers.
4.13 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.
F1 layer is intended to be the layer providing continuity in the network. For that
reason lowering the initial Cpich Power on F1 could have impact on current cell
footprints requiring RF re-design and/or densification. However, coverage can be
ruled by EcNo rather than by RCSP and Cpich Power reduction on F1 can be
considered to increase network capacity in case the area is well covered (good site
density). But Cpich Power reduction on F1 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 F1 layer & (CPICH-2dB) on upper

layers F2+
o
This configuration may be suitable for asymmetric topologies relying

on F1 R99 & F2+ HSxPA configurations; this way HSDPA throughput
is maximized and service voice continuity guaranteed;
Performance for RRC Redirection from F1 to F2+ cells should be

carefully monitored;
Choice 2: (CPICH-2dB) on F1 cells & (CPICH-2dB) on F2+ cells

o
This configuration may be suitable for symmetric topologies relying on

F1 & F2+ R99/HSxPA configurations; however, this may impact on
current F1 cell footprints requiring RF re-design and/or densification;
F1 potential mobility issues at cluster border due to unbalanced

CPICH with adjacent F1 cells (however a gap up to 2dB should work
and impact on mobility call drop considered negligible);
If EcNo coverage is guaranteed there should be no risk of HSDPA

throughput degradation;
Some RSCP related thresholds may be retuned;
Page 29/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
4.14 TYPICAL STRATEGY FOR IRAT MOBILITY

This section provides high level recommendations for IRAT mobility (GSM and/or
LTE). IRAT mobility strategy for Cell Reselection, RRC Redirection and Hard Handover
is determined by UE Capabilities, Network Deployment and available Functionalities.
In Cell Reselection, IRAT mobility strategy is often determined by UEs capabilities
rather than by load strategy since objective is providing to the end user the maximum
quality of service possible (e.g. data applications can make use of higher
throughputs). This assumption leads to the following concept:
UE having both GSM and 3G capability is intended to camp in preference on

the 3G network, leading to cell reselection parameters strategy forcing UMTS
UE capable to camp on 3G as soon as possible.
UE having both 3G and LTE capability is intended to camp in preference on

the LTE network, leading to cell reselection parameters strategy forcing LTE
UE capable to camp on 4G as soon as possible.
RRC Redirection strategy should take into consideration the strategy idealized for cell
reselection in idle mode. Assuming that 2G<->3G cell reselection strategies rely on 3G
preferred and that RRC Redirection to GSM could take around 12s, using RRC
Redirection to GSM is not recommended for deployment and solution for 3G to 2G
mobility can rely rather on iMCTA hard handover.
Assuming that 4G<->3G cell reselection strategies rely on 4G preferred, most likely an
LTE data call on 3G would be requested in areas of bad/inexistent LTE coverage. This
strategy increase the risk of failure on blind redirection using RRC Redirection to LTE
is not recommended for initial deployment.
Concerning Hard Handover (or redirection during call for LTE), and assuming 3G
and/or GSM are widely deployed across mobile networks, and LTE is still in an initial
deployment phase, the following policies can be used:
2G may be considered to rescue CS calls dealing with 3G coverage or

resource shortage.
o
Obs: PS and CS+PS calls should not be rescued from 3G to 2G since

3G is widely deployed and HSxPA throughput is strongly penalized on
GSM layer.
3G may be used to fallback CS calls or to rescue calls dealing with 4G

coverage shortage since 4G is not widely deployed.
From a UTRAN perspective, the following features deal with IRAT LTE mobility (for
parameter settings details please refer to UPUG):
Mobility between UMTS and LTE Cell Reselection
LTE to UMTS HHO
Mobility between UMTS and LTE HO and Cell Reselection Enhancement
CS Fallback Enhancement LTE to UMTS
Page 30/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
iMCRA Step 2 (3G to LTE RRC Redirection)
iMCTA Enhanced (3G to LTE Redirection after AO Downsize)
From a UTRAN perspective, the following features deal with IRAT GSM mobility (for
parameter settings details please refer to UPUG):
3G to 2G Cell Reselection
3G/2G RRC Redirection based on Cell Load
3G to 2G Redirect for Speech Calls
iMCRA Step 2
iMCTA
IRAT/IFREQ Measurements Evolution
3G to 2G Handover
2G to 3G Handover for CS Domain
The following image provides an overall overview on IRAT mobility strategy:
4G
4G UE capable to
camp on 4G as
soon as possible
Fallback CS calls and

rescue PS calls in
coverage shortage
3G
3G UE capable to
camp on 3G as
soon as possible
2G
Rescue CS calls in
coverage or
resource shortage
Figure 8: Typical IRAT mobility scenarios
4.15 TYPICAL STRATEGY FOR SMALL CELLS MOBILITY

Small Cells (Metro/Femto) based solution intends to improve indoor coverage and
capacity for residential and enterprise usage or providing supplementary outdoor
capacity on hot spots (e.g. crowded commercial areas). Small cells footprint is
naturally small and is seen somehow like a concentric cell below a continuous Macro
layer.
Small cells may be deployed on shared carrier (sharing an FDD frequency) or in a
dedicated carrier (using dedicated FDD frequency). Deployments on shared carrier
Page 31/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary

require specific attention to the DL mutual interference zone (3G degradation may
happen) and to the UL interference zone for Small cell user.
3G to Small Cells mobility rely on cell reselection functionality. Strategy is often forcing
UEs to camp on Small Cells as soon as possible. Typical Cell Reselection parameters
can be tuned to achieve the desired strategy but HCS may be considered. However, it
is not recommended to use HCS with HMD (High Mobility Detection) detection in order
to move the low mobility UEs to the small cell carrier. Reason is that implementation
and fine tuning could become a tedious operation. Also, the algorithm concept is
based on UEs making important number of cell reselection during a time period (to
the HMD algorithm, speed does not really exist). This may happen to static UEs
covered in the interference zone.
4.16 ONEBTS 6 CARRIER 2NB CONFIGURATION (120426)

4.16.1
FEATURE DESCRIPTION
This feature allows the usage of two NodeBs co-located in the same physical space to provide
support for more carriers than the current four carrier limitation (in a single oneBTS).
The additional NodeB, either Macro 9341 or DBS 9396 (d2U) and RRH is installed at the same
cell site and separately managed; with hardware configured for up to a three sector cell site.
It is configured to support six carriers across contiguous or discontinuous spectrum in PCS or
Cellular. Separate antennas, TMAs and feeder systems or external duplexer connectivity to
Antenna systems can be used. The cell parameters and cell optimisation are individually
configured using the cell planning tools.
A configuration example is for one NodeB to support 1, 2, 3 or 4 carriers while the second
NodeB is supplemented with carriers 5 or 6.
4.16.2
FEATURE IMPACTS
This feature has no impact on OAM, Alarms or on PM data. The two NodeBs are created and
managed as two entirely separate hardware elements.
Page 32/33

UMT/IRC/APP/016664
05.04 / EN EXTERNAL
16/Mar/2012
UA08.1 preliminary
Z END OF DOCUMENT Y
Page 33/33
UMT/IRC/APP/016664
Z END OF DOCUMENT Y
V05.04
16/MAR/2012

HPUG UA08 V05.04 Preliminary Ext

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HPUG UA08 V05.04 Preliminary Ext

Transféré par

Droits d'auteur :

Formats disponibles

HSxPA Parameters User Guide

HSxPA Parameters User Guide

SCOPE OF THIS DOCUMENT .............................................................................................. 13

AUDIENCE FOR THIS DOCUMENT ........................................................................................ 13

RELATED DOCUMENTS .................................................................................................... 16

HSxPA Parameters User Guide

HSxPA Parameters User Guide

edchOlpcInactivitySirDecreaseLimit : it must be bounded with minimum

HSxPA Parameters User Guide

New section introduced named TYPICAL STRATEGY FOR IRAT MOBILITY

HSxPA Parameters User Guide

eagchPower, ehichPowerSignature and ergchPowerSignature.

HSxPA Parameters User Guide

HSxPA Parameters User Guide

HSxPA Parameters User Guide

Replacement of some reserved parameters (temporary) with new

HSxPA Parameters User Guide

HSxPA Parameters User Guide

HSxPA Parameters User Guide

HSxPA Parameters User Guide

HSxPA Parameters User Guide

1.2 SCOPE OF THIS DOCUMENT

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

Restriction: Pico/Micro NodeB

1.3 AUDIENCE FOR THIS DOCUMENT

UTRAN Data fill

Trials and FOA

HSxPA Parameters User Guide

The parameter names are written in bold italic.

The objects names are written in bold.

The parameters properties are presented as follow:

The protocol messages are written in CAPITAL LETTERS.

The data fill rules are presented as the following:

The system restrictions are presented as the following:

The engineering recommendations on parameter value are presented as the

N.A.: Not Applicable.

N.S.: Not Significant.

HSxPA Parameters User Guide

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

HSxPA Parameters User Guide

1.5 RELATED DOCUMENTS

Access Network Parameters

UTRAN Parameters User Guide

Iub transport Engineering Guide

CEM Capacity Engineering guide

Product Engineering Information

UA08.1 Feature Planning Guide

Micro NodeB & 9314 Pico NodeB Feature

HSxPA Parameters User Guide

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

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

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.

HSxPA Parameters User Guide

Manufacturer: They represent system constants defined by the manufacturer.

Regardless of the parameter type (customer or manufacturer), the parameters can

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

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

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