HSxPA Parameters User Guide

8/10/2019 HSxPA Parameters User Guide

1/476

HSxPA Parameters User Guide

Document number: UMT/IRC/APP/016664

Document issue: V03.10Document status: Standard

Date: 02/Oct/2009

External Document


2/476

Copyright 2007 by Alcatel-Lucent. All Rights Reserved.

About Alcatel-Lucent

Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service

providers, enterprises and governments worldwide, to deliver voice, data and video

communication services to end-users. As a leader in fixed, mobile and converged broadband

networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end

solutions that enable compelling communications services for people at home, at work and on

the move. For more information, visit Alcatel-Lucent on the Internet: http://all.alcatel-

lucent.com

Notice

The information contained in this document is subject to change without notice. At the time

of publication, it reflects the latest information on Alcatel-Lucents offer, however, our

policy of continuing development may result in improvement or change to the specifications

described.

Trademarks

Alcatel, Lucent Technologies, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of

Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-

Lucent assumes no responsibility for inaccuracies contained herein.

Alcatel-Lucent Proprietary
http://all.alcatel-lucent.com/http://all.alcatel-lucent.com/http://all.alcatel-lucent.com/http://all.alcatel-lucent.com/


3/476

CONTENTS

1 INTRODUCTION

2 HSXPA OVERVIEW

3 HSDPA PRINCIPLES, SCHEDULING AND RESOURCE MANAGEMENT

4 E-DCH PRINCIPLES, SCHEDULING AND RESOURCE MANAGEMENT

5 CALL MANAGEMENT

6 MOBILITY

7 DEPLOYMENT SCENARIOS



4/476

HSXPAPARAMETERS USER GUIDE

1 INTRODUCTION



5/476

HSxPA Parameters User Guide 03.10 / EN 02/Oct/2009UMT/IRC/APP/016664 EXTERNAL Standard

Volume 1 : Introduction

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

Page 1/24

CONTENTS

1 INTRODUCTION..........................................................................................................................111.1 OBJECT..................................................................................................................................11

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

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

1.4 NOMENCLATURE .....................................................................................................................13

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

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

3 ABBREVIATIONS AND DEFINITIONS.......................................................................................183.1 ABBREVIATIONS ......................................................................................................................18

3.2 DEFINITIONS...........................................................................................................................23


6/476




Page 2/24

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, serviceMinRate, serviceHighRate,

serviceLowRatecorrected

New recommendation for serviceHighRate

Class of numberOfHsPdschCodes and numberOfHsScchCodes corrected

New value concerning the TBS applied from maximum MCS for Category

10 and xCem (value applicable from UA6.0.5)

Update of the Engineering Recommendation concerning the maximum

HSDPA throughput for UE Cat.10

In Volume 5:

Recommended value for dlTxPowerEstimationcorrected

24/09/2009


Updates:

In Volume 5:

Update concerning the parameter edchMaxNumberUserNodeB.

02/09/2009


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


7/476




Page 3/24


Updates:

In Volume 4:

Deletion of the remarks, including comments related to the xCEM resets andcell lock-unlock, for the parameters eagchPowerControlModeXcem,ehichErrorProbability, minPowerCorrection, maxPowerCorrection,pMinDlEDCH and pMaxDlEDCH

26/06/2009


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 the parameter

HsdpaGbrIncreaseFactorForMobility

Description of the feature IU USER TRAFFIC CONFORMANCE added

(coming from Vol.7 Iub resource management)

Restriction added for the parameter maxHspaPowerOffset.

In Volume 4:

Clarification regarding edchTfciTableIndex : Table 0 (2msTtiTable0 and

10msTtiTable0) must not be used

Update of the recommended value for reserved0 : bit 24 and bit 25 are used

to select UL ILPC Algo2 for UE Category 4 TTI 2ms and UE Category 6 TTI

2ms.

Update of the recommended value for plNonMax, {Ref E-TFCI; Ref PO},

and maxSirTargetfor Ue Category6 TTI 2ms with SRB on EDCH.

Clarification regarding the parameters edchMacdPowerOffsetEdchTti10

and edchMacdPowerOffsetEdchTti2


8/476




Page 4/24

Clarification regarding the parameters

isEdchFpBundlingModeForEdchTti2msAllowed and

isEdchFpCrcPayloadPresence

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

noise (Vol4, section 4.1.3)

Update RSEPS (Vol4, section 4.1.2)

Update pour la UE category Cat4 to Cat6 (Vol4, section 5.2)

Update pour la partie: MACE scheduler inputs (Vol4, section 7.1)

Update pour la partie Scheduling Grant (Vol4, section 7.2)

Update pour la IBTS Local Congestion Control feature (Vol4, section 7.8.4)

Update pour le SRB on HSPA during Call vs HSUPA over Iur (Vol4, section

9)

New recommendation for nFramesBeforeEdchDeCongestion

In Volume 5:

Feature 84900 has been added

Clarification of GBR algorithms

Clarification of the recommendation for deltaCfnForEdchXXX

Clarification of the impact of the flag enhancedQualityOfService on

minBrForHsdpausage

New recommendation for ovsfCodesThroughput16QamUe

Clarification of the RNC CAC on codes

Section 6.1.3 deleted because no more applicable in UA6

Clarification of the values for reservationFactorOnCodesForGbrTraffic and

initialActivityFactorForIb

Parameter timerT2ForMultiRabHsdpa (not used in UA6) replaced by

timerT2ForHsdpa

In Volume 6:

Clarification regarding Event 1J : an event 1J for Primary Cell replacement isignored by the RNC

In Volume 7:

Volume 7 has been deleted (see section 1.2)

In Volume 8 (new name: Volume 7 since Volume 7 has been deleted):

Mention PA power pooling restriction for STSR2 * 6 sectors configurations.

06/03/2009

Issue 03.08 / EN, Preliminary


9/476




Page 5/24

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, 8.2):

Correction of parameter definitions, update of recommended settings

Updates on maxNrOfErgchEhich : Parameter definition, recommended

value for xCEM, configuration restrictions (Vol.4, 4.2.2.2)

Addition of recommended value for prohibitedStatusTimerin UL (Vol.4, 5.2)

In Volume 5:

Update of deltaCfnForEdchAndHsdpaMobility and

deltaCfnForEdchAndHsdpaChannelTypeSwitching recommended value

(Vol.5, 5.1.2)

