Documente Academic
Documente Profesional
Documente Cultură
External Document
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
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-
0H
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-Lucent’s 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 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
CONTENTS
1
1H INTRODUCTION
2
2H HSXPA OVERVIEW
3
3H HSDPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
4
4H HSUPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT
5
5H CALL MANAGEMENT
6
6H MOBILITY
7
7H DEPLOYMENT SCENARIOS
Alcatel-Lucent – Proprietary
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
1 INTRODUCTION
Alcatel-Lucent – Proprietary
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
CONTENTS
1 INTRODUCTION..........................................................................................................................11
1.1 OBJECT ..................................................................................................................................11
1.2 SCOPE OF THIS DOCUMENT .....................................................................................................12
1.3 AUDIENCE FOR THIS DOCUMENT ..............................................................................................12
1.4 NOMENCLATURE .....................................................................................................................13
1.5 RELATED DOCUMENTS ............................................................................................................15
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
PUBLICATION HISTORY
10/09/2010
Issue 04.06 / EN,
Updates:
•In Volume 2:
•Introduced UE categories related to 81204
•In Volume 3:
•Introduced feature 81204 HSDPA Dual cell operation and its impact on RNC
and NodeB along with activation flags. Update accordingly the recommended
values for DlRlcQueueSizeForUeCat, rlcRetransmissionBufferInKbytes,
macehsMaximumPduSizePsIb.
•Introduced feature 113511 HSDPA Aggregate Throughput up to 40Mbps per
board
•Correct the pre-requesite for HSDPA+ optimal throughput: changed ‘UL
MAC-e BLER around 0’ to ‘UL RLC BLER around 0’.
•Miscellaneous cleanup and re-wordings.
•In Volume 4:
•Added behavior related to HSDPA-DC call when RNC or NodeB CAC fails
•Added RNC EDCH CAC description (34441.1)
•In Volume 6:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•New section 4.3 STRATEGY DEPENDENCIES;
•Update on sections 4.4 BI CARRIER DEPLOYMENT SCENARIOS & 4.5 TRI
CARRIER DEPLOYMENT SCENARIOS in order to reflect 81213 Load
Balancing between HSPA Carriers feature capabilities and 81204 Dual Cell
HSDPA Operation capabilities;
05/06/2010
Issue 04.05 / EN,
Updates:
•In Volume 3:
•Clarification concerning activation of feature 75998 (detailing on feature
support per type of controller board and iso-functional behaviour with
hsdpaWindowsObserveTime set to 100ms)
•Inclusion of section 9.6 dedicated to description of feature 97431 – HSDPA
OLS Differentiation at Node B Level
•Clarification of numberOfHsPdschCodes when Fair sharing or DCTM is
activated and use of activityFactorCcch in OCNS and HSDPA power
calculations
•Clarified HS-DSCH required power report’s unit of measurement and its flow
•In Volume 4:
•Note introduced concerning the settings for the parameter
maxEdchCommonChannelPower
•In Volume 5:
•Restriction note introduced concerning the utilisation of the feature GBR with
the feature HSDPA OLS Differentiation at NodeB Level
•Clarification regarding the Mac-hs GBR formula when the HSDPA call
operates in flexible RLC mode.
•In Volume 6:
•Update on communication for feature 34475; feature 34475 is a globalization
of 33480
•Remove Section 8 EXAMPLE OF INTER-FREQUENCY AND INTER-
SYSTEM SCENARIO from HPUG
Page 3/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•Update on iMCTA strategy for different topologies; Speech calls always
rescue to GSM
•Update on HSxPA requirements for Load Balancing configurations, including
Fair Sharing reservation on codes recommendation
26/03/2010
Issue 04.04 / EN,
Updates:
•In Volume 1:
•History update
•In Volume 3:
•Clarification concerning the DCTM activation
•Update of the "Pre-requisites to reach the maximum throughput with 64QAM"
•Removal of the UA6 restriction concerning the setting of
maxHspaPowerOffset (from UA7, other value than 0dB can be used)
•Clarification of section “Transport Block Size Optimization” concerning the
iCem and xCem applicability
•Clarification concerning the selection of the UL SIR Target parameters
min/max/initialSirTargetEdch2ms or min/max/initialSirTargetHsdpa or
min/max/initialSirTarget
•Update of the server configuration (socket buffer size) for ‘maximum HSDPA
throughput’.
•Modification of the range and format of rlcRetransmissionBufferInBytes
•Clarification of the recommendation for prohibitedStatusTimer in the object
DlRlcAckFlexibleMode (10s)
•In Volume 4:
•Modification of the recommended value for gRakeActivation
•Description of the enablePeriodicSirTargetUpdate for the UL SIR target
update mechanism
•Add the recommended value for happyBitDelay on UCU-III.
•Clarification for the nHarqRetransTargetSx and
maxNumActiveEdchUsersPerCellForSx: dependant on several factors.
•Editorial modification: the recommended values for UL SIR Targets are
removed in order to avoid duplication in both HPUG and UPUG.
•In Volume 5:
•Remove section 3 MULTI-CARRIER MANAGEMENT; the content of this
section is transferred to UPUG
•In Volume 6:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•Update concerning the suspend time offset: suspendTimeOffset parameter
is replaced with iubSuspendTimeOffset and iurSuspendTimeOffset
•Update of the feature 34475 Compressed Mode in MAC-e: globalization for
US Market of the feature 33480.
•New section added 5 INTER-CARRIER MANAGEMENT FOR HSXPA
•In Volume 7:
•UCU-III capabilities added
•Following sentence deleted “Note that HSUPA mobiles working at 900MHz
are not available” because there are in UA7 900MHz UE doing HSUPA
•New sections added to the document:
•FOUR CARRIER DEPLOYMENT SCENARIOS
•UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ
•TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION
•CPICH DESIGN CHOICES
•Remove section STSR2 VERSUS STSR 1+1
13/11/2009
Issue 04.03 / EN,
Updates:
•In Volume 1:
•History update
•Clarification of the nomenclature concerning the green frame (green frame
can be used to explain differences between 2 consecutive or non consecutive
releases)
•In Volume 2:
•New recommended value for cqiPowerOffset
•In Volume 3:
•New recommended value for serviceBFactor and serviceMaxRate
•Update of the recommendation concerning the “Pre-requisites to reach the
maximum throughput with 64QAM”
•Clarification of the HS-DSCH allocated power (factor) in case of 64QAM
•Correct the parameter name of HSDPA_packet_error_rate_target (not
HSDPA_packet_error_rate_target)
•Clarification concerning the UCUIII parameters (they are tunable parameters)
•Clarification concerning the Engineering Recommendation: Maximum
HSDPA throughput
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•Additional information provided on implemented solution for feature PM75998
– Radio Measurement Frequency Increase: Tx Power
•Feature 34388 Layer 2 Enhancements. Correction regarding the
recommended value of DlRlcQueueSizeForUeCat, clarification regarding the
rule for maxIubHsDschFrameSize
•In Volume 4:
• Introduction of the parameter locFrequencyReuseFactor
•Better explanation was introduced concerning the parameters:
edchBLSupervisionTimer, edchBLStepReductionFrameLoss,
edchBLStepIncrease and edchBLIubBandwidth.
• Update was done to section 7.1: MAC-E Scheduler Inputs - Measurements
• Feature 34249 EUL Capacity Optimized HARQ Operation. The deactivation
of the feature for the iCEM is no longer done through a patch MIB, it is
deactivated by default.
• Feature 33481 E-DCH DL control channels Power Control. Correction
regarding the activation flags: the parameter agchPowerControlActivated is
not an activation flag. This parameter is an obsolete parameter.
• Feature 34633 E-DCH Mac-e throughput of 10Mbps. Correction regarding
the recommended value for edchMaxThroughputXcem (it shall automatic
instead of 7680).
• Feature 34441 2ms TTI on OneBTS. Changes used to describe the
implementation of the 2ms TTI on OneBTS (using the UCU-III) including new
E-TFCI tables and other parameter settings specific to this platform.
•In Volume 5:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
• Feature 29808 Multi-Carrier PA power pooling. Clarification regarding the
supported radio configurations and the rules regarding CEM pool.
23/09/2009
Issue 04.02 / EN,
Updates:
•In Volume 1:
•History update
•In Volume 2:
•harqNbMaxRetransmissionsXcem parameter changed from class 2 to
class 3
•UA5 restrictions removed and 64-QAM HS-DSCH UE category added
•In Volume 3:
•hsdpaSchedulerWeightingFactorXcem,
hsdpaBlerTargetUpperLimitXcem, hsdpaBlerTargetLowerLimitXcem,
hsdpaUECategoryThroughputWeightingXcem, minimumPowerForHsdpa
and maxHspaPowerOffset parameters changed from class 0 to class 3
•Parameter name changed from isRlcReconfigAllowedForR99 in UA6.0 to
is2ndRrcRbReconfNeededForQC7200 in UA7.0.
•Feature 34388 “Layer 2 Enhancements: Flexible RLC and MAC-ehs”: new
recommendation for hsdschSlowStartPeriod (recovery from burst cases),
rlcRetransmissionBufferInKbytes.
New recommendation for eligibleUeCategoryForHighPerformance,
isHighPerformancePduSizeReconfAllowed,
eligibleUeCategoryForSirTargetHsdpa (the Release7 UE Cat 13, 14, 17
and 18 are eligible)
•New value concerning the “TBS applied from maximum MCS” for Category
10 and xCem
•Update of the Engineering Recommendation concerning the maximum
HSDPA throughput for UE Cat.10
• Update of the parameter settings for maximumTokenGenerationRate and
bucketBufferTimeSapied from maximum MCS” for UE category 14
•In Volume 4:
•edchInitialTBIndex10msTTI, edchInitialTBIndex2msTTI,
edchSpiRelativeWeight, ergchPowerSignature,
eagchErgchEhichTotalPower, eagchPowerOffset,
eagchPowerOffsetEdchTti2ms, ehichPowerOffset,
ehichPowerOffsetEdchTti2ms, ergchPowerOffset and
ergchPowerOffsetEdchTti2ms parameters changed from class 0 to class 3.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•Update to the feature 75786 – iBTS Local Congestion Control. Change made
on the activation flag parameter’s name: from edchCMActivation (UA6 and
UA7.0) to edchLocalCongestionControlActivation (UA7.1).
31/07/2009
Issue 04.01 / EN, Preliminary
Updates:
•In Volume 1:
•History update
•In Volume 2:
•None
•In Volume 3:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
•Introduction of the feature 34388 “Layer 2 Enhancements: Flexible RLC and
MAC-ehs” (section 5.5)
•Clarification of the recommendation concerning the Mac-d PDU size for Cat.6
and 12
•Introduction of the feature 34386 “64 QAM for HSDPA”
•Range of serviceMaxRate, serviceMinRate, serviceHighRate,
serviceLowRate corrected
•New recommendation for serviceHighRate
•Class of numberOfHsPdschCodes and numberOfHsScchCodes corrected
•New recommendation for hsdpaSchedulerAlgorithmXcem
•Update of the “TBS applied from maximum MCS” for UE Category 10 with
flexible Mac-d pdu and 656 bits Mac-d pdu and for UE Category 14
•Update of recommendation concerning the “Pre-requisites to reach the
maximum throughput with 64QAM”
•In Volume 4:
•None
•In Volume 5:
•Restructuration made for chapter named RRC TRAFFIC SEGMENTATION;
Chapter renamed to iMCRA.
•Description of 75069 iMCRA - Intelligent Multi-Carrier RRC Connection
Allocation
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
FIGURES
Figure 1: Static and Configuration Parameters 16
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
1 INTRODUCTION
1.1 OBJECT
The HSxPA Parameters User Guide (HPUG) document provides parameters setting
recommendations from Alcatel-Lucent’s 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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
• Tag [iCEM] indicates that the behaviour or the feature is specific to iCEM.
• Tag [xCEM] indicates that the behaviour or the feature is specific to xCEM
only or to xCEM and UCU-III if there is no [UCU-III] tag.
• Tag [UCU-III] indicates that the behaviour or the feature is specific to [UCU-
III].
• No tag indicates that the behaviour or the feature is common for all the
boards.
R99 related features and settings are not part of this document. Please refer to
[R01]a.[R02].
The following volumes have been deleted from the UA6.0 HPUG and replaced by a
specific document:
- Volume 7: Iub Resource Management Æ refer to [R03]
- Volume 8: Capacity Æ refer to [R04]
The HSxPA Parameters User Guide is not supposed to present the whole Plan of
record. For accurate Plan of record and feature delivery information please refer to
your account and PLM prime.
Refer also to [R06] for more information on features available for UA7.
The Pico/Micro NodeB product is out of scope of this document, thus all eng’g information, algorithms
description and parameters values provided in this document are strictly related to “standard” Alcatel-
Lucent NodeB products.
See [R07] for details related to HSxPA implementation in Pico & Micro NodeB.
Page 12/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
• UTRAN Data fill
• Trials and FOA
1.4 NOMENCLATURE
• The parameter names are written in bold italic.
• The objects names are written in bold.
• The parameters properties are presented as follow:
Parameter Object
Range & Unit
User Granularity
Class
Value
• The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.
• The data fill rules are presented as the following:
Rule:
Restriction:
Engineering Recommendation:
• The difference between Release N and Release N-x are presented as the
following:
UAN-x-UAN Delta:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
• Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o N.A.: Not Applicable.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
2 PARAMETERS ORGANIZATION
In order to understand the definition and the role of the different parameters, it is
appropriate to explain how these parameters are linked together and grouped within
the RAN model.
Static
WPS Templates
Customer
Non-Static
Manufacturer
CIQ
OMC
database System DRF
There are two main kinds of parameters in Alcatel-Lucent’s system, the static and
configuration parameters.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
o Manufacturer: They represent system constants defined by the manufacturer.
They do not appear at the MMI neither in the DRFs.
• Regardless of the parameter type (customer or manufacturer), the parameters can have
the following classes:
o Class 0: the value of the parameter is set at the parent object creation.
Currently, most of the objects can only be killed and re-created through a new
MIB built (either btsEquipmentMIB or rncMIB).
o Class 1: new parameter value is taken into account on the next RNC restart.
This class is no longer valid.
o Class 2: parameters of an object created at the OMC-R (respectively OMC-B)
can only be set when the object and its parent are both locked. The new value
will be taken into account after the object is back to working state
(administrative state set to “unlocked”).
o Class 3: parameters of an object created on the OMC–R (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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
3.1 ABBREVIATIONS
ACK Acknowledgment
AICH Acquisition Indicator Channel
AM Acknowledged Mode
AMC Adaptive Modulation and Coding
ARP Allocation Retention Priority
ARQ Automatic Repeat Request
ATM Asynchronous Transfer Mode
AS Active Set
BBU Base-Band Unit
BLER Block Error Rate
CAC Call Admission Control
CC Chase Combining
CCPCH Common Control Physical Channel
CE Channel Element
CEM Channel Element Module
CFN Connection Frame Number
CM Compressed Mode
CN Core Network
CP Passport: Control Processor
CPICH Common Pilot Channel
CRC Cyclic Redundancy Check
CS Circuit Switched
DCH Dedicated Channel
DDM Dual Duplexer Module
DL Downlink
DPCCH Dedicated Physical Control Channel
DPDCH Dedicated Physical Data Channel
DS Delay Sensitive
DS1 Digital Signal level 1 (1.544 Mbit/s)
DTX Discontinuous Transmission
E-AGCH Enhanced Access Grant Channel
ECC E-DCH Congestion Control
E-DCH Enhanced DCH (also referred as HSUPA or EUL)
E-DPCCH Enhanced Dedicated Physical Control Channel
E-DPDCH Enhanced Dedicated Physical Data Channel
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
E-HICH Enhanced Hybrid ARQ Indicator Channel
E-RGCH Enhanced Relative Grant Channel
E-TFC E-DCH Transport Format Combination
E-TFCI E-DCH Transport Format Combination Indicator
EUL Enhanced Uplink (stands for E-DCH)
FP 3GPP: Frame Protocol
Alcatel-Lucent Passport: Function Processor
FRS Feature Requirements Specification
GMM GPRS Mobility Management
G-RAKE Generalized rake receiver
GRF Global Reduction Factor
H-ARQ Hybrid ARQ
HCS Hierarchical Cell Structure
HS-DSCH High Speed Downlink Shared Channel
HS-SCCH Shared Control Channel for HS-DSCH
HSDPA High-Speed Downlink Packet Access
HSUPA High-Speed Uplink Packet Access
HHO Hard Handover
HO Handover
IE Information Element
iMCTA intelligent Multiple Carrier Traffic Allocation
iMCRA intelligent Multiple Carrier Re-direction Algorithm
iRM intelligent RAB mapping
IMEI International Mobile Equipment Identification
IMSI International Mobile Subscriber Identification
IP Internet Protocol
IR Incremental Redundancy
KPI Key Performance Indicator
LA Location Area
LAC Location Area Code
LCG Local Cell Group
MAC Medium Access Control
MCPA Multi-Carrier Power Amplifier (also referred as PA)
MIB 3GPP: Master Information Block;
Alcatel-Lucent RNC/NodeB: Management Information Base
MMI Man-Machine Interface
MO Mobile Originated
MT Mobile Terminated
NACK Negative Acknowledgement
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
NAS Non Access Stratum
NBAP NodeB Application Part
NDS Non-Delay Sensitive
OAM Operations, Administration and Maintenance
OLPC Outer-Loop Power Control
OLS Olympic Level Service
OMC Operations and Maintenance Center
OMC-B OMC NodeB
OMC-R OMC RNC
OVSF Orthogonal Variable Spreading Factor
PA Power Amplifier (stands for MCPA)
P-CCPCH Primary CCPCH
PCPCH Physical Common Packet Channel
P-CPICH Primary CPICH
PCR Peak Cell Rate
PDU Protocol Data Unit
PICH Paging Indicator Channel
PLMN Public Land Mobile Network
PRACH Physical Random Access Channel
PS Packet Switched
P-SCH Primary SCH
PSCR Physical Shared Channel Reconfiguration
QAM Quadrature Amplitude Modulation
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
RA Registration Area
RAB Radio Access Bearer
RACH Random Access Channel
RAN Radio Access Network
RANAP Radio Access Network Application Part
RAT Radio Access Technology
RB Radio Bearer
RL Radio Link
RLS Radio Link Set
RLC Radio Link Control
RMS Root Mean Square
RNC Radio Network Controller
RNC-AN RNC Access Node
RNC-CN RNC Control Node
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
RNC-IN RNC Interface Node
RNS Radio Network Subsystem (an RNC and its associated NodeBs)
RoT Rise over Thermal
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSN Retransmission Sequence Number
RSSI Received Signal Strength Indicator
RTWP Received Total Wideband Power
SCCP Signalling Connection Control Part
S-CCPCH Secondary CCPCH
SCH Synchronization Channel
S-CPICH Secondary CPICH
SCR Sustainable Cell Rate
SDU Service Data Unit
SF Spreading Factor
SFN System Frame Number
SHO Soft Handover
SI Scheduling Information
SIB System Information Block
SM Session Management
SRB Signalling Radio Bearer
SRLR Synchronous Radio Link Reconfiguration
SS7 Signalling System 7
S-SCH Secondary SCH
STM1 Synchronous Transport Module-1 (155.52 Mbit/s)
TFC Transport Format Combination
TFCI Transport Format Combination Indicator
TFCS Transport Format Combination Set
THP Traffic Handling Priority
TM Transparent Mode
TNL Transport Network Layer
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 22/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
3.2 DEFINITIONS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/24
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 1 : Introduction
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/24
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
2 HSXPA OVERVIEW
Alcatel-Lucent – Proprietary
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
CONTENTS
1 INTRODUCTION............................................................................................................................4
1.1 OBJECT ....................................................................................................................................4
1.2 SCOPE OF THIS DOCUMENT .......................................................................................................4
4 UE CATEGORIES........................................................................................................................36
4.1 HSDPA .................................................................................................................................36
4.2 HSUPA .................................................................................................................................37
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
TABLES
Table 1: HSUPA / HSDPA comparison 8
Table 2: Number of processes per UE category for iCEM 17
Table 3: Number of processes per UE category for UCU-III 18
Table 3: Number of processes per UE category for xCEM 18
Table 4: RV coding for 16QAM 20
Table 5: RV coding for QPSK 20
Table 6: RV update table in the MIR case (Trv[i]) 23
Table 7: RV update table in the PIR case (Trv[i]) 23
Table 8: RV updates tables when harqType set to Dynamic Redundancy 24
Table 9: RV update table in the IR case (Trv[i]) 26
Table 10: RV update table in the CC case (Trv[i]) 26
Table 11: E-DPDCH slot formats 30
Table 12: E-DPCCH slot formats 31
Table 13: E-DPCCH power offset index vs. amplitude 32
Table 14: Relative grant information (E-RGCH) 34
Table 15: ACK/NACK information (E-HICH) 35
Table 16: HSDPA UE categories (3GPP TS25.306) 36
Table 17: HSUPA UE categories (3GPP TS25.306) 37
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
FIGURES
Figure 1: R99 principle ........................................................................................................................................ 6
Figure 2: HSDPA principle .................................................................................................................................. 6
Figure 3: HSDPA layer2/layer1 flows ................................................................................................................ 7
Figure 4: MAC-hs entity on UTRAN side .......................................................................................................... 7
Figure 5: Protocol Architecture of E-DCH......................................................................................................... 9
Figure 6: UE side MAC architecture .................................................................................................................. 9
Figure 7: Transport channel configuration...................................................................................................... 10
Figure 8: HSDPA channels and associated R99 channels.......................................................................... 11
Figure 8: HSDPA channels for HSDPA-DC operation.................................................................................. 11
Figure 9: Timing relationship at NodeB between physical channels .......................................................... 12
Figure 10: HS-SCCH structure......................................................................................................................... 13
Figure 11: HS-PDSCH structure ...................................................................................................................... 13
Figure 12: HS-DPCCH structure...................................................................................................................... 14
Figure 12: HS-DPCCH ACK/NACK structure for dual cell/carrier calls...................................................... 14
Figure 12: HS-DPCCH CQI mapping for dual cell/carrier calls ................................................................... 14
Figure 13: Example of throughput or BLER versus radio conditions for different modulation ................ 17
Figure 14: RV parameters assignment algorithm .......................................................................................... 21
Figure 15: ACK/NACK/DTX management for HARQ processes ................................................................ 22
Figure 16: Dynamic selection of HARQ type.................................................................................................. 25
Figure 17: HSUPA channels and associated R99 channels........................................................................ 28
Figure 18: E-DPCCH / E-DPDCH frame structure ........................................................................................ 30
Figure 19: E-DPDCH/E-DPCCH multiplexing on I/Q .................................................................................... 31
Figure 20: Uplink physical channels multiplexing.......................................................................................... 31
Figure 21: E-AGCH frame structure ................................................................................................................ 33
Figure 22: E-HICH frame structure .................................................................................................................. 34
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system description, configuration aspect and engineering
recommendations.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
3 SYSTEM OVERVIEW
HSDPA
3GPP has standardized HSDPA in Release 5 [R01] in order to increase maximum
user throughput for downlink packet data (streaming, interactive and background
traffic classes) and decrease downlink packet transmission delay. This Release 5 is
fully compatible with the previous Release 99 (R99).
In R99, data are transmitted on a dedicated channel with a given user throughput and
a downlink transmitted power controlled according to the radio conditions:
Same Throughput
Unused
Data Power
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
Typically, a user in good radio conditions will receive his data with a high bit rate
whereas a user in bad radio conditions will receive his data with a lower bit rate.
The efficiency of this rate adaptation is due to a new MAC entity, the MAC-hs layer,
located in the NodeB (see the two following figures), near the physical channel, which
allows a high reactivity in the resource allocation according to the RF conditions
changes. This MAC-hs layer manages the scheduling of users and the
retransmissions of packets.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
RRC
RRC(RNC)
(RNC)
RLC
RLC(RNC)
(RNC)
MAC Control PCCH BCCH CCCH CTCH MAC Control MAC Control DCCH DTCH DTCH
MAC-hs
MAC-hs MAC-d
(NodeB)
(NodeB) (S-RNC)
MAC-c/sh
MAC-c/sh
(C-RNC)
(C-RNC)
Associated Associated
Downlink HS-DSCH Uplink PCH FACH RACH CPCH DSCH DCH DCH
Signaling Signaling
R5
R5L1:
L1:HSDPA
HSDPA(NodeB)
(NodeB) R99
R99L1:
L1:Channel
ChannelCoding
Coding/ /Multiplexing
Multiplexing(NodeB)
(NodeB)
HS-SCCH HS-PDSCH HS-DPCCH S-CCPCH S-CCPCH PRACH PCPCH PDSCH DPCH DPDCH/DPCCH
Page 7/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
• 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)
QPSK,
Not 2 ms
HSDPA 16QAM, Turbo No Supported Supported Supported
supported only
64QAM
Supported Supported
2 ms, BPSK and
HSUPA Supported Turbo Yes Supported but less but less
10 ms QPSK
reactive reactive
• Turbo coding
• Spreading on a separate OVSF code and scrambling together with other
physical channels.
• HSUPA is power controlled as for R99. Indeed, HSUPA channels have a
power offset relative to DPCCH.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
MAC-d MAC-d
MAC-es
MAC-es /
MAC-e
MAC-e MAC-e EDCH FP EDCH FP
Uu
UE NodeB Iub DRNC Iur SRNC
M A C -d
M A C -es / M A C -c/sh
M A C -hs
M A C -e
E -D C H
H S -D S C H PCH FA C H FA C H R A C H C PCH U SCH U SCH D SCH D SC H DCH DCH
( FD D only ) ( T D D only ) ( T D D only )
A sso c ia te d A sso c ia ted A sso c ia te d
A sso c ia te d
U p link D o w nlink U p link
D o w nlink
S igna lling S igna lling S igna lling
S igna lling
3.1 HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
In downlink, the HS-PDSCH are transmitted with the HS-SCCH (High Speed – Shared
Control CHannel) channel. This channel is broadcasted over the cell but his
information concerned only the user who has to receive the HS-PDSCH. The HS-
SCCH allows the user to know if the HS-PDSCH is for him and to decode them
correctly.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
The following figure summarizes the different channels needed for a HSDPA call:
HSDPA channels
NodeB
HSDPA UE
Associated DPCH for data, speech + SRB traffic
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 cells
Page 11/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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
The mobile receives a HS-SCCH subframe (see the following figure) containing
control information among which:
• Channelization-code-set information (7 bits – slot #0 of subframe)
• Modulation scheme information (1 bit – slot #0 of subframe), i.e. value 0 is
QPSK and value 1 is 16QAM or 64-QAM (distinction between 16-QAM and
64-QAM is explained in [R10])
The SF is fixed to 128. It indicates to which UE data is intended to, on which codes
and with which parameters. There are as many HS-SCCH transmitted during a TTI as
scheduled user number.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 12/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Data
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).
The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload. The
SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One
HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of
codes is given by UE capabilities).
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
ACK/NACK CQI
Page 14/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the
N_acknack_transmit parameter, as specified in [R04] §6A.1.1.
Because of the 33621 HSPA Configuration at site Granularity feature, it’s 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)
Only value “no repetition” (ackNackRepetitionFactor = 1) is allowed, since xCEM supports only this
value.
The CQI is only sent in some specific subframes, as specified in [R04] §6A.1.1,
depending on the following parameters:
• The CQI feedback cycle: k,
• The repetition factor of CQI: N_cqi_transmit.
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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
term of throughput or BLER) according to the modulation:
AMC Illustration
800
700 QPSK ¼
QPSK ½
600 QPSK ¾
Throughput (kbps)
16QAM ½
500 16QAM ¾
400
300
200
100
0
-20 -15 -10 -5 0 5
Ior/Ioc (dB)
Figure 16: Example of throughput or BLER versus radio conditions for different modulation
There is an HARQ process assigned per transport block for all the transmissions. The
number of processes per UE is limited and depends on its category. The number of
processes per UE category is the one given in [R02]:
[iCEM]
Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Ue Category 13 14 15 16 17 18
Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Ue Category 13 14 15 16 17 18 19 20 21 22 23 24
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.
[xCEM]
[UCU-III]
For UCU-III, the maximum number of retransmissions is set to 10
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
[iCEM][xCEM]:
The two following parameters are common for iCEM and xCEM (RNC parameters):
3.1.3.2 RV PARAMETERS
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Xrv (Value) s r b
0 1 0 0
1 0 0 0
2 1 1 1
3 0 1 1
4 1 0 1
5 1 0 2
6 1 0 3
7 1 1 0
Xrv (Value) s r
0 1 0
1 0 0
2 1 1
3 0 1
4 1 2
5 0 2
6 1 3
7 0 3
The determination of the s, r and b parameters will be based on the Xrv update, but
not necessarily in the increasing order. The update indeed follows a predefined order
stored in a table (called hereafter Trv). The only requirement to fill this table is that
Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be the
nominal configuration).
The rules to compute the Xrv parameters then are (see the following figure):
• For the first transmission, Xrv is initialized to Trv[0].
• Upon reception of a NACK, Xrv is assigned the next value in the table (once
the last value of the table, Nmax, has been set, the next value should be the
first one again).
• In case of no reception of ACK/NACK (DTX indication), the parameters must
not be updated so that the same information not received by the UE should be
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
sent again (this ensure no systematic bits are lost, because all blocks may not
be self-decodable).
Y Xrv = Trv[0]
New transmission ?
k=0
N
Y
DTX indication ? Xrv(n) = Xrv(n-1)
N
k=k+1 Nmax = 1 (CC)
Xrv(n) = Trv[k mod Nmax] = 4 (PIR - QPSK)
= 6 (PIR – 16QAM)
= 8 (MIR)
Figure 17: RV parameters assignment algorithm
The following figure describes the different states of HARQ processes and possible
actions related to these.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Update of RV parameters
Data transmission
NACK
Reset HARQ process
Remove Mac-d PDU Nret = Nret +1
Update structures
Y
Nret > Nret_max ?
N
Wait for
NACK/DTX state
retransmission
Page 22/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
changes the RV parameter update compared to Nack reception, that is to say
that the RV parameter update is not the same as for Nack, so no update, see
§3.1.3.2 “RV Parameters” section). The process is then set in the “DTX state”.
The processes in the NACK or DTX state are just waiting for being re-scheduled for a
new retransmission.
[iCEM]
A configurable parameter (CC/PIR/MIR) indicates the possibility of switching between
Chase Combining, a Partial IR or a mix between Partial and Full IR sequence. It
implies that 3 different tables must be stored (see below), chosen accordingly:
• The Chase Combining option corresponds to the first redundancy version
always applied for all (re)transmissions.
• The PIR indicates that for all redundancy versions, the systematic bits must
be transmitted (blocks are self-decodable). Only the RV with s = 1 must be
taken into account.
• The MIR corresponds to a sequence where both systematic and non-
systematic bits can be punctured. All possible redundancy versions are
assumed and it corresponds to default version.
Each HARQ type is characterized by its update table Trv (see tables below)
i 1 2 3 4 5 6 7 8
Xrv(QPSK) 0 2 5 6 1 3 4 7
Xrv(16QAM) 6 2 1 5 0 3 4 7
i 1 2 3 4 5 6
Xrv(QPSK) 0 2 4 6
Xrv(16QAM) 6 2 5 0 4 7
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
With the feature “HSDPA Performance Enhancement – Optimal Redundancy Version
for HARQ retransmission” (29819), a fourth HARQ type can be selected: the Dynamic
Redundancy noted DR (harqType = 4). This value is introduced to indicate that
dynamic RV selection must be performed.
The aim of this sub-feature is to optimize the redundancy version (RV) of the
retransmissions by dynamically selecting the most efficient HARQ type (and his
corresponding RV table presented below) according to several parameters: UE
category, number of HARQ processes and applied AMC for first transmission.
The different HARQ types (each one being associated to a restricted redundancy
version set) that can be selected are:
Chase Combining (CC): same redundancy version than first transmission is
applied (QPSK only).
RV = 0.
CC + Constellation rearrangement (CC+CoRe): same puncturing pattern is
applied but constellation rotation is performed (16QAM only).
RV ∈ [0; 4; 5; 6].
Partial Incremental Redundancy (PIR): systematic bits are prioritized.
RV ∈ [0; 2; 4; 6] in QPSK and [0; 2; 4; 5; 6; 7] in 16QAM.
Full Incremental Redundancy (FIR): parity bits are prioritized.
RV ∈ [1; 3; 5; 7] in QPSK and [1; 3] in 16QAM
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
• 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
These values are then used to select the right HARQ type as explained by the
following figure:
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].
[xCEM]
The HARQ type selection is done through the parameter harqTypeXcem:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Parameter harqTypeXcem Object HsdpaConf
Range & Unit [ccType, irType]
User Customer Granularity BTSCell
Class 3
Value irType
The following tables give according to [R03] the redundancy version and constellation
depending on the modulation:
i 1 2 3 4
Xrv(QPSK) 0 2 5 6
Xrv(16QAM) 6 2 1 5
Xrv(64QAM) 6 2 1 5
[xCEM] only:
i 1 2 3 4
Xrv(QPSK) 0 0 0 0
Xrv(16QAM) 0 4 5 6
Xrv(64QAM) 0 4 5 6
[iCEM]
The scheduler first receives as input every TTI the number of codes available and the
remaining power for HS-PDSCH and HS-SCCH (see [Vol. 3]). The received
ACK/NACK and CQI must also be provided to the scheduler when available. Thanks
to this information, UE capabilities, configuration parameters provided by the RNC and
taking into account the previously scheduled data, the scheduler can select the sub
flows of the users to schedule in order to optimally use available resources. The main
concepts of the scheduler are:
• Retransmissions are of higher priority than new transmissions and should be
scheduled first.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
• 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 there’s no
CPU limitation).
• No queue ID should be left starving, i.e. the scheduler should always allocate
even a small part of radio resources to all users (even those with low priority
and bad CQI).
From UA5.0, the MAC-hs scheduler has been enhanced (29807 – MAC-hs scheduler
improvement) in order to support 2 MAC-hs scheduler types (Classical Proportional
Fair, ALU Proportional Fair,) and manage SPI.
The scheduling method for the different scheduler is the following one:
• Classical Proportional Fair: Users are chosen according to the instantaneous
CQI/averaged CQI criteria. UEs that are in their best instantaneous conditions
with regard to their average are scheduled first.
• Alcatel-Lucent Proportional Fair scheduler: Users are chosen according to the
number of transmitted bits and the reported CQI
[xCEM]
The aim of the scheduler is to share the resources between the different HSDPA
users. xCEM scheduler works in following steps:
- To select of a limited number of users from those which are ready for
transmission in the curret TTI (the number of users per TTI being
limited by the number of HS-SCCH configured and by the available
resources mainly in term of codes and power).
- To select of a Transport Format resource Combination (TFRC =
{MAC-hs PDU size; number of HS-PDSCH codes; modulation
alphabet}) of each user.
- To allocate of power for the HS-SCCH and HS-DSCH of each user.
- To rank the users according to certain pre-defined scheduling metric,
which may or may not take the chosen TFRC into account.
With iCEM, the TFRC is chosen by doing a mapping between the CQI (CQI processed
in order to take into account the bler target and to fit with the available resources).
With xCEM, the TFRC selection is based on the Spectral Efficiency (SE). The SE for a
given SINR states the maximal number of bits before channel encoding and before
addition of CRC bits and tail bits for terminating the Turbo Code that can be
transmitted over an AWGN channel with a certain BLER. The SINR is based on the
CQI reported by the UE.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Since UA7.1.2, xCEM 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 and divide equally the target
GBR between the resources of twodual cells..
H
DC
E-
DP
E-
CH
H
HI
GC
E-
CH
A
E-
RG
E-
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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-DPDCH and E-DPCCH (sub) frame structure is presented on the figure below
(from [3GPPref]):
E-DPCCH 10 bits
1 subframe = 2 ms
1 radio frame, Tf = 10 ms
On uplink, each radio frame is divided in 5 sub frames, each of length 2 ms. Different
E-DPDCH and E-DPCCH slot formats have been defined as shown on the two tables
below:
Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Subframe Bits/Slot
Ndata
0 15 256 150 30 10
1 30 128 300 60 20
2 60 64 600 120 40
3 120 32 1200 240 80
4 240 16 2400 480 160
5 480 8 4800 960 320
6 960 4 9600 1920 640
7 1920 2 19200 3840 1280
Table 12: E-DPDCH slot formats
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Sub frame Bits/Slot
Ndata
0 15 256 150 30 10
Table 13: E-DPCCH slot formats
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]:
.
.
.
. ced,k βed,k iqed,k
E-DPDCHk
Σ
.
. I+jQ
.
Se-dpch
. ced,K βed,K iqed,K
E-DPDCHN
DPCCH
DPDCHs Sdpch
Spreading
Sdpch,n
Σ
HS-DPCCH Shs-dpcch I+jQ
Spreading
S
E-DPDCHs
E-DPCCH Se-dpch
Spreading
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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:
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 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 5/15
Table 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:
⎛ Δ E − DPCCH ⎞
⎜⎜ ⎟⎟
β ec = β c ⋅ 10 ⎝ 20 ⎠
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
E-AGCH 20 bits
1 subframe = 2 ms
1 radio frame, Tf = 10 ms
An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one E-
AGCH frame. The transmission over one E-AGCH sub-frame and over one E-AGCH
frame shall be used for UEs for which E-DCH TTI is set to respectively 2 ms and
10 ms. 6 bits are used to code Access Grant values. One 16 bits CRC (xored by UE
id) is attached to the AG value to form one 22 bits word. A rate 1/3 convolution coding
(constraint length 9) is then used leading to a total of 90 protected bits. A specific
puncturing scheme is then applied to finally select a 60 bits sequences (30 bits are
removed). With this kind of mechanisms only one UE can be touched at each E-DCH
TTI.
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 33/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
Command RG Value (serving E-DCH RLS) RG Value (other radio links)
UP +1 not allowed
HOLD 0 0
DOWN -1 -1
The orthogonal signature sequences Css,40, m(i) and the index m(i) in slot i are chosen in
the same tables than those used for E-HICH ACK/NACK indicators. The E-RGCH
signature sequence index l is given by higher layers.
In each cell, the E-RGCH and E-HICH assigned to a UE shall be configured with the
same channelisation code (SF 128).
• The E-DCH Hybrid ARQ Indicator Channel (E-HICH) is a fixed rate (SF=128)
dedicated downlink physical channel carrying the uplink E-DCH hybrid ARQ
acknowledgement indicator.
The following figure illustrates the structure of the E-HICH:
1 subfram e = 2 m s
1 radio fram e, T f = 10 m s
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
The ACK/NACK command is mapped to the HARQ acknowledgement indicator as
described in the table below.
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.
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.
In UA6, only the 10 ms E-DCH TTI is supported in UCU-III. In UA7.1 both 10 ms and 2 ms E-DCH TTI
are supported in UCU-III.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 35/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
4 UE CATEGORIES
4.1 HSDPA
3GPP has standardized several UE categories to accommodate a large spectrum of
HSDPA mobile implementations (see [R05]). The UE category provides the mobile
capabilities like max number of HS-PDSCH codes supported, modulation schemes
(64QAM, 16QAM, QPSK), MAC-HS transport block size, etc.
HS-DSCH Maximum number Minimum Maximum number of bits of an HS- Total number of
category of HS-DSCH codes inter-TTI DSCH transport block received within soft channel bits
received interval an HS-DSCH TTI
Category 1 5 3 7298 19200
Category 2 5 3 7298 28800
Category 3 5 2 7298 28800
Category 4 5 2 7298 38400
Category 5 5 1 7298 57600
Category 6 5 1 7298 67200
Category 7 10 1 14411 115200
Category 8 10 1 14411 134400
Category 9 15 1 20251 172800
Category 10 15 1 27952 172800
Category 11 5 2 3630 14400
Category 12 5 1 3630 28800
Category 13 15 1 35280 259200
Category 14 15 1 42192 259200
Category 15 15 1 23370 345600
Category 16 15 1 27952 345600
Category 17 15 1 35280 259200
Category 18 15 1 42192 259200
Category 19 - - - -
Category 20 - - - -
Category 21 15 1 23370 345600
Category 22 15 1 27952 345600
Category 23 15 1 35280 518400
Category 24 15 1 42192 518400
Table 17: HSDPA UE categories (3GPP TS25.306)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
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.
4.2 HSUPA
For HSUPA, the following UE categories have been specified in 3GPP [R05]:
Category 1 1 SF4
10 ms TTI 7110 -
only
Category 2 2 SF4 10 ms and 14484 2798
2 ms TTI
Category 3 2 SF4 10 ms TTI 14484 -
only
Category 4 2 SF2 10 ms and 20000 5772
2 ms TTI
Category 5 2 SF2 10 ms TTI 20000 -
only
Category 6 4 SF2 10 ms and 20000 11484
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]
In UA7 SF2 and 2msTTI are supported only by the xCEM (UE categories 4, 5 and 6
are supported) whereas the iCEM board keep the same capabilities as in UA5 (i.e UE
Cat 2, 4, 5 and 6 are not supported).
In term of bit rate, we can expect a maximum MAC-e throughput of:
• 2.0 Mbits/s for TTI = 10 ms
And a maximum RLC throughput of:
o Category 3: 1380 kb/s
o Category 5: 1890 kb/s
• 5.76 Mbits/s for TTI = 2 ms
And a maximum RLC throughput of:
o Category 4: 2720 kb/s
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/38
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 2 : HSxPA Overview
[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.
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 38/38
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
Alcatel-Lucent – Proprietary
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
CONTENTS
1 INTRODUCTION............................................................................................................................6
1.1 OBJECT ....................................................................................................................................6
1.2 SCOPE OF THIS DOCUMENT .......................................................................................................6
3 HSDPA ACTIVATION..................................................................................................................10
4 SCHEDULER ...............................................................................................................................10
4.1 ALGORITHM ............................................................................................................................10
4.1.1 [iCEM]............................................................................................................................10
4.1.2 [xCEM] [UCU III]............................................................................................................12
4.1.2.1 UL processing........................................................................................................... 12
4.1.2.2 CQI Æ SNR mapping and SNR Æ SE mapping ...................................................... 12
4.1.2.3 HARQ process and priority queue selection ............................................................ 12
4.1.2.4 User ranking ............................................................................................................. 13
4.1.2.5 SNR estimation for HS-PDSCH................................................................................ 13
4.1.2.6 TFRC selection......................................................................................................... 13
4.2 SCHEDULER TYPES .................................................................................................................16
4.2.1 [iCEM]............................................................................................................................16
4.2.2 [xCEM] [UCU III]............................................................................................................17
4.3 QOS MANAGEMENT .................................................................................................................19
4.3.1 [iCEM]............................................................................................................................19
4.3.2 [xCEM]...........................................................................................................................22
4.4 UE CATEGORY MANAGEMENT ..................................................................................................30
4.4.1 [iCEM]............................................................................................................................30
4.4.2 [xCEM]...........................................................................................................................31
4.5 HSDPA USER SCHEDULING.....................................................................................................31
4.5.1 [iCEM]............................................................................................................................31
4.5.2 [xCEM]...........................................................................................................................32
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
5.5.1 Overview .......................................................................................................................58
5.5.2 Configuration .................................................................................................................58
5.5.3 Interection & Mobility.....................................................................................................59
5.5.4 Parameter settings ........................................................................................................60
5.5.5 NodeB impact................................................................................................................61
5.6 LAYER 2 ENHANCEMENTS: FLEXIBLE RLC AND MAC-EHS .........................................................66
5.6.1 Flexible RLC and MAC-ehs...........................................................................................66
5.6.2 IUB Frame protocol .......................................................................................................74
7 OVSF CODES..............................................................................................................................87
7.1 CELL CONFIGURATION ............................................................................................................87
7.2 HSDPA CODE ALLOCATION ....................................................................................................88
7.2.1 Dynamic Code Tree Management ................................................................................89
7.2.2 Fair Sharing...................................................................................................................99
Page 2/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.5.3 Parameters Settings and Recommendations ............................................................ 136
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
TABLES
Table 1: CQI mapping table for 336 bits MAC-d PDU size 43
Table 2: CQI mapping table for 656 bits MAC-d PDU size 44
Table 3: Max hsdschInterval value 45
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size 47
Table 5: Necessary throughput per HSDPA UE category (assuming Maximum TBS per TTI) 47
Table 6: Iub bandwidth per number of E1 links 47
Table 7: HS-PDSCH Slot formats 52
Table 8: HS-SCCH power offset table according the reported CQI 128
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
FIGURES
Figure 1: MAC-hs scheduler overview ............................................................................................................ 11
Figure 2: TFRC selection algorithm used by the xCEM/ UCU-III................................................................ 15
Figure 3 : Example of Scheduling Weight for different value of serviceBFactor....................................... 24
Figure 4: Example of Scheduling Weight for different value of serviceKFactor........................................ 25
Figure 5: Parameters to configure the feature “MAC-d PDU size 656 bits” .............................................. 38
Figure 6: Conditions to invoke the feature 79164.......................................................................................... 41
Figure 7: Padding bits in the MAC-hs PDU .................................................................................................... 42
Figure 8: Codes limitation ................................................................................................................................. 49
Figure 9: Code boost ......................................................................................................................................... 49
Figure 10: CQI mapping tables ........................................................................................................................ 51
Figure 11 : Benefits of flexible RLC and Mac-ehs versus fixed RLC and Mac-hs.................................... 68
Figure 12 : RB congestion control Object Tree.............................................................................................. 74
Figure 13: CQI Processing................................................................................................................................ 77
Figure 14 : BLER Target according to the CQI and the UE category for the different BLER Ajustement
algorithm ...................................................................................................................................................... 79
Figure 15: CQI adjustment to BLER algorithm............................................................................................... 80
Figure 16: HS-DPCCH synchronization algorithm ........................................................................................ 85
Figure 17: R99, HSDPA & HSUPA Common Channels codes allocation ................................................. 88
Figure 18: HS-PDSCH codes pre-emption or re-allocation ......................................................................... 91
Figure 19: Number of HS-PDSCH codes pre-empted .................................................................................. 91
Figure 20: Number of HS-PDSCH codes re-allocated.................................................................................. 92
Figure 21: Illustration of the HS-PDSCH re-allocation blocking .................................................................. 92
Figure 22: Exemple of codes occupancy for SF16 ..................................................................................... 100
Figure 23: Power allocation at RNC level..................................................................................................... 103
Figure 24: Physical shared channel reconfiguration message.................................................................. 105
Figure 25: Power allocation at NodeB level ................................................................................................. 106
Figure 26: Transmitted carrier power (on the left) and averaged HSDPA power (on the right) ........... 108
Figure 27: Common measurement................................................................................................................ 109
Figure 28: Power measurement process...................................................................................................... 110
Figure 29: Measurement flow of HS-DSCH required power...................................................................... 113
Figure 30: Power distribution between HS-DSCH and HS-SCCH channels........................................... 113
Figure 31: measurementPowerOffset transmission .................................................................................... 115
Figure 32: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH....... 116
Figure 33: hsdpaAmpUsage parameter........................................................................................................ 118
Figure 34: Dynamic Power Allocation ........................................................................................................... 119
Figure 35: HS-DSCH power management for 1st transmission................................................................ 121
Figure 36: MAC-hs transport block adaptation according to the number of MAC-d PDU to transmit . 123
Figure 37: Remaining power for multi-users per TTI scheduling .............................................................. 127
Figure 38: HS-SCCH power control overview.............................................................................................. 128
Figure 39: Selection of OLPC UL SIR Target parameters by the RNC ................................................... 135
Figure 40: Algorithm for CQI Generating Function...................................................................................... 143
Figure 41: Traffic Conformance Algorithm.................................................................................................... 147
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system description, configuration aspect and engineering
recommendations.
Global US
PM ID Feature Title Activation flag Release
market Market
HSDPA Flexible N/A UA4.2 Yes Yes
27931
resources Mgt
hsdpaActivation
isHsdpaAllowed
HS-SCCH Power N/A UA4.2 Yes Yes
27939
Control
UE Cat 7 & 8 N/A UA5.0 Yes Yes
29809
Support
UE Cat 9 & 10 N/A UA5.0 Yes Yes
29813
Support
isHsPdschDynamicManagementAllowed
Dynamic DL Code
29800 Tree Mgt For isCellHsPdschDynamicManagementActive UA5.0 Yes Yes
HSDPA (from UA6.0)
hsdpaSchedulerAlgorithm
hsdpaSchedulerWeightingFactor
MAC-hs scheduler UA5.0 Yes Yes
29807
improvement hsdpaUeCategoryThroughputWeighting
hsdpaSpiRelativeWeight
isHsxpaServiceIndicatorEnabled
HSDPA and E-
32520 DCH Service hsdpaServiceIndicatorMethod UA5.0 Yes Yes
Indicator
edchServiceIndicatorMethod
hsdpaCqiBlerAdjustmentAlgo
HSDPA
29819 Performance ueCategory1..12 UA5.0 Yes No
Enhancement
harqType
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Global US
PM ID Feature Title Activation flag Release
market Market
rxDemodulation
isDynamicMacdPduSizeManagementAllowed
UE cat.8 max. eligibleUeCategoryForHighPerformance
throughput with UA5.1 Yes No
34340
PDU 656 & RLC minimumUserMbrForHighPerformance
reconfiguration
maxCellRadius (only in UA5.1)
xCEM hardware N/A UA5.1 Yes No
27350
introduction
High quality UL N/A
R99 RAB for High UA5.1 Yes Yes
34652
HSDPA DL data
rate
isDynamicMacdPduSizeManagementAllowed
eligibleUeCategoryForHighPerformance
MAC-d PDU size
29799 Management for minimumUserMbrForHighPerformance UA6.0 Yes Yes
HSDPA
isHsdpaCellHighPerformance (from UA6)
isHighPerformancePduSizeReconfAllowed
OneBTSEquipment::hsdpaCodeTreeManageme
ntActivation (UCU-III)
HSDPA Flexible hsdpaFlexibleModulationVsCodeActivation UA6.0 Yes No
34102
Modulation
Support OCNS proprietaryHSDPAOCNSActivation UA6.0 No Yes
34195
with HSDPA
Qualcomm issue is2ndRrcRbReconfNeededForQC7200
79164 with 656 PDU size UA6.0 Yes Yes
workaround
Layer 2 isMacEhsAllowed (scope RNC)
Enhancement: UA7.0 Yes Yes
34388 isMacEhsAllowed (scope FDDCell)
Flexible RLC and
MAC-ehs
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Global US
PM ID Feature Title Activation flag Release
market Market
isDl64QamAllowed
64 QAM for isDl64QamOnRncAllowed UA7.0 Yes Yes
34386
HSDPA
is64QamAllowedForUeCategory
Radio hsdpaWindowsObserveTime
Measurement UA7.1 Yes No
75998 isDchPowerMarginAdaptive
Frequency
Increase: Tx Power
HSDPA OLS N/A (creation of optional object)
97431 Differentiation at UA7.1 Yes No
Node B Level
isHsdpaDualCellActivated (scope FDDCell)
isHsdpaDualCellAllowed (scope RNC)
Dual Cell HSDPA isDualCellAllowedForUeCategory UA7.1.2 Yes No
81204
Operation
hsdpaPlusPreferredMode
dualCellActivation (scope BTSCell)
[iCEM]
[GM]
Feature not applicable UA7.1.2
Hsdpa aggregate Yes Yes
113511
throughput 40Mbps [xCEM] [UCU-III] [US]
UA7.1.3
No activation flag
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
3 HSDPA ACTIVATION
HSDPA is activated through several activation flags at RNC, FDDCell and BTSCell
level:
Note that isHsdpaAllowed exists also in two other objects (RNC / NeighbouringRNC
and RNC / NodeB / FDDCell / UMTSFddNeighbouringCell) in order to know if the
HSDPA call has to be reconfigured or not in DCH when the primary cell changes in
case of mobility over Iur.
4 SCHEDULER
4.1 ALGORITHM
4.1.1 [iCEM]
As described in the figure below, MAC-hs scheduling consists of choosing the MAC-d
flow (QId) to serve.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The QId is selected using radio (CQI) and priority (SPI) criteria. The selection of a QId
to be scheduled is based on a single cost function with inputs from two costs:
- The first one (C1) depends on the scheduler type. It takes into account the radio
criterion.
- The second one (C2) takes into account the priority of the QID and mainly
depends on the base credits assigned to this SPI priority and the average CQI.
This is used by both Alcatel-Lucent PF and Classical PF schedulers.
The resulting cost is a function of these two costs, and is different according to the
scheduler type. Indeed, for Alcatel-Lucent Proportional Fair scheduler, the resulting
cost should be equal to αC1+βC2, while for the Classical Proportional Fair, the
resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The QId with the
smallest cost is scheduled first. Costs are updated after the QId has been served.
Once a user is chosen to be scheduled according to its cost function, the scheduler
selects for this user a TFRC (transport block size, number of HS-PDSCH and
modulation) based on the reported CQI and by taking into account the available
resources in term of power and codes (see 8.2). CQI can also be adapted in order to
control the Mac-hs BLER (see 6)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
4.1.2.1 UL PROCESSING
First of all, the scheduler needs to receive and decode the HS-DPCCH for all the
users in order to have Ack/Nack and CQI information.
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]
where
Contrary to iCEM, xCEM/UCU-III does not directly use the CQI. The received CQI
information is mapped to SNR values (SNRMAP,dB) depending on UE category. The
TFRC selection is then based on a second mapping between this SNR and the
Spectral Efficiency (SE). The SE defines the number of bits per HS-PDSCH code per
TTI that can be transmitted for a given symbol SNR and SF = 16 (assuming 10%
MAC-hs bler) in an AWGN channel.
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 are expected.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 12/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
4.1.2.4 USER RANKING
A priority is assigned to each user (after its priority queue and HARQ process have
been selected) based on a cost function. xCEM scheduler also creates a user ranking
list by sorting users by increasing cost (first scheduled is the one with the lowest cost).
The xCEM scheduler will try to schedule users one after the other according to this
ranked list (first user in the ranking list will be schedule first, then the second user of
the rank list, and so on). This iterative process is repeated as long as the ranking list is
not empty or as long as some resources are still available.
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)
SE gives the number of bits per HS-PDSCH code per TTI that the user can receive for
given RF conditions and the available power. So, the xCEM/UCU-III scheduler will
select from a look up table the TFRC (transport block size TBS, number of HS-
PDSCH codes nHS-PDSCH and modulation). LUT is made such as the selected TFRC
corresponds to the higher TBS and the lower number of HS-PDSCH so that the
spectral efficiency of this TFRC is lower than the SE computed previously:
TBS / nHS_PDSCH ≤ SE with maximal TBS and minimal nHS_PDSCH
Page 13/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
QAM. This xCEM/UCU-III behavior (QPSK and 16-QAM can be used whatever the
number of HS-PDSCH codes) is related to the feature 34102, which introduces similar
behavour in iCEM.
[UCU III]
In case of an HARQ retransmission, the scheduler will not use the instantaneous SE
but the cumulated SE over all the transmissions of this HARQ process, allowing to
account for IR or CC gains (SEcum = SEcurrent + SEcum).
[xCEM]
The spectral efficiency is SE = min(SEcurrent; SEcum).
This power is also weighted by the term factor because if B/W is smaller than SE, it
means that less power is needed to achieve the same error rate:
PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH x factor
SNR ( B / W )
factor =
SNR ( SE )
Where:
- B is the Transport Block Size selected by the scheduler
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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:
[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.
Then, available resources are updated for the next round of scheduling.
The following drawing summarizes the algorithm used by the xCEM/UCU-III to select
the TFRC of a UE:
Modulation
Number of HS-PDSCH
SNR of one HS-PDSCH (linear)
SNR of one HS-PDSCH (dB)
Æ Æ Æ
Log2lin
SNR (dB) SE TFRC
CQI
UE Cat.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
4.2.1 [iCEM]
As explained in [R05], the RF cost function noted C1 is based on the following
principles:
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).
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.
Parameters:
Parameter hsdpaSchedulerWeightingFactor Object HsdpaConf
Range & Unit [1…8] decimal
User Customer Granularity BTSCell
Class 3
Value 5
The selection of any of these scheduler types can be changed on line through a
customer class 3 parameter: hsdpaSchedulerAlgorithm.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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).
When the xCem has been introduced, the recommended scheduler was the proportionalThroughput in
order to be iso-functional with the iCem scheduler (proportionalFair).
Nevertheless, there is no behaviour difference between the two xCem schedulers when the QoS is
disabled. The behavior differences appear when the QoS is enabled:
- proportionalThroughput allows a relative differentiation between users
- CRmax allows a absolute differentiation between users
The choice of the xCem scheduler depends mainly of the customer strategy in term of QoS.
Nevertheless, the CRmax scheduler is more appropriate to have a GBR-like behavior and offer more
flexibility than proportionalThroughput. That is the reason why the CRmax is the recommended
scheduler in UA7.
Note that to be really able to guarantee a GBR, the Fair Sharing feature is needed.
The cost of each priority queue is computed differently with CRmax and
proportionalThroughput:
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
Page 17/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Where
- SPIweight is given by the OAM parameter hsdpaSpiRelativeWeight
- Scheduling weight SW(u,q) allows to control the scheduling priority for
each user u and queue q according to the measured MAC-d
throughput R. This throughput R is defined as the averaged number
of ACKed MAC-d PDUs times the PDU size divided by TTI duration to
get the bit rate. The scheduling weight can be controlled by the OMC
parameters serviceMinRate, serviceMaxRate, serviceBFactor and
serviceKFactor. 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 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 PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
- with PropTh, all the relative weights hsdpaSpiRelativeWeight have
to be set with the same value (the value 100 disables totally the SPI
management algorithm) or all the SPI have to be set with the same
value (e.g. 0).
- with Crmax, the Scheduling Weight has to be equal to 1 by setting
serviceBFactor to 1
See section 4.3.2 for more details on QoS management for xCEM.
[UCU-III]
Three different scheduling modes are offered, and are called ‘CRMax’,
‘Unconstrained’ and ‘Fair Throughput’. ‘CRMax’ is the default setting, and with this
mode the handling of different traffic classes and scheduling priorities is supported.
The ‘Unconstrained’ mode as well as the ‘Fair Throughput’ mode do not take traffic
class into account, i.e. all calls are handled equally as far as the scheduling priorities
are concerned.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The ‘Unconstrained’ mode assigns the priorities per user in the MAC-hs purely based
on the instantaneous RF conditions. Rate constraints are not taken into account. This
mode yields the highest cell throughput at the expense of reduced user throughput at
cell edge.
The ‘Fair Throughput’ mode assigns the priorities per user in the MAC-hs based on
the hardcoded minimal and maximal rate constraints of 126 kbps and 130 kbps,
respectively. This means that the priority of a user is increased or decreased if its
measured throughput is below or above the given rate constraints. The minimal and
the maximal rates are not guaranteed. They are only applied to weight the user
priorities according to their measured throughput.
For the scheduling modes ‘Fair Throughput’ and ‘Unconstrained’ also service
parameters sets are introduced, which are read only in the OMC-U reflecting the
parameters hard coded in the Node B. No scheduling priority is allocated to them.
The QoS management allows a better Quality Of Service for the users defined with a higher priority
compared to the others users. In order to maximize the cell throughput, the recommendation is to
disable to QoS management in order to avoid that users with high priority will be schedule first even if
experiencing bad RF conditions.
4.3.1 [iCEM]
Basically, with iCem, the QoS management is done by differentiating the users
according to their SPI (the SPI are defined per TC/ARP/THP) and by applying a
relative weight for each SPI. The ratio between the relative weights of two different
SPI gives more or less the ratio of throughput between 2 users characterized by their
SPI assuming they experienced the same RF conditions. This is achieved through
second cost function C2.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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 :
For example, with two different QIds, the throughput of both QId is such that:
Thpt(QId1)/Thpt(QId2) =
Weight SPI(QId1)/ Weight SPI(QId2) * TBS[CQIav(QId1)] / TBS[CQIav(QId2)]
The base credits assigned per SPI priority (via hsdpaSpiRelativeWeight) provide the
relative weight given per priority. The absolute value is not meaningful, only the ratio
between priorities is important. Example: if base credits of priority queue #4 (resp #3)
is set to 20 (resp 10), a UE in priority queue #4 would be provided around twice
throughput than a UE in priority queue #3 if CQI are equal.
In case all base credits are set to 100, the whole SPI management is deactivated.
Note that in case base credits are equal but with a value different from 100, the
behavior should nevertheless roughly be the same but the SPI management part is
active.
Note that the ratio on throughputs may be subject to a certain tolerance (around 10%)
and will not be respected in case there is no resource limitation for some UEs (to
avoid wasting resources by artificially restraining some UEs while other UEs suffer
very bad radio conditions).
Parameters:
Parameter hsdpaSpiRelativeWeight Object HsdpaConf
Range & Unit [1..16][1..100] List of Decimal
User Customer Granularity BTSCell
Class 3
Value 2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The recommendation in order to maximize the HSDPA cell throughput is to disable the QoS
management by setting the hsdpaSpiRelativeWeight to [100 … 100].
The setting of SPI (common for iCem and xCem) is done in RNC /
RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos:
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]
GBR Handling:
In the presence of GBR MAC-d flows, these flows will be served first as long as their
GBR is not satisfied (irrespective of their SPI), even if the throughput of non GBR
MAC-d flows (and even with higher SPI) must be reduced down to 0 kbps.
To determine if a GBR MAC-d flow has reached its GBR or not, MAC-hs continuously
monitors the average throughput of the flow (using an exponential filtering based on
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi parameter). This averaging is
needed since the GBR has to be shown to hold over long-term (hundreds of ms to
seconds) compared to the 2ms TTI.
When several GBR MAC-d flows are below their GBR, they are ranked by decreasing
priorities (or SPI). For each GBR MAC-d flow, MAC-hs scheduler evaluates total radio
capacity and how much of the total radio capacity it shall allocate to this flow to
guarantee its GBR. These evaluations are smoothed by OMC-B parameters
hsdpaGbrNbUePerTtiForgettingFactor and
hsdpaGbrNbNeededTtiForgettingFactor respectively.
For a given priority, if the radio capacity - according to above evaluation - is enough to
satisfy all GBR flows then the flows are ranked by decreasing deficit (difference
between actual throughput and GBR). If the radio capacity is not enough then the
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
flows are ranked by increasing deficit in order to guarantee the GBR of most flows
(moreover, GBR flows for which it is absolutely not possible to guarantee their GBR
even by allocating them all resources are put at the end of the list of GBR flows).
Parameters:
Parameter hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi Object HsdpaConf
Range & Unit [1..16][1..11] List of Decimal
User Customer Granularity BTSCell
Class 3
Value [8, .., 8] (default value)
4.3.2 [xCEM]
The two xCEM schedulers manage the QoS differently:
- With proportionalThroughput: a relative weight is applied on each SPI
via hsdpaSpiRelativeWeight (same parameter as with iCEM) so that
the throughputs of the different non GBR MAC-d flows, when they are
experiencing the same radio conditions, are proportional to their
respective SPI weights. For GBR flows measured throughput R is
compared with the following threshold per SPI and then appropriate
user ranking is applied as per section 4.2.2, which includes the use of
serviceBFactor again defined per SPI
serviceMinRate = MAC-hs GBR - serviceLowRate
- With CRmax: for a given SPI, priority of the queue is increased (or
decreases) by multiplying the cost function by a Scheduling Weight
(SW) if the MAC-d throughput R is lower (or higher) than the
parameter serviceMinRate (or serviceMaxRate). The parameters
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 22/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
serviceBFactor and serviceKFactor are shaping factors for
increasing and decreasing the priorities:
the larger the values for serviceBFactor and serviceKFactor
the more the priority is decreased or increased, if the
measured average throughput R falls below serviceMinRate
or exceeds serviceMaxRate.
if serviceBFactor is set to one serviceMinRate and
serviceMaxRate are not taken into account. In this case the
priority of a user is neither decreased nor increased.
SW(u,q) = serviceBFactor ω
Where the term w depends on whether the measured MAC-d throughput R is lower or
higher than serviceMinRate:
If R ≥ serviceMinRate:
R − serviceMinRate
serviceKFactor
⎛ ⎞
ω =⎜ ⎟
⎝ serviceMaxRate − serviceMinRate ⎠
If R < serviceMinRate:
serviceMinRate − R
1 / serviceKFactor
⎛ ⎞
ω = −⎜ ⎟
⎝ serviceMaxRate − serviceMinRate ⎠
For GBR MAC-d flows, with CRmax algorithm, serviceMinRate and serviceMaxRate
are not taken from OMC-B but fixed by MAC-hs according to MAC-hs GBR (NBAP)
with margins coming from OMC-B:
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
B = 7, K = 7 B = 5, K = 7 B = 3, K = 7 B = 1, K = 7
5
Priority
0
20 30 40 50 60 70 80
Data Rate [kbps]
1000
100
Scheduling Weight (log)
10 B=7
B=5
B=3
1 B=1
0 10 20 30 40 50 60 70 80
0,1
0,01
Data Rate (kbps)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
B = 7, K = 7 B = 7, K = 5 B = 7, K = 3 B = 7, K = 1
5
Priority
0
20 30 40 50 60 70 80
Data Rate [kbps]
1000
100
Scheduling Weight (log)
10 K=7
K=5
K=3
1 K=1
0 10 20 30 40 50 60 70 80
0,1
0,01
Data Rate (kbps)
When the throughput of a user is lower than the serviceMinRate (Rmin), its priority is
increased.
When the throughput of a user is higher than the serviceMaxRate (Rmax), its priority
is decreased.
Note that when the serviceBFactor is set to 1, the Scheduling Weight is equal to 1,
meaning that all the users have the same priority (no QoS).
Contrary to the PropTh (xCem) or PropFair (iCem) schedulers, Crmax scheduler can
apply different Scheduling Weight even if all the spi have the same value. If only one
SPI is defined, all the users will use the same value for serviceMinRate,
serviceMaxRate, serviceKFactor, serviceBFactor but the SW will depend on the
current throughput.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The throughput of each MAC-d flow (R as described previously) is monitored
permanently and is averaged using an exponential average whose forgetting factor is
determined by:
Parameters:
The parameters used by the schedulers are the following ones:
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter serviceHighRate Object HsdschServiceParameterSet
Range & Unit [0…10000] decimal kb/s
User Customer Granularity BTSCell
Class 3
Value 80 for PS Streaming and 300 for PS I/B
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
UA5.1-UA6.0 : schedulingPriorityLevel
In UA5.1, only 6 HsdschServiceParameterSet have been defined. So, the mapping between SPI and
HsdschServiceParameterSet was done thanks to the parameter schedulingPriorityLevel (in
HsdschServiceParameterSet).
In UA6.0, 16 HsdschServiceParameterSet have been defined (one per SPI). So, the parameter
schedulingPriorityLevel does not exist in UA6.0 since it is not useful anymore
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
[UCU III]
Engineering Recommendation:
UCU III : supports QOS differentiation only on 7 different priorities. In deployments with UCU III, the RNC
mapping of QOS to SPI will use a more restricted set of SPI. HSDPA Service Parameter Set Instances for
these 7 different priorities are 1-7 : Table HS-DSCH Service Parameter Sets Instances:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
ServiceMaxRate = 300 configured at
[kbps] OMC
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 11
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300 Parameter set
[kbps] for scheduling
ServiceLowRate = 0 priority 11.
HsdschServiceParameterSet HSDSCHServiceParameterSet5
[kbps] Can be
ServiceHighRate = 10 configured at
[kbps] OMC
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300 Parameter set
[kbps] for scheduling
ServiceLowRate = 0 priority 10.
HsdschServiceParameterSet HSDSCHServiceParameterSet6
[kbps] Can be
ServiceHighRate = 10 configured at
[kbps] OMC
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
Parameter set
[kbps]
for scheduling
ServiceLowRate = 0
HsdschServiceParameterSet HSDSCHServiceParameterSet7 priority 9. Can
[kbps]
be configured
ServiceHighRate = 10
at OMC
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
ServiceMinRate = 0
HsdschServiceParameterSet HSDSCHServiceParameterSetUc [kbps] Parameter set
for scheduling
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
ServiceMaxDelay = 0 configured at
[ms] OMC
ServiceBFactor = 1
ServiceKFactor = 1
ServiceMinRate = 126
[kbps]
ServiceMaxRate = 130 Parameter set
[kbps] for scheduling
ServiceMaxDelay = 0 priority 10.
HsdschServiceParameterSet HSDSCHServiceParameterSetFt
[ms] Can not be
configured at
ServiceBFactor = 5 OMC
ServiceKFactor = 13
Note : Scheduling modes ‘Fair Throughput’ and ‘Unconstrained’ also service parameters sets are
introduced, which are read only in the OMC-U reflecting the parameters hard coded in the UCU III .
4.4.1 [iCEM]
UE categories also add some bias in the way virtual buffer are filled, described above.
The impact depends on the value of the OMC-B parameter
hsdpaUeCategoryThroughputWeighting. It defines the way balance is performed
between different categories when one of them is limited by the transport block size.
Indeed, above CQI 15 for instance, the transport block size of a UE cat 12 remains
constant while for other categories (e.g. 6 or 10) their transport block size still
increases with the CQI.
Two behaviours are then defined according to the value of the parameter:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
When hsdpaUeCategoryThroughputWeighting equals ueCategoryProportionality,
the TBS(CQI) is the mapping table CQIÆTBS of the category of the UE. When it
equals ueCategoryEquity, the same table is used for all UE categories (i.e. the one of
category 12).
It must be noted that this parameter is only applicable when SPI management is
activated. Hence, it is disabled in case of all hsdpaSpiRelativeWeights [SPI] are
equal to 100.
4.4.2 [xCEM]
xCEM scheduler is also able to balance throughput between different UE categories
when one of them is limited by the transport block size. The end result is similar to that
of iCEM (see section 4.4.1 for more details), with new parameter name:
In case of UCU-III this behaviour is set by default through a NodeB tunable to provide
similar result to ueCategoryEquity setting in xCEM
4.5.1 [iCEM]
Every TTI, the scheduler is launched in order to efficiently assign the available
resources (number of codes and remaining power) to the different users.
The first step consists in managing the retransmissions. The NACKed blocks are
scheduled first, in a FIFO order when possible (in case the UE capabilities prevent
from receiving data in the corresponding TTI, it is not retransmitted in that TTI). Then,
once retransmissions are handled, the remaining number of codes and power are
computed and constitute the input of the next step.
When there is no more retransmission to send, the scheduler selects the suitable QId
(according the cost function) for a user transmitting packet for the first time. This
selection is repeated as long as some resources remain (codes, power and CPU) and
if data can be scheduled for the corresponding TTI.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
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 doesn’t 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 doesn’t remain enough codes to transmit the HS-PDSCH, the
configuration is changed (transport block size reduced, corresponding to a
smaller CQI) to use the remaining codes. The power is then updated
accordingly.
4.5.2 [xCEM]
Before selecting the UEs to be scheduled in the TTI, the scheduler computes the
transmit power of the HS-SCCH for each user in the ranking list. It will remove from
the list all the UEs which cannot be scheduled because their HS-SCCH transmit
power is higher than the available power.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
5 TFRC MANAGEMENT
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
Decrease in the prohibitedStatusTimer leads to increase in the uplink Status traffic. The interest of
the 656 bits configuration is to allow reaching very high throughputs (6 Mbps and more) with moderate
uplink Status traffic.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 33/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
In order to have high DL throughput, UL acknowledgements have to be sent very quickly. That’s 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
- 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 suffices all cases.
The feature “29799 MAC-d PDU size Management for HSDPA” consists in choosing
the MAC-d PDU size according to several parameters:
- eligibleUeCategoryForHighPerformance to define the UE categories eligible for
656 bits.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 35/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
- minimumUserMbrForHighPerformance to configure 656 bits if MBR (RANAP
Maximum BitRate) value is above this parameter.
- isHsdpaCellHighPerformance to restrict primary cell to 336 bits.
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.
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter isHsdpaCellHighPerformance Object FDDCell
Range & Unit Boolean {True; False}
User Customer Granularity Cell
Class 3
Value True
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
False
isDynamicMacdPduSizeManagementAllowed 336 bits is used on RNC
True
0
eligibleUeCategoryForHighPerformance 336 bits is used for Cat.n
1
> MBR
minimumUserMbrForHighPerformance 336 bits is used for this ue
< MBR False
336 bits is used at RB setup
isHsdpaCellHighPerformance
for this cell
True
656bits is used at RB setup
for this cell
0 PDU size reconf. is not allowed
isHighPerformancePduSizeReconfAllowed
(except in some special cases)
1
PDU size reconf. is allowed sduRetransmitAfterPduSizeChange
Figure 5: Parameters to configure the feature “MAC-d PDU size 656 bits”
MAC-d PDU selection: The MAC-d PDU size is chosen when an HS-DSCH MAC-d
flow is setup that is to say at RAB establishment or reconfiguration of the RB to HS-
DSCH. In UA05.1 (or in UA6.0 with reconfiguration disabled), if a second HS-DSCH
Mac-d flow is setup then it will use the same MAC-d PDU size than the first one (even
if its MBR would have lead to use a different size). In UA6.0 with reconfiguration
enabled, a second HS-DSCH Mac-d flow can use a Mac-d PDU size different from the
1st one.
Mobility over Iur: The cell of DRNC is considered as 336 bits capable. In case of
mobility over Iur (HS-DSCH cell change towards a DRNS), the MAC-d PDU size of the
HS-DSCH MAC-d flow is not reconfigured if the reconfiguration is disabled
(isHighPerformancePduSizeReconfAllowed = False) : if the call was using the 336 bits
(or 656 bits), it will continue to use 336 bits (or 656 bits) after the mobility over Iur.
If the DRNS does not support the 656 bits configuration it will refuse the mobility of a
656 bits MAC-d flow thus leading to a DCH fallback of the RB by the SRNC (“HSxPA
to DCH fallback” feature has to be enabled).
If the reconfiguration is enabled (isHighPerformancePduSizeReconfAllowed =
True), the MAC-d PDU size can be reconfigured if necessary (e.g. MAC-d PDU size of
the new cell is different from the current MAC-d PDU size). When the SRNC has to
setup an HS-DSCH MAC-d flow over Iur, it configures it using 336 bits. For more
information on mobility over Iur, see [Vol. 6].
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 38/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
MAC-d PDU size reconfiguration: MAC-d PDU size reconfiguration may also happen
during transport channel type switching that is to say during HSDPA-R99 mobility or
AO transition. One exception is when this channel switching is due to a RAB
establishment (like a CS RAB or a second PS RAB where a first PS RAB was on
Cell_FACH due to inactivity). In this case, the configuration use for the PS RAB on
HS-DSCH is 336 bits. When reconfiguration is triggered, SDU can be managed in
different ways according to the parameters sduRetransmitAfterPduSizeChange (in
RadioAccessService / RlcConfClass / DlRlcAckMode). This parameter 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.
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 39/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
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 doesn’t transition to
URA_PCH i.e. DCH -> FACH->DCH doesn’t invoke the bug.
Following diagram shows all the conditions (in red) that need to be satisfied for the
PM79164 workaround to be invoked.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 40/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 41/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Mac-hs SDU
RLC SDU Mac-d SDU = Mac-d PDU
These new tables are activated via the following class 3 OMC-B parameters:
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):
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 42/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
MAC-d HS- UE
Default Optimised Max capability PDU PDSCH category
codes
1 377 365 1 QPSK 1 +4 dB 1 – 12
2 377 365 1 QPSK 1 +3 dB 1 – 12
3 377 365 1 QPSK 1 +2 dB 1 – 12
4 377 365 1 QPSK 1 +1 dB 1 – 12
5 377 365 1 QPSK 1 0dB 1 – 12
6 377 365 1 QPSK 1 -1 dB 1 – 12
7 377 365 1 QPSK 2 -2 dB 1 – 12
8 792 699 2 QPSK 2 0dB 1 – 12
9 792 699 2 QPSK 2 -1 dB 1 – 12
10 1262 1036 3 QPSK 3 0dB 1 – 12
11 1483 1380 4 QPSK 3 0dB 1 – 12
12 1742 1711 5 QPSK 3 0dB 1 – 12
13 2279 2046 6 QPSK 4 0dB 1 – 12
14 2583 2404 7 QPSK 4 0dB 1 – 12
15 3319 3090 9 QPSK 5 0dB 1 – 12
16 - 30 3440 3440 10 QPSK 5 16 - CQI 11 – 12
16 3565 3440 10 16-QAM 5 0dB 1 – 10
17 4189 4115 12 16-QAM 5 0dB 1 – 10
18 4664 4420 13 16-QAM 5 0dB 1 – 10
19 5287 5101 15 16-QAM 5 0dB 1 – 10
20 5887 5782 17 16-QAM 5 0dB 1 – 10
21 6554 6438 19 16-QAM 5 0dB 1 – 10
22 7168 7168 21 16-QAM 5 0dB 1 – 10
23 - 30 7168 7168 21 16-QAM 5 22 - CQI 1–6
23 9719 9546 28 16-QAM 7 0dB 7 – 10
24 11418 11216 33 16-QAM 8 0dB 7 – 10
25 14411 14155 42 16-QAM 10 0dB 7 – 10
26 - 30 14411 14155 42 16-QAM 10 25 - CQI 7–8
26 17237 17237 51 16-QAM 12 0dB 9 – 10
27 - 30 17237 17237 51 16-QAM 12 26 - CQI 9
27 - 30 20251 60 16-QAM 15 27 - CQI 9
27 - 30 21754 21754 64 16-QAM 15 27 - CQI 10
Table 1: CQI mapping table for 336 bits MAC-d PDU size
Page 43/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
5 792 686 1 QPSK 2 +3dB 1 - 12
6 792 686 1 QPSK 2 +2dB 1 - 12
7 792 686 1 QPSK 2 +1dB 1 - 12
8 792 686 1 QPSK 2 0dB 1 - 12
9 792 686 1 QPSK 2 -1dB 1 - 12
10 792 686 1 QPSK 3 -2dB 1 - 12
11 1483 1356 2 QPSK 3 0dB 1 - 12
12 1742 1356 2 QPSK 3 -1dB 1 - 12
13 2279 2010 3 QPSK 4 0dB 1 - 12
14 2279 4 QPSK 4 -1dB 1 - 12
14 2677 4 QPSK 4 0dB 1 - 12
15 3319 3319 5 QPSK 5 0dB 1 - 12
16 3319 3319 5 QPSK 5 -1dB 1 - 12
17 - 30 3319 3319 5 QPSK 5 15 - CQI 11 - 12
17 4189 3970 6 16-QAM 5 0dB 1 - 10
18 4664 4664 7 16-QAM 5 0dB 1 - 10
19 5287 5287 8 16-QAM 5 0dB 1 - 10
20 5287 5287 8 16-QAM 5 -1dB 1 - 10
21 6554 5993 9 16-QAM 5 0dB 1 - 10
22 7168 6673 10 16-QAM 5 0dB 1 - 10
23 - 30 7168 6673 10 16-QAM 5 22 - CQI 1-6
23 - 30 7298 11 16-QAM 5 23 - CQI 1-6
23 9719 9210 14 16-QAM 7 0dB 7 - 10
24 11418 11216 17 16-QAM 8 0dB 7 - 10
25 14411 13904 21 16-QAM 10 0dB 7 - 10
26 - 30 14411 13904 21 16-QAM 10 25 - CQI 7-8
26 17237 17237 26 16-QAM 12 0dB 9 - 10
27 - 30 17237 17237 26 16-QAM 12 26 - CQI 9
27 - 30 20251 30 16-QAM 15 27 - CQI 9
27 - 30 21754 21754 33 16-QAM 15 27 - CQI 10
Table 2: CQI mapping table for 656 bits MAC-d PDU size
Note that with MAC-d PDU size = 656 bits, the minimum number of HS-PDSCH codes
that can be managed is 2 if the feature Flexible Modulation (see section 5.4) is
disabled. If Flexible Modulation is enabled, even 1 HS-PDSCH code can be managed
with a MAC-d PDU of 656 bits.
[iCEM] [xCEM]
Based on Figure 7: Padding bits in the MAC-hs PDU, the throughput can be computed
at different levels from the TBS and the Mac-d pdu size:
Th_MAC-hs = TBS / TTI
Nb_of_MAC-d_pdu = floor[(TBS – 21)/MacdPduSize]
Th_MAC-d = Nb_of_MAC-d_pdu * MacdPduSize
Th_rlc = Nb_of_MAC-d_pdu * (MacdPduSize-16)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 44/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
For iCEM:
Some UE categories are limited to a maximum TBS (see [Vol. 2]). So, above a certain
CQI, TBS do not increase anymore but power is reduced by 1dB per CQI. Moreover,
for a given CQI, TBS can have different values:
- Default values corresponding to values used in UA4.2.
- Optimized values used when the Transport Block Size Optimization feature is
enabled in order to decrease the padding bits.
- Max capability values used when ueCategoryX (in
HsdpaMaxUeCategoryCapabilityActivation) is set to True in order to increase
maximum throughput for a given UE category
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:
Maximum Maximum number
UE MAC-d PDU hsdschInterval
Transport of
category size max (ms)
Block Size MAC-d PDU
336 42 90
7–8 14411
656 21 190
336 60 60
9 20251
656 30 130
336 64 60
10 21754
656 33 120
Table 3: Max hsdschInterval value
A value too high for hsdschInterval parameter will lead to reduce throughput.
For iCEM, the recommendation for hsdschInterval is 50ms.
For xCEM:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 45/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The hsdschInterval is hardcoded. The MAC-hs flow control algorithm calculates the
maximal number of MAC-d PDUs that can be transmitted by the RNC within a HS-
DSCH interval of 80 ms. These credits are sent to the RNC in the message HS-DSCH
CAPACITY ALLOCATION. The maximal credit that can be allocated to the RNC is
2047 MAC-d PDUs. A HS-DSCH CAPACITY ALLOCATION message is sent to the
RNC:
- when a HS-DSCH CAPACITY REQUEST was received from the RNC in the
Node B
- or when the MAC-hs flow control algorithm determines at the end of the HS-
DSCH interval the necessity (at most each 80ms). The HS-DSCH interval is
80 ms and an infinite repetition period is used, allowing to not resend a
CAPACITY ALLOCATION each 80ms if it is not needed.
As described above, if the MCS selected corresponds to a Transport Block Size that
exceeds what the UE can support according to its category then a lower MCS is
selected and the power requirements are lowered by -1dB/CQI. This is described in
the table below:
1 to 6 7298 22 7168 21
7 to 8 14411 25 14155 42
9 20251 27 20251 60
11 to 12 3630 16 3440 10
MAC-d PDU size = 656 bits
UE Maximum HS-DSCH Maximum TBS applied from Max MAC-d
category TBS per TTI MCS maximum MCS PDUs
1 to 6 7298 23 7298 11
7 to 8 14411 25 13904 21
20251 (iCEM)
9 20251 27 30
19891 (xCEM)
27 (iCEM) 21754 (iCEM) 33 (iCEM)
10 27952
30 (xCEM) 26490 (xCEM) 40 (xCEM)
5
11 to 12 3630 15 3319
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 46/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
10, 16 and
27952 30 26504 N/A
22
Restriction
The maximum RLC throughput with UE category may be limited (limit around 4-4.5 Mb/s) due to the
RLC window size limitation.
Against RLC window size limitation, prohibitedStatusTimer parameter can be decreased (from 70ms
to 30ms) or PDU size can be increased (from 336 bits to 656 bits) in order to reach higher throughput.
Decrease the prohibitedStatusTimer leads to increase the uplink Status traffic (impact has to be
study especially in multi-UE scenario).
The following tables give the HSDPA throughput at ATM layer and the Iub bandwidth
per E1 in case of Fixed RLC:
Table 5: Necessary throughput per HSDPA UE category (assuming Maximum TBS per TTI)
E1 1 E1 2 E1 3 E1 4 E1 5 E1 6 E1 7 E1 8 E1
(Kbps) (Kbps) (Kbps) (Kbps) (Kbps) (Kbps) (Kbps) (Kbps)
Page 47/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
In UA6.0, the scheduler can only use the QPSK and the 16QAM modulation.
In UA7.0, with the introduction of the xCem feature 34386 “64 QAM for HSDPA”, the scheduler is able
to use the 64QAM modulation in order to reach higher throughput
[iCEM]
Previously to UA6.0, there was no flexibility between modulation and number of HS-
PDSCH codes (QPSK used with 1, 2, 3, 4 and 5 HS-PDSCH and 16QAM used with
equal to or more than 5 codes). TFRC is selected according to the mapping tables
given in 5.3. In UA6.0, the feature 34102 “HSDPA Flexible Modulation” has been
implemented for iCem in order to be able to use QPSK or 16QAM whatever the
number of HS-PDSCH codes, and then to optimize the cell throughput.
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 48/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
(power may be increased in order to take into account the fact that 16-QAM
modulation is less efficient) and hence increase the throughput.
Implementation is based on different mapping tables according to the number of
remaining HS-PDSCH codes (1, 2, 3 or 4), to the UE category (only if the number of
remaining codes is higher or equal to 5) and the MAC-d PDU size. Based on these
inputs TFRC will be selected to maximize the throughput.
Mapping
- Number of remaining codes tables - Modulation = 16QAM
- ue category - TBS
- mac-d PDU size - Power offset
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).
Mapping
- Number of remaining codes tables - Modulation = QPSK
- mac-d PDU size - TBS
- ue category
Note that the code boost is not applicable for Cat.1-6 and 12 (max nb of codes = 5)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 49/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Activation
Note that when the Flexible modulation is enabled, the two following flags are ignored
(see 5.3 for more details on these flags):
• hsdpaUeCategoryTransportBlockOptimization
• hsdpaMaxUeCategoryCapabilityActivation
5.4.2.1 DESCRIPTION
From UA7.x, the xCem/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 to increase the HSDPA throughput in two cases:
- Case without code limitation: 64QAM allows higher peak throughputs in very
good radio conditions (21.6 Mbps on the physical layer in the DL instead of
14.4 Mbps with 16QAM)
- Case with code limitation: 64QAM can also be used in code limited situations
to increase the data rate for users in good radio conditions.
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)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 50/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
- Category 19 and 20 (64-QAM and MIMO capable)
Since MIMO is not supported in UA7.1.2, 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.
These new CQI mapping tables (defined in [R02]) are used to translate the CQI values
into a recommended maximum TB size and a modulation scheme (allowing the
64QAM capable UE to propose the usage of TFRC including 64QAM). With a high
CQI value (good channel quality) the UE can indicate that 64QAM can be used.
The maximum Transport Block Sizes allow thanks to mac-ehs and 64QAM are given
in Table 4.
New Look Up Tables
New LUT are used to allow scheduler selecting the higher TB size for 64QAM
modulation format.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 51/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The current HS-SCCH format allows only to select 2 types of modulation: QPSK and
16QAM. That is why the HS-SCCH format is modified in order to be able to select 3
types of modulation: QPSK, 16QAM and 64QAM: If 64-QAM has been configured for
the HS-DSCH, the modulation scheme information bit can only tell the UE whether
QPSK is used (value 0) or not (value 1). The choice between 16-QAM or 64-QAM is
known from the last bit of channelization code set information (see Vol.2 for more
information concerning the HS-SCCH format).
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 SF Bits/ HS-DSCH Bits/ Ndata
Rate (kbps) Rate (ksps) subframe Slot
0(QPSK) 480 240 16 960 320 320
1(16QAM) 960 240 16 1920 640 640
2(64QAM) 1440 240 16 2880 960 960
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 52/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
physical layer category IE, corresponding to the HS-DSCH category
supported by the UE when MAC-ehs is not configured)
- The NodeB is allowed to used the 64QAM:
RadioAccessService.isDl64QamOnRncAllowed = True
FDDCell.isDl64QamAllowed = True
Mac-ehs enabled
- The UE category is allowed to 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), a reconfiguration disabling 64QAM is triggered and vice
versa. On iCEM UE category 13 and above are handled as category 10.
Mobility of a 64-QAM capable UE between two 64-QAM capable serving cell is
supported.
64 QAM is not supported over Iur (as MAC-ehs). ALU SRNC will reconfigure the call
to MAC-hs when the serving cell moves under the control of a DRNC. ALU DRNC will
not advertive MAC-ehs and 64-QAM support over the Iur. If a SRNC decides to use
MAC-ehs and/or 64-QAM over the Iur, ALU DRNC will refuse the configuration.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 53/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter is64QamAllowedForUeCategory Object HsdpaRncConf
Range & Unit BitString – 64 bits (0=not allowed, 1=allowed)
User Customer Granularity RNC
Class 3B
Value 0000000000000000000000000000000000000000110011110011000000000000
1 for all the UE categories supporting 64QAM, that is to say
13,14,17,18,19,20,23 and 24
Note that the following parameters are not used in this release:
RemoteFDDCell.isDl64QamAllowed
NeighbouringRNC.isIurDlQam64Allowed
NeighbouringRNC.isIncoming3Gto3GWithIur64QAMAllowed
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 54/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The maximum throughput by using 64QAM modulation is reached when the maximum number of HS-
PDSCH codes are available (max throughput obtained with 15 HS-PDSCH).
The maximum number of HS-PDSCH codes can be obtained when the Fair Sharing feature is enabled
(up to 15 HS-PDSCH) but depends also on the codes configuration (number of S-CCPCH, number of
HS-SCCH, number of E-HICH/ERGCH, number of E-AGCH).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 55/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The following pre-requisites are needed to reach the maximum throughput with 64QAM:
3- Hybrid Iub or Native IP Iub (xCcm In order to achieve high throughput, ATM BW (8 E1s) is not sufficient and
Hardware on NodeB and GIGe on RNC Hybrid Iub is recommended.
needed)
3- RNC Packet server : DCPS or DCPS (Dual Core Packet Server) allows to support higher throughput than
Hardware PSFP PSFS in the RNC but nevertheless PSFP is enough (PSFP can support up to
2 R7 ue using 64QAM at the max throughput in 2 different BTS with the
same PMC-RAB (worst case))
4- Setting Maximum number of HS-PDSCH Fair Sharing enabled (Dyn codes mgt part):
codes (15) BTSEquipment / hsdpaCodeTreeManagementActivation = True
FDDCell / isHsxpaR99ResourcesSharingOnCellAllowed = True
4- Setting Avoid PA power saturation PA power saturation leads to a unstable CQI at 30 impacting the throughput.
A "backoff power" of -2dB is yet implemented to avoid this issue by reducing
the allocated power.
If needed, maxHspaPowerOffset can also be changed to reduce the
available power (PmaxHsdpa = Phsdpa = Pcell - maxHspaPowerOffset)
4- Setting UL bearer allowing: HSUPA with 10ms TTI (2ms TTI is not mandatory)
- throughput high enough to or UL 384 (if rab adaptation is disabled) with minSirTargetHsdpa = 4.7dB
acknownledge the high DL
throughput
- UL RLC BLER around 0%
4- Setting Correct Iub congestion If not correctly set, the throughput can fluctuate very strongly and we couldn’t
management setting get more than 2 or 3Mbps max (some time less than 1M)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 56/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
5- RF High CQI Throughput becomes higher for Cat.14 compared to Cat.10 when CQI > 23
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 User Equipment and PC In order to avoid any DL throughput limitation
client configuration
7- Core Correct VPN and Firewall In order to avoid any DL throughput limitation
configuration
7- Core No Maximum Bit Rate (MBR) Ranap MBR higher than the max throughput and Iu Source Conformance
limitation disabled (If Source Conformance is On, the RNC will limit the HSDPA
throughput to min(MBR;maximumTokenGenerationRate))
3- 3GPP R7 UE
Hardware
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 57/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
5.5.1 OVERVIEW
UA7.1.2 feature ‘Dual Cell HSDPA operation’ (HSDPA-DC) introduces 3GPP Rel’8
HS+ functionality whereby R8 capable UE is able to achieve twice the throughput as
compared to Rel’7 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 needs fewer system modifications than Rel’7 features:
• New UE categories
• New ACK/NACK & CQI mapping for the HS-DPCCH
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
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 58/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
“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 Rel’8)
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 59/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Also in UA7.1.2, only single PS I/B RAB mapped to HSDPA/HSUPA is eligible for
HSDPA-DC call else any multi-RAB or multi-service call will be setup as legacy
HSDPA call.
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
These parameters activate / deactivate the support of HSDPA Dual Cell operation at
cell level
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 60/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter dualCellActivation Object HsdpaConf
Range & Unit True, False
User Customer Granularity BTSCell
Class 0
Value 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 not supported in UA7.1.2 it is recommended to keep this parameter set to DC
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
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
• 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 61/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
Supported Hardware
NodeB radio configurations
iTRM / MCPA xTRM / MCPA TRDU CPRI RRH
STSR2 or STSR3 or STSRx+y
where pair of cells supporting
Dual Cell operation follow same
Tx paths Yes with 2 iTRM Yes Yes Yes
A pair of MCPA A pair of TRDU
STSR1+1 or STSRx+y where supporting DC- supporting DC- A pair of CPRI RRH
pair of cells supporting Dual HSDPA share the Yes with same HSDPA share the supporting DC-HSDPA
Cell operation does not follow same APN Alcatel power MCPA same APN Alcatel share the same APN
same Tx paths Part Number (*) Part Number (**) Alcatel 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.
(**) Not supported in UA07.1.2. Carriers operating in DC mode have to be transmitted
by the same RRH or TRDU.
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
There will be 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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 62/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Even though both schedulers are independent and use separate HARQ entities,
Alcatel-Lucent recommends configuring same scheduler type
(HsdpaSchedulerAlgorithmXcem) between the two cells
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 63/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The following pre-requisites are needed to reach the maximum throughput with HSDPA-DC:
1- Feature UTRAN Licensing Feature 113511 activated to enable 39.6Mbps HSDPA capability in xCEM else
configured to allow max xCEM will limit the overall throughput to 28.8Mbps
throughput
3- Hybrid Iub or Native IP Iub In order to achieve high throughput, Hybrid/ Native IP Iub is recommended with
Hardware (xCCm on NodeB and GIGe MDA-GE interface on xCCM. Nevertheless, ATM (iCCM) are also supported
on RNC needed)
3- RNC Packet server : DCPS DCPS (Dual Core Packet Server) allows to support higher throughput
Hardware
4- Setting Maximum number of HS- Fair Sharing enabled (Dyn codes mgt part):
PDSCH 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 UL bearer allowing: HSUPA with 10ms or 2msec TTI is the only supported RAB in UL
- throughput high enough to
acknownledge the high DL
throughput
- UL RLC BLER around 0%
4- Setting Correct Iub congestion If not correctly set, the throughput can fluctuate very strongly.
management setting
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 64/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
7- Core Correct FTP server If the FTP server has a limited configuration and could not be changed, high
configuration throughput could be achieved by establishing 4 (or more) FTP sessions in parallel
7- Core Correct VPN and Firewall In order to avoid any DL throughput limitation
configuration
7- Core No Maximum Bit Rate Ranap MBR higher than the max throughput and Iu Source Conformance disabled
(MBR) limitation (If Source Conformance is On, the RNC will limit the HSDPA throughput to
min(MBR;maximumTokenGenerationRate))
hsdpaMaxThroughputXcem can be set to its maximum value 39600 Kbps (feature 113511) for
mono-user Dual Cell demonstration. However in a Live Network it is recommended to limit the
maximum throughput per board with the following values :
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 65/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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, as defined by the IP protocol). It permits to use big PDU sizes, thus avoiding
RLC blocking situations. It also permits to avoid adding padding to the data to fit the
PDU size.
Alcatel-Lucent SRNC will always segment the SDU to this maximum PDU size. It will
build a PDU smaller than this maximum size only if the SDU (or the last segment of
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 66/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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 re-
establishment of the downlink.
In case reconfiguration from HS-DSCH/MAC-hs or DCH to HS-DSCH/MAC-ehs, the
RB can be reconfigured to RLC flexible mode, without need for RLC re-establishment
(because Alcatel-Lucent SRNC uses LI=7 bits for both fixed and flexible modes).
However, if LI=15 bits is used for flexible mode (by modifying
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 reversely.
As the PDU size is variable, the polling method based on the number of PDU sent
becomes meaningless. It is superseded by a new method based on a number of bytes
sent (fresh data or retransmitted data). This is controlled by the parameter
nbrOfBytesBetweenPolling in DlRlcAckFlexibleMode.
IF
isLiForFlexibleRlcActivated = True (recommended)
THEN
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.
ELSE
RNC RLC does not support LI and 7Bit is used to configure the UE RLC LI only (consistent
with UA 7.0 behavior).
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 67/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
MAC-d PDU
(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
MAC-d PDU
= Mac-ehsSDU
MAC-d PDU 1 MAC-d PDU 2 MAC-d PDU 3
MAC-ehs
PDU Mac-ehs Mac-ehs
Reordering SDU 1 Reordering SDU 2 …
header 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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 68/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Selection criteria:
The selection of Mac-ehs is done on a per call basis.
MAC-ehs (known also as flexible MAC-d PDU size format on NBAP/RNSAP) is
selected if the following conditions are fulfilled:
• The UA7.0 feature ‘34388 Layer 2 Enhancements : flexible RLC and Mac-ehs’
is active (isMacehsAllowed at RNC level is TRUE)
• UE supports MAC-ehs (as per UE capabilities)
• Node B handling the serving cell support MAC-d PDU flexible size format (as
per Node B capability given in NBAP HS-DSCH MAC-d PDU Size Capability
IE), ie. HSDPA is handled by [xCEM] or [UCU-III]
• The serving cell is controlled by SRNC (i.e., not by a drift RNC)
• isMacehsAllowed at FDDCell level is TRUE for the serving cell (and for all –
unlocked- HSDPA cells of the same carrier of the same Node B)
In this case, MAC-ehs is used and all radio-bearers are mapped on MAC-ehs
reordering queues. The selection of the RLC mode (fixed or flexible) is done on a per
radio bearer basis.
If the RB is mapped on HS-DSCH and if MAC-ehs/flexible MAC-d PDU size format is
selected for the call, the SRNC will use RLC flexible size for this RB in the following
cases:
• RAB is PS I/B. The used maximum PDU size will be the one specified by the
parameter macehsMaximumPduSizePsIb in HsdpaRncConf.
• RAB is PS Streaming and parameter isRlcFlexibleSizeForPsStrAllowed in
HsdpaRncConf is TRUE. The used maximum PDU size will be the one
specified by parameter macehsMaximumPduSizePsStr in HsdpaRncConf.
Parameters:
The feature Layer 2 Enhancements (Flexible RLC and Mac-ehs) is activated as
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 69/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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
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.
The maximum MAC-d PDU size for a PS Streaming Radio Bearer, is configured with
parameter macehsMaximumPduSizePsStr
Engineering Recommendation: maximum MAC-d PDU size when RLC operates in flexible mode
Although the configurable maximum MAC-d PDU size may be up to 1504 bytes, it is recommended to
configure it to 378 bytes, in order to cope with PS ciphering constraints (when MAC-d PDU size gets
bigger than 378 bytes, the efficiency of the ciphering degrades). However with introduction of HSDPA-
DC feature next higher value of 506 bytes is required to approach peak throughput.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 70/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
In UA6, the DL RLC queue size for the HSDPA RB was specified through the parameter
dlRlcQueueSize in DlRbSetConf/PS_HSDSCH_xxx. To cope with the limited range of this parameter
[1..128], the value was internally doubled by the software. The recommended value was 128, giving an
effective value of 256.
In UA7, the DL RLC queue size for the HSDPA RB is specified, for each UE category, through the
parameter dlRlcQueueSizeForUeCat in HsdpaRncConf. This parameter has a larger range [1..2048].
The recommended value is 256 except for the high rate capable UEs (categories 13, 14, 17, 18, 19,
21, 21 to 24) for which the recommended value is 512.
Note: the parameter dlRlcQueueSize in DlRbSetConf remains applicable for all RB other than HSDPA
RB.
Page 71/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter maxIubHsDschFrameSize Object HsdpaRncConf
Range & Unit [1..1520] ; unit : bytes
User Customer Granularity RNC
Class 3
Value 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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 72/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
Page 73/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
• The slow start is extended to the Idle-to-Burst case (in addition to the
Congestion Recovery case), when new data arrive from the Core Network
after an idle period. The definition of the “idle period” is defined as a static
parameter in the RNC and is provisioned to be 20ms.
• The unused credits are redistributed on top of the nominal rate (they were lost
in UA6.0).
The objects in the RAN model used to configure the Rb Congestion Control are shown
in the figure below.
RNC
Radio Access
Service
RbCongestionControl
HsDschSlowStart dchSlowStart
HsDschSlowStart
HsDschSlowStart
HsDschSlowStart
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 74/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The parameter dchSlowStartActivation activates the congestion control for DCH RB.
Four HsDschSlowStart instances are created by default, they store the slow start
parameters for four scenarios: respectively ‘Fixed RLC – Recovery from Burst,
‘Flexible RLC – Recovery from Burst, ‘Fixed RLC – Recovery from Congestion,
‘Flexible RLC – Recovery from Congestion’.
The parameter hsdschSlowStartPeriod gives the slow start period for HS-DSCH
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 75/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdschSlowStartRate Object HsDschSlowStart
Range & Unit List of up to 10 values in the range [0%..100%], step 10, unit %
User Customer Granularity HsDschSlowStart
Class 3
Value 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 76/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
HS-DPCCH demodulation
and CQI decoding
CQIreported
CQIprocessed
Figure 13: CQI Processing
Two algorithms have been introduced to handle bad UE behaviors that would disrupt
the system. Note that in the nominal case, these algorithms should not have any
impact.
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 77/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
• 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.
The main principle is the computation and use of a 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.
- 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”.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 78/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
“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
cqiThHigh
cqiThLow
hsdpaCqiBlerAdjustmentAlgo CQI 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Cat.12
dynamicOuterLoopAlgo Cat.1-6
Cat.7-10
outerLoopLikeAlgo Cat.x Bler Target = hsdpaBlerTargetUpperLimit
blerRangeBasedAlgo Cat.x Bler Target < 30% (in practice around 10%)
highBlerTarget = hsdpaBlerTargetUpperLimit
mediumBlerTarget = hsdpaBlerTargetMediumLimit
lowBlerTarget = hsdpaBlerTargetLowerLimit
Figure 14 : BLER Target according to the CQI and the UE category for the different BLER
Ajustement algorithm
Page 79/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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).
Parameters:
Parameter hsdpaCqiBlerAdjustmentAlgo Object HSDPAConf
Range & Unit [deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo,
dynamicOuterLoopAlgo]
User Customer Granularity BTSCell
Class 3
Value dynamicOuterLoopAlgo
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 80/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdpaAdjustBlerToChannelVariation Object HSDPAConf
Range & Unit [TRUE, FALSE]
User Customer Granularity BTSCell
Class 3
Value FALSE
BLER Target algo (dynamicOuterLoopAlgo) bring gain in most cases because the setting (BLER
target value) varies depending upon several factors: UE category, CQI distribution and UE speed (if
hsdpaAdjustBlerToChannelVariation flag is set to true).
That is why UA6.0 algo (dynamicOuterLoopAlgo) is recommended because its performance matches
the indoor and outdoor RF environments.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 81/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdpaBlerStepSize Object HSDPAConf
Range & Unit [0.1..1.0] step:0.1
User Customer Granularity BTSCell
Class 3
Value 0.1
[xCEM]
With xCEM, constBlerTarget algorithm has been implemented to control the MAC-hs
BLER.
Note that the MAC-hs bler estimation is still based on ack/nack information reported
on HS-DPCCH.
With constBlerTarget algorithm, MAC-hs BLER is managed as with iCEM
outerLoopLikeAlgo algorithm, except that the offset δ(ack,nack) is applied on SNR of
one HS-PDSCH instead of directly on CQI. This calculated SNR is then mapped to a
spectral efficiency and used for TFRC selection. However unlike iCEM, xCEM loosely
targets the constant BLER or packet error rate for first transmission and may allow it to
deviate from the target to optimize throughput.
The first transmission target value for the packet error rate impacts the observed data
rate significantly. If the target error rate is set to very small value, the scheduler only
selects small transport block sizes. This results in a low throughput. On the other side
if the target value is set to a large value, larger transport block sizes are selected. In
this case it may happen that the packet is still not received correctly in the UE after all
HARQ retransmissions. Then RLC retransmissions are required, which also leads to a
reduced throughput.
Following equivalent parameters have been defined for xCEM as:
Restriction: dynamicHarqTxTarget
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 82/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdpaBlerTargetUpperLimitXcem Object HsdpaConf
Range & Unit [1…99] %
User Customer Granularity BTSCell
Class 3
Value 15
[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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 83/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter HSDPA_SINR_max_factor Object None
(tunable
parameter)
Range & Unit [-200,…,330] & each step is equal to 0.1 dB
User - Granularity NodeB
Class 0
Value 20 (meaning 2dB)
Note that these four parameters are internal NodeB tunable parameters (can not be
modified through OAM)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 84/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
Page 85/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
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
RxDemodulation value demodulation for high
enhancement detection
speed UE
2 ON OFF OFF
1 OFF ON OFF
7 OFF OFF ON
5 OFF ON ON
6 ON OFF ON
0 ON ON OFF
4 ON ON ON
When coming back into the HSD_IN_SYNC state, scheduler cost function must be
reinitialized (both costs set to respective lower cost of active QIDs).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 86/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
7 OVSF CODES
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 87/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The following figures illustrate the different S-CCPCH Channel configurations
described above:
Figure 17: R99, HSDPA & HSUPA Common Channels codes allocation
Page 88/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
- 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.
Fair Sharing is enabled
- When change in the HS-PDSCH code usage occurs, the NodeB will
(DCTM has to be
reconfigure the CE module in order to take into account the new
disabled):
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.
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.
OR
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 89/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
threshCodesToTriggerStealing * SF8/SFMonitoring ≥1
AND Nb of free SF8 codes == 0 (Cond.2)
As SFMonitoring can not be lower than SF16, the second condtion (Cond.2) allows
checking the availability of one SF8.
When the pre-emption condition is encountered, the RNC steals some HS-PDSCH
codes in order to have numCodesForDchAfterStealing free OVSF codes.
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.
The re-allocation of HS-PDSCH codes is triggered when the number of free OVSF
codes is strictly higher than threshCodesToTriggerReallocation.
When the re-allocation condition is encountered, the RNC re-allocate some HS-
PDSCH codes in order to have numCodesForDchAfterReallocation free OVSF
codes.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 90/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Number of free OVSF codes after re-allocation:
#FreeOvsfCodesSfx ≥ numCodesForDchAfterReallocation (Cond.5)
OR
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.
If #FreeOvsfCodesSfx No
< threshCodesToTriggerStealing
Yes
If threshCodesToTriggerStealing * SF8/SFMonitoring ≥1 No
AND Nf of free SF8 codes == 0
Yes
If #FreeOvsfCodesSfx
> threshCodesToTriggerReallocation
Yes
Yes
Number of HS-PDSCH codes stolen is such as: Number of HS-PDSCH codes stolen is such as:
New Nb of free SF8 codes > 0 #FreeOvsfCodesSfx ≥ numCodesForDchAfterStealing
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 91/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
HS-PDSCH codes reallocation is triggered
Yes
Number of HS-PDSCH codes re-allocated is such as: Number of HS-PDSCH codes re-allocated is such as:
New Nb of free SF8 codes > 0 FreeOvsfCodesSfx ≥ numCodesForDchAfterReallocation
Restriction: HS-PDSCH codes re-allocation can be blocked by a R99 code even if re-allocation
is triggered
The HS-PDSCH codes have to be consecutive whatever the free OVSF codes. So, if a R99 code is
contiguous to the HS-PDSCH codes already reserved, new HS-PDSCH can not be re-allocated. This
scenario is illustrated by the following figure. HSDPA throughput impact should be low since it appears
in specific condition and can be reduce by setting appropriate value for the minimum codes for HS-
PDSCH.
SF128
SF256
SF16
SF32
SF64
SF4
SF8
0 Common channels
0
1 (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 Reallocation of a 5th HS-PDSCH
2 code is impossible because of the
10
5 R99 code even if the number of
11 free codes triggers the reallocation
12
6
13
3
14 HS-PDSCH (4 for ex)
7
15
Page 92/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The isHsPdschDynamicManagementAllowed parameter allows the activation of the
“Dynamic Code Tree Mgt” feature:
The following parameter is used in UA6.0 to activate the DCTM feature at FDDCell
level:
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 93/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter numberOfHsPdschCodes Object HsdpaCellClass
Range & Unit [1..15]
User Customer Granularity CellClass
Class 0
Value 5
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 94/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter minNumberOfHsPdschCodes Object HsPdschDynamicManagement
Range & Unit [0..15]
User Customer Granularity CellClass
Class 3
Value 1
This parameter allows to guarantee a minimum QoS for HSDPA and depends on the operator
strategy:
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
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 95/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 96/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
With typical parameters setting (monitoring line = SF16 and NaR = NaS = ThR = ThS = 2), the
maximum number of HS-PDSCH is 12 (1 SF16 for common channel, HS-SCCH and DL HSUPA
channels, 1 SF16 for SRBs and 2 free SF16).
For HSDPA KPI tests, the maximum number of HS-PDSCH codes can be increased by increasing
monitoring line SFx and by decreasing number of free SFx codes (in order to schedule several
HSDPA UE in the same TTI).
Higher number of HS-PDSCH codes can be reached with monitoring line equal to SF128 and 1 free
SF128 (1 SF16 for common channel including several HS-SCCH, 1 SF16 for SRBs including 1 free
SF128 and 14 SF16 for HS-PDSCH).
Note that configuration with monitoring line equal to SF256 and 1 free SF256 does not allow admitting
several HSDPA UE since HSDPA call is established with SRB13.6 (SF128). After RAB establishment,
SRB13.6 is reconfigured in SRB3.4 (SF256).
Increasing this parameter leads to decrease in the number of PSCR for reallocation but HSDPA
throughput may be degraded if some free SF16 are not reallocated because of this timer. That why his
value is 0.
Note: The number of free OVSF codes is re-evaluated for each R99 code release or
allocation except at timer expiry. When the timer
minTimeBeforeReallocationOfHsPdsch is expired, RNC will check automatically the
threshold compared to the number of free OVSF codes without waiting for a R99 code
release or reallocation.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 97/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
To avoid ping-pong:
numCodesForDchAfterReallocation >= threshCodesToTriggerStealing
numCodesForDchAfterStealing <= threshCodesToTriggerReallocation
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 98/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
OCNS code allocation is done before HSDPA configuration and it may lead to a conflict as HS-
PDSCH codes are always allocated from the bottom and need to be contiguous. To avoid any issue
with HS-PDSCH and the common channels codes, OCNS configuration has to be modified according
to the number of S-CCPCH codes:
Param identity
Default value Recommended value Range
(Customer Class 2)
8 with 1 S-CCPCH
OCNSChannelizationCodeNumber 7 10 with 2 S-CCPCH Integer [0…511]
12 with 3 S-CCPCH
Note that in UA6.0, the feature “OCNS for HSDPA” has been introduced for US market. See 9.3 for
more details.
In the previous releases, the HS-PDSCH codes configuration is managed by the RNC.
Indeed, the RNC sent to the NodeB through the PSCR message to configure (at cell
setup) or reconfigure (according to the R99 traffic if DCTM is ON) the HS-PDSCH
codes usuable by the scheduler.
In UA6.0 with Fair Sharing, the NodeB is able to know which HS-PDSCH codes can
be used for HSDPA traffic according the R99 traffic. For that, NodeB has a view in real
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 99/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
time of the R99 codes usage and then is able to compute which remaining codes can
be used for HS-PDSCH.
Fair Sharing feature consists in:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Among these free SF16 codes, the largest group of consecutive free SF16 codes will
be selected to allocate HS-PDSCH codes.
Note that Fair Sharing feature also introduces HSDPA CAC at RNC level. So, some
HS-PDSCH codes can be reserved for HSDPA users to guarantee a QoS depending
upon the GBR / minBR of the HSDPA RAB. These reserved codes change
dynamically with traffic (at each HSDPA RB allocation/release) and cannot be
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 100/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
ACTIVATION
The feature Fair Sharing and Dynamic Code Tree Management can not be activated
in the same time in a cell because they are incompatible. Before activating one, the
other has to be deactivated.
[iCEM] [xCEM]
[UCU III]
The same parameter activates the NodeB part of the feature but resides in different
objects depending upon the NodeB platform:
Note that the CCM must monitor the code occupancy all the time whatever the feature
activation.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 101/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.1 INTRODUCTION
The HSDPA principle is to allocate the power not used by DCH calls to HSDPA
channels. This implies an accurate power management in order not to impact DCH
calls and to allow the highest data rate on HSDPA channels.
When the cell is HSUPA capable, the new DL channels associated to E-DCH (E-
AGCH, E-HICH and E-RGCH) request some additional power.
For power computation, described below, this DL HSUPA power is considered as part
of DCH power. Note that the power consumption for DL HSUPA is low (few
percentage of total PA power).
For simplification, in the following paragraph, “DCH channels” refers only to DCH
channels when HSUPA is not activated and to DCH + DL HSUPA channels when
HSUPA is activated.
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)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 102/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
PMaxCell
SHO margin
Ptraffic
PmaxHsdpa
RNC
PminHsdpa
HSUPA
OCNS (opt.)
CCCRNC
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:
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:
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
Note: The activation of OCNS with HSDPA & Multiple S-CCPCH requires
modifications of OCNS default parameters. Refer to section 7.2 for more details.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 103/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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 minimum
power for HSDPA so 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: For the considered cell, common channels activity factor is used
in power reservation for common channels,
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 104/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter maxHspaPowerOffset Object HsdpaCellClass
Range & Unit Integer (dB)
[0 … 50] step 0.1
User Customer Granularity FDDCell
Class 3
Value 0
Before UA5.0, the maximum power that the RNC could allocate to HSxPA channels was defined and
SHO power was not taken into account anymore because power consumption in common channels
was over-estimated at RNC (due to activity factor at RNC level being hardcoded to 100%) especially if
several S-CCPCH channels were configured. Due to this, the probability to be HSDPA power limited
was high in multi-S-CCPCH scenarios. So, the UA5.0 formula was modified such that:
PmaxHspa = PMaxCell - PCCC * ActivityFactorCcch - POCNS
Typically, PmaxHspa was around 60% of PA power in UA4.2 whereas it is around 80% in UA5.0 thanks to
the activity factor on common channels being 66% instead of 100%.
From UA5.0, the maximum power is transmitted from the RNC to the NodeB in the
information element (IE) HS-PDSCH_HSSCCH_EAGCH_E-RGCH_and_E-
HICH_Total_Power through the PHYSICAL SHARED CHANNEL
RECONFIGURATION MESSAGE during the cell setup. If it is not present, HSDPA
can be allocated the whole power. The number of HS-PDSCH and HS-SCCH codes
reserved in the cell are also sent through this message, in the IE HS-
PDSCH_FDD_code_information and HS-SCCH_FDD_code_information respectively
(see the following figure).
HS-SCCH_FDD_code_information
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 105/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.2.1.2 NODEB LEVEL
[iCEM] [xCEM]
In a HSDPA cell, a new margin is introduced in order to anticipate power fluctuation on
DCH channel mainly due to power control and then avoid PA overload: DCH margin
(see the following figure). HSDPA channels can not use this margin. If the power for
DCH calls exceeds the DCH power margin then HSDPA will reduce its power to
provide DCH calls with power resource.
PMaxCell
PRemain
DCH margin
NodeB
E-DCH
DCH
PTotNonHsdpaWithMargin
OCNS (opt.) PTotNonHsdpa
CCCNodeB
Note that the common channel consumption at NodeB level is lower than at RNC level
due to activity factor consideration.
and
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 106/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The remaining power PRemain is the power usable by HSDPA:
and
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.
[iCEM] [xCEM]
Flexible power management feature consists in using for HSDPA all the remaining
power left by dedicated and common channels according to the RNC upper limit as:
[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).
[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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 107/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.2.2.1 TRANSMITTED CARRIER POWER
[iCEM] [xCEM]
The transmitted carrier power PTotCell (see the following figure) is the total cell power
consumed by all codes. This transmitted carrier power is measured and
communicated within the NodeB every 100ms through a Power Management
Message (PMM) ATM cell.
[iCEM] [xCEM]
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:
where PInstHSDPA corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor (Rho = 0.9775 hardcoded). PTotHSDPA should be
initialized with the instantaneous value.
PMaxCell PMaxCell
HSDPA PTotHsdpa
NodeB
NodeB
Power
Power
consumed by
consumed by PTotCell PTotCell
non HSDPA
all codes
codes
Figure 26: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)
Note that power consumed by non HSDPA codes includes, in this release, the
downlink HSUPA channels.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 108/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.2.2.3 TOTAL NON HSDPA POWER
[iCEM] [xCEM]
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:
This measurement is reported (see the following figure) from the NodeB to the RNC
through a COMMON MEASUREMENT message in the element information (IE)
Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-
AGCH, E-RGCH or E-HICH transmission defined as a percentage of the max cell
power. This measurement is used by the RNC CAC on DCH (only for HSxPA cells)
instead of Transmitted Carrier Power measurement (this latest continues to be
reported and is still used for non-HSDPA cells). The measurement period is 100ms
but the report periodicity (for these two measurements) toward RNC is typically much
higher.and is configurable via OMC.
COMMON MEASUREMENT
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 slightly
overestimate the R99 contribution and impact DCH call admission control. This effect can be
attenuated by increasing DCH admission threshold on power for HSUPA cells (see [R05] for details)
[iCEM] [xCEM]
The available power for HSDPA for the next 100ms period can then be computed. It
corresponds to the difference between the maximum available power in the cell
PMaxCell and the total non HSDPA power with DCH margin PTotNonHsdpaWithMargin. It is
bounded by PmaxHspa:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 109/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
with PTotNonHsdpaWithMargin = (1+ DchPowerMargin/100) * (PTotNonHsdpa - PCPICH) + PCPICH
PTotNonHsdpa
PHSDPA
A new common measurement is computed and periodically sent from NodeB to RNC
(as done for the Total Transmitted Carrier Power of all codes not used for HS-DSCH
and HS-SCCH). This measurement is the HS-DSCH Required Power. It corresponds
to the total power needed to ensure the GBR for corresponding flows of a given cell. A
value per SPI is reported and is expressed in thousandths of the max transmission
power. With PA power pooling enabled, the value for maxTxPower for HSDPA
dedicated carrier is increased by 1+paOverbookingRatio so hs-dsch required power
is reported with respect to this “overbooked max transmission power” value.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 110/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
hsdschReqPwReportingPeriod defines the reporting period for HS-DSCH Required
Power Common Measurement.
[xCEM]
The required transmit power for a GBR queue is approximately the average power per
payload bit multiplied by the number of bits guaranteed in the measurement interval.
While the guaranteed number of bits in the measurement interval can be determined
precisely, the average TX power per bit can only be approximated. It depends on the
channel conditions (CQI), on the quality of the HS-SCCH and HS-PDSCH power
estimation, on the scheduler strategy (many small MAC-hs PDUs or some large ones),
on the selected TBS (overhead of header bits and padding), on the number of
retransmissions. A good approximation might be the cumulated TX power of all HSD
transmissions done during the measurement interval divided by the cumulated number
of payload bits contained in those HSD transmissions.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 111/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
[UCU-III]
For this measurement, the MAC-hs scheduler shall maintain an additional cumulative
counter for the HSDPA transmit power used for GBR queues. This counter is
increased by the transmit power used for the HS-PDSCH and HS-SCCH channels,
whenever a MAC-hs PDU is transmitted which contains data from a GBR priority
queue. The existing counter for the total HSD transmit power is not changed, i.e. it
contains the HSDPA transmit power for non-GBR as well as for GBR queues.
The MAC-hs scheduler shall include in the measurement report of the HSDPA
transmitted carrier power both values, the total HSDPA transmit power as well as the
HSDPA transmit power used for just GBR queues.
There is a new OAM parameter introduced namely addGBRTransmitPower, in order
to select which of the 2 measurement value shall be reported to the RNC, the
“Transmitted carrier power of all non-HS channels” or the “Transmitted carrier power
of all non-HS channels and all GBR HS-channels”. Depending on the setting of this
OAM parameter, the measurement controller ignores the “GBR HSDPA Tx power” or
adds it to the value of the “Transmitted carrier power of all non-HS channels”.
Since UA6.0, RNC doesn’t 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 112/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The available power for HSDPA PHSDPA is shared between HS-SCCH and HS-DSCH
channels (see the following figure).
HS-DSCH
PHsdpa
HS-SCCH
NodeB
DCH margin
DCH
OCNS (opt.)
CCC
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 113/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
PHS-SCCH < PHSDPA
The power allocated to HS-SCCH is explained in section dedicated to the feature “HS-
SCCH power control”.
The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH transport
channel:
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:
Note that CQI computation by the UE is totally independent from the HS-DSCH
scheduling by the NodeB, since UE has no information concerning CQI processed and
algorithms used by the NodeB. That is why UE reports a CQI even if this UE is not
scheduled by the NodeB.
On the other hand, NodeB computes a modified CQI (noted CQIprocessed or AMC) to
ensure a transmission with a given BLER target (cf section 6.1) assuming a downlink
power equals to:
where
− PP-CPICH is the power of the P-CPICH channel,
− Γ is the measurement power offset
− Δ is the reference power offset given by the reference tables of CQI [R02].
The power PHS-DSCH is defined by a power offset compared to the P-CPICH power.
This power offset corresponds to the measurementPowerOffset parameter. The
mobile is able to compute this reference power thanks to the P-CPICH power
measurement and to the measurementPowerOffset parameter. The
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 114/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
measurementPowerOffset parameter is sent from the RNC to the NodeB through the
HS-DSCH FDD INFORMATION message during the Radio Link
Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HS-
PDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration
(see the following figure). In case this parameter is not present in the setup message,
the configuration must then be rejected.
HS-DSCH FDD
INFORMATION
during Radio Link
DOWNLINK HS-PDSCH Setup/Reconfiguration
INFORMATION
during Radio Bearer
Setup/Reconfiguration
measurementPowerOffset
Figure 31: measurementPowerOffset transmission
In fact, this power can be seen as the HS-DSCH power required by the mobile
corresponding to its reported CQI. From a NodeB point of view, this power is the
maximum power that can be allocated to one HSDPA user even if more power could
be used (Note that for CQI lower than 5 the allocated power may be higher … see the
column Power offset of Table 1 and Table 2).
Note that the reference power offset Δ is the one corresponding to the processed CQI
(CQIprocessed) and not the reported CQI (CQIreported). See “CQI” section for more details.
[iCEM]
The HS-DSCH power is equally distributed between all the physical channels HS-
PDSCH:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 115/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Where:
- PHSDPA is the power that is available for HSDPA
- PHS-SCCH(u) is the allocated power for HS-SCCH channel of user u
If more than one user to be scheduled for the next TTI, then NHS-PDSCH is equal to the
total number of HS-PDSCH codes (Ntotal). Else, NHS-PDSCH is the minimum between the
total number of HS-PDSCH codes and the UE capability (Nue capability) in other words,
the maximum number of HS-PDSCH that a UE of a given category can manage:
NHS-PDSCH = min(Ntotal; Nue capability)
For UCU III, Ntotal is the number of HS-PDSCH codes configured by the NodeB due to
Fairsharing being activated by default.
For xCEM
Ntotal is:
Ntotal = min(Nconfigured; SumNue capability)
Where:
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH PHS-DSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-PDSCH
HS-SCCH PHS-SCCH
Dch Margin
R99
CCC
Figure 32: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 116/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Note that a user can be scheduled only if its available HS-PDSCH power PavailableHS-
PDSCH(u) is positive, otherwise the next user of the ranking list shall be selected.
Before starting to schedule users, scheduler needs to know the total power it can use
for HSDPA according to R99 traffic usage. As with iCEM, total power usable by the
scheduler may be limited by the RNC (see PmaxHsdpa computation in section 8.2.1.1).
At nodeB level, with xCEM, a minimum percentage of power for HSDPA can be
defined through the parameter hsdpaMinAmpUsage. A percentage of the cell power
can also be taken into account to compute the remaining power (power not used by
non HSDPA channels) through hsdpaAmpUsage. Then, the total power usable for
HSDPA is:
PHSDPA total =
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)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 117/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Pmax
hsdpaAmpUsage.Pmax
PHSDPA
HSDPA
= hsdpaAmpUsage.Pmax – PTotNonHsdpaWithMargin
Dch Margin
R99 PTotNonHsdpaWithMargin
CCC
HSDPA power is allocated dynamically, that is to say that HSDPA will use all the
remaining power so that the amplifier capability can be fully exploited and more power
can be allocated to HSDPA if no R99 calls are active. However, this allocated power is
not reserved for HSDPA. The power control functionality of R99 in the Node B is not
aware what amount of power has been allocated to HSDPA. If not all the HSDPA
power is allocated or if no HSDPA users are active, this power can be utilized for R99
channels. On the other side, power being allocated to HSDPA channels does not limit
the R99 power. The inner loop R99 power control is unaffected.
The principle of dynamic power allocation is shown in the figure below.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 118/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Amplifier Capability
R99 Power
HSDPA Power
Overhead Power
The NodeB dynamic power allocation allocates the power to HSDPA until the amplifier
capability is reached. The OMC-B parameter hsdpaAmpUsage allows limiting the
overall power being consumed by common channel, R99 and HSDPA. Currently the
default value is set to 80% of the amplifier capability, i.e. to 32 watts for a 40 watts
amplifier.
Also the minimal power for HSDPA allocated by dynamic power allocation can be
controlled in the OMC-B by the parameter hsdpaMinAmpUsage. The default is
currently set to 10%, i.e. if R99 power consumption is high no power may be left to
HSDPA. Setting this value to a non-zero value (x > 0) allocates at least x% of the
amplifier power to HSDPA. This helps to avoid stalling of the HS-DSCH throughput if
the R99 load is large.
As the traffic load in downlink direction increases, the demanded power for HSDPA
and R99 may exceed the amplifier capability of the Node B. This can happen if the
R99 and the common channel power exceed the amplifier capability. In order to
maintain signal quality of existing calls and to prevent the amplifier from overheating,
the Node B applies Aggregate Overload Control (AOC). AOC acts on R99 and
HSDPA signals in the same way. P-CPICH is not affected by AOC scaling. With
dynamic power allocation, the occurrence of amplifier overload is not expected in
normal circumstances since the HSDPA power is adjusted according to the R99 load.
If the default value of hsdpaAmpUsage is increased, AOC as described below may be
activated to prevent the amplifier from overheating. Therefore it is not recommended
to increase the value beyond default of 80%.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 119/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdpaAmpUsage Object OneBTSEquipment
Range & Unit [0…100] %
User Customer Granularity OneBTSCell
Class 3
Value 80
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 120/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
UE selected
Power limitation
management
PHS-DSCH < Ptemp ?
N ΔRP = round(10.log(Ptemp / P’HS-DSCH))
CQI1 = CQIprocessed
Y N
CQI1 > 0 ?
ncodes = f(CQI1)
UE not scheduled
ΔRC = 0
nCodes < Y
Code limitation
nCodesRemain ?
management
CQI2 = CQI1
N
Select the highest CQI (CQI2) which number
of codes equals the remaining number of
codes
Other limitation
management
ΔRO = 0
N
CQI3 = CQI2
Select the highest CQI (CQI3)
fulfilling both criteria
UE scheduled
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 121/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
8.2.4.1.1 POWER LIMITATION
In case there doesn’t 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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 122/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Mac-hs transport block(CQI2)
Mac-d PDU
Mac-d PDU
Figure 36: MAC-hs transport block adaptation according to the number of MAC-d PDU to
transmit
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)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 123/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
For MAC-d PDU size of 656 bits:
• CQI 0: means that the mobile considers it is out of range. In such a case no
data for this specific user is scheduled by the MAC-hs
• CQI 1 to 7: in this case, the MAC-hs consider the mobile has reported a CQI
8. The scheduler relies on a power adjustment on HS-PDSCH and on the
HARQ repetitions to cope with low radio link quality (+1 dB per CQI value
rule).
• CQI 8, 11, 13 are processed normally.
• CQI 9, 10 (and resp. 12 or 14 or 20): in this case the MAC-hs considers the
mobile has reported a CQI 8 (resp. 11 or 13 or 19) to minimize padding. The
scheduler lowers the power requirement on HS-PDSCH (-1dB/CQI).
• CQI 15 to 30 (except 20): are processed as described in Table 2, decreasing
power requirements by 1 dB per CQI when the UE is addressed using a lower
MCS than the reported CQI (because of power shortage or because UE
capabilities are reached)
The above sections dealt with the situation where resource limitation can impact CQI
handling. However in UA5.0 and previous releases, implemented power management
may also lead to some unused power in NodeB in some situations (especially in mono
UE and high CQI situations).
The purpose of this UA6.0 feature is to improve the power management in NodeB
such that not to leave unused power in the situations where the remaining power can
be allocated to the UEs increasing their applied MCS.This feature only concerns iCEM
because the power management in xCEM is different and this behaviour is already
incorporated in its scheduler.
The scheduler first performs a preliminary scheduling, and resource allocation as in
UA5.0, serving priority queues (QID) up to their post BLER adjustment CQI, as shown
in Figure 35. This guarantees a minimum performance level on a par with UA5.0.
If there are any remaining resources (power, codes and CPU) left after the first
scheduling stage, a second resource allocation is carried. Remaining resources are
allocated first to the QID on top of the list of already scheduled QID in the TTI. If there
are remaining resources, these are allocated to next QID and so on. The reallocation
of resources is performed as following:
• 1 dB increase in power is associated to 1 CQI increase, up to the maximum MCS
of the UE (maxCQIcategory). We also do not increase the CQI if we are already
stuck at the maximum CQI.
• This process is iterated, until there are no more remaining resources to allocate to
QIDs, or nor more QIDs to serve.
• If the remaining power is less than 1 dB, it is allocated to the QID if it leads to
MCS increase.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 124/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsdpaFullPowerUsage Object HsdpaConf
Range & Unit Boolean {True, False}
User Customer Granularity BTSCell
Class 3
Value True
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:
“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.
Page 125/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
[xCEM]
As explained in [R05], the TFRC selection is done through a Look Up Table (LUT).
The MAC-hs scheduler uses a different LUT for first transmission and retransmissions
(and for MAC-d PDU size of 336 bits and 656 bits). In case of HARQ retransmission,
the transport block size is not changed from the initial transmission ([R05])
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 126/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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
HS-DSCH
NodeB HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Note: When several HSDPA users are scheduled in the same time interval and when
all the PA is used (due to R99 users or due to high measurementPowerOffset
value), HS-SCCH blocking may appear if HS-SCCH power allocated for one user is
not constant between two TTI (because HS-SCCH and HS-PDSCH are not aligned in
time (2-slots delay)). In this case, one of the users has not enough power for its HS-
SCCH and cannot be scheduled anymore. In order to avoid this issue, a power check
has been introduced since UA5.0 in order to be sure to have enough power for the
HS-SCCH.
HS-SCCH power control is not a true power control mechanism but rather a power
mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is
derived from the reported CQI (noted CQIreported), not from CQI adapted by the NodeB
in anyway, in order to adapt the transmission power to actual reported radio
conditions.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 127/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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 figure).
1 hsScchPcOffset(1)
2 hsScchPcOffset(2)
……….
30 hsScchPcOffset(30)
Disabling the power control consists in setting all hsScchPcOffset to the same value.
The following figure summarizes the HS-SCCH power control:
CQIReported hsScchPcOffset(CQIReported)
I
CQ
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 128/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
The hsScchPcOffset parameters depend on the CQI reported by the UE to the NodeB. However the
UE computes his CQI according to the measurementPowerOffset parameter which defines the
reference power. Then hsScchPcOffset parameters have to be linked to a
measurementPowerOffset value. If the measurementPowerOffset increases of 1dB, the
hsScchPcOffset table has to be shifted by 1 unit.
Here is a table summarizing hsScchPcOffset values according to measurementPowerOffset :
hsScchPcOffset
MPO = 5 dB MPO = 6 dB MPO = 7 dB MPO = 8 dB MPO = 9 dB
1 0 0 0 0 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 -3 0 0 0 0
8 -3 -3 0 0 0
9 -5 -3 -3 0 0
10 -5 -5 -3 -3 0
11 -5 -5 -5 -3 -3
12 -8 -5 -5 -5 -3
13 -8 -8 -5 -5 -5
14 -8 -8 -8 -5 -5
15 -8 -8 -8 -8 -5
CQI
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
Page 129/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsscchSnr Object HsdpaConf
Range & Unit [-5.0…19.0] dB (step .1)
User Customer Granularity BTSCell
Class 3
Value 1
Note that for the first implementation of the xCem, the recommendation for
hsscchSnr was 5dB in order to avoid a too low HS-SCCH power for high CQI since
no minimum power was defined. Today, a minimum power is defined for HS-SCCH
(see below), allowing to reduce the value of hsscchSnr.
With UCU III, the transmit power of HS-SCCH for each scheduled user is calculated
so that the SNR of the HS-SCCH at UE side shall be equal to hssccSnr.
The computation of the HS-SCCH power is based on the most recent 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).
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 130/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter hsScchPcOffset Object HsdpaConf
Range & Unit List[1..30]
[-28.0..28.0] dB
User Customer Granularity BTSCell
Class 3
Value 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -3.0 -3.0 -5.0 -5.0 -5.0 -8.0 -8.0 -8.0 -8.0 -
8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0
For each value of the list of hsScchPcOffset, the following relationship must be verified:
HsScchPcOffset + pCpichPower ≥ maxTxPower – 35 dB
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.
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.
If the minimum value of this parameter is used in order to reserve entire power for HSDPA (which is
not recommended), there will be a conflict between power allocated to common channels and power
reserved for HSDPA (see details about power reservation formula in chapter 8.2.1.1). Also, there will
be not enough power in the cell to setup an SRB. This will forbid any HSDPA call establishments.
In order to allow HSDPA calls, following formula has to be used to compute the minimum value for this
parameter:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 131/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter measurementPowerOffset Object HsdpaUserService
Range & Unit Integer (0.5 dB)
[-12..26]
User Customer Granularity HsdpaUserService[0..14]
Class 3
Value 15 (= 7.5dB)
measurementPowerOffset parameter defines the reference power used by the UE to compute its
CQI and the maximum power that the NodeB can allocated to one UE. The value 7.5 dB allows to
allocate up to about 60% of PA power (PA = 45dBm and Cpich power = 35dBm) for the HS-DSCH
channel. A lower value favours the scheduling of 2 UE per TTI by limiting the power per HSDPA user.
For first deployments, the probability to have 2 UE scheduled in the same TTI will be low. Then with
this value, the HSDPA user throughput is not limited by power.
It is recommend to avoid setting the measurementPowerOffset to a too high value to avoid power
limitation but high enough to optimize the HSDPA capacity, the following rule should be taken into
account:
0.8.PA > Log2lin(pcpichPower + measurementPowerOffset)
This rule allows to respect the following BTS check:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 132/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 133/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
bursts. Indeed, if a burst of application-level UL ACKs (e.g. TCP UL ACKs) is received
by the server, the server may transmit on downlink a large amount of data at the same
time. If this data transmitted on downlink excesses the core network bandwidth, DL
application-level packets are lost, which leads to application-level retransmissions.
Such application-level retransmissions may have an significant impact on DL
throughput and user experience.
Regarding the case of a call with HSDPA in the downlink and DCH in the uplink, it has
been observed that bursts of application-level UL ACKs occur when UL radio quality is
degraded (UL radio BLER higher than target BLER) even for a short period of time.
Indeed, if UL radio quality is degraded, UL RLC retransmissions occur. Since RNC
waits for retransmitted RLC-PDUs before transmitting data to the server (“In-
Sequence-Delivery” mechanism), such UL RLC retransmissions results in a burst of
application-level UL ACKs sent to the server.
Regarding the case of a call with HSDPA in the downlink and E-DCH in the uplink, it
has also been observed that bursts of application-level UL ACKs occur when UL radio
QoS is degraded (average 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.
Page 134/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
set of parameters for UL SIR Target initial value, lower bound and upper bound:
initialSirTargetHsdpa, minSirTargetHsdpa and maxSirTargetHsdpa. These
parameters can be set per UL service.
Note that the default set of parameters (i.e. when in DL R’99 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.
All
The Uplink Radio Bearer is EDCH (the Downlink is HSDPA) AND conditions
are TRUE
minSirTargetEdch2ms
The selected EDCH TTI is 2ms AND initialSirTargetEdch2ms
The HSUPA UE Category is 1 in ‘eligibleUeCategoryForSirTargetEdch2ms’ maxSirTargetEdch2ms
All
The Downlink Radio Bearer is HSDPA (the Uplink is R99 or HSUPA) AND conditions minSirTargetHsdpa
are TRUE
The HSDPA UE Category is1 in ‘eligibleUeCategoryForSirTargetHsdpa’ initialSirTargetHsdpa
maxSirTargetHsdpa
minSirTarget
initialSirTarget
maxSirTarget
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 135/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
• HSDPA UE Category is eligible for “Management of UL power profiles…” sub-
feature.
Eligible HSDPA UE Categories can be set via
eligibleUeCategoryForSirTargetHsdpa parameter.
The method for setting eligible HSDPA UE Categories is described in 8.5.3.
Parameter eligibleUeCategoryForSirTargetHsdpa
Object PowerConfClass
Granularity PowerConfClass
Range & Unit Bit string (64 bits), N/A
User & Class Customer, 3
Value 0000000000000000000000000000000000000000000000110011001111000000
This parameter defines the HSDPA UE Categories eligible for “Management of UL power profiles…”
sub-feature. Having defined bit #0 as the LSB (least significant bit) i.e. the bit at the right edge of the
bit string, bit #0 corresponds to Category 1 and bit #11 corresponds to Category 12.
Meaning of each bit (from bit #0 to bit #11) is as follows:
0: corresponding HSDPA UE Category is not eligible
1: corresponding HSDPA UE Category is eligible
It is recommended to activate HSDPA-specific UL power profiles for HSDPA UE Categories 7 to 10,
and for Release7 UE Cat 13, 14, 17, 18 Hence, bits #6 to #9, #12, #13, #16, #17 should be set to 1.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 136/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
initialSirTargetHsdpa: For HSDPA calls and if HSDPA UE Category is eligible for
“Management of UL power profiles…” sub-feature of UA6 34246, UL SIR Target used
for the initialization of UL OLPC algorithm.
Parameter initialSirTargetHsdpa
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
Range & Unit Signed [-8.2 … 17.3] step: 0.1, dB
User & Class Customer, 3
Value UlUsPowerConf instance initialSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K Greater than initialSirTarget in order to
PS_128K_IBxSRB_3_4K ensure high quality UL RAB when DL is
PS_384K_IBxSRB_3_4K mapped on HSDPA. Refer to [R01]
Other instances Refer to [R01]
Parameter minSirTargetHsdpa
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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 Greater than minSirTarget in order to
PS_128K_IBxSRB_3_4K ensure high quality UL RAB when DL is
PS_384K_IBxSRB_3_4K mapped on HSDPA. Refer to [R01]
Other instances Refer to [R01]
Parameter maxSirTargetHsdpa
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
Range & Unit Signed [-8.2 … 17.3] step: 0.1, dB
User & Class Customer, 3
Value For all UlUsPowerConf instances: Refer to [R01]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 137/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
9 OTHER FEATURES
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
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 138/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
• 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)
All these sub-features have already been described in the previous sections except
the last one:
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 139/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
- 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.
A R99 OCNS channel can co-exist along side a HSDPA OCNS channel.
Node B (particularly the HSDPA scheduler) is responsible to provide resources for the
virtual users simulated by HSDPA-OCNS channel. A software resides in the Node B
and is used when HSDPA-OCNS is switched on. This software generates virtual users
inside the HSDPA scheduler so that the scheduler algorithm can schedule the virtual
users together with the real ones, it will assign downlink resources to the virtual users
in the same way as it does for real users. Since the scheduler requires feedback (such
as CQI) from mobiles in order to decide the required resources per user, the software
could generate the required feedback per HSDPA-OCNS user and feed it back to the
scheduler if the feedback information (e.g. CQI) is not specified by the operator. Each
HSDPA-OCNS user will be then assigned certain resources and NodeB will transmit
data (also generated by the software) in the downlink. The software then has the
following main actions:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 140/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
2. Generate constant data to be transmitted every TTI (2ms) in the downlink by
the virtual HSDPA-OCNS users. The data pattern will be fixed for each
simulated user. It also depends upon the UE category, MAC-hs window size,
number of active Users in the cell, and other parameters, if the UE can be
scheduled in each TTI or not.
3. Simulate feedback from the terminal received in the uplink direction. The
feedback contains a CQI value, which can be fixed all the time the HSDPA-
OCNS is active or it can be randomly generated. If CQI factor specified via an
user interface in OMC is zero then the CQI should be randomly generated
following a uniform distribution, if CQI specified by an operator is not zero,
then a fixed CQI factor should be used all the time.
4. Scheduler will generate its own dummy values for ACK and NACK according
to ACK/NACK ratio defined in percentage by the user input.
5. Scheduler will receive UE capability number as part of input parameters just
like normal HSDPA user.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 141/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
Filter coefficient (for an IIR filter) and Mean CQI, will be used in this random CQI
generator and hence are only applicable when CQI = 0.
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI=0, then random value between
range 1 and 30 shall be used by the scheduler according to the generating function
defined below. The randomly generated CQI values have a mean value of “Mean
CQI”.
The generated CQI values are for 2 second duration. The generated CQI are re-used
for the subsequent 2 second intervals.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 142/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Start
Initialisation
Seed = 4096;
Input values for initial
parameters 'Mean' and 'filt_coef' count=0;
are set by higher layer. Mean=20
filt_coef=1;
a=(0.5)^(filt_coef/2);
X(count)=1;
No
if (count =Mean)
YES
if Y<1
Y=1; Restricting the final CQI value
elseif Y>30 between 1 and 30.
Value less than 1 should be
Y=30; truncated to 1 and value larger
else than 30 should clipped to 30.
Y=Y;
end
CQI = 31-Y;
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 143/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 144/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Note: The NodeB would determine the stop time for each channel based on the
channel activity time and the time it has received the HSDPA-OCNS channel setup
command.
Parameter Cell ID
Object HSDPAOCNS
Granularity FDDCell
Range & Unit Integer Type:
User & Class customer
Value User defined
Cell ID is a user input for HSDPA OCNS operation and is selected by the operator
from available cells from a user interface at OMC-R WIPS.
Parameter proprietaryHSDPAOCNSActivation
Object FDDCell
Granularity FDDCell
Range & Unit False / True
User & Class Customer & Class 3
Value False
proprietaryHSDPAOCNSActivation is used to turned HSDPA OCNS on or off.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 145/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
This mechanism is optional and can be activated at RNC level (applicable to HSxPA
Service).
9.4.2 ALGORITHM
This capability is based on a token bucket algorithm as specified in [R04].
This algorithm is used to verify that traffic packets submitted by the Core Network to a
UMTS bearer do not exceed the requested Max value. It uses the following two
parameters (r and b) for the traffic contract and one variable (TBC) for the internal
usage.
• r: token rate, (corresponds to the monitored Maximum bit rate).
• b: bucket size, (the upper bound of TBC, corresponds to bounded burst size).
• TBC (Token bucket counter): the number of remaining tokens at any time.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 146/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Each Time a packet of length Li arrives, the value of TBC is checked. If TBC is large
enough (b ≥ Li), meaning that the packet fits into the buffer, the traffic is considered as
conformant and the packet is accepted (as L1 and L2 in picture above), otherwise it is
deleted (as L3).
The value of TBC increases at a rate of “r” by time unit, and does not exceed “b”. The
RNC will actually updates TBC each time it receives a packet, by dT*r where dT is the
difference of time between the reception of the current packet and the previous
packet.
In the scope of HSxPA implementation, this algorithm is used to make sure users do
not exceed the original QoS contract.
Note : the bandwidth limit used in the algorithm is actually the RAB Maximum Bitrate,
bounded by a provisonable parameter MaximumTokenGenerationRate. This is useful
in case the Core Network has not be configured appropriately. The bucket size b is
equal to the provisionable parameter BucketBufferTime * MBR.
9.4.3 PARAMETERS
The following three parameters are used to activate and configure the Iu User traffic
Conformance Feature:
• sourceConformanceActivation is used to activate/inhibit the Iu conformance
algorithm for downlink HSxPA user data.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 147/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter sourceConformanceActivation Object DlSourceConformanceInformation
Range & Unit Enum
{Off, On}
User Customer Granularity RNC
Class 3
Value Default: Off
Recommended : On if the operator wants to limit UE throughput
Note: The default value corresponds to ~4Mbits/s. If the operator wants that none
user benefits of cat6 Qos (only Cat12) , it can be set to 1.4 M/s=175kbytes/s
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 148/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Parameter bucketBufferTime Object UlSourceConformanceInformation
Range & Unit Integer (ms)
[10..30000] step = 10
User Customer Granularity RNC
Class 3
Value 2000
When Sequence Number loss is detected, TCP layer slows down (reduces window )
so that sender throughput is decreased.
HSDPA subscribers will have access to the full UE Cat12 throughput when in HSDPA
cell. If the HSDPA subscriber goes into R99 area it has PS384K R99 channel.
Provisioning to be changed: The Downlink MaxBitRate in the HLR needs increased for
HSDPA subscribers to 1.4 Megs ( case cat12 and 3.4M if cat6 is allowed)
R99 subscribers keep their MaxBitRate to 384K in HLR . A R99 subscriber using a
HSDPA capable UE in a HSDPA cell will have a HSDPA channel being limited to
384K throughput ( value from Core RAB)
Objective of this feature is to increase the frequency of the PA occupancy for R99 and
other common channels.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 149/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 150/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
9.5.2.1 AVERAGED HSDPA POWER
The value of the filtering coefficient for calculation of exponentially average HSDPA
power used for all HS-PDSCH and HS-SCCH codes is based on a different smoothing
interval, based on new parameter hsdpaWindowsObserveTime.
While before the weighting factor was hardcoded to Rho = 0.9775, with the activation
of the feature, the value is calculated as follows:
The total power not used by HSDPA is computed by subtracting the total HSDPA
power from the total cell power. However, with the activation of this feature, the
reporting is no longer done every 100ms, but instead at a 10ms rate. This means that
another filtering process is used, for the PTotCell, using filtering coefficient Alpha:
The formula for Alpha is equivalent as the formula for Rho, with the difference that
SampleDuration = 10ms, which is the reporting rate interval from CCM to CEM.
The expression for calculation of PTotNonHsdpa does not change:
The calculation for the available power for HSDPA does not change, and is given by:
Page 151/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
parameters dchPowerMarginThresholdList and dchPowerMarginList (please see
definition in next section).
Even if the periodic reporting of PTotCell from CCM to CEM is reduced to 10ms, the
reporting from CEM to CCM module is still kept at 100ms. This means that the
periodic transmission between BBU and CEM CallP must be adapted, and requires a
new filtering process.
For the HSDPA cell, the non-HSDPA contribution over the previous 10ms interval is
calculated as follows:
where PTotHsdpaFiltered represents the filtered HSDPA power transmitted during the
previous 10ms, calculated using the following expression:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 152/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
- 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).
Parameter hsdpaWindowsObserveTime Object BTSEquipment
Range & Unit Decimal (ms)
[10..100] step:10
User Customer Granularity BTS
Class 3
Value Default: 100
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
dchPowerMargin = dchPowerMarginList [1]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 153/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Else if
dchPowerMarginThresholdList [2] <= NonHsdpaPowerRelativeToPmax <
dchPowerMarginThresholdList [1] then
dchPowerMargin = dchPowerMarginList [2]
Else if
dchPowerMarginThresholdList [3] <= NonHsdpaPowerRelativeToPmax <
dchPowerMarginThresholdList [2] then
dchPowerMargin = dchPowerMarginList [3]
Else if
dchPowerMarginThresholdList [4] <= NonHsdpaPowerRelativeToPmax <
dchPowerMarginThresholdList [3] then
dchPowerMargin = dchPowerMarginList [4]
Else if
NonHsdpaPowerRelativeToPmax < dchPowerMarginThresholdList [4] then
dchPowerMargin = dchPowerMarginList [5]
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 154/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
OLS for a user is determined based on the user profile configured in the HLR. The
parameters that determine the OLS level in the RNC are provided through the RAB
ASSIGNMENT REQUEST message as Traffic Class (TC), Traffic Handling Priority
(THP) and Allocation/Retention Priority (ARP). The RNC maps these parameters into
a single OLS level, based in the configuration.
The basic principle of the feature is that when there is enough HSDPA Interactive and
Background traffic on the Iub to cause full utilisation of the provisioned Iub bandwidth
(i.e. Iub congestion), the feature will ensure that users with different OLS levels
achieve different throughputs, with throughput rate ratios for different OLS levels
controlled based on configurable parameters. The feature is applicable for both ATM
and IP transport.
This feature deals with priority handling at transport layer. Additional information is
provided in [R07].
Page 155/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
To achieve full differentiation, both SPI (by Node B MAC-hs) and OLS differentiation (implemented
by this feature) must be activated.
qos 3 Bw
cfactor =
# G * gW * gA+ # S * sW * sA+ # B * bW * bA
Based on the calculation above and the parameter settings, the Iub budget for each
type of OLS user is determined, for the next 50ms:
• iubBudgetGold = cfactor * gW
• iubBudgetSilver = cfactor * sW
• iubBudgetBronze = cfactor * bW
Calculated Iub budgets per user are then passed to PMC-RAB for each HSDPA RAB,
evry 50ms. PMC-RAB must respect these Iub credits in addition to HSDPA credits
allocated by the Node B and must ensure that the total transmitted PDUs will not
exceed the Iub credits for the following 50ms.
By default, PM97431 is not active. In UA6.0 and UA7.1 releases, there is the
possibility of controlling the activation of the feature by means of a CDL/Inode
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 156/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
configuration, visible only internally on the RNC (i.e. not integrated into OAM WPS
model).
A new optional component OlsDifferentiation has been added under the RncInode
component. If the the optional component is not present, the feature is not active. If it
is present, the feature is active.
Under this optional object are included the configurable weights per OLS. Internally,
the following structure will be created:
RncIn
OlsDifferentiation
goldWeight
silverWeight
bronzeWeight
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 157/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Feature PM97431 was developed strictly assuming the condition that enhancedQualityOfService
attribute is disabled. PM97431 and functionality supported when enhancedQualityOfService =
enabled are mutually exclusive.
There is a provisioning check warning in case an operator tries to activate PM97431 when
enhancedQualityOfService = enabled and when tries to set enhancedQualityOfService = enabled
while PM97431 is active.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 158/159
HSxPA Parameters Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 3: HSDPA Principles, Scheduling & Resource Management
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 159/159
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
Alcatel-Lucent – Proprietary
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
CONTENTS
1 INTRODUCTION............................................................................................................................6 39H
4.1.2.1 PM33612 UL load estimation in presence of urban noise for multiple CEM............ 19 52H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
6.7 PRIORITY INFO IN MAC-E SCHEDULER .......................................................................................58 76H
9.1.1.3.3 Parameters defined for “PS_EDCH” and “SRB_EDCH” UL rBs .......................... 97 107H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
10.3 MOBILITY MANAGEMENT ...................................................................................................... 121 12H
11 PM34393 ADVANCED RECEIVER FOR HIGH UL DATA RATE ........................................... 124 124H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
TABLES
Table 1: UE categories
0H 30 128H
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table
3H 37 13H
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table 37
4H 132H
table 37 13H
Table 7: UCU-III/10 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset} table
6H
38 134H
Table 8: UCU-III/2 ms TTI/2XSF2 recommended {Reference E-TFCI; Reference Power Offset} table 38
7H 135H
Table 10: Primary Cell HSUPA Category according to Primary Cell E-DPDCH SF capability and
9H
Table 11: EdpchParameters instance according to Target HSUPA UE Category and selected E-DCH
10H
TTI 41 138H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
FIGURES
Figure 1: Noise Rise vs. UL Load .................................................................................................................... 12
15H 143H
Figure 4: {E-TFCI; Transport Block Size} tables for 10ms TTI, as defined in 3GPP TS 25.321 ............ 32
18H 146H
Figure 5: {E-TFCI; Transport Block Size} tables for 2ms TTI, as defined in 3GPP TS 25.321 .............. 32
19H 147H
Figure 13: Structure of the TNL Congestion Indication control frame. ....................................................... 65
27H 15H
Figure 14: Example of the GRF variation with the congestion status......................................................... 65
28H 156H
Figure 21: 34249 RAN model for E-DCH UL services and misc................................................................. 97
35H 163H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
1 INTRODUCTION
1.1 OBJECT
The objective of this volume (UA7 HPUG [Vol.4]) is to describe from an engineering
164H
Global USA
PM ID Feature Title Activation flag Release
Market Market
isEdchAllowed, edchActivation
E-DCH Step1 UA5.0 Yes Yes
29840 [iCEM] [xCEM]
(HSUPA)
edchResourceActivation
E-DCH DL control [iCEM] Feature not applicable.
channels Power
Control [xCEM] Activated by default.
33481 Remark: UA6 UA5.1 Yes Yes
version of the
feature also exists
(see below).
E-DPDCH isUlOuterPCActivated (for UL
Retransmissions services with E-DCH) UA5.1 Yes Yes
34172
for DPCCH SIR
Adaptation
[iCEM]
rotOrthogonalityEstimation
Self-interference in UA5.1 Yes No
34221
MAC-e Scheduler [xCEM] [UCU-III]
Feature not applicable.
[xCEM]
33327 MAC-e Scheduler edchSpiRelativeWeight
enhancements UA6.0 Yes No
[iCEM]
Feature not applicable.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
HSPA congestion No activation flag.
33367 detection & UA6.0 Yes No
notification
[iCEM] Feature not applicable.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
81112 UL load estimation [xCEM] UA6.0 Yes No
in presence of locFrequencyReuseFactor
urban noise
[iCEM]
Feature not applicable
34441 2ms TTI on isEdchTti2msAllowed UA7.1 No Yes
oneBTS
34633 E-DCH Mac-e [iCEM] UA7.1 Yes Yes
throughput of Feature not applicable
10Mbps
[xCEM] [UCU-III]
No activation flag
33612 UL load estimation [xCEM] UA7.1.2 Yes No
in presence of edchLoadEstimationAlgorithm
urban noise for
multiple CEM [iCEM]
Feature not applicable
34393 Advanced [xCEM] [UCU-III] UA7.1.2 Yes Yes
Receiver for High gRakeActivation
UL Data Rate (with
Doppler [iCEM]
measurements) Feature not applicable
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
3 E-DCH ACTIVATION
In order to activate E-DCH on a given cell, the following activation flags must all be set
to “True”.
[iCEM] [xCEM]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
[iCEM] [xCEM]
Note that without RSEPS activation (refer to next section ) the reference RTWP is not
transmitted to the RNC. Therefore the non E-DCH RTWP transmitted through NBAP
common message assumed a default value for the thermal noise: NBAP RTWPnon E-
DCH = -106.1 + RoTnon-EDCH
The parameter rtwpReference is the reference of RTWP when the BTS does not
receive any radio signal for this cell. If the parameter isRtwpReferenceSelfLearning
is set to TRUE, this parameter is only used to initiate the RTWP self learning feature.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The noise rise is expressed as:
Noise rise = RTWP/RTWPref
18
16
14
Noise Rise (dB)
12
10
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
UL load
The maximum allowable UL load should not be set too high. It should not be set to a
too low value in order not to impact the E-DCH capacity. A correct value is between
50% and 85% (i.e. 3 and 8 dB noise rise).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 12/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Available
UL load for
E-DCH
scheduling
CS64
RSSI
PS64
CS12.2
CS12.2
Thermal Noise
Figure 2: Example of uplink load (thermal noise/R99/E-DCH)
Two parameters are used to set the maximum allowed UL radio load:
rtwpMaxCellLoadNonEdch (under BTSCell object) and totalRotMax (under
FDDCell object).
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”.
4.1.1.1 TOTALROTMAX
[iCEM] [xCEM]
Parameter used to set the maximum allowed total UL radio load, for E-DCH
scheduling purpose. Basically, the MAC-e scheduler allocates grants so that the total
UL radio load remains below and close to totalRotMax. Note that totalRotMax value
is specified in terms of “UL noise rise” (also referred as “RoT” – Rise over Thermal
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
noise), so unit is dB. As a reminder, UL radio load and RoT are equivalent quantities
that are linked together by the formula given at the beginning of this section. For more
information on E-DCH scheduling mechanisms, please refer to section 6 (iCEM) and 168H
section 7 (xCEM).
169H
For iBTS, in case E-DCH is activated on R’99+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 R’99 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.
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:
1
rtwpMaxCellLoadNonEdch ≤ 1 − totalRotMax / 10
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).
[UCU-III]
In OneBTS this parameter is used to determine the maximum noise rise to ensure
uplink coverage. The maximum E-DCH target load for the cell is set internally in the
OneBTS to 85% by default. In case totalRotMax is exceeded due to interference, the
the MAC-e scheduler will reduce its target load for E-DCH in order to reduce the total
uplink cell load. Thus, it is recommended to set this parameter to 15 dB to make the
likelihood of E-DCH target load roll-back low and preserve the E-DCH capacity as
much as possible.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter totalRotMax Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit Decimal [0.0 ... 20.0] step 0.1, dB
User Customer Granularity Cell
Class 2 or 3
Value [iCEM] [xCEM]
R’99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
[UCU-III] 15
Note: Please refer to UPUG Vol.6 for further details regarding the two distinct
parameter classes utilisation.
Rule: totalRotMax
The maximum allowed total UL radio load in terms of UL noise rise (or RoT) should be set lower than
or equal to 8dB (which corresponds to an UL radio load of 84.2%).
totalRotMax ≤ 8 (for iBTS only -> not for OneBTS)
If above rule is not respected, there is a high probability to face system instability regarding UL noise
rise fluctuation, such as important and frequent peaks of UL noise rise (i.e. “UL RSSI” peaks).
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter referenceRtwp Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit [-112.0..-70.0] step:0.1, dBm
User Customer Granularity Cell
Class 2 or 3
Value -106.1
Please refer to UPUG Vol.6 (totalRotMax description) for further details regarding
these two distinguish parameter class utilisation.
When the RSEPS measurements are deactivated, this parameter indicates if the BTS
does a correction of the RTWP before reporting it to RNC in the NBAP COMMON
MEASUREMENT REPORT. If the parameter is set to TRUE, the correction is:
-106.1 + (Rtwp_measured - rtwpReferenceOrSelfLearned).
Example: isRtwpReferenceSelfLearned is set to TRUE. The selfLearned
rtwpReference is measured by the BTS to -105dBm. The BTS read a RTWP of -
100dBm --> The BTS will report: -106.1 + (-100 + 105) = -101.1 dBm (instead of -100)
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 (as described in the
upper section).
If we activate the RSEPS measurements, the RNC configures NBAP common
measurements to report periodically
• Total_RTWP
• Reference_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 E-DCH power.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The RNC is now able to compute the non E-DCH load for iRM UL load as follow:
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[UCU-III]
OneBTS does not support RSEPS, but only a special measurement of RTWP which is
derived from the non-EDCH load. This measurement is equivalent to RTWP provided
in UA5.1. Therefore, the RSEPS measurement is deactivated:
isNbapCommonMeasRsepsAllowed set to False.
This global formula can be represented in more detail by the portions of the several
contributors:
Lest, total = {Lest, s + Lest, ns + ∑C∈peer-serving Lest, ps, C + Lest, DCH + Lest, HS - DPCCH} x (1 + Loc)
Page 18/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The Loc value can be tuned and it is recommended to set it to the value of 20. The
following parameter is used for this purpose:
This feature is applicable only to Node B configurations (iBTS) where the whole traffic
of one carrier is handled by one and only one xCEM (absence of inter modem board
messaging in UA06 prevents usage of UL load estimation based on SIR values for
carriers having cells or UL contributors distributed over multiple modem boards).
With feature 81112 only one xCEM can support the frequency for which the feature is activated.
So, for any other supported configurations, e.g. iCEM and xCEM “mixity” this feature is
not applicable as it is not possible to guarantee that following a failure, no iCEM will be
allocated for the frequency for which this feature is activated.
Due to the absence of inter board messaging, it’s still not possible to apply this feature in a scenario
of iCEM/xCEM mixity
The feature PM33612 available for UA7.1.2 onwards, is essentially a copy of 81112,
with the main difference that now it will be possible to activate it when using multi
baseband board NodeB configurations. With 33612, multiple xCEM can now support
the frequency for which the feature is being activated.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
A new parameter will be then introduced: edchLoadEstimationAlgorithm. This
parameter will allow using the feature per RfCarrier and not per BTSCell as before.
This parameter will be responsible for choosing the UL load estimation algorithm
(RTWP based or SIR based).
[iCEM][UCU-III]
This feature is dedicated to iBTS xCEM only.
In case of high UL RSSI alarm activation, the threshold could be set to 10dB above
Noise level (i.e. 90% Ul load). A normal noise level value measured in the TRM should
be in the range [-107.5dBm, -104.5dBm] so the alarm threshold could be set to
-94.5dBm to cover all the range.
[UCU-III]
Feature dedicated to iBTS only
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
4.2.1 AT RNC
At RNC level, some power is reserved for E-DCH downlink channels in the same
manner as the RNC level power reservation performed for common control channels.
The aim of this power reservation at RNC level for E-DCH DL channels is to perform
CAC of DL DCH traffic, i.e. this power is not allowed to be used by DL DCH traffic at
CAC (as it is the case for the power reserved at RNC level for CCC channels).
In the following figure showing power allocation at RNC level, the power reserved for
E-DCH DL channels is represented in light blue (“E-DCH”).
PMaxCell
SHO margin
to be transmitted
PminHsdpa
to the NodeB
E-DCH
OCNS (opt.)
CCCRNC
The amount of power reserved for E-DCH DL channels at RNC level can be set via
eagchErgchEhichTotalPower parameter.
Parameter eagchErgchEhichTotalPower Object EdchCellClass
Range & Unit Decimal [0.0 … 50.0] step:0.1, dBm
User Customer Granularity EdchCellClass
Class 3
Value 10
4.2.2 AT NODEB
At the NodeB, power is allocated in priority to CCC channels, E-DCH DL channels and
DCH DL traffic. The remaining power is then allocated to HSDPA DL channels (i.e.
HS-SCCH and HS-DSCH).
Remark: At NodeB, there is no upper limit for E-DCH DL channels total Tx power.
maxEdchCommonChannelPower parameter under EdchConf, which was originally
created for this purpose, is ignored by the system.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
When the E-DCH serving NodeB sends an E-AGCH, E-RGCH or E-HICH command to
an E-DCH UE, the power allocated to E-AGCH or to the considered E-RGCH or E-
HICH signature is fixed for iCEM, and updated every 2ms (in order to match E-AGCH
and E-RGCH/E-HICH sub-frame length of 2ms) for xCEM and UCU-III. Regarding
non-serving NodeB, E-DCH DL channels power control is only possible for xCEM and
UCU-III, and only under certain conditions for xCEM. Please refer to section 9.2 for 170H
[iCEM]
On iCEM, E-DCH DL channels are not power controlled; their transmit power is fixed
and can be set via eagchPower, ehichPowerSignature and ergchPowerSignature
parameters. Note that on iCEM, E-RGCH is only used for the purpose of sending
“Down” RG commands to non-serving UEs when the ratio of UL noise rise generated
by non-serving radio links to total E-DCH UL noise rise exceeds
targetNonServingToTotalEDCHPowerRatio threshold. Please refer to [Vol.6], 17H
section 3.3.3 for more information on handling of non-serving radio links and more
generally on E-DCH Macro Diversity.
On iCEM, E-DCH DL channels are not power controlled; their transmit power is fixed and can be set
via eagchPower, ehichPowerSignature and ergchPowerSignature parameters.
eagchPower: Power offset for one E-AGCH channel, relative to the CPICH power.
Parameter eagchPower Object EdchConf
Range & Unit Signed [-35.0 … 15.0] step:0.1, dB
User Customer Granularity BTSCell
Class 3
Value -2.5
Remark: Only one mobile can be addressed per E-AGCH channel and per TTI.
Page 22/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
ergchPowerSignature: Power offset for one E-RGCH signature, relative to the
CPICH power.
Even if UA6 “E-DCH Macro Diversity” (32076) feature has not been activated yet,
ergchPowerSignature must be set greater than a certain value (which depends on PA maximum
power and CPICH Tx power) for NodeB internal power check to succeed.
According to NodeB internal power check rules described in [Vol.3] section 8.4, must be set so that
172H
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.
[xCEM] [UCU-III]
On xCEM and UCU-III, power control of E-AGCH, E-RGCH and E-HICH is supported
via “E-DCH DL control channels Power Control” (33481) feature. Note that this feature
was originally introduced for xCEM in UA5.1 but has been improved in UA6. Please
refer to section 9.2 for a detailed description of the mechanism and parameters
173H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
4.2.2.2 E-DCH DL CHANNELS CONFIGURATION
per cell.
Parameter maxNrOfEagch
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Integer [1 … 8], N/A
User & Class Customer, 0
Value 1
Remarks:
• [iCEM] On iCEM, up to 3 E-AGCH channels can be configured per cell. However,
since the maximum number of E-DCH radio links that can handle one E-BBU on
iCEM is 15, depending on the expected E-DCH traffic on the considered zone, it
may not be useful to send several E-AGCH commands at the same time, and on
the other hand saving DL code resource could benefit to DL traffic. Consequently,
for iCEM, if low E-DCH traffic is expected, it is recommended to set
maxNrOfEagch = 1.
37H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
In iBTS (for both iCEM and xCEM), up to 3 E-AGCH channels can be configured per cell.
However, maxNrOfEagch parameter can be set to a value up to 8.
If maxNrOfEagch is set to a value higher than 3, the iBTS returns an NBAP Physical Shared Channel
Reconfiguration (PSCR) Failure message to the RNC. In this case, the RNC then tries to configure the
shared channels on the considered cell, but without E-DCH service. In other words, in iBTS, setting
maxNrOfEagch to a value higher than 3 causes to loose E-DCH service on all the cells for which this
setting applies.
In iBTS (for both iCEM and xCEM), please follow the following rule for maxNrOfEagch:
maxNrOfEagch ≤ 3.
Parameter maxNrOfErgchEhich
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Integer [1 … 8], N/A
User & Class Customer, 0
Value [iCEM] 1
[xCEM] 1
[UCU-III] 1
Remarks:
• [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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
With the introduction of the feature UA7.0 34386 64 QAM for HSDPA (see
[Vol.3]), a large amount of DL codes are needed to reach high downlink rates
174H
[xCEM] [UCU-III]
to 128 E-DCH radio links (or 116) are supported per xCEM board, hence per cell
assuming there is no E-DCH radio link established on the other cells supported by the
same board). This means that setting maxNrOfErgchEhich = 4 actually enables up to
76 E-DCH radio links per cell.
For UCU-III, a maximum of 64 E-DCH radio links can be supported per cell from a
hardware point of view (up to 64 E-DCH radio links are supported per cell –regardless
to the number of UCU-III boards–, but a maximum of 3 x 64 = 192 E-DCH radio links
can be supported per NodeB with 3 UCU-III boards). This means that setting
maxNrOfErgchEhich = 4 actually enables up to 64 E-DCH radio links per cell.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
On iCEM, since the maximum number of E-DCH radio links that can handle one E-BBU is 15, one
E-RGCH/E-HICH channel per cell is sufficient. Consequently, for iCEM, in order to save DL code
resource, it is recommended to set maxNrOfErgchEhich = 1.
On xCEM, up to 4 E-RGCH/E-HICH channels (i.e. OVSF codes) can be configured per cell. For
xCEM, in order to maximize the possible number of simultaneous E-DCH users per cell, it is
possible to set maxNrOfErgchEhich = 4. However, it is recommended to set maxNrOfErgchEhich
to 1 to save DL code resource, hence favour UA7 HSDPA+ performances.
Configuration method:
If it is chosen to set different maxNrOfErgchEhich depending on the type of boards:
• Use two specific EdchCellClass instances (one for iCEM and one for xCEM).
• For the EdchCellClass instance related to each type of board (iCEM and xCEM), set
maxNrOfErgchEhich to above-specified value.
• Make each cell (FDDCell object) point toward the appropriate EdchCellClass instance,
according to the type of board that handles E-DCH traffic for this cell.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
From UA6, for iCEM, up to 3 E-RGCH/E-HICH channels can be configured per cell.
From UA6, for xCEM, up to 4 E-RGCH/E-HICH channels can be configured per cell.
However, maxNrOfErgchEhich parameter can be set to a value up to 8.
In iBTS (for both iCEM and xCEM), if maxNrOfErgchEhich is set to a value higher than 4, the
NodeB returns an NBAP PSCR Failure message to the RNC. In this case, the RNC then tries to
configure the shared channels on the considered cell, but without E-DCH service. In other words, in
iBTS, setting maxNrOfErgchEhich to a value higher than 4 for xCEM causes to loose E-DCH
service on all the cells for which this setting applies.
• As explained above, since the iCEM can handle 15 E-DCH radio links at maximum, it is useless
to configure more than one E-RGCH/E-HICH channel per cell.
• As long as maxNrOfErgchEhich is set to a value lower than or equal to 4, the NodeB does not
return an NBAP PSCR Failure message to the RNC, i.e. there is no risk of loosing E-DCH
service.
• If maxNrOfErgchEhich is set to a value lower than 4, the exact number of E-RGCH/E-HICH
channels (i.e. SF 128 OVSF codes) specified via maxNrOfErgchEhich parameter is
configured. If maxNrOfErgchEhich is set to 4, only 3 E-RGCH/E-HICH channels are
configured.
In iBTS (for both iCEM and xCEM), please follow the following rule for maxNrOfErgchEhich:
maxNrOfErgchEhich ≤ 4
Restriction: 9313 Micro NodeB & 9314 Pico NodeB support only 1 E-AGCH and 1 E-RGCH/E-
HICH
As a consequence, in the edchCellClass used to configure a Micro/Pico Nodeb cell, the parameters
maxNrOfEagch and maxNrOfErgchEhich must be set to 1.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
5.2 UE CATEGORIES
As the SF2 and 2msTTI are supported only by the xCEM, the UE categories 4, 5 and
6 are supported only by the xCEM in UA6 whereas the iCEM board keeps the same
capabilities as in UA5 (i.e UE CAT 4, 5 and 6 are not supported by iCEM). For UA7.1,
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
Maximum Throughput @
Maximum Maximum
Maximum RLC ATM layer
Terminal Minimum TTI MAC-e Date Rate at
Number Throughput (+30% protocol
Category SF [ms] PDU Size MAC-e layer
of Codes [Mbps] headers)
[Bits] [Mbps]
[Mbps]
Category 1 1 SF 4 10 7110 0.71 0.67 0.87
10/ 14484/ 1.45/ 1.38/ 1.79/
Category 2 2 SF 4
2 2798 1.40 1.28 1.66
Category 3 2 SF 4 10 14484 1.45 1.38 1.79
10/ 20000/ 2.00/ 1.89/ 2.45/
Category 4 2 SF 2
2 5772 2.89 2.72 3.53
Category 5 2 SF 2 10 20000 2.00 1.89 2.45
10/ 20000/ 2.00/ 1.89/ 2.45/
Category 6 4 SF 2
2 11484 5.74 5.44 7.07
Note: When 4 codes are transmitted in parallel, 2 codes shall be transmitted with SF2 and the other 2 with SF4
Table 1: UE categories
The RNC configures the ETFCI table according to UE category and cell capabilities
(i.e. TTI type).
Parameter prohibitedStatusTimer
Object UlRlcAckMode
Granularity RNC, RlcConfClass
Range & Unit Enum {10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170,
180, 190, 200, 210, 220, 230, 240, 250, 260, 270, 280, 290, 300, 310, 320, 330,
340, 350, 360, 370, 380, 390, 400, 410, 420, 430, 440, 450, 460, 470, 480, 490,
500, 510, 520, 530, 540, 550, 600, 650, 700, 750, 800, 850, 900, 950, 1000}
Ms
User & Class Customer, 3
Value For ”PS_HSDSCH_EDCH_IB_AM” and ”SRB_HSDSCH_EDCH_AMUM”
instances of RlcConfClass: 30
[UCU-III]
For the OneBTS UCU-III, for UA6 only 10ms TTI is supported and minimum SF equal
to 2SF2 in UA6 (i.e. cat 2, 4, and 6 on 2ms TTI are not supported). UCU-III supports
up to category 5, on 10 ms TTI only. It does not support category 6 (and it would be
managed like a category 4 on 10ms TTI).
For UA7.1, the OneBTS UCU-III supports both 2 and 10 ms TTI for UE categories 2, 4
and 6, and up to 4 codes, 2 SF2 and 2 SF4 E-DPDCH codes for category 6.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
TTI (i.e. “10ms TTI E-DCH TBS Table 0” and “10ms TTI E-DCH TBS Table 1”) and
two tables corresponding to 2ms TTI (i.e. “2ms TTI E-DCH TBS Table 0” and “2ms TTI
E-DCH TBS Table 1”). All four tables are available, i.e. for each E-DCH TTI type either
one of the two corresponding tables may be configured.
As shown below in Figure 4, Table 0 has an exponential increase and Table 1 has a
178H
linear increase. The choice of the {E-TFCI; Transport Block Size} table is linked with
the {Reference E-TFCI; Reference Power Offset} table, described in next section.
Regarding 10ms TTI, 128 E-TFCIs are defined for “10ms TTI E-DCH TBS Table 0”,
and 121 E-TFCIs are defined for “10ms TTI E-DCH TBS Table 1”. For iCEM, xCEM
and UCI-III, it is strongly recommended to use “10ms TTI E-DCH TBS Table 1”.
Regarding 2ms TTI, as shown in Figure 5, 128 E-TFCIs are defined for “2ms TTI E-
179H
DCH TBS Table 0”, and 126 E-TFCIs are defined for “2ms TTI E-DCH TBS Table 1”.
For the xCEM (for which 2ms TTI is available), it is strongly recommended to use
“2ms TTI E-DCH TBS Table 1”. ”. For UCU-III, (for which 2ms TTI is available in
UA7.1) the same recommendation applies.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
2.0E+04
1.8E+04
Transport block size (bits)
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
1.2E+04
1.0E+04
Transport block size (bits)
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The aim of this table has been described in section 5.3. For a given E-DCH call,18H
This table defines for each E-TFCI a corresponding Power Offset (i.e. value
indicating the power ratio E-DPDCH / UL DPCCH, also referred as “βed/βc”). For a
given E-DCH call, the same table is configured both at NodeB side and at UE
side.
• E-DCH MAC-d flow-specific power offset:
Power offset assigned to each MAC-d flow of the considered E-DCH call
(sometimes also referred as “Δharq”).
From UA6 onwards, up to two MAC-d flows –one for user data and one for UL
SRB– are supported on E-DCH for iBTS xCEM and OneBTS UCU-III. Each MAC-
d flow can be assigned a MAC-d flow-specific power offset. The offset is
configurable per UL RB (i.e. different MAC-d flow-specific power offset values can
be set for PS_EDCH and SRB_EDCH UL RBs). For a given UL RB, the MAC-d
flow-specific power offset is set via edchMacdPowerOffsetEdchTti10 (for 10ms
E-DCH TTI) and edchMacdPowerOffsetEdchTti2 parameter (for 2ms E-DCH
TTI).
Note that the offset specified for a given MAC-d flow is used regardless of the
number of MAC-d flows (user data only or user data and signaling) setup for the
call.
• Amount of data to transmit on E-DCH in UE buffer
• Available UE power
• Number of slots in the next 10ms E-DCH TTI affected by a Compressed Mode
gap.
• E-DCH Minimum Set E-TFCI:
Unique E-TFCI value, configured at UE (and NodeB) via RRC (and NBAP) at E-
DCH call establishment. 3GPP TS 25.321 [R05] specifies that, within the limit
182H
Page 33/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
only if the board handling the E-DCH call is an xCEM. From UA6 onwards, this
parameter is also used for the UCU-III. E-DCH Minimum Set E-TFCI value is set
via edchMinSetEtfci parameter under EdpchParameters. Please refer to 7.2 for 183H
Figure 6 shows the principle of retrieving the whole {E-TFCI; Power Offset} table
185H
basing on the {Reference E-TFCI; Reference Power Offset} table. X-axis represents
TBS, and Y-axis represents Power Offset in dB.
25
E-DPDCH power relativ to DPCCH (dB)
20
15
10
0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
TB size (bits) 4
x 10
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Again, in order to avoid too much signaling when configuring the {Reference E-TFCI;
Reference Power Offset} table both at NodeB and at UE side, the RNC sends coded
values (after quantization) for the Reference Power Offsets (i.e. power ratio E-DPDCH
/ UL DPCCH, also referred as “βed/βc”). The coded values for Power Offsets are
specified in 3GPP TS 25.213 [R06], Table 1B.1, and recalled below for convenience.
186H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 35/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter referenceEtfciPowerOffset Object ReferenceEtfciConfList
Range & Unit Integer [0 … 29], N/A
User Customer Granularity RNC
Class 0
Value [xCEM] [iCEM] See below: Table 3, Table 4, Table 5, Table 6
194H 195H 196H 197H
The four recommended tables for iBTS (i.e. iCEM, 10ms TTI on xCEM, 2ms TTI with
E-DPDCH min SF of 2xSF2 on xCEM, 2ms TTI with E-DPDCH min SF of
2xSF2+2xSF4 on xCEM) and the four recommended tables for OneBTS using the (i.e.
10 ms TTI on UA6.0 on UCU-III, new 10 ms TTI on UA7.1 and 2ms TTI with E-
DPDCH min SF of 2xSF2 on UCU-III, 2ms TTI with E-DPDCH min SF of
2xSF2+2xSF4 on UCU-III), as well as the recommended configuration method are
described below.
UA6 UA7.1 Delta: [UCU-III] {Reference E-TFCI; Reference Power Offset} table
Due to the introduction of 2ms E-DCH TTI support in UA7.1 for UCU-III, new {Reference E-TFCI;
Reference Power Offset} tables (corresponding to 2ms TTI cases) are introduced.
[iCEM] [xCEM]
Reason for using board-specific {Ref E-TFCI; Ref PO} tables (10ms TTI case):
Regarding 10ms TTI, due to the specific implementation and behavior of xCEM E-
DCH functions, the recommended {Reference E-TFCI; Reference Power Offset} table
is different for iCEM and xCEM. In particular, for xCEM, in order to avoid UL load
divergence issues due to user self-interference for high data rate transmission in
channel profiles with bad orthogonality, the strategy is to allow higher UL DPCCH
power (set via maxSirTarget parameter) while using smaller E-DPDCHs / UL DPCCH
power ratio (set via {Reference E-TFCI; Reference Power Offset} table), compared
with iCEM. Please refer to section 9.1 of this volume and to [R01] for more information
201H 20H
For iCEM, the recommended {Reference E-TFCI; Reference Power Offset} table is as
follows.
0 0 2
1 3 11
2 11 15
3 85 22
4 95 23
5 96 24
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
For xCEM with 10ms, the recommended {Reference E-TFCI; Reference Power Offset}
table is as follows.
0 3 9
1 5 10
2 25 16
3 51 18
4 106 19
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table
For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
0 3 13
1 5 14
2 83 20
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table
For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2+2xSF4, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
0 3 13
1 5 14
2 58 15
3 91 18
4 98 21
[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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The recommended {Reference E-TFCI; Reference Power Offset} table is as follows for
the UCU-III and 10 ms TTI for both UA6.0 and UA7.1.
0 3 10
1 9 13
2 25 17
For the UCU-III with 2ms TTI and E-DPDCH min SF of 2xSF2, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
0 3 13
1 5 14
2 83 20
For the UCU-III with 2ms TTI and E-DPDCH min SF of 2xSF2+2xSF4, the
recommended {Reference E-TFCI; Reference Power Offset} table is as follows.
0 3 13
1 5 14
2 58 15
3 91 18
4 98 21
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 38/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
{REF E-TFCI; REF PO} TABLE SELECTION MECHANISM
At the establishment of an E-DCH call, the {Ref E-TFCI; Ref PO} table configured by
RNC (both at UE side and NodeB side) is selected according to the following
elements:
• The HSUPA Category of the considered UE,
• The type of board (iCEM , xCEM or UCU-III) handling E-DCH for the E-DCH
serving cell (known by E-DPDCH SF capability of the E-DCH serving cell).
• The requested UL service (e.g. E-DCH stand-alone or E-DCH + CS AMR NB).
This is achieved by using multiple EdpchInfoClass instances, as shown in Figure 203H
7
• The requested type of E-DCH TTI (i.e. 10ms or 2ms)
Remark: The reason why cell E-DPDCH SF capability is taken into account in {Ref E-
TFCI; Ref PO} table selection mechanism is to make possible the use of a different
table for a cell served by an iCEM and a cell served by an xCEM or UCU-III. Indeed,
the optimal table is different for each type of board. The RNC does not have the direct
knowledge of the type of board (iCEM or xCEM or UCU-III) serving a given cell.
However, the RNC has the knowledge of the E-DPDCH SF capability of a given cell.
Since the SF capability for iCEM (limited to 2xSF4) is different than for the xCEM or
UCU-III, by looking at the SF capability of a given cell the RNC can know the type of
board that serves it.
The parameters model at OMC-R (i.e. at RNC) is defined as follows.
RadioAccessService
EdpchParameters EdchParameters
ReferenceEtfciConfList EdchCellClass
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 39/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Once the EdpchInfoClass instance has been selected according to the requested UL
service, under this EdpchInfoClass instance, one instance of EdpchParameters
object is selected by RNC among 9 available instances. Each instance of
EdpchParameters object includes (among other parameters) one {Ref E-TFCI; Ref
PO} table. The parameters and the {Ref E-TFCI; Ref PO} table under the selected
EdpchParameters instance will be used to configure the considered E-DCH call. The
EdpchParameters instance is selected as follows.
SF32 16 16
SF16 16 16
SF8 16 16
SF Capability
SF4 1 2
2xSF4 3 2
2xSF2 5 4
2xSF2+2xSF4 16 16
Table 10: Primary Cell HSUPA Category according to Primary Cell E-
DPDCH SF capability and selected E-DCH TTI
Remarks:
• Value 16 for Primary Cell HSUPA Category is a special value, used so that
Target HSUPA UE Category is not driven by Primary Cell HSUPA Category in
Step 2 of EdpchParameters instance selection algorithm (see Step 2 below).
• For the case where the Primary Cell E-DPDCH SF Capability reported by the
NodeB is 2xSF2+2xSF4 but with isSrbOnEdchAllowedWhenTrbOnEdch
parameter set to “False” (i.e. UA6 33581 “SRB on E-DCH during Call” disabled),
the Primary Cell E-DPDCH SF Capability used in the {Ref E-TFCI; Ref PO} table
selection mechanism (in Step 1 of EdpchPararmeters instance selection
algorithm) is forced to 2xSF2. This case applies to both the Global and US
markets.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 40/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Step 3. EdpchParameters instance is selected among the 9 available instances,
basing on the computed Target HSUPA UE Category and the E-DCH TTI
selected for the considered E-DCH call, according to the following table.
2 UECategory2EdchTti10ms UECategory2EdchTti2ms
UE Category
3 UECategory3EdchTti10ms N/A
4 UECategory4EdchTti10ms UECategory4EdchTti2ms
5 UECategory5EdchTti10ms N/A
6 UECategory6EdchTti10ms UECategory6EdchTti2ms
Table 11: EdpchParameters instance according to Target HSUPA UE
Category and selected E-DCH TTI
Once the EdpchInfoClass instance has been selected according to the requested UL service,
under this EdpchInfoClass instance, one instance of EdpchParameters object is selected by RNC
among 28 (9 UA6 + 19 UA7) available instances. Although, these new 19 EdpchParameters
instances are not still available to be used.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 41/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
{REF E-TFCI; REF PO} TABLE SETTING AT OMC
Engineering Recommendation:
Configuration of {Reference E-TFCI; Reference Power Offset} tables via instances of
EdpchParameters objects.
[iCEM] [xCEM]
UECategory1EdchTti10ms
UECategory2EdchTti10ms
UECategory3EdchTti10ms
• Set xCEM/10ms TTI recommended table (Table 4) for the following EdpchParameters
205H
instances:
UECategory4EdchTti10ms
UECategory5EdchTti10ms
UECategory6EdchTti10ms
• Set xCEM/2ms TTI/2xSF2 recommended table (Table 5) for the following EdpchParameters
206H
instances:
UECategory2EdchTti2ms
UECategory4EdchTti2ms
• Set xCEM/2ms TTI/2xSF2+2xSF4 recommended table (Table 6) for the following 207H
EdpchParameters instance:
UECategory6EdchTti2ms
[UCU-III]
For all EdpchInfoClass instances for UA6.0, set UCU-III recommended table (Table 7) for all 208H
EdpchParameters instances.
For all EdpchInfoClass instances for UA7.1:
• Set UCU-III/10 ms TTI recommended table (Table 7) for the following EdpchParameters
209H
instances:
UECategory4EdchTti10ms
UECategory5EdchTti10ms
UECategory6EdchTti10ms
• Set UCU-III/2 ms TTI/2xSF2 recommended table (Table 8) for the following EdpchParameters
210H
instances:
UECategory2EdchTti10ms
UECategory4EdchTti10ms
Set UCU-III/2 ms TTI/2xSF2 + 2xSF4 recommended table (Table 9) for the following 21H
EdpchParameters instances:
UECategory6EdchTti10ms
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 42/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
{REF E-TFCI; REF PO} TABLE RECONFIGURATION
The {Reference E-TFCI; Reference Power Offset} table (as well as other E-DCH call
attributes) may be reconfigured while in E-DCH call, for one of the following reasons.
When E-DCH is configured with TTI of 10ms, the NodeB sends to the RNC one IUB
E-DCH FP Data Frame, containing one MAC-e PDU, each 10ms.
[xCEM]
When E-DCH is configured with TTI of 2ms, the NodeB may send data to the RNC in
either bundling mode (which consists in NodeB sending data every 10ms TTI and
bundling several 2-ms TTI together) or unbundling mode (which consists in NodeB
sending E-DCH FP Data Frame every 2ms). Only unbundling mode is supported.
isEdchFpBundlingModeForEdchTti2msAllowed: when a RAB is mapped on E-
DCH with a TTI 2ms, this flag specifies if the NodeB shall bundle the E-DCH FP frame
of 2ms into an FP frame of 10ms (this parameter is specific xCEM).
Restriction: For E-DCH configured with TTI of 2ms, xCEM only supports unbundling mode,
which consists in NodeB sending E-DCH FP Data Frame every 2ms
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 43/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[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.
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
213H
referred as “βed/βc”), are configured via the {Reference E-TFCI; Reference Power
Offset} table. However, for the specific case of a MAC-e PDU with stand-alone
Scheduling Information (SI) field (i.e. no user data transmitted), a specific Power
Offset value is applied instead of the value specified by the table (according to 3GPP
TS 25.331 [R09], see Power Offset for Scheduling Info IE). The value in dB for this
214H
[iCEM] [xCEM]
The following parameter is used for 10ms TTI:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 44/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[UCU-III]
Since UA7.1, the UCU-III supports the 2 ms TTI. The following parameter is used for
2ms TTI:
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 E-
TFCI the required number of E-DPDCH(s) and their SF (see 3GPP TS 25.212 [R03]). 215H
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 .
UECategory4EdchTti10ms
[xCEM] [UCU-III] 18 (corresponds to
UECategory5EdchTti10ms
PLnon-max = 0.72)
UECategory6EdchTti10ms
UECategory2EdchTti2ms
[xCEM] [UCU-III] 20 (corresponds to
UECategory4EdchTti2ms
PLnon-max = 0.8)
UECategory6EdchTti2ms
Remark: Similarly to {Reference E-TFCI; Reference Power Offset} table, the PLnon-max
value used for a given UE is selected according to type of board handling E-DCH for
the E-DCH serving cell, HSUPA UE Category, E-DCH TTI type and UL service.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 45/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, 20 is the new recommended value for
plNonMax for category 2, 4 and 6 UEs.
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 46/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved0
The bits 24 and 25 were used for The bit 16 was used The bit 8 was used to The bits 0, 1 and
UL ILPC Algorithm selection for to distinguish Global control the execution 2 were used for
UeCat4 TTI2ms and UeCat6 Market (value 0) and time of the SRB on EDCH
TTI2ms EDCH calls. See below. US Market (value 1) reconfiguration from activation.
cell DCH to Cell FACH
In UA7.0, the 1st and 2nd less significant bytes of the parameter reserved0 are freed and replaced by new
parameters. The 1st byte is replaced by isSrbOnEdchForAllEdchCategory, isSrbOnEdchForAllMinSf,
isSrbOnEdchForAllEdchTti (refer to the section 10 in this volume).The 2nd byte is replaced by
reconfigTimeDchFach (refer to [R01] Volume 11).
From UA7.1, the 4th less significant byte of the parameter reserved0 is freed and replaced by new
parameters (isTpcAlgo2ForEdchCat4 and isTpcAlgo2ForEdchCat6, see above).
The 1st and 2nd less significant bytes are re-used for the feature 28528 Multi-Operator Core Network
(MOCN). (refer to [R01] Volume 15)
The 3rd less significant byte remains used as in UA6.0 to distinguish Global Market (bit 16 is set to 0) and
US Market (bit 16 is set to 1)
Refer to the engineering recommendation below.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 47/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[GM] 00000000 00000000 xxxxxxxx xxxxxxxx (binary). The first and second less significant bytes
are operator dependant if the feature 28528 Multi-Operator Core Network (MOCN) is configured
(refer to [R01] Volume 15), else they are unused and could be set to 0.
The UE applies the E-DCH Mac-d Flow Power Offset on top of transport block size
specific power offset when actually transmitting data on E-DPDCHs. The E-DCH Mac-
d Flow Power Offset is configurable per E-DCH RB (typically an E-DCH Mac-d Flow
Power Offset is configurable for PS_EDCH RB and another one is configurable for
SRB_EDCH).
Both UE and Nodeb use the E-DCH Mac-d Flow Power Offset for the calculation of
the TPR (Traffic to Pilot power Ratio), according to the formula in 3GPP TS 25.214
[R12], section 5.1.2.5B.2.
219H
• [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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 48/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter edchMacdPowerOffsetEdchTti10 Object EdchParameters
Range & Unit [0..6] step:1
User Customer Granularity UlRbSetConf
Class 0
Value For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 5
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 49/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 50/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Rule: rotMarginPrediction
rotMarginPrediction corresponds to the UL load prediction model correction step x 100 (i.e. a
rotMarginPrediction set to 3 correspond to a step of 0.03).
This parameter setting is a trade off between time of convergence and fluctuation of RoT_meas close
to RoT_max.
According to system simulation results, 0.05 is an optimal value.
needs as an input the uplink load available for the E-DCH traffic of the considered cell.
Regarding the iCEM, in order to estimate, at each TTI, the UL load available for E-
DCH, the following actions are performed within the NodeB:
• Derivation, every 24 hours, of the thermal noise level (RTWPref) at the BTS, via
thermal noise level “self-learning” algorithm (c.f. section 4.1.1), basing on 21H
• Estimation, every E-DCH TTI (i.e. 10ms since only 10ms TTI is supported on
iCEM), of the current total UL load. This action is also often referred as “UL load
prediction”. The accuracy of this estimation has an important impact on the
performance of the MAC-e scheduler.
In section 6.1 has already been presented an enhancement – “UL Load Fine
2H
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 51/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Before the introduction of UA5.1/iCEM 34221 feature, since this self-interference
phenomenon was not taken into account when estimating current total UL load, the
computed UL load available for E-DCH could be over-estimated (compared to the
actual UL load available for E-DCH). Consequently, especially for channel profiles with
bad “orthogonality”, the grants allocated could be too large, which could lead to UL
overload and thus de-grant of E-DCH users (iCEM defense mechanism against UL
overload is described in section 6.3). 23H
Remarks:
Restriction: RTWPnon E-DCH sent to the RNC does not benefit from UA5.1/iCEM 34221 feature
The improvement on the accuracy of the estimation of current total UL load brought by 34221 is only
used by the MAC-e scheduler in the NodeB. The quantity RTWPnon E-DCH sent every 100ms from the
NodeB to the RNC via NBAP does not benefit from this improvement.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 52/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
In some specific cases, the throughput of an E-DCH user transmitting at high bit rate
may be degraded with the activation of 34221. However, the average E-DCH cell
throughput should increase so this should not be an issue.
rtwpTimeDetection
RoT
ALARM
rtwpMargin
totalRoTMax
OK
OK
Time
Figure 9: RTWP exceeding margin
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 53/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter rtwpTimeDetection Object BTSCell
Range & Unit [100..400] step:100 ms
User Customer Granularity Cell
Class 3
Value 400 ms
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 54/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Once the grant is signaled, the E-DPDCH power should not exceed the grant
information:
n.β ed2 < signaled grant value
Where n stands for the number of E-DPDCH physical channels.
The HSUPA scheduler monitors the available UL load. An average value of the UL
RTWP is available once every 100 ms.
The grant sent to each UE is computed by the MAC-e scheduler based on:
• UL load available for HSUPA
• Number for E-DCH UE asking for grant allocation
• Scheduling Information transmitted by each UE. The scheduling information
are transmitted periodically on the E-DPDCH according to
periodicityOfSchedInfoGrant and periodicityOfSchedInfoNoGrant,
depending on whether the UE is granted or not (please refer to section 7.4. for
further details about these two parameters). They contain the following
information:
• Happy bit: this bit is transmitted on the E-DPCCH and represents the UE
state according to his current max grant notification. The parameter
happyBitDelay defines the delay to be used by the UE in its procedure to set
the Happy Bit. The happyBitDelay value is signaled to the UE at call setup.
Please refer to the section 7.1 for the description of this parameter.
26H
The resulting maximum grant allocation is the minimum of all grant allocations
provided by each of the step described above and is sent on one E-AGCH (RNTI and
Grant info).
Please refer to the section 7.1 for the description of these parameters.
27H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 55/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The grants are computed by the scheduler to provide some fairness between users.
They are limited by the fact that the global uplink interferences level must not go
above a certain threshold (totalRotMax – over which the system might become
instable and might diverge) and by the BTS processing capabilities dedicated to E-
DCH. The main target of the scheduler is to grant UEs so that the total UL load of the
cell stays near the target load (totalRotMax), but not above. If the uplink load gets
above this limit, then the scheduler will reduce the grants of the E-DCH links. In case
of radio “overload” (due to other traffics: CCH, DCH, inter-cell interferences and other
interferences), the grants of E-DCH users get down to ZERO_GRANT in order to
avoid radio divergence. The radio overload condition is defined by the fact that the UL
load is above the RTWPlimit (totalRotMax + rtwpMargin) during a certain time
(rtwpTimeDetection). If the UL load is below the limit then the E-DCH UEs may be
granted more.
When the grant allocated to a given E-DCH UE is modified, the MAC-e scheduler
reevaluates the contribution of this UE to the total uplink load. The MAC-e scheduler
computes grants of all users so that the total uplink load stays close to the target total
uplink load (set via totalRotMax) without exceeding it.
In case grants are reduced, this will reduce the load of the system and will free
resources for other E-DCH users. However the UE which grants have been reduced
will continue using former grants for ongoing H-ARQ retransmissions, meaning that
resources cannot be reallocated immediately to other users.
RATE SCHEDULING
In iCEM, only one type of E-DCH scheduling is supported: “Rate Scheduling”.
Parameter edchSchedulerAlgorithm Object BTSEquipment
Range & Unit Enum {roundRobinSlidingWindow, rateScheduling}
User Customer Granularity Cell
Class 3
Value rateScheduling
In iCEM, with Rate Scheduling, all E-DCH active users (having data to transmit) are
transmitting (having grants) simultaneously. They share resources in a fair way and
the general principle being that:
• hardware resources are shared equally between all active cells (containing at
least one active user)
• hardware resources assigned to an active cell are shared equally between all
active users of this cell
• the cell load (apart from R99 part) is shared equally between all active users
of this cell
Page 56/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
For more details, see [R04]. 28H
If the UE uses an E-TFCI too high regarding the grant it has been allocated, NodeB
cannot decode data sent by UE on E-DCH, since for this UE hardware resources have
not been reserved at NodeB for such large E-TFC. For this specific case, the wrongly
detected E-AGCH should be resent as soon as possible in order to avoid useless E-
DCH transmissions (since not decoded by NodeB) that cause UL interference for
other users.
If the UE uses an E-TFCI too low regarding the grant it has been allocated, NodeB
normally decodes data sent by UE on E-DCH, but E-DCH user throughput is degraded
compared to what it could have been if UE had correctly decoded the E-AGCH
command.
Since UA5/iCEM, the following defense mechanisms against E-AGCH bad detection
have been implemented in the MAC-e scheduler.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 57/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
UA5.0 UE uses an E-TFCI higher than For a given UE, each time any of beside cases is
the maximum E-TFCI allowed detected (on reception of E-DPCCH at NodeB), an E-
according to current grant AGCH error counter is incremented for this UE. The E-
computed by MAC-e scheduler AGCH error counter is reset if UE happens to use an
for this UE. E-TFCI different than the one used when E-AGCH
error was detected. If the counter reaches a certain
UA5.0 UE sends a MAC-e PDU that only limit (7), an E-AGCH Alarm is raised for this UE.
includes SI (no payload),
MAC-e scheduler then resends E-AGCH commands
although MAC-e scheduler has
(the same command that has been sent previously but
granted this UE with a grant
not detected or wrongly decoded) to UEs for which an
different than Zero Grant.
E-AGCH alarm has been raised.
UA5.1 Happy Bit received from UE is set Remark: For the case when UE uses an E-TFCI higher
onwards to unhappy, while UE uses an E- than the maximum E-TFCI allowed (and only for this
TFCI lower than [the maximum E- case), after the E-AGCH error counter has reached the
TFCI allowed according to current limit (i.e. after E-AGCH Alarm has been raised), the E-
grant computed by MAC-e AGCH channel is preempted (with regards to already
scheduler for this UE] -3. planned E-AGCH commands) in order to resend the E-
AGCH command as soon as possible.
Rule: siActivityTimer
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 58/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Scheduling Priority Internal priority level
Highest Priority 15 Prio_Level_Gold
14 Prio_Level_Silver
13 Prio_Level_Bronze
12
11
10
9
8
7
6 Prio_Level_Other
5
4
3
2
1
Lowest Priority 0
Table 13: Scheduling Priority iCEM
Since only 4 behaviors are possible but 16 SPI values available, the operator shall
ensure that only the highest SPI values are used.
Similarly to MAC-hs scheduler, the MAC-e scheduler support relative weighting
according to SPI in order to obtain relative throughput when UEs are under same
radio and traffic conditions.
Internal metrics for fair processing (fair index and average consumption per UE of
shared resources) take SPI into account to allow more service to high priority UEs
than low ones of the same serving cell at iso radio and traffic conditions.
A weighting vector (1 by 4) edchSpiRelativeWeight will be provisioned at OMC-B to
configure the relative weight of the SPIs in similar way to HSDPA. This parameter is
common for both iCEM and xCEM.
Parameter edchSpiRelativeWeight Object EdchConf
Range & Unit [1..16][0..100]
User Customer Granularity BTSCell
Class 0
Value 100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100
OAM must check after reception of this table the following items:
- Values of weights from SPI = 11 to SPI = 0 are set to 100
- Values from SPI = 15 to SPI = 12 are set with decreasing values:
1 ≤ E-DCHSpiRelativeWeight [SPI = 12]
≤ E-DCHSpiRelativeWeight [SPI = 13]
≤ E-DCHSpiRelativeWeight [SPI = 14]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 59/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS. Please refer to
section 11 for details.
edchSpi: For each E-DCH call, the Core Network provides in RANAP RAB
Assignment message the following QoS attributes: Traffic Class, ARP (Allocation
Retention Priority), THP (Traffic Handling Priority). edchSpi parameter, which is
located under RadioAccessService → TrafficClassBasedQos → ArpBasedQos →
ThpBasedQos, is used to assign to each {Traffic Class, ARP, THP} combination an
E-DCH SPI (Scheduling Priority Indicator). edchSpi parameter is used in the same
way for iCEM, xCEM and UCU-III cases.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 60/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
In UA5/iCEM, tests showed that at least 2 E1 per NodeB are required in order to avoid
E-DCH Data Frame loss on Iub when several E-DCH users are transferring
simultaneously. In other words, in UA5/iCEM, at least 2 E1 per NodeB are required in
order to reach the maximum E-DCH aggregate throughput per E-BBU (i.e. 2.1 Mbps
at MAC-e level).
In UA6 the feature “Iub Bandwidth Limitation for E-DCH (iCEM)” (33332.2) is
introduced in order to take into account the UL Iub congestion in the E-DCH scheduler
and limit the UL radio and HW resources to the available Iub BW for E-DCH (Iub BW
not used by R99 traffic).
In order to perform this mechanism the congestion status should be known, thus a
direct interaction with feature HSPA congestion detection & notification (33367) is
necessary.
RNC
HSUPA Throughput
Node B
Iub
HSUPA BW limitation by Node B HSUPA congestion detection by RNC
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 61/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter isEdchBandwidthLimitationAllowed Object BTSEquipment
Range & Unit False,True
User Customer Granularity BTSEquipment
Class 3
Value True
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 wait up to its expiry before the MAC-d flow is marked
as congested.
If all the P missing frames are received during that interval, the MAC-d flow is NOT
marked as congested, the timer is stopped. In that case, the last received frame is the
new 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 62/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
With 10ms TTI, when N succeeding E-DCH UL Data Frames have their successive
FSN Nn = Nn-1+1, the leg is marked as non-congested. N is controlled by the
parameter nFramesBeforeEdchDeCongestion.
With 2ms TTI in non-bundling mode, the algorithm uses parameter
nFramesBeforeEdchDeCongestion multiplied by 5.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 63/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
When a congested Mac-d flow becomes non-congested, the RNC sends one “TNL
Congestion indication” message with cause “No TNL Congestion”.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 64/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Figure 14: Example of the GRF variation with the congestion status
The iCEM scheduler reduces the UL codec limitation by GRF where the codec
limitation is calculated as follow:
CDC_size_Max = min(2.1Mbps,edchBLIubBandwidth)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 65/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The following parameter is a timer that controls the periodicity where the NodeB
modifies the reduction factor.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 66/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 67/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
and especially TTI2ms performances. Refer to [R14] for more details. This
29H
- The Maximum Target Received Total Wide Band Power is sent over
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message. It
is derived from OMC-R parameters FDDCell→totalRotMax and
FDDCell→rtwpReference. RTWPref will be adjusted according to self-
learned RTWP value in the NodeB, as well as the resulting RoT.
- The Target Non-serving E-DCH to Total E-DCH Power Ratio is sent over
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message. It
is derived from OMC-R parameters FDDCell→ targetNonServingToTotal-
EdchPoweRatio (see Vol.6 for further details regarding this parameter).
The target UL load Ltarget is derived and is defined as the most restricting criterion
among above limitations.
The first parameter is specific to xCEM only, next two are common between iCEM and
xCEM and last one is common among UCU-III, xCEM and iCEM (please refer to
section 4.1.1 for further details).
230H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 68/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter totalRotMax Object FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Range & Unit Decimal [0.0 ... 20.0] step 0.1, dB
User Customer Granularity Cell
Class 2 or 3
Value [iCEM] [xCEM]
R’99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
[UCU-III] 15
Measurements
RTWP is reported every 100ms to the MAC-e scheduler.
[xCEM][UCU-III],
Estimates every 10ms the average total UL load LE-DCH generated by E-DCH
serving users, non-serving users and peer-serving users.
The total UL load (E-DCH or not) Ltotal is also generated according to RTWP
measurements or Ec/I0 and TPR measurements depending on selected
mode, allowing to derive the Lnon E-DCH = Ltotal – LE-DCH.
[UCU-III]
RTWP is reported every 2ms to the MAC-e scheduler for OneBTS.
Ltotal will be generated according to Ec/Io and TPR measurements, allowing to
derive the Lnon E-DCH = Ltotal – LE-DCH.
The available E-DCH load is then derived and corresponds to Lavailable, E-DCH = Ltarget -
Lnon E-DCH. If Lavailable, E-DCH <= 0, then the cell is overloaded.
UE specific information
- Happy bit status
- Scheduling information
- Reference scheduling grant SGref, i, taken from previous scheduling interval
- Average transport block size i.e. PHY throughput
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 69/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter happyBitDelay Object EdchCellClass
Range & Unit Enum {2, 10, 20, 50, 100, 200, 500, 1000}
User Customer Granularity RNC,
Class 3 EdchCellClass
Value [iCEM][xCEM] 50
[UCU-III] 10
[xCEM]
If an SI is received while UE is not granted, the MAC-e scheduler assumes for initial
grant computation that TBrequested = TB(Edchconf→edchInitialTBIndexXxx).
edchInitialTBIndex10msTTI and edchInitialTBIndex2msTTI parameters are used to
set the E-TFCI to be used for initial grant sent to UE via AG command.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 70/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
[iCEM]
Regarding iBTS, edchInitialTBIndexXxx parameters are taken into account by the
system only if the board handling the E-DCH call is an xCEM. As explained in 5.4, for 23H
iBTS, RNC detects the type of board handling E-DCH traffic for the considered cell via
the E-DPDCH SF capability of the considered cell.
If the board handling the E-DCH call is an iCEM, edchInitialTBIndexXxx parameters
are ignored by the system. For iCEM, differently from xCEM, this initial grant is sent to
UE via RRC signaling and not via AG command. A hard-coded value is used for the
initial grant (SG=14 which corresponds to E-TFCI 7 if UE is alone on the E-BBU,
SG=38 which corresponds to no grant −wait for AG command− if UE is not alone on
the E-BBU).
[UCU-III]
For the OneBTS, the equivalent to edchInitialTBIndex10msTTI and
edchInitialTBIndex2msTTI are internal NodeB tunable parameters.
The requested TB is converted to a target grant 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 and xCEM boards (not UCU-III).
Hypothetical overload
Lhypothetical > Lavailable: this condition corresponds to “hypothetical” overload situation
posterior to update of requested TB of all UEs.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 71/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The MAC-e scheduler shall also check whether the interference created by the peer-
serving RL is smaller than or equal to Edchconf→edchSofterHoLimit (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.
As it has been explained in 5.4, E-DCH Minimum Set E-TFCI is a unique E-TFCI
23H
value, configured at UE (and NodeB) via RRC (and NBAP) at E-DCH call
establishment. 3GPP TS 25.321 [R05] specifies that, within the limit allowed by
234H
the type of board handling E-DCH traffic for the considered cell via the E-DPDCH SF
capability of the considered cell.
E-DCH Minimum Set E-TFCI value is set via edchMinSetEtfci parameter under
EdpchParameters. From UA6 onwards, this parameter is also used for the UCU-III.
Note that the parameters rtwpMargin and rtwpTimeDetection are not used for xCEM
overload algorithm.
The xCEM overload algorithm is triggered when the average non E-DCH load,
estimated based on the last received RTWP measurement, is higher than the “E-DCH
Max load” corresponding to RoT_max setting.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 72/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The SI reporting is activated for 10ms and 2ms TTI through the following flags
The amount of time with no data from UE, used to consider a UE as inactive, is
configurable through the parameter edchInactivityTimerXcem.
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):
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 73/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter periodicityOfSchedInfoGrant Object EdchCellClass
Range & Unit EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
User Customer Granularity EdchCellClass
Class 3
Value 50
Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoGrant.
- After reception of SI trigger, AG is sent with the next valid value with AG >=
SGtarget.
Page 74/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
- If SGtarget,i = SGref,i, set RGi = "HOLD".
[UCU-III]
The ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set
different for OneBTS for UA06, due to different reference ETFCI and reference power
offset settings. Our recommendation is: ergch2IndexStepThreshold=18,
ergch3IndexStepThreshold=15.
Since UA7.1, the UCU-III supports the 2 ms TTI. For this TTI, the
ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set to the
same values as the xCEM, namely ergch2IndexStepThreshold=20, and
ergch3IndexStepThreshold=16.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 75/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Since only 4 behaviors are possible but 16 SPI values available, the operator shall
ensure that only the highest SPI values are used.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 76/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 77/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
OAM must check after reception of this table the following items:
- Values of weights from SPI = 11 to SPI = 0 are set to 100
- Values from SPI = 15 to SPI = 12 are set with decreasing values:
1 ≤ E-DCHSpiRelativeWeight [SPI = 12]
≤ E-DCHSpiRelativeWeight [SPI = 13]
≤ E-DCHSpiRelativeWeight [SPI = 14]
≤ E-DCHSpiRelativeWeight [SPI = 15] ≤ 100
Regarding edchSpi parameter, please see section 6.7 for a detailed description.
237H
[UCU-III]
[xCEM] The Mac-e non scheduled mode is supported by the xCEM and it’s 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 78/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter maxMacePduContentsSizeForNonScheduledModeTti2 Object EdchParameters
Range & [1..1096], integer
Unit
User Customer Granularity UlRbSetConf
Class 3
Value 162
The non scheduled mode is only used when the SRB over E-DCH is activated (please
refer to section 10 of the current volume).
In order to perform this mechanism the congestion status should be known, thus a
direct interaction with feature HSPA congestion detection & notification (33367) is
necessary.
The Iub congestion detection and reporting are common to both xCEM and iCEM
(same mechanism is used).
Page 79/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The xCEM scheduler reduces the UL load limit by GRF (and not the codec limitation
as for the iCEM case).
The same parameters are applicable for both iCEM and xCEM boards (refer to 6.8.3).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 80/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The feature reacts the following way:
1. Hardware/microcode detects the AAL2 UL overflow
2. Platform software performs fault confirmation (leaky bucket mechanism) and
report the fault to OAM CCM
3. OAM CCM informs all xCEM of AAL2 congestion when activation parameter
edchCMActivation is set to TRUE
4. When xCEM manages E-DCH, xCEM reduces or increases E-DCH throughput
according to congestion indication from OAM CCM
5. OAM CCM reports an alarm to OMC-B only if the AAL2 overflow condition is still
present despite the xCEM congestion control mechanism for E-DCH.
The local congestion feature (75786) uses the same mechanism to control the
congestion than feature 33332 “Iub congestion control for e-DCH”. The interaction
between both features is that the BTS considers congestion of E-DCH when either it
has been detected locally (75586) or remotely (33367). To do so, the congestion
control mechanism uses the minimum value between:
• Load limit (overload)
• GRF
As a result, features 33332 and 75786 can be managed at the same time.
The parameter name edchCMActivation, used previously in UA6 & UA7.0 and in a provisory basis,
will now have the name edchLocalCongestionControlActivation for UA7.1.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 81/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Remark: The feature is managed the same way in all cases when user plan for E-
DCH is managed on ATM external AAL2 VCC, i.e:
ATM over PCM (IMA or no IMA)
ATM over PCM with multiple IMA Group
Hybrid IUB for the ATM leg
[iCEM]
This feature is not applicable.
[UCU-III]
This feature is not applicable, but a similar mechanism can be achieved based on the
Iub Overload Control. The only difference is the generation of the Iub overload
indicator which is done by means of ATM queue fill levels.
The Node B periodically informs the MAC-e scheduler about the Iub status. A
congestion event is reported if the low priority UL queue size (at AAL2 PVC level, ATM
Adaptation Layer 2 Permanent Virtual Circuit) crosses a certain HIGH threshold
(tunable at the NodeB) and the PVC is not in congested state. A congestion release
event is reported if the queue size crosses a LOW threshold (tunable at the NodeB)
and the PVC is not in uncongested state.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 82/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 83/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
This section describes the principle of UL OLPC for E-DCH with Alcatel-Lucent
implementation.
For a detailed description of the UA5.1 behaviour (34172 “E-DPDCH Retransmissions
for DPCCH SIR Adaptation” feature), refer to UA5.x HSxPA Engineering Guide [R02]. 239H
Since UA6, E-DCH UL OLPC is enhanced with the introduction of UA6 34249 EUL
Capacity Optimized HARQ Operation. For a detailed description of the specific
aspects introduced by this feature, please refer to section 9.1.1.2. 240H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 84/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 85/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
In UA5.0 and early UA5.1/iCEM, for stand-alone E-DCH calls (i.e. E-DCH + SRB in
uplink, no multi-service), the format used for the UL SRB for the SRB inactivity periods
(i.e. no signaling data transmitted) was TF1x0 (i.e. transport format that forces the
transmission of a CRC even when there is no signaling data to transmit), instead of
the usual TF0x148 format. This allowed continuous monitoring of the radio quality
(BLER) of the UL DCH transport channel holding the SRB, thus continuous updating
of UL SIR Target even when there is no activity on E-DCH and no or few UL signaling
activity (signaling activity is generally low, e.g. around 5%).
However, in early UA5.1/iCEM, tests showed that in most of the cases, the usage of
SRB TF1x0 for stand-alone E-DCH calls makes UL SIR Target decrease gradually
down to minSirTarget when there is no activity on E-DCH. This allowed saving some
UE Tx power and some UL load, but the gain is small because during inactivity
periods on E-DCH the only power-consuming UL physical channel is UL DPCCH. On
the other hand, the usage of SRB TF1x0 for stand-alone E-DCH calls lead to
substantial degradation of radio quality on E-DCH (i.e. NHARQ measured > NHARQ
Target) just after traffic on E-DCH started again. Indeed, when traffic on E-DCH
started again, UL SIR Target was well below the value required to achieve the target
radio quality on E-DCH.
For above reasons, effective from UA5.1.0.3, it has been decided to remove SRB
TF1x0 for stand-alone E-DCH calls (i.e. E-DCH + SRB in uplink, no multi-service), and
use instead the usual TF0x148 format. Then, as a consequence, for a stand-alone E-
DCH call in uplink (i.e. no voice or video telephony in parallel), it is not possible to
monitor continuously the radio quality when there is no activity on E-DCH, which
means that UL SIR Target almost stays at the level it was when activity on E-DCH
stopped. Test showed that this allows improving E-DCH radio quality for the case of
sporadic UL traffic (e.g. UL pings).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 86/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
PARTIAL UL SIR TARGET COMPUTATION
The Partial UL SIR Target associated to the E-DCH channel is derived within the UL
OLPC Machine associated to the E-DCH channel. Each time the RNC receives an E-
DCH Data Frame for the user considered (remark: from UA6, since E-DCH SHO is
supported, if UE is in E-DCH SHO then one E-DCH Data Frame among several
frames carrying the same data is selected at RNC), it updates the Partial UL SIR
Target associated to the E-DCH channel of this user, as follows:
With:
• ulSirStep: Parameter that impacts the amplitude of each change in the Partial
UL SIR Target associated to the E-DCH transport channel.
In UA5.1, when an HARQ Failure Indication (see 3GPP TS 25.427 [R07] for H24
UL OLPC.
Page 87/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
OLPC Machine associated to the E-DCH transport channel, i.e. above formula is
not impacted by this mechanism. Please refer to UA7 UPUG [R01], Vol.9, section 245H
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).
In UA6, the uplink Outer-Loop Power Control (UL OLPC) for E-DCH is improved by
introducing an adaptive target number of HARQ retransmissions, via UA6 34249 “EUL
Capacity Optimized HARQ Operation” feature. This mechanism allows adapting the
target number of HARQ retransmissions (NHARQ Target) according to current number
of E-DCH users and UL radio load. In other words, this mechanism allows adapting
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 88/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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 9.1.1.2.2) 247H
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 9.1.1.2.2 for details on 248H
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.
Page 89/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
• 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)
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 basing
on the following inputs:
• Current number of “active E-DCH users” in the cell.
For UA6 34249, “active E-DCH users” refers to UEs currently having an E-DCH
radio link established with the considered cell (hence these UEs are in Cell_DCH
RRC state), and for which this cell is the E-DCH serving cell.
• Current UL Radio Load Color.
The UL Radio Load Color is derived from the non E-DCH UL radio load of the cell.
For a detailed description of the calculation of UL Radio Load Color, please refer
to UA7 UPUG [R01], Vol.6, section 5.4.1.
249H
Below figure shows how Cell State is determined according to the current number of
“active E-DCH users” and UL Radio Load Color of the cell. Note that maxNumActive-
EdchUsersPerCellForS1 and maxNumActiveEdchUsersPerCellForS2 parameters
are used to set the thresholds for Cell State change on number of “active E-DCH
users” criterion.
Number of
“active
E-DCH users” S3
maxNumActive-
EdchUsers-
PerCellForS2
S2
maxNumActive-
EdchUsers-
PerCellForS1 S1 UL Radio
Load Color
0
green yellow red
Figure 17: Cell State computation
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 90/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The Partial SIR Target related to the E-DCH transport channel (note: in case of SRB
on E-DCH, there are two Partial SIR Targets related to E-DCH, see below paragraph
“SRB ON E-DCH CASE”) is computed as it was explained in section 9.1.1.2.1. With 250H
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:
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.
[US] For EDCH calls, the UL SRB is always carried on the E-DCH along with the UL
TRB.
In case of SRB on E-DCH, two MAC-d flows are carried on E-DCH: the UL SRB MAC-
d flow, and the UL TRB MAC-d flow. Regarding the UL OLPC, two UL OLPC
Machines are built for E-DCH. Each one of the two UL OLPC Machines computes
separately the Partial SIR Target related to the MAC-d flow it is related to. This is
shown in below figure.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 91/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
•
SIR Target
NodeB 1
UL OLPC Master
NodeB 1
Partial Partial
SIR Target SIR Target
(E-DCH SRB) (E-DCH TRB)
UL OLPC UL OLPC
Machine Machine
(E-DCH SRB) (E-DCH TRB)
N of HARQ N of HARQ
Retransmissions IE Retransmissions IE
Figure 18: UL OLPC in case of SRB on E-DCH
Note that for the case of SRB on E-DCH, there are two sets of
nHarqRetransTargetSx parameters, one for the SRB and one for the TRB MAC-d
flow, thus making it possible to set the target number of HARQ retransmissions NHARQ
Target for each Cell State separately for the SRB and for the TRB MAC-d flow.
In order to guarantee good link quality for the UL SRB, for the SRB MAC-d flow it is
recommended to set NHARQ Target to a low and same value for all Cell States (see
section 9.1.1.3.3 for more details on this recommendation).
253H
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.
Remark: As of 3GPP (see TS 25.427 [R07]), only the E-DCH serving NodeB can
254H
Page 92/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
• The HFI monitoring period is set via edchOlpcSamplingPeriodTti10ms and
edchOlpcSamplingPeriodTti2ms parameters.
• During the HFI monitoring period, the following internal counters are incremented:
Below figure shows how HFI Reception Scenario is determined according to current
HFI Ratio and Serving Ratio quantities. Note that edchOlpcServingRatioThreshold
and edchOlpcHfiRatioThreshold parameters are used to set the thresholds for HFI
Reception Scenario determination based on Serving Ratio criterion and HFI Ratio
criterion, respectively.
Serving Ratio
HFI 0 HFI 1
edchOlpc-
ServingRatio-
Threshold
HFI 3 HFI 2
0 HFI Ratio
0 edchOlpcHfiRatioThreshold
Figure 19: HFI Reception Scenario computation
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 93/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 94/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
• VS.EdchLinkImbalance counter is relevant only for periods with no congestion
on Iub. Indeed, if one of the Iub interfaces related to a NodeB involved in the E-
DCH call is congested, the E-DCH Data Frames carried on this Iub interface
cannot arrive in the same timeframe as the E-DCH Data Frames with the same
data carried on other Iub interface(s), so it is not possible to check for radio UL/DL
imbalance at RNC basing on the received E-DCH Data Frames.
E-DCH UL OLPC can be disabled by following one of the two methods below.
• Method 1 (UL OLPC active when in E-DCH call but E-DCH radio link quality not
taken into account):
For the UL services including an E-DCH UL RB, remove the E-DCH transport
channel from the list of reference transport channels driving the UL OLPC
algorithm.
• Method 2 (UL OLPC locked when in E-DCH call):
For the UL services including an E-DCH UL RB, set minSirTarget =
maxSirTarget.
Page 95/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
parameters nHarqRetransTargetS1, nHarqRetransTargetS2 and
nHarqRetransTargetS1 must be set to different values.
It is recommended to set these parameters so that the following rule is verified:
nHarqRetransTargetS1 ≤ nHarqRetransTargetS2 ≤ nHarqRetransTargetS3
On the other hand, in order to disable the ability to adapt 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.
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, …).
RNC
RadioAccessService
UlRbSetConf/ UlRbSetConf/
PS_EDCH PS_EDCH
PS_EDCH_MUX PS_EDCH_MUX
SRB EDCH SRB_EDCH
DynamicParameterForEdchTti10ms DynamicParameterForEdchTti2ms
ulSirStep ulSirStep
updateThreshold updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepFastDecrease edchSirStepFastDecrease
edchOlpcHfiRatioThreshold edchOlpcHfiRatioThreshold
edchOlpcServingRatioThreshold edchOlpcServingRatioThreshold
edchSirStepHfi edchSirStepHfi
edchLinkBalanceThreshold edchLinkBalanceThreshold
nHarqRetransTargetS1
NHarqRetransTarget 3 NHarqRetransTargetUeCat4 3 nHarqRetransTargetS2
3 instances : nHarqRetransTargetS3
nHarqRetransTargetS1
NHarqRetransTargetUeCat6 3
nHarqRetransTargetS2 nHarqRetransTargetS1
one instance
nHarqRetransTargetS3 nHarqRetransTargetS2
per OLS.
nHarqRetransTargetS3
Page 96/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The next figure shows the RAN model for the parameters defined per UL service
(including E-DCH UL services) and for other parameters.
RNC
RNC
RadioAccessService
RadioAccessService
DedicatedConf
DedicatedConf EdchRncConf
edchOlpcSamplingPeriodTti10ms
PowerConfClass 15 edchOlpcSamplingPeriodTti2ms
eligibleUeCategoryForSirTargetEdch2ms EdchCellClass 15
maxNumActiveEdchUsersPerCellForS1
maxNumActiveEdchUsersPerCellForS2
UlUsPowerConf/ UlUserService/
PS_EDCHxSRB_3_4K PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K CS_AMR_NBxPS_EDCHxSRB_3_4K
… …
initialSirTarget
minSirTarget
maxSirTarget UlOuterLoopPowerCtrl
initialSirTargetHsdpa
minSirTargetHsdpa ulUpdatePeriod
maxSirTargetHsdpa
initialSirTargetEdch2ms
minSirTargetEdch2ms
maxSirTargetEdch2ms
Figure 21: 34249 RAN model for E-DCH UL services and misc.
ulSirStep: Impacts the amplitude of each change in the Partial SIR Target related to
the E-DCH transport channel. Note that the formula giving Partial SIR Target for E-
DCH is different than the one for DCH.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 97/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter ulSirStep
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit 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 DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Integer [0 … 255], 0.1dB
User & Class Customer, 3
Value For UlRbSetConf/PS_EDCH and UlRbSetConf/SRB_EDCH: 1
(corresponds to 0.1dB)
Parameter edchNrOfConsecutiveZeroHarqReTxThreshold
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Integer [0 … 1024], N/A
User & Class Customer, 3
Value 200
edchSirStepFastDecrease: Step size used for Partial SIR Target update when “Fast
Decrease” mechanism has been triggered.
Parameter edchSirStepFastDecrease
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Signed [-0.300 … 0.000] step 0.005, dB
User & Class Customer, 3
Value -0.02
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 98/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
edchOlpcHfiRatioThreshold: Threshold applying to the HFI Ratio (Number of HFI
frames / Total number of valid frames after frame selection) quantity computed at the
end of each HFI monitoring period. In order to determine the current HFI Reception
Scenario, a comparison is done between HFI Ratio and
edchOlpcHfiRatioThreshold.
Parameter edchOlpcHfiRatioThreshold
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Integer [0 … 100], %
User & Class Customer, 3
Value [iCEM] [xCEM] 100
[UCU-III] 10
Parameter edchOlpcServingRatioThreshold
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Integer [0 … 100], %
User & Class Customer, 3
Value [iCEM] [xCEM] 0
[UCU-III] 50
edchSirStepHfi: Sequence containing the step size values for Partial SIR Target
update each time HFI Reception Scenario is updated. The 3 values of the sequence
correspond to {HFI 1, HFI 2, HFI 3}.
Parameter edchSirStepHfi
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit List of decimal [0.000 … 1.000] step 0.005, dB
User & Class Customer, 3
Value [iCEM] [xCEM] {0; 0; 0}
[UCU-III] {0.15; 0.1; 0.2}
Page 99/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Setting edchLinkBalanceThreshold to 1024 disables “UL/DL Imbalance Detection”
mechanism (i.e. disables VS.EdchLinkImbalance counter).
Parameter edchLinkBalanceThreshold
Object DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity RNC, UlRbSetConf, E-DCH TTI type
Range & Unit Integer [0 … 1024], N/A
User & Class Customer, 3
Value 200
Parameter nHarqRetransTargetS1
Object NHarqRetransTarget
Granularity RNC, UlRbSetConf, E-DCH TTI type, UE Category
Range & Unit Decimal [0.00 … 12.00], step 0.01 N/A
User & Class Customer, 3
Value For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget:0.07
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:0.04
See the engineering recommendation ‘Adaptative NHARQ’ below.
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:0.04
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 100/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
nHarqRetransTargetS2: NHARQ Target value used for UL OLPC when Cell State = S2.
Parameter nHarqRetransTargetS2
Object NHarqRetransTarget
Granularity RNC, UlRbSetConf, E-DCH TTI type, UE Category
Range & Unit Decimal [0.00 … 12.00], step 0.01 N/A
User & Class Customer, 3
Value For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.25
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:1.2
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:1.2
See the engineering recommendation ‘Adaptative NHARQ’ below.
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:0.04
nHarqRetransTargetS3: NHARQ Target value used for UL OLPC when Cell State = S3.
Parameter nHarqRetransTargetS3
Object NHarqRetransTarget
Granularity RNC, UlRbSetConf, E-DCH TTI type, UE Category
Range & Unit Decimal [0.00 … 12.00], step 0.01 N/A
User & Class Customer, 3
Value For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.85
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:1.5
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:1.5
See the engineering recommendation ‘Adaptative NHARQ’ below.
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti10ms/NharqRetransTarget: 0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat4:0.04
DynamicParameterForEdchTti2ms/NharqRetransTarget2msCat6:0.04
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 101/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The optimal target number of HARQ retransmissions (nHarqRetransTargetSx) and maximum active
EDCH users for cell state S1, S2 and S3 (maxNumActiveEdchUsersPerCellForSx) highly depend
on several aspects:
• The EDCH activity factor, ie. at busy hour, ratio of UEs actively transferring at high rate in uplink
vs UEs having sporadic or low rate uplink traffic)
• The UE Categories penetration factor (e.g ratio of Cat5 vs Cat6).
• The EDCH Mac-e throughput decoding capacity, i.e [xCEM] the full capacity of 10Mbps offered by
the feature 34633 may be restricted due to commercial agreement (Capacity Licencing).
• The available maximum UL Load
• The limiting factor which is hit first on a given cell (either UL Load or EDCH decoding capacity)
The recommended values provided in this document shall be considered as a guideline and could be
tuned more on the field.
Rule: nHarqRetransTargetSx
• For each E-DCH TTI type, the target average number of HARQ retransmissions 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 102/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
As explained in 9.1.1.2.2, for the case of SRB on E-DCH, there are two sets of
256H
nHarqRetransTargetSx parameters, one for the UL SRB MAC-d flow and one for the UL TRB
MAC-d flow. For the SRB MAC-d flow, in order to guarantee short transmission delay,
it is recommended to set NHARQ Target to a low and same value for all Cell States, as indicated
below.
Under:
[US] UlRbSetConf/SRB_EDCH/ DynamicParameterForEdchTti10ms/NharqRetransTarget:
UA6.0, UA7.0 - UA7.1 Delta: Nharq Target differentiation between E-DCH Cat4 and Cat6
In UA6.0 and UA7.0, the set of three NHarq retransmission targets was the same regardless of the E-
DCH UE Category. This set was defined in the object nHarqRetransTarget in the RAN model.
In UA7.1, it is possible to define distinct set of three 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.
Parameter isUlOuterPCActivated
Object UlOuterLoopPowerCtrl
Granularity RNC, UlUserService
Range & Unit Boolean {False, True}, N/A
User & Class Customer, 3
Value For all UlUserService instances*: True
* Except “SRB_CellFACH” and “TRBxSRB_CellFACH” for which UL OLPC does not apply
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 103/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
ulUpdatePeriod: Period between two UL SIR Target periodical updates, in number of
largest TTI (i.e. value is an integer) among the transport channels referenced for the
considered UL service.
Parameter ulUpdatePeriod
Object UlOuterLoopPowerCtrl
Granularity RNC, UlUserService
Range & Unit Integer [0 … 255], N/A
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] [UCU-III]: 250 (corresponds to 500ms since in this case largest TTI is the
TTI of the E-DCH transport channel (2ms))
Parameter initialSirTarget
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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] 257H
Parameter minSirTarget
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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] 258H
Parameter maxSirTarget
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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] 259H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 104/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
Parameter eligibleUeCategoryForSirTargetEdch2ms
Object PowerConfClass
Granularity PowerConfClass
Range & Unit BitString
User & Class Customer, 3
Value 0000000000101010
Parameter initialSirTargetEdch2ms
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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] 260H
Parameter minSirTargetEdch2ms
Object UlUsPowerConf
Granularity PowerConfClass, UlUsPowerConf
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] 261H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 105/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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
Granularity PowerConfClass, UlUsPowerConf
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] 26H
In UA6.0, the specific maximum SIR target required for E-DCH TTI2ms calls was ensured by a
hard-coded internal offset Max Sir Target Offset 2ms, applied on top of the configured
maxSirTarget. For UeCategory4 2ms calls, Max Sir Target Offset 2ms value was 2.6 dB. For
UeCategory6 2ms calls (with SRB on E-DCH), Max Sir Target Offset 2ms value was 2.1 dB.
on a per-call basis.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 106/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
due to the fact that specific {Reference E-TFCI; Reference Power Offset} tables are set for iCEM
xCEM and UCU-III, for E-DCH calls, it is strongly recommended to follow the board-specific SIR
targets parameters recommendations for all UlUsPowerConf instances with “PS_EDCH”. Refer to
the UPUG [R01] for the exhaustive recommended values.
265H
Configuration method:
• [GM] In case a network is deployed with iCEM and xCEM boards handling HSUPA calls, use
two specific PowerConfClass instances (one for iCEM and one for xCEM).
• For the PowerConfClass instance related to each type of board (iCEM and xCEM, or UCU-
III), set the UL OLPC SIR Targets parameters to the board-specific values as recommended
in the UPUG [R01]. 26H
• 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.
Parameter maxNumActiveEdchUsersPerCellForS1
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Integer [0 … 64] N/A
User & Class Customer, 3
Value See the engineering recommendation ‘Adaptative NHARQ’
Parameter maxNumActiveEdchUsersPerCellForS2
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Integer [0 … 64] N/A
User & Class Customer, 3
Value See the engineering recommendation ‘Adaptative NHARQ’
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 107/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
edchOlpcSamplingPeriodTti10ms: HFI monitoring period (for 10ms E-DCH TTI
case), i.e. period within which internal counters related to HFI reception are
incremented, and after which HFI Ratio and Serving Ratio quantities are computed.
Parameter edchOlpcSamplingPeriodTti10ms
Object EdchRncConf
Granularity RNC
Range & Unit Integer [0 … 500] step: 10, ms
User & Class Customer, 3
Value 100
Parameter edchOlpcSamplingPeriodTti2ms
Object EdchRncConf
Granularity RNC
Range & Unit Integer [0 … 500] step: 10, ms
User & Class Customer, 3
Value 20
9.2.1.1 INTRODUCTION
The feature “EDCH DL Control Channels Power Control” (33481) was originally
introduced in UA5.1 and has been improved in UA6.
It is available on xCEM and UCU-III.
It is not supported on iCEM (E-DCH DL channels are not power controlled).
This feature allows saving some DL power by performing power control of E-DCH DL
channels (E-AGCH, E-RGCH and E-HICH), hence the available NodeB power is
increased and the DL intra-cell and extra-cell interference are reduced.
As a reminder, this section and the following one only apply to xCEM and UCU-III.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 108/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
E-AGCH
Power control of E-AGCH channel is enabled and derived within the NodeB according
to the following formula.
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.
E-RGCH
Power control of E-RGCH channel is enabled and derived within the NodeB according
to the following formula.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 109/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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 E-
AGCH power, may be derived according to three different methods or a combination
of these methods. The three methods for the computation of E-DCH DL channels
base power are:
• Method based on DL DPCH channel power:
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 and then update
the power basing on the DL ILPC commands received from the considered
mobile. An offset* is also applied.
y both 10ms and 2ms E-DCH TTI (introduced in UA6): if 2ms E-DCH TTI is
used, an additional fixed power offset is applied on top of the E-DCH DL
channels power.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 110/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
because CQI based algorithm or DL DPCH transmit power based algorithm
provide yet good power levels.
All below parameters are xCEM or UCU-III specific (i.e. not used by iCEM).
BTSEquipment
OneBTSEquipment
pMinDlEDCH
BTSCell 0…12
pMaxDlEDCH
eagchPowerOffset
EdchConf 0…0 ehichErrorProbability
minPowerCorrection
pMinDlEDCH maxPowerCorrection
pMaxDlEDCH
eagchPowerControlModeXcem powerOffsetERGCHServingNoSHO
eagchPowerOffset commonERGCHPowerOffset
ehichErrorProbability
minPowerCorrection deltaDownServingCellNoHO
maxPowerCorrection
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset
9.2.1.3.2 PARAMETERS
For the recommended values on OneBTS UCU-III, please refer to the section 12 in
this volume.
The current section gives recommended values for xCEM.
pMinDlEDCH:
Power Control of E-DCH DL channels enabled:
Lower bound for “E-DCH DL channels base power” PE DCH(k). Value is relative to
CPICH Tx power.
Power Control of E-DCH DL channels disabled:
Power offset of E-HICH signature at serving NodeB, relative to CPICH Tx power.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 111/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter pMinDlEDCH
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value -25.0
pMaxDlEDCH: Upper bound for “E-DCH DL channels base power” PE DCH(k). Value is
relative to CPICH Tx power.
Parameter pMaxDlEDCH
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value -15.0
eagchPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to “E-DCH DL channels base power” PE DCH(k).
Power Control of E-DCH DL channels disabled:
Power offset of E-AGCH relative to CPICH Tx power.
Parameter eagchPowerOffset
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-45.0 … 65.0] step 0.1, dB
User & Class Customer, 3
Value Power Control of E-DCH DL channels enabled: 10.0
Power Control of E-DCH DL channels disabled: -4.0
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 112/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter powerOffsetERGCHServingNoSHO
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-12.8 … 12.7] step 0.1, dB
User & Class Customer, 3
Value 1.5
Parameter eagchPowerControlModeXcem
Object EdchConf
Granularity BTSCell
Range & Unit Boolean {Fixed, Dynamic}, N/A
User & Class Customer, 3
Value Dynamic
Parameter ehichErrorProbability
Object EdchConf
Granularity BTSCell
Range & Unit Integer [1 255], 0.1%
User & Class Customer, 3
Value 10 (corresponds to 1%)
Parameter minPowerCorrection
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-12.8 12.7] step 0.1, dB
User & Class Customer, 3
Value 0.0
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 113/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter maxPowerCorrection
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-12.8 12.7] step 0.1, dB
User & Class Customer, 3
Value 0.0
Remarks: Current recommendation is to disable “E-HICH Outer-Loop correction”
mechanism by setting minPowerCorrection = maxPowerCorrection.
document.
For information, the following parameter is also present in the RAN Model, but ignored
by the system:
.
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
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value 4.00
Parameter eagchPowerOffsetEdchTti2ms
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value 4.00
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 114/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Parameter ergchPowerOffset
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value -4.00
Parameter ergchPowerOffsetEdchTti2ms
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value -4.00
Parameter ehichPowerOffset
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value -4.00
Parameter ehichPowerOffsetEdchTti2ms
Object EdchCellClass
Granularity EdchCellClass
Range & Unit Signed [-32.00 31.75] step: 0.25, dB
User & Class Customer, 3
Value -4.00
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 115/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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.
[UCU-III]
It will be possible to extend the SRB on E-DCH as soon as all TRB are mapped on E-
DCH in the uplink, whatever the minSF and whatever the TTI value of the E-DCH
configuration. For UA6.0, the OneBTS does not support 2ms TTI. UCU-III supports up
to category 5, on 10 ms TTI only. It does not support category 6 (and it would be
managed like a category 4 on 10ms TTI). For UA7.1 onwards, the OneBTS supports 2
ms TTI for categry 2, 4 and 6 UEs as well as up to the 2SF2+2SF4 configuration for
category 6.
DL UL
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 116/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
In order to achieve right UL outer loop power control, feature PM 34249 EUL Capacity
Optimized HARQ Operation is needed. It may be not sufficient as there is no more 1x0
transport format in the Uplink.
In order to achieve right DL outer loop power control, 1x0 shall be used on the SRB
DPDCH when there is no data to be sent from SRB.
Restriction:
SRB over E-DCH is not supported during E-DCH FP over Iur, a fallback on DCH is applied in uplink for
SRB, in case the drift RNC controls the primary cell (mobile is considered as a category 4).
E-DCH FP over Iur is introduced by the feature 30744 allowing the SRNC to manage RABs mapped
over E-DCH in UL when a drift RNC controls the Primary Cell, thus allowing inter-RNC mobility for E-
DCH.
Parameters:
First, the feature flag activation.
• isSrbOnEdchAllowedWhenTrbOnEdch
Enable the possibility to map SRB on E-DCH in the UL for Cat 6 UE, while the call is
handling RAB(s) over E-DCH
• srbSpi
SPI used for SRB on E-DCH during a call. This parameter is located in srbQos under
Radio Access Service.
Three activation flags are added to the model, in the radio access service:
• isSrbOnEdchForAllEdchCategory: SRB on E-DCH for all E-DCH categories
o False: E-DCH cat 6 UE only
o True: All E-DCH categories
• isSrbOnEdchForAllMinSf: SRB on E-DCH for all NodeB minSF
o False: 2 SF2 + 2 SF4 minSF only.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 117/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
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
In UA6.0, the parameters used to configure the HSUPA UE categories, the Minimum SF, and the E-
DCH TTI eligible for SRB on E-DCH were the three first bits of reserved0 in RadioAccessService.
From UA7.0, three parameters are used: isSrbOnEdchForAllEdchCategory,
isSrbOnEdchForAllMinSf, isSrbOnEdchForAllEdchTti in RadioAccessService.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 118/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
• The following “datafill” rules are presented:
Rule:
d flow#2 parameters for UL: [max bit rate depending on UE category and TTI] SRBs
for E-DCH”
Restriction:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 119/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
• The engineering recommendations on parameter value are presented as the
following:
Hereafter are the typical values to be used on the different customers to support high bit-rate in UL:
US Market [UCU-III]
Model Configuration Value Meaning
isSrbOnEdchForAllEdchCategory True All UE Categories
isSrbOnEdchForAllMinSf True Whatever minSF
isSrbOnEdchForAllEdchTti True For all NodeB; For all TTI
Finally, as a reminder, the following are the usual settings that are required for a smooth operation of
the feature:
• The parameter enabledForRabMatching located under
RNC/RadioAccessService/UlUserService/PS_EDCHxSRB_EDCH must be set to
TRUE to ensure that the RAB matching algorithm would select SRB over E-DCH
when the call is eligible for such configuration.
• The parameter isAlwaysOnAllowed located under
RNC/RadioAccessService/UlUserService/PS_EDCHxSRB_EDCH must be set to
TRUE to ensure a good functioning of the Always-On algorithm for calls with SRB
over E-DCH.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 120/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
SRB on DCH/E-DCH + TRB PS on HSDPA/E-DCH <==> SRB on DCH/DCH + TRB
PS on HSDPA/E-DCH + TRB CS on DCH/DCH
RAB setup through incoming relocation:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 121/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
SRB on CELL_FACH + TRB on CELL_FACH <==> SRB on DCH/E-DCH + TRB PS
on HSDPA/E-DCH (10 ms) (US MARKET)
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-
DCH (10 ms) (US MARKET)
SRB on CELL_FACH + TRB on CELL_FACH <==> SRB on DCH/E-DCH + TRB PS
on HSDPA/E-DCH (2 ms) (US MARKET)
Call on CELL/URA_PCH state <==> SRB on DCH/E-DCH + TRB PS on HSDPA/E-
DCH (2 ms) (US MARKET)
Even if the SRB over e-DCH is tagged as an xCEM only feature, there are two
scenarios where the unidirectional DCH must be supported on iCEM boards:
• Call reconfiguration. This use case happens when the call is already
established on a NodeB that is composed by at least one iCEM and one
xCEM. The DCH SRB part is currently handled by the iCEM board and the
traffic TRB is currently handled by the xCEM. Upon whatever event, the RNC
decides to reconfigure the call with SRB on E-DCH and TRB on E-DCH &
HSDPA. If the reconfiguration on the TRB would not be an issue, the
successful reconfiguration of the SRB requires that the iCEM does support the
unidirectional DCH SRB.
• Mobility. This use case happens when the call is already configured with SRB
on E-DCH and when the UE is entering a NodeB containing at least an iCEM.
When the RNC will perform a RL setup to extend the DCH active set, the DCH
configuration will be a DL unidirectional DCH for SRB 3.4 kbps and an UL
DPCCH (only).
The mobility use case is the most important one. The RNC has no DCH fallback
procedure on a RL setup failure. Therefore if the NodeB would refuse unidirectional
DCH due to a non supported configuration that will probably end in a call drop. This is
applicable for iCEM.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 122/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
The call reconfiguration use case will be covered by the DCH fallback algorithm if the
reconfiguration fails. But as the mix of iCEM with xCEM will occur on site and as the
CCM load balancing may establish the DCH part of the call on a D-BBU on the iCEM,
the iCEM shall support the unidirectional DCH in order to increase the possibility for
SRB on E-DCH on the network.
The requirements to support unidirectional DCH on iCEM are:
• It is applicable to a DL SRB 3.4 kbps only
• RL restore and RL failure messages remain based on SIR only
• Reconfiguration of the DCH:
o 13.6 UL/DL ==> 3.4 DL only
o 3.4 UL/DL <==> 3.4 DL only
• UL DPCCH Slot Format remains 0
• iCEM capacity not degraded
On the HSDPA side, the channelization code of the HS-DPCCH will change according
to chapter 4.3.1.2.2 of [R06]. 273H
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 123/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
11.1 INTRODUCTION
In UA7.1 this feature will allow NodeB to switch to advanced receiver topology for a
subset of users that are experiencing dispersive channel conditions while providing
high data rates in UL. This capability is introduced through generalized RAKE
(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 and
PedB3 where non-line of sight multi-path dominates. The objective of this feature is to
reach max UL data rate fighting against ISI and inter OVSF code interference to
achieve a better EbNo as compared to RAKE. The following parameter is used to
activate this feature which is applicable to both xCEM and UCU-III modules.
[xCEM]
[UCU-III]
In UA7.1, due to risk of large performance regression for E-DCH mobility users (>15km/h speed) it was
not recommended to enable this feature in Live. This restriction was applicable to both channel cards.
With UA7.1.2 a fix has been introduced through 34393, 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/hr. This speed limit has been determined by means of empirical measurements and
simulations
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 124/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 125/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
12 ONEBTS PARAMETERS
The following tables are listed for parameters that are unique to the UA06 OneBTS
NodeB (USA market), and are under OAM object OneBTSEquipment.
[UCU-III]
eAGCHPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to “E-DCH DL channels base power” PE DCH(k).
Power Control of E-DCH DL channels disabled:
Power offset of E-AGCH relative to CPICH Tx power.
Parameter eAGCHPowerOffset
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-45.0 … 65.0] step 0.1, dB
User & Class Customer, 3
Value 10.0
Parameter eHICHErrorProbability
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Integer [1 255], 0.1%
User & Class Customer, 3
Value 10 (corresponds to 1%)
Parameter deltaDownServingCellNoHO
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Integer [1 1000], 0.01dB
User & Class Customer, 3
Value 20 (corresponds to 0.2dB)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 126/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
maxPowerCorrection: Upper bound for power offset of E-HICH signature relative to
“E-DCH DL channels base power” PE-DCH (k).
Remark: Current recommendation is to disable “E-HICH Outer-Loop correction”
mechanism by setting minPowerCorrection = maxPowerCorrection.
Parameter maxPowerCorrection
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-12.8 12.7] step 0.1, dB
User & Class Customer, 3
Value -3.0
Parameter minPowerCorrection
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-12.8 12.7] step 0.1, dB
User & Class Customer, 3
Value -3.0
powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to E-
HICH signature power of considered RL.
Remarks:
- For serving NodeB, only dedicated RG commands are used (at a given time, same
command is transmitted on all radio links).
- powerOffsetERGCHServingNoSHO applies to both E-DCH serving RL and E-DCH
non-serving RLs of serving NodeB (“NoSHO” has no specific meaning).
Parameter powerOffsetERGCHServingNoSHO
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-12.8 … 12.7] step 0.1, dB
User & Class Customer, 3
Value 1.5
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 127/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
pMaxDlEDCH: Upper bound for “E-DCH DL channels base power” PE DCH(k). Value is
relative to CPICH Tx power.
Parameter pMaxDlEDCH
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value 6.0
pMinDlEDCH: Lower bound for “E-DCH DL channels base power” PE DCH(k). Value is
relative to CPICH Tx power.
Parameter pMinDlEDCH
Object OneBTSEquipment
Granularity OneBTSEquipment
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value -18.0
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 128/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
edchServiceParameterSet2: This parameter set defines the OAM parameters,
which are valid for the interactive "silver" service class, i.e. with medium priority.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 129/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
edchServiceParameterSet4: This parameter set defines the OAM parameters,
which are valid for the background service class.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 130/131
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 4: HSUPA Principles, Scheduling & Resource Management
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 131/131
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
5 CALL MANAGEMENT
Alcatel-Lucent – Proprietary
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
CONTENTS
1 INTRODUCTION............................................................................................................................5 21H
6.3 IUB/IUR CONGESTION MANAGEMENT FOR PS STREAMING RAB ON EDCH ................................47 51H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
7.2 RAB ALLOCATION PHASE: .......................................................................................................51 57H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
TABLES
Table 1: HSDPA RB Configuration and system behaviour
0H 8 81H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
FIGURES
Figure 1 : HS-DSCH power reservation at call admission ........................................................................... 14
7H 8H
Figure 5: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 51
1H 92H
Figure 6: HSUPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 52
12H 93H
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates = none) ........... 62
16H 97H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system description, configuration aspect and engineering
recommendations.
Global US
PM ID Feature Title Activation flag Release
market Market
Always-on On isAlwaysOnAllowed
27942 UA4.2 Yes Yes
HSDPA
HSDPA Radio N/A UA4.2 Yes Yes
27945
Bearer
Multi-Services N/A
30741 Handling On UA5.0 Yes Yes
HSUPA
Multi-RAB Handling isMultiRabOnHsdpaAllowed UA5.0 Yes Yes
29797
on HSDPA
edchToDchFallbackPermission
HSDPA to DCH UA5.0 Yes Yes
32602
fallback edchToDchFallbackSteps
isGbrOnHsdpaAllowed (used
29804 GBR on HSDPA only to map Streaming on UA6.0 Yes Yes
HSDPA)
New RAB and N/A
33320 combinations for UA6.0 Yes Yes
UA06
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
RNC:
isHsxpaR99ResourcesSharing
OnCellAllowed
NodeB:
Fair Sharing of
[iCEM] [xCEM] UA6.0 Yes Yes
33694 Resources -
HSDPA vs DCH BTSEquipment::hsdpaCodeTre
eManagementActivation
[UCU-III]
OneBTSEquipment::hsdpaCod
eTreeManagementActivation
isThreeRabAllowed
isMpdpExtendedRabCombsAll
owed
34170 3 PDP Support UA6.0 No Yes
mpdpInactivityIuRelease
isMpdpExtendedRabCombsAll
owed
Multiple PS I/B on isMultiRabOnEdchAllowed UA7.1 Yes No
34018
HSUPA
edchMaxLegs2msPerCell [GM]
UA7.1.2
CAC algorithm edchMaxUsersPerCell Yes Yes
34441.1
evolution [US]
UA7.1.3
Streaming on isStreamingOnEdchAllowed UA7.1.2 Yes No
30742
EDCH
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
HSxPA only applies to the PS domain meaning that the entire CS domain RABs are
supported on dedicated channels (DCH).
From UA6.0, Utran supports the Traffic Classes Streaming, Interactive & Background
on HSDPA. And, the TC Streaming is only served on DCH if the end-to-end latency
requirements are too stringent (more details are presented on Chapter 3.of this 102H
volume)
PS Streaming on
Supported on HSDPA (from UA6)
HSDPA
Speech on DCH +
Supported (from UA5.0)
PS I/B on HSDPA
CSD/DCH + PS I/B
Supported (from UA5.0)
on HSDPA
Speech on DCH +
(PS+PS) on Supported (from UA5.0)
HSDPA
(PS I/B+PS
Streaming) on Supported (from UA6.0)
HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
RB Configuration System behaviour
All RABs DCH Supported: no impact coming from HSDPA. All RAB combinations existing in
available in HSUPA this release are available on DCH in an HSDPA cell (either for a mobile that
Cell does not support HSDPA or for a RAB combination that is not supported on
HSDPA)
Speech on DCH +
Supported on HSUPA in UA7.1
(PS+PS) on HSUPA
3 HSXPA CAC
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:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Parameter transportTypeSelectionTransferDelayThreshold Object HsdpaRncConf
Range & Unit Integer [0 … 65536] seconds
User Customer Granularity RNC
Class 3
Value 0
This parameter is not useful. That is why the recommendation is to set his value to 0. In this case, the
mapping of a PS Streaming RAB on HSDPA is independent on the CN transfer delay. Then, the
conditions to map a PS Streaming on HSDPA are:
- the mobile is HSDPA capable,
Note that the parameter is only used to allow or not the mapping of PS Streaming Rab
on HS-DSCH. This parameter activates no GBR algorithm. GBR algorithms (introduce
with the feature 29804 “GBR on HSDPA”) are enabled by default:
- NodeB: New mac-hs scheduler behaviour when the mac-hs GBR IE is
received (higher priority for mac-hs GBR users and computation of the HS-
DSCH required power)
- RNC: Computation of the mac-hs GBR used by the Fair Sharing feature and
eventually sent to the NodeB
details). At reception of this IE, the mac-hs scheduler activates a new behaviour
allowing to
- Schedule with a higher priority the mac-hs GBR users (see [Vol. 3] for more 105H
details).
- Report from the NodeB to the RNC the power needed to guarantee the mac-hs
GBR (this information is reported through the new NBAP 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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).
In the previous releases, the specific CAC admission process in the RNC for
HSDPA/HSUPA is based on the number of simultaneous authorized users per cell to
limit the degradation of the quality of service. So, iRM CAC is not played for
HSDPA/HSUPA RAB. In UA6.0, thanks to the Fair Sharing and GBR features, some
resources (power and codes) can be reserved for HSDPA in order to guarantee a
certain QoS. In this case, the CAC for HSDPA is no more based on the number of
HSDPA users but based on the available resources (as for DCH).
In UA6.0, if the Fair Sharing is disabled, the RNC CAC is based on the number of
HSDPA users as in the previous releases
(isHsxpaR99ResourcesSharingOnCellAllowed = False): Any PS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Interactive/Background RAB request is admitted on HSDPA until the maximum
number of simultaneous users allowed on HSDPA is reached for the cell. Unlike the
iRM CAC performed for the RB mapped on DCH channels, the admission on HSDPA
does not take into account any other criterion such as RF power. After this, for E-DCH,
any PS I/B RAB request is admitted on E-DCH, provided that the considered cell
supports E-DCH. If HSDPA CAC fails, then both the uplink and the downlink are fall-
backed to DCH. In case of RNC CAC failure (maximum number of HSDPA or HSUPA
users), the HSPA to DCH Fallback mechanism is triggered (see Section 3.3). 108H
more details).
Target Bitrate
The target bitrate is equal to:
a mac-hs GBR
or to the parameter minHsDschReservationForCac if the mac-hs GBR is
null
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 12/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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):
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.
PS STR RAB with RANAP GBR > 0 min(RANAP GBR; RANAP MBR) + RLC/MAC headers
PS I/B RAB with minBr > 0 min(minBrForHsdpa, RANAP MBR) + RLC/MAC headers
For HSDPA-DC call in UA7.1.2, 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. 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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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)
dlTxPowerEstimation
initialActivityFactorForIb
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
For non GBR mac-d flows (see 3.1 for definition of non GBR user), the power
10H
As mentioned in 3.1, the operator has the choice to consider a PS I/B user as a mac-
12H
hs GBR user (same behaviour as a PS Streaming user). For that, the mac-hs GBR
has to be different from 0 (minBrForHsdpa > 0) and the parameter
isDlPowerSelfTuningForPsIbAllowed has to be set to True. This configuration
allows the scheduler to really try to enforce this mac-hs GBR.
Then, a GBR mac-d flow corresponds either to a Streaming RAB or to a PS I/B RAB if
a minBrForHsdpa has been defined (non null) and
isDlPowerSelfTuningForPsIbAllowed is True.
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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:
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
HS-PDSCH codes reservation
Target Bit Rate
ovsfCodesThroughputXXUe
XX = QPSK or 16QAM
reservationFactorOnCodesForGbrTraffic
reservationFactorOnCodesForGbrTraffic
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 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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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) 13H
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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)
- 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
- 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
Note that the DCTM feature and RNC Fair Sharing algorithm are totally exclusive
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Parameter isDlPowerSelfTuningForPsIbOnHsdpaEnabled Object FDDCell
Range & Unit Boolean {True; False}
User Customer Granularity Cell
Class 3
Value True to consider PS I/B users as a GBR users (power reservation updated
periodically and higher priority of scheduling), False otherwise.
Rule: isDlPowerSelfTuningForPsIbOnHsdpaEnabled
When this flag is set to True, the HSDPA power reserved by the RNC is updated thanks to the NBAP
common measurement “HS-DSCH required power” reported by the NodeB.
This message informs the RNC of the power needed to guarantee the GBR. Basically, the estimation
of this required power to guarantee the GBR is done by the scheduler knowing the current throughput
and the current HSDPA power consumed by the NodeB.
Considering a constant power consumption for HSDPA (in general, equal to Pcpich + MPO for a single
HSDPA user), the “HS-DSCH required power” will increase when the current throughput will decrease.
Then, the cell capacity can be reduced when the ue is in bad RF conditions (low throughput).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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 2 N/A
3
N/A
1 -
Streaming 2 -
3 -
1 minBrForHsdpa = 16 kbps
1 2 minBrForHsdpa = 8 kbps
3 minBrForHsdpa = 8 kbps
1 minBrForHsdpa = 16 kbps
Interactive 2 2 minBrForHsdpa = 8 kbps
3 minBrForHsdpa = 8 kbps
1 minBrForHsdpa = 16 kbps
3 2 minBrForHsdpa = 8 kbps
3 minBrForHsdpa = 8 kbps
1 minBrForHsdpa = 4 kbps
Background 2 N/A minBrForHsdpa = 4 kbps
3 minBrForHsdpa = 4 kbps
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 doesn’t allow to use normally these defaut values. Please refer to the the restriction
box below for details.
2- No resource reservation:
The simpler way to reserve nothing for HSDPA should be to set minBrForHsdpa to 0kb/s.
Nevertheless, set 0kb/s can lead to HSDPA call drop in case of transport congestion. That is why the
minimum value for minBrForHsdpa is 4kb/s (to avoid any HSDPA call drop in case of transport
congestion). With 4kb/s, the resources reserved are low. But to really reserve nothing for HSDPA
(best effort), the recommendation is to set :
reservationFactorOnCodesForGbrTraffic = 0%
initialActivityFactorForIb = 0%
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = False
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Traffic Class ARP THP Target Bit Rate
1
Conversational 2 N/A
3
N/A
1 -
Streaming 2 -
3 -
1 minBrForHsdpa = 128 kbps
1 2 minBrForHsdpa = 128 kbps
3 minBrForHsdpa = 128 kbps
1 minBrForHsdpa = 100 kbps
Interactive 2 2 minBrForHsdpa = 100 kbps
3 minBrForHsdpa = 100 kbps
1 minBrForHsdpa = 4 kbps
3 2 minBrForHsdpa = 4 kbps
3 minBrForHsdpa = 4 kbps
1 minBrForHsdpa = 128 kbps
Background 2 N/A minBrForHsdpa = 100 kbps
3 minBrForHsdpa = 4 kbps
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 22/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Traffic Class ARP THP Target Bit Rate
1
Conversational 2 N/A
3
N/A
1 -
Streaming 2 -
3 -
1 minBrForHsdpa = 128 kbps
1 2 minBrForHsdpa = 100 kbps
3 minBrForHsdpa = 4 kbps
1 minBrForHsdpa = 128 kbps
Interactive 2 2 minBrForHsdpa = 100 kbps
3 minBrForHsdpa = 4 kbps
1 minBrForHsdpa = 128 kbps
3 2 minBrForHsdpa = 100 kbps
3 minBrForHsdpa = 4 kbps
1 minBrForHsdpa = 4 kbps
Background 2 N/A minBrForHsdpa = 4 kbps
3 minBrForHsdpa = 4 kbps
Note that the values used in these tables for minBrForHsdpa and especially 128kb/s and 100kb/s are
given as an example. These values can be tuned according to a 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.
minBrForHsdpa is used by Fair Sharing feature (for RNC CAC) but also by Iub congestion
management algorithm.
From a transport point of view, minBrForHsdpa is the throughput allowed during a transport
congestion state. In order to be in line with the EBR value (EBR is used for transport CAC),
minBrForHsdpa should be lower or equal to EBR (if EBR > 0).
Note that the minBrForHsdpa is respected during Iub congestion regardless of the setting for the
enhancedQualityOfService flag (used for the feature 97431 - “HSDPA OLS Differentiation at NodeB
Level”. See [R04] and Volume 3 for more details on this parameter and this feature).
14H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
With the default value (-35dB), the power reserved at call admission is very low.
Anyway, this power will be updated for mac-hs GBR (PS I/B or PS Streaming) users thanks to the HS-
DSCH required power sent by the NodeB to the RNC.
For non mac-hs GBR (PS I/B only) users, the power reserved is never updated during the call. So, in
order to reserve a more realistic amount of power, dlTxPowerEstimation can be set with the
following values :
dlTxPowerEstimation = [-5, -3, -2, -2, -2, -2, -2]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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).
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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Parameter initialActivityFactorForIb Object HsxpaR99ResourcesSharingCellClass
Range & [0..100] %
Unit
User Customer Granularity RNC
Class 3
Value 100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value
- 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)
From UA7.1.2, the call admission is enhanced in RNC with a CAC for E-DCH users
(feature 34441.1).
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 checks if the current total number of simultaneous serving E-DCH
legs and non-serving E-DCH legs is equal or above the CAC threshold for E-DCH
legs, edchMaxUsersPerCell. If this is true, the call is handled as follows:
If the check fails for the E-DCH serving RL, the call is fall-backed to UL DCH.
If the check fails for a non-serving RL, the failed Radio Link is added to the
DCH active set but not added to E-DCH active set.
For a 2ms E-DCH radio link case, this current total number is also compared against
the edchMaxLegs2msPerCell threshold and the call is handled as follows:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
If the check fails for the E-DCH serving RL, the call is setup as 10ms TTI E-
DCH call
If the check fails for a non-serving RL, the failed Radio Link is added to the
DCH active set but not added to E-DCH active set
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.
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). On reception of this failure message the
SRNC handles the call as follows:
If the failure occured for the E-DCH serving RL, the call is fall-backed to DCH
(the DRNC sent the failure cause "Requested Configuration not supported")
or setup as 10ms TTI E-DCH call (the DRNC sent the failure cause ”E-DCH
TTI2ms not supported”).
If the failure occured for a non-serving E-DCH RL, the failed Radio Link is
added to the DCH active set but not added to E-DCH active set
The parameter edchMaxUsersPerCell defines the maximum number of simultaneous
serving and non-serving EDCH legs per cell.
edchMaxUsersPerCell has been defined in the RAN model for a long time, but is not used before
UA7.1.2. It is used from UA7.1.2 onwards.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
The parameter edchMaxLegs2msPerCell defines the maximum number of
simultaneous serving 2ms TTI E-DCH legs and non-serving 2ms TTI E-DCH legs per
cell.
Rationale: E-DCH TTI2ms calls are heavy consumers of CE baseband decoding capacity. In case of
many E-DCH TTI2ms calls doing high uplink traffic, the throughput per user become identical or even
worst compared with the scenario where only E-DCH TTI10ms is used.
Note that the amount of users above which it is preferable to use TTI10ms depends on the traffic
profile and the cell to CE board mapping.
Each of these modules has some capacity limitations and this capacity is limited
through some sets of parameters (see [R05]). 120H
If one of the E-BBU or H-BBU limit is reached, the BTS will send a RL Reconfiguration
Failure (meaning NodeB CAC failure)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
In case of BTS CAC failure (not enough HSDPA or HSUPA resources), the HSPA to
DCH fallback mechanism is triggered (see section 3.3)) 12H
Note that the NodeB CAC is unchanged whatever the Fair Sharing activation status
may be.
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)
HSxPA-to-DCH fallback is not allowed when CAC occurs for shared resources.
Restriction:
HSPA to DCH fallback at Always-On upsize is not supported. However, fallback at Always-on upsize
is triggered when a second RAB is being established (either CS or PS).
RNC tries and remaps a call establish “fall-backed to DCH RAB” onto HSDPA or
HSUPA in the following cases:
• RAB assignment (to establish or to release a second RAB)
• Primary Cell change
• Inter-RNC (UE involved or not) HHO
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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.
For the HSxPA CAC failure scenarios mentioned above, when RNC receives NBAP
RadioLinkReconfigurationFailure, DCH fallback is systematically triggered whatever
the NBAP cause (even for NodeB_resource_unavailable). However, when receiving a
cause that gives specific information on UL or DL, RNC directly takes the good
decision, depending on the different permissions presented below.
HSDPA is directly reconfigured into DCH whereas 2 steps can be provisioned for
HSUPA through edchToDchFallbackSteps parameter:
• MonoStep to directly reconfigure HSUPA into DCH
• MultiStep to try and reconfigure first into HSDPA (and then into DCH in case
of HSDPA CAC failure)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
In such a case, counter VS.RadioLinkReconfigurationPrepareUnsuccess for screening
RadioLinkReconfigurationFailure will be pegged twice for the same RAB Assignment
procedure.
Both permissions should be set to AnyCase in order to improve Accessibility and Retainability.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
• dch ↔ hs-dsch:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 33/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
• 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
deltaCfnForHsdpaChannelTypeSwitching: Delta CFN used for SRLR due to
channel type switching between DCH and HS-DSCH
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 35/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Reconfiguration procedure. It is possible to use either a synchronous or an
asynchronous procedure.
Restriction:
• UL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC
entities so lose all PDUs under transmission).
• The UE RLC Queue Size is never reconfigured. The implication is that if a R6 mobile is
performing the RAB Assignment procedure in non-E-DCH cell, the RLC Queue Size of the
resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is
subsequently transitioned to a e-DCH cell.
Parameters:
isRlcReconfigurationForChannelTypeSwitchingEdch: Activation of the RLC
reconfiguration during a channel type switching between DCH and E-DCH.
Parameter isRLCReconfigurationForChannelTypeSwitchingEdch Object EdchRncConf
Range & Boolean
Unit {True, False}
User Customer Granularity RNC
Class 3
Value True
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
deltaCfnForEdchAndHsdpaChannelTypeSwitching: Delta CFN used for SRLR due
to channel type switching of both HSDPA and E-DCH.
Values shown above for deltaCfnForEdchXXX are the default ones. These parameters are not used
when Enhanced Dynamic Delta CFN feature is active (isSrlrDeltaCfnOptimized set to True), which is
the recommended configuration. If the feature is disabled, optimization of these parameters may be
necessary.
5 MULTI-RAB HANDLING
5.1.1 PRINCIPLES
The feature Multi-Rab Handling on HSDPA allows handling the following
configurations:
• CS speech DCH + PS i/b HSDPA
• CSD DCH + PS i/b HSDPA
• PS i/b HSDPA + PS i/b HSDPA [+CS speech]
• PS i/b HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCU-III only)
• PS streaming DCH + PS i/b HSDPA [+CS speech]
• PS streaming HSDPA + PS i/b HSDPA [+CS speech]
• PS streaming HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCU-
III only)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
• 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).
Note: when the feature is deactivated, then the resulting DlUserService will be
mapped on DCH only.
Secondly, an activation flag for 3 PDP contexts (3 x I/B or 2 I/B + 1x Streaming) is
used to restrict the number of PS RABs in the RNC. This will over-ride any settings of
three RABs in HSDPACombinationList described below.
Page 38/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Rule:
When the multi-RAB on HSDPA is activated, it is recommended to ensure that the related
DlUserService are enabled for RAB Matching:
• Speech + HSDPA
• CSD + HSDPA
• PS Streaming (DCH or HSDPA) + HSDPA
• Speech + PS Streaming (DCH or HSDPA) + HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 39/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Allowed
/0 /0 TRUE TRUE
/0 /1 FALSE FALSE
/1 /0 FALSE FALSE
/1 /1 FALSE FALSE All DluserService
/2 /0 FALSE FALSE without HSDSCH
/2 /1 FALSE FALSE
/3 /0 FALSE FALSE
/3 /1 FALSE FALSE
/0 /0 FALSE FALSE CS_64K + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 FALSE FALSE CS_64K + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_64K + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 FALSE FALSE CS_64KxPS_HSDSCH CS_64K + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 TRUE TRUE xSRB_3_4K CS_64K + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE CS_64K + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE CS_64K + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE CS_64K + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE CS_AMR + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 TRUE TRUE CS_AMR + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_AMR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 TRUE TRUE CS_AMR_NBxPS_HSD CS_AMR + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 TRUE TRUE SCHxSRB_3_4K CS_AMR + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE TRUE CS_AMR + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE TRUE CS_AMR + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE CS_AMR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE CS_AMR + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 TRUE TRUE CS_AMR + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_AMR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 TRUE TRUE CS_AMR_WBxPS_HS CS_AMR + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 TRUE TRUE DSCHxSRB_3_4K CS_AMR + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE CS_AMR + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE CS_AMR + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE CS_AMR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE CS_AMR_NBxPS_xxK_ CS_AMR + PS_xxK_STR + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
STRxPS_HSDSCHxSR
/0 /1 FALSE FALSE B_3_4K CS_AMR + PS_xxK_STR + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_AMR + PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 FALSE FALSE CS_AMR + PS_xxK_STR + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE CS_AMR + PS_xxK_STR + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 40/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
/3 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE CS_AMR + PS_xxK_STR + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE CS_AMR + PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 FALSE FALSE CS_AMR_WBxPS_xxK CS_AMR + PS_xxK_STR + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
_STRxPS_HSDSCHxS
/2 /0 FALSE FALSE RB_3_4K CS_AMR + PS_xxK_STR + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE CS_AMR + PS_xxK_STR + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE CS_AMR + PS_xxK_STR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE PS_xxK_STR + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 FALSE FALSE PS_xxK_STR + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE PS_xxK_STR + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 FALSE FALSE PS_xxK_STRxPS_HSD PS_xxK_STR + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 FALSE FALSE SCHxSRB_3_4K PS_xxK_STR + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE PS_xxK_STR + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE PS_xxK_STR + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE PS_xxK_STR + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE PS_39_2K_VoIP + 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 FALSE FALSE PS_39_2K_VoIP + 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE PS_39_2K_VoIP + 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 FALSE FALSE PS_39_2K_VoIPxPS_H PS_39_2K_VoIP + 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 FALSE FALSE SDSCHxSRB_3_4K PS_39_2K_VoIP + 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE FALSE PS_39_2K_VoIP + 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE FALSE PS_39_2K_VoIP + 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE PS_39_2K_VoIP + 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/0 /0 FALSE FALSE 0xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/0 /1 TRUE TRUE 0xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/1 /0 TRUE TRUE 1xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/1 /1 TRUE TRUE PS_HSDSCHxSRB_3_ 1xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/2 /0 TRUE TRUE 4K 2xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/2 /1 FALSE TRUE 2xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
/3 /0 FALSE TRUE 3xPS_HSDSCH_IB + 0xPS_HSDSCH_STR + SRB_3_4K
/3 /1 FALSE FALSE 3xPS_HSDSCH_IB + 1xPS_HSDSCH_STR + SRB_3_4K
5.2.1 PRINCIPLES
Unlike multi service on HSDPA, there is no activation flag to enable or disable the
multi RAB on HSUPA.
The activation is done thru the parameter enabledForRabMatching in UluserService
Object for the following instances:
• Speech + E-DCH
• CSD + E-DCH
• PS Streaming + E-DCH
• Speech + PS Streaming + E-DCH
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 41/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Note: if the related UlUserServcie are not allowed to be used by the RAB Matching,
there is no fallback on DCH, implying RAB Assignment Failure during RB
Setup.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 42/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Supports of the following new RBs are now available:
PS+PS on E-DCH
CS+PS+PS on E-DCH
The 34018 - Multiple PS on E-DCH, shall not be activated if 34170 - 3 PDP Contexts Support in
UTRAN is activated, a check is added. So, the following parameter for the Global Market case, should
be set to:
- isThreeRABAllowed = False
Inversely, for the US Market the following parameter should be set to:
- isMultiRabOnEdchAllowed = False
Rule: activation of multi RAB on HSDPA before activation of multi RAB on HSUPA
Finally, there’s another parameter that gives the allowed EDCH configuration in terms
of supported PS RAB for each traffic class. So, for each UlUserService, the sequence
shown below will indicate which MUX EDCH combination is allowed or not.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 43/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
EdchCombinationList [0..3]
refers to the number of allowed PS I/B EDCH
} Related to multiple PS/IB on HSUPA
(PM34018)
EdchCombinationEntry [0..1]
refers to the number of allowed PS STR EDCH } Related to streaming over HSUPA
(PM30742)
AllowedList (boolean, boolean)
refers to the number of allowed CS Voice EDCH
[iCEM] [UCU-III]
The feature is supported only by the xCEM. This feature is not required for
OneBTS/UCUIII in V7 and also not possible with iCEM.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 44/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
8 new RAB combinations are available:
PS streaming on E-DCH will use 656 bit MAC-d PDU size, while PS I/B, can have
either 336 bit or 656 bit.
Before setting up the uplink streaming RAB, the RNC shall check if setup is on E-DCH
or DCH. In particular, the RAB shall be setup on DCH, if the RANAP Transfer Delay is
below the configurable threshold and so, the following parameter is used:
[iCEM] [UCU-III]
The feature is only supported by the xCEM.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 45/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
The RANAP GBR provided by the CN has to be rescaled to take into account the
RLC/MACd header sizes and the result is:
RANAP GBR: provided by the CN and range can go from 0 to16000000 [bit/s].
RLCHeaderSize: (manufacturer data) depend on the RLC type of the RbSet. It is 24 for Acknowledged Mode
which is the mode used for PS Streaming [bits]
MACdHeaderSize: (manufacturer data) is equal to 0 for HSDPA DL RbSets because HSDPA MACd flows are
not multiplexed. [bits]
24 24
In case MACes GBR > 2 -1, then MACes GBR = 2 -1
Max UECapabilityRate: Maximum physical data rate given by UE category and applied TTI [kbps]
⎧ MBR × TTI ⎫
MACes PDU Size = ceil ⎨ ⎬ × MACd PDU Size + MACes HeaderSize + SI Size [bits]
⎩ RLC PDU Size ⎭
RLC PDUSize: For PS streaming the Packet Data Unit size in the Radio Link Control is 640 [bits]
MACd PDUSize: For PS streaming the Packet Data Unit size in the MACd layer is 656 [bits]
MACesHeaderSize: MACes header size is 18 in case of 1x PS RAB and 36 in case of 2xPS RAB [bits]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 46/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
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
Concerning Iub: There's no efficient way in the NodeB to reduce the rate of
a given MACd flow for UEs having multiple EDCH MACd flows, because the
grant provided to the UE is only global. It is up to the UE to reduce whatever
flow it wants in line with the grant.
Mitigating a worst case scenario (when the UE has a PS STR + PS I/B flow,
whit the streaming QoS congested and the decision is taken to reduce only
the PS I/B, when the right way to handle it would be to leave the I/B flow
unchanged and reduce the streaming progressively from MBR), it is likely that
for most multiple MACd flow scenarios, the I/B flow has a low rate at the time
the streaming session is active, so that a reduction of global rate does reduce
the streaming rate right away.
The conclusion is that a progressive reduction of grants is sufficient to handle
the congestion.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 47/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
IuxFpHeaderSize: corresponds to the header size of the Iub interface. Values is equal to 7 for header + 2 or 5
at the end of the payload [octets]
IuxFp GBR: corresponds to the bandwidth reservation allocated to IuxFp. Is is based on the RANAP GBR
and taking into account the RLC/MACd/IuxFp header sizes
The corrective factor is configurable by the operator and should optimise the use of
the resources given the real conditions (e.g.: protocol overheads) in order to help
determining a more precise EBR.
The recommended value for edchTransportEbrCorrectiveFactor is shown below:
For GBR users over EDCH, a new load measure can be performed. When CAC is
activated, the NodeB shall provide the following enhancements to the existing CAC
functionality by adding LoadEDCH_GBR to LoadNon-EDCH as described below:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 48/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
If no CAC available and if more EDCH GBR services are requested, than what can be
admitted, the E-DCH scheduler will still give priority to the streaming service but it
would not be able anymore to serve all STR users with their GBR. In consequence,
some (new or existing) streaming users (e.g.in SHO condition), will see degradation in
their performance.
On the reception of the NBAP failure message for E-DCH streaming service, the RNC
shall fall back to DCH.
The following parameter enables or disables the NodeB CAC for E-DCH GBR service:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 49/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
RRC/ RACH / RRC connection Request The RRC Connection Request message initiated
by the UE contains the establishment cause.
NBAP / RL Setup
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)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 50/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
NBAP/ Radio Link Reconfiguration Request ( A HS-DSCH Radio Link is created as well as the
associated DCH
HS-DSCH Radio Link)
The RAB is now established. the mobile is now waiting for end-to-end
service accept.
Figure 5: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 51/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
UE Node B RNC SGSN
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
The RAB is now established. the mobile is now waiting for end-to-end
service accept.
Figure 6: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 52/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 53/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
UE Node B RNC SGSN
SCCP/ Released
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 54/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
9 RRM ALGORITHMS
9.1 ALWAYS-ON
9.1.1 MECHANISM
The Always-on mechanism applies to HSDPA in DL and E-DCH in UL the same way
as for R99 DCH radio bearers. Only Interactive/Background QoS traffic classes are
eligible to Always-on.
Note: Always-on does not apply if the 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:
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. Let’s introduce them in the next
chapters.
transitions):
• Normal Mode: In this state the session is operating with the original
RB that was allocated at call admission or reconfigured by other PS
Call Management features (RB Adaptation, iRM Scheduling, iRM Pre-
emption). For a session to be maintained in this state, the user traffic
must remain above a predefined threshold: if it falls and stays below
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 55/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
this threshold during a given period of time, the RAB is downsized. A
session is returned to this state, from Idle mode or downsized mode,
if:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 56/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
The simplified state transitions are shown in Figure 8. 127H
Downsizing Release
(Tdownsize expiry) (Tinactivity expiry)
URA_PCH
Normal Idle
CELL_FACH
mode mode
Upsizing CELL_PCH
(Traffic
resuming)
Downsized mode
RB Ré-establishment
(Traffic resuming)
(Tinactivity expiry)
9.1.3.1 ACTIVATION
Always-on has to be activated for HSDPA and E-DCH. Several parameters are to be
set:
• First, Always-on has to be activated on RNC :
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 57/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Parameter isAlwaysOnAllowed Object DlUserService
Range & Unit Boolean
{True, False}
User Customer Granularity DlUserService
Class 3
Value See table below
DlUserService isAlwaysOnAllowed
CS_64KxPS_HSDSCHxSRB_3_4K True
CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K True
CS_AMR_NBxPS_64K_STRxPS_HSDSCHxSRB_3_4K True
CS_AMR_NBxPS_128K_STRxPS_HSDSCHxSRB_3_4K True
CS_AMR_NBxPS_256K_STRxPS_HSDSCHxSRB_3_4K True
CS_AMR_NBxPS_HSDSCHxSRB_3_4K True
PS_16K_STRxPS_HSDSCHxSRB_3_4K True
PS_64K_STRxPS_HSDSCHxSRB_3_4K True
PS_128K_STRxPS_HSDSCHxSRB_3_4K True
PS_256K_STRxPS_HSDSCHxSRB_3_4K True
PS_HSDSCHxSRB_3_4K True
DlRbSetConf isAlwaysOnAllowed
PS_HSDSCH_IB degraded2AlwaysOnOnly
PS_HSDSCH_IB_MUX releaseOnly
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 58/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
UlUserService isAlwaysOnAllowed
CS_64KxPS_EDCHxSRB_3_4K True
CS_AMR_NBxPS_16K_STRxPS_EDCHxSRB_3_4K True
CS_AMR_NBxPS_32K_STRxPS_EDCHxSRB_3_4K True
CS_AMR_NBxPS_128K_STRxPS_EDCHxSRB_3_4K True
CS_AMR_NBxPS_EDCHxSRB_3_4K True
PS_16K_STRxPS_EDCHxSRB_3_4K True
PS_32K_STRxPS_EDCHxSRB_3_4K True
PS_128K_STRxPS_EDCHxSRB_3_4K True
PS_EDCHxSRB_3_4K True
UlRbSetConf isAlwaysOnAllowed
PS_EDCH degraded2AlwaysOnOnly
PS_EDCH_MUX releaseOnly
The RNC shall not send RAB Release or Iu Release with cause "User Inactivity" for Streaming RAB.
For that reason, associated PS I/B (DCH or HSDSCH) which are used for the signalling should not be
downsized/released by Always-on.
The 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] 129H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 59/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
9.1.3.2 MODES
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 60/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH CELL FACH t
CELL PCH / URA PCH
Downsize timer
Step 1
(timerT1ForHsdpa, Downsize
timerT1ForHsdpaAndEDch) timer
Step 2 Downsize
(fachToCellPchTimer, timer
fachToUraPchTimer) Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer) t
Traffic UL/DL
Page 61/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Low activity /
Activity (UL or DL) Inactivity
Downsize
Release
t
Traffic UL/DL
In this mode, the Always-on feature directly releases the user after a period T2 of
inactivity. The timers used are:
o timerT2ForHsdpa in case of HSDPA only
o timerT2ForHsdpaAndEdch in case HSDPA & DCH are both activated.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 62/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Always-on (releaseOnly)
HSDPA + UL DCH
HSDPA + E-DCH
t
Release timer
(timerT2ForHsdpa
timerT2ForHsdpaAndEDch)
t
Traffic UL/DL
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).
In case of I/B multi PS services supported in HSDPA (HSDPA PS Mux), after a period
T2 of inactivity, the user is transferred in Cell/URA_PCH state (if activated) and after
an additional T3 of inactivity the call is released. If Cell/URA_PCH states are not
active, the call is released after T2 timer.
In case of HSDPA multi-service (HSDPA+CS or HSDPA+STR), the Always-on Step 1
is not applied (no downsize to CS+PS 8) and the PS I/B is released after T2 (no
downsize to Cell/URA_PCH can be performed due to CS part).
The T2 timer used is: timerT2ForHsdpa (UL DCH / DL HSDPA) or
timerT2ForHsdpaAndEdch (UL E-DCH / DL HSDPA)
9.1.3.4 UPSIZE
For Always-on upsize, the mechanism and the parameters are the same as for R99.
When upsizing to HSDPA or E-DCH and no resource are available (in case of CAC
failure), the call will be released.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 63/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
9.1.3.5 REMINDER FOR TIMER USAGE
In the following tables, the D is used ton indicate degraded2AlwaysOn mode and the
R stands for the releaseOnly mode.
PS I/B + SRB
timerT1ForHsdpa
D timerT2
timerT1ForHsdpaAndEDch
HSDPA / E-DCH
timerT2ForHsdpa
R NA
timerT2ForHsdpaAndEDch
D
timerT2ForHsdpa (1)
HSDPA / E-DCH NA (1)
timerT2ForHsdpaAndEDch
R
timerT2ForHsdpa (1)
HSDPA / DCH (Mux) R NA (1)
timerT2ForHsdpaAndEDch
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")
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 64/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Second case when x_PCH is activated (PchRrcStates ≠ none):
PS I/B + SRB
Always On
T1 (=> CELL_FACH) T2 (=> Cell/URA_PCH) T3 (=> Idle)
Mode
Always On
T1 (=> CELL_FACH) T2 (=> Cell/URA_PCH) T3 (=> Idle)
Mode
tDchPchMpdpForHsdpaAndDc uraPchToIdleTimer/
HSDPA / DCH R ;
h (1) cellPchToIdleTimer
Always On
T1 (=> CS+PS8) T2 (=> CS + PS 0) T3 (=> Idle)
Mode
timerT2ForHsdpa uraPchToIdleTimer/
D ;
timerT2ForHsdpaAndEDch cellPchToIdleTimer
HSDPA / E-DCH
timerT2ForHsdpa
R ; NA
timerT2ForHsdpaAndEDch
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 65/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Restriction:
The Always-on configuration has to be consistent in UL & DL (same Always-on mode), otherwise the
downsize can not be triggered by the RNC.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 66/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Parameter timerT2ForHsdpa, Object AlwaysOnTimer
timerT2ForHsdpaAndEdch
Range & Unit [10..10800000] (ms)
User Customer Granularity OLS
Class 3
Value 10000
Note: The timerT2ForMultiRabHsdpa was used in UA5.x, since Ua6 this timer is replaced by
TimerT2ForHsdpa
The uraPchToIdleTimer and the cellPchToIdleTimer are used for the downsizing
respectively from URA_PCH and CELL_PCH to Idle state.
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.
Engineering Recommendation:
As soon as the mobility is detected, the user is moved to URA_PCH. Static users will stay in
CELL_PCH state and will be able to be paged only on their cell (location known at cell level in
CELL_PCH state while location is known at URA level in URA_PCH state).
Page 67/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
the more users multiplexed on HS-DSCH, the less users will be allocated high bit
rates.
However, as it is possible to reserve some power for HSDPA users, this power shall
be consider as consumed in cell colour calculation for the HSDPA cells.
In the same way, OVSF codes reserved for HS-PDSCH and HS-SCCH are
considered to be used in the cell colour calculation.
In UA6.0, when the feature Fair Sharing is activated, OVSF codes load is computed
following the usual formula:
1 NumberOfFreeCodesPerSpreadingFactor − n * SF / 16
Code _ Load = 1 − * ∑
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).
In UA5.0, the OVSF codes load is computed in different ways depending on the activation of the feature Dynamic
Code tree management :
• when feature Dynamic Code tree management is deactivated, the formula used is the following:
1 NumberOfFreeCodesPerSpreadingFactor
Code _ Load = 1 − * ∑
NumberOfSpreadingFactors All _ SF SF
Where SF=4, 8, 16, 32, 64, 128 and 256 (NumberOfSpreadingFactors=7).
• when the feature Dynamic Code tree management is activated (see [Vol. 3] for details), the code load is
13H
⎡ NumberOfFreeCodesPerSpreadingFactor ⎤
⎢ ⎥
⎢+ Ceil ( NumberOfSF16CodesAllocatedToHsPdsch × SF ⎥
⎢ 16⎥
⎢− Ceil (minNumberOfHsPdschCodes × SF ⎥
Code _ Load = 1 −
1
* ∑ ⎣⎢ 16 ⎦⎥
NumberOfSpreadingFactors All _ SF SF
Where Ceil(x), is the function that rounds to the nearest integer equal or greater than x (because SF/16 can be
fractional).
Then, in UA5.0, there are a fixed number of SF 16 codes reserved for HSDPA (minNumberOfPdschCodes).
These codes are considered as used (static) by the iRM Cell Colour calculation even if there is no on-going
transmission on HSDPA channel. With the Fair-sharing feature, there is no more codes reserved statically to
HSDPA but there is a full sharing of OVSF codes resource between R99 and HSDPA, leading to a better
efficiency of the OVSF codes resource usage. The iRM thresholds may then have to be retuned.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 68/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Moreover, the iRM thresholds can be tuned independently from the HSDPA
configuration.
The operator may tune iRM thresholds so that colour turns yellow before stealing HS-
DSCH codes and red before having stolen all HS-DSCH codes.
For more details see UTRAN Parameters Used Guide [R01] 132H
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 operator’s
provisioning.
9.5.1 DESCRIPTION
The UA6.0 pre-emption mechanism is applicable for R99 DCH calls as well as for
HSDPA / E-DCH calls.
The full description of the feature is provided in the UPUG UA6.0, Volume 14 – Load
Management.
The pre-emption is triggered on CAC failures and allows freeing some resources by
downgrading or releasing some current users in order to admit incoming services with
higher priority.
The following figure gives an overview of the concepts used in the UA6.0 algorithm:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 69/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
NodeB DL radio resources not available
NodeB UL radio resources not available Dedicated
NodeB resources not available
RNC DL code resources not available
Shared
RNC DL power resources not available
Eligible CAC
Failures
1 Steps / 2 Steps Eligible
Services
R99
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 70/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
33322
Upon CAC Failure
Preemption Shared resources (R99 & HSDPA) : OVSF Codes & DL Power
Dedicated resources : CEM (Node B)
GBR on HSDPA Power consumption Node B feedback to RNC (needed for fair-
sharing)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 71/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
• The CAC failure is UL : the pre-empted users will be either UL DCH / DL DCH
or UL DCH / DL HSDPA
The list of eligible users is ordered according to service priority and OLS.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 72/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Note: The HsxPA to DCH fallback is exclusive with Fair-sharing when the CAC failure
is DL Power or OVSF Codes.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 73/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
• isPreemptionAllowedForHsdpa: This parameter is used to activate/de-
activate pre-emption process for UL DCH/DL HSDPA calls.
Parameter isPreemptionAllowedForHsdpa
Object PreemptionAllowedInfo
Granularity RNC
Range & Unit Boolean: {True, False}
User & Class Customer, Class 3
Value False (De-activate the feature for HSDPA)
True (Activate the feature for HSDPA)
Parameter isPreemptionAllowedForEdch
Object PreemptionAllowedInfo
Granularity RNC
Range & Unit Boolean: {True, False}
User & Class Customer, Class 3
Value False (De-activate the feature for E-DCH)
True (Activate the feature for E-DCH)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 74/75
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 5 : Call Management
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 75/75
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
6 MOBILITY
Alcatel-Lucent – Proprietary
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
CONTENTS
1 INTRODUCTION............................................................................................................................5
1.1 OBJECT ....................................................................................................................................5
1.2 SCOPE OF THIS DOCUMENT .......................................................................................................5
Page 1/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
6 INTER-FREQUENCY AND INTER-SYSTEM HHO FOR HSXPA...............................................47
6.1 INTER-FREQUENCY MOBILITY FOR HSXPA ..............................................................................48
6.1.1 Inter-Frequency intra-RNC Mobility for HSxPA.............................................................48
6.1.2 Inter-Frequency inter-RNC without Iur Mobility for HSxPA...........................................49
6.1.3 Inter-Frequency inter-RNC with Iur Mobility for HSxPA................................................49
6.1.4 Full Event HHO setting for HSxPA................................................................................50
6.2 INTER-SYSTEM MOBILITY FOR HSXPA.....................................................................................51
6.2.1 3G to 2G Handover .......................................................................................................51
6.2.2 2G to 3G Handover .......................................................................................................51
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
TABLES
Table 1: SHO Event Recommended Settings Summary 26
Table 2: Summary matrix for E-DCH Compressed Mode support 43
Table 3: HHO Event Recommended Settings Summary 51
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
FIGURES
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case) ......................... 10
Figure 2: E-DCH link is deleted and re-established on new Primary Cell (nominal case) ...................... 12
Figure 3: E-DCH macro diversity general principle ....................................................................................... 14
Figure 4: OMC-R RAN model for 32076......................................................................................................... 19
Figure 5: OMC-B RAN model for 32076 ......................................................................................................... 20
Figure 6: Transmission of E-DPDCH (10ms TTI) when in CM operation .................................................. 40
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
Mobility algorithms and parameters applicable to HSDPA & E-DCH (HSUPA) system.
This includes a system description, configuration aspect and engineering
recommendations.
Global US
PM ID Feature Title Activation flag Release
market Market
isGsmCModeActivationAllowed
isInterFreqCModeActivationAllowed
Compressed Mode in UA5.0 Yes Yes
29798
MAC-hs isInterFreqMeasActivationAllowed
isPatternAllowed
[iBTS]
No activation flag.
Page 5/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
HSDPA over Iur b/w isMacShHsdpaAllowed UA5.1 Yes Yes
34012
management
No activation flag.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
This section describes the existing mobility procedures for HSxPA calls.
If it is not possible to re-establish HSxPA on the new primary (i.e. CAC failure in the
HS-DSCH RL Reconfiguration consecutive to the primary cell change), HSPA to DCH
fallback mechanism is applied if provisioned (cf. relative section), otherwise RNC
triggers IU-PS Release procedure.
Mobiles can be spread over HSxPA and not-HSxPA layers thanks to several
algorithms:
• Idle Mode & HCS feature while in Idle, PCH and Cell FACH states (refer to
UPUG [R01])
Page 8/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
primary cell and it is re-established under the new one synchronously via the
normal Synchronized RL Reconfiguration procedure (NBAP RL
Reconfiguration on both source and target NodeB and RRC RB
Reconfiguration message. This is shown in the Figure 1 below.
• If the new primary cell does not support HSDPA then the RB is reconfigured
to DCH. iRM CAC is performed and if there is a CAC failure, the call is
dropped.
• If the new primary cell supports HSDPA while the former did not, then the RB
is reconfigured to HS-DSCH. In case HSDPA CAC failure occurs, fallback to
DCH may occur if provisioned; Fallback to DCH will be blocked if Fair sharing
is activated and CAC occurred due to either power or Code shortage. In this
case iMCTA CAC will take place instead (if provisioned). IU-PS is released
otherwise.
During the reconfiguration, data transfer is suspended by the RNC (not for the whole
reconfiguration time but only for a short time before the synchronized cell change,
please refer to the section 7 for the parameter which control the time when RNC
suspends the traffic). Data that were in the MAC-hs buffer of the former cell are
discarded (except if both cells are managed by the same H-BBU board). User data are
not lost thanks to RLC retransmissions but if the primary cell changes too often; the
data throughput can be impacted.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
RL Reconfiguration Ready
RL Reconfiguration Prepare
(MAC-d flow to Delete)
RL Reconfiguration Ready
Activation CFN
RB Reconfiguration Complete
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case)
Engineering Recommendation:
Starting from the release UA7.0, MAC-ehs (enhanced MAC-hs) may be used for the
call, depending on the capability of the NodeB and the RNC configuration.
If the inter-nodeB mobility (soft HO) involves a source NodeB and a target NodeB with
different MAC-ehs capability, the RB is reconfigured accordingly (from MAC-hs to
MAC-ehs or reversely). Depending on the mobility scenario an RLC one-sided re-
establishment of the downlink may be performed.
For intra-nodeB mobility (softer HO) involving a source cell and a target cell with
different feature activation state (MAC-ehs allowed on one cell, MAC-ehs not allowed
on the other cell), the RB can not be reconfigured accordingly (the NodeB does not
support such kind of reconfiguration). If the source cell has MAC-ehs allowed but not
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
RL Reconfiguration Ready
RL Reconfiguration Ready
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)
Page 12/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• 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).
Since UA6, the capability of the UTRAN to handle multiple E-DCH radio links
simultaneously for a given UE, i.e. full support of E-DCH softer HO and SHO is
introduced via 32076 “E-DCH Macro Diversity Support” feature. This feature allows
improving E-DCH user throughput when UE is in inter NodeB SHO condition, by
decoding E-DCH simultaneously on multiple NodeBs and performing frame selection
at RNC. In addition, this feature allows always guaranteeing acceptable radio
conditions for E-DCH serving radio links, by managing the UL noise rise (i.e. UL
interference) generated by E-DCH non-serving 1 radio links.
The main characteristics of 32076 are as follows.
• For a given E-DCH call, multiple E-DCH radio links can be decoded
simultaneously by multiple NodeBs.
• E-DCH active set:
o For a given E-DCH call, the E-DCH AS is the set of cells for which an
E-DCH radio link is configured
o The E-DCH AS is updated according to DL radio conditions
o The E-DCH AS is included in the DCH AS
• For each NodeB involved in the E-DCH call, the E-DCH signals received from a
given UE are combined via Maximum Ratio Combining (MRC) method before
1
For an E-DCH call, “E-DCH non-serving radio links” designate the E-DCH radio links established on cells
other than the Primary Cell. E-DCH non-serving radio-links may belong either to the same NodeB as the one of
the Primary Cell (serving NodeB) or to other NodeB (non-serving NodeB).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
being processed. The combined signals are all the E-DCH signals received on the
cells in the DCH AS of this NodeB.
• At a given time, the same RG command and same ACK/NACK information is
• transmitted to the UE on all the cells in the E-DCH AS of the E-DCH serving
NodeB.
• Iub E-DCH Data Frame selection at RNC:
For a given CFN, multiple Iub E-DCH Data Frames may be received at RNC from
different NodeBs. The first correctly received Data Frame is selected, the others
are discarded.
• Management of UL noise rise generated by E-DCH non-serving RLs:
o For each E-DCH cell, the UL noise rise generated by E-DCH non-
serving radio links is monitored
o If the UL noise rise from E-DCH non-serving radio links is too high,
“Down” RG is sent to non-serving UEs
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
3.3.3.1.2 E-DCH ACTIVE SET MANAGEMENT
Action triggered: Cell”A” 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
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
o If the new Primary Cell does not support E-DCH, the E-DCH RB is
reconfigured to UL DCH.
iCEM/xCEM specificities:
[iCEM] [xCEM] For the iBTS, iCEM and xCEM capabilities are different regarding E-
DCH TTI and E-DPDCH min SF. This means that for a given UE moving in a network
with iCEM and xCEM boards handling E-DCH, the E-DCH call attributes depend on
the type of board of the E-DCH serving cell.
Example:
UE: HSUPA Category 5, “IR” E-DCH HARQ type supported:
• iCEM handling E-DCH on E-DCH serving cell:
{10ms TTI, 2xSF4, IR},
{Ref E-TFCI; Ref PO} table of EdpchParameters/UECategory3EdchTti10ms
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• xCEM handling E-DCH on E-DCH serving cell:
{10ms TTI, 2xSF2, IR},
{Ref E-TFCI; Ref PO} table of EdpchParameters/UECategory5EdchTti10ms
For more information on the {Ref E-TFCI; Ref PO} table selection mechanism, please
refer to [Vol. 4], section 5.4, “{REF E-TFCI; REF PO} TABLE SELECTION
MECHANISM”.
[UCU-III] For the OneBTS, all the cells in the network have the same E-DCH
capabilities. Hence, the E-DCH call attributes only depend on the HSUPA UE
Category and do not change during the call unless there is a mixed deployment of
2ms and 10ms TTIs (from UA7.1 UCU-III supports both the 2 ms and 10 ms TTIs).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• [iCEM]
With
E DCH Rx Power Non Serving : E-DCH power received at NodeB antenna of the
considered cell from non-serving radio links (of both non-serving UEs and
non-serving peer UEs).
E DCH Rx Power Total : Total E-DCH power received at NodeB antenna of the
considered cell from all radio links (serving and non-serving).
Then “Down” RG commands are sent from this cell to non-serving UEs:
o Common RG are used for UEs for which this cell is not under the serving
NodeB
o Dedicated RG are used for UEs for which this cell is under the serving
NodeB (non-serving peer UEs)
• [xCEM] [UCU-III]
With
E DCH Rx Power Non Serving RLs of Non Serving NodeB : E-DCH power received at
NodeB antenna of the considered cell from non-serving radio links (the RL of
non-serving peer UEs are not considered here).
Then common “Down” RG commands are sent from this cell to non-serving UEs (the
non-serving peer UEs are not considered here)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
3.3.3.2 PARAMETER SETTINGS AND RECOMMENDATIONS
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:
Below figure shows the RAN model (i.e. parameters and objects tree) at OMC-R.
OMC-R
RNC
RadioAccessService NodeB
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed FDDCell
targetNonServingToTotalEdchPowerRatio
DedicatedConf EdchRncConf
maxNumberOfRlEdch
FullEventHoConfShoMgt FullEventRepCritShoMgt
FullEventHoConfShoMgtEvent1J FullEventRepCritShoMgtEvent1J
hysteresis1J amountRep1J
timeToTrigger1J maxNbReportedCells1J
repActThresh1J
repInterval1J
[xCEM] [UCU-III]
Below figure shows the RAN model at OMC-B.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Remark: All below parameters only apply to xCEM or UCU-III (i.e. not used by iCEM).
OMC-B
BTSEquipment OneBTSEquipment
BTSCell eDCHSofterHOLimit
commonERGCHPowerOffset
EdchConf
edchSofterHoLimit eDCHNumCommonRGPerCode
nonServingEHICHPowerOffset
commonERGCHPowerOffset
edchNumCommonRgPerCode
Parameter isEdchRlAddOrSetupDefenseAllowed
Object RadioAccessService
Granularity RNC
Range & Unit Boolean {False, True}, N/A
User & Class Customer, 3
Value True
Parameter isRrcEdchEvent1JAllowed
Object RadioAccessService
Granularity RNC
Range & Unit Boolean {False, True}, N/A
User & Class Customer, 3
Value True
targetNonServingToTotalEdchPowerRatio:
[iCEM] (E-DCH handled by iCEM on considered cell):
Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna of considered cell)
from non-serving RLs] to [total E-DCH Rx power].
[xCEM] [UCU-III] (E-DCH handled by xCEM or UCU-III on considered cell):
Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna of considered cell)
from non-serving RLs of non-serving NodeB(s)] to [total E-DCH Rx power].
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Parameter targetNonServingToTotalEdchPowerRatio
Object FDDCell
Granularity FDDCell
Range & Unit Integer [0 … 100], %
User & Class Customer, 3
Value 25
Parameter maxNumberOfRlEdch
Object EdchRncConf
Granularity RNC
Range & Unit Integer [1 … 4], N/A
User & Class Customer, 3
Value 4
Parameter iubEdchDelayVariation
Object NodeBConfClass
Granularity NodeBConfClass
Range & Unit Integer [1 … 255], Number of E-DCH TTIs
User & Class Customer, 3
Value [iCEM] [xCEM] 5
[UCU-III] 3
Parameter hysteresis1J
Object FullEventHoConfShoMgtEvent1J
Granularity HoConfClass, UsHoConf
Range & Unit Decimal [0.0 … 7.5] step 0.5, dB
User & Class Customer, 3
Value 3.0
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Parameter timeToTrigger1J
Object FullEventHoConfShoMgtEvent1J
Granularity HoConfClass, UsHoConf
Range & Unit Enum {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,
5000}, ms
User & Class Customer, 3
Value 100
Parameter amountRep1J
Object FullEventRepCritShoMgtEvent1J
Granularity MeasurementConfClass
Range & Unit Enum {1, 2, 4, 8, 16, 32, 64, Infinity}, N/A
User & Class Customer, 3
Value Infinity
Parameter maxNbReportedCells1J
Object FullEventRepCritShoMgtEvent1J
Granularity MeasurementConfClass
Range & Unit Integer [1 … 6], N/A
User & Class Customer, 3
Value [iCEM] [xCEM] 3
[UCU-III] 6
Parameter repActThresh1J
Object FullEventRepCritShoMgtEvent1J
Granularity MeasurementConfClass
Range & Unit Integer [2 … 4], N/A
User & Class Customer, 3
Value 2
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 22/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Parameter repInterval1J
Object FullEventRepCritShoMgtEvent1J
Granularity MeasurementConfClass
Range & Unit Enum {0, 250, 500, 1000, 2000, 4000, 8000, 16000}, ms
User & Class Customer, 3
Value 500
[xCEM] [UCU-III]
edchSofterHoLimit: Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna
of considered cell) from non-serving RLs of serving NodeB] to [total E-DCH Rx power].
Parameter nonServingEHICHPowerOffset
Object EdchConf
Granularity BTSCell
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value 0.0
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Parameter commonERGCHPowerOffset
Object [xCEM] EdchConf
[UCU-III] OneBTSEquipment
Granularity [xCEM] BTSCell
[UCU-III] OneBTSEquipment
Range & Unit Signed [-35.0 … 15.0] step 0.1, dB
User & Class Customer, 3
Value 0.0
Before UA6, UsHoConf used to be defined per DlUserService, i.e. one mobility profile could be
defined for each RAB.
From UA6, in order to ease the setting, UsHoConf is now defined per mobilityServiceType, a
parameter allowing several DlUserServices to be assigned to the same mobility setting.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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:
A specific rule must be defined for the SHO settings of the HSDPA multi-service UsHoConfs:
• Applicable to reportingRange 1A, 1B, 1E and 1F
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).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
mobilityServiceType
Event
Parameter Object
Others with
PsHSDPA
HSDPA
1C hysteresis1C 7.5 dB
FullEventHOConfShoMgtEvent1C
timeToTrigger1C 320 ms
1D hysteresis1D 6 dB 6 dB
useCioFor1D False
cpichEcNoThresholdUsedFreq1F -15 dB
FullEventHOConfShoMgtEvent1F
timeToTrigger1F 640 ms
• As a SRNC:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
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.
o In a non Alcatel-Lucent - Alcatel-Lucent case, an HSDPA configuration
occurs when the DRNC receives a RNSAP Radio Link Setup Request or
a Radio Link Reconfiguration Prepare message with HS-DSCH IEs.
From UA5.1, HSDPA over Iur has been fully supported with a correct management of
Iub congestion taking into account HSDPA traffic coming from Iur. Refer to [R07] for
further details on Iub congestion management.
HSDPA over Iur is not guaranteed when facing non Alcatel-Lucent RNC (for details refer to [R02]).
Therefore, in such cases, on Alcatel-Lucent serving RNC, the neighbour RNC should be provisioned
as non HSDPA capable, unless successful IOT has been performed with the other vendor.
Starting from the release UA7.0, MAC-ehs (enhanced MAC-hs) may be used for the
call (refer to the description of the feature 34388 in the Volume 3 for more details).
However, MAC-ehs is not supported over IUR: in case of HSDPA mobility over IUR, if
the RB was using MAC-ehs, the RB is reconfigured to MAC-hs.
In the case of SRNS relocation - UE not involved (Inter RNC mobility with IUR), the
RB remains configured with MAC-hs, regardless of the MAC-ehs capability of the
target cell. It may be reconfigured to MAC-ehs at the next inter-nodeB mobility
occasion towards a MAC-ehs capable cell.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
If the HSUPA over Iur is not supported or deactivated on SRNC or DRNC, the system
will behave similarly as in UA5: While HSUPA running, if the primary cell goes under
the control of a DRNC then the SRNC will consider that the new primary is not E-DCH
capable and, as such, will perform an UL Transport Channel type switching to DCH
whereas DL HS-DSCH is properly reconfigured over Iur (in case HSDPA over Iur is
provisioned); In UA6 if E-DCH over IuR is not supported then no non-serving (non-
primary) E-DCH link will be established over IuR.
When HSUPA over Iur is supported and activated on both SRNC and DRNC, the
mobility between serving cells (under SRNC) and drift cells (under DRNC) is handled
by the SRNC, in the same way as intra RNC edch mobility, based on the primary cell
edch capabilities and the target drift cell edch capabilities in terms of
Edch support
TTI capabilities (2ms or 10ms)
Min SF capabilities
Note that the edch capabilities for drift cells that are declared as neighbours to the
border serving cells (i.e. known by the SRNC) are configured under “RemoteFddCell”.
When the Iur is well dimensioned, it’s recommended to set the edch capabilities,
under remoteFddCell object, in line with the real cell capabilities otherwise, we can
use these parameters to “downgrade” the drift cell capabilities in order to limit the edch
traffic over Iur or to deactivate completely the edch over Iur toward some specific drift
cells. We can for example limit the edch over Iur to CAT3 by setting the TTI
capabilities to 10ms and Min SF capabilities to 2SF4 even if the drift cell is 2ms
capable and supporting 2SF2+2SF4.
In case of HSUPA over Iur, the DRNC is responsible for the Iub edch bandwidth
limitation management for the drift BTS
The DRNC detects the edch congestion based on edch frame loss as
described in HPUG volume 4.
The DRNC discard the TNL congestion messages received from the SRNC.
Restriction:
• In UA6.0, the Iur edch bandwidth limitation is not supported that’s why it’s highly
recommended to activate the SRNS relocation in case of limited Iur capacity so that the Iur
resources will be released as soon as the call moves completely to the DRNC.
• Also, E-DCH to E-DCH inter-freq mobility over Iur cases is not supported. UE involved
relocation is triggered by the SRNC instead of inter-freq mobility over Iur.
• Finally, PM30744 does not support SRB over E-DCH, a fallback on DCH applies in uplink for
SRB, in case drift RNC controls the primary cell
PARAMETERS:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• isHsdpaOverIurAsSrncAllowed: This parameter allows RNC to
enable/disable HSDPA over Iur when acting as a Serving RNC.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• isEdchAllowed: This parameter under RemoteFddCell defines the HSUPA
capabilities of an UMTS neighbouring cell belonging to another RNC.
When a cell belonging to a DRNC is added in the active set, it sends to the SRNC its
neighbourhood in RNSAP RadioLinkAdditionResponse or RadioLinkSetupResponse
messages, together with primary scrambling code and HSxPA capabilities using HS-DSCH
Support and edch Support Indicator.
Such indicator allows SRNC to learn the capability of a cell that does NOT belong to
SRNC; it also allows SRNC to update the capability of a cell depending on its real status
(HSxPA activated or not) and depending on what is provisioned on DRNC.
This parameter has to be set carefully in order to avoid Iur IOT issues with other
vendor’s RNCs and also to not block the RNSAP RL setup for unidirectional DL DCH
only case.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
In UA7.1, the UA7.0 parameter reserved0 (first byte), located under NeighbouringRNC, is freed and
replaced with isRnsapCr1357Supported (also located under NeighbouringRNC). The settings used
by the first byte of reserved0, 0 or 1, will be now treated by this new parameter as False or True,
respectively.
Note that other bytes of reserved0 may still be in use for different purposes.
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.
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 vendor’s RNC which support only 3GPP [R04] Rel-6 baseline,
when receiving a RNSAP RADIO LINK SETUP REQUEST message including UL
DPDCH Indicator for E-DCH Operation IE, but without E-DPCH Information IE (e.g.
unidirectional DCH only case), UA6 DRNC should reply RNSAP RADIO LINK SETUP
FAILURE since it is compliant to 3GPP [R04] Rel-6 Spec.
For a DRNC UA7.0, receiving a RNSAP message compliant with 3GPP [R04] Rel-7
CR1357, the DRNC shall overwrite the NBAP message to be sent in order to follow
UA06 Iub behaviour (since 3GPP [R05] Rel-7 CR1462 is not support in UA7.0, but it
will be supported in UA7.1).
After UA7.1 introduction, Alcatel-Lucent UTRAN will fully support not only CR1357
[R04] but also CR1462 [R05]. Another parameter is then introduced:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Parameter isNbapCr1462Supported Object NodeB
Range & Unit {True, False}, Boolean
User Customer Granularity BTS
Class 3
Value See engineering recommendation below
If NodeB version is Rel-6 (or earlier), UL DPDCH Indicator for E-DCH Operation IE
shall be sent when E-DPCH Information IE is present (UA6 NodeB will apply this
Check rule)
If NodeB version is Rel-7 (or latter), UL DPDCH Indicator for E-DCH Operation IE can
be present without the presence of E-DPDCH information IE
Two new flags can then be set:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 33/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
o When set to False, this parameter also prevents any Intra-frequency
Inter-RNC HHO from HSDPA.
DCH to E-DCH
DCH to DCH
o When set to False, this parameter also prevents any Intra-frequency
Inter-RNC HHO from E-DCH.
Engineering Recommendation:
‘SRNS relocation - UE involved’ (Inter RNC mobility without IUR) for HSDPA MAC-ehs
calls (feature 34388) is supported. However, the Source RNC needs to know the
release of the Target RNC in order to select the proper ‘Source to Target Transparent
Container’ format and eventually properly encode the MAC-ehs specific IEs.
Upon relocation, the RB is configured accordingly to the MAC-ehs 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, the RB will no longer be mapped on MAC-ehs.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
In UA7, the Source RNC knows the release of the Target RNC through the second
byte of the parameter reserved0 in the object NeighbouringRNC.
The release of the Target RNC must not be over-estimated, otherwise the SRNS relocation – UE not
involved’ of an HSDPA call mapped on MAC-ehs may lead to call drop.
Upon ‘SRNS relocation – UE not involved’ 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/reserved0 (second byte) ‘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/reserved0 (second byte) ‘over-estimates’ the release of the Target RNC, the
Source RNC would encode MAC-ehs specific IEs in the Rel’7 Source to Target Transparent
Container’ that could not be decoded by the Target RNC, leading to call drop.
‘SRNS relocation - UE involved’ (Inter RNC mobility without IUR) for HSDPA-DC calls
(feature 81204) is supported with the following limitation: SRNS ASN Containers for
Rel’8 is not available in UA7. Therefore, the UA7.1.2 release does not support SRNS
relocation as a rel’8 UE. SRNS Relocation 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.
Page 35/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
is managed by a dedicated BBU. In case of xCEM/UCU-III board, all the services are
managed by the same M-BBU.
Restriction: Higher Layer Scheduling (HLS) method not supported with HS-DSCH or E-DCH
HLS has been introduced so that 2 different methods are now supported for the gap creation: SF/2
and HLS.
Note that for any DL configuration with an HS-DSCH or E-DCH, HLS CM method shall not apply.
Refer to [R01] for further details on CM measurements.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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).
o On going - the pattern already started. The activation CFN
information is then useless and the position in the pattern must be
recovered thanks to the three included parameters defined below. If
CMCFN is valid, current patterns have to be stopped at CMCFN if not
finished yet.
o On going + not started – this mix state can only be notified if
CMCFN is valid. In that case, the on going pattern is handled as
previously described but must be stopped at CMCFN. Then, the new
APSI is provided and must be taken into account as described in the
“not started” state.
o Finished – the pattern is already finished so the whole activation
information can be ignored. Note that this state is not explicitly
needed as it may also be deduced by the non-presence of pattern Id
in CM status.
• Current TGP [Id] (only if “on going” or “on going + not started” state). Fits in
the range [0..TGPRC-1].
• Position in pattern [Id] (only if “on going” or “on going + not started” state).
Fits in the range [0..TGPL-1].
• TGPRC [Id] (only if “on going” or “on going + not started” state). Range
[0..511].
• APSI [Id] (only if “not started” or “on going + not started” state).
2
[Id] means that this information must be provided for each configured pattern.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 38/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
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/OneBTS), the CQI is not decoded if it falls into an
UL gap or if the reference periods overlaps with a DL gap. The ACK/NACK frame
that overlaps with an UL gap is considered as DTX.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 39/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
0.66ms slot
10ms E-DCH TTI 10ms E-DCH TTI
0 1 2 3 4 5 6 Tx Gap 11121314 0 1 2 3 4 5 6 7 8 9 10 DTX
With the introduction of 33480 feature (since UA5.1), uplink CM transmission gaps are
taken into account by the MAC-e entity at the Node-B when decoding MAC-e PDUs,
thus enabling decoding of data sent by an E-DCH CM-compliant UE on E-DCH under
the E-DCH Compressed Mode format for E-DCH 10 ms TTI specified by 3GPP [R03].
Remark: A flag for activation/deactivation of 33480 feature is present in the RAN
Model until UA7.0 (edchCMActivation parameter under BTSEquipment object), but
it is not used for the 33480 activation, i.e. 33480 feature is always activated. This flag
is removed in UA7.1. In other words, the Node-B always assumes that E-DCH UE
use the compressed E-DCH format when sending data on E-DCH over a gapped
TTI.
Concerning the downlink, E-AGCH, E-RGCH and E-HICH transmission method when
CM reception gaps occur is not modified (compared to the no CM case).
UPLINK
The solution presented here applies only to E-DCH with 10ms TTI (the solution for E-
DCH with 2ms TTI is simple and is briefly mentioned at the beginning of this section).
As of today, a significant part of the commercial R6 UEs still do not support E-DCH
transmission on 10ms TTI when in CM operation as specified by 3GPP in [R03].
Hence, the following behaviour description has been split in two cases: “UE not
supporting E-DCH Compressed Mode” and “UE supporting E-DCH Compressed
Mode”.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 40/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
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 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
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 41/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 42/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
CM gaps not taken into account by UE when CM gaps not taken into account by UE when
transmitting on E-DCH ⇒ A MAC-e PDU transmitting on E-DCH ⇒ A MAC-e PDU
transmitted over a gapped TTI cannot be transmitted over a gapped TTI cannot be
decoded. decoded.
However, MAC-e PDU is HARQ-retransmitted in
Node-B expects UE to auto-reduce its grant and
non-gapped format ⇒ If TTI used for HARQ UE does not do so (detected by Node-B due to E-
retransmission is not gapped, retransmitted
TFC larger than expected) ⇒ Node-B sends an
UE support for EDCH compressed mode
CM gaps taken into account by UE when CM gaps taken into account by UE when
transmitting on E-DCH ⇒ Since Node-B is not transmitting on E-DCH
aware of gapped format, a MAC-e PDU ⇒ Since Node-B is aware of gapped format, a
transmitted over a gapped TTI cannot be MAC-e PDU transmitted over a gapped TTI is
decoded. decoded.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 43/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
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:
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 44/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
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.
Page 45/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Several features are used in order to implement different multi-layers strategies for
HSxPA, providing inter carrier mobility:
• Idle Mode & Hierarchical Cell Structure (HCS) allows strategies based on
UEs camping homogeneously on different frequencies or favour specific
carriers or even prioritizing cell layers for mobiles in idle mode, Cell_FACH
and URA/Cell_PCH connected modes. The HCS cell reselection algorithm
also takes into account UE speed so that fast moving UEs can be placed in
large cells to avoid excessive cell reselections.
• Intelligent Multi-Carrier RRC Connection Allocation (iMCRA) allows
redirecting UE to FDD cells at RRC connection establishment. iMCRA
strategies are based on:
o RRC Redirection based on UE Capabilities allowing redirecting UE
at RRC connection establishment based on their release and/or on
the establishment cause sent to RNC in RRC Connection Request
message. It also allows redirecting UE to the preferred R99 layer.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 46/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
PARAMETERS:
isInterFreqMeasActivationAllowed: This parameter indicates if the inter-frequency
measurement activation is allowed or not in the RNC.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 47/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
isInterFreqCModeActivationAllowed must be set to True for all DlUserServices dealing with HS-
DSCH
isGsmCModeActivationAllowed must be set to True for all DlUserServices dealing with HS-DSCH
except for:
• Standalone HS-DSCH or HS-DSCH mixed with PS Streaming high bit rate since high
throughput will not be maintained on GSM
• HS-DSCH mixed with CS conversational because CSD64 not supported on GSM
This setting is also applicable to HSUPA RAB as the parameters are per DlUserService (i.e. HS-
DSCH).
Refer to UPUG Vol. 13, [R01], for the exhaustive list of value per DlUserService.
All reconfigurations from HSxPA to DCH, DCH to HSxPA and HSxPA to HSxPA are
supported by both iCEM and xCEM, and by UCU-III.
PARAMETERS:
For details on parameters isHsdpaHhoWithMeasAllowed and
isEdchHhoWithMeasAllowed please refer to section 3.6.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 48/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Engineering Recommendation:
However, in very specific cases where HSxPA capabilities are missing (e.g. if other
vendor’s source RNC did not provide the UE’s HSxPA-capabilities), Target RNC first
establishes the PS RAB into DCH, requests UE’s HSxPA-capabilities through RRC
UE Enquiry Capability procedure and eventually reconfigures the PS RAB into HSxPA
if needed.
Relocation procedures are detailed in [R01]
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 49/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
PARAMETERS:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 50/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Event
Value
Parameter Object
timerAlarmHOEvent FullEventHOConfHhoMgt 0
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 51/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
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.
• All HS-DSCH Capacity Requests that are sent to the NodeB before
the starting activation time are silently discarded.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 52/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
• When the credits are not yet explicitly granted, the NodeB silently
delete HS-DSCH data coming from the RNC (i.e. no HS-DSCH
Capacity Allocation is sent to the RNC).
• After the activation time, on the first HS-DSCH Capacity Request with
nonzero BO (Buffer Occupancy), the NodeB immediately replies with
HS-DSCH Capacity Allocation.
• In the steady-state (after that first HS-DSCH Capacity Request
message), a Capacity Allocation can be sent at any time (depending
on NodeB buffer occupancy) indicating to the RNC the number of
MAC-d PDUs it can send for the corresponding MAC-d flow with the
associated priority. This is done without needing a Capacity Request
and without evaluation the BO (RNC Buffer Occupancy).
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 53/54
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 6 : Mobility
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 54/54
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
7 DEPLOYMENT SCENARIOS
Alcatel-Lucent – Proprietary
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
CONTENTS
1 INTRODUCTION............................................................................................................................4 12H
4.7 UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ ..................................................................25 26H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 1/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
TABLES
Table 1: different topologies of carriers with the minimum associated hardware
0H 7 40H
Table 2: summary for Cell Reselection, RCC Redirection & Handover strategies per topology
1H 16
41H
Table 4: summary for Cell Reselection, RCC Redirection & Handover strategies per topology
3H 21
43H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 2/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
FIGURES
Figure 1: Examples of applications for traffic distribution...................................................................... 11
5H 45H
Figure 2: Examples of overload handling strategies at various cell load levels .................................... 11
6H 46H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 3/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
R99 & HSDPA & E-DCH (HSUPA) multi-layer system deployments. This document
intends to:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 4/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
2 RELATED DOCUMENTS
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 5/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
This part aims at:
• Listing all the topologies that could be faced in UA7,
• Providing the UA7 Deployment Engineering Recommendations.
In order to limit only to realistic use cases, selection of the target UA7 topologies had
been based on:
• HSxPA & R99 Performance expectations
• Capacity usage efficiency
• Deployment cost: New Hardware or Optimization activities (Network re-
engineering actions) required
3 DEPLOYMENT STATUS
The aim of this section is to present the minimum hardware required to support the
topologies described in section 4. 53H
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 E-
BBU (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)
- 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
Node-B whatever the number of iCem Æ only one HSUPA carrier)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 6/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
xCem:
- 1 xCem contains 4 BBU that can be configured as D-BBU (4 max), H-BBU (2
max) or E-BBU (1 max). In case of M-BBU (by default since UA6.0), a BBU
can be used in the same time for R99, HSDPA and HSUPA
- 1 BBU is able to manage up to 2 carriers
iCcm:
- The maximum configuration supported by an iCcm is:
- 3 xCem (M) + 2 iCem128 (D,D) + 1 iCem (D) or
xCcm:
As xCEM has better performance than iCEM, it’s recommended to allocate HSxPA
services on xCEM. 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 7/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
• Bi Carrier deployments
• Tri Carrier deployments
• Four Carrier deployments
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 8/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
o Up to 14 or 15 HS-PDSCH codes usable for HSDPA thanks to Fair
Sharing (dynamic codes management part) & generally 1 PCM
deployed
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 9/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
problem and apply a strategy based on UEs camping homogeneously on different
frequencies. Other strategies intend to favour specific carriers. Different strategies can
be use for idle and connected mode.
RRC Redirection: On RRC establishment from idle mode UTRAN has load
information of the originating cell and co-located cells. UTRAN has also capabilities
information of the originating and twin cells and can get from the RRC Connection
Request message the UE capability and the establishment cause. If the load of the
originating cell is higher than of co-located cells or even call establishment is not
possible because call admission control (CAC) fails establishing the signalling Rab
(SRB), then UTRAN could decide to redirect the UE to another frequency or to GSM.
Redirection to GSM is typically applied for CS voice calls in case of CAC failure
establishing the SRB. For lower load conditions redirection is not recommended
because UTRAN has no load information of the GSM cells. Redirection is performed
towards the GSM system without any specific cell information. Therefore, the UE can
determine the most suitable performing an inter-system cell reselection. In case of
redirection to another frequency UTRAN determines the target cell and performs RRC
establishment on this cell. At the time of RRC establishment UTRAN has no
information if the target cell has sufficient coverage at the UE location, no
measurement information is available and the redirection is performed in blind mode.
Therefore, only co-located cells are considered for redirection. But also for co-located
cells there is a certain risk that the UE is not able to establish the call on the target
cell. In case of failure the UE comes back to the originating cell and repeat the RRC
establishment request; UTRAN then accepts the repeated request (except CAC failure
case). Advantages of RRC redirection are that compressed mode is not needed and
RAB establishment is done directly on the target cell.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 10/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
HSxPA Traffic
R99 traffic
Overloaded
cell GSM
The following picture provides an idea of load balancing and overload handling
strategies at various cell load levels. In this example, Cell Reselection in Idle Mode
can be used to equally distributing UEs across the different layers; iMCRA can start
load distribution when load on originating cell becomes Yellow; iMCTA Service can
handover calls when load on cell becomes Red and calls can also be handover by
iMCTA CAC to another frequency when experience CAC failure.
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
Cell Load Color Cell Load Color Cell Load Color CAC Failure at CAC Failure at Cell Load
>= Green >= Yellow >= Red RAB Est. RRC Setup.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 11/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
¾ 81213 Load Balancing Between HSPA Carriers (improved RRC redirection for
traffic segmentation or load balancing with specific HSDPA downlink load
criterion);
¾ 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);
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 12/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
¾ 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);
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 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 13/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
81213 Load Balancing between HSPA Carriers feature provides further flexibility on
network topology allowing sequential HSPA load strategies between layers build
under segmentation on HSPA capability configuration.
ALU propose the following strategies:
• Traffic Segmentation based on HSPA capability
• Traffic Segmentation based on call type
• Load Distribution (recommended for high traffic)
Data other
Conversational
other
•Cell Reselection favor F1 •Cell Reselection
•Conversational & Data Flux •Load Distribution
•iMCTA Service Segmentation CS & PS •iMCTA Service Load Balancing
HSxPA HSxPA
R99 R99/HSxPA
The following table is making a summary for Cell Reselection, RCC Redirection &
Handover strategies behind each proposed topology evolution. It is considered that
Cell sizes are equivalent (for Cpich Power recommendations please refer to 4.9). 56H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 14/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Idle Mode: Favour Use iMCRA standard solution with iMCTA Alarm: Conversational calls
Data Conversational carrier on cell Call Type Segmentation strategy; redirected to GSM. Data with low
selection/reselection by bits rates calls on FDD2 redirected
Establishment cause
Conversational keeping the UE on the to GSM.
“Conversational” redirected to FA
originating FDD1 cell that had
Type ‘Conversational’. iMCTA CAC: An inter Rat handover
been selected by the UE for
is preferred over an inter frequency
access, avoiding redirection Establishment cause “Streaming”,
handover only when FDD neighbour
for Conversational Services. “Interactive”, “Background”, “High
target cells are RED (avoiding
Priority signalling” and
Connected Mode: Disable increasing the load of a target FDD
“Registration”: redirected to FA
Inter Frequency cell cell by choosing the 2G access).
Type ‘Data’.
reselection; When UE enters
iMCTA Service used to ensure
in Cell FACH, we want him to
Conversational calls are re-directed
stay on Data layer, not select
on FDD1 and Data calls are re-
back Conversational layer.
directed on FDD2
Idle Mode: Favour R99 carrier Use iMCRA with capaAndEstCause iMCTA Alarm: Voice calls
HSxPA on cell selection/reselection by option (traffic segmentation) redirected to GSM. R99 PS with low
keeping the UE on the strategy; bits rates calls on FDD1 redirected
R99 originating FDD1 cell that had to GSM.
All UEs with establishment cause
been selected by the UE for
"Conversational” redirected to R99 iMCTA CAC: An inter Rat handover
access, avoiding redirection
cell. is preferred over an inter frequency
for Speech Services.
handover only when FDD neighbour
DCH capable UE with establishment
Connected Mode: disable target cells are RED (avoiding
cause “Streaming" “Interactive”,
Inter Frequency cell increasing the load of a target FDD
“Background”, “High Priority
reselection; When UE enters cell by choosing the 2G access).
signalling” and “Registration”
in Cell FACH, we want him to
redirected to R99 cell’. iMCTA Service used to ensure R99
stay on HSxPA layer, not
calls are re-directed on FDD1 and
select back R99 layer. HSDPA or HSUPA capable UE with
HSxPA calls are re-directed on
establishment cause “Streaming"
FDD2.
“Interactive”, “Background” , “High
Priority signalling” and “Registration”
redirected to HSxPA cell.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 15/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Idle Mode: Favour Activate 81213 Load Balancing iMCTA Alarm: Voice calls
HSxPA R99/HSxPA carrier on cell between HSPA Carriers feature redirected to GSM. For R99 PS with
selection/reselection by using associated iMCRA low bits rates calls an inter Rat
R99/HSxPA keeping the UE on the functionality with capaAndEstCause handover is preferred over an inter
originating FDD1 cell that had option (traffic segmentation) frequency handover only when FDD
been selected by the UE for strategy but with neighbour target cells are RED.
access, avoiding redirection layerPreferredForR99 = TRUE on Allow only inter carrier mobility from
for Speech Services. FDD1 R99/HSxPA cell; FDD2 to FDD1.
Connected Mode: Activate All UEs with establishment cause iMCTA CAC: An inter Rat handover
Sib4 & Sib12 allowing UE to "Conversational” redirected to is preferred over an inter frequency
reselect the best layer when in R99/HSxPA cell. handover only when FDD neighbour
cell FACH state. target cells are RED (avoiding
DCH calls are always assigned to
increasing the load of a target FDD
FDD1.
cell by choosing the 2G access).
HSPA calls are load distributed to
iMCTA Service used to ensure R99
FDD2 if unloaded FDD2 cell
calls are re-directed on FDD1 and
available.
HSxPA calls perform load
Else, if FDD2 cell are loaded then balancing.
HSPA establishment in FDD1 if
unloaded.
Idle Mode: UEs camping Activate 81213 Load Balancing iMCTA Alarm & CAC: Voice calls
other homogeneously on different between HSPA Carriers feature redirected to GSM. For PS an inter
frequencies. using associated iMCRA Rat handover is preferred over an
other functionality with Load Distribution inter frequency handover only when
Connected Mode: Reuse Idle
strategy inducing redirection to FDD neighbour target cells are RED
Mode configuration with UEs
lowest loaded frequency if (avoiding increasing the load of a
camping homogeneously on
originating cell has cell colour target FDD cell by choosing the 2G
different frequencies.
YELLOW or RED; example: access); allow only iMCTA Alarm
inter carrier mobility from FDD2 to
DCH and HSPA calls are load
FDD1.
distributed if twin cell load is lower
than originating cell load; Load iMCTA Service used for load
distribution starts later for DCH and balancing.
Streaming calls (when originating
cell becomes RED); Load
distribution starts early for HSPA
calls (when originating cell becomes
YELLOW).
Table 2: summary for Cell Reselection, RCC Redirection & Handover strategies per topology
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 16/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
The following table is making a summary for HSxPA requirements behind each
proposed topology evolution.
Codes mgt:
Data - In order to have the maximum HS-PDSCH codes available, Fair Sharing activation is
recommended (even without resources reservation); numberOfHsScchCodes =
Conversational
3 if the HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often
and if 15 HS-PDSCH codes are not mandatory; 2 otherwise
Power mgt:
Ul load mgt:
totalRotMax = 8dB
Codes mgt:
HSxPA - In order to have the maximum HS-PDSCH codes available, Fair Sharing activation is
recommended (even without resources reservation); numberOfHsScchCodes =
R99
3 if the HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often
and if 15 HS-PDSCH codes are not mandatory; 2 otherwise
Power mgt:
Ul load mgt:
totalRotMax = 8dB
Codes mgt:
HSxPA - In order to have the maximum HS-PDSCH codes available and to perform HSxPA
iMCTA Service load balancing, Fair Sharing activation is mandatory with
R99/HSxPA numberOfHsScchCodes= 2;
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 17/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
only depends upon the UE category; all HSD capable UEs(except Cat 11 and 12)
will always use the 16QAM parameter);
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on both carriers.
Power mgt:
- No PA power pooling
Ul load mgt:
totalRotMax = 8dB for HSXPA carrier and totalRotMax = 6dB for R99/HSXPA carrier
Codes mgt:
other - In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
balancing, Fair Sharing activation is mandatory with numberOfHsScchCodes= 2;
other
If feature 81213 Load Balancing between HSPA Carriers is not activated it is
recommended to:
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on both carriers.
Power mgt:
- No PA power pooling
Ul load mgt:
totalRotMax = 6dB
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 18/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
81213 Load Balancing between HSPA Carriers feature provides further flexibility on
network topology allowing sequential HSPA load strategies between layers build
under segmentation on HSPA capability configuration.
ALU propose the following strategies:
• Traffic Segmentation based on HSPA capability
• Traffic Segmentation based on call type
• Load Distribution (recommended for high traffic)
• HSPA Sequential Load
Data other
Data other
Conversational other
HSxPA HSxPA
HSxPA HSxPA
R99 R99/HSxPA
The following table is making a summary for Cell Reselection, RCC Redirection &
Handover strategies behind each proposed topology evolution. It is considered that
Cell sizes are equivalent (for Cpich Power recommendations please refer to 4.9). 58H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 19/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Idle Mode: Favour Activate 81213 Load Balancing iMCTA Alarm: Conversational calls
Data Conversational carrier on cell between HSPA Carriers feature redirected to GSM; For R99 PS with
selection/reselection by using associated iMCRA low bits rates calls an inter Rat
Data keeping the UE on the functionality with Call Type handover is preferred over an inter
originating FDD1 cell that Segmentation strategy; frequency handover only when FDD
Conversational
had been selected by the UE neighbour target cells are RED.
Establishment cause
for access, avoiding Allow only inter carrier mobility from
“Conversational” redirected to FA
redirection for upper layer to lower layers.
Type ‘Conversational’.
Conversational Services.
iMCTA CAC: An inter Rat handover
Establishment cause “Streaming”,
Connected Mode: Activate is preferred over an inter frequency
“Interactive”, “Background”, “High
Sib4 & Sib12; disable Inter handover only when FDD neighbour
Priority signalling” and
Frequency cell reselection target cells are RED (avoiding
“Registration”: redirected to FA
FDD1 <> FDD2&FDD3 increasing the load of a target FDD
Type ‘Data’ less loaded.
(when UE enters in Cell cell by choosing the 2G access).
FACH, we want him to stay
iMCTA Service used to ensure
on Data layer, not select
Conversational calls are re-directed
back Conversational layer);
on FDD1 and Data calls are re-
UEs camping
directed on FDD2 & FDD3; Also
homogeneously on FDD2 &
ensure Load Balancing between
FDD3 frequencies but with
FDD2 & FDD3.
delayed scanning and higher
hysteresis comparing to Idle
Mode.
Idle Mode: Favour R99 Activate 81213 Load Balancing iMCTA Alarm: Voice calls
carrier on cell between HSPA Carriers feature redirected to GSM. For R99 PS with
HSxPA
selection/reselection by using associated iMCRA low bits rates calls an inter Rat
HSxPA keeping the UE on the functionality with UE Capabilities handover is preferred over an inter
originating FDD1 cell that (traffic segmentation) strategy; frequency handover only when FDD
R99 had been selected by the UE neighbour target cells are RED.
All UEs with establishment cause
for access, avoiding Allow only inter carrier mobility from
"Conversational” redirected to R99
redirection for Speech upper layer to lower layers.
cell.
Services.
iMCTA CAC: An inter Rat handover
DCH capable UE with
Connected Mode: Activate is preferred over an inter frequency
establishment cause “Streaming"
Sib4 & Sib12; disable Inter handover only when FDD neighbour
“Interactive”, “Background”, “High
Frequency cell reselection target cells are RED (avoiding
Priority signalling” and
FDD1 <> FDD2&FDD3 increasing the load of a target FDD
“Registration” redirected to R99
(when UE enters in Cell cell by choosing the 2G access).
cell’.
FACH, we want him to stay
iMCTA Service used to ensure R99
on HSxPA layer, not select HSDPA or HSUPA capable UE
calls are re-directed on FDD1 and
back R99 layer); UEs with establishment cause
HSxPA calls are re-directed on
camping homogeneously on “Streaming" “Interactive”,
FDD2 & FDD3; Also ensure Load
FDD2 & FDD3 frequencies “Background” , “High Priority
Balancing between FDD2 & FDD3.
but with delayed scanning signalling” and “Registration”
and higher hysteresis redirected to HSxPA cells less
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 20/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Idle Mode: Favour R99 Activate 81213 Load Balancing iMCTA Alarm: Voice calls
HSxPA carrier on cell between HSPA Carriers feature redirected to GSM. For R99 PS with
selection/reselection by using associated iMCRA low bits rates calls an inter Rat
HSxPA keeping the UE on the functionality with UE Capabilities handover is preferred over an inter
originating FDD1 cell that (traffic segmentation) strategy but frequency handover only when FDD
R99 / HSxPA had been selected by the UE with layerPreferredForR99 = neighbour target cells are RED.
for access, avoiding TRUE on FDD1 R99/HSxPA cell; Allow only inter carrier mobility from
redirection for Speech upper layer to lower layers.
All UEs with establishment cause
Services.
"Conversational” redirected to iMCTA CAC: An inter Rat handover
Connected Mode: Activate R99/HSxPA cell. is preferred over an inter frequency
Sib4 & Sib12 allowing UE to handover only when FDD neighbour
DCH calls are always assigned to
reselect the best layer when target cells are RED (avoiding
FDD1.
in cell FACH state. increasing the load of a target FDD
HSPA calls are load distributed to cell by choosing the 2G access).
FDD2+ if unloaded FDD2+ cells
iMCTA Service used to ensure R99
available.
calls are re-directed on FDD1 and
Else, if FDD2+ cells are loaded HSxPA calls are re-directed on
then HSPA establishment in FDD2 & FDD3; Also ensure Load
FDD1 if unloaded. Balancing between FDD2 & FDD3.
Idle Mode: UEs camping Activate 81213 Load Balancing iMCTA Alarm & CAC: Voice calls
other homogeneously on different between HSPA Carriers feature redirected to GSM. For PS an inter
frequencies. using associated iMCRA Rat handover is preferred over an
other
functionality with Load Distribution inter frequency handover only when
Connected Mode: Reuse
other strategy inducing redirection to FDD neighbour target cells are RED
Idle Mode configuration with
lowest loaded frequency if (avoiding increasing the load of a
UEs camping
originating cell has cell colour target FDD cell by choosing the 2G
homogeneously on different
YELLOW or RED; example: access); Allow only inter carrier
frequencies.
mobility from upper layer to lower
DCH and HSPA calls are load
layers.
distributed if twin cell load is lower
than originating cell load; Load iMCTA Service used for load
distribution starts later for DCH balancing.
and Streaming calls (when
originating cell becomes RED);
Load distribution starts early for
HSPA calls (when originating cell
becomes YELLOW).
Table 4: summary for Cell Reselection, RCC Redirection & Handover strategies per topology
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 21/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
The following table is making a summary for HSxPA requirements behind each
proposed topology evolution.
Codes mgt:
Data - In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
balancing, Fair Sharing activation is mandatory; numberOfHsScchCodes = 3 if the
Data
HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often and if 15 HS-
PDSCH codes are not mandatory 2 otherwise;
Conversational
If feature 81213 Load Balancing between HSPA Carriers is not activated it is
recommended to:
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on both HSPA carriers.
Power mgt:
Ul load mgt:
totalRotMax = 8dB
Codes mgt:
HSxPA - In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
balancing, Fair Sharing activation is mandatory; numberOfHsScchCodes = 3 if the
HSxPA
HSDPA traffic is high enough to schedule up to 3 ue per TTI quite often and if 15 HS-
PDSCH codes are not mandatory 2 otherwise;
R99
If feature 81213 Load Balancing between HSPA Carriers is not activated it is
recommended to:
Page 22/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
ovsfCodesThroughput16QAMUE=200;
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on both HSPA carriers.
Power mgt:
Ul load mgt:
totalRotMax = 8dB
Codes mgt:
HSxPA - In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
balancing, Fair Sharing activation is mandatory; numberOfHsScchCodes = 2;
HSxPA
If feature 81213 Load Balancing between HSPA Carriers is not activated it is
recommended to:
R99 / HSxPA
- Set minBrForHsdpa= 100 for Interactive and Background; create of new
hsxpaR99ResourcesSharingId= HsxpaR99ResourcesSharingCellClass/1for all carriers
with new values for: initialActivityFactorForIB=100;
reservationFactorOnCodesForGbrTraffic=100; ovsfCodesThroughputQpskUE= 200;
ovsfCodesThroughput16QAMUE=200;
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on FDD2 & FDD3 carriers
(RRC Redirection strategy will force HSPA UEs to establish on FDD2 & FDD3; however, if
FDD2 & FDD3 layers become both overloaded (Black), it is not guaranteed that the Dual
Cell capable UEs would be moved to those capable cells instead of staying on FDD1).
Power mgt:
- No PA power pooling
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 23/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Ul load mgt:
totalRotMax = 8dB for HSXPA carriers and totalRotMax = 6dB for R99/HSXPA carrier
Codes mgt:
other
- In order to have the maximum HS-PDSCH codes available and to perform HSxPA load
other balancing, Fair Sharing activation is mandatory with numberOfHsScchCodes= 2;
Otherwise use HSDPA downlink load criterion associated to feature 81213 with or without
MinBr (retuning of HspaCellLoadParametersparameters may be needed). Retuning of
green2YellowCLCThreshold and yellow2GreenCLCThreshold parameters may be needed
for iMCTA Service, and tuning of fair sharing parameters for iMCTA CAC.
Feature 81204 Dual Cell HSDPA Operation may be activated on FDD2 & FDD3 carriers
(in this case RRC Redirection strategy will place HSPA UEs on less loaded cell; it is not
guaranteed that the Dual Cell capable UEs would be moved to FDD2 & FDD3 capable
cells instead of staying on FDD1).
Power mgt:
- PA power pooling
Ul load mgt:
totalRotMax = 6dB
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 24/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Some other operators deploy U850/U900 carriers mainly in areas where does not
exist U1900/U2100 layers. In this case U850/U900 is deployed to complement the
U1900/U2100 coverage, originating small overlap between different bands. Handover
mobility solution in such scenario may be difficult to manage due to the problematic of
triggering Alarm to rescue calls between layers that have limited overlay and different
exit zones. In these cases, for PS calls, Inter Frequency mobility can be achieved
during cell reselection period when in Cell_FACH/URA_PCH. For CS calls, feature
34224 may be used to activate the simultaneous compressed mode allowing an HHO
to GSM in case of 3G coverage lost.
Usually, the most important constraint to deploy UMTS 900/850 MHz is the frequency
band available by the operator knowing that this frequency band is already used for
GSM network.
U2100 F1
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 25/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Previous recommendations provided in sections 4.4 and 4.5 consider that cell sizes
60H 61H
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;
FDD3 FDD3
GSM
Please note that iMCTA Alarm mobility should be always triggered towards a
continuous layer; i.e. if FDD3 is not a continuous layer configuration should avoid
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 26/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
iMCTA Alarm mobility from FDD2 towards FDD3; this can be achieved in UA7 by
appropriate configuration for Alarm Priority Tables;
FDD1 layer is intended to be the layer providing continuity in the network. For that
reason lowering the initial Cpich Power on FDD1 could have impact on current cell
footprints requiring RF re-design &/OR densification. However, coverage can be ruled
by EcNo rather the by RCSP and Cpich Power reduction on FDD1 can be considered
to increase network capacity in case the area is well covered (good site density). But
Cpich Power reduction on FDD1 should be measured in a cluster basis since CPICH
power differences for adjacent cells can be a source of mobility call drop. On
collocated carriers some operators reduce Cpich Power on upper layers providing
more capacity for traffic channels.
The following recommendations are generic and do not consider the complexity of
different STSR configurations. CPICH design choices can rely on:
• Choice 1: keep initial CPICH design on FDD1 layer & (CPICH-2dB) on upper
layers FDDx
o This configuration may be suitable for asymmetric topologies relying
on FDD1 R99 & FDDx HSxPA configurations; this way HSDPA
throughput is maximized and service voice continuity guaranteed;
o Performance for RRC Redirection from FDD1 to FDDx cells should be
carefully monitored;
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 27/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
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.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 28/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
100%
paRatio (F2)
paRatio (F2)
HSDPA
HSDPA
PA Power Ratio GBR,
R’99
Fixed
partitioning GBR,
Power
R’99
paRatio (F1)
paRatio (F1)
not used
R’99 R’99
0%
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.
When the Multi-Carrier PA Power Pooling is used, the maxTxPower assigned to each carrier,
noted maxTxPower(Fx), is recommended to have the same ratio as the PA ratio attributed to each
carrier, as shown in the following formula.
maxTxPower(Fx) ≤ maxDlPowerCapability(Fx)
With maxDlPowerCapability(Fx) (dBm) = maxPowerAmplification + 10*log( paRatio(Fx)/100) +Tx
Losses (dB)
P max Hspa (F2) [dBm] = Max Tx Power (F2) [dBm] – maxHspaPowerOffset (F2)
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 29/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
At NodeB:
P HSDPA (F2) [W] = Min { P max Hspa (F2) [W] ; PA Power - P Total Non HSDPA with Margin }
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 (refer to the section
8 in the Volume 3)
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 30/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
5.1.1.3 SUPPORTED RADIO CONFIGURATIONS
• STSR2+1
• STSR2+2
The configuration STSR2 * 6 sectors does not support the feature 29808.
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).
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
• Cells belonging to F2 : BTSEquipment/LocalCellGroup frequencyGroupId = 0
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 31/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
BTSEquipment/LocalCellGroup r99ResourceId = x
• Cells belonging to F3 : BTSEquipment/LocalCellGroup frequencyGroupId = 1
BTSEquipment/LocalCellGroup r99ResourceId = y
OMC-R
RNC
RadioAccessService NodeB
Number of instances
DedicatedConf (indicated when > 1) FDDCell
isPowerPoolingActivated
OMC-B
BTSEquipment
paPoolingActivation
BTSCell PaResource 12
paRatio maxPowerAmplification
HsdpaConf
dchPowerMargin
maxHspaPowerOffset: For the considered cell, offset relative to Max Tx Power of this
cell, used to set the maximum allowed power for HSDPA non-GBR traffic and E-DCH
DL channels (PmaxHspa formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to [Vol. 3], section 64H
8.2.1.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 32/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
DL CAC and DL iRM” (Ptraffic formula with 29808 activated) and 5.1.2.4. 6H
Parameter paOverbookingRatio
Object HsdpaCellClass
Granularity HsdpaCellClass
Range & Unit Integer [1 … 100], %
User & Class Customer, 3
Value 30
Parameter isPowerPoolingActivated
Object FDDCell
Granularity FDDCell
Range & Unit Boolean {False, True}, N/A
User & Class Customer, 3
Value F1: False
F2: True
activityFactorCcch: For the considered cell, common channels activity factor used in
power reservation for common channels, regarding DL CAC and DL iRM of R99 and
HSDPA GBR traffic (Ptraffic formula). For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to [Vol. 3], section 68H
8.2.1.
maxTxPower:
For the considered cell, used to set maximum allowed Tx power for all DL physical
channels added together (common + traffic), at the reference point. maxTxPower
value takes into account power partitioning between cells served by the considered
PA. For the detailed description of the parameter (parameter frame with explicit
recommended value, engineering recommendation), please refer to UA7 UPUG [R01], 69H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 33/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
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.
paPoolingActivation: For the case where NodeB PA is shared between two carriers
(F1 for R99 traffic and F2 for HSPA (+R99) traffic), flag enabling dynamic PA power
sharing between F1 and F2, at NodeB level.
Parameter paPoolingActivation
Object BTSEquipment
Granularity BTSEquipment
Range & Unit Boolean {False, True}, N/A
User & Class Customer, 0
Value True
paRatio:
For the case where NodeB PA is shared between multiple carriers, maximum allowed
ratio of PA power for the considered cell. For the detailed description of the parameter
(parameter frame with explicit recommended value), please refer to UA7 UPUG [R01], 70H
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 [Vol. 3], sections 8.
71H
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 34/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
5.1.2.4 OTHER RECOMMENDATIONS
PA OVERBOOKING RATIO
The PA overbooking ratio should not exceed 130%.
For recall, the PA overbooking ratio is: (Max Tx Power (F1) + Max Tx Power (F2)) / PA
Power
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
paOverbookingRatio :
Set according to Max Tx Power (F1), Max Tx Power (F2) and PA Power,
as explained above in 5.1.1.2. 74H
Example:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 35/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 36/37
HSxPA Parameters User Guide 04.06 / EN 10/Sep/2010
UMT/IRC/APP/016664 EXTERNAL Preliminary
Volume 7 : Deployment Scenarios
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
Page 37/37
UMT/IRC/APP/016664 V04.06
HSXPA PARAMETERS USER GUIDE UA7 10/SEP/2010
Z END OF DOCUMENT Y
Alcatel-Lucent – Proprietary