HSPA Algos UA07 TMO18256D0SGDENI3.0 PDF

9300 WCDMA
TMO18256 9300 WCDMA UAO7

HSxPA Algorithms Description
TMO18256 Issue D0 SG DEN I3.0
STUDENT GUIDE
All Rights Reserved © Alcatel-Lucent 2011
All rights reserved © Alcatel-Lucent 2011

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 Description - Page 1
Empty page
Switch to notes view!
2 All Rights Reserved © Alcatel-Lucent 2011

9300 WCDMA
TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description
This page is left blank intentionally

Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both 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-Lucent’s 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
3written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2011
9300 WCDMA
All rights reserved © Alcatel-Lucent 2011
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.

Blank Page

9300 WCDMA

Course Outline
Section
About This1.Course
HSDPA
4. Topic/Section is Positioned Here
Module 1.
Course outline TMO18256
Technical support
Section 2. HSUPA 5. Topic/Section is Positioned Here
Course objectives
Module 1. TMO18256
Section 3. Appendix
1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here
Xxx Module 1. TMO18256
Xxx
Section 4. Glossary 7. Topic/Section is Positioned Here
Xxx
Module 1. TMO18256
Section 5. iMCRA
Module 1. TMO18256

9300 WCDMA

Course Outline [cont.]

9300 WCDMA

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

9300 WCDMA

Course Objectives [cont.]

9300 WCDMA

About this Student Guide

Conventions
Switch used
to notes in this guide
view!
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.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

9300 WCDMA
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

About this Student Guide [cont.]

9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! 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
Yes (or No (or

Instructional objectives globally globally Comments
yes) no)
1 To be able to XXX
2
9300 WCDMA

Self-assessment of Objectives [cont.]
Yes (or No (or

Instructional objectives Globally globally Comments
yes) no)

9300 WCDMA
Other comments
Thank you for your answers to this questionnaire


Do not delete this graphic elements in here:
11
Section 1
HSDPA
Module 1
9300 WCDMA

Section 1 Module 1 Page 1
Blank Page

HSDPA
9300 WCDMA TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description
Document History
Edition Date Author Remarks

Module Objectives
Upon completion of this module, you should be able to:
Describe HSDPA principles and associated parameters

Describe HSDPA radio resource management parameters
Describe HSDPA mobility features and associated parameters

HSDPA

Module Objectives [cont.]

HSDPA

Table of Contents
Page
1 HSDPA Principles 7
1.1 HSDPA Distributed Architecture 8
1.2 HSDPA Evolution (HSDPA+) 9
1.3 HSDPA Activation Flags 10
1.4 HSDPA Dual Cell Activation 11
1.5 HSDPA UE Categories 12
1.6 HSDPA Evolution UE Categories 13
1.7 H-BBU Resource Allocation 14
1.7.1 Multi-Mode BBU Resource Allocation – xCEM case 15
1.7.2 Multiple xCEM per carrier 16
1.7.3 Parameters involved in CEM configuration 17
1.8 HSDPA/E-DCH Service Indicator broadcast 18
1.9 Transport Channel 19
1.10 Physical Channels 20
1.11 DL OVSF Code Tree 21
1.12 What is CQI in HSDPA ? 22
1.13 HSDPA Key Features 23
1.14 NodeB Scheduler 24
1.15 AMC Principles 25
1.15.1 QPSK & 16QAM Modulation Schemes 26
1.15.2 64 QAM On HSDPA 27
1.16 HARQ Types 28
1.16.1 Two H-ARQ Combining Techniques 29
1.16.2 Answer the Questions 30
115 1.16.3 H-ARQ Combining Performances All Rights Reserved © Alcatel-Lucent 2011
31
HSDPA
1.16.4
9300 WCDMA TMO18256 9300Constellation Re-arrangement
WCDMA UAO7 HSxPA Algorithms Description (16QAM) 32
1.16.5 Redundancy Version Parameters 33
1.16.6 Optimal Redundancy Version for HARQ retransmission 34
1.16.6.1 Channel Coding : Recall 35
1.16.6.2 Redundancy Version Selection per HARQ process 36
1.16.7 HARQ Stop and Wait Principles 37
1.16.8 HARQ Mechanisms 38
1.17 Multi-RAB handling on HSDPA 39
1.18 User Services supported with HSDPA – Stand-alone 40
1.19 User Services supported with HSDPA - Combination 41
2 HSDPA Scheduler 42
2.1 QoS Mapping 43
2.2 Scheduling Priority Indicator (SPI) 44
2.3 UE, QId and SPI 45
2.4 Scheduling Priority of GBR & Retransmissions 46
2.5 User Throughput & UE Category Management 47
2.6 Scheduler iCEM 48
2.6.1 Schedulers using Cost Function C1 only 49
2.6.2 Schedulers using Cost Functions C1 and C2: C1 50
2.6.3 Schedulers using Cost Functions C1 and C2: C2 51
2.6.4 TFRC SELECTION 52
2.7 Scheduler xCEM 53
2.7.1 SNR ESTIMATION FOR HS-PDSCH 54
2.7.2 TFRC SELECTION 55
2.7.3 TFRC SELECTION Summary 56
2.7.4 QoS management for proportionalThroughput scheduler 57
2.7.5 QoS management for CRmax scheduler 58
3 CQI & MAC-HS BLER Management 59
3.1 CQI Modification Principles 60
3.2 HS-DPCCH detection based on CQI 61

Table of Contents [cont.]
Page
3.3 HSDPA BLER as per 3 GPP 62
3.4 CQI adjustment based on BLER: blerRangeBasedAlgo 63
3.5 CQI adjustment based on BLER: OuterLoopLikeAlgorithm 64
3.6 CQI adjustmt based on BLER: Dynamic BLER Adjustment 65
3.6.1 CQI adjustment step as a function of the CQI range 66
3.7 CQI adjustment based on BLER : XCEM case 67
4 HSDPA Codes Management 68
4.1 HSDPA Codes Allocation Overview 69
4.2 Fair Sharing 70
4.3 Fair Sharing - RAN Model 71
4.4 Dynamic Code Tree Management 72
4.4.1 HS-PDSCH OVSF Codes Allocation 73
4.4.2 HS-PDSCH Codes Preemption / Reallocation 74
4.4.3 DCTM – RNC RAN Model 75
4.4.4 DCTM – NodeB RAN Model 76
5 HSDPA Power Management 77
5.1 HSDPA DL Power Reservation at RNC 78
5.2 HSDPA DL Power Available at NodeB – iCEM case 79
5.3 HSDPA DL Power Available at NodeB – xCEM case 80
5.4 Dynamic PA Power Sharing R99/HSPA Carriers 81
5.4.1 Impact on DCH DL CAC and DL iRM 82
5.5 HSDPA Power Distribution 83
5.6 HS-SCCH Power Control for iCEM 84
5.7 HS-SCCH Power Control for xCEM 85
1 1 6 5.8 HS-PDSCH Power for iCEM - 1st All Transmission
Rights Reserved © Alcatel-Lucent 2011
86
HSDPA
9300 WCDMA5.9 HS-PDSCH
TMO18256 Power
9300 WCDMA UAO7 for iCEM
HSxPA Algorithms - Retransmissions
Description 87
5.10 HS-PDSCH Power for xCEM 88
5.11 Exercise 89
5.12 HSDPA Full Power Usage 90
5.13 HS-DPCCH Power 91
5.14 HSDPA Power - RAN Model 92
6 HSDPA CAC & Call Management 93
6.1 RAB Matching and CAC 94
6.2 HSDPA CAC 95
6.2.1 Fair Bit Rate 96
6.2.2 Call Admission Control & Power Reservation 97
6.2.3 Call Admission Control & Codes Reservation 98
6.3 HSDPA to DCH Fallback 99
6.4 Initial Rate Capping during RB reconfiguration 100
6.5 Always On for HSDPA/DCH: Mono-Service PS/Mono-RAB 101
6.6 AON for HSDPA/DCH: Multi-Service PS/Multi-RAB PS 102
7 Other HSDPA Features 103
7.1 Fixed RLC and MAC-hs 104
7.2 Transport Block Size Optimization: CQI 1 to 15 105
7.3 Flexible RLC and MAC-ehs 106
7.4 64 QAM On HSDPA Activation Flags 107
7.5 HSDPA Flexible Modulation 108
8 HSDPA Mobility 109
8.1 3G->2G HHO 110
8.2 3G->3G Intra-RNC Inter-freq HHO 111
8.3 3G->3G Inter-RNC Inter-freq HHO 112
8.4 HSDPA over Iur 113
8.4.1 64-QAM over Iur: Not Supported 114

1 HSDPA Principles

HSDPA

1 HSDPA Principles
1.1 HSDPA Distributed Architecture
HS-PDSCH HS-SCCH
Data Transfer (PS I/B) Downlink Transfer Information
(UEid, OVSF,...) Introduction of MAC-ehs
RNC
Iub
HS-DPCCH
DPCH Feedback Information
Upper Layer Signaling (CQI, ACK/NACK)
Transport channel Frame Protocols

HS-DSCH HS-DSCH
RLC RLC
New MAC-ehs Layer
MAC-d MAC-d
Replaces MAC-hs
HS-DSCH Flow control HS-DSCH
MAC-ehs MAC-ehs FP FP
L2 L2
PHY Uu PHY L1 Iub L1
UE NodeB RNC
HSDPA
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 HSDPA Principles
1.2 HSDPA Evolution (HSDPA+)
Radio Interfaces
Multi-carrier HSDPA
e.g. Cat 10 e.g. Cat 14 F1
Q Q M MIMO Channel N
Node-B UE Channel Matrix, H
F2 Rel’7
I I I I
2.1
UL UL DL GHz DL
High SNR needed
5 5 5
16-QAM 64-QAM MHz MHz
MHz
HSPA+ Introduction HSPA+ Advanced HSPA+ Hot-Spots

Principles
Dual Carrier HSDPA (3GPP Rel8) MIMO 16QAM (3GPP Rel7) or MIMO
HSDPA 64QAM (3GPP Rel7)
64QAM (3GPP Rel8)
Up to 21 Mbps Up to 42 Mbps Up to 42 Mbps
Good radio condition needed Need 2 adjacent carriers High CAPEX (Double Radio Modules) &
OPEX (High Power Consumption)
No hw impact for Node Bs
Challenging terminal mix: MIMO
UE Cat 13-18 UE Cat 21-24 capable (high price tag)
The Smart Solution for Alcatel-Lucent HSDPA

Evolution in UA07 : 64 QAM & Dual Carrier
HSDPA

1 HSDPA Principles
1.3 HSDPA Activation Flags
RNC
NodeB BTSEquipment RadioAccessService UmtsNeighboring
FddCell BTSCell RemoteFDDCell
hsdpaActivation hsdpaResourceActivation isHsdpaAllowed isHsdpaAllowed
1 1 10 All Rights Reserved © Alcatel-Lucent 2011

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

4 FRS 81204: DC – HSDPA
1.4 HSDPA Dual Cell Activation
NodeB BTSEquipment RNC
FddCell1 BTSCell1 RadioAccessService

FddCell2 BTSCell2
HspaConf
isHsdpaDualCellActivated isHsdpaDualCellAllowed
dualCellActivation
hsdpaPlusPreferredMode

HSDPA
HSDPA-DC is configured if the following conditions are fulfilled:

The local cell is HSDPA-DC capable: The NodeB indicates to the RNC its cells’ DC
capability through “Multi Cell Capability Info” IE in the NBAP “Audit Response” or
“Resource Status Indication” messages by setting “Multi Cell Capable" for the Local Cell
and populating the “SecondaryServingCellList” with valid secondary serving cell
The UE is HSDPA-DC capable: The UE informs the RNC of its capabilities in the “RRC
Connection Setup Complete” message:
- “multiCellSupport” IE is set to TRUE (3GPP Rel’8)
- “HS-DSCH physical layer category extension2” IE corresponding to the HS-DSCH category
supported by the UE when HSDPA-DC and MAC-ehs are configured
The UTRAN is allowed to use HSDPA-DC:
RadioAccessService.isHsdpaDualCellAllowed = True
FDDCell.isHsdpaDualCellActivated = True
FDDCell.hsdpaPlusPreferredMode = dualCellPreferred
BTSCell/HsdpaConf.dualCellActivation = True
MAC-ehs HSDPA and E-DCH are enabled on both cells

1 HSDPA Principles
1.5 HSDPA UE Categories
HS -DSCH Category HS -PDSCH Max Number Inter -TTI Min Interval Modulation Max Peak Rate
Category 1 5 3 QPSK & 16 -QAM 1.2 Mbps
Category 11 5 2 QPSK only 0.9 Mbps
Category 12 5 1 QPSK only 1.8 Mbps
• QPSK mandatory for HSDPA capable UE

• 16 QAM optional
HSDPA
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 HSDPA Principles
1.6 HSDPA Evolution UE Categories
HS -DSCH Category HS -PDSCH Max Number Inter -TTI Min Interval Modulation Max Peak Rate
Category 13
1 5
15 3
1 QPSK&&16/
QPSK 1664-QAM
QAM 21.6 Mbps
Category 14
2 5
15 3
1 QPSK&&16/
QPSK 1664-QAM
QAM 14.4 Mbps
21.6
Category 15
3 5
15 2
1 QPSK
QPSK&&1616QAM
-QAM
& MIMO 1.8 Mbps
23.4 Mbps
Category 16
4 5
15 2
1 QPSK&&1616QAM
QPSK -QAM
& MIMO 1.8Mbps
28 Mbps
Category 17
5 5
15 1 QPSK
QPSK&&16/64
16 -QAM
- QAM 3.6 Mbps
21.6 Mbps
Category 18
6 15
5 1 QPSK
QPSK&&16/64
16 -QAM
- QAM 3.6 Mbps
21.6 Mbps
Category 19
7 10
15 1 QPSK
QPSK && 16 -QAM
16/64 QAM & MIMO 7.3 Mbps
35.3 Mbps
Category 20
8 10
15 1 QPSK
QPSK && 16 -QAM
16/64 QAM & MIMO 7.3 Mbps
42.2 Mbps
Category 21
9 15 1 QPSK
QPSK && 16 -QAM
16QAM & DC 10.2 Mbps
23.4
Category 10
22 15 1 QPSK
QPSK && 16 -QAM
16QAM & DC 14.4
28 Mbps
Mbps
Category 23
11 15
5 2
1 QPSKQPSK only
& 16/64 QAM & DC 0.9 Mbps
35.3 Mbps
Category 24
12 15
5 1 QPSKQPSK
& 16/64 QAM & DC
only 1.8 Mbps
42.2 Mbps
DC : Dual Carrier
MIMO : Multiple Input Multiple Output
HSDPA
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 HSDPA Principles
1.7 H-BBU Resource Allocation
– iCEM case BTSEquipment
UL
HS-DPCCH MAC-hs BTSCell
• HARQ
DL
• Scheduler
HS-DPDCH(s)
HS-SCCH(s) • Link Adaptation (AMC) HsdpaConf
HsdpaResourceId
BTS
H-BBU
iCEM128
H-BBU
iTRM MCPA DDM
H-BBU
iCEM128
D-BBU
H-BBU
iCCM iTRM MCPA DDM
iCEM64
D-BBU
iCEM128
D-BBU iTRM MCPA DDM
D-BBU
CEMa
D-BBU
Digital Shelf Radio Shelf

HSDPA
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.7.1 Multi-Mode BBU Resource Allocation – xCEM case
xCEM
BTSEquipment
BBU
BBU BBU
BBU 05
DCH DCH UA
DCH DCH
xCEM HsXpaResource
BBU
BBU BBU
BBU
BBU BBU
HSDPA
BBU
HSUPA BBU
HSDPA HSUPA
DCH DCH
DCH
DCH
BBU
BBU BBU
BBU
HSDPA HSDPA
HSDPA
HSDPA
Per xCEM :
- Up to 256 CE where 128 of them can
be used to support HSDPA and/or
HSUPA calls
06
UA - Up to 6 cells belonging to 2 LCGs
xCEM
BBU
BBU BBU
BBU
Multimode Multimode
Multimode
Multimode Per M-BBU :
BBU BBU Up to 64 calls shared

BBU BBU dynamically between R99,
Multimode Multimode
Multimode
Multimode HSDPA & HSUPA

HSDPA
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.7.2 Multiple xCEM per carrier
xCEM 1
1xCEM: 256 CE
Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 Cell 6 & 4.7/1.7Mbps DL/UL/Cell
UA05.1
xCEM 1 xCEM 2 & UA06
Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 2xCEM: 512 CE

Cell 6 & 9.3/3.4Mbps DL/UL/Cell
xCEM 1 xCEM 2 xCEM 3

3xCEM: 768CE
Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 & 14/5Mbps DL/UL/Cell
Cell 6
UA07.1.2
xCEM 1 xCEM 2 xCEM 3 xCEM 4
4xCEM: Cell 1,2,3 for
Cell 1 Cell 2 Cell 3 Cell 4 Cell 5 Cell 6
HSPA+ Max HSDPA Rel 7
capabilities guaranteed
On one carrier

HSDPA
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.7.3 Parameters involved in CEM configuration
BTSEquipment
RfCarrier R99Resource LocalCellGroup HsXpaResource
BTSCell
minimumR99ResourceRequired
localCellGroupId
hsdpaResourceActivation
LocalCellGroupId edchResourceActivation
r99ResourceId
hspaHardwareAllocation
priority
rfCarrierId
HsdpaConf
Common iCEM/xCEM parameters
hsdpaResourceId
HSPA allocation in iCEM or xCEM hsxpaResourceId
xCEM specific parameters EdchConf

EdchResourceId
iCEM specific parameters
HSDPA
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 HSDPA Principles
1.8 HSDPA/E-DCH Service Indicator broadcast
isHsxpaServiceIndicatorEnabled
(RadioAccessService)
RNC
SIB5 SIB5
NodeB NodeB
non HSDPA
HSDPA cell
cell
HSDPA UE Auto hsdpaServiceIndicatorMethod Auto HSDPA UE

edchServiceIndicatorMethod
(FDDCell)
HSDPA HSDPA
OK! NOK!

HSDPA
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 HSDPA Principles
1.9 Transport Channel
HSDPA Downlink transport channel: HS-DSCH BTSCell
HsdpaConf
DTCH
• Downlink
Traffic • TTI: 2ms
TRB • TBS free attribute of Transport format harqType
Mobile i
• AMC = f(CQI) harqTypeXcem
• HARQ
HS-DSCH • Turbo coding 1/3
DL • CRC 24bits
HS-PDSCH HS-SCCH
HS-DPCCH

HSDPA
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 HSDPA Principles
1.10 Physical Channels
RadioAccessService
DTCH
Traffic
TRB
HsdpaCellClass
HS-DSCH
DL
numberOfHsPdschCodes
HS-PDSCH HS-SCCH
numberOfHsScchCodes
HS-DPCCH

HSDPA
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 HSDPA Principles
1.11 DL OVSF Code Tree
SF128
SF256
SF16
SF32
SF64
SF4
SF8
0 Common channels (including S-CCPCH/1)
0
0
1 4 S-CCPCH/0
0
2 2
1 S-CCPCH/2
3
1 5 STATIC
4 6 Allocation
2
5 3 HS-SCCH
1
6 7
3
7
DYNAMIC
8
4 Allocation
9 Free OVSF codes
2 numberOfHsScchCodes
10
5
11
12
STATIC or DYNAMIC
6 Allocation
13 HS-PDSCH
3
numberOfHsPdschCodes
14
7
15
HSDPA
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 HSDPA Principles
1.12 What is CQI in HSDPA ?
Category 6 UE CQI Mapping Table

PHS-DSCH = PP-CPICH + Γ + ∆(CQI)
CQI Value HS-PDSCH Number RLC Throughput Modulation
0 out of range
1 1 0 kbps QPSK
S oft CQI vs C/I - P edes trian_a 1 RX
2 1 0 kbps QPSK 25
3 1 0 kbps QPSK
4 1 0 kbps QPSK
5 1 144 kbps QPSK
6 1 144 kbps QPSK
20
7 2 144 kbps QPSK
8 2 288 kbps QPSK
s oftCQI
9 2 288 kbps QPSK
10 3 432 kbps QPSK
11 3 576 kbps QPSK 15
12 3 720 kbps QPSK
13 4 864 kbps QPSK
14 4 1008 kbps QPSK
15 5 1296 kbps QPSK
10
16 5 1440 kbps 16-QAM -10 -8 -6 -4 -2 0 2 4 6 8 10
C/I (dB)
... ... ... ...
29 5 3024 kbps 16-QAM
30 5 3024 kbps 16-QAM
Target BLER ≤ 10%

HSDPA
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 HSDPA Principles
1.13 HSDPA Key Features
RNC Capacity Request Capacity Allocation

Control FP Control FP Data FP
Flow Control
Dynamically fills the Queues of each UE
Queue IDs
Scheduler
Fills the TTIs with one or more users based on their priority and
feedback information
HARQ Processes
Retransmissions handling, TFRC selection, AMC …
Feedback Reception Radio Transmission

HSDPA
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 HSDPA Principles
1.14 NodeB Scheduler
Flow Control
(UEX, SPIY)
QId0 QId1 QIdK QIdN

available codes
available power
UE capabilities
ACK/NACK/CQI HARQ
Compressed Mode information
Min COST value
UE HSDPA synchronisation state
NodeB Scheduler
HSDPA scheduler runs every 2 ms

HSDPA
NodeB scheduler sets the number of users transmitting in the next TTI. For each user it determines the
HARQ process used, the QId from which data are transmitted, the parameters used for the transmission
(codes, power, modulation, redundancy version).
The aim of the scheduler is to dynamically share available DL bandwidth among users in order to optimize
overall throughput and fulfill UTRAN and UE criteria. In order to manage the two aspects, QId are selected
using radio (CQI) and priority (SPI) criteria. Selection of QId is based on a single cost function which inputs
are two costs:
C1 depends on the scheduler type. It takes into account the radio criterion.
C2 takes into account the priority of the QID and mainly depends on the base credits assigned to
this SPI priority and the average CQI. This is only used by Alcatel-Lucent and Proportional Fair
schedulers.
The resulting cost is a function of these two costs, and is different according to the scheduler type. Indeed,
for Alcatel-Lucent Proportional Fair scheduler, the resulting cost should be equal to α*C1+β*C2, while for
the classical Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The
QId with the smallest cost is scheduled first. Costs are updated after the QId has been served.
Note : when the UE is in compressed mode or in non HSDPA synchronised state (see chapter HS-DPCCH
detection based on CQI, for more details), then the Node B will not schedule it.

1 HSDPA Principles
1.15 AMC Principles
UE Category Reported CQI AMC Illustration

800
700 QPSK ¼
QPSK ½
600 QPSK ¾
16QAM ½
Throughput (kbps)
500 16QAM ¾
AMC
2ms
400
300
200
100
0
Coding Modulation Number of -20 -15 -10 -5 0 5
Rate Scheme OVSF Codes Ior/Ioc (dB)
Maximum Throughput

HSDPA
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.12 AMC Principles
1.15.1 QPSK & 16QAM Modulation Schemes
16QAM
Q
QPSK
1011 1001 0001 0011
1010 1000 0000 0010

10 00
I
I
1110 1100 0100 0110
11 01
1111 1101 0101 0111
2 bits per symbol

480kbps per OVSF
960 bits per TTI
4 bits per symbol
960kbps per OVSF
1920 bits per TTI

HSDPA
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.12 AMC Principles
1.15.2 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.

HSDPA
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.
The theoretical peak data rate at physical layer is :

21.6 Mbps = 2880 x 15 codes / 2ms with 64QAM instead of 14.4 Mbps = 1920 x 15 codes / 2ms with 16QAM

1 HSDPA Principles
1.16 HARQ Types
Chase Combining
DATA DATA DATA DATA DATA
NACK NACK NACK NACK ACK
BTSEquipment
{mirType, pirType, ccType, drType, …WithPowerAdaptation} harqType
{ccType, irType} harqTypeXcem BTSCell
HsdpaConf
Incremental Redundancy Combining
DATA DATA1 DATA2 DATA3 DATA4
NACK NACK NACK NACK ACK

HSDPA
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.13 HARQ Types
1.16.1 Two H-ARQ Combining Techniques
Chase Combining Incremental Redundancy

Original useful data bits
Turbo coding Turbo coding

Rate 1/3 Rate 1/3
1st rate 1st rate

matching Node B side matching
2nd rate UE buffer size UE buffer size 2nd rate

matching matching
RV=6 1st transmission RV=0
RV=6 2nd transmission RV=2
RV=6 3rd transmission RV=5
RV=6 UE side
Eff. coding rate (RCC) = # data bits / (#data bits + # parity bits)
RIR < RCC Parity bits
⇒Better protection of the data bits (protection)
⇒higher probability to decode correctly

HSDPA
HOW are those data blocks combined to be able to recover a correct blocks from several corrupted
copies?
1st step Rate Matching:
3GPP TS 25.212] The first rate matching stage matches the number of input bits to the virtual buffer.
Note that, if the number of input bits does not exceed the virtual buffering capability, the first rate-
matching stage is transparent. The 1st rate matching performs segmentation at the maximum UE buffer
size when required.
The second rate matching stage matches the number of bits after first rate matching stage to the
number of physical channel bits available in the HS-PDSCH set in the TTI. The 2nd rate matching follows
transport format indications to achieve the effective coding rate expected during the TTI.
2nd step retransmission according to combining methods:
Chase Combining (CC)
Retransmit the same block with exactly the same bits at each retransmission
The UE buffer size is fixed for each transport block retransmission
Incremental Redundancy (IR)
Retransmit the same block with different redundancy information at each retransmission,
thanks to different rate matching version.
The use of different Redundancy Versions (RV) increases the performances of the channel
since the total effective coding rate is decreased (more protection bits) at each
retransmission
The UE buffer size increases for each transport block retransmission. IR requires a larger
memory and processing in the UE than the Chase Combining case.
The ARQ combining scheme is based on Incremental redundancy. Chase Combining is
considered to be a particular case of Incremental Redundancy.

1.13 HARQ Types
1.16.2 Answer the Questions
According to the previous slide:
What is the coding rate (Rbuffer) after the 1st rate matching for both combining
mechanisms?
What is the coding rate (RCC(#k)) of each block applying the Chase Combining
mechanism?
What is the coding rate (RIR(#k)) of each block applying the Incremental
Redundancy combining mechanism?
Compare the effective coding rates (RIR(UE) and RCC(UE)) at UE side

between CC and IR techniques after retransmissions.

HSDPA

1.13 HARQ Types
1.16.3 H-ARQ Combining Performances
coding rate 3/4, Pedestrian A, 3 km/h, H-ARQ = ON, N_max = 5

1
High error N = 1, CC
N = 2, CC
rate N = 3, CC
N = 1, IR
N = 2, IR
ns N = 3, IR
10% BLER 0.1 io
2dB gain iss
m
(N=3)
ans
BLER
-tr
Re g
o din al
c t
0.01
r de men
tte re cy
Be h Inc ndan
t
Low error wi Redu
rate Bad link Good link
quality ~2dB gain
0.001 (N=3)
quality
-10 -5 0 5 10
Ior/Ioc [dB]

HSDPA
What does this figure represent?

Error rate is function of the quality of the radio link
BLER= Block Error Rate
Ior/Ioc is representative of the radio conditions of the cell, in dB:
N represents the index of transmission
N=1 first transmission; N=2 second transmission (=first re-transmission)
IR = Incremental Redundancy is an H-ARQ combining technique
CC = Chase Combining is another H-ARQ combining technique
What happen without H-ARQ?
Without H-ARQ, to reach an error rate of 5%, an Ior/Ioc of 8 dB is required, meaning a good link
quality.
If the channel quality induces a BLER=0.1=10%, it means 10% chance to receive an erroneous block
(at N=1). If this block is effectively in error,
at the first retransmission (N=2), the chance to get the same block in error is now at the power of
2, i.e. BLER=10%x10%=0.01=1%,
for the second retransmission (N=3), the block has been received in error for the second time, your
chance to receive again the block in error for the third time is BLER=0.1%.
What are the advantages of H-ARQ?
You can notice that for the same number of re-transmission, both H-ARQ combining techniques achieve
better performances than without (much less errors for the same quality of the link).
What are the performances of the H-ARQ combining techniques?
We can notice that for a single retransmission (N=2), there is not much differences between Chase
Combining and Incremental Redundancy.
For the second re-transmission (N=3), IR achieves better performances than CC with a gain of 2dB.

1.13 HARQ Types
1.16.4 Constellation Re-arrangement (16QAM)
Q Q
1011 1001 0001 0011 1110 0110 0100 1100
1010 1000 0000 0010 1010 0010 0000 1000
b=0 b=1
I I
1110 1100 0100 0110 1011 0011 0001 1001
1111 1101 0101 0111 1111 0111 0101 1101
Q Q
1000 1010 0010 0000 0010 1010 1000 0000
1001 1011 0011 0001 0110 1110 1100 0100
b=2 b=3
I I
1101 1111 0111 0101 0111 1111 1101 0101
1100 1110 0110 0100 0011 1011 1001 0001

HSDPA
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).
b Output bit sequence Operation
0 nk, nk+1, nk+2, nk+3 none
1 nk+2, nk+3, nk, nk+1 swapping MSBs with LSBs
2 nk, nk+1, nk+2, nk+3 inversion of the logical values of LSBs
3 nk+2, nk+3, nk, nk+1 swapping MSBs with LSBs & LSBs values inversion

1.13 HARQ Types
1.16.5 Redundancy Version Parameters
Kmax
RV Coding MIR RV Update Table
16QAM XRV s r b QPSK XRV s r k 0 1 2 3 4 5 6 7
0 1 0 0 0 1 0 QPSK XRV 0 2 5 6 1 3 4 7
1 0 0 0 1 0 0
16QAM XRV 6 2 1 5 0 3 4 7
2 1 1 1 2 1 1
3 0 1 1 3 0 1
TRV[k]
4 1 0 1 4 1 2
5 1 0 2 5 0 2 RV Update
6 1 0 3 6 1 3
7 1 1 0 7 0 3 YES XRV=TRV[0]
New Tx?
k=0
NO
Kmax
PIR RV Update Table YES

DTX? XRV=XRV
k 0 1 2 3 4 5
QPSK XRV 0 2 4 6
CC RV
NO
16QAM XRV 6 2 5 0 4 7
k=k+1
TRV[k] XRV= TRV[k mod Kmax]

HSDPA
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.13 HARQ Types
1.16.6 Optimal Redundancy Version for HARQ retransmission
harqType
if = drType or DRWithPowerAdaptation
(hsdpaConf)
k 0 1 2 3 4 5
First RTx? PIR QPSK XRV 0 2 4 6
16QAM XRV 6 2 5 0 4 7
YES
k 0 1 2 3 4
FIR QPSK XRV 0 5 1 3 7
16QAM XRV 6 1 3
Dynamic
RV Table
Selection
k 0 1 2 3
CC+CoRe
16QAM XRV 6 5 0 4
maximum number of bits per HARQ

number of RM2 punctured bits k 0
number of systematic bits CC
QPSK XRV 0
total number of radio bits

HSDPA
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.16.6.1 Channel Coding : Recall
First Rate Virtual Second Rate

Matching IR Buffer Matching
Systematic NSYS
bits RM S
Input Turbo Parity 1 NP2 Spreading &

Data Coding bits RM P1_1 RM P1_2 Modulation
1/3
Parity 2 NP1
bits RM P2_1 RM P2_2
NIR
NRM1 NDATA
NPUNC2
HSDPA
Definitions from 3GPP 25.212:

NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes times the modulation order (2, 4
or 6) times 480 bits (e.g. 16 QAM : number of codes x 4 x 480 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 1 st RM step.
NRM1 = NSYS + NP1 + NP2
NPUNC2 = NRM1 - NDATA: number of bits punctured by 2nd RM stage.

1.16.6.2 Redundancy Version Selection per HARQ process
NACK received
No Use RV tables of HARQ type

1st retrans
chosen at 1st retransmission
Yes
Yes
CC / CC+CoRe NDATA>= 3xNSYS
No
Yes
NDATA>= NIR
No
Yes No
FIR NDATA-NSYS -NPUNC2 < 0 PIR

HSDPA
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.13 HARQ Types
1.16.7 HARQ Stop and Wait Principles
HARQ Wait for Transmission
UE is Scheduled
TB1 HARQ
Update RV Parameters
TB2 HARQ
Transmit Data
HSDSCH
Wait for ACK/NACK Reception
Insert DTX
ACK ACK/NACK/DTX? DTX
Indication
NACK
Reset & Free ACK/NACK

Nret = Nret + 1
HARQ Process HS-DPCCH
harqNbMaxRetransmissions
YES Nret > Nret_max NO harqNbMaxRetransmissionsXcem
(HsdpaConf)

HSDPA
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.13 HARQ Types
1.16.8 HARQ Mechanisms
Ack Data 1 RV0 RV1 RV2
Data 1 Process 0
Nack Data 2
Process 1
Data 2 Ack Data 3 Process 2
Process 3
Data 3 Ack Data 4
Data 4
Transmissions
Ack Data 5 To next step
Data 5 Nack Data 2 (demultiplexing)
combining
Data 2 Nack Data 6 Data 1
Data 6 Ack/nack Ack Data 3

Data 7
Data 7 Ack Data 4
Data 8
Data 8 Ack Data 5
Data 2
Data 2 Ack Data 7
Data 6
Data 6 Ack Data 8
Data 9 combining
Data 9 Ack Data 2
Data 10
Data 10 Ack Data 6
Data 11
Data 11 Ack Data 9
Data 12
Data 12 Ack Data 10
Data 13
Data 13 Data 11
Data 12
Data 13
HSDPA
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 HSDPA Principles
1.17 Multi-RAB handling on HSDPA
isMultiRabOnHsdpaAllowed (RadioAccessService)
Core Network enabledForRabMatching (multi-RAB DlUserService)
enabledForRabMatching (multi-RAB UlUserService)
SRNC
HS-DSCH
Interactive call
Background call
Streaming call
Conversational call Speech, Video telephony

DCH

HSDPA
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 HSDPA Principles
1.18 User Services supported with HSDPA – Stand-alone
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
PS Streaming HSDPA/HSUPA DL: f(HSD UE category)
UL: f(HSU UE category, TTI, GBR (only for xCEM))

HSDPA
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,
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 HSDPA Principles
1.19 User Services supported with HSDPA - Combination
isMultiRabOnHsdpaAllowed (RadioAccessService)
Combination
CS Conv. Speech + 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/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384
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 MUX HSDPA/DCH DL: f(HSD UE category) UL: 64,128
CS Conv. Speech + PS Streaming HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128
(CS Conv. Speech +) (PS I/B HSDPA/DCH +) PS Streaming:
PS Streaming (HSDPA or DCH/DCH) DL: 16,64,128,256,384 or f(HSD UE category, GBR)
UL: 16,32,64,128
PS I/B: DL: f(HSD UE category) UL: 8,16,32,64,128,384
(CS Conv. Speech +) (PS I/B HSDPA/HSUPA +) PS Streaming:
PS Streaming (HSDPA or DCH/DCH) DL: 16,64,128,256,384 or f(HSD UE category, GBR)
UL: 16,32,64, E-DCH (f(HSU UE category, TTI,
GBR (only for xCEM)))
PS I/B:
DL: f(HSD UE category) UL: f(HSU UE category, TTI)
CS Conv. Speech + PS Streaming HSxPA DL: f(HSD UE category, GBR)
(CS Conv. Speech +) PS I/B MUX HSxPA DL: f(HSD UE category (only for xCEM))
HSDPA
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,
and those that can support a maximum of 384kbps.
As a consequence:
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.
When the multi-RAB on HSDPA is activated (isMultiRabOnHsdpaAllowed set to True), it is recommended to ensure that
the related DlUserService are enabled for RAB Matching:
• Speech + HSDPA
• CSD + HSDPA
• PS Streaming (DCH or HSDPA) + HSDPA
• Speech + PS Streaming (DCH or HSDPA) + HSDPA

2 HSDPA Scheduler

HSDPA

2 HSDPA Scheduler
2.1 QoS Mapping
QoS differentiation is based on TC, ARP and THP parameters
Service differentiation Subscriber differentiation
• Virtual Office
=> emails • Privileged
users
• Web Browsing
• Video Streaming
3GPP
TC: Traffic Class OLS: Olympic Level Service (gold, silver,bronze)

ARP: Allocation/Retention Priority Mapping MLP: MAC Logical Channel Priority
THP: Traffic Handling Priority table SPI: Scheduling Priority Indicator
UTRAN & Core ALU’s RNC

HSDPA
There are mainly two reasons why operators wish to implement QoS differentiation:
Service differentiation:
because PS data services have different QoS requirements, there is a need to provide QoS
differentiation among these different services. For example, since streaming video does not have the
same QoS requirements than web browsing, traffic must be scheduled differently. Due to capacity
constraints, operators may also want to treat PS services differently when performing admission
control.
a preferential treatment can be granted to premium users consuming a high volume of data compared
to users of a less privileged subscription class who are ready to support lower performance in case of
reduced final rate.
QoS differentiation can be implemented by means of three different QoS attributes :
Traffic Class (TC), Allocation/Retention Priority (ARP) and Traffic Handling Priority (THP is only
defined for Interactive TC). Because QoS has to be provided end-to-end, operators need to have the
flexibility to use these parameters consistently in the QoS differentiation algorithms implemented in
each network element, including the UTRAN.
Alcatel-Lucent RNC makes use of different parameters to prioritize subscribers or services :
Olympic Level Service (OLS) is Alcatel-Lucent's terminology to account for subscriber priority. The
RNC supports three distinct OLS priority values, i.e. Gold > Silver > Bronze and typically uses these
values in iRM features.
MAC Logical channel Priority (MLP) is used to prioritize different user's RAB when multiplexed onto
the same DCH (i.e. MAC-d multiplexing). This is the case when multiple PS I/B RAB are assigned to the
same user. MLP value ranges from 1 to 8.
Scheduling Priority Indicator (SPI) is used in the HSDPA packet scheduler to prioritize the different
MAC-d entity.

2 HSDPA Scheduler
2.2 Scheduling Priority Indicator (SPI)
From Used as inputs to RRM algorithms to OLS:
From RAB Request • Used as input to iRM Tables & AO
RAB assignment provide user QoS differentiation • Subscriber Differentiation
assignment Request
MLP:
Traffic ARP THP OLS MLP SPI • Used to prioritize the different PS I/B RABs assigned
to the same user (at the MAC layer).
class
• Service Differentiation
Streaming 1 N/A Gold N/A 15
SPI:
Streaming 2 N/A Silver N/A 14 • Derived SPI is provided by the RNC to the BTS per
MAC-d for MAC-(e)hs prioritization in the HSDPA
Streaming 3 N/A Bronze N/A 13 scheduler
• Subscriber Differentiation
Interactive 1 1 Gold 8 12
Interactive 1 2 Gold 7 11
Interactive 1 3 Gold 6 10 RadioAccessService
Interactive 2 1 Silver 5 9
Interactive 2 2 Silver 4 8 TrafficClassBasedQos 0..3
Interactive 2 3 Silver 3 7
Interactive 3 1 Bronze 2 6 iuPriorityLevel
Interactive 3 2 Bronze 2 5 ArpBasedQos 3
Interactive 3 3 Bronze 2 4
iuThp ThpBasedQos
Background 1 N/A Gold 1 3 3
mlp
Background 2 N/A Silver 1 2 ols
Background 3 N/A Bronze 1 1 spi
HSDPA
QoS differentiation can be implemented by means of three different QoS attributes:

1. Traffic Class (TC),
2. Allocation/Retention Priority (ARP) and
3. Traffic Handling Priority (THP is only defined for Interactive TC).
The Alcatel-Lucent RNC makes use of the above 3 different parameters to prioritize subscribers or services,
by using an operator configurable table which provides the flexibility to define OLS, MLP and SPI based on
TC and/or ARP and/or THP parameters :
1. Olympic Level Service (OLS) subscriber priority, i.e. Gold > Silver > Bronze. Typically used in iRM
features (iRM Table, AO, iRM Preemption, Power Control).
2. MAC Logical channel Priority (MLP) used to prioritize the different PS I/B RABs assigned to the same
user, when multiplexed onto a single DCH. This attribute is only relevant for interactive and
background Traffic Class. MLP value ranges from 1 to 8.
3. Scheduling Priority Indicator (SPI) is used in the HSDPA packet scheduler to prioritize the different
MAC-d entity. SPI value ranges 0 to 15 (0 = lowest priority, 15 = highest priority).
In order to provide operators with the flexibility to define OLS, MLP and SPI based on TC and/or ARP and/or
THP parameters, the above configurable table is provided at the OMC, where the green bold part
represents what can be filled by the operator (this table is just an example).

2 HSDPA Scheduler
2.3 UE, QId and SPI
UE0 UEN
cmCH-PI 4
cmCH-PI 6
cmCH-PI 4
cmCH-PI 6
RNC
PDU flow0
PDU flow0
PDU flow1
CID m
CID n
CID l
QI0 QI0 QI1 QI2

NodeB
SP4 SP6 SP4 SP6

HSDPA
Each UE can be configured with one or more MAC-d flows according to the number of PS services
established and mapping rules on RNC side. Each MAC-d flow is associated to a CID for data Frame Protocol.
One MAC-d flow is constituted of one or more logical subflows. If these subflows are assigned the same
priority, they are multiplexed at RNC side and this is transparent to NodeB and they are seen as a single
flow. If these subflows are assigned a different priority, they are discriminated by the SPI/CmCH-PI
parameter and are seen as different flows.
These resulting flows then constitute the priority queues for a UE and are assigned a Queue ID. Up to 8
queues can be defined per UE and are referred in the whole document as the QId.
For one UE, two QIds from the same MAC-d flow then necessarily have two different priorities, while two
QIds of two different MAC-d flows may have the same priority. A QId is then unambiguously defined by its
MAC-d flow CID and its priority (SPI).
In the scheduler the QId of all UEs are classified according to their SPI/CmCH-PI. This enables allocating
some bandwidth according to the priority. Up to 16 SPI can be defined in the scheduler.
Note:
CmCH-PI: Common Transport Channel Priority Indicator ( SPI)
SPI: Scheduling Priority Indicator ( CmCH-PI)

2 HSDPA Scheduler
2.4 Scheduling Priority of GBR & Retransmissions
isGbrOnHsdpaAllowed (RadioAccessService)
Step 1 : Traffic Classe Criteria :
cmCH-PI 6
cmCH-PI 4
cmCH-PI 4
cmCH-PI 6
1) GBR QIx priority > Non GBR QIy priority UEN
RNC
2) Highest GBR SPI UE0
3) Lowest GBR
PDU flow0
PDU flow0
PDU flow1
CID m
CID l
CID n
Step 2 : Retransmissions Criteria
QI0 QI0 QI1 QI2
NodeB
Retransmissions > First Transmission
Criteria checked for all UE for iCEM & for
different HARQ processes of a given priority SP4 SP6 SP4 SP6
queue for xCEM

HSDPA
1) GBR priority :
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
2) Retransmissions priority :
With iCEM, retransmissions are always transmitted before first transmissions.
With xCEM, retransmissions are transmitted before first transmission only for different HARQ processes of a given
priority queue. Between two different priority queues (between two different users), retransmissions have no
priority over first transmissions anymore. The aim is to maximize the cell throughput.