Update of the HSDPACombinationList table

activateOls added

Parameter name corrected (isDlPowerSelfTuningForPsIbOnHsdpaEnabled)


10/476




Page 6/24

Clarification of the rule of the parameter isGbrOnHsdpaAllowed

Clarification of the Fair Sharing/GBR features

In Volume 7:

Engineering recommendation concerning the maximumBucketSize is deletedsince this parameter is no more used in UA6.0

In Volume 8:


In Volume 9:


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 "PAoverbooking ratio" definition

28/10/2008


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

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)

hsdschPowReportingPeriodreplaced 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

spiparameter 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)
http://../CESAR/RMD/Content/Parameters/V6.0/RNC/CNode/HsdpaResource.htmlhttp://../CESAR/RMD/Content/Parameters/V6.0/RNC/CNode/HsdpaResource.html


11/476




Page 7/24

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 "UCU-

III" {Ref E-TFCI; Ref PO} table (Vol.4, 5.4)

Update of nHarqRetransTargetSxparameters for 10ms E-DCH TTI (Vol.4,

8.1.2.3.4)

Mention of hard-coded offset on top of E-DCH maxSirTargetfor 2ms E-DCH

TTI (Vol.4, 8.1.2.3.4)

edchSpiparameter added

In Volume 5:

Modification of the recommendation for

transportTypeSelectionTransferDelayThreshold

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

enabled

Update of the HSDPACombinationList

Update of Fair Sharing description

In Volume 9:

General updates

29/08/2008


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


12/476




Page 8/24

Update of Abbreviations section (Vol.1, 3.1)

Miscellaneous updates (totalRotMax, edchInitialTBIndex , plNonMax,

edchHarqMaxRetransEdchTtixx , harqType...)

In Vol.3:

Forgetting factor formula for xCem (used to average the throughput of each

mac-d flow) corrected

Clarification concerningschedulingPriorityLevelin UA5.1 and UA6.0

serviceHighRate: value updated and engg recommendation added-

hsdschReqPwReportingPeriod and hsdschReqPwFilterCoeffadded

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

hsScchSnrvalue updated

hsdpaBlerTargetUpperLimitXcem value updated

Spectral Efficiency computation updated

Excess power algorithm updated

Restriction concerning the algorithm dynamicHarqTxTarget (parameter

hsdpaCqiBlerAdjustmentAlgorithmXcem) added

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 minBrForHsdpaadded

Recommendation for minHsDschReservationForCac added

Recommendation for dlTxPowerEstimationadded

In Vol6 :

Description of HSUPA over Iur feature

27/06/2008


Updates


13/476




Page 9/24

20/06/2008

Issue 03.04 / EN, Draft

Updates

06/06/2008


Updates

23/May/2008


Updates

28/March/2008


Document Creation


14/476




Page 10/24

FIGURES

Figure 1: Static and Configuration Parameters 16


15/476




Page 11/24

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 Alcatel-Lucent WCDMA customers, which are grouped into two different markets due to their

particular functional specificities:

USA Market, i.e. customers with UTRAN where Alcatel-Lucent 939X Node B

(former Lucent OneBTS) is deployed

Global Market, i.e. any other customers

This document provides a description of the features included in the UA06 release. At

the beginning of each volume, a table has been added to clearly indicate to which

market, among the two listed previously, each feature is applicable to. Note that one

feature can belong to one or two markets but: A feature which is not applicable to USA Market is not supported on a

UTRAN with Alcatel-Lucent 939X Node B (former Lucent OneBTS).

For features common to USA market and Global markets, the behaviour on

UTRAN with 939X Node B might be different from other Alcatel-Lucent Node

B products, in which case the differences are described in the Hardware

Dependencies section.

Features are by default not supported on 9313 Micro Node B nor 9314 Pico Node B.

For the list of features supported on these products please refer to 33341 Alcatel-

Lucent 9313 Micro Node B and 33342 Alcatel-Lucent 9314 Pico Node B

descriptions.


16/476




Page 12/24

1.2 SCOPE OF THIS DOCUMENT

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

applicability:

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

Tag [xCEM]indicates that the behavior or the feature is specific to xCEM only

or to xCEM and UCU-III if there is no [UCU-III] tag.

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

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

R99 related features and settings are not part of this document. Please refer to

[R01]a.[R02].

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

specific document:

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

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

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

The HSxPA Parameters User Guide is not supposed to present the whole Plan of

record. For accurate Plan of record and feature delivery information please refer to

your account and PLM prime.

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

UA5.x.

Restrict ion: Pico/Micro NodeB

The Pico/Micro NodeB product is out of scope of this document, thus all engg information, algorithms

description and parameters values provided in this document are strictly related to standard Alcatel-

Lucent NodeB products.

See [R01]a.[R07]for details related to HSxPA implementation inPico & Micro NodeB.

1.3 AUDIENCE FOR THIS DOCUMENT

This document targets an audience involved in the following activities:


17/476




Page 13/24

RF engineering

UTRAN Datafill

Trials and VO

1.4 NOMENCLATURE

The parameter names are written in bold italic.

The objects names are written in bold.

The parameters properties are presented as follow:

Parameter Object

Range & Unit

User

Class

Granularity

Value

The protocol messages are written in CAPITAL LETTERS.

The Information Elements (IE) contained in the protocol messages are written the

following way: TPC_DL_Step_Size .

The datafill rules are presented as the following:

Rule:

The system restrictions are presented as the following:

Restriction:

The engineering recommendations on parameter value are presented as the

following:

Engineering Recommendation:

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

following:

UAN-1-UAN Delta:


18/476




Page 14/24

Some parameters values can not be provided in this document; in that case, the

following abbreviations are used:

o N.A.: Not Applicable.

o N.S.: Not Significant.

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

configuration. Example: addressing parameters).


19/476




Page 15/24

1.5 RELATED DOCUMENTS

Reference documents:

[R01] NTP 411-8111-813 Access NetworkParameters

[R02] UMT/DCL/DD/0020 UTRAN Parameters User Guide

[R03] UMT/IRC/APP/0164 Iub transport Engineering Guide

[R04] UMT/IRC/APP/025147 CEM Capacity Engineering guide

[R05] UMT/IRC/APP/007147 Product Engineering Information

[R06] UMT/SYS/INF/016608 UA05 Feature Planning Guide

[R07] UMT/BTS/INF/016135 Micro NodeB & 9314 Pico NodeB Feature

