HSxPA Algorithms Description

TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description - Page 1All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

9300 WCDMATMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description

STUDENT GUIDE

TMO18256 Issue D0 SG DEN I1.0

All rights reserved Alcatel-Lucent 2010 Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent



TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description9300 WCDMA

2

Empty page

Switch to notes view!

This page is left blank intentionally




3

Terms of Use and Legal Notices

Switch to notes view!1. Safety WarningBoth lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to

wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the

equipment alone.

The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

2. Trade Marks

Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.

All other trademarks, service marks and logos (Marks) are the property of their respective holders, including Alcatel-

Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning

the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.

Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to

change without notice.

3. Copyright

This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No

other use or transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and

must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may

be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from

Alcatel-Lucent.

Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly

prohibited.

User obtains no rights in the information or in any product, process, technology or trademark which it includes or

describes, and is expressly prohibited from modifying the information or creating derivative works without the express

written consent of Alcatel-Lucent.

All rights reserved Alcatel-Lucent 2010

4. Disclaimer

In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including

lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-

Lucent has been advised of the possibility of such damages.

Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an

endorsement, nor a recommendation.

This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The

information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some

cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely

accurate.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment

and its operation, or contact your nearest Alcatel-Lucent representative for more information.

The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-

Lucent disclaims any warranties in connection with the products as used and described in the courses or the related

documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,

including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of

dealing, usage or trade practice.

Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed

internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in

nature

5. Governing Law

The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are

governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal

Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,

but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a

valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these

Terms of Use and Legal Notices shall remain in full force and effect.




4

Blank Page






5

Course Outline

About This CourseCourse outline

Technical support

Course objectives

1. Topic/Section is Positioned HereXxx

Xxx

Xxx

2. Topic/Section is Positioned Here






Section 1. HSDPA

Module 1. HSDPA TMO18256

Section 2. HSUPA

Module 1. HSUPA TMO18256

Section 3. Appendix

Module 1. Appendix TMO18256

Section 4. Glossary

Module 1. Glossary TMO18256

Section 5. iMCRA

Module 1. iMCRA TMO18256




6

Course Outline [cont.]






7

Course Objectives


Welcome to TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description

Upon completion of this course, you should be able to:

The objectives is to supply explanations about the Algorithms for

- HSDPA

- HSUPA




8

Course Objectives [cont.]






9

About this Student Guide

Switch to notes view!Conventions used in this guide

Where you can get further information

If you want further information you can refer to the following:

Technical Practices for the specific product

Technical support page on the Alcatel website: http://www.alcatel-lucent.com

Note

Provides you with additional information about the topic being discussed.

Although this information is not required knowledge, you might find it useful

or interesting.