2 HSDPA Scheduler
2.5 User Throughput & UE Category Management
BTSCell
HsdpaConf hsdpaSpiRelativeWeight
hsdpaUeCategoryThroughputWeighting ueCategoryProportionality
hsdpaUeCategoryThroughputWeightingXcem
ueCategoryEquity
Th(QId1) Weight[SPI(QId1)] TBS[CQIav(QId1)]
= x
Th(QId2 ) Weight[SPI(QId2)] TBS[CQIav(QId2)]
Th(QId1) Weight[SPI(QId1)] TBScat12[CQIav(QId1)]

= x
Th(QId2) Weight[SPI(QId2)] TBScat12 [CQIav(QId2)]
Feature used only if SPI management is activated

HSDPA
The base credits assigned per SPI priority provide the relative weight given per priority. The absolute value
is not meaningful, only the ratio between priorities is important.
hsdpaSpiRelativeWeight is a table of maximum 16 weight values (between 1 and 100) each one
corresponding to a SPI value.
Example: if base credits of priority queue #4 (resp #3) is set to 20 (resp 10), a UE in priority queue
#4 would be provided around twice throughput than a UE of same category in priority queue #3 if
CQI are equal.
UE categories also add some bias in the way Qids are emptied. A balance is performed between different
categories when one of them is limited by the transport block size. Indeed, above CQI 15 for instance, the
transport block size of a UE cat 12 remains constant while for other categories (e.g. 6 or 10) their transport
block size still increases with the CQI.
Two behaviors are then defined according to the value of the parameter
hsdpaUeCategoryThroughputWeighting :
ueCategoryEquity: UE categories with same SPI will reach the same throughput in average at the
same CQI.
ueCategoryProportionality: UEs throughput will depend on their category. With same SPI, their
ratio throughput will then be proportional to the ratio of transport block size of corresponding CQI
(when UEs have the same CQI).
The hsdpaUeCategoryThroughputWeighting (iCEM) and hsdpaUeCategoryThroughputWeightingXcem

(xCEM) parameter is only applicable when SPI management is activated. Hence, it is disabled in case of
all hsdpaSpiRelativeWeights [SPI] are equal to 100.

2 HSDPA Scheduler
2.6 Scheduler iCEM
UE Capabilities Available Power & Codes ACK/NACK/CQI Previously Transmitted PDUs
Retransmissions First
QId0 QId1 QIdN
New Transmissions
hsdpaSchedulerAlgorithm
(HsdpaConf)
Round Robin Fair MaxCQI Classical Prop Fair ALU Prop Fair Min COST value
COST = C1 = C1 = C1 = γ x C1 x C2 = α*C1+β*C2
Defined by 3GPP, but

not used by ALU UE #1 UE #N
• power • power
• codes • codes
• number of bits • number of bits

HSDPA
A preliminary allocation phase consists in scheduling retransmissions before allocating resources to new
transmissions. In case retransmissions are scheduled in the coming TTI, the amount of power available for
new transmissions is reduced accordingly.
For new transmissions, the decision of the scheduler is based on cost function C1 & C2.
C1 cost depends on the scheduler type. It takes into account the radio criterion :
Round Robin: serve UEs one after the other
Max C/I: serve UEs which reports the best radio conditions (best CQI)
Fair: all UEs benefit from the same throughput
Classical Proportional Fair: favor UEs that report a high CQI versus their averaged CQI to take
benefit from instantaneous good radio conditions vs. average conditions
Alcatel-Lucent Proportional Fair: favor UEs that have less been served compared to what they
should get according to their reported CQI
UE selection is a tradeoff between throughput optimization and equity among UEs.
C2 cost takes into account the priority of the QID and mainly depends on the base credits assigned to this
SPI priority and the average CQI.
This is used by both Alcatel-Lucent PF and Classical PF schedulers
The resulting cost is a function of these two costs, and is different according to the scheduler type. Indeed,
for Alcatel-Lucent Proportional Fair scheduler, the resulting cost should be equal to αC1+βC2, while for the
Classical Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The QId
with the smallest cost is scheduled first. Costs are updated after the QId has been served.

2.6 Scheduler iCEM
2.6.1 Schedulers using Cost Function C1 only
ROUND ROBIN
Goal to serve mobiles one after the other
Cost function C1 C1T = C1T-1 + δ

with δ = 1 if scheduled, 0 otherwise
MAX C/I
Goal to serve the mobile which reports the best radio conditions
Cost function C1 C1T = 30 – CQIinstT

with CQIinst is the latest CQI reported
FAIR
Goal To provide the same throughput to all mobiles
Cost function C1 C1T-1 = C1T-1-1 + nb_bits_transmitted

HSDPA
Round Robin: serve UEs one after the other

Advantage: all UEs are served
Drawback: allocated resources are not adapted to radio conditions, Ues in bad radio conditions will
lead to retransmissions and therefore decrease of MAC-d cell throughput
Max C/I: serve UEs which reports the best radio conditions (best CQI)
Advantage: choosing UEs on radio conditions improves effective throughput by inducing smaller
probability to get errors and thus triggering less retransmissions
Drawback: selecting UEs according to radio conditions induces UEs in bad conditions to never be
served
Fair: all UEs benefit from the same throughput
Advantage: all UEs are served
Drawback: allocated resources are not adapted to the amount of data to be sent per UE

2.6 Scheduler iCEM
2.6.2 Schedulers using Cost Functions C1 and C2: C1
CLASSICAL PROPORTIONAL FAIR
to favor mobiles that report a high CQI versus their averaged CQI to
Goal
take benefit from instantaneous good radio conditions vs average
conditions
Cost function C1 C1T = CQIavT / CQIinstT

with CQIavT = ρ x CQIavT-1 + (1 - ρ) x CQIinstT
ALCATEL-LUCENT PROPORTIONAL FAIR
to favor mobiles that have not been served (#PDUs transmitted) versus
Goal
what they requested (#PDUs according to the CQI reported), because
there was not enough resources (power, codes or processing)
Cost function C1 C1T = ρ x C1T-1 + (1 - ρ ) x (Nbits / Nbitsopt))
BTSCell
ρ = (2n-1)/2n with n = hsdpaSchedulerWeightingFactor
hsdpaResource

HSDPA
Proportional Fair: favor UEs that report a high CQI versus their averaged CQI to take benefit from
instantaneous good radio conditions vs. average conditions
Advantage: choosing UEs on radio conditions improvement will increase effective throughput like
for MAX C/I scheduler but at the same might allow to serve all UEs according to radio conditions
variations per UE
CQIinst is the latest CQI reported (considered before CQI BLER adjustment)
Drawback: UEs experiencing very good stable radio conditions might not be served
Alcatel-Lucent Proportional Fair: favor UEs that have less been served compared to what they should get
according to their reported CQI
Advantage: UE selection is a tradeoff between throughput optimization and equity among UEs
Nbits is the number of transmitted bits in the TTI
Nbitsopt is the number of bits the UE can transmit at the reported CQI

2.6 Scheduler iCEM
2.6.3 Schedulers using Cost Functions C1 and C2: C2
C2 = f(SPI weight, average CQI)
TC CQIAV
C2
CQIAV TC
SPI QIdN
ARP THP SPI
QIdM
ARP THP
WEIGHT TBSAV
TBSAV WEIGHT
THROUGHPUTN
THROUGHPUTM

HSDPA
SPI management only applies to Alcatel-Lucent and Proportional Fair schedulers and is not supported by the
other schedulers.
SPI is determined based on the combination of the UMTS Traffic Class, the Allocation/Retention Priority and
the Traffic Handling Priority.
The second cost function C2 is based on the priority of the QId (SPI), and mainly on the based credits
allocated to this SPI priority, and also on the average CQI in order to share the HSDPA radio capacity of the
cell between users so that the throughput of each QId is be proportional:
to the weight of the SPI,
to the transport block size of the averaged CQI reported by the UE.
The based credits assigned per SPI priority provide the relative weight given per priority. The absolute
value is not meaningful, only the ratio between priorities is important.
Ratio on throughputs may be subject to a certain tolerance (around 10%) and are not fully respected in case
there is no resource limitation for some UEs (to avoid wasting resources by artificially restraining some UEs
while other UEs suffer very bad radio conditions).

2.6 Scheduler iCEM
2.6.4 TFRC SELECTION
QId0 QId1 QIdN
TFRC:
CQI selected = TBS
3GPP Tables n HS-PDSCH
f (CQI, BLER, resources*)
Modulation
Min COST value
* Resources : Power, codes, MAC-hs buffer occupancy, MAC-d PDU size

HSDPA
Once a user is chosen to be scheduled according to its cost function, the scheduler selects for this user a
TFRC (transport block size, number of HS-PDSCH and modulation) based on the CQI selected.
CQI selected depends on CQI reported by UE, the BLER and also the available resources (power, codes,
MAC-hs buffer occupancy & MAC-d PDU size).
Note : The scheduler uses CQI reported by UE for scheduling and uses CQI selected for TFRC selection.

2 HSDPA Scheduler
2.7 Scheduler xCEM
UE Capabilities Available Power & Codes ACK/NACK/SNRMap,dB Previously Transmitted PDUs
Retransmissions First per Priority Queue

QId0 QId1 QIdN
New Transmissions
hsdpaSchedulerAlgorithmXcem
(HsdpaConf)
CRmax proportionalThroughput
Min COST value
CostCRmax = SW(u,q) . J(uq,) / CR(u,q) CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q)
Note : the two algos are the
same if QoS is disabled
(SW or SPIweight = 1) UE #1 UE #N
• power • power
• codes • codes
• number of bits • number of bits

HSDPA
With xCEM, two sheduler types are possible :

- proportionalThroughput allows a relative differentiation between users (based on SPI weight)
- CRmax allows a absolute differentiation between users
According to the 3GPP (X[R02]X), the UE has to report a CQI assuming a BLER 1st TX of 10%.
Contrary to iCEM, xCEM does not directly use the CQI. The received CQI information is mapped to SNR values (SNRMAP,dB) depending on UE
category. The TFRC selection is then based on a second mapping between this SNR and the Spectral Efficiency (SE). The SE defines the
number of bits per HS-PDSCH code per TTI that can be transmitted for a given symbol SNR and SF = 16 (assuming 10% MAC-(e)hs BLER) in
an AWGN channel.
The eligibility of the users is checked based on the number of HARQ processes already used by the user. Note that the 3GPP standard
supports only one priority queue and one HARQ process for each user to be used within one TTI. In case several HARQ processes are
ready for retransmission then priority is given to the process waiting the longest.
HARQ process can be selected for transmission or retransmission only if no ack/nack are expected.
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for GBR MAC-d flows when R ≥ serviceMinRate
CostpropTh = (1/(ServiceBFactor(u,q)*100)) * J(u,q) / CR(u,q) for GBR MAC-d flows when R < serviceMinRate(R = Nbr PDU (ACK) x PDU
size / TTI)
CostCRmax = SW(u,q) . J(uq,) / CR(u,q) for all MAC-d flow types
where
- SPIweight is given by the OAM parameter hsdpaSpiRelativeWeight
- Scheduling weight SW(u,q) allows to control the scheduling priority for each user u and queue q according to the measured MAC-d
Throughput R. This throughput R is defined as the averaged number of ACKed MAC-d PDUs times the PDU size divided by TTI duration to
get the bit rate. The scheduling weight can be controlled by the OMC parameters serviceMinRate, serviceMaxRate, serviceBFactor
and serviceKFactor.
- Job size J(u,q) represents the average throughput of the priority queue (this throughput is smoothed, using an exponential filtering, by
the OAM parameter hsdpaSchedulerWeightingFactorXcem for xCEM). The job size is calculated by the MAChs internally for each user
and queue
- Channel rate CR(u) is the spectral efficiency (SE) times the number of available HSDPA code
Note that the cost functions for PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
- with PropTh, all the relative weights hsdpaSpiRelativeWeight have to be set with the same value (the value 100 disables totally the
SPI management algorithm) or all the SPI have to be set with the same value (e.g. 0).
- with Crmax, the Scheduling Weight has to be equal to 1 by setting serviceBFactor to 1

2.7 Scheduler xCEM
2.7.1 SNR ESTIMATION FOR HS-PDSCH
Available
Power per
HS-PDSCH
code
QId0 QId1 QIdN
SNR (dB) of
1 HS-PDSCH
Min COST value

CQI
SNR MAP,dB
SNRdB = SNRMAP,dB + Pavail/HS-PDSCH - Pcpich – Γ + δ(ack,nack)

HSDPA
For the user selected from the ranking list, the scheduler estimates the SNR of one HS-PDSCH based on the
SNRMAP,dB derived from CQI and on the available power per HS-PDSCH code:
SNRdB = SNRMAP,dB + Pavail/HS-PDSCH – Pcpich – Γ + δ(ack,nack)
• SNRMAP,dB is the last SNR value mapped on CQI assuming a HSDSCH power of Pcpich + Γ (Γ being the
measurementPowerOffset/2 ).
• Pavail/HS-PDSCH is the power available per HS-PDSCH.
• δ(ack,nack) is a correction factor used to ensure that the 1st Tx BLER or residual BLER after N
transimissions is achieved. δ(ack,nack) is increased or decreased depending whether a ACK or a
NACK is received
This SNRdB is then mapped to the Spectral Efficiency (SE) and used for TFRC selection.
The SE defines the number of bits per HS-PDSCH code per TTI that can be transmitted for a given symbol
SNR and SF = 16 (assuming 10% MAC-(e)hs BLER) in an AWGN channel

2.7 Scheduler xCEM
2.7.2 TFRC SELECTION
SE = the number of bits per HS-PDSCH code per TTI
SE
SNR (dB) of
1 HS-PDSCH Look Up Table TFRC:
TBS
n HS-PDSCH
Modulation
Target : TBS / n HS-PDSCH ≤ SE with maximal TBS and minimal n HS-PDSCH

HSDPA
SE gives the number of bits per HS-PDSCH code per TTI that the user can receive for given RF conditions
and the available power. So, the xCEM scheduler will select from a look up table the TFRC (transport block
size TBS, number of HS-PDSCH codes nHSPDSCH and modulation). LUT is made such as the selected TFRC
corresponds to the higher TBS and the lower number of HS-PDSCH so that the spectral efficiency of this
TFRC is lower than the SE computed previously:
TBS / nHS_PDSCH ≤ SE with maximal TBS and minimal nHS_PDSCH
Modulation is selected in order to use resources most efficiently. If SE is low then QPSK is preferred,
whereas 16-QAM is used when SE is high and UE supports 16-QAM. This xCEM behavior (QPSK and 16-QAM
can be used whatever the number of HS-PDSCH codes) is related to the feature 34102, which introduces
this in iCEM.
Note that the TFRC selection takes into account:
the UE capability
the buffer occupancy of the selected priority queue
the number of available HS-PDSCH codes
the spectral efficiency SE

2.7 Scheduler xCEM
2.7.3 TFRC SELECTION Summary

HSDPA
This drawing summarizes the algorithm used by the xCEM to select the TFRC of a UE

2.7 Scheduler xCEM
2.7.4 QoS management for proportionalThroughput scheduler
hsdpaSchedulerAlgorithmXcem = proportionalThroughput
QId0 QId1 QIdN QIdx QIdy QIdw
Ranking prio.
Non GBR Mac-d flows GBR Mac-d flows

hsdpaSpiRelativeWeight
serviceBFactor
Throughput R
<
No serviceMinRate
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi Yes
(HsdpaConf)
serviceLowRate
(HsdschServiceParameterSet)
serviceMinRate = MAC-hs GBR - serviceLowRate

serviceLowRate
Non GBR or GBR with R>= serviceMinRate : CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q)
GBR with R< serviceMinRate : CostpropTh = (1/ServiceBFactor(u,q)*100) * J(u,q) / CR(u,q)
HSDPA
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for GBR MAC-d flows when
R ≥ serviceMinRate
CostpropTh = (1/ServiceBFactor(u,q)*100) * J(u,q) / CR(u,q) for GBR MAC-d flows when R < serviceMinRate
GBR Handling:
In the presence of GBR MAC-d flows, these flows will be served first as long as their GBR is not satisfied
(irrespective of their SPI), even if the throughput of non GBR MAC-d flows (and even with higher SPI)
must be reduced down to 0 kbps.
To determine if a GBR MAC-d flow has reached its GBR or not, MAC-(e)hs continuously monitors the average
throughput of the flow (using an exponential filtering based on
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi parameter). This averaging is needed since the
GBR has to be shown to hold over long-term (hundreds of ms to seconds) compared to the 2ms TTI.
The serviceMinRate used in this type of scheduler is not the equal to the serviceMinRate parameter value
but is calculated by as Mac-(e)hs GBR – serviceLowRate parameter.

2.7 Scheduler xCEM
2.7.5 QoS management for CRmax scheduler
hsdpaSchedulerAlgorithmXcem = CRmax
serviceMinRate serviceMinRate
serviceMaxRate QId0 QId1 QIdN
serviceLowRate non GBR Mac-d flow

serviceHighRate
serviceMaxRate
serviceBFactor
serviceKFactor
COST x SW
(HsdschServiceParameterSet)
Decrease OR Increase
MAC-hs GBR (NBAP) - serviceLowRate
COST
serviceLowRate
Throughput R
<
serviceMinRate
GBR Mac-d flow OR
Throughput R
>
serviceMaxRate
MAC-hs GBR (NBAP) + serviceLowRate
serviceHighRate
R< serviceMinRate Or R> serviceMaxRate : CostCRmax = SW(u,q) . J(uq,) / CR(u,q)

serviceMinRate <= R<= serviceMaxRate : CostCRmax = J(uq,) / CR(u,q)
HSDPA
With CRmax: for a given SPI, priority of the queue is increased (or decreases) by multiplying the cost
function by a Scheduling Weight (SW)
(SW) if the MAC-d throughput R is lower (or higher) than the parameter serviceMinRate (or
serviceMaxRate). The parameters serviceBFactor and serviceKFactor are shaping factors for increasing
and decreasing the priorities:
the larger the values for serviceBFactor and serviceKFactor the more the priority is decreased or
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
if serviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In
this case the priority of a user is neither decreased nor increased.
The Scheduling Weight is computed as follow:
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:

3 CQI & MAC-HS BLER Management

HSDPA

3.1 CQI Modification Principles
HS-DPCCH demodulation
and CQI decoding
isolate a deficient UE which never responds
(too many consecutive DTX detection)
HS-DPCCH detection
maintain an acceptable BLER
CQIreported on first transmission
CQI adjustment based on BLER
CQIprocessed
Scheduler
CQI update due to:

• Power limitation
• Codes limitation
• MAC-(e)hs buffer occupancy
• MAC-d PDU size
CQIselected

HSDPA
First level of CQI modifications is performed to take into account possible RL synchronization loss
detections, and the CQI defense mechanisms to handle DTX and BLER problems.
Second level of CQI modifications is performed by the NodeB Scheduler. It aims at dynamically aligning the
Transport Format with the current resources availability.
Transport formats always remain based on the CQI mapping tables. Two different CQI correspond
to different transport formats with the same power to reach the same performance level, but
could also correspond to two different powers with the same transport format. A step of 1dB is
considered to go from one CQI to the next one.
The transport format is determined according to the processed CQI, CQIprocessed. In case of a lack
of resources (codes or power), the applied CQI, CQIapplied, is then modified according to the
previous rule to take this into account. It is done in four steps:
power limitation management
codes limitation management
lack of MAC-d PDU in buffer
optimization of CQI according to MAC-d PDU size

3.2 HS-DPCCH detection based on CQI
RxDemodulation
(BTSEquipment)
NodeB
Initialisation
UE not scheduled
HSD_OUT_SYNC
NO YES
N successive
CQI detected?
M successive
NO
DTX detected?
YES
HSD_IN_SYNC
N=M=2
UE scheduled
(hard coded)
HSDPA
HS-DPCCH detection based on CQI is introduced in order to schedule UEs only when HS-DPCCH decoding is
reliable enough to get valid CQI information and correctly decode ACK/NACK.
This algorithm manages two states: HSDPA Synchronized and HSDPA-Not Synchronized.
The initial state is considered as not synchronized (HSD _OUT_SYNC), i.e. nothing has been
yet received on HS-DPCCH.
To acquire the synchronization on the HS-DPCCH (HSD_IN_SYNC), N successive CQI must be
detected.
When in HSD_IN_SYNC state, CQI are taken into account in the MAC-(e)hs. In case of DTX,
the last decoded value is kept.
If M successive expected CQI are not detected (DTX), the UE falls into the HSD_OUT_SYNC
state.
When in HSD_OUT_SYNC state, the UE is not scheduled. CQI still remains to be detected &
decoded in order to reactivate the UE if possible. If ACK/NACK is expected from previously
transmitted transport blocks, they must be decoded and taken into account for HARQ
process update. Pending retransmissions are nevertheless not transmitted and are stored
until the HSD_IN_SYNC state is back. Finally, during that state, no Capacity Allocation should
be sent to the RNC.
In case the CQI falls into an UL transmission gap (compressed mode), it must not be taken into account for
this algorithm, i.e. neither as DTX nor as detected.
When coming back into the HSD_IN_SYNC state, scheduler cost function must be reinitialized (both costs set
to respective lower cost of active QIDs).
The HS-DPCCH synchronization algorithm is activated thanks to the bit 1 of the RxDemodulation
parameter:
- bit 1 = 0 ⇒ ON - HS-DPCCH synchronization based on CQI is activated
- bit 1 = 1 ⇒ OFF - HS-DPCCH synchronization based on CQI is deactivated
This algorithm is activated by default. As the parameter is class 0, it then cannot be changed online.

3.3 HSDPA BLER as per 3 GPP
Category 6 UE CQI Mapping Table
CQI Value HS-PDSCH Number RLC Throughput Modulation PHS-DSCH = PP-CPICH + Γ + ∆(CQI)
0 out of range
1 1 0 kbps QPSK
2 1 0 kbps QPSK S oft CQ I vs C/I - P e de s tria n_a 1 RX

25
3 1 0 kbps QPSK
4 1 0 kbps QPSK
5 1 144 kbps QPSK
6 1 144 kbps QPSK 20
7 2 144 kbps QPSK
s oftCQI
8 2 288 kbps QPSK
9 2 288 kbps QPSK

15
10 3 432 kbps QPSK
11 3 576 kbps QPSK
12 3 720 kbps QPSK
13 4 864 kbps QPSK 10

-10 -8 -6 -4 -2 0 2 4 6 8 10
14 4 1008 kbps QPSK C/I (dB)
15 5 1296 kbps QPSK
16 5 1440 kbps 16-QAM
... ... ... ...
29 5 3024 kbps 16-QAM Target BLER ≤ 10%

30 5 3024 kbps 16-QAM

HSDPA
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/64-QAM).
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.

3.4 CQI adjustment based on BLER:
blerRangeBasedAlgo
bufferSize
nackNbMin hsdpaCqiBLERAdjustmentAlgo = blerRangeBasedAlgo
bufferSize
nackNbMax
(HsdpaConf)
(static)
1 2 buffer is full
3
AC K 4
ACK
AC CK
NA
K NbNACK <= Yes
CQIprocessed = CQIreported+1
nackNbMin ?
1st Transmission No
ACK/NACK
Buffer
NbNACK > Yes
CQIprocessed = CQIreported-1
nackNbMax ?
No
empty the buffer

HSDPA
A CQI BLER adaptation algorithm has been introduced to compute an offset to apply on reported CQI in
order to keep the BLER on first transmission within an acceptable range (typically between 0 and 30%).
hsdpaCqiBLERAdjustmentAlgo parameter is set to blerRangeBasedAlgo to activate this mode of
CQI adjustment.
Indeed field measurements have shown that a better user throughput could be achieved at a MAC-ehs BLER
value higher than the 10% 3GPP value (typically between 20 to 30%).
It is continuously updated with the following rules:
A buffer of fixed size (= BufferSize) is created for each UE to compute the BLER.
Anytime an ACK/NACK is received related to the 1 st transmission of a MAC-(e)hs block, the buffer is
updated to store this information. The buffer is filled in a cyclic way.
When the buffer is full, the number of NACK (NackNb) indication within the last BufferSize ones is
computed. The offset is then updated according to the following rules:
If NackNb ≤ NackNbMin, the system is too good and bandwidth efficiency could be improved
(throughput increase and/or power reduction). ∆CQI is increased by 1 and the buffer is
reinitialized.
If NackNb > NackNbmax, the BLER is too high. Performances are then degraded. ∆CQI is
decreased by 1 and the buffer is reinitialized
In all other cases, the system is considered in its stationary state and then behaves
satisfactorily. ∆CQI is not updated and the buffer is not reinitialized.

3.5 CQI adjustment based on BLER:
OuterLoopLikeAlgorithm
hsdpaCqiBLERAdjustmentAlgo = OuterLoopLikeAlgorithm
DeltaCqi
DeltaCqicur
0 #CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
NACK NACK ACK

DeltaCqiCur
0 #CQIreported
- hsdpaBLERStepSize
hsdpaBLERTargetUpperLimit
hsdpaBLERStepSize x
-5
100 - hsdpaBLERTargetUpperLimit

HSDPA
In UA05, the purpose of the feature “HSDPA performance enhancements – Configurable CQI adjustment
according to BLER target algorithm” is to put the parameters of this algorithm at the OMC so that the
operator can tune its BLER target.
hsdpaCqiBLERAdjustmentAlgo parameter is set to outerLoopLikeAlgo to activate this new mode of CQI
adjustment.
BLER Target algo (outerLoopLikeAlgo) brings gain in specific cases because his setting (BLER target
value) depends on several factors: number of simultaneous UE, UE cat., CQI distribution.
That’s why UA4.2 algo is recommended because his performances are good in most cases.
hsdpaBLERTargetUpperLimit: defines the expected BLER target
hsdpaBLERObservationWindow: corresponds to the update period of the CQI offset
hsdpaBLERStepSize: it corresponds to the step applied upon reception of NACK. In case of ACK, the step is
a function of this parameter and of the BLER target.
All these parameters are defined per BTSEquipment -> BTSCell -> HsdpaConf object.

3.6 CQI adjustmt based on BLER: Dynamic BLER
Adjustment
hsdpaCqiBLERAdjustmentAlgo = dynamicOuterLoopAlgo
DeltaCqi
DeltaCqicur
0 #CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
NACK NACK ACK

DeltaCqiCur
0 #CQIreported
- hsdpaBLERStepSize
hsdpaBLERStepSize x hsdpaBLERTargetXXLimit
upStepXXBLERTarget =
-5 100 - hsdpaBLERTargetXXLimit
Low Medium High

HSDPA
iCEM:
In UA05.0, the purpose of the feature “HSDPA performance enhancements – Configurable CQI adjustment
according to BLER target algorithm” is to put the parameters of this algorithm at the OMCB so that the
operator can tune its BLER target.
In UA06.0, the algorithm of CQI adjustment according to BLER is further enhanced by supporting multiple
BLER targets (configurable via OMC-B) and auto selection of one of these targets depending upon the
average CQI and the UE speed.
The tuning of the algorithm is made possible though the following new and older release parameters:
hsdpaBLERTargetUpperLimit: defines the Upper BLER target.
hsdpaBLERTargetLowerLimit: defines the Lower BLER target.
hsdpaBLERTargeMediumLimit: defines the medium BLER target.
hsdpaBLERObservationWindow: corresponds to the update period of the CQI offset
hsdpaBLERStepSize: it corresponds to step in dB applied upon reception of NACK. In case of ACK,
the step is a function of this parameter and of the BLER target.
hsdpaCqiBLERAdjustmentAlgo: this parameter is used to deactivate the feature:
0: deactivated.
1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no possible
parameterization, for iso-functional introduction.
2: outerLoopLikeAlgo. It corresponds to the UA05.x algorithm, allowing a single BLER target.
3: dynamicOuterLoopAlgo. It corresponds to the UA06.0 evolution, with dynamic BLER target
switching.

3.6 CQI adjustmt based on BLER: Dynamic BLER Adjustment
3.6.1 CQI adjustment step as a function of the CQI
range
Start
Nack DTX
Ack/Nack?
Ack End
hsdpaAdjustBLERToChannelVariation
deltaCqiCur -= downStep
ueSpeed ≤ ueSpeedThd
Yes And No
adjustToChVar = True
Or
cqiAverage ≥ cqiThdHigh
deltaCqiCur += upStepLowBLERTarget Yes No

cqiThdLow < cqiAverage
deltaCqiCur += upStepMediumBLERTarget deltaCqiCur += upStepHighBLERTarget

HSDPA
Better throughput will be achieved:

with High Target BLER for high UE speed and low CQI
with Low Target BLER for low UE speed or high CQI

3.7 CQI adjustment based on BLER : XCEM case
hsdpaCqiBLERAdjustmentAlgorithmXcem
constBLERTarget
dynamicHarqTxTarget
outerLoopLikeAlgo algorithm
hsdpaBLERTargetUpperLimitXcem
See iCEM description

HSDPA
xCEM:
With xCEM, two algorithms have been implemented to control the MAC-(e)hs BLER:
- constBLERTarget
- dynamicHarqTxTarget
Note that the MAC-(e)hs BLER estimation is still based on ack/nack information reported on HS-DPCCH.
With UA05.1 xCEM, MAC-(e)hs BLER is managed as with iCEM outerLoopLikeAlgo algorithm, except that the
offset δ(ack,nack) is applied on SNR of one HS-PDSCH instead of directly on CQI. This calculated SNR is then
mapped to a spectral efficiency and used for TFRC selection.
Concerning the parameter hsdpaCqiBLERAdjustmentAlgorithmXcem, the value activated in UA05.1.1 and
the value constBLERTarget in UA06.0 activate the same algorithm.
The value dynamicHarqTxTarget has not to be selected since this algorithm is not supported.
The value deactivated inhibits the CQI Adjustment based on BLER but is not recommended.

4 HSDPA Codes Management

HSDPA

4.1 HSDPA Codes Allocation Overview
isHsPdschDynamicManagementAllowed isHsxpaR99ResourcesSharingOnCellAllowed
isCellHsPdschDynamicManagementActive hsdpaCodeTreeManagementActivation
Static allocation Dynamic allocation Fair sharing allocation
R99 traffic
R99 reservation
R99 & HSDPA
Free R99 maxNumberOfHsPdschCodes reservation
minNumberOfHsPdschCodes
HSDPA reservation HSDPA traffic
HSDPA Codes are HSDPA Codes are HSDPA Codes are

fixed & sent by RNC dynamic & sent by Autonomously defined
to Node B RNC to Node B by Node B according to
R99 traffic
HSDPA

4.2 Fair Sharing
True
isGbrOnHsdpaAllowed « HS-DSCH required power » for GBR (PS Str) + minBr (PS I/B)
False « HS-DSCH required power » for minBR (PS I/B)
GBR On GBR info sent to NodeB (GBR or minBR)
hsdschReqPwFilterCoeff
FS On « HS-DSCH required power » hsdschReqPwReportingPeriod
(NBAPMeasurement)
hsdpaCodeTreeManagementActivation
(BTSEquipment)
OVSF I/B MinBR
STR GBR
TC/ARP/THP isHsxpaR99ResourcesSharingOnCellAllowed
Used isDlPowerSelfTuningForPsIbOnHsdpaEnabled
(FDDCell)
NodeB dynamic OVSF codes management:

HSDPA RNC
Power CAC Monitor the DL OVSF code tree occupancy
Used Determine the codes available for HS-
PDSCH scheduling
Initial Radio Resources
(power, codes)
Reconfigure the H-BBU accordingly via a
new internal message
HSDPA
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 other criterion such as RF power.

4.3 Fair Sharing - RAN Model
RNC NodeB FDDCell Parameter for ‘GBR on HSDPA’ in UA06.0
isHsxpaR99ResourcesSharingOnCellAllowed Parameter for ‘Fair Sharing’ in UA06.0

isDlPowerSelfTuningForPsIbOnHsdpaEnabled
hsxpaR99ResourcesSharingId
RadioAccessService
isGbrOnHsdpaAllowed
isMultiServiceWithDchStrAndHsDschIbAllowed
TrafficClassBasedQos ArpBasedQos ThpBasedQosl

minBrForHsdpa
DedicatedConf MeasurmentConfClass NBAPMeasurment

hsdschReqPwFilterCoeff
hsdpaReqPwReportingPeriod
HsxpaR99ResourcesSharingCellClass
HsdpaRncConf
minHsDschReservationForCac
hsdpaTransportEbrCorrectiveFactor
dlTxPowerEstimation
transportTypeSelectionTransferDelayThreshold
ovsfCodesThroughputQpskUe
ovsfCodesThroughput16QamUe
reservationFactorOnCodesForGbrTraffic
initialActivityFactorForIb

HSDPA

4.4 Dynamic Code Tree Management
SF256
SF128
SF16
SF32
SF64
SF4
SF8
0 0
0 Pre-emption/Re-allocation is performed on
1 configuration line (SF16 always for HS-PDSCH)
0
2
1
3
Monitoring is performed on monitoring line
4
(SFx is operator choice between SF16 and SF256)
2
5
1
6
3 isHsPdschDynamicManagementAllowed
7 RNC
= True
8
4 RadioAccessService
9
2 isCellHsPdschDynamicManagementActive
10
5 HsdpaCellClass = True
11
BTSEquipment
12 HsPdschDynamicManagement
6 hsdpaCodeTreeManagementActivation
13
3 = False
14
7 127 spreadingFactorLevelForOvsfMonitoring
15

HSDPA
The monitoring line is set by default to SF16 in order to facilitate the monitoring and tuning of Dynamic DL
Code Tree Management parameters.
DCTM and Fair Sharing algorithms are totally incompatible.
Then:
• Prior to DCTM activation, Fair Sharing (RNC and NodeB algo) has to be disabled
• Prio to Fair Sahring activation (RNC and NodeB algo), DCTM has to be disabled

4.4.1 HS-PDSCH OVSF Codes Allocation
RNC
SF4
free
SF8 RadioAccessService
SF16
SF32
HS-PDSCH
HsdpaCellClass
SF64
SF128 cmCH numberOfHsPdschCodes

SF256 HS-SCCH
Cell Setup
numberOfHsScchCodes
SF4
R99 free maxNumberOfHsPdschCodes
SF8
SF16
SF32
HS-PDSCH
SF64
SF128 cmCH
SF256 HS-SCCH
Live Cell

HSDPA
The number of HS-SCCH is fixed due to the numberOfHsScchCodes parameter.

The number of HS-PDSCH codes which are reserved at cell setup is equal to numberOfHsPdschCodes
parameter.
If the Dynamic DL Code Tree Management feature is activated then:
minNumberOfHsPdschCodes represents the minimum number of OVSF codes always reserved for
HSDPA traffic in the cell whatever the R99 DCH traffic value and even if the current HSDPA is null
maxNumberOfHsPdschCodes represents the maximum number of OVSF codes that can be
allocated for HSDPA traffic in the cell whatever the R99 DCH traffic value.