Planning Guide


20/476



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 withinthe RAN model.

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


Page 16/24

RNC OMC WPS

Static

Non-Static

WPS Templates

Manufacturer

Customer

CIQ

OMC

database System DRF

Figure 1: Static and Configuration Parameters

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

configuration parameters.

The static parametershave the following characteristics:

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

They are part of the network element load.

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

The customer cannot modify them.

The configuration parametershave the following characteristics:

They are contained in the OMC database.

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

o Customer: Can be modified by the customer at the OMC (at the MMI or with

DRFs).


21/476




Page 17/24

o Manufacturer: They represent system constants defined by the manufacturer.

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

Regardless of the parameter type (customer or manufacturer), the parameters can have

the following classes:

o Class 0: the value of the parameter is set at the parent object creation.

Currently, most of the objects can only be killed and re-created through a new

MIB built (either btsEquipmentMIBor rncMIB).

o Class 1:new parameter value is taken into account on the next RNC restart.

This class is no longer valid.

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

can only be set when the object and its parent are both locked. The new value

will be taken into account after the object is back to working state

(administrative state set to unlocked).

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

can be modified when the object (and parent object) is unlocked. The new

value is taken into account immediately.

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

Class 3-A2: new value is taken into account upon event reception

(service establishement, SRLR).

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


22/476




Page 18/24

3 ABBREVIATIONS AND DEFINITIONS

3.1 ABBREVIATIONS

ACK Acknowledgment

AICH Acquisition Indicator Channel

AM Acknowledged Mode

AMC Adaptive Modulation and Coding

ARP Allocation Retention Priority

ARQ Automatic Repeat Request

ATM Asynchronous Transfer Mode

AS Active Set

BBU Base-Band Unit

BLER Block Error Rate

CAC Call Admission Control

CC Chase Combining

CCPCH Common Control Physical Channel

CEM Channel Element Module

CFN Connection Frame Number

CM Compressed Mode

CN Core NetworkCP Passport: Control Processor

CPICH Common Pilot Channel

CRC Cyclic Redundancy Check

CS Circuit Switched

DCH Dedicated Channel

DDM Dual Duplexer Module

DL Downlink

DPCCH Dedicated Physical Control Channel

DPDCH Dedicated Physical Data Channel

DS Delay Sensitive

DS1 Digital Signal level 1 (1.544 Mbit/s)

DTX Discontinuous Transmission

E-AGCH Enhanced Access Grant Channel

E-DCH Enhanced DCH (also referred as HSUPA or EUL)

E-DPCCH Enhanced Dedicated Physical Control Channel

E-DPDCH Enhanced Dedicated Physical Data Channel

E-HICH Enhanced Hybrid ARQ Indicator ChannelE-RGCH Enhanced Relative Grant Channel


23/476




Page 19/24

E-TFC E-DCH Transport Format Combination

E-TFCI E-DCH Transport Format Combination Indicator

EUL Enhanced Uplink (stands for E-DCH)

FP 3GPP: Frame ProtocolAlcatel-Lucent Passport: Function Processor

FRS Feature Requirements Specification

GMM GPRS Mobility Management

H-ARQ Hybrid ARQ

HCS Hierarchical Cell Structure

HS-DSCH High Speed Downlink Shared Channel

HS-SCCH Shared Control Channel for HS-DSCH

HSDPA High-Speed Downlink Packet Access

HSUPA High-Speed Uplink Packet Access

HHO Hard Handover

HO Handover

IE Information Element

iMCTA intelligent Multiple Carrier Traffic Allocation

iRM intelligent RAB mapping

IMEI International Mobile Equipment Identification

IMSI International Mobile Subscriber Identification

IP Internet Protocol

IR Incremental Redundancy

KPI Key Performance Indicator

LA Location Area

LAC Location Area Code

LCG Local Cell Group

MAC Medium Access Control

MCPA Multi-Carrier Power Amplifier (also referred as PA)

MIB 3GPP: Master Information Block;

Alcatel-Lucent RNC/NodeB: Management Information Base

MMI Man-Machine Interface

MO Mobile Originated

MT Mobile Terminated

NACK Negative Acknowledgement

NAS Non Access Stratum

NBAP NodeB Application Part

NDS Non-Delay Sensitive

OAM Operations, Administration and Maintenance

OLPC Outer-Loop Power Control


24/476




Page 20/24

OLS Olympic Level Service

OMC Operations and Maintenance Center

OMC-B OMC NodeB

OMC-R OMC RNCOVSF Orthogonal Variable Spreading Factor

PA Power Amplifier (stands for MCPA)

P-CCPCH Primary CCPCH

PCPCH Physical Common Packet Channel

P-CPICH Primary CPICH

PCR Peak Cell Rate

PDU Protocol Data Unit

PICH Paging Indicator Channel

PLMN Public Land Mobile Network

PRACH Physical Random Access Channel

PS Packet Switched

P-SCH Primary SCH

PSCR Physical Shared Channel Reconfiguration

QAM Quadrature Amplitude Modulation

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RA Registration AreaRAB Radio Access Bearer

RACH Random Access Channel

RAN Radio Access Network

RANAP Radio Access Network Application Part

RAT Radio Access Technology

RB Radio Bearer

RL Radio Link

RLS Radio Link Set

RLC Radio Link Control

RMS Root Mean Square

RNC Radio Network Controller

RNC-AN RNC Access Node

RNC-CN RNC Control Node

RNC-IN RNC Interface Node

RNS Radio Network Subsystem (an RNC and its associated NodeBs)

RoT Rise over Thermal

RRC Radio Resource ControlRRM Radio Resource Management


25/476




Page 21/24

RSCP Received Signal Code Power

RSN Retransmission Sequence Number

RSSI Received Signal Strength Indicator

RTWP Received Total Wideband PowerSCCP Signaling Connection Control Part

S-CCPCH Secondary CCPCH

SCH Synchronization Channel

S-CPICH Secondary CPICH

SCR Sustainable Cell Rate

SDU Service Data Unit

SF Spreading Factor

SFN System Frame Number

SHO Soft Handover

SI Scheduling Information

SIB System Information Block

SM Session Management

SRB Signaling Radio Bearer

SRLR Synchronous Radio Link Reconfiguration

SS7 Signaling System 7

S-SCH Secondary SCH

