HPUG UA7 Preliminary External V04.05 Jun10

8/12/2019 HPUG UA7 Preliminary External V04.05 Jun10

1/506


2/506

Copyright 2010 by Alcatel-Lucent. All Rights Reserved.

About Alcatel-Lucent

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

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

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

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

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

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

lucent.com

Notice

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

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

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

described.

Trademarks

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

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

Lucent assumes no responsibility for inaccuracies contained herein.

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


3/506

CONTENTS

1 INTRODUCTION2 HSXPA OVERVIEW3 HSDPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT4 HSUPA PRINCIPLES, SCHEDULING & RESOURCE MANAGEMENT5 CALL MANAGEMENT6 MOBILITY7 DEPLOYMENT SCENARIOS



4/506

HSXPAPARAMETERS USER GUIDE

1 INTRODUCTION



5/506

HSxPA Parameters User Guide 04.05 / EN 04/Jun/2010UMT/IRC/APP/016664 EXTERNAL Preliminary

Volume 1 : Introduction

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

Page 1/23

CONTENTS

1 INTRODUCTION..........................................................................................................................101.1 OBJECT..................................................................................................................................10

1.2 SCOPE OF THIS DOCUMENT .....................................................................................................11

1.3 AUDIENCE FOR THIS DOCUMENT ..............................................................................................11

1.4 NOMENCLATURE .....................................................................................................................12

1.5 RELATED DOCUMENTS ............................................................................................................14

2 PARAMETERS ORGANIZATION ...............................................................................................15

3 ABBREVIATIONS AND DEFINITIONS.......................................................................................173.1 ABBREVIATIONS ......................................................................................................................17

3.2 DEFINITIONS...........................................................................................................................22


6/506




Page 2/23

PUBLICATION HISTORY

05/06/2010

Issue 04.05 / EN,

Updates:

In Volume 3:

Clarification concerning activation of feature 75998 (detailing on feature

support per type of controller board and iso-functional behaviour with

hsdpaWindowsObserveTime set to 100ms)

Inclusion of section 9.6 dedicated to description of feature 97431 HSDPA

OLS Differentiation at Node B Level

Clarification of numberOfHsPdschCodes when Fair sharing or DCTM is

activated and use of activityFactorCcch in OCNS and HSDPA power

calculations

Clarified HS-DSCH required power reports unit of measurement and its flow

In Volume 4:

Note introduced concerning the settings for the parameter

maxEdchCommonChannelPower

In Volume 5:

Restriction note introduced concerning the utilisation of the feature GBR withthe feature HSDPA OLS Differentiation at NodeB Level

Clarification regarding the Mac-hs GBR formula when the HSDPA call

operates in flexible RLC mode.

In Volume 6:

Update on communication for feature 34475; feature 34475 is a globalization

of 33480

Remove Section 8 EXAMPLE OF INTER-FREQUENCY AND INTER-

SYSTEM SCENARIO from HPUG

Update on definition for parameters isHsdpaHhoWithMeasAllowed and

isEdchHhoWithMeasAllowed

Introduction of the parameter isNbapCr1462Supported

Miscellaneous clarifications (terminology) regarding the feature E-DCH

Macro-Diversity

In Volume 7:

Update on iMCTA strategy for different topologies; Speech calls always

rescue to GSM

Update on HSxPA requirements for Load Balancing configurations, includingFair Sharing reservation on codes recommendation


7/506




Page 3/23

26/03/2010

Issue 04.04 / EN,

Updates:

In Volume 1:

History update

In Volume 3:

Clarification concerning the DCTM activation

Update of the "Pre-requisites to reach the maximum throughput with 64QAM"

Removal of the UA6 restriction concerning the setting of

maxHspaPowerOffset (from UA7, other value than 0dB can be used)

Clarification of section Transport Block Size Optimization concerning the

iCem and xCem applicability

Clarification concerning the selection of the UL SIR Target parameters

min/max/initialSirTargetEdch2ms or min/max/initialSirTargetHsdpa or

min/max/initialSirTarget

Update of the server configuration (socket buffer size) for maximum HSDPA

throughput.

Modification of the range and format of rlcRetransmissionBufferInBytes

Clarification of the recommendation for prohibitedStatusTimer in the objectDlRlcAckFlexibleMode (10s)

In Volume 4:

Modification of the recommended value for gRakeActivation

Description of the enablePeriodicSirTargetUpdate for the UL SIR target

update mechanism

Add the recommended value for happyBitDelay on UCU-III.

Clarification for the nHarqRetransTargetSx and

maxNumActiveEdchUsersPerCellForSx : dependant on several factors.

Editorial modification: the recommended values for UL SIR Targets are

removed in order to avoid duplication in both HPUG and UPUG.

In Volume 5:

Remove section 3 MULTI-CARRIER MANAGEMENT; the content of this

section is transferred to UPUG

In Volume 6:

Update concerning the suspend time offset: suspendTimeOffset parameter