4.4.2 HS-PDSCH Codes Preemption / Reallocation
Free R99 DCH Codes
minTimeBeforeReallocationOfHsPdsch
threshCodesToTriggerReallocation
numCodesForDchAfterReallocation
numCodesForDchAfterStealing
threshCodesToTriggerStealing
time
Number of HS-PDSCH codes HS-PDSCH HS-PDSCH HS-PDSCH
preemption preemption reallocation
maxNumberOfHsPdschCodes
time

HSDPA
Dynamic DL code tree management consists in monitoring the DCH code tree load towards a code margin
defined by the customer.
This is a preventive solution to avoid potential DCH call drops due to an instantaneous unavailability of
codes for DCH.
When Dynamic DL Codes Tree Management for HSDPA is used the number of HS-PDSCH codes reserved for
HSDPA traffic may be updated dynamically according the number of free OVSF codes.
.

4.4.3 DCTM – RNC RAN Model
RNC
NodeB
RadioAccessService
FDDCell
isHsPdschDynamicManagementAllowed
HsdpaCellClass hsdpaCellClassId hsdpaResource
isCellHsPdschDynamicManagementActive
HsPdschDynamicManagement
minNumberOfHsPdschCodes maxNumberOfHsPdschCodes
numCodesForDchAfterReallocation numCodesForDchAfterStealing
threshCodesToTriggerReallocation threshCodesToTriggerStealing
spreadingFactorLevelForOvsfMonitoring minTimeBeforeReallocationOfHsPdsch

HSDPA
The parameter isHsPdschDynamicManagementAllowed activates the feature at RNC level for all the
NodeB.
In order to activate the feature only on a limited number of NodeB, activation at FDDCell level is requested
thanks to isCellHsPdschDynamicManagementActive parameter.
Parameters Rules:
To have normal feature behavior:
numCodesForDcfhAfterReallocation <= threshCodesToTriggerReallocation
numCodesForDchAfterStealing >= threshCodesToTriggerStealing
To avoid ping-pong:
numCodesForDchAfterReallocation >= threshCodesToTriggerStealing
numCodesForDchAfterStealing <= threshCodesToTriggerReallocation
To be in line with monitoring line
numCodesForDchAfterReallocation <= spreadingFactorLevelForOvsfMonitoring
numCodesForDchAfterStealing <= spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerReallocation <= spreadingFactorLevelForOvsfMonitoring
threshCodesToTriggerStealing <= spreadingFactorLevelForOvsfMonitoring
To be coherent at cell setup
minNumberOfHsPdschCodes <= numberOfHsPdschCodes
numberOfHsPdschCodes <= maxNumberOfHsPdschCodes

4.4.4 DCTM – NodeB RAN Model
BTS Parameter for ‘GBR on HSDPA’ in UA06.0
Parameter for ‘Fair Sharing’ in UA06.0
BTSEquipment
hsdpaCodeTreeManagementActivation
BTSCell
HsdpaConf HsdschServiceParameterSet
iCEM xCEM
hsdpaGbrNbNeededTtiForgettingFactor Used by serviceFilterFactor
hsdpaGbrNbUePerTtiForgettingFactor MAC-(e)hs scheduler serviceHighRate
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi serviceLowRate

HSDPA
The feature Fair Sharing and Dynamic Code Tree Management can not be activated in the same time in a
cell because they are incompatible. Before activating one, the other has to be deactivated.
The parameter hsdpaCodeTreeManagementActivation activates the NodeB part of the Fair sharing
feature:
- If True, HS-PDSCH code are determined by CCM and HBBU is dynamically reconfigured.
- If False, HS-PDSCH codes are determined by the RNC and PSCR is directly applied.
Note that the CCM must monitor the code occupancy all the time whatever the feature activation.

5 HSDPA Power Management

HSDPA

5.1 HSDPA DL Power Reservation at RNC
RNC
RadioAccessService PMaxCell
SHO margin
HsdpaCellClass
PmaxHspa
PminHsdpa
minimumPowerForHsdpa
OCNS (opt.)
PminHsdpa = CCCRNC
PMaxCell - minimumPowerForHsdpa
<unset> PmaxHspa =
when Fair Sharing is enabled PMaxCell - maxHspaPowerOffset

HSDPA
It is possible to reserve a minimum power for HSDPA noted PminHsdpa that is subtracted from the power of
the DCH pool. This power is defined through the minimumPowerForHsdpa parameter such as:
The recommendation is that no power has to be reserved for HSDPA. Two solutions are possible:
1. minimumPowerForHsdpa = 50dB so that the minimum power reserved for HSDPA is very low (ex :
PminHsdpa = PMaxCell – minimumPowerForHsdpa = 45dBm – 50dB = -5dBm = 0.3mW)
2. minimumPowerForHsdpa = unset so that no minimum power is reserved for HSDPA.
In UA06.0, the maximum power that the RNC can allocate to HSxPA channels is defined by:
PmaxHspa = PMaxCell – maxHspaPowerOffset
The RNC sends this available power by setting the « HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-
HICH Total Power » IE in the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message as
Pmaxcell – maxHspaPowerOffset.
if maxHspaPowerOffset =0, the Node B can use all the available remaining power for HSDPA
transmission
if maxHspaPowerOffset >0, the operator has the ability to reserve an amount of power
which cannot be used by HSDPA

5.2 HSDPA DL Power Available at NodeB – iCEM case
PMaxCell
BTSEquipment power available
PRemain for
HSDPA traffic
BTSCell
PDCHmargin DCH margin
NodeB
HsdpaConf
E-DCH
DCH
dchPowerMargin
PTotNonHsdpa
- PCPICH OCNS (opt.)
CCCNodeB
PDCHmargin = dchPowerMargin x
(PTotNonHsdpa- PCPICH) CPICH
PTotNonHsdpa =
PDCH + POCNS + PCCC + PE-DCH
Available power for HSDPA
PHsdpa = min (Premain, PmaxHspa)

HSDPA
In a HSDPA cell, a new margin is introduced in order to anticipate power fluctuation on DCH channel mainly
due to power control and then avoid PA overload: the dchPowerMargin.
HSDPA channels can not use this margin. If the power for DCH calls exceeds the DCH power margin
then HSDPA will reduce his power to provide DCH calls with power resource.
dchPowerMargin parameter can be tuned so that the DCH margin is large enough to manage the
power fluctuation on the DCH and so that not too much unnecessary power is reserved.
Note that the common channel consumption at NodeB level is lower than at RNC level due to activity factor
consideration.
Flexible power management feature consists in using for HSDPA all the remaining power left by dedicated
and common channels according the RNC upper limit.
Then, the power available for HSDPA is defined by: PHsdpa = min(PRemain, PmaxHspa) where
PRemain is the remaining power available for HSDPA from the NodeB perspective
PmaxHspa is the maximum power that can be allocated for HSDPA from an RNC perspective

5.3 HSDPA DL Power Available at NodeB – xCEM case
PMaxCell
BTSEquipment
PRemain power available
for
BTSCell HSDPA traffic
PDCHmargin DCH margin
NodeB
HsdpaConf
E-DCH
DCH
dchPowerMargin
PTotNonHsdpa
- PCPICH OCNS (opt.)
CCCNodeB
PDCHmargin = dchPowerMargin x
(PTotNonHsdpa- PCPICH) CPICH
Available power for HSDPA PTotNonHsdpa =

PHsdpa = min (Premain, PmaxHspa) PDCH + POCNS + PCCC + PE-DCH
Premain = max(hsdpaAmpUsage.Pmax hsdpaAmpUsage

– PTotNonHsdpaWithMargin; X PMaxCell
hsdpaMinAmpUsage (BTSCell->HspaConf)
hsdpaMinAmpUsage.Pmax)
(BTSCell->HspaConf)
HSDPA
Before starting to schedule users, scheduler needs to know the total power it can use for HSDPA according
to R99 traffic usage. As with iCEM, total power usable by the scheduler may be limited by the RNC
(PmaxHsdpa).
At nodeB level, with xCEM, a minimum percentage of power for HSDPA can be defined through the
parameter hsdpaMinAmpUsage. A percentage of the cell power can also be taken into account to compute
the remaining power (power not used by non HSDPA channels) through hsdpaAmpUsage. Then, the total
power usable for HSDPA is:
PHSDPA total = min(max(hsdpaAmpUsage.Pmax – PTotNonHsdpaWithMargin; hsdpaMinAmpUsage.Pmax);
PmaxHsdpa)
where:
- PTotNonHsdpaWithMargin is the power used by non HSDPA channels with DCH margin.
- Pmax is the maximum power of the cell.
- PmaxHsdpa is maximum power for HSDPA computed by RNC and sent to NodeB through NBAP message.

5.4 Dynamic PA Power Sharing R99/HSPA Carriers
100%
isPowerPoolingActivated
paRatio (F2)
paRatio (F2)
(FDDCell)
HSDPA
HSDPA paPoolingActivation
(BTSEquipment)
PA Power Ratio
GBR,
R99
Fixed
GBR, maxTxPower (Fx) ≤ Max Dl Power Capability (Fx)
Power partitioning
paRatio (F1)
paRatio (F1)
not used R99

Max Power Amplification [dBm]
maxPowerAmplification
+10*log( paRatio
paRatio (Fx)/100)
R99 R99 -Tx Losses [dB]
0%
UA05 UA06:
: PA power sharing
Static Dynamic PA power sharing
between F1 and F2 carriers. between F1 and F2 carriers.
paRatio parameter must be set paRatio can be set as follows:
as follows:
paRatio (F1) + paRatio (F2) ≤ 100% paRatio (F1) + paRatio (F2) > 100%
False True
Power Sharing Activated ?

HSDPA
Multi-carrier PA Power Pooling from UA06:

Aim:
Applies to the case where NodeB Power Amplifier (PA) is shared between two carriers —F1* for R99
traffic and F2* for HSPA(+R99) traffic—
* F1: Carrier with HSDPA disabled * F2: Carrier with HSDPA enabled
Optimize usage of available DL power, by allowing dynamic PA power sharing between F1 and F2 ⇒
Improve HSDPA performance
Guarantee that this feature has no impact on R99 traffic
Main characteristics:
Maximum PA power ratio for each carrier is fixed (as in UA05):
DL power allocated to a given carrier cannot exceed maximum allowed for this carrier.
Max PA power ratio for each carrier can be set so that sum of ratios exceeds 100%:
If, on F1 (R99 carrier), a part of DL power is not used,
it is possible to reallocate this power to F2 (HSPA carrier).
Feature impact on R99 power allocation:
With this feature HSDPA traffic may use an important part of PA power
But, R99 traffic has full priority for power allocation (as in UA05)
Feature impact on DL CAC and DL iRM (both mechanisms apply to R99 traffic):
DL CAC and DL iRM are based on max PA power ratio set for the considered carrier.
F1: No impact (since R99 traffic has full priority for power allocation)
F2: When this feature is activated, if high traffic on F1, currently available power on F2
may be lower than value indicated by max PA power ratio for F2.
5.4 Dynamic PA Power Sharing R99/HSPA Carriers
5.4.1 Impact on DCH DL CAC and DL iRM
100%
paRatio (F2)
paRatio (F2)
HSDPA UA06
HSDPA P traffic (F2)
= (Max Tx Power (F2) – Min Pw Hsdpa (F2))
PA Power Ratio
GBR, / (1+ paOverbookingRatio

paOverbookingRatio /100)
R99
Fixed - P CCC (F2) x Activity Factor Cch
activityFactorCcch
partitioning GBR, – P E-DCH - P OCNS
Power
paRatio (F1)
R99
paRatio (F1)
not used
P_traffic
R99 R99
= Max (R99+HSDPA) traffic allowed
0%
UA05
P traffic(F2)
= Max TxPower(F2)
– Min Pw Hsdpa(F2)
- P CCC(F2) x Activity Factor Cch
- P E-DCH-P OCNS

HSDPA
In UA06, when PA power pooling feature is enabled, Ptraffic does not correspond to the actual amount
of available power due to power overbooking. Potentially, if the same definition as in UA05 is kept, a
CAC failure may occurs whereas some Power is still available.
There is only one threshold for call admission (Ptraffic) that is common to DCH and HS-DSCH traffics.
For R99 users, the power cell color that is used for iRM is modified to include the power used by the HS-
DSCH users
In UA05 the Activity Factor CCCH is hard coded ) 66%. In UA06 it is a customer parameter.

5.5 HSDPA Power Distribution
PMaxCell
HS-DSCH
PHsdpa
HS-SCCH
DCH margin
NodeB
E-DCH
DCH
OCNS (opt.)
CCCNodeB
Question : Calculate PHSDPA if PHS-SCCH is 20dBm & PHS-DSCH is 15 dBm ?

HSDPA
The available power for HSDPA PHSDPA is shared between HS-SCCH and HS-DSCH channels.
A HSDPA user is scheduled only if there is enough power for HS-SCCH therefore if the following condition is
fulfilled: PHS-SCCH < PHSDPA.
If not, the scheduler will try to schedule another user.

5.6 HS-SCCH Power Control for iCEM
BTSEquipment
PHS-SCCH = PP-CPICH + hsscchPcOffset [CQI]
BTSCell
HsdpaConf
HS-S
C CH
P-CP
ICH
+
distance
0 dB CQI
Power
Offset
HS-SCCH to P-CPICH 1–7 0 dB
Power Offset 8–9 -3 dB
- 10 – 12 -5 dB
13 – 30 -8 dB

HSDPA
The aim of this feature is to adjust, according to the radio condition, the power allocated to HS-SCCH in
order:
to save power for data or other UE
to have a good detection probability of HS-SCCH
There is no true power control mechanism on HS-SCCH and a CQI-based power control procedure is
implemented instead.
A direct relation between the quality of DL radio conditions and the amount of power to be allocated to
the HS-SCCH is used. The worst the DL radio conditions, the smallest the CQI and the greatest the power to
be allocated to the HS-SCCH. The principle then consists in associating a power offset (relative to P-CPICH
power) to the HS-SCCH depending on the reported CQI value. The power allocated for HS-SCCH is derived
from the CQI reported by the mobile in order to adapt the transmission power to radio conditions.
This is configured in a table that gives a power offset relative to P-CPICH for each CQI group.
The hsScchPcOffset parameters depend on the CQI reported by the UE to the NodeB.
However the UE computes his CQI according to the measurementPowerOffset parameter which defines the
reference power.
Then hsScchPcOffset parameters have to be linked to a measurementPowerOffset value. If the
measurementPowerOffset increases of 1dB, the hsScchPcOffset table has to be shifted of 1 unit.

5.7 HS-SCCH Power Control for xCEM
BTSCell
PHS-SCCH = PP-CPICH + Γ - f (CQI) + Constant + hsscchSnr
HsdpaConf
measurementPowerOffset
HS-S SNR =
C CH
hsscchSnr
HS-SCCH
P-CP
ICH
HS-SCCH to P-CPICH
Power Offset +
+2 dB
distance
0 dB
-8 dB
-
HSDPA
With xCEM, the transmit power of HS-SCCH for each scheduled user is calculated so that the SNR of the HS-
SCCH at UE side shall be equal to hsscchSnr
Note that for the first implementation of the xCem, the recommendation for hsscchSnr was 5dB in order to
avoid a too low HS-SCCH power for high CQI since no minimum power was defined. Today, a minimum
power is defined for HS-SCCH (see below), allowing to reduce the value of hsscchSnr.
The computation of the HS-SCCH power is based on the most recent SNRMAP,dB from CQI �� SNR mapping
for each user, taking into account that HS-SCCH uses an SF128 :
PHS-SCCH = hsscchSnr + PP-CPICH + Γ – SNRMAP,dB – 10.log10(128/16) + 5dB
Where:
- PP-CPICH is the transmitted power of the P-CPICH (in dBm).
- Γ is the measurement power offset.
Note that :
- the maximum value for HS-SCCH power is P-CPICH power + 2dB
- the minimum value for HS-SCCH power is P-CPICH power - 8dB

5.8 HS-PDSCH Power for iCEM - 1st Transmission
CQI selected by NodeB CQI reported by UE
Power Adjustment
CQI rep. <> CQI sel. ? YES

Adjust Power
RLC
∆ALU CQI = ∆ dB Throughput Available
Power
NO
OK
RadioAccessService
PHS-DSCH = PP-CPICH + Γ + ∆(CQI)
HsdpaUserService measurementPowerOffset PHS-PDSCH

=
PHS-DSCH
∆ 3GPP(CQI, UEcategory) + ∆ ALU(CQIselected - CQIreported) nHS-PDSCH

HSDPA
Power is dynamically allocated to HSDPA users every TTI (2 ms). The power that can be used for HSDPA
corresponds to the power left after dedicated and common channels have been served.
Once a user has been chosen to be scheduled at the next TTI, the MAC-(e)hs scheduler checks that there is
enough remaining power for the HS-SCCH. If it is not the case then it tries to schedule another user.
After HS-SCCH power has been allocated, the scheduler computes the remaining power that can be used for
HS-DSCH. The power allocated to HS-DSCH depends on the CQI reported by the UE and is evenly shared
among the number of OVSF codes.
If there is not enough power for this CQI then the scheduler may use a lower CQI with lower power
requirements (so the user will not be served with the maximum throughput it can expect from his radio
conditions).
Once a user has been scheduled, the scheduler tries to serve another user in the same TTI with the
remaining power, if there is still a free HS-SCCH power for this TTI.
The reasons why the HS-DSCH power may be reduced compared to the one requested by the UE (CQI
reported):
Not enough remaining power
Not enough remaining HS-PDSCH codes
Not enough Mac-PDUs left to send
Not enough H-BBU processing resources
The the HS-DSCH power is equally distributed over all HS-PDSCH codes used to send the Mac-(e)hs block to
the UE.

5.9 HS-PDSCH Power for iCEM - Retransmissions
UE selected
(retransmission nb > 0)
UE is scheduled with
Transmitted Pwr =
1st Tx power + Power_offsetdB
(CQI1st – CQIret)xStep – Const
harqType ……WithPowerAdaptation
(hsdpaConf)

HSDPA
When an error occurs, the same AMC is applied for retransmissions (same transport block size, number of
HS-PDSCH codes and modulation).
In UA05, the purpose of this feature is then to adapt the power of retransmissions to new radio conditions,
in order to improve decoding probability while saving power when possible. In case of erroneous CQI
decoding for the initial transmission, it also allows to recover retransmissions.
A power offset with respect to initial transmission is then computed and depends on CQI variation or
retransmission index. It is a linear function of the CQI difference:
Power_offsetdB = (CQI1st – CQIret)*Step – Const
Step and Const are constants values provided by studies are: Step = 0.5, Const = 3
“Step” is positive, it helps handling the erroneous CQI and allows consuming right power according
to new conditions.
“Const” illustrates the gain brought by redundancy versions recombining and should be positive; a
negative value could also be set to enforce first retransmission to be decoded while consuming
maybe unnecessary power.
This feature can be used with any HARQ Retransmission type thanks to harqType:
MIRWithPowerAdaptation, PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation.
Note : for xCEM, all available HSDPA power is used and shared between the different users. So, we do not
need this feature, which is valid for iCEM, as iCEM uses power for HSDPA according to a dedicated formula.

5.10 HS-PDSCH Power for xCEM
PMaxCell
HS-DSCH (UE2)
PHsdpa – PHS-SCCH (UE1) PHsdpa-New
PHS-PDSCH available (UE1) =
NHS-PDSCH HS-SCCH (UE2)
PHsdpa
HS-DSCH (UE1)
PHsdpa-New – PHS-SCCH (UE2) HS-SCCH (UE1)

PHS-PDSCH available (UE2) = DCH margin
NHS-PDSCH-New
E-DCH
DCH
NHS-PDSCH = total number of codes OCNS (opt.)

= Min (Cell configured codes, UE1 capability + UE2 capability)
CCCNodeB
NHS-PDSCH-New = NHS-DPSCH – nHS-PDSCH (UE1)
nHS-PDSCH = UE1 codes
Available HSDPA codes
PHSDPA-New = PHSDPA – (PHS-SCCH (UE1) + PHS-DSCH (UE1)

HSDPA
The SNR estimation of one HS-PDSCH depends on the available power for one HSPDSCH.
Assuming that the power is uniformly distributed over all codes (NHS-PDSCH) that are available for HSDPA, the available
power for one HS-PDSCH (for user u from the ranking list) is:
PavailableHS-PDSCH(u) = (PHSDPA – PHS-SCCH(u)) / NHS-PDSCH
Where:
- PHSDPA is the power that is available for HSDPA
- PHS-SCCH(u) is the allocated power for HS-SCCH channel of user u
- NHS-PDSCH is the number of HS-PDSCH codes computed as below.
If more than one user to be scheduled for the next TTI

then NHS-PDSCH is equal to the total number of HS-PDSCH codes (Ntotal).
Else
NHS-PDSCH is the minimum between the total number of HS-PDSCH codes and the UE capability (Nue capability) in other
words, the maximum number of HS-PDSCH that a UE of a given category can manage: NHS-PDSCH = min(Ntotal; Nue capability)
where
- Ntotal = min(Nconfigured; SumNue capability)
and:
- Nconfigured is the number of HS-PDSCH codes configured (internal or external PSCR message)
-SumNue capability is the sum of the UE capability of the numberOfHsScchCodes first users at the top of the ranking list of
the previous TTI.
The SE defines the number of bits per HS-PDSCH code per TTI that can be transmitted at a given radio condition.
Note : for xCEM all available HSDPA power is used and shared between the different users each TTI. So, there is no
waste of power.

5.11 Exercise
PMaxCell
numberOfHsPdschCodes = 15
numberOfHsScchCodes = 2 HS-DSCH (UE2)
PHsdpa-New
measurementPowerOffset = 7 dB
PHSDPA = 30W HS-SCCH (UE2)
PHsdpa
PHS-SCCH (UE1) = 3W & PHS-SCCH (UE2) = 2W
nHS-PDSCH (UE1) = 5 & nHS-PDSCH (UE2) = 4 HS-DSCH (UE1)
PCPICH = 33 dBm
∆(CQI) = 0 HS-SCCH (UE1)
hsdpaFullPowerUsage = false DCH margin
E-DCH
Calculate PHSDPA (UE1) & PHSDPA (UE2) with iCEM & xCEM
DCH
OCNS (opt.)
CCCNodeB

HSDPA

5.12 HSDPA Full Power Usage
iCEM Activation* :
hsdpaFullPowerUsage
(HSDPAConf)
Raw HS-DSCH power

Mac-d queues selected
for the next TTI scheduling
Increase MCS by +1dB/CQI until: QId0 QId1 QIdK

- no more power
- no more HS-PDSCH codes
- max MCS reached
+
priority of QIdz(UEX,SPIY)
-
remaining yes Select QIdz for the next scheduling
Power ? in priority order
no
Schedule Data
(*) the equivalent xCEM feature is supported by default

HSDPA
Once all flows have been selected for the TTI if some power remains unallocated, with the feature “HS-
DSCH power adjustment evolutions” it can be redistributed to the UE that have been selected to try to
increase their transport block size (higher MCS using the rule +1dB/CQI). This is described later in this
chapter.
This feature is specific to iCEM. xCEM/OneBTS already implements a mechanism to use all the power that is
available for HSDPA.
This features introduces a mechanism to redistribute the remaining power (after MAC-d flows have been
selected for scheduling in the next TTI) in order to use power efficiently.
The activation of this feature is controlled by hsdpaFullPowerUsage. When this feature is not active the
MAC-(e)hs scheduler allocates at most Pcpich+ + for the HS-PDSCH of each user, as explained before. When
the feature is active the power on HSPDSCH for each user is no more limited.
After the selection of the UE to be scheduled in the TTI (this step is not modified), the scheduler will check
if there is still some power unallocated.
In this case the scheduler will go again through all the selected UE for this TTI, starting from the first one
selected in the previous step (but it does not change the list of selected UE).
MAC-(e)hs scheduler increases the MCS using the +1dB power/CQI rule, until there is no more power
available (rounded up to the nearest dB) or no more HS-PDSCH codes available or no more processing
available or the maximum transport block size manageable by the HSDPA category of this UE category has
been reached.
If there is still some power available then the scheduler will iterate with the next selected UE.
Note : for xCEM, all available HSDPA power is used and shared between the different users at each TTI. So,
there is no waste of power and consequently, we do not need this feature, which is valid for iCEM, as iCEM
uses power for HSDPA according to a dedicated formula, in which after scheduling all UE, we can have
some unused power.

5.13 HS-DPCCH Power
OVSFd βd
DPDCH x x
∑ I
RNC
Modulation
OVSFc βc
DPCCH x x RadioAccessService
HS-DPCCH
OVSFhs
x
βhs
x
∑ Q
HsdpaUserService
βhs NACK
βhs CQI ackPowerOffset
βhs ACK cqiPowerOffset
NACK
βc CQI nackPowerOffset
ACK
DPCCH

HSDPA
Radio conditions information and acknowledgements are reported by the UE to the Node B through the HS-
DPCCH channel. This channel allows the Node B 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 Node B an Ack, otherwise a Nack.
The HS-DPCCH BLER should be low enough to ensure correct HS-DSCH transmission. A correct demodulation
of CQI ensures suitable transport block transmission. A correct ACK/NACK demodulation ensures a good H-
ARQ efficiency.
The power allocated to the HS-DPCCH is derived from the power of the associated DPCCH taking into
account three specific power offsets. These power offsets should not be set too high in order not to impact
the uplink coverage and capacity.
Offset values are sent to the UE via RRC signaling. These signaled values correspond to predefined (3GPP
standards) quantized amplitude ratios Beta HS/BetaC.

5.14 HSDPA Power - RAN Model
RNC
RadioAccessService NodeB
DedicatedConf FDDCell
isPowerPoolingActivated
activityFactorCcch
HsdpaCellClass EdchCellClass
minimumPowerForHsdpa eagchErgchEhichTotalPower
maxHspaPowerOffset
paOverbookingRatio
BTSEquipment Class2CellReconfParams
paPoolingActivation maxTxPowerPerOls
Class3CellReconfParams
BTSCell maxTxPowerPerOls
paRatio
PaResource
HsdpaConf
dchPowerMargin maxPowerAmplification
hsdpaAmpUsage

HSDPA

6 HSDPA CAC & Call Management

HSDPA

6.1 RAB Matching and CAC
RAB Request RNC
RNC
Service = PS? NO
RadioAccessService
YES
HsdpaCellClass
Traffic Class NO
STR,= I/B? maximumNumberOfUsers
YES
BTSEquipment
HSDPA UE? NO
hsdpaMaxNumberUserHbbu
YES
hsdpaMaxNumberUserXcem
Primary Cell = HSDPA Cell? NO

Capacity
YES
hsdpaNumberUserCapacityLicensing
HSDPA RAB R99 RAB
HSDPA CAC
HSDPA
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.

6.2 HSDPA CAC
RNC CAC
xCEM & Fair Sharing ? isHsxpaR99ResourcesSharingOnCellAllowed
No (FDDCell)
Yes Max Users = 100 ? maximumNumberOfUsers

(HsdpaCellClass)
No
Check Check
Codes & Power number of
HSDPA users
Node B CAC :
iCEM : Check number of HSDPA users per BBU
xCEM : Check number of HSDPA users per xCEM board

HSDPA
In case of iCEM or xCEM without fair sharing, if maximumNumberOfUsers parameter is set to 0, then the
CAC fails and RNC will trigger DCH fallback if activated.
maximumNumberOfUsers is defined in OMC per RNC and corresponds to max HSDPA users per cell.

6.2 HSDPA CAC
6.2.1 Fair Bit Rate
PS STR
RANAP GBR = 0 ?
Yes
No Fair Bit Rate =

Fair Bit Rate = minHsDschReservationForCac

(HsxpaR99ResourcesSharingCellClass)
min(RANAP GBR, RANAP MBR) + RLC/MAC headers
PS I/B with MinBR minBrForHsdpa

(ThpBasedQos)
MinBR = 0 ?
Yes
No Fair Bit Rate =

Fair Bit Rate =

min(minBrForHsdpa, RANAP MBR) +All RLC/MAC
1 1 96 headers
Rights Reserved © Alcatel-Lucent 2011
HSDPA

6.2 HSDPA CAC
6.2.2 Call Admission Control & Power Reservation
I/B MinBR
STR GBR
TC/ARP/THP
HSDPA RNC
PS STR
CAC (Power)
dlTxPowerEstimation*
(Fair Bit Rate)
Traffic Power
(SHO reserved)
PS I/B
dlTxPowerEstimation*
(Fair Bit Rate)
Traffic x
P traffic admission Pres
Power
initialActivityFactorForIb
Pused
Overhead R99 traffic used

Power
(CCC+OCNS
+ E-DCH)
(*) is an power relative to P-CPICH power

HSDPA
Fair Bitrate
For streaming services, this fair bitrate is derived from RANAP GBR (including radio protocols overheads).
For I/B services, the fair bitrate is given by the parameter minBrForHsdpa, offering a differentiation per
OLS (in fact ARP, THP and Traffic Class).
If the minBrForHsdpa is above RANAP MBR then the minBrForHsdpa for this RAB is “downgraded” to the
MBR.
For minBrForHsdpa = 0, the operator can choose to reserve a minimum amount of resources defined by the
parameter minHsDschReservationForCac.
Power reservation: At admission, power is reserved for each RB mapped on HS-DSCH. The reservation is
done or updated each time a MAC-d flow is setup, deleted or reconfigured or on mobility of the serving HS-
DSCH cell.
The power to reserve for this HS-DSCH RAB is fonction of the fair bitrate:
power = dlTxPowerEstimation (fair bitrate)
The parameter dlTxPowerEstimation defines the power to reserve for several reference bitrates ([64kbps;
128kbps; 256kbps; 384kbps; 1000kbps; 2000kbps; 4000kbps]). If the fair bitrate is between two reference
bitrates then the RNC will perform a linear interpolation between these two values.
And finally, this reserved power can be weighted by a parameter (initialActivityFactorForIb) in order to
take into account the activity factor of the PS I/B MAC-d flows (either GBR or non GBR).
For PS I/B MAC-d flow, the power reservation will not change until the resources are released.
For GBR mac-d flows, the power is updated periodically by a self-tuning mechanism (thanks to NBAP
HSDSCH Required Power common measurement). For I/B services, the operator has the choice to use the
minBrForHsdpa as a MAC-ehs GBR (based on flag isDlPowerSelfTuningForPsIbAllowed), so that MAC-(e)hs
scheduler will really try to enforce this minBrForHsdpa. If minBrForHsdpa = 0 (for the TC/ARP/THP
combination) then no GBR information is given to Node B.
DCTM and Fair Sharing algorithms are totally incompatible. Then:
Prior to DCTM activation, Fair Sharing (RNC and NodeB algo) has to be disabled
Prio to Fair Sharing activation (RNC and NodeB algo), DCTM has to be disabled

6.2 HSDPA CAC
6.2.3 Call Admission Control & Codes Reservation
I/B MinBR
STR GBR
TC/ARP/THP
HSDPA RNC
CAC (Codes)
For UE category 11 and 12: 1..15

Nb of SF16 codes = fair bitrate / ovsfCodesThroughputQpskUe
For UE category 1 to 10: 1..15

Nb of SF16 codes = fair bitrate / ovsfCodesThroughput16QamUe
PS STR
PS I/B with MinBR = 0 PS I/B with MinBR = 0 x reservationFactorOnCodesForGbrTraffic
x initialActivityFactorForIb x reservationFactorOnCodesForGbrTraffic
x initialActivityFactorForIb

HSDPA
Codes reservation
At admission, some codes are reserved for each RB mapped on HS-DSCH. The reservation is done or updated
each time a MAC-d flow is setup, deleted or reconfigured or on mobility of the serving HS-DSCH cell.
As for power, the number of codes to reserve for this HS-DSCH RAB is directly proportional to the fair
bitrate:
For UE category 11 and 12:
Nb of SF16 codes = fair bitrate / ovsfCodesThroughputQpskUE [1xSF16]
For UE category 1 to 10:
Nb of SF16 codes = fair bitrate / ovsfCodesThroughput16QamUE [1xSF16]
Parameters ovsfCodesThroughputQpskUE and ovsfCodesThroughput16QamUE give the bitrate that can
be achieved with one HS-PDSCH code (1xSF16). Two different parameters have been defined in order to be
able to take into account the gain brought by ue categories using the 16 QAM modulation.
For GBR MAC-d flows the RNC can apply an over-reservation factor
(reservationFactorOnCodesForGbrTraffic) because it is more important to reserve enough codes for
these flows than for best effort MAC-d flows, given that there is no feedback from Node B when there are
not enough HS-PDSCH codes to reach the GBR.
In case of RNC CAC failure, pre-emption can be triggered thanks to the feature “Pre-emption process for
DCH and HSDPA/HSUPA”.

6.3 HSDPA to DCH Fallback
RAB assignment (to establish or to release)

IU release
RabAssignment
Primary cell change
Incoming Inter-RNC UE involved Hard Handover
Incoming Intra-RNC Alarm Hard Handover AnyCase
Mobility
hsdpaToDchFallbackPermission
HSDPA RB
to established
NoFallBack
CAC OK ?
No
Yes HSDPA to DCH Fallback
HSDPA RB DCH RB
established to established

HSDPA
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:
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.

6.4 Initial Rate Capping during RB reconfiguration
This sub feature is used to limit the initial data rates allocated on several
procedures (call establishment, AO, HS transport channel type reconfiguration)
These rate limitation is applied only on a DCH transport channel for initial state
and can be modified later by other algorithms like RRA
isOamCappingOfDataAllowed
= True New set of capping parameters
maxDlEstablishmentRate maxUlEstablishmentRate
(CacConfClass) (CacConfClass)
A parameter for each scenario and direction (UL/DL):
• Always-On Capping: Cell_FACH or PCH state to Cell_DCH
• Fallback Capping: HSDPA/HSUPA to DCH/DCH or to HSDPA/DCH

HSDPA/DCH to DCH/DCH
• Establishment Capping: On DCH establishment

HSDPA
maxDlRateHsdpaAndDchToDchAndDch
maxDlRateHsdpaAndEdchToDchAndDch
On Fallback
maxUlRateHsdpaAndDchToDchAndDch
maxUlRateHsdpaAndEdchToDchAndDch
maxUlRateHsdpaAndEdchToHsdpaAndDch
maxDlRateRabEstablishDchAndDch
On Call Establishment
maxUlRateRabEstablishDchAndDch
maxUlRateRabEstablishHsdpaAndDch
maxDlRateTransitionToDchDlTriggerDchAndDch
maxUlRateTransitionToDchDlTriggerDchAndDch
Always-On
maxUlRateTransitionToDchDlTriggerHsdpaAndDch
maxDlRateTransitionToDchUlTriggerDchAndDch
maxUlRateTransitionToDchUlTriggerDchAndDch
maxUlRateTransitionToDchUlTriggerHsdpaAndDch

6.5 Always On for HSDPA/DCH: Mono-Service PS/Mono-
RAB
isAlwaysOnAllowed = degraded2AlwaysOnOnly pchRrcStates = none
HSDPA/DCH timerT1ForHsdpa timerT2

PS I/B CELL_FACH PMM-idle
CELL_DCH AO Step1 AO Step3
isAlwaysOnAllowed = degraded2AlwaysOnOnly PchRrcStates = UraPchEnabled
HSDPA/DCH timerT1
ForHsdpa fachToUraPchTimer uraPchToIdleTimer
PS I/B CELL_FACH URA_PCH PMM-idle
CELL_DCH AO Step1 AO Step2 AO Step3
isAlwaysOnAllowed = releaseOnly pchRrcStates = none
HSDPA/DCH timerT2ForHsdpa
PS I/B PMM-idle
CELL_DCH AO Step3

HSDPA
Analog to R99 cases but with specific timer parameters

6.6 AON for HSDPA/DCH: Multi-Service PS/Multi-RAB PS
Mono-Service PS / Multi-RAB PS I/B HSDPA

HSDPA/DCH timerT2ForHsdpa
PS I/B MUX PMM-idle
CELL_DCH AO Step3
Multi-Service CS+PS / Mono-RAB PS I/B HSDPA

isAlwaysOnAllowed = degraded2AlwaysOnOnly pchRrcStates = any
CS + PS I/B timerT2ForHsdpa CS + PS I/B 0/0 xxxPchToIdleTimer MM-connected

HSDPA/DCH
(CELL_DCH) +
CELL_DCH AO Step2 AO Step3 PMM-idle
Multi-Service CS+PS / Multi-RAB PS I/B HSDPA

CS + PS I/B MUX timerT2ForHsdpa MM-connected

HSDPA/DCH +
CELL_DCH AO Step3 PMM-idle

HSDPA
Analog to R99 cases but with specific timer parameters

7 Other HSDPA Features

HSDPA

7.1 Fixed RLC and MAC-hs
The RLC SDU

segmentation into fixed
size RLC PDUs may lead
RLC SDU User payload to padding in RLC PDU.
RLC PDU (fixed size) Pad.
The Transport Block Size is

MAC-d PDU the result of the TRFC
selection algorithm. A non
negligible number of
padding bits may be
MAC-hs
MAC-hs PDU header MAC-hs SDU Pad. required to fit the
Transport Block Size.
Transport Block Size (based on TRFC selection)
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
•
HSDPA
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

7.2 Transport Block Size Optimization: CQI 1 to 15
Mac-hs PDU = 1TTI
BTSEquipment
Mac-hs SDU
BTSCell
RLC SDU Mac-d SDU = Mac-d PDU
21 320 16 320 16 320 16 Padding HsdpaConf
HsdpaUeCategoryTransportBlockOptimisation
Transport Block Size
Num of 336
CQI Num of HS -
bit MAC -d Modulation
value Default Optimized PDSCH codes
PDU
1 377 1 QPSK 1
2 377 1 QPSK 1
ueCategory1
3 377 1 QPSK 1
ueCategory2
4 377 1 QPSK 1
ueCategory3
5 377 365 1 QP SK 1
6 377 1 QPSK 1
7 377 1 QPSK 2
8 792 699 2 QPSK 2
9 792 2 QPSK 2 ueCategory12
10 1262 1036 3 QPSK 3
11 1483 1380 4 QPSK 3
12 1742 1711 5 QPSK 3
13 2279 2046 6 QPSK 4
14 2583 2404 7 QPSK 4
15 3319 3090 9 QPSK 5

HSDPA
If the Optimized TBS is used then the Padding Bits ratio is less and then the coding rate decrease.
Therefore the decoding improves, the BLER decreases and the throughput increases.
This feature is used by iCEM only. xCEM already implements the TBS optimisation (less padding) thanks to
Flexible RLC feature.

7.3 Flexible RLC and MAC-ehs
No need for padding

as RLC PDU size can
be adjusted to fit
RLC SDU User payload exactly the size of the
RLC SDU
RLC PDU
(flexible size)
MAC- d PDU MAC-d PDU 1 MAC-d PDU 2 MAC-d PDU 3

(=MAC-ehs SDU)
Reordering SDU2
MAC-ehs
Pad-
MAC-ehs header
PDU header ReorderingSDU 1 MAC-ehs
header
……
Reordering PDU Reordering PDU
Padding bits are

reduced as MAC-ehs
can segment a MAC-d
isMacEhsAllowed isMacEhsAllowed PDU in case it cannot
fit into the selected
(RadioAccessService) (FDDCell) Transport Block

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

7.4 64 QAM On HSDPA Activation Flags
NO
MAC-ehs configured ?
YES
isDl64QamAllowed (FDDCell)
NO
NodeB 64QAM capable? isDl64QamOnRncAllowed
YES
NO
is64QamAllowedForUeCategory
(HsdpaRncConf)
= capable?
UE 64QAM
YES
isMacEhsAllowed
NO (RadioAccessService)
NodeB 64 QAM Activated?
isMacEhsAllowed
YES (FDDCell)
NO
UE CAT 64-QAM Eligible?
YES
Node B 64-QAM Eligible QPSK / 16-QAM

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

1 MAC-ehs configured : The feature Flexible RLC and MAC-ehs must be configured. isMacEhsAllowed =
True and isMacEhsAllowed = True.
2 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
3 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
doesn’t 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)
4 The NodeB is allowed to used the 64QAM: RadioAccessService.isDl64QamOnRncAllowed = True and
FDDCell.isDl64QamAllowed = True.
5 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.