STM1 Synchronous Transport Module-1 (155.52 Mbit/s)TFC Transport Format Combination

TFCI Transport Format Combination Indicator

TFCS Transport Format Combination Set

THP Traffic Handling Priority

TM Transparent Mode

TNL Transport Network Layer

TRB Traffic Radio Bearer

TrCH Transport Channel

TRM Transceiver Module

TS Technical Specification

TTI Transmission Time Interval

UBR Unspecified Bit Rate

UE User Equipment

UL Uplink

UM Unacknowledged Mode

URA UTRAN Registration Area

UTRAN Universal Terrestrial Radio Access NetworkVCC Virtual Channel Connection


26/476




Page 22/24

VP Virtual Path


27/476




Page 23/24

3.2 DEFINITIONS


28/476




Page 24/24

END OF DOCUMENT


29/476

HSXPAPARAMETERS USER GUIDE

2 HSXPA OVERVIEW



30/476

HSxPA Parameters Guide 03.10 / EN 02/Oct/2009UMT/IRC/APP/016664 EXTERNAL Standard

Volume 2 : HSxPA Overview


Page 1/38

CONTENTS

1 INTRODUCTION............................................................................................................................41.1 OBJECT....................................................................................................................................4

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

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

2.1 HPUGVOLUMES......................................................................................................................5

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

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

3.1 HSDPA ...................................................................................................................................93.1.1 Transport and physical channels ....................................................................................93.1.1.1 Downlink channels.................................................................................................... 123.1.1.2 Uplink channels ........................................................................................................ 133.1.2 Fast link adaptation.......................................................................................................153.1.3 Fast Retransmission Mechanism (HARQ)....................................................................163.1.3.1 Number of HARQ Processes.................................................................................... 163.1.3.2 RV Parameters ......................................................................................................... 173.1.3.3 State of HARQ Processes........................................................................................ 193.1.3.4 Choice of the HARQ type......................................................................................... 213.1.4 Fast scheduling.............................................................................................................25

3.2 HSUPA(E-DCH)...................................................................................................................26

3.2.1 Transport and physical channels ..................................................................................263.2.1.1 Uplink channels ........................................................................................................ 283.2.1.2 Downlink channels.................................................................................................... 313.2.2 UA5 implementation of E-DCH .....................................................................................34

4 UE CATEGORIES........................................................................................................................35

4.1 HSDPA .................................................................................................................................35

4.2 HSUPA .................................................................................................................................36


31/476




Page 2/38

TABLES

Table 1: HSUPA / HSDPA comparison 8

Table 2: Number of processes per UE category for iCEM 16Table 3: RV coding for 16QAM 18Table 4: RV coding for QPSK 18Table 5: RV update table in the MIR case (Trv[i]) 21Table 6: RV update table in the PIR case (Trv[i]) 21Table 7: RV updates tables when harqType set to Dynamic Redundancy 22Table 8: Number of processes per UE category for xCEM/UCU-III 24Table 9: RV update table in the IR case (Trv[i]) 24Table 10: RV update table in the CC case (Trv[i]) 24Table 11: E-DPDCH slot formats 29Table 12: E-DPCCH slot formats 29Table 13: E-DPCCH power offset index vs. amplitude 31Table 14: Relative grant information (E-RGCH) 32

Table 15: ACK/NACK information (E-HICH) 33Table 16: HSDPA UE categories (3GPP TS25.306) 35Table 17: HSUPA UE categories (3GPP TS25.306) 36


32/476




Page 3/38

FIGURES

Figure 1: R99 principle ........................................................... ................................................................ ............. 6

Figure 2: HSDPA principle ................................................................ ............................................................... ... 6Figure 3: HSDPA layer2/layer1 flows ........................................................ ........................................................ 7Figure 4: MAC-hs entity on UTRAN side ............................................................. ............................................. 7Figure 5: Protocol Architecture of E-DCH ............................................................ ............................................. 9Figure 6: UE side MAC architecture .......................................................... ........................................................ 9Figure 7: Transport channel configuration ........................................................... ........................................... 10Figure 8: HSDPA channels and associated R99 channels............................................................... ........... 11Figure 9: Timing relationship at NodeB between physical channels ..................................................... ..... 12Figure 10: HS-SCCH structure........................................................ ................................................................ . 13Figure 11: HS-PDSCH structure ...................................................... ............................................................... . 13Figure 12: HS-DPCCH structure ...................................................... ............................................................... . 14Figure 13: Example of AMC: Throughput versus Ior/Ioc (radio condition)................................................. 16Figure 14: RV parameters assignment algorithm .......................................................... ................................ 19

Figure 15: ACK/NACK/DTX management for HARQ processes ............................................................... . 20Figure 16: Dynamic selection of HARQ type....................................................... ........................................... 23Figure 17: HSUPA channels and associated R99 channels ............................................................. ........... 27Figure 18: E-DPCCH / E-DPDCH frame structure ....................................................... ................................. 29Figure 19: E-DPDCH/E-DPCCH multiplexing on I/Q .............................................................. ...................... 30Figure 20: Uplink physical channels multiplexing .......................................................... ................................ 30Figure 21: E-AGCH frame structure .......................................................... ...................................................... 31Figure 22: E-HICH frame structure ............................................................ ...................................................... 33


33/476




Page 4/38

1 INTRODUCTION

1.1 OBJECT

The objective of this document is to describe from an engineering point of view the

HSDPA & E-DCH (HSUPA) system.

This includes a system description, configuration aspect and engineering

recommendations.

1.2 SCOPE OF THIS DOCUMENT

This document gives an overview of the HSxPA.


34/476




Page 5/38

2 RELATED DOCUMENTS

2.1 HPUG VOLUMES

[Vol. 1] Introduction

[Vol. 2] HSxPA overview

[Vol. 3] HSDPA principles scheduling and resource management

[Vol. 4] E-DCH principles scheduling and resource management

[Vol. 5] Call Management

[Vol. 6] Mobility

[Vol. 7] Deployment scenarios

2.2 REFERENCE DOCUMENTS

[R01] 3GPP TS 25.308 UTRA High Speed Downlink Packet Access

(HSPDA); Overall description; Stage 2

[R02] 3GPP TS 34.108 Common Test Environments for User Equipment

(UE) Conformance Testing

[R03] 3GPP TS 25.212 Multiplexing and channel coding (Release6)

[R04] 3GPP TS 25.214 Physical layer procedures (FDD)