is replaced with iubSuspendTimeOffset andiurSuspendTimeOffset

Update of the feature 34475 Compressed Mode in MAC-e: globalization for

US Market of the feature 33480.


8/506




Page 4/23

New section added 5 INTER-CARRIER MANAGEMENT FOR HSXPA

In Volume 7:

UCU-III capabilities added

Following sentence deleted Note that HSUPA mobiles working at 900MHz

are not available because there are in UA7 900MHz UE doing HSUPA

New sections added to the document:

FOUR CARRIER DEPLOYMENT SCENARIOS

UMTS 2100/1900 MHZ VERSUS UMTS 900/850 MHZ

TYPICAL SCENARIOS FOR NEIGHBOR DECLARATION

CPICH DESIGN CHOICES

Remove section STSR2 VERSUS STSR 1+1

13/11/2009

Issue 04.03 / EN,

Updates:

In Volume 1:

History update

Clarification of the nomenclature concerning the green frame (green frame

can be used to explain differences between 2 consecutive or non consecutivereleases)

In Volume 2:

New recommended value for cqiPowerOffset

In Volume 3:

New recommended value for serviceBFactorand serviceMaxRate

Update of the recommendation concerning the Pre-requisites to reach the

maximum throughput with 64QAM

Clarification of the HS-DSCH allocated power (factor) in case of 64QAM

Correct the parameter name of HSDPA_packet_error_rate_target (not

HSDPA_packet_error_rate_target )

Clarification concerning the UCUIII parameters (they are tunable parameters)

Clarification concerning the Engineering Recommendation: Maximum

HSDPA throughput

Additional information provided on implemented solution for feature PM75998

Radio Measurement Frequency Increase: Tx Power

Feature 34388 Layer 2 Enhancements. Correction regarding the

recommended value of DlRlcQueueSizeForUeCat, clarification regarding the

rule for maxIubHsDschFrameSize


9/506




Page 5/23

In Volume 4:

Introduction of the parameter locFrequencyReuseFactor

Better explanation was introduced concerning the parameters:

edchBLSupervisionTimer, edchBLStepReductionFrameLoss,edchBLStepIncrease andedchBLIubBandwidth.

Update was done to section 7.1: MAC-E Scheduler Inputs - Measurements

Feature 34249 EUL Capacity Optimized HARQ Operation. The deactivation

of the feature for the iCEM is no longer done through a patch MIB, it is

deactivated by default.

Feature 33481 E-DCH DL control channels Power Control. Correction

regarding the activation flags: the parameter agchPowerControlActivatedis

not an activation flag. This parameter is an obsolete parameter.

Feature 34633 E-DCH Mac-e throughput of 10Mbps. Correction regardingthe recommended value for edchMaxThroughputXcem (it shall automatic

instead of 7680).

Feature 34441 2ms TTI on OneBTS. Changes used to describe the

implementation of the 2ms TTI on OneBTS (using the UCU-III) including new

E-TFCI tables and other parameter settings specific to this platform.

In Volume 5:

Clarification of the recommendation concerning

transportTypeSelectionTransferDelayThreshold

Clarification of the minBrForHsdpa recommendation concerning the flagactivateOls

Section 3.2.2 Call Type added a note for UA6-UA7 Delta: Causes no longer

available for redirection

Section 3.2 iMCRA, deleted all references to old UA6 parameters

isRedirectionForTrafficSegmentation and

isRedirectionBasedOnEstablishmentCause and TwinCellId

Section 3.2.9 Parameters, updated definition for TwinCellListto include CRe

00192926 - Twin cell collocated or notupdate;

In Volume 6:

Update concerning the suspendTimeOffset parameter.

Feature 34475 Compressed Mode in MAC-e including DL E-DCH

transmission

In Volume 7:

Feature 29808 Multi-Carrier PA power pooling. Clarification regarding the

supported radio configurations and the rules regarding CEM pool.


10/506




Page 6/23

23/09/2009

Issue 04.02 / EN,

Updates:

In Volume 1:

History update

In Volume 2:

harqNbMaxRetransmissionsXcem parameter changed from class 2 to

class 3

UA5 restrictions removed and 64-QAM HS-DSCH UE category added

In Volume 3:

hsdpaSchedulerWeightingFactorXcem ,

hsdpaBlerTargetUpperLimitXcem , hsdpaBlerTargetLowerLimitXcem ,

hsdpaUECategoryThroughputWeightingXcem , minimumPowerForHsdpa

and maxHspaPowerOffsetparameters changed from class 0 to class 3

Parameter name changed from isRlcReconfigAllowedForR99 in UA6.0 to

is2ndRrcRbReconfNeededForQC7200 in UA7.0.

Feature 34388 Layer 2 Enhancements: Flexible RLC and MAC-ehs: new

recommendation for hsdschSlowStartPeriod (recovery from burst cases),

rlcRetransmissionBufferInKbytes.