7.5 HSDPA Flexible Modulation
UA05.x iCEM UA06/UA07 iCEM
iCEM Activation* :
Follow 3GPP False
AMC tables hsdpaFlexibleModulationVsCodeActivation
(HsdpaConf)
True
Static TFRC Table

Transport Block Size Num of 336
CQI bit MAC-d Num of HS
Modulation PDSCH - Nb of codes {1,2,…,15} x Modulation {QPSK , 16QAM}
value Default Optimized codes
PDU Maximize nb of transmitted bits*
1 137 1 QPSK 1
2 173 1 QPSK 1
3 233 1 QPSK 1
4 317 1 QPSK 1
5 377 365 1 QPSK 1
6 461 1 QPSK 1
7 650 1 QPSK 2
8 792 699 2 QPSK 2
9 931 2 QPSK 2
10 1262 1036 3 QPSK 3
11 1483 1380 4 QPSK 3 Codes limitation TBS boost
12 1742 1711 5 QPSK 3
13 2279 2046 6 QPSK 4
14 2583 2404 7 QPSK 4
15 3319 3090 9 QPSK 5 16 QAM QPSK
(*) the equivalent xCEM feature is supported by default

HSDPA
In UA05.x, the mapping between number of HS-PDSCH codes and modulation is fixed, that is to say :
QPSK for less than 5 HS-PDSCH codes
16QAM for more than 5 HS-PDSCH codes
In UA06.0, the feature “HSDPA Flexible Modulation” introduces a flexible mapping between codes and
modulation in order to improve HSDPA throughput / performances.
The scope of the feature is to modify the applied TFRC (number of bits, number of codes, modulation,
power) so that (number of codes, modulation) shall take any possible value in {1,2,…,15} x {QPSK , 16QAM}.
Two cases may appear:
Code limitation: When the number of available codes is limited, 16QAM modulation is preferred in
order to transmit a higher number of bits.
Ex : if the remaining number of codes is 2, scheduler will use the TFRC (2404 bits, 2 codes,
16QAM) instead of (699 bits, 2 codes, QPSK).
TBS boost: When it remains some HS-PDSCH codes, QPSK modulation is preferred in order to
transmit a higher number of bits.
Ex : if 14 codes are available, the TFRC selected will be (6101 bits , 14 codes, QPSK) instead
of (5101 bits , 5 codes, 16QAM)

8 HSDPA Mobility

HSDPA

8 HSDPA Mobility
8.1 3G->2G HHO
Core Network
SRNC GSM/GPRS BSS
FDD Cell GSM Cell
HS BCCH
-
PD
F
As
TB
SC
so
1
H
UL
ci
at
&
ed
DL
DP
CH
2 Cell Change Order activationHoGsmPsAllowed

isInterFreqMeasActivationAllowed
isPatternAllowed isGsmCmodeActivationAllowed
(CmodePatternSeqInfo) (RadioAccessService)
HSDPA is released in original cell only at the end

HSDPA
Thanks to Compress Mode in MAC-(e)hs a UE can performed a HHO to 2G with measurements when on a
HSDPA RAB.
CM for 2G neighboring cells measurements is activated when UE is having a PS RAB on 3G if:
isInterFreqMeasActivationAllowed = True
isGsmCmodeActivationAllowed = True
isPatternAllowed = True
Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering.
The selection between FDD and 2G Access is part of iMCTA algorithm, mostly based on UE
capabilities, priority tables and available neighboring cells
3G to 2G HHO is possible for a UE having a PS service if activationHoGsmPsAllowed must be set to True

If UE is having a CS+PS service then activationHoGsmCsAllowed must also be set to True

8 HSDPA Mobility
8.2 3G->3G Intra-RNC Inter-freq HHO
SRNC
FDD Cell F1 FDD Cell F2
HS
-
P-CPICH
PD
CH
As
CH
SC
DS
so
1
H
3
DP
ci
-P
at
HS
ed
ed
at
DP
ci
so
CH
As
2 Radio Bearer Reconfiguration
isHsdpaHhoWithMeasAllowed
is3Gto3GWithoutIurAllowedforCS
is3Gto3GWithoutIurAllowedforPS

HSDPA
Global 3G->3G Inter-frequency HHO are controlled by parameters is3Gto3GWithoutIurAllowedforCS and

is3Gto3GWithoutIurAllowedforPS even though naming is not explicit.
Specific 3G->3G Inter-frequency Intra-RNC HHO when on a HSDPA RAB is controlled by
When set to False, this parameter prevents any Inter-frequency Intra-RNC reconfiguration to
HSDPA, and only the 2 following transitions can then occur for DL Transport Channel:
HSDPA to DCH
DCH to DCH
This parameter is not used by RNC in case of outgoing and incoming HHO (i.e. Inter-RNC HHO).
isIrmCacForInterFreqIntraRncEnable: allows to play iRM CAC tables on the Target FDD cell before
executing HHO (only applicable for Intra-RNC HHO).

8 HSDPA Mobility
8.3 3G->3G Inter-RNC Inter-freq HHO
Core Network
SRNC Target RNC
FDD Cell F1 FDD Cell F2
HS P-CPICH
-
PD
As
CH
SC
SC
so
1 3
PD
H
DP
ci
at
ed
HS
ed
at
DP
ci
so
CH
As
2 Radio Bearer Reconfiguration is3Gto3GWithoutIurAllowedforPS

HSDPA
In case of Inter-RNC mobility, source RNC uses R5 or R6 extensions (depending on established RAB) in order
to indicate in the RRC container:
The HSxPA-capabilities of the mobile
The RAB currently running on Source RNC (either HS-DSCH or E-DCH)
This nominal RRC container allows Target RNC to directly reconfigure the RAB in HSxPA without any DCH
transition.
However, in very specific cases where HSxPA capabilities are missing (e.g. RNC 4.2 facing RNC 5.0), Target
RNC first establishes the PS RAB into DCH, requests UE’s HSxPA-capabilities through RRC UE Enquiry
Capability procedure and eventually reconfigures the PS RAB into HSxPA if needed.
Inter-RNC HHO are processed in the same way whether there is Iur or not, i.e. through a SNRS Relocation
procedure.

8 HSDPA Mobility
8.4 HSDPA over Iur
Core Network
isHsdpaOverIurAsSrncAllowed
isMacShHsdpaAllowed
Radio Link
3 Reconfiguration
HS-DSCH
HS-DSCH
SRNC 4 DRNC
Associated DCH
isHsdpaOverIurAsDrncAllowed
isHsdpaAllowed (RadioAccessService)
(NeighbouringRNC)
isHsdpaAllowed
(RemoteFDDCell)
HS
CH
-
PD
As
CH
DS
so
SC
DP
5
-P
ci
HS
at
ed
ed
at
ci
DP
so
CH
As
Primary Cell change
2 (Event 1d)

HSDPA
Within the scope of HSDPA mobility over Iur between Alcatel-Lucent RNCs, this feature consists in
supporting the HS-DSCH FP over Iur as well as the HSDPA RAB messaging over RNSAP.
Depending on the Iur dimensioning constraints, the feature can be deactivated by the customer.
Assuming a deactivation of the feature, a DCH fall back is performed to maintain the call
continuity once crossing the Iur.
As a SRNC, the decision to configure an existing RL over Iur with HSDPA is taken when the primary cell
selection results with a cell belonging to a neighboring RNC. The request is sent to the neighboring RNC
using a RNSAP Radio Link Reconfiguration Prepare message with HS-DSCH information.
As a DRNC:
In a Alcatel-Lucent - Alcatel-Lucent case, an existing radio link is configured to HSDPA when the DRNC
receives a RNSAP Radio Link Reconfiguration Prepare message with HS-DSCH IEs.
In a non Alcatel-Lucent - Alcatel-Lucent case, an HSDPA configuration occurs when the DRNC receives a
RNSAP Radio Link Setup Request or a Radio Link Reconfiguration Prepare message with HS-DSCH IEs.
isHsdpaOverIurAsSrncAllowed: This parameter allows RNC to enable/disable HSDPA over Iur when
acting as a Serving RNC.
isHsdpaOverIurAsDrncAllowed: This parameter allows RNC to accept/reject HSDPA reconfiguration
over Iur when acting as a Drift RNC.
isHsdpaAllowed: This parameter defines the HSDPA capabilities of neighboring RNC to which Iur
link is provisioned.
In case, DRNC is prior to UA05.1, it is recommended to set NeighboringRnc.isHsdpaAllowed to False
so as to prevent any reconfiguration attempt to HSDPA at Primary cell change to a DRNC since Iur
and Iub traffic load is not controlled.
In case isHsdpaOverIurAsDrncAllowed is set to True, the parameter isMacShHsdpaAllowed under
RadioAccessService must also be set to True so as to have Iub bandwidth limitation processing HSDPA
traffic over Iur,

8.4 HSDPA over Iur
8.4.1 64-QAM over Iur: Not Supported
Core Network
Radio Link
3 Reconfiguration
HS-DSCH
HS-DSCH
SRNC 4 DRNC
Associated DCH
16 QAM
64
QA
HS
CH
-
PD
As
CH
DS
so
SC
DP
5
-P
ci
HS
at
ed
AM
ed
at
ci
Q
DP
so
CH
16
As
Primary Cell change
2 (Event 1d)

HSDPA
Iur:
64 QAM is not supported over Iur (because MAC-ehs is not supported over Iur) . ALU SRNC will reconfigure
the call to MAC-ehs when the serving cell moves under the control of a DRNC. ALU DRNC will not advertise
MAC-ehs and 64-QAM support over the Iur. If a SRNC decides to use MAC-ehs and/or 64-QAM over the Iur,
ALU DRNC will refuse the configuration.

Module Summary
This lesson covered the following topics:

HSDPA activation principles and associated parameters
HSDPA radio resource management and associated parameters
HSDPA mobility features and associated parameters

HSDPA

Self-assessment on the Objectives
Please be reminded to fill in the form

Self-Assessment on the Objectives
for this module
The form can be found in the first part
of this course documentation

HSDPA

End of Module

HSDPA

21
Section 2
HSUPA
Module 1
9300 WCDMA

Blank Page

HSUPA
Document History

Module Objectives
Describe HSUPA principles and associated parameters

Describe HSUPA radio resource management parameters
Describe HSUPA mobility features and associated parameters

HSUPA


HSUPA

Table of Contents
Page
1 HSUPA Principles 7
1.1 HSUPA Activation Flags 8
1.2 E-DCH Capable UE Supported 9
1.3 E-BBU Resource Allocation – iCEM case 10
1.4 Multi-Mode BBU Resource Allocation – xCEM case 11
1.5 E-DCH/HSDPA Service Indicator broadcast 12
1.6 Scheduling 13
1.7 Physical Channels 14
1.8 Multiple E-AGCH and E-RGCH 15
1.9 Physical Channels Role 16
1.10 Transport Channel 17
1.11 E-DCH 2 ms TTI activation 18
1.12 HARQ 19
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ 20
1.13 MAC-e non-scheduled Mode 21
1.14 PS Streaming on HSUPA 22
1.15 User Services supported with HSUPA 23
2 HSUPA Scheduler 24
2.1 Grant Allocation 25
2.2 E-TFCI Table Configuration – Virtual UE Category 26
2.3 E-TFCI Table Configuration – Virtual UE Category example 27
2.4 Priority Info Support (iCEM and xCEM) 28
2.5 Scheduler iCEM: Principle 29
2.5.1 iCEM MAC-e Scheduler 30
2 1 5 2.6 Scheduler xCEM: Principle All Rights Reserved © Alcatel-Lucent 2011
31
HSUPA
2.6.19300
9300 WCDMA TMO18256 xCEM MAC-e
WCDMA UAO7 Scheduler
HSxPA Algorithms Description 32
2.6.2 xCEM MAC-e Scheduler – Scheduling Weight (SW) 33
2.6.3 xCEM MAC-e Scheduler – Degrant Mechanism 34
3 HSUPA Radio Load & Interference Management 35
3.1 UL Radio Load Monitoring: needed for E-DCH scheduling 36
3.2 UL Radio Load Monitoring: Defense Mechanism 37
3.3 UL Radio Load : Self-interference issue with E-DCH 38
3.4 Self-interference issue on UL Noise Rise 39
3.4.1 First solution 40
3.4.2 Second Solution 41
4 HSUPA Power Management 42
4.1 DL Power Management: RNC level 43
4.2 DL Power Management: NodeB level 44
4.2.1 E-DCH signaling channels Power Control Parameters 45
4.3 UL Power Management 46
4.3.1 Closed Loop Power Control 47
4.3.2 Scheduling and Power Offset 48
4.3.3 UL Outer Loop Power Control on UL DPDCH (UA05.0) 49
4.3.4 UL OL Power Control on HARQ retransmission (UA05.1) 50
4.3.4.1 SIR Target update decision 51
4.3.5 E-DCH Adaptive HARQ Control 52
4.3.6 Specific case of SRB on E-DCH 53
4.3.7 Fast Decrease of E-DCH Partial SIR Target 54
4.3.8 E-DCH Partial SIR Target in case of Soft HO - Definition 55
4.3.9 E-DCH Partial SIR Target in case of Soft HO - Calculation 56
4.3.9.1 E-DCH Partial SIR Target in case of Soft HO - Exercise 57
4.4 Radio Link Control - DL/UL Imbalance Detection 58
5 HSUPA CAC & Call Management 59
5.1 HSUPA CAC 60
5.2 RAB Allocation Phase 61

Page
5.3 HSUPA to DCH Fallback 62
5.4 Always On: degraded2AOnOnly - URA/Cell_PCH used 63
5.4.1 degraded2AOnOnly - URA/Cell_PCH not used 64
5.4.2 Always On: releaseOnly - URA/Cell_PCH not used 65
6 HSUPA Mobility 66
6.1 E-DCH Radio Links Set, E-DCH Active Set: Definitions 67
6.2 E-DCH serving NodeB, E-DCH non-serving NodeB 68
6.3 E-DCH Active Set Management: Event 1J 69
6.4 E-DCH Active Set Management: Primary Cell Change 70
6.5 Soft HO Data Transmission Example 71
6.6 UL Noise Rise due to E-DCH Non-Serving RL : iCEM case 72
6.6.1 xCEM case 73
6.7 E-DCH Macro Diversity RAN Model 74
6.8 Intra-Freq Mobility : Primary Cell Change 75
6.8.1 Call Flow 76
6.11.1 Inter-Freq Inter-RNC Mobility: With Iur AND 82
6.12 Inter-RAT Mobility 83

HSUPA

1 HSUPA Principles

HSUPA

1 HSUPA Principles
1.1 HSUPA Activation Flags
RNC
NodeB BTSEquipment RadioAccessService UmtsNeighboring
FddCell BTSCell RemoteFDDCell
edchActivation edchResourceActivation isEdchAllowed isEdchAllowed

HSUPA
HSUPA is activated through several activation flags at RNC, FDDCell and BTSCell level.

1 HSUPA Principles
1.2 E-DCH Capable UE Supported
UE categories 4 to 6 are supported only by the xCEM.

The RNC configure the ETFC table taking into account the UE category
SRB over E-DCH is used to support UE cat6 as no DPDCH is supported when
using 2SF2+2SF4
Maximum
Maximum Maximum number
number of bits
number of of bits of an e-
Minimum Support for 10 of an e-DCH Air
E-DCH e-DCH DCH transport Air Interface
spreading and 2ms TTI e- transport block Interface
Category codes block transmitted data rate
factor DCH transmitted data rate
transmitte within a 10 ms e-
within a 2 ms e-
d DCH TTI
DCH TTI
Category 1 1 SF4 10ms TTI only 7296 700kbps -
Category 2 2 SF4 10ms and 2ms TTI 14592 1.4Mbps 2919 1.4Mbps
Category 3 2 SF4 10ms TTI only 14592 1.4Mbps -
Category 4 2 SF2 10ms and 2ms TTI 20000 2Mbps 5837 2.9Mbps
Category 5 2 SF2 10ms TTI only 20000 2Mbps -
2 SF2
Category 6 10ms and 2ms TTI 20000 2Mbps 11520 5.7Mbps
2 SF4
ly
On
M
x CE

HSUPA
E-DCH UE categories have been defined by 3GPP according to their radio capabilities.
To be eligible to E-DCH, the UE must support Release 6 (or later) including:
the Access Stratum Indicator which is part of the RRC connection request message,
E-DCH capability in UE Radio Access Capability IE (in the Physical Channel Capability IE) in RRC
Connection Setup Complete message.
The UE categories have been defined to determine the following characteristics:
How many codes the UE can transmit simultaneously
Is the UE able to support 10 ms and 2 ms TTI
What is the maximum throughput transmitted
In term of bit rates, we can expect a maximum of:

2 Mbits /s for TTI = 10 ms
5.76 Mbits /s for TTI = 2 ms
iCEM supports up to SF4 and 10ms TTI only.

Therefore UE category 2, 4, 5 and 6 will be managed by iCEM sheduler as UE category 3.

1 HSUPA Principles
1.3 E-BBU Resource Allocation – iCEM case
UL BTSEquipment
E-DPCCH(s)
E-DPDCH(s) MAC-e
DL BTSCell
• UL E-DCH scheduling and granting
E-HICH • UL demodulation/decoding of E-DCH
E-AGCH • Handling of E-DCH HARQ feedback on the DL EdchConf
E-RGCH
EdchResourceId
BTS
H-BBU
iCEM128
E-BBU
UL iTRM MCPA DDM
DPCCH(s)
E-DPCCH(s) D-BBU
iCEM128
E-DPDCH(s) D-BBU
DL
E-HICH
E-AGCH H-BBU
iCCM iTRM MCPA DDM
iCEM64
E-RGCH
D-BBU
iCEM128
D-BBU iTRM MCPA DDM
D-BBU
CEMa
D-BBU
Digital Shelf Radio Shelf

HSUPA
The HSUPA 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, HSDPA and HSUPA services. In order for the BTS to be able to manage both
dedicated, HSUPA and HSUPA services, the BTS has to specialize BBUs as:
D-BBU: BBU managing dedicated services,
H-BBU: BBU managing HSDPA services,
E-BBU: BBU managing HSUPA services.
The partition between E-BBU and D-BBU and H-BBU is done by the BTS at BTS startup reading the value of
the edchResourceId parameter for a BTS Cell when the btsCell parameter edchResourceActivation is set
to TRUE. When used, this parameter associates a logical HSUPA resource identifier for this cell.
In UA06.0, an iCEM E-BBU can work only in “shared mode”: the E-BBU is managing 1 LCG (3 cells) of a
NodeB.
HSUPA is supported by Alcatel-Lucent BTS within the following system limits:

For HSUPA managed by iCEM/iCEM2 :
All cells of a given LocalCellGroup are managed by one E-BBU
Maximum 1 LocalCellGroup (up to 3 HSUPA Cells) per E-BBU
Maximum 1 iCEM E-BBU per NodeB (except for UTRAN Sharing) in UA05.1. & UA06.0

1 HSUPA Principles
1.4 Multi-Mode BBU Resource Allocation – xCEM case
xCEM
BTSEquipment
BBU
BBU BBU
BBU 05
DCH DCH UA
DCH DCH
xCEM HsXpaResource
BBU
BBU BBU
BBU
BBU BBU
HSDPA
BBU
HSUPA BBU
HSDPA HSUPA
DCH DCH
DCH
DCH
BBU
BBU BBU
BBU
HSDPA HSDPA
HSDPA
HSDPA
Per xCEM :
- Up to 256 CE where 128 of them can
be used to support HSDPA and/or
HSUPA calls
06 - Up to 6 cells belonging to 2 LCGs
UA
xCEM
BBU
BBU BBU
BBU
Multimode Multimode
Multimode Per M-BBU :
Multimode
Up to 64 calls shared
BBU
BBU BBU
BBU dynamically between R99,
Multimode Multimode
Multimode HSDPA & HSUPA
Multimode

HSUPA
UA06 Restrictions:
M-BBU functionality is activated by default in UA06.0 (no means to deactivate it).
HSUPA is supported by Alcatel-Lucent BTS within the following system limits:

For HSUPA 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 HSUPA resources of the xCEM are seen as a single pool of capacity
Maximum 2 LocalCellGroup (up to 6 HSUPA Cells) per xCEM board.
For a given LocalCellGroup, HSDPA & HSUPA resources must be located on the same xCEM
board.

1 HSUPA Principles
1.5 E-DCH/HSDPA Service Indicator broadcast
isHsxpaServiceIndicatorEnabled
RNC
SIB5 SIB5
NodeB NodeB
non E-DCH
E-DCH cell
cell
HSxPA UE Auto hsdpaServiceIndicatorMethod Auto HSxPA UE

edchServiceIndicatorMethod
(FDDCell)
E-DCH E-DCH
OK! NOK!

HSUPA
This feature allows the mobile to display an indication when it is under HxDPA coverage.
UTRAN also broadcasts an E-DCH cell indicator information element in SIB 5 for cells that are E-DCH
capable.
UTRAN broadcasts an HSDPA cell indicator information element in SIB 5 for cells that are HSDPA
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
(HSUPA and HSDPA), all combinations between HSDPA and HSUPA being allowed:
Off: the ‘edchServiceIndicator’ (or respectively the ‘hsdpaServiceIndicator’ ) information is not
broadcasted in SYSINFO message
On: the ‘edchServiceIndicator’ (or respectively the ‘hsdpaServiceIndicator’) information is always
broadcasted on SYSINFO, with value EDCH_CAPABLE (or respectively HSDPA_CAPABLE). This
information is broadcasted to the UE even if the corresponding service (-E-DCH (or respectively
HSDPA)) is not operational on the corresponding cell.
Auto: the ‘edchServiceIndicator’ (or respectively the ‘hsdpaServiceIndicator’) information is
broadcasted to the UE indicating the current state of the corresponding service: EDCH_CAPABLE if
service is operational, EDCH_NOT_CAPABLE otherwise (or respectively HSDPA_CAPABLE if service is
operational, HSDPA_NOT_CAPABLE otherwise)

1 HSUPA Principles
1.6 Scheduling
Scheduler
Channel Assignment 2
• Absolute Grant
• Ack / Nack 5
• Relative Grants 6
EE--DPCCH
DPCCH E-DPDCH E-AGCH E-DPCCH E-DPDCH E-HICH E-RGCH
00 1 2 3 4 5 6
• Scheduling info
1
• Format definition 3
• Traffic data 4
HSUPA
This slide shows the role of each HSUPA channel when the UE requests to send data.
Scheduler goals
The Scheduler is the key element of the HSUPA solution.
It is in charge of two major tasks:
It manages E-DCH cell resources between UEs
It deals with uplink radio interferences
What is Scheduling Information? It is a message reported by UE to indicate the current status of its waiting
list.
The UE available power results from: UE Power headroom)/ highest priority level /queue total size
percentage occupied by the queue of higher priority
One main constraint of the scheduler consists in supporting fairness among users according to their Queue
priority level:
4 levels of priority (SPI),
ensure a minimum access for each active UE.
With the introduction of the MAC-e protocol in charge of the scheduling, the Node B becomes smarter as a
decision-making center.

1 HSUPA Principles
1.7 Physical Channels
E-DPDCH E-DCH Dedicated Physical Data Channel UL

Carries the actual Traffic
DTCH E-DPCCH E-DCH Dedicated Physical Control Channel UL
Traffic
TRB Describes the E-DPDCH
E-HICH E-DCH HARQ Indicator Channel DL
Ack/Nack from BTS
E-DCH E-AGCH E-DCH Absolute Grant Channel DL

Resource allocation (absolute value)
UL E-RGCH E-DCH Relative Grant Channel DL
Resource allocation (more or less)
E-DPDCH
RadioAccessService
E-HICH E-DPCCH
maxNrOfEagch
maxNrOfErgchEhich DedicatedConf
E-AGCH E-RGCH
EdchCellClass

HSUPA
HSUPA includes a new set of new physical channels. Here are the basic functions of each channel:
E-DPDCH (E-DCH Dedicated Physical Data Channel) carries the actual UL Traffic
The number of E-DPDCH per UE depends of its E-DCH category.
E-DPCCH (E-DCH Dedicated Physical Control Channel) associated to the E-DPDCH to control it
There is up to 1 E-DPCCH channel per UE
E-HICH (E-DCH HARQ Indicator Channel) to indicate in DL to the UE if the UL transmission are well
received (ACK/NACK channel).
In UA05 up to 3 E-HICH maximum can be configured per BTS.
E-AGCH (E-DCH Absolute Grant Channel) and E-RGCH (E-DCH Relative Grant Channel) to indicate in
DL to the 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).

1 HSUPA Principles
1.8 Multiple E-AGCH and E-RGCH
Non Serving
Serving Node B
Node B
maxNrOfEagch
maxNrOfErgchEhich
(edchCellClass) Serving Non
RL Serving RL
Non
Serving RL
For each E-RGCH/E-HICH
40 signatures per code
The users shall be uniformly distributed over the
available E-RGCH/E-HICH codes
The selected code shall have at least 2 free Rel’6 UE
signatures that can be used for E-HICH and E-RGCH
For each affected RL one available signature for
E-DPCCH & E-DPDCH
E-HICH should be allocated E-RGCH & E-HICH
E-RGCH (Common RG)
One available signature for dedicated RG shall be
allocated to serving users (per radio link) E-AGCH
Associated DCH
Non serving users shall get uniformly assigned to
signatures reserved for common RG

HSUPA
iCEM
On iCEM, up to 3 E-AGCH channels can be configured per cell. However, since the maximum number of E-
DCH radio links that can handle one E-BBU on iCEM is 15, depending on the expected E-DCH traffic on the
considered zone, it may not be useful to send several E-AGCH commands at the same time, and on the
other hand saving DL code resource could benefit to DL traffic. Consequently, for iCEM, if low E-DCH traffic
is expected, it is recommended to set maxNrOfEagch = 1.
On iCEM, since the maximum number of E-DCH radio links that can handle one E-BBU is 15, one E-RGCH/E-
HICH channel per cell is sufficient. Therefore, for iCEM, in order to save DL code resource, it is
recommended to set maxNrOfErgchEhich = 1.
xCEM
On xCEM, up to 3 E-AGCH channels can be configured per cell. However, since on xCEM AG commands are
only sent for activation and deactivation of the granting process of a given user, depending on expected E-
DCH traffic on the considered zone, it may not be useful to send several EAGCH commands at the same
time, and on the other hand saving DL code resource could benefit to DL traffic. Consequently, for xCEM, if
low E-DCH traffic is expected, it is recommended to set maxNrOfEagch = 1.
On xCEM, up to 4 E-RGCH/E-HICH channels (i.e. OVSF codes) can be configured per cell. For xCEM, in order
to maximize the possible number of simultaneous E-DCH active users per cell while limiting the impact of a
potential wrong setting to the value 4 applying to iCEM (e.g. in case of xCEM board failure for a NodeB with
a mix of iCEM and xCEM), it is recommended to set maxNrOfErgchEhich = 3.
Note that in UA07, it is recommended to set maxNrOfErgchEhich to 1 for xCEM and UCUIII (instead of 4 in
UA06), in order to save DL codes hence favor HSDPA+ performances.

1 HSUPA Principles
1.9 Physical Channels Role
Node B
Node B allocates resources Ack/Nack
( Absolute or relative )
Dedicated Dedicated
E-AGCH E-RGCH E-DPCCH E-DPDCH E-HICH

Mobile
describes format and sends data

HSUPA
We can divide the new set of channels into 2 categories: traffic & scheduling.
Scheduling channels
E-AGCH carries E-DCH absolute grant. It indicates to the E-DCH UE (either individually or per group)
what are their resources (absolute UL resources limitation).
E-RGCH carries E-DCH relative grants. It is a dedicated channel for the Node B involved in the E-DCH
active set. This channel allows each node B dealing with E-DPDCH to reduce the UE emitted power
in order to avoid radio interferences.
Traffic & signaling channels
E-HICH carries feedback information (ACK/NACK) sent by the Node B to indicate whether the
packets are properly received. This channel is based on the Node B HARQ algorithm. Thanks to this
channel, the Node B can send back to the UE indications about the faulty packets.
E-DPDCH is the uplink channel that carries the user data ; TTI is either 10ms (mandatory supported
by UE) or 2ms (optional support). Modulation is the same as DCH.
E-DPCCH is used to carry the uplink L1 signaling required to demodulate the E-DPCH: E-TFCI identity
of the E-TFC selected, RSN (number of HARQ retransmissions) and “happy bit” (telling if the grants
allocated to this UE are sufficient vs. the amount data waiting in the transmission buffer).

1 HSUPA Principles
1.10 Transport Channel
BTSCell
HSUPA Uplink transport channel: E-DCH
EdchConf
DTCH isEdchTti2msAllowed
• Uplink
Traffic • TTI: 2ms or 10ms
TRB
Mobile i • TBS free attribute of Transport format
• ETFCI
• HARQ: Incremental Redundancy
E-DCH •Turbo coding 1/3
UL • CRC 24bits
E-DPDCH
E-HICH E-DPCCH
E-AGCH E-RGCH

HSUPA
A specific E-DCH transport channel is defined. As the classical DCH transport channel it allows to offer
transport services to higher layers.
The E-DCH transport channel is defined by the following characteristics:
Only for UL
Two possible TTI : 10ms and 2ms. From UA06, ttiType parameter under EdchConf is ignored by the
system. 10 ms is always possible and 2ms is possible only if isEdchTti2msAllowed is set to True
Transport block size and Transport Block set size are free attributes of the transport format.
Possibility of HARQ process with retransmission procedures applied at Node B. Max number of
retransmission must be defined. Each transmitted blocks are numbered.
Three HARQ types can be used: Chase Combining/cc, partial incremental redundancy/pir and
full incremental redundancy/fir
Turbo coding with rate 1/3 is used
CRC is 24 bits length
E-TFCI (Transport Format Combination Indication for E-DCH) indicates which format is currently
used for the UL transmission.
Remark: In UA07, ttiType parameter under EdchConf is ignored by the system.

1 HSUPA Principles
1.11 E-DCH 2 ms TTI activation
UE E-
1 AG - 2ms TTI
UE CH
2 UE
3U
10
ms E4 - 8 HARQ process
xCEM UE
5
Cat. 2, 4 & 6 - Special ETFC table
isEdchTti2msAllowed = True - Node B reports 1 FP each 2 ms
- In case of mobility, the RNC
isEdchTti2msAllowed = True reconfigure the TTI depending on
(EdchCellClass) Same Scheduling period
(40 ms) Primary cell capability
Cat. 1, 3 & 5 - 10ms TTI

- 4 HARQ process
When 2ms TTI is not activated all UEs are configured with 10ms TTI

HSUPA
The 2ms TTI is supported in UA06 only by the xCEM board. The 2ms TTI is supported by the UCU-III board in
UA7.1.
When 2ms TTI is activated by setting the parameters isEdchTti2msAllowed under RadioAccessService and
EdchCellClass to “True”, a UE supporting 2ms TTI (i.e. CAT 2, 4 and 6) will be configured with 2ms TTI
using a special ETFC table. In this case, 8 HARQ processes are used. The NB scheduler uses the same
scheduling period for both 2ms and 10ms TTI UEs.
For 2ms TTI UEs, the NB will report 1 FP each 2ms. If the UE is not supporting 2ms TTI or if the 2ms TTI is
deactivated, the UE will be configured with 10ms TTI.
For mobility, the RNC will reconfigure the TTI during the E-DCH call based on cell capabilities and mobility
scenarios.
Remark: In UA06, ttiType parameter under EdchConf is ignored by the system.
The MAC-e scheduler runs every 40ms for UEs configured with 2ms TTI or 10ms TTI.

1 HSUPA Principles
1.12 HARQ
HARQ Wait for Transmission
UE has resources for

transmission
E-HICH
Update RV Parameters
Transmit Data ACK/NACK
Wait for ACK/NACK Reception
Insert DTX
ACK ACK/NACK/DTX? DTX
Indication
NACK
RadioAccessService
Reset & Free
HARQ Process
Nret = Nret + 1 UlRSetConf
YES Nret > Nret_max NO

EdchParameters
edchHarqMaxRetrans

HSUPA
edchHarqMaxRetrans represents the maximum number of retransmission at Edch HARQ

level. When this maximum is reached the corresponding MAC-e block is flushed and the
HARQ process is freed.

1.12 HARQ
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ
NAck
NAck
NAck
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
Ack
E-HICH UE1
(Downlink Control)
packet1
packet2
packet3
packet4
packet5
packet6
packet7
packet8
packet2
packet9
packet1
packet1
packet1
packet1
packet1
Packet1
packet2
packet1
Packet1
Packet1
E-DPDCH UE1
7
0
6
5
(Uplink Data)
2 ms
HARQ cycle=8x2ms=16ms
E-DPDCH UE2
Packet1 packet2 packet3 packet4 Pa
(Uplink Data)
10 ms
HARQ cycle=4x10ms=40ms
process #1 process #2 process #3 process #4 process #5 process #6 process #7 process #8

HSUPA
Higher reactivity and lower RTT with 2ms TTI.