[R05] 3GPP TS 25.306 UE Radio Access capabilities definition

[R06] 3GPP TS 25.213 Spreading and modulation (FDD)

[R07] UMT/BTS/INF/016135 Micro NodeB & 9314 Pico NodeB Feature

Planning Guide

[R08] UMT/IRC/APP/007147 UMTS BTS Product Engineering Information

[R09] UMT/IRC/APP/014654 HSxPA Engineering User Guide UA5.x


35/476



3 SYSTEM OVERVIEW

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

PowerPower

ControlControl

Data Power

Unused Power Data

Unused

Same Throughput

Figure 1: R99 principle

In HSDPA, data are transmitted on a shared channel by using all the available power

and by controlling the downlink user throughput according to the radio conditions:

RateRate

AdaptationAdaptation 100% Power

100%

Figure 2: HSDPA principle

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

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

The efficiency of this rate adaptation is due to a new MAC entity, the MAC-hs layer,

located in the NodeB (see the two following figures), near the physical channel, which

allows a high reactivity in the resource allocation according to the RF conditions

changes. This MAC-hs layer manages the scheduling of users and the

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

Page 6/38


36/476



HS-DSCH

Ass oci ated

Uplink

Signaling

Ass oci atedDownlink

Signaling

DCCH DTCHDTCHMAC Control MAC ControlCCCH CTCHBCCHPCCHMAC Control

RRC (RNC)RRC (RNC)

RLC (RNC)RLC (RNC)


Page 7/38

HS-PDSCH

FACH

S-CCPCH

FACH

S-CCPCH

RACH

PRACH

RACH

PRACH

DSCH

PDSCH

DSCH

PDSCH

DCH

DPCH

CPCH

PCPCH

CPCH

PCPCH

PCH

S-CCPCH

PCHPCH

S-CCPCHHS-DPCCHHS-SCCH

MAC-c/sh

(C-RNC)

MAC-c/sh

(C-RNC)

DCH

DPDCH/DPCCH

R99 L1: Channel Coding / Mult iplexing (NodeB)R99 L1: Channel Coding / Mult iplexing (NodeB)R5 L1: HSDPA (NodeB)R5 L1: HSDPA (NodeB)

MAC-d

(S-RNC)MAC-hs

(NodeB)

MAC-hs

(NodeB)

Figure 3: HSDPA layer2/layer1 flows

Figure 4: MAC-hs entit y on UTRAN side

HSDPA benefits are based on:

New transport and physical channels.

Fast link adaptation.

Fast retransmission mechanism (HARQ). Fast scheduling.


37/476




Page 8/38

HSUPA

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

increase maximum user coverage and throughput for uplink packet data and decreaseuplink packet transmission delay. This Release 6 is fully compatible with the previous

Releases (R99 and R5).

HSUPA uses the same new techniques of HSDPA:

Fast scheduling

Fast retransmission mechanism (HARQ)

Macrodiv TTI ModulationChannel

coding

Power

controlHARQ

Fast

scheduling

Fast l ink

adaptation

HSDPANot

supported

2 ms

only

QPSK and

16QAMTurbo No Supported Supported Supported

HSUPA Supported2 ms,

10 ms

BPSK and

QPSKTurbo Yes Supported

Supported

but less

reactive

Supported

but less

reactive

Table 1: HSUPA / HSDPA comparison

The physical layer is similar to R99:

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

Turbo coding

Spreading on a separate OVSF code and scrambling together with otherphysical channels.

HSUPA is power controlled as for R99. Indeed, HSUPA channels have apower offset relative to DPCCH.


38/476



PHY PHY

EDCH FP EDCH FP

IubUE NodeBUu

DCCHDTCH

TNL TNL

DTCHDCCH

MAC-e

SRNC

MAC-d

MAC-e

MAC-d

MAC-es /MAC-e

MAC-es

Iur

TNL TNL

DRNC

Figure 5: Protocol Architecture of E-DCH

Associated

Downlink

Si na llin

E-DCH

M A C - d

F A CH RA CH

D CCH D T CHD T CH

D S CH D CH D CH

MAC Control

U S CH( TDD only )

CP CH( FDD only )

CT CHBCCH C C C H S H CCH( TDD on ly )

P CCH

P CH F A CH

MAC-c/sh

U S CH( TDD only )

D S CH

MAC-hs

HS-DSCH

Associated

Uplink

Signalling

Associated

Downlink

Signalling

MAC-es /MAC-e

Associated

Uplink

Signalling

Figure 6: UE side MAC archi tecture

3.1 HSDPA

3.1.1 TRANSPORT AND PHYSICAL CHANNELS

In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on

the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are sent

on a HS-DSCH (High Speed Downlink Shared CHannel) which is mapped on one or

several HS-PDSCH (High Speed Physical Downlink Shared CHannel). Users are

multiplexed on the HS-DSCH channel in time and code. Transmission is based on

shorter sub-frames of 2ms (TTI) instead of 10ms in R99.


Page 9/38


39/476



In downlink, the HS-PDSCH are transmitted with the HS-SCCH (High Speed Shared

Control CHannel) channel. This channel is broadcasted over the cell but his

information concerned only the user who has to receive the HS-PDSCH. The HS-

SCCH allows the user to know if the HS-PDSCH is for him and to decode them

correctly.

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

NodeB through the HS-DPCCH channel. This channel allows the NodeB to adapt the

downlink data rate and to manage retransmission process. The HS-DPCCH is divided

in two parts. The first one is the Channel Quality Indicator (CQI) which is a value

between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30

= good radio conditions). The second one is the acknowledgement information: if data

are well received by the UE, the UE sends to the NodeB an Ack, otherwise a Nack.

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

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

figure):

One DCH handling the signaling in both UL and DL,

One DCH transporting the UL traffic,

One HS-DSCH for the DL traffic.

Figure 7: Transport channel configuration


Page 10/38


40/476



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

NodeB

HSDPA UE

HS-PDSCH for data (I/B) traf ficHS-PDSCH for data (I/B) traf fic


Page 11/38

HSDPA channelsHSDPA channels

HS-SCCH signali ng part (UE id, ) associatedto HS-PDSCHHS-SCCH signali ng part (UE id, ) associatedto HS-PDSCH

HS-DPCCH Feedback in formationHS-DPCCH Feedback in formation