New recommendation for eligibleUeCategoryForHighPerformance,

isHighPerformancePduSizeReconfAllowed,

eligibleUeCategoryForSirTargetHsdpa (the Release7 UE Cat 13, 14, 17

and 18 are eligible)

New value concerning the TBS applied from maximum MCS for Category

10 and xCem

Update of the Engineering Recommendation concerning the maximum

HSDPA throughput for UE Cat.10

Update of the parameter settings for maximumTokenGenerationRateand

bucketBufferTimeSapied from maximum MCS for UE category 14

In Volume 4:

edchInitialTBIndex10msTTI, edchInitialTBIndex2msTTI,

edchSpiRelativeWeight, ergchPowerSignature ,

eagchErgchEhichTotalPower, eagchPowerOffset,

eagchPowerOffsetEdchTti2ms , ehichPowerOffset ,

ehichPowerOffsetEdchTti2ms , ergchPowerOffset and

ergchPowerOffsetEdchTti2ms parameters changed from class 0 to class 3.

Update to the feature 75786 iBTS Local Congestion Control. Change made

on the activation flag parameters name: from edchCMActivation (UA6 and

UA7.0)toedchLocalCongestionControlActivation(UA7.1).

New parameters available, in replacement of spare parameters or for

miscellaneous EDCH enhancements: isSrbOnEdchForAllEdchCategory ,


11/506




Page 7/23

isSrbOnEdchForAllMinSf, isSrbOnEdchForAllEdchTti,

eligibleUeCategoryForSirTargetEdch2ms, initialSirTargetEdch2ms ,

minSirTargetEdch2ms , maxSirTargetEdch2ms,

maxMacePduContentsSizeForNonScheduledModeTti2,

maxMacePduContentsSizeForNonScheduledModeTti10,isTpcAlgo2ForEdchCat4 , isTpcAlgo2ForEdchCat6 ,

NHarqRetransTarget2msCat4and NHarqRetransTarget2msCat4

Feature 34633 e-DCH MAC-e Throughput increase to 10Mbps

Feature 34393 Advanced Receiver for High UL Data Rate

New recommendation for maxNrOfErgchEhich

In Volume 5:

Introduction of the feature 34018 - Multiple PS I/B on HSUPA

CR00187250 update related to iMCRA feature;

Update of the ue categories using the parameter

ovsfCodesThroughput16QamUE

In Volume 6:

targetNonServingToTotalEdchPowerRatio parameter changed from class

2 to class 3

Introduction of the new UA7.0/UA7.1 parameter

reserved0/isRnsapCr1357Supportunder NeighbouringRNC.

Feature 34388 Layer 2 Enhancements: Flexible RLC and MAC-ehs: clarify

the interaction between MAC-ehs and SRNS Relocation UE not involved.

In Volume 7:

isPowerPoolingActivated and paOverbookingRatio parameters changed

from class 0 to class 3

31/07/2009

Issue 04.01 / EN, Preliminary

Updates:

In Volume 1:

History update

In Volume 2:

None

In Volume 3:

Introduction of the feature 34388 Layer 2 Enhancements: Flexible RLC and

MAC-ehs (section 5.5)

Clarification of the recommendation concerning the Mac-d PDU size for Cat.6and 12


12/506




Page 8/23

Introduction of the feature 34386 64 QAM for HSDPA

Range of serviceMaxRate, serviceMinRate, serviceHighRate,

serviceLowRatecorrected

New recommendation for serviceHighRate

Class of numberOfHsPdschCodes and numberOfHsScchCodes corrected

New recommendation for hsdpaSchedulerAlgorithmXcem

Update of the TBS applied from maximum MCS for UE Category 10 with

flexible Mac-d pdu and 656 bits Mac-d pdu and for UE Category 14

Update of recommendation concerning the Pre-requisites to reach the

maximum throughput with 64QAM

In Volume 4:

None

In Volume 5:

Restructuration made for chapter named RRC TRAFFIC SEGMENTATION;

Chapter renamed to iMCRA.

Description of 75069 iMCRA - Intelligent Multi-Carrier RRC Connection

Allocation

Recommended value for dlTxPowerEstimationcorrected

In Volume 6:

Description of the mobility cases involving a RB reconfiguration from/to MAC-ehs

In Volume 7

None


13/506




Page 9/23

FIGURES

Figure 1: Static and Configuration Parameters 15


14/506




Page 10/23

1 INTRODUCTION

1.1 OBJECT

The HSxPA Parameters User Guide (HPUG) document provides parameters setting

recommendations from Alcatel-Lucents experience, coming from studies, simulations

and experimentations. It gives the rationales of these settings by describing the

HSDPA & E-DCH (HSUPA) system from an engineering point of view. It also gives

some engineering rules related to parameters settings. This includes a system

description, configuration aspect and engineering recommendations.

The HPUG does not contain the complete list of configuration parameters, this

objective being covered in [R01].

The parameters described in this document are mainly customer configuration

