Documente Academic
Documente Profesional
Documente Cultură
Document number:
Document issue:
Document status:
Date:
UMT/IRC/APP/016664
V03.10
Standard
02/Oct/2009
External Document
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
V03.10
02/OCT/2009
Alcatel-Lucent Proprietary
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
CONTENTS
1
INTRODUCTION
HSXPA OVERVIEW
CALL MANAGEMENT
MOBILITY
DEPLOYMENT SCENARIOS
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
INTRODUCTION
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
CONTENTS
1
INTRODUCTION..........................................................................................................................11
1.1
OBJECT ..................................................................................................................................11
1.2
1.3
1.4
NOMENCLATURE .....................................................................................................................13
1.5
ABBREVIATIONS ......................................................................................................................18
3.2
DEFINITIONS ...........................................................................................................................23
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
PUBLICATION HISTORY
02/10/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 3:
Clarification of the recommendation concerning the mac-d PDU size for Cat.6
and 12
Range
of
serviceMaxRate,
serviceLowRate corrected
serviceMinRate,
serviceHighRate,
In Volume 5:
Recommended value for dlTxPowerEstimation corrected
24/09/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 5:
Update concerning the parameter edchMaxNumberUserNodeB.
02/09/2009
Issue 03.10 / EN, Standard
Updates:
In Volume 4:
Notes added to the parameters totalRotMax and referenceRTWP
concerning the utilisation of two distinguish classes.
Update of the parameter referenceRtwp
25/08/2009
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Issue 03.10 / EN, Standard
Updates:
In Volume 4:
Deletion of the remarks, including comments related to the xCEM resets and
cell lock-unlock, for the parameters eagchPowerControlModeXcem,
ehichErrorProbability, minPowerCorrection, maxPowerCorrection,
pMinDlEDCH and pMaxDlEDCH
26/06/2009
Issue 03.09 / EN, Standard
Updates:
In Volume 1:
Clarification of the meaning of Class 3 parameters and also other class
general updates.
In Volume 3:
Wrong parameter name: hsdpaGbrNbUeTtiForgettingFactor replaced by
hsdpaGbrNbUePerTtiForgettingFactor
Clarification of the support of E-RGCH by iCem
Clarification of the recommendation for hsdpaFullPowerUsage
Clarification of the formula used to compute the power reservation from
DlTxPowerEstimation
Clarification of the case Mobility over Iur for the feature Dynamic mac-d pdu
size mgt
Clarification
concerning
HsdpaGbrIncreaseFactorForMobility
the
parameter
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Clarification
regarding
the
isEdchFpBundlingModeForEdchTti2msAllowed
isEdchFpCrcPayloadPresence
parameters
and
06/03/2009
Issue 03.08 / EN, Preliminary
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Updates:
In Volume 3:
Clarification of the Dyn Bler Target algo
Clarification of the QoS management (section 4.3 SPI management
renamed QoS management) and Crmax behavior
Section related to the 656 PDU QUALCOMM UE BUG WORKAROUND
added
In Volume 4:
Update regarding the Iub congestion handling for edch in Vol.4; 6.8 & 7.8
Update regarding the priority info in mac-e scheduler in Vol.4; 6.7 & 7.6
Update regarding the ue categories in Vol.4; 5.2 and Vol.2; 4.2
Update regarding the ibts local congestion control in Vol.4; 7.8.4
Update regarding rseps measurements in Vol.4; 4.1.2
Update regarding the location of totalRotMax
Update of "xCEM/10ms TTI" and "xCEM/2ms/2xSF2 TTI" {Ref E-TFCI; Ref
PO} tables (Vol.4, 5.4), plNonMax recommended value for 2ms E-DCH TTI
(Vol.4, 5.5)
Update of happyBitDelayEdchTti2ms, periodicityOfSchedInfoXxx,
edchInitialTBIndex10msTTI, and 2ms edchMinSetEtfci recommended
values (Vol.4, 7.2, 7.4)
Update on 2ms E-DCH TTI activation method (Vol.4, 5.1)
Addition of recommended settings for 2ms TTI with SRB on E-DCH, incl.
addition of "xCEM/2ms TTI/2xSF2+2xSF4" {Ref E-TFCI; Ref PO} table (Vol.4,
5.4, 5.5, 8.1.2.3)
Updates on UA6 34249 "Optimized HARQ" feature (Vol.4, 8.1.2):
Behavior for E-DCH handled on iCEM, behavior for SRB on E-DCH case,
update of recommended settings
Updates on power control of E-DCH DL channels (Vol.4,
Correction of parameter definitions, update of recommended settings
8.2):
Page 5/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Clarification of the rule of the parameter isGbrOnHsdpaAllowed
Clarification of the Fair Sharing/GBR features
In Volume 7:
Engineering recommendation concerning the maximumBucketSize is deleted
since this parameter is no more used in UA6.0
In Volume 8:
Volume 8 has been deleted (see section 1.2)
In Volume 9:
Volume 9 has been deleted (see section 1.2)
In Volume 10 (new name: Volume 8 since Volume 8 and 9 have been deleted):
Updates on UA6 29808 "PA Pooling" feature (Vol.10, 6.1.2.4): Change in "PA
overbooking ratio" definition
28/10/2008
Issue 03.07 / EN, Preliminary
Updates:
In Volume 2 and 3:
Granularity Change: Because of the 33621 HSPA Configuration at site
Granularity feature, its now possible to have until 15 different instances.
Different values can also be defined per FDDCell for the parameters under the
HsdpaUserService (this is possible using HsdpaUserServiceId under
HsdpaResource)
In Volume 3 :
Clarifications on Management of UL power profiles... sub-feature of UA6
34246: Sub-feature applies to both Global Market and USA market, and
includes all the functionalities of UA5.1.2 34652 (Vol.3, 8.5)
hsdschPowReportingPeriod replaced by hsdschReqPwReportingPeriod
New
recommendation
for
hsdpaBlerTargetLowerLimit,
hsdpaBlerTargetMediumLimit, hsdpaAdjustBlerToChannelVariation
Clarification of the recommendation for hsscchSnr
Modification of the recommendation for servicehighrate in case of PS
Streaming
Rule added related to ue capability and 656 bits feature
spi parameter added
Rule added related to DCTM and Fair Sharing activation
Correction of the numerical example given in the engg recommendation
related to spreadingFactorLevelForOvsfMonitoring
Clarification of the engg recommendation concerning the 656 bits activation
according to the ue categories (eligibleUeCategoryForHighPerformance)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
In Volume 4:
Correction on parameter name: Correction of parameter name: from
edchDeSequencingWaitTimerIP to DeSequencingWaitTimer (RAN Model
designation)
Update of "xCEM/10ms TTI" {Ref E-TFCI; Ref PO} table, addition of "UCUIII" {Ref E-TFCI; Ref PO} table (Vol.4, 5.4)
Update of nHarqRetransTargetSx parameters for 10ms E-DCH TTI (Vol.4,
8.1.2.3.4)
Mention of hard-coded offset on top of E-DCH maxSirTarget for 2ms E-DCH
TTI (Vol.4, 8.1.2.3.4)
edchSpi parameter added
In Volume 5:
Modification
of
the
recommendation
transportTypeSelectionTransferDelayThreshold
for
29/08/2008
Issue 03.06 / EN, Preliminary
Updates:
General update of section on management of UL power profile for HSDPA calls, with
description of UA6 "Management of UL power profiles... sub-feature of UA6 34246
(Vol.3, 8.5)
General update of section on E-DCH UL OLPC (presentation, corrections), with
addition of iCEM and OneBTS specific parameter settings (Vol.4, 8.1)
General update of section on E-DCH Mobility (presentation, corrections), with
addition of information related to OneBTS (Vol.6, 3.3)
Update of section on setting of number of E-AGCH and E-RGCH/E-HICH channels
per cells (4.2.2.2): Changes in recommended values, mention of UA6 34175 "UA06
xCEM HSPA Capacity Evolution" feature, addition of warnings on operational impact
of wrong settings.
Clarifications regarding iBTS NodeB internal power checks (Vol.3, 8.4)
For some parameters (mostly related to E-DCH DL ch. power control), addition of
required operation at OAM (e.g. NodeB reboot) to take into account a parameter
setting change.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Update of Abbreviations section (Vol.1, 3.1)
Miscellaneous
updates
(totalRotMax,
edchHarqMaxRetransEdchTtixx, harqType...)
edchInitialTBIndex,
plNonMax,
In Vol.3:
Forgetting factor formula for xCem (used to average the throughput of each
mac-d flow) corrected
Clarification concerning schedulingPriorityLevel in UA5.1 and UA6.0
serviceHighRate: value updated and engg recommendation addedhsdschReqPwReportingPeriod and hsdschReqPwFilterCoeff added
Minimum value for HS-SCCH power added
Clarification of the term factor used to compute the HS-DSCH power by
xCem
Updates of the computation of the number of HS-PDSCH codes used by
xCem
hsScchSnr value updated
hsdpaBlerTargetUpperLimitXcem value updated
Spectral Efficiency computation updated
Excess power algorithm updated
Restriction
concerning
the
algorithm
dynamicHarqTxTarget
hsdpaCqiBlerAdjustmentAlgorithmXcem) added
(parameter
In Vol4:
Update and addition of new UA6 parameters
Description of Mac-e non scheduled mode sub-feature
Description of RSEPS NBAP measurements
In Vol.5:
maximumNumberOfUsers : class 3, not class 0 and update of the definition.
Recommendation for minBrForHsdpa added
Recommendation for minHsDschReservationForCac added
Recommendation for dlTxPowerEstimation added
In Vol6 :
Description of HSUPA over Iur feature
27/06/2008
Issue 03.05 / EN, Preliminary
Updates
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
20/06/2008
Issue 03.04 / EN, Draft
Updates
06/06/2008
Issue 03.03 / EN, Draft
Updates
23/May/2008
Issue 03.02 / EN, Draft
Updates
28/March/2008
Issue 03.01 / EN, Draft
Document Creation
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
FIGURES
Figure 1: Static and Configuration Parameters
16
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
1 INTRODUCTION
1.1 OBJECT
The HSxPA Parameters User Guide (HPUG) document provides parameters setting
recommendations from Alcatel-Lucents experience, coming from studies, simulations
and experimentations. It gives the rationales of these settings by describing the
HSDPA & E-DCH (HSUPA) system from an engineering point of view. It also gives
some engineering rules related to parameters settings. This includes a system
description, configuration aspect and engineering recommendations.
The HPUG does not contain the complete list of configuration parameters, this
objective being covered in [R01].
The parameters described in this document are mainly customer configuration
parameters accessible by the customer (operator) via the MMI of the OMC.
Nevertheless, some manufacturer configuration parameters as well as some static
parameters are also covered when they are required to understand the different
UMTS mechanisms.
In the case where the recommended values of the HPUG are different from any other
document, the HPUG recommended should prevail.
The parameter values in HPUG are the recommended values by Alcatel-Lucent, which
means that they are the best values to achieve the optimal network performance.
A common and single UA06 load is delivered to address the needs of all AlcatelLucent WCDMA customers, which are grouped into two different markets due to their
particular functional specificities:
USA Market, i.e. customers with UTRAN where Alcatel-Lucent 939X Node B
(former Lucent OneBTS) is deployed
Global Market, i.e. any other customers
This document provides a description of the features included in the UA06 release. At
the beginning of each volume, a table has been added to clearly indicate to which
market, among the two listed previously, each feature is applicable to. Note that one
feature can belong to one or two markets but:
A feature which is not applicable to USA Market is not supported on a
UTRAN with Alcatel-Lucent 939X Node B (former Lucent OneBTS).
For features common to USA market and Global markets, the behaviour on
UTRAN with 939X Node B might be different from other Alcatel-Lucent Node
B products, in which case the differences are described in the Hardware
Dependencies section.
Features are by default not supported on 9313 Micro Node B nor 9314 Pico Node B.
For the list of features supported on these products please refer to 33341 AlcatelLucent 9313 Micro Node B and 33342 Alcatel-Lucent 9314 Pico Node B
descriptions.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Tag [iCEM] indicates that the behavior or the feature is specific to iCEM.
Tag [xCEM] indicates that the behavior or the feature is specific to xCEM only
or to xCEM and UCU-III if there is no [UCU-III] tag.
Tag [UCU-III] indicates that the behavior or the feature is specific to [UCU-III].
No tag indicates that the behavior or the feature is common for all the boads.
R99 related features and settings are not part of this document. Please refer to
[R01]a.[R02].
The following volumes have been deleted from the UA6.0 HPUG and replaced by a
specific document:
-
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.
Page 12/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
RF engineering
UTRAN Datafill
Trials and VO
1.4 NOMENCLATURE
Parameter
Range & Unit
User
Class
Value
Object
Granularity
The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.
Rule:
Restriction:
Engineering Recommendation:
The difference between Release N and Release N-1 are presented as the
following:
UAN-1-UAN Delta:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
1.5 RELATED DOCUMENTS
Reference documents:
[R01] NTP 411-8111-813
[R02] UMT/DCL/DD/0020
[R03] UMT/IRC/APP/0164
[R04] UMT/IRC/APP/025147
[R05] UMT/IRC/APP/007147
[R06] UMT/SYS/INF/016608
[R07] UMT/BTS/INF/016135
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 15/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
2 PARAMETERS ORGANIZATION
In order to understand the definition and the role of the different parameters, it is
appropriate to explain how these parameters are linked together and grouped within
the RAN model.
RNC
OMC
WPS
Static
WPS Templates
Customer
Non-Static
Manufacturer
CIQ
OMC
database
System DRF
There are two main kinds of parameters in Alcatel-Lucents system, the static and
configuration parameters.
A new network element needs to be reloaded and built in order to change their values.
Customer: Can be modified by the customer at the OMC (at the MMI or with
DRFs).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
o
Regardless of the parameter type (customer or manufacturer), the parameters can have
the following classes:
o
Class 0: the value of the parameter is set at the parent object creation.
Currently, most of the objects can only be killed and re-created through a new
MIB built (either btsEquipmentMIB or rncMIB).
Class 1: new parameter value is taken into account on the next RNC restart.
This class is no longer valid.
Class 3-A2: new value is taken into account upon event reception
(service establishement, SRLR).
Class 3-B: new value is taken into account for next call.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Acknowledgment
AICH
AM
Acknowledged Mode
AMC
ARP
ARQ
ATM
AS
Active Set
BBU
Base-Band Unit
BLER
CAC
CC
Chase Combining
CCPCH
CEM
CFN
CM
Compressed Mode
CN
Core Network
CP
CPICH
CRC
CS
Circuit Switched
DCH
Dedicated Channel
DDM
DL
Downlink
DPCCH
DPDCH
DS
Delay Sensitive
DS1
DTX
Discontinuous Transmission
E-AGCH
E-DCH
E-DPCCH
E-DPDCH
E-HICH
E-RGCH
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
E-TFC
E-TFCI
EUL
FP
FRS
GMM
H-ARQ
Hybrid ARQ
HCS
HS-DSCH
HS-SCCH
HSDPA
HSUPA
HHO
Hard Handover
HO
Handover
IE
Information Element
iMCTA
iRM
IMEI
IMSI
IP
Internet Protocol
IR
Incremental Redundancy
KPI
LA
Location Area
LAC
LCG
MAC
MCPA
MIB
MMI
Man-Machine Interface
MO
Mobile Originated
MT
Mobile Terminated
NACK
Negative Acknowledgement
NAS
NBAP
NDS
Non-Delay Sensitive
OAM
OLPC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
OLS
OMC
OMC-B
OMC NodeB
OMC-R
OMC RNC
OVSF
PA
P-CCPCH
Primary CCPCH
PCPCH
P-CPICH
Primary CPICH
PCR
PDU
PICH
PLMN
PRACH
PS
Packet Switched
P-SCH
Primary SCH
PSCR
QAM
QoS
Quality of Service
QPSK
RA
Registration Area
RAB
RACH
RAN
RANAP
RAT
RB
Radio Bearer
RL
Radio Link
RLS
RLC
RMS
RNC
RNC-AN
RNC-CN
RNC-IN
RNS
RoT
RRC
RRM
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
RSCP
RSN
RSSI
RTWP
SCCP
S-CCPCH
Secondary CCPCH
SCH
Synchronization Channel
S-CPICH
Secondary CPICH
SCR
SDU
SF
Spreading Factor
SFN
SHO
Soft Handover
SI
Scheduling Information
SIB
SM
Session Management
SRB
SRLR
SS7
Signaling System 7
S-SCH
Secondary SCH
STM1
TFC
TFCI
TFCS
THP
TM
Transparent Mode
TNL
TRB
TrCH
Transport Channel
TRM
Transceiver Module
TS
Technical Specification
TTI
UBR
UE
User Equipment
UL
Uplink
UM
Unacknowledged Mode
URA
UTRAN
VCC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
VP
Virtual Path
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
3.2 DEFINITIONS
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/24
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 1 : Introduction
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/24
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
HSXPA OVERVIEW
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CONTENTS
1
INTRODUCTION............................................................................................................................4
1.1
OBJECT ....................................................................................................................................4
1.2
2.2
HSDPA ...................................................................................................................................9
3.1.1
Transport and physical channels ....................................................................................9
3.1.1.1
Downlink channels.................................................................................................... 12
3.1.1.2
Uplink channels ........................................................................................................ 13
3.1.2
Fast link adaptation .......................................................................................................15
3.1.3
Fast Retransmission Mechanism (HARQ) ....................................................................16
3.1.3.1
Number of HARQ Processes.................................................................................... 16
3.1.3.2
RV Parameters ......................................................................................................... 17
3.1.3.3
State of HARQ Processes ........................................................................................ 19
3.1.3.4
Choice of the HARQ type ......................................................................................... 21
3.1.4
Fast scheduling .............................................................................................................25
3.2
HSUPA (E-DCH)...................................................................................................................26
3.2.1
Transport and physical channels ..................................................................................26
3.2.1.1
Uplink channels ........................................................................................................ 28
3.2.1.2
Downlink channels.................................................................................................... 31
3.2.2
UA5 implementation of E-DCH .....................................................................................34
4
UE CATEGORIES........................................................................................................................35
4.1
HSDPA .................................................................................................................................35
4.2
HSUPA .................................................................................................................................36
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TABLES
Table 1: HSUPA / HSDPA comparison
Table 2: Number of processes per UE category for iCEM
Table 3: RV coding for 16QAM
Table 4: RV coding for QPSK
Table 5: RV update table in the MIR case (Trv[i])
Table 6: RV update table in the PIR case (Trv[i])
Table 7: RV updates tables when harqType set to Dynamic Redundancy
Table 8: Number of processes per UE category for xCEM/UCU-III
Table 9: RV update table in the IR case (Trv[i])
Table 10: RV update table in the CC case (Trv[i])
Table 11: E-DPDCH slot formats
Table 12: E-DPCCH slot formats
Table 13: E-DPCCH power offset index vs. amplitude
Table 14: Relative grant information (E-RGCH)
Table 15: ACK/NACK information (E-HICH)
Table 16: HSDPA UE categories (3GPP TS25.306)
Table 17: HSUPA UE categories (3GPP TS25.306)
8
16
18
18
21
21
22
24
24
24
29
29
31
32
33
35
36
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FIGURES
Figure 1: R99 principle ........................................................................................................................................ 6
Figure 2: HSDPA principle .................................................................................................................................. 6
Figure 3: HSDPA layer2/layer1 flows ................................................................................................................ 7
Figure 4: MAC-hs entity on UTRAN side .......................................................................................................... 7
Figure 5: Protocol Architecture of E-DCH......................................................................................................... 9
Figure 6: UE side MAC architecture .................................................................................................................. 9
Figure 7: Transport channel configuration...................................................................................................... 10
Figure 8: HSDPA channels and associated R99 channels.......................................................................... 11
Figure 9: Timing relationship at NodeB between physical channels .......................................................... 12
Figure 10: HS-SCCH structure......................................................................................................................... 13
Figure 11: HS-PDSCH structure ...................................................................................................................... 13
Figure 12: HS-DPCCH structure...................................................................................................................... 14
Figure 13: Example of AMC: Throughput versus Ior/Ioc (radio condition)................................................. 16
Figure 14: RV parameters assignment algorithm .......................................................................................... 19
Figure 15: ACK/NACK/DTX management for HARQ processes ................................................................ 20
Figure 16: Dynamic selection of HARQ type.................................................................................................. 23
Figure 17: HSUPA channels and associated R99 channels........................................................................ 27
Figure 18: E-DPCCH / E-DPDCH frame structure ........................................................................................ 29
Figure 19: E-DPDCH/E-DPCCH multiplexing on I/Q .................................................................................... 30
Figure 20: Uplink physical channels multiplexing.......................................................................................... 30
Figure 21: E-AGCH frame structure ................................................................................................................ 31
Figure 22: E-HICH frame structure .................................................................................................................. 33
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.
description,
configuration
aspect
and
engineering
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios
[R07] UMT/BTS/INF/016135
Planning Guide
[R08] UMT/IRC/APP/007147
[R09] UMT/IRC/APP/014654
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
3 SYSTEM OVERVIEW
HSDPA
3GPP has standardized HSDPA in Release 5 [R01] in order to increase maximum
user throughput for downlink packet data (streaming, interactive and background
traffic classes) and decrease downlink packet transmission delay. This Release 5 is
fully compatible with the previous Release 99 (R99).
In R99, data are transmitted on a dedicated channel with a given user throughput and
a downlink transmitted power controlled according to the radio conditions:
Same Throughput
Unused
Power
Control
Unused Power
Data
Data Power
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 AlcatelLucent written authorization
Page 6/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
MAC Control
MAC Control
MAC Control
MAC-hs
MAC-hs
(NodeB)
(NodeB)
DCCH DTCH
DTCH
MAC-d
(S-RNC)
MAC-c/sh
MAC-c/sh
(C-RNC)
(C-RNC)
Associated
Downlink
Signaling
HS-DSCH
Associated
Uplink
Signaling
PCH
R5
R5L1:
L1:HSDPA
HSDPA(NodeB)
(NodeB)
HS-SCCH
HS-PDSCH
HS-DPCCH
FACH
RACH
CPCH
DSCH
DCH
DCH
R99
R99L1:
L1:Channel
ChannelCoding
Coding/ /Multiplexing
Multiplexing(NodeB)
(NodeB)
S-CCPCH
S-CCPCH
PRACH
PCPCH
PDSCH
DPCH
DPDCH/DPCCH
Fast scheduling.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA
HSUPA
Fast scheduling
Macrodiv
TTI
Modulation
Channel
coding
Power
control
HARQ
Fast
scheduling
Fast link
adaptation
Not
supported
2 ms
only
QPSK and
16QAM
Turbo
No
Supported
Supported
Supported
Supported
2 ms,
10 ms
BPSK and
QPSK
Supported
Supported
but less
reactive
Supported
but less
reactive
Turbo
Yes
BPSK modulation only, QPSK is used when there is more than one E-DPDCH
physical channel (SF4).
Turbo coding
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
DTCH DCCH
DCCH DTCH
MAC-d
MAC-d
MAC-es
MAC-es /
MAC-e
MAC-e
MAC-e EDCH FP
PHY
UE
PHY
Uu
EDCH FP
TNL
TNL
NodeB
Iub
TNL
TNL
DRNC
Iur
SRNC
M A C C o ntro l D C C H
DTCH
D TC H
M A C -d
M A C -es /
M A C -e
E -D C H
A sso c ia te d
D o w nlink
S igna lling
A sso cia te d
U p link
S igna lling
M A C -c/sh
M A C -h s
H S -D S C H
A sso cia te d
A sso cia te d
D o w nlink
U p link
S igna lling
S igna lling
PC H
FA C H
FA C H R A C H
DCH
3.1 HSDPA
3.1.1 TRANSPORT AND PHYSICAL CHANNELS
In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on
the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are sent
on a HS-DSCH (High Speed Downlink Shared CHannel) which is mapped on one or
several HS-PDSCH (High Speed Physical Downlink Shared CHannel). Users are
multiplexed on the HS-DSCH channel in time and code. Transmission is based on
shorter sub-frames of 2ms (TTI) instead of 10ms in R99.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/38
DCH
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA channels
NodeB
HSDPA UE
The maximum bit rate that can be achieved in the UL can be the bottleneck for the
maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP
acknowledgements due to low bandwidth in the UL will limit the DL throughput, even if
the RF conditions would allow more.
From UA04.2, the RB adaptation feature is supported. This feature dynamically adapts
the UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from
8kbps up to 384kbps, but 8kbps is not recommended to be activated (configured as
eligible). Therefore, although UL:8 DL:[max bit rate for UE categories 12 and 6] will be
allocated by the RNC if UL:8 is explicitly requested in the RAB assignment, it is not
recommended to do so, otherwise the user will experience low throughput in the DL.
The following flowchart describes the timing relations between the different physical
channels:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HS-SCCH#2
2 slots
HS-PDSCH
N_acknack_transmit = 2
HS-DPCCH
ACK
ACK
ACK
7,5 slots
UE identity (16 bits used as a mask in slots #0, #1 & #2 of subframe), i.e.
subset of the HRNTI
The SF is fixed to 128. It indicates to which UE data is intended to, on which codes
and with which parameters. There are as many HS-SCCH transmitted during a TTI as
scheduled user number.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 12/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Data
Slot #0
Slot #2
Slot #1
1 HS-SCCH subframe = 2ms
Figure 10: HS-SCCH structure
A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been
assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this
slot #0, other information are given in slots #1 and 2): the mobile receives a transport
block on one or several HS-PDSCH (see the following figure).
Data
Slot #0
Slot #1
Slot #2
M= 2 for QPSK
(960 coded bits per TTI)
M = 4 for 16QAM
(1920 coded bits per TTI)
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).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ACK/NACK
CQI
Subframe #0
Subframe #4
Subframe #i
1 radio frame = 10ms
Figure 12: HS-DPCCH structure
The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the
N_acknack_transmit parameter, as specified in [R04] 6A.1.1.
Parameter
Range & Unit
User
Class
Value
ackNackRepetitionFactor
[1..4]
Customer
3
1
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
The CQI is only sent in some specific subframes, as specified in [R04] 6A.1.1,
depending on the following parameters:
Parameter
Range & Unit
User
Class
Value
cqiRepetitionFactor
[1..4]
Customer
3
1
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
cqiFeedbackCycleK
Enum {0, 2, 4, 8, 10, 20, 40, 80, 160} ms
Customer
Granularity
3
2
HsdpaUserService
HsdpaUserService[0..14]
Parameter
Range & Unit
User
Class
Value
cqiPowerOffset
[0..8]
Customer
3
5
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
Parameter
Range & Unit
User
Class
Value
ackPowerOffset
[0..8]
Customer
3
6
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
Parameter
Range & Unit
User
Class
Value
nackPowerOffset
[0..8]
Customer
3
7
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
Page 15/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
AMC Illustration
800
700
Throughput (kbps)
600
500
QPSK
QPSK
QPSK
16QAM
16QAM
400
300
200
100
0
-20
-15
-10
-5
Ior/Ioc (dB)
Retransmitting by the NodeB the data blocks not received or received with
errors by the UE;
Ue Category
10
11
12
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
harqNbMaxRetransmissions
[131] decimal
Customer
3
7
Object
HsdpaConf
Granularity
BTSCell
The two following parameters are common for iCEM and xCEM (RNC parameters):
Parameter
Range & Unit
User
Class
Value
Object
HsdpaUserService
discardTimer
Enum [20; 40; 60; 80; 100; 120; 140; 160; 180 ; 200; 250; 300; 400; 500; 750;
1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500] ms
Customer
Granularity
HsdpaUserService[0..14]
3
500
This parameter defines the time to live for a MAC-hs SDU starting from the instant of
its arrival into an HSDPA Priority Queue.The Node B shall use this information to
discard out-of-data MAC-hs SDUs from the HSDPA Priority Queues
Parameter
Range & Unit
User
Class
Value
Object
HsdpaUserService
timerT1
Enum [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, 400] ms
Customer
Granularity
HsdpaUserService[0..14]
3
100
This parameter is used by the NodeB to stop the re-transmission of the corresponding
MAC-hs PDU (but ignored by the iCEM).
3.1.3.2 RV PARAMETERS
The IR (Incremental Redundancy) and modulation parameters necessary for the
channel coding and modulation steps are: the r, s and b values. The r and s
parameters (Redundancy Version or RV parameters) are used in the second rate
matching stage, while the b parameter is used in the constellation rearrangement step
(see [R03] for details):
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
These three parameters are indicated to the UE by the Xrv value sent on the HSSCCH (see section 3.1.1.1). The coding tables of Xrv are given hereafter:
Xrv (Value)
Xrv (Value)
The determination of the s, r and b parameters will be based on the Xrv update, but
not necessarily in the increasing order. The update indeed follows a predefined order
stored in a table (called hereafter Trv). The only requirement to fill this table is that
Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be the
nominal configuration).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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).
Y
New transmission ?
Xrv = Trv[0]
k=0
N
DTX indication ?
Xrv(n) = Xrv(n-1)
N
k=k+1
Xrv(n) = Trv[k mod Nmax]
Nmax = 1 (CC)
= 4 (PIR - QPSK)
= 6 (PIR 16QAM)
= 8 (MIR)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Update of RV parameters
Data transmission
ACK
WACK state
DTX
ACK/NACK/DTX ?
Insertion of DTX
indication
NACK
Reset HARQ process
Remove Mac-d PDU
Update structures
Nret = Nret +1
N
NACK/DTX state
Wait for
retransmission
In case of a DTX indication, the same actions as for a NACK reception are
done, except that a parameter must be updated to notify DTX detection (this
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The processes in the NACK or DTX state are just waiting for being re-scheduled for a
new retransmission.
The PIR indicates that for all redundancy versions, the systematic bits must
be transmitted (blocks are self-decodable). Only the RV with s = 1 must be
taken into account.
The MIR corresponds to a sequence where both systematic and nonsystematic bits can be punctured. All possible redundancy versions are
assumed and it corresponds to default version.
Each HARQ type is characterized by its update table Trv (see tables below)
Xrv(QPSK)
Xrv(16QAM)
Xrv(QPSK)
Xrv(16QAM)
The choice of the HARQ type (CC, MIR or PIR) is defined for all the retransmissions
by setting the parameter harqType (= 1 for MIR, = 2 for PIR and = 3 for CC). When
the HARQ type is selected, specific RV tables are used, one for QPSK and another
one for 16QAM (as explained in the previous paragraphs).
With the feature HSDPA Performance Enhancement Optimal Redundancy Version
for HARQ retransmission (29819), a fourth HARQ type can be selected: the Dynamic
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
NP1 and NP2: number of parity bits 1 and 2 after 1st RM step.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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].
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
10
11
12
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.
harqNbMaxRetransmissionsXcem
[131] decimal
Customer
0
7
Object
HsdpaConf
Granularity
BTSCell
harqTypeXcem
[ccType, irType]
Customer
3
irType
Object
HsdpaConf
Granularity
BTSCell
The following tables give according to [R03] the redundancy version and constellation
depending on the modulation:
i
Xrv(QPSK)
Xrv(16QAM)
Xrv(QPSK)
Xrv(16QAM)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[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:
The Queue ID (QId) is chosen according the Scheduling Priority Indicator (SPI
or CmCH-PI) and the radio condition based on CQI.
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:
[xCEM]
The aim of the scheduler is to share the resources between the different HSDPA
users. xCEM scheduler works in following steps:
-
To select of a limited number of users from those which are ready for
transmission in the curret TTI (the number of users per TTI being
limited by the number of HS-SCCH configured and by the available
resources mainly in term of codes and power).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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 AlcatelLucent written authorization
Page 26/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
H
PD
C
E-
HI
CH
EA
GC
ERG
H
CH
ED
E-
DP
CC
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
Transport block size and Transport Block set size are free attributes of the
transport format.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchHarqMaxRetransEdchTti10
Integer [0 ..15], N/A
Customer
3
[iCEM] [xCEM] 4
[UCU-III] 3
Object
EdchParameters
Granularity
RNC,
UlRbSetConf
[xCEM]
edchHarqMaxRetransEdchTti2: Defines the maximum number of retransmission at
E-DCH HARQ level when the UL RB is mapped on E-DCH with an E-DCH TTI of 2ms.
Parameter
Range & Unit
User
Class
Value
edchHarqMaxRetransEdchTti2
Integer [0 ..7], N/A
Customer
3
7
Object
EdchParameters
Granularity
RNC,
UlRbSetConf
The E-DPDCH and E-DPCCH (sub) frame structure is presented on the figure below
(from [3GPPref]):
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
E-DPCCH
10 bits
Slot #0
Slot #1
Slot #2
Slot #i
Slot #14
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
SF
Bits/ Frame
Bits/ Subframe
0
1
2
3
4
5
6
7
15
30
60
120
240
480
960
1920
256
128
64
32
16
8
4
2
150
300
600
1200
2400
4800
9600
19200
30
60
120
240
480
960
1920
3840
Bits/Slot
Ndata
10
20
40
80
160
320
640
1280
Slot Format #i
SF
Bits/ Frame
15
256
150
30
Bits/Slot
Ndata
10
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ed,1
iqed,1
ced,k
ed,k
iqed,k
E-DPDCH1
.
.
.
.
E-DPDCHk
.
.
.
.
ced,K
ed,K
iqed,K
cec
ec
iqec
I+jQ
Se-dpch
E-DPDCHN
E-DPCCH
DPCCH
DPDCHs
Sdpch
Spreading
Sdpch,n
Shs-dpcch
HS-DPCCH
Spreading
E-DPDCHs
E-DPCCH
I+jQ
S
Se-dpch
Spreading
The reference E-TFCI transport blocks and power offsets are signaled through the call
setup message. They contain a subset of the authorized E-TFCI.
One E-DPCCH frame contains 10 bits, 7 for E-TFCI index, 2 for the RV version used
(HARQ process), and 1 happy bit. The power offset of the E-DPCCH can be set
through deltaEdpcch parameter:
Parameter
Range & Unit
User
Class
Value
deltaEdpcch
Integer [0 8], N/A
Customer
0
4
Object
EdpchParameters
Granularity
RNC, EdpchInfoClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 30/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
10 20
30/15
24/15
19/15
15/15
12/15
9/15
8/15
6/15
5/15
Table 13: E-DPCCH power offset index vs. amplitude
The value of ec is based on the power offset E-DPCCH signalled by higher layers. The
formula to apply is:
ec = c 10
E DPCCH
20
E-AGCH
20 bits
Slot #0
Slot #1
Slot #2
Slot #i
Slot #14
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 EAGCH frame. The transmission over one E-AGCH sub-frame and over one E-AGCH
frame shall be used for UEs for which E-DCH TTI is set to respectively 2 ms and
10 ms. 6 bits are used to code Access Grant values. One 16 bits CRC (xored by UE
id) is attached to the AG value to form one 22 bits word. A rate 1/3 convolution coding
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 31/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
bi,j = a Css,40,m(i),j
In a serving E-DCH radio link set, the relative grant a is set to +1, 0, or -1 and in a
radio link not belonging to the serving E-DCH radio link set, the relative grant a is set
to 0 or -1.
The relative grant (RG) command is mapped to the relative grant value as described
in the table below:
Command
UP
+1
not allowed
HOLD
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.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
b i,0
b i,1
b i,39
T slot = 2560 chip
S lot #0
S lot #1
S lot #2
S lot #i
Slot #14
1 subfram e = 2 m s
1 radio fram e, T f = 10 m s
Command
ACK
+1
-1
The orthogonal signature sequences Css,40,m(i) and the index m(i) are given in specific
tables. The E-HICH signature sequence index l is given by higher layers.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 33/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 34/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
4 UE CATEGORIES
4.1 HSDPA
3GPP has standardized several UE categories to accommodate a large spectrum of
HSDPA mobile implementations (see [R05]). The UE category provides the mobile
capabilities like max number of HS-PDSCH codes supported, modulation schemes
(16QAM, QPSK), MAC-HS transport block size, etc.
HS-DSCH category
Category 1
Category 2
Category 3
Category 4
Category 5
Category 6
Category 7
Category 8
Category 9
Category 10
Category 11
Category 12
Maximum
number of
HS-DSCH
codes
received
5
5
5
5
5
5
10
10
15
15
5
5
Minimu
m interTTI
interval
3
3
2
2
1
1
1
1
1
1
2
1
Maximum number of
bits of an HS-DSCH
transport block
received within
an HS-DSCH TTI
7298
7298
7298
7298
7298
7298
14411
14411
20251
27952
3630
3630
Total
number of
soft channel
bits
19200
28800
28800
38400
57600
67200
115200
134400
172800
172800
14400
28800
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 35/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Category 1
Maximum
number of
E-DCH
codes
transmitted
Minimum
spreading
factor
SF4
Support for
10 and 2 ms
TTI E-DCH
Maximum number of
bits of an E-DCH
transport block
transmitted within a
10 ms E-DCH TTI
Maximum number of
bits of an E-DCH
transport block
transmitted within a 2
ms E-DCH TTI
7110
10 ms TTI
only
Category 2
2
SF4
14484
2798
10 ms and
2 ms TTI
Category 3
2
SF4
14484
10 ms TTI
only
Category 4
2
SF2
20000
5772
10 ms and
2 ms TTI
Category 5
2
SF2
20000
10 ms TTI
only
Category 6
4
SF2
20000
11484
10 ms and
2 ms TTI
NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 36/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 37/38
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 38/38
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
V03.10
02/OCT/2009
Alcatel-Lucent Proprietary
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CONTENTS
1
INTRODUCTION............................................................................................................................5
1.1
OBJECT ....................................................................................................................................5
1.2
2.2
HSDPA ACTIVATION....................................................................................................................9
SCHEDULER .................................................................................................................................9
4.1
ALGORITHM ..............................................................................................................................9
4.1.1
iCEM................................................................................................................................9
4.1.2
xCEM/UCU-III................................................................................................................11
4.1.2.1
UL processing........................................................................................................... 11
4.1.2.2
CQI SNR mapping and SNR SE mapping ...................................................... 11
4.1.2.3
HARQ process and priority queue selection ............................................................ 11
4.1.2.4
User ranking ............................................................................................................. 12
4.1.2.5
SNR estimation for HS-PDSCH................................................................................ 12
4.1.2.6
TFRC selection......................................................................................................... 12
4.2
SCHEDULER TYPES .................................................................................................................14
4.2.1
iCEM..............................................................................................................................14
4.2.2
xCEM.............................................................................................................................15
4.3
QOS MANAGEMENT .................................................................................................................17
4.3.1
iCEM..............................................................................................................................18
4.3.2
xCEM.............................................................................................................................20
4.4
UE CATEGORY MANAGEMENT ..................................................................................................28
4.4.1
iCEM..............................................................................................................................28
4.4.2
xCEM.............................................................................................................................29
4.5
HSDPA USER SCHEDULING.....................................................................................................29
4.5.1
4.5.2
5
iCEM..............................................................................................................................29
xCEM.............................................................................................................................30
5.2
5.3
5.4
6.2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
7.1
7.2
INTRODUCTION .......................................................................................................................74
8.2
8.2.1
Power allocation............................................................................................................74
8.2.1.1
RNC level.................................................................................................................. 74
8.2.1.2
NodeB level .............................................................................................................. 78
8.2.1.3
Power available for HSDPA channels ...................................................................... 79
8.2.2
Power measurements ...................................................................................................79
8.2.2.1
Transmitted carrier power......................................................................................... 80
8.2.2.2
Averaged HSDPA power .......................................................................................... 80
8.2.2.3
Total non HSDPA power .......................................................................................... 81
8.2.2.4
Available HSDPA power........................................................................................... 82
8.2.2.5
HS-DSCH Required Power ...................................................................................... 83
8.2.3
HSDPA power distribution.............................................................................................85
8.2.3.1
HS-SCCH power ...................................................................................................... 85
8.2.3.2
HS-DSCH power ...................................................................................................... 86
8.2.3.3
HS-PDSCH power .................................................................................................... 88
8.2.4
Power management ......................................................................................................92
8.2.4.1
First transmission ..................................................................................................... 92
8.2.4.2
Retransmission......................................................................................................... 97
8.2.4.3
Multi-users per TTI ................................................................................................... 99
8.3
HS-SCCH POWER MANAGEMENT ......................................................................................... 100
8.4
8.5
THE DL 106
8.5.1
8.5.2
8.5.3
9
Introduction................................................................................................................. 106
Feature Description.................................................................................................... 107
Parameters Settings and Recommendations ............................................................ 108
9.2
9.3
9.3.1
HSDPA OCNS principle ............................................................................................. 112
9.3.2
HSDPA OCNS parameters ........................................................................................ 113
9.4
IU USER TRAFFIC CONFORMANCE ........................................................................................ 118
9.4.1
9.4.2
9.4.3
9.4.4
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TABLES
Table 1: CQI mapping table for 336 bits MAC-d PDU size
Table 2: CQI mapping table for 656 bits MAC-d PDU size
Table 3: Max hsdschInterval value
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size
Table 5: Necessary throughput per HSDPA UE category
Table 6: Iub bandwidth per number of E1 links
Table 7: HS-SCCH power offset table according the reported CQI
UT
TU
UT
TU
TU
UT
TU
UT
UT
TU
TU
TU
UT
UT
40
41
42
43
44
44
100
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FIGURES
Figure 1: MAC-hs scheduler overview ............................................................................................................ 10
Figure 2: TFRC selection algorithm used by the xCEM/ UCU-III ................................................................ 14
Figure 3 : Example of Scheduling Weight for different value of serviceBFactor ....................................... 22
Figure 4: Example of Scheduling Weight for different value of serviceKFactor ........................................ 23
Figure 5: Parameters to configure the feature MAC-d PDU size 656 bits .............................................. 35
Figure 6: Conditions to invoke the feature 79164 .......................................................................................... 38
Figure 7: Padding bits in the MAC-hs PDU .................................................................................................... 39
Figure 8: Codes limitation ................................................................................................................................. 45
Figure 9: Code boost ......................................................................................................................................... 46
Figure 10: CQI Processing................................................................................................................................ 47
Figure 11 : BLER Target according to the CQI and the UE category for the different BLER Ajustement
algorithm ...................................................................................................................................................... 49
Figure 12: CQI adjustment to BLER algorithm............................................................................................... 50
Figure 13: HS-DPCCH synchronization algorithm ........................................................................................ 55
Figure 14: R99, HSDPA & HSUPA Common Channels codes allocation ................................................. 59
Figure 15: HS-PDSCH codes pre-emption or re-allocation ......................................................................... 62
Figure 16: Number of HS-PDSCH codes pre-empted .................................................................................. 63
Figure 17: Number of HS-PDSCH codes re-allocated.................................................................................. 63
Figure 18: Illustration of the HS-PDSCH re-allocation blocking .................................................................. 64
Figure 19: Exemple of codes occupancy for SF16 ....................................................................................... 72
Figure 20: Power allocation at RNC level ....................................................................................................... 75
Figure 21: Physical shared channel reconfiguration message .................................................................... 78
Figure 22: Power allocation at NodeB level ................................................................................................... 78
Figure 23: Transmitted carrier power (on the left) and averaged HSDPA power (on the right) ............. 81
Figure 24: Common measurement .................................................................................................................. 81
Figure 25: Power measurement process ........................................................................................................ 83
Figure 26: Power distribution between HS-DSCH and HS-SCCH channels ............................................. 86
Figure 27: measurementPowerOffset transmission ...................................................................................... 87
Figure 28: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH......... 89
Figure 29: hsdpaAmpUsage parameter .......................................................................................................... 90
Figure 30: Dynamic Power Allocation ............................................................................................................. 91
Figure 31: HS-DSCH power management for 1st transmission.................................................................. 93
Figure 32: MAC-hs transport block adaptation according to the number of MAC-d PDU to transmit ... 95
Figure 33: Remaining power for multi-users per TTI scheduling ................................................................ 99
Figure 34: HS-SCCH power control overview.............................................................................................. 101
Figure 35: Algorithm for CQI Generating Function ...................................................................................... 115
Figure 36: Traffic Conformance Algorithm.................................................................................................... 119
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.
description,
configuration
aspect
and
engineering
PM ID
27931
Feature Title
HSDPA Flexible
resources Mgt
Activation flag
N/A
Release
Global
US
market Market
UA4.2
Yes
Yes
UA4.2
Yes
Yes
hsdpaActivation
27932
HSDPA Step 1
hsdpaResourceActivation
isHsdpaAllowed
27939
HS-SCCH Power
Control
N/A
UA4.2
Yes
Yes
29809
UA5.0
Yes
Yes
29813
UE Cat 9 & 10
Support
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
29800
Dynamic DL Code
Tree Mgt For HSDPA
N/A
isHsPdschDynamicManagementAll
owed
isCellHsPdschDynamicManagemen
tActive (from UA6.0)
hsdpaSchedulerAlgorithm
hsdpaSchedulerWeightingFactor
29807
MAC-hs scheduler
improvement
hsdpaUeCategoryThroughputWeig
hting
hsdpaSpiRelativeWeight
isHsxpaServiceIndicatorEnabled
32520
hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA Performance
Enhancement
ueCategory1..12
UA5.0
Yes
No
UA5.1
Yes
No
UA5.1
Yes
No
UA5.1
Yes
Yes
UA6.0
Yes
Yes
harqType
rxDemodulation
isDynamicMacdPduSizeManageme
ntAllowed
34340
UE cat.8 max.
throughput with PDU
656 & RLC
reconfiguration
eligibleUeCategoryForHighPerform
ance
minimumUserMbrForHighPerforma
nce
maxCellRadius (only in UA5.1)
27350
34652
xCEM hardware
introduction
High quality UL R99
RAB for High HSDPA
DL data rate
N/A
N/A
isDynamicMacdPduSizeManageme
ntAllowed
eligibleUeCategoryForHighPerform
ance
29799
minimumUserMbrForHighPerforma
nce
isHsdpaCellHighPerformance (from
UA6)
isHighPerformancePduSizeReconf
Allowed
29804
GBR on HSDPA
UA6.0
Yes
Yes
33390
Dynamic BLER
Adjustment
hsdpaCqiBlerAdjustmentAlgo
hsdpaCqiBlerAdjustmentAlgorithm
xCEM
UA6.0
Yes
No
33391
HS-DSCH Power
Adjustment Evolution
hsdpaFullPowerUsage
UA6.0
Yes
No
UA6.0
Yes
Yes
RNC:
isHsxpaR99ResourcesSharingOnC
ellAllowed
U
33694
Fair Sharing of
Resources - HSDPA
vs DCH
NodeB:
U
BTSEquipment::hsdpaCodeTreeMa
nagementActivation (iCEM/xCEM)
OneBTSEquipment::hsdpaCodeTre
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA Flexible
Modulation
hsdpaFlexibleModulationVsCodeAc
tivation
UA6.0
Yes
No
proprietaryHSDPAOCNSActivation
UA6.0
No
Yes
UA6.0
Yes
Yes
IsRlcReconfigAllowedForR99
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios
Quality
[R05] UMT/SYS/DD/013319
[R06] UMT/BTS/INF/016135
Planning Guide
of
Service
(QoS)
concept
and
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
3 HSDPA ACTIVATION
HSDPA is activated through several activation flags at RNC, FDDCell and BTSCell
level:
Parameter
Range & Unit
User
Class
Value
isHsdpaAllowed
Object
RadioAccessService
Granularity
RNC
False, True
Customer
3
True
Parameter
Range & Unit
User
Class
Value
Object
FDDCell
Customer
2
True
Granularity
Cell
hsdpaResourceActivation
Object
BTSCell
Granularity
Cell
hsdpaActivation
False, True
Parameter
Range & Unit
User
Class
Value
False, True
Customer
2
True
Note that isHsdpaAllowed exists also in two other objects (RNC / NeighbouringRNC
and RNC / NodeB / FDDCell / UMTSFddNeighbouringCell) in order to know if the
HSDPA call has to be reconfigured or not in DCH when the primary cell changes in
case of mobility over Iur.
HTU
HTU
UTH
UTH
UTH
UTH
HTU
UTH
UTH
4 SCHEDULER
4.1 ALGORITHM
4.1.1 iCEM
As described in the figure below, MAC-hs scheduling consists of choosing the MAC-d
flow (QId) to serve.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The QId is selected using radio (CQI) and priority (SPI) criteria. The selection of a QId
to be scheduled is based on a single cost function with inputs from two costs:
- The first one (C1) depends on the scheduler type. It takes into account the radio
criterion.
- The second one (C2) takes into account the priority of the QID and mainly
depends on the base credits assigned to this SPI priority and the average CQI.
This is used by both Alcatel-Lucent PF and Classical PF schedulers.
The resulting cost is a function of these two costs, and is different according to the
scheduler type. Indeed, for Alcatel-Lucent Proportional Fair scheduler, the resulting
cost should be equal to C1+C2, while for the Classical Proportional Fair, the
resulting cost is rather equal to *C1*C2 (, , being hard coded). The QId with the
smallest cost is scheduled first. Costs are updated after the QId has been served.
Once a user is chosen to be scheduled according to its cost function, the scheduler
selects for this user a TFRC (transport block size, number of HS-PDSCH and
modulation) based on the reported CQI and by taking into account the available
resources in term of power and codes (see 8.2). CQI can also be adapted in order to
control the Mac-hs BLER (see 6)
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
where
is the reference power offset given by the reference tables of CQI [R02].
X
Contrary to iCEM, xCEM/UCU-III does not directly use the CQI. The received CQI
information is mapped to SNR values (SNRMAP,dB) depending on UE category. The
TFRC selection is then based on a second mapping between this SNR and the
Spectral Efficiency (SE). The SE defines the number of bits per HS-PDSCH code per
TTI that can be transmitted for a given symbol SNR and SF = 16 (assuming 10%
MAC-hs bler) in an AWGN channel.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
SNRMAP,dB is the last SNR value mapped on CQI assuming a HSDSCH power of Pcpich + ( being the measurementPowerOffset/2 ).
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 12/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
the UE capability
For UCU III: in case of an HARQ retransmission, the scheduler will not use the
instantaneous SE but the cumulated SE over all the transmissions of this HARQ
process, allowing to account for IR or CC gains (SEcum = SEcurrent + SEcum).
B
This power is also weighted by the term factor because if B/W is smaller than SE, it
means that less power is needed to achieve the same error rate:
PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH x factor
B
factor =
SNR( B / W )
SNR ( SE )
Where:
-
Only for UCU III: After all users have been selected for this TTI, some portion of the
HSDPA power may still be unused. This unused power is called excess power and is
redistributed equally over all HS-PDSCH codes that have been allocated for the
scheduled users in the TTI.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Then, available resources are updated for the next round of scheduling.
The following drawing summarizes the algorithm used by the xCEM/UCU-III to select
the TFRC of a UE:
SNR (dB)
Log2lin
Number of HS-PDSCH
MAC-hs PDU Size
SE
SE
SE
CQI
SNR (dB)
Modulation
TFRC
CQI
UE Cat.
PowerHsPdschAvailable_dBm
Modulation Capability
PowerCpich_dBm
MPO
DeltaAckNack
The goal is to favour mobiles that have not been served (nb_bits_transmitted) versus
what they should have been (according to the CQI reported, nb_bits_optimum),
because there was not enough resources (power, codes or processing).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The goal is to favour mobiles that report a high CQI versus their averaged CQI to take
benefit from instantaneous good radio conditions vs. average conditions.
Where
is
the
forgetting
factor
(see
the
parameter
hsdpaSchedulerWeightingFactor), nb_bits_transmitted represents the number of
bits actually sent to the mobile (transport block size used), CQIinst is the latest CQI
reported (considered before CQI BLER adjustment).
Parameters:
Parameter
Range & Unit
User
Class
Value
hsdpaSchedulerWeightingFactor
[18] decimal
Customer
3
5
Object
HsdpaConf
Granularity
BTSCell
The selection of any of these scheduler types can be changed on line through a
customer class 3 parameter: hsdpaSchedulerAlgorithm.
Parameter
Range & Unit
User
Class
Value
hsdpaSchedulerAlgorithm
[alcatel-Lucent, proportionalFair] Enum
Customer
3
proportionalFair
Object
HsdpaConf
Granularity
BTSCell
4.2.2 xCEM
[xCEM]
Two schedulers are supported and can be selected through the parameter
hsdpaSchedulerAlgorithmXcem
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 15/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
hsdpaSchedulerAlgorithmXcem
[CRmax, proportionalThroughput] Enum
Customer
3
proportionalThroughput
Object
HsdpaConf
Granularity
BTSCell
Note that these 2 schedulers are the same when the QoS is disabled.
The cost of each priority queue is computed differently with CRmax and
proportionalThroughput:
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for
GBR MAC-d flows when R serviceMinRate
B
Where
-
Channel rate CR(u) is the spectral efficiency (SE) times the number
of available HSDPA codes
U
Note that the cost functions for PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
-
See section 4.3.2 for more details on QoS management for xCEM.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameters:
Parameter
Range & Unit
User
Class
Value
Object
hsdpaSpiRelativeWeight
[1..16][1..100] List of Decimal
Customer
Granularity
3
2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
HsdpaConf
BTSCell
The setting of SPI (common for iCem and xCem) is done in RNC /
RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos:
Parameter
Range & Unit
User
Class
Value
Spi
[0..15]
Customer
3
Depends on customer strategy
Object
ThpBasedQos
Granularity
RNC
To disable the QoS, all the relative weights hsdpaSpiRelativeWeight have to be set
with the same value (the value 100 disables totally the SPI management algorithm) or
all the spi have to be set with the same value (e.g. 0).
Note :
[iCEM] [xCEM] Supports differentiation on all 16 SPI
[UCU-III] Supports QOS differentiation only on 7 different priorities. In deployments
with UCU-III, the RNC mapping of QOS to SPI will use a more restricted set of SPI.
GBR Handling:
U
In the presence of GBR MAC-d flows, these flows will be served first as long as their
GBR is not satisfied (irrespective of their SPI), even if the throughput of non GBR
MAC-d flows (and even with higher SPI) must be reduced down to 0 kbps.
To determine if a GBR MAC-d flow has reached its GBR or not, MAC-hs continuously
monitors the average throughput of the flow (using an exponential filtering based on
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi parameter). This averaging is
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameters:
U
Parameter
Range & Unit
User
Class
Value
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi
[1..16][1..11] List of Decimal
Customer
3
[8, .., 8] (default value)
Parameter
Range & Unit
User
Class
Value
hsdpaGbrNbUePerTtiForgettingFactor
[1..11] Decimal
Customer
3
8 (default value)
Parameter
Range & Unit
User
Class
Value
hsdpaGbrNbNeededTtiForgettingFactor
[1..11] Decimal
Customer
3
8 (default value)
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
Object
HsdpaConf
Granularity
BTSCell
4.3.2 xCEM
The two xCEM schedulers manage the QoS differently:
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
With CRmax: for a given SPI, priority of the queue is increased (or
decreases) by multiplying the cost function by a Scheduling Weight
(SW) if the MAC-d throughput R is lower (or higher) than the
parameter serviceMinRate (or serviceMaxRate). The parameters
serviceBFactor and serviceKFactor are shaping factors for
increasing and decreasing the priorities:
Where the term w depends on whether the measured MAC-d throughput R is lower or
higher than serviceMinRate:
If R serviceMinRate:
R serviceMinRate
serviceMaxRate serviceMinRate
serviceKFactor
If R < serviceMinRate:
serviceMinRate R
serviceMaxRate serviceMinRate
1 / serviceKFactor
For GBR MAC-d flows, with CRmax algorithm, serviceMinRate and serviceMaxRate
are not taken from OMC-B but fixed by MAC-hs according to MAC-hs GBR (NBAP)
with margins coming from OMC-B:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
B = 5, K = 7
B = 3, K = 7
B = 1, K = 7
7
6
Priority
5
4
3
2
1
0
20
30
40
50
60
70
80
100
B=7
10
B=5
B=3
1
0
10
20
30
40
50
60
70
80
B=1
0,1
0,01
Data Rate (kbps)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
B = 7, K = 5
B = 7, K = 3
B = 7, K = 1
7
6
Priority
5
4
3
2
1
0
20
30
40
50
60
70
80
100
K=7
10
K=5
K=3
1
0
10
20
30
40
50
60
70
80
K=1
0,1
0,01
Data Rate (kbps)
When the throughput of a user is lower than the serviceMinRate (Rmin), its priority is
increased.
When the throughput of a user is higher than the serviceMaxRate (Rmax), its priority
is decreased.
The higher the serviceBFactor or serviceKFactor are, the higher the Scheduling
Weight is.
Note that when the serviceBFactor is set to 1, the Scheduling Weight is equal to 1,
meaning that all the users have the same priority (no QoS).
Contrary to the PropTh (xCem) or PropFair (iCem) schedulers, Crmax scheduler can
apply different Scheduling Weight even if all the spi have the same value. If only one
SPI is defined, all the users will use the same value for serviceMinRate,
serviceMaxRate, serviceKFactor, serviceBFactor but the SW will depend on the
current throughput.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
for UCU III: set to 0.001 for GBR and 0.005 for non GBR flows
Parameter
Range & Unit
User
Class
Value
hsdpaSchedulerWeightingFactorXcem
[18] decimal
Customer
0
8
Parameter
Range & Unit
User
Class
Value
serviceBFactor
[130] decimal
Customer
3
7 (default value)
Object
HsdpaConf
Granularity
BTSCell
Object
HsdschServiceParameterSet
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
serviceKFactor
[130] decimal
Customer
3
7 (default value)
Object
HsdschServiceParameterSet
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
serviceMaxRate
[010000] decimal kb/s
Customer
3
120 (default value)
Object
HsdschServiceParameterSet
Granularity
BTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
serviceMinRate
[010000] decimal kb/s
Customer
3
40 (default value)
Object
HsdschServiceParameterSet
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
Object
serviceHighRate
[010000] decimal kb/s
Customer
Granularity
3
80 for PS Streaming and 300 for PS I/B
HsdschServiceParameterSet
BTSCell
Parameter
Range & Unit
User
Class
Value
serviceLowRate
[010000] decimal kb/s
Customer
3
0 (default value)
Object
HsdschServiceParameterSet
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
serviceFilterFactor
[111] decimal
Customer
3
8 (default value)
Object
HsdschServiceParameterSet
Granularity
BTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Engineering Recommendation:
UCU III : supports QOS differentiation only on 7 different priorities. In deployments with UCU III, the RNC
mapping of QOS to SPI will use a more restricted set of SPI. HSDPA Service Parameter Set Instances for
these 7 different priorities are 1-7 : Table HS-DSCH Service Parameter Sets Instances:
U
Parent Object
HsdschServiceParameterSet
Instance Name
HSDSCHServiceParameterSet1
HsdschServiceParameterSet
HSDSCHServiceParameterSet2
HsdschServiceParameterSet
HSDSCHServiceParameterSet3
Default [Unit]
SchedulingPriorityLevel
= 15
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 14
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 13
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
Remark
Parameter set
for scheduling
priority 15.
Can be
configured at
OMC
Parameter set
for scheduling
priority 14.
Can be
configured at
OMC
Parameter set
for scheduling
priority 13.
Can be
configured at
OMC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 26/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HsdschServiceParameterSet
HsdschServiceParameterSet
HSDSCHServiceParameterSet4
HSDSCHServiceParameterSet5
HsdschServiceParameterSet
HSDSCHServiceParameterSet6
HsdschServiceParameterSet
HSDSCHServiceParameterSet7
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 12
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 11
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
ServiceKFactor = 7
SchedulingPriorityLevel
= 10
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 300
[kbps]
ServiceLowRate = 0
[kbps]
ServiceHighRate = 10
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 7
Parameter set
for scheduling
priority 12.
Can be
configured at
OMC
Parameter set
for scheduling
priority 11.
Can be
configured at
OMC
Parameter set
for scheduling
priority 10.
Can be
configured at
OMC
Parameter set
for scheduling
priority 9. Can
be configured
at OMC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HsdschServiceParameterSet
HSDSCHServiceParameterSetUc
ServiceKFactor = 7
ServiceMinRate = 0
[kbps]
ServiceMaxRate = 1000
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 1
Parameter set
for scheduling
priority 10.
Can not be
configured at
OMC
ServiceKFactor = 1
HsdschServiceParameterSet
HSDSCHServiceParameterSetFt
ServiceMinRate = 126
[kbps]
ServiceMaxRate = 130
[kbps]
ServiceMaxDelay = 0
[ms]
ServiceBFactor = 5
Parameter set
for scheduling
priority 10.
Can not be
configured at
OMC
ServiceKFactor = 13
Note : Scheduling modes Fair Throughput and Unconstrained also service parameters sets are
introduced, which are read only in the OMC-U reflecting the parameters hard coded in the UCU III .
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
It must be noted that this parameter is only applicable when SPI management is
activated. Hence, it is disabled in case of all hsdpaSpiRelativeWeights [SPI] are
equal to 100.
Parameter
Range & Unit
User
Class
Value
hsdpaUeCategoryThroughputWeighting Object
[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
3
ueCategoryProportionality
HsdpaConf
BTSCell
4.4.2 xCEM
xCEM scheduler is able to balance throughput between different UE categories when
one of them is limited by the transport block size. The principle is the same as with
iCEM (see section 4.4.1 for more details), only the parameter name changes:
X
Parameter
Range & Unit
User
Class
Value
hsdpaUeCategoryThroughputWeightingXcem Object
[ueCategoryEquity, ueCategoryProportionality] Enum
Customer
Granularity
0
ueCategoryProportionality
HsdpaConf
BTSCell
The first step consists in managing the retransmissions. The NACKed blocks are
scheduled first, in a FIFO order when possible (in case the UE capabilities prevent
from receiving data in the corresponding TTI, it is not retransmitted in that TTI). Then,
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
When there is no more retransmission to send, the scheduler selects the suitable QId
(according the cost function) for a user transmitting packet for the first time. This
selection is repeated as long as some resources remain (codes, power and CPU) and
if data can be scheduled for the corresponding TTI.
A user can only be considered as candidate if it is allowed to receive some data in the
current TTI, i.e. if several criteria are respected (CQIprocessed 0, min inter TTI distance,
AckNack repetition factor, one HARQ process available, UE not already scheduled for
retransmissions).
B
For each candidate user, HS-SCCH power is determined (see Power Management
section) and power checking is done on both the current TTI and the previous one
(HS-SCCH and corresponding HS-PDSCH only overlap by 1 slot). If there is not
enough power to transmit the HS-SCCH in the current TTI, the user is not selected.
X
Then for the UE with the lowest cost within the remaining candidates UEs, the number
of PDU to transmit as well as the number of codes and the transmitted power are
chosen according to the processed CQI in order to fit as well as possible to what the
UE can correctly receive (see Power Management section for more details on the
algorithm):
X
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 AlcatelLucent written authorization
Page 30/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
5 TFRC MANAGEMENT
5.1 MAC-D PDU SIZE MANAGEMENT
336 bits configuration might limit the throughput (especially for high UE category like
Cat.8 and above) due to UE processing capabilities (too many PDU/s to handle) or
due to RLC stalling (RLC window size is limited to 2047 PDU) in case of a too high
round-trip delay. So, a MAC-d PDU of 656 bits (maximum number of MAC-d PDU is
21 for 656 bits MAC-d PDU size and 42 for 336 bits for Cat.8) allows higher user
throughput.
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).
Decrease in the prohibitedStatusTimer leads to increase in the uplink Status traffic. The interest of
the 656 bits configuration is to allow reaching very high throughputs (6 Mbps and more) with moderate
uplink Status traffic.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 31/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UL service: HSUPA
TCP/RLC setting :
DlRlcQueueSize = 128 RLC SDU for Cat.9 or 256 for Cat.10 (Note that the value
used by the RNC is 2 times the value datafilled. For example, in order to used 256 for
Cat.10, the datafilled value should be 128)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
656 bits MAC-d PDU size has to be used at least for UE categories allowing high user
throughput, that is to say UE Cat.7, 8, 9 and 10.
Parameter
Range & Unit
User
Class
Value
HsdpaRncConf
eligibleUeCategoryForHighPerformance Object
BitString 64 bits (0=not eligible, 1=eligible)
Customer
Granularity
RNC
3
0000000000000000000000000000000000000000000000000000001111000000
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 33/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
minimumUserMbrForHighPerformance
Integer [0.. 16 000 000] bit/s
Customer
3
0 (customer dependant)
Object
HsdpaRncConf
Granularity
RNC
Parameter
Range & Unit
User
Class
Value
Parameter
Range &
Unit
User
Class
Value
isHsdpaCellHighPerformance
Boolean {True; False}
Customer
3
True
isDynamicMacdPduSizeManagementAllowed
Boolean
{True, False}
Customer
3
True
Object
FDDCell
Granularity
Cell
Object
RadioAccessService
Granularity
RNC
All Node B should be upgraded to at least UA05.1 prior to the RNC activation
(isDynamicMacdPduSizeManagementAllowed).
if
29797
(multi-service
on
HSDPA)
is
enabled
isUeCapabilitiesInRabMatchingAllowed = TRUE
isUeCapabilitiesInRabMatchingAllowedForPhyAndRlc = TRUE
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 34/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HsdpaRncConf
isHighPerformancePduSizeReconfAllowed Object
BitString 64 bits (0=not eligible, 1=eligible), one bit per UE Categorie (Cat. 1 on the
right)
Customer
Granularity
RNC
3
0000000000000000000000000000000000000000000000000000001111000000
True
isDynamicMacdPduSizeManagementAllowed
True
eligibleUeCategoryForHighPerformance
1
minimumUserMbrForHighPerformance
< MBR
isHsdpaCellHighPerformance
False
0
> MBR
False
True
Figure 5: Parameters to configure the feature MAC-d PDU size 656 bits
MAC-d PDU selection: The MAC-d PDU size is chosen when an HS-DSCH MAC-d
flow is setup that is to say at RAB establishment or reconfiguration of the RB to HSDSCH. In UA05.1 (or in UA6.0 with reconfiguration disabled), if a second HS-DSCH
Mac-d flow is setup then it will use the same MAC-d PDU size than the first one (even
if its MBR would have lead to use a different size). In UA6.0 with reconfiguration
enabled, a second HS-DSCH Mac-d flow can use a Mac-d PDU size different from the
1st one.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 35/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Mobility over Iur: The cell of DRNC is considered as 336 bits capable. In case of
mobility over Iur (HS-DSCH cell change towards a DRNS), the MAC-d PDU size of the
HS-DSCH MAC-d flow is not reconfigured if the reconfiguration is disabled
(isHighPerformancePduSizeReconfAllowed = False) : if the call was using the 336 bits
(or 656 bits), it will continue to use 336 bits (or 656 bits) after the mobility over Iur.
U
If the DRNS does not support the 656 bits configuration it will refuse the mobility of a
656 bits MAC-d flow thus leading to a DCH fallback of the RB by the SRNC (HSxPA
to DCH fallback feature has to be enabled).
If the reconfiguration is enabled (isHighPerformancePduSizeReconfAllowed =
True), the MAC-d PDU size can be reconfigured if necessary (e.g. MAC-d PDU size of
the new cell is different from the current MAC-d PDU size). When the SRNC has to
setup an HS-DSCH MAC-d flow over Iur, it configures it using 336 bits. For more
information on mobility over Iur, see [Vol. 6].
X
MAC-d PDU size reconfiguration: MAC-d PDU size reconfiguration may also happen
during transport channel type switching that is to say during HSDPA-R99 mobility or
AO transition. One exception is when this channel switching is due to a RAB
establishment (like a CS RAB or a second PS RAB where a first PS RAB was on
Cell_FACH due to inactivity). In this case, the configuration use for the PS RAB on
HS-DSCH is 336 bits. When reconfiguration is triggered, SDU can be managed in
different ways according to the parameters sduRetransmitAfterPduSizeChange (in
RadioAccessService / RlcConfClass / DlRlcAckMode). This parameter configures the
resegmentation upon RLC reconfiguration with MAC-d PDU size change. Following
values are possible:
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 36/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
User
Class
Value
Object
DlRlcAckMode
sduRetransmitAfterPduSizeChange
[none, notTransmitted, notFullyTransmitted, notFullyAcknowledged] Enum
Customer
Granularity
RlcConfClass
3
notFullyAcknowledged
UE capabilities handling: Along with 34340 (and according to the flag
isDynamicMacdPduSizeManagementAllowed), when a MAC-d flow is setup for an
3GPP R5 UE, the RNC will configure an RLC window size that fits into the UE
memory (totalRLC-AM-BufferSize IE in RLC-Capability and RLC-Capability-r5-ext UE
capabilities).
If
the
RLC
window
size
configured
at
OMC
(TransmissionWindowsSize) is too big for the UE, the RNC recomputes the RLC
window size to match with UE memory constraints ([R03]).
U
For 3GPP R5 UE, in case of PS RAB establishment when there are other PS RABs
established, if the UE has not enough memory to cope with the nominal (OAM) RLC
window sizes the RNC will trigger a standalone RLC reconfiguration (after the RRC
RB SETUP or RRC RB RELEASE) to rebalance the RLC windows.
With Streaming traffic, the RNC will always ensure that the RB is configured with a
minimum window size to be able to reach the GBR. This minimum equals
GBR*(RTD+RLC TimerStatusProhibit)/MAC-d PDU size where RTD=100 ms
hardcoded.
Note that a PDU size of 656 bits is always used for a Streaming MAC-d flow.
Page 37/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
IsRlcReconfigAllowedForR99
True, False
Customer
3
True
Object
RadioAccessService
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 38/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
21
320
16
320
16
320
16
Padding
These new tables are activated via the following class 3 OMC-B parameters:
Parameter
Range &
Unit
User
Class
Value
Object
ueCategoryX
X = [1..12]
True, False
Customer
Granularity
3
True for all UE categories
HsdpaUeCategoryTransportBlockOptimisation
BTSCell
Note that such activation is independent per UE category and only part of them can
then be optimized.
UE Category support
The mapping between CQI and Transport Block Size depends on the UE category.
The following tables summarize this mapping for MAC-d PDU size equal to 336 and
656 bits (iCEM only):
Mac-d PDU size = 336 bits
Number
Number
Applicable
of
of
for
Modulation
Power offset
HSMAC-d
UE
PDSCH
Default Optimised Max capability PDU
category
codes
377
365
1
QPSK
1
+4 dB
1 12
377
365
1
QPSK
1
+3 dB
1 12
377
365
1
QPSK
1
+2 dB
1 12
377
365
1
QPSK
1
+1 dB
1 12
377
365
1
QPSK
1
0dB
1 12
377
365
1
QPSK
1
-1 dB
1 12
377
365
1
QPSK
2
-2 dB
1 12
Transport Block Size
CQI
1
2
3
4
5
6
7
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 39/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
792
792
1262
1483
1742
2279
2583
3319
3440
3565
4189
4664
5287
5887
6554
7168
7168
9719
11418
14411
14411
17237
17237
699
699
1036
1380
1711
2046
2404
3090
3440
3440
4115
4420
5101
5782
6438
7168
7168
9546
11216
14155
14155
17237
17237
21754
21754
20251
2
2
3
4
5
6
7
9
10
10
12
13
15
17
19
21
21
28
33
42
42
51
51
60
64
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
2
2
3
3
3
4
4
5
5
5
5
5
5
5
5
5
5
7
8
10
10
12
12
15
15
0dB
-1 dB
0dB
0dB
0dB
0dB
0dB
0dB
16 - CQI
0dB
0dB
0dB
0dB
0dB
0dB
0dB
22 - CQI
0dB
0dB
0dB
25 - CQI
0dB
26 - CQI
27 - CQI
27 - CQI
1 12
1 12
1 12
1 12
1 12
1 12
1 12
1 12
11 12
1 10
1 10
1 10
1 10
1 10
1 10
1 10
16
7 10
7 10
7 10
78
9 10
9
9
10
Table 1: CQI mapping table for 336 bits MAC-d PDU size
CQI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
14
15
16
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 40/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
3319
4189
4664
5287
5287
6554
7168
7168
3319
3970
4664
5287
5287
5993
6673
6673
9719
11418
14411
14411
17237
17237
9210
11216
13904
13904
17237
17237
21754
21754
7298
20251
5
6
7
8
8
9
10
10
11
14
17
21
21
26
26
30
33
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
5
5
5
5
5
5
5
5
5
7
8
10
10
12
12
15
15
15 - CQI
0dB
0dB
0dB
-1dB
0dB
0dB
22 - CQI
23 - CQI
0dB
0dB
0dB
25 - CQI
0dB
26 - CQI
27 - CQI
27 - CQI
11 - 12
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1 - 10
1-6
1-6
7 - 10
7 - 10
7 - 10
7-8
9 - 10
9
9
10
Table 2: CQI mapping table for 656 bits MAC-d PDU size
Note that with MAC-d PDU size = 656 bits, the minimum number of HS-PDSCH codes
that can be managed is 2 if the feature Flexible Modulation (see section 5.4) is
disabled. If Flexible Modulation is enabled, even 1 HS-PDSCH code can be managed
with a MAC-d PDU of 656 bits.
X
Based on Figure 7: Padding bits in the MAC-hs PDU, the throughput can be computed
at different levels from the TBS and the Mac-d pdu size:
X
Some UE categories are limited to a maximum TBS (see [Vol. 2]). So, above a certain
CQI, TBS do not increase anymore but power is reduced by 1dB per CQI. Moreover,
for a given CQI, TBS can have different values:
X
Optimized values used when the Transport Block Size Optimization feature is
enabled in order to decrease the padding bits.
Max
capability
values
used
when
ueCategoryX
(in
HsdpaMaxUeCategoryCapabilityActivation) is set to True in order to increase
maximum throughput for a given UE category
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 41/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ueCategoryX
X = [1..12]
True, False
Object
HsdpaMaxUeCategoryCapabilityActivation
Customer
3
True for all UE categories
Granularity
BTSCell
Note: There is a 3GPP limitation regarding the maximum number of MAC-d PDUs that
can be allocated in one Capacity Allocation: 2047 PDUs. This means that in order to
provide the maximum bit rate for a single UE of category X, the hsdschInterval
parameter must be set inferior or equal to 2047 / max nb of MAC-d PDU * 2ms:
UE
category
Maximum
Transport
Block Size
78
14411
20251
10
21754
MAC-d PDU
size
336
656
336
656
336
656
Maximum number
of
MAC-d PDU
42
21
60
30
64
33
hsdschInterval
max (ms)
90
190
60
130
60
120
A value too high for hsdschInterval parameter will lead to reduce throughput.
[iCEM]
For iCEM, the recommendation for hsdschInterval is 50ms.
Parameter
Range & Unit
User
Class
Value
hsdschInterval
[10500] ms step = 10
Customer
3
50ms
Object
HsdpaConf
Granularity
BTSCell
[xCEM]
For xCEM, the hsdschInterval is hardcoded. The MAC-hs flow control algorithm
calculates the maximal number of MAC-d PDUs that can be transmitted by the RNC
within a HS-DSCH interval of 80 ms. These credits are sent to the RNC in the
message HS-DSCH CAPACITY ALLOCATION. The maximal credit that can be
allocated to the RNC is 2047 MAC-d PDUs. A HS-DSCH CAPACITY ALLOCATION
message is sent to the RNC:
- when a HS-DSCH CAPACITY REQUEST was received from the RNC in the
Node B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 42/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
As described above, if the MCS selected corresponds to a Transport Block Size that
exceeds what the UE can support according to its category then a lower MCS is
selected and the power requirements are lowered by -1dB/CQI. This is described in
the below table
MAC-d PDU size = 336 bits
Ue
category
Maximum HS-DSCH
TBS per TTI
Maximum
MCS
Max MAC-d
PDUs
1 to 6
7 to 8
9
7298
14411
20251
22
25
27
7168
14155
20251
21
42
60
10
27952
27 (iCEM)
29 (xCEM)
21754 (iCEM)
23792 (xCEM)
64 (iCEM)
70 (xCEM)
11 to 12
3630
Ue
category
1 to 6
7 to 8
9
16
3440
MAC-d PDU size = 656 bits
Maximum HS-DSCH Maximum
TBS applied from
TBS per TTI
MCS
maximum MCS
7298
23
7298
14411
25
13904
20251 (iCEM)
20251
27
19891 (xCEM)
10
Max MAC-d
PDUs
11
21
30
10
27952
27 (iCEM)
30 (xCEM)
21754 (iCEM)
26490 (xCEM)
33 (iCEM)
40 (xCEM)
11 to 12
3630
15
3319
Table 4: Maximum Transport Block Size used according to UE category and MAC-d PDU Size
Restriction
The maximum RLC throughput with UE category may be limited (limit around 4-4.5 Mb/s) due to the
RLC window size limitation.
Against RLC window size limitation, prohibitedStatusTimer parameter can be decreased (from 70ms
to 30ms) or PDU size can be increased (from 336 bits to 656 bits) in order to reach higher throughput.
Decrease the prohibitedStatusTimer leads to increase the uplink Status traffic (impact has to be
study especially in multi-UE scenario).
The following tables give the HSDPA throughput at ATM layer and the Iub bandwidth
per E1:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 43/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Cat 11 12
1 440 kbps
1 872 kbps
Cat 1 6
3 360 kbps
4 368 kbps
Cat 7 8
6 720 kbps
8 736 kbps
Cat 9
8 160 kbps
10 608 kbps
Cat 10
12 160 kbps
15 808 kbps
IuB
bandwidth
1 E1
2 E1
3 E1
4 E1
5 E1
6 E1
7 E1
8 E1
(Kbps)
(Kbps)
(Kbps)
(Kbps)
(Kbps)
(Kbps)
(Kbps)
(Kbps)
1 920
3840
5760
7680
9600
11520
13440
15360
With iCem and previously to UA6.0, there was no flexibility between modulation and
number of HS-PDSCH codes (QPSK used with 1, 2, 3, 4 and 5 HS-PDSCH and
16QAM used with equal to or more than 5 codes). TFRC is selected according to the
mapping tables given in 5.3.
X
In UA6.0, the feature 34102 HSDPA Flexible Modulation has been implemented for
iCem in order to be able to use QPSK or 16QAM whatever the number of HS-PDSCH
codes, and then to optimize the cell throughput. This feature consists in choosing the
modulation (QPSK or 16-QAM) which is the most efficient regarding the situation (HSPDSCH codes shortage or not) : 16-QAM allows to transmit more data with the same
number of codes at the expense of power ; QPSK allows to transmit more data with
the same power at the expense of the number of codes.
Page 44/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Code limitation: when the number of HS-PDSCH codes available is lower than
the number of codes requested by the UE
Code boost: when the number of HS-PDSCH codes available is higher than
the number of codes requested by the UE
Code limitation
U
Basically, the codes limitation scenario corresponds to the multi-users case or when
few HS-PDSCH codes are configured.
The aim is to use, 16QAM instead of QPSK when there is a code limitation (normally
QPSK is used for less than 5 codes) in order to increase the Transport Block Size
(power may be increased in order to take into account the fact that 16-QAM
modulation is less efficient) and hence increase the throughput.
Implementation is based on different mapping tables according to the number of
remaining HS-PDSCH codes (1, 2, 3 or 4), to the UE category (only if the number of
remaining codes is higher or equal to 5) and the MAC-d PDU size. Based on these
inputs TFRC will be selected to maximize the throughput.
Mapping
tables
- Modulation = 16QAM
- ue category
- TBS
- Power offset
Note that :
The tables for the case with 5 or more remaining codes are the default tables
(when hsdpaFlexibleModulationVsCodeActivation = False).
Code boost
U
Basically, the codes boost scenario corresponds to the mono-user case when there
remain some unused HS-PDSCH codes.
The aim is to use the remaining codes with the QPSK instead of 16QAM (normally
16QAM is used for more than 5 codes) in order to the increase the Transport Block
Size (power remains the same) and hence increase the throughput.
Implementation is based on different mapping tables according to the number of
remaining HS-PDSCH codes (7, 8, 9, 10, 11, 12, 13, 14, 15), the MAC-d PDU size
and the UE capability (up to 10 codes for category 7-8, 12 for category 9 and up to 15
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 45/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Mapping
tables
- Modulation = QPSK
- TBS
Activation
U
Parameter
Range & Unit
User
Class
Value
hsdpaFlexibleModulationVsCodeActivation
Boolean {True, False}
Customer
3
True
Object
HSDPAConf
Granularity
BTSCell
Note that when the Flexible modulation is enabled, the two following flags are ignored
(see 5.3 for more details on these flags):
X
hsdpaUeCategoryTransportBlockOptimization
hsdpaMaxUeCategoryCapabilityActivation
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 46/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Two algorithms have been introduced to handle bad UE behaviors that would disrupt
the system. Note that in the nominal case, these algorithms should not have any
impact.
The purpose of these algorithms is respectively to:
Both algorithms are processed just after the CQI report and can be processed in any
order. The resulting CQI from both steps (referred as CQIprocessed in this document)
constitutes the input of both flow control and scheduler algorithms (except HS-SCCH
power control).
B
Page 47/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
0: deactivated.
The main principle still remains, i.e. computation and use of a DeltaCqi, but the way
and the frequency this variable is updated changes:
- A CQI offset is computed and applied on the received CQI.
- This offset is updated according to received feedback for first transmission, ACK or
NACK only.
- This offset is now updated as an outer-loop-like algorithm. Up (resp. down) steps are
applied upon reception of ACK (resp. NACK). The Up steps are computed in
accordance to the selected BLER target.
- Anytime a CQI is received, the offset is applied and the resulting value constitutes
the entry point of the scheduler.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 48/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
is
set
to
DownStep
UpStep
upStepLowBlerT arg et =
upStepMediumBlerT arg et =
upStepHighBlerT arg et =
These thresholds (cqiThLow and cqiThHigh) are hard-coded and a value is defined
per UE category as illustrated in the following figure:
cqiThHigh
cqiThLow
hsdpaCqiBlerAdjustmentAlgo
dynamicOuterLoopAlgo
outerLoopLikeAlgo
blerRangeBasedAlgo
CQI
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Cat.12
Cat.1-6
Cat.7-10
Cat.x
Bler Target = hsdpaBlerTargetUpperLimit
Cat.x
Bler Target < 30% (in practice around 10%)
highBlerTarget = hsdpaBlerTargetUpperLimit
mediumBlerTarget = hsdpaBlerTargetMediumLimit
lowBlerTarget = hsdpaBlerTargetLowerLimit
Figure 11 : BLER Target according to the CQI and the UE category for the different BLER
Ajustement algorithm
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 49/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 50/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
hsdpaCqiBlerAdjustmentAlgo
[deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo,
dynamicOuterLoopAlgo]
Customer
Granularity
3
dynamicOuterLoopAlgo
Parameter
Range & Unit
User
Class
Value
hsdpaAdjustBlerToChannelVariation
[TRUE, FALSE]
Customer
3
FALSE
HSDPAConf
BTSCell
Object
HSDPAConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaBlerTargetUpperLimit
[[1..99]] %
Customer
3
30
Object
HSDPAConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaBlerTargetLowerLimit
[[1..99]] %
Customer
3
1
Object
HSDPAConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaBlerTargetMediumLimit
[[1..99]] %
Customer
3
20
Object
HSDPAConf
Granularity
BTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 51/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
hsdpaBlerObservationWindow
[1..100] Decimal (TTIs)
Customer
3
10
Object
HSDPAConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaBlerStepSize
[0.1..1.0] step:0.1
Customer
3
0.1
Object
HSDPAConf
Granularity
BTSCell
Principle - xCEM:
U
With xCEM, constBlerTarget algorithm has been implemented to control the MAC-hs
BLER.
Note that the MAC-hs bler estimation is still based on ack/nack information reported
on HS-DPCCH.
With constBlerTarget algorithm, MAC-hs BLER is managed as with iCEM
outerLoopLikeAlgo algorithm, except that the offset (ack,nack) is applied on SNR of
one HS-PDSCH instead of directly on CQI. This calculated SNR is then mapped to a
spectral efficiency and used for TFRC selection. However unlike iCEM, xCEM loosely
targets the constant BLER or packet error rate for first transmission and may allow it to
deviate from the target to optimize throughput.
The first transmission target value for the packet error rate impacts the observed data
rate significantly. If the target error rate is set to very small value, the scheduler only
selects small transport block sizes. This results in a low throughput. On the other side
if the target value is set to a large value, larger transport block sizes are selected. In
this case it may happen that the packet is still not received correctly in the UE after all
HARQ retransmissions. Then RLC retransmissions are required, which also leads to a
reduced throughput.
Following equivalent parameters have been defined for xCEM as:
Parameter
Range & Unit
User
Class
Value
hsdpaCqiBlerAdjustmentAlgorithmXcem Object
[deactivated, constBlerTarget, dynamicHarqTxTarget] Enum
Customer
Granularity
3
constBlerTarget
HsdpaConf
BTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 52/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
deactivated,
constBlerTarget
The value dynamicHarqTxTarget should not be selected since this algorithm is not supported.
Parameter
Range & Unit
User
Class
Value
hsdpaBlerTargetUpperLimitXcem
[199] %
Customer
0
15
Object
HsdpaConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaBlerTargetLowerLimitXcem
[199] %
Customer
0
1
Object
HsdpaConf
Granularity
BTSCell
With UCU III, the method of "constBlerTarget" described above is supported with
down step set to 0.4dB (HSDPA_SINR_down_step) and packet error target of 20%
(HSDPA_packet_error_target). The correction term (ACK,NACK) is upper and lower
limited by 2dB (HSDPA_SINR_max_factor) and -1dB (HSDPA_SINR_min_factor)
respectively.
The up step size HSDPA_SINR_up_step is calculated in the MAC-hs as:
HSDPA_SINR_up_step
HSDPA_packet_error_target
=
HSDPA_SINR_down_step 1 HSDPA_packet_error_target
Parameter
Range & Unit
User
Class
Value
HSDPA_SINR_down_step
Integer 0,,512}& [0.001 dB]
0
0.4 dB
Object
HsdpaConf
Granularity
BTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 53/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA_packet_error_target
Integer: {-63,,0} & step size of 0.1
0
-7
Object
HsdpaConf
Granularity
BTSCell
A default value of 7 corresponds to the logarithm of the packet error target rate of
20%.
Parameter
Range & Unit
User
Class
Value
HSDPA_SINR_max_factor
Integer:{-200,,330} & 0.1 dB
0
20 (meaning 2dB)
Object
HsdpaConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
HSDPA_SINR_min_factor
Integer: {-400,,200} & 0.1 dB
0
-10 (meaning -1dB)
Object
HsdpaConf
Granularity
BTSCell
Once in that HSD_IN_SYNC state, CQI are taken into account in the MAC-hs.
In case of DTX, the last decoded value is kept.
If M successive expected CQI are not detected (DTX), then the UE falls into
the HSD_OUT_SYNC state.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 54/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 55/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RxDemodulation
[0..2147483647] Decimal
Customer
0
4
Object
BTSEquipmentl
Granularity
BTS
Bit 1:
Bit 2:
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.
common Layer1 UL
HS-DPCCH presence
enhancement
detection
OFF
OFF
OFF
ON
OFF
OFF
OFF
ON
OFF
OFF
OFF
ON
OFF
ON
ON
ON
OFF
ON
ON
ON
OFF
RxDemodulation value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 56/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ON
ON
ON
When coming back into the HSD_IN_SYNC state, scheduler cost function must be
reinitialized (both costs set to respective lower cost of active QIDs).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 57/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
7 OVSF CODES
7.1 CELL CONFIGURATION
Since UA5.0, codes reservation at cell setup is done as follows:
Only the HS-PDSCH codes are reserved at the bottom of the OVSF code
tree. All the other channels are reserved just after the following channels (1)
common channels, (2) OCNS, (3) HS-SCCH channels, (4) DL HSUPA
channels)
The number of HS-PDSCH codes reserved at cell setup is still defined by the
numberOfHsPdschCodes parameter as in UA4.2. When the feature
Dynamic DL Codes Tree Management for HSDPA is activated the number of
HS-PDSCH codes reserved for HSDPA traffic can be updated dynamically
according the number of free OVSF codes
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 58/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Figure 14: R99, HSDPA & HSUPA Common Channels codes allocation
DCTM disabled
and
Fair Sharing disabled:
DCTM enabled
(Fair Sharing has to be
disabled)
- Reservation of the HS-PDSCH codes is static and the number of HSPDSCH codes is defined by the parameter numberOfHsPdschCodes.
- HSDPA codes configuration is sent during the cell setup from RNC to
NodeB through the Physical Shared Channel Reconfiguration message
and these codes can not be used or pre-empted for other services.
- This message contains the number of HS-PDSCH and the index of the
first one knowing that HS-PDSCH codes are reserved at the bottom of
the OVSF tree.
- Reservation of HS-PDSCH codes is dynamic and depends on the R99
traffic.
- Codes not used by R99 can be used for HS-PDSCH channels.
- Nevertheless, some codes needed to be kept free in order to anticipate
the admission of a R99 call.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 59/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Since UA5.0, the HS-SCCH codes are allocated at the top of the OVSF tree after the
common channels. The number of HS-SCCH is defined by the
numberofHsScchCodes.
Monitoring line
U
to
SF16
via
the
The pre-emption (or stealing) of HS-PDSCH codes is triggered when the number of
free OVSF codes is strictly lower than threshCodesToTriggerStealing.
(Cond.1)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 60/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
(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.
(Cond.3)
OR
New Nb of free SF8 codes > 0 if
((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing *
SF8/SFMonitoring) 1))
(Cond.4)
The second condition (Cond.4) allows to guarantee at least one SF8 if needed.
The HS-PDSCH codes are pre-empted from the top to the bottom of the OVSF tree
and the minNumberOfHsPdschCodes parameter guarantees a minimum number of
HS-PDSCH codes that can not be stolen.
In order to avoid reallocation just after a stealing, the RNC starts a timer
(minTimeBeforeReallocationofHsPdsch) when a stealing is triggered during which
reallocation is forbidden but stealing is allowed.
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 HSPDSCH codes in order to have numCodesForDchAfterReallocation free OVSF
codes.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 61/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
(Cond.5)
OR
New Nb of free SF8 codes > 0 if
((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing *
SF8/SFMonitoring) 1))
(Cond.6)
The second condition (Cond.6) allows to guarantee at least one SF8 if needed.
The HS-PDSCH codes are re-allocated from the bottom to the top of the OVSF tree
and the maxNumberOfHsPdschCodes parameter guarantees a maximum number of
HS-PDSCH codes that can be re-allocated.
If #FreeOvsfCodesSfx
< threshCodesToTriggerStealing
No
Yes
No
If threshCodesToTriggerStealing * SF8/SFMonitoring 1
AND Nf of free SF8 codes == 0
Yes
If #FreeOvsfCodesSfx
> threshCodesToTriggerReallocation
Yes
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 62/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
No
Yes
Number of HS-PDSCH codes stolen is such as:
New Nb of free SF8 codes > 0
No
Yes
Number of HS-PDSCH codes re-allocated is such as:
New Nb of free SF8 codes > 0
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 63/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
SF128
SF64
SF32
SF16
SF8
SF4
0
0
Common channels
(3 S-CCPCH) + 2 HS-SCCH
0
2
1
3
R99 codes
4
2
5
1
6
3
7
8
4
9
2
10
5
11
12
6
13
3
14
7
15
isHsPdschDynamicManagementAllowed
[false, true]
Customer
3
False
Object
RadioAccessService
Granularity
RNC
The following parameter is used in UA6.0 to activate the DCTM feature at FDDCell
level:
Parameter
Range & Unit
User
Class
Value
isCellHsPdschDynamicManagementActive
[false, true]
Customer
0
False
Object
HsdpaCellClass
Granularity
CellClass
Page 64/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note: When feature is disabled at RNC level, no NBAP message is sent by RNC to provide NodeB
with new configuration, that is to say that the number of HS-PDSCH remains the same after deactivation and is not equal to numberOfHsPdschCodes. In order to reinitialize the number of HSPDSCH to numberOfHsPdschCodes, we need either to lock/unlock the cell or to disable the feature
at FDDCell level (parameter being class 0).
Prior to DCTM activation, Fair Sharing (RNC and NodeB algo) has to be disabled
Prior to Fair Sharing activation (RNC and NodeB algo), DCTM has to be disabled
Parameter
Range & Unit
User
Class
Value
numberOfHsPdschCodes
[1..15]
Customer
0
5
Object
HsdpaCellClass
Granularity
CellClass
Parameter
Range & Unit
User
Class
Value
numberOfHsScchCodes
[1..4]
Customer
0
2
Object
HsdpaCellClass
Granularity
CellClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 65/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The number of HS-PDSCH codes reserved in the HSDPA cell (numberOfHsPdschCodes) has to be
chosen according to the number of HS-SCCH codes (numberOfHsScchCodes) reserved and on the
UE category. For example, if only one HS-SCCH code (one user per TTI) is configured and majority of
users have UE Category 6 or 12 (5 HS-PDSCH codes max), there is no need to reserve more than 5
HS-PDSCH codes. In a trial context, we suppose 2 HS-SCCH codes (up to 2 UE per TTI) and UE
category 6 or 12 (5 HS-PDSCH codes max). So 10 HS-PDSCH codes are required.
In Live Network, there is a low probability to have more than 2 users scheduled during the same TTI
Moreover, the more UE are scheduled, the more HS-PDSCH codes are needed to avoid code
limitation. This is the reason why the number of HS-SCCH codes is set to 2.
numberOfHsPdschCodes = 5 for shared carrier or 10 for dedicated carrier in order to keep the same
behavior as in UA4.2 (static reservation) if the feature is de-activated
numberOfHsScchCodes = 2 in order to schedule up to 2 HSDPA users when R99 traffic is low
numberOfHsScchCodes = 4 in order to schedule up to 4 HSDPA users when DL throughput is low
(number of HS-PDSCH needed is low) for HSUPA or VoIP services
Parameter
Range & Unit
User
Class
Value
maxNumberOfHsPdschCodes
[1..15]
Customer
3
15
Object
HsPdschDynamicManagement
Granularity
CellClass
Parameter
Range & Unit
User
Class
Value
minNumberOfHsPdschCodes
[0..15]
Customer
3
1
Object
HsPdschDynamicManagement
Granularity
CellClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 66/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Recommended value
If only one HS-PDSCH code is configured (due to minNumberOfHsPdschCodes = 1 and very high
R99 traffic), the NodeB sends Capacity Allocation with 0 credits. To avoid that,
minNumberOfHsPdschCodes can be set to a value higher or equal to 2 if the MAC-d PDU is 656
bits and if Flexible Modulation is disabled.
The number of OVSF codes of SFX in the tree is monitored at each OVSF code
allocation or deallocation. The X corresponds to the parameter called
spreadingFactorLevelForOvsfMonitoring
Parameter
Range &
Unit
User
Class
Value
spreadingFactorLevelForOvsfMonitoring
[16, 32, 64, 128, 256]
Object
HsPdschDynamicManagement
Customer
3
16
Granularity
CellClass
The number of HS-PDSCH codes (SF16) that are reallocated will be computed so that
after reallocation, the number of SFX free for DCH is targeted to
numCodesForDchAfterReallocation parameter.
Parameter
Range &
Unit
User
Class
Value
numCodesForDchAfterReallocation
[1..255]
Object
HsPdschDynamicManagement
Customer
3
2
Granularity
CellClass
The number of HS-PDSCH codes (SF16) that are stolen will be computed so that after
stealing,
the
number
of
SFX
free
for
DCH
is
targeted
to
numCodesForDchAfterStealing parameter
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 67/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
numCodesForDchAfterStealing
[1..255]
Customer
3
2
Object
HsPdschDynamicManagement
Granularity
CellClass
When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is
strictly greater than threshCodesToTriggerReallocation parameter, the RNC will
reallocate some HS-PDSCH codes.
Parameter
Range &
Unit
User
Class
Value
threshCodesToTriggerReallocation
[1..255]
Object
HsPdschDynamicManagement
Customer
3
2
Granularity
CellClass
When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is
strictly lower than threshCodesToTriggerStealing parameter, the RNC will steal
some HS-PDSCH codes.
Parameter
Range & Unit
User
Class
Value
threshCodesToTriggerStealing
[1..255]
Customer
3
2
Object
HsPdschDynamicManagement
Granularity
CellClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 68/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
When
stealing
has
been
triggered,
the
RNC
starts
minTimeBeforeReallocationOfHsPdsch timer during which reallocation is forbidden
but stealing is allowed
Parameter
Range &
Unit
User
Class
Value
minTimeBeforeReallocationOfHsPdsch
[0..3600] Decimal (s)
Object
HsPdschDynamicManagement
Customer
3
0
Granularity
CellClass
Note: The number of free OVSF codes is re-evaluated for each R99 code release or
allocation
except
at
timer
expiry.
When
the
timer
minTimeBeforeReallocationOfHsPdsch is expired, RNC will check automatically the
threshold compared to the number of free OVSF codes without waiting for a R99 code
release or reallocation.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 69/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
To avoid ping-pong:
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 70/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Param identity
Default value Recommended value
Range
(Customer Class 2)
RNC / NodeB / FDDCell
OCNSActivation
OCNSSpreadingFactor
False
SF8
SF256
100%
Integer [0100]
8 with 1 S-CCPCH
OCNSChannelizationCodeNumber
10 with 2 S-CCPCH
Integer [0511]
12 with 3 S-CCPCH
Note that in UA6.0, the feature OCNS for HSDPA has been introduced for US market. See 9.3 for
more details.
X
One part of the Fair Sharing algorithm is located at RNC level and manages
the HSDPA CAC (see [Vol. 5] for more details)
X
The other part of Fair Sharing algorithm is located at NodeB level and
dynamically manages the HS-PDSCH codes allocation according to the R99
traffic (this section describes this part of the Fair Sharing algorithm).
In the previous releases, the HS-PDSCH codes configuration is managed by the RNC.
Indeed, the RNC sent to the NodeB through the PSCR message to configure (at cell
setup) or reconfigure (according to the R99 traffic if DCTM is ON) the HS-PDSCH
codes usuable by the scheduler.
In UA6.0 with Fair Sharing, the NodeB is able to know which HS-PDSCH codes can
be used for HSDPA traffic according the R99 traffic. For that, NodeB has a view in real
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 71/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
For each cell, CallP CCM must maintain an up-to-date view of the codes in use by
R99 and common channels. This view is updated anytime one of the following
channels is setup or released, or when its code and/or SF is reconfigured:
-
Common channels (P-CPICH, P-CCPCH, S-CCPCH, AICH, PICH, MICH, HSSCCH, E-AGCH)
So, at each NBAP Radio Link Setup, Addition, Reconfiguration, Deletion, the Node B
rebuilds dynamically an image of the tree to determine which SF16 codes are not
blocked/allocated to DCH and can be used as HS-PDSCH by the MAC-hs scheduler.
When Fair Sharing is enabled, the NodeB has a view of the codes used or reserved
by R99 and then knows which SF16 codes are free.
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
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 72/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Once available HS-PDSCH codes are determined, the H-BBU is reconfigured. When
the Fair Sharing is disabled, the new HS-PDSCH configuration is sent from the RNC
to the NodeB through the PSCR message. When the Fair Sharing is enabled, the new
HS-PDSCH configuration is sent from the CallP CCM to the H-BBU through an
internal PSCR message. This message (NBAP PSCR or internal PSCR gives the
same information, that is to say the number of HS-PDSCH codes and the index of the
first HS-PDSCH code).
ACTIVATION
The feature Fair Sharing and Dynamic Code Tree Management can not be activated
in the same time in a cell because they are incompatible. Before activating one, the
other has to be deactivated.
- iCEM/xCEM
Parameter
Range & Unit
User
Class
Value
hsdpaCodeTreeManagementActivation
Boolean {True, False}
Customer
3
True
Object
BTSEquipmentl
Granularity
BTS
- UCU-III
Parameter
Range & Unit
User
Class
Value
hsdpaCodeTreeManagementActivation
Boolean {True, False}
Customer
3
True
Object
OneBTSEquipmentl
Granularity
OneBTS
The same parameter activates the NodeB part of the feature but resides in different
objects depending upon the NodeB platform:
- If TRUE, HS-PDSCH codes are determined by CCM and HBBU is
dynamically reconfigured.
- If FALSE, available HS-PDSCH codes are determined by the RNC and
NBAP PSCR is directly applied.
Note that the CCM must monitor the code occupancy all the time whatever the feature
activation.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 73/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note that the common channels power reserved by RNC supposed 100% activity for
each channel. That led to over-estimation in the power reservation compared to the
actual consumption at the NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 74/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PmaxHsdpa
PminHsdpa
HSUPA
OCNS (opt.)
CCCRNC
Figure 20: Power allocation at RNC level
When OCNS is required (for cell loading during acceptance or trial tests), its power is
defined as a percentage of the power not used by common channels such as:
POCNS = (PMaxCell - PCCC) x OCNSpower
B
It is possible (if Fair Sharing is disabled) to reserve a minimum power for HSDPA
noted PminHsdpa that is subtracted from the power of the DCH pool (see the Ptraffic
formula below). This power is defined through the minimumPowerForHsdpa
parameter such as:
B
So, the higher this parameter, the lower the minimum power for HSDPA. This power is
reserved for the purpose of the Call Admission Control (CAC) at RNC and can not be
guaranteed at NodeB level if some DCH users need more power. This reservation
limits the DCH bearer admission. By reducing the number of DCH bearers, more
available power for HSDPA can be expected for the mac-hs scheduling. This minimum
power is reserved after OCNS power allocation (if OCNS is activated in the cell) and
may lead to RL reconfiguration failure for HSDPA if there is not enough power left.
Rule: Relationship between OCNS power and minimum power for HSDPA
PminHsdpa < PMaxCell - POCNS - PCCC
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 75/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The RNC reserves also some power for the SHO margin that is used for the
admission of the users in soft handover and can not be used for users in first
admission. This power is a percentage of the traffic power:
PSHO = (1 - callAdmissionRatio).Ptraffic
B
With:
Ptraffic = PMaxCell - PCCC * activityFactorCcch - POCNS - Pedch - PminHsdpa
B
When Fair Sharing feature is enabled, there is no need to reserve anymore minimum
power for HSDPA so above calculation becomes:
Ptraffic = PMaxCell PCCC*ActivityFactorCcch - POCNS Pedch
B
Ptraffic is the power available for both DCH and HSDPA allocations (I/B and Streaming).
B
activityFactorCcch: For the considered cell, common channels activity factor is used
in power reservation for common channels,
Parameter
activityFactorCcch
[0100] %
Customer
3
[iCEM] [xCEM] 66
[UCU-III] 36
Object
FDDCell
Granularity
FDDCell
This leads to definition of maximum power that the RNC can allocate to HSDPA
channels: PmaxHsdpa. This maximum power is computed at the RNC and given to
NodeB during the cell setup inside the physical shared reconfiguration channel NBAP
message.
B
In UA6.0, the maximum power that the RNC can allocate to HSxPA channels is
defined by:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 76/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
maxHspaPowerOffset
Integer (dB)
[0 50] step 0.1
Customer
0
0
User
Class
Value
Object
HsdpaCellClass
Granularity
FDDCell
Restriction: maxHspaPowerOffset
In UA6, parameter maxHspaPowerOffset can only be set equal to 0 dB. Other values are not
supported.
Typically, PmaxHspa was around 60% of PA power in UA4.2 whereas it is around 80% in UA5.0 thanks to
the activity factor on common channels being 66% instead of 100%.
B
From UA5.0, the maximum power is transmitted from the RNC to the NodeB in the
information
element
(IE)
HS-PDSCH_HSSCCH_EAGCH_E-RGCH_and_EHICH_Total_Power
through
the
PHYSICAL
SHARED
CHANNEL
RECONFIGURATION MESSAGE during the cell setup. If it is not present, HSDPA
can be allocated the whole power. The number of HS-PDSCH and HS-SCCH codes
reserved in the cell are also sent through this message, in the IE HSPDSCH_FDD_code_information and HS-SCCH_FDD_code_information respectively
(see the following figure).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 77/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PMaxCell
NodeB
PRemain
DCH margin
E-DCH
DCH
OCNS (opt.)
PTotNonHsdpa
PTotNonHsdpaWithMargin
CCCNodeB
Figure 22: Power allocation at NodeB level
Note that the common channel consumption at NodeB level is lower than at RNC level
due to activity factor consideration.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 78/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
and
PTotNonHsdpa = PDCH + POCNS + PCCC + PE-DCH
B
The dchPowerMargin parameter should be tuned so that the DCH margin is large
enough to manage the power fluctuation on the DCH while ensuring at the same time
that not too much unnecessary power is reserved.
Note that the common channel power used by the NodeB should be less than the
power reserved by RNC because of time multiplexing of several common channels.
UCU III:
U
For UCUIII no such margin exists and its power management is described in detail in
section 8.2.3.3.
X
Flexible power management feature consists in using for HSDPA all the remaining
power left by dedicated and common channels according to the RNC upper limit as:
PHSDPA = min(PRemain, PmaxHspa)
B
UCU III:
U
HSDPA power (used for HS-PDSCH and HS-SCCH) is bounded by an upper limit,
given by the RNC in the NBAP PHYSICAL SHARED CHANNEL
RECONFIGURATION message (PmaxHsdpa).
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 79/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
The transmitted carrier power PTotCell (see the following figure) is the total cell power
consumed by all codes. This transmitted carrier power is measured and
communicated within the NodeB every 100ms through a Power Management
Message (PMM) ATM cell.
B
The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes
PTotHsdpa (see the following figure) is computed and updated every TTI. An exponential
averaging is applied, whose coefficient is chosen to be coherent with the PMM
measurement. Every TTI, the following processing must then be done:
B
where PInstHSDPA corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor (Rho = 0.9775 hardcoded). PTotHSDPA should be
initialized with the instantaneous value.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 80/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PMaxCell
Power
consumed by
all codes
NodeB
NodeB
HSDPA
PTotCell
Power
consumed by
non HSDPA
codes
PTotHsdpa
PTotCell
Figure 23: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)
Note that power consumed by non HSDPA codes includes, in this release, the
downlink HSUPA channels.
The total power not used by HSDPA (PTotNonHsdpa) is then computed over the last
period by subtracting the total HSDPA power from the total cell power:
B
This measurement is reported (see the following figure) from the NodeB to the RNC
through a COMMON MEASUREMENT message in the element information (IE)
Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, EAGCH, E-RGCH or E-HICH transmission defined as a percentage of the max cell
power. This measurement is used by the RNC CAC on DCH (only for HSxPA cells)
instead of Transmitted Carrier Power measurement (this latest continues to be
reported and is still used for non-HSDPA cells). The measurement period is 100ms
but the report periodicity (for these two measurements) toward RNC is typically much
higher.and is configurable via OMC.
COMMON MEASUREMENT
Transmitted carrier power of all codes not used for HSPDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission
Figure 24: Common measurement
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 81/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The available power for HSDPA for the next 100ms period can then be computed. It
corresponds to the difference between the maximum available power in the cell
PMaxCell and the total non HSDPA power with DCH margin PTotNonHsdpaWithMargin. It is
bounded by PmaxHspa:
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 82/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
N
ATM cell received ?
PTotHsdpa
PTotCell
PTotNonHsdpa
PHSDPA
Transmit PTotNonHsdpa every
100ms to CallP (common
measurement process)
A new common measurement is computed and periodically sent from NodeB to RNC
(as done for the Total Transmitted Carrier Power of all codes not used for HS-DSCH
and HS-SCCH). This measurement is the HS-DSCH Required Power. It corresponds
to the total power needed to ensure the GBR for corresponding flows of a given cell. A
value per SPI is reported.
U
Parameter
Range & Unit
User
Class
Value
hsdschReqPwReportingPeriod
[103600000] step : 10ms
Customer
3
10000 (10s)
Object
NBAPMeasurement
Granularity
MeasurementConfClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 83/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
User
Class
Value
Object
hsdschReqPwFilterCoeff
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19]
Customer
Granularity
3
3
NBAPMeasurement
MeasurementConfClass
Contribution of each flow configured in GBR is first estimated over the whole
100ms period
Then required power of all the flows with a configured GBR is aggregated per SPI.
The required power for a given flow takes into account both HS-SCCH and HSPDSCH contribution. The idea is to evaluate the total transmitted power on both
channels when the UE was scheduled with associated number of transmitted bits.
Power needed to achieve the GBR with such conditions can then be derived. In case
the UE is not scheduled during the measurement period, the estimation is done based
on averaged reported CQI instead.
xCEM: The required transmit power for a GBR queue is approximately the average
power per payload bit multiplied by the number of bits guaranteed in the measurement
interval.
U
While the guaranteed number of bits in the measurement interval can be determined
precisely, the average TX power per bit can only be approximated. It depends on the
channel conditions (CQI), on the quality of the HS-SCCH and HS-PDSCH power
estimation, on the scheduler strategy (many small MAC-hs PDUs or some large ones),
on the selected TBS (overhead of header bits and padding), on the number of
retransmissions. A good approximation might be the cumulated TX power of all HSD
transmissions done during the measurement interval divided by the cumulated number
of payload bits contained in those HSD transmissions.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 84/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The MAC-hs scheduler shall include in the measurement report of the HSDPA
transmitted carrier power both values, the total HSDPA transmit power as well as the
HSDPA transmit power used for just GBR queues.
There is a new OAM parameter introduced namely addGBRTransmitPower, in order
to select which of the 2 measurement value shall be reported to the RNC, the
Transmitted carrier power of all non-HS channels or the Transmitted carrier power
of all non-HS channels and all GBR HS-channels. Depending on the setting of this
OAM parameter, the measurement controller ignores the GBR HSDPA Tx power or
adds it to the value of the Transmitted carrier power of all non-HS channels.
Parameter
Range & Unit
User
Class
Value
addGBRTransmitPower
Boolean {True, False}
Customer
3
False
Object
OneBTSEquipment
Granularity
OneBTSCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 85/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PHsdpa
NodeB
HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 26: Power distribution between HS-DSCH and HS-SCCH channels
A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
PHS-SCCH < PHSDPA
B
The power allocated to HS-SCCH is explained in section dedicated to the feature HSSCCH power control.
On the one hand, HSDPA UE needs to have a power reference in order to adapt its
reported CQI to the radio link condition (in the same radio condition, the reported CQI
will be higher if more power is used to transmit the HS-DSCH channel). As specified
by 3GPP ([R02]), UE has to compute its CQI in order to assure a BLER first
transmission equal to 10% by assuming that NodeB sends its HS-DSCH with the
following reference power:
X
Note that CQI computation by the UE is totally independent from the HS-DSCH
scheduling by the NodeB, since UE has no information concerning CQI processed and
algorithms used by the NodeB. That is why UE reports a CQI even if this UE is not
scheduled by the NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 86/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
where
is the reference power offset given by the reference tables of CQI [R02].
The power PHS-DSCH is defined by a power offset compared to the P-CPICH power.
This power offset corresponds to the measurementPowerOffset parameter. The
mobile is able to compute this reference power thanks to the P-CPICH power
measurement
and
to
the
measurementPowerOffset
parameter.
The
measurementPowerOffset parameter is sent from the RNC to the NodeB through the
HS-DSCH
FDD
INFORMATION
message
during
the
Radio
Link
Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HSPDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration
(see the following figure). In case this parameter is not present in the setup message,
the configuration must then be rejected.
B
HS-DSCH FDD
INFORMATION
during Radio Link
Setup/Reconfiguration
DOWNLINK HS-PDSCH
INFORMATION
during Radio Bearer
Setup/Reconfiguration
measurementPowerOffset
Figure 27: measurementPowerOffset transmission
In fact, this power can be seen as the HS-DSCH power required by the mobile
corresponding to its reported CQI. From a NodeB point of view, this power is the
maximum power that can be allocated to one HSDPA user even if more power could
be used (Note that for CQI lower than 5 the allocated power may be higher see the
column Power offset of Table 1 and Table 2).
X
Note that the reference power offset is the one corresponding to the processed CQI
(CQIprocessed) and not the reported CQI (CQIreported). See CQI section for more details.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 87/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The HS-DSCH power is equally distributed between all the physical channels HSPDSCH:
PHS-PDSCH[dBm] = PHS-DSCH[dBm] - 10.log(#codes)
B
xCEM/UCU III:
U
The SNR estimation of one HS-PDSCH depends on the available power for one HSPDSCH. Assuming that the power is uniformly distributed over all codes (NHS-PDSCH)
that are available for HSDPA, the available power for one HS-PDSCH (for user u from
the ranking list) is:
B
Where:
-
If more than one user to be scheduled for the next TTI, then NHS-PDSCH is equal to the
total number of HS-PDSCH codes (Ntotal). Else, NHS-PDSCH is the minimum between the
total number of HS-PDSCH codes and the UE capability (Nue capability) in other words,
the maximum number of HS-PDSCH that a UE of a given category can manage:
B
For UCU III, Ntotal is the number of HS-PDSCH codes configured by the NodeB due to
Fairsharing being activated by default.
B
Where:
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 88/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PHS-DSCH
HS-SCCH
PHS-SCCH
Dch Margin
R99
CCC
Figure 28: Available power per HS-PDSCH code used to compute the SNR of one HS-PDSCH
Note that a user can be scheduled only if its available HS-PDSCH power PavailableHSPDSCH(u) is positive, otherwise the next user of the ranking list shall be selected.
B
Before starting to schedule users, scheduler needs to know the total power it can use
for HSDPA according to R99 traffic usage. As with iCEM, total power usable by the
scheduler may be limited by the RNC (see PmaxHsdpa computation in section 8.2.1.1).
B
At nodeB level, with xCEM, a minimum percentage of power for HSDPA can be
defined through the parameter hsdpaMinAmpUsage. A percentage of the cell power
can also be taken into account to compute the remaining power (power not used by
non HSDPA channels) through hsdpaAmpUsage. Then, the total power usable for
HSDPA is:
PHSDPA total =
B
min(max(hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin;
B
hsdpaMinAmpUsage.Pmax); PmaxHsdpa)
B
where:
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 89/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSDPA
PHSDPA
= hsdpaAmpUsage.Pmax PTotNonHsdpaWithMargin
Dch Margin
R99
PTotNonHsdpaWithMargin
CCC
Figure 29: hsdpaAmpUsage parameter
Parameter
Range & Unit
User
Class
Value
hsdpaAmpUsage
[0100] %
Customer
3
100
Object
HsdpaConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaMinAmpUsage
[0100] %
Customer
3
0
Object
HsdpaConf
Granularity
BTSCell
UCU III:
U
HSDPA power is allocated dynamically, that is to say that HSDPA will use all the
remaining power so that the amplifier capability can be fully exploited and more power
can be allocated to HSDPA if no R99 calls are active. However, this allocated power is
not reserved for HSDPA. The power control functionality of R99 in the Node B is not
aware what amount of power has been allocated to HSDPA. If not all the HSDPA
power is allocated or if no HSDPA users are active, this power can be utilized for R99
channels. On the other side, power being allocated to HSDPA channels does not limit
the R99 power. The inner loop R99 power control is unaffected.
The principle of dynamic power allocation is shown in the figure below.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 90/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
R99 Power
HSDPA Power
Overhead Power
Figure 30: Dynamic Power Allocation
The NodeB dynamic power allocation allocates the power to HSDPA until the amplifier
capability is reached. The OMC-B parameter hsdpaAmpUsage allows limiting the
overall power being consumed by common channel, R99 and HSDPA. Currently the
default value is set to 80% of the amplifier capability, i.e. to 32 watts for a 40 watts
amplifier.
Also the minimal power for HSDPA allocated by dynamic power allocation can be
controlled in the OMC-B by the parameter hsdpaMinAmpUsage. The default is
currently set to 10%, i.e. if R99 power consumption is high no power may be left to
HSDPA. Setting this value to a non-zero value (x > 0) allocates at least x% of the
amplifier power to HSDPA. This helps to avoid stalling of the HS-DSCH throughput if
the R99 load is large.
As the traffic load in downlink direction increases, the demanded power for HSDPA
and R99 may exceed the amplifier capability of the Node B. This can happen if the
R99 and the common channel power exceed the amplifier capability. In order to
maintain signal quality of existing calls and to prevent the amplifier from overheating,
the Node B applies Aggregate Overload Control (AOC). AOC acts on R99 and
HSDPA signals in the same way. P-CPICH is not affected by AOC scaling. With
dynamic power allocation, the occurrence of amplifier overload is not expected in
normal circumstances since the HSDPA power is adjusted according to the R99 load.
If the default value of hsdpaAmpUsage is increased, AOC as described below may be
activated to prevent the amplifier from overheating. Therefore it is not recommended
to increase the value beyond default of 80%.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 91/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
hsdpaAmpUsage
[0100] %
Customer
3
80
Object
OneBTSEquipment
Granularity
OneBTSCell
Parameter
Range & Unit
User
Class
Value
hsdpaMinAmpUsage
[0100] %
Customer
3
10
Object
OneBTSEquipment
Granularity
OneBTSCell
Lack of MAC-d PDU in buffer or transport block size limitation (multi-cell per
H-BBU for instance),
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 92/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RP = round(10.log(Ptemp / PHS-DSCH))
CQI1 = CQIprocessed + RP
RP = 0
CQI1 = CQIprocessed
ncodes = f(CQI1)
UE not scheduled
RC = 0
CQI2 = CQI1
N
Select the highest CQI (CQI2) which number
of codes equals the remaining number of
codes
RC = CQI2 CQI1
N
Select the highest CQI (CQI3)
fulfilling both criteria
RO = 0
CQI3 = CQI2
Code limitation
management
nCodes <
nCodesRemain ?
CQI1 > 0 ?
Other limitation
management
Power limitation
management
CQI optimization
management
RO = CQI3 CQI2
UE scheduled
Page 93/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In case there are less MAC-d PDU available in the buffer than what would have
allowed the scheduler to transmit relative to the derived CQI from previous steps
(CQI2), the configuration is then chosen to match to the lowest CQI (CQI3) that
enables to transmit this number of PDU (see the following figure). The power must, of
course, be decreased accordingly with the same rules as before.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 94/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
21
320
16
320
16
Padding
21
320
16
320
16
Padding
Figure 32: MAC-hs transport block adaptation according to the number of MAC-d PDU to
transmit
The processing resource may be limited in the H-BBU pool configuration for instance.
All transport block sizes may not be handled. In case the one corresponding to the last
processed CQI is not manageable, the CQI is reduced to the highest one that fits with
the available resources. The power is also decreased accordingly.
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 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).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 95/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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 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).
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:
This process is iterated, until there are no more remaining resources to allocate to
QIDs, or nor more QIDs to serve.
If the remaining power is less than 1 dB, it is allocated to the QID if it leads to
MCS increase.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 96/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
hsdpaFullPowerUsage
Boolean {True, False}
Customer
3
True
Object
HsdpaConf
Granularity
BTSCell
The gain will be higher when the maximum power for a HS-DSCH is low and when only one user is
scheduled per TTI.
8.2.4.2 RETRANSMISSION
iCem:
U
The same AMC as first transmission is applied for retransmissions, i.e. same transport
block size, number of HS-PDSCH codes and modulation. Besides, in UA4.2 the same
power was also applied if possible.
The purpose of the feature HSDPA performance enhancement Power adaptation
for HARQ retransmissions is to adapt the power of retransmissions to new radio
conditions, in order to improve decoding probability while saving power when possible.
In case of erroneous CQI decoding for the initial transmission, it also allows to recover
retransmissions.
A power offset with respect to initial transmission is computed and depends on CQI
variation or retransmission index. It is a linear function of the CQI difference:
Power_offsetdB = (CQI1st CQIret)*Step Const.
B
Step is positive real number; it helps handling the erroneous CQI and allows
consuming right power according to new conditions. Const illustrates the gain
brought by redundancy versions re-combining and should be positive; a negative
value could also be set to enforce first retransmission to be decoded while consuming
maybe unnecessary power.
Default current values provided by studies are: Step = 0.5; Const = 3.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 97/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
As the power adaptation is independent of the HARQ type selected, 4 new values are
defined to activate or not power adaptation with any HARQ Type. The following coding
is then performed:
- If harqType < 10, no power adaptation
- If harqType 10, power adaptation is activated and harqType = harqType-10
The fourth new following values are then introduced:
MIRwithPowerAdaptation (11)
PIRwithPowerAdaptation (12)
CCwithPowerAdaptation (13)
DRwithPowerAdaptation (14)
Note that Step and Const cannot be changed as theres no available parameter at
OMC-B.
Parameters Settings:
Parameter
Range & Unit
Object
HsdpaConf
harqType
[mirType, pirType, ccType, drType, MIRWithPowerAdaptation,
PIRWithPowerAdaptation, CCWithPowerAdaptation,
DRWithPowerAdaptation]
Customer
Granularity
BTSCell
3
mirType
User
Class
Value
xCem:
U
As explained in [R05], the TFRC selection is done through a Look Up Table (LUT).
The MAC-hs scheduler uses a different LUT for first transmission and retransmissions
(and for MAC-d PDU size of 336 bits and 656 bits). In case of HARQ retransmission,
the transport block size is not changed from the initial transmission ([R05])
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 98/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
PRemain
NodeB
HS-DSCH
HS-SCCH
DCH margin
DCH
OCNS (opt.)
CCC
Figure 33: Remaining power for multi-users per TTI scheduling
Note: When several HSDPA users are scheduled in the same time interval and when
all the PA is used (due to R99 users or due to high measurementPowerOffset
value), HS-SCCH blocking may appear if HS-SCCH power allocated for one user is
not constant between two TTI (because HS-SCCH and HS-PDSCH are not aligned in
time (2-slots delay)). In this case, one of the users has not enough power for its HSSCCH and cannot be scheduled anymore. In order to avoid this issue, a power check
has been introduced since UA5.0 in order to be sure to have enough power for the
HS-SCCH.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 99/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The aim of this feature is to adjust, according to the radio condition, the power
allocated to HS-SCCH in order
HS-SCCH power control is not a true power control mechanism but rather a power
mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is
derived from the reported CQI (noted CQIreported), not from CQI adapted by the NodeB
in anyway, in order to adapt the transmission power to actual reported radio
conditions. This is configured in a table that gives a power offset relative to P-CPICH
for each CQI such as:
B
where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each
CQI (see the following figure).
CQIreported
hsScchPcOffset(1)
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:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 100/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CQ
hsScchPcOffset(CQIReported)
CQI
MPO = 5 dB
MPO = 6 dB
MPO = 7 dB
MPO = 8 dB
MPO = 9 dB
-3
-3
-3
0
0
-5
-3
-3
10
-5
-5
-3
-3
11
-5
-5
-5
-3
-3
12
-8
-5
-5
-5
-3
13
-8
-8
-5
-5
-5
14
-8
-8
-8
-5
-5
15
-8
-8
-8
-8
-5
16
-8
-8
-8
-8
-8
17
-8
-8
-8
-8
-8
18
-8
-8
-8
-8
-8
19
-8
-8
-8
-8
-8
20
-8
-8
-8
-8
-8
21
-8
-8
-8
-8
-8
22
-8
-8
-8
-8
-8
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 101/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
-8
-8
-8
-8
-8
24
-8
-8
-8
-8
-8
25
-8
-8
-8
-8
-8
26
-8
-8
-8
-8
-8
27
-8
-8
-8
-8
-8
28
-8
-8
-8
-8
-8
29
-8
-8
-8
-8
-8
30
-8
-8
-8
-8
-8
xCEM/UCU III:
U
Once a user has been selected from the ranking list, the scheduler computes the
power needed (to have a good probability of detection) for the HS-SCCH channel of
this user.
With xCEM, the transmit power of HS-SCCH for each scheduled user is calculated so
that the SNR of the HS-SCCH at UE side shall be equal to hsscchSnr.
Parameter
Range & Unit
User
Class
Value
hsscchSnr
[-5.019.0] dB (step .1)
Customer
3
1
Object
HsdpaConf
Granularity
BTSCell
Note that for the first implementation of the xCem, the recommendation for
hsscchSnr was 5dB in order to avoid a too low HS-SCCH power for high CQI since
no minimum power was defined. Today, a minimum power is defined for HS-SCCH
(see below), allowing to reduce the value of hsscchSnr.
With UCU III, the transmit power of HS-SCCH for each scheduled user is calculated
so that the SNR of the HS-SCCH at UE side shall be equal to hssccSnr.
The computation of the HS-SCCH power is based on the most recent SNRMAP,dB from
CQI SNR mapping for each user, taking into account that HS-SCCH uses an
SF128 :
B
Where:
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 102/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
User
Class
Value
dchPowerMargin
Integer (%)
[0 100]
Customer
3
20
Object
HsdpaConf
Granularity
BTSCell
Parameter
Range & Unit
User
Class
Value
Object
HsdpaConf
hsScchPcOffset
List[1..30]
[-28.0..28.0] dB
Customer
Granularity
BTSCell
3
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -3.0 -3.0 -5.0 -5.0 -5.0 -8.0 -8.0 -8.0 -8.0 8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0
Parameter
Range & Unit
User
Class
Value
minimumPowerForHsdpa
Integer (dB)
[0.0 50.0]
Customer
0
Unset or 50.0 (= 50.0dB)
Object
HsdpaCellClass
Granularity
FDDCell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 103/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In order to allow HSDPA calls, following formula has to be used to compute the minimum value for this
parameter:
minimumPowerForHsdpaMin = Pccc + PSRB
B
See [R01] for details about power reservation for CCs and SRBs.
X
Parameter
Range & Unit
measurementPowerOffset
Integer (0.5 dB)
[-12..26]
Customer
3
15 (= 7.5dB)
User
Class
Value
Object
HsdpaUserService
Granularity
HsdpaUserService[0..14]
If this condition is not satisfied then the HSDPA call is not setup
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 104/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Internally to the NodeB, several power checks are performed in order to guarantee that power settings
are compliant with NodeB capabilities. To avoid any issue, HSxPA power settings must fulfill the
following rules.
HSDPA rules:
U
(5) Pccc + PHS-SCCH(CQI) + eAgchPower + eHichPower + eRgchPower Max Tx Power whatever the
CQI
B
With
(9) PHS-SCCH(CQI) = PP-CPICH + hsScchPcOffset(CQI)
B
Note that above formulas are expressed in linear scale, except (3), (4), (6), (7), (8), (9) which are
expressed in logarithmic scale.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 105/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 106/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In UA5.1, the management of UL power profile (lower bound for UL SIR Target) for HSDPA
calls was handled by UA5.1.2 High quality UL R99 RAB for High HSDPA DL data rate (34652)
feature.
In UA6, the management of UL power profile (initial value, lower bound and upper bound for UL
SIR Target) for HSDPA calls is handled by Management of UL power profiles depending on
whether HSDPA is mapped on the DL sub-feature of UA6 34246 Power Control
Enhancements feature. Management of UL power profiles sub-feature of UA6 34246
includes all the functionalities of UA5.1.2 34652 regarding the upper bound for UL SIR Target,
and introduces the same concept for the initial value and the lower bound.
Remark: The set of parameters used by each of above two features is different.
U
For DL FTP data transfer, UL radio quality strongly impacts the TCP layer when UL
TCP ACKs are delayed or lost. Hence, Management of UL power profiles subfeature brings important improvement to DL throughput and user experience in this
case.
And for DL UDP streaming, UL radio quality is less impacting compared with DL FTP
data transfer, because high layer acknowledgement of data received by the mobile is
not performed. However, Management of UL power profiles may improve the
transmission of UDP signaling in the uplink, thus bringing some improvement on user
experience.
Page 107/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
eligibleUeCategoryForSirTargetHsdpa
Object
PowerConfClass
Granularity
Range & Unit
PowerConfClass
Bit string (64 bits), N/A
Customer, 3
Value
0000000000000000000000000000000000000000000000000000001111000000
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 108/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
initialSirTargetHsdpa
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
UlUsPowerConf instance
initialSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
4.7
PS_384K_IBxSRB_3_4K
Other instances
minSirTargetHsdpa
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
UlUsPowerConf instance
minSirTargetHsdpa value
PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
4.7
PS_384K_IBxSRB_3_4K
Other instances
maxSirTargetHsdpa
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 109/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
9 OTHER FEATURES
9.1 HSDPA AND E-DCH SERVICE INDICATOR (32520)
This feature allows the mobile to display an indication when it is under HSDPA or
HSDPA and HSUPA coverage: The cell capability is broadcast on SYSINFO message
(SIB5) with value HSDPA/E-DCH Capable.
Thanks to this feature, the end-user can be made aware that he is within
HSDPA/HSUPA coverage, and can then decide whether to use or not services that
require high bandwidths.
Parameters available for this feature:
isHsxpaServiceIndicatorEnabled allows to enable/disable the feature at
RNC level
Parameter
Range & Unit
User
Class
Value
isHsxpaServiceIndicatorEnabled
False, True
Customer
3
True
Object
RadioAccessService
Granularity
RNC
hsdpaServiceIndicatorMethod
ON, OFF, AUTO
Customer
3
Auto
Object
FDDCell
Granularity
FDDCell
edchServiceIndicatorMethod
ON, OFF, AUTO
Customer
3
Auto
Object
FDDcell
Granularity
FDDCell
Once the feature is activated at RNC level, three operating modes are possible for
each cell indicator (HSDPA and HSUPA), all combinations between HSDPA and
HSUPA being allowed:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 110/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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):
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 111/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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:
Page 112/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The Baseband Channel Elements in the Node B handles any HSDPA-OCNS user as if
it was a real user in the downlink. Therefore an HSDPA-OCNS user will require the
same amount of downlink resources as a real user in terms of Channel Elements.
Please note that with HSDPA-OCNS there is no associated uplink HSDPA channel
such as HS-DPCCH and no traffic on the Iub either. As a result NodeB has to
generate dummy values for CQI and ACK/NACK to simulate uplink HSDPA channel
and also for MAC-d PDU queue size.
CQI
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Real Type: 0...30 in step of 1
Customer
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 113/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
User defined
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI = 0, then random values between
range 1 and 30 shall be used by the scheduler from a generating function.
If 1< CQI <30 then a constant CQI value should be generated all the time and passed
to the scheduler. A fixed CQI value means that the scheduler would try to assign
resources based on the CQI value enter by the user. If the CQI value demands more
resources than available for a given TTI, then the OCNS user will not be scheduled for
that TTI.
Parameter
Mean CQI
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Real Type: 0...30 in step of 1
customer
Value
User defined
Parameter
Filter Coefficient
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Integer Type: 110 in step of 1
customer
Value
User defined
Filter coefficient (for an IIR filter) and Mean CQI, will be used in this random CQI
generator and hence are only applicable when CQI = 0.
NodeB scheduler shall use the user provided CQI value to drive the HSDPA-OCNS
channel. The CQI range is between 0 and 30. If CQI=0, then random value between
range 1 and 30 shall be used by the scheduler according to the generating function
defined below. The randomly generated CQI values have a mean value of Mean
CQI.
The generated CQI values are for 2 second duration. The generated CQI are re-used
for the subsequent 2 second intervals.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 114/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Initialisation
Seed = 4096;
count=0;
Mean=20
filt_coef=1;
a=(0.5)^(filt_coef/2);
X(count)=1;
count = count+1
Z = rand()
X(count)=X(count-1)xZ
No
if (count =Mean)
YES
Y= -log(X)
Y = (1-a)*Y_previous + a*Y;
if Y<1
Y=1;
elseif Y>30
Y=30;
else
Y=Y;
end
CQI = 31-Y;
Page 115/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ACK/NACK ratio
Object
OCNS
Granularity
Range & Unit
FDDCell
Integer Type: 0100% in 1% step
customer
Value
User defined
NodeB scheduler shall generate ACK or NACK every TTI. ACK/NACK will be
generated according to ratio defined by the user in percentage. This parameter
indicates the percentage of number of positive and negative acknowledgements as
input to NodeB scheduler. This would be used to trigger re-transmission by the
scheduler.
0% means all transport blocks are negatively acknowledged (NACK) by UE, 100%
means all transport blocks are positively acknowledged by UE, i.e. no retransmission
is required. If the ratio is lower, the throughput would also be lower.
Parameter
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Integer Type: 0100
Customer
Value
User defined
in step of 1
NodeB shall provide the maximum number of MAC-d PDU per TTI. This parameter is
then mapped to a certain transport block size to be transmitted over the air. This
parameter is related to amount traffic coming into the NodeB from higher layer. If zero,
it means that there is no data to transmit.
Parameter
UE Capability Number
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Integer Type: 112
customer
Value
User defined
NodeB shall use UE Capability Number in the scheduler as received in the OCNS
channel setup message. This parameter will be used by the scheduler to assign the
resources accordingly. For example if UE capability number is 12 then scheduler will
use QPSK modulation only for data transmission.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 116/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
OCNSHSDPA
Granularity
Range & Unit
FDDCell
Integer Type: 0144
minutes.
customer
Value
User defined
NodeB shall use Channel Activity Time to determine the time at which a particular
channel shall be deleted (or stopped). This parameter defines the time duration for
which a particular HSDPA-OCNS channel shall be ON. The minimum channel enabled
time is 0. This denotes a special case whereby the NodeB will disable the timer and let
the channel run until the OMC-R user locks/de-activates the object and hence causes
the channel to be deleted.
Note: The NodeB would determine the stop time for each channel based on the
channel activity time and the time it has received the HSDPA-OCNS channel setup
command.
Parameter
Cell ID
Object
HSDPAOCNS
Granularity
Range & Unit
FDDCell
Integer Type:
customer
Value
User defined
Cell ID is a user input for HSDPA OCNS operation and is selected by the operator
from available cells from a user interface at OMC-R WIPS.
Parameter
proprietaryHSDPAOCNSActivation
Object
FDDCell
Granularity
Range & Unit
FDDCell
False / True
Value
False
proprietaryHSDPAOCNSActivation is used to turned HSDPA OCNS on or off.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 117/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The HSDPA DL channel is given regardless of the MaxBitRate in the Core RAB
A R5 UE user that has a subscription in the HLR of MaxBitRate=64K or 384K or 2M
will be given with the same HSDPA DL channel and will benefit of throughputs up to
1.2M ( UE cat12)
If a subscriber (whatever MaxBitRate in HLR ) inserts its SIM into a HSDPA UE , it will
have access to a throughput that is only limited by the UE ( cat12=>1.4Megs,
cat6=>3.4Megs)
In UA5.0, a PS E-DCH RAB is allocated if:
Coupled with the usage of HSDPA to carry the DL traffic, HSUPA has been designed
to carry only a best effort traffic (i.e. interactive/background traffic on E-DCH); in other
word an HSUPA leg is always associated to an HSDPA leg.
9.4.2 ALGORITHM
This capability is based on a token bucket algorithm as specified in [R04].
X
This algorithm is used to verify that traffic packets submitted by the Core Network to a
UMTS bearer do not exceed the requested Max value. It uses the following two
parameters (r and b) for the traffic contract and one variable (TBC) for the internal
usage.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 118/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
Each Time a packet of length Li arrives, the value of TBC is checked. If TBC is large
enough (b Li), meaning that the packet fits into the buffer, the traffic is considered as
conformant and the packet is accepted (as L1 and L2 in picture above), otherwise it is
deleted (as L3).
The value of TBC increases at a rate of r by time unit, and does not exceed b. The
RNC will actually updates TBC each time it receives a packet, by dT*r where dT is the
difference of time between the reception of the current packet and the previous
packet.
In the scope of HSxPA implementation, this algorithm is used to make sure users do
not exceed the original QoS contract.
Note : the bandwidth limit used in the algorithm is actually the RAB Maximum Bitrate,
bounded by a provisonable parameter MaximumTokenGenerationRate. This is useful
in case the Core Network has not be configured appropriately. The bucket size b is
equal to the provisionable parameter BucketBufferTime * MBR.
U
9.4.3 PARAMETERS
The following three parameters are used to activate and configure the Iu User traffic
Conformance Feature:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 119/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
sourceConformanceActivation Object
DlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : On if the operator wants to limit UE throughput
User
Class
Value
Parameter
Range & Unit
sourceConformanceActivation Object
UlSourceConformanceInformation
Enum
{Off, On}
Customer
Granularity RNC
3
Default: Off
Recommended : On if the operator wants to limit UE throughput
User
Class
Value
Parameter
Range &
Unit
User
Class
Value
maximumTokenGenerationRate
Integer (kBytes/s)
[1..2000]
Customer
3
Default: 500
Object
DlSourceConformanceInformation
Granularity
RNC
Note: The default value corresponds to ~4Mbits/s. If the operator wants that none
user benefits of cat6 Qos (only Cat12) , it can be set to 1.4 M/s=175kbytes/s
U
Parameter
Range &
Unit
User
Class
Value
maximumTokenGenerationRate
Integer (kBytes/s)
[1..2000]
Customer
3
Default: 500
Object
UlSourceConformanceInformation
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 120/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
User
Class
Value
bucketBufferTime
Integer (ms)
[10..30000] step = 10
Customer
3
Default: 3750
Object
DlSourceConformanceInformation
Granularity
RNC
bucketBufferTime
Integer (ms)
[10..30000] step = 10
Customer
3
Default: 500
Object
UlSourceConformanceInformation
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 121/122
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 122/122
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
V03.10
02/OCT/2009
Alcatel-Lucent Proprietary
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CONTENTS
1
INTRODUCTION............................................................................................................................5
1.1
OBJECT ....................................................................................................................................5
1.2
2.2
4.1.1
UL load management....................................................................................................10
4.1.1.1
totalRotMax............................................................................................................... 12
4.1.2
RSEPS measurements .................................................................................................15
4.1.3
UL load estimation in presence of urban noise.............................................................17
4.1.4
High UL RSSI alarm......................................................................................................18
4.2
DL POWER MANAGEMENT .......................................................................................................20
4.2.1
At RNC ..........................................................................................................................20
4.2.2
At NodeB .......................................................................................................................20
4.2.2.1
E-DCH DL channels power settings......................................................................... 21
4.2.2.2
E-DCH DL channels configuration ........................................................................... 23
5
5.2
UE CATEGORIES .....................................................................................................................28
5.3
5.4
5.5
5.6
MISCELLANEOUS ....................................................................................................................42
6.2
6.3
6.4
6.5
6.6
ACTIVITY MONITORING.............................................................................................................55
6.7
6.8
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
7.2
7.3
7.4
ACTIVITY MONITORING.............................................................................................................68
7.5
7.6
7.7
7.8
9.1.1
E-DCH UL OLPC in UA5...............................................................................................79
9.1.2
UA6 34249 EUL Capacity Optimized HARQ Operation .............................................80
9.1.2.1
Principle of E-DCH UL OLPC ................................................................................... 80
9.1.2.2
UA6 34249 Feature description................................................................................ 84
9.1.2.3
Parameter settings and recommendations............................................................... 90
9.2
POWER CONTROL OF E-DCH DL CHANNELS ......................................................................... 101
9.2.1
UA5.1/xCEM E-DCH DL control channels Power Control (33481) ......................... 101
9.2.1.1
Introduction ............................................................................................................. 101
9.2.1.2
Feature description................................................................................................. 101
9.2.1.3
Parameter settings and recommendations............................................................. 103
9.2.2
UA6/xCEM E-DCH DL control channels Power Control (33481) ............................ 106
9.2.2.1
Feature description................................................................................................. 106
9.2.2.2
Parameter settings and recommendations............................................................. 107
9.2.2.3
Other recommendations ......................................................................................... 109
10
10.2
10.3
10.4
10.5
11
12
Page 2/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TABLES
Table 1: UE categories
29
Table 2: Quantization for E-DPDCH (from 3GPP TS 25.213)
34
Table 3: iCEM recommended {Reference E-TFCI; Reference Power Offset} table
35
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table
36
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table 36
Table 6: xCEM/2ms TTI/2xSF2+2xSF4 recommended {Reference E-TFCI; Reference Power Offset}
36
table
Table 7: UCU-III recommended {Reference E-TFCI; Reference Power Offset} table
37
Table 8: Primary Cell HSUPA Category according to Primary Cell E-DPDCH SF capability and
39
selected E-DCH TTI
Table 9: EdpchParameters instance according to Target HSUPA UE Category and selected E-DCH
40
TTI
Table 10: Grant Index values
51
Table 11: Scheduling Priority iCEM
56
Table 12: E-DCH SPI
58
Table 13: Scheduling Priority xCEM
71
TU
UT
TU
UB
UB
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
UT
TU
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FIGURES
Figure 1: Noise Rise vs. UL Load .................................................................................................................... 11
Figure 2: Example of uplink load (thermal noise/R99/E-DCH) .................................................................... 12
Figure 3: Power allocation at RNC level ......................................................................................................... 20
Figure 4: {E-TFCI; Transport Block Size} tables for 10ms TTI, as defined in 3GPP TS 25.321 ............ 31
Figure 5: E-DPDCH Power vs. Transport Block Size ................................................................................... 33
Figure 6: UA6 E-DCH parameters model at OMC-R .................................................................................... 38
Figure 7: reserved0 bit configuration ............................................................................................................... 44
Figure 8: RTWP exceeding margin.................................................................................................................. 50
Figure 9: Iub BW limitation iCEM ..................................................................................................................... 59
Figure 10: Uplink Iub Congestion iCEM .......................................................................................................... 60
Figure 11: Uplink Iub DeCongestion iCEM ..................................................................................................... 61
Figure 12: TNL Congestion Indication iCEM .................................................................................................. 62
Figure 13: GRF updating GRF iCEM .............................................................................................................. 63
Figure 14: Uplink Iub Congestion xCEM......................................................................................................... 74
Figure 15: TNL Congestion Indication xCEM ................................................................................................. 75
Figure 16: Local congestion control mechanism ........................................................................................... 76
Figure 17: E-DCH UL OLPC general principle............................................................................................... 80
Figure 18: Cell State computation ................................................................................................................... 86
Figure 19: UL OLPC in case of SRB on E-DCH ............................................................................................ 87
Figure 20: HFI Reception Scenario computation........................................................................................... 88
Figure 21: UA6 34249 RAN model for PS_EDCH and SRB_EDCH UL RBs ...................................... 91
Figure 22: UA6 34249 RAN model for E-DCH UL services and misc. ....................................................... 92
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
UT
UT
TU
TU
TU
TU
UT
UT
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1 INTRODUCTION
1.1 OBJECT
The objective of this volume (UA6 HPUG [Vol.4]) is to describe from an engineering
point of view E-DCH principle, scheduling and resource management aspects in
Alcatel-Lucent UTRAN release UA06. This includes a system description,
configuration aspect and engineering recommendations.
X
Feature Title
Release
Global
Market
USA
Marke
t
UA5.0
Yes
Yes
UA5.1
Yes
Yes
isUlOuterPCActivated (for UL
services with E-DCH)
UA5.1
Yes
Yes
UA5.1
Yes
No
Activation flag
isEdchAllowed, edchActivation
29840
UA5.1
33481
34172
34221
33327
33332
33336
33367
E-DCH Step1
(HSUPA)
E-DCH DL control
channels Power
Control
Remark: UA6 version
of the feature also
exists (see below).
E-DPDCH
Retransmissions for
DPCCH SIR
Adaptation
U
[iCEM] [xCEM]
edchResourceActivation
[iCEM] Feature not applicable.
Self-interference in
MAC-e Scheduler
[iCEM]
rotOrthogonalityEstimation
[xCEM] [UCU-III]
Feature not applicable.
MAC-e Scheduler
enhancements
Iub bandwidth
limitation for E-DCH
edchSpiRelativeWeight
UA6.0
Yes
No
isEdchBandwidthlimitationAllowe
d
UA6.0
Yes
No
HSUPA UE
categories 4 to 6
HSPA congestion
detection &
notification
isEdchTti2msAllowed
UA6.0
Yes
Yes
UA6.0
Yes
No
No activation flag.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UA6
33481
E-DCH DL control
channels Power
Control
[xCEM]
eagchPowerControlActivated,
eagchPowerControlModeXcem
UA6.0
Yes
Yes
[UCU-III]
eagchPowerControlActivated
[iCEM] Feature not applicable.
33581
34134
34175
SRB on E-DCH
during call
[xCEM] [UCU-III]
isSrbOnEdchAllowedWhenTrbOnEdch
UA6.0
Yes
Yes
RssiHighAlarmThreshold
UA6.0
Yes
No
No activation flag.
UA6.0
Yes
No
UA6.0
Yes
Yes
UA6.0
Yes
No
UA6.0
No
Yes
UA6.0
No
Yes
UA6.0
No
Yes
UA6.0
Yes
No
UA6.0
Yes
No
34249
EUL Capacity
Optimized HARQ
operation
[xCEM] [UCU-III]
No activation flag.
Feature can be restricted to UA5.1
mode by applying specific
parameter settings.
34167
Defence mechanism
for UE not supporting
CM with HSPA
isEdchCmFallbackAllowed
34229
IFHHO
Enhancements
isInterFreqHandoverOverIurAllowed
Voice + HSUPA
Remark: UA6 34438
feature only applies
to USA Market.
However, voice +
HSUPA multi-service
is available for both
Global Market and
USA Market.
OneBTS
Interoperability Parity
iBTS Local EDCH
Congestion Control
U
34438
34373
75786
[iCEM][UCU-III]
Feature not applicable
[xCEM]
edchCMActivation
81112
UL load estimation
in presence of
urban noise
[iCEM][UCU-III]
Feature not applicable
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol.1] Introduction
[Vol.2] HSxPA Overview
[Vol.3] HSDPA Principles, Scheduling and Resource Management
[Vol.4] E-DCH Principles, Scheduling and Resource Management
[Vol.5] Call Management
[Vol.6] Mobility
[Vol.7] Deployment Scenarios
[R02] UMT/IRC/APP/014654
[R04] UMT/SYS/DD/018827
[R08] UMT/BTS/INF/016135
Planning Guide
[R13] UMT/IRC/APP/021071
Engineering
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
3 E-DCH ACTIVATION
In order to activate E-DCH on a given cell, the following activation flags must all be set
to True.
Parameter
Range & Unit
User
Class
Value
Parameter
Range & Unit
User
Class
Value
Object
RadioAccessService
Customer
3
True
Granularity
RNC
edchActivation
Object
FDDCell
Granularity
Cell
Object
BTSCell
Granularity
Cell
isEdchallowed
False, True
False, True
Customer
2
True
[iCEM] [xCEM]
Parameter
Range & Unit
User
Class
Value
edchResourceActivation
False, True
Customer
0
True
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RTWPref depends on several factors such as NodeB configuration, cable length, TMA
usage or not, temperature. Therefore, a self learning algorithm has been implemented
that keeps tracking this parameter every day based on the average of the minimum
samples of RTWP observation. This algorithm is activated by default.
B
[iCEM] [xCEM]
Parameter
Range & Unit
User
Class
Value
isRtwpReferenceSelfLearning
Object
BTSEquipment
Granularity
Cell
False, True
Customer
3
True
Note that the reference RTWP is not transmitted to the RNC. Therefore the non EDCH RTWP transmitted through NBAP common message assumed a default value
for the thermal noise: NBAP RTWPnon E-DCH = -106.1 + RoTnon-EDCH
B
Parameter
Range & Unit
User
Class
Value
rtwpReference
Object
BTSCell
Granularity
Cell
Customer
3
-106.1
The parameter rtwpReference is the reference of RTWP when the BTS does not
receive any radio signal for this cell. If the parameter isRtwpReferenceSelfLearning
is set to TRUE, this parameter is only used to initiate the RTWP self learning feature.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
14
12
10
8
6
4
2
0
0.1
0.2
0.3
0.4
0.5
UL load
0.6
0.7
0.8
0.9
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RSSI
CS64
PS64
CS12.2
CS12.2
Thermal Noise
Figure 2: Example of uplink load (thermal noise/R99/E-DCH)
Two parameters are used to set the maximum allowed UL radio load:
rtwpMaxCellLoadNonEdch (under BTSCell object) and totalRotMax (under
FDDCell object).
rtwpMaxCellLoadNonEdch : Parameter used to set the maximum allowed non EDCH UL radio load, for UL Radio Load CAC at NodeB mechanism described in
UPUG [R01], Vol.6, section 5.10. As mentioned in [R01], rtwpMaxCellLoadNonEdch
is taken into account by the system only if UL Radio Load CAC at NodeB
mechanism has been activated, i.e. only if rtwpMaxCellLoadCacActivation (under
BTSCell) has been set to true.
X
Parameter
Range & Unit
User
Class
Value
rtwpMaxCellLoadNonEdch
[0..100] (%)
Customer
3
50
Object
BTSCell
Granularity
Cell
4.1.1.1 totalRotMax
[iCEM] [xCEM]
Parameter used to set the maximum allowed total UL radio load, for E-DCH
scheduling purpose. Basically, the MAC-e scheduler allocates grants so that the total
UL radio load remains below and close to totalRotMax. Note that totalRotMax value
is specified in terms of UL noise rise (also referred as RoT Rise over Thermal
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 12/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
totalRotMax
Object
FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Granularity
Cell
Please refer to UPUG Vol.6 for further details regarding these two distinguish
parameter class utilisation.
[UCU-III]
Regarding OneBTS this parameter is used to determine the maximum noise rise to
ensure uplink coverage. The maximum target uplink load for the cell is set internally in
the OneBTS to 85%. If this maximum level of interferences is exceeded, then the
MAC-e scheduler will reduce its target load for E-DCH to reduce the total uplink cell
load. Thus, it is recommended to set this parameter to 15 dB.
Parameter
Range & Unit
User
Class
Value
totalRotMax
[0..20] step:0.1 (db)
Customer
2
15
Object
FDDCell
Granularity
Cell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
rtwpMaxCel lLoadNonEd ch 1
1
10
totalRotMa x / 10
If above relationship is not fulfilled, then maximum allowed non E-DCH UL radio load for UL Radio
Load CAC at NodeB mechanism is considered by NodeB as equal to the maximum allowed total UL
radio load, i.e. 1-1/(10 totalRotMax / 10).
P
Rule: totalRotMax
The maximum allowed total UL radio load in terms of UL noise rise (or RoT) should be set lower than
or equal to 8dB (which corresponds to an UL radio load of 84.2%).
totalRotMax 8 (for iBTS only -> not for OneBTS)
If above rule is not respected, there is a high probability to face system instability regarding UL noise
rise fluctuation, such as important and frequent peaks of UL noise rise (i.e. UL RSSI peaks).
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:
Parameter
Range & Unit
User
Class
Value
isRtwpAdjustmentForRnc
Object
BTSEquipment
Granularity
Cell
False, True
Customer
3
True
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
referenceRtwp
Object
FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Granularity
Cell
Object
FDDCell/
Class2PscrParams
FDDCell/
Class3PscrParams
Granularity
Cell
Please refer to UPUG Vol.6 (totalRotMax description) for further details regarding
these two distinguish parameter class utilisation.
When the RSEPS measurements are deactivated, this parameter indicates if the BTS
does a correction of the RTWP before reporting it to RNC in the NBAP COMMON
MEASUREMENT REPORT. If the parameter is set to TRUE, the correction is:
-106.1 + (Rtwp_measured - rtwpReferenceOrSelfLearned).
Example: isRtwpReferenceSelfLearned is set to TRUE. The selfLearned
rtwpReference is measured by the BTS to -105dBm. The BTS read a RTWP of 100dBm --> The BTS will report: -106.1 + (-100 + 105) = -101.1 dBm (instead of -100)
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 edch power (UA5 behavior).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 15/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RSEPS
are
sent
by
NodeB
and
Non_Edch_Ul_Load=Total_Ul_Load RSEPS[ratio]
Where
Total_Ul_Load=1-10^(-Total_RoT/10)
Total_Rot=Total_RTWP[dBm]-Reference_RTWP[dBm].
Note that:
The
parameters
nbapCommonMeasRsepsFilterCoef
and
nbapCommonMeasRsepsReportingPeriod are not used anymore and
the RSEPS measurements are configured with the same filter coefficient
and periodicity as RTWP measurements based on the parameters
nbapCommonMeasRtwpFilterCoef
and
nbapCommonMeasRtwpReportingPeriod (please refer to [R01] for
details about these parameters).
RNC
and
isUplinkRadioLoadEnabled (located under RNC RadioAccessService)
have to be set to the value True (please refer to [R01] for details about
these parameters).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isNbapCommonMeasRsepsAllowed
Object
NodeB
Granularity
BTS
False,true
Customer
3
True
[UCU-III]
OneBTS for the moment does not support RSEPS, but only a special measurement of
RTWP which is derived from the non-EDCH load. This measurement is equivalent to
RTWP provided in UA5.1. Therefore, the RSEPS measurement is deactivated:
isNbapCommonMeasRsepsAllowed set to False.
A new measurement method is then put in place and this method can be selected
(instead of the actual RTWP method) at cell level by using the
BTSEquipment/BTSCell/EdchConf
maxEdchCommonChannelPower
parameter (this old unused parameter is re-used for this specific purpose in this
version due to late introduction of this feature).
As it is know, with the current method the radio load is based on the following
equation:
UL load = 1 RTWPref/ RTWP
B
Loc is the other-cell interference factor accounting for the load impact from
users which have no active radio link in the cell
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
This parameter represents 100 + the proportion of power due to other external cells of
the specified cell. Values below 100 indicates deactivation of the feature (values from
[+100.0...+200.0] will activate the feature) and Mac-e scheduler will use RTWP values
for UL Load estimation.
Parameter
Range & Unit
User
Class
Value
Object
maxEdchCommonChannelPower
Decimal [-35.0 +200.0] step:0.1, none
Customer
Granularity
3
0
EdchConf
BTSCell
This new UL load estimation can be applicable to any frequency band (2100 MHz,
900/850 MHz). However it could be acceptable that the feature is applied by default
only to 850/900 MHz and excludes 2100 MHz for which the RTWP based method
could be kept unchanged.
This feature is applicable only to Node B configurations (iBTS) where the whole traffic
of one carrier is handled by one and only one xCEM (absence of inter modem board
messaging in UA06 prevents usage of UL load estimation based on SIR values for
carriers having cells or UL contributors distributed over multiple modem boards). Note
that for any other supported configurations, e.g. iCEM and xCEM mixity this feature
is not applicable as it is not possible to guarantee that following a failure, no iCEM will
be allocated for the frequency for which this feature is activated.
[iCEM][UCU-III]
This feature is dedicated to iBTS xCEM only.
Page 18/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RssiHighAlarmThreshold
Object
BTSEquipment
Granularity
Cell
Customer
3
unset
In case of high UL RSSI alarm activation, the threshold could be set to 10dB above
Noise level (i.e. 90% Ul load). A normal noise level value measured in the TRM should
be in the range [-107.5dBm, -104.5dBm] so the alarm threshold could be set to
-94.5dBm to cover all the range.
[UCU-III]
Feature dedicated to iBTS only
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
SHO margin
PMaxCell
RNC
Ptraffic
PminHsdpa
E-DCH
OCNS (opt.)
CCCRNC
Figure 3: Power allocation at RNC level
The amount of power reserved for E-DCH DL channels at RNC level can be set via
eagchErgchEhichTotalPower parameter.
Parameter
Range & Unit
User
Class
Value
eagchErgchEhichTotalPower
Decimal [0.0 50.0] step:0.1, dBm
Customer
0
10
Object
EdchCellClass
Granularity
EdchCellClass
4.2.2 AT NODEB
At the NodeB, power is allocated in priority to CCC channels, E-DCH DL channels and
DCH DL traffic. The remaining power is then allocated to HSDPA DL channels (i.e.
HS-SCCH and HS-DSCH).
Remark: At NodeB, there is no upper limit for E-DCH DL channels total Tx power.
maxEdchCommonChannelPower parameter under EdchConf, which was originally
created for this purpose, is ignored by the system.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[iCEM]
On iCEM, E-DCH DL channels are not power controlled; their transmit power is fixed
and can be set via eagchPower, ehichPowerSignature and ergchPowerSignature
parameters. Note that on iCEM, E-RGCH is only used for the purpose of sending
Down RG commands to non-serving UEs when the ratio of UL noise rise generated
by non-serving radio links to total E-DCH UL noise rise exceeds
targetNonServingToTotalEDCHPowerRatio threshold. Please refer to [Vol.6],
section 3.3.2 for more information on handling of non-serving radio links and more
generally on E-DCH Macro Diversity in UA6.
X
eagchPower: Power offset for one E-AGCH channel, relative to the CPICH power.
Parameter
Range & Unit
User
Class
Value
eagchPower
Signed [-35.0 15.0] step:0.1, dB
Customer
3
-2.5
Object
EdchConf
Granularity
BTSCell
Remark: Only one mobile can be addressed per E-AGCH channel and per TTI.
U
ehichPowerSignature
Signed [-35.0 15.0] step:0.1, dB
Customer
3
-8.0
Object
EdchConf
Granularity
BTSCell
Remark: On iCEM, up to 15 E-HICH signatures may be used on the same E-HICH/ERGCH channel (instead of 40 as of 3GPP) since the maximum number of E-DCH
radio links that can handle one E-BBU is 15.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ergchPowerSignature
Signed [-35.0 15.0] step:0.1, dB
Customer
0
-8 dB
Object
EdchConf
Granularity
BTSCell
Hence, for the usual case of maxTxPower = 45dBm, pcpichPower = 35dBm, it is recommended
to set ergchPowerSignature to -22.0dB.
If UA6 E-DCH Macro Diversity (32076) feature is activated, it is recommended to set
ergchPowerSignature to -8dB.
Remark: In above Engineering Recommendation, the term +3.0 is introduced so that,
even if pcpichPower is set to a value lower than usual (e.g. for lab test purpose), in a
certain extend it is not required to modify ergchPowerSignature value.
U
For information, the following iCEM-specific parameters are also present in UA6 RAN
Model (under EdchConf) but ignored by the system. Their default value (Fixed)
should not be changed.
Rule: eagchPowerControlMode, ehichPowerControlMode, ergchPowerControlMode setting
eagchPowerControlMode, ehichPowerControlMode, ergchPowerControlMode under EdchConf
(iCEM-specific parameters) should not be set to a value different from the default one, i.e. Fixed.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[UCU-III]
On UCU-III, power control of E-AGCH, E-RGCH and E-HICH is supported via UA6 EDCH DL control channels Power Control (33481) feature. Please refer to section 9.2
for a detailed description of the mechanism and parameters involved in this feature.
X
TH
Parameter
maxNrOfEagch
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
1
Remarks:
U
TH
TH
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
maxNrOfErgchEhich
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
[iCEM] 1
[xCEM] 4
[UCU-III] 4
Remarks:
U
[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 AlcatelLucent written authorization
Page 24/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[xCEM] [UCU-III]
Remark on maximum number of E-DCH users per cell:
U
As explained above, assuming that one E-RGCH Common signature is allocated per
E-RGCH/E-HICH channel, one E-RGCH/E-HICH channel can support up to 19 E-DCH
radio links. Accordingly, setting maxNrOfErgchEhich = 4 theoretically enables up to
76 E-DCH radio links per cell.
For xCEM, a maximum of 128 E-DCH radio links can be supported per cell from a
hardware point of view (up to 128 E-DCH radio links are supported per xCEM board,
hence per cell assuming there is no E-DCH radio link established on the other cells
supported by the same board). This means that setting maxNrOfErgchEhich = 4
actually enables up to 76 E-DCH radio links per cell.
For UCU-III, a maximum of 64 E-DCH radio links can be supported per cell from a
hardware point of view (up to 64 E-DCH radio links are supported per cell regardless
to the number of UCU-III boards, but a maximum of 3 x 64 = 192 E-DCH radio links
can be supported per NodeB with 3 UCU-III boards). This means that setting
maxNrOfErgchEhich = 4 actually enables up to 64 E-DCH radio links per cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Configuration method:
U
Use two specific EdchCellClass instances (one for iCEM and one for xCEM).
For the EdchCellClass instance related to each type of board (iCEM and xCEM), set
maxNrOfErgchEhich to above-specified value.
Make each cell (FDDCell object) point toward the appropriate EdchCellClass instance,
according to the type of board that handles E-DCH traffic for this cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 26/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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.
Restriction: 9313 Micro NodeB & 9314 Pico NodeB support only 1 E-AGCH and 1 E-RGCH/EHICH
As a consequence, in the edchCellClass used to configure a Micro/Pico Nodeb cell, the parameters
maxNrOfEagch and maxNrOfErgchEhich must be set to 1.
See [R13] for more information on the 9313 Micro NodeB.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
RadioAccessService
Customer
3
True
Granularity
RNC
isEdchTti2msAllowed
Object
EdchCellClass
Granularity
EdchCellClass
isEdchTti2msAllowed
Parameter
Range & Unit
User
Class
Value
True,False
True,False
Customer
3
True
5.2 UE CATEGORIES
As the SF2 and 2msTTI are supported only by the xCEM, the UE categories 4, 5 and
6 are supported only by the xCEM in UA6 whereas the iCEM board keeps the same
capabilities as in UA5 (i.e UE CAT 4, 5 and 6 are not supported by iCEM).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Maximum
Number
of Codes
Minimum
SF
Category 1
SF 4
Category 2
SF 4
Category 3
SF 4
Category 4
SF 2
Category 5
SF 2
Category 6
SF 2
TTI
[ms]
Maximum
MAC-e
PDU Size
[Bits]
Maximum
Date Rate at
MAC-e layer
[Mbps]
10
10/
2
10
10/
2
10
10/
2
7110
14484/
2798
14484
20000/
5772
20000
20000/
11484
0.71
1.45/
1.40
1.45
2.00/
2.89
2.00
2.00/
5.74
Maximum
RLC
Throughput
[Mbps]
0.67
1.38/
1.28
1.38
1.89/
2.72
1.89
1.89/
5.44
Throughput @
ATM layer
(+30% protocol
headers)
[Mbps]
0.87
1.79/
1.66
1.79
2.45/
3.53
2.45
2.45/
7.07
Note: When 4 codes are transmitted in parallel, 2 codes shall be transmitted with SF2 and the other 2 with SF4
Table 1: UE categories
In UA6, the RNC configures the ETFCI table according to UE category and cell
capabilities (i.e. TTI type).
prohibitedStatusTimer
Object
UlRlcAckMode
Granularity
RNC, RlcConfClass
Enum {10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170,
180, 190, 200, 210, 220, 230, 240, 250, 260, 270, 280, 290, 300, 310, 320, 330,
340, 350, 360, 370, 380, 390, 400, 410, 420, 430, 440, 450, 460, 470, 480, 490,
500, 510, 520, 530, 540, 550, 600, 650, 700, 750, 800, 850, 900, 950, 1000}
Ms
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
As shown below in Figure 4, Table 0 has an exponential increase and Table 1 has a
linear increase. The choice of the {E-TFCI; Transport Block Size} table is linked with
the {Reference E-TFCI; Reference Power Offset} table, described in next section.
X
Regarding 10ms TTI, 128 E-TFCIs are defined for 10ms TTI E-DCH TBS Table 0,
and 121 E-TFCIs are defined for 10ms TTI E-DCH TBS Table 1. For both iCEM and
xCEM, it is strongly recommended to use 10ms TTI E-DCH TBS Table 1.
Regarding 2ms TTI, 128 E-TFCIs are defined for 2ms TTI E-DCH TBS Table 0, and
126 E-TFCIs are defined for 2ms TTI E-DCH TBS Table 1. For the xCEM (for which
2ms TTI is available), it is strongly recommended to use 2ms TTI E-DCH TBS Table
1.
Parameter
Range & Unit
User
Class
Value
Object
EdpchParameters
edchTfciTableIndex
Enum {2msTtiTable0, 2msTtiTable1, 10msTtiTable0, 10msTtiTable1}, N/A
Customer
Granularity RNC
0
EdpchParameters instance related to 10ms TTI: 10msTtiTable1
EdpchParameters instance related to 2ms TTI: 2msTtiTable1
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 30/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 31/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In UA6, up to two MAC-d flows one for user data and one for UL SRB are
supported on E-DCH for iBTS xCEM and OneBTS UCU-III. Each MAC-d flow can
be assigned a MAC-d flow-specific power offset, which value can be set per UL
RB (i.e. different MAC-d flow-specific power offset values can be set for
PS_EDCH and SRB_EDCH UL RBs). For a given UL RB, the MAC-d flow-specific
power offset is set via edchMacdPowerOffsetEdchTti10 (for 10ms E-DCH TTI)
and edchMacdPowerOffsetEdchTti2 parameter (for 2ms E-DCH TTI).
Available UE power
Number slots in next 10ms E-DCH TTI affected by a Compressed Mode gap.
Figure 5 shows the principle of retrieving the whole {E-TFCI; Power Offset} table
basing on the {Reference E-TFCI; Reference Power Offset} table. X-axis represents
TBS, and Y-axis represents Power Offset in dB.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
30
25
20
15
10
0.2
0.4
0.6
0.8
1
1.2
TB size (bits)
1.4
1.6
1.8
2
4
x 10
Again, in order to avoid too much signaling when configuring the {Reference E-TFCI;
Reference Power Offset} table both at NodeB and at UE side, the RNC sends coded
values (after quantization) for the Reference Power Offsets (i.e. power ratio E-DPDCH
/ UL DPCCH, also referred as ed/c). The coded values for Power Offsets are
specified in 3GPP TS 25.213 [R06], Table 1B.1, and recalled below for convenience.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 33/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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
Object
ReferenceEtfciConfList
referenceEtfci
Integer [0 127], N/A
Customer
Granularity
RNC
0
See below Table 3, Table 4, Table 5, Table 6 and Table 7
Parameter
Range & Unit
User
Class
Value
Object
ReferenceEtfciConfList
referenceEtfciPowerOffset
Integer [0 29], N/A
Customer
Granularity
RNC
0
See below: Table 3, Table 4, Table 5, Table 6 and Table 7
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 34/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Due to the introduction of 2ms E-DCH TTI in UA6/xCEM, new {Reference E-TFCI; Reference
Power Offset} tables (corresponding to 2ms TTI cases) are introduced in UA6.
Regarding 10ms TTI, as for UA5.1, due to the specific implementation and behavior of xCEM EDCH functions, the recommended {Reference E-TFCI; Reference Power Offset} table is
different for iCEM and xCEM.
The four recommended tables for iBTS (i.e. iCEM, 10ms TTI on xCEM, 2ms TTI with
E-DPDCH min SF of 2xSF2 on xCEM, 2ms TTI with E-DPDCH min SF of
2xSF2+2xSF4 on xCEM) and the recommended table for OneBTS, as well as the
recommended configuration method are described below.
[iCEM] [xCEM]
U
Reason for using board-specific {Ref E-TFCI; Ref PO} tables (10ms TTI case):
U
Regarding 10ms TTI, due to the specific implementation and behavior of xCEM EDCH functions, the recommended {Reference E-TFCI; Reference Power Offset} table
is different for iCEM and xCEM. In particular, for xCEM, in order to avoid UL load
divergence issues due to user self-interference for high data rate transmission in
channel profiles with bad orthogonality, the strategy is to allow higher UL DPCCH
power (set via maxSirTarget parameter) while using smaller E-DPDCHs / UL DPCCH
power ratio (set via {Reference E-TFCI; Reference Power Offset} table), compared
with iCEM. Please refer to section 9.1.2.3.4 for more information on the recommended
setting for maxSirTarget for E-DCH calls.
X
For iCEM, the recommended {Reference E-TFCI; Reference Power Offset} table is as
follows.
ReferenceEtfciConfList
referenceEtfci
referenceEtfciPowerOffset
11
11
15
85
22
95
23
96
24
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 35/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
referenceEtfci
referenceEtfciPowerOffset
10
25
16
51
18
106
19
Table 4: xCEM/10ms TTI recommended {Reference E-TFCI; Reference Power Offset} table
For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
ReferenceEtfciConfList
referenceEtfci
referenceEtfciPowerOffset
13
14
83
20
Table 5: xCEM/2ms TTI/2xSF2 recommended {Reference E-TFCI; Reference Power Offset} table
For xCEM with 2ms TTI and E-DPDCH min SF of 2xSF2+2xSF4, the recommended
{Reference E-TFCI; Reference Power Offset} table is as follows.
ReferenceEtfciConfList
referenceEtfci
referenceEtfciPowerOffset
13
14
58
15
91
18
98
21
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 36/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
referenceEtfci
referenceEtfciPowerOffset
10
13
25
17
Type of board (iCEM or xCEM) handling E-DCH for the E-DCH serving cell
(known by E-DPDCH SF capability of the E-DCH serving cell).
Remark: The reason why cell E-DPDCH SF capability is taken into account in {Ref ETFCI; Ref PO} table selection mechanism is to make possible the use of a different
table for a cell served by an iCEM and a cell served by an xCEM. Indeed, the optimal
table is different for iCEM and xCEM. The RNC does not have the direct knowledge of
the type of board (iCEM or xCEM) serving a given cell. However, the RNC has the
knowledge of the E-DPDCH SF capability of a given cell. Since the SF capability for
iCEM (2xSF4) is different than for the xCEM (2xSF2), by looking at the SF capability
of a given cell the RNC can know the type of board that serves it.
U
In UA5, at the establishment of an E-DCH call, the requested UL service (e.g. E-DCH
stand-alone or E-DCH + CS AMR NB) is not taken into account in {Reference E-TFCI;
Reference Power Offset} table selection mechanism. In UA6, an enhancement has
been brought to {Ref E-TFCI; Ref PO} table selection mechanism, which consists into
taking into account the requested UL service (as well as HSUPA UE Category and
type of board handling E-DCH for the E-DCH serving cell). This is achieved by using
multiple EdpchInfoClass instances, as shown in Figure 6. In addition, in UA6, the
requested type of E-DCH TTI (i.e. 10ms or 2ms) is also taken into account in the table
selection mechanism.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 37/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
EdpchInfoClass
EdpchParameters
ReferenceEtfciConfList
UlUserService
UlRbSetConf
DedicatedConf
EdchTfcConf
EdchUserService
EdchParameters
EdchCellClass
ReferenceEtfciConfList
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 38/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
SF64
SF32
SF16
SF8
SF4
2xSF4
2xSF2
2xSF2+2xSF4
Table 8: Primary Cell HSUPA Category according to Primary Cell EDPDCH SF capability and selected E-DCH TTI
Remarks:
U
Value 16 for Primary Cell HSUPA Category is a special value, used so that
Target HSUPA UE Category is not driven by Primary Cell HSUPA Category in
Step 2 of EdpchParameters instance selection algorithm (see Step 2 below).
For the case where the Primary Cell E-DPDCH SF Capability reported by the
NodeB is 2xSF2+2xSF4 but with isSrbOnEdchAllowedWhenTrbOnEdch
parameter set to False (i.e. UA6 33581 SRB on E-DCH during Call disabled),
the Primary Cell E-DPDCH SF Capability used in the {Ref E-TFCI; Ref PO} table
selection mechanism (in Step 1 of EdpchPararmeters instance selection
algorithm) is forced to 2xSF2.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 39/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Target HSUPA
UE Category
1
2
3
4
5
6
Set iCEM recommended table (Table 3) for the following EdpchParameters instances:
UECategory1EdchTti10ms
UECategory2EdchTti10ms
UECategory3EdchTti10ms
Set xCEM/10ms TTI recommended table (Table 4) for the following EdpchParameters
instances:
UECategory4EdchTti10ms
UECategory5EdchTti10ms
UECategory6EdchTti10ms
Set xCEM/2ms TTI/2xSF2 recommended table (Table 5) for the following EdpchParameters
instances:
UECategory2EdchTti2ms
UECategory4EdchTti2ms
[UCU-III]
For all EdpchInfoClass instances, set UCU-III recommended table (Table 7) for all
EdpchParameters instances.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 40/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
/PS_EDCHxSRB_EDCH),
the
EdpchInfoClass instance is reselected accordingly. Then E-DCH call attributes
are reconfigured (both at UE side and NodeB side). The reconfiguration is done
towards Node B via NBAP Radio Link Reconfiguration and towards UE via Radio
Bearer Reconfiguration procedures.
isEdchFpBundlingModeForEdchTti2msAllowed
Boolean (True, False)
Customer
3
False
Object
NodebConfClass
Granularity
NodebConfClass
Restriction: In UA06, for E-DCH configured with TTI of 2ms, xCEM only supports unbundling
mode, which consists in NodeB sending E-DCH FP Data Frame every 2ms
The parameter isEdchFpBundlingModeForEdchTti2msAllowed must be set to False.
Page 41/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
5.6 MISCELLANEOUS
POWER OFFSET FOR SCHEDULING INFO
As explained above in 5.4, Power Offsets (i.e. E-DPDCH/UL DPCCH power ratio, also
referred as ed/c), are configured via the {Reference E-TFCI; Reference Power
Offset} table. However, for the specific case of a MAC-e PDU with stand-alone
Scheduling Information (SI) field (i.e. no user data transmitted), a specific Power
Offset value is applied instead of the value specified by the table (according to 3GPP
TS 25.331 [R09], see Power Offset for Scheduling Info IE). The value in dB for this
specific Power Offset is set via powerOffsetForSchedInfo parameter.
X
[iCEM] [xCEM]
The following parameter is used for 10ms TTI:
Parameter
Range & Unit
User
Class
Value
powerOffsetForSchedInfo
Integer [0 6], dB
Customer
3
6
Object
EdchCellClass
Granularity
EdchCellClass
powerOffsetForSchedInfoEdchTti2ms
Integer [0 6], dB
Customer
3
3
Object
EdchCellClass
Granularity
EdchCellClass
[UCU-III]
Parameter
Range & Unit
User
Class
Value
powerOffsetForSchedInfo
Integer [0 6], dB
Customer
3
0
Object
EdchCellClass
Granularity
EdchCellClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 42/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
On the other hand, PLnon-max value is not specified by 3GPP. In UA5, PLnon-max value
could not be modified by the customer (hard-coded parameter). In UA6, PLnon-max
value can be set via plNonMax parameter under EdpchParameters.
B
plNonMax: Used to set the value of PLnon-max. plNonMax parameter value must be
specified as plNonMax = 25 * PLnon-max .
B
Parameter
Range & Unit
User
Class
Value
plNonMax
Integer [11 25], 25 * PLnon-max
Customer
3
EdpchParameters instance
Object
EdpchParameters
Granularity
RNC
UECategory1EdchTti10ms
[iCEM] [xCEM] 25
(corresponds to PLnon-max = 1)
plNonMax value
UECategory2EdchTti10ms
UECategory3EdchTti10ms
[UCU-III] 18
(corresponds to PLnon-max = 0.72)
B
UECategory4EdchTti10ms
18 (corresponds to PLnon-max = 0.72)
UECategory5EdchTti10ms
UECategory6EdchTti10ms
UECategory2EdchTti2ms
UECategory4EdchTti2ms
UECategory6EdchTti2ms
Remark: Similarly to {Reference E-TFCI; Reference Power Offset} table, the PLnon-max
value used for a given UE is selected according to type of board handling E-DCH for
the E-DCH serving cell, HSUPA UE Category, E-DCH TTI type and UL service.
U
Two ILPC algorithms are defined by the 3GPP standard: the Algo1 and the Algo2. The
Algo1 is the Alcatel-Lucent recommended algorithm for all cases, except for
UeCategory4 TTI2ms and UeCategory6 TTI2ms calls. For these EDCH calls, the
Algo2 is the most suitable: it ensures stable performance because it is less reactive to
power variations (TPC rate is 300 command/s with algo2 while it is 1500 commands/s
with algo1).
The granularity of the parameter powerCtrlAlgo (refer to UPUG Vol.9 for further
details regarding this parameter) is the group of cells, not the type of calls, hence it
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 43/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note the 2nd byte and 3rd byte are also used, respectively to control the execution time
of the reconfiguration from cell_DCH to Cell_FACH (refer to UPUG Vol.11 for further
details) and to differentiate US Market RNC from Global Market RNC.
P
bit number
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
Reserved0
The bit 24 and the bit 25 are used to select the UL ILPC algo2 for EDCH UeCategory4
call and UeCategory6 call, when it is in TTI2ms cell:
Reserved0 bit 24: SRB UL ILPC algorithm selection for UeCategory4 call
when it is in TTI2ms cell
o
Reserved0 bit 25: SRB UL ILPC algorithm selection for UeCategory6 call
when it is in TTI2ms cell
o
Parameter
Range & Unit
Reserved0 bit 24
Bit: 0 or 1 Kind of Boolean
Object
RadioAccessService
User
Class
Value
Customer
3-a2
1
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 44/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Reserved0 bit 25
Bit: 0 or 1 Kind of Boolean
Object
RadioAccessService
User
Class
Value
Customer
3-a2
1
Granularity
RNC
Rule: UL ILPC Algo2 must be used for EDCH UECategory4 call and EDCH UECategory6 call
when the cell is TTI2ms
In order to force the use of UL ILPC Algo2 for EDCH UeCategory4 call and EDCH UECategory6 call,
when the cell is TTI2ms, the bit 24 and the bit 25 of the parameter Reserved0 must be set to 1.
Note that the bit 24 and the bit 25 have no effect when the cell is TTI10ms: in this case the UL ILPC
Algo1 is used regardless of their values.
Value
Meaning
1 byte is 0x00: refer to the section 10.1 in Vol4.
2nd byte is 0x05: refer to the UA6 UPUG [R01], Vol.11
3rd byte is 0x00: used to easily identify a Global Market RNC
4th byte is 0x03: UL ILPC Algo2 is used for UeCategory4 TTI2ms calls
and for UeCategory6 TTI2ms calls.
1st byte is 0x07: refer to the section 10.1 in Vol4.
2nd byte is 0x12: refer to the UA6 UPUG [R01], Vol.11
3rd byte is 0x01: used to easily identify a US Market RNC
4th byte is 0x00: The default UL ILPC Algo1 is used (anyway, the 4th byte
is ignored because TTI 2ms is not supported on UCU-III.)
st
P
Global
Market
50332928
US Market
70151
The UE applies the E-DCH Mac-d Flow Power Offset on top of transport block size
specific power offset when actually transmitting data on E-DPDCHs. In UA6.0, the EDCH Mac-d Flow Power Offset is configurable per EDCH RB (typically an E-DCH
Mac-d Flow Power Offset is configurable for PS_EDCH RB and another one is
configurable for SRB_EDCH).
Both UE and Nodeb use the E-DCH Mac-d Flow Power Offset for the calculation of
the TPR (Traffic to Pilot power Ratio), according to the formula in 3GPP TS 25.214
[R12], section 5.1.2.5B.2.
X
Page 45/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchMacdPowerOffsetEdchTti10:
The
recommended
value
for
edchMacdPowerOffsetEdchTti10 is 0.
Parameter
Range & Unit
User
Class
Value
edchMacdPowerOffsetEdchTti10
Object
EdchParameters
Granularity
UlRbSetConf
[0..6] step:1
Customer
0
0
[XCEM] edchMacdPowerOffsetEdchTti2: when the E-DCH TTI is 2ms, two EDCH Mac-d flows may be established (the one bearing the PS EDCH, and
potentially the one bearing the SRB EDCH), so it might be useful to specify an
offset for each Mac-d flow in order to get different probability of retransmission.
Parameter
Range & Unit
User
Class
Value
edchMacdPowerOffsetEdchTti2
Object
EdchParameters
Granularity
UlRbSetConf
[0..6] step:1
Customer
0
For UlRbSetConf PS_EDCH: 0
For UlRbSetConf SRB_EDCH: 0
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 46/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The scheduler will then allocate new E-TFCI based on the updated prediction function.
Two new parameters are introduced to activate and configure the UL load fine
prediction.
rotPredictionCorrection
Object
EdchConf
Granularity
BTS
Off, On
Customer
3
ON
rotMarginPrediction
Object
EdchConf
Granularity
BTS
[0..10]
Customer
3
5
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 47/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Derivation, every 24 hours, of the thermal noise level (RTWPref) at the BTS, via
thermal noise level self-learning algorithm (c.f. section 4.1.1), basing on
measurements at the BTS
B
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.
FEATURE DESCRIPTION
Remark: UA5.1 34221 feature applies only to the iCEM board.
U
Actually, for channel profiles with large delay spread, orthogonality between the
different UL codes of a same user is not perfect. In other words, when focusing on a
given UL code (e.g. the DPCCH) of a user, some part of the energy of other UL codes
(e.g. E-DPDCHs) of the same user is seen as interference.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 48/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Restriction: RTWPnon E-DCH sent to the RNC does not benefit from UA5.1/iCEM 34221 feature
B
The improvement on the accuracy of the estimation of current total UL load brought by 34221 is only
used by the MAC-e scheduler in the NodeB. The quantity RTWPnon E-DCH sent every 100ms from the
NodeB to the RNC via NBAP does not benefit from this improvement.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 49/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
rotOrthogonalityEstimation
Enum {Off, On}, N/A
Customer
3
On
Object
EdchConf
Granularity
BTSCell
rtwpTimeDetection
RoT
ALARM
rtwpMargin
totalRoTMax
OK
OK
Time
Figure 8: RTWP exceeding margin
Parameter
Range & Unit
User
Class
Value
rtwpMargin
Object
BTSCell
Granularity
Cell
[0.5..2.0] step:0.5 dB
Customer
3
2 dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 50/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
rtwpTimeDetection
Object
BTSCell
Granularity
Cell
[100..400] step:100 ms
Customer
3
400 ms
Index
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 51/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Happy bit: this bit is transmitted on the E-DPCCH and represents the UE
state according to his current max grant notification.
The resulting maximum grant allocation is the minimum of all grant allocations
provided by each of the step described above and is sent on one E-AGCH (RNTI and
Grant info).
Parameter
Range & Unit
User
Class
Value
Parameter
Range & Unit
User
Class
Value
happyBitDelay
Object
EdchCellClass
Granularity
RNC,
EdchCellClass
Customer
3
50
happyBitDelayEdchTti2ms
Object
EdchCellClass
Granularity
EdchCellClass
Customer
3
10
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 52/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
edchSchedulerAlgorithm
Enum {roundRobinSlidingWindow, rateScheduling}
Customer
Granularity
3
rateScheduling
BTSEquipment
Cell
In UA6/iCEM, with Rate Scheduling, all E-DCH active users (having data to transmit)
are transmitting (having grants) simultaneously. They share resources in a fair way
and the general principle being that:
hardware resources are shared equally between all active cells (containing at
least one active user)
hardware resources assigned to an active cell are shared equally between all
active users of this cell
the cell load (apart from R99 part) is shared equally between all active users
of this cell
the number of active user changes (one becomes active or one becomes
inactive)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 53/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Periodically, each T_Threshold_TTI (100ms) for UEs that are granted above
the fairness index. In UA5.1 this timer is accessible via OMC and can be
modified by the customer. The new parameter name in UA5.1 is
edchRateSchedulerOptimisationTimer.
Parameter
Range & Unit
User
Class
Value
edchRateSchedulerOptimisationTimer
[10..50] step 4. Unit=TTI
Customer
3
10
Object
BTSEquipment
Granularity
BTS
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 54/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UA5.0
UA5.1
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 55/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
siActivityTimer (iCEM-specific)
Integer [8 48] (step: 4). TTI.
Customer
3
12
Object
BTSEquipment
Granularity
BTSEquipment
Rule: siActivityTimer
The siActivityTimer should be set according to the following rule:
siActivityTimer*TTI > max(periodicityOfSchedInfoNoGrant, periodicityOfSchedInfoGrant).
Lowest Priority
Scheduling Priority
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Prio_Level_Gold
Prio_Level_Silver
Prio_Level_Bronze
Prio_Level_Other
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 56/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchSpiRelativeWeight
Object
EdchConf
[1..16][0..100]
Customer
Granularity
BTSCell
0
100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100
OAM must check after reception of this table the following items:
-
[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS. Please refer to
section 11 for details.
edchSpi: For each E-DCH call, the Core Network provides in RANAP RAB
Assignment message the following QoS attributes: Traffic Class, ARP (Allocation
Retention Priority), THP (Traffic Handling Priority). edchSpi parameter, which is
located under RadioAccessService TrafficClassBasedQos ArpBasedQos
ThpBasedQos, is used to assign to each {Traffic Class, ARP, THP} combination an
E-DCH SPI (Scheduling Priority Indicator). edchSpi parameter is used in the same
way for iCEM, xCEM and UCU-III cases.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 57/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchSpi
[0 15]
Customer
3
Value
Object
ThpBasedQos
Granularity
RNC,
TrafficClassBasedQos,
ArpBasedQos,
ThpBasedQos
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 58/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RNC
HSUPA Throughput
Node B
TNL congestion notification to NodeB
Iub
HSUPA BW limitation by Node B
This
feature
can
be
activated/deactivated
at
isEdchBandwidthlimitationAllowed under BTSEquipment.
Parameter
Range & Unit
User
Class
Value
NodeB
isedchBandwidthlimitationAllowed
False,True
Customer
3
True
level
via
the
flag
Object
BTSEquipment
Granularity
BTSEquipment
The NB includes a FSN in every E-DCH Data Frame. If FSNn > FSNn-1+1, P frames
are missing and might be lost, but it could also be due to IP de-sequencing issue.
B
Page 59/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note that only one timer is running; when this timer runs, no frame loss can be
detected for the succeeding frames, this is simpler and it is not felt as a critical issue,
the main point being to avoid wrong frame loss detection.
If at least one frame is missing at the expiry of the timer, then the MAC-d flow is
marked as congested frame loss, the FSNn is assigned with the last received frame,
and the nominal algorithm is resumed.
B
Parameter
Range & Unit
User
Class
Value
nFramesBeforeEdchCongestion
0..255
Customer
NA
1
Object
RNC INode
Granularity
Inode
Parameter
Range & Unit
User
Class
Value
deSequencingWaitTimer
0..100
Customer
NA
0
Object
RNC INode
Granularity
Inode
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 60/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
algorithm
uses
parameter
nFramesBeforeEdchDeCongestion
0..255
Customer
NA
50
Object
RNC INode
Granularity
Inode
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 61/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
congestionControlPeriod
0..2550 in step of 10ms
Customer
NA
40
Object
RNC INode
Granularity
Inode
When a congested Mac-d flow becomes non-congested, the RNC sends one TNL
Congestion indication message with cause No TNL Congestion.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 62/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range & Unit
User
Class
Value
edchBLSupervisionTimer
10..1000 in step of 10ms
Customer
3
80
Object
BTSEquipment
Granularity
BTS
Parameter
Range & Unit
User
Class
Value
edchBLStepReductionFrameLoss
0..100 in %
Customer
3
1
Object
BTSEquipment
Granularity
BTS
Parameter
Range & Unit
User
Class
Value
edchBLStepIncrease
0..100 in %
Customer
3
1
Object
BTSEquipment
Granularity
BTS
The iCEM scheduler reduces the UL codec limitation by GRF where the codec
limitation is calculated as follow
CDC_size_Max = min(2.1Mbps,edchBLIubBandwidth)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 63/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UE status: UE category, SI
From these inputs the scheduler will derive the scheduling grants. Overload
management as well as AG and RG sending is described below.
[UCU-III]
For OneBTS there is no man-made restriction of the E-DCH processing
resources possible.
- The Maximum Target Received Total Wide Band Power is sent over
NBAP in PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message. It
is derived from OMC-R parameters FDDCelltotalRotMax and
FDDCellrtwpReference. RTWPref will be adjusted according to selflearned RTWP value in the NodeB, as well as the resulting RoT.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 64/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The following parameters (except the first one which is xCEM only) are common to
iCEM, xCEM and UCU-III (please refer to section 4.1.1 for further details).
X
Parameter
Range & Unit
User
Class
Value
edchMaxThroughputXcem
[480..7680] step:480 kbps
Customer
3
7680
Object
Parameter
Range & Unit
User
Class
Value
isRtwpReferenceSelfLearning
Object
BTSEquipment
Granularity
Cell
Parameter
Range & Unit
User
Class
Value
Parameter
Range & Unit
User
Class
Value
BTSEquipment
Granularity
HsXpaResource
TU
UT
False, True
Customer
3
True
Object
BTSCell
Customer
3
-106.1
Granularity
Cell
totalRotMax
[0..20] step:0.1 (db)
Customer
2
R99+HSPA shared carrier: 6
HSPA dedicated carrier: 8
Object
FDDCell
Granularity
Cell
rtwpReference
[-115.0..-50.0] step:0.1 dBm
Measurements
- RTWP is reported every 100ms to the MAC-e scheduler.
[UCU-III]
Every 2ms for OneBTS.
- [xCEM][UCU-III], estimates every 10ms the average total UL load LE-DCH
generated by E-DCH serving users, non-serving users and peer-serving
users.
B
- The total UL load (E-DCH or not) Ltotal is also generated according to RTWP
measurements allowing to derive the Lnon E-DCH = Ltotal LE-DCH.
B
[UCU-III]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 65/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
- The available E-DCH load is then derived and corresponds to Lavailable, E-DCH =
Ltarget - Lnon E-DCH. If Lavailable, E-DCH <= 0, then the cell is overloaded.
B
UE specific information
- Happy bit status
- Scheduling information
- Reference scheduling grant SGref, i, taken from previous scheduling interval
B
[xCEM]
If an SI is received while UE is not granted, the MAC-e scheduler assumes for initial
grant computation that TBrequested = TB(EdchconfedchInitialTBIndexXxx).
edchInitialTBIndex10msTTI and edchInitialTBIndex2msTTI parameters are used to
set the E-TFCI to be used for initial grant sent to UE via AG command.
B
[iCEM]
Regarding iBTS, edchInitialTBIndexXxx parameters are taken into account by the
system only if the board handling the E-DCH call is an xCEM. As explained in 5.4, for
iBTS, RNC detects the type of board handling E-DCH traffic for the considered cell via
the E-DPDCH SF capability of the considered cell.
X
Page 66/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The requested TB is converted to a target grant SGtarget, i for each UE i and the total
UL load Lhypothetical is computed. If Lhypothetical <= Lavailable, all the requests can be fulfilled
and the MAC-e scheduler proceeds with AG and/or RG sending.
B
Object
EdchConf
Customer
0
52
Granularity
BTSCell
edchInitialTBIndex2msTTI
Object
EdchConf
Granularity
BTSCell
edchInitialTBIndex10msTTI
[0..127] step 1
Parameter
Range & Unit
User
Class
Value
[0..127] step 1
Customer
0
8
Hypothetical overload
The MAC-e scheduler first check if the interference created by non-serving UEs
compared to the total E-DCH interference is smaller than or equal to Target Nonserving E-DCH to Total E-DCH Power Ratio set by RNC. If this is not the case, the
MAC-e scheduler shall first reduce non-serving UEs by sending DOWN command.
The MAC-e scheduler shall also check whether the interference created by the peerserving RL is smaller than or equal to EdchconfedchSofterHoLimit (see Vol.6 for
details regarding this parameter) threshold. If this is not the case, the MAC-e
scheduler shall further reduce the peer-serving RLs by sending DOWN command.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 67/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
E-DCH Minimum Set E-TFCI value is set via edchMinSetEtfci parameter under
EdpchParameters.
Parameter
Range & Unit
User
Class
Value
edchMinSetEtfci
Object
EdpchParameters
[0..127] step:1
Customer
Granularity
0
EdpchParameters instances related to 10ms TTI: 7
EdpchParameters instances related to 2ms TTI: 3
EdpchInfoClass
MAC-e scheduler de-grants all the UEs and sends RG = DOWN command.
Note that the parameters rtwpMargin and rtwpTimeDetection are not used for xCEM
overload algorithm.
The xCEM overload algorithm is trigged when the average non E-DCH load, estimated
based on the last received RTWP measurement, is higher than the E-DCH Max load
corresponding to RoT_max setting.
isEdchSchedulingInfoReportingAllowed
False,True
Customer
3
True
Object
EdchParameters
Granularity
UlRbSetConf
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 68/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isEdchSchedulingInfoReportingEdchTti2msAllowed
False,True
Object
EdchParameters
Customer
3
True
Granularity
UlRbSetConf
The two following parameters are common to iCEM and xCEM. However, the
siActivityTimer is specific to iCEM. The xCEM has an equivalent parameter called
edchInactivityTimerXcem.
Parameter
Range & Unit
User
Class
Value
edchInactivityTimerXcem
[0..20000ms] step 40
Customer
3
1440
Object
EdchConf
Granularity
BTScell
Object
EdchCellClass
Granularity
EdchCellClass
periodicityOfSchedInfoGrant
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50
Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoGrant.
U
Parameter
Range & Unit
User
Class
Value
periodicityOfSchedInfoGrantEdchTti2ms
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50
Object
EdchCellClass
Granularity
EdchCellClass
Object
EdchCellClass
Granularity
EdchCellClass
periodicityOfSchedInfoNoGrant
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50
Remark: OneBTS has the same table shown above, but a default value of 100 ms for
periodicityOfSchedInfoNoGrant.
U
Parameter
Range & Unit
User
Class
Value
periodicityOfSchedInfoNoGrantEdchTti2ms
EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000
Customer
3
50
Object
EdchCellClass
Granularity
EdchCellClass
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 69/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
After reception of SI trigger, AG is sent with the next valid value with AG >=
SGtarget.
B
ergch2IndexStepThreshold
[0..37] step 1
Customer
0
20
Object
EdpchParameters
Granularity
RNC
Parameter
Range & Unit
User
Class
Value
ergch3IndexStepThreshold
[0..37] step 1
Customer
0
16
Object
EdpchParameters
Granularity
RNC
[UCU-III]
The ergch2IndexStepThreshold and ergch3IndexStepThreshold have to be set
different for OneBTS for UA06. They have to be aligned with the used reference ETFCI and reference power offset settings. Our recommendation is:
ergch2IndexStepThreshold=18, ergch3IndexStepThreshold=15
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 70/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Lowest Priority
Scheduling Priority
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Prio_Level_Gold
Prio_Level_Silver
Prio_Level_Bronze
Prio_Level_Other
Page 71/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
EdchServiceParameterSet
Customer
3
40 (default value)
Granularity
BTSCell
serviceMaxRate
Object
EdchServiceParameterSet
Customer
3
300 (default value)
Granularity
BTSCell
serviceBfactor
Object
EdchServiceParameterSet
Customer
3
7 (default value)
Granularity
BTSCell
serviceKfactor
Object
EdchServiceParameterSet
serviceMinRate
[0..10000]
Parameter
Range & Unit
User
Class
Value
[0..10000]
Parameter
Range & Unit
User
Class
Value
[1..30]
Parameter
Range & Unit
User
Class
Value
Remark:
U
[1..30]
Customer
Granularity
BTSCell
3
7 (default value)
This mode can be disabled by setting the serviceBfactor equal to 1 for all the SPI.
edchSpiRelativeWeight
Object
EdchConf
[1..16][0..100]
Customer
Granularity
BTSCell
0
100,100,100,100, 100,100,100,100, 100,100,100,100, 100,100,100,100
(default value)
Remark: This mode can be disabled by setting all the weight values equal to 100.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 72/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Regarding edchSpi parameter, please see section 6.7 for a detailed description.
X
[UCU-III]
The parameter edchSpiRelativeWeight is not used for oneBTS. Please refer to
section 11 for details.
maxMacePduContentsSizeForNonScheduledMode
Object
EdchParameters
Granularity
UlRbSetConf
[1..1096]
Customer
3
162
The non scheduled mode is only used when the SRB over edch is activated.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 73/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isSrbOnEdchAllowedWhenTrbOnEdch
True,False
Customer
3
True
Object
RadioAccessService
Granularity
RNC
For a correct functioning of this feature it is necessary the interaction with feature
HSPA congestion detection & notification (33367).
The Iub congestion detection and reporting are common to both xCEM and iCEM.
HSUPA Throughput
RNC
Node B
TNL congestion notification to NodeB
Iub
HSUPA BW limitation by Node B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 74/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The same parameters are applicable for both iCEM and xCEM boards (refer to 6.8.3).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 75/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
EDCH throughput will be progressively increased on xCEM when the iBTS did not
detect any AAL2 cells lost in uplink for a minimum period of time.
As a result, features 33332 and 75786 can be managed at the same time.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 76/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Range
unit
Initial values
BtsEquipment
edchCMActivation
3
This parameter is used to activate the feature Local EDCH
Congestion Control in the BTS
When set to TRUE, the BTS control the EDCH throughput based on
ATM cell that are locally dropped in the BTS
When set to FALSE, this feature is deactivated
Boolean (True, false)
None
False
Remark: The feature is managed the same way in all cases when user plan for EDCH
is managed on ATM external AAL2 VCC, i.e:
U
[iCEM]
This feature is not applicable.
[UCU-III]
This feature is not applicable, but a similar mechanism can be achieved based on the
Iub Overload Control. The only difference is the generation of the Iub overload
indicator which is done by means of ATM queue fill levels.
The Node B periodically informs the MAC-e scheduler about the Iub status. A
congestion event is reported if the low priority UL queue size (at AAL2 PVC level, ATM
Adaptation Layer 2 Permanent Virtual Circuit) crosses a certain HIGH threshold
(tunable @ NodeB) and the PVC is not in congested state. A congestion release event
is reported if the queue size crosses a LOW threshold (tunable @ NodeB) and the
PVC is not in uncongested state.
.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 77/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 78/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In UA5.0, the UL OLPC algorithm was not handling E-DCH specifically. Indeed, the
link quality of the E-DCH transport channel was not monitored and thus not taken into
account in the UL OLPC. In UA5.0, for E-DCH calls, it was possible though to benefit
from UL OLPC, by performing UL OLPC basing on the link quality of the non-E-DCH
transport channel(s) established. However due to some auto-interference and RSSI
divergence problems, in UA5.0 it was recommended to disable the UL OLPC for EDCH calls, by setting minSirTarget and maxSirTarget to the same value for the UL
services that include an E-DCH RB.
For E-DCH, the principle of UL OLPC is similar, but the quality criterion for adjusting
the UL SIR Target is different. For E-DCH, the quality criterion for adjusting the UL
SIR Target is the measured number of HARQ retransmissions on the E-DCH channel.
The RNC adjusts the UL SIR Target so that the average number of HARQ
retransmissions converges toward a target number of HARQ retransmissions (refered
as NHARQ Target below in this document). The RNC knows the actual number of
HARQ retransmissions that was necessary for decoding a given MAC-e PDU at
NodeB, thanks to a specific Information Element N of HARQ Retransmissions sent
by the NodeB through Iub FP. The N of HARQ Retransmissions IE is enclosed in each
E-DCH UL Data Frame sent by NodeB to RNC over Iub.
B
In UA5.1, this UL OLPC algorithm newly capable of taking into account E-DCH link
quality was introduced via UA5.1 34172 E-DPDCH Retransmissions for DPCCH SIR
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 79/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Simulations results showed that, for a given cell, the optimal NHARQ Target value
depends on the number of E-DCH active UEs in the cell and the total UL radio load. In
UA6, E-DCH UL OLPC is improved by introducing an adaptive target number of
HARQ retransmissions, via UA6 34249 EUL Capacity Optimized HARQ Operation
feature.
B
SIR Target
NodeB 1
UL OLPC Master
NodeB 2
Partial
SIR Target
Partial
SIR Target
Partial
SIR Target
UL OLPC
Machine
UL OLPC
Machine
UL OLPC
Machine
CRCI of UL
DCH 1
CRCI of UL
DCH 2
(DCH 1)
(DCH 1)
(DCH 2)
(DCH 2)
(E-DCH)
(E-DCH)
Else:
SIR Tg = min { Partial SIR Targets }
Update triggering:
Periodically
On event, i.e. if 1 Partial SIR Tg
increased more than a threshold
since previous update.
N of HARQ
Radio quality on E-DCH taken
Retransmissions IE
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 80/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In UA5.0 and early UA5.1/iCEM, for stand-alone E-DCH calls (i.e. E-DCH + SRB in
uplink, no multi-service), the format used for the UL SRB for the SRB inactivity periods
(i.e. no signaling data transmitted) was TF1x0 (i.e. transport format that forces the
transmission of a CRC even when there is no signaling data to transmit), instead of
the usual TF0x148 format. This allowed continuous monitoring of the radio quality
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 81/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
For above reasons, effective from UA5.1.0.3, it has been decided to remove SRB
TF1x0 for stand-alone E-DCH calls (i.e. E-DCH + SRB in uplink, no multi-service), and
use instead the usual TF0x148 format. Then, as a consequence, for a stand-alone EDCH call in uplink (i.e. no voice or video telephony in parallel), it is not possible to
monitor continuously the radio quality when there is no activity on E-DCH, which
means that UL SIR Target almost stays at the level it was when activity on E-DCH
stopped. Test showed that this allows improving E-DCH radio quality for the case of
sporadic UL traffic (e.g. UL pings).
With:
ulSirStep: Parameter that impacts the amplitude of each change in the Partial
UL SIR Target associated to the E-DCH transport channel.
Remark: ulSirStep is different from ulUpSirStep parameter, which is used for
the derivation of Partial UL SIR Target associated to transport channels of
DCH type. The formula giving Partial UL SIR Target is different for DCH.
Please refer to UA6 UPUG [R01], Vol.9, section 2.3.4 for the formula giving
Partial UL SIR Target for the DCH case.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 82/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In UA5.1, when an HARQ Failure Indication (see 3GPP TS 25.427 [R07] for
detailed information on the different cases of E-DCH HFI) is reported by the EDCH Serving NodeB, NHARQ was taken equal to the maximum allowed number
of HARQ retransmissions.
HX
In UA6, when an HFI is reported by the E-DCH Serving NodeB (as of 3GPP,
only the E-DCH serving NodeB can send HFI messages), a specific correction
is applied to Partial UL SIR Target, i.e. above formula does not apply. See
section 9.1.2.2.3 for more information on HFI handling in E-DCH UL OLPC.
X
If at least the Partial SIR Target of one of the transport channels has
increased since previous update:
UL SIR Target = max{ Partial SIR Targets }
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 83/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Else:
UL SIR Target = min{ Partial SIR Targets }
The RNC sends the new UL SIR Target computed as explained above to NodeB(s)
each time there is an on event or periodical update. Note that regarding the periodical
updates, in UA5.x the UL SIR Target was sent to NodeB(s) only when it was different
from its previous value, whereas in UA6 the UL SIR Target is sent to NodeB(s) at
each periodical update regardless of the UL SIR Target value.
The key enhancements of UA6 34249 with respect to UA5.1 E-DCH UL OLPC (UA5.1
34172 feature) are as follows.
Due to the limited E-DCH decoding capacity of the iCEM board (i.e. 2.1Mbps @MAC-e), in case of
multiple E-DCH UEs per cell, E-DCH user throughput is rather limited by board E-DCH decoding
capacity than available UL radio load. In case of multiple E-DCH UEs per cell, lab tests showed that
targeting a higher number of HARQ retransmissions is useless and may even degrade
performance.
Hence, when E-DCH is handled by an iCEM, NHARQ Target is not adapted according to current
number of active E-DCH users and UL Radio Load Color. Precisely, adaptive NHARQ Target
mechanism is disabled by always forcing Cell State is to S1 (see section 9.1.2.2.2 for details on
adaptive NHARQ Target mechanism). This can be done by using an hard-coded parameter:
cellrrm_c[0].data.spare[0] = 1. (RNC rebuilt is necessary)
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 84/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Both 10ms and 2ms E-DCH TTI (2ms E-DCH TTI introduced in UA6
for the xCEM)
Cell State, which can take three different values S1, S2 and S3, is computed basing
on the following inputs:
Below figure shows how Cell State is determined according to the current number of
active E-DCH users and UL Radio Load Color of the cell. Note that maxNumActiveEdchUsersPerCellForS1 and maxNumActiveEdchUsersPerCellForS2 parameters
are used to set the thresholds for Cell State change on number of active E-DCH
users criterion.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 85/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
S3
maxNumActiveEdchUsersPerCellForS2
S2
maxNumActiveEdchUsersPerCellForS1
S1
0
green
UL Radio
Load Color
yellow
red
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 86/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In case of SRB on E-DCH, two MAC-d flows are carried on E-DCH: the UL SRB MACd flow, and the UL TRB MAC-d flow. Regarding the UL OLPC, two UL OLPC
Machines are built for E-DCH. Each one of the two UL OLPC Machines computes
separately the Partial SIR Target related to the MAC-d flow it is related to. This is
shown in below figure.
SIR Target
NodeB 1
UL OLPC Master
NodeB 1
Partial
SIR Target
Partial
SIR Target
UL OLPC
Machine
UL OLPC
Machine
(E-DCH SRB)
(E-DCH SRB)
N of HARQ
Retransmissions IE
(E-DCH TRB)
(E-DCH TRB)
N of HARQ
Retransmissions IE
Note that for the case of SRB on E-DCH, there are two sets of
nHarqRetransTargetSx parameters, one for the SRB and one for the TRB MAC-d
flow, thus making it possible to set the target number of HARQ retransmissions NHARQ
Target for each Cell State separately for the SRB and for the TRB MAC-d flow.
B
In order to guarantee good link quality for the UL SRB, for the SRB MAC-d flow it is
recommended to set NHARQ Target to a low and same value for all Cell States (see
section 9.1.2.3.3 for more details on this recommendation).
B
Page 87/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Periodically, basing on HFI messages received from the E-DCH serving NodeB
and the E-DCH Data Frames correctly received from the serving and non-serving
NodeB(s) during the last HFI monitoring period), an HFI Reception Scenario is
determined among 4 possible scenarios HFI 0, HFI 1, HFI 2 and HFI 3.
Remark: As of 3GPP (see TS 25.427 [R07]), only the E-DCH serving NodeB can
report HFI messages to the RNC.
U
During the HFI monitoring period, the following internal counters are incremented:
Nb HFI frames
At the end of the HFI monitoring period, the following two quantities are computed:
o
Below figure shows how HFI Reception Scenario is determined according to current
HFI Ratio and Serving Ratio quantities. Note that edchOlpcServingRatioThreshold
and edchOlpcHfiRatioThreshold parameters are used to set the thresholds for HFI
Reception Scenario determination based on Serving Ratio criterion and HFI Ratio
criterion, respectively.
Serving Ratio
edchOlpcServingRatioThreshold
0
HFI 0
HFI 1
HFI 3
HFI 2
HFI Ratio
edchOlpcHfiRatioThreshold
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 88/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
When the UE is in E-DCH SHO (inter-NodeB SHO, not softer HO), at the end of each
HFI monitoring period, the Partial SIR Target related to the E-DCH transport channel
is updated. In case of SRB on E-DCH, the same correction is applied to both Partial
SIR Targets of SRB and TRB. The Partial SIR Target is updated as follows.
Partial UL SIR Target (k+1)
= Partial UL SIR Target (k) + edchSirStepHfi [HFI Reception Scenario]
With edchSirStepHfi being a parameter which contains a sequence of three values
selected according to the HFI Reception Scenario detected HFI 1, HFI 2 and HFI 3.
Note that HFI 0 corresponds to the normal E-DCH SHO scenario, i.e. only few or no
HFI are received from the serving NodeB, and in most cases when an HFI is received
the corresponding MAC-e PDU is not decoded by the non-serving NodeB(s).
When the UE is not in E-DCH SHO (but UE may be in E-DCH softer HO), at the end
of each HFI monitoring period, the Partial SIR Target is updated as in above formula,
but the correction applied is always taken equal to edchSirStepHfi [HFI 1], regardless
to the current HFI Reception Scenario.
Each time a consecutive MAC-e PDU is decoded by a non-serving NodeB but not
decoded by the serving NodeB (i.e. if the quality of the E-DCH radio link(s) of the
serving NodeB is poor compared to the quality of the E-DCH radio link(s) of nonserving NodeB(s)), internal counter Nb Consecutive Good Frames Not Received
on Serving NodeB is incremented.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 89/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In case of SRB on E-DCH, each one of the two MAC-d flows is treated
independently for counting consecutive MAC-e PDUs decoded by a non-serving
NodeB but not decoded by the serving NodeB
The conditions for E-DCH UL OLPC to be enabled (i.e. for the UL OLPC algorithm to
take into account radio quality of the E-DCH transport channel) are as follows.
For
UL
services
with
E-DCH,
isUlOuterPCActivated
(under
UlOuterLoopPowerCtrl object) must be set to True. Note that the
recommendation in UA6 UPUG [R01] is to set isUlOuterPCActivated to True
for all UL services (except SRB_CellFACH and TRBxSRB_CellFACH for which UL OLPC does
not apply).
X
For the UL services with E-DCH, the E-DCH transport channel must be set as a
reference channel for the driving of UL OLPC. This can be done by making sure
that an instance of ReferenceUlRbSetList with referenceUlRbSetConfId set to
UlRbSetConf/PS_EDCH exists for all UL services with E-DCH. If such instance
of ReferenceUlRbSetList does not exist, it must be created.
E-DCH UL OLPC can be disabled by following one of the two methods below.
Method 1 (UL OLPC active when in E-DCH call but E-DCH radio link quality not
taken into account):
U
For the UL services including an E-DCH UL RB, remove the E-DCH transport
channel from the list of reference transport channels driving the UL OLPC
algorithm.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 90/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UB
UB
In order to enable the ability to adapt the target number of HARQ retransmissions
NHARQ Target according to current number of E-DCH users and UL radio load, the
parameters
nHarqRetransTargetS1,
nHarqRetransTargetS2
and
nHarqRetransTargetS1 must be set to different values.
B
On the other hand, in order to disable the ability to adapt NHARQ Target according
to current number of E-DCH users and UL radio load, the parameters
nHarqRetransTargetS1, nHarqRetransTargetS2 and nHarqRetransTargetS1
must be set to the same value.
B
UlRbSetConf/
PS_EDCH
SRB_EDCH
DynamicParameterForEdchTti10ms
[iCEM] [xCEM]
DynamicParameterForEdchTti10ms object:
Only present under UlRbSetConf/PS_EDCH
DynamicParameterForEdchTti2ms
ulSirStep
updateThreshold
edchNrOfConsecutiveZeroHarqReTxThreshold
edchSirStepFastDecrease
edchOlpcHfiRatioThreshold
edchOlpcServingRatioThreshold
edchSirStepHfi
edchLinkBalanceThreshold
NHarqRetransTarget 3
NHarqRetransTarget 3
nHarqRetransTargetS1
nHarqRetransTargetS2
nHarqRetransTargetS3
3 instances of
NHarqRetransTarget object:
one instance per OLS.
Figure 21: UA6 34249 RAN model for PS_EDCH and SRB_EDCH UL RBs
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 91/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Other parameters
RNC
RNC
RadioAccessService
RadioAccessService
DedicatedConf
DedicatedConf
15
PowerConfClass
EdchCellClass
EdchRncConf
edchOlpcSamplingPeriodTti10ms
edchOlpcSamplingPeriodTti2ms
15
maxNumActiveEdchUsersPerCellForS1
maxNumActiveEdchUsersPerCellForS2
UlUsPowerConf/
UlUserService/
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K
initialSirTarget
minSirTarget
maxSirTarget
PS_EDCHxSRB_3_4K
PS_EDCHxSRB_EDCH
CS_AMR_NBxPS_EDCHxSRB_3_4K
UlOuterLoopPowerCtrl
isUlOuterPCActivated
ulUpdatePeriod
Figure 22: UA6 34249 RAN model for E-DCH UL services and misc.
ulSirStep
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
RNC, UlRbSetConf, E-DCH TTI type
Decimal [0.005 0.300] step: 0.005, dB
Customer, 3
Value
Object
Granularity
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 92/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
updateThreshold
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
RNC, UlRbSetConf, E-DCH TTI type
Integer [0 255], 0.1dB
Customer, 3
Value
Object
Granularity
edchNrOfConsecutiveZeroHarqReTxThreshold
Object
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity
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
Customer, 3
Value
-0.02
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 93/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchOlpcHfiRatioThreshold
Object
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity
Integer [0 100], %
Customer, 3
Value
Parameter
edchOlpcServingRatioThreshold
Object
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity
Integer [0 100], %
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
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 94/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchLinkBalanceThreshold
Object
DynamicParameterForEdchTti10ms
DynamicParameterForEdchTti2ms
Granularity
Customer, 3
Value
200
nHarqRetransTargetS1: NHARQ Target (i.e. target number of HARQ retransmissions)
value used for UL OLPC when Cell State = S1. In addition, for SRB on E-DCH case,
for the SRB MAC-d flow, NHARQ Target is always taken equal to
nHarqRetransTargetS1 (independently from current Cell State).
B
Parameter
nHarqRetransTargetS1
Object
NHarqRetransTarget
Granularity
Customer, 3
Value
For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.07
DynamicParameterForEdchTti2ms: 0.04
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04
nHarqRetransTargetS2: NHARQ Target value used for UL OLPC when Cell State = S2.
B
Parameter
nHarqRetransTargetS2
Object
NHarqRetransTarget
Granularity
Customer, 3
Value
For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.25
DynamicParameterForEdchTti2ms: 1.2
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 95/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
nHarqRetransTargetS3
Object
NHarqRetransTarget
Granularity
Customer, 3
Value
For UlRbSetConf/PS_EDCH:
DynamicParameterForEdchTti10ms: 0.85
DynamicParameterForEdchTti2ms: 1.5
For UlRbSetConf/SRB_EDCH:
DynamicParameterForEdchTti2ms: 0.04
Rule: nHarqRetransTargetSx
For each E-DCH TTI type, the target average number of HARQ retransmissions NHARQ Target
specified by nHarqRetransTargetSx parameters must be consistent with the maximum allowed
number of HARQ retransmissions set by edchHarqMaxRetransEdchTti10 (for 10ms E-DCH
TTI) and edchHarqMaxRetransEdchTti2 (for 2ms E-DCH TTI).
For each E-DCH TTI type, nHarqRetransTargetSx must be filled in with the same value for all
three instances of NHarqRetransTarget (there is one NHarqRetransTarget instance per OLS
Olympic Level Service).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 96/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isUlOuterPCActivated
Object
UlOuterLoopPowerCtrl
Granularity
RNC, UlUserService
Customer, 3
Value
ulUpdatePeriod
Object
UlOuterLoopPowerCtrl
Granularity
Range & Unit
RNC, UlUserService
Integer [0 255], N/A
Customer, 3
Value
Parameter
initialSirTarget
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 97/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
minSirTarget
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
Parameter
maxSirTarget
Object
UlUsPowerConf
Granularity
Range & Unit
PowerConfClass, UlUsPowerConf
Signed [-8.2 17.3] step: 0.1, dB
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 98/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
(Note: E-DCH UeCategory4 on TTI 2ms, an hard-coded offset of 2.6 dB is applied on top of the
configured maxSirTarget, leading to an actual maxSirTarget of 10.8 dB)
For UlUsPowerConf instance PS_EDCHxSRB_EDCH, it is recommended to set initialSirTarget
and maxSirTarget as follows.
(Note: E-DCH UeCategory6 on TTI 2ms and SRB over EDCH, an hard-coded offset of 2.1 dB is
applied on top of the configured maxSirTarget, leading to an actual maxSirTarget of 10.5 dB)
Configuration method:
U
Use two specific PowerConfClass instances (one for iCEM and one for xCEM).
For the PowerConfClass instance related to each type of board (iCEM and xCEM), set
initialSirTarget and maxSirTarget to above-specified values.
Make each cell (FDDCell object) point toward the appropriate PowerConfClass instance,
according to the type of board that handles E-DCH traffic for this cell.
Reason for using board-specific initialSirTarget and maxSirTarget values for E-DCH
calls:
U
The choice of using board-specific initialSirTarget and maxSirTarget values for EDCH calls is linked with the choice of using board-specific {Reference E-TFCI;
Reference Power Offset} tables. Please refer to section 5.4 for the reason for using
board-specific {Reference E-TFCI; Reference Power Offset} tables.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 99/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
maxNumActiveEdchUsersPerCellForS1
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 3
Value
2
maxNumActiveEdchUsersPerCellForS2: Maximum number of active E-DCH users
per cell for Cell State = S2.
Parameter
maxNumActiveEdchUsersPerCellForS2
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 3
Value
4
edchOlpcSamplingPeriodTti10ms: HFI monitoring period (for 10ms E-DCH TTI
case), i.e. period within which internal counters related to HFI reception are
incremented, and after which HFI Ratio and Serving Ratio quantities are computed.
Parameter
edchOlpcSamplingPeriodTti10ms
Object
EdchRncConf
Granularity
RNC
Customer, 3
Value
100
edchOlpcSamplingPeriodTti2ms: HFI monitoring period (for 2ms E-DCH TTI case).
Parameter
edchOlpcSamplingPeriodTti2ms
Object
EdchRncConf
Granularity
RNC
Customer, 3
Value
20
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 100/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
E-AGCH
Power control of E-AGCH channel is enabled and derived within the NodeB according
to the following formula.
PE DCH(k): E-DCH DL channels base power. This is a unique power value derived
within the xCEM according to the algorithm presented below; it is used as a base
for derivation of E-AGCH power (and also E-HICH and E-RGCH when power
control of those channels is enabled).
POE AGCH : Power offset of E-AGCH relative to E-DCH DL channels base power.
Can be set to the desired value via eagchPowerOffset under EdchConf (See
section 9.2.1.3 for a detailed description of this parameter).
E-HICH
Power control of E-HICH channel is enabled and derived within the NodeB according
to the following formula. As a reminder, E-RGCH and E-HICH commands share a
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 101/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
E-RGCH
Power control of E-RGCH channel is enabled and derived within the NodeB according
to the following formula.
E-DCH DL channels base power PE DCH(k), which is used as a base for derivation of EAGCH power, may be derived according to three different methods or a combination
of these methods. The three methods for the computation of E-DCH DL channels
base power are:
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 102/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The following formula gives the final expression of PE DCH(k). This formula reflects a
generalized approach that combines above three methods. The advantage of this
generalized approach is that it enables optimizing 33481 feature performance
according to the environment considered, through the appropriate choice of weighting
factors 1 and 2.
B
2
EDCH
Parameter
pMinDlEDCH
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
-25.0
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 103/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
pMaxDlEDCH
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
-15.0
eagchPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to E-DCH DL channels base power PE DCH(k).
U
Parameter
eagchPowerOffset
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to EHICH signature power of considered RL.
Remarks:
- For serving NodeB, only dedicated RG commands are used (at a given time, same
command is transmitted on all radio links).
- powerOffsetERGCHServingNoSHO applies to both E-DCH serving RL and E-DCH
non-serving RLs of serving NodeB (NoSHO has no specific meaning).
U
Parameter
powerOffsetERGCHServingNoSHO
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
1.5
For information, the following parameters are also present in the RAN Model, but
ignored by the system:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 104/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
eagchPowerOffset
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
4.00
Parameter
eagchPowerOffsetEdchTti2ms
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
4.00
Parameter
ergchPowerOffset
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
-4.00
Parameter
ergchPowerOffsetEdchTti2ms
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
-4.00
Parameter
ehichPowerOffset
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
-4.00
Parameter
ehichPowerOffsetEdchTti2ms
Object
EdchCellClass
Granularity
EdchCellClass
Customer, 0
Value
-4.00
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 105/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
New computation method for E-DCH DL channels base power PE-DCH (k)
In UA6, PE-DCH (k) computation is based either on one of following methods, or on a
combination of following methods:
- CQI received at NodeB (as in UA5.1)
- DL DPCH channel Tx power
- DL Inner-Loop Power Control (ILPC) commands (not used in final implementation)
Correction on top of PE-DCH (k) computed basing on E-HICH bad detection by UE.
Benefits to all E-DCH RLs of the E-DCH serving NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 106/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RNC
BTSCell
012
RadioAccessService
EdchConf
00
EdchRncConf 00
pMinDlEDCH
pMaxDlEDCH
eagchPowerControlModeXcem
eagchPowerOffset
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset
00
eagchPowerControlActivated
Remark: powerOffsetERGCHServingSHO
parameter is also introduced in UA6 RAN Model
(under EdchConf). However, this parameter is
ignored by the system.
9.2.2.2.2 PARAMETERS
eagchPowerControlActivated: Flag enabling Power Control for all E-DCH DL
channels (E-AGCH, E-HICH and E-RGCH), at RNC level.
Parameter
eagchPowerControlActivated
Object
EdchRncConf
Granularity
RNC
Customer, 3
Value
True
eagchPowerControlModeXcem: Flag enabling Power Control for all E-DCH DL
channels, at cell level.
Parameter
eagchPowerControlModeXcem
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
Dynamic
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 107/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ehichErrorProbability
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
10 (corresponds to 1%)
minPowerCorrection: In E-HICH Outer-Loop correction mechanism, maximum
correction that can be applied to E-DCH DL channels base power PE-DCH (k).
B
Parameter
minPowerCorrection
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
0.0
Parameter
maxPowerCorrection
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
0.0
Remarks:
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 108/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Board-specific parameters:
All parameters above-listed in Parameters setting are xCEM-specific.
Remark on E-HICH signature power for iCEM:
For both the E-DCH serving RL and non-serving RLs (of serving NodeB and non-serving NodeB(s) ),
E-HICH signature power is fixed to a unique value by ehichPowerSignature under EdchConf.
Remark on E-RGCH signature power for iCEM:
For E-DCH non-serving RLs of non-serving NodeB(s), E-RGCH signature power is fixed to a unique
value by ergchPowerSignature under EdchConf.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 109/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[UCU-III]
It will be possible to extend the SRB on E-DCH as soon as all TRB are mapped on EDCH in the uplink, whatever the minSF and whatever the TTI value of the E-DCH
configuration.. OneBTS does not support 2ms TTI. UCU-III supports up to category 5,
on 10 ms TTI only. It does not support category 6 (it would be managed like a
category 4 on 10ms TTI).
DL
UL
L3
SRB
TRB
L2 - Trsp
DCH-FP
HS-DSCH FP
E-DCH FP E-DCH FP
HS-DPCCH
E-DPCCH
E-DPDCH
L1
DPCCH/DPDCH HS-SCCH
HS-PDSCH
E-HICH DPCCH
SRB
TRB
In order to achieve right DL inner loop power control algorithm, the SRB DCH is used.
In order to achieve right UL inner loop power control algorithm, UL DPCCH is used.
In order to achieve right UL outer loop power control, feature PM 34249 EUL Capacity
Optimized HARQ Operation is needed. It may be not sufficient as there is no more 1x0
transport format in the Uplink.
In order to achieve right DL outer loop power control, 1x0 shall be used on the SRB
DPDCH when there is no data to be sent from SRB.
Restriction:
SRB over E-DCH is not supported during E-DCH FP over Iur, a fallback on DCH is applied in uplink for
SRB, in case the drift RNC controls the primary cell (mobile is considered as a category 4).
E-DCH FP over Iur is introduced by the feature 30744 allowing the SRNC to manage RABs mapped
over E-DCH in UL when a Drift DRNC controls the Primary Cell, thus allowing inter-RNC mobility for
E-DCH.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 110/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isSrbOnEdchAllowedWhenTrbOnEdch
TRUE/FALSE None
Object
RadioAccessService
Customer
3-a2
FALSE
Granularity
RNC
Parameter
Range &
Unit
User
Class
Value
srbQos.srbSpi
Integer [0..15]
Object
RadioAccessService
Customer
3-a2
15
Granularity
RNC
isSrbOnEdchAllowedWhenTrbOnEdch
Enable the possibility to map SRB on E-DCH in the UL for Cat 6 UE, while the call is
handling RAB(s) over E-DCH
srbQos.srbSpi
Reserved0 bit 1: reserved0 Bit 1: SRB on E-DCH for all NodeB minSF
o
Reserved0 bit 2 : reserved0 Bit 2: SRB on E-DCH for all E-DCH TTI
o
Parameter
Range & Unit
Reserved0 bit 0
Bit: 0 or 1 Kind of Boolean
Object
RadioAccessService
User
Class
Value
Customer
3-a2
0
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 111/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Reserved0 bit 1
Bit: 0 or 1 Kind of Boolean
Object
RadioAccessService
User
Class
Value
Customer
3-a2
0
Granularity
RNC
Parameter
Range & Unit
Reserved0 bit 2
Bit: 0 or 1 Kind of Boolean
Object
RadioAccessService
User
Class
Value
Customer
3-a2
0
Granularity
RNC
Rule:
As a reminder, a cell is a 2 ms E-DCH TTI capable if:
The 34.108 [R09] E-DCH configuration is selected, chapter 6.10.2.4.6.2.1.1.1.2, MACd flow#2 parameters for UL: [max bit rate depending on UE category and TTI] SRBs
for E-DCH
X
Higher layer
RLC
MAC
Layer 1
NOTE:
RAB/Signaling RB
SRB #1
SRB #2
SRB #3
Logical channel type
DCCH
DCCH
DCCH
RLC mode
UM
AM
AM
Payload sizes, bit
136
128
128
Max data rate, bps
Depends on UE category and TTI
AMD PDU header, bit
8
16
16
MAC-es multiplexing
4 logical channel multiplexing
MAC-d PDU size, bit
144
MAC-e/es header fixed 18
part, bit
TrCH type
E-DCH
TTI
10 ms (alt. 2 ms) (NOTE)
Coding type
TC
CRC, bit
24
The support of 2 ms TTI depends on the UE category.
The SRB will be mapped on E-DCH using the non-schedule traffic.
SRB #4
DCCH
AM
128
16
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 112/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Restriction:
Nevertheless, facing iBTS limitation on iCEM, parameter reserved0 Bit 2 shall never be set to 1 if
there at least a iCEM on a NodeB where E-DCH is activated.
Finally, as the oneBTS does not support 2 ms TTI for E-DCH, every reference to the 2 ms TTI is not
applicable for some customers.
Value
0
0
0
Model Configuration
reserved0 Bit 0
reserved0 Bit 1
reserved0 Bit 2
Meaning
Cat 6 UE only
2 SF2 + 2 SF4 minSF only
2 ms TTI only and 2 ms supported on NodeB
US Market
Value
Meaning
1
All UE Categories
1
Whatever minSF
1
For all NodeB; For all TTI
Remark: Refer to section 5.6 of this volume for further details regarding the reserved0 parameter.
U
Finally, as a reminder, the following are the usual settings that are required for a smooth operation of
the feature:
Page 113/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 114/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Even if the SRB over e-DCH is tagged as an xCEM only feature, there are two
scenarios where the unidirectional DCH must be supported on iCEM and CEM
boards:
Call reconfiguration. This use case happens when the call is already
established on a NodeB that is composed by at least one iCEM (or CEM) and
one xCEM. The DCH SRB part is currently handled by the iCEM (or CEM)
board and the traffic TRB is currently handled by the xCEM. Upon whatever
event, the RNC decides to reconfigure the call with SRB on E-DCH and TRB
on E-DCH & HSDPA. If the reconfiguration on the TRB would not be an issue,
the successful reconfiguration of the SRB requires that the iCEM (or CEM)
does support the unidirectional DCH SRB.
Mobility. This use case happens when the call is already configured with SRB
on E-DCH and when the UE is entering a NodeB containing at least an iCEM
(or CEM). When the RNC will perform a RL setup to extend the DCH active
set, the DCH configuration will be a DL unidirectional DCH for SRB 3.4 kbps
and an UL DPCCH (only).
The mobility use case is the most important one. The RNC has no DCH fallback
procedure on a RL setup failure. Therefore if the NodeB would refuse unidirectional
DCH due to a non supported configuration that will probably end in a call drop. This is
applicable for CEM and iCEM.
The call reconfiguration use case will be covered by the DCH fallback algorithm if the
reconfiguration fails. But as the mix of iCEM (or CEM) with xCEM will occur on site
and as the CCM load balancing may establish the DCH part of the call on a D-BBU on
the iCEM (or CEM), the iCEM (or CEM) shall support the unidirectional DCH in order
to increase the possibility for SRB on E-DCH on the network.
The requirements to support unidirectional DCH on CEM and iCEM are:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 115/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
On the HSDPA side, the channelization code of the HS-DPCCH will change according
to chapter 4.3.1.2.2 of [R06].
X
Nmax-dpdch
(as defined in subclause 4.2.1)
0
1
2,4,6
3,5
B
C ch,256,33
Cch,256,64
Cch,256,1
Cch,256,32
B
PARAMETERS (Modified)
In the MO UlRbSetConf, one value of enum shall be renamed in order to cope with
its actual usage: Value 13 shall be renamed into SRB_ON_HSPA.
Transport characteristic that shall be used for the UlRbSetConf:
Parameter
Range &
Unit
User
Class
Value
UlRbSetConf
cacTransportInfoList[].cacTransportInfoInstanceCharacteristic Object
AMR_12_2(0), AMR_10_2(1), AMR_7_95(2), AMR_7_4(3), AMR_6_7(4), AMR_5_9(5),
AMR_5_15(6), AMR_4_75(7), INTERACTIVE_1ST_THP(8), INTERACTIVE_2ND_THP(9),
INTERACTIVE_3RD_THP(10), INTERACTIVE_THP_UNSPECIFIED(11), BACKGROUND(12),
SRB_ON_HSPA(13), SRB_ON_DCH(14), UNSPECIFIED(15)
Customer
Granularity RNC
3-a2
Refer to PM 34202 & PM 33579
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 116/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
11 COMPRESSED MODE:
[iCEM] [xCEM]
Compressed Mode can be used for E-DCH calls with iBTS.
On E-DCH, compressed frames are obtained by MAC-e adequate scheduling. MAC-e sets restrictions
so that only a sub-set of the allowed TFCs are used in a compressed frame. The maximum number of
bits that will be delivered to the physical layer during the compressed radio frame is then known and a
transmission gap can be generated.
The principle in UE is the following: the Serving Grant calculated at each TTI with the E-AGCH and
ERGCH
commands is scaled down with the following formula
Sg = Sg * (Nc/15) where
- Sg is the Serving Grant,
- Sg the modified Serving Grant and
- Nc the non-DTX slots due to uplink Compressed mode in the 10 ms TTI
Then, the maximum amount of data from the MAC-d flows is quantized to the next smaller supported
E-TFC based on the Sg
The compressed mode is managed as usual on the associated DCH (SF/2 method).
For the E-DCH part, the compressed mode gaps are taken into account by the MAC-e scheduler,
leading to a minimal degradation of throughput (feature 33480 E-DCH Compressed Mode UA05.1):
- The UE is able to transmit on the E-DPDCH during compressed mode but using a different
transport format in order not to transmit during uplink gaps. These frames can be decoded by the
BTS, except if the UE applies a SF/2 format (this can be prevented by using adequate E-TFCI
tables). In case the UE chooses the SF/2 format the Node B will ACK the frame but not decode it.
The purpose of this ACK is to avoid retransmissions (that would not be decoded either) and RLC
will retransmit the lost PDUs.
- The retransmissions of a NACKed frame for which the first transmission was affected by a gap uses
the same format that the initial transmission. The BTS is also able to decode these frames except in
case of SF/2 format.
- The BTS may address the UE on E-AGCH or E-HICH or E-RGCH during downlink gaps. However
due to the fact that we use a TTI of 10ms information are repeated 5 times during the TTI, we can
expect that the UE may be able to decode these information.
Note : in case the UE does not properly apply the right format for compressed frames (non 3GPP
compliant behaviour) the Node B will not be able to decode these frames, leading to NACKs these
frames (and their retransmissions) and RLC retransmissions. In this case, tests showed that there is a
substantial degradation of E-DCH user throughput, but CM and measurements are performed as
usual by the mobile, and mobility is achieved while maintaining the E-DCH call (i.e. no call drop)..]
Handling of NodeBs and UEs with missing compressed mode capability for E-DCH (FRS34167
UA06):
[UCU-III]
In networks with OneBTS the parameter
RadioAccessService.isEdchCmFallbackAllowed must be set to value 'allowedAlways' such that
EDCH calls are reconfigured to uplink DCH if Compressed Mode is needed.
Legacy UEs: Some non-standards conforming UEs do not support compressed mode in combination
with E-DCH. If the UE has indicated in the UE Capability Information that it does not support
compressed mode with E-DCH2 or compressed mode activation for E-DCH fails then a reconfiguration
to uplink DCH is performed and compressed mode is activated with the DCH configuration. The
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 117/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
[iCEM] [xCEM]
In networks with iBTS the parameter RadioAccessService.isEdchCmFallbackAllowed
should be set to value 'ueDependent' to enable the automatic fallback to DCH. If it is assumed that all
UEs support E-DCH with compressed mode and no fallback to DCH should be triggered for
compressed mode activation then the parameter can be set to value 'never'.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 118/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
12 ONEBTS PARAMETERS
The following tables are listed for parameters that are unique to the UA06 OneBTS
NodeB (USA market), and are under OAM object OneBTSEquipment.
[UCU-III]
eAGCHPowerOffset:
Power Control of E-DCH DL channels enabled:
Power offset of E-AGCH relative to E-DCH DL channels base power PE DCH(k).
U
Parameter
eAGCHPowerOffset
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
10.0
eHICHErrorProbability: Target E-HICH error rate for E-HICH Outer-Loop correction
mechanism.
Parameter
eHICHErrorProbability
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
10 (corresponds to 1%)
deltaDownServingCellNoHO: If a ACK was sent on E-HICH and the next associated
UL block is a fresh transmission, then the E-HICH was received correctly and the
correction value is decreased by this value.
Parameter
deltaDownServingCellNoHO
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
20 (corresponds to 0.2dB)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 119/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
maxPowerCorrection
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
-3.0
minPowerCorrection: Lower bound for power offset of E-HICH signature relative to
E-DCH DL channels base power PE-DCH (k).
B
Parameter
minPowerCorrection
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
-3.0
powerOffsetERGCHServingNoSHO:
For E-DCH RLs of serving NodeB, power offset of E-RGCH signature relative to EHICH signature power of considered RL.
Remarks:
- For serving NodeB, only dedicated RG commands are used (at a given time, same
command is transmitted on all radio links).
- powerOffsetERGCHServingNoSHO applies to both E-DCH serving RL and E-DCH
non-serving RLs of serving NodeB (NoSHO has no specific meaning).
U
Parameter
powerOffsetERGCHServingNoSHO
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
1.5
powerOffsetERGCHServingSHO: This parameter is ignored by the system.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 120/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
pMaxDlEDCH
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
6.0
pMinDlEDCH: Lower bound for E-DCH DL channels base power PE DCH(k). Value is
relative to CPICH Tx power.
B
Parameter
pMinDlEDCH
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Customer, 3
Value
-18.0
edchServiceParameterSet1
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
15
serviceMinRate
Integer: {0,1,..,10000}
40 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
300 [kbps]
serviceBFactor
Integer: {0,1,..,30}
7
serviceKFactor
Integer: {0,1,..,30}
7
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 121/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchServiceParameterSet2
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
14
serviceMinRate
Integer: {0,1,..,10000}
25 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
200 [kbps]
serviceBFactor
Integer: {0,1,..,30}
10
serviceKFactor
Integer: {0,1,..,30}
7
Object
OneBTSEquipment
Granularity
OneBTSEquipment
edchServiceParameterSet3
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
13
serviceMinRate
Integer: {0,1,..,10000}
10 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
14
serviceKFactor
Integer: {0,1,..,30}
7
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 122/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
edchServiceParameterSet4
schedulingPriorityLevel
Integer: {0,1,..,15}
Customer
3
12
serviceMinRate
Integer: {0,1,..,10000}
0 [kbps]
serviceMaxRate
Integer: {0,1,..,10000}
100 [kbps]
serviceBFactor
Integer: {0,1,..,30}
15
serviceKFactor
Integer: {0,1,..,30}
7
Object
OneBTSEquipment
Granularity
OneBTSEquipment
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 123/124
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 124/124
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
CALL MANAGEMENT
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CONTENTS
1
INTRODUCTION............................................................................................................................5
1.1
OBJECT ....................................................................................................................................5
1.2
2.2
OVERVIEW................................................................................................................................9
3.2
3.3
IMCTA ..................................................................................................................................17
4.2
4.2.1
RNC CAC ......................................................................................................................20
4.2.2
Node-B CAC..................................................................................................................36
4.3
HSPA TO DCH FALLBACK .......................................................................................................37
4.3.1
4.3.2
5
FALLBACK MECHANISM:............................................................................................37
PARAMETERS SETTINGS AND RECOMMENDATIONS: ..........................................38
5.2
6.1.1
Principles.......................................................................................................................44
6.1.2
Multi-RAB Combination Configuration (HSDPA) ..........................................................45
6.2
MULTI-RAB HANDLING ON HSUPA .........................................................................................48
6.2.1
6.2.2
7
Principles.......................................................................................................................48
Restriction on combination Streaming + HSUPA..........................................................48
7.2
8.2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ALWAYS-ON............................................................................................................................54
9.1.1
Mechanism ....................................................................................................................54
9.1.2
New RRC states............................................................................................................54
9.1.3
Activation & ModeS.......................................................................................................56
9.1.3.1
Activation .................................................................................................................. 56
9.1.3.2
Modes ....................................................................................................................... 59
9.1.3.3
Multiservice with HSDPA (HSDPA+CS & HSDPA+STR) ........................................ 62
9.1.3.4
Upsize....................................................................................................................... 62
9.1.3.5
Reminder for timer usage ......................................................................................... 63
9.1.4
Parameters Settings and Recommendations ...............................................................65
9.2
IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING .......................................................66
9.3
9.4
9.5
Description ....................................................................................................................68
Feature Dependencies..................................................................................................69
CAC Failures .................................................................................................................70
Other backup mechanisms ...........................................................................................71
Activation flags ..............................................................................................................72
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TABLES
Table 1: HSDPA RB Configuration and system behavior
Table 2: HSUPA RB Configuration and system behavior
Table 3: Summary of RNC detection regarding RRC Traffic Segmentation
Table 4: RRC Connection Request and suitable layer
Table 5: iMCTA Priority Table
Table 6 : Target Bit Rate
Table 7 : Corrective factor for power reservation
Table 8 : Corrective factor for codes reservation
Table 9: Always-on timer usage (URA/Cell_PCH states not used)
Table 10: Always-on timer usage (URA/Cell_PCH states are used)
TU
UT
TU
UT
TU
TU
8
9
14
15
17
22
23
25
63
64
UT
UT
UT
TU
TU
UT
UT
UT
UT
TU
TU
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FIGURES
Figure 1: Example of multi-layer structure ...................................................................................................... 10
Figure 2 : HS-DSCH power reservation at call admission ........................................................................... 23
Figure 3 : HS-PDSCH codes reservation at call admission ......................................................................... 26
Figure 4: Example of biggest pool of free SF16 ............................................................................................ 26
Figure 5: HSxPA Call setup / initial connection (Cell_DCH) ........................................................................ 49
Figure 6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 50
Figure 7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH) ....................... 51
Figure 8: Call release (RAB release case) ..................................................................................................... 53
Figure 9: AO state transitions ........................................................................................................................... 56
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none)............ 60
Figure 11: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates = none) ........... 61
Figure 12: Always-on for HSDPA/E-DCH (releaseOnly mode) ................................................................... 62
Figure 13: UA6.0 Pre-emption global view ..................................................................................................... 69
Figure 14: UA6.0 Pre-emption feature dependencies .................................................................................. 70
Figure 15: Pre-emption and other congestion management procedures .................................................. 72
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
TU
UT
TU
UT
UT
UT
UT
TU
TU
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.
description,
configuration
aspect
and
engineering
PM ID
Feature Title
Activation flag
27930
HSDPA Service
N/A
27935
Multi-Carrier
HSDPA
traffic
segmentation
isRedirectionForTrafficSegmen
tation
Always-on
HSDPA
isAlwaysOnAllowed
27942
On
Release
Global
market
US
Market
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
isRedirectionBasedOnEstablis
hmentCause
HSDPA Radio
Bearer
Multi-Services
Handling On
HSUPA
Multi-RAB Handling
on HSDPA
N/A
HSDPA to DCH
fallback
edchToDchFallbackPermission
32602
34168
STSR2+1
N/A
UA5.1
Yes
No
29804
GBR on HSDPA
isGbrOnHsdpaAllowed
(used
only to map Streaming on
HSDPA)
UA6.0
Yes
Yes
33320
UA6.0
Yes
Yes
27945
30741
29797
N/A
isMultiRabOnHsdpaAllowed
edchToDchFallbackSteps
N/A
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
NodeB:
U
33694
Fair Sharing of
Resources HSDPA vs DCH
[iCEM] [xCEM]
BTSEquipment::hsdpaCodeTre
eManagementActivation
UA6.0
Yes
Yes
UA6.0
No
Yes
UA6.0
Yes
Yes
[UCU-III]
OneBTSEquipment::hsdpaCod
eTreeManagementActivation
isThreeRabAllowed
isMpdpExtendedRabCombsAll
owed
34170
3 PDP Support
mpdpInactivityIuRelease
isMpdpExtendedRabCombsAll
owed
84900
Traffic
Segmentation
between HSPA
Layers by RRC
Redirection
layerPreferredForR99
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios
[R02] UMT/BTS/INF/016135
Planning Guide
[R03] UMT/SYS/DD/018826
[R04] UMT/IRC/APP/0164
[R05] UMT/IRC/APP/025147
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RB Configuration
System behavior
PS I/B on HSDPA
PS Streaming on
HSDPA
Speech on DCH +
PS I/B on HSDPA
CSD/DCH + PS I/B
on HSDPA
Speech on DCH +
(PS+PS) on
HSDPA
(PS I/B+PS
Streaming) on
HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
System behavior
All
RABs
DCH
available in HSUPA
Cell
PS I/B on HSUPA
Supported
Speech on DCH + PS
I/B on HSUPA
Speech on DCH +
(PS+PS) on HSUPA
CSD/DCH + PS I/B on
HSDPA
Supported
3 MULTI-CARRIER MANAGEMENT
3.1 OVERVIEW
To increase the network capacity, operators may deploy multi-layer configurations with
several layers structures:
Moreover, the introduction of HSUPA since UA5.x networks is also progressive with
hot spots and there is a real need to redirect R99/R4 and HSDPA/HSUPA capable
mobiles (R5, R6) towards the appropriate layer.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FDD2
HSUPA
Since UA5.x, several features are used in order to distribute the traffic between the
different layers including 2G (GSM, CDMA):
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
This feature impacts the choice of the target cell and the frequency layer at the call
establishment. The main benefits are to allow HSxPA capable mobiles to benefit from
HSxPA service and to avoid loading the HSxPA layer with R99/R4 mobiles.
In case HSxPA is deployed on both layers (allowing both layers to carry HSPA traffic),
it is possible to prefer some of the HSPA capable layers for R99 traffic:
HSxPA service originated on preffered cell will be redirected to the nonpreferred cell;
This algorithm is enhanced in UA6.0, i.e. RNC still makes the difference between
R99/R4 UEs and the other ones (i.e. R5 or R6). But it is now able to find preferred
HSxPA cells for R99 traffic. This enhancement is only applicable if the originating cell
and operational twin cell is enabled for HSDPA (parameter hsdpaActivation).
Emergency calls are never redirected and are served on the layer selected by the
mobile to limit the probability of call setup failure.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The UE Release via the Access Stratum Release indicator IE, knowing that:
o
The requested service via the Establishment Cause IE knowing that traffic
class Conversational can not be served on HSxPA layer. This filtering is
optional depending on the setting of the parameter
isRedirectionBasedOnEstablishmentCause;
And check layerPreferredforR99 for both cells; In case both cells have the
same layerPreferredForR99 value (FALSE or TRUE), RNC may try to
disregard layerPreferredForR99;
Page 12/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The following table depicts the decision taken by RNC depending on the value of the
following parameters:
isRedirectionForTrafficSegmentation
isRedirectionBasedOnEstablishmentCause
layerPreferredForR99
Originating cell
hsdpaActivation == TRUE
isRedirectionForTrafficSegmentation == TRUE and
FddCell.
isRedirectionBasedOnEstablishmentCause
InterFreqHHO
parameters
FALSE
TRUE
layerPreferredForR99
layerPreferredForR99
(rnc_com_i100)
FALSE
layerPreferredForR99
Twin cell
hsdpaActivation == TRUE
FALSE
N/A(note)
TRUE
FALSE
TRUE
R99 mobile is
not directed
R5+ mobile is
re-directed to
HSPA twin cell
N/A(note)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TRUE
R99 mobile is
re-directed to
non-HSPA cell
R5+ mobile is
not directed
N/A(note)
N/A(note)
Hereafter the static mapping between the Establishment cause sent by the mobile in
the RRC Connection Request and the suitable layer pointed by RNC:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Suitable layer
DCH
DCH or HSxPA*
HSxPA
HSxPA
HSxPA
DCH
DCH or HSxPA*
HSxPA
DCH or HSxPA
(i.e. no re-direction)
Registration
HSxPA
Detach
DCH or HSXPA
(i.e. no re-direction)
HSxPA
DCH or HSxPA
(i.e. no re-direction)
DCH or HSxPA
(i.e. no re-direction)
Meaning
HSxPA
DCH or HSXPA
(i.e. no re-direction)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 15/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isRedirectionForTrafficSegmentation
Boolean
{True, False}
Customer
3
TRUE
Object
InterFreqHhoFddCell
Granularity
FDDCell
isRedirectionBasedOnEstablishmentCause
Boolean
{True, False}
Customer
3
TRUE
Object
InterFreqHhoFddCell
Granularity
FDDCell
Object
FddCell
layerPreferredForR99*
Boolean
{True, False}
Customer
Granularity FDDCell
3
Depending on topology (for further details please refer to Volume 7)
*Note: In UA6 parameter reserved1 (bit 0) under FDDCell is used for
layerPreferredForR99. In future releases, layerPreferredForR99 will be taken care
of by feature 75069.
Restriction:
In UA6 RRC Traffic Segmentation does not distinguish HSDPA-capable and HSUPA-capable cells.
Such segmentation is then performed by iMCTA Service after RAB is established.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
twinCellId
Decimal
Customer
3
N/A
Object
InterFreqHhoFddCell
Granularity
FDDCell
3.3 IMCTA
iMCTA is an algorithm allowing to allocate traffic across 3G and 2G layers; it is
invoked at the following events:
3G and 2G neighborhoods
The priority for each carrier of the requested service type, through Priority
Table as depicted hereafter:
Priority Table
CS
CS conv.
CS streaming
speech
PS
PS
CS speech +
streaming
I/B
other
FDD1
P2
P1
P1
P1
P2
P2
FDD2
P3
P2
P2
P2
P1
P1
2G
P1
PNA
P3
P3
P3
P3
iMCTA Alarm and CAC are not specific to HSxPA as they do not distinguish R99 from
R5/R6 mobiles.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
4 HSXPA CAC
4.1 RAB MATCHING
Any PS RAB request with Interactive or Background traffic class is matched to the
HSDPA/HSUPA Radio Bearer configuration if the mobile is HSDPA/HSUPA capable
and the primary cell of the active set supports HSDPA/HSUPA.
U
If the HSUPA is not supported in the cell (but the HSDPA is present), the request
is mapped on: UL DCH/DL HSDPA.
If neither HSUPA nor HSDPA are supported in the cell, the request is mapped on:
UL/DL DCH (iRM CAC is performed).
Any PS RAB with Streaming traffic class is matched to the HSDPA RB configuration if:
U
Parameter
Range & Unit
transportTypeSelectionTransferDelayThreshold
Integer [0 65536] seconds
Object
HsdpaRncConf
User
Class
Value
Customer
3
0
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Anyway, if needed, customer has the possibility to base the mapping of Streaming Rab on R99 or HSDSCH according to this parameter.
Parameter
Range &
Unit
User
Class
Value
isGbrOnHsdpaAllowed
Boolean
{True, False}
Customer
3
True (customer dependant)
Object
RadioAccessService
Granularity
RNC
Note that the parameter is only used to allow or not the mapping of PS Streaming Rab
on HS-DSCH. This parameter activates no GBR algorithm. GBR algorithms (introduce
with the feaure 29804 GBR on HSDPA) are enabled by default:
- NodeB: New mac-hs scheduler behavior when the mac-hs GBR IE is
received (higher priority for mac-hs GBR users and computation of the HSDSCH required power)
- RNC: Computation of the mac-hs GBR used by the Fair Sharing feature and
eventually sent to the NodeB
For
PS
Streaming
on
HSDPA
and
PS
I/B
on
HSDPA
when
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = True, the RNC sends to the
NodeB the Mac-hs GBR IE (corresponding to the Target Bit Rate, see 4.2.1 for more
details). At reception of this IE, the mac-hs scheduler activates a new behavior
allowing to
X
schedule with a higher priority the mac-hs GBR users (see [Vol. 3] for more
details).
report from the NodeB to the RNC the power needed to guarantee the mac-hs
GBR (this information is reported through the new NBAP commom measurement
HS-DSCH required power). This HS-DSCH required power will be used by the
RNC to update its power reservation and then will be used by the RNC CAC
algorithms.
Page 19/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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 feature and GBR feature,
some resources (power and codes) can be reserved for HSDPA in order to guarantee
a certain QoS. In this case, the CAC for HSDPA is no more based on the number of
HSDPA users but based on the available resources (as for DCH).
One part of the Fair Sharing algorithm is located at RNC level and manages
the HSDPA CAC (this section describes this part of the Fair Sharing
algorithm)
The other part of Fair Sharing algorithm is located at NodeB level and
manages dynamically the HS-PDSCH codes allocation according to the R99
traffic (see [Vol. 3] for more details).
X
In UA6.0, if the Fair Sharing is disabled, the RNC CAC is based on the number of
HSDPA
users
as
in
the
previous
releases
(isHsxpaR99ResourcesSharingOnCellAllowed
=
False):
Any
PS
Interactive/Background RAB request is admitted on HSDPA until the maximum
number of simultaneous users allowed on HSDPA is reached for the cell. Unlike the
iRM CAC performed for the RB mapped on DCH channels, the admission on HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
share resources between R99 users and HSDPA users in a fair way
(resources may be reserved for HSDPA users according to their needs
according to the service to establish and bitrate to achieve)
limit the number of HSDPA users according to the load of the system so that
each one can benefit from a certain level of QoS
allow deploying new services on HSDPA that are no more best effort but
needs a guaranteed QoS (like streaming)
Fair Sharing consists in reserving an amount of resources (power and codes) for each
established HSDPA RAB which is a function of the bitrate needed for the service.
The bitrate uses to compute the resources needed for HSDPA users depends on the
service:I/B services or Streaming service and is called Target Bitrate.
Target Bitrate
U
a mac-hs GBR
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
For minBrForHsdpa = 0 (PS I/B) or RANAP GBR = 0 (PS Streaming), the operator
can choose to reserve a minimum amount of resources defined by the parameter
minHsDschReservationForCac.
Type of service
minHsDschReservationForCac
minHsDschReservationForCac
Power reservation
U
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)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Corrective factor
RANAP GBR
PS I/B RAB with
initialActivityFactorForIb
minBr > 0
PS I/B RAB with
initialActivityFactorForIb
minBr = 0
For non GBR mac-d flows (see 4.1 for definition of non GBR user), the power
reservation will not change until the resources are released.
X
For GBR mac-d flows (see 4.1 for definition of non GBR user), the power is updated
periodically by a self-tuning mechanism (thanks to NBAP HSDSCH Required Power
common measurement).
X
As mentioned in 4.1, the operator has the choice to consider a PS I/B user as a machs GBR user (same behavior as a PS Streaming user). For that, the mac-hs GBR has
to be different from 0 (minBrForHsdpa > 0) and the parameter
isDlPowerSelfTuningForPsIbAllowed has to be set to True. This configuration
allows the scheduler to really try to enforce this mac-hs GBR.
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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
Pccc is the power reserved the common control channel taking into account
an activity factor defined by the parameter ActivityFactorCCH (in FDDCell).
Pedch is the power reserved for the DL channels related to E-DCH defined by
the parameter eagchErgchEhichTotalPower.
When Fair Sharing feature is enabled, the iRM power color is based on the self-tuned
R99 power (as in previous releases) and on the self-tuned HSDPA GBR required
power (NBAP measurement) plus the power reserved for HSDPA non-GBR users
(reservation depends on the number of HSDPA users and their minBR). Note that PS
I/B users are also self-tuned (i.e. handled as mac-hs GBR) if
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = TRUE
Codes reservation
U
At call admission, some codes are reserved for each RB mapped on HS-DSCH. The
reservation is done or updated each time a MAC-d flow is setup, deleted or
reconfigured or on mobility of the serving HS-DSCH cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
As for power, the number of codes to reserve for this HS-DSCH RAB is directly
proportional to the target bitrate:
For ue category 11 and 12:
Nb of SF16 codes = target bitrate / ovsfCodesThroughputQpskUE [1xSF16]
For ue category 1 to 10:
Nb of SF16 codes = target bitrate / ovsfCodesThroughput16QamUE [1xSF16]
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.
Corrective factor
reservationFactorOnCodesForGbrTraffic
RANAP GBR
PS I/B RAB with
reservationFactorOnCodesForGbrTraffic
minBr > 0
and initialActivityFactor
initialActivityFactor
minBr = 0
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
reservationFactorOnCodesForGbrTraffic
Codes reserved for PS
Streaming on HSDPA
initialActivityFactorForIb
Codes reserved for PS I/B
on HSDPA if minBr = 0
reservationFactorOnCodesForGbrTraffic
Codes reserved for PS I/B
on HSDPA if minBr > 0
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
where
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 26/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameters:
U
maximumNumberOfUsers is used for the HSDPA CAC done by the RNC. The
number of users is per cell. By default this parameter is set to 100 (when the value
is set to 100 the RNC CAC is deactivated, i.e. Node-B performs the Call
Admission Control). Note that even if maximumNumberOfUsers is different from
100, RNC CAC based on the number of HSDPA users is deactivated when Fair
Sharing feature is enabled (isHsxpaR99ResourcesSharingOnCellAllowed =
True). If maximumNumberOfUsers = 0 (not recommended), CAC failure
happens when HSDPA call try to be admitted, leading to trigger a HSDPA to DCH
fallback.
Parameter
Range & Unit
maximumNumberOfUsers
Integer [0 100] N/A
Object
HsdpaCellClass
User
Class
Value
Customer
3
100
Granularity
RNC
Parameter
Range & Unit
User
Class
Value
Parameter
Range & Unit
User
Class
Value
isHsxpaR99ResourcesSharingOnCellAllowed
Boolean {True; False}
Customer
2
True
Object
FDDCell
Granularity
Cell
The limitation of the number of E-DCH users is entirely controlled through the BTS
parameter edchMaxNumberUserEbbu.
Object
BTSEquipment
Granularity
BTS
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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)
At cell setup, the NodeB receives from the RNC a PSCR message. The number of HS-PDSCH
codes configured according to this PSCR depends on the RNC algorithm (Fair Sharing : 15;
DCTM : 12 with the recommended setting; 5 or 10 if Fair Sharing and DCTM are disabled)
After the cell setup, the number of HS-PDSCH codes available by the scheduler is updated
according the R99 admission or release thanks to the Fair Sharing algorithm
If a new PSCR message is received (in case of DCTM enabled), the scheduler will used this
information to know how many HS-PDSCH codes are available
Note that the DCTM feature and RNC Fair Sharing algorithm are totally exclusive
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FDDCell
isDlPowerSelfTuningForPsIbOnHsdpaEnabled Object
Boolean {True; False}
Customer
Granularity
Cell
3
True to consider PS I/B users as a GBR users (power reservation updated
periodically and higher priority of scheduling), False otherwise.
Rule: isDlPowerSelfTuningForPsIbOnHsdpaEnabled
When this flag is set to True, the HSDPA power reserved by the RNC is updated thanks to the NBAP
common measurement HS-DSCH required power reported by the NodeB.
This message informs the RNC of the power needed to guarantee the GBR. Basically, the estimation
of this required power to guarantee the GBR is done by the scheduler knowing the current throughput
and the current HSDPA power consumed by the NodeB.
Considering a constant power consumption for HSDPA (in general, equal to Pcpich + MPO for a single
HSDPA user), the HS-DSCH required power will increase when the current throughput will decrease.
Then, the cell capacity can be reduced when the ue is in bad RF conditions (low throughput).
Parameter
Range &
Unit
User
Class
Value
minBrForHsdpa
[0..2048] kb/s
Object
ThpBasedQos
Customer
3
Default values (see the table below)
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1- Default recommendation:
U
Traffic Class
ARP
THP
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
minBrForHsdpa = 16 kbps
minBrForHsdpa = 8 kbps
minBrForHsdpa = 8 kbps
minBrForHsdpa = 16 kbps
minBrForHsdpa = 8 kbps
minBrForHsdpa = 8 kbps
minBrForHsdpa = 16 kbps
minBrForHsdpa = 8 kbps
minBrForHsdpa = 8 kbps
1
Background
2
3
minBrForHsdpa = 4 kbps
N/A
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
The minBrForHsdpa is also used by the Transport feature Enhanced QoS to manage the transport
congestion. This default recommendation is the recommendation for Enhanced QoS.
2- No resource reservation:
U
The simpler way to reserve nothing for HSDPA should be to set minBrForHsdpa to 0kb/s.
Nevertheless, set 0kb/s can lead to HSDPA call drop in case of transport congestion. That is why the
minimum value for minBrForHsdpa is 4kb/s (to avoid any HSDPA call drop in case of transport
congestion). With 4kb/s, the resources reserved are low. But to really reserve nothing for HSDPA
(best effort), the recommendation is to set :
reservationFactorOnCodesForGbrTraffic = 0%
initialActivityFactorForIb = 0%
isDlPowerSelfTuningForPsIbOnHsdpaEnabled = False
Different type of differentiation can be used by the operator according to their strategy:
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 30/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ARP
THP
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
3
1
Background
minBrForHsdpa = 4 kbps
minBrForHsdpa = 128 kbps
N/A
ARP
THP
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
1
Background
2
3
minBrForHsdpa = 4 kbps
N/A
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 31/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ARP
THP
1
Conversational
3
1
Streaming
N/A
2
N/A
3
1
Interactive
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
1
Background
2
3
minBrForHsdpa = 4 kbps
N/A
minBrForHsdpa = 4 kbps
minBrForHsdpa = 4 kbps
Note that the values used in these tables for minBrForHsdpa and especially 128kb/s and 100kb/s are
given as an example. These values can be tuned according to a tradeoff between QoS and capacity.
The value 4kb/s means that very low resources are reserved (as explained, it is not recommended to
set 0kb/s to avoid any HSDPA call drop due to transport congestion management)
Note that if the customer wants to define the minBrForHsdpa per OLS, then OLS has to be enabled
thanks to the parameter activateOls (in RadioAccessService).
From a transport point of view, minBrForHsdpa is the throughput allowed during a transport
congestion state. In order to be in line with the EBR value (EBR is used for transport CAC),
minBrForHsdpa should be lower or equal to EBR (if EBR > 0).
Note that the minBrForHsdpa is respected during Iub congestion regardless of the setting for the
enhancedQualityOfService flag (used to enabled the feature Enhanced QoS. See [R04] for more
details on this feature).
X
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
minHsDschReservationForCac
[0..1024] kb/s
Object
HsxpaR99ResourcesSharingCellClass
Customer
3
Max value of minBrForHsdpa
Granularity
RNC
Parameter
Range &
Unit
User
Class
Value
dlTxPowerEstimation
[1..7][-35.0..15.0] step:0.1dB
Object
HsxpaR99ResourcesSharingCellClass
Customer
Granularity RNC
3
-35.0,-35.0,-35.0,-35.0,-35.0,-35.0,-35.0 (7 values corresponding to [64kbps; 128kbps;
256kbps; 384kbps; 1000kbps; 2000kbps; 4000kbps])
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 33/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
ovsfCodesThroughputQpskUe
[1..15][0..14400] kb/s
Parameter
Range &
Unit
User
Class
Value
ovsfCodesThroughput16QamUe
[1..15][0..14400] kb/s
Object
HsxpaR99ResourcesSharingCellClass
Customer
Granularity RNC
3
200,0,0,0,0,0,0,0,0,0,0,0,0,0,0 (the value n gives the bitrate for n SF16 codes. Only first
value is meaningful (1xSF16))
Object
HsxpaR99ResourcesSharingCellClass
Customer
Granularity RNC
3
300,0,0,0,0,0,0,0,0,0,0,0,0,0,0 (the value n gives the bitrate for n SF16 codes. Only first
value is meaningful (1xSF16)).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 34/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note that if ovsfCodesThroughputxxxUe is equal to 0kb/s per SF16, then a hard-coded value will be
used. This value is hard-coded to 200kb/s per SF16.
For example:
If (ovsfCodesThroughputQpskUe = 0 ; ovsfCodesThroughput16QamUe = 0) then
ThPerSf16 = 200kb/s (hard-coded) for QPSK ue
ThPerSf16 = 200kb/s (hard-coded) for 16Qam ue
If (ovsfCodesThroughputQpskUe = 100 ; ovsfCodesThroughput16QamUe = 0) then
ThPerSf16 = 100kb/s for QPSK ue
ThPerSf16 = 200kb/s (hard-coded) for 16Qam ue
If (ovsfCodesThroughputQpskUe = 0 ; ovsfCodesThroughput16QamUe = 100) then
ThPerSf16 = 200kb/s (hard-coded) for QPSK ue
ThPerSf16 = 100kb/s for 16Qam ue
If (ovsfCodesThroughputQpskUe = 100 ; ovsfCodesThroughput16QamUe = 300) then
ThPerSf16 = 100kb/s for QPSK ue
ThPerSf16 = 300kb/s for 16Qam ue
Parameter
Range &
Unit
User
Class
Value
reservationFactorOnCodesForGbrTraffic
[0..500] %
Object
HsxpaR99ResourcesSharingCellClass
Customer
Granularity RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 35/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
initialActivityFactorForIb
[0..100] %
Object
HsxpaR99ResourcesSharingCellClass
Customer
Granularity RNC
3
100 (default) or 0 in order to reserve no resource whatever the minBrForHsdpa value
hsxpaR99ResourcesSharingId
N.A.
Customer
3
Pointer
Object
FDDCell
Granularity
Cell
Each of these modules has some capacity limitations and this capacity is limited
through some sets of parameters (see [R05]).
X
If one of the E-BBU or H-BBU limit is reached, the BTS will send a RL Reconfiguration
Failure (meaning NodeB CAC failure)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 36/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Note that the NodeB CAC is unchanged whatever the Fair Sharing activation.
IU release
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:
In case HSPA to DCH fallback is disabled, any HSxPA CAC failure leads to an IU-PS
Release procedure (except if backup mechanisms like iMCTA or pre-emption feature
for HSxPA are activated. See [1] Vol14).
Note that HSPA to DCH fallback is only processed when RNC is acting as Serving
RNC. When acting as Drift RNC, any HSPA CAC failure leads to a RNSAP Radio Link
Reconfiguration or Setup Failure.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 37/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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:
MultiStep to try and reconfigure first into HSDPA (and then into DCH in case
of HSDPA CAC failure)
Object
hsdpaToDchFallbackPermission
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
AnyCase
RadioAccessService
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 38/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Object
edchToDchFallbackPermission
Enum
{NoFallBack, RabAssignment, Mobility, AnyCase}
Customer
Granularity
3
AnyCase
RadioAccessService
RNC
edchToDchFallbackSteps
Enum
{MonoStep, MultiStep}
Customer
3
MultiStep
Object
RadioAccessService
Granularity
RNC
When it is associated to a RB Reconfiguration procedure (due to mobility or AlwaysOn), it is done simultaneously with the transport channel reconfiguration (synchronous
reconfiguration).
Page 39/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
dch hs-dsch:
U
o
U
fach hs-dsch:
U
hs-dsch hs-dsch:
U
No RLC Reconfiguration because the transport channel keeps unchanged but the
establishment of the radio link on the new primary cell supporting HSDPA needs a
synchronized RB reconfiguration via the parameter deltaCfnForHsdpaMobility.
Restriction:
DL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC
entities so lose all PDUs under transmission).
The RNC RLC Queue Size is never reconfigured. The implication is that if a R5 mobile is
performing the RAB Assignment procedure in non-HSDPA cell, the RLC Queue Size of the
resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is
subsequently transitioned to a HSDPA cell.
Parameters:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 40/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isRLCReconfigurationForChannelTypeSwitching
Boolean
{True, False}
Customer
3
True
Object
HsdpaRncConf
Granularity
RNC
deltaCfnForHsdpaMobility
Integer
[0..255] (x10ms)
Customer r
3
45
Object
HsdpaRncConf
Granularity
RNC
deltaCfnForHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
80
Object
HsdpaRncConf
Granularity
RNC
deltaCfnForHsdpaRLCReconfiguration
Integer
[0..255] (x10ms)
Customer
3
0
Object
HsdpaRncConf
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 41/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
When it is associated to a RB Reconfiguration procedure (due to mobility or AlwaysOn), it is done simultaneously with the transport channel reconfiguration (synchronous
reconfiguration).
Restriction:
UL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC
entities so lose all PDUs under transmission).
The UE RLC Queue Size is never reconfigured. The implication is that if a R6 mobile is
performing the RAB Assignment procedure in non-E-DCH cell, the RLC Queue Size of the
resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is
subsequently transitioned to a e-DCH cell.
Parameters:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 42/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isRLCReconfigurationForChannelTypeSwitchingEdch
Boolean
{True, False}
Customer
3
True
RLC
Object
EdchRncConf
Granularity
RNC
deltaCfnForEdchAndHsdpaMobility
Integer
[0..255] (x10ms)
Customer
3
45
Object
EdchRncConf
Granularity
RNC
deltaCfnForEdchChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
150
Object
EdchRncConf
Granularity
RNC
deltaCfnForEdchAndHsdpaChannelTypeSwitching
Integer
[0..255] (x10ms)
Customer
3
80
Object
EdchRncConf
Granularity
RNC
deltaCfnForEdchRlcReconfiguration
Integer
[0..255] (x10ms)
Customer
3
150
Object
EdchRncConf
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 43/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
6 MULTI-RAB HANDLING
6.1 MULTI-RAB HANDLING ON HSDPA
6.1.1 PRINCIPLES
The feature Multi-Rab Handling on HSDPA allows to handle the following
configurations:
PS i/b HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCU-III only)
PS streaming HSDPA + PS i/b HSDPA + PS i/b HSDPA [+CS speech] (UCUIII only)
RAB Assign
RAB Release
Incoming Relocation
Always On Upsize
Etc.
Note:
U
Always On Step 2 applies for Multi-RAB HSDPA configurations (no Step 1).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 44/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
Range &
Unit
User
Class
Value
isMultiRabOnHsdpaAllowed
Boolean
{True, False}
Customer
3
True
Object
RadioAccessService
Granularity
RNC
Note: when the feature is deactivated, then the resulting DlUserService will be
mapped on DCH only.
U
isThreeRabAllowed
Boolean
{True, False}
Customer
3
False for GM, True for US Market
Object
RadioAccessService
Granularity
RNC
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 HSDPA only
CS Speech + PS HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 45/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2
HSDPACombinationEntry
must
be
configured
per
HSDPACombinationList, corresponding to the number of PS Streaming over
HSDPA Supported with this DlUserService:
o
HSDPACombinationEntry
HSDPACombinationList
Allowed
/0
/0
TRUE
TRUE
/0
/1
FALSE
FALSE
/1
/0
FALSE
FALSE
/1
/1
FALSE
FALSE
For DlUserServices
Meaning
All DluserService
without HSDSCH
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 46/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
/0
FALSE
FALSE
/2
/1
FALSE
FALSE
/3
/0
FALSE
FALSE
/3
/1
FALSE
FALSE
/0
/0
FALSE FALSE
CS_64K +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
FALSE FALSE
CS_64K +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
TRUE
CS_64K +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
FALSE FALSE
CS_64K +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
TRUE
CS_64K +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
CS_64K +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
CS_64K +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
FALSE
CS_64K +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
CS_AMR +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
TRUE
TRUE
CS_AMR +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
TRUE
CS_AMR +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
TRUE
TRUE
CS_AMR +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
TRUE
TRUE
CS_AMR +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE
TRUE
CS_AMR +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE
TRUE
CS_AMR +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
FALSE
CS_AMR +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
CS_AMR +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
TRUE
TRUE
CS_AMR +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
TRUE
CS_AMR +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
TRUE
TRUE
CS_AMR +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
TRUE
TRUE
CS_AMR +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
CS_AMR +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
CS_AMR +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
FALSE
CS_AMR +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
CS_AMR + PS_xxK_STR +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
FALSE
CS_AMR + PS_xxK_STR +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
CS_AMR + PS_xxK_STR +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
CS_AMR + PS_xxK_STR +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
CS_AMR + PS_xxK_STR +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
TRUE
CS_64KxPS_HSDSCH
xSRB_3_4K
CS_AMR_NBxPS_HSD
SCHxSRB_3_4K
CS_AMR_WBxPS_HS
DSCHxSRB_3_4K
TRUE
CS_AMR_NBxPS_xxK_
STRxPS_HSDSCHxSR
B_3_4K
TRUE
CS_AMR_WBxPS_xxK
_STRxPS_HSDSCHxS
RB_3_4K
/3
/1
FALSE
FALSE
CS_AMR + PS_xxK_STR +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
PS_xxK_STR +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
FALSE FALSE
PS_xxK_STR +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
PS_xxK_STR +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
FALSE FALSE
PS_xxK_STR +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
FALSE FALSE
PS_xxK_STR +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
PS_xxK_STR +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
PS_xxK_STR +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
PS_xxK_STR +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE FALSE
PS_39_2K_VoIP +
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
FALSE FALSE
PS_39_2K_VoIP +
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
PS_39_2K_VoIP +
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
TRUE
PS_xxK_STRxPS_HSD
SCHxSRB_3_4K
FALSE
TRUE
PS_39_2K_VoIPxPS_H
SDSCHxSRB_3_4K
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 47/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
/1
FALSE FALSE
PS_39_2K_VoIP +
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/2
/0
FALSE FALSE
PS_39_2K_VoIP +
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE FALSE
PS_39_2K_VoIP +
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE FALSE
PS_39_2K_VoIP +
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE FALSE
PS_39_2K_VoIP +
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/0
/0
FALSE
FALSE
0xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/0
/1
TRUE
TRUE
0xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/1
/0
TRUE
TRUE
1xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/1
/1
TRUE
TRUE
1xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
PS_HSDSCHxSRB_3_
4K
/2
/0
TRUE
TRUE
2xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/2
/1
FALSE
TRUE
2xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
/3
/0
FALSE
TRUE
3xPS_HSDSCH_IB +
0xPS_HSDSCH_STR +
SRB_3_4K
/3
/1
FALSE
FALSE
3xPS_HSDSCH_IB +
1xPS_HSDSCH_STR +
SRB_3_4K
Speech + E-DCH
CSD + E-DCH
PS Streaming + E-DCH
Note: if the related UlUserServcie are not allowed to be used by the RAB Matching,
there is no fallback on DCH, implying RAB Assignment Failure during RB
Setup.
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 48/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UE
Node B
RNC
SGSN
The RRC Connection Request message initiated
by the UE contains the establishment cause.
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 AlcatelLucent written authorization
Page 49/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
UE
Node B
RNC
SGSN
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete
Figure 6: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 50/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Node B
RNC
SGSN
"Common Id" is used to provide the RNC with the user IMSI
RANAP/ Common Id
RRC/ Security Mode Complete
The Radio Link is reconfigured to add the EDPCH in uplink in the serving cell. (The HSDSCH part is not shown)
NBAP/ Radio Link Reconfiguration Ready (E-DCH FDD info Response, E-DCH FDD DL
Control Channel
Figure 7: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 51/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
the HSDPA and associated HSUPA or UL DCH are released. A Radio Link
Deletion request is sent to each of the BTS being part of the active set,
including the BTS which supports the HS-DSCH.
the RNC attempts a Radio Link Reconfiguration to remove the HSDPA MAC-d
flow from the cell supporting it and
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 52/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Node B
RNC
SGSN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 53/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
9 RRM ALGORITHMS
9.1 ALWAYS-ON
9.1.1 MECHANISM
The Always-on mechanism applies to HSDPA in DL and E-DCH in UL the same way
as for R99 DCH radio bearers. Only Interactive/Background QoS traffic classes are
eligible to Always-on.
Note: Always-on does not apply if the Signaling Indication parameter of the RAB
Assignment Request associated with the Interactive RAB has been set to signaling.
In this case (example: Video Streaming signaling like RTSP protocol, or VoIP
signaling like SIP protocol), the RB will not be downsized nor released by Always-on.
Always-on allows to optimize radio resource usage for bursty traffic (low activity
factor), but at the same time shall take into account the limitation in terms of
simultaneous connected users on the traffic shared channels:
The monitoring of user activity at RLC level (DTCH) for both UL and DL is the same as
for R99. Nevertheless, some new parameters appear. Lets introduce them in the next
chapters.
no dedicated physical channel is allocated to the UE, hence the users have no
impact on the cell capacity and only consume RRC context resource.
Always-on controls a user session by introducing three states (see Figure 9: AO state
transitions):
X
Normal Mode: In this state the session is operating with the original
RB that was allocated at call admission or reconfigured by other PS
Call Management features (RB Adaptation, iRM Scheduling, iRM
Preemption). For a session to be maintained in this state, the user
traffic must remain above a predefined threshold: if it falls and stays
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 54/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
pre-defined
threshold
(from
Idle Mode: In this state the session has released all its radio
resources and the RRC context, but the PDP context is still
maintained by the Core Network. A session is downgraded to Idle
mode if there has been no user traffic for a given (provisionable)
period of time. This state is also known as AO Step 3 (and was
previously referred to as AO Step 2).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 55/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Normal mode
AO Step 1
AO Step 2
AO Step 3
Release
(Tinactivity expiry)
Downsizing
(Tdownsize expiry)
URA_PCH
Normal
mode
Idle
mode
CELL_FACH
Upsizing
(Traffic
resuming)
CELL_PCH
Downsized mode
RB R-establishment
(Traffic resuming)
(Tinactivity expiry)
Parameter
Range & Unit
User
Class
Value
Object
AlwaysOnConf
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 56/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isAlwaysOnAllowed
Boolean
{True, False}
Customer
3
See table below
User
Class
Value
Object
DlUserService
Granularity
DlUserService
DlUserService
CS_64KxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_64K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_128K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_256K_STRxPS_HSDSCHxSRB_3_4K
CS_AMR_NBxPS_HSDSCHxSRB_3_4K
PS_16K_STRxPS_HSDSCHxSRB_3_4K
PS_64K_STRxPS_HSDSCHxSRB_3_4K
PS_128K_STRxPS_HSDSCHxSRB_3_4K
PS_256K_STRxPS_HSDSCHxSRB_3_4K
PS_HSDSCHxSRB_3_4K
Parameter
Range & Unit
isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True
True
True
User
Class
Value
DlRbSetConf
PS_HSDSCH_IB
PS_HSDSCH_IB_MUX
DlRbSetConf
DlRbSetConf
isAlwaysOnAllowed
degraded2AlwaysOnOnly
releaseOnly
UlUserService
isAlwaysOnAllowed
Boolean
{True, False}
Customer
3
See table below
Object
UlUserService
Granularity
UlUserService
isAlwaysOnAllowed
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 57/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isAlwaysOnAllowed
True
True
True
True
True
True
True
True
True
Object
isAlwaysOnAllowed
Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
Customer
Granularity
3
See table below
User
Class
Value
UlRbSetConf
PS_EDCH
UlRbSetConf
UlRbSetConf
isAlwaysOnAllowed
degraded2AlwaysOnOnly
Parameter
Range & Unit
User
Class
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 58/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
9.1.3.2 MODES
The following modes are possible :
Step 1: The user is first downsized after a period T1 of low activity (or
inactivity). The associated timer for HSDPA and E-DCH is a new
parameter timerT1ForHsdpaAndEdch for UL E-DCH / DL HSDPA
and existing parameter timerT1ForHsdpa for UL DCH / DL HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 59/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Low activity /
Inactivity
Downsize
(step 1)
Downsize
(step 2)
Downsize
(step 3)
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH
CELL FACH
Downsize timer
Step 1
(timerT1ForHsdpa,
timerT1ForHsdpaAndEDch)
Downsize
timer
Step 2
(fachToCellPchTimer,
fachToUraPchTimer)
Downsize
timer
Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)
Traffic UL/DL
Figure 10: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates none)
When Cell/URA_PCH states are not activated, Always-on mechanism may use 1
or 2 steps for the downsize part (behaviour as before UA5.0)
In this mode, the Always-on feature first downsize the user to Always-on
CELL_FACH and perform the release in a second time.
The timers used are:
o timerT1ForHsdpa in case of HSDPA only
o timerT1ForHsdpaAndEdch in case HSDPA & DCH are both activated.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 60/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Low activity /
Inactivity
Downsize
Release
Inactivity
HSDPA + UL DCH
HSDPA + E-DCH
Downsized RB (CELL_FACH)
Downsize
timer
(timerT1ForHsdp
timerT1ForHsdpaAndEDch)
Release timer
(timerT2)
Traffic UL/DL
In this mode, the Always-on feature directly releases the user after a period T2 of
inactivity. The timers used are:
o timerT2ForHsdpa in case of HSDPA only
o timerT2ForHsdpaAndEdch in case HSDPA & DCH are both activated.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 61/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Low activity
Inactivity
Release
HSDPA + UL DCH
HSDPA + E-DCH
t
Release timer
(timerT2ForHsdpa
timerT2ForHsdpaAndEDch)
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).
DCH
DL
HSDPA)
or
9.1.3.4 UPSIZE
For Always-on upsize, the mechanism and the parameters are the same as for R99.
When upsizing to HSDPA or E-DCH and no resource are available (in case of CAC
failure), the call will be released.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 62/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
T1 ( => CELL_FACH)
T2 ( => Idle)
timerT1ForHsdpa
timerT1ForHsdpaAndEDch
timerT2
NA
timerT2ForHsdpa
timerT2ForHsdpaAndEDch
Always-on mode
T1 ( =>CELL_FACH)
T2 ( => Idle)
timerT2ForHsdpa
Always-on mode
T1 ( => CS + PS8)
T2 ( => CS)
NA
timerT2ForHsdpa (1)
timerT2ForHsdpaAndEDch
HSDPA / E-DCH
HSDPA / DCH
CS + PS I/B (Mux) + SRB
D
HSDPA / E-DCH
(1)
timerT2ForHsdpa (1)
timerT2ForHsdpaAndEDch
NA
P
P
(1)
P
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 63/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
T1 (=> CELL_FACH)
T2 (=> Cell/URA_PCH)
T3 (=> Idle)
timerT1ForHsdpa
fachToCellPchTimer/
timerT1ForHsdpaAndEdch fachToUraPchTimer
cellPchToIdleTimer/
uraPchToIdleTimer
NA
timerT2forHsdpa
timerT2forHsdpaAndEdch
HSDPA / E-DCH
NA
HSDPA / DCH
T1 (=> CELL_FACH)
T2 (=> Cell/URA_PCH)
tDchPchMpdpForHsdpaAndDc
h (1)
T3 (=> Idle)
uraPchToIdleTimer/
cellPchToIdleTimer
T1 (=> CS+PS8)
T2 (=> CS + PS 0)
T3 (=> Idle)
timerT2ForHsdpa
timerT2ForHsdpaAndEDch
uraPchToIdleTimer/
cellPchToIdleTimer
NA
timerT2ForHsdpa
timerT2ForHsdpaAndEDch
timerT2ForHsdpaAndDch
uraPchToIdleTimer/
cellPchToIdleTimer
HSDPA / E-DCH
HSDPA / DCH
(Mux)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 64/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Parameter
timerT1ForHsdpa,
timerT1ForHsdpaAndEdch
[10..3600000] (ms)
Customer
3
10000
Object
AlwaysOnTimer
Granularity
OLS
Parameter
Range & Unit
User
Class
Value
Object
AlwaysOnTimer
Granularity
OLS
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 65/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
timerT2ForHsdpa,
timerT2ForHsdpaAndEdch
[10..10800000] (ms)
Customer
3
10000
Object
AlwaysOnTimer
Granularity
OLS
Note: The timerT2ForMultiRabHsdpa was used in UA5.x, since Ua6 this timer is replaced by
TimerT2ForHsdpa
The uraPchToIdleTimer and the cellPchToIdleTimer are used for the downsizing
respectively from URA_PCH and CELL_PCH to Idle state.
Parameter
Range & Unit
User
Class
Value
uraPchToIdleTimer,
cellPchToIdleTimer
[1..7200] (min)
Customer
3
60
Object
AlwaysOnTimer
Granularity
OLS
Parameter
Range & Unit
User
Class
Value
nbOfCellUpdatesFromCellPchToUraPch
[1..65535]
Customer
3
1
Object
RadioAccessService
Granularity
RNC
Engineering Recommendation:
As soon as the mobility is detected, the user is moved to URA_PCH. Static users will stay in
CELL_PCH state and will be able to be paged only on their cell (location known at cell level in
CELL_PCH state while location is known at URA level in URA_PCH state).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 66/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
However, as it is possible to reserve some power for HSDPA users, this power shall
be consider as consumed in cell color calculation for the HSDPA cells.
In the same way, OVSF codes reserved for HS-PDSCH and HS-SCCH are
considered to be used in the cell color calculation.
In UA6.0, when the feature Fair Sharing is activated, OVSF codes load is computed
following the usual formula:
Code _ Load = 1
1
NumberOfFr eeCodesPerSpreadingF actor n * SF / 16
*
NumberOfSp readingFactors All _ SF
SF
Where n*SF/16 represents the codes that are reserved for HSDPA users at SF level
(n being a number of SF16 codes).
when feature Dynamic Code tree management is deactivated, the formula used is the following:
Code _ Load = 1
NumberOfFreeCodesPerSpreadingFactor
1
*
NumberOfSpreadingFactors All _ SF
SF
when the feature Dynamic Code tree management is activated (see [Vol. 3] for details), the code load is
computed according to the following formula:
X
Code _ Load = 1
1
*
NumberOfSpreadingFactors All _ SF
NumberOfFreeCodesPerSpreadingFactor
+ Ceil ( NumberOfSF16CodesAllocatedToHsPdsch SF
16
Ceil (minNumberOfHsPdschCodes SF
16
SF
Where Ceil(x), is the function that rounds to the nearest integer equal or greater than x (because SF/16 can be
fractional).
Then, in UA5.0, there is a fixed number of SF 16 codes reserved for HSDPA (minNumberOfPdschCodes).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 67/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Moreover, the iRM thresholds can be tuned independently from the HSDPA
configuration.
The operator may tune iRM thresholds so that color turns yellow before stealing HSDSCH codes and red before having stolen all HS-DSCH codes.
For more details see UTRAN Parameters Used Guide [R01]
X
On the Iub, the Iub load color takes into account the actual traffic on the link on a
selected set of VCC QoS, so may include or not HSDPA traffic according to operators
provisioning.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 68/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Dedicated
Eligible CAC
Failures
Shared
1 Steps / 2 Steps
Eligible
Services
R99
Preemption
RAB Assignment
Queuing allowed
HSUPA
HSDPA
Speech
; Preemption
Video telephony
Capability
CS Streaming
Always-on Upsize
Radio Link Addition
Emergency Call
PS Streaming
Queuing not
Signaling PS Interactive
allowed
PS Interactive
; Preemption
Vulnerability
; Priority (*)
PS Background
Eligible
procedures
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 69/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Preemption
33694
Fair sharing of
resources
29804
GBR on HSDPA
A HS-DSCH resource allocation failure will trigger the pre-emption of HSDSCH user(s)
From UA6.0, at RNC level, with the introduction of the Fair-sharing feature, the OVSF
Codes and DL Power resources are managed as 1 pool shared by DCH and HSDPA
calls.
Example 1 : the incoming user is R5 on a HSDPA capable cell (and not HSUPA
capable)
The CAC failure is DL and at RNC level : the preempted users will be either
UL DCH / DL DCH or UL DCH / DL HSDPA
The CAC failure is DL at Node B level : the preempted users will be either UL
DCH / DL HSDPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 70/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The CAC failure is UL : the preempted users will be either UL DCH / DL DCH
or UL DCH / DL HSDPA
The CAC failure is DL and at RNC level : the preempted users will be either
UL DCH / DL DCH or UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is DL at Node B level : the preempted users will be either UL
DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is UL : the preempted users will be either UL DCH / DL DCH
or UL DCH / DL HSDPA
The CAC failure is DL and at RNC level : the preempted users will be either
UL DCH / DL DCH or UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The CAC failure is DL and at Node B level : the preempted users will be either
UL DCH / DL HSDPA or UL E-DCH / DL HSDPA
The list of elligible users is ordered according to service priority and OLS.
iMCTA
Preemption
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 71/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
32602
HSxPA to DCH
fallback
29415
iMCTA CAC &
Alarm
33322
Preemption
Note : The HsxPA to DCH fallback is exclusive with Fair-sharing when the CAC failure
is DL Power or OVSF Codes.
U
HSDPA
E-DCH
There is no specific flag for DCH : when the feature is activated (at RNC and Cell
level), the preemption for DCH is activated by default.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 72/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
isPreemptionAllowedForHsdpa: This parameter is used to activate/deactivate pre-emption process for UL DCH/DL HSDPA calls.
Parameter
isPreemptionAllowedForHsdpa
Object
PreemptionAllowedInfo
Granularity
RNC
Customer, Class 3
Value
isPreemptionAllowedForEdch: This parameter is used to activate/deactivate pre-emption process for UL E-DCH / DL HSDPA.
Parameter
isPreemptionAllowedForEdch
Object
PreemptionAllowedInfo
Granularity
RNC
Customer, Class 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 73/74
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 74/74
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
MOBILITY
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
CONTENTS
1
INTRODUCTION............................................................................................................................5
1.1
OBJECT ....................................................................................................................................5
1.2
2.2
3.2
3.3
3.3.1
E-DCH Mobility in UA5 (Macro Diversity not supported) ..............................................10
3.3.1.1
Cell addition to DCH AS and Primary Cell change procedures for E-DCH calls ..... 10
3.3.1.2
E-DCH Mobility in UA5: Main characteristics ........................................................... 11
3.3.2
UA6 32076 E-DCH Macro Diversity Support..............................................................12
3.3.2.1
Feature description................................................................................................... 12
3.3.2.2
Parameter settings and recommendations............................................................... 17
3.4
FULL EVENT SHO SETTING FOR HSXPA..................................................................................23
3.5
3.5.1
HSDPA OVER IUR .......................................................................................................26
3.5.2
HSUPA OVER IUR .......................................................................................................27
3.6
INTRA-FREQUENCY INTER-RNC HHO......................................................................................31
4
4.1.1
Feature Description.......................................................................................................33
4.1.2
Compressed Mode Configuration .................................................................................33
4.1.3
Transmission Gap Patterns evaluation .........................................................................35
4.1.4
Compressed frames management................................................................................35
4.2
COMPRESSED MODE IN MAC-E ...............................................................................................36
4.2.1
Compressed Mode for E-DCH in UA5.0 .......................................................................36
4.2.2
Compressed Mode for E-DCH in UA5.1 .......................................................................38
4.3
RNC DEFENSE MECHANISM AGAINST UES NOT SUPPORTING HSDPA OR E-DCH COMPRESSED
MODE 41
5
5.1.1
Inter-Frequency intra-RNC Mobility for HSxPA.............................................................45
5.1.2
Inter-Frequency inter-RNC without Iur Mobility for HSxPA...........................................46
5.1.3
Inter-Frequency inter-RNC with Iur Mobility for HSxPA................................................47
5.1.4
Full Event HHO setting for HSxPA................................................................................48
5.2
INTER-SYSTEM MOBILITY FOR HSXPA.....................................................................................49
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
6
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
TABLES
Table 1: SHO Event Recommended Settings Summary
Table 2: HHO Event Recommended Settings Summary
25
48
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
FIGURES
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case) ........................... 9
Figure 2: E-DCH link is deleted and re-established on new Primary Cell (nominal case) ...................... 11
Figure 3: E-DCH macro diversity general principle ....................................................................................... 13
Figure 4: OMC-R RAN model for UA6 32076 ................................................................................................ 18
Figure 5: OMC-B RAN model for UA6 32076 ................................................................................................ 18
Figure 6: Transmission of E-DPDCH (10ms TTI) when in CM operation .................................................. 36
Figure 7: Summary matrix for E-DCH Compressed Mode support ............................................................ 40
Figure 8: Example of Inter-frequency and Inter-System scenario............................................................... 51
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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
recommendations.
description,
configuration
aspect
and
engineering
PM ID
27935
Activation flag
Release
Global
marke
t
US
Market
isRedirectionBasedOnEstablishmentC
ause
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA4.2
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.0
Yes
Yes
UA5.1
Yes
Yes
Feature Title
RRC Traffic
Segmentation
isRedirectionForTrafficSegmentation
Automatic/Available
check if
at
Upgrade
27936
Automatic/Available at Upgrade
27937
HSDPA
Alarm
Mobility - inter RAT:
3G to 2G only and
blind
29802
isHsdpaHhoWithMeasAllowed
but
isRLCReconfigurationForChannelType
Switching
isHsdpaAllowed
29817
isHsdpaOverIurAsDrncAllowed
isHsdpaOverIurAsSrncAllowed
isGsmCModeActivationAllowed
29798
Compressed Mode in
MAC-hs
isInterFreqCModeActivationAllowed
isInterFreqMeasActivationAllowed
isPatternAllowed
33480
Compressed Mode in
MAC-e Scheduler
[iBTS]
No activation flag.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Compressed Mode for HSPA calls can be
activated/deactivated via
isInterFreqCModeActivationAllowed
and isGsmCModeActivationAllowed
(for DL services with HSDPA).
34012
isMacShHsdpaAllowed
UA5.1
Yes
Yes
UA6.0
Yes
Yes
UA6.0
Yes
Yes
isInterFreqHandoverOverIurAllowed
UA6.0
No
Yes
isEdchAllowed
isEdchOverIurSrncAllowed
isEdchOverIurDrncAllowed
UA6.0
Yes
No
UA6
Yes
No
No activation flag.
32076
34167
34229
E-DCH Macro
Diversity Support
Defense mechanism
for UEs not
supporting CM with
HSPA
Inter Freq HO
Enhancements
isEdchCmFallbackAllowed
30744
84900
Traffic Segmentation
between HSPA
Layers by RRC
Redirection
isHSDPACMFallbackAllowed
layerPreferredForR99
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment Scenarios
[R02] UMT/SYS/DD/013319
[R04] UMT/BTS/INF/016135
Planning Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 7/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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:
HCS feature while in Idle, PCH and Cell FACH states (refer to UPUG [R01])
If the former primary cell is no longer present in the new Active Set (following
an Active Set Update procedure), the new HS-DSCH radio link is setup
using a normal Synchronized RL Reconfiguration procedure on the new
primary cell and HS-DSCH radio link is immediately released on the old
primary cell (NBAP RL Deletion) before the RRC Measurement Control
procedure is sent with parameters relevant to the HSDPA mobility.
If the former primary cell remains in the Active Set, the HS-DSCH RL is
deleted on the former primary just after the RRC Measurement Control
procedure is sent, and it is re-established under the new one synchronously
via the RRC RB Reconfiguration message.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
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; 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).
Data that were in the MAC-hs buffer of the former cell are discarded (except if both
cells are managed by the same H-BBU board). User data are not lost thanks to RLC
retransmissions but if the primary cell changes too often, the data throughput can be
impacted.
RNC
Node B
source
Node B
target
UE
Activation CFN
RB Reconfiguration Complete
Figure 1: HS-DSCH link is deleted and re-established on new primary (nominal case)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Engineering Recommendation:
In case of TMA usage, externalAttenuationMainDivUL/DL values need to be accurately filled with
cable losses. Otherwise, HSDPA mobility can be highly impacted (UL reception asymmetry for soft
handover).
If the old Primary Cell was E-DCH and not the new one, the RB is
reconfigured to DCH.
If the old Primary Cell was not E-DCH but the new one is, the RB is
reconfigured to E-DCH.
If the new Primary Cell is E-DCH and the call was E-DCH, then call is kept on
E-DCH.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
RNC
Node B
source
Node B
target
UE
Activation CFN
RB Reconfiguration Complete
Figure 2: E-DCH link is deleted and re-established on new Primary Cell (nominal case)
The E-DCH active set (AS) includes only 1 cell, i.e. the E-DCH serving cell.
As of 3GPP, the E-DCH serving cell is the same as the HSDPA serving cell. As of
Alcatel-Lucent implementation, the E-DCH serving cell is the same as the Primary
Cell, i.e. the best cell on a CPICH criterion.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
controlled by the target cell. In this case, UE Tx power is driven down by the target
cell, which leads the UL SIR at current serving NodeB (i.e. source NodeB) to become
too low for E-DPDCH decoding. This results in HARQ retransmissions on E-DCH and
thus E-DCH user throughput degradation.
In UA6, inter NodeB E-DCH mobility is performed smoothly thanks to UA6 32076 EDCH Macro Diversity Support feature, which allows decoding E-DPDCH
simultaneously at source NodeB and target NodeB.
For a given E-DCH call, multiple E-DCH radio links can be decoded
simultaneously by multiple NodeBs.
For a given E-DCH call, the E-DCH AS is the set of cells for which an
E-DCH radio link is configured
For each NodeB involved in the E-DCH call, the E-DCH signals received from a
given UE are combined via Maximum Ratio Combining (MRC) method before
being processed. The combined signals are all the E-DCH signals received on the
cells of this NodeB that are included in the DCH AS.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 12/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
For each E-DCH cell, the UL noise rise generated by E-DCH nonserving radio links is monitored
If the UL noise rise from E-DCH non-serving radio links is too high,
Down RG is sent to non-serving UEs
Iub
Iub
E-DCH non-serving
NodeB:
NodeB that does not
include the E-DCH
serving cell
All E-DCH signals
received from UE are
MRC combined before
being processed.
E-HICH:
Same E-HICH
information is
transmitted to UE on all
cells of the considered
non-serving
NodeB included in
E-DCH AS.
Only ACK E-HICH
is allowed.
E-RGCH:
Only Down RG
is allowed.
RNC:
Iub E-DCH Data Frame selection:
For a given CFN, multiple E-DCH Data Frames may be
received from different NodeBs. First correctly received
Data Frame is selected, others are discarded.
MAC-es PDU reordering:
MAC-es PDUs may arrive at RNC out of order, due to
possible MAC-e PDU loss on a given HARQ process, and/or
due to E-DCH Macro Diversity.
The E-DCH active set may include multiple cells; the E-DCH AS is included in the
DCH AS, and may include up to 4 cells (as of 3GPP)
At E-DCH radio bearer establishment, the E-DCH AS is created and includes only 1
cell: the E-DCH serving cell, i.e. the Primary Cell (Alcatel-Lucent implementation)
From E-DCH RB establishment, any cell added to the DCH AS is added to the E-DCH
AS as well, provided that the following conditions are fulfilled.
o
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
o
The cell to be added supports the current {E-DCH TTI, E-DPDCH minimum
SF, E-DCH HARQ type} configuration of the considered E-DCH call.
All cells removed from the DCH AS and present in the E-DCH AS are also removed
from the E-DCH AS
If the new Primary Cell does not support current {E-DCH TTI, E-DPDCH min
SF, E-DCH HARQ type} configuration:
If the new Primary Cell does not support E-DCH, the E-DCH RB is
reconfigured to UL DCH.
For a given E-DCH call, {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}
configuration is common to all E-DCH radio links.
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type} configuration is determined
by RNC at the beginning of the E-DCH call, basing on UE and E-DCH serving
NodeB capabilities.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
{E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type} configuration must always
match the E-DCH serving cell (i.e. the Primary Cell) capabilities. Consequently, at
Primary Cell change, {E-DCH TTI, E-DPDCH min SF, E-DCH HARQ type}
configuration is changed to match E-DCH capabilities of the new Primary Cell (if
E-DCH capabilities changed).
For a given E-DCH call, the {Ref E-TFCI; Ref PO} table is common to all the EDCH radio links.
The {Ref E-TFCI; Ref PO} table is selected by RNC at the beginning of the E-DCH
call, and updated at Primary Cell change, basing on the following attributes of the
call:
o
iCEM/xCEM specificities:
[iCEM] [xCEM] For the iBTS, iCEM and xCEM capabilities are different regarding EDCH 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 handling E-DCH on the E-DCH serving cell.
Example:
UE: HSUPA Category 5, IR E-DCH HARQ type supported:
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.
Page 15/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
[iCEM]
An E-DCH non-serving radio link is decoded only if there is free a Modem/CRCP (i.e.
Modem/CRCP not handling any E-DCH radio link yet), on iCEM E-BBU.
[xCEM] [UCU-III] Basically, E-DCH non-serving radio links are always decoded.
If the board decoding capacity (7.7Mbps for xCEM and 4Mbps for UCU-III, at MAC-e
level) is reached due to high E-DCH traffic:
1/ Decoding of E-DCH non-serving radio links is stopped (MAC-e PDU discard)
2/ If the number of discarded MAC-e PDUs exceeds a certain threshold, a CE
Overload indication is sent to the MAC-e scheduler. This results in a reduction of the
target E-DCH load and thus in Down RG commands sent to the E-DCH UEs.
[iCEM]
If
> targetNonServingToTotalEDCHPowerRatio
With
E DCH Rx Power Non Serving : E-DCH power received at NodeB antenna of the
considered cell from non-serving radio links (for which this cell is or is not
under the serving NodeB).
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:
Common RG are used for UEs for which this cell is not under the serving
NodeB
Dedicated RG are used for UEs for which this cell is under the serving
NodeB
[xCEM] [UCU-III]
If
>
targetNonServingToTotalEDCHPowerRatio
With
E DCH Rx Power Non Serving RLs of Non Serving NodeB : E-DCH power received at
NodeB antenna of the considered cell from non-serving radio links for which
this cell is not under the serving NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Then common Down RG commands are sent from this cell to non-serving UEs for
which this cell is not under the serving NodeB
If
> edchSofterHoLimit
With
E DCH Rx Power Non Serving RLs of Serving NodeB : E-DCH power received at NodeB
antenna of the considered cell from non-serving radio links for which this cell
is under the serving NodeB.
Then dedicated Down RG commands are sent from this cell to non-serving UEs for
which this cell is under the serving NodeB.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
parameter : same or similar parameter already present in UA5.1
parameter : new parameter from UA6
Object :
new object from UA6
RNC
RadioAccessService
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed
DedicatedConf
FDDCell
targetNonServingToTotalEdchPowerRatio
EdchRncConf
maxNumberOfRlEdch
HoConfClass 15
UsHoConf/
PsHSDPA
CsSpeechPlusHSDPA
NodeB
Number
of
instances
(indicated
when > 1)
MeasurementConfClass 15
FullEventHoConfShoMgt
FullEventRepCritShoMgt
FullEventHoConfShoMgtEvent1J
hysteresis1J
timeToTrigger1J
FullEventRepCritShoMgtEvent1J
amountRep1J
maxNbReportedCells1J
repActThresh1J
repInterval1J
NodeBConfClass 15
iubEdchDelayVariation
[xCEM] [UCU-III]
Below figure shows the RAN model at OMC-B.
Remark: All below parameters only apply to xCEM or UCU-III (i.e. not used by iCEM).
parameter : same or similar parameter already present in UA5.1
parameter : new parameter from UA6
Object :
new object from UA6
BTSEquipment
OneBTSEquipment
eDCHSofterHOLimit
commonERGCHPowerOffset
eDCHNumCommonRGPerCode
BTSCell
EdchConf
edchSofterHoLimit
nonServingEHICHPowerOffset
commonERGCHPowerOffset
edchNumCommonRgPerCode
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
3.3.2.2.3 OMC-R PARAMETERS
isEdchRlAddOrSetupDefenseAllowed: Flag enabling to try to add a given cell in
DCH AS just after failing to add this cell in DCH AS and E-DCH AS simultaneously.
Parameter
isEdchRlAddOrSetupDefenseAllowed
Object
RadioAccessService
Granularity
RNC
Customer, 3
Value
True
isRrcEdchEvent1JAllowed: Flag enabling the configuration of Event 1J, when FullEvent Triggered reporting of measurements mode is used for intra-frequency mobility.
Parameter
isRrcEdchEvent1JAllowed
Object
RadioAccessService
Granularity
RNC
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].
Parameter
targetNonServingToTotalEdchPowerRatio
Object
FDDCell
Granularity
FDDCell
Integer [0 100], %
Customer, 2
Value
25
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
maxNumberOfRlEdch: Maximum E-DCH active set size (i.e. maximum number of EDCH RLs allowed per UE). Used to activate/deactivate UA6 32076 E-DCH Macro
Diversity Support (maxNumberOfRlEdch = 1: feature deactivated).
Remark: In UA5, since E-DCH macro diversity is not supported, it is mandatory to set
maxNumberOfRlEdch to 1.
Parameter
maxNumberOfRlEdch
Object
EdchRncConf
Granularity
RNC
Customer, 3
Value
iubEdchDelayVariation
Object
NodeBConfClass
Granularity
NodeBConfClass
Customer, 3
Value
[iCEM] [xCEM] 5
[UCU-III] 3
hysteresis1J
Object
FullEventHoConfShoMgtEvent1J
Granularity
HoConfClass, UsHoConf
Customer, 3
Value
3.0
timeToTrigger1J
Object
FullEventHoConfShoMgtEvent1J
Granularity
HoConfClass, UsHoConf
Enum {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,
5000}, ms
Customer, 3
Value
100
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
amountRep1J: Amount of periodical reports, after an Event 1J Measurement Report
has been triggered.
Parameter
amountRep1J
Object
FullEventRepCritShoMgtEvent1J
Granularity
MeasurementConfClass
Customer, 3
Value
Infinity
maxNbReportedCells1J
Object
FullEventRepCritShoMgtEvent1J
Granularity
MeasurementConfClass
Customer, 3
Value
[iCEM] [xCEM] 3
[UCU-III] 6
repActThresh1J
Object
FullEventRepCritShoMgtEvent1J
Granularity
MeasurementConfClass
Customer, 3
Value
repInterval1J
Object
FullEventRepCritShoMgtEvent1J
Granularity
MeasurementConfClass
Customer, 3
Value
500
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
3.3.2.2.4 OMC-B PARAMETERS
[xCEM] [UCU-III]
Remark: All below parameters only apply to xCEM or UCU-III (i.e. not used by iCEM).
edchSofterHoLimit: Maximum allowed ratio of [E-DCH Rx power (at NodeB antenna
of considered cell) from non-serving RLs of serving NodeB] to [total E-DCH Rx power].
Parameter
[xCEM] edchSofterHoLimit
[UCU-III] eDCHSofterHOLimit
Object
[xCEM] EdchConf
[UCU-III] OneBTSEquipment
Granularity
[xCEM] BTSCell
[UCU-III] OneBTSEquipment
Integer [0 100], %
Customer, 3
Value
40
nonServingEHICHPowerOffset
Object
EdchConf
Granularity
BTSCell
Customer, 3
Value
0.0
[xCEM] edchNumCommonRgPerCode
[UCU-III] eDCHNumCommonRGPerCode
Object
[xCEM] EdchConf
[UCU-III] OneBTSEquipment
Granularity
[xCEM] BTSCell
[UCU-III] OneBTSEquipment
Customer, 3
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
commonERGCHPowerOffset: For E-DCH RLs of non-serving NodeB(s), power
offset of E-RGCH signature relative to CPICH Tx power.
Remark: For non-serving NodeB, only common RG commands are used.
Parameter
commonERGCHPowerOffset
Object
[xCEM] EdchConf
[UCU-III] OneBTSEquipment
Granularity
[xCEM] BTSCell
[UCU-III] OneBTSEquipment
Customer, 3
Value
0.0
Parameter
Range & Unit
User
Class
Value
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Previous ETP lead 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
timeToTrigger1D = 1280 ms
The following rule has applied since UA5 regarding HSDPA multi-service UsHoConfs:
Rule: SHO setting for HSDPA multi-service UsHoConfs
A specific rule must be defined for the SHO settings of the HSDPA multi-service UsHoConfs:
FET
parameters
have
moved
between
HoConfClass
and
Prior to UA6, timeToTriggers and hysteresis used to be defined under MeasurementConfClass i.e.
common whatever DlUserService.
In UA6, each timeToTriggers and hysteresis are now located under HoConfClass i.e. per
mobilityServiceType.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
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).
Event
mobilityServiceType
Parameter
Object
PsHSDPA
1A
Others with
HSDPA
3.5 dB
cpichEcNoReportingRange1A
4.5 dB
FullEventHOConfShoMgtEvent1A
200 ms
timeToTrigger1A
1B
5.5 dB
cpichEcNoReportingRange1B
7.5 dB
FullEventHOConfShoMgtEvent1B
1280 ms
timeToTrigger1B
1C
hysteresis1C
7.5 dB
FullEventHOConfShoMgtEvent1C
timeToTrigger1C
1D
320 ms
hysteresis1D
FullEventHOConfShoMgtEvent1D
timeToTrigger1D
6 dB
6 dB
1280 ms
640 ms
useCioFor1D
1E
False
isEvent1EUsed
FullEventHOConfShoMgt
cpichEcNoThresholdUsedFreq1E
False
-11 dB (N.S.)
FullEventHOConfShoMgtEvent1E
timeToTrigger1E
1F
100 ms (N.S.)
isEvent1FUsed
FullEventHOConfShoMgt
cpichEcNoThresholdUsedFreq1F
True
-15 dB
FullEventHOConfShoMgtEvent1F
timeToTrigger1F
640 ms
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
3.5 INTRA-FREQUENCY MOBILITY OVER IUR
3.5.1 HSDPA OVER IUR
HSDPA over Iur capability is required in both SRNC and DRNC to allow the handling
of the configuration, maintenance and release of active HSDPA calls over Iur. In
HSDPA mode, the SRNC configures one radio link to the UE with HS-DSCH specific
information.
As a SRNC:
o
As a DRNC:
o
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 Error!
Reference source not found. for further details on Iub congestion management.
Restriction: HSDPA over Iur with non Alcatel-Lucent RNC
HSDPA over Iur is not guaranteed when facing non Alcatel-Lucent RNC (for details refer to [R02]).
Therefore, in such cases, on Alcatel-Lucent serving RNC, the neighbour RNC should be provisioned
as non HSDPA capable, unless successful IOT has been performed with the other vendor.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 26/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
3.5.2 HSUPA OVER IUR
From UA6.0, HSUPA over Iur is supported with the introduction of the feature 30744
(feature only available for Global Market). HSUPA over Iur capability is required in
both SRNC and DRNC to allow the handling of the configuration, maintenance and
release of active HSUPA calls over Iur.
If the HSUPA over Iur is not supported or deactivated on SRNC or DRNC, the system
will behave similarly as in UA5: While HSUPA running, if the primary cell goes under
the control of a DRNC then the SRNC will consider that the new primary is not E-DCH
capable and, as such, will perform an UL Transport Channel type switching to DCH
whereas DL HS-DSCH is properly reconfigured over Iur (in case HSDPA over Iur is
provisioned); In UA6 if E-DCH over IuR is not supported then also no non-serving
(non-primary) E-DCH link must 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, its recommended to set the edch capabilities,
under remoteFddCell object, in line with the real cell capabilities otherwise, we can
use these parameters to downgrade the drift cell capabilities in order to limit the edch
traffic over Iur or to deactivate completely the edch over Iur toward some specific drift
cells. We can for example limit the edch over Iur to CAT3 by setting the TTI
capabilities to 10ms and Min SF capabilities to 2SF4 even if the drift cell is 2ms
capable and supporting 2SF2+2SF4.
In case of HSUPA over Iur, the DRNC is responsible for the Iub edch bandwidth
limitation management for the drift BTS
The DRNC detects the edch congestion based on edch frame loss as
described in HPUG volume 4.
The DRNC discard the TNL congestion messages received from the SRNC.
Note that in UA6.0, the Iur edch bandwidth limitation is not supported thats why its
highly recommended to activate the SRNS relocation in case of limited Iur capacity so
that the Iur resources will be released as soon as the call moves completely to the
DRNC (i.e no more serving cell in the active set).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Restriction:
In UA6.0, the Iur edch bandwidth limitation is not supported thats why its highly
recommended to activate the SRNS relocation in case of limited Iur capacity so that the Iur
resources will be released as soon as the call moves completely to the DRNC (i.e no more
serving cell in the active set).
Also, E-DCH to E-DCH inter-freq mobility over Iur cases is not supported. A UE involved
relocation is triggered by the SRNC instead of an 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:
Parameter
Range & Unit
User
Class
Value
isHsdpaOverIurAsSrncAllowed
Boolean
{True, False}
Customer
3
True
Parameter
Range & Unit
User
Class
Value
User
Class
Value
RNC
Object
RadioAccessService
Granularity
RNC
to
isEdchOverIurSrncAllowed
Boolean
{True, False}
Customer
3
True
Parameter
Range & Unit
Object
RadioAccessService
Granularity
RNC
isHsdpaOverIurAsDrncAllowed
Boolean
{True, False}
Customer
3
True
Object
RadioAccessService
Granularity
RNC
to
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Parameter
Range & Unit
User
Class
Value
isEdchOverIurDrncAllowed
Boolean
{True, False}
Customer
3
True
Parameter
Range & Unit
User
Class
Value
RadioAccessService
Granularity
RNC
isMacShHsdpaAllowed
Boolean
{True, False}
Customer
3
True
Object
RadioAccessService
Granularity
RNC
Parameter
Range & Unit
User
Class
Value
isHsdpaAllowed
Boolean
{True, False}
Customer
3
True
Parameter
Range & Unit
User
Class
Value
NeighbouringRNC
Granularity
RNC
isEdchAllowed
Boolean
{True, False}
Customer
3
True
Object
NeighbouringRNC
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Parameter
Range & Unit
User
Class
Value
isHsdpaAllowed
Object
RemoteFddCell
Granularity
Cell
False, True
Customer
3
True
See also the following rule.
Parameter
Range & Unit
User
Class
Value
Object
RemoteFddCell
Customer
Granularity
3
Depends on remote cell capabilities. Default value: 2sf4.
Parameter
Range & Unit
User
Class
Value
Cell
Object
RemoteFddCell
Granularity
Cell
False, True
Customer
3
True
See also the following rule.
Parameter
Range & Unit
User
Class
Value
Object
RemoteFddCell
False, True
Customer
Granularity
3
Depends on remote cell capabilities. Default 10ms.
Cell
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: primary scrambling code but also 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.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 30/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Rule: Coherency for RemoteFddCell.isHsdpaAllowed & RemoteFddCell.isEdchAllowed on all
RNCs
A cell, declared as neighbour of several cells (belonging or not to the same RNC), must have the
same value for RemoteFddCell.isHsdpaAllowed and RemoteFddCell.isEdchAllowed activation
flag otherwise PS call may be abusively reconfigured to DCH following a SHO over Iur.
Iur is NOT provisioned between both RNCs (e.g. due to IOT reasons between
different manufacturers or during swap process)
Parameter
Range & Unit
User
Class
Value
HSDPA to DCH
DCH to DCH
isHsdpaHhoWithMeasAllowed
Boolean
{True, False}
Customer
3
TRUE
Object
RadioAccessService
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 31/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Parameter
Range & Unit
User
Class
Value
When set to False, this parameter prevents any Intra-RNC HHO to EDCH, and only the 2 following transitions can then occur for UL
Transport Channel:
E-DCH to DCH
DCH to DCH
isEdchHhoWithMeasAllowed
Boolean
{True, False}
Customer
3
TRUE
Object
RadioAccessService
Granularity
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Note that the two first parts are also applicable to HSUPA.
Restriction: Higher Layer Scheduling (HLS) method not supported with HS-DSCH or E-DCH
In UA6, HLS has been introduced so that 2 different methods are now supported for the gap creation:
SF/2 and HLS.
Note that in UA6, for any DL configuration with an HS-DSCH or E-DCH, HLS CM method shall not
apply.
Refer to [R01] for further details on CM measurements.
Note:
isCmHlsAllowedWithEdch and
isCmSfo2AllowedWithEdch
under
EdchRncConf object have been present in RAN Model since UA5 but are still NOT
used for Compressed Mode purpose.
Page 33/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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, after or at the
same time of both or only one of these two 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 inform
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 TGP [Id] (only if on going or on going + not started state). Fits in
the range [0..TGPRC-1].
[Id] means that this information must be provided for each configured pattern.
1
[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 AlcatelLucent written authorization
Page 34/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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 HBBU must retrieve position in current pattern and continue to evaluate it until
CMCFN. Then the new APSI will be taken into account.
when his ACK/NACK will overlap with an UL transmission gap. As the forecast
of this event is tricky, the decision is done with the DL pattern (if processing is
at a frame level) by assuming that UL and DL are often synchronous.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 35/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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:
0.66ms slot
10ms E-DCH TTI
0 1 2 3 4 5 6 Tx Gap 11121314
First HARQ transmission
Page 36/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
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 behavior description for UA5.0 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 AlcatelLucent written authorization
Page 37/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
4.2.2 COMPRESSED MODE FOR E-DCH IN UA5.1
UA5.0-UA5.1 Delta: Compressed MAC-e PDUs decoded by Node-B from UA5.1
From UA5.1, Compressed Mode for E-DCH is fully supported by the Node-B via Compressed Mode in
MAC-e Scheduler (33480) feature. Data sent by an E-DCH CM-compliant UE on E-DCH under the EDCH Compressed Mode format for E-DCH 10 ms TTI specified by 3GPP [R03] are correctly decoded
by the Node-B.
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, 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 UA5.1 RAN
Model (edchCMActivation parameter under BTSEquipment object). However, this
flag is not active anymore, i.e. 33480 feature is always activated. In other words, in
UA5.1 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 and E-HICH transmission method when CM
reception gaps occur is not modified (compared to the no CM case).
The solution presented here applies only to E-DCH with 10ms TTI (E-DCH with 2ms
TTI is not commercially available in UA5.1).
UPLINK
UE NOT SUPPORTING E-DCH COMPRESSED MODE
If for any reason, a UE not supporting E-DCH Compressed Mode is made entering
CM operation while an E-DCH call is established, any MAC-e PDU that is transmitted
over a gapped TTI can not be decoded by the Node-B, since data is corrupted by the
gap. However, since the UE does not support E-DCH Compressed Mode, such MACe PDU is HARQ-retransmitted in a non compressed format. Since in UA5.1 the NodeB assumes the UE to use the compressed E-DCH format for the HARQ
retransmission of a first transmission affected by CM gaps, it will detect that the UE
uses an E-TFCI higher than expected. Consequently, the Node-B applies the defense
mechanism against bad detection of E-AGCH (cf. [Vol. 4]), i.e. it sends a forced-ACK
to the UE (and retransmits the E-AGCH). This mechanism avoids useless HARQ
retransmissions. RLC retransmission is triggered after a while, and the data included
in the lost MAC-e PDU is finally retrieved. For this case (i.e. UA5.1, UE not supporting
E-DCH CM), substantial E-DCH throughput degradation was observed during lab
tests.
UE SUPPORTING E-DCH COMPRESSED MODE
As explained in above Section 4.2.1, for the 10ms E-DCH TTI case, when transmitting
data on E-DCH over a TTI that is affected by uplink CM gaps, the UE reduces on its
own behavior the Serving Grant that it uses for E-TFC selection, according to the
number of slots affected by uplink CM gaps within the TTI. This is done so that, during
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 38/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
a TTI affected by CM gaps, the maximum number of bits delivered by the UE to the
physical layer is fewer than the number of bits that can be actually supported (i.e.
number of bits supported by the largest E-TFC that meets both current grant allocated
by the Node-B and current number of available slots some slots are not due to CM
transmission gaps).
This operation of limitation of E-TFCs set during UL compressed frames is done
by the UE (and not by the Node-B), i.e. the UE takes the action to reduce by itself
the number of E-TFCs usable according to the UL transmission gaps pattern.
For UL compressed frames, the UE reduces the number of E-TFCs usable according
to the following method. In case of UL compressed frame, the Serving Grant SG
computed each TTI within the UE (according to the received E-AGCH command) is
reduced by the UE to SG, according to the number of non-DTX slots Nc in the TTI:
SG = SG * (Nc/15)
Remark: 15 is the total number of slots (1 slot = 0.66ms) within one 10ms TTI.
As a result, on the UE side, the amount of data from MAC-d layer for the current TTI is
reduced to fit the highest E-TFC usable by the UE given the reduced serving grant
SG. Then, when sending E-DCH data over the 10ms TTI, the UE maps the MAC-e
PDU only on the slots available (i.e. the slots not affected by CM transmission gaps).
With the introduction of 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. UA5.1, 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 in above Section 4.2.1, the UE reduces
on its own behavior the Serving Grant that it uses for E-TFC selection according to the
number of slots affected by uplink CM gaps within the 10ms TTI. Consequently, in the
majority of cases, the spreading factor of the E-TFC finally selected by the UE is equal
to (or greater than) the SF of the E-TFC that would have been selected purely basing
on the grant sent by the Node-B. However, if for any reason the SF of the E-TFC
finally selected by the UE happens to be smaller than the SF of the E-TFC that would
have been selected purely basing on the grant sent by the Node-B, the Node-B cannot
decode the MAC-e PDU. In this case (i.e. SF selected by the UE smaller than the
minimum SF allowed by the Node-B for this UE for current TTI), the Node-B cannot
decode the MAC-e PDU, but instead the Node-B sends a forced-ACK (i.e. it sends an
ACK although it could not decode the MAC-e DPU) in order to avoid following HARQ
retransmissions which it would not be able to decode as well. RLC retransmission is
triggered after a while, and the data included in the lost MAC-e PDU is finally
retrieved.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 39/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Concerning the UL DCH associated to the E-DCH, Compressed Mode is handled as
in previous releases, i.e. using Spreading Factor Reduction method (SF=SF/2).
DOWNLINK
E-AGCH 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 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 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.
No (UA5.0)
CM gaps not taken into account by UE when
transmitting on E-DCH A MAC-e PDU
transmitted over a gapped TTI cannot be decoded.
However, MAC-e PDU is HARQ-retransmitted in
non-gapped format If TTI used for HARQ
retransmission is not gapped, retransmitted
No MAC-e PDU is decoded by Node-B.
Substantial E-DCH throughput degradation.
If UE reports correctly Measurement Control
Failure, a defense mechanism at RNC disables CM
for this UE for the duration of E-DCH call.
CM gaps taken into account by UE when
transmitting on E-DCH Since Node-B is not
aware of gapped format, a MAC-e PDU transmitted
over a gapped TTI cannot be decoded.
In addition, MAC-e PDU is HARQ-retransmitted in
gapped format as well it cannot be decoded.
Yes RLC retransmission triggered after maximum
number of HARQ transmissions reached.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 40/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
4.3 RNC DEFENSE MECHANISM AGAINST UES NOT
SUPPORTING HSDPA OR E-DCH COMPRESSED MODE
Some non-standards-conforming UEs do not support compressed mode in
combination with HSDPA or with HSUPA.
The Alcatel-Lucent UTRAN has implemented a defense mechanism to handle this
missing UE capability. The operator can choose between following options:
CM Deactivation:
In case a UE reports an RCC Measurement Control Failure at CM activation while
in HSPA call, the RNC deactivates CM at Node-B side for this UE in order to
prevent degradation of HSDPA (or E-DCH) throughput due to UE not supporting
HSDPA (E-DCH) data transmission while in CM.
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.
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 AlcatelLucent written authorization
Page 41/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Restriction: Alcatel-Lucent 939x NodeB
Alcatel-Lucent 939x NodeB does not support CM in combination with HSUPA. Before CM activation it
is required to reconfigure the uplink from HSUPA to DCH. The downlink remains on HSDPA.
To enable the unconditional fallback from HSUPA to DCH for CM activation the parameter
isEdchCmFallbackAllowed must be set to 'allowedAlways'.
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.
PARAMETERS:
isHSDPACMFallbackAllowed: Enables/disables fallback from HSDPA to DCH if
compressed mode activation failed for a HSDPA call. On DCH the compressed mode
activation is attempted again. The fallback is required for some legacy R5 UEs that
don't support compressed mode for HSDPA calls.
Parameter
Range & Unit
User
Class
Value
isHSDPACMFallbackAllowed
Boolean {True, False}
Customer
3
TRUE
Object
RadioAccessService
Granularity
RNC
Object
isEdchCmFallbackAllowed
Enum {never, ueDependent, allowedAlways}
Customer
Granularity
3
See following recommendation
RadioAccessService
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 42/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Engineering Recommendation: Fallback of HSUPA to DCH on CM activation
isEdchCmFallbackAllowed must be set to 'allowedAlways' in markets with deployed Alcatel-Lucent
939x NodeB.
In markets without Alcatel-Lucent 939x NodeB it is recommended to set isEdchCmFallbackAllowed
to 'ueDependent'.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 43/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
PARAMETERS:
isInterFreqMeasActivationAllowed: This parameter indicates if the inter-frequency
measurement activation is allowed or not in the RNC.
Parameter
Range & Unit
User
Class
Value
isInterFreqMeasActivationAllowed
Boolean
{True, False}
Customer
3
TRUE
Object
RadioAccessService
Granularity
RNC
isInterFreqCModeActivationAllowed
Boolean
{True, False}
Customer
3
See following recommendation
Object
DlUserService
Granularity
DlUserService
isGsmCModeActivationAllowed
Boolean
{True, False}
Customer
3
See following recommendation
Object
DlUserService
Granularity
DlUserService
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 44/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Engineering Recommendation: CM (inter RAT or inter Freq) activation recommendations
isInterFreqCModeActivationAllowed must be set to True for all DlUserServices dealing with HSDSCH
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
This setting is also applicable to HSUPA RAB as the parameters are per DlUserService (i.e. HSDSCH).
Refer to UPUG Vol. 13, [R01], for the exhaustive list of value per DlUserService.
HSxPA to DCH
HSxPA to HSxPA
DCH to HSxPA
All reconfigurations from HSxPA to DCH, DCH to HSxPA and HSxPA to HSxPA are
supported by both iCEM and xCEM
Then, RNC establishes a Radio Link on the target cell and reconfigures the mobile on
the new frequency (with new HS-DSCH and E-DCH information). Previous Radio Link
is released once RNC has received RRC Radio Bearer Reconfiguration Complete
from UE.
PARAMETERS:
Page 45/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
o
Parameter
Range & Unit
User
Class
Value
HSDPA to DCH
DCH to DCH
RadioAccessService
Granularity
RNC
User
Class
Value
isHsdpaHhoWithMeasAllowed
Boolean
{True, False}
Customer
3
TRUE
Parameter
Range & Unit
When set to False, this parameter prevents any Intra-RNC HHO to EDCH, and only the 2 following transitions can then occur for UL
Transport Channel:
E-DCH to DCH
DCH to DCH
isEdchHhoWithMeasAllowed
Boolean
{True, False}
Customer
3
TRUE
Object
RadioAccessService
Granularity
RNC
Engineering Recommendation:
If HSxPA is deployed on the same NodeB using 2 dedicated carriers, isHsdpaHhoWithMeasAllowed
and isEdchHhoWithMeasAllowed must be set to TRUE in order to prevent any conflict with iMCTA
Service strategy.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 46/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
This nominal RRC container allows Target RNC to directly reconfigure the RAB in
HSxPA without any DCH transition.
However, in very specific cases where HSxPA capabilities are missing (e.g. RNC 4.2
facing RNC 5.0), Target RNC first establishes the PS RAB into DCH, requests UEs
HSxPA-capabilities through RRC UE Enquiry Capability procedure and eventually
reconfigures the PS RAB into HSxPA if needed.
Relocation procedures are detailed in [R01]
handover from source cell at a DRNC to target cell at the same DRNC
handover from source cell at the SRNC to target cell at a neighbouring RNC
Note: The neighbouring RNC may be an existing DRNC which is already
involved in the active set on the old frequency or will become a new DRNC
otherwise
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 5.1.1.
After successful DCH to DCH handover over Iur a previous HSxPA call will be
reconfigured back to HSDPA on the new frequency immediately. Reconfiguration back
to HSUPA is not supported in this case, refer to section 3.5.
Typical unsuccessful cases are handled as follows:
If the reconfiguration from HSxPA to DCH ends up with the call remaining on
HSxPA then SRNS relocation may be attempted if allowed.
If the DCH to DCH handover ends up with the call remaining on the old
frequency then SRNS relocation may be attempted if allowed. If the call finally
remains on DCH on the old frequency (i.e SRNS relocation is unsuccessful as
well or not allowed) then a previous HSxPA call will be reconfigured back to
HSxPA on the old frequency by intra frequency mobility.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 47/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
For description of detailed scenarios and interaction with SRNS relocation please refer
to UTRAN Parameters User Guide,[R01].
PARAMETER:
isInterFreqHandoverOverIurAllowed: This parameter enables/disables the interfrequency hard handover over Iur on a per neighbouring RNC basis
Parameter
Range & Unit
isInterFreqHandoverOverIurAllowed
Boolean
{True, False}
Customer
3
TRUE
User
Class
Value
Object
NeighbouringRNC
Granularity
N/A
2D
2F
Parameter
Object
Value
Event
Specific 2D/2F thresholds must be set to all UsHoConfs that contain HS-DSCH in
order to prevent call drop that may occur due radio degradation following CM
activation. The following table depicts the Engineering recommendation for HSxPA
whose RSCP thresholds differs from DCH setting presented in UPUG Vol. 13 [R01].
cpichEcNoThresholdUsedFreq2D
FullEventHOConfHhoMgt
-14
cpichRscpThresholdUsedFreq2D
FullEventHOConfHhoMgt
-110
timeToTrigger2D
FullEventRepCritHHOMgt
1280
cpichEcNoThresholdUsedFreq2F
FullEventHOConfHhoMgt
-13
cpichRscpThresholdUsedFreq2F
FullEventHOConfHhoMgt
-108
timeToTrigger2F
FullEventRepCritHHOMgt
1280
timerAlarmHOEvent
FullEventHOConfHhoMgt
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 48/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
5.2 INTER-SYSTEM MOBILITY FOR HSXPA
5.2.1.1.1 3G TO 2G HANDOVER
In case iMCTA has selected 2G as Target Access, RNC configures CM for InterSystem 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.
5.2.1.1.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 AlcatelLucent written authorization
Page 49/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
suspendTimeOffset
Integer
[0 255] (x 10ms)
Customer
3
24
Object
HsdpaRncConf
Granularity
RNC
All HS-DSCH Capacity Requests that are sent to the NodeB before
the starting activation time are silently discarded.
When the credits are not yet explicitly granted, the NodeB silently
delete HS-DSCH data coming from the RNC (i.e. no HS-DSCH
Capacity Allocation is sent to the RNC).
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.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 50/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
X
R99
R99
HSxPA
HSxPA
HSxPA
R99
R99
R99
Y
R99
GSM
Figure 8: Example of Inter-frequency and Inter-System scenario
Three HHO scenarios are presented on the figure (among many others):
1. An HSxPA user performing PS call enters HSxPA coverage: after SHO
mobility, iMCTA Service triggers Inter-frequency HHO towards the HSxPA
layer.
2. An HSxPA mobile performing HSxPA call leaves HSxPA coverage: iMCTA
Alarm triggers Inter-frequency HHO towards R99 layer.
3. A mobile is leaving the UMTS coverage: iMCTA Alarm triggers Inter-system
HHO towards GSM.
Please refer to [R01] for complete details on iMCTA algorithm and settings.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 51/52
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Volume 6 : Mobility
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 52/52
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
DEPLOYMENT SCENARIOS
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
CONTENTS
1
INTRODUCTION............................................................................................................................4
1.1
OBJECT ....................................................................................................................................4
1.2
2.2
DEPLOYMENT STATUS...............................................................................................................6
4.2
4.3
4.4
4.5
4.6
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 1/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TABLES
Table 1: Different topologies of carriers with the minimum associated hadware
Table 2: summury for Idle Mode, RCC Redirection & Handover strategies per topology
Table 3: summury for HSDPA & HSUPA requirements per topology
Table 4: summury for Idle Mode, RCC Redirection & Handover strategies per topology
Table 5: summury for HSDPA & HSUPA requirements per topology
TU
7
14
15
19
22
UT
TU
TU
UT
UT
TU
TU
UT
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 2/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
FIGURES
Figure 1: Examples of applications for traffic distribution ............................................................................. 10
Figure 2: Examples of applications for traffic distribution for Bi Frequency............................................... 11
Figure 3: Examples of applications for traffic distribution for Tri carrier ..................................................... 11
Figure 4: Mono Carrier to Bi Frequency deployments evolution ................................................................. 12
Figure 5: Bi Frequency to tri carrier deployments evolution ........................................................................ 17
TU
UT
TU
UT
TU
UT
UT
TU
TU
UT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 3/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA & E-DCH (HSUPA) system.
This includes a system
recommendations.
description,
configuration
aspect
and
engineering
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 4/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
2 RELATED DOCUMENTS
2.1 HPUG VOLUMES
[Vol. 1] Introduction
[Vol. 2] HSxPA overview
[Vol. 3] HSDPA principles scheduling and resource management
[Vol. 4] E-DCH principles scheduling and resource management
[Vol. 5] Call Management
[Vol. 6] Mobility
[Vol. 7] Deployment scenarios
[R02] UMT/BTS/INF/016135
Planning Guide
[R03] UMT/IRC/APP/000055
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 5/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
In order to limit only to realistic use cases, selection of the target UA6.0 topologies had
been based on:
Deployment cost: New Hardware or Optimization activities (Network reengineering 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.
X
iCem:
U
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 6/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
iCcm:
U
xCcm:
U
#carriers
1 carrier
2 carriers
2 carriers
2 carriers
2 carriers
2 carriers
3 carriers
3 carriers
3 carriers
3 carriers
3 carriers
3 carriers
3 carriers
F1
R99/HSxPA
R99
R99/HSDPA
R99/HSDPA
R99/HSxPA
R99/HSxPA
R99
R99
R99/HSDPA
R99/HSDPA
R99/HSxPA
R99/HSxPA
R99/HSxPA
F2
F3
HSxPA
HSxPA
R99/HSxPA
HSxPA
R99/HSxPA
HSDPA
HSxPA
HSDPA
HSxPA
R99/HSDPA
R99/HSxPA
R99/HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
R99/HSxPA
Product
STSR1
STSR2, STSR1+1
STSR2, STSR1+1
STSR2, STSR1+1
STSR2, STSR1+1
STSR2, STSR1+1
STSR3, STSR2+1
STSR3, STSR2+1
STSR3, STSR2+1
STSR3, STSR2+1
STSR3, STSR2+1
STSR3, STSR2+1
STSR3, STSR2+1
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 AlcatelLucent written authorization
Page 7/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
R99
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 8/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
R99 / HSxPA
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 9/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA Traffic
Copyright 1996 Northern Telecom
Load F1 first
R99 traffic
Non loaded
cell
Sequential Loading
Service segmentation
Overloaded
cell
Load Balancing
Overloaded cell
Speech call
GSM
GSM fallback
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 10/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Profile Y
Profile Y
Profile X&Y
Profile X
Profile X&Y
Profile X&Y
Cell Reselection
RRC Traffic Segmentation
iMCTA Service Segmentation
iMCTA Load Balancing
Profile Y
Profile Y
Profile X&Y
Profile Y
Profile Y
Profile X&Y
Profile X
Profile X&Y
Profile X&Y
Cell Reselection
RRC Traffic Segmentation
iMCTA Service Segmentation
iMCTA Load Balancing
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 11/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
R99 / HSxPA
HSxPA
HSxPA
R99 / HSxPA
HSxPA
R99 / HSxPA
R99
R99/ HSDPA
R99/HSDPA
R99 / HSxPA
R99 / HSxPA
The following table is making a summury for Idle Mode, RCC Redirection & Handover
strategies behind each proposed topology evolution. It is considered that Cell sizes
are equivalent.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 12/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TOPOLOGY
HSxPA
R99
RESELECTION
RRC Redirection
HANDOVER
Favour F1 on cell
selection/reselection
Segmentation to
inducing Service
Segmentation for
RRC establishment
R99/HSxPA traffic
to F2.
distribution.
Sib4&Sib12 keeping the
UE on its current layer
for R99 and delay the
inter-freq mobility from
F2 to F1.
UEs camping
RRC traffic
homogeneously on
segmentation
different frequencies.
function (PMid
84900) redirecting
UEs camping
RRC traffic
homogeneously on
segmentation not
R99 / HSxPA
different frequencies.
applicable.
R99/HSDPA
HSxPA
R99/ HSDPA
HSxPA
R99 / HSxPA
UEs camping
RRC traffic
homogeneously on
segmentation
different frequencies.
function (PMid
84900) redirecting
R99 traffic to F1
balancing.
R99 / HSxPA
R99 / HSxPA
UEs camping
RRC traffic
homogeneously on
segmentation not
different frequencies.
applicable.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 13/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The following table is making a summury for HSxPA requirements behind each
proposed topology evolution.
TOPOLOGY
HSxPA
R99
totalRotMax = 8dB
Codes mgt:
U
HSxPA
R99/ HSDPA
- No PA power pooling
- Power Evolution activation on F2, no Power Evolution on F1
Ul load mgt:
U
totalRotMax = 8dB
Codes mgt:
U
R99 / HSxPA
R99/HSDPA
- No PA power pooling
- No Power Evolution
Ul load mgt:
U
totalRotMax = 6dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 14/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA
R99 / HSxPA
Power mgt:
U
- No PA power pooling
- Power Evolution activation on F2, no Power Evolution on F1
Ul load mgt:
U
R99 / HSxPA
R99 / HSxPA
Power mgt:
U
- No PA power pooling
- No Power Evolution
Ul load mgt:
U
totalRotMax = 6dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 15/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
F1(R99) + F2(HSxPA)
o
F1(R99/HSDPA) + F2(HSxPA)
o
F1(R99/HSDPA) + F2(R99/HSxPA)
o
F1(R99/HSxPA) + F2(HSxPA)
o
F1(R99/HSxPA) + F2(R99/HSxPA)
o
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 16/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA
R99 / HSxPA
HSxPA
R99 / HSxPA
R99
R99/ HSDPA
R99/HSDPA
R99 / HSxPA
R99 / HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
HSxPA
R99 / HSxPA
HSDPA
HSxPA
HSxPA
HSDPA
R99/ HSDPA
R99 / HSxPA
R99 / HSxPA
R99
R99
R99/ HSDPA
R99/ HSDPA
R99 / HSxPA
R99 / HSxPA
R99 / HSxPA
The following table is making a summury for Idle Mode, RCC Redirection & Handover
strategies behind each proposed topology evolution. It is considered that Cell sizes
are equivalent.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 17/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
TOPOLOGY
HSxPA
HSDPA
R99
RESELECTION
RRC Redirection
HANDOVER
RRC traffic
selection/reselection
segmentation
function (PMid
homogeneously on F2
84900) redirecting
& F3.
Sib4&Sib12 keeping
the UE on its current
layer for R99; load
sharing F2<->F3 but
not on F1.
HSxPA
HSxPA
RRC traffic
selection/reselection
segmentation
function (PMid
homogeneously on F2
84900) redirecting
& F3.
Sib4&Sib12 keeping
R99
HSxPA
HSxPA
R99/ HSDPA
RRC traffic
selection/reselection
segmentation
function (PMid
homogeneously on F2
84900) redirecting
& F3.
Sib4&Sib12 keeping
HSxPA
HSDPA
R99/ HSDPA
RRC traffic
selection/reselection
segmentation
function (PMid
homogeneously on F2
84900) redirecting
& F3.
Sib4&Sib12 keeping
the UE on its current
layer for R99; load
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 18/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA
R99/ HSDPA
UEs camping
RRC traffic
homogeneously on
segmentation
different frequencies.
function (PMid
84900) redirecting
F3.
Sib4&Sib12 keeping
the UE on its current
R99 / HSxPA
HSxPA
R99 / HSxPA
R99 / HSxPA
UEs camping
RRC traffic
homogeneously on
segmentation
different frequencies.
function (PMid
84900) redirecting
F3.
Sib4&Sib12 keeping
the UE on its current
layer for HSxPA layer;
R99 / HSxPA
R99 / HSxPA
UEs camping
RRC traffic
homogeneously on
segmentation not
different frequencies.
applicable.
R99 / HSxPA
load sharing
F1<->F2<->F3.
Table 4: summury for Idle Mode, RCC Redirection & Handover strategies per topology
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 19/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
The following table is making a summury for HSxPA requirements behind each
proposed topology evolution.
TOPOLOGY
HSxPA
HSDPA
- numberOfHsScchCodes = 3
R99
Power mgt:
U
totalRotMax = 8dB
Codes mgt:
U
HSxPA
HSxPA
- numberOfHsScchCodes = 3
R99
Power mgt:
U
totalRotMax = 8dB
Codes mgt:
U
HSxPA
HSxPA
R99/ HSDPA
Power mgt:
U
- No PA power pooling
- Power Evolution activation on F2/F3
Ul load mgt:
U
totalRotMax = 8dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 20/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA
U
HSDPA
R99/ HSDPA
Power mgt:
U
- No PA power pooling
- Power Evolution activation on F2/F3
Ul load mgt:
U
totalRotMax = 8dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 21/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
HSxPA
R99/ HSDPA
R99 / HSxPA
Power mgt:
U
- No PA power pooling
- Power Evolution activation F3
Ul load mgt:
U
HSxPA
R99 / HSxPA
R99 / HSxPA
Power mgt:
U
- No PA power pooling
- Power Evolution activation on F3
Ul load mgt:
U
R99 / HSxPA
R99 / HSxPA
- numberOfHsScchCodes = 2
Power mgt:
R99 / HSxPA
U
- No PA power pooling
- No Power Evolution
Ul load mgt:
U
totalRotMax = 6dB
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 22/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
A certain spacing (F2-F1) between the 2 frequencies are required: [4.6; 5.1]
(while STSR1+1 frequencies spacing: [4.6; 55.2])
The radio coverage of the cells are not noise limited: Average RSCP < -90
dBm (average RSCP anticipated by subtracting 3 dB to the current average
RSCP in case of PCPICH - 3dB)
If the 2 above conditions are respected, STSR2 will be favor in large bi-carriers
deployment area due to the hardware cost saving (no need of 2 PA). In this case it
special attention should be performed at border with the mono-carrier area.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 23/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Same site location for UMTS 900MHz as for UMTS 2100MHz (same number
of sites) Case 1.
Same R99 capacity for UMTS 900MHz as for UMTS 2100MHz (same
subscriber density and same Effective Service Area) Case 2.
Same downlink coverage for UMTS 900MHz as for UMTS 2100MHz (same
CPICH received power) Case 3.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 24/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 25/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Main characteristics:
Maximum PA power ratio for each carrier is fixed (as in UA5):
DL power allocated to a given carrier cannot exceed maximum allowed for this carrier.
Max PA power ratio for each carrier can be set so that sum of ratios exceeds 100%:
With UA6 29808, HSDPA traffic may use an important part of PA power
No impact
But, R99 traffic has full priority for power allocation (as in UA5)
Feature impact on DL CAC and DL iRM (both mechanisms apply to R99 traffic):
DL CAC and DL iRM are based on max PA power ratio set for the considered carrier.
y F1: No impact (since R99 traffic has full priority for power allocation)
y F2: When 29808 is activated, if high traffic on F1, currently available power on F2
may be lower than value indicated by max PA power ratio for F2.
In order to avoid potential impact:
DL CAC and DL iRM triggering criterions slightly modified on F2 when 29808 is activated
y
y
UA6 29808: Dynamic PA power sharing between R99 and HSPA carrier
Recommended UA6 settings for
paRatio and maxTxPower :
paRatio
GBR,
R99
Power
not used
R99
Fixed
partitioning
HSDPA
maxTxPower
paRatio (F1)
HSDPA
paRatio (F2)
paRatio (F2)
paRatio (F1)
PA Power Ratio
100%
0%
UA5:
Static PA power sharing
between F1 and F2 carriers.
paRatio parameter must be set
as follows:
paRatio (F1) + paRatio (F2) 100%
GBR,
R99
R99
UA6:
Dynamic PA power sharing
between F1 and F2 carriers.
paRatio can be set as follows:
paRatio (F1) + paRatio (F2) > 100%
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 26/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
RNC:
UA5:
P max Hspa (F2) [W] = Max Tx Power (F2) [W] P CCC (F2) . Activity Factor Cch P OCNS
Min { maxTxPower (F2) ;
Max Dl Power Capability (F2) }
UA6:
P max Hspa (F2) [dBm] = Max Tx Power (F2) [dBm] maxHspaPowerOffset (F2)
New parameter introduced in UA6
P HSDPA (F2) [W] = Min { P max Hspa (F2) [W] ; PA Power - P Total Non HSDPA with Margin }
Total non HSDPA power over both carriers
measured at NodeB each COMMON MEASUREMENT period
No impact of 29808 on
R99 power allocation
P traffic (F2) [W] = Max Tx Power (F2) [W] Min Pw Hsdpa (F2) [W]
- P CCC (F2) . Activity Factor Cch P E-DCH - P OCNS
Common channels activity factor
(UA5: hard-coded. UA6: set via activityFactorCcch)
Remark: For F1 (i.e. R99 carrier), same formula without Min Pw Hsdpa and P E-DCH
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 27/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
y
y
y
Impact on F2:
Full priority is given to R99 traffic
In P traffic formula, Max Tx Power (F2)
may not reflect the actual maximum
R99 and HSDPA traffic on F2
power available on F2
If 29808 is activated, a priori
(especially if high traffic on F1)
paRatio (F1) + paRatio (F2) > 100%
y In order to avoid potential impact on DL CAC and DL iRM,
P traffic formula is modified as follows for F2 when 29808 is activated:
P traffic (F2) [W]
= (Max Tx Power (F2) [W] Min Pw Hsdpa (F2) [W]) / (1+paOverbookingRatio/100)
- P CCC (F2) . Activity Factor Cch P E-DCH - P OCNS
y
y
y
OMC-R
RNC
NodeB
RadioAccessService
Number of instances
(indicated when > 1)
DedicatedConf
HsdpaCellClass 32
minimumPowerForHsdpa
maxHspaPowerOffset
paOverbookingRatio
EdchCellClass 15
eagchErgchEhichTotalPower
FDDCell
isPowerPoolingActivated
Class2CellReconfParams
Class3CellReconfParams
maxTxPower
activityFactorCcch
OMC-B
BTSEquipment
paPoolingActivation
BTSCell
paRatio
PaResource 12
maxPowerAmplification
HsdpaConf
dchPowerMargin
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 28/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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
8.2.1.
B
Parameter
paOverbookingRatio
Object
HsdpaCellClass
Granularity
HsdpaCellClass
Integer [1 100], %
Customer, 0
Value
30
isPowerPoolingActivated
Object
FDDCell
Granularity
FDDCell
Customer, 0
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
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 29/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
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 UA6 UPUG [R01],
Vol.8, section 3.2.1.
X
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 5.1.1 of this volume, UA6 29808: Dynamic PA power sharing between R99
and HSPA carrier.
X
paPoolingActivation
Object
BTSEquipment
Granularity
BTSEquipment
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 UA6 UPUG [R01],
Vol.8, section 3.2.2.
X
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.2.1.1.2, 8.2.2.1.4 and 8.4.
B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 30/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Rationale:
Assuming that paRatio (F1) is set to 50%, 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 certain amount of power always required for F1 (common ch, etc)
System stability must be guaranteed
Example:
Assumptions: MCPA 60W, maxPowerAmplification = fullMode,
Tx Losses = 1.3dB, paRatio(F1) = 50%, PA overbooking ratio = 130%
paRatio (F2) = 80%
maxTxPower (F1) = 47.8dBm + 10*log(50%) -1.3 = 43.5dBm
maxTxPower (F2) = 47.8dBm + 10*log(80%) -1.3 = 45.5dBm
paOverbookingRatio = 30
Possible optimization:
Page 31/32
03.10 / EN
EXTERNAL
02/Oct/2009
Standard
Z END OF DOCUMENT Y
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Page 32/32
UMT/IRC/APP/016664
HSXPA PARAMETERS USER GUIDE UA6.0
Z END OF DOCUMENT Y
Alcatel-Lucent Proprietary
V03.10
02/OCT/2009