Ass ociated DPCH for data, speech + SRB t raffi cAss ociated DPCH for data, speech + SRB t raffi c

Figure 8: HSDPA channels and associated R99 channels

The maximum bit rate that can be achieved in the UL can be the bottleneck for the

maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP

acknowledgements due to low bandwidth in the UL will limit the DL throughput, even if

the RF conditions would allow more.

From UA04.2, the RB adaptation feature is supported. This feature dynamically adapts

the UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from

8kbps up to 384kbps, but 8kbps is not recommended to be activated (configured as

eligible). Therefore, although UL:8 DL:[max bit rate for UE categories 12 and 6] will be

allocated by the RNC if UL:8 is explicitly requested in the RAB assignment, it is not

recommended to do so, otherwise the user will experience low throughput in the DL.

The following flowchart describes the timing relations between the different physical

channels:


41/476



HS-SCCH#2

ACK ACK ACK

7,5 slots

HS-SCCH#1

HS-PDSCH

N_acknack_transmit = 2

2 ms

HS-DPCCH

2 slots

Figure 9: Timing relationship at NodeB between phys ical channels

3.1.1.1 DOWNLINK CHANNELS

The mobile receives a HS-SCCH subframe (see the following figure) containing

control information among which:

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

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

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

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

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

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

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

The SF is fixed to 128. It indicates to which UE data is intended to, on which codes

and with which parameters. There are as many HS-SCCH transmitted during a TTI as

scheduled user number.


Page 12/38


42/476



Data

Slot #0 Slot #1 Slot #2

1 HS-SCCH subframe = 2ms

Tslot = 2560 chips = 40 bits

Figure 10: HS-SCCH structure

A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been

assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this

slot #0, other information are given in slots #1 and 2): the mobile receives a transportblock on one or several HS-PDSCH (see the following figure).

M= 2 for QPSK

(960 coded bits per TTI)

M = 4 for 16QAM

(1920 coded bits per TTI)

Data

Slot #0 Slot #1 Slot #2

1 HS-PDSCH subframe = 2ms

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

Figure 11: HS-PDSCH structure

The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload. The

SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One

HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of

codes is given by UE capabilities).

3.1.1.2 UPLINK CHANNELS

When addressed on HS-SCCH, the UE will then send feedback frame(s) on HS-

DPCCH (SF = 256), roughly 7.5slots after HS-PDSCH frame, containing (see the

following figure):

The HARQ Ack/Nack;

The CQI (Channel Quality Indication).


Page 13/38


43/476



CQI

Subframe #0 Subframe #i Subframe #4

1 radio frame = 10ms

Tslot = 2560 chips

= 10 bits

ACK/NACK

2.Tslot = 5120 chips

= 20 bits

Figure 12: HS-DPCCH structure

The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the

N_acknack_transmit parameter, as specified in [R04]6A.1.1.

Parameter ackNackRepetitionFactor Object HsdpaUserService

Range & Unit [1..4]

User Customer

Class 3

Granularity HsdpaUserService[0..14]

Value 1

UA5.x-UA6.0 Delta: Granularity Change

Because of the 33621 HSPA Configuration at site Granularity feature, its now possible to have until 15

different instances. Different values can also be defined per FDDCell for the parameters under the

HsdpaUserService (this is possible using HsdpaUserServiceId under HsdpaResource)

Restriction: ackNackRepetitionFactorand xCEM

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

value.

The CQI is only sent in some specific subframes, as specified in [R04] 6A.1.1,

depending on the following parameters:

The CQI feedback cycle: k,

The repetition factor of CQI: N_cqi_transmit.

Parameter cqiRepetitionFactor Object HsdpaUserService

Range & Unit [1..4]

User Customer

Class 3


Value 1


Page 14/38
http://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://../CESAR/RMD/Content/Parameters/V6.0/RNC/CNode/HsdpaResource.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://../CESAR/RMD/Content/Parameters/V6.0/RNC/CNode/HsdpaResource.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.html


44/476




Page 15/38

Parameter cqiFeedbackCycleK Object HsdpaUserService

Range & Unit Enum {0, 2, 4, 8, 10, 20, 40, 80, 160} ms

User Customer

Class 3


Value 2

Rule: cqiRepetitionFactor and cqiFeedbackCycleK

These parameters have to respect the following rule:

cqiRepetitionFactorcqiFeedbackCycleK/ 2

Note that cqiFeedbackCycleK= 0 is not supported.

Parameter cqiPowerOffset Object HsdpaUserService

Range & Unit [0..8]User Customer

Class 3


Value 5

Parameter ackPowerOffset Object HsdpaUserService

Range & Unit [0..8]

User Customer

Class 3


Value 6

Parameter nackPowerOffset Object HsdpaUserService

Range & Unit [0..8]

User Customer

Class 3


Value 7

Engineering Recommendation: HS-DPCCH power

Note that power allocated on the HS-DPCCH can be different for each data (Ack, Nack or CQI)

through the power offset parameters: ackPowerOffset, nackPowerOffset and cqiPowerOffset. The

nackPowerOffset has to be higher than the other power offset in order to secure the reception of Nack,a Nack misdetection being unfavorable when TCP retransmission occurs.

3.1.2 FAST LINK ADAPTATION

Every TTI, Adaptive Modulation and Coding (AMC) is updated according to the radio

conditions experienced by the UE and his category (see 4.1). AMC (number of codes,

code rate and modulation type) is chosen among 30 possibilities corresponding to one

CQI in order to reach the maximum bit rate while guarantying a certain QoS (10%

BLER for example). All UE categories have to support QPSK and 16QAM modulation

except categories 11 and 12 which only support QPSK (16QAM modulation allowing
http://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.html


45/476



higher bit rate). The following figure illustrates the AMC by showing the throughput

versus the radio conditions (Ior/Ioc):

QPSK

QPSK

QPSK

16QAM

16QAM

-20 -15 -10 -5 0 50

100

200

300

400

500

600

700

800

Ior/Ioc (dB)

Throughput(kbps)

AMC Il lust rat ion

QPSK

QPSK

QPSK

16QAM

16QAM

QPSK

QPSK

QPSK

16QAM

16QAM

-20 -15 -10 -5 0 50

100

200

300

400

500

600

700

800

Ior/Ioc (dB)

Throughput(kbps)

AMC Il lust rat ion

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

3.1.3 FAST RETRANSMISSION MECHANISM (HARQ)

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