1 HSUPA Principles
1.13 MAC-e non-scheduled Mode
isSrbOnEdchAllowedWhenTrbOnEdch =True
srbQos.srbSpi =15
isSrbOnEdchForAllEdchCategory =False
RRC (Max MAC-e PDU size for non-scheduled data ) isSrbOnEdchForAllMinSf =False
isSrbOnEdchForAllEdchTti =False
NB
AP (RadioAccessService)
(M
a xM
AC
-e
PD
Us
ize
f or
no
n-s
che
d ule
d da
ta E-DCH (SR
) B)
isEdchTti2msAllowed = True
xCEM
E-
E-
Cat. 6
AG
DC F2+
)
SRB
CH
H( 2S
(T
DC B)
(SG
RB
TR
H( )
)
(SG
+
C 2S
E-D GCH
SR
F4
B)
E-A
Other Cat.
Cat. 6
HSUPA
MAC-e Non-scheduled mode is supported by xCEM only (Non scheduled means sending data by UE without
waiting for E-AGCH from Node B).
This feature is used to carry SRB on E-DCH
Allow to maximize the E-DCH performances when using 2SF2 (TRB) + 2SF4 (TRB + SRB).
The cell should be 2ms TTI capable
Used only for UE cat6
Non scheduled Mode is selected by the RNC in case of SRB on E-DCH
The RNC sends the max MAC-e PDU size to be used by the UE for non-scheduled data to both UE (RRC
message) and NB (NBAP message)
The UE is allowed to send data in the limit of resources allocated by the RNC without asking for a
grant before
This grant is on top of SG (Serving Grant) and can be used by the UE for only non-scheduled data
(SRB in our case)
isSrbOnEdchAllowedWhenTrbOnEdch: Enable the possibility to map SRB on E-DCH in the UL for Cat 6 UE,
while the call is handling RAB(s) over E-DCH
srbQos.srbSpi: SPI used for SRB on E-DCH during a call
isSrbOnEdchForAllEdchCategory: SRB on E-DCH for all E-DCH categories
False: E-DCH cat 6 UE only
True: All E-DCH categories
• isSrbOnEdchForAllMinSf: SRB on E-DCH for all NodeB minSF
False: 2 SF2 + 2 SF4 minSF only.
True: All NodeB minSF
isSrbOnEdchForAllEdchTti: SRB on E-DCH for all E-DCH TTI
False: 2 ms TTI only and 2 ms supported on NodeB
True: 2 ms and 10 ms allowedAll
toRights
use Reserved © Alcatel-Lucent 2011
SRB on EDCH
1 HSUPA Principles
1.14 PS Streaming on HSUPA
NO
Cell E-DCH capable?
isStreamingOnEdchAllowed
YES (edchConf)
NO
UE Release
=
= R7 ?
YES
NO
isStreamingOnEdchAllowed ?
YES
NO
Enabled for Rab Matching?* • In Case of Multi Service or
Multi-RAB
YES
RNC PS Streaming on HSUPA PS Str On DCH

HSUPA
Note: PS Streaming over HSUPA Feature is optionally supported starting UA07.1.2

In case of multi-service - a CS (speech) is yet established - the corresponding RAB combination
« CS(speech)+ PS streaming over E-DCH + SRB (over DCH or E-DCH) is enabled (enabledForRabMatching)
In case of multi-RAB - a PS I/B over E-DCH is yet established - the corresponding RAB combination « PS I/B
over E-DCH + PS streaming over E-DCH + SRB (over DCH or E-DCH) is enabled (enabledForRabMatching),
the feature 34018 multi-RAB on E-DCH is enabled (isMultiRabOnEdchAllowed), and the
edchCombinationList allows the multiplexing on E-DCH of PS I/B + PS streaming .
Supported on xCEM only. Not supported on iCEM and UCU-III.

Has 656 bit MAC-d PDU size,
Supports 2ms or 10ms E-DCH TTI ,
Supports the following RAB combinations :
PS streaming (E-DCH/HS-DSCH) + SRB on DCH
PS streaming (E-DCH/HS-DSCH) + SRB on E-DCH
CS speech (DCH/DCH) + PS streaming (E-DCH/HS-DSCH) + SRB on DCH
PS streaming (E-DCH/HS-DSCH) + PS I/B (E-DCH/HS-DSCH) + SRB on DCH
PS streaming (E-DCH/HS-DSCH) + PS I/B (E-DCH/HS-DSCH) + SRB on E-DCH
CS speech (DCH/DCH) + PS streaming (E-DCH/HS-DSCH) + PS I/B (E-DCH/HS-DSCH) + SRB on DCH.
CS speech can be one of the following AMR configurations: [12.2], [12.2 7.95 5.9 4.75], [12.2 7.4 5.9
4.75] or AMR-WB.
CS data (DCH/DCH) is not supported with any PS streaming RAB.

1 HSUPA Principles
1.15 User Services supported with HSUPA
HSxPA isMonoDirectionalHsdpaRabAllowed
isMultiRabOnEdchAllowed
Stand-Alone
PS I/B HSDPA/HSUPA DL: f(HSD UE category)
PS Streaming HSDPA/HSUPA DL: f(HSD UE category)
Combination
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:
PS Streaming (HSDPA or DCH/DCH) DL: 16,64,128,256,384 or f(HSD UE category,
GBR)
UL: 16,32,64, E-DCH (f(HSU UE category, TTI,
GBR (only for xCEM)))
PS I/B:
DL: f(HSD UE category) UL: f(HSU UE
category, TTI)
CS Conv. Speech + PS Streaming HSxPA DL: f(HSD UE category, GBR)
(CS Conv. Speech +) PS I/B MUX HSxPA DL: f(HSD UE category (only for xCEM))

HSUPA
Unlike multi service on HSDPA, there is no activation flag to enable or disable the multi RAB on HSUPA.
The activation is to be done thought the parameter enabledForRabMatching in UluserService Object for the following
instances:
• Speech + E-DCH
• CSD + E-DCH
• PS Streaming + E-DCH
• Speech + PS Streaming + E-DCH
Note: if the related UlUserService are not allowed to be used by the RAB Matching, there is no fallback on DCH,
implying RAB Assignment Failure during RB Setup.
UE Radio Access Capabilities specification (TS 25.306) includes UE UL DPCH Capability with simultaneous E-DCH
information, which defines the modification of transmission capabilities in uplink in terms of DPCH in case an E-DCH
is configured simultaneously.
TS 25.306 indicates that UE can only support a maximum of 64kbps on DCH with a simultaneous E-DCH configuration
Hence the following combination is not supported (ie. no automatic fallback to 64kbps on DCH) :
• PS Streaming UL:128kbps+PS I/B (E-DCH)
• Corresponding combination with CS is not supported either.
As a consequence, there will be a failure if the RNC attempts to establish the previous combination.
To workaround this issue, it is possible to fallback all (CS+)PS Streaming + PS I/B combinations to DCH.
This workaround is not activated by default but there is a flag to activate it, isMonoDirectionalHsdpaRabAllowed
(RadioAccessService). When set to False, the combinations (CS+)PS Streaming + PS I/B HSDPA are fallbacked on
(CS+)PS Streaming + PS I/B DCH.
Multiple PS I/B on HSUPA Will now be possible with the upgrade to UA7.1 if isMultiRabOnEdchAllowed is set to True:
�� Support of multiple PS I/B RABs on E-DCH requires the support of an additional MAC-d flow.
�� This feature aims at providing support of PS I/B+PS I/B and related combinations with CS on HSUPA
�� The feature is supported only by the xCEM. This feature is not required for OneBTS/UCUIII in V7.1
�� RAB combinations shall be then supported for 2ms and for 10ms TTI as well.
Note: isMultiRabOnEdchAllowed can be set to TRUE only if isMultiRabOnHsdpaAllowed is set to TRUE.

2 HSUPA Scheduler

HSUPA

2 HSUPA Scheduler
2.1 Grant Allocation
Total interference contribution Allocated Power / interference

contribution decides which
transport format can be used,
BTS so which throughput is
Absolute
& relative available
grants
UEn Interference
contribution
UE knows which Transport

UE3 IC UEn format it can use
UE1 IC
UE2 IC RNC sends
Required power to use the ETFC

ETFC
UE1 corresponden
ETFC
ce info at call
UE3 ETFC
UE2 setup
ETFC
Node B
ETFC
z Grants a
ETFC
Serving_Grant certain
ETFC power
ETFC
ETFC UE might use

Acronyms ETFC all or part of
TFC: Transport Format Combination (E-TFC => E-DCH) the allocated
TFCI: Transport Format Combination Indicator (E-TFCI => E-DCH) power

HSUPA
The scheduling principles give the ability to the Node B to control the set of TFCs a UE may use.
More precisely, the MAC protocol layer is in charge of the selection of the appropriate Transport format for
each Transport channel, using the Transport Format Combination Set (TFCS) assigned by the RRC.
Grants are allocated to each E-DCH UE. These UEs can then tune the power level at which they are allowed
to transmit. Each UE can adapt its throughput according to the grants by selecting the E-TFC in the E-TFCS
that is compatible with the granted power.
Grants are valid until new ones are sent. Mobiles can be addressed individually (primary E-RNTI) or in
groups (secondary E-RNTI).
A UE may be active or inactive on E-DCH. Any inactive UE has no grant allocated (grants are zero). To send
data, it has to send a Scheduling Information (SI) message to ask for grants.
Grants functions
The scheduling system is based on grants. Grants are computed by the scheduler:
to ensure some fairness between al users.
to prevent the global UL interferences level from exceeding a threshold (RTWPmax standing for
Received Total Wideband Power).
to make sure each UE will adapt its throughput on E-DPDCH according to the grants it has received.

2 HSUPA Scheduler
2.2 E-TFCI Table Configuration – Virtual UE Category
The RNC configure the reference E-TFCI table according to RAB combination,
virtual UE category and E-DCH TTI
The virtual UE category is the minimum of UE category and primary cell
category
Primary cell category is defined as follows
Min SF Node B TTI Capability Primary Cell Comments
Category
1*SF4 10 1
1*SF4 2 2 1*SF4 with 2ms is not
supposed to be common; in
this case NodeB category is
assumed to correspond to
2*SF4 and 2ms TTI
2*SF4 10 3
2*SF4 2 2
2*SF2 10 5
2*SF2 2 4
All other cases 16 In this case virtual UE
category=UE category
HSUPA

2 HSUPA Scheduler
2.3 E-TFCI Table Configuration – Virtual UE Category example
Example: UE CAT6 on E-DCH Cell with xCEM
Step1: primary Cell HSUPA Category is

computed based on min SF capability and
E-DCH TTI
Cell HSUPA Category = 3
Step2: Virtual UE category is computed as

the minimum between Primary cell HSUPA
category and HSUPA UE category
Virtual UE Category = min{ 3;6 } = 3
•Step3: EdpchParameters instance is

selected based on Virtual UE CAT and E-
DCH TTI
UECategory3EdchTti10ms
HSUPA

2 HSUPA Scheduler
2.4 Priority Info Support (iCEM and xCEM)
Priority Info is taken into account by both iCEM and xCEM HSU schedulers.
The E-DCH SPI is given by OMC mapping tables according to traffic class and
ARP/THP info provided in the RANAP RAB request
Restriction: Only 4 priority levels are considered by both iCEM and xCEM
For each SPI we configure a E-DCH

priority weight
The scheduler take into account the
SPI info in the grant allocation so the 15
data rate between UE is proportional
to the priority weight
eDchSpiRelativeWeight [E-DCH SPI]
(edchConf)

HSUPA
Restriction: Only 4 priority levels are considered by both iCEM and xCEM.
Since only 4 behaviors are possible but 16 SPI values available, the operator shall ensure that only the
highest SPI values are used.
Similarly to MAC-hs scheduler, the MAC-e scheduler support relative weighting according to SPI in order to
obtain relative throughput when UEs are under same radio and traffic conditions.
Internal metrics for fair processing (fair index and average consumption per UE of shared resources) take
SPI into account to allow more service to high priority UEs than low ones of the same serving cell at iso
radio and traffic conditions.
A weighting vector (1 by 4) EdchSpiRelativeWeight will be provisioned at OMC-B to configure the relative
weight of the SPIs in similar way to HSDPA. This parameter is common for both iCEM and xCEM.
Priority Info is taken into account by both iCEM and xCEM HSU schedulers.
The E-DCH SPI is given by OMC mapping tables according to traffic class and ARP/THP info provided in the
RANAP RAB request.

2 HSUPA Scheduler
2.5 Scheduler iCEM: Principle
Number of UE asking for Grants
UE max bit rate capability
E-BBU capacity
UL radio load Scheduling Information from UE:
UE power headroom
available for E-DCH UE User Buffer
Happy Bit
iCEM
E-DCH Scheduler
Absolute Grants
Allocated Per UE
periodicityOfSchedInfoGrant
happyBitDelay
periodicityOfSchedInfoNoGrant
(EdchClass)
(EdchClass)
HSUPA scheduler runs every 40 ms

HSUPA
The scheduling process will distribute grants to UE according to :

1. Cell’s limitations :
the cell load level (RTWP measured periodically each 100ms)
HW and SW resources in Node B (E-BBU capacity)
2. Fairness :
UE satisfaction (happy bit carried in E-DPCCH) with rate scheduler
UE for which satisfaction level is below 0.5 (averaging of happy bit) will be a priority
candidate to have more resources if some are available once fairness between UE is
ensured
Data payload already transferred
3. UE limitations :
UE available power (UPH reported in System Information SI message defined by
UPH=UE_MaxTxPower / Pdpcch)
increasing grants for a UE which is already at maximum transmission power is useless. UE
will not be granted more than UPH-(1+βd2/ βc2+βhs2/ βc2+βec2/ βc2)
UE data (buffer status reported in SI, ie. DataQueueSize)
UE with no data to transmit (inactive) will be granted ZERO_GRANT
active UE will not be granted more than the maximum e-TFCI corresponding to the limit
DataQueueSize/Period

2.5 Scheduler iCEM: Principle
2.5.1 iCEM MAC-e Scheduler
Interference Contribution
UL Load
whole E-DCH cell capacity

rateScheduling equally shared by all mobiles
Time
the higher the number of E-DCH
the lower the user data rate
BTSEquipment
edchSchedulerAlgorithm
eDchSpiRelativeWeight [E-DCH SPI]

Fair but Proportional to
(edchConf)

HSUPA
Only one kind of scheduler is available in UA05: the Rate Scheduler.

In this scheme, all E-DCH active users (having data to transmit) are transmitting (having grants)
simultaneously.
They share resources in a fair way,the general principle being that :
hardware resources are shared equally between all active cells (containing at least one active
user)
hardware resources assigned to an active cell are shared equally between all active users of
this cell
the cell load (apart from R99 part) is shared equally between all active users of this cell
From this is derived a fairness index that represents to the grant corresponding to a fair allocation
between active UE.
Grants are modified when:
the number of active user changes (one becomes active or one becomes inactive)
R99 uplink radio load has changed significantly
Periodically, each T_Threshold_TTI (100ms) for UEs that are granted above the fairness
index. The timer parameter is edchRateSchedulerOptimisationTimer.
Periodically each 500ms
On top of that, once a UE have been fairly served, remaining available resources (hardware or
radio resources) are allocated for a given period to other UE ranked as follows: UE with
ZERO_GRANT but with data to transmit (according to SI), then UE not satisfied (satisfaction
level < 0.5) then UE not served fairly
But internal metrics for fair processing (fair index and average consumption per UE of shared resources)
take SPI into account to allow more service to high priority UEs than low ones of the same serving cell.

2 HSUPA Scheduler
2.6 Scheduler xCEM: Principle
Number of UE asking for Grants
UE max bit rate capability xCEM E-DCH
processing capacity
UL radio load Scheduling Information from UE: Maximum Target RTWP
UE power headroom
available for E-DCH UE User Buffer
Happy Bit
xCEM
E-DCH Scheduler
Relative and Absolute Grants

Allocated Per UE
periodicityOfSchedInfoGrant
happyBitDelay
periodicityOfSchedInfoNoGrant
happyBitDelayEdchTti2ms
periodicityOfSchedInfoGrantEdchTti2ms
(EdchClass) periodicityOfSchedInfoNoGrantEdchTti2ms
(EdchClass)
HSUPA scheduler runs every 40 ms

HSUPA
The task of the scheduler is to fairly distribute the available E-DCH load among the E-DCH users while
keeping the uplink load within a limit UL load configured by RNC. The resources are allocated essentially
via relative grants (RGs) and also via absolute grants (AG) for activation and deactivation.
The MAC-e scheduler runs every 40ms (corresponding to a HARQ round trip time for 10ms TTI). The MAC-e
scheduler considers following inputs:
Cell resources: CE processing, maximum RTWP
Measurements: RTWP, E-DCH load
UE status: UE category, SI
NodeB resources
E-DCH processing resources are pooled across cells handled by one xCEM.
The Maximum Target Received Total Wide Band Power sent over NBAP in PHYSICAL SHARED
CHANNEL RECONFIGURATION REQUEST message. It is derived from OMC-R parameters
FddCell→TotalRotMax and FddCEll→RtwpRef. RTWPref will be adjusted according to self-learned
RTWP value in the NodeB, as well as the resulting RoT.
The target UL load Ltarget is derived and is defined as the most restricting criterion among above
limitations
Measurements
RTWP is reported every 100ms to the MAC-e scheduler.
xCEM estimates every 10ms the average total UL load LE-DCH generated by E-DCH serving users.
The available E-DCH load is derived and corresponds to Lavailable, E-DCH = Ltarget - Lnon E-DCH. If
Lavailable, E-DCH <= 0, then the cell is overloaded.
UE specific information
Happy bit status
Scheduling information
Reference scheduling grant SGref, i, taken from previous scheduling interval
Average transport block size i.e. PHY throughput

2.6.1 xCEM MAC-e Scheduler
Received Amount of
Available load Estimation La xCEM data from the last
MAC-e Scheduler scheduling period
Hypothetical load Lh
Happy Bit
Lh ≤ La Lh > La
All requests 1. Reduce Non-Serving Users

are granted 2. Reduce Serving Users:
•UEs ranking according to:
• Throughput
• SPI Relative Weight RWj
• SPI Scheduling Weight SWi
See next Slide

HSUPA
The scheduler calculates the requests from serving user for the next scheduling interval using the following
information: received amount of Data from the past scheduling period and status of the Happy bit received
on eDPCCH.
It computes available load and estimates the hypothetical load Lh which is the required load if all request
can be fulfilled.
If Lh ≤ La then all request are granted
Else, some request must be downgraded :
Reduce non-serving users if any
Reduce serving users:
UE are ranked according to a Relative Weight RWi (eDchSpiRelativeWeight configured at
OMC), and a Scheduling Weight, SWi which depends on eDchServiceParameterSet:
if Average Throughput is near Rmax then SWi is high so PFi low, this UE will be the
first to be down-granted
if Average Tput is near Rmin then SWi is low so PFi high, this UE will be the last to
be down-granted
if Rmin< Average Tput < Rmax then Swi = 1, UE is downgraded only according to RWi
The scheduler de-grants the UE with lowest priority and update Lh and repeats the
procedure as long as Lh>La.

2.6.2 xCEM MAC-e Scheduler – Scheduling Weight (SW)
serviceMinRate serviceMinRate
serviceMaxRate QId0 QId1 QIdN
serviceLowRate non GBR MAC-d flow

serviceHighRate
serviceMaxRate
serviceBFactor
serviceKFactor
COST x SW
(edchServiceParameterSet)
Decrease OR Increase
MAC-hs GBR - serviceLowRate
COST
serviceLowRate
Throughput R
<
serviceMinRate
GBR MAC-d flow OR
Throughput R
>
serviceMaxRate
MAC-hs GBR + serviceLowRate
serviceHighRate
R< serviceMinRate Or R> serviceMaxRate : SW(u,q) = serviceBFactorω

serviceMinRate <= R<= serviceMaxRate : SW(u,q) = 1
HSUPA
For a given SPI, priority of the queue is increased (or decreases) by multiplying the cost function by a
Scheduling Weight (SW) if the MAC-d throughput R is lower (or higher) than the parameter serviceMinRate
(or serviceMaxRate). The parameters serviceBFactor and serviceKFactor are shaping factors for
increasing and decreasing the priorities:
the larger the values for serviceBFactor and serviceKFactor the more the priority is decreased or
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
if serviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In
this case the priority of a user is neither decreased nor increased.
The Scheduling Weight is computed as follow:
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:

2.6.3 xCEM MAC-e Scheduler – Degrant Mechanism
Lh > La
schedulingPrioritylevel
serviceBFactor 1. Reduce Non-Serving Users
serviceKFactor 2. Reduce Serving Users:
serviceMaxRate •UEs ranking according to:
serviceMinRate • Throughput eDchSpiRelativeWeight
(EdchServiceParameterSet) • Relative Weight RWj (EdchConf)
• Scheduling Weight SWi
Rmax Rmax
Rmax Average Tput
Rmin Rmin
Average Tput Average Tput
Rmin
PFi SWi = 1 SWi

SWi UE is downgranted only according to RWi PFi
This UE will be the last to be down-granted This UE will be the first to be down-granted
The scheduler de-grants the UE with lowest priority and update Lh and repeats the procedure as long as Lh>La
HSUPA
The B and K factors increase or decrease the priority of a user depending on its measured data rate
The priority becomes the higher the more the data rate R falls below Rmin
The priority becomes the smaller the more the data rate R exceeds Rmax
At R = Rmin, the priority is 1 for all B and K factors
At R = Rmax, the priority is 1/B for all K factors
The MAC-e scheduler de-grants the UE with lowest priority and updates the hypothetical load and
repeats the procedure as long as Lhypothetical > Lavailable. Each UE will be de-granted by 1 step at
the maximum.
Priority Weighting (Rmin = 40 kbps, Rmax = 60 kbps) Priority Weighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7 B = 5, K = 7 B = 3, K = 7 B = 1, K = 7 B = 7, K = 7 B = 7, K = 5 B = 7, K = 3 B = 7, K = 1
7
- When average throughput for MAC-d flow#i is lower than serviceMinRate (configured per Scheduling
7
Priory Level) the MAC-e scheduler shall increase the rank until the average throughput is equal to
6 the serviceMinRate. The resources are taken from6 the MAC-d flows that have an average throughput
5 higher than their serviceMinRate and especially those
5 with an average throughput higher than their
serviceMaxRate. In overload situation, UEs in bad RF conditions will remain with throughput lower
Priority
Priority
4 4
than serviceMinRate. However, this behavior can be overruled by adjusting the serviceBFactor and
3 serviceKFactor to allow UE with bad RF conditions3 to achieve serviceMinRate.
2 2
1 - When average throughput for MAC-d flow#i is higher1 than serviceMaxRate (configured per
0 Scheduling Priory Level) the MAC-e scheduler shall0decrease the rank until resources are given to
20 those
30 with 40
average 50throughput
60 70 than serviceMinRate.
lower 80 20 30 40 50 60 70 80
Data Rate [kbps] Data Rate [kbps]
When the average throughput is between serviceMinRate and serviceMaxRate, a given {UE, MAC-d
flow} will be ranked higher if RF conditions are better. {UE, MAC-d flow} with same RF conditions,
but different SPI, will be ranked considering edchSpiRelativeWeight.

3 HSUPA Radio Load & Interference Management

HSUPA

3.1 UL Radio Load Monitoring: needed for E-DCH scheduling
totalRotMax
RTWP = Received Total Wideband Power rotPredictionCorrection (FDDCell*)
Rise Over Thermal: RoT = RTWP / Thermal Noise rotMarginPrediction
(EdchConf)
RTWPref + totalRotMax typical: 6dB (=75% UL load) UL overload
rtwpMaxCellLoadCacActivation
(BTSCell) E-DCH traffic
Available load
for E-DCH
rtwpMaxCellLoadNonEdch
R99 CAC, BTS level
typical: 50% (=3dB) Increase to
cope with
E-DCH
interf.
R99 traffic R99 RoT sent to RNC
R99 traffic + Interference for cell color
+ Interference calculation
RTWPref
Thermal Noise Thermal Noise
No E-DCH With E-DCH

HSUPA
Rise Over Thermal: RoT = RTWP / Thermal Noise

The RNC calculates RoT using Thermal Noise value.
Two thresholds are defined:

Max RTWP for total UL traffic (R99/E-DCH).
Max RTWP for non E-DCH traffic only used for R99 CAC at the cell level.
E-DCH traffic is assigned the unused UL load up to the max RTWP.

Non E-DCH load (i.e. R99 + interference) will increase to cope with the E-DCH interference (as it was the
case for HSDPA).
RTWP measure is regularly sent by the BTS to the RNC for cellColour.
Once an R99 call is accepted, it will not be dropped even if the non E-DCH load exceeds the max
specified.
totalRotMax is implemented on FDDCell->Class2PscrParams and FDDCell ->Class3PscrParams

3.2 UL Radio Load Monitoring: Defense Mechanism
rtwpTimeDetection
RoT (BTSCell)
All users are de-granted

All HARQ acked
rtwpTimeDetection
rtwpMargin
(BTSCell)
totalRotMax
Time
ALARM

HSUPA
A defense mechanism is introduced in the BTS :

when the RoT exceeds totalRotMax plus rtwpMargin during a period greater than
trtwpTimeDetection then:
an alarm is raised
all E-DCH UEs are de-granted
all active HARQ processes are acknowledged to avoid retransmissions.
The alarm is reset when:
all E-DCH UEs are de-granted
the RoT is below totalRotMax
Note that the parameters rtwpMargin and rtwpTimeDetection are not used for xCEM overload algorithm.
The xCEM overload algorithm is trigged when the average non E-DCH load, estimated based on the last
received RTWP measurement, is higher than the “E-DCH Max load” corresponding to RoT_max setting.

3.3 UL Radio Load : Self-interference issue with E-DCH
Poor orthogonality between different UL codes of a same user for
channel profiles with large time-diversity order (Vehicular profiles)
When focusing on a given UL code (e.g. the DPCCH),
a part of other codes (e.g. E-DPDCHs) power is seen as interference
E-DPDCHs
High rate transmission on E-DCH
Rx Signal
Code Power
at Node B Increase of “Self-interference”
Decrease of SIR
(“SIR”: DPCCH SIR used in
DPDCH UL Inner-Loop Power Control)
DPCCH DPCCH
SIR SIR
Part of user signal power seen as

Thermal noise + interference by DPCCH
Interference i.e. « Self-interference »
from other users

HSUPA

3.4 Self-interference issue on UL Noise Rise
High rate transmission on E-DCH
or “SIR”: DPCCH SIR used in
UL Inner-Loop Power Control
Increase of “Self-interference”
UL Inner-Loop Power Control:

Decrease of SIR Node B controls UE Tx power in
order to maintain SIR as close as
possible to SIR Target
Increase of UE Tx power due to UL ILPC

since power ratio E-DPDCH/DPCCH
βed2/β
(β βed2) is constant for a given grant
Increase of E-DPDCH Tx power
Channel profile Channel profile
with good with poor
orthogonality orthogonality UL Radio Overload Detection
all E-DCH users in the cell are
UL noise rise converges UL noise rise degranted to Zero
to a new working point diverges
E-DCH throughput degrade

HSUPA
Solution to avoid drift of UL noise rise :
When channel profile has poor orthogonality, MAC-e scheduler should allocate lower grant than when
orthogonality is good.

3.4.1 First solution
Limitation of maximum E-TFCI

MAC-e scheduler is configured so it cannot grant higher than E-TFCI 89
4
x 10 3GP P TB ta ble (TTI 10 ms ) E-DP DCH power vs . trans port block s ize
2 30
1.8
10ms TtiTa ble0 25
E-DP DCH power re lativ to DP CCH (dB)

1.6
10ms TtiTa ble1
1.4
Tra ns ort block s ize (bits )
20
1.2
1
Max E-DCH TBS 15
0.8
10
0.6
0.4
5
0.2
0 0
0 20 40 60 80 100 120 140 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Tra ns ort block s iz e index TB s ize (bits ) 4
x 10
E-TFCI = 89
HSUPA
In UA05.0, due to the self-interference issue, the MAC-e scheduler must be configured so it cannot grant
above E-TFCI 89.
This is done by including Reference Power Offset 29 in the {Reference E-TFCI; Reference Power Offset}
table.
Reference Power Offset 29 is a code known by the UA05.x iCEM that tells the MAC-e scheduler not to grant
above the E-TFCI just prior to the Reference E-TFCI corresponding to Reference Power Offset 29, i.e. not to
grant above E-TFCI 89.
At the UE side, the {E-TFCI; Power Offset} couples from E-TFCI 86 to 89 are extrapolated (as specified by
3GPP) from the couple {85; 22}, so the reference couple {90; 29} is transparent for the UE.

3.4.2 Second Solution
Self-interference is taken into account in “UL load prediction” function

⇒ No need to limit maximum E-TFCI
e-modem e-codec (MAC-e Scheduler) Total

UL
γ Goffset load
Main Orthogonality
Channel loss Goffset UL Load
Div Estimation Estimation Processing Prediction
βed
rotOrthogonalityEstimation SIR Goffset : Grant

Estimation of (EdchConf)
orthogonality degree Added to SIR in “UL Load
( γ ) of channel Prediction” module
profile experienced
by user Activation flag
Estimation based on relative If set to Off then self-interference is not taken into account (Goffset=0)
delays and amplitudes of
paths.

HSUPA
“Self-interference in MAC-e Scheduler” feature can be activated via rotOrthogonalityEstimation

activation flag under EdchConf object.
Taking self-interference in UL load prediction for HSUPA scheduling avoids UL noise rise overload for
Pedestrian B and Vehicular A channel profiles.

4 HSUPA Power Management

HSUPA

4.1 DL Power Management: RNC level
SHO margin P MaxCell
Max Power for

HS-DSCH & HS-SCCH,
RNC view
P traffic
E-AGCH & E-HICH
to be transmitted
P minHsdpa to the NodeB
E -DCH RadioAccessService
OCNS ( opt.)
CCC RNC
FDDCell DedicatedConf
EdchResource edchCellClassId EdchCellClass
eagchErgchEhichTotalPower

HSUPA
At RNC level, some power is reserved for E-DCH downlink channels in the same manner as the RNC
level power reservation performed for common control channels.
The aim of this power reservation at RNC level for E-DCH DL channels is to perform CAC of DL DCH traffic,
i.e. this power is not allowed to be used by DL DCH traffic at CAC (as it is the case for the power reserved
at RNC level for CCC channels).

4.2 DL Power Management: NodeB level
BTSEquipment
E-AGCH BTSCell
eagchPower
E-DCH
EdchConf
E-HICH ehichPowerSignature
E-RGCH ergchPowerSignature
no PC for iCEM = fixed

eagchPowerControlMode
ehichPowerControlMode
ergchPowerControlMode
PC for xCEM = dynamic
OR fixed eagchPowerControlModeXcem

HSUPA
At NodeB level, the DL power for E-AGCH, E-RGCH/E-HICH channels is dynamically allocated on a 2ms basis
when there is a need to address E-DCH users on these channels.
The power that is not used by these channels can be used for HSDPA DL channels (HS-SCCH and HS-
PDSCH).
In this release:
These channels are not power controlled for iCEM board but power controlled for xCEM board:
Therefore Power Control Mode parameters are set to fixed value for iCEM:
eagchPowerControlMode
ehichPowerControlMode
ergchPowerControlMode
eagchPower is the power allocated for one E-AGCH (up to 3 E-AGCH can be used). At each TTI, only one
UE can be addressed on each E-AGCH code.
ehichPowerSignature is the power allocated for one E-HICH signature (up to 15 (resp 40) E-HICH
signatures can be used for iCEM (resp xCEM)).
ergchPowerSignature is the power allocated for one E-RGCH signature (up to 15 (resp 40) E-HICH
signatures can be used for iCEM (resp xCEM). Only the common E-RGCH is used in case of iCEM.
One HICH/RGCH is defined for iCEM per cell and up to 4 HICH/RGCH can be defined per cell for xCEM.
E-DCH DL Channels PC can be enabled for xCEM when eagchPowerControlModeXcem parameter is set to
Dynamic.

4.2 DL Power Management: NodeB level
4.2.1 E-DCH signaling channels Power Control Parameters
BTSEquipment
BTSCell
pMaxDlEDCH
E-AGCH PEAGCH(k) = eagchPowerOffset
PEDCH(k) + POEAGCH EdchConf
PEDCH(k) = f(CQI)
E-HICH PEHICH signature(k) = ehichErrorProbability

minPowerCorrection
PEDCH(k) + POEHICH signature
maxPowerCorrection
pMinDlEDCH
E-RGCH PERGCH signature(k) = nonServingEHICHPowerOffset
PEHICH signature(k) + POERGCH/EHICH powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset
E-AGCH, E-HICH and E-RGCH can be power controlled in serving cell only

HSUPA
xCEM (iBTS) Behavior:

E-AGCH, E-RGCH and E-HICH transmitted by the serving cell can be power controlled as well on xCEM,
based on the received CQI reports. The power allocated on an E-DCH DL control channel shall be higher
than EdchConf→pMinDlEDCH but shall not exceed EdchConf→pMaxDlEDCH (offset compared to P-CPICH).
The power allocated on E-AGCH is based on the received valid CQI (once every subframe at the maximum,
could be slower depending on CQI feedback cycle, CQI repetition factor).
If activated, the power control for AGCH is based on CQI:
The AGCH is only sent by the serving radio leg
Since HS-DSCH is the DL RB for HSUPA ⇒ CQI is always available
Fast update period (each CQI)
If fixed power is used on E-AGCH, the transmit code power of any dedicated E-AGCH channel on the E-DCH
serving NodeB shall be equal to EdchConf→eagchPowerOffset dB with respect to the PCPICH level of the
cell where the channel is setup.
The power of the E-HICH shall be such that the E-HICH error rate has the value defined by NodeB parameter
EdchConf→ehichErrorProbability (provided the outer loop correction is within the range
[EdchConf→minPowerCorrection, EdchConf→maxPowerCorrection]).The power of the dedicated E-RGCH
on the E-DCH serving NodeB shall be such that the power offset between the E-HICH and the E-RGCH is
equal to EdchConf→powerOffsetERGCHServingNoSHO for both the serving and peer-serving E-RGCH
leg(s).
Non-serving E-RGCH legs as well as non-serving E-HICH legs are sent with fixed power
(EdchConf→commonErgchPowerOffset and EdchConf→nonServing EhichPowerOffset respectively). In
case 2ms E-DCH TTI is configured, an additional offset (internal parameter) shall be used to cope with the
fact that in this case EAGCH, E-RCH/E-HICH are not transmitted repeatedly.
Note that EdchConf→eagchPowerControlModeXcem activates power control on all E-DCH DL control
channels.

4.3 UL Power Management
ILPC SIR Target Update
NodeB level
OLPC
βc SIR
estimation
R99
βd
BLER
R5 β hs estimation
RNC level
E-DCH Throughput
deltaEdpcch
R6 β ec E-DPCCH PO
β ed E-DPDCH PO + E-DCH TBS
referenceEtfciPowerOffset
edchTfcsTableIndex
HSUPA
E-DCH is power controlled as for R99:

The inner loop power control (cell level) is based on the DPCCH SIR estimation and comparison with
the SIR target (±1 dB at each slot).
The outer loop power control (RNC level) is based in UA05.0 on DPDCH QoS (CRC), not the E-DPDCH
=> potential issues when there is no TRB on the DPDCH since the SRB is rarely transmitted.
Workaround for the OLPC:
Disable the OLPC by setting the min and max SIR target to the same value for the
PS_EDCHxSRB_3_4K UlUserService
The E-DCH throughput is depending on the E-TFCI Transport Block Size transmitted by the UE which is itself
depending on the E-DPDCH Power Granting
The user is allowed to use a subset of authorized E-TFCI.
A {E-TFCI; Transport Block Size} table defines for each E-TFCI (E-DCH Transport Format
Combination Indicator) a corresponding Transport Block Size. Four {E-TFCI; TBS} tables are
defined in 3GPP TS25.321: 2 tables corresponding to 10ms TTI (i.e. “10ms TTI E-DCH TBS Table
0” and “10ms TTI E-DCH TBS Table 1”) and 2 tables corresponding to 2ms TTI (i.e.“2ms TTI E-
DCH TBS Table 0” and “2ms TTI E-DCH TBS Table 1”). All 4 tables are available, i.e. for each E-
DCH TTI type either one of the two corresponding tables may be configured.
For 10ms TTI and 2ms TTI, it is strongly recommended to use respectively “10ms TTI E-DCH TBS
Table 1” and “2ms TTI E-DCH TBS Table 1”. edchTfciTableIndex ‘Table 0’ (2msTtiTable0 and
10msTtiTable0) must not be used.

4.3.1 Closed Loop Power Control
Inner loop
Outer loop
RB Log Transp Phys RNC calculates the BLER (CRC)

SRB DCCH DCH DPDCH UE Tx on DPDCH
DPCCH BTS sends packets to RNC => RNC finds new SIRTarget to
TRB DTCH E-DCH EDPDCH obtain the needed BlerTarget
EDPCCH
RNC sends new SIR Target
BTS compares SIR target

with DPCCH SIR
BTS sends power control
commands at 1500 Hz
to obtain SIR
RadioAccessService
ulUserService/PS_EDCHxSRB_3_4K ulRbSetConf/SRB
UlOuterLoopPowerCtrl/0 dynamicParameterPerDch
ReferenceUlRbSetList/0 blerQualityList
ReferenceUlRbSetConfId blerTarget

HSUPA

4.3.2 Scheduling and Power Offset
RNC
RadioAccessService
RL reconf prepare
RB setup
The UE finds At call set-up, RNC sends edchTfcConf edchUserService
the whole (ETFCI vs. PO) table - E-DCH MAC-d flow PO
using the reference ETFCI POs - PO for SI
- Reference ETFCI Pos edchMACdPowerOffset
- E-DPCCH PO powerOffsetForSchedInfo
BTS sends grants the UE according to
available resources and UE needs
ReferenceTfciConfList
According to the grant it has
received, its needs and available
power, the UE chooses the ETFCI deltaEdpcch referenceEtfci
PowerOffset
RB Log Transp Phys

DPDCH
SRB DCCH DCH UE Tx
DPCCH
TRB DTCH E-DCH EDPDCH PO (relative to DPCCH) from ETFCI/PO
EDPCCH table
PO EDCH Per MACD Flow from RB setup
PO EDPCCH (relative to DPCCH) from RB setup

HSUPA
The E-DPCCH is power controlled relatively to the uplink DPCCH by the means of a pre-defined offset ∆E-
DPCCH.
The E-DPDCH is also power controlled relatively to the uplink DPCCH.
There is an offset per E-DCH MAC-d flow and then the power offset of the selected E-DCH Transport
Format Combination is added.
The power offset needed for each E-DCH TFC is interpolated from the reference E-TFC(s) than
are provisioned by the operator. The UE selects one of the E-TFC than fits its needs – possibly
the highest- and that it is allowed to use according to its grants.
These offsets are not reconfigured during the call.

4.3.3 UL Outer Loop Power Control on UL DPDCH (UA05.0)
E-DCH OL Power Control

is based on CRCI relative
E-DCH to the UL DCH channels
HS-DSCH
UL Data Transfer (PS I/B) ulUpSirStep
DL Data Transfer
(DynamicParameterPerDch)
(PS I/B)
RNC
Iub
DCH blerTarget
Upper Layer Signaling
initialUlSirTarget Partial Partial

DCH 1 OLPC DCH 2 OLPC
isUlOuterPCActivated SIR Target OLPC

Update Master
(UlUserService / UlOuterLoopPowerCtrl)

HSUPA
Aim of Uplink Outer-Loop Power Control for DCH is to maintain a certain radio link quality for each UL DCH
transport channel.
UL OLPC allows fixing optimal balancing between:
UE Tx power and audio quality (for speech)
UE Tx power and RLC retransmissions (for data)
Principle:
RNC monitors BLER on each UL transport channel, using CRC Indicator of selected UL DCH Iub data
frame
RNC adapts SIR Target (“SIR Target”: UL DPCCH target SIR) so that BLER on each UL transport
channel meets target BLER for this channel
In UA05.0, the Open Loop PC is based on the UL quality of the associated UL DCH channel, means on the UL
SRB data transmission.

4.3.4 UL OL Power Control on HARQ retransmission (UA05.1)
HS-DSCH E-DCH E-DCH OL Power Control

UL Data Transfer (PS I/B) is based on Number of HARQ
DL Data Transfer
(PS I/B) NACK of the E-DCH channel
ulSirStep
(DynamicParameterForEdchTti10ms)
(DynamicParameterForEdchTti2ms
RNC
DCH
Upper Layer Signaling
Iub
Computation of Partial SIR Target (E-DCH case):

• Update frequency: On reception of UL E-DCH Data Frame by RNC, i.e. every 10ms or 2ms.
•Computation method: Partial SIR Tg (k+1) = Partial SIR Tg (k) + ulSirStep x (NHARQ – NHARQ Target)
known from
N of HARQ Retransmissions IE set via
blerTarget
(BlerQualityList)
HSUPA
UL Outer-Loop Power Control (UL OLPC) for E-DCH in UA05.1

Handled by “E-DPDCH Retransmissions for DPCCH SIR Adaptation” (34172) feature
Aim: Maintain a certain radio link quality for the E-DCH transport channel.
UL OLPC allows fixing optimal balancing between UE Tx power and number of HARQ retransmissions.
Principle:
RNC monitors number of HARQ retransmissions on E-DCH transport channel,using Number of HARQ
Retransmissions IE enclosed in E-DCH Iub data frame.
RNC adapts SIR Target (“SIR Target”: UL DPCCH target SIR) so that average number of HARQ retrans
on E-DCH meets target number of HARQ retrans (NHARQ Target)
NHARQ Target: fixed parameter in UA05.1
Simulation results showed that System simulation: Variable SIR Target

optimal NHARQ Target depends on: Multi-user Mono-user
•1200
Throughput [kbps]
• Number of E-DCH users •1100

E-DCH RLC User
in the cell •1000

• UL radio load •900
•800
•700
Improvement in UA6 by •600
•500
introducing adaptive •400
•0 •0.2 •0.4 •0.6 •0.8 •1 •1.2 •1.4
NHARQ Target NHARQ Target

4.3.4 UL OL Power Control on HARQ retransmission (UA05.1)
4.3.4.1 SIR Target update decision
SIR Target
NodeB 1
UL OLPC Master •• Update of SIR

NodeB 2 Target, according
to all Partial SIR
Targets
Partial Partial Partial
SIR Target SIR Target SIR Target
(DCH 1) (DCH 2) (E-DCH)
UL OLPC MAChine (DCH 1) UL OLPC MAChine (DCH 2) UL OLPC MAChine (E-

DCH)
CRCI of UL DCH 2 N of HARQ

CRCI of UL DCH 1
Retransmissions IE

HSUPA
Update of SIR Target, according to all Partial SIR Targets:

if at least 1 Partial SIR Target increased since previous update:
SIR Tg = max { Partial SIR Targets }
if all Partial SIR Targets decreased:
SIR Tg = min { Partial SIR Targets }
Update triggering:
Periodically
On event,
i.e. if 1 Partial SIR Tg increased more than updateThreshold since previous update.
For the UL services with E-DCH, the E-DCH transport channel must be set as a reference channel for the
driving of UL OLPC. This can be done by making sure that an instance of ReferenceUlRbSetList with
referenceUlRbSetConfId set to “UlRbSetConf/PS_EDCH” exists for all UL services with E-DCH. If such
instance of ReferenceUlRbSetList does not exist, it must be created.
Note: The E-DCH TTI2ms calls require high SIR Target values to reach the best performances. A special set
of parameters is defined, allowing SIR target differentiation between E-DCH TTI10ms and 2ms.
eligibleUeCategoryForSirTargetEdch2ms: Eligible UE E-DCH categories for specific SIR target settings (in
case of E-DCH TTI 2ms). The bit 0 corresponds to category 1, bit 1 corresponds to category 2 and so on. The
recommended setting allows having E-DCH UeCategory2, UeCategory4 and UeCategory6 eligible for specific
SIR settings when they are using TTI2ms.
For the UE for which eligibleUeCategoryForSirTargetEdch2ms is set to True, then the SIR target
parameters to be used when 2ms TTI is used are:
initialSirTargetEdch2ms instead of initialSirTarget or initialSirTargetHsdpa
minSirTargetEdch2ms instead of minSirTarget or minSirTargetHsdpa
maxSirTargetEdch2ms instead of maxSirTarget or maxSirTargetHsdpa

4.3.5 E-DCH Adaptive HARQ Control
Number of “active E-DCH users”
S3
maxNumActiveEdchUsersPerCellForS2
(EdchCellClass)
S2
maxNumActiveEdchUsersPerCellForS1
(EdchCellClass)
S1
green yellow red UL Radio Load Color
Cell State = S1 ⇒ NHARQ Target = nHarqRetransTargetS1

ulSirStep
Cell State = S2 ⇒ NHARQ Target = nHarqRetransTargetS2 (DynamicParameterForEdchTti10ms)
(DynamicParameterForEdchTti2ms)

HSUPA
CELL STATE
In UA06, in order to adapt NHARQ Target value according to current number of E-DCH users and UL radio
load of the considered cell, for each cell, a state (Cell State) specific to UA06 34249 feature is computed
and updated. Note that at a given instant, the same NHARQ Target value is used for all the E-DCH UEs for
which the considered cell is the E-DCH serving cell.
Cell State, which can take three different values – S1, S2 and S3, is computed basing on the following
inputs:
Current number of “active E-DCH users” in the cell.
“Active E-DCH users” refers to UEs currently having an E-DCH radio link established with the considered cell
(hence these UEs are in Cell_DCH RRC state), and for which this cell is the E-DCH serving cell.
Current UL Radio Load Color.
The UL Radio Load Color is derived from the non E-DCH UL radio load of the cell. For a detailed description
of the calculation of UL Radio Load Color.
Below figure shows how Cell State is determined according to the current number of “active E-DCH users”
and UL Radio Load Color of the cell. Note that maxNumActive- EdchUsersPerCellForS1 and
maxNumActiveEdchUsersPerCellForS2 parameters are used to set the thresholds for Cell State change on
number of “active E-DCH users” criterion.
The Partial SIR Target related to the E-DCH transport channel (note: in case of SRB on E-DCH, there are two
Partial SIR Targets related to E-DCH.
NHARQ Target, which is used as an input to compute the Partial SIR Target related to the E-DCH transport
channel, can take three different values depending on the current Cell State:
iCEM : Adaptive HARQ control is not used, because

All Rights Reservedlab tests shown2011
© Alcatel-Lucent that there is no gain, and we can even
have degradation. So, we use value corresponding to S1
TMO18256 Issue D0 state.
SG DEN I3.0
4.3.6 Specific case of SRB on E-DCH
2 MAC-d flows are carried on E-DCH

One MAC-d flow for SRB
2 Partial SIR Target computed for each MAC-d flow
One MAC-d flow for TRB
For the SRB MAC-d flow,
NHARQ Target is always taken equal to nHarqRetransTargetS1 (independently from
current Cell State), in order to guarantee short transmission delay.
•
SIR Target
NodeB 1
UL OLPC Master
NodeB 1
Partial Partial
SIR Target SIR Target
(E-DCH SRB) (E-DCH TRB)
UL OLPC UL OLPC
MAChine MAChine
(E-DCH SRB) (E-DCH TRB)
N of HARQ N of HARQ
Retransmissions IE Retransmissions IE

HSUPA
In order to guarantee good link quality for the UL SRB, for the SRB MAC-d flow, the target number of
retransmissions NHARQ Target is fixed and taken equal to nHarqRetransTargetS1 in Partial SIR Target
computation. In other words, for the SRB MAC-d flow, NHARQ Target is not adapted according to current
number of E-DCH users and UL radio load.

4.3.7 Fast Decrease of E-DCH Partial SIR Target
“Fast Decrease” mechanism

Aim: Enable faster convergence of SIR Target when in good radio conditions
For the considered MAC-d flow carried on E-DCH
if more than edchNrOfConsecutiveZeroHarqReTxThreshold MAC-es PDUs are received
without any HARQ retransmission or HFI (HARQ Failure Indication)
then a new formula is applied for Partial SIR Target:
Negative value
Partial SIR Tg (k+1) = Partial SIR Tg (k) + edchSirStepFastDecrease

HSUPA
Once the triggering condition for “Fast Decrease” mechanism has been fulfilled, the Partial SIR Target of
the considered MAC-d flow is updated according to above specific formula at each consecutive E-DCH Data
Frame received without any HARQ retransmission or HFI. “Fast Decrease” mechanism is cancelled as soon as
an E-DCH Data Frame is received with at least one HARQ retransmission or with an HFI, and the Partial SIR
Target is then updated according to the usual formula.

4.3.8 E-DCH Partial SIR Target in case of Soft HO - Definition
HFI Reception Scenarios
Periodically, based on HFI (HARQ Failure Indication) messages received from the E-DCH
serving NodeB (during the last HFI monitoring period), an HFI Reception Scenario is
determined among 4 possible scenarios.
HFI monitoring period = edchOlpcSamplingPeriodTti10ms or edchOlpcSamplingPeriodTti2ms
During HFI monitoring period, the following internal counters are incremented:
Nb HFI frames, Nb valid frames from serving NodeB, Total nb valid frames after frame
selection
At the end of HFI monitoring period, following two quantities are computed:
HFI Ratio = Nb HFI frames / Total nb valid frames after frame selection
Serving Ratio = Nb valid frames from serving NodeB / Total nb valid frames after frame
selection
HFI Reception Scenario determination: Serving Ratio
HFI 0 HFI 1
edchOlpcServingRatioThreshold
HFI 3 HFI 2
HFI Ratio
edchOlpcHfiRatioThreshold

HSUPA
Note: As of 3GPP (TS 25.427), only the E-DCH serving NodeB can send HFI messages.
When the UE is in E-DCH SHO, the analysis at RNC of HARQ Failure Indication (HFI) messages received from
the E-DCH serving NodeB and the E-DCH Data Frames correctly received from the serving and non-serving
NodeB(s) allows adapting the Partial SIR Target(s) of E-DCH MAC-d flow(s) according to the type of E-DCH
SHO scenario detected.
At the RNC, the HFI messages received from the E-DCH serving NodeB and the E-DCH Data Frames correctly
received from the serving and non-serving NodeB(s) are processed to determine an E-DCH SHO scenario (HFI
Reception Scenario).

4.3.9 E-DCH Partial SIR Target in case of Soft HO - Calculation
Partial SIR Target correction according to HFI Reception Scenario

According to the HFI Reception Scenario determined during the last HFI monitoring
period, the following correction is (commonly) applied to Partial SIR Target(s) of E-DCH
MAC-d flow(s).
Partial SIR Tg (k+1) = Partial SIR Tg (k) + edchSirStepHfi [HFI Reception Scenario]
Sequence of 3 values corresponding to HFI 1, HFI 2, HFI 3.
HFI 0: Corresponds to the « normal case » ⇒ No Partial SIR Target correction applied
No SHO or Softer HO case: Partial SIR Target correction always = edchSirStepHfi [HFI1]

HSUPA
PARTIAL UL SIR TARGET COMPUTATION
E-DCH SHO case:

When the UE is in E-DCH SHO (inter-NodeB SHO, not softer HO), on reception of an HFI message from the E-
DCH serving NodeB (and also at the end of the HFI monitoring period if the detected HFI Reception Scenario
is HFI 3), the Partial SIR Target related to the E-DCH transport channel is updated. In case of SRB on E-DCH,
the same correction is applied to both Partial SIR Targets of SRB and TRB.
The Partial SIR Target is updated as follows:
Partial UL SIR Target (k+1) = Partial UL SIR Target (k) + edchSirStepHfi [HFI Reception Scenario]
with edchSirStepHfi being a parameter which contains a sequence of three values selected according to
the HFI Reception Scenario detected – HFI 1, HFI 2 and HFI 3.
Note that HFI 0 corresponds to the “normal” E-DCH SHO scenario, i.e. only few or no HFI are received from
the serving NodeB, and in most cases when an HFI is received the corresponding MAC-e PDU is not decoded
by the non-serving NodeB(s).
Non E-DCH SHO case:

When the UE is not in E-DCH SHO (but UE may be in E-DCH softer HO), on reception of an HFI message from
the E-DCH serving NodeB, the Partial SIR Target is updated as in above formula, but the correction applied
is always taken equal to edchSirStepHfi [HFI 1], regardless to the current HFI Reception Scenario.

4.3.9 E-DCH Partial SIR Target in case of Soft HO - Calculation
4.3.9.1 E-DCH Partial SIR Target in case of Soft HO - Exercise
Active Set = cells 1, 2 & 3

Primary cell = cell 1
UE sends the 5 paquets : ABCDE
Cell 1 receives correctly paquets A & E
Cell 2 receives correctly paquets A & C
Cell 3 receives correctly paquets C, D & E
1) What are the paquets correctly received by RNC

2) Calculate HFI Ratio
3) Calculate Serving Ratio

HSUPA
PARTIAL UL SIR TARGET COMPUTATION
E-DCH SHO case:

When the UE is in E-DCH SHO (inter-NodeB SHO, not softer HO), on reception of an HFI message from the E-
DCH serving NodeB (and also at the end of the HFI monitoring period if the detected HFI Reception Scenario
is HFI 3), the Partial SIR Target related to the E-DCH transport channel is updated. In case of SRB on E-DCH,
the same correction is applied to both Partial SIR Targets of SRB and TRB.
The Partial SIR Target is updated as follows:
Partial UL SIR Target (k+1) = Partial UL SIR Target (k) + edchSirStepHfi [HFI Reception Scenario]
with edchSirStepHfi being a parameter which contains a sequence of three values selected according to
the HFI Reception Scenario detected – HFI 1, HFI 2 and HFI 3.
Note that HFI 0 corresponds to the “normal” E-DCH SHO scenario, i.e. only few or no HFI are received from
the serving NodeB, and in most cases when an HFI is received the corresponding MAC-e PDU is not decoded
by the non-serving NodeB(s).
Non E-DCH SHO case:

When the UE is not in E-DCH SHO (but UE may be in E-DCH softer HO), on reception of an HFI message from
the E-DCH serving NodeB, the Partial SIR Target is updated as in above formula, but the correction applied
is always taken equal to edchSirStepHfi [HFI 1], regardless to the current HFI Reception Scenario.

4.4 Radio Link Control - DL/UL Imbalance Detection
Principle:
The RNC counts the number of E-DCH frames (MAC-e PDUs) not decoded by the serving
NodeB but decoded by a non-serving NodeB
This counter helps network engineering teams to detect UL/DL imbalance issues, without having
to perform a drive test
Counter = Nb Consecutive Good Frames Not Received on Serving NodeB is :

incremented when MAC-e PDU is decoded by a non-serving NodeB but not decoded by the serving
NodeB
Reset to zero when a MAC-e PDU is decoded by the serving NodeB
Counter > edchLinkBalanceThreshold VS.EdchLinkImbalance ++

HSUPA
If the counter has a high value, this means that most of correctly received frames are received from the
other cells (not from the primary cell).
This means that the primary cell has bad UL. As the primary cell is choosen only with DL criteria (CPICH
Ec/No), then one of the reasons of this imbalanced situation could be a bad setting of DL thresholds used to
select the primary cell (event 1d thresholds).

5 HSUPA CAC & Call Management

HSUPA

5.1 HSUPA CAC
edchMaxNumberUserEbbu (iCEM)
edchNumberUserCapacityLicensing Capacity BTSEquipment
edchMaxNumberUserXcem(xCEM)
Core
Network
RRC connection establishment

Service Request
Security Functions
Activate PDP context Request
Rab Assignment Request
NodeB CAC for E-DCH

Radio Link Reconfiguration Prepare
Radio Link Reconfiguration Ready

Radio Link Reconfiguration Commit
Radio Bearer setup
HSUPA
In this implementation, the specific CAC admission process in the RNC for HSUPA is based on the number of
simultaneous authorized users per BBU to limit the degradation of the quality of service. So, there is no
RNC CAC but only the following NodeB CAC is performed :
the HSUPA iCEM resources are handled by E-BBU function
A maximum number of user per E-BBU is defined (edchMaxNumberUserEbbu parameter)
If the limit is reached, the BTS will send a RL Reconfiguration Failure (meaning NodeB CAC
failure). In case of HSUPA CAC failure a fallback to DCH establishment is possible if provisoned.
the HSUPA xCEM resources are handled by M-BBU function
A maximum number of user per xCEM board is defined (edchMaxNumberUserXcem parameter)
Unlike in UA05, edchMaxUsersPerCell: and edchMaxNumberUserNodeB are not more used.

5.2 RAB Allocation Phase
UE NodeB RNC SGSN
RANAP/RAB Assignment Request

e-DCH-MACdFlow-ID,
PowerOffsets AGCH, RGCH, HICH,
PowerOffset EDPCCH), NBAP/Radio Link Reconfiguration Prepare
Reference ETFCI PO, TTI
HARQ (RV table, max retrans )
AGCH OVSF code

ERNTI (1&2) NBAP/Radio Link Reconfiguration Ready
RGCH HICH OVSF code HICH
signature
initial serving grant value
NBAP/Radio Link Reconfiguration Commit
Same as RL Reconf Prep + ERNTI (1&2)

RRC/Radio Bearer Setup AGCH, RGCH,HICH OVSF
HICH signature
Initial serving grant
RRC/Radio Bearer Setup Complete
RANAP/RAB Assignment Response

HSUPA
In this phase, only the NBAP Radio Link Reconfiguration procedure and RRC Radio Bearer Reconfiguration
are modified because of E-DCH.

5.3 HSUPA to DCH Fallback

IU release
RabAssignment
Primary cell change
Incoming Inter-RNC UE involved Hard Handover
Incoming Intra-RNC Alarm Hard Handover AnyCase
Mobility
edchToDchFallbackPermission
HSUPA/HSDPA RB
to established
NoFallBack
HSUPA to DCH Fallback
No edchToDchFallbackSteps
CAC OK ?
Yes
MultiStep MonoStep
HSUPA/HSDPA RB DCH/HSDPA RB DCH/DCH RB

established to established to established

HSUPA
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. Like for HSDPA to DCH Fallback the following CAC failure scenarios trigger such a
fallback:
IU release
Primary cell change
Inter-RNC UE involved Hard Handover
Alarm Hard Handover
HSDPA is directly reconfigured into DCH whereas 2 steps can be provisioned for HSUPA through
edchToDchFallbackSteps parameter:
MonoStep to directly reconfigure HSUPA into DCH
MultiStep to try and reconfigure first into HSDPA (and then into DCH in case of HSDPA CAC failure)

5.4 Always On: degraded2AOnOnly - URA/Cell_PCH used
Always-on (degraded2AlwaysOnOnly, PchRrcStates ≠ none)
Low activity / Inactivity

Activity (UL or DL)
Downsize
(step 1)
Downsize Downsize
(step 2) (step 3)
Inactivity
HSDPA + E-DCH CELL_FACH t

CELL_PCH / URA_PCH
Downsize timer Step 1
timerT1ForHsdpaAndEdch
Downsize
(AlwaysOnTimer)
timerT1ForHsdpaAndEDch timer
Step 2 Downsize
(fachToCellPchTimer, timer
fachToUraPchTimer) Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)
t
Traffic UL/DL
isAlwaysOnAllowed isAlwaysOnAllowed PchRrcStates

(UlUserService) (UlRbSetConf) (RadioAccessService)

HSUPA
When Cell/URA_PCH states are activated, Always-on mechanism is using 3 steps for the downsize part:
Step 1: The user is first downsized after a period T1 of low activity (or inactivity). The associated
timer for HSDPA and E-DCH is a new parameter: timerT1ForHsdpaAndEdch
Step 2: The user is further downsized after a period T2 of inactivity. There is one timer per target
downsized state. Hence the new parameters fachToCellPchTimer and fachToUraPchTimer
Step 3: In URA_PCH or CELL_PCH the user does not have a DTCH assigned, hence it is not possible to
measure activity at RLC/MAC level. The user is released after a period T3 of inactivity. As the
decision can be taken in either the Cell FACH, URA_PCH or Cell_PCH state, there is one timer per
source state. Hence the algorithm uses the new parameters cellPchToIdleTimer /
uraPchToIdleTimer.

5.4.1 degraded2AOnOnly - URA/Cell_PCH not used
Always -on (degraded2AlwaysOnOnly , PchRrcStates = none )
Low activity /
Activity (UL or DL) Inactivity
Downsize
Release
Inactivity
HSDPA + -E DCH
Downsized RB (CELL_FACH)
t
Downsize Release timer
timer (timerT2)
(timerT1ForHsdpaAndEdch)
(AlwaysOnTimer)
t
Traffic UL/DL


HSUPA
When Cell/URA_PCH states are not activated, Always-on mechanism will use 2 steps for the downsize part
when isAlwaysOnAllowed is set to degraded2AlwaysOnOnly for the HSDPA/E-DCH UserService.
In this mode, the Always-on feature first downsize the user to Always-on CELL_FACH and perform the
release to PMM-Idle in a second time.
The timers used are:
timerT1ForHsdpaAndEdch for Cell_DCH to Cell_FACH transition
timerT2 for Cell_FACH to PM-Idle transition

5.4.2 Always On: releaseOnly - URA/Cell_PCH not used
Always - on (releaseOnly )
Activity (UL or DL) Low activity Inactivity

Release
HSDPA + E - DCH
t
Release timer
(timerT2ForHsdpaAndEdch)
(AlwaysOnTimer)
t
Traffic UL/DL


HSUPA
When Cell/URA_PCH states are not activated, Always-on mechanism will use 1 step for the downsize part
when isAlwaysOnAllowed is set to releaseOnly for the HSDPA/E-DCH UserService.
In this mode, the Always-on feature downsize the user directly from Cell_DCH to PMM-Idle when user traffic
is null during timerT2ForHsdpaAndEdch.

6 HSUPA Mobility

HSUPA

6 HSUPA Mobility
6.1 E-DCH Radio Links Set, E-DCH Active Set: Definitions
A
E-DCH serving radio link
E-DCH non-serving RL of serving NodeB
C
E-DCH non-serving RL of non-serving NodeB
Cell of DCH AS (but not in E-DCH AS) B

Cell of E-DCH active set (and of DCH AS) RL4
RL1 G D
I F
E-DCH serving cell
RL3
Active Set
H E
RL2
E-DCH Active Set
Iub
E-DCH serving RLS
E-DCH non-serving RLS
Fill up the table

HSUPA
Definitions
E-DCH Serving NodeB is the Node B hosting the E-DCH serving radio link.
E-DCH Serving Radio Link is a radio link which carries the E-DCH channel of a UE and also hosts the E-DCH
absolute grant channel (E-AGCH).
E-DCH Non-serving Radio Link is a radio link which carries the E-DCH channel of a UE but does not host the
E-AGCH channel.
E-DCH Serving Radio Link Set is the set of E-DCH radio links controlled by the E-DCH Serving NodeB.
E-DCH Non-Serving Radio Link Set is the set of E-DCH radio links controlled by another NodeB than the E-
DCH Serving NodeB.
E-DCH Active Set may include multiple cells: the E-DCH AS is included in the DCH AS (as of 3GPP) the E-DCH
AS may include a maximum of 4 cells (as of 3GPP).
At E-DCH Radio Bearer (RB) establishment, E-DCH AS is created and includes only 1 cell: the E-DCH Serving
Cell, i.e. the Primary Cell (ALU implementation).
Since E-DCH RB establishment, all cells added to DCH AS are added to E-DCH AS, provided:
E-DCH AS is still not full
Cell to be added supports current E-DCH Configuration {E-DCH TTI, E-DPDCH SF, HARQ type} for the
considered E-DCH call.
All cells removed from DCH AS and present in E-DCH AS are also removed from E-DCH AS.

6 HSUPA Mobility
6.2 E-DCH serving NodeB, E-DCH non-serving NodeB
Serving E-DCH
Radio Link Set
Non Serving EDCH

Radio Link Set
serving NodeB
non-serving NodeB
Serving E-DCH
cell E-AGCH
1 E-HICH
1 Dedicated E-RGCH for this UE
Common E-RGCH
1 E-HICH for this UE
E-DPCCH
+
E-DPDCH Maximum size of E-DCH Active Set
maxNumberOfRlEdch
(EdchRncConf)
HSUPA capable UE

HSUPA
E-DCH serving NodeB

•E-DCH serving cell:
o E-DCH serving cell = Primary Cell (ALU impl.)
o E-AGCH is transmitted only on the E-DCH serving cell (3GPP)
• All E-DCH signals received from UE are MRC combined before being processed.
• E-RGCH, E-HICH:
o Same RG command (on E-RGCH) and same ACK/NACK information (on E-HICH) is transmitted to
UE on all cells of the serving NodeB in E-DCH AS.
E-DCH non-serving NodeB
•All E-DCH signals received from UE are MRC combined before being processed.
• E-HICH:
o Same E-HICH information is transmitted to UE on all cells of the considered non-serving NodeB
included in E-DCH AS.
o Only “ACK” E-HICH is allowed.
• E-RGCH:
o Only “Down” E-RGCH is allowed.
UA06 “E-DCH Macro Diversity Support” feature will:
improve E-DCH user throughput when UE is in Softer of Soft HO condition, by decoding E-DPDCH
simultaneously on multiple radio links and recombining data at RNC.
reduce UL interference caused by E-DCH users of neighboring cells when necessary (in order to Improve
radio condition of E-DCH users of current cell).

6 HSUPA Mobility
6.3 E-DCH Active Set Management: Event 1J
Event1J
Event1J
Event1J
Event1J
isRrcEdchEvent1JAllowed
CPICH_Ec/No
amountRep1J
E-AS Cell (FullEventRepCritShoMgtEvent1J)
AS Cell
entering reporting range maxNbReportedCells1J

(FullEventRepCritShoMgtEvent1J)
leaving reporting range InE-AS Cell
repActThresh1J
(FullEventRepCritShoMgtEvent1J)
timeToTrigger1J repInterval1J
(FullEventHoConfShoMgtEvent1J) (FullEventRepCritShoMgtEvent1J)
10 LogM AS + CIO AS ≥ 10 LogM InEAS + CIO InEAS ± H 1J /2 )
hysteresis1J (FullEventHoConfShoMgtEvent1J)
neighbouringCellOffset (UmtsNeighbouringRelation)

HSUPA
Inter-NodeB E-DCH mobility issue in UA05:

Uplink Inner-Loop Power Control (UL ILPC) is controlled by the cell with best UL path loss, which in some
cases might not be the E-DCH serving cell (i.e. Primary Cell).
⇒ Just before Primary Cell change, UL ILPC may be controlled by the target cell
⇒ UE Tx Power may be driven down by the target cell
⇒ SIR at current serving NodeB (i.e. source NodeB) may become too low for E-DPDCH decoding
⇒ HARQ retransmissions on E-DCH ⇒ E-DCH user throughput degradation
Event 1J (specific to E-DCH Macro Diversity):

Definition: The CPICH of a cell that is in DCH AS but not in E-DCH AS (cell “B”) becomes better than
the CPICH of a cell that is already in E-DCH AS (cell “A”).
Action triggered: Cell ”A” is removed from the E-DCH AS and replaced by cell “B”
(provided that cell “B” supports current E-DCH Configuration).
Remark: Event 1J is only configured when the “Full-Event Triggered” reporting of measurements
mode is used for intra-frequency mobility.
repActThresh1J: Minimum number of cells in E-DCH AS in order for Event 1J to be detected.

6 HSUPA Mobility
6.4 E-DCH Active Set Management: Primary Cell Change
Event1D
CPICH_Ec/No
R6 cell new Primary Cell R99/R5 cell

not support current
NotBest Cell E-DCH Configuration
Best Cell
E-DCH Configuration changed to match the E-DCH RB

E-DCH capabilities of the new Primary reconfigured to UL DCH
Cell.
E-AS not Compatible E-AS Compatible

More Restrictive
new Primary Cell
Remove All E-AS cells

not compatible Reconfigure All E-AS cells

HSUPA
Primary Cell change:

When Primary Cell changes, E-DCH serving cell is changed to the new Primary Cell.
If the new Primary Cell does not support current E-DCH Configuration:
- E-DCH Configuration is changed to match E-DCH capabilities of the new Primary Cell.
- If E-DCH Configuration is changed to a more restrictive one (e.g. 10ms TTI → 2ms TTI or best SF
configuration SF4 → SF2), any cell of E-DCH AS not supporting the new E-DCH Configuration is
removed from E-DCH AS.
If the new Primary Cell does not support E-DCH, the E-DCH RB is reconfigured to UL DCH.
For a given E-DCH call, E-DCH Configuration is common to all E-DCH RLs.
E-DCH Configuration is determined by RNC at beginning of the E-DCH call,
basing on UE and E-DCH serving NodeB capabilities.
E-DCH Configuration must always match E-DCH serving cell (i.e. Primary Cell) capabilities
⇒ At Primary Cell change, E-DCH Configuration is changed to match E-DCH capabilities of
the new Primary Cell (if E-DCH capabilities changed).
iCEM/xCEM specificities:
iCEM and xCEM capabilities are different regarding E-DCH TTI and E-DPDCH SF
⇒ E-DCH call attributes depend on type of board handling E-DCH on the E-DCH serving cell.
Example:
UE: HSUPA Category 5, “IR” E-DCH HARQ type supported:
− iCEM handling E-DCH on E-DCH serving cell ⇒ {10ms TTI, 2xSF4, IR}, “Cat 3” Ref E-TFCI table
− xCEM handling E-DCH on E-DCH serving cell ⇒ {10ms TTI, 2xSF2, IR}, “Cat 5” Ref E-TFCI table

6 HSUPA Mobility
6.5 Soft HO Data Transmission Example
Physical Channels Transport Channels
E-AGCH
1. Absolute Grant Serving RNC
E-DCH FP
E-DCH
E-DPCCH 5. Void ! UE
cell
2a. E-TFCI(1) 9a. Data Tx(2) Ctxt
6a. E-TFCI(2) RLS 13a. Void
10a. E-TFCI(1)
E-DPDCH
3a. Data Tx(1)
7a. Data Tx(2)
11a. Data Tx(1)
E-HICH
4a. NACK(1)
8a. ACK(2) 14. Data
UE 12a. NACK(1) Reordering/
Non- Combining
E-DPCCH
2b. E-TFCI(1) serving
6b. E-TFCI(2) E-DCH
cell E-DCH FP
10b. E-TFCI(1)
5. Void
E-DPDCH RLS 9b. Data Tx(2)
3b. Data Tx(1)
13b. Data Tx(1)
7b. Data Tx(2)
11b. Data Tx(1)
E-HICH
4b. NACK(1)
8b. ACK(2)
12b. ACK(1)

HSUPA
This operation occurs in soft handover situations (SHO): Intra Node B and inter Node B macro-diversity are
supported by the HSUPA solution.
Multiple Node Bs transmit HARQ ACK/NACK in DL. The reliability of the signaling is essential to avoid de-
synchronization of the Node Bs buffers and ACK/NACK errors.
In softer handover, cells belonging to the same Node B transmit the same HARQ ACK/NACK information
(same RLS).
Resynchronization of HARQ instances at the Node B are implicitly performed, based on Retransmission
Sequence Number.
iubEdchDelayVariation: Delay on Iub for MAC-es re-ordering function in RNC. Same value (in number of E-
DCH TTIs) applies for both 10ms and 2ms E-DCH TTI.

6 HSUPA Mobility
6.6 UL Noise Rise due to E-DCH Non-Serving RL : iCEM case
E-DCH serving radio link E-DCH serving UE

E-DCH cell considered
E-DCH non- serving UE
E DCH Rx Power ( + ) targetNonServingToTotalEDCHPowerRatio

IF
E DCH Rx Power ( + + )
> (FDDCell)
“Down” sent on Common E-RGCH for non-serving UE in non-serving NodeB

THEN
“Down” sent on Dedicated E-RGCH for non- serving UE in serving NodeB

HSUPA
For each E-DCH cell, the UL noise rise generated by E-DCH non-serving radio links is monitored.
According to the measured ratio of E-DCH Rx power from non-serving radio links to total E-DCH Rx power,
“Down” RG commands may be sent from this cell to non-serving UEs, in order to always guarantee
acceptable radio conditions for E-DCH serving radio links.
edchNumCommonRgPerCode: Number of signatures per E-RGCH/E-HICH channel reserved for common RG
commands.

6.6 UL Noise Rise due to E-DCH Non-Serving RL : iCEM case
6.6.1 xCEM case
E-DCH serving radio link E-DCH serving UE

E-DCH cell considered
E-DCH non- serving UE
E DCH Rx Power ( ) targetNonServingToTotalEDCHPowerRatio

IF
> (FDDCell)
THEN “Down” sent on Common E-RGCH for non-serving UE in non-serving NodeB
E DCH Rx Power ( ) edchSofterHoLimit

IF
> (EdchConf)
THEN “Down” sent on Dedicated E-RGCH for non-serving UE in serving NodeB

HSUPA
For each E-DCH cell, the UL noise rise generated by E-DCH non-serving radio links is monitored.
According to the measured ratio of E-DCH Rx power from non-serving radio links to total E-DCH Rx power,
“Down” RG commands may be sent from this cell to non-serving UEs, in order to always guarantee
acceptable radio conditions for E-DCH serving radio links.
Using two different parameters allows to power down later the non-serving RLs on serving NodeB compared
to non-serving RLs on non-serving NodeB in order to keep advantage of the softer handover MRC gain.

6 HSUPA Mobility
6.7 E-DCH Macro Diversity RAN Model
RNC
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed
FDDCell
targetNonServingToTotalEdchPowerRatio
DedicatedConf EdchRncConf
maxNumberOfRlEdch
HoConfClass MeasurementConfClass NodeBConfClass

iubEdchDelayVariation
UsHoConf/ FullEventRepCritShoMgt
PsHSDPA
CsSpeechPlusHSDPA BTSEquipment
…
FullEventHoConfShoMgt FullEventRepCritShoMgtEvent1J BTSCell

amountRep1J
maxNbReportedCells1J
EdchConf
FullEventHoConfShoMgtEvent1J repActThresh1J
repInterval1J edchSofterHoLimit
hysteresis1J
nonServingEHICHPowerOffset
timeToTrigger1J
commonERGCHPowerOffset
edchNumCommonRgPerCode
HSUPA
isEdchRlAddOrSetupDefenseAllowed: Flag enabling to try to add a given cell in DCH AS just after failing to
add this cell in DCH AS and E-DCH AS simultaneously.

6 HSUPA Mobility
6.8 Intra-Freq Mobility : Primary Cell Change
Core Network Core Network
Serving Serving
RNC RNC
FDD1 FDD1 FDD1 FDD1

1 2
Primary Primary
Cell Cell
Primary Cell
Change
E-DCH
HS-DSCH
DCH
UE UE
E-AGCH
HSUPA
When a cell is added in the active set without primary cell change (i.e. E-DPCH still running on former
primary cell), the new radio link is established with UL SRB 3.4 kbps + UL TRB 0 kbps (+ another possible UL
TRB in case of multi-service).
When the primary cell changes, intra-frequency mobility of the E-DPCH serving link is managed through
deleting and re-establishing on the new primary cell (synchronous reconfiguration if the new primary cell
was in the old active set). The HS-DSCH is reconfigured in the same SRLR procedure.
If it is not possible to establish the E-DPDCH on the new cell (i.e. HSUPA CAC failure) then the RAB
mapped on E-DPDCH is released unless HSUPA to DCH fallback is provisioned.
When a new primary cell is selected, the transport channel type selector is played:
If the old primary cell was E-DCH and not the new one, the RB is reconfigured to DCH.
If the old primary cell was not E-DCH but the new one is, the RB is reconfigured to E-DCH.
If the new primary cell is E-DCH and the call was E-DCH, then call is kept on E-DCH.

6.8 Intra-Freq Mobility : Primary Cell Change
6.8.1 Call Flow
RNC source Node B target Node B UE
Primary cell change
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Commit (Activation CFN)
RL Reconfiguration Commit (Activation CFN)
RB Reconfiguration (Activation CFN, new E-RNTI, Serving

E-DCH RL, E-AGCH info, E-HICH info)
Measurement Control (new neighboring list)
Activation CFN
RB Reconfiguration Complete

HSUPA
E-DCH is established only on Primary cell of the Active Set (UA05.0)

Each time the primary cell changes, the E-DCH RL is deleted on the former primary and it is re-established
under the new primary, using a synchronous reconfiguration. The HS-DSCH is reconfigured at the same
time.

Exercise
Assumptions:
For all UsHOConf: hysteresis1J = 3dB, timeToTrigger1J = 100 ms
maxActiveSetSize = 4
maxNumberOfRlEdch = 3
CIO = 0 dB (For all adjacencies)
EDCHEnable = True (For Cell1, Cell2, Cell3, Cell4, Cell5)
On the graph next page, being given that:
At T0, DCH AS = E-DCH AS = {Cell1,Cell2, Cell3}, MS= {Cell4, Cell5}
Questions:
Put on the graph the events that the UE will report.

After each reported event* define DCH AS, E-DCH AS and Monitored Set cells?
(*) We assume that each reported event leads to a successful Active set update
procedure

HSUPA

Exercise [cont.]
CPICH_Ec/No
-5dB
1dB
Cell1
Cell2
Cell3
Cell5
Cell4
T0
50ms

HSUPA

6.9 Intra-Freq Mobility over Iur
isHsdpaOverIurAsSrncAllowed Core Network isHsdpaOverIurAsDrncAllowed
isEdchOverIurSrncAllowed isEdchOverIurDrncAllowed
isMacShHsdpaAllowed
(RadioAccessService) 2
Serving Iur Drift

RNC Primary Cell RNC
FDD1 FDD1
Change FDD1 FDD1
Primary Neighbour
Primary
Cell Cell
1 3
isHsdpaAllowed
isEdchAllowed
(NeighbouringRNC)
isHsdpaAllowed
isEdchAllowed
edchMinSfCapabilities
E-DCH
isEdchTti2msAllowed
HS-DSCH
(RemoteFddCell)
UE DCH

HSUPA
From UA06.0, HSUPA over Iur is supported. HSUPA over Iur capability is required in both SRNC and DRNC to
allow the handling of the configuration, maintenance and release of active HSUPA calls over Iur.
If the HSUPA over Iur is not supported or deactivated on SRNC or DRNC, the system will behave as in UA05:
While HSUPA running, if the primary cell goes under the control of a DRNC then the SRNC will consider that
the new primary is not E-DCH capable and, as such, will perform an UL Transport Channel type switching to
DCH whereas DL HS-DSCH is properly reconfigured over Iur (in case HSDPA over Iur is provisioned).
When HSUPA over Iur is supported and activated on both SRNC and DRNC, the mobility between serving
cells (under SRNC) and drift cells (under DRNC) is handled by the SRNC, in the same way as intra RNC E-DCH
mobility, based on the primary cell E-DCH capabilities and the target drift cell E-DCH capabilities in terms
of
E-DCH support:
TTI capabilities (2ms or 10ms)
Min SF capabilities
Note that the E-DCH capabilities for drift cells that are declared as neighbors to the border serving cells
(i.e. known by the SRNC) are configured under “RemoteFddCell”.
When the Iur is well dimensioned, it’s recommended to set the E-DCH capabilities, under remoteFddCell
object, in line with the real cell capabilities otherwise, we can use these parameters to “downgrade” the
drift cell capabilities in order to limit the E-DCH traffic over Iur or to deactivate completely the E-DCH over
Iur toward some specific drift cells. We can for example limit the E-DCH over Iur to CAT3 by setting the TTI
capabilities to 10ms and Min SF capabilities to 2SF4 even if the drift cell is 2ms capable and supporting
2SF2+2SF4.

6.10 Inter-Freq Intra-RNC Mobility
Core Network isEdchHhoWithMeasAllowed Core Network
is3Gto3GWithoutIurAllowedforPS
Serving Serving
RNC RNC
FDD1 FDD2 FDD1 FDD2

1 2
Primary Primary
Cell Cell
iMCTA
P-CPICH
E-DCH
HS-DSCH
UE DCH UE

HSUPA
In case of Intra-RNC HHO, RNC selects the target Transport Channel type based on:
The activation flag of HSDPA HHO feature (isHsdpaHhoWithMeasAllowed)
The activation flag of HSUPA HHO feature (isEdchHhoWithMeasAllowed)
The HSxPA capabilities of the target cell and the mobile
isEdchHhoWithMeasAllowed: When set to FALSE, this parameter prevents any Intra-RNC HHO to HSUPA,
and only the 2 following transitions can then occur for UL Transport Channel:
HSUPA to DCH
DCH to DCH
Note: This parameter is not used by RNC in case of outgoing and incoming HHO (i.e. Inter-RNC HHO).
If HSxPA is deployed on the same NodeB using 2 dedicated carriers, isHsdpaHhoWithMeasAllowed
and isEdchHhoWithMeasAllowed must be set to TRUE in order to prevent any conflict with iMCTA
Service strategy.
In case of Inter-frequency Intra-RNC HHO, is3Gto3GWithoutIurAllowedforCS and
is3Gto3GWithoutIurAllowedforPS must also be set to True (even though naming is not explicit.
isIrmCacForInterFreqIntraRncEnable: When set to True, this parameter allows to play iRM CAC tables on
the Target FDD cell before executing HHO (only applicable for Intra-RNC HHO).

6.11 Inter-Freq Inter-RNC Mobility: Without Iur OR
is3Gto3GWithoutIurAllowedforCS Core Network isInterFreqHandoverOverIurAllowed
is3Gto3GWithoutIurAllowedforPS (NeighbouringRNC)
(RadioAccessService) SRNS Relocation = False
1 2 2 1
Serving Serving
no Iur
RNC RNC RNC RNC
FDD1 FDD1 FDD2 FDD2
iMCTA
Primary Primary
Cell Cell
1 2
P-CPICH
E-DCH
HS-DSCH
UE DCH

HSUPA
Inter-Freq inter-RNC mobility is handled in the same way with or without Iur through a SRNS Relocation
procedure.
The parameters is3Gto3GWithoutIurAllowedforCS and is3Gto3GWithoutIurAllowedforPS must be set to
true with or withour Iur.
In case of Inter-RNC mobility, source RNC uses R5 or R6 extensions (depending on established RAB) in order
to indicate in the RRC container:
The HSxPA-capabilities of the mobile
The RAB currently running on Source RNC (either HS-DSCH or E-DCH)
This nominal RRC container allows Target RNC to directly reconfigure the RAB in HSxPA without any DCH
transition.
In case of inter-RNC handover with Iur the handover is either performed through:
an SRNS relocation if parameter isInterFreqHandoverOverIurAllowed = False, or
a Reconfiguration to uplink and downlink DCH and handover over Iur if parameter
isInterFreqHandoverOverIurAllowed = True

6.11 Inter-Freq Inter-RNC Mobility: Without Iur OR
6.11.1 Inter-Freq Inter-RNC Mobility: With Iur AND
is3Gto3GWithoutIurAllowedforCS Core Network isInterFreqHandoverOverIurAllowed
is3Gto3GWithoutIurAllowedforPS (NeighbouringRNC)
(RadioAccessService) = True
1 2 2 1
Serving Drift
RNC
Iur RNC
FDD1 FDD1 FDD2 FDD2
iMCTA
Primary Primary
Cell Cell
1 2
P-CPICH
E-DCH
HS-DSCH
UE DCH

HSUPA
In case of inter-RNC handover with Iur the handover is either performed through:
an SRNS relocation if parameter isInterFreqHandoverOverIurAllowed = False, or
a Reconfiguration to uplink and downlink DCH and handover over Iur if parameter
isInterFreqHandoverOverIurAllowed = True
The parameters is3Gto3GWithoutIurAllowedforCS and is3Gto3GWithoutIurAllowedforPS must be set to

true with or withour Iur.

6.12 Inter-RAT Mobility
Nothing specific compared to R99 or HSDPA 3G to 2G HHO
activationHoGsmPsAllowed
isInterFreqMeasActivationAllowed
isBlindHoRescueAllowed
isPatternAllowed isGsmCmodeActivationAllowed
(CmodePatternSeqInfo) (DlUserService)

HSUPA
activationHoGsmPsAllowed indicates if the handover PS toward GSM/GPRS is allowed.

isGsmCmodeActivationAllowed is used to activate or deactivate the compressed mode for GSM neighbors
measurements for a specific service
isBlindHoRescueAllowed indicates if blind handover for iMCTA Alarm is allowed for this RNC.

Module Summary

HSUPA activation principles and associated parameters
HSUPA radio resource management and associated parameters
HSUPA mobility features and associated parameters

HSUPA


for this module

HSUPA

End of Module

HSUPA

31
Section 3
Appendix
Module 1
9300 WCDMA

Blank Page

Appendix
Document History

Module Objectives
Describe HSDPA CQI mapping tables

Describe HSUPA E-TFCI and grants
Describe HSDPA modulation usage versus codes
Describe Dynamic MAC-d PDU size

Appendix


Appendix

Table of Contents
Page
1 HSDPA : CQI Mapping Tables (3GPP) 7
1.1 HSDPA CQI Mapping Tables 8
1.1 CQI mapping table A for UE categories 1 to 6 9
1.2 CQI mapping table B for UE categories 7 to 8 10
1.3 CQI mapping table C for UE category 9 11
1.4 CQI mapping table D for UE category 10 12
1.5 CQI mapping table E for UE category 11 and 12 13
1.6 HSDPA CQI Mapping Table F 14
1.7 HSDPA CQI Mapping Table G 15
1.8 HSDPA CQI Mapping Table H & I 16
2 HSUPA : E-TFCI and Grant 17
2.1 E-DCH Transport Blocks Tables 18
2.2 E-DPDCH power vs Transport Block Size 19
2.3 Absolute Grant Table 20
3 Flexible HSDPA modulation usage versus codes (xCEM) 21
3.1 HSDPA modul. and code / CQI : 25.214 Mapping Table 22
3.2 Flexible resources usage 23
3.3 TFRC Selection for Flexible HSDPA 24
4 Dynamic MAC-d PDU size 25
4.1 Dynamic MAC-d PDU size 26
4.1.1 MAC-d PDU size 27
4.1.2 MAC PDU size Configuration 28
4.1.3 How to configure a Mac-d PDU size of 656 bits 29
4.1.4 MAC-d PDU size Selection 30
315 4.1.5 MAC-PDU size : Mobility HSDPA-HSDPA – Reconf not allowed
31
Appendix
4.1.69300
9300 WCDMA TMO18256 MAC-PDU size
WCDMA UAO7 HSxPA : Mobility
Algorithms Description HSDPA-HSDPA – Reconf allowed 32
4.1.7 MAC-PDU size : Mobility HSDPA-HSDPA – CEM type 33
4.1.8 MAC-PDU size : Mobility HSDPA - R99 34
4.1.9 MAC-PDU size : Mobility Over Iur – Reconf not allowed 35
4.1.10 MAC-PDU size : Mobility Over Iur – Reconf allowed 36
4.1.11 Mac-d PDU size reconfiguration 37
4.2 High Quality UL R99 RAB for High HSDPA DL Rate - Issue 38
4.2.1 Solution 39


Appendix This page is left blank intentionally

1 HSDPA : CQI Mapping Tables (3GPP)

Appendix

1.1 HSDPA CQI Mapping Tables

Appendix

1.2 CQI mapping table A for UE categories 1 to 6

Appendix

1.3 CQI mapping table B for UE categories 7 to 8

Appendix

1.4 CQI mapping table C for UE category 9

Appendix

1.5 CQI mapping table D for UE category 10

Appendix

1.6 CQI mapping table E for UE category 11 and 12

Appendix

1.7 HSDPA CQI Mapping Table F

Appendix

1.8 HSDPA CQI Mapping Table G

Appendix

1.9 HSDPA CQI Mapping Table H & I

Appendix

2 HSUPA : E-TFCI and Grant

Appendix

2.1 E-DCH Transport Blocks Tables
4
x 10 3GP P TB ta ble (TTI 10 ms )
2
1.8
10ms TtiTa ble0
1.6
10ms TtiTa ble1
1.4
Tra ns ort block s ize (bits )

1.2
0.8
0.6
0.4
0.2
0
0 20 40 60 80 100 120 140
Tra ns ort block s iz e index
Param identity (Customer Default value Range Comment

Class 3)
edchTfcsTableIndex 10msTtiTable1 2msTtiTable0, 2ms tables not
2msTtiTable1, supported. Table1
10msTtiTable0, more suitable for RLC
10msTtiTable1 PDU size 336 bits.

Appendix

2.2 E-DPDCH power vs Transport Block Size
The higher the E-DP DCH power vs . trans port bloc k s ize
30
transport block size
is, the higher is the
required power 25
E-DP DCH power re lativ to DP CCH (dB)

In order not to
signal all power 20
offsets, only a
subset are signaled 15
as reference.
The remaining E- 10
TFCI are
interpolated as 5
specified by 3GPP.
0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
TB s ize (bits ) 4
x 10
Reference signaled E-TFCI

Appendix
121 E-TFCI are defined for table 1 (128 for table 0).
In order not to signal all power offsets, only few of them are signaled as reference. Each reference element
contains a couple of values :
Reference E-TFCI (Transport block size index, range [0-127])
Reference Power Offset (E-DPDCH/UL DPCCH power ratio index, range [0-29])
Non referenced Power Offsets are obtained by interpolation at the UE , according to the interpolation
method specified by 3GPP in TS 25.214 .
121 E-TFCI are defined for table 1 (128 for table 0).
In order not to signal all power offsets, only few of them are signaled as reference. Each reference element
contains a couple of values :
Reference E-TFCI (Transport block size index, range [0-127])
Reference Power Offset (E-DPDCH/UL DPCCH power ratio index, range [0-29])
Non referenced Power Offsets are obtained by interpolation at the UE , according to the interpolation
method specified by 3GPP in TS 25.214 .

2.3 Absolute Grant Table
Absolute Grant Value Index

2
Absolute grant information (168/15) x6
2
(150/15) x6
31
30
(168/15)2x4
are signaled through the E- 2
(150/15) x4
29
28
AGCH. It contains: 2
(134/15) x4
2
(119/15) x4
27
26
2
The E-RNTI, i.e. UE identity (150/15) x2
2
(95/15) x4
25
24
2
(168/15) 23
The grant value index (150/15)
2
22
between 0 and 31. (134/15)
(119/15)
2
2
21
20
(106/15)2
Depending on the TTI (95/15)
2
19
18
length, it is transmitted on (84/15)
(75/15)
2
2
17
16
one sub-frame (3 slots) or (67/15)
(60/15)
2
2
15
14
one frame (15 slots). (53/15)
(47/15)2
2
13
12
Once transmitted, no need
2
(42/15) 11
(38/15)
2
10
to transmit it again, unless (34/15)
(30/15)
2
2
9
8
grant modification needed (27/15)
(24/15)2
2
7
6
2
(19/15) 5
2
(15/15) 4
2
(11/15) 3
(7/15)2 2
ZERO_GRANT* 1
INACTIVE* 0

Appendix

3 Flexible HSDPA modulation usage
versus codes (xCEM)

Appendix

3 Flexible HSDPA modulation usage versus codes (xCEM)
3.1 HSDPA modul. and code / CQI : 25.214 Mapping
Table
Transport Number of Reference power NIR XRV

CQI value Modulation adjustment ∆
Block Size HS-PDSCH
Tables specified
0 N/A Out of range in
1 137 1 QPSK 0 28800 0 TS 25.214
… For each UE
6 461 1 QPSK 0 category
7 650 2 QPSK 0 Condition: BLER ≤
10%
…
0
Example for UE
15 3319 5 QPSK
category 10
16 3565 5 16-QAM 0
Poor granularity :
…
performances are
0
23 9719 7 16-QAM reduced by using
24 11418 8 16-QAM 0
the 25.214
25 14411 10 16-QAM 0 example.
26 17237 12 16-QAM 0
xCEM uses a table
27 21754 15 16-QAM 0 with much more
28 23370 15 16-QAM 0 possibilities
29 24222 15 16-QAM 0
30 25558 15 16-QAM 0

Appendix
Once it has been decided to which users data shall be transmitted, for each of those users a Transport
Format Resource Combination needs to chosen.
A TFRC denotes the triplet of transport block size, modulation alphabet and number of channelization
codes.
Also the Tx power needs to be chosen properly by the TFRC selector.
The scheduler selects for each user to be scheduled a new TFRC in each TTI of 2ms.
Link adaptation between TFRC used for HSDPA in previous release was robust but not always optimized in
term of cell resource usage.
Indeed there was a one to one relationship between the processed CQI and the TFRC selected by the
scheduler.

3.2 Flexible resources usage
For the same Transport burst size, QPSK modulation is more robust but requires more codes
TrBlk:7168
0
10
−1
10
BLER 1stTx
−2
10
−3
10
7 7.5 8 8.5 9 9.5 10 10.5 11
3.5
RLC Throughput [Mbps]
2.5
2
5*16QAM
9*QPSK
1.5
7 7.5 8 8.5 9 9.5 10 10.5 11
Ior/Ioc [dB]
flexible resources usage and accurate performances estimation algorithm

=> better spectrum efficiency and cell throughput
Appendix
With this solution, the HSDPA scheduler offer additional flexibility for selecting the TFRC versus the RF
conditions, the available power, the number of available HS-PDSCH
and the UE category.
Each Transport Burst (TB) size is offered with various combination of codes and modulations (QPSK, 16QAM),
except for very high TB size not available with QPSK.
Particularly:
QPSK over more than 5 codes is made available for UE category 8 or 10 in low or medium radio
condition.
16QAM can be selected even if less than 5 SF16 codes are available for UE category 1 to 10. This
allows optimizing the cell HSDPA throughput in case of code shortage.
The HSDPA scheduler selects the TFRC that:
1. Maximizes the TB size
2. Minimize the number of codes (to leave as much resource as possible for other users to be
scheduled).
3. Prefer QPSK modulation (as it is more power efficient than 16QAM).

3.3 TFRC Selection for Flexible HSDPA
Each Transport Burst (TB) size is offered with various combination of

codes and modulations (QPSK, 16QAM)
Flexible HSDPA modulation and code / CQI : 25.331 Mapping Table
CQI =16 TBS1 ; TBS2
QPSK ; 16 QAM
TRFC Selection
Nb of Code1 ; Nb of Code2
xCEM
Particularly:
QPSK over more than 5 codes is made available for UE category 8 or 10 in low
or medium radio condition.
16QAM can be selected even if less than 5 SF16 codes are available for UE
category 1 to 10. This allows optimizing the cell HSDPA throughput in case of
code shortage.

Appendix
The TFRC selection in xCEM is based on a look up tables (LUT) with four input variables
Modulation capability of the UE
Maximal MAC-hs payload size given by the UE capability and the queue size
The number of available codes limited by the UE capability (W)
Spectral efficiency (SE)
The spectral efficiency is a metric how many bits/code/TTI can be transmitted successfully in a TTI
The CQI is not directly used in the MAC-hs but mapped to a SNR per code based on PCPICH +
measurement power offset Γ
Based on the available HSDPA power the SNR is scaled and mapped to a spectral efficiency (SE) in
bits/code/TTI
Since the spectral efficiency is based on the truly available HSDPA power, the TFRC selection is not limited
by PCPICH + measurement power offset
The LUT is defined so that chosen modulation efficiently uses resources (power and codes)
In power limited situation QPSK is preferable (lower Es/N0)
more codes but increases the transport block size for the same power
In code limited situation 16-QAM is preferable (higher Es/N0) :
more power but increases the transport block size for the same number of codes
The modulation is chosen according to the Spectral Efficiency

Spectral Efficiency is based on the available power
In power limited situation, Spectral Efficiency is low QPSK is selected
In non-power limited situation, Spectral Efficiency is high 16-QAM is selected
4 Dynamic MAC-d PDU size

Appendix

4 Dynamic MAC-d PDU size
4.1 Dynamic MAC-d PDU size
RNC
NodeB RadioAccessService
isDynamicMacdPduSizeManagementAllowed
FDDCell
isHsdpaCellHighPerformance
Mac-hs PDU = 1TTI

HsdpaRncConf
Mac-hs SDU
eligibleUeCategoryForHighPerformance
minimumUserMbrForHighPerformance
21 320 16 320 16 320 16 Padding
isHighPerformancePduSizeReconfAllowed
Mac-hs PDU = 1TTI
Mac-hs SDU
21 640 16 640 16 640 16 Padding

Appendix
ALU UTRAN can use 2 Mac-d PDU sizes for HS-DSCH Mac-d flows : 336 or 656 bits.
336 bits configuration might limit the throughput due to UE processing capabilities (too many PDU/s to
handle) or due to RLC stalling (RLC window size is limited to 2047) in case of a too high round-trip delay.
Mac-d PDU size of 656 bits support allows to reach maximum throughput
Mac-d PDU size chosen at RAB establishment of a first PS I/B RAB according to:
• UE category (eligibleUeCategoryForHighPerformance)
• Cell (isHsdpaCellHighPerformance)
• Maximum Bit Rate (minimumUserMbrForHighPerformance)
• feature activation at RNC level (isDynamicMacdPduSizeManagementAllowed)
• PDU size can be reconfigured during the call and a 2nd HS-DSCH Mac-d flow can use a Mac-d PDU
size different from the 1st one (isHighPerformancePduSizeReconfAllowed)
In UA05.1, the flag to restrict primary cell to 336 bits was was MaxCellRadius. In UA06 it is
isHsdpaCellHighPerformance in UA06).
Basically, in UA05.1, the MAC-d PDU size does not change during the call whatever the configuration of
the primary cell. The difference between UA05.1 and UA06 is the possibility to reconfigure the MAC-d
PDU size during the call. This reconfiguration is allowed in UA06 if the flag
isHighPerformancePduSizeReconfAllowed is set to True.

4.1.1 MAC-d PDU size
336 bits configuration might limit the throughput

due to UE processing capabilities (too many PDU/s
to handle) or due to RLC stalling (RLC window size
is limited to 2047) in case of a too high round-trip
MAC-d PDU delay
= 336 bits
Max HSDPA user throughput @ RLC =
Max HSDPA user throughput @ RLC

= ƒ (Mac-d PDU size)
MAC-d PDU
= 336 bits
or = ƒ (UE cat.)
= 656 bits
Appendix
This Dynamic Mac-d PDU management is only applicable to the case where MAC-hs/fixed MAC-d PDU size
format is used for the call.
In UA5.0, only Mac-d PDU size of 336 bits is fully supported. From UA5.1, Mac-d PDU size of 656 bits can
also be used in certain cases.
336 bits configuration might limit the throughput due to UE processing capabilities (too many PDU/s to
handle) or due to RLC stalling (RLC window size is limited to 2047) in case of a too high round-trip delay.
The maximum HSDPA user throughput is limited either by UE processing capabilities (too many PDU/s to
handle) or by RLC window blocking (RLC window size being limited to 2047 MAC-d PDU):
when STATUS frequency from UE is too low to acknowledge the RLC window. STATUS frequency is
limited by the parameter prohibitedStatusTimer (minimum time in ms between STATUS reports).
when RLC Round Trip Time is too high
Basically : Max HSDPA user throughput @ RLC =

RLC window size * (Mac-d PDU size – Mac-d header) / (RLC Round Trip Time + prohibitedStatusTimer)
For example, the maximum theorical HSDPA user throughput should be around 5Mb/s for 336 bits or 10Mb/s
for 656 bits MAC-d PDU size assuming the following parameters: RLC window size = 2047 PDU, MAC-d header
= 16 bits, RLC RTT = 60ms, prohibitedStatusTimer = 70ms.
Decrease in the prohibitedStatusTimer leads to increase in the uplink Status traffic.

Therefore the interest of the 656 bits configuration is to allow reaching very high throughputs (6 Mbps and
more) with moderate uplink Status traffic.
From UA5.1, Mac-d PDU size of 656 bits support allows to reach maximum throughput for UE category 8:
7.2Mb/s @ Mac-hs 6.9Mb/s @ Mac-d
6.7Mb/s @ RLC 8.7Mb/s @ ATM
4.1.2 MAC PDU size Configuration
Two different MAC-d PDU sizes (336 or 656 bits) can be used.
MAC-d PDU size is chosen at RAB establishment of a first PS I/B RAB according
to :
• UE category: UE cat. can be eligible or not to 656 bits

eligibleUeCategoryForHighPerformance
(HsdpaRncConf)
• Cell: cell can be restricted to 336 bits at RB setup
isHsdpaCellHighPerformance
(FDDCell)
• 656 bits feature activation at RNC level

isDynamicMacdPduSizeManagementAllowed
• Requested RANAP MBR (Maximum Bit Rate)

Core minimumUserMbrForHighPerformance
Network (HsdpaRncConf)

Appendix
This feature consists in choosing the MAC-d PDU size according to several parameters:
eligibleUeCategoryForHighPerformance to define the UE categories eligible for 656 bits.
minimumUserMbrForHighPerformance to configure 656 bits if MBR (RANAP Maximum Bit Rate)
value is above this parameter.
isHsdpaCellHighPerformance to restrict primary cell to 336 bits
Moreover isDynamicMacdPduSizeManagementAllowed flag allows to activate or deactivate the
feature at RNC level.
656 bits MAC-d PDU size has to be used for UE categories allowing high user throughput, that is to say UE
Cat.7, 8, 9 and 10.

4.1.3 How to configure a Mac-d PDU size of 656 bits
eligibleUeCategoryForHighPerformance in RNC / RAS / HsdpaRncConf (class 3)
Bit string of 64 bits

Range & Unit
Bit n = 1 means UE Cat. n is eligible to 656 bits; 0 means not eligible
0000000000000000000000000000000000000000000000000000001111000000
Value
means that ue cat. 7, 8, 9, 10 are eligible to 656 bits
isHsdpaCellHighPerformance in RNC / NodeB / FDDCell (class 3)
Range & Unit Boolean {True; False}
Value True to activate 656 bits at RNC cell; False to deactivate

Appendix
isDynamicMacdPduSizeManagementAllowed in RNC / RAS (class 3)
Range & Unit Boolean {True; False}
Value True to activate 656 bits at RNC level; False to deactivate
All NodeB has to be upgraded to at least UA05.1 prior to the RNC activation.
656 bits PDU can be used only if “multi-service on HSDPA” is enabled (isMultiRabOnHsdpaAllowed = True)
minimumUserMbrForHighPerformance in RNC / RAS / HsdpaRncConf (class 3)
Range & Unit Integer [0.. 16 000 000] bit/s
0 (default value) customer dependent

Value
656 bits if RANAP MBR value is higher than this parameter.

4.1.4 MAC-d PDU size Selection
NodeB can handle different PDU sizes for a same UE

having 2 PS I/B RABs mapped on to HSDPA depending on
1st RAB (MBR1)
2nd RAB (MBR2)
Mac-d PDU size is chosen when an HS- isHighPerformancePduSizeReconfAllowed

= True : MAC-d PDU size can be different
DSCH MAC-d flow is setup that is to
say at RAB establishment or
reconfiguration of the RB to HS-DSCH. = False : same MAC-d PDU size

Appendix
MAC-d PDU selection: The MAC-d PDU size is chosen when an HS-DSCH MAC-d flow is setup that is to say at
RAB establishment or reconfiguration of the RB to HSDSCH.
In UA05.1 if a second HS-DSCH MAC-d flow is setup then it will use the same MAC-d PDU size than the first
one (even if its MBR would have lead to use a different size).

4.1.5 MAC-PDU size : Mobility HSDPA-HSDPA – Reconf not allowed
MAC-d PDU size can be reconfigured or not isHighPerformancePduSizeReconfAllowed
depending on isHighPerformancePduSizeReconfAllowed = False
Cat. 656
Cell 656 Mac-d PDU size is not reconfigured (656) Cell 656

Appendix
Cell 336 : cell restricted to 336 bits at RB setup

Cell 656 : cell not restricted to 336 bits at RB setup
Cat. 336 : UE cat. not eligible to 656 bits
Cat. 656 ; UE cat. eligible to 656 bits
HSDPA-HSDPA Mobility: In case of HSDPA-HSDPA mobility (intra or inter-frequency), the MAC-d PDU size can
not be reconfigured if the reconfiguration is disabled (isHighPerformancePduSizeReconfAllowed = False).

4.1.6 MAC-PDU size : Mobility HSDPA-HSDPA – Reconf allowed
MAC-d PDU size can be reconfigured or not isHighPerformancePduSizeReconfAllowed
depending on isHighPerformancePduSizeReconfAllowed = True
Cat. 656
Cell 656 Mac-d PDU size is reconfigured (336) Cell 336
Cell 336 Mac-d PDU size is reconfigured (656) Cell 656

Appendix
Cell 336 : cell restricted to 336 bits at RB setup

Cell 656 : cell not restricted to 336 bits at RB setup
Cat. 336 : UE cat. not eligible to 656 bits
Cat. 656 ; ue cat. eligible to 656 bits
HSDPA-HSDPA Mobility: In case of HSDPA-HSDPA mobility (intra or inter-frequency), the MAC-d PDU size can
be reconfigured according to configuration of new cell if the reconfiguration is enabled
(isHighPerformancePduSizeReconfAllowed = True).

4.1.7 MAC-PDU size : Mobility HSDPA-HSDPA – CEM type
iCEM does not support Mac-ehs thus no 64-QAM support

xCEM can support Mac-ehs when the feature is activated
If a cell does not support 64-QAM the mobile cat13 or plus will be handled
as a category 10 UE
64-QAM
Cell with xCEM 64 QAM to 16QAM/QPSK Reconfig. Cell with iCEM
Cell with xCEM No Reconfiguration Cell with xCEM

Appendix

4.1.8 MAC-PDU size : Mobility HSDPA - R99
Cat. 656
HSDPA R99
Cell 656 MAC-d PDU size is reconfigured (656 336) Cell 336
Cell 336 MAC-d PDU size is not reconfigured (336) Cell 336
Cat. 656
R99 HSDPA
Cell 336 MAC-d PDU size is reconfigured (336 656) Cell 656

Appendix
MAC-d PDU size is reconfigured for HSDPA to DCH or for DCH to HSDPA mobility.

4.1.9 MAC-PDU size : Mobility Over Iur – Reconf not allowed
“HSDPA over Iur” feature has to be activated = False
SRNC DRNC
Iur
Iub Iub
NodeB NodeB
SRNS Cat. 656 DRNS
Mobility of a 656 bits MAC-d flow is refused 656 not supported

Cell 656 leading to a DCH fallback of the RB by the SRNC on DRNS
(« HSxPA to DCH fallback » feature has to be activated)

Appendix
Mobility over Iur: In case of mobility over Iur (HS-DSCH cell change towards a DRNS), the MAC-d PDU size of
the HS-DSCH MAC-d flow is not reconfigured if the reconfiguration is disabled
(isHighPerformancePduSizeReconfAllowed = False). If the DRNS does not support the 656 bits configuration
it will refuse the mobility of a 656 bits MAC-d flow thus leading to a DCH fallback of the RB by the SRNC
(“HSxPA to DCH fallback” feature has to be enabled).

4.1.10 MAC-PDU size : Mobility Over Iur – Reconf allowed
“HSDPA over Iur” feature has to be activated = True
SRNC DRNC
Iur
Iub Iub
NodeB NodeB
SRNS Cat. 656 DRNS
656 not supported

Cell 656 MAC-d PDU size is reconfigured (656 336)
on DRNS

Appendix
If the reconfiguration is enabled (isHighPerformancePduSizeReconfAllowed = True), the MAC-d PDU size

can be reconfigured if necessary (MAC-d PDU size of the new cell is different from the current MAC-d PDU
size). When the SRNC has to setup an HS-DSCH MAC-d flow over Iur, it configures it using 336 bits.

4.1.11 Mac-d PDU size reconfiguration
Mac-d PDU size reconfiguration may also happen during transport channel type
switching (towards or from DCH/FACH, like Always-On)
PS in Cell_DCH
AO downsize : PS in Cell_Fach
mapped on
656 336 reconfiguration on FACH 336
HS-DSCH 656
PS in Cell_DCH
PS in Cell_Fach AO upsize :
mapped on
on FACH 336 336 656 reconfiguration
HS-DSCH 656

Appendix
MAC-d PDU size reconfiguration: MAC-d PDU size reconfiguration may only happen during transport channel
type switching (towards or from DCH/FACH, like Always-On), that is to say during HSDPA-R99 mobility or AO
transition.
One exception if when this channel switching is due to a RAB establishment (like a CS RAB or a second PS
RAB where a first PS RAB was in Cell_FACH due to inactivity).
In this case, the configuration use for the PS RAB on HS-DSCH is 336 bits. During a MAC-d PDU size
reconfiguration, all RLC SDUs that were under transmission (meaning they were already segmented and not
yet acknowledged by UE) are discarded by the RNC thus relying on TCP layer retransmissions.

4.2 High Quality UL R99 RAB for High HSDPA DL Rate - Issue
UE Node B RNC CN Application
Server
DL RLC PDU TCP data

(App. Data)
App. 1
TCP UL radio problem
ACKs UL RLC PDU
2 (App. Data)
n STATUS = NACK
1 UL TCP ACKs stored

Re-Tx
Burst of TCP
ACKs
CN discards application packets

Appendix
When performing high data rate downlink transfer on HSDPA (e.g. HSDPA Category 8 UE with 656 bits MAC-d
PDU performing DL FTP), the application-level UL ACKs must reach the application server with short delay
and at a regular pace, i.e. without bursts.
Indeed, if a burst of application-level UL ACKs (e.g. TCP UL ACKs) is received by the server, the server may
transmit on downlink an important amount of data at the same time.
If this important amount of data transmitted on downlink excesses the core network bandwidth, DL
application-level packets are lost, which leads to application level retransmissions. Such application-level
retransmissions may have an important impact on DL throughput and user experience.
Regarding the case of a call with HSDPA in the downlink and DCH in the uplink, it has been observed that
bursts of application-level UL ACKs occur when UL radio quality is degraded (UL radio BLER higher than
target BLER) even for a short period of time.
Indeed, if UL radio quality is degraded, UL RLC retransmissions occur. Since RNC waits for retransmitted
RLC-PDUs before transmitting data to the server (“In-Sequence-Delivery” mechanism), such UL RLC
retransmissions results in a burst of application-level UL ACKs sent to the server.

7.7 High Quality UL R99 RAB for High HSDPA DL Rate - Issue
4.2.1 Solution
eligibleUeCategoryForSirTargetHsdpa
(PowerConfClass)
RNC UlUserService
CS_AMR_NBxSRB_3_4K
CS_64KxSRB_3_4K
initialSirTargetHsdpa (UlUsPowerConf) PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
(NBAP) PS_384K_IBxSRB_3_4K
StandaloneSRBDCCH3_4K
...
UL SIR Target
maxSirTargetHsdpa (UlUsPowerConf)
minSirTargetHsdpa (UlUsPowerConf)
TTI

Appendix
From UA06, “Management of UL power profiles depending on whether HSDPA is mapped on the DL” sub-
feature of UA06 “Power Control Enhancements” feature allows improving UL radio quality for calls with
HSDPA high data rate in the downlink, thus avoiding the issue of bursts of application-level UL ACKs, which
improves DL throughput and user experience.
The management of UL power profile (initial value, lower bound and upper bound for UL SIR Target) for
HSDPA calls is handled by “Management of UL power profiles depending on whether HSDPA is mapped on
the DL” sub-feature of UA06 “Power Control Enhancements” feature. “Management of UL power profiles…”
sub-feature of UA06 “Power Control Enhancements” includes all the functionalities of UA05.1.2 regarding
the upper bound for UL SIR Target, and introduces the same concept for the initial value and the lower
bound.
For the HSDPA UE categories (e.g. HSDPA Category 8 UE) specified by the operator, and when in HSDPA call
(i.e. when a PS HS-DSCH DL RB is established), “Management of UL power profiles depending on whether
HSDPA is mapped on the DL” sub-feature of UA06 “Power Control Enhancements” allows using a specific set
of parameters for UL SIR Target initial value, lower bound and upper bound:
initialSirTargetHsdpa, minSirTargetHsdpa and maxSirTargetHsdpa.
These parameters can be set per UL service.
Note that from UA06, the default set of parameters (i.e. when in DL R99 call) for UL SIR Target initial
value, lower bound and upper bound is: initialSirTarget, minSirTarget and maxSirTarget. These
parameters can be set per UL service. “Management of UL power profiles…” sub-feature can be
activated/deactivated at cell cluster level, via eligibleUeCategoryForSirTargetHsdpa parameter under
PowerConfClass object.
CONDITIONS FOR APPLYING HSDPA-SPECIFIC UL POWER PROFILE
For a given call, system applies the HSDPA-specific UL power profile (i.e. initialSirTargetHsdpa,
minSirTargetHsdpa, maxSirTargetHsdpa) corresponding to the currently established UL service if the
following conditions are true:
• Current call is an HSDPA call (i.e. a PS HS-DSCH DL RB is established).
• HSDPA UE Category is eligible for “Management of UL power profiles…” sub-feature. Eligible HSDPA UE
Categories can be set via eligibleUeCategoryForSirTargetHsdpa parameter.
End of Module

Appendix

41
Section 4
Glossary
Module 1
9300 WCDMA

Blank Page

Glossary
Document History
01 2010-04-30 Chatila, Rayan First edition for UA7:

Elsner, Bernhard • 64-QAM modulation on HSDPA
Charneau, Jean-Noël • Flexible RLC and Mac-ehs
• Multiple xCEM per carrier

Abbreviations and Acronyms
# CS Circuit Switch
16-QAMSwitch to notes
16 – Quadrature view!
Amplitude CTCH Common Traffic CHannel
Modulation
1xEV-DO 1x EVolution Data Only D
1xEV-DV 1x EVolution Data and Voice DCCH Dedicated Control CHannel
1xRTT 1 times 1.25MHz Radio Transmission DCH Dedicated CHannel
Technology DL Downlink
3GPP 3rd Generation Partnership Project DPCCH Dedicated Physical Control CHannel
3xEV-DV 3x Evolution Data and Voice DPCH Dedicated Physical CHannel
DPDCH Dedicated Physical Data CHannel
A D-RNC Drift-Radio Network Controller
AAL2 ATM Adaptation Layer type 2 DS Delay Sensitive
AAL5 ATM Adaptation Layer type 5 DS-CDMA Direct Sequence-Code Division
ACK ACKnowledgment Multiple Access
AICH Acquisition Indicator CHannel DSCH Downlink Shared CHannel
AM Acknowledged Mode DTCH Dedicated Traffic CHannel
AMC Adaptive Modulation and Coding DTX Discontinuous Transmission
AMD Acknowledged Mode Data
AMR Adaptive Multi-Rate E
AO Always-On E1 Standard European PCM link (2.048
ARQ Automatic Repeat Query Mbps)
AS Access Stratum, Active Set EDGE Enhanced Data for Global Evolution
ASC Access Service Class EGPRS EDGE GPRS
ATM Asynchronous Transfer Mode
F
B 413 FA
All Rights Reserved © Alcatel-Lucent 2011 Frequency Allocation
BCCHGlossary Broadcast Control CHannel
FACH Forward Access CHannel
BCH Broadcast CHannel FBI FeedBack Information
BER Bit Error Rate FDD Frequency Division Duplex
BFN NodeB Frame Number FDMA Frequency Division Multiple Access
BLER BLock Error Rate FIFO First In First Out
BMC Broadcast Multicast Control FP Frame Protocol
BPSK Binary Phase Shift Keying
BR Bit Rate G
BTS Base Transceiver Station GBR Guaranteed Bit Rate
GMM Global Mobility Management
C GPRS General Packet Radio Service
CAC Call Admission Control GSM Global System for Mobile
CC Chase Combining communications
CCCH Common Control CHannel GTP GPRS Tunneling Protocol
CCP Communication Control Port
CCPCH Common Control Physical CHannel H
CCTrCH Coded Composite Transport CHannel
CDMA Code Division Multiple Access HARQ Hybrid ARQ
CEM Channel Element Module HFI HARQ Failure Indication
CFN Connection Frame Number HFN Hyper Frame Number
CID Channel IDentifier HO HandOver
CK Ciphering Key H-RNTI HS-DSCH Radio Network Temporary
CM Compressed Mode Identifier
CmCH-PI Common transport CHannel Priority HSDPA High Speed Downlink Packet Access
Indicator (SPI) HS-DPCCH High Speed Dedicated Physical
CP NodeB Control Port Control CHannel
CP Control Plane HS-DSCH High Speed Downlink Shared
CPCH Common Packet CHannel CHannel
CPICH Common PIlot CHannel HS-PDSCH High Speed Physical Downlink
CQI Channel Quality Indicator Shared CHannel
CRC Cyclic Redundancy Check HS-SCCH High Speed Shared Control Channel
C-RNC Controlling-Radio Network Controller HSUPA High Speed Uplink Packet Access
C-RNTI Cell-Radio Network Temporary
Identity

Abbreviations and Acronyms [cont.]
I Switch to notes view! NBAP Node B Application Part

IE Information Element NDI New Data Indicator
IK Integrity Key
ILPC Inner Loop Power Control
IMA Inverse Multiplexing ATM NDS Non-Delay Sensitive
iMCTA intelligent Multi Carrier Traffic Node B Logical node responsible for radio
Allocation Tx/Rx to/from UE
iMCRA intelligent Multi Carrier RRC Allocation NRZ Non Return to Zero
IMEI International Mobile Equipment
Identity O
IMSI International Mobile Subscriber OAM Operation Administration and
Identity Maintenance
IMT-2000 International Mobile OCNS Orthogonal Channel Noise Simulator
Telecommunication for year 2000 OLPC Outer Loop Power Control
IP Internet Protocol OLS Olympic Level Service
IR Incremental Redundancy OVSF Orthogonal Variable Spreading
iRM intelligent RAB Mapping Factor
Iu Interconnection point between RNC
and 3G Core Network P
Iub Interface between Node B and RNC PA Power Amplifier
Iur Interface between two RNCs PCCH Paging Control CHannel
P-CCPCH Primary-Common Control Physical
K CHannel
Kbps Kilobit per second PCH Paging CHannel
kHz kiloHertz PCM Pulse Code Modulation
KPI 4Glossary
14

Key Performance Indicator PCPCH Physical Common Control CHannel
Ksps 9300 WCDMAKilo symbol per second
PDP Packet Data Protocol
PDU Protocol Data Unit
PI Paging Indicator
L PI Priority Indicator
L1 Layer 1 (Physical Layer) PICH Paging Indicator CHannel
L2 Layer 2 (Data Link Layer) PIR Partial Incremental Redundancy
L3 Layer 3 (Network Layer) PLMN Public Land Mobile Network
LA Location Area PMM Packet Mobility Management
LAC Location Area Code PN Pseudo Noise
LAI Location Area Identity PQ Priority Queue
LAN Local Area Network PRACH Physical Random Access CHannel
LSB Least Significant Bit PS Packet Switch
P-SCH Primary-Synchronization CHannel
M PSK Phase Shift Keying
MAC Medium Access Control
Mbps Megabit per second Q
MBR Maximum Bit Rate QId Queue Identity
MCC Mobile Country Code QoS Quality of Service
MCPA Multi Carrier Power Amplifier QPSK Quadrature Phase Shift Keying
Mcps Megachip per second
MHz MegaHertz R
MIMO Multiple In Multiple Out R4 Release 4
MIR Mix Incremental Redundancy R5 Release 5
MM Mobility Management R6 Release 6
MNC Mobile Network Code RA Routing Area
MOC Managed Object Class RAB Radio Access Bearer
MOI Managed Object Instance RAC Routing Area Code
MOS Mean Opinion Score RACH Random Access CHannel
MRC Maximum Ratio Combining RAN Radio Access Network
MSB Most Significant Bit RANAP Radio Access Network Application
Part
N RB Radio Bearer
NACK Negative ACKnowledgement RF Radio Frequency
NAS Non Access Stratum RL Radio Link
Abbreviations and Acronyms [cont.]
RNSAP Radio Network

Switch Subsystem
to notes view!Application TrCH Transport CHannel
Part TS Time Slot
RNTI Radio Network Temporary Identity TTI Transmission Time Interval
RRC Radio Resource Control TX Transmitter / Transmission
RRM Radio Resource Management
RTWP Received Total Wideband Power
RTT Radio Transmission Technology U
RV Redundancy Version UARFCN UMTS Absolute Radio Frequency
RX Receiver / Reception Channel Number
UDP User Datagram Protocol
S UE User Equipment
SA Service Area UM Unacknowledged Mode
SAP Service Access Point UMTS Universal Mobile Telecommunication
SAW Stop And Wait System
S-CCPCH Secondary-Common Control UP User Plane
Physical CHannel UPH UE Power Headroom
SCH Synchronization CHannel URA UTRAN Registration Area
SCR Sustainable Cell Rate U-RNTI UTRAN-Radio Network Temporary
SDU Service Data Unit Identity
SF Spreading Factor UTRAN Universal Terrestrial Radio Access
SFN System Frame Number Network
SHO Soft HandOver Uu the radio interface between UTRAN
SI System Information and UE
SIM Subscriber Identity Module
SIR Signal to Interference Ratio V
SM 4Glossary
1 5Session Management

VCC Virtual Channel Connection
SNR 9300 WCDMA Signal to9300Noise
TMO18256 Ratio
WCDMA UAO7 HSxPA Algorithms Description VoIP Voice over IP
SPI Scheduling Priority Indicator (CmCH-
PI) W
SRLR Synchronous Radio Link W-CDMA Wideband-CDMA
Reconfiguration
S-RNC Serving-Radio Network Controller
S-SCH Secondary-Synchronization CHannel
STTD Space Time Transmit Diversity
STSR sectorial transmit and sectorial receive
SW Scheduling Weight
T
TAF That's All Folks!
TB Transport Block
TBS Transport Block Size
TC Traffic Class
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
TF Transport Format
TFC Transport Format Combination
TFCI Transport Format Combination
Indicator
TFI Transport Format Indicator
TFO Tandem Free Operation
TFRC Transport Format and Resource
Combination
TFRI Transport Format and Resource
Indicator
TFS Transport Format Set
THP Traffic Handling Priority
TPC Transmit Power Control

End of Module

Glossary

5
Section 5
iMCRA
TMO18256 Edition D0 SG DEN I3.0
9300 WCDMA

Section 5 Pager 1
Blank Page

iMCRA
Document History

Section 5 Pager 2
Module Objectives
Explain the benefits of intelligent Multi Carrier RRC Allocation

List redirection types
Explain the term „twin cells“
Describe the iMCRA capabilities
Distinguish the different iMCRA algorithm types
Explain the iMCRA RAN model

iMCRA

Section 5 Pager 3

iMCRA

Section 5 Pager 4
Table of Contents
Page
1 iMCRA overview 7
1.1 Why intelligent Multi Carrier RRC Allocation? 8
1.2 Redirection types 9
1.3 Twin cells definition 10
2 iMCRA Standard Solution - Capabilities 11
2.1 UE capabilities and Call type 12
2.2 Cell capabilities and faType 13
3 iMCRA Standard Solution - Algorithms 14
3.1 CapaOnly 15
3.2 CapaAndEstCause 16
3.3 PreferredFa 17
3.4 CAC 18
4 iMCRA Standard Solution - RAN model 19
4.1 iMCRA: RAN Model 20
5 iMCRA Standard Solution - Exercices 21
5.1 Exercise 1 22
5.2 Exercise 2 23
6 iMCRA with HSDPA Load - Activation 24
6.1 Feature Activation 25
7 iMCRA with HSDPA Load - Capabilities 26
7.1 UE capabilities and Call type 27
7.2 Call capabilities 28
7.3 Cell capabilities 29
8 iMCRA with HSDPA Load - Algorithms 30
55 8.1 Number of HSPA I/B services All Rights Reserved © Alcatel-Lucent 2011 31
iMCRA
8.2
9300 WCDMA DL power
TMO18256 HSPA
9300 WCDMA UAO7 HSxPACell colour
Algorithms Description 32
8.3 DL OVSF codes HSPA Cell colour 33
8.4 HSPA Cell Color 34
8.5 iMCRA Solution using HSDPA downlink load criterion 35
8.6 Example 36
8.7 Detailed algo in CapaOnly type 37
8.8 Detailed algo in CapaAndEstCause type 38
8.9 Detailed algo in PrefferedFa type 39
8.10 Detailed algo in CAC type 40
9 iMCRA with HSDPA Load - RAN model 41
9.1 RAN Model 42

Section 5 Pager 5

iMCRA This page is left blank intentionally

Section 5 Pager 6
1 iMCRA overview

iMCRA

Section 5 Pager 7
1 iMCRA overview
1.1 Why intelligent Multi Carrier RRC Allocation?
R99 R99 R99 R99 3G F3

R99 R99 R99 R99 R99
3G F2
HSDPA HSDPA HSDPA HSDPA HSDPA
3G F1
R99 R99 R99 R99 R99
R99 R99 R99 R99 R99
Why iMCRA ? Traffic Segmentation

UE & Cell Capability isRrcRedirectionInterFreq
RRC CAC Failure (RadioAccessService)
Load balancing

iMCRA
To increase the network capacity and optimize HSxPA throughput, operators may deploy multi-layer
configurations with several layers structures:
Multi-layers based on asymmetric topologies (dedicated layers for HSxPA or Data traffic separated
from dedicated layers for R99 or Conversational traffic),
Multi-layers based on symmetric topologies (shared layers for HSxPA and R99 traffic),
Several features are used in order to implement different multi-layers strategies for HSxPA, providing inter
carrier mobility:
Idle Mode & Hierarchical Cell Structure (HCS) allows strategies based on UEs camping homogeneously on
different frequencies or favor specific carriers or even prioritizing cell layers for mobiles in idle mode,
Cell_FACH and URA/Cell_PCH connected modes. The HCS cell reselection algorithm also takes into account
UE speed so that fast moving UEs can be placed in large cells to avoid excessive cell reselections.
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA) allows redirecting UE to FDD cells at RRC
connection establishment. iMCRA strategies are based on:
RRC Redirection based on UE Capabilities allowing redirecting UE at RRC connection establishment
based on their release and/or on the establishment cause sent to RNC in RRC Connection Request
message. It also allows redirecting UE to the preferred R99 layer.
RRC Redirection based on Preferred Frequency allowing redirecting different establishment causes
based on service type to the preferred frequency allocation or allowing redirection to the lowest
loaded frequency based on originating cell load.
RRC Redirection based on CAC failure allowing redirecting to another frequency upon SRB CAC
failure.
Intelligent Multi-Carrier Traffic Allocation (iMCTA) allowing handover UE to another layer when in
Cell_DCH connected mode.

Section 5 Pager 8
1 iMCRA overview
1.2 Redirection types
preferredFa
based on Frequency Allocation

Preferences
capaOnly capaAndEstCause
based on UE HSPA based on UE Capabilities

Capabilities only and Call Type
rrcRedirectionType
(InterFreqHhoFddCell)
Cac
None
based on RRC
Call Admission Failure Algorithm Disabled

iMCRA
During RRC Connection Setup procedure the RNC determines the preferred Frequency Allocation (FA) based
on:
UE capability only (Redirection based on UE HSPA capabilities already available in UA06 plus
segmenting R6+ UEs, plus choice of less loaded target cell);
UE capability and establishment cause (Redirection based on UE HSPA capabilities and call type
already available in UA06 plus segmenting R6+ UEs, plus choice of less loaded target cell)
Preferred FA (Select original cell or twin cell with lowest cell load)
Note: FA – Frequency Allocation = Carrier;
Optional FA classification: “Conversational”, “Data” or “Other” layer
OriginatingCellColourThresholdset to either GREEN/YELLOW/RED
GREEN: Full Load distribution; high number of redirections
RED: Load distribution only when originating cell gets overloaded
CAC (Redirection to twin cell with lowest load if CAC failure on originating cell)
None (Redirection disabled)

Section 5 Pager 9
1 iMCRA overview
1.3 Twin cells definition
Up to 5 twin cells can be defined :

- Inter-frequency cells from same or other NodeB
- With same or higher coverage than the original cell
NodeB1
twinCellList
FDD1
(InterFreqHhoFddCell)
CellId xyz
FDD2
FDD3
FDD4
FDD5
NodeB 2
5 10 All Rights Reserved © Alcatel-Lucent 2011

iMCRA
The twin cells are co-located inter-frequency cell plus cells from other Node B for blind redirection
referenced by Cell Id
Cells FDD2, FDD3, FDD4 and FDD5 are twin cells of cell FDD1.

Section 5 Pager 10
2 iMCRA Standard Solution - Capabilities

iMCRA

Section 5 Pager 11
2.1 UE capabilities and Call type
RNC
RRC/RACH (RRC Connection Request)

IE: Access Stratum Release (UE Release)
Establishment Cause
UE Capability Combinations Establishment Cause Call Type

UE Release UE Capability UE Capability Originating
Indication Deduced Conversational Call Conversational
Terminating
R99 N/A Conversational Call
DCH Originating Interactive
R6 or higher Absent
Originating Background
R5 N/A Originating Streaming

HSDPA Terminating Interactive
DATA
R6 or higher HS-DSCH Terminating Background
Terminating Streaming
R6 or higher HS-DSCH HSUPA
+ E-DCH Other Causes Other

iMCRA
The UE capabilities combinations are based on the Access Stratum Release Indication IE in the RRC
Connection Request message for the identification of the different UE types.
The call type identification is based on the Establishment Cause IE in the RRC Connection Request message
to distinguish the different call types.
Note:
In UA7 the following causes “Originating Subscribed Traffic Call”, “Registration” and “Originating High
Priority Signalling” are mapped to the Data type but they may be removed from the list of Data causes that
could perform a redirection. Indeed, for short and low traffic procedures some operators may prefer to
keep the UE on the originating cell that had been selected by the UE for access.
In UA7 the spare RadioAccessService.reserved2 byte 2 (3 rd byte) is used to handle the configuration
referred above. For future releases, Boolean; {True, False} parameter
RadioAccessService.isOrigHighPrioSigAndRegistPreferredDataCall will apply.

Section 5 Pager 12
2.2 Cell capabilities and faType
For capaOnly and capaAndEstCause type : For preferredFa type :

cell capability is determined by cell‘s capability is defined by
its HSDPA / EDCH activation parameters its faType parameter
RadioAccessService
RRCRedirectionConfClass 0..6
Cell Concept Cell Capability Cell Configuration

Frequency Allocation 1..6
Indication
R99 DCH Capable hsdpaActivation = False
edchActivation = False faType
HSDPA HSDPA Capable hsdpaActivation = True (InterFreqHhoFddCell)
edchActivation = False
HSxPA HSUPA Capable hsdpaActivation = True
edchActivation = True Conversational
Other
Data

iMCRA

Section 5 Pager 13
3 iMCRA Standard Solution - Algorithms

iMCRA

Section 5 Pager 14
3.1 CapaOnly
Step 2 : Load Balancing
layerPreferredForR99
isRrcRedirectionInterFreq = True Select “UE Capability”
compatible Cells among
originating and twin cells
rrcRedirectionType = capaOnly
If originating cell among

candidates
rrcRedirectOrigCellColorThreshold and its color < threshold,
(InterFreqHhoFddCell) Setup call in originating cell
Step 1 : Candidate Target Cell List Selection

Else select cells with lowest
UE capability Target FA Fallback FAs * load color (Green<Yellow<Red)
DCH DCH Cells Originating &

all twin cells
HSDPA HSDPA Cells HSUPA then selected ones, Setup call in it.
DCH Cells Else select the final target cell
with round robin mechanism
HSUPA HSUPA Cells HSDPA then (dlFrequencyNumber >
DCH Cells originating one)
* Fallback FA : Cells used in case Target FA is empty
iMCRA
Please note that an optional criterion introduced by UA6 feature 84900 is based on preferred layer to
distinguish the R99 services potentially served on preferred layer from the others. It is only applicable for
configurations using rrcRedirectionType = ‘capaOnly’ or ‘capaAndEstCause’.
In such condition, for all cells with layerPreferredforR99 = TRUE the RNC shall assume HSPA Cell
Capability = DCH. For all cells with layerPreferredforR99 = FALSE the RNC shall assume HSPA Cell
Capability = HSPA.
When to decide if a RRC connection should be redirected to DCH (R99) layer, function check
layerPreferredforR99 for both cells, in addition to the existing criteria’s. Only when both twin cells are
configured as HSPA capable, layerPreferredforR99 is checked. If the current cell does not prefer R99 but
the twin cell does, redirect is selected. Otherwise, the current behaviour is unchanged.
When to decide if a RRC connection should be redirected to HSPA layer, function check
layerPreferredforR99 for both cells, in addition to the existing criteria’s. Only when both twin cells are
configured as HSPA capable, layerPreferredforR99 is checked. If the current cell prefers R99 but the twin
cell does not, redirect is selected. Otherwise, the current behaviour is unchanged.
This option applies in case HSxPA is deployed on both layers (allowing both layers to carry HSPA traffic and
keeping RRC Traffic Segmentation enabled for R5+ UEs). It is possible to prefer some of the HSPA capable
layers for R99 traffic by using parameter layerPreferredforR99 (it is possible to configure several cells
with layerPreferredForR99=TRUE and to configure R99-only cells, layerPreferredForR99 cells and HSPA
cells):
DCH service originated on non-preferred cell will be redirected to the
preferred cell
HSxPA service originated on preferred cell will be redirected to the nonpreferred cell
This algorithm is enhanced from UA6.0, i.e. RNC is able to find preferred HSxPA cells for DCH traffic in case
using RRC Traffic Segmentation based on UE Capabilities. This enhancement is only applicable if the
originating cell and operational twin cell is enabled for HSDPA (parameter hsdpaActivation).
Emergency calls are redirected in case of CAC failure, only.

Section 5 Pager 15
3.2 CapaAndEstCause
layerPreferredForR99 Step 2 : Load Balancing
isRrcRedirectionInterFreq = True Select “UE Capability & Call
type” compatible Cells among
rrcRedirectionType = capaAndEstCause originating and twin cells
rrcRedirectOrigCellColorThreshold
Step 1 : Candidate Target Cell List Selection candidates
and its color < threshold,
UE capability Call type Target FA Fallback Setup call in originating cell
FAs
Conversational DCH
DCH Else select cells with lowest
Data DCH
load color (Green<Yellow<Red)
Other Originating
Conversational DCH
Same as in
HSDPA Data HDSPA capaOnly If originating cell among
selected ones, Setup call in it.
Other Originating Else select the final target cell
Conversational DCH with round robin mechanism
(dlFrequencyNumber >
HSUPA Data HSUPA originating one)
Other Originating
iMCRA

Section 5 Pager 16
3.3 PreferredFa
faType
Select “preferred FA type”
isRrcRedirectionInterFreq = True compatible Cells among
originating and twin cells
rrcRedirectionType = preferredFA

candidates
and its color < threshold,
rrcRedirectOrigCellColorThreshold Setup call in originating cell

Call Type Target FA Fallback FAs Else select cells with lowest
load color (Green<Yellow<Red)
Select FAs with FAs of type other;
Conversational faType set to if none FAs of type
Conversational Data
Select FAs with FAs of type other; selected ones, Setup call in it.
Data faType set to if none FAs of type Else select the final target cell
Data conversational with round robin mechanism
(dlFrequencyNumber >
Other Any available originating one)
cell referenced
for redirection

iMCRA

Section 5 Pager 17
3.4 CAC
isRrcRedirectionInterFreq = True
rrcRedirectionType = cac

If CAC failure occurs,
RNC select cells with lowest
cell color (green < yellow < red)
RRC Connection Request

If more than one cell selected, Select
CAC Failure on Originating Cell the final target cell with round robin
mechanism (dlFrequencyNumber>
originating one)

Target FAs : Twin cells for all cases of CAC failure (R99, HSPA, CS…)

iMCRA
RRC Redirection can trigger re-try of RRC Connection Allocation procedure when CAC failure occurs.
If CAC occurred during SRB establishment on the originating cell then the RNC considers redirection to a list
of twin cells. Emergency calls are also redirected in case of CAC failure.
iMCRA Interaction with 3G to 2G Redirect for Speech Calls:
If iMCRA is activated with rrcRedirectionType= cac (cares for redirection to another frequency only. Not
for redirection to GSM), if CAC occurred during SRB establishment on the originating cell then the RNC
considers redirection to another FDD cell; this is applicable to all establishment causes.
If both iMCRA & 3G/2G Redirect for Speech calls are activated, Originating Conversational call or
Emergency call is redirected by feature 3G/2G Redirect for Speech calls (CAC) to GSM only when the
redirection triggered by iMCRA fails CAC again on target cell selected.
If rcRedirectionType= cAC is not configured and 3G/2G Redirect for Speech calls is activated, RNC decides
to redirect to 2G Conversational or Emergency calls upon SRB CAC failure on originating cell.
iMCRA Interaction with 3G to 2G Redirection based on cell load:
If both iMCRA and 3G to 2G Redirection based on cell load are activated, for Originating Conversational call
or Emergency call, when target twin cell(s) are selected by iMCRA RRC Redirection and all the twin cell
loads reach the configurable threshold for 3G/2G redirection, the UE can be redirected to 2G using RRC
Connection Reject message by 3G to 2G Redirection based on cell load.

Section 5 Pager 18
4 iMCRA Standard Solution - RAN model

iMCRA

Section 5 Pager 19
4 iMCRA Standard Solution - RAN model
4.1 iMCRA: RAN Model
RNC
isRrcRedirectionInterFreq
FddCell
RrcRedirectionConfClass 0..6 InterFreqHhoFddCell

rrcRedirectionConfClassId
rrcRedirectionType
FrequencyAllocation 1..6 twinCellList
dlFrequencyNumber rrcRedirectOrigCellColourThreshold
ulFrequencyNumber
faType
fddFrequencyUserLabel

iMCRA

Section 5 Pager 20
5 iMCRA Standard Solution - Exercices

iMCRA

Section 5 Pager 21
5.1 Exercise 1
Suggest the parameters’ values for the 3 different configuration strategies:
I. Always perform redirection based on UE type and Establishment cause

II. Always perform redirection based on call type only
III. Perform redirection based on load only and only if originating cell is RED
Parameter Value I. Value II. Value III.

rrcRedirectionType
rrcRedirectOrigCellColourThresh
old
faType FDD1
faType FDD2
faType FDD3

iMCRA

Section 5 Pager 22
5.2 Exercise 2
R5 (HSDPA) UE
Config 1 Config 2
MO I/B
isRrcRedirectionInterFreq True True
FDD1 rrcRedirectionType capaAndEstCa PreferredFa
use
FDD2 rrcRedirectOrigCellColour Yellow Yellow
Threshold
FDD3 Cell Type faType
FDD4 FDD1 CellA HSUPA Data
FDD2 Cell B HSUPA Data

FDD5
FDD3 Cell C HSUPA Other
FDD6 FDD4 Cell D R99 Data
FDD5 Cell E R99 Other
FDD6 Cell F R99 Conversational
Question: For both configuration scenarios determine which is the target cell
for the RRC Establishment.

iMCRA

Section 5 Pager 23
6 iMCRA with HSDPA Load - Activation

iMCRA

Section 5 Pager 24
6 iMCRA with HSDPA Load - Activation
6.1 Feature Activation
RNC
RadioAccessService
isHspaCellLoadAllowedForImcra
isHsxpaR99ResourcesSharingOnCellAllowed
Fair Sharing

iMCRA
If parameter isHspaCellLoadAllowedForImcra = TRUE the RNC shall determine the new

downlink HSPA Load Colour (DL HSPA load) for each controlled, operational and HSPA
capable cell as the maximum colour of “DL power HSPA Cell colour” & “DL OVSF codes
HSPA Cell colour”.
The load calculation is based on the assumption that Fair Sharing is active.
Fair sharing can be activated on cell basis with parameter
isHsxpaR99ResourcesSharingOnCellAllowed.
For cells with isHsxpaR99ResourcesSharingOnCellAllowed = FALSE the RNC will set HSPA
DL Load Colour to the fix value BLACK.
The iMCRA with HSDPA Load is applicable only to HSPA I/B. For R99 & HSPA Str, we use the iMCRA standard
solution, as the standard solution already takes into account R99 & HSPA Str load.

Section 5 Pager 25
7 iMCRA with HSDPA Load - Capabilities

iMCRA

Section 5 Pager 26
7.1 UE capabilities and Call type
RNC
RRC/RACH (RRC Connection Request)

IE: Access Stratum Release (UE Release)
Establishment Cause
UE Capability Combinations Establishment Cause Call Type

UE Release UE Capability UE Capability Originating
Indication Deduced Conversational Call Conversational
Terminating
R99 N/A Conversational Call
DCH Originating Interactive
R6 or higher Absent
Originating Background
R5 N/A Originating Streaming

HSDPA Terminating Interactive
DATA
R6 or higher HS-DSCH Terminating Background
Terminating Streaming
R6 or higher HS-DSCH HSUPA
+ E-DCH Other Causes Other

iMCRA
The UE capabilities combinations are based on the Access Stratum Release Indication IE in the RRC
Connection Request message for the identification of the different UE types.
The call type identification is based on the Establishment Cause IE in the RRC Connection Request message
to distinguish the different call types.
Note:
In UA7 the following causes “Originating Subscribed Traffic Call”, “Registration” and “Originating High
Priority Signalling” are mapped to the Data type but they may be removed from the list of Data causes that
could perform a redirection. Indeed, for short and low traffic procedures some operators may prefer to
keep the UE on the originating cell that had been selected by the UE for access.
In UA7 the spare RadioAccessService.reserved2 byte 2 (3 rd byte) is used to handle the configuration
referred above. For future releases, Boolean; {True, False} parameter
RadioAccessService.isOrigHighPrioSigAndRegistPreferredDataCall will apply.

Section 5 Pager 27
7.2 Call capabilities
For capaOnly type :
call capability = UE Capability
For capaAndEstCause type :

call capability is given by table below
UE Capability Call Type Call Capability

Conversational
DCH
DCH Data
Other Originating cell
Conversational DCH
HSDPA Data HSDPA
Conversational DCH
HSUPA Data HSUPA
Note : Call capability is not used in PreferredFa & CaC types

iMCRA

Section 5 Pager 28
7.3 Cell capabilities
Cell Capability Cell Concept Capability Indication Cell Configuration
R99 R99 DCH Capable hsdpaActivation = FALSE
edchActivation = FALSE
Unloaded “R99/HSPA” or R99/HSDPA HSDPA Capable hsdpaActivation TRUE

Loaded “R99/HSPA” edchActivation = FALSE
layerPreferredforR99 = TRUE
R99/HSxPA HSUPA Capable hsdpaActivation = TRUE

edchActivation = TRUE
layerPreferredforR99 = TRUE
Unloaded “Pure” HSPA HSDPA HSDPA Capable hsdpaActivation TRUE

or Loaded “Pure” HSPA edchActivation = FALSE
layerPreferredforR99 = FALSE
HSxPA HSUPA Capable hsdpaActivation = TRUE

edchActivation = TRUE
layerPreferredforR99 = FALSE
An R99/HSPA cell is loaded if DL/UL DCH load > twinCellTargetCellColourThreshold or

DL HSPA load > twinCellTargetHspaCellLoadThreshold
A “Pure” HSPA cell is loaded if DL HSPA load > twinCellTargetHspaCellLoadThreshold

(uplink load is ignored in this case)
iMCRA
The concept of Cell Capability (used to select the applicable cells for redirection) is updated:
For options ‘UE Capability Only’ & ‘Capability and Establishment Cause’ the RAB matching shall take into
account Call Capability and Cell Capabilities:
For option ‘Preferred FA’ the RAB matching shall take into account the Call Type and the Frequency
Allocation definition “Conversational”, “Data” or “Other”;
For selecting the applicable cells for redirection from the originating cell and its twin cells a new
overloaded concept is added with:
An R99/HSPA cell is loaded if DL/UL DCH load > twinCellTargetCellColourThreshold or DL HSPA load >
twinCellTargetHspaCellLoadThreshold
A “Pure” HSPA cell is loaded if DL HSPA load > twinCellTargetHspaCellLoadThreshold (uplink load is
ignored in this case)
Note: The value of parameters twinCellTargetCellColourThreshold and
twinCellTargetHspaCellLoadthreshold is taken from the originating cell and applies to all possible
targets, i.e. originating cell and twin cells.

Section 5 Pager 29
8 iMCRA with HSDPA Load - Algorithms

iMCRA

Section 5 Pager 30
8.1 Number of HSPA I/B services
nb_current_HSDPA_I_B_services is updated based on

incoming message concerning a HSDPA serving link
NBAP/RNSAP RL Reconfiguration prepare/cancel,
NBAP/RNSAP RL Setup/failure and
NBAP/RNSAP RL Release
C-RNC being SRNC or DRNC
One Dual Carrier-user counts for 1 connection in the anchor

and 1 connection in the secondary carrier

iMCRA
The RNC determine the number of PS I/B services configured in downlink over HSDPA with
or without MinBR (nb_current_HSDPA_I_B_services) per cell. This includes
PS I/B services with the C-RNC being SRNC and with the C-RNC acting as DRNC;
PS I/B services on secondary cell for Dual Cell HSDPA calls (one Dual Carrier-user
counts for 1 connection in the load criterion incremented both on the anchor and
the secondary carriers);
nb_current_HSDPA_I_B_services is updated based on incoming NBAP/RNSAP RL
Reconfiguration prepare/cancel, RL Setup/failure and RL Release which concerns a
HSDPA serving link, and it is used on “DL power HSPA Cell colour” and “DL OVSF codes
HSPA Cell colour” formulas.

Section 5 Pager 31
8.2 DL power HSPA Cell colour
max_tx_power_cell
powerused
for
Dl_load_power_avail_HSPA_wo_GBR_MinBR HSDPA I/B traffic
E-DCH
HSDPA_GBR
dl_power_HSDPA_GBR
DCH
dl_power_R99 OCNS (opt.)
dl_power[R99+HSDPA GBR]
CCCNodeB
CPICH
Dl_load_power_avail_HSPA_wo_GBR_MinBR
RDl_load_power_avail_HSPA_wo_GBR_MinBR =
max_tx_power_cell
RDl_load_power_avail_HSPA_wo_GBR_MinBR
HSPA_dl_power_Load = 1-
Nb_current_HSDPA_I_B_services + 1

iMCRA
“DL power HSPA Cell colour” formula is based on NBAP common measurements from
Node-B existing functionality. The DL Power HSPA cell load calculation relies in the
concept of estimating the DL power available for a new HSDPA PS I/B with or without
MinBR service. Conceptually, if the number of R99 or HSPA users starts increasing in the
cell the available power for a new HSDPA PS I/B will decrease in proportion. By
subtracting to 100% the estimated power available for a new HSDPA PS I/B the RNC will
get the DL power HSPA cell load.
HSPA_dl_power_load = 1 - HSPA_dl_power_share
HSPA_dl_power_share
= dl power resource share available for next HSPA without GBR service
= dl_load_power_avail_HSPA_wo_GBR_MinBR[ratio] div (nb_current_HSDPA_I_B_services +
1)
With:
Dl_load_power_avail_HSPA_wo_GBR_MinBR[ratio] =
(max_tx_power – dl_power [R99 + HSDPA GBR]) div max_tx_power_cell
dl_power[R99+HSDPA GBR] = Total Transmitted Carrier Power of all codes not used for
HSDPA and E-DCH + HS-DSCH required power needed to ensure the GBR power.

Section 5 Pager 32
8.3 DL OVSF codes HSPA Cell colour
1..15
HsdpaUsedSF16 = fair bitrate / ovsfCodesThroughputQpsk/16QAMUe
SF4
R99 R99
SF8
SF16
HS-PDSCH HS-PDSCH
SF16 Pool SF16 Pool
SizeBiggestSf16Pool - ∑ HsdpaUsedSF16
RDl_load_codes_avail_HSPA_wo_GBR_MinBR =
16
RDl_load_codes_avail_HSPA_wo_GBR_MinBR
HSPA_dl_codes_Load = 1-
Nb_current_HSDPA_I_B_services + 1

iMCRA
“DL OVSF codes HSPA Cell colour” formula is based on DL OVSF management framework
introduced by feature 33694 HSxPA & R99 Fair Sharing Resource. The DL OVSF codes HSPA
cell load calculation relies in the concept of estimating the DL OVSF codes available for a
new HSDPA PS I/B with or without MinBR service. Conceptually, if the number of R99 or
HSPA users starts increasing in the cell the available codes for a new HSDPA PS I/B will
decrease in proportion. By subtracting to 100% the estimated codes available for a new
HSDPA PS I/B the RNC will get the DL OVSF codes HSPA cell load.
HSPA_dl_codes_load = 1 - HSPA_dl_codes_share
HSPA_dl_codes_share
= dl code resource share available for next HSPA without GBR service
= dl_load_codes_avail_HSPA_wo_GBR_MinBR[ratio] div (nb_current_HSDPA_I_B_services +
1)
With:
Dl_load_codes_avail_HSPA_wo_GBR_MinBR[ratio] = (SizeBiggestSf16Pool -
TotalHsdpaUsedSF16) / 16
SizeBiggestSf16Pool: Variable introduced by UA06 feature 33694. The number of free
codes in the largest SF16 code block. Note that a code block consists of a number of
successive SF16 codes. This is an integer value.
TotalHsdpaUsedSF16: Variable introduced by UA06 feature 33694. The minimum number
of SF16 codes that are allocated in use for HSDPA in one cell calculated based on HSDPA
GBR, HSDPA MinBR and HSDPA I/B without MinBR (mib value).

Section 5 Pager 33
8.4 HSPA Cell Color
%Load
100%
•Red2Black_th
Black2Red_th
•Yellow2Red_th
Red2Yellow_th
Green2Yellow_th
Yellow2Green_th
•0%
HSDPA Cell Color = worse (HSPA code load, HSPA power load)

iMCRA
The HSPA Cell load color is the maximum (the worst) between the HSPA code load and the
HSPA power load.
Remeber:
For cells with isHsxpaR99ResourcesSharingOnCellAllowed = FALSE the RNC will set HSPA
DL Load Color to the fix value BLACK.

Section 5 Pager 34
8.5 iMCRA Solution using HSDPA downlink load
criterion
Target cell selection by RNC for an HSPA data call

Twin cells are first ranked according to their overload and traffic type
preference.
Unloaded “HSPA preferred” > Unloaded “Rel 99 preferred” > Loaded “HSPA
preferred”> Loaded “Rel99 preferred” > DCH only layer
Select the originating cell if the originating cell is among the set of
selected cells and if the originating cell color is better than the
originating threshold
DL HSPA load (F0) < rrcRedirectOrigHspaCellLoadThreshold and
UL DCH load (F0) < rrcRedirectOrigCellColourThreshold
Otherwise if more than one cell is selected:
If the originating cell is one of the target cells then the UE should remain in
originating cell.
Else, from the remaining cells of the twinCellList the target cell is selected
with round robin mechanism

iMCRA
The main idea for HSPA cell load usage by iMCRA is the following:
1. Candidate Target Cell List selection
Target cells for redirection are selected according to their overload and traffic type
preference:
Unloaded “Pure HSPA” > Unloaded “R99/HSPA” > Loaded “Pure HSPA”> Loaded
“R99/HSPA” > DCH only layer
DCH call: "DCH only layer" or “R99/HSPA” > “Pure HSPA”
2. Load Balancing phase

If the originating cell is selected as candidate target cell then RRC redirection may be
triggered if the originating cell HSPA load is higher than or equal to the originating
load threshold
If all candidate cells (originating & twin target) have the same cell capability then if
source cell has better colour or the same colour as best twin cell then no redirection
is triggered

Section 5 Pager 35
8.6 Example
Condition on the originating cell : RRC redirection may be trigged if the

originating cell HSPA load is > rrcRedirectOrigHspaCellLoadThreshold
Status of the target cell: A cell can be a candidate target for a redirection if
the cell HSPA load is ≤ targetHspaCellloadThreshold
Example: F0 is an access layer dedicated to Rel. 99
targetHspaCellloadThreshold targetHspaCellloadThreshold
F2 (F1 or F2) = BLACK F2 (F1 or F2) = RED
F1 F1
rrcRedirectOrigHspaCellLoadT rrcRedirectOrigHspaCellLoadT
F0 hreshold(F0) = GREEN F0 hreshold(F0) = GREEN
F1 & F2 are HSPA layers F0 is F1 & F2 are HSPA layers F0 is Rel99 layer
Rel99 layer
⇒ RRC redirection to HSPA layers is always triggered ⇒ new data call with an HSPA capable UE is assigned to
F0 (Rel 99)
iMCRA

Section 5 Pager 36
8.7 Detailed algo in CapaOnly type
UE Call
UE
Capability Capability Selected Candidate Target FA Target Cell Selection Algorithm
Release
Indication (Deduced)
R99 N/A DCH 1.Select DCH cell, R99/HSPA cell Unloaded 1.If for a HSPA call more than one cell with HSPA
and R99/HSPA cell Loaded; capability is selected then selects the cells that fit
>= R6 Absent
best to the Call capability: HSDPA Call -> first
2.Select HSPA cell Unloaded and HSPA cell HSDPA cell then HSUPA cell, and HSUPA Call ->
Loaded if (1) not available; First HSUPA cell then HSDPA cell.
R5 N/A HSDPA 1.Select “Pure” HSPA cell Unloaded;
2.If originating cell among candidates & cell colour
>= R6 HS-DSCH better than threshold, setup call on originating cell
2.Select R99/HSPA cell Unloaded If (1) not
>= R6 HS-DSCH HSUPA available;
3.Else select cells with lowest cell colour; for DCH
+ E-DCH
use normal cell colour threshold (green < yellow <
3.Select “Pure” HSPA cell Loaded If (1) & (2)
red); for HSxPA Calls first select cells with lowest
not available;
DL HSPA load then select cells with lowest UL
DCH load; for DL use new set of HSPA cell colour
4.Select R99/HSPA cell Loaded If (1) & (2) &
threshold (green < yellow < red < black);
(3) not available;
4.If originating cell among selected ones, setup call
5.Select DCH cell If (1) & (2) & (3) & (4) not
in it. Else select the final target cell with round robin
available;
mechanism;

iMCRA

Section 5 Pager 37
8.8 Detailed algo in CapaAndEstCause type
Call
UE
Call Type Capability Selected Candidate Target FA Target Cell Selection Algorithm
Capability
(Deduced)
DCH Conversational DCH 1.Select DCH cell, R99/HSPA cell Unloaded and R99/HSPA cell 1.If for a HSPA call more than one cell with
Loaded; HSPA capability is selected then selects the
Data 2.Select HSPA cell Unloaded and HSPA cell Loaded if (1) not cells that fit best to the Call capability:
available; HSDPA Call -> first HSDPA cell then
HSUPA cell, and HSUPA Call -> First
Other Originating Originating Cell HSUPA cell then HSDPA cell.
Cell 2.If originating cell among candidates & cell
HSDPA Conversational DCH 1.Select DCH cell, R99/HSPA cell Unloaded and R99/HSPA cell colour better than threshold, setup call on
Loaded; originating cell
2.Select HSPA cell Unloaded and HSPA cell Loaded if (1) not 3.Else select cells with lowest cell colour; for
available; DCH use normal cell colour threshold (green
< yellow < red); for HSxPA Calls first select
Data HSDPA 1.Select “Pure” HSPA cell Unloaded; cells with lowest DL HSPA load then select
2.Select R99/HSPA cell Unloaded If (1) not available; cells with lowest UL DCH load; for DL use
3.Select “Pure” HSPA cell Loaded If (1) & (2) not available; new set of HSPA cell colour threshold (green
4.Select R99/HSPA cell Loaded If (1) & (2) & (3) not available; < yellow < red < black);
5.Select DCH cell If (1) & (2) & (3) & (4) not available; 4.If originating cell among selected ones,
Other Originating Originating Cell setup call in it. Else select the final target cell
Cell with round robin mechanism;
HSUPA Conversational DCH 1.Select DCH cell, R99/HSPA cell Unloaded and R99/HSPA cell
Loaded;
2.Select HSPA cell Unloaded and HSPA cell Loaded if (1) not
available;
Data HSUPA 1.Select “Pure” HSPA cell Unloaded;
2.Select R99/HSPA cell Unloaded If (1) not available;
3.Select “Pure” HSPA cell Loaded If (1) & (2) not available;
4.Select R99/HSPA cell Loaded If (1) & (2) & (3) not available;
5.Select DCH cell If (1) & (2) & (3) & (4) not available;
Other Originating Originating Cell
Cell

iMCRA

Section 5 Pager 38
8.9 Detailed algo in PrefferedFa type
Selected
Call Type Fallback FAs Target Cell Selection Algorithm
Target FA
Conversational Select the FAs FAs of type 1.If originating cell among candidates & cell colour
with faType ‘Other’, if none better than threshold, setup call on originating cell
set to FAs of type
‘Conversation ‘Data’ 2.Else select cells with lowest cell colour; for DCH
al’ use normal cell colour threshold (green < yellow <
red); for HSxPA Calls first select cells with lowest DL
Data Select the FAs FAs of type
HSPA load then select cells with lowest UL DCH
with faType ‘Other’, if none
load; for DL use new set of HSPA cell colour
set to ‘Data’ FAs of type
threshold (green < yellow < red < black);
‘Conversational’
Other Select every 3.If originating cell among selected ones, setup call in
configured FA it. Else select the final target cell with round robin
for the mechanism;
originating
cell

iMCRA

Section 5 Pager 39
8.10 Detailed algo in CAC type
Target Cell Selection Algorithm
1.If CAC failure occurs, select cells with lowest cell colour; for DCH use normal cell colour threshold (green < yellow
< red); for HSxPA Calls first select cells with lowest DL HSPA load then select cells with lowest UL DCH load; for DL
use new set of HSPA cell colour threshold (green < yellow < red < black);
2.Select the final target cell with round robin mechanism;

iMCRA

Section 5 Pager 40
9 iMCRA with HSDPA Load - RAN model

iMCRA

Section 5 Pager 41
9 iMCRA with HSDPA Load - RAN model
9.1 RAN Model
New UA7.1 parameter RNC New UA7.1 Object
New UA7.1.2 parameter
New UA7.1.2 Object
DedicateConfClass NodeB RadioAccessService

isHspaCellLoadAllowedForImcra
CacConfClass FddCell
isPinitRrcRedirectionAllowed
twinCellTargetHspaCellLoadthreshold
twinCellTargetCellColourThreshold
HspaCellLoadParameters
InterFreqHhoFddCell RrcRedirectionConfClass 0..6
green2YellowHSPAPwrDlLoadThreshold rrcRedirectionConfClassId
yellow2GreenHSPAPwrDlLoadThreshold rrcRedirectionType
yellow2RedHSPAPwrDlLoadThreshold twinCellList
red2YellowHSPAPwrDlLoadThreshold rrcRedirectOrigCellColourThreshold FrequencyAllocation 1..6
red2BlackHSPAPwrDlLoadThreshold rrcRedirectOrigHspaCellLoadThreshold
Black2RedHSPAPwrDlLoadThreshold dlFrequencyNumber
green2YellowHSPACodesDlLoadThreshold ulFrequencyNumber
yellow2GreenHSPACodesDlLoadThreshold faType
yellow2RedHSPACodesDlLoadThreshold fddFrequencyUserLabel
red2YellowHSPACodesDlLoadThreshold
red2BlackHSPACodesDlLoadThreshold
Black2RedHSPACodesDlLoadThreshold

iMCRA

Section 5 Pager 42
Module Summary

Benefits of intelligent Multi Carrier RRC Allocation
Redirection types
iMCRA capabilities
iMCRA algorithm types
iMCRA RAN model

iMCRA

Section 5 Pager 43

for this module

iMCRA

Section 5 Pager 44
End of Module

iMCRA

Section 5 Pager 45
Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent @@YEAR
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 2

HSPA Algos UA07 TMO18256D0SGDENI3.0 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HSPA Algos UA07 TMO18256D0SGDENI3.0 PDF

Uploaded by

Copyright:

Available Formats

9300 WCDMA

TMO18256 9300 WCDMA UAO7

All Rights Reserved © Alcatel-Lucent 2011

All rights reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

2 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

All rights reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

3. Topic/Section is Positioned Here

5 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

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

7 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

9 All Rights Reserved © Alcatel-Lucent 2011

Where you can get further information

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

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2011

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2011

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

112 All Rights Reserved © Alcatel-Lucent 2011

Edition Date Author Remarks

All Rights Reserved © Alcatel-Lucent 2011

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

Describe HSDPA principles and associated parameters

113 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

114 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

117 All Rights Reserved © Alcatel-Lucent 2011

All Rights Reserved © Alcatel-Lucent 2011

Transport channel Frame Protocols

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:

112 All Rights Reserved © Alcatel-Lucent 2011

113 All Rights Reserved © Alcatel-Lucent 2011

114 All Rights Reserved © Alcatel-Lucent 2011

117 All Rights Reserved © Alcatel-Lucent 2011

1 1 10 All Rights Reserved © Alcatel-Lucent 2011

1 1 11 All Rights Reserved © Alcatel-Lucent 2011

1 1 14 All Rights Reserved © Alcatel-Lucent 2011

1 1 15 All Rights Reserved © Alcatel-Lucent 2011

1 1 16 All Rights Reserved © Alcatel-Lucent 2011

1 1 18 All Rights Reserved © Alcatel-Lucent 2011

1 1 19 All Rights Reserved © Alcatel-Lucent 2011

1 1 20 All Rights Reserved © Alcatel-Lucent 2011

1 1 22 All Rights Reserved © Alcatel-Lucent 2011

1 1 23 All Rights Reserved © Alcatel-Lucent 2011