parameters accessible by the customer (operator) via the MMI of the OMC.

Nevertheless, some manufacturer configuration parameters as well as some static

parameters are also covered when they are required to understand the different

UMTS mechanisms.

In the case where the recommended values of the HPUG are different from any other

document, the HPUG recommended should prevail.

The parameter values in HPUG are the recommended values by Alcatel-Lucent, which

means that they are the best values to achieve the optimal network performance.

A common and single load is delivered to address the needs of all Alcatel-LucentWCDMA customers, which are grouped into two different markets due to their

particular functional specificities:

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

(former Lucent OneBTS) is deployed

Global Market, i.e. any other customers

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

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

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

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

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

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

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

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

Dependencies section.

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

Node B. For the list of features supported on these products please refer to 33341

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

descriptions.


15/506




Page 11/23

1.2 SCOPE OF THIS DOCUMENT

Features behaviour or features can be specific to one board or common for several

boards. In the next volumes, the following rule is applied to define the feature

applicability:

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

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

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

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

III].

No tag indicates that the behaviour or the feature is common for all the

boards.

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

[R01]a.[R02].

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

specific document:

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

- Volume 8: Capacity refer to [R04]

- Volume 9: Product recommendations refer to [R05]

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

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

your account and PLM prime.

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

Restrict ion: Pico/Micro NodeBThe Pico/Micro NodeB product is out of scope of this document, thus all engg information, algorithms

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

Lucent NodeB products.

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

1.3 AUDIENCE FOR THIS DOCUMENT

This document targets an audience involved in the following activities:

RF engineering


16/506


17/506




Page 13/23

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

following abbreviations are used:

o N.A.: Not Applicable.

o N.S.: Not Significant.

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

configuration. Example: addressing parameters).


18/506




Page 14/23

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/ 025020 UA07 Feature Planning Guide

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

Planning Guide


19/506



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.

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


Page 15/23

RNC OMC WPS

Static

Non-Static

WPS Templates

Manufacturer

Customer

CIQ

OMC

database System DRF

Figure 1: Static and Configuration Parameters

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

configuration parameters.

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


20/506




Page 16/23

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

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

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

the following classes:

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

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

MIB built (either 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 establishment, SRLR).

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


21/506




Page 17/23

3 ABBREVIATIONS AND DEFINITIONS

3.1 ABBREVIATIONS

ACK Acknowledgment

AICH Acquisition Indicator Channel

AM Acknowledged Mode

AMC Adaptive Modulation and Coding

ARP Allocation Retention Priority

ARQ Automatic Repeat Request

ATM Asynchronous Transfer Mode

AS Active Set

BBU Base-Band Unit

BLER Block Error Rate

CAC Call Admission Control

CC Chase Combining

CCPCH Common Control Physical Channel

CE Channel Element

CEM Channel Element Module

CFN Connection Frame Number

CM Compressed ModeCN Core Network

CP Passport: Control Processor

CPICH Common Pilot Channel

CRC Cyclic Redundancy Check

CS Circuit Switched

DCH Dedicated Channel

DDM Dual Duplexer Module

DL Downlink

DPCCH Dedicated Physical Control Channel

DPDCH Dedicated Physical Data Channel

DS Delay Sensitive

DS1 Digital Signal level 1 (1.544 Mbit/s)

DTX Discontinuous Transmission

E-AGCH Enhanced Access Grant Channel

ECC E-DCH Congestion Control

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

E-DPCCH Enhanced Dedicated Physical Control ChannelE-DPDCH Enhanced Dedicated Physical Data Channel


22/506




Page 18/23

E-HICH Enhanced Hybrid ARQ Indicator Channel

E-RGCH Enhanced Relative Grant Channel

E-TFC E-DCH Transport Format Combination

E-TFCI E-DCH Transport Format Combination IndicatorEUL Enhanced Uplink (stands for E-DCH)

FP 3GPP: Frame Protocol

Alcatel-Lucent Passport: Function Processor

FRS Feature Requirements Specification

GMM GPRS Mobility Management

G-RAKE Generalized rake receiver

GRF Global Reduction Factor

H-ARQ Hybrid ARQ

HCS Hierarchical Cell Structure

HS-DSCH High Speed Downlink Shared Channel

HS-SCCH Shared Control Channel for HS-DSCH

HSDPA High-Speed Downlink Packet Access

HSUPA High-Speed Uplink Packet Access

HHO Hard Handover

HO Handover

IE Information Element

iMCTA intelligent Multiple Carrier Traffic Allocation

iMCRA intelligent Multiple Carrier Re-direction Algorithm

iRM intelligent RAB mapping

IMEI International Mobile Equipment Identification

IMSI International Mobile Subscriber Identification

IP Internet Protocol

IR Incremental Redundancy

KPI Key Performance Indicator

LA Location Area

LAC Location Area Code

LCG Local Cell Group

MAC Medium Access Control

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

MIB 3GPP: Master Information Block;