consists in:

Retransmitting by the NodeB the data blocks not received or received witherrors by the UE;

Combining by the UE the transmission and the retransmissions in order toincrease the probability to decode correctly the information.

3.1.3.1 NUMBER OF HARQ PROCESSES

There is an HARQ process assigned per transport block for all the transmissions. The

number of processes per UE is limited and depends on its category. The number of

processes per UE category is the one given in [R02]:

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

Number of HARQ Processes 2 2 3 3 6 6 6 6 6 6 3 6

Table 2: Number of p rocesses per UE category for iCEM


Page 16/38


46/476




Page 17/38

Once this number is reached, the UE should not be eligible by the scheduler for new

transmissions unless one of them is reset (ACK reception, discard timer expiration,

max number of retransmissions reached). If the maximum number of retransmission is

reached or if discard timer (discardTimer or timerT1) expiration, then the MAC-hs PDU

is discarded leading to a RLC retransmission.

The maximum number of allowed MAC-hs retransmissions is :

For iCEM:

Parameter harqNbMaxRetransmissions Object HsdpaConf

Range & Unit [131] decimal

User Customer

Class 3

Granularity BTSCell

Value 7

The two following parameters are common for iCEM and xCEM (RNC parameters):

Parameter discardTimer Object HsdpaUserService

Range & Unit Enum [20; 40; 60; 80; 100; 120; 140; 160; 180 ; 200; 250; 300; 400; 500; 750;1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500] ms

User Customer

Class 3


Value 500

This parameter defines the time to live for a MAC-hs SDU starting from the instant of

its arrival into an HSDPA Priority Queue.The Node B shall use this information to

discard out-of-data MAC-hs SDUs from the HSDPA Priority Queues

Parameter timerT1 Object HsdpaUserService

Range & Unit Enum [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, 400] ms

User Customer

Class 3


Value 100

This parameter is used by the NodeB to stop the re-transmission of the corresponding

MAC-hs PDU (but ignored by the iCEM).

3.1.3.2 RV PARAMETERS

The IR (Incremental Redundancy) and modulation parameters necessary for the

channel coding and modulation steps are: the r, s and b values. The r and s

parameters (Redundancy Version or RV parameters) are used in the second rate

matching stage, while the b parameter is used in the constellation rearrangement step

(see [R03]for details):

s is used to indicate whether the systematic bits (s=1) or the non-systematicbits (s=0) are prioritized in transmissions.

r(range 0 to rmax-1) changes the initialization Rate Matching parameter valuein order to modify the puncturing or repetition pattern.


47/476




Page 18/38

The bparameter can take 4 values (0 3) and determines which operationsare produced on the 4 bits of each symbol in 16QAM. This parameter is not

used in QPSK and constitutes the 16QAM constellation rotation for averaging

LLR at the turbo decoder input.

These three parameters are indicated to the UE by the Xrv value sent on the HS-

SCCH (see section 3.1.1.1). The coding tables of Xrv are given hereafter:

Xrv (Value) s r b

0 1 0 0

1 0 0 0

2 1 1 1

3 0 1 1

4 1 0 1

5 1 0 2

6 1 0 3

7 1 1 0

Table 3: RV coding for 16QAM

Xrv (Value) s r

0 1 0

1 0 0

2 1 1

3 0 1

4 1 2

5 0 26 1 3

7 0 3

Table 4: RV coding for QPSK

The determination of the s, r and b parameters will be based on the Xrv update, but

not necessarily in the increasing order. The update indeed follows a predefined order

stored in a table (called hereafter Trv). The only requirement to fill this table is that

Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be thenominal configuration).


48/476



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

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

Upon reception of a NACK, Xrv is assigned the next value in the table (once

the last value of the table, Nmax, has been set, the next value should be thefirst one again).

In case of no reception of ACK/NACK (DTX indication), the parameters mustnot be updated so that the same information not received by the UE should be

sent again (this ensure no systematic bits are lost, because all blocks may not

be self-decodable).

New transmission ?Xrv = Trv[0]

k = 0

Y

N

DTX indication ? Xrv(n) = Xrv(n-1)Y

N

k = k + 1

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

= 4 (PIR - QPSK)

= 6 (PIR 16QAM)

= 8 (MIR)

Figure 14: RV parameters assignment algorithm

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

3.1.3.3 STATE OF HARQ PROCESSES

The following figure describes the different states of HARQ processes and possible

actions related to these.


Page 19/38


49/476



ACK/NACK/DTX ?

HARQ process assigned

by the scheduler

Y

Update of RV parameters

Data transmissi on

Wait for ACK/NACK

reception

Insertion of DTX

indication

Reset HARQ processRemove Mac-d PDU

Update structures

Nret = Nret +1

Nret > Nret_max ?

Wait for

retransmission

NACK

DTX

N

WACK state

NACK/DTX state

ACK

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

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

a new Transport Block or a retransmission. The RV parameters are computed

accordingly as described before (see 3.1.3.2 RV Parameters section) and data is

transmitted. The HARQ process is then waiting for feedback information

(ACK/NACK/DTX) and is set in the so-called WACK state (Waiting for

Ack/Nack/DTX). The exact timing for reception of the feedback information must be

computed thanks to the chip offset and relatively to the TTI corresponding to the

transmission.

Upon reception of the feedback information, three behaviors occur:

In case of an ACK, the HARQ process is reset and corresponding MAC-dPDUs are removed from memory. This HARQ process can now be used for a

new transmission.

In case of a NACK, the number of retransmissions must be incremented. If themaximum number of retransmissions is not reached, the HARQ process is set

in the so-called NACK state and then inserted in the NACK list of HARQ

processes.

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


Page 20/38


50/476




Page 21/38

changes the RV parameter update compared to Nack reception, that is to say

that the RV parameter update is not the same as for Nack, so no update, see

3.1.3.2RV Parameters section). The process is then set in the DTX state.

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

new retransmission.

3.1.3.4 CHOICE OF THE HARQ TYPE

A configurable parameter (CC/PIR/MIR) indicates the possibility of switching between

Chase Combining, a Partial IR or a mix between Partial and Full IR sequence. It

implies that 3 different tables must be stored (see below), chosen accordingly:

The Chase Combining option corresponds to the first redundancy versionalways applied for all (re)transmissions.

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

taken into account.

The MIR corresponds to a sequence where both systematic and non-systematic bits can be punctured. All possible redundancy versions are