Technical Reference (1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical

Practices where you can find more information on the topic being discussed.

WarningAlerts you to instances where non-compliance could result in equipment

damage or personal injury.




10

About this Student Guide [cont.]






11

Self-assessment of Objectives

At the end of each section you will be asked to fill this questionnaire

Please, return this sheet to the trainer at the end of the training


Instructional objectives Yes (or globally yes)

No (or globally no)

Comments

1 To be able to XXX

2

Contract number :

Course title :

Client (Company, Center) :

Language : Dates from : to :

Number of trainees : Location :

Surname, First name :

Did you meet the following objectives ?

Tick the corresponding box

Please, return this sheet to the trainer at the end of the training




12

Self-assessment of Objectives [cont.]


Instructional objectives Yes (or Globally yes)

No (or globally no)

Comments

Thank you for your answers to this questionnaire

Other comments

Section 1 Module 1 Page 1


3JK11636AAAAWBZZA Issue 1.1

Do not delete this graphic elements in here:

11All Rights Reserved Alcatel-Lucent 2010

Module 1TMO18256 D0 SG DEN I1.0

Section 1HSDPA Algorithms Description

9300 W-CDMAUA06 HSxPA Algorithms Description

TMO18256 D0 SG DEN I1.0





9300 W-CDMA UA07 HSxPA Algorithms DescriptionHSDPA Algorithms Description Module 1

1 1 2

Blank Page


First editionElsner, BernhardCharneau, Jean-Nol

2010-04-3001

RemarksAuthorDateEdition

Document History






1 1 3

Module Objectives

Upon completion of this module, you should be able to:

Describe HSDPA activation principles and associated parameters

Describe HSDPA radio resource management parameters

Describe HSDPA mobility features and associated parameters






1 1 4

Module Objectives [cont.]







1 1 5

Table of Contents

Switch to notes view!Page

1 HSDPA Activation 71.1 HSDPA Distributed Architecture 81.2 HSDPA Activation Flags 91.3 64 QAM On HSDPA Activation Flags 101.4 HSDPA Capable-UE Supported 111.5 H-BBU Resource Allocation 121.5.1 M-BBU Resource Allocation xCEM case 131.5.2 Multiple xCEM per carrier 141.5.3 Parameters involved in CEM configuration 15

1.6 HSDPA/E-DCH Service Indicator broadcast 161.7 Transport Channel 171.8 Physical Channels 181.9 DL OVSF Code Tree 191.10 HSDPA Key Features 201.11 AMC Principles 211.12 UE Capabilities and Max Bit Rates 221.13 HARQ Types 231.14 Modulation Schemes 241.15 Constellation Rearrangement (16QAM) 251.16 64 QAM On HSDPA 261.17 Redundancy Version Parameters 271.18 Flexible RLC and MAC-ehs 281.19 HARQ Stop and Wait Principles 301.20 HARQ Mechanisms 311.21 Optimal Redundancy Version for HARQ retransmission 321.22 Channel Coding : Recall 331.23 Selection of the Redundancy Version per HARQ process 341.24 Multi-RAB handling on HSDPA 351.25 Multi-RAB and GBR handling on HSDPA 361.26 User Services supported with HSDPA 37

2 HSDPA RRM 382.1 RAB Matching and CAC 392.2 HSDPA to DCH Fallback 402.3 Fair Sharing 412.3.1 Call Admission Control & Power Reservation 422.3.2 Call Admission Control & Codes Reservation 432.3.3 Fair Sharing - RAN Model 44

2.4 Initial Rate Capping during RB reconfiguration 452.4.1 Initial Rate Capping during RB reconfig: RAN Model 46

2.5 QoS Mapping 472.6 Scheduling Priority Indicator (SPI) 482.7 UE, QId and SPI 492.8 NodeB Scheduler 502.9 Dynamic Code Tree Management 512.9.1 HS-PDSCH OVSF Codes Allocation 522.9.2 HS-PDSCH Codes Preemption / Reallocation 532.9.3 DCTM RNC RAN Model 542.9.4 DCTM NodeB RAN Model 55

2.10 HSDPA DL Power Reservation at RNC 562.11 Dynamic PA Power Sharing R99/HSPA Carriers 572.11.1 Impact on DCH DL CAC and DL iRM 58

2.12 HSDPA DL Power Available at NodeB 592.13 HSDPA Power - RAN Model 602.14 HSDPA Power Distribution 612.15 HSDPA Full Power Usage 62






1 1 6

Table of Contents [cont.]

Switch to notes view!Page

2.16 HS-SCCH Power Control 632.17 HS-PDSCH Dynamic Power Allocation for 1st Transmission 642.18 UE Capabilities and Max Bit Rates 652.19 HSDPA Flexible Modulation 662.20 CQI Modification Principles 672.21 HS-DPCCH detection based on CQI 682.22 CQI adjustment based on BLER: blerRangeBasedAlgo 692.23 CQI adjustment based on BLER: OuterLoopLikeAlgorithm 702.24 CQI adjustment based on BLER: Dynamic BLER Adjustment 712.24.1 CQI adjustment based on BLER: Dynamic BLER Adjustment 72

2.25 HS-PDSCH Power Adaptation for Retransmissions 742.26 HS-DPCCH Power 752.27 Scheduler iCEM 762.27.1 Schedulers using Cost Function C1 only 772.27.2 Schedulers using Cost Functions C1 and C2: C1 782.27.3 Schedulers using Cost Functions C1 and C2: C2 792.27.4 C2 Parameters 80

2.28 Scheduler xCEM 852.28.1 SNR ESTIMATION FOR HS-PDSCH 862.28.2 TFRC SELECTION 872.28.3 TFRC SELECTION Summary 882.28.4 SPI management for GBR Mac-d flows 892.28.5 SPI management for non GBR Mac-d flows 902.28.6 SPI management 91

2.29 Scheduler: SPI management 922.30 Dynamic MAC-d PDU size 932.30.1 MAC-d PDU size 942.30.2 MAC PDU size Configuration 952.30.3 How to configure a Mac-d PDU size of 656 bits 962.30.4 MAC-d PDU size Selection 972.30.5 MAC-PDU size : Mobility HSDPA-HSDPA 982.30.6 MAC-PDU size : Mobility HSDPA - R99 1012.30.7 MAC-PDU size : Mobility Over Iur 1022.30.8 Mac-d PDU size reconfiguration 104

2.31 Transport Block Size Optimization: CQI 1 to 15, all UE cat. 1052.32 High Quality UL R99 RAB for High HSDPA DL Rate - Issue 1062.32.1 UA05.1 Solution 1072.32.2 UA06 Solution 108

2.33 Always On for HSDPA/DCH: Mono-Service PS / Mono-RAB 1092.34 Always On for HSDPA/DCH: Multi-Service PS / Multi-RAB PS 110

3 HSDPA Mobility 1113.1 3G->2G HHO 1123.2 3G->3G Intra-RNC Inter-freq HHO 1133.3 3G->3G Inter-RNC Inter-freq HHO 1143.4 HSDPA over Iur 1153.4.1 64-QAM over Iur: Not Supported 1163.4.2 Iub Bandwidth Management 117






1 1 7

1 HSDPA Activation






1 1 8

1 HSDPA Activation

1.1 HSDPA Distributed Architecture

Uu Iub

MAC-d

RLC

HS-DSCH FP

MAC-ehsHS-DSCH

FP

RLC

L2 L2

Flow control

PHY PHY L1 L1

RNCNodeBUE

HS-SCCHDownlink Transfer Information(UEid, OVSF,...)

HS-PDSCHData Transfer (PS I/B)

HS-DPCCH Feedback Information

(CQI, ACK/NACK)

DPCHUpper Layer Signaling

RNC

Introduction of MAC-ehs

Iub

MAC-d

MAC-ehs

New MAC-ehs LayerReplaces MAC-hs

Transport channelHS-DSCH

Frame ProtocolsHS-DSCH

new

HSDPA is an increment on UTRAN procedures, and is fully compatible with R4 layer 1 and layer 2. It is based on the introduction of a new MAC entity (MAC-hs) in the Node B, that is in charge of scheduling / repeating the data on a new physical channel (HS-DSCH) shared between all users. MAC-hs has been replaced by MAC-ehs in UA07!

This has a minor impact on network architecture. There is no impact on RLC protocol and HSDPA is compatible with all transport options (AAL2 and IP).

On the Node B side, MAC-ehs layer provides the following functionalities:

Fast repetition layer handled by HARQ processes

Adaptive Modulation and Coding

New transport channel High Speed Downlink Shared Channel (HS-DSCH)

Flow control procedure to manage Node B buffering

Some new L1 new functionalities are introduced compared to R4:

3 new physical channels: HS-PDSCH to send DL data, HS-SCCH to send DL control information relative to HS-PDSCH, and HS-DPCCH to receive UL control information

New channel coding chain for HS-DSCH transport channel and HS-SCCH physical channel

In UA07 the following new 3GPP R7 features have been introduced:

Flexible RLC: instead of using fixed RLC PDU sizes (320 bits or 640 bits), the size of a RLC PDU can vary. The maximum size is determined by the RNC based on the data rate offered over the radio. The size can vary during the transfer.

MAC-ehs: enhanced MAC-hs layer that brings several enhancements and simplifications:

It allows coping with MAC-d PDU of different sizes

It brings the capability to segment MAC-d PDUs

64-QAM requires Mac-ehs






1 1 9

1 HSDPA Activation

1.2 HSDPA Activation Flags

BTSEquipment

BTSCell

hsdpaResourceActivation

FddCell

NodeB RadioAccessService

isHsdpaAllowedhsdpaActivation

RNC

isHsdpaAllowed

UmtsNeighboring

RemoteFDDCell

HSDPA activation main switch is located at RNC level, under the Radio Access Service subtree. If the value

of isHsdpaAllowed is set to TRUE, then all the new MOIs required for HSDPA operation should be defined in

the RNC configuration.

Activation consists in:

at BTS level, set hsdpaResourceActivation to TRUE.

at RNC level, set isHsdpaAllowed to TRUE

and at Cell level hsdpaActivation to TRUE.

Note that HSDPA needs to be activated at BTS level first, and that prior to the activation on a BTS, a new

VCC shall be created on the corresponding Iub link to carry HSDPA traffic.

Deactivation can be performed at two levels:

deactivation at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA

dedicated resources preserved,

deactivation at cell level: setting hsdpaActivation and hsdpaResourceActivation to FALSE completely

deactivates HSDPA.

Note that isHsdpaAllowed exists also in two other objects (RNC/NeighboringRNC and RNC/NodeB/FDDCell/UMTSFddNeighboringCell) in order to know if the HSDPA call has to be reconfigured or

not in DCH when the primary cell changes in case of mobility over Iur.






1 1 10

1 HSDPA Activation

1.3 64 QAM On HSDPA Activation Flags

64-QAM Eligible

NodeB 64QAM capable?

QPSK / 16-QAM

YES

YES

YES

NO

NO

NO

Node BNode B

YES

NO

=UE 64QAM capable?

NodeB 64 QAM Activated?

UE CAT 64-QAM Eligible?

isDl64QamAllowed (FDDCell)

isDl64QamOnRncAllowed (RadioAccessServicel)

is64QamAllowedForUeCategory (HsdpaRncConf)

new

The 64QAM modulation is configured if the following conditions are fulfilled:

1 The NodeB is 64QAM capable: The NodeB indicates to the RNC its 64QAM capability through the SixtyfourQAMDLCapability IE in the NBAP Audit Response or Resource Status Indication messages

2 The UE is 64QAM capable: The UE informs the RNC of its capabilities in the RRC Connection Setup Complete message:-MAC-ehs support IE concerning the support of the MAC-ehs/RLC flexible size

feature (3GPP R7).-HS-DSCH physical layer category extension IE corresponding to the HS-DSCH

category supported by the UE when Mac-ehs is configured (If the Mac-ehs is not configured, the SRNC

doesnt use this IE but the HS-DSCH physical layer category IE, corresponding to the HS-DSCH category

supported by the UE when MAC-ehs is not configured)

3 The NodeB is allowed to used the 64QAM: RadioAccessService.isDl64QamOnRncAllowed = True and FDDCell.isDl64QamAllowed = True Mac-ehs enabled

4 The UE category is allowed to used the 64QAM: HsdpaRncConf. is64QamAllowedForUeCategory = 1 for all the UE categories supporting 64QAM, that is to say 13,14,17,18 If all these conditions are fulfilled,

then the NodeB will send the new HS-SCCH to inform the UE of the modulation used (QPSK, 16QAM or

64QAM) depending on the TFRC selection algorithm.






1 1 11

1 HSDPA Activation

1.4 HSDPA Capable-UE Supported

1.8 MbpsQPSK only15Category 12


14.4 MbpsQPSK & 16-QAM115Category 10










Max Peak RateModulationInter-TTI Min IntervalHS-PDSCH Max NumberHS-DSCH Category













Max Peak RateModulationInter-TTI Min IntervalHS-PDSCH Max NumberHS-DSCH Category

QPSK mandatory for HSDPA capable UE

16/64QAM optional

slide + notes

updated

Twelve categories have been specified by Release 5 for HSDPA UEs according to the value of several

parameters among which are the following:

Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15)