Alcatel-Lucent RNC/NodeB: Management Information Base

MMI Man-Machine Interface

MO Mobile Originated

MT Mobile Terminated

NACK Negative Acknowledgement


23/506




Page 19/23

NAS Non Access Stratum

NBAP NodeB Application Part

NDS Non-Delay Sensitive

OAM Operations, Administration and MaintenanceOLPC Outer-Loop Power Control

OLS Olympic Level Service

OMC Operations and Maintenance Center

OMC-B OMC NodeB

OMC-R OMC RNC

OVSF Orthogonal Variable Spreading Factor

PA Power Amplifier (stands for MCPA)

P-CCPCH Primary CCPCH

PCPCH Physical Common Packet Channel

P-CPICH Primary CPICH

PCR Peak Cell Rate

PDU Protocol Data Unit

PICH Paging Indicator Channel

PLMN Public Land Mobile Network

PRACH Physical Random Access Channel

PS Packet Switched

P-SCH Primary SCHPSCR Physical Shared Channel Reconfiguration

QAM Quadrature Amplitude Modulation

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RA Registration Area

RAB Radio Access Bearer

RACH Random Access Channel

RAN Radio Access Network

RANAP Radio Access Network Application Part

RAT Radio Access Technology

RB Radio Bearer

RL Radio Link

RLS Radio Link Set

RLC Radio Link Control

RMS Root Mean Square

RNC Radio Network Controller

RNC-AN RNC Access NodeRNC-CN RNC Control Node


24/506




Page 20/23

RNC-IN RNC Interface Node

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

RoT Rise over Thermal

RRC Radio Resource ControlRRM Radio Resource Management

RSCP Received Signal Code Power

RSN Retransmission Sequence Number

RSSI Received Signal Strength Indicator

RTWP Received Total Wideband Power

SCCP Signalling Connection Control Part

S-CCPCH Secondary CCPCH

SCH Synchronization Channel

S-CPICH Secondary CPICH

SCR Sustainable Cell Rate

SDU Service Data Unit

SF Spreading Factor

SFN System Frame Number

SHO Soft Handover

SI Scheduling Information

SIB System Information Block

SM Session ManagementSRB Signalling Radio Bearer

SRLR Synchronous Radio Link Reconfiguration

SS7 Signalling System 7

S-SCH Secondary SCH

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

TFC Transport Format Combination

TFCI Transport Format Combination Indicator

TFCS Transport Format Combination Set

THP Traffic Handling Priority

TM Transparent Mode

TNL Transport Network Layer

TRB Traffic Radio Bearer

TrCH Transport Channel

TRM Transceiver Module

TS Technical Specification

TTI Transmission Time Interval

UBR Unspecified Bit RateUE User Equipment


25/506




Page 21/23

UL Uplink

UM Unacknowledged Mode

URA UTRAN Registration Area

UTRAN Universal Terrestrial Radio Access NetworkVCC Virtual Channel Connection

VP Virtual Path


26/506




Page 22/23

3.2 DEFINITIONS


27/506




Page 23/23

END OF DOCUMENT


28/506

HSXPAPARAMETERS USER GUIDE

2 HSXPA OVERVIEW



29/506


30/506

HSxPA Parameters Guide 04.05 / EN 04/Jun/2010UMT/IRC/APP/016664 EXTERNAL Preliminary

Volume 2 : HSxPA Overview


Page 2/37

TABLES

Table 1: HSUPA / HSDPA comparison 8

Table 2: Number of processes per UE category for iCEM 16Table 3: Number of processes per UE category for xCEM/UCU-III 17Table 4: RV coding for 16QAM 18Table 5: RV coding for QPSK 19Table 6: RV update table in the MIR case (Trv[i]) 22Table 7: RV update table in the PIR case (Trv[i]) 22Table 8: RV updates tables when harqType set to Dynamic Redundancy 23Table 9: RV update table in the IR case (Trv[i]) 25Table 10: RV update table in the CC case (Trv[i]) 25Table 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


31/506




Page 3/37

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 throughput or BLER versus radio conditions for different modulation ................ 16Figure 14: RV parameters assignment algorithm .......................................................... ................................ 20

Figure 15: ACK/NACK/DTX management for HARQ processes ............................................................... . 21Figure 16: Dynamic selection of HARQ type....................................................... ........................................... 24Figure 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


32/506


33/506




Page 5/37

2 RELATED DOCUMENTS

2.1 HPUG VOLUMES

[Vol. 1] Introduction

[Vol. 2] HSxPA overview

[Vol. 3] HSDPA principles scheduling and resource management

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

[Vol. 5] Call Management

[Vol. 6] Mobility

[Vol. 7] Deployment scenarios

2.2 REFERENCE DOCUMENTS

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

(HSPDA); Overall description; Stage 2

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

(UE) Conformance Testing

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

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

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

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

[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

[R10] UMT/SYS/DD/013319 HSDPA System Specification


34/506



3 SYSTEM OVERVIEW

HSDPA[R01]3GPP has standardized HSDPA in Release 5 in order to increase maximum

user throughput for downlink packet data (streaming, interactive and background

traffic classes) and decrease downlink packet transmission delay. This Release 5 is

fully compatible with the previous Release 99 (R99).

In R99, data are transmitted on a dedicated channel with a given user throughput and

a downlink transmitted power controlled according to the radio conditions:

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/37


35/506


36/506




Page 8/37

HSUPA

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

increase maximum user coverage and throughput for uplink packet data and decrease

uplink packet transmission delay. This Release 6 is fully compatible with the previous

Releases (R99 and R5).

HSUPA uses the same new techniques of HSDPA:

Fast scheduling

Fast retransmission mechanism (HARQ)

Macrodiv TTI ModulationChannel

coding

Power

controlHARQ

Fast

scheduling

Fast l ink

adaptation

HSDPANot

supported

2 ms

only

QPSK and

16QAM Turbo 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.


37/506



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/37


38/506



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

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

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

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

correctly.

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

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

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

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

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

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

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

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

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

figure):

One DCH handling the signaling in both UL and DL,

One DCH transporting the UL traffic,

One HS-DSCH for the DL traffic.

Figure 7: Transport channel configuration


Page 10/37


39/506



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/37

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:


40/506



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. value 0 isQPSK and value 1 is 16QAM or 64-QAM (distinction between 16-QAM and

64-QAM is explained in [R10])

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

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

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

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

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

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

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

scheduled user number.


Page 12/37


41/506



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


M = 6 for 64QAM


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/37


42/506



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.

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

depending on the following parameters:

The CQI feedback cycle: k,

The repetition factor of CQI: N_cqi_transmit.

Parameter cqiRepetitionFactor Object HsdpaUserService

Range & Unit [1..4]

User Customer

Class 3


Value 1


Page 14/37
http://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.htmlhttp://../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://../RMD/Content/Parameters/V6.0/RNC/CNode/HsdpaResource.htmlhttp://c/Program%20Files/RMD/Content/Parameters/V5.0/RNC/CNode/HsdpaUserService.html


43/506




Page 15/37

Parameter cqiFeedbackCycleK Object HsdpaUserService

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

User Customer

Class 3


Value 2

Rule: cqiRepetitionFactor and cqiFeedbackCycleK

These parameters have to respect the following rule:

cqiRepetitionFactorcqiFeedbackCycleK / 2

Note that cqiFeedbackCycleK= 0 is not supported.

Parameter cqiPowerOffset Object HsdpaUserService

Range & Unit [0..8]User Customer

Class 3


Value 6

Parameter ackPowerOffset Object HsdpaUserService

Range & Unit [0..8]

User Customer

Class 3


Value 6

Parameter nackPowerOffset Object HsdpaUserService

Range & Unit [0..8]

User Customer

Class 3


Value 7

Engineering Recommendation: HS-DPCCH power

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

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

nackPowerOffset has to be higher than the other power offset in order to secure the reception of Nack,a Nack misdetection being unfavorable as it will result in RLC or worst case TCP retransmissions.

3.1.2 FAST LINK ADAPTATION

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

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

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

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

BLER for example). The capabilities of the UE in term of modulation depend on their

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


44/506



- categories 11 and 12 support only QPSK,

- categories lower or equal to 10 support QPSK and 16QAM

- categories 13, 14, 17, 18 support QPSK, 16QAM and 64QAM

16QAM modulation allowing higher bit rate than QPSK and 64QAM modulation

allowing higher bit rate than 16QAM. The following figures illustrate the gain (in term of

throughput or BLER) according to the modulation:

QPSK

QPSK

QPSK

16QAM

16QAM

-20 -15 -10 -5 0 50

100

200

300

400

500

600

700

800

Ior/Ioc (dB)

Throughput

(kbps)

AMC Ill ust rati on

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 Ill ust rati on

Figure 13: Example of throughput or BLER versus radio condi tions for dif ferent modulation

3.1.3 FAST RETRANSMISSION MECHANISM (HARQ)The HARQ (Hybrid Automatic Repeat Query) is a retransmission mechanism which

consists in:

Retransmitting by the NodeB the data blocks not received or received 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]:

[iCEM]

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

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

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


Page 16/37


45/506




Page 17/37

[xCEM][UCU-III]

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

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

Table 3: Number of processes per UE category 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:

[iCEM]:

Parameter harqNbMaxRetransmissions Object HsdpaConf

Range & Unit [131] decimal

User Customer

Class 3

Granularity BTSCell

Value 7

[xCEM]

Parameter harqNbMaxRetransmissionsXcem Object HsdpaConfRange & Unit [131] decimal

User Customer

Class 3

Granularity BTSCell

Value 7

[UCU-III]

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

[iCEM][xCEM]:

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

Parameter discardTimer Object HsdpaUserService

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

User Customer

Class 3


Value 500

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

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

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


46/506




Page 18/37

Parameter timerT1 Object HsdpaUserService

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

User Customer

Class 3


Value 100

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

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

3.1.3.2 RV PARAMETERS

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

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

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

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

(see [R03]for details):

s is used to indicate whether the systematic bits (s=1) or the non-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.

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 13 0 1 1

4 1 0 1

5 1 0 2

6 1 0 3

7 1 1 0

Table 4: RV coding for 16QAM


47/506




Page 19/37

Xrv (Value) s r

0 1 0

1 0 0

2 1 1

3 0 1

4 1 2

5 0 2

6 1 3

7 0 3

Table 5: RV coding for QPSK

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

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

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

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

nominal configuration).

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

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

Upon reception of a NACK, Xrv is assigned the next value in the table (oncethe last value of the table, Nmax, has been set, the next value should be the

first one again).

In case of no reception of ACK/NACK (DTX indication), the parameters 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).


48/506



New transmission ?Xrv = Trv[0]

k = 0

Y

N

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

N

k = k + 1

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

= 4 (PIR - QPSK)

= 6 (PIR 16QAM)

= 8 (MIR)

Figure 14: RV parameters assignment algorithm

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

3.1.3.3 STATE OF HARQ PROCESSES

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

actions related to these.


Page 20/37


49/506



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.2RV 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 21/37


50/506




Page 22/37

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

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

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

[iCEM]

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

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

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

The Chase Combining option corresponds to the first redundancy 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 6: RV update table in the MIR case (Trv[i ])

i 1 2 3 4 5 6

Xrv(QPSK) 0 2 4 6

Xrv(16QAM) 6 2 5 0 4 7

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

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

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

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

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


51/506



With the feature HSDPA Performance Enhancement Optimal Redundancy Version

for HARQ retransmission (29819), a fourth HARQ type can be selected: the Dynamic

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

dynamic RV selection must be performed.

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

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

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

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

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

version set) that can be selected are:

Chase Combining (CC): same redundancy version than first transmission 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 8: RV updates tables when harqType set to Dynamic Redundancy

The principle is that incremental redundancy is only selected when required, i.e. assoon as punctured bits by the 2

ndRate Matching stage AND total number of softbits

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

Otherwise, chase combining is sufficient. In case of IR, it is only necessary to puncture

systematic bits (FIR) in case it is not possible to transmit all parity bits punctured by

the 2nd

RM stage in the first retransmission.

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

NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes 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.


Page 23/37


52/506



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

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

NRM1 = NSYS+ NP1+ NP2

NPUNC2= NRM1 - NDATA: number of bits punctured by 2ndRM 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 firsttransmission. The HARQ Type only needs to be determined when 1

stretransmission

occurs.

Parameters Settings:

[Vol. 3]See .

[xCEM]

The HARQ type selection is done through the parameter harqTypeXcem:


Page 24/37


53/506




Page 25/37

Parameter harqTypeXcem Object HsdpaConf

Range & Unit [ccType, irType]

User Customer

Class 3

Granularity BTSCell

Value irType

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

depending on the modulation:

i 1 2 3 4

Xrv(QPSK) 0 2 5 6

Xrv(16QAM) 6 2 1 5

Xrv(64QAM) 6 2 1 5

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

[xCEM] only:

i 1 2 3 4

Xrv(QPSK) 0 0 0 0

Xrv(16QAM) 0 4 5 6

Xrv(16QAM) 0 4 5 6

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

3.1.4 FAST SCHEDULING

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

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

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

[iCEM]

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

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

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

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

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

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

concepts of the scheduler are:

Retransmissions are of higher priority than new transmissions and should bescheduled first.


54/506




Page 26/37

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 allocateeven a small part of radio resources to all users (even those with low priority

and bad CQI).

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

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

Fair, ALU Proportional Fair,) and manage SPI.

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

Classical Proportional Fair: Users are chosen according to the 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).

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

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

alphabet}) of each user.

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

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

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

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

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

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

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

addition of CRC bits and tail bits for terminating the Turbo Code that can be

transmitted over an AWGN channel with a certain BLER. The SINR is based on the

CQI reported by the ue.


55/506



3.2 HSUPA (E-DCH)

3.2.1 TRANSPORT AND PHYSICAL CHANNELS

HSUPA proposed the following set of new physical channels:

E-DPCCHcarries the UL signaling information

E-DPDCHcarries the data traffic

E-HICH (Hybrid ARQ Indicator Channel) in DL to indicate if the ULtransmission are well received (ACK/NACK channel)

E-AGCH(Absolute Grant Channel) and E-RGCH(Relative Grant Channel) inDL to indicate to the HSUPA UE (individually or per group) what are their

allocated UL resources. This indication can be done using an explicit value

(through E-AGCH) or relatively to the last allocated UL resources (with E-

RGCH)

E-DP

CCH

E-DPDCH

E-HICH

E-HICH

E-AGCH

E-AGCH

E-RGCH

E-RGCH

Figure 17: HSUPA channels and associated R99 channels

A specific E-DCHtransport channel is defined. As the classical DCH transport channel

it allows to offer transport services to higher layers. The E-DCH transport channel is

characterized by:

Only for UL Two possible TTI: 10ms and 2ms


Page 27/37


56/506




Page 28/37

Transport block size and Transport Block set size are free attributes of thetransport format.

Possibility of HARQ process with retransmission procedures applied atNodeB. The maximum allowed number of retransmissions is defined via

edchHarqMaxRetransEdchTti10 (for 10ms E-DCH TTI) and

edchHarqMaxRetransEdchTti2(for 2ms E-DCH TTI) parameters.

Support of E-DCH HARQ retransmissions of type Incremental Redundancy.Remark: In UA6, only Incremental Redundancy type of E-DCH HARQ is

supported. harqType parameter under EdchConf is ignored by the system,

(as in UA5), and there is no related parameter at RNC level (UA5

harqRvConfiguration parameter under EdchUserService has been

removed).

Turbo coding with rate 1/3 is used

CRCis 24 bits length

E-TFCI (Transport Format Combination Indication) indicates which format iscurrently used for the UL transmission

Sequence number, redundancy version, E-TFCI must be placed onto E-DPCCH

channel. On the other hand the traffic transported by E-DCH TrCh must be placed on

the E-DPDCH part.

edchHarqMaxRetransEdchTti10: Defines the maximum number of retransmission at

E-DCH HARQ level when the UL RB is mapped on E-DCH with an E-DCH TTI of

10ms.

Parameter edchHarqMaxRetransEdchTti10 Object EdchParameters

Range & Unit Integer [0 ..15], N/A

User Customer

Class 3

Granularity RNC,UlRbSetConf

Value [iCEM] [xCEM]4[UCU-III] 3

edchHarqMaxRetransEdchTti2: Defines the maximum number of retransmission atE-DCH HARQ level when the UL RB is mapped on E-DCH with an E-DCH TTI of 2ms.

Parameter edchHarqMaxRetransEdchTti2 Object EdchParametersRange & Unit Integer [0 ..7], N/A

User Customer

Class 3

Granularity RNC,UlRbSetConf

Value [xCEM] 7[UCU-III] 7

3.2.1.1 UPLINK CHANNELS

The E-DPDCH is used to carry the E-DCH transport channel. There may be zero, one,or several E-DPDCH on each radio link.


57/506



The E-DPCCH is a physical channel used to transmit control information associatedwith the E-DCH. There is at most one E-DPCCH on each radio link.

The E-DPDCH and E-DPCCH (sub) frame structure is presented on the figure below

(from [3GPPref]):

Data, Ndatabits

Slot #1 Slot #14Slot #2 Slot #iSlot #0

Tslot= 2560 chips, Ndata= 10*2kbits (k=07)

Tslot= 2560 chips

1 subframe = 2 ms

1 radio frame, Tf= 10 ms

E-DPDCHE-DPDCH

E-DPCCH 10 bits

Figure 18: E-DPCCH / E-DPDCH frame structure

On uplink, each radio frame is divided in 5 sub frames, each of length 2 ms. DifferentE-DPDCH and E-DPCCH slot formats have been defined as shown on the two tablesbelow:

Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Subframe Bits/SlotNdata

0 15 256 150 30 10

1 30 128 300 60 20

2 60 64 600 120 40

3 120 32 1200 240 80

4 240 16 2400 480 160

5 480 8 4800 960 320

6 960 4 9600 1920 6407 1920 2 19200 3840 1280

Table 11: E-DPDCH slot formats

Slot Format #i Channel Bit Rate (kbps) SF Bits / Frame Bits / Sub frame Bits /SlotNdata

0 15 256 150 30 10

Table 12: E-DPCCH slot formats

E-DCH multicode transmission is possible only for SF = 4 and SF = 2.


Page 29/37


58/506



The possible codes are SF 256 for E-DPCCH and SF2 to SF256 for E-DPDCH. These

two new channels produced a composite complex signal as described in the figure

below [3GPP ref]:

I+jQ

Se-dpch

ced,1 ed,1

E-DPDCH1

iqed,1

ced,k ed,k

E-DPDCHk

iqed,k

ced,K ed,K

E-DPDCHN

iqed,K

cec ec

E-DPCCH

iqec

.

.

.

.

.

.

.

.

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

Sdpch,n

I+jQ

Sdpch

Shs-dpcch

S

Se-dpchSpreading

Spreading

Spreading

DPCCHDPDCHs

HS-DPCCH

E-DPDCHsE-DPCCH

Figure 20: Uplink physical channels mul tiplexing

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 o

HPUG UA7 Preliminary External V04.05 Jun10

Documents

Transcript of HPUG UA7 Preliminary External V04.05 Jun10