assumed and it corresponds to default version.

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

i 1 2 3 4 5 6 7 8

Xrv(QPSK) 0 2 5 6 1 3 4 7

Xrv(16QAM) 6 2 1 5 0 3 4 7

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

i 1 2 3 4 5 6

Xrv(QPSK) 0 2 4 6

Xrv(16QAM) 6 2 5 0 4 7

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

The choice of the HARQ type (CC, MIR or PIR) is defined for all the retransmissions

by setting the parameter harqType(= 1 for MIR, = 2 for PIR and = 3 for CC). When

the HARQ type is selected, specific RV tables are used, one for QPSK and another

one for 16QAM (as explained in the previous paragraphs).

With the feature HSDPA Performance Enhancement Optimal Redundancy Versionfor HARQ retransmission (29819), a fourth HARQ type can be selected: the Dynamic


51/476



Redundancy noted DR (harqType = 4). This value is introduced to indicate that

dynamic RV selection must be performed.

The aim of this sub-feature is to optimize the redundancy version (RV) of the

retransmissions by dynamically selecting the most efficient HARQ type (and his

corresponding RV table presented below) according to several parameters: UE

category, number of HARQ processes and applied AMC for first transmission.

The different HARQ types (each one being associated to a restricted redundancy

version set) that can be selected are:

Chase Combining (CC): same redundancy version than first transmission isapplied (QPSK only).

RV = 0.

CC + Constellation rearrangement (CC+CoRe): same puncturing pattern isapplied but constellation rotation is performed (16QAM only).

RV [0; 4; 5; 6].

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

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

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

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

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

The principle is that incremental redundancy is only selected when required, i.e. as

soon as punctured bits by the 2nd

Rate Matching stage AND total number of softbits

per HARQ process the UE can handle are higher than the number of transmitted bits.

Otherwise, chase combining is sufficient. In case of IR, it is only necessary to puncturesystematic bits (FIR) in case it is not possible to transmit all parity bits punctured by

the 2nd

RM stage in the first retransmission.

More in detail, during the Rate Matching step, following variables are computed:

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

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

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

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


Page 22/38


52/476



NRM1 = NSYS+ NP1+ NP2

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

RM stage.

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

following figure:

Figure 16: Dynamic selection of HARQ type

Note: As the RV of the 1st transmission is identical whatever the HARQ type is,

previous variables should then be stored during the rate matching of the first

transmission. The HARQ Type only needs to be determined when 1stretransmission

occurs.

Parameters Settings:

See [Vol. 3].

HARQ with xCEM:

For xCEM as for iCEM, an HARQ process is assigned per transport block for all the

transmissions and the number of processes per UE is limited and depends on its

category:


Page 23/38


53/476




Page 24/38

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

Number of HARQ Processes 2 3 3 4 6 6 6 6 6 6 3 6

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

Once this number is reached, the UE should not be eligible by the scheduler for new

transmissions unless one of them is reset (ACK reception, discard timer expiration,

max number of retransmissions reached). If the maximum number of retransmission is

reached or if discard timer (discardTimer or timerT1) expiration, then the MAC-hs PDU

is discarded leading to a RLC retransmission.

The maximum number of allowed MAC-hs retransmissions is :

Parameter harqNbMaxRetransmissionsXcem Object HsdpaConfRange & Unit [131] decimal

User Customer

Class 0

Granularity BTSCell

Value 7

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

The HARQ type selection is done through the parameter harqTypeXcem:

Parameter harqTypeXcem Object HsdpaConf

Range & Unit [ccType, irType]

User CustomerClass 3

Granularity BTSCell

Value irType

The following tables give according to [R03]the redundancy version and constellation

depending on the modulation:

i 1 2 3 4

Xrv(QPSK) 0 2 5 6

Xrv(16QAM) 6 2 1 5

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

i 1 2 3 4

Xrv(QPSK) 0 0 0 0

Xrv(16QAM) 0 4 5 6

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


54/476




Page 25/38

3.1.4 FAST SCHEDULING

The aim of the MAC-hs scheduler is to optimize the radio resources occupancy

between users. Every TTI, it must then select Queue IDs for which data is going to be

transmitted and the amount of corresponding MAC-d PDUs to transmit.

[iCEM]

The scheduler first receives as input every TTI the number of codes available and the

remaining power for HS-PDSCH and HS-SCCH (see [Vol. 3]). The received

ACK/NACK and CQI must also be provided to the scheduler when available. Thanks

to this information, UE capabilities, configuration parameters provided by the RNC and

taking into account the previously scheduled data, the scheduler can select the sub

flows of the users to schedule in order to optimally use available resources. The main

concepts of the scheduler are: Retransmissions are of higher priority than new transmissions and should be

scheduled first.

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

The transport blocks should always be optimized according to the transmittedCQI when possible (if enough codes and power are available and if theres no

CPU limitation).

No queue ID should be left starving, i.e. the scheduler should always allocate

even a small part of radio resources to all users (even those with low priorityand bad CQI).

From UA5.0, the MAC-hs scheduler has been enhanced (29807 MAC-hs scheduler

improvement) in order to support 2 MAC-hs scheduler types (Classical Proportional

Fair, ALU Proportional Fair,) and manage SPI.

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

Classical Proportional Fair: Users are chosen according to the instantaneousCQI/averaged CQI criteria. UEs that are in their best instantaneous conditions

with regard to their average are scheduled first.

Alcatel-Lucent Proportional Fair scheduler: Users are chosen according to thenumber of transmitted bits and the reported CQI

[xCEM]

The aim of the scheduler is to share the resources between the different HSDPA

users. xCEM scheduler works in following steps:

- To select of a limited number of users from those which are ready for

transmission in the curret TTI (the number of users per TTI being

limited by the number of HS-SCCH configured and by the available

resources mainly in term of codes and power).


55/476




Page 26/38

- To select of a Transport Format resource Combination (TFRC =

{MAC-hs PDU size; number of HS-PDSCH codes; modulation

alphabet}) of each user.

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

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

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

With iCEM, the TFRC is chosen by doing a mapping between the CQI (CQI processed

in order to take into account the bler target and to fit with the available resources).

With xCEM, the TFRC selection is based on the Spectral Efficiency (SE). The SE for a

given SINR states the maximal number of bits before channel encoding and before

addition of C

Documents

HSxPA Parameters User Guide