Minimum inter-TTI interval, which defines the minimum time between the beginning of two

consecutive transmissions to this UE. If the inter-TTI interval is one, this means that the UE can

receive HS-DSCH packets during consecutive TTIs, i.e. every 2 ms. If the inter-TTI interval is two,

the scheduler needs to skip one TTI between consecutive transmissions to this UE.

Supported modulations (QPSK only or both QPSK and 16QAM/64QAM)

Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-

DSCH / Inter-TTI interval).

These twelve categories provide a much more coherent set of capabilities as compared to R99 which gives

UE manufacturers freedom to use completely typical combinations.

New UE categories have been introduced to support the 64QAM and MAC-ehs:

- 13 and 14 (64-QAM only),

- 17 and 18 (64-QAM or MIMO).

Note that MIMO is not supported in UA07.

The UE category 64QAM capable deployed in Live is Cat.14.






1 1 12

1 HSDPA Activation

1.5 H-BBU Resource Allocation

BTS

iCCM iTRM

iTRM

iTRM

MCPA DDM

Radio Shelf

MCPA DDM

MCPA DDM

Digital Shelf

iCEM128H-BBU

H-BBU

iCEM128

iCEM64

iCEM128

H-BBU

D-BBU

D-BBU

CEMaD-BBU

D-BBU

H-BBU

D-BBU

HsdpaConf

BTSEquipment

BTSCell

HsdpaResourceId

ULHS-DPCCHDLHS-DPDCH(s)HS-SCCH(s)

MAC-hs HARQ Scheduler Link Adaptation (AMC)

iCEM case

The HSDPA support on UMTS BTS requires Alcatel-Lucent second generation of CEM i.e. iCEM64 or iCEM128

or third generation xCEM.

Base Band processing is performed by BBUs of iCEM. One restriction of current BBUs is that one BBU cannot

process both Dedicated and HSDPA services. In order for the BTS to be able to manage both dedicated and

HSDPA services, the BTS has to specialize BBUs as:

D-BBU: BBU managing dedicated services,

H-BBU: BBU managing HSDPA services.

The partition between H-BBU and D-BBU is done by the BTS at BTS startup reading the value of the

hsdpaResourceId parameter for a BTS Cell when the btsCell parameter hsdpaResourceActivation is set to TRUE. When used, this parameter associates a logical HSDPA resource identifier for this cell.

An H-BBU can work either in mono-cell mode (the H-BBU is managing one cell only) or in shared mode

(the H-BBU is managing two or three cells of the same LCG, a LCG (Local Cell Group) is a group of 3 cells

handling the same frequency). The H-BBU operating mode is chosen at provisioning time.

When the H-BBU is working in shared mode, each cell will be granted with a fraction of the overall H-BBU

capacity.

From UA05.0, HSDPA is supported on 2 different carriers but note that one H-BBU is capable to support only

one carrier.

HSDPA is supported by Alcatel-Lucent BTS within the following system limits:

For HSDPA managed by iCEM/iCEM2 :

A given HSDPA Cell is managed by one single H-BBU and cannot be split between several H-BBU.

From one to three cells per H-BBU. All the cells must belong to same LocalCellGroup.






1 1 13


1.5.1 M-BBU Resource Allocation xCEM case

BBUDCH

BBUDCH

BBUDCH

BBUDCH

BBUHSDPA

BBUHSDPA

BBUHSDPA

BBUHSDPA

xCEMBBUHSDPA

BBUHSDPA

BBUHSUPA

BBUHSUPA

BBUDCH

BBUDCH

BBUDCH

BBUDCH

xCEM

BBUMultimode

BBUMultimode

BBUMultimode

BBUMultimode

BBUMultimode

BBUMultimode

BBUMultimode

BBUMultimode

xCEM

DPCCH, DPDCH (DCH + SRB + CCH) all HSDPA channels all HSUPA channels

-Up to 256 CE where 128 of them can be used to support HSDPA and/or HSUPA calls-Up to 6 cells belonging to 2 LCGs

UA05

UA06

notes

updated

BTSEquipment

HsXpaResource

UA06 Restrictions:

M-BBU functionality is activated by default in UA06.0 (no means to deactivate it).

HSDPA is supported by Alcatel-Lucent BTS within the following system limits:

For HSDPA managed by xCEM :

All cells of a given LocalCellGroup are managed by M-BBUs on a same xCEM (cannot be split between several xCEM). All HSDPA resources of the xCEM are seen as a single pool of capacity

Maximum 2 LocalCellGroup (up to 6 HSDPA Cells) per xCEM board.






1 1 14


1.5.2 Multiple xCEM per carrier

Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 Cell 6




xCEM 1

xCEM 1 xCEM 2

xCEM 1 xCEM 2 xCEM 3

xCEM 1 xCEM 2 xCEM 3 xCEM 4

UA05.1& UA06

UA07.1.2

1xCEM: 256 CE& 4.7/1.7Mbps DL/UL/Cell

2xCEM: 512 CE& 9.3/3.4Mbps DL/UL/Cell

3xCEM: 768CE& 14/5Mbps DL/UL/Cell

4xCEM: Cell 1,2,3 for

HSPA+ Max HSDPA Rel 7 capabilities guaranteedOn one carrier

new

The xCEM board has been introduced with the configuration rule that HSPA baseband resources for one

carrier cannot be shared across xCEM. R99 traffic is however allocated in load balancing. This feature

introduces new HSPA high capacity Node B baseband configurations including up to 3 xCEM per carrier.

HSxPA baseband resources for each a cell (HSDPA/HSUPA schedulers, encoding and decoding MAC and radio

resources) are still processed on the same board. However the HSPA resources of the cells belonging to

the same carrier can be distributed on different boards.

R99 traffic can still be allocated in a load balancing fashion as in previous release independently of the

HSPA resource location.

The operator has the possibility to configure HSPA resource (group of several HSPA cells) and the mapping

to the configured xCEM. Each group can be configured with a weight influencing the HSPA resource re-

configuration in case of missing board. The resource assignment algorithm can then take the expected

traffic load of a given cell (configured weight) into account and avoid as much as possible the

combination of 2 cells with heavy load on the same board.

In case of multiple xCEM per carrier, iCEM mixture is not supported. Moreover, in case of iCCM, a maximum

of 3 xCEM per Node B can be supported.

The feature allows to guaranty that sufficient baseband processing capacity can be used to target very high

HSDPA data rate (e.g. with 64QAM) in highly loaded sites with high probability of concurrent traffic in all

sectors. It also allows higher HSDPA capacity for sites with more than 3 sectors.

.






1 1 15


1.5.3 Parameters involved in CEM configuration

BTSCell

R99Resource LocalCellGroup

BTSEquipment

RfCarrier

minimumR99ResourceRequired

hspaHardwareAllocation

HsdpaConf

EdchConf

hsdpaResourceIdhsxpaResourceId

EdchResourceId

HSPA allocation in iCEM or xCEM

Common iCEM/xCEM parameters

xCEM specific parameters

iCEM specific parameters

localCellGroupIdhsdpaResourceActivationedchResourceActivationLocalCellGroupId

r99ResourceIdpriority

rfCarrierId

HsXpaResource

slide

updated

Parameter hspaHardwareAllocation (under BTSEquipment/RfCarrier) coherent with the type of CEM boards in the NodeB (iCEM /xCEM).

Number of H-BBU to be allocated on iCEM = Number of different hsdpaResourceId among BTS Cells with their hsdpaResourceActivation set to TRUE and within BTS HSDPA System limits.

Number of M-BBU to be allocated on xCEM for HSxPA = Number of different hsxpaResourceId among BTS cells with their hsdpaResourceActivation set to TRUE. multiplied by 4.

Number of D-BBU (on iCEM) and M-BBU for DCH traffic (on xCEM) in accordance to parameter

minimumR99ResourceRequired.

r99ResourceId: this parameter is used to pool the LCG. The LCG that have the same r99ResourceId are pooled together and are managed by the same CEM boards (maximum 2 LCG per pool and maximum 2 pools

per NodeB).

By default, it is recommended to keep the default values of this parameter: the pooling of LCG is

automatically performed if needed. The following cases may require a dedicated engineering:

UTRAN Sharing: this parameter can be used to discriminate the resources allocated to each

PLMN.

3 carriers on local cells (STSR2+1 or STSR3): 2 LCG must be pooled together; the 3rd LCG is

supported on separate CEM boards. There is no constraint to choice the 2 LCG that are pooled.

In 6 sectors with 2 carriers, the LCG can be pooled per carrier or per cluster.






1 1 16

1 HSDPA Activation

1.6 HSDPA/E-DCH Service Indicator broadcast

HSDPA OK!

HSDPA NOK!

HSDPA cellnon HSDPA

cell

RNC

SIB5SIB5

NodeB

HSDPA UE

NodeB

HSDPA UE

isHsxpaServiceIndicatorEnabled

(RadioAccessService)

hsdpaServiceIndicatorMethodedchServiceIndicatorMethod

(FDDCell)

Auto Auto

notes

updated

This feature allows the mobile to display an indication when it is under HSxPA coverage.

UTRAN broadcasts an HSDPA cell indicator information element in SIB 5 for cells that are HSDPA

capable.

UTRAN also broadcasts an E-DCH cell indicator information element in SIB 5 for cells that are E-DCH

capable.

Thanks to this feature, the end-user can be made aware that he is within HSxPA coverage, and can then

decide whether or not to use services that require high bandwidth.

Once the feature is activated at RNC level, three operating modes are possible for each cell indicator

(HSDPA and HSUPA), all combinations between HSDPA and HSUPA being allowed:

Off: the hsdpaServiceIndicator (or respectively the edchServiceIndicator ) information is not

broadcasted in SYSINFO message

On: the hsdpaServiceIndicator (or respectively the edchServiceIndicator) information is always

broadcasted on SYSINFO, with value HSDPA_CAPABLE (or respectively EDCH_CAPABLE). This

information is broadcasted to the UE even if the corresponding service (HSDPA (or respectively E-

DCH)) is not operational on the corresponding cell.

Auto: the hsdpaServiceIndicator (or respectively the edchServiceIndicator) information is

broadcasted to the UE indicating the current state of the corresponding service: HSDPA_CAPABLE if

service is operational, HSDPA_NOT_CAPABLE otherwise (or respectively EDCH_CAPABLE if service is

operational, EDCH_NOT_CAPABLE otherwise)






1 1 17

1 HSDPA Activation

1.7 Transport Channel

HSDPA Downlink transport channel: HSHS--DSCHDSCH

HS-DSCH

DTCH

DL

Traffic

TRBMobile i

HS-PDSCH

HS-DPCCH

HS-SCCH

Downlink

TTI: 2ms

TBS free attribute of Transport format

AMC = f(CQI)

HARQ

Turbo coding 1/3

CRC 24bits

BTSCell

HsdpaConf

harqTypeharqTypeXcem

From a Radio Bearer perspective, a HSDPA data session implies:

A HS-DSCH transport channel supported by a variable number of HS-PDSCH SF16 physical channels. The

HS-DSCH transport channel is used to transport the downlink data packets between UTRAN and UE, i.e.

packets associated to the DTCH logical channel

An associated DCH. This dedicated transport channel is used to transport the signaling messages,

including the signaling exchanged at the RRC level and the signaling exchanged between the UE and the

Core Network (e.g. all SM and GMM layer messages). The associated DCH also transports the packet data

in the uplink direction.

The HS-DSCH transport channel is defined as follows:

Short fixed TTI value of 2 ms,

One Transport Block (data block) per TTI,

Fixed length CRC (24 bits) per data block,

Type of channel coding: turbo code rate 1/3

Effective code rate achieved with rate matching

Dynamic redundancy version.

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

experienced by the UE and his category.

AMC (number of codes, code rate and modulation type) is chosen among 30 possibilities, each one

corresponding to one CQI, in order to reach the maximum bit rate while guarantying a certain QoS

(10% BLER for example)






1 1 18

1 HSDPA Activation

1.8 Physical Channels

DTCH

DL

Traffic

TRB

RadioAccessService

numberOfHsPdschCodes

numberOfHsScchCodes

HsdpaCellClass

HS-PDSCH

HS-DPCCH

HS-SCCH

HS-DSCH

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. A HS-PDSCH corresponds to one channelization code of fixed

spreading factor SF=16 from the set of channelization codes reserved for HS-DSCH transmission.

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. The HS-SCCH is a fixed rate (60 kbps, SF=128) downlink physical channel used to carry downlink

signaling related to HS-DSCH transmission.

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.






1 1 19

1 HSDPA Activation

1.9 DL OVSF Code Tree

SF256

SF128

SF64

SF32

SF16

SF8

SF4

0

10

02

31

4

52

16

73

8

94

210

115

12

136

314

157

0

2

3

1

S-CCPCH/0

S-CCPCH/2

4

5

6

7

HS-SCCH

Common channels (including S-CCPCH/1)

HS-PDSCH

STATIC

Allocation

Free OVSF codes

STATIC or DYNAMIC Allocation

DYNAMIC

Allocation

numberOfHsScchCodes

numberOfHsPdschCodes

OVSF codes reservation for the HS-PDSCH channels can be managed statically or dynamically according to

the activation of the feature DCTM (Dynamic Code Tree Management) or of the feature Fair Sharing or

none of them.

When DCTM and Fair Sharing are both disabled:

Reservation of the HS-PDSCH codes is static and the number of HSPDSCH codes is defined by the

parameter numberOfHsPdschCodes.

HSDPA codes configuration is sent during the cell setup from RNC to NodeB through the Physical Shared

Channel Reconfiguration message and these codes can not be used or pre-empted for other services.

This message contains the number of HS-PDSCH and the index of the first one knowing that HS-PDSCH

codes are reserved at the bottom of the OVSF tree.

When DCTM is enabled (Fair Sharing must be disabled):

Reservation of HS-PDSCH codes is dynamic and depends on the R99 traffic.

Codes not used by R99 can be used for HS-PDSCH channels.

Nevertheless, some codes needed to be kept free in order to anticipate the admission of a R99 call.

New HS-PDSCH configuration is sent from RNC to NodeB through a PSCR message each time a HS-PDSCH

pre-emption or reallocation is triggered according to R99 traffic variation.

When Fair Sharing is enabled (DCTM must be disabled):

OVSF codes are managed by NodeB (no more by RNC) that is to say that the NodeB knows in real time

which codes are used or not by R99 and is then able to compute which codes are available for HS-PDSCH.

When the number of HS-PDSCH codes changes, the NodeB then reconfigures the H-BBU or M-BBU in order

to take into account the new number of HS-PDSCH codes.

As the NodeB knows TTI per TTI the occupancy of the codes tree, there is no need the keep some codes

free to anticipate the admission of a R99 call.






1 1 20

1 HSDPA Activation

1.10 HSDPA Key Features

SchedulerFills the TTIs with one or more users based on their priority and

feedback information

HARQ ProcessesRetransmissions handling, TFRC selection, AMC

Queue IDs

Radio TransmissionFeedback Reception

Capacity Request

Control FP

Capacity Allocation

Control FP Data FP

Flow ControlDynamically fills the Queues of each UE

RNC

slide

updated

The main architectural shift with respect to R4 is the introduction of an ARQ scheme for error recovery at

the physical layer (which exists independently of the ARQ scheme at the RLC layer). This fast

retransmission scheme is of paramount importance for TCP as generally TCP has not performed well in a

wireless environment.

This architectural evolution gives a new importance to the role of the Node B in the UTRAN. It then

necessarily goes together with the introduction of some new functions managed by the Node B, including

the following:

Flow Control: new control frames are exchanged in the user plane between Node B and RNC to

manage the data frames sent by the RNC.

Scheduler: determines for each TTI which users will be served and how many data bits they will

receive.

Hybrid Automatic Repeat Query: retransmissions management.

Adaptive Modulation and Coding: new channel coding stages and radio modulations schemes are

introduced to provide data throughput flexibility.

Feedback demodulation and decoding in UL.






1 1 21

1 HSDPA Activation

1.11 AMC Principles

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 IllustrationUE Category Reported CQI

CodingRate

ModulationScheme

Number ofOVSF Codes

AMC

AMC

2ms

Maximum Throughput

Adaptive Modulation and Coding (AMC) is a fundamental feature of HSDPA. It consists in continuously

optimizing the user data throughput based on the channel quality reported by the UE (CQI feedback). This

optimization is performed using adaptive modification of the coding rate, the modulation scheme, the

number of OVSF codes employed and the transmit power per code.

Different combinations of modulation and channel coding rate (based on the Transport Format and

Resource Combinations or TFRC) can be used to provide different peak data rates. Essentially, when

targeting a given level of reliability, users experiencing more favorable channel conditions (e.g. closer to

the NodeB) will be allocated higher data rates.

The above figure shows an illustration of the user throughput evolution for one single OVSF code in function

of the channel quality as a result of AMC.






1 1 22

1 HSDPA Activation

1.12 UE Capabilities and Max Bit Rates

-10 -8 -6 -4 -2 0 2 4 6 8 1010

15

20

25

C/I (dB)s

oftC

QI

S oft CQI vs C/I - P edes trian_a 1 RX

Category 6 UE CQI Mapping Table

16-QAM3024 kbps530

16-QAM3024 kbps529

............

16-QAM1440 kbps516

QPSK1296 kbps515

QPSK1008 kbps414

QPSK864 kbps413

QPSK720 kbps312

QPSK576 kbps311

QPSK432 kbps310

QPSK288 kbps29

QPSK288 kbps28

QPSK144 kbps27

QPSK144 kbps16

QPSK144 kbps15

QPSK0 kbps14

QPSK0 kbps13

QPSK0 kbps12

QPSK0 kbps11

out of range0

ModulationRLC ThroughputHS-PDSCH NumberCQI Value

Target BLER 10%

notes

updated

The maximum achievable data rate depends on the UE category but also on the instantaneous radio

conditions it is exposed to. Each UE category has therefore a reference table specifying the supported

combinations between the reported CQI values, the number of codes and the radio modulation (QPSK or

16/64QAM).

Instantaneous radio channel conditions are known at the UTRAN level thanks to the periodical decoding of

the Channel Quality Indicator sent by the UE to the NodeB onto the HS-DPCCH. The UE first estimates the

Carrier over Interference ratio (C/I). From this estimate the UE then determines a CQI (with a maximum HS-

DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The NodeB takes this input

into consideration in order to adapt the throughput to the UE.

Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.






1 1 23

1 HSDPA Activation

1.13 HARQ Types

Chase CombiningChase Combining

NACK NACK NACK NACK ACK

DATA DATA DATA DATA DATA

NACK NACK NACK NACK ACK

DATA DATA1 DATA2 DATA3 DATA4

Incremental Redundancy CombiningIncremental Redundancy Combining

BTSCell

BTSEquipment

HsdpaConf

harqType{mirType, pirType, ccType, drType, WithPowerAdaptation}

harqTypeXcem{ccType, irType}

With HARQ the UE does not discard the energy from failed transmissions. The UE stores and later combines

it with the retransmissions in order to increase the probability of successful decoding. This is a form of soft

combining.

HSDPA supports both Chase Combining (CC) and Incremental Redundancy (IR).

Chase Combining is the basic combining scheme. It consists of the Node B simply retransmitting the exact

same set of coded symbols as were in the original packet.

With Incremental Redundancy, different redundancy information can be sent during re-transmissions, thus

incrementally increasing the coding gain. This can result in fewer retransmissions than for Chase Combining

and is particularly useful when the initial transmission uses high coding rates (for example, 3/4). However,

it results in higher memory requirements for the UE.

The Chase Combining option corresponds to the first redundancy version applied for all retransmissions.

Partial Incremental Redundancy indicates that for all redundancy versions the systematic bits must be

transmitted (only RV parameters with s = 1 are taken into account).

Full Incremental Redundancy corresponds to sequences where both systematic and non-systematic bits can

be punctured.






1 1 24

1 HSDPA Activation

1.14 Modulation Schemes

I

Q

0000

00011001

10001010

1011

1110

1111

01001100

1101

0010

0110

0111

0011

0101

11

10

01

00

Q

I

4 bits per symbol960kbps per OVSF

1920 bits per TTI

2 bits per symbol480kbps per OVSF960 bits per TTI

16QAM16QAM

QPSKQPSK

In order to achieve very high data rates, HSDPA adds a higher order modulation (16QAM) to the existing

QPSK modulation used for R4 channels.

As the 16QAM requires 2 times more bits to define one radio modulation symbol, the resulting number of

bits per TTI is multiplied by a factor 2, same thing for the total maximum throughput at the physical layer.

QPSK is mandatory for HSDPA capable UE, 16QAM is optional.






1 1 25

1 HSDPA Activation

1.14 Constellation Rearrangement (16QAM)

b=2

I

Q

0000

00011001

10001010

1011

1110

1111

01001100

1101

0010

0110

0111

0011

0101

I

Q

0011

00101010

10111001

1000

1101

1100

01111111

1110

0001

0101

0100

0000

0110

I

Q

0000

01000110

00101010

1110

1011

1111

00010011

0111

1000

1001

1101

1100

0101

I

Q

1100

10001010

11100110

0010

0111

0011

11011111

1011

0100

0101

0001

0000

1001

b=0

b=3

b=1

This function only applies to 16 QAM modulated bits. In case of QPSK it is transparent. The following table

describes the operations that produce the different constellation versions.

The input bit sequence is composed of a set of four consecutive bits nk, nk+1, nk+2, nk+3 (with k mod 4 = 0).

swapping MSBs with LSBs & LSBs values inversionnk+2, nk+3, nk, nk+13

inversion of the logical values of LSBsnk, nk+1, nk+2, nk+32

swapping MSBs with LSBsnk+2, nk+3, nk, nk+11

nonenk, nk+1, nk+2, nk+30

OperationOutput bit sequenceb






1 1 26

1 HSDPA Activation

1.16 64 QAM On HSDPA

64-QAM provides 6 bits per symbol compared to 4 bits for the 16QAM

Goal of 64QAM feature:

64QAM allows higher peak throughputs in very good radio conditions: At physical

layer: 21.6 Mbps with 64QAM instead of 14.4 Mbps with 16QAM

64QAM can also be used in code limited situations to increase the data rate for

users in good radio conditions.

new

This higher number of bits per symbol allows to increase the spectral efficiency of the transmitted signal (and then the throughput) but also makes it more vulnerable to interference. 64QAM is selected whenever allowed by radio conditions (i.e. high SNR)

Impact of 64QAM feature on the system:

1 New UE categories supporting the 64QAM are introduced.

2 New CQI mapping tables is introduced allowing higher Transport Blocks (TB) by using 64QAM modulation

3 New Look Up Tables are used to allow scheduler selecting the higher TB size for 64QAM modulation format.

4 New format for the HS-SCCH is defined allowing to indicate any of the 3 modulation schemes (QPSK, 16QAM and 64QAM) used on the HS-PDSCH in the current TTI.

5 New slot format for the HS-PDSCH is defined with 960 bits/slot.

6 Mac-ehs has to be configured in order to allow the usage of 64QAM because the selection of the modulation scheme is done in the MAC-ehs as part of the Transport Format Resource Combination (TFRC) selection function (Note that the MAC-ehs can be configured by the RNC without allowing the usage of 64QAM).

New UE categories have been introduced to support the 64QAM :-13 and 14 (64-QAM only), -17 and 18 (64-QAM or MIMO). These UE categories are MAC-ehs capable MIMO is not supported in UA07.






1 1 27

1 HSDPA Activation

1.17 Redundancy Version Parameters

0117

3016

2015

1014

1103

1112

0001

0010

brs16QAM XRV

307

316

205

214

103

112

001

010

rsQPSK XRV

RV CodingRV Coding MIR RV Update TableMIR RV Update Table

7430512616QAM XRV

74316520QPSK XRV

76543210k

TRV[k]

XRV=TRV[0]k=0

YES

NO

New Tx?

DTX? XRV=XRV

k=k+1

XRV= TRV[k mod Kmax]

NO

YES

RV UpdateRV Update

Kmax

PIR RV Update TablePIR RV Update Table

74052616QAM XRV

6420QPSK XRV

543210k

TRV[k]

Kmax

CC RVCC RV

The IR 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:

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

in transmissions.

- r (range 0 to rmax-1) changes the initialization Rate Matching parameter value in order to modify

the puncturing or repetition pattern.

- b can take 4 values (0,...,3) and determines which operations are produced on the 4 bits of each

symbol in 16QAM. This parameter is not used in QPSK and constitutes the 16QAM constellation

rotation.

These three parameters are indicated to the UE by the Xrv value sent on the HS-SCCH. The Xrv update

follows a predefined order stored in a table. A configurable parameter indicates the possibility to chose

between Chase Combining, Partial Incremental Redundancy or Full Incremental Redundancy. It implies that

three different tables must be stored.






1 1 28

1 HSDPA Activation

1.18 Flexible RLC and MAC-ehs

MAC-hsheader

RLC SDU

RLC PDU (fixed size)

MAC-d PDU

MAC-hs PDU MAC-hs SDU Pad.

Pad.

User payload

Transport Block Size (based on TRFC selection)

The RLC SDU segmentation into fixed size RLC PDUs may lead to padding in RLC PDU.

The Transport Block Size is the result of the TRFC selection algorithm. A non negligible number of padding bits may be required to fit the Transport Block Size.

In case of very bad radio condition, the selected Transport Block Size may be too small to contain a fixed-size MAC-d PDU: the UE is not scheduled

new

The new features in UA07 Flexible RLC and MAC-ehs are selected on a per-call basis. The selection is based on the following criteria:

Criteria for Mac-ehs selection:

RNC capability (feature activation flag), FddCell capability (feature activation flag)

NodeB local cell capability (notified to the RNC at NodeB startup in the NBAP RSI and NBAP Audit

Response

UE capability (notified to the RNC at RRC Connection Request)

Once Mac_ehs has been selected, criteria for Flexible RLC selection are based on the radio bearer to be

setup:

PS I/B: flexible RLC is always chosen

PS Str: flexibled RLC is chosen if isRlcFlexibleSizeForPsStrAllowed = TRUE

Other RB : fixed RLC is always chosen

The Layer2 Improvements feature has the following restrictions:

Not supported on iCem: the RB are reconfigured to MAC-ehs

Not supported over Iur: the RB are reconfigured to MAC-ehs






1 1 29

1 HSDPA Activation

1.18 Flexible RLC and MAC-ehs [cont.]

User payload

ReorderingSDU 1 header

MAC-d PDU 2

ReorderingSDU 1

Reordering SDU2

header

Reordering PDU

RLC SDU

RLC PDU

MAC- d PDU(=MAC-ehs SDU)

MAC-ehsPDU

(flexible size)

MAC-ehsheader

MAC-ehsheader

MAC-d PDU 3

Reordering PDU

MAC-d PDU 1

Pad-

No need for padding as RLC PDU size can be adjusted to fit exactly the size of the RLC SDU

Padding bits are reduced as MAC-ehscan segment a MAC-d PDU in case it cannot fit into the selected Transport Block

new

Intra-NodeB intra-frequency mobility with the source cell and the target cell having different Mac-ehs

capability: the NodeB does not support such reconfiguration:

Intra-Node mobility from Mac-hs to Mac-ehs capable cell: the RB remain configured with Mac-hs.

Intra-Node mobility from Mac-ehs to Mac-hs capable cell: the RB are fallbacked to R99.

Note: anyway there is no rationale for a customer to setup such configuration (FDDCell A isMacEhsAllowed= False and FDDCell B and C isMacEhsAllowed =True) !

Note: such restriction does not exist for intra-NodeB inter-frequency mobility.

The Layer2 Improvements feature has the following restrictions:

Inter RNC with IUR mobility (SRNS Relocation - UE not involved)

The RB remains with Mac-hs (as it was before SRNS relocation took place, refer to the restriction: not

supported over IUR).

It may be reconfigured to Mac-ehs at the next inter-NodeB mobility occasion to a cell Mac-ehs capable.

Note that such restriction does not exist for Inter RNC without Iur mobility (SRNS relocation UE involved):

the RB are reconfigured accordingly to the capability of the cell in the Target RNC.






1 1 30

1 HSDPA Activation

1.19 HARQ Stop and Wait Principles

Update RV Parameters

Transmit Data

Insert DTXIndication

Nret = Nret + 1Reset & FreeHARQ Process

Wait for Transmission

Wait for ACK/NACK Reception

ACK/NACK/DTX?

Nret > Nret_max

HARQHARQ

UE is Scheduled

ACK

YES

NACK

DTX

NO

TB1 HARQHARQ

TB2 HARQHARQ

HSDSCH

ACK/NACK

HS-DPCCH

harqNbMaxRetransmissionsharqNbMaxRetransmissionsXcem

(HsdpaConf)

Once a UE is scheduled, a HARQ process is assigned that may correspond to either a new Transport Block

transmission or a TB retransmission. The RV parameters are computed accordingly and data is transmitted.

The HARQ process is then waiting for feedback information (ACK/NACK/DTX):

In case of ACK reception, the HARQ process is reset and corresponding MAC-d PDUs are removed

from memory. This HARQ process can now be used for a new transmission.

In case of NACK reception, the number of retransmissions must be incremented. If the maximum

number of retransmissions (harqNbMaxRetransmissions for iCEM or harqNbMaxRetransmissionsXcem for xCEM) is not reached, the HARQ process is inserted in the NACK list of HARQ processes asking for retransmission.

In case of DTX indication, the same actions as for NACK reception are performed, except that a

parameter must be updated to notify DTX detection (this changes the RV parameter update).

After a NACK reception or a DTX indication, the HARQ processes are just waiting for being re-scheduled for

a new retransmission.

Note: DTX indication is used when there is no ACK/NACK reception.






1 1 31

1 HSDPA Activation

1.20 HARQ Mechanisms

Data 6 Ack/nack

Data 2

Data 7

Data 8

Data 6

Data 9

Data 11

Data 10

Data 12

Data 13

Data 1

To next step

(demultiplexing)

Data 2

Data 1

Data 2

Data 2

Transmissions

Ack

Nack

Ack

Ack

Nack

RV0 RV1 RV2

Process 0

Process 1

Process 2

Process 3

Data 2

combining

Data 5

Data 5

Data 3

Data 4

Ack

Ack

Data 3

Data 4

Data 9

Data 11

Data 10

Data 12

Data 13

Data 9

Data 11

Data 10

Data 12

Data 13

Ack

Ack

Ack

Ack

Ack

combining

Data 6

Data 6Ack

Data 1

Data 2

Data 2Data 6

Nack

Data 5

Data 3

Data 4

Data 8

Data 7

Data 7

Data 8

Ack

Ack

notes

updated

The retransmission mechanism selected for HSDPA is Hybrid Automatic Repeat Query (HARQ) with Stop and

Wait protocol (SAW). HARQ allows the UE to rapidly request retransmission of erroneous transport blocks

until they are successfully received. HARQ functionality is implemented at the MAC-(e)hs layer, which is

terminated at the NodeB, as opposed to the RLC (Radio Link Control), which is terminated at the S-RNC.

Therefore the retransmission delay of HSDPA is much lower than for R4, significantly reducing the delay

jittering for TCP/IP and delay sensitive applications.

In order to better use the waiting time between acknowledgments, multiple processes can run for the same

UE using separate TTIs. This is referred to as multiple Stop And Wait mechanism. While one channel is

awaiting an acknowledgment, the remaining channels continue to transmit.

There is a HARQ process assigned per transport block for all the retransmissions. The number of processes

per UE is limited and depends on UE category. The number of processes per UE category is defined by 3GPP

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

transmissions unless one of them is reset (ACK reception, max number of retransmissions reached,...).






1 1 32

1 HSDPA Activation

1.21 Optimal Redundancy Version for HARQ retransmission

CC

FIR

PIR

DynamicDynamic

RV TableRV Table

SelectionSelection

First RTx?

YES

maximum number of bits per HARQ

number of RM2 punctured bits

number of systematic bits

total number of radio bits

CC+CoRe

74052616QAM XRV

6420QPSK XRV

543210k

31616QAM XRV

73150QPSK XRV

43210k

405616QAM XRV

3210k

0QPSK XRV

0k

harqType(hsdpaConf)

if = drType or DRWithPowerAdaptation

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

dynamically selecting the most efficient HARQ type (and his corresponding RV table presented below)

according to several parameters: UE category, number of HARQ processes and applied AMC for first

transmission.

The different HARQ types (each one being associated to a restricted redundancy version set) that

can be selected are:

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

RV = 0

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

RV [0; 4; 5; 6].

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

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

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

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

To enable this feature the harqType parameter should be set to drType

Other possible values are mirType, pirType, ccType






1 1 33

1 HSDPA Activation

1.22 Channel Coding : Recall

InputData

TurboCoding

First RateMatching

Second Rate

MatchingVirtualIR Buffer

Spreading &Modulation

Systematic

bits

Parity 1

bits

Parity 2

bits

1/3

NSYS

NP2

NP1

RM S

RM P1_2

RM P2_2

RM P1_1

RM P2_1

NRM1 NDATA

NPUNC2

NIR

Definitions from 3GPP 25.212:

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

or 4) times 960 bits ???

NIR: maximum number of soft bits available in the virtual IR buffer per HARQ process the UE can

handle. It only depends on the UE category and the number of allocated HARQ processes.

NSYS: number of systematic bits

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

NRM1 = NSYS + NP1 + NP2

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






1 1 34

1 HSDPA Activation

1.23 Selection of the Redundancy Version per HARQ process

NACK received

1st retrans

NDATA>= 3xNSYS

NDATA>= NIR

NDATA-NSYS -NPUNC2 < 0

Use RV tables of HARQ typechosen at 1st retransmission

Yes

No

CC / CC+CoReYes

Yes

No

No

PIRFIRNoYes

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

dynamically selecting the most efficient HARQ type (and his corresponding RV table presented below)

according to several parameters: UE category, number of HARQ processes and applied AMC for first

transmission.

The different HARQ types (each one being associated to a restricted redundancy version set) that

can be selected are:

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

RV = 0

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

RV [0; 4; 5; 6].

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

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

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

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






1 1 35

1 HSDPA Activation

1.24 Multi-RAB handling on HSDPA

Interactive callBackground callStreaming call

Conversational call Speech, Video telephony

SRNC

Core Network

HS-DSCH

DCH

isMultiRabOnHsdpaAllowed (RadioAccessService)

enabledForRabMatching (multi-RAB DlUserService)enabledForRabMatching (multi-RAB UlUserService)

notes

updated

The UMTS allows to run different services (i.e. RAB) in parallel. For instance, a user can simultaneously run

a packet data session and initiate or receive a voice call without having to interrupt the packet data

transmission.

In the first HSDPA commercial release UA.2, all RAB combinations were supported on DCH: when a user had

a packet data session mapped on HSDPA and a second RAB had to be established, an automatic switching to

DCH was performed.

From UA05, the system is enhanced to take into account simultaneous user services like for example, the

possibility to make a voice or a video-telephony call while still benefiting from the high speed downlink

packet access provided by HSDPA.

If isMultiRabOnHsdpaAllowed is set to False, then the resulting multi-RAB DlUserService will be mapped on DCH only.






1 1 36

1 HSDPA Activation

1.25 Multi-RAB and GBR handling on HSDPA

Streaming, Interactive, Background

Core Network RNC

RNC

NodeB

NodeB

UEN

QI0 QI1 QI2

CID m

PDU flow

0

CID n

PDU flow

1cmCH-PI 6

cmCH-PI 6

cmCH-PI 4

SP6 SP6SP4

UE0

QI0

CID l

PDU flow

0

cmCH-PI 4

SP4

GBR QIx priority >

Non GBR QIy priority

If not All GBR flows satisfied

Higher SPI and smaller GBR served first

HS-DSCH

isMultiRabOnHsdpaAllowed (RadioAccessService)

enabledForRabMatching (multi-RAB DlUserService)enabledForRabMatching (multi-RAB UlUserService)

isGbrOnHsdpaAllowed (RadioAccessService)

Speech, Video telephonyDCH

notes

updated

Before UA06:

GBR only possible over DCH Transport channel

Since UA06:

From UA06.0 guaranteed bit rate (GBR) available for applications mapped on HS-DSCH Transport

channel GBR and non-GBR MAC-d flows are scheduled using common pool of resources available for

HSDPA (like power, code and time)

GBR queues are given priority over non-GBR traffic and within GBR queues higher SPI traffic is served

first

Within each SPI, if not all the GBR flows satisfied then the priority is given to those with least demanded

bandwidth

This can mean that flows with higher SPI and smaller GBR will always get served while those in lower SPI

as well as non-GBR flows will suffer from lack of throughput

Activated by simple RNC switch attribute

isGbrOnHsdpaAllowed under RadioAccessService

Benefits:

Allows support of following radio access bearers over HSDPA

PS Streaming (non-buffered delay sensitive applications)

PS Interactive/ Background with minimum bit rate (minBR) constraint

Enables ALU customers to support real-time video and audio multimedia services, real-time interactive

services (like games) and interactive or background services for Gold subscribers over HSDPA

Efficient use of air-interface resources by HSDPA made available to real-time services, enhancing

capacity in mixed configuration and off-loading such users from DCH in multi-layer configuration






1 1 37

1 HSDPA Activation

1.26 User Services supported with HSDPA

HSxPA

Stand-alone

PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)

PS Streaming HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128

Combination

CS Conv. Speech + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

CS Conv. VT + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

(CS Conv. Speech +) PS I/B MUX HSDPA/DCH DL: f(HSD UE category) UL: 64,128

CS Conv. Speech + PS Str. HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128

(CS Conv. Speech +) (PS I/B HSDPA/DCH+) PS Streaming (HSDPA or DCH/DCH) :

PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64,128

PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

CS Conv. Speech + PS I/B HSD/HSU DL: f(HSD UE category) UL: f(HSU UE category, TTI)

CS Conv. VT + PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)

(CS Conv. Speech +) (PS I/B HSDPA/HSUPA+) PS Streaming (HSDPA or DCH/DCH) :

PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64

PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)

UE are basically classified into 4 categories (TS 25.306):

those that can support a maximum of 32kbps on DCH with a simultaneous HS-DSCH configuration,

those that can support a maximum of 64kbps,

those that can support a maximum of 128kbps,

and those that can support a maximum of 384kbps.

As a consequence:

UE with a maximum capability of 32kbps does not support:

PS Streaming DL:64kbps/128kbps/256kbps+PS I/B (HS-DSCH)

CSD 64 + PS I/B (HS-DSCH)


PS Streaming DL:128kbps/256kbps+PS I/B (HS-DSCH)


PS Streaming DL:256kbps+PS I/B (HS-DSCH)

There is no limitation for UE with a maximum capability of 384kbps.

The DL capability with simultaneous HS-DSCH configuration IE is ignored by the RNC in UA05. Consequently, there will be a failure if the RNC attempts to establish one of the previously listed combinations for the corresponding UE. To avoid this situation, it is possible to fallback all (CS+)PS Streaming+PS I/B combinations to DCH.

This option is not activated by default but there is a flag to activate it:

isPsStreamingOnHSDPAAllowed (radioAccessService)

When set to false, all PS I/B + PS Str combinations will be mapped into DCH.






1 1 38

2 HSDPA RRM






1 1 39

2 HSDPA RRM

2.1 RAB Matching and CAC

HSDPA RAB

Service = PS?

Traffic Class

STR, I/B?

R99 RAB

YES

YES

YES

RAB Request

NO

NO

NO

RNCRNC

HSDPA UE?

Primary Cell = HSDPA Cell?

YES

NO

HSDPA CAC

RadioAccessService

HsdpaCellClass

maximumNumberOfUsers

RNC

BTSEquipment

hsdpaMaxNumberUserHbbu

hsdpaMaxNumberUserXcem

=

Capacity

hsdpaNumberUserCapacityLicensing

notes

updated

In UA06.0, if the Fair Sharing is disabled, the CAC is based on the number of HSDPA users as in the previous

releases (isHsxpaR99ResourcesSharingOnCellAllowed = False):

Any PS Interactive/Background RAB request is admitted on HSDPA until the maximum number of

simultaneous users allowed on HSDPA is reached for the cell.

PS Streaming must be disabled on HSDPA if Fair Sharing is deactivated as GBR can not be guaranteed.

RNC CAC:

maximumNumberOfUsers is the maximum number of HSDPA users per cell. By default this parameter is set to 100 (when the value is set to 100 the RNC CAC is deactivated, i.e. Node B performs the Call Admission

Control). Note that even if it is different than 100, RNC CAC based on the number of HSDPA users is

deactivated when Fair Sharing feature is enabled (isHsxpaR99ResourcesSharingOnCellAllowed = True).

BTS CAC:

Once the RNC CAC passed, the Node B is requested for CEM resources allocation through Radio Link

Reconfiguration procedure

The HSDPA CEM resources is handled by the H-BBU function for the iCEM or the M-BBU for the xCEM

If the H-BBU or M-BBU limit is reached, the BTS will send a RL Reconfiguration Failure (meaning NodeB

CAC failure)

The BTS limits the number of simultaneous HS-DSCH radio-links because of limited processing capacity. If

the limit is reached, the radio-link setup/reconfiguration is rejected. This leads to a RAB reject by the RNC.

BTS rejects when the current number of HSDPA users managed by the H-BBU is equal to hsdpaMaxNumberUserHbbu parameter value or when the current number of HSDPA users managed by the xCEM is equal to hsdpaMaxNumberUserXcem parameter value.

In case of HSDPA CAC failure (lack of resource) HSDPA to DCH fallback is triggered in order to reconfigure

the request to DCH as if the UE was not HSDPA capable.






1 1 40

2 HSDPA RRM

2.2 HSDPA to DCH Fallback

HSDPA RB to established

CAC OK ?

DCH RB to established

HSDPA RB established

Yes

No

HSDPA to DCH Fallback

RAB assignment (to establish or to release)IU release

Primary cell change

Incoming Inter-RNC UE involved Hard HandoverIncoming Intra-RNC Alarm Hard Handover

Mobility

hsdpaToDchFallbackPermission

(RadioAccessService)

RabAssignment

AnyCase

NoFallBack

HSPA to DCH fallback feature allows to establish or reconfigure the PS I/B RAB into DCH in case of HSDPA or

HSUPA CAC failure. The following HSxPA CAC failure scenarios trigger such a fallback:

RAB assignment (to establish or to release)

IU release

Primary cell change

Inter-RNC UE involved Hard Handover

Alarm Hard Handover

If for whatever reason the CAC fails when allocating the new radio bearer on HS-DSCH, the RNC will try to

fallback the radio bearer on DCH (this may be deactivated by the operator).

In this case, the RAB matching will be played again on DCH as if the mobile was not HSDPA capable. If the

output of the iRM table is reject then the fallback will not be attempted and the RAB will be rejected.

If the call admission on DCH rejects the fallback then the RAB will be rejected (but the existing ones will

be kept), except if there is another layer, in which case iMCTA (for CAC failure reason) is played.

If the UE has already a PS I/B RAB mapped on HS-DSCH then the RNC will try also to reconfigure this one to

DCH. If the CAC fails on the new configuration only the new RAB will be rejected (iMCTA may be also

played) but the existing ones will be kept.

RNC tries and remaps a call establish fall-backed to DCH RAB onto HSDPA or HSUPA in the following cases:

RAB assignment (to establish or to release a second RAB)

Primary Cell change

Inter-RNC (UE involved or not) HHO

HSPA to DCH fallback at Always-On upsize is not supported in UA05.0. However, fallback at Always-On

upsize is triggered when a second RAB is being established (either CS or PS).

In case HSPA to DCH fallback is disabled, any HSxPA CAC failure leads to an IU-PS Release procedure.






1 1 41

2 HSDPA RRM

2.3 Fair Sharing

FS On HS-DSCH required power

GBR On GBR info sent to NodeB (GBR or minBR)

NodeB dynamic OVSF codes management:

Monitor the DL OVSF code tree occupancy

Determine the codes available for HS-PDSCH scheduling

Reconfigure the H-BBU accordingly via a new internal message

OVSF

Power

I/B MinBRTC/ARP/THP

HSDPA RNC CAC

STR GBR

Used

Used

isGbrOnHsdpaAllowed

HS-DSCH required power for minBR (PS I/B)

HS-DSCH required power for GBR (PS Str) + minBr (PS I/B)True

False

Initial Radio Resources(power, codes)

hsdpaCodeTreeManagementActivation(BTSEquipment)

hsdschReqPwFilterCoeffhsdschReqPwReportingPeriod

(NBAPMeasurement)

isHsxpaR99ResourcesSharingOnCellAllowedDlPowerSelfTuningForPsIbOnHsdpaEnabled

(FDDCell)

Before UA06:

HSDPA CAC is based on number of HSDPA users whatever resources shared between all the HSDPA users (no

minimum HSDPA QoS)

Since UA06:

HSDPA CAC may be based on resource consumption (power and codes) in order to guarantee a given HSDPA

QoS to each HSDPA user (GBR or minBR)

From a RNC point of view, the purpose of Fair Sharing is to:

Base HSDPA CAC on resource consumption (power and codes) in order to guarantee a given HSDPA

QoS to each HSDPA user (GBR or MinBR)

Determine the initial required radio resources (power and codes) based on a target bit rate (GBR

parameter for Streaming RAB or MinBR parameter depending on TC/ARP/THP for I/B RAB)

Self-tune HSDPA power due to NodeB periodically reported HS-DSCH required power that gives the

minimum necessary power to meet GBR (reported for GBR users and for MinBR users if MinBR is

transmitted to the NodeB as a GBR)

From a NodeB point of view, the purpose of Fair Sharing is to:

Monitor the DL OVSF code tree occupancy

Determine the codes available for HS-PDSCH scheduling

Reconfigure the H-BBU accordingly via a new internal message

In UA06.0, if the Fair Sharing is disabled, the CAC is based on the number of HSDPA users as in the previous

releases isHsxpaR99ResourcesSharingOnCellAllowed = False):

Any PS Interactive/Background RAB request is admitted on HSDPA until the maximum number of

simultaneous users allowed on HSDPA is reached for the cell.

Unlike the iRM CAC performed for the RB mapped on DCH channels, the admission on HSDPA does not take

into account any o

Documents

HSxPA Algorithms Description