HSxPA Algorithms Description

9300 WCDMA
TMO18256 9300 WCDMA UAO7

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

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description - Page 1
Empty page
Switch to notes view!
9300 WCDMA
TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description
This page is left blank intentionally

Terms of Use and Legal Notices

1. Safetyto
Warning
Switch
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 AlcatelLucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written consent of Alcatel-Lucent.
9300 WCDMA
All rights reserved Alcatel-Lucent 2010
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not AlcatelLucent 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. AlcatelLucent 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
HSDPA
About
This1.Course
4. Topic/Section is Positioned Here
Course outline
Module 1. HSDPA TMO18256
Technical
support
Section 2. HSUPA
Course objectives
Module 1. HSUPA TMO18256
Section 3. Appendix
1. Topic/Section
is Positioned Here
Module 1. Appendix TMO18256
Xxx
Xxx
Section
4. Glossary
Xxx
Module 1. Glossary TMO18256
Section 5. iMCRA
Module 1. iMCRA 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
used
in this guide
Switch
to notes
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.]

10
9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each

Course title :
Please, return this
Client (Company, Center) :
Language
:
Switch
section you will be asked to fill this questionnaire

sheet to the trainer at the end of the training
to notes view!
Number of trainees :
Dates from :
to :
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
Instructional objectives
1
Yes (or
globally
yes)
No (or
globally
no)
To be able to XXX
2
11
9300 WCDMA

Comments
Self-assessment of Objectives [cont.]

Instructional objectives
12
Yes (or
Globally
yes)
No (or
globally
no)
Comments
9300 WCDMA
Other comments
Thank you for your answers to this questionnaire

Do not delete this graphic elements in here:
11
Section 1
HSDPA Algorithms Description
Module 1
TMO18256 D0 SG DEN I1.0
9300 W-CDMA
UA06 HSxPA Algorithms Description

3JK11636AAAAWBZZA Issue 1.1
Section 1 Module 1 Page 1
Blank Page
112
HSDPA Algorithms Description Module 1

9300 W-CDMA UA07 HSxPA Algorithms Description
Document History
Edition
Date
Author
Remarks
01
2010-04-30
Elsner, Bernhard
Charneau, Jean-Nol
First edition

Module Objectives
Upon completion of this module, you should be able to:
Describe HSDPA activation principles and associated parameters
Describe HSDPA radio resource management parameters
Describe HSDPA mobility features and associated parameters
113


Module Objectives [cont.]
114

Table of Contents
Page

1 HSDPA Activation
1.1 HSDPA Distributed Architecture
1.2 HSDPA Activation Flags
1.3 64 QAM On HSDPA Activation Flags
1.4 HSDPA Capable-UE Supported
1.5 H-BBU Resource Allocation
1.5.1 M-BBU Resource Allocation xCEM case
1.5.2 Multiple xCEM per carrier
1.5.3 Parameters involved in CEM configuration
1.6 HSDPA/E-DCH Service Indicator broadcast
1.7 Transport Channel
1.8 Physical Channels
1.9 DL OVSF Code Tree
1.10 HSDPA Key Features
1.11 AMC Principles
1.12 UE Capabilities and Max Bit Rates
1.13 HARQ Types
1.14 Modulation Schemes
1.15 Constellation Rearrangement (16QAM)
1.16 64 QAM On HSDPA
1.17 Redundancy Version Parameters
1.18 Flexible RLC and MAC-ehs
1.19 HARQ Stop and Wait Principles
1.20 HARQ Mechanisms
1 1 5 1.21 Optimal Redundancy Version for
HARQ retransmission
9300 W-CDMA
UA07 Channel
HSxPA Algorithms Coding
Description
1.22
: Recall
1.23 Selection of the Redundancy Version per HARQ process
1.24 Multi-RAB handling on HSDPA
1.25 Multi-RAB and GBR handling on HSDPA
1.26 User Services supported with HSDPA
2 HSDPA RRM
2.1 RAB Matching and CAC
2.2 HSDPA to DCH Fallback
2.3 Fair Sharing
2.3.1 Call Admission Control & Power Reservation
2.3.2 Call Admission Control & Codes Reservation
2.3.3 Fair Sharing - RAN Model
2.4 Initial Rate Capping during RB reconfiguration
2.4.1 Initial Rate Capping during RB reconfig: RAN Model
2.5 QoS Mapping
2.6 Scheduling Priority Indicator (SPI)
2.7 UE, QId and SPI
2.8 NodeB Scheduler
2.9 Dynamic Code Tree Management
2.9.1 HS-PDSCH OVSF Codes Allocation
2.9.2 HS-PDSCH Codes Preemption / Reallocation
2.9.3 DCTM RNC RAN Model
2.9.4 DCTM NodeB RAN Model
2.10 HSDPA DL Power Reservation at RNC
2.11 Dynamic PA Power Sharing R99/HSPA Carriers
2.11.1 Impact on DCH DL CAC and DL iRM
2.12 HSDPA DL Power Available at NodeB
2.13 HSDPA Power - RAN Model
2.14 HSDPA Power Distribution
2.15 HSDPA Full Power Usage

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Table of Contents [cont.]

Page

2.16 HS-SCCH Power Control
2.17 HS-PDSCH Dynamic Power Allocation for 1st Transmission
2.19 HSDPA Flexible Modulation
2.20 CQI Modification Principles
2.21 HS-DPCCH detection based on CQI
2.22 CQI adjustment based on BLER: blerRangeBasedAlgo
2.23 CQI adjustment based on BLER: OuterLoopLikeAlgorithm
2.24 CQI adjustment based on BLER: Dynamic BLER Adjustment
2.24.1 CQI adjustment based on BLER: Dynamic BLER Adjustment
2.25 HS-PDSCH Power Adaptation for Retransmissions
2.26 HS-DPCCH Power
2.27 Scheduler iCEM
2.27.1 Schedulers using Cost Function C1 only
2.27.2 Schedulers using Cost Functions C1 and C2: C1
2.27.4 C2 Parameters
2.28 Scheduler xCEM
2.28.1 SNR ESTIMATION FOR HS-PDSCH
2.28.2 TFRC SELECTION
2.28.3 TFRC SELECTION Summary
2.28.4 SPI management for GBR Mac-d flows
2.28.5 SPI management for non GBR Mac-d flows
2.28.6 SPI management
1 1 6 2.29 Scheduler: SPI management All Rights Reserved Alcatel-Lucent 2010
9300 W-CDMA
UA07 Dynamic
HSxPA Algorithms Description
2.30
MAC-d PDU size
2.30.1 MAC-d PDU size
2.30.2 MAC PDU size Configuration
2.30.3 How to configure a Mac-d PDU size of 656 bits
2.30.4 MAC-d PDU size Selection
2.30.5 MAC-PDU size : Mobility HSDPA-HSDPA
2.30.6 MAC-PDU size : Mobility HSDPA - R99
2.30.7 MAC-PDU size : Mobility Over Iur
2.30.8 Mac-d PDU size reconfiguration
2.31 Transport Block Size Optimization: CQI 1 to 15, all UE cat.
2.32 High Quality UL R99 RAB for High HSDPA DL Rate - Issue
2.32.1 UA05.1 Solution
2.32.2 UA06 Solution
2.33 Always On for HSDPA/DCH: Mono-Service PS / Mono-RAB
2.34 Always On for HSDPA/DCH: Multi-Service PS / Multi-RAB PS
3 HSDPA Mobility
3.1 3G->2G HHO
3.2 3G->3G Intra-RNC Inter-freq HHO
3.3 3G->3G Inter-RNC Inter-freq HHO
3.4 HSDPA over Iur
3.4.1 64-QAM over Iur: Not Supported
3.4.2 Iub Bandwidth Management

63
64
65
66
67
68
69
70
71
72
74
75
76
77
78
79
80
85
86
87
88
89
90
91
92
93
94
95
96
97
98
101
102
104
105
106
107
108
109
110
111
112
113
114
115
116
117
1 HSDPA Activation
117


1 HSDPA Activation
1.1 HSDPA Distributed Architecture

HS-PDSCH
new
HS-SCCH
Data Transfer (PS I/B)
Downlink Transfer Information

(UEid, OVSF,...)
Introduction of MAC-ehs
RNC
Iub
HS-DPCCH
DPCH
Feedback Information
(CQI, ACK/NACK)
Upper Layer Signaling
Transport channel
HS-DSCH
RLC
MAC-d
RLC
MAC-d
New MAC-ehs Layer

Replaces MAC-hs
MAC-ehs
PHY
UE
118
Uu
Frame Protocols
HS-DSCH
MAC-ehs
HS-DSCH
FP
Flow control
PHY
L2
L1
Iub
NodeB
HS-DSCH
FP
L2
L1
RNC

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 MACehs 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 Activation
1.2 HSDPA Activation Flags
RNC
NodeB
BTSEquipment
FddCell
hsdpaActivation
RadioAccessService
BTSCell
hsdpaResourceActivation
119
UmtsNeighboring
RemoteFDDCell
isHsdpaAllowed
isHsdpaAllowed

HSDPA activation main switch is located at RNC level, under the Radio Access Service subtree. If the value
of isHsdpaAllowed is set to TRUE, then all the new MOIs required for HSDPA operation should be defined in
the RNC configuration.
Activation consists in:
at BTS level, set hsdpaResourceActivation to TRUE.
at RNC level, set isHsdpaAllowed to TRUE
and at Cell level hsdpaActivation to TRUE.
Note that HSDPA needs to be activated at BTS level first, and that prior to the activation on a BTS, a new
VCC shall be created on the corresponding Iub link to carry HSDPA traffic.
Deactivation can be performed at two levels:
deactivation at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA
dedicated resources preserved,
deactivation at cell level: setting hsdpaActivation and hsdpaResourceActivation to FALSE completely

deactivates HSDPA.
Note that isHsdpaAllowed exists also in two other objects (RNC/NeighboringRNC and
RNC/NodeB/FDDCell/UMTSFddNeighboringCell) in order to know if the HSDPA call has to be reconfigured or
not in DCH when the primary cell changes in case of mobility over Iur.

1 HSDPA Activation
1.3 64 QAM On HSDPA Activation Flags
new
isDl64QamAllowed (FDDCell)
NO
NodeB 64QAM capable?
isDl64QamOnRncAllowed
(RadioAccessServicel)
YES
NO
UE 64QAM
= capable?
is64QamAllowedForUeCategory
(HsdpaRncConf)
YES
NO
NodeB 64 QAM Activated?

YES
NO
UE CAT 64-QAM Eligible?

YES
Node B
64-QAM Eligible
1 1 10
QPSK / 16-QAM

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

1 The NodeB is 64QAM capable: The NodeB indicates to the RNC its 64QAM capability through the
SixtyfourQAMDLCapability IE in the NBAP Audit Response or Resource Status Indication messages
2 The UE is 64QAM capable: The UE informs the RNC of its capabilities in the RRC Connection Setup
Complete message:-MAC-ehs support IE concerning the support of the MAC-ehs/RLC flexible size
feature (3GPP R7).-HS-DSCH physical layer category extension IE corresponding to the HS-DSCH
category supported by the UE when Mac-ehs is configured (If the Mac-ehs is not configured, the SRNC
doesnt use this IE but the HS-DSCH physical layer category IE, corresponding to the HS-DSCH category
supported by the UE when MAC-ehs is not configured)
3 The NodeB is allowed to used the 64QAM: RadioAccessService.isDl64QamOnRncAllowed = True and
FDDCell.isDl64QamAllowed = True Mac-ehs enabled
4 The UE category is allowed to used the 64QAM: HsdpaRncConf. is64QamAllowedForUeCategory = 1 for
all the UE categories supporting 64QAM, that is to say 13,14,17,18 If all these conditions are fulfilled,
then the NodeB will send the new HS-SCCH to inform the UE of the modulation used (QPSK, 16QAM or
64QAM) depending on the TFRC selection algorithm.

1 HSDPA Activation
1.4 HSDPA Capable-UE Supported
slide + notes
Max Peakupdated
Rate
HS-DSCH Category
HS-PDSCH Max Number
Inter-TTI Min Interval
Modulation
Category 1
QPSK & 16-QAM
1.2 Mbps
Category 2
QPSK & 16-QAM
1.2 Mbps
Category 3
QPSK & 16-QAM
1.8 Mbps
Category 4
QPSK & 16-QAM
1.8 Mbps
Category 5
QPSK & 16-QAM
3.6 Mbps
Category 6
QPSK & 16-QAM
3.6 Mbps
Category 7
10
QPSK & 16-QAM
7.3 Mbps
Category 8
10
QPSK & 16-QAM
7.3 Mbps
Category 9
15
QPSK & 16-QAM
10.2 Mbps
Category 10
15
QPSK & 16-QAM
14.4 Mbps
Category 11
QPSK only
0.9 Mbps
Category 12
QPSK only
1.8 Mbps
QPSK mandatory for HSDPA capable UE

16/64QAM optional
1 1 11

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 HSDSCH / 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 Activation

iCEM case
BTSEquipment
UL
HS-DPCCH
DL
HS-DPDCH(s)
HS-SCCH(s)
MAC-hs
HARQ
Scheduler
Link Adaptation (AMC)
BTS
iCEM128
HsdpaConf
HsdpaResourceId
H-BBU
H-BBU
iCEM128
BTSCell
iTRM
MCPA
DDM
iTRM
MCPA
DDM
iTRM
MCPA
DDM
H-BBU
D-BBU
iCEM64
iCEM128
iCCM
H-BBU
D-BBU
D-BBU
CEMa
D-BBU
D-BBU
1 1 12
Digital Shelf
Radio Shelf

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.5.1 M-BBU Resource Allocation xCEM case

xCEM
BBU
BBU
DCH
DCH
DCH
DCH
xCEM
BBU
BBU
BBU
BBU
BBU
BBU
HSUPA
HSDPA
HSUPA
DCH
DCH
HSDPA
BBU
BBU
HSDPA
HSDPA
xCEM
BBU
BBU
Multimode
Multimode
BBU
BBU
Multimode
Multimode
BTSEquipment
05
UA
BBU
BBU
notes
updated
HsXpaResource
BBU
BBU
DCH
DCH
BBU
BBU
HSDPA
HSDPA
-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
BBU
BBU
Multimode
Multimode
BBU
BBU
Multimode
Multimode
1 1 13
DPCCH, DPDCH
(DCH + SRB + CCH)
all HSDPA channels
all HSUPA channels

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.5.2 Multiple xCEM per carrier
new
xCEM 1
Cell 1
Cell 2
Cell 3
xCEM 1
Cell 1
Cell 5
Cell 6
Cell 3
Cell 2
Cell 4
Cell 2
Cell 5
Cell 6
xCEM 3
xCEM 2
Cell 3
Cell 4
1xCEM: 256 CE
& 4.7/1.7Mbps DL/UL/Cell
UA05.1
& UA06
xCEM 2
xCEM 1
Cell 1
Cell 4
Cell 5
Cell 6
2xCEM: 512 CE
& 9.3/3.4Mbps DL/UL/Cell
3xCEM: 768CE
& 14/5Mbps DL/UL/Cell
UA07.1.2
xCEM 1
xCEM 2
xCEM 3
Cell 1
Cell 2
Cell 3
xCEM 4
4xCEM: Cell 1,2,3 for
1 1 14
Cell 4
Cell 5
Cell 6
HSPA+ Max HSDPA Rel 7

capabilities guaranteed
On one carrier

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 reconfiguration 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.5.3 Parameters involved in CEM configuration
slide
updated
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

1 1 15

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 Activation
1.6 HSDPA/E-DCH Service Indicator broadcast

isHsxpaServiceIndicatorEnabled
(RadioAccessService)
RNC
SIB5
SIB5
NodeB
NodeB
non HSDPA
cell
HSDPA cell
HSDPA UE
notes
updated
Auto
hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod
Auto
HSDPA UE
(FDDCell)
HSDPA
OK!
1 1 16
HSDPA
NOK!

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 EDCH)) 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 Activation

HSDPA Downlink transport channel: HS-DSCH
BTSCell
HsdpaConf
DTCH
Traffic
TRB
Mobile i
HS-DSCH
DL
HS-PDSCH
Downlink
TTI: 2ms
TBS free attribute of Transport format
AMC = f(CQI)
HARQ
Turbo coding 1/3
CRC 24bits
harqType
harqTypeXcem
HS-SCCH
HS-DPCCH
1 1 17

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 Activation
RadioAccessService
DTCH
Traffic
TRB
HsdpaCellClass
HS-DSCH
DL
HS-PDSCH
HS-SCCH
numberOfHsPdschCodes
numberOfHsScchCodes
HS-DPCCH
1 1 18

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 subframes 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 HSDPCCH 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 Activation
1.9 DL OVSF Code Tree

SF256
SF128
SF64
SF32
SF16
SF8
SF4
Common channels (including S-CCPCH/1)
S-CCPCH/0
1
0
2
S-CCPCH/2
1
3
4
2
5
STATIC
Allocation
5
6
HS-SCCH
1
6
3
DYNAMIC
Allocation
8
4
Free OVSF codes
9
2
numberOfHsScchCodes
10
5
11
12
6
HS-PDSCH
13
3
STATIC or DYNAMIC
Allocation
14
7
15
1 1 19

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 Activation
1.10 HSDPA Key Features

RNC
slide
updated
Capacity Request
Control FP
Capacity Allocation
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
1 1 20
Radio Transmission

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 Activation
1.11 AMC Principles
UE Category
Reported CQI
AMC Illustration
800
700
Throughput (kbps)
2ms
AMC
600
500
QPSK
QPSK
QPSK
16QAM
16QAM
400
300
200
100
Coding
Rate
Modulation
Scheme
Number of
OVSF Codes
-20
-15
-10
-5
Ior/Ioc (dB)
Maximum Throughput
1 1 21

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 HSDPA Activation
notes
updated
Category 6 UE CQI Mapping Table

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

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 HSDSCH 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 Activation
1.13 HARQ Types

Chase Combining
DATA
DATA
NACK
DATA
DATA
NACK
NACK
{mirType, pirType, ccType, drType, WithPowerAdaptation}

{ccType, irType}
DATA
NACK
ACK
BTSEquipment
harqType
harqTypeXcem
HsdpaConf
Incremental Redundancy Combining

DATA
DATA1
NACK
1 1 23
DATA2
NACK
BTSCell
DATA3
NACK
DATA4
NACK
ACK

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 HSDPA Activation
1.14 Modulation Schemes

16QAM
Q
QPSK
1011
1001
0001
0011
Q
1010
1000
0000
0010
10
00
11
01
I
1110
1100
0100
0110
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
1 1 24

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 HSDPA Activation
1.14 Constellation Rearrangement (16QAM)

Q
1011
1001
0001
0011
1110
0110
0100
1100
1010
1000
0000
0010
1010
0010
0000
1000
b=0
1110
1100
0100
0110
1011
0011
0001
1001
1111
1101
0101
0111
1111
0111
0101
1101
b=1
1000
1010
0010
0000
0010
1010
1000
0000
1001
1011
0011
0001
0110
1110
1100
0100
b=2
1101
1111
0111
0101
0111
1111
1101
0101
1100
1110
0110
0100
0011
1011
1001
0001
1 1 25
b=3

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

1 HSDPA Activation
1.16 64 QAM On HSDPA
new
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.
1 1 26

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 (64QAM or MIMO). These UE categories are MAC-ehs capable MIMO is not supported in UA07.

1 HSDPA Activation
Kmax
1.17 Redundancy Version Parameters

MIR RV Update Table
RV Coding
16QAM XRV
QPSK XRV
QPSK XRV
16QAM XRV
TRV[k]
RV Update
New Tx?
QPSK XRV
16QAM XRV
DTX?
YES
XRV=XRV
CC RV
NO
k=k+1
XRV= TRV[k mod Kmax]
TRV[k]
1 1 27
XRV=TRV[0]
k=0
NO
Kmax
PIR RV Update Table
YES

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 HSDPA Activation
1.18 Flexible RLC and MAC-ehs
RLC SDU
new
The RLC SDU
segmentation into fixed
size RLC PDUs may lead
to padding in RLC PDU.
User payload
RLC PDU (fixed size)
Pad.
MAC-d PDU
MAC-hs PDU
MAC-hs
header
MAC-hs SDU
Pad.
The Transport Block Size is

the result of the TRFC
selection algorithm. A non
negligible number of
padding bits may be
required to fit the
Transport Block Size.
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
1 1 28

The new features in UA07 Flexible RLC and MAC-ehs are selected on a per-call basis. The selection is
based on the following criteria:
Criteria for Mac-ehs selection:
RNC capability (feature activation flag), FddCell capability (feature activation flag)
NodeB local cell capability (notified to the RNC at NodeB startup in the NBAP RSI and NBAP Audit
Response
UE capability (notified to the RNC at RRC Connection Request)
Once Mac_ehs has been selected, criteria for Flexible RLC selection are based on the radio bearer to be
setup:
PS I/B: flexible RLC is always chosen
PS Str: flexibled RLC is chosen if isRlcFlexibleSizeForPsStrAllowed = TRUE
Other RB : fixed RLC is always chosen
The Layer2 Improvements feature has the following restrictions:

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

1 HSDPA Activation
1.18 Flexible RLC and MAC-ehs [cont.]
RLC SDU
new
No need for padding
as RLC PDU size can
be adjusted to fit
exactly the size of the
RLC SDU
User payload
RLC PDU
(flexible size)
MAC-d PDU 1
MAC- d PDU
(=MAC-ehs SDU)
MAC-d PDU 2
MAC-d PDU 3
MAC-ehs
PDU
MAC-ehs
header
ReorderingSDU 1
Pad-
Reordering SDU2
header
MAC-ehs
header
Reordering PDU
Reordering PDU
Padding bits are

reduced as MAC-ehs
can segment a MAC-d
PDU in case it cannot
fit into the selected
Transport Block
1 1 29

Intra-NodeB intra-frequency mobility with the source cell and the target cell having different Mac-ehs
capability: the NodeB does not support such reconfiguration:
Intra-Node mobility from Mac-hs to Mac-ehs capable cell: the RB remain configured with Mac-hs.
Intra-Node mobility from Mac-ehs to Mac-hs capable cell: the RB are fallbacked to R99.
Note: anyway there is no rationale for a customer to setup such configuration (FDDCell A isMacEhsAllowed
= False and FDDCell B and C isMacEhsAllowed =True) !
Note: such restriction does not exist for intra-NodeB inter-frequency mobility.
The Layer2 Improvements feature has the following restrictions:
Inter RNC with IUR mobility (SRNS Relocation - UE not involved)
The RB remains with Mac-hs (as it was before SRNS relocation took place, refer to the restriction: not
supported over IUR).

It may be reconfigured to Mac-ehs at the next inter-NodeB mobility occasion to a cell Mac-ehs capable.
Note that such restriction does not exist for Inter RNC without Iur mobility (SRNS relocation UE involved):
the RB are reconfigured accordingly to the capability of the cell in the Target RNC.

1 HSDPA Activation
1.19 HARQ Stop and Wait Principles

HARQ
Wait for Transmission

UE is Scheduled
Update RV Parameters
TB1
HARQ
TB2
HARQ
Transmit Data
HSDSCH
Wait for ACK/NACK Reception
ACK
ACK/NACK/DTX?
DTX
Insert DTX
Indication
NACK
Reset & Free

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

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 HSDPA Activation
1.20 HARQ Mechanisms

Ack
Data 1
Data 2
Ack
Transmissions
Data 5
Data 2
Data 6
Data 1
RV0 RV1 RV2
Process 0
Process 1
Process 2
Process 3
Nack Data 2
Ack Data 3
Data 3
Data 4
notes
updated
Ack/nack
Ack
Data 4
Nack Data 2
Nack Data 6
Ack
Data 7
Ack
Data 8
Ack
Data 2
Ack
Data 6
Ack
Data 9
Ack
Data 10
Ack
Data 11
Ack
Data 12
Ack
To next step
(demultiplexing)
Data 5
combining
Data 3
Data 7
Data 4
Data 8
Data 5
Data 2
Data 7
Data 6
Data 9
Data 10
Data 11
Data 12
Data 13
Data 1
Data 8
combining
Data 2
Data 6
Data 9
Data 10
Data 11
Data 13
Data 12
Data 13
1 1 31

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 Activation
1.21 Optimal Redundancy Version for HARQ retransmission

harqType
(hsdpaConf)
if
= drType or DRWithPowerAdaptation
First RTx?
PIR
QPSK XRV
16QAM XRV
QPSK XRV
16QAM XRV
16QAM XRV
QPSK XRV
YES
FIR
Dynamic
RV Table
Selection
CC+CoRe
maximum number of bits per HARQ

number of RM2 punctured bits
number of systematic bits
total number of radio bits
CC
1 1 32

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 HSDPA Activation
1.22 Channel Coding : Recall
First Rate
Matching
NSYS
Systematic
bits
Input
Data
Turbo
Coding
Virtual
IR Buffer
Parity 1
bits
RM P1_1
Parity 2
bits
RM P2_1
1/3
NP2
NP1
Second Rate
Matching
RM S
RM P1_2
Spreading &
Modulation
RM P2_2
NIR
NRM1
NDATA
NPUNC2
1 1 33

Definitions from 3GPP 25.212:

NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes times the modulation order (2
or 4) times 960 bits ???
NIR: maximum number of soft bits available in the virtual IR buffer per HARQ process the UE can
handle. It only depends on the UE category and the number of allocated HARQ processes.
NSYS: number of systematic bits
NP1 and NP2: number of parity bits 1 and 2 after 1st RM step.
NRM1 = NSYS + NP1 + NP2
NPUNC2 = NRM1 - NDATA: number of bits punctured by 2nd RM stage.

1 HSDPA Activation
1.23 Selection of the Redundancy Version per HARQ process

NACK received
1st retrans
No
Use RV tables of HARQ type

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

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 HSDPA Activation
1.24 Multi-RAB handling on HSDPA
notes
updated
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
1 1 35

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 Activation
1.25 Multi-RAB and GBR handling on HSDPA
notes
updated
isMultiRabOnHsdpaAllowed (RadioAccessService)
enabledForRabMatching (multi-RAB DlUserService)
enabledForRabMatching (multi-RAB UlUserService)
NodeB
Higher SPI and smaller GBR served first
HS-DSCH
DCH
1 1 36
QI0
QI0
SP4
QI1
SP6
cmCH-PI 6
cmCH-PI 4
UEN
CID n
PDU flow1
If not All GBR flows satisfied
cmCH-PI 6
UE0
CID m
PDU flow0
cmCH-PI 4
Core Network
CID l
PDU flow0
GBR QIx priority

>
Non GBR QIy priority
RNC
isGbrOnHsdpaAllowed (RadioAccessService)
QI2
SP4 SP6
Streaming, Interactive, Background

Speech, Video telephony

Before UA06:
GBR only possible over DCH Transport channel
Since UA06:
From UA06.0 guaranteed bit rate (GBR) available for applications mapped on HS-DSCH Transport
channel GBR and non-GBR MAC-d flows are scheduled using common pool of resources available for
HSDPA (like power, code and time)
GBR queues are given priority over non-GBR traffic and within GBR queues higher SPI traffic is served
first
Within each SPI, if not all the GBR flows satisfied then the priority is given to those with least demanded
bandwidth
This can mean that flows with higher SPI and smaller GBR will always get served while those in lower SPI
as well as non-GBR flows will suffer from lack of throughput

Activated by simple RNC switch attribute
isGbrOnHsdpaAllowed under RadioAccessService
Benefits:
Allows support of following radio access bearers over HSDPA
PS Streaming (non-buffered delay sensitive applications)
PS Interactive/ Background with minimum bit rate (minBR) constraint
Enables ALU customers to support real-time video and audio multimedia services, real-time interactive
services (like games) and interactive or background services for Gold subscribers over HSDPA
Efficient use of air-interface resources by HSDPA made available to real-time services, enhancing
capacity in mixed configuration and off-loading such users from DCH in multi-layer configuration

1 HSDPA Activation
1.26 User Services supported with HSDPA

HSxPA
Stand-alone
PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384
PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)
PS Streaming HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128
Combination
CS Conv. Speech + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384
CS Conv. 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 Str. HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128
(CS Conv. Speech +) (PS I/B HSDPA/DCH+) PS Streaming (HSDPA or DCH/DCH) :
PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64,128
(CS Conv. Speech +) (PS I/B HSDPA/HSUPA+) PS Streaming (HSDPA or DCH/DCH) :
PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64
1 1 37

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

those that can support a maximum of 32kbps on DCH with a simultaneous HS-DSCH configuration,
those that can support a maximum of 64kbps,
those that can support a maximum of 128kbps,
and those that can support a maximum of 384kbps.
As a consequence:
UE with a maximum capability of 32kbps does not support:

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

PS Streaming DL:256kbps+PS I/B (HS-DSCH)
There is no limitation for UE with a maximum capability of 384kbps.

The DL capability with simultaneous HS-DSCH configuration IE is ignored by the RNC in UA05. Consequently,
there will be a failure if the RNC attempts to establish one of the previously listed combinations for the
corresponding UE. To avoid this situation, it is possible to fallback all (CS+)PS Streaming+PS I/B
combinations to DCH.
This option is not activated by default but there is a flag to activate it:
isPsStreamingOnHSDPAAllowed (radioAccessService)
When set to false, all PS I/B + PS Str combinations will be mapped into DCH.

2 HSDPA RRM
1 1 38


2 HSDPA RRM
2.1 RAB Matching and CAC
notes
updated
RNC
RAB Request
RNC
Service = PS?
NO
RadioAccessService
YES
Traffic Class
STR,= I/B?
HsdpaCellClass
NO
maximumNumberOfUsers
YES
BTSEquipment
HSDPA UE?
NO
hsdpaMaxNumberUserHbbu
YES
Primary Cell = HSDPA Cell?
hsdpaMaxNumberUserXcem
NO
Capacity
YES
hsdpaNumberUserCapacityLicensing
HSDPA RAB
R99 RAB
HSDPA CAC
1 1 39

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.

2 HSDPA RRM
2.2 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
established
DCH RB
to established
1 1 40

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.

2 HSDPA RRM
2.3 Fair Sharing

True
isGbrOnHsdpaAllowed
False
HS-DSCH required power for GBR (PS Str) + minBr (PS I/B)
HS-DSCH required power for minBR (PS I/B)
GBR On GBR info sent to NodeB (GBR or minBR)

FS On HS-DSCH required power
hsdschReqPwFilterCoeff
hsdschReqPwReportingPeriod
(NBAPMeasurement)
hsdpaCodeTreeManagementActivation
(BTSEquipment)
I/B MinBR
TC/ARP/THP
OVSF
STR GBR
Used
isHsxpaR99ResourcesSharingOnCellAllowed
DlPowerSelfTuningForPsIbOnHsdpaEnabled
(FDDCell)
NodeB dynamic OVSF codes management:

HSDPA RNC
CAC
Power
Monitor the DL OVSF code tree occupancy

Determine the codes available for HSPDSCH scheduling
Used
Initial Radio Resources
(power, codes)
1 1 41
Reconfigure the H-BBU accordingly via a

new internal message

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.
2.3 Fair Sharing
2.3.1 Call Admission Control & Power Reservation

I/B MinBR
TC/ARP/THP
STR GBR
Min(RANAP MBR)
minBrForHsdpa
RANAP GBR
HSDPA RNC
CAC (Power)
Ps Str
Traffic Power
(SHO reserved)
Ps I/B
dlTxPowerEstimation*
P traffic admission
Traffic
Power
x
fair bitrate
x
Pres
initialActivityFactorForIb
Pused
Overhead
Power
(CCC+OCNS
+ E-DCH)
R99 used
+
HSDPA Required Power (GBR)
+
HSDPA Reserved Power (non GBR
with minBR)
(*) is an power relative to P-CPICH power

1 1 42

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 HSDSCH cell.
The power to reserve for this HS-DSCH RAB is directly proportional to the fair bitrate:
power = dlTxPowerEstimation x 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
2.3 Fair Sharing
2.3.2 Call Admission Control & Codes Reservation

minBrForHsdpa 0
or
minHsDschReservationForCac
if minBrForHsdpa = 0
I/B MinBR
TC/ARP/THP
STR GBR
HSDPA RNC
CAC (Codes)
reservationFactorOnCodesForGbrTraffic
minBR > 0
For UE category 11 and 12:
Nb of SF16 codes = fair bitrate /
1..15
ovsfCodesThroughputQpskUe
For UE category 1 to 10:
1..15
ovsfCodesThroughput16QamUe
Nb of SF16 codes = fair bitrate /
1 1 43

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.

2.3 Fair Sharing
2.3.3 Fair Sharing - RAN Model

RNC
NodeB
Parameter for GBR on HSDPA in UA06.0
FDDCell
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
1 1 44


2 HSDPA RRM
new
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
maxDlEstablishmentRate
(CacConfClass)
= True
New set of capping parameters
maxUlEstablishmentRate
(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
1 1 45

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

Always-On
2.4.1 RAN Model
new
RAS
DedicatedConf/CacConfClass
DchRateCapping
maxDlRateHsdpaAndDchToDchAndDch
maxDlEstablishmentRbRate
maxUlEstablishmentRbRate
maxDlRateHsdpaAndEdchToDchAndDch
maxDlRateRabEstablishDchAndDch
maxDlRateTransitionToDchDlTriggerDchAndDch
maxDlRateTransitionToDchUlTriggerDchAndDch
maxUlRateHsdpaAndDchToDchAndDch
maxUlRateHsdpaAndEdchToDchAndDch
maxUlRateHsdpaAndEdchToHsdpaAndDch
isOamCappingOfDataAllowed
isUlRbRateAdaptationAllowed
isDlRbRateAdaptationAllowed
maxUlRateRabEstablishDchAndDch
maxUlRateRabEstablishHsdpaAndDch
maxUlRateTransitionToDchDlTriggerDchAndDch
maxUlRateTransitionToDchDlTriggerHsdpaAndDch
maxUlRateTransitionToDchUlTriggerDchAndDch
maxUlRateTransitionToDchUlTriggerHsdpaAndDch
1 1 46


2 HSDPA RRM
2.5 QoS Mapping

slide
updated
QoS differentiation is based on TC, ARP and THP parameters

Service differentiation
Subscriber differentiation
Virtual Office
Privileged
=> emails
users
Web Browsing
Video Streaming
3GPP
OLS: Olympic Level Service (gold, silver,bronze)
TC: Traffic Class
ARP: Allocation/Retention Priority Mapping MLP: MAC Logical Channel Priority
table
SPI: Scheduling Priority Indicator
THP: Traffic Handling Priority
ALUs RNC
UTRAN & Core

1 1 47

There are mainly two reasons why operators wish to implement QoS differentiation:
Service differentiation:
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 :

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.
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 RRM
2.6 Scheduling Priority Indicator (SPI)

From
From RAB Request
RAB assignment
assignment Request
Used as inputs to RRM algorithms to

provide user QoS differentiation
Traffic
class
OLS
slide
updated
OLS:
Used as input to iRM Tables & AO
Subscriber Differentiation
MLP:
ARP
THP
MLP
SPI
Streaming
N/A
Gold
N/A
15
Streaming
N/A
Silver
N/A
14
Streaming
N/A
Bronze
N/A
13
Interactive
Gold
12
Interactive
Gold
11
Interactive
Gold
10
Interactive
Silver
Interactive
Silver
Interactive
Silver
Interactive
Bronze
Interactive
Bronze
Interactive
Bronze
Background
N/A
Gold
Background
N/A
Silver
Background
N/A
Bronze
1 1 48
Used to prioritize the different PS I/B RABs assigned

to the same user (at the MAC layer).
Service Differentiation
SPI:
Derived SPI is provided by the RNC to the BTS per
MAC-d for MAC-(e)hs prioritization in the HSDPA
scheduler
Subscriber Differentiation
RadioAccessService
TrafficClassBasedQos0..3
iuPriorityLevel
iuThp
mlp
ols
spi
ArpBasedQos
ThpBasedQos

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 RRM
2.7 UE, QId and SPI
QI0
SP4
SP6
QI1
SP4
cmCH-PI 6
PDU flow1
cmCH-PI 4
CID n
cmCH-PI 6
QI0
1 1 49
PDU flow0
CID m
CID l
PDU flow0
RNC
NodeB
UEN
cmCH-PI 4
UE0
QI2
SP6

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 RRM
2.8 NodeB Scheduler

Flow Control
(UEX, SPIY)
QId0 QId1
available codes
available power
UE capabilities
ACK/NACK/CQI
Compressed Mode information
UE HSDPA synchronisation state
QIdK
QIdN
HARQ
Min COST value
COST = f(C1, C2)
C1 = f(Scheduler Type)
C2 = f(SPI, CQI, UE Category)
NodeB Scheduler
1 1 50

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.

2 HSDPA RRM

0
SF256
SF128
SF64
SF32
SF16
SF8
SF4
0
0
Pre-emption/Re-allocation is performed on
configuration line (SF16 always for HS-PDSCH)
2
1
Monitoring is performed on monitoring line

(SFx is operator choice between SF16 and SF256)
4
2
5
6
3
isHsPdschDynamicManagementAllowed
RNC
7
8
RadioAccessService
9
BTSEquipment
10
5
HsdpaCellClass
11
12
HsPdschDynamicManagement
6
13
14
7
15
127
1 1 51
spreadingFactorLevelForOvsfMonitoring

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

2.9.1 HS-PDSCH OVSF Codes Allocation

RNC
notes
updated
SF4
free
SF8
RadioAccessService
SF16
SF32
HS-PDSCH
HsdpaCellClass
SF64
SF128
cmCH
Cell Setup
HS-SCCH
SF256
numberOfHsScchCodes
minNumberOfHsPdschCodes
SF4
R99
free
maxNumberOfHsPdschCodes
SF8
SF16
SF32
HS-PDSCH
SF64
SF128
cmCH
SF256
1 1 52
Live Cell
HS-SCCH

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.

2.9.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
preemption preemption
HS-PDSCH
reallocation
time
1 1 53

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

2.9.3 DCTM RNC RAN Model

RNC
NodeB
RadioAccessService
FDDCell
isHsPdschDynamicManagementAllowed
hsdpaCellClassId
HsdpaCellClass
hsdpaResource
isCellHsPdschDynamicManagementActive
HsPdschDynamicManagement
numCodesForDchAfterReallocation
threshCodesToTriggerReallocation
spreadingFactorLevelForOvsfMonitoring
1 1 54
numCodesForDchAfterStealing
threshCodesToTriggerStealing
minTimeBeforeReallocationOfHsPdsch

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

2.9.4 DCTM NodeB RAN Model
slide
updated
BTS
Parameter for GBR on HSDPA in UA06.0

Parameter for Fair Sharing in UA06.0
BTSEquipment
BTSCell
HsdpaConf
HsdschServiceParameterSet
iCEM
xCEM
hsdpaGbrNbNeededTtiForgettingFactor
hsdpaGbrNbUePerTtiForgettingFactor
Used by
MAC-(e)hs scheduler
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi
1 1 55
serviceFilterFactor
serviceHighRate
serviceLowRate

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

2 HSDPA RRM
2.10 HSDPA DL Power Reservation at RNC

PMaxCell
RadioAccessService
RNC
SHO margin
HsdpaCellClass
PmaxHspa
PminHsdpa
minimumPowerForHsdpa
OCNS (opt.)
CCCRNC
PminHsdpa =
PMaxCell -
<unset>
when Fair Sharing is enabled
1 1 56
PmaxHspa =
PMaxCell - maxHspaPowerOffset

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 EHICH 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

2 HSDPA RRM

HSDPA
GBR,
R99
isPowerPoolingActivated
(FDDCell)
paRatio (F2)
paPoolingActivation
(BTSEquipment)
HSDPA
Fixed
partitioning
Power
not used
GBR,
R99
paRatio (F1)
paRatio (F2)
paRatio (F1)
PA Power Ratio
100%
R99
maxTxPower (Fx) Max Dl Power Capability (Fx)

maxPowerAmplification
Max
Power Amplification [dBm]
paRatio (Fx)/100)
+10*log( paRatio
R99
+Tx Losses [dB]
0%
UA05
: PA power sharing
Static
between F1 and F2 carriers.
UA06:
Dynamic PA power sharing
between F1 and F2 carriers.
paRatio parameter must be set

as follows:
paRatio (F1) + paRatio (F2) 100%
paRatio can be set as follows:

paRatio (F1) + paRatio (F2) > 100%
False
True
Power Sharing Activated ?

1 1 57

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.
2.11.1 Impact on DCH DL CAC and DL iRM

paRatio (F2)
HSDPA
GBR,
R99
Power
not used
Fixed
partitioning
R99
HSDPA
UA06
P traffic (F2)
= (Max Tx Power (F2) Min Pw Hsdpa (F2))

/ (1+ paOverbookingRatio
paOverbookingRatio /100)
paRatio (F1)
paRatio (F2)
paRatio (F1)
PA Power Ratio
100%
GBR,
R99
R99
- P CCC (F2) x Activity

activityFactorCcch
Factor Cch
P E-DCH - P OCNS
P_traffic
= Max (R99+HSDPA) traffic allowed
0%
P traffic(F2)
UA05
= Max TxPower(F2)
Min Pw Hsdpa(F2)
- P CCC(F2) x Activity Factor Cch
- P E-DCH-P OCNS
1 1 58

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.

2 HSDPA RRM
2.12 HSDPA DL Power Available at NodeB

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

1 1 59

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

2 HSDPA RRM
2.13 HSDPA Power - RAN Model

RNC
RadioAccessService
NodeB
DedicatedConf
HsdpaCellClass
maxHspaPowerOffset
paOverbookingRatio
FDDCell
isPowerPoolingActivated
activityFactorCcch
EdchCellClass
eagchErgchEhichTotalPower
BTSEquipment
Class2CellReconfParams
maxTxPowerPerOls
paPoolingActivation
Class3CellReconfParams
BTSCell
maxTxPowerPerOls
paRatio
HsdpaConf
dchPowerMargin
1 1 60
PaResource
maxPowerAmplification


2 HSDPA RRM
2.14 HSDPA Power Distribution
PMaxCell
HS-DSCH
PHsdpa
NodeB
HS-SCCH
DCH margin
E-DCH
DCH
OCNS (opt.)
CCCNodeB
1 1 61

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.

2 HSDPA RRM
2.15 HSDPA Full Power Usage
notes
updated
iCEM Activation* :
hsdpaFullPowerUsage
(HSDPAConf)
Raw HS-DSCH power

Mac-d queues selected
for the next TTI scheduling
QId0 QId1
Increase MCS by +1dB/CQI until:
QIdK
- no more power
- no more HS-PDSCH codes
- max MCS reached
+
remaining
Power ?
yes
priority of QIdz(UEX,SPIY)
for the next scheduling
Select QIdz
in priority order
no
Schedule Data
1 1 62
(*) the equivalent xCEM feature is supported by default


Once all flows have been selected for the TTI if some power remains unallocated, with the feature HSDSCH 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.

2 HSDPA RRM
2.16 HS-SCCH Power Control

PHS-SCCH = PP-CPICH +
BTSEquipment
hsscchPcOffset [CQI]
BTSCell
HsdpaConf
HS-S
C
CH
P-CP
ICH
+
distance
0 dB
17
Power
Offset
0 dB
CQI
HS-SCCH to P-CPICH
Power Offset
1 1 63
89
-3 dB
10 12
-5 dB
13 30
-8 dB

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.

2 HSDPA RRM
2.17 HS-PDSCH Dynamic Power Allocation for 1st Transmission
notes
updated
CQI selected by NodeB
CQI reported by UE
Power Adjustment
CQI rep. <> CQI sel. ?
YES
Adjust Power
ALU CQI = dB
RLC
Throughput
Available
Power
NO
OK
RadioAccessService
PHS-DSCH = PP-CPICH + + (CQI)

HsdpaUserService
measurementPowerOffset
3GPP(CQI, UEcategory) + ALU(CQIselected - CQIreported)

1 1 64

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 code 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

2 HSDPA RRM

Category 6 UE CQI Mapping Table
HS-PDSCH Number
RLC Throughput
Modulation
out of range
0 kbps
QPSK
0 kbps
QPSK
0 kbps
QPSK
0 kbps
QPSK
144 kbps
QPSK
144 kbps
QPSK
144 kbps
QPSK
288 kbps
QPSK
288 kbps
QPSK
10
432 kbps
QPSK
11
576 kbps
QPSK
12
720 kbps
QPSK
13
864 kbps
QPSK
14
1008 kbps
QPSK
15
1296 kbps
QPSK
16
1440 kbps
16-QAM
S oft CQ I vs C/I - P e de s tria n_a 1 RX

25
20
s oftCQI
CQI Value
15
...
...
...
...
29
3024 kbps
16-QAM
30
3024 kbps
16-QAM
1 1 65
10
-10
-8
-6
-4
-2
0
C/I (dB)
10
Target BLER 10%

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

2 HSDPA RRM
2.19 HSDPA Flexible Modulation

UA05.x iCEM
UA06 iCEM
iCEM Activation* :
False
Follow 3GPP
AMC tables
hsdpaFlexibleModulationVsCodeActivation
(HsdpaConf)
True
Static TFRC Table

CQI
value
Transport Block Size

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
137
173
233
317
377
461
650
792
931
1262
1483
1742
2279
2583
3319
Optimized
365
699
1036
1380
1711
2046
2404
3090
Num of 336
Num of HS
bit MAC-d
Modulation PDSCH
codes
PDU
1
1
1
1
1
1
1
2
2
3
4
5
6
7
9
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
1
1
1
1
1
1
2
2
2
3
3
3
4
4
5
Nb of codes {1,2,,15} x Modulation {QPSK , 16QAM}

Maximize nb of transmitted bits*
Codes limitation
TBS boost
16 QAM
QPSK
(*) the equivalent xCEM feature is supported by default

1 1 66

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)

2 HSDPA RRM
2.20 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

on first transmission
CQIreported
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
1 1 67

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

2 HSDPA RRM
2.21 HS-DPCCH detection based on CQI

RxDemodulation
(BTSEquipment)
NodeB
Initialisation
UE not scheduled
HSD_OUT_SYNC
N successive
CQI detected?
YES
NO
NO
M successive
DTX detected?
YES
HSD_IN_SYNC
UE scheduled
1 1 68
N=M=2
(hard coded)

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.
2 HSDPA RRM
bufferSize
nackNbMin
nackNbMax
hsdpaCqiBLERAdjustmentAlgo = blerRangeBasedAlgo
(HsdpaConf)
buffer is full
3
AC K
ACK
NA
AC CK
K
(static)
bufferSize
2.22 CQI adjustment based on BLER: blerRangeBasedAlgo
NbNACK <=
nackNbMin ?
1st Transmission
ACK/NACK
Buffer
Yes
CQIprocessed = CQIreported+1
No
NbNACK >
nackNbMax ?
Yes
CQIprocessed = CQIreported-1
No
empty the buffer
1 1 69

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 1st 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.

2 HSDPA RRM
2.23 CQI adjustment based on BLER: OuterLoopLikeAlgorithm

hsdpaCqiBLERAdjustmentAlgo = OuterLoopLikeAlgorithm
DeltaCqi
DeltaCqicur
#CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
DeltaCqiCur
NACK NACK ACK
#CQIreported
hsdpaBLERStepSiz
e
hsdpaBLERTargetUpperLimit
-5
1 1 70
hsdpaBLERStepSiz
e
x
100
- hsdpaBLERTargetUpperLimit

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

2 HSDPA RRM
2.24 CQI adjustment based on BLER: Dynamic BLER

Adjustment
hsdpaCqiBLERAdjustmentAlgo = dynamicOuterLoopAlgo
DeltaCqi
DeltaCqicur
#CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
DeltaCqiCur
NACK NACK ACK
hsdpaBLERStepSi
ze
-5
#CQIreported
upStepXXBLERTarget =
Low
1 1 71
Medium
hsdpaBLERStepSi
ze
High
100
hsdpaBLERTargetXXLi
mit
hsdpaBLERTargetXXLimit

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.

2.24.1 CQI adjustment based on BLER: Dynamic BLER

Adjustment
Start
Nack
DTX
Ack/Nack?
Ack
End
hsdpaAdjustBLERToChannelVariation
deltaCqiCur -= downStep
ueSpeed ueSpeedThd
And
adjustToChVar = True
Or
cqiAverage cqiThdHigh
Yes
deltaCqiCur += upStepLowBLERTarget
Yes
No
cqiThdLow < cqiAverage
deltaCqiCur += upStepMediumBLERTarget
1 1 72

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

No
deltaCqiCur += upStepHighBLERTarget
2.24.1 CQI adjustment based on BLER: Dynamic BLER

Adjustment [cont.]
hsdpaCqiBLERAdjustmentAlgorithmXcem
constBLERTarget
dynamicHarqTxTarget
outerLoopLikeAlgo algorithm
HARQ
hsdpaBLERTargetUpperLimitXcem
UE is Scheduled
Transmit Data
See Previous Slide
ACK
DTX
ACK/NACK/DTX?
Insert DTX
Indication
NACK
Reset & Free

HARQ Process
Nret = Nret + 1
YES
1 1 73
Nret > Nret_max
NO

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.

2 HSDPA RRM
2.25 HS-PDSCH Power Adaptation for Retransmissions
UE selected
(retransmission nb > 0)
UE is scheduled with
Transmitted Pwr =
1st Tx power + Power_offsetdB
(CQI1st CQIret)xStep Const
harqType
WithPowerAdaptation
(hsdpaConf)
1 1 74

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.

2 HSDPA RRM
2.26 HS-DPCCH Power
DPDCH
DPCCH
HS-DPCCH
OVSFd
OVSFc
x
OVSFhs
x
hs
I
RNC
Modulation
RadioAccessService
Q
HsdpaUserService
hs NACK
hs CQI
hs ACK
ackPowerOffset
cqiPowerOffset
NACK
CQI
DPCCH
1 1 75
ACK
nackPowerOffset

Radio conditions information and acknowledgements are reported by the UE to the Node B through the HSDPCCH 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 HARQ 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 BetaHS/BetaC.

2 HSDPA RRM
2.27 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
Proportional Fair
Alcatel-Lucent
COST = C1
= C1
= C1
= x C1 x C2
= *C1+*C2
UE #0
power
codes
number of bits
UE #1
power
codes
number of bits
1 1 76
Min COST value
UE #N
power
codes
number of bits

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. The RF cost function
noted C1 is based on the following principles :
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
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.
When the scheduler chooses a UE, it determines the amount of data to transfer and the number of codes
and the power to use (TFRC selection). This selection takes into account the CQI reported by the UE but
can be reduced according to the available power and codes. It also determines the HARQ parameters to be
used.
C1 can be interpreted as a Radio Cost
C2 can be interpreted as a Priority Cost

2.27 Scheduler iCEM
2.27.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
1 1 77

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.27 Scheduler iCEM

CLASSICAL PROPORTIONAL FAIR
to favor mobiles that report a high CQI versus their averaged CQI to
take benefit from instantaneous good radio conditions vs average
conditions
Goal
C1T = CQIavT / CQIinstT
Cost function C1
with CQIavT = x CQIavT-1 + (1 - ) x CQIinstT

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

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
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.27 Scheduler iCEM

C2 = f(N_bits_transmitted, SPI weight, average CQI)
TC
CQIAV
C2
SPI
ARP
CQIAV
QIdN
TC
THP
SPI
QIdM
WEIGHT
ARP
THP
TBSAV
TBSAV
WEIGHT
THROUGHPUTN
THROUGHPUTM
1 1 79

SPI management only applies to Alcatel-Lucent and Proportional Fair schedulers and is not supported by the
other schedulers.
SPI is determine 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, 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 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.
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.27 Scheduler iCEM
2.27.4 C2 Parameters
BTSCell
hsdpaSpiRelativeWeight
HsdpaConf
hsdpaUeCategoryThroughputWeighting
ueCategoryEquity
ueCategoryProportionality
Th(QId1)
Th(QId2 )
Th(QId1)
Th(QId2)
Weight[SPI(QId1)]
Weight[SPI(QId2)]
1 1 80
Weight[SPI(QId1)]
Weight[SPI(QId2)]
TBS[CQIav(QId1)]
TBS[CQIav(QId2)]
TBScat12[CQIav(QId1)]
TBScat12 [CQIav(QId2)]

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

Exercise
QId1 QId2 QId3
QId0
Retransmissions First
New Transmissions
hsdpaSchedulerAlgorithm
(HsdpaConf)
Min COST value

Round Robin
Fair
MaxCQI
Proportional Fair
Alcatel-Lucent
Assumptions
UE0
UE1
UE2
UE3
Cat.
12
12
10
10
TC
ARP THP OLS SPI QId
Background 1 NA
?
? 0
Interactive 1
1
?
? 1
Interactive 1
1
?
? 2
1
Interactive 1
?
? 3
Reported CQI
10
10
10
10
10
10
10
10
10
10
10
10
13
15
10
10
13
15
13
15
15
15
15
15
15
25
25
25
25
25
25
24
22
20
25
24
22
20
22
20
T0
1 1 81


Exercise

Define the SPI value for each Qid

Assuming hsdpaSchedulerAlgorithm = Round Robin, find which UE is scheduled
at each TTI:
Cost
UE0
UE1
UE2
UE3
SPI QId 1st

TTI
? 0
? 1
? 2
? 3
2nd
TTI
3rd
TTI
4th
TTI
5th
TTI
6th
TTI
7th
TTI
8th
TTI
9th
TTI
Assuming hsdpaSchedulerAlgorithm = CQI, find which UE is scheduled at each

TTI:
Cost
UE0
UE1
UE2
UE3
SPI QId 1st

TTI
? 0
? 1
? 2
? 3
1 1 82
2nd
TTI
3rd
TTI
4th
TTI
5th
TTI


6th
TTI
7th
TTI
8th
TTI
9th
TTI
Exercise
Assuming hsdpaSchedulerAlgorithm = Alcatel-Lucent, calculate throughput

relative ration for each QId
SPI
10
11
12
13
14
15
16
hsdpaSpiRelativeWeight 50 50 50 50 50 50 50 50 100 100 100 100 100 100 100 100

hsdpaUeCategoryThroughputWeighting = ueCategoryEquity
Throughput relative ratio (C2 based)
1st
TTI
2nd
TTI
3rd
TTI
4th
TTI
5th
TTI
6th
TTI
7th
TTI
8th
TTI
9th
TTI
QId0/
QId1
QId0/
QId2
QId0/
QId3
QId1/
QId2
QId1/
QId3
QId2/
QId3
1 1 83

CQI management up to CQI 15 (all UE categories)

CQI
value
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
137
173
233
317
377
461
650
792
931
1262
1483
1742
2279
2583
3319
Optimized
365
699
1036
1380
1711
2046
2404
3090
Num of 336
bit MAC-d
PDU
Modulation
Num of HSPDSCH codes
1
1
1
1
1
1
1
2
2
3
4
5
6
7
9
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
1
1
1
1
1
1
2
2
2
3
3
3
4
4
5

Exercise
hsdpaUeCategoryThroughputWeighting = ueCategoryProportionality
Throughput relative ratio (C2 based)
1st
TTI
2nd
TTI
3rd
TTI
4th
TTI
5th
TTI
6th
TTI
7th
TTI
8th
TTI
9th
TTI
QId0/
QId1
QId0/
QId2
QId0/
QId3
QId1/
QId2
QId1/
QId3
QId2/
QId3
1 1 84

CQI management from CQI 16 to CQI 30 (UE category 10)

CQI
value
Num of 336
bit MAC -d
PDU
Modulation
Num of HS PDSCH codes
Default
Optimized
16
3565
3440
10
16-QAM
17
4189
4115
12
16-QAM
18
4664
4420
13
16-QAM
19
5287
5101
15
16-QAM
20
5887
5782
17
16-QAM
21
6554
6438
19
16-QAM
22
7168
7168
21
16-QAM
23
9719
9546
28
16-QAM
24
11418
11216
33
16-QAM
25
14411
14155
42
16-QAM
10
26
17237
51
16-QAM
12
27
21754
64
16-QAM
15
64
16-QAM
15
64
16-QAM
15
64
16-QAM
15
28
29
30
21754 (-1dB) 23370

21754 (-2dB) 23792
23792 (-1dB)

2.28 Scheduler xCEM
UE Capabilities
Available Power & Codes
ACK/NACK/SNRMap,dB
Previously Transmitted PDUs
Retransmissions First per Priority Que

QId0
QId1
QIdN
New Transmissions
hsdpaSchedulerAlgorithmXcem
(HsdpaConf)
proportionalThroughput
CRmax
CostCRmax = SW(u,q) . J(uq,) / CR(u,q)
UE #0
power
codes
number of bits
Min COST value
CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q)
UE #1
power
codes
number of bits
1 1 85
UE #N
power
codes
number of bits

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 = CostCRmax for GBR MAC-d flows when R < serviceMinRate
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 MACd 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 codes.
2.28 Scheduler xCEM
2.28.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)

1 1 86

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 + PavailableHS-PDSCH Pcpich + (ack,nack)
SNRMAP,dB is the last SNR value mapped on CQI assuming a HSDSCH power of Pcpich + ( being
the measurementPowerOffset/2 ).
PavailableHS-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 a SE and used for TFRC selection.

2.28 Scheduler xCEM
2.28.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
TBS / n HS-PDSCH SE with maximal TBS and minimal n HS-PDSCH
1 1 87

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
For UCU III: in case of an HARQ retransmission, the scheduler will not use the instantaneous SE but the
cumulated SE over all the transmissions of this HARQprocess, allowing to account for IR or CC gains (SEcum
= SEcurrent + SEcum).
For xCem: the spectral efficiency SE is SE = min(SEcurrent; SEcum).
The power allocated for the HS-DSCH of the user i is :PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH
This power is also weighted by the term factor because if B/W is smaller than SE, it means that less power
is needed to achieve the same error rate:
PHS-DSCH(i) = PavailableHS-PDSCH x nHS_PDSCH x factor
()
(/)
SNR SE
factor = SNR B W
Where: B is the Transport Block Size selected by the scheduler and W is the number of HS-PDSCH codes
selected by the scheduler
Only for UCU III: After all users have been selected for this TTI, some portion of the HSDPA power may still
be unused. This unused power is called excess power and may be redistributing equally over all HS-PDSCH
that been allocated to the scheduled users in the TTI.
Then, available resources are updated
the
next round
of scheduling.
Allfor
Rights
Reserved
Alcatel-Lucent
2010
2.28 Scheduler xCEM
2.28.3 TFRC SELECTION Summary
1 1 88

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

2.28 Scheduler xCEM
2.28.4 SPI management for GBR Mac-d flows

hsdpaSchedulerAlgorithmXcem = proportionalThroughput
QId0
QId1
QIdN
QIdx
QIdy
QIdw
Ranking prio.
Non GBR Mac-d flows
GBR Mac-d flows
hsdpaSpiRelativeWeight
serviceBFactor
Throughput R
<>
serviceMinRate
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi
(HsdpaConf)
serviceLowRate
(HsdschServiceParameterSet)
serviceMinRate = MAC-(e)hs GBR - serviceLowRate

serviceLowRate
1 1 89

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)*10) * 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.28 Scheduler xCEM
2.28.5 SPI management for non GBR Mac-d flows

hsdpaSchedulerAlgorithmXcem = proportionalThroughput
TC
SNR
SPI
ARP
SNR
QIdN
TC
THP
SPI
QIdM
WEIGHT
ARP
THP
SE
SE
WEIGHT
THROUGHPUTN
THROUGHPUTM
1 1 90

The two xCEM schedulers manage the priorities differently:

With proportionalThroughput: a relative weight is applied on each SPI via hsdpaSpiRelativeWeight

(same parameter as with iCEM) so that the throughputs of the different non GBR MAC-d flows, when
they are experiencing the same radio conditions, are proportional to their respective SPI weights. For
GBR flows measured throughput R is compared with the following threshold per SPI and then
appropriate user ranking is applied.
serviceMinRate = MAC-(e)hs GBR serviceLowRate
With CRmax: for a given SPI, priority of the queue is increased (or decreases) by multiplying the cost
function by a Scheduling Weight (SW) if the MAC-d throughput R is lower (or higher) than the
parameter serviceMinRate (or serviceMaxRate). The parametersserviceBFactor and serviceKFactor
are shaping factors forincreasing 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 serviceMinRateor 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.

2.28 Scheduler xCEM
2.28.6 SPI management

hsdpaSchedulerAlgorithmXcem = CRmax
serviceMinRate
serviceMaxRate
QId0
QId1
QIdN
serviceMinRate
serviceLowRate
serviceHighRate
non GBR Mac-d flow
serviceBFactor
serviceKFactor
serviceMaxRate
(HsdschServiceParameterSet)
COST x SW
Decrease OR Increase
COST
MAC-(e)hs GBR -serviceLowRate

serviceLowRate
Throughput R
<
serviceMinRate
OR
GBR Mac-d flow
Throughput R
>
serviceMaxRate
MAC-(e)hs GBR +serviceHighRate
serviceLowRate
1 1 91

With CRmax: for a given SPI, priority of the queue is increased (or decreases) by multiplying the cost
function by a Scheduling Weight
(SW) if the MAC-d throughput R is lower (or higher) than the parameter serviceMinRate (or
serviceMaxRate). The parameters serviceBFactor and serviceKFactor are shaping factors for increasing
and decreasing the priorities:
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
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 HSDPA RRM
2.29 Scheduler: SPI management
No
HS-SCCH transmit power

<
Available power
UE is removed from scheduling list
Yes
HS-S
CC
P-CP H
ICH
0 dB
distance
HS-SCCH to P-CPICH
Power Offset
iCEM
xCEM
ReTx are always transmitted before 1st Tx
1 1 92
ReTx are transmitted before

1st Tx only for Different HARQ processes
of a given priority queue

Before selecting the UEs to be scheduled in the TTI, the scheduler computes the transmit power of the HSSCCH for each user in the ranking list. It will remove from
the list all the UEs which cannot be scheduled because their HS-SCCH transmit power is higher than the
available power.
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 RRM
2.30 Dynamic MAC-d PDU size

RNC
NodeB
RadioAccessService
isDynamicMacdPduSizeManagementAllowed
FDDCell
isHsdpaCellHighPerformance
Mac-hs PDU = 1TTI
HsdpaRncConf
Mac-hs SDU
RLC SDU
eligibleUeCategoryForHighPerformance
Mac-d SDU = Mac-d PDU
minimumUserMbrForHighPerformance
21
320
16
320
16
320
16
Padding
isHighPerformancePduSizeReconfAllowed
Mac-hs PDU = 1TTI

Mac-hs SDU
RLC SDU
21
640

16
640
16
1 1 93
640
16
Padding

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.

2.30.1 MAC-d PDU size
MAC-d PDU
= 336 bits
notes
updated
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
Max HSDPA user throughput @ RLC

= (Mac-d PDU size)
MAC-d PDU
= 336 bits
or
= 656 bits
1 1 94


= (UE cat.)
2.30.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

(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
Network
1 1 95
minimumUserMbrForHighPerformance
(HsdpaRncConf)

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.

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

Bit n = 1 means UE Cat. n is eligible to 656 bits; 0 means not eligible
Value
0000000000000000000000000000000000000000000000000000001111000000
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
1 1 96

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
Value
0 (default value) customer dependent

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

2.30.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 HSDSCH MAC-d flow is setup that is to
say at RAB establishment or
reconfiguration of the RB to HS-DSCH.
1 1 97
= True : MAC-d PDU size can be different
= False : same MAC-d PDU size

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

2.30.5 MAC-PDU size : Mobility HSDPA-HSDPA

MAC-d PDU size can be reconfigured or not
depending on isHighPerformancePduSizeReconfAllowed
= False
Cat. 656
Cell 656
Mac-d PDU size is not reconfigured (656)
Cell 656
Cell 656
Cell 336
Cell 336
Cell 656
Cell 336
Cell 336
1 1 98

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 enabled (isHighPerformancePduSizeReconfAllowed = True).

2.30.5 MAC-PDU size : Mobility HSDPA-HSDPA [cont.]

MAC-d PDU size can be reconfigured or not
depending on isHighPerformancePduSizeReconfAllowed
= True
Cat. 656
Cell 656
Cell 656
Cell 656
Mac-d PDU size is reconfigured (636)
Cell 336
Cell 336
Mac-d PDU size is reconfigured (656)
Cell 656
Cell 336
Cell 336
1 1 99

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

2.30.5 MAC-PDU size : Mobility HSDPA-HSDPA [cont.]

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
1 1 100


new
2.30.6 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
Cell 336
Cell 336
Cell 656
1 1 101

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

2.30.7 MAC-PDU size : Mobility Over Iur

HSDPA over Iur feature has to be activated
SRNC
= False
DRNC
Iur
Iub
Iub
NodeB
SRNS
Cat. 656
Cell 656
Cell 656
NodeB
DRNS
Cell 656
Mobility of a 656 bits MAC-d flow is refused
656 not supported

on DRNS
leading to a DCH fallback of the RB by the SRNC

( HSxPA to DCH fallback feature has to be activated)
1 1 102

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

2.30.7 MAC-PDU size : Mobility Over Iur [cont.]

HSDPA over Iur feature has to be activated
SRNC
= True
DRNC
Iur
Iub
Iub
NodeB
SRNS
Cat. 656
NodeB
DRNS
Cell 656
Cell 656
Cell 656
656 not supported

on DRNS
1 1 103

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.

2.30.8 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
mapped on
HS-DSCH 656
AO downsize :
656 336 reconfiguration
PS in Cell_Fach
on FACH 336
PS in Cell_Fach
on FACH 336
AO upsize :
336 656 reconfiguration
PS in Cell_DCH
mapped on
HS-DSCH 656
1 1 104

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.

2 HSDPA RRM
2.31 Transport Block Size Optimization: CQI 1 to 15, all UE

cat.
BTSEquipment
Mac-hs PDU = 1TTI

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

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.

2 HSDPA RRM
UE
Node B
RNC
1
UL radio problem
UL RLC PDU
2 (App. Data)
n
Re-Tx
Application
Server
TCP data
DL RLC PDU
(App. Data)
App.
TCP
ACKs
CN
STATUS = NACK
UL TCP ACKs stored
Burst of TCP
ACKs
CN discards application packets

1 1 106

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.

2.32.1 UA05.1 Solution

Increase Minimum SIR Target for the UL RB if :

Current call is an HSDPA call (i.e. a PS HS-DSCH DL RB is established)
High Quality UL R99 RAB is activated for this RNC
isExtendedSrbDcch3dot4k
High Quality UL R99 RAB is activated for this cell

sibMaxAllowedULTxPowerOnRachConnectedMode
(PowerConfClass)
High Quality UL R99 RAB is activated for this HSDPA UE category

(HsdpaRncConf)
High Quality UL R99 RAB is activated for the UL service (i.e. UlUserService)
ulDownSirStep
(UlOuterLoopPowerCtrlf)
New Minimum SIR Target = baseline [dB] + offset [dB]

sibMaxAllowedULTxPowerOnRachConnectedMode / 10 + 5
1 1 107
ulDownSirStep

isExtendedSrbDcch3dot4k: Enables or disables the feature HIGH QUALITY UL R99 RAB FOR HIGH HSDPA DL
DATA at RNC level. Value is True or False.
sibMaxAllowedULTxPowerOnRachConnectedMode: Enables or disables the feature at cell / cluster of
cells level.
For the PowerConfClass assigned to a given cell / cluster of cells:
sibMaxAllowedULTxPowerOnRachConnectedMode 20 enables the feature
sibMaxAllowedULTxPowerOnRachConnectedMode > 20 disables the feature
The parameter eligibleUeCategoryForHighPerformance defines the eligible HSDPA UE Categories for HIGH
QUALITY UL R99 RAB FOR HIGH HSDPA DL DATA feature.
Having defined bit #0 as the LSB (least significant bit) i.e. the bit at the right edge of the bit string, bit #32
corresponds to Category 1 and bit #43 corresponds to Category 12.
Meaning of each bit (from bit #32 to bit #43) is as follows:
0: corresponding HSDPA UE Category is not eligible for the feature
1: corresponding HSDPA UE Category is eligible for feature
It is recommended to set HSDPA UE Categories 7 to 10 eligible for the feature. Hence, bits #38 to #41 must
be set to 1.
ulDownSirStep: Enables or disables the feature per UlUserService
ulDownSirStep 0.1 enables the feature
ulDownSirStep = 0.1 disables the feature
It is recommended to enable the feature for the following UL services: PS_128K_IB_MUXxSRB_3_4K,

PS_128K_IBxSRB_3_4K, PS_384K_IBxSRB_3_4K.

2.32.2 UA06 Solution

eligibleUeCategoryForSirTargetHsdpa
(PowerConfClass)
RNC
initialSirTargetHsdpa (UlUsPowerConf)
(NBAP)
UlUserService
CS_AMR_NBxSRB_3_4K
CS_64KxSRB_3_4K
PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
PS_384K_IBxSRB_3_4K
StandaloneSRBDCCH3_4K
...
UL SIR Target
maxSirTargetHsdpa (UlUsPowerConf)
minSirTargetHsdpa (UlUsPowerConf)
TTI
1 1 108

In 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 in 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 subfeature. Eligible HSDPA UE
Categories can be set via eligibleUeCategoryForSirTargetHsdpa parameter.
2 HSDPA RRM
2.33 Always On for HSDPA/DCH: Mono-Service PS / Mono-RAB

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

Analog to R99 cases but with specific timer parameters

PMM-idle
2 HSDPA RRM
2.34 Always On for HSDPA/DCH: Multi-Service PS / Multi-RAB

PS
Mono-Service PS / Multi-RAB PS I/B HSDPA
HSDPA/DCH
PS I/B MUX
CELL_DCH
pchRrcStates = none
timerT2ForHsdpa
AO Step3
Multi-Service CS+PS / Mono-RAB PS I/B HSDPA
CS + PS I/B
HSDPA/DCH
CELL_DCH
PMM-idle
pchRrcStates = any
CS + PS I/B 0/0 xxxPchToIdleTimer MM-connected
+
(CELL_DCH)
AO Step3
PMM-idle
timerT2ForHsdpa
AO Step2
Multi-Service CS+PS / Multi-RAB PS I/B HSDPA
CS + PS I/B MUX
HSDPA/DCH
CELL_DCH
1 1 110
pchRrcStates = none
timerT2ForHsdpa
AO Step3

Analog to R99 cases but with specific timer parameters

MM-connected
+
PMM-idle
3 HSDPA Mobility
1 1 111


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

activationHoGsmPsAllowed
isPatternAllowed
isInterFreqMeasActivationAllowed
isGsmCmodeActivationAllowed
(CmodePatternSeqInfo)
1 1 112

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

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

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

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

1 1 114

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

3 HSDPA Mobility
3.4 HSDPA over Iur

Core Network
isHsdpaOverIurAsSrncAllowed
isMacShHsdpaAllowed
Radio Link
Reconfiguration
HS-DSCH
HS-DSCH
SRNC
DRNC
4
Associated DCH
isHsdpaOverIurAsDrncAllowed
isHsdpaAllowed
(NeighboringRNC)
HS
SC
PD
CH
DP
2
1 1 115
ed
at
ci
so
As
HS
-P
As
DS
so
CH
ci
at
ed
DP
CH
isHsdpaAllowed
(RemoteFDDCell)
Primary Cell change

(Event 1d)

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,
3.4 HSDPA over Iur
3.4.1 64-QAM over Iur: Not Supported

new
Core Network
3
Radio Link
Reconfiguration
HS-DSCH
HS-DSCH
SRNC
DRNC
4
Associated DCH
64
HS
SC
PD
CH
DP
1 1 116
AM
ed
at
ci
so
As
QA
M
HS
-P
As
DS
so
CH
ci
at
ed
16
DP
CH
Q
16 QAM
Primary Cell change

(Event 1d)

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.

3.4 HSDPA over Iur
3.4.2 Iub Bandwidth Management

Prior UA05.1, In case of Iub congestion the SRNC is not aware !
DRNC
HS-DSCH
Iur Capacity Allocation
= true
Xoff message (link to Iub)
Capacity Allocation
isMacShHsdpaAllowed
Iur Bearer
Iub Bearer
SRNC
Xoff period
Usable credit
1 1 117
Usable credit

CASE OF DRIFT IUR IN UA05.0

When Iub congestion takes place on Serving Iub, the traffic is regulated.
When Iub congestion takes place on Drift Iub, the SRNC is not informed of the congestion.
CASE OF DRIFT IUR IN UA05.1
A new entity has been introduced in UA05.1: MAC-sh. This user-plane entity is created by the Control plane
for each MAC-d flow of a HSDPA call that is supported over the Iur. The MAC-sh entity is only created by the
Drift RNC
UA05.0-UA05.1 Delta: Interaction with Iub Bandwidth limitation:
In UA05.0, HSDPA over Iur is not fully supported as Iub bandwidth limitation feature does not take into
account DL traffic (NDS and HSDPA) coming through Iur. Therefore, in case of Iub congestion on the Drift
leg, no back pressure mechanism is implemented on Drift RNC.
In UA05.1, such restriction is removed by the introduction of feature HSDPA over Iur b/w management with
which HSDPA traffic coming from Iub and Iur are handled the same way in DRNC.
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.

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
1 1 118


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
1 1 119


End of Module
Module 1
1 1 120


21
Section 2
HSUPA Algorithms Description
Module 1
9300 W-CDMA

3JK11637AAAAWBZZA Issue 1
Blank Page
212
HSUPA Algorithms Description Module 2

Document History
Edition
Date
Author
Remarks
01
2010-04-30
Elsner, Bernhard
Charneau, Jean-Nol
First edition

Module Objectives
Describe HSUPA activation principles and associated parameters
Describe HSUPA radio resource management parameters
Describe HSUPA mobility features and associated parameters
213


214

Table of Contents
Page

1 HSUPA Activation
1.1 HSUPA Activation Flags
1.2 E-DCH Capable UE Supported
1.3 E-BBU Resource Allocation iCEM case
1.4 Multi-Mode BBU Activation xCEM case
1.5 E-DCH/HSDPA Service Indicator broadcast
1.6 Scheduling
1.8 Multiple E-AGCH and E-RGCH
1.9 Physical Channels Role
1.11 E-DCH 2 ms TTI activation
1.12 HARQ
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ
1.13 MAC-e non-scheduled Mode
2 HSUPA RRM
2.1 Grant Allocation
2.2 E-TFCI Table Configuration
2.3 E-DCH Scheduler iCEM: Principle
2.4 E-DCH Scheduler xCEM: Principle
2.5 Priority Info Support (iCEM and xCEM)
2.5.1 iCEM MAC-e Scheduler
2.5.2 xCEM MAC-e Scheduler
2.6 UL Radio Load Monitoring: needed for E-DCH scheduling
Mechanism
All Rights
Reserved Alcatel-Lucent 2010
2 1 52.7 UL Radio Load Monitoring: Defense
HSUPA Algorithms
Description
Module
2
2.8
UL
Radio
Load
:
Self-interference
issue
with E-DCH
2.9 Self-interference issue on UL Noise Rise
2.9.1 First solution
2.9.2 Second Solution
2.10 DL Power Management: RNC level
2.11 DL Power Management: NodeB level
2.11.1 E-DCH signaling channels Power Control Parameters
2.12 UL Power Management
2.12.1 Closed Loop Power Control
2.12.2 Scheduling and Power Offset
2.12.3 UL Outer Loop Power Control on UL DPDCH (UA05.0)
2.12.4 UL OL Power Control on HARQ retransmission (UA05.1)
2.12.6 E-DCH Adaptive HARQ Control (UA06)
2.12.7 Specific case of SRB on E-DCH
2.12.8 Fast Decrease of E-DCH Partial SIR Target if Good Radio
2.12.9 E-DCH Partial SIR Target in case of Soft HO
2.13 Radio Link Control - DL/UL Imbalance Detection
2.14 User Services supported with HSUPA
2.15 HSUPA CAC
2.16 RAB Allocation Phase
2.17 HSUPA to DCH Fallback
2.18 Always On: degraded2AOnOnly - URA/Cell_PCH used
2.18.1 degraded2AOnOnly - URA/Cell_PCH not used
2.18.2 Always On: releaseOnly - URA/Cell_PCH not used
3 HSUPA Mobility
3.1 E-DCH Radio Links Set, E-DCH Active Set: Definitions
3.2 E-DCH serving NodeB, E-DCH non-serving NodeB
3.3 E-DCH Active Set Management: Event 1J
3.4 E-DCH Active Set Management: Primary Cell Change
3.5 Soft HO Data Transmission Example

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
26
27
29
30
31
33
34
35
36
37
38
39
40
41
42
43
44
45
46
48
49
50
51
53
54
55
56
57
58
59
60
61
62
63
64
65
66

Page

3.6 Manage UL Noise Rise due to E-DCH Non-Serving RL : iCEM case
3.6.1 xCEM case
3.7 E-DCH Macro Diversity RAN Model
3.8 Intra-Freq Mobility : Primary Cell Change
3.8.1 Call Flow
3.9 Intra-Freq Mobility over Iur
3.10 Inter-Freq Intra-RNC Mobility
3.11 Inter-Freq Inter-RNC Mobility: Without Iur OR
3.11.1 Inter-Freq Inter-RNC Mobility: With Iur AND
3.12 Inter-RAT Mobility
216


67
68
69
70
71
74
75
76
77
78
1 HSUPA Activation
217


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

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

isEdchAllowed
1 HSUPA Activation
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

Support for 10
and 2ms TTI eDCH
Maximum number
of bits of an eDCH transport
block transmitted
within a 10 ms eDCH TTI
Air Interface
data rate
Maximum
number of bits
of an e-DCH
transport block
transmitted
within a 2 ms eDCH TTI
SF4
10ms TTI only
7296
700kbps
SF4
10ms and 2ms TTI
14592
1.4Mbps
2919
Category 3
SF4
10ms TTI only
14592
1.4Mbps
Category 4
SF2
10ms and 2ms TTI
20000
2Mbps
5837
Category 5
SF2
10ms TTI only
20000
2Mbps
Category 6
2
2
SF2
SF4
10ms and 2ms TTI
20000
2Mbps
11520
E-DCH
Category
Maximum
number of
e-DCH
codes
transmitte
d
Minimum
spreading
factor
Category 1
Category 2
EM
xC
219
Air
Interface
data rate
1.4Mbps
2.9Mbps
5.7Mbps
ly
On

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 Activation
1.3 E-BBU Resource Allocation iCEM case

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

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 Activation
1.4 Multi-Mode BBU Activation xCEM case

xCEM
BBU
BBU
slide + notes
updated
BBU
BBU
DCH
DCH
DCH
DCH
iCEM
BBU
BBU
BBU
BBU
HSUPA
HSUPA
HSDPA
HSDPA
DPCCH, DPDCH (DCH

+ SRB + CCH)
all HSDPA channels
all HSUPA channels
xCEM
BBU
BBU
Multimode
Multimode
BBU
BBU
Multimode
Multimode
BBU
BBU
Multimode
Multimode
BBU
BBU
Multimode
Multimode
2 1 11
-Up to 256 DCH calls with any 128 of

them supporting HSDPA and/or
HSUPA.
-Up to 6 cells belonging to 2 LCGs
Up to 64 calls (DCH or
HSDPA or mix of
both).

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 Activation
1.5 E-DCH/HSDPA Service Indicator broadcast

isHsxpaServiceIndicatorEnabled
RNC
SIB5
SIB5
NodeB
NodeB
non E-DCH
cell
E-DCH cell
HSxPA UE
Auto
hsdpaServiceIndicatorMethod
edchServiceIndicatorMethod
Auto
HSxPA UE
(FDDCell)
E-DCH
OK!
2 1 12
E-DCH
NOK!

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 Activation
1.6 Scheduling
Scheduler
Channel Assignment
EE--DPCCH
DPCCH
00
E-DPDCH
2 1 13
E-AGCH
E-DPCCH
E-DPDCH
Absolute Grant
Ack / Nack
Relative Grants
E-HICH
E-RGCH
Scheduling info
Format definition
Traffic data

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:
15 levels of priority,
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 Activation
slide + notes
updated
DTCH
Traffic
TRB
E-DCH
UL
E-DPDCH
E-DCH Dedicated Physical Data Channel

Carries the actual Traffic
UL
E-DPCCH
E-DCH Dedicated Physical Control Channel

Describes the E-DPDCH
UL
E-HICH
E-DCH HARQ Indicator Channel

Ack/Nack from BTS
DL
E-AGCH
E-DCH Absolute Grant Channel

Resource allocation (absolute value)
DL
E-RGCH
E-DCH Relative Grant Channel

Resource allocation (more or less)
DL
E-DPDCH
E-HICH
E-DPCCH
RadioAccessService
maxNrOfEagch
maxNrOfErgchEhich
E-AGCH
E-RGCH
DedicatedConf
EdchCellClass
2 1 14

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
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).
The number of E-DPDCH per UE depends of its E-DCH category.
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 Activation
1.8 Multiple E-AGCH and E-RGCH

Non Serving
Node B
Serving
Node B
maxNrOfEagch
maxNrOfErgchEhich
notes
updated
Serving
RL
(edchCellClass)
Non
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
Rel6 UE
The selected code shall have at least 2 free

signatures that can be used for E-HICH and E-RGCH
For each affected RL one available signature for

E-HICH should be allocated
One available signature for dedicated RG shall be

allocated to serving users (per radio link)
Non serving users shall get uniformly assigned to
signatures reserved for common RG
2 1 15
E-DPCCH & E-DPDCH

E-RGCH & E-HICH
E-RGCH (Common RG)
E-AGCH
Associated DCH

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/EHICH 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 Activation
1.9 Physical Channels Role
notes
updated
Node B
Ack/Nack
Node B allocates resources

( Absolute or relative )
Dedicated
E-AGCH
E-RGCH
E-DPCCH
Dedicated
E-DPDCH
E-HICH
Mobile
describes format
and sends data
2 1 16

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 Activation
notes
updated
BTSCell
HSUPA Uplink transport channel: E-DCH
EdchConf
isEdchTti2msAllowed
DTCH
Uplink
TTI: 2ms or 10ms
TBS free attribute of Transport format
ETFCI
HARQ: Incremental Redundancy
Turbo coding 1/3
CRC 24bits
Traffic
TRB
Mobile i
E-DCH
UL
E-DPDCH
E-HICH
E-AGCH
E-DPCCH
E-RGCH
2 1 17

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 Activation
1.11 E-DCH 2 ms TTI activation

UE
1
xCEM
UE
2
10
m
notes
updated
EA
UE
3
s
GC
H
UE
4U
E5
- 2ms TTI
- 8 HARQ process
- Special ETFC table
Cat. 2, 4 & 6
- Node B reports 1 FP each 2 ms
isEdchTti2msAllowed = True
(EdchCellClass)
Same Scheduling period
Cat. 1, 3 & 5
- In case of mobility, the RNC

reconfigure the TTI depending on
Primary cell capability
- 10ms TTI
When 2ms TTI is not activated all UEs are configured with 10ms TTI
2 1 18

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.

1 HSUPA Activation
1.12 HARQ
HARQ

UE has resources for
transmission
E-HICH
ACK/NACK
Transmit Data
ACK
ACK/NACK/DTX?
DTX
Insert DTX
Indication
RadioAccessService
NACK
Reset & Free
HARQ Process
Nret = Nret + 1
YES
Nret > Nret_max
UlRSetConf
NO
EdchParameters
edchHarqMaxRetrans
2 1 19

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

1.12 HARQ
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ

Ack
Ack
packet1
packet1
packet2
Packet1
Ack
packet1
Ack
packet1
Ack
packet1
packet1
packet1
packet9
packet2
Packet1
packet8
packet7
packet6
packet5
packet4
Ack
Ack
Ack
NAck
Ack
Ack
Ack
Ack
Ack
Ack
Ack
packet3
packet2
Packet1
E-DPDCH UE1
(Uplink Data)
NAck
NAck
E-HICH UE1
(Downlink Control)
2 ms
HARQ cycle=8x2ms=16ms
E-DPDCH UE2
(Uplink Data)
Packet1
packet2
packet3
packet4
10 ms
HARQ cycle=4x10ms=40ms
process #1
process #2
2 1 20
process #3
process #4
process #5

Higher reactivity and lower RTT with 2ms TTI.

process #6
process #7
process #8
Pa
1 HSUPA Activation
1.13 MAC-e non-scheduled Mode

isSrbOnEdchAllowedWhenTrbOnEdch = True
srbQos.srbSpi
Reserved0 bit0, bit1,bit2 = 0
RRC (Max MAC-e PDU size for non-scheduled data )
NB
AP
(M
ax
MA
C-e
PD
Us
i ze
for
no
n
-sc
he
d
ule
d
da
ta
ttiType = 2
E-DCH (S
RB)
xCEM
)
( SG
B)
CH
SR
+
AG
ERB
(T
F4
H
2S
DC F2+
2S
E-
DC
)
SRB
H(
)
RB
(T
)
H
C
(S G
E-D GCH
E-A
Other Cat.
Cat. 6
Cat. 6
2 1 21

MAC-e Non-scheduled mode is supported by xCEM only.

This feature is used to carry SRB on E-DCH
Allow to maximize the E-DCH performances when using 2SF2+2SF4
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 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
Reserved0 bit 0, bit 1, bit 2: Three activation flags are added to the model, in the radio access service:
Reserved0 bit 0: reserved0 Bit 0: SRB on E-DCH for all E-DCH categories
Bit 0 = 0: E-DCH cat 6 UE only

Bit 0 = 1: All E-DCH categories
Reserved0 bit 1: reserved0 Bit 1: SRB on E-DCH for all NodeB minSF
Bit 1 = 0: 2 SF2 + 2 SF4 minSF only.

Bit 1 = 1: All NodeB minSF
Reserved0 bit 2 : reserved0 Bit 2: SRB on E-DCH for all E-DCH TTI

Bit 2 = 0: 2 ms TTI only and 2 ms supported on NodeB

Bit 2 = 1: 2 ms and 10 ms allowed
2 HSUPA RRM
2 1 22


2 HSUPA RRM
2.1 Grant Allocation

Allocated Power / interference
contribution decides which
transport format can be used,
so which throughput is
available
Total interference contribution
BTS
Absolute
& relative
grants
UEn Interference
contribution
UE3 IC
UEn
UE2 IC
UE1
UE3
UE2
Serving_Grant
Acronyms
TFC: Transport Format Combination (E-TFC => E-DCH)
TFCI: Transport Format Combination Indicator (E-TFCI => E-DCH)
2 1 23
Required power to use the ETFC
UE1 IC
UE knows which Transport

format it can use
RNC sends
corresponden
ce info at call
setup
ETFC
ETFC
ETFC
ETFC
ETFC
ETFC
ETFC
ETFC
ETFC
ETFC
Node B
Grants a
certain
power
UE might use
all or part of
the allocated
power

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 RRM
2.2 E-TFCI Table Configuration

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 NodeB category
1*SF4
10
1
1*SF4
2*SF4
10
2*SF4
2*SF2
10
2*SF2
All other cases

2 1 24
16
Comments
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
In this case virtual UE

category=UE category


2 HSUPA RRM
2.2 E-TFCI Table Configuration [cont.]

Example: UE CAT6 on E-DCH Cell with iCEM
Step1: primary Cell HSUPA Category is
computed based on min SF capability and
E-DCH TTI
Cell HSUPA Category = 5

Step2: Virtual UE category is computed as
the minimum between Primary cell HSUPA
category and HSUPA UE category
Virtual UE Category = min{ 5;6 } = 5

Step3: EdpchParameters instance is
selected based on Virtual UE CAT and EDCH TTI
UECategory5EdchTti10ms
2 1 25


2 HSUPA RRM
2.3 E-DCH Scheduler iCEM: Principle

Number of UE asking for Grants
UE max bit rate capability
UL radio load
available for E-DCH
E-BBU capacity
Scheduling Information from UE:

UE power headroom
UE User Buffer
Happy Bit
iCEM
E-DCH Scheduler
Grants allocated
Per UE
periodicityOfSchedInfoGrant
periodicityOfSchedInfoNoGrant
happyBitDelay
(EdchClass)
2 1 26
(EdchClass)

The scheduling process will distribute grants to UE according to :

1.
2.
Cells limitations :
the cell load level (RTWP measured periodically each 100ms)
HW and SW resources in Node B (E-BBU capacity)
Fairness :
UE satisfaction (happy bit carried in E-DPCCH) with rate scheduler

3.
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
UE limitations :
UE available power (UPH reported

UPH=UE_MaxTxPower / Pdpcch)

in
System
Information
SI
message
defined
by
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 HSUPA RRM
2.4 E-DCH Scheduler xCEM: Principle

Number of UE asking for Grants
UE max bit rate capability
UL radio load
available for E-DCH
Scheduling Information from UE:

UE power headroom
UE User Buffer
xCEM E-DCH
processing capacity
Maximum Target RTWP
Happy Bit
xCEM
E-DCH Scheduler
happyBitDelay
Relative and Absolute Grants

allocated
Per UE
(EdchClass)
2 1 27
periodicityOfSchedInfoGrant
periodicityOfSchedInfoNoGrant
(EdchClass)

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 FddCellTotalRotMax
and FddCEllRtwpRef. 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 HSUPA RRM
2.4 E-DCH Scheduler xCEM: Principle [cont.]
2 1 28

Grant Index values
Once the grant is signaled, the E-DPDCH power should not exceed the grant information:
n*ed < signaled grant value

2 HSUPA RRM
2.5 PS Streaming on HSUPA
new
NO
Cell E-DCH capable?
isStreamingOnEdchAllowed
(edchConf)
YES
NO
UE Release
= R7 ?
=
YES
isStreamingOnEdchAllowed ?
NO
YES
NO
Enabled for Rab Matching?*
In Case of Multi Service or

Multi-RAB
YES
RNC
PS Streaming on HSUPA
2 1 29
PS Str On DCH

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.

2 HSUPA RRM
2.5 Priority Info Support (iCEM and xCEM)

slide + notes
updated
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
data rate between UE is proportional
to the priority weight
15
eDchSpiRelativeWeight [E-DCH SPI]

(edchConf)
2 1 30

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.5 Priority Info Support
2.5.1 iCEM MAC-e Scheduler

Interference Contribution
UL Load
whole E-DCH cell capacity

equally shared by all mobiles
rateScheduling
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)
2 1 31

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.5.2 xCEM MAC-e Scheduler

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

2. Reduce Serving Users:
All requests
are granted
UEs ranking according to:

Throughput
SPI Relative Weight RWj
SPI Scheduling Weight SWi
See next Slide

2 1 32

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.5.2 xCEM MAC-e Scheduler [cont.]

serviceMinRate
serviceMaxRate
QId0
QId1
QIdN
new
serviceMinRate
serviceLowRate
serviceHighRate
non GBR MAC-d flow
serviceBFactor
serviceKFactor
serviceMaxRate
(edchServiceParameterSet)
COST x SW
Decrease OR Increase
COST
MAC-hs GBR - serviceLowRate

serviceLowRate
Throughput R
<
serviceMinRate
OR
GBR MAC-d flow
Throughput R
>
serviceMaxRate
MAC-hs GBR + serviceLowRate
serviceHighRate
2 1 33

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:
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
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.5.2 xCEM MAC-e Scheduler [cont.]
Lh > La
schedulingPrioritylevel
serviceBFactor
serviceKFactor
serviceMaxRate
serviceMinRate
1. Reduce Non-Serving Users

2. Reduce Serving Users:
UEs ranking according to:
Throughput
Relative Weight RWj
Scheduling Weight SWi
(EdchServiceParameterSet)
eDchSpiRelativeWeight
(EdchConf)
Rmax
Rmax
Average Tput
Rmax
Rmin
Average Tput
SWi
Rmin
Average Tput
Rmin
SWi = 1
PFi
SWi
UE is downgranted only according to RWi
This UE will be the last to be down-granted
PFi
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
2 1 34

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
Priority Weighting (Rmin = 40 kbps, Rmax = 60 kbps)

B = 5, K = 7
B = 3, K = 7
B = 1, K = 7
B = 7, K = 7
5
Priority
Priority
B = 7, K = 7
Priority Weighting (Rmin = 40 kbps, Rmax = 60 kbps)
4
3
B = 7, K = 3
B = 7, K = 1
4
3
B = 7, K = 5
0
20
30
40
50
60
70
80
20
30
Data Rate [kbps]
40
50
Data Rate [kbps]

60
70
80
2 HSUPA RRM
2.6 UL Radio Load Monitoring: needed for E-DCH scheduling

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

for cell color
calculation
RTWPref
Thermal Noise
Thermal Noise
No E-DCH
2 1 35
With E-DCH

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

2 HSUPA RRM
2.7 UL Radio Load Monitoring: Defense Mechanism
rtwpTimeDetection
(BTSCell)
RoT
All users are de-granted

All HARQ acked
rtwpTimeDetection
rtwpMargin
totalRotMax
Time
ALARM
2 1 36

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.

2 HSUPA RRM
2.8 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
UL Inner-Loop Power Control)
DPDCH
DPCCH
DPCCH
SIR
SIR
Thermal noise +
Interference
from other users
2 1 37
Part of user signal power seen as

interference by DPCCH
i.e. Self-interference


2 HSUPA RRM

High rate transmission on E-DCH
SIR: DPCCH SIR used in
UL Inner-Loop Power Control
or
Increase of Self-interference
UL Inner-Loop Power Control:

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

since power ratio E-DPDCH/DPCCH
(i.e. ed) is constant for a given grant
Increase of E-DPDCH Tx power

Channel profile
with good
orthogonality
UL noise rise converges

to a new working point
Channel profile
with poor
orthogonality
UL noise rise
diverges
UL Radio Overload Detection

all E-DCH users in the cell are
degranted to Zero
E-DCH throughput degrade

2 1 38

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.

2.9.1 First solution

Limitation of maximum E-TFCI

MAC-e scheduler is configured so it cannot grant higher than E-TFCI 89
x 10
3GP P TB table (TTI 10 ms )
E-DP DCH power vs . trans port block s ize

30
1.8
Trans ort block s ize (bits )
E-DP DCH power relativ to DP CCH (dB)
10ms TtiTable0
10ms TtiTable1
1.6
1.4
1.2
Max E-DCH TBS
1
0.8
0.6
0.4
25
20
15
10
0.2
0
20
40
60
80
100
Trans ort block s ize index
120
140
0.2
0.4
0.6
0.8
1
1.2
TB s ize (bits )
1.4
1.6
1.8
2
x 10
E-TFCI = 89
2 1 39

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.

2.9.2 Second Solution

Self-interference is taken into account in UL load prediction function

No need to limit maximum E-TFCI
e-modem
Main
Div
Channel
Estimation
e-codec (MAC-e Scheduler)

Orthogonality
loss
Estimation
Estimation of
orthogonality degree
( ) of channel
profile experienced
by user
Estimation based on relative
delays and amplitudes of
paths.
2 1 40
Goffset
Processing
Goffset
Total
UL
load
UL Load
Prediction
ed
rotOrthogonalityEstimation
(EdchConf)
SIR
Goffset :
Grant
Added to SIR in UL Load

Prediction module
Activation flag
If set to Off then self-interference is not taken into account (Goffset=0)

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.

2 HSUPA RRM
2.10 DL Power Management: RNC level
RNC view
SHO margin
P MaxCell
P traffic
P minHsdpa
notes
updated
Max Power for

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

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

2 HSUPA RRM
2.11 DL Power Management: NodeB level

BTSEquipment
E-AGCH
E-DCH
BTSCell
eagchPower
EdchConf
RadioAccessService
E-HICH
EdchRncConf
eagchPowerControlActivated
ehichPowerSignature
no PC for iCEM = fixed

PC for xCEM = dynamic
eagchPowerControlMode
ehichPowerControlMode
ergchPowerControlMode
eagchPowerControlModeXcem
2 1 42

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 HSPDSCH).
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
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 E-HICH signatures can be
used).
E-DCH DL Channels PC can be enabled for xCEM thanks to eagchPowerControlModeXcem and
eagchpowerContraolActivated parameters.

2 DL Power Management: NodeB level
2.11.1 E-DCH signaling channels Power Control Parameters

BTSEquipment
BTSCell
pMaxDlEDCH
E-AGCH
PEAGCH(k) =
PEDCH(k) + POEAGCH
eagchPowerOffset
EdchConf
PEDCH(k)
E-HICH
PEHICH signature(k) =
PEDCH(k) + POEHICH
signature
ehichErrorProbability
minPowerCorrection
maxPowerCorrection
pMinDlEDCH
E-RGCH
2 1 43
PERGCH signature(k) =
PEHICH signature(k) + POERGCH/EHICH
nonServingEHICHPowerOffset
powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset

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
EdchConfpMinDlEDCH but shall not exceed EdchConfpMaxDlEDCH (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 EdchConfeagchPowerOffset 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
EdchConfehichErrorProbability (provided the outer loop correction is within the range
[EdchConfminPowerCorrection, EdchConfmaxPowerCorrection]).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 EdchConfpowerOffsetERGCHServingNoSHO 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
(EdchConfcommonErgchPowerOffset and EdchConfnonServing 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 EdchConfeagchPowerControlModeXcem activates power control on all E-DCH DL control
channels.

2 HSUPA RRM

ILPC
notes
updated
SIR Target Update
NodeB level
OLPC
R99
R5
c
d
hs
SIR
estimation
BLER
estimation
RNC level
E-DCH Throughput
deltaEdpcch
R6
ec
ed
E-DPCCH PO
E-DPDCH PO
E-DCH TBS
referenceEtfciPowerOffset
edchTfcsTableIndex
2 1 44

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.

2.12.1 Closed Loop Power Control

Inner loop
Outer loop
RB
SRB
Log
Transp
DCCH DCH
TRB
DTCH E-DCH
Phys
DPDCH UE Tx
DPCCH
EDPDCH
EDPCCH
BTS sends packets to RNC
RNC calculates the BLER (CRC)

on DPDCH
=> RNC finds new SIRTarget to
obtain the needed BlerTarget
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
2 1 45


blerTarget
2.12.2 Scheduling and Power Offset

RNC
RadioAccessService
RL reconf prepare
RB setup
The UE finds
the whole (ETFCI vs. PO) table
using the reference ETFCI POs
BTS sends grants the UE according to
available resources and UE needs
At call set-up, RNC sends

- E-DCH MAC-d flow PO
- PO for SI
- Reference ETFCI Pos
- E-DPCCH PO
edchTfcConf
edchUserService
edchMACdPowerOffset
powerOffsetForSchedInfo
ReferenceTfciConfList
According to the grant it has

received, its needs and available
power, the UE chooses the ETFCI
RB
Log
Transp
Phys
SRB
DCCH
DCH
DPDCH
DPCCH
TRB
DTCH
E-DCH
EDPDCH
EDPCCH
deltaEdpcch
referenceEtfci
PowerOffset
UE Tx
PO (relative to DPCCH) from ETFCI/PO
table
PO EDCH Per MACD Flow from RBsetup
PO EDPCCH (relative to DPCCH) from RB setup
2 1 46

The E-DPCCH is power controlled relatively to the uplink DPCCH by the means of a pre-defined offset EDPCCH. However, as the E-DPCCH does not benefit from diversity (no soft handover), it may be needed to
increase slightly the offset.
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.
As for the E-DPCCH, the E-DPDCH does not benefit from diversity.
These offsets are not reconfigured during the call.

2.12.3 UL Outer Loop Power Control on UL DPDCH (UA05.0)
HS-DSCH
DL Data Transfer
(PS I/B)
E-DCH OL Power Control

is based on CRCI relative
to the UL DCH channels
E-DCH
UL Data Transfer (PS I/B)
ulUpSirStep
(DynamicParameterPerDch)
RNC
Iub
blerTarget
DCH
initialUlSirTarget
isUlOuterPCActivated (UlOuterLoopPowerCtrl)
2 1 47
SIR Target
Update
Partial
DCH 1 OLPC
Partial
DCH 2 OLPC
OLPC
Master

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.

2.12.4 UL OL Power Control on HARQ retransmission (UA05.1)

HS-DSCH
DL Data Transfer
(PS I/B)
E-DCH OL Power Control

is based on Number of HARQ
NACK of the E-DCH channel
E-DCH
UL Data Transfer (PS I/B)
ulSirStep
(DynamicParameterForEdchTti10ms)
RNC
DCH
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.
Computation method: Partial SIR Tg (k+1) = Partial SIR Tg (k) + ulSirStep
x (NHARQ NHARQ Target)
known from
N of HARQ Retransmissions IE
2 1 48
set via
blerTarget
(BlerQualityList)

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

optimal NHARQ Target depends on:
Improvement in UA6 by
introducing adaptive
NHARQ Target
E-DCH RLC User

Throughput [kbps]
Number of E-DCH users

in the cell
UL radio load
System simulation: Variable SIR Target

Multi-user
Mono-user
1200
1100
1000
900
800
700
600
500
400
0.2

0.4
0.6
0.8
NHARQ Target
1.2
1.4
2.12.5 UL OL Power Control on HARQ retransmission (UA05.1) [cont.]
SIR Target
NodeB 1
NodeB 2
UL OLPC Master
Partial
SIR Target
Partial
SIR Target
(DCH 1)
(DCH 2)
UL OLPC MAChine (DCH 1)
CRCI of UL DCH 1
UL OLPC MAChine (DCH 2)
CRCI of UL DCH 2
2 1 49
Update of SIR
Target, according
to all Partial SIR
Targets
Partial
SIR Target
(E-DCH)
UL OLPC MAChine (EDCH)
N of HARQ
Retransmissions IE

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.

2.12.6 E-DCH Adaptive HARQ Control (UA06)

Number of active E-DCH users
S3
maxNumActiveEdchUsersPerCellForS2
(EdchCellClass)
S2
maxNumActiveEdchUsersPerCellForS1
(EdchCellClass)
S1
green
yellow
Cell State = S1 NHARQ Target =
nHarqRetransTargetS1
2 1 50
red
UL Radio Load Color
ulSirStep

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:
Cell State = S1 NHARQ Target = nHarqRetransTargetS1

2.12.7 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
2 1 51
Partial
SIR Target
Partial
SIR Target
(E-DCH SRB)
(E-DCH TRB)
UL OLPC
MAChine
UL OLPC
MAChine
(E-DCH SRB)
(E-DCH TRB)
N of HARQ
Retransmissions IE
N of HARQ
Retransmissions IE

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.

2.12.8 Fast Decrease of E-DCH Partial SIR Target if Good Radio

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) +
2 1 52
edchSirStepFastDecrease

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

2.12.9 E-DCH Partial SIR Target in case of Soft HO

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
HFI 3
HFI 2
edchOlpcServingRatioThreshold
HFI Ratio
edchOlpcHfiRatioThreshold
2 1 53

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

2.12.9 E-DCH Partial SIR Target in case of Soft HO [cont.]

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.
Triggers for applying Partial SIR Target correction:

Reception of HFI
End of HFI monitoring period if HFI Reception Scenario = HFI 3
HFI 0: Corresponds to the normal case No Partial SIR Target correction applied
No SHO case: Partial SIR Target correction always =
2 1 54
edchSirStepHfi [HFI1]

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

2 HSUPA RRM
2.13 Radio Link Control - DL/UL Imbalance Detection

notes
updated
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
2 1 55
VS.EdchLinkImbalance ++


2 HSUPA RRM
2.14 User Services supported with HSUPA

isMonoDirectionalHsdpaRabAllowed
HSxPA
Stand-alone
enabledForRabMatching (UlUserService)

PS Streaming HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128
Combination
CS Conv. Speech + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384
CS Conv. 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 Str. HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128
(CS Conv. Speech +) (PS I/B HSDPA/DCH+) PS Streaming (HSDPA or DCH/DCH) :
PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64,128
(CS Conv. Speech +) (PS I/B HSDPA/HSUPA+) PS Streaming (HSDPA or DCH/DCH) :
PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64
2 1 56

Unlike multi service on HSDPA, there is no activation flag to enable or disable the multi RAB on HSDPA.
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 EDCH 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.

2 HSUPA RRM
2.15 HSUPA CAC

edchNumberUserCapacityLicensing
Capacity
BTSEquipment
edchMaxNumberUserEbbu (iCEM)
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

2 1 57

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.

2 HSUPA RRM
2.16 RAB Allocation Phase

UE
RNC
NodeB
e-DCH-MACdFlow-ID,
PowerOffsets AGCH, RGCH, HICH,
PowerOffset EDPCCH),
Reference ETFCI PO, TTI
HARQ (RV table, max retrans )
AGCH OVSF code

ERNTI (1&2)
RGCH HICH OVSF code HICH
signature
initial serving grant value
SGSN
slide
updated
RANAP/RAB Assignment Request

NBAP/Radio Link Reconfiguration Prepare
NBAP/Radio Link Reconfiguration Ready
NBAP/Radio Link Reconfiguration Commit
Same as RL Reconf Prep + ERNTI (1&2)

AGCH, RGCH,HICH OVSF
HICH signature
Initial serving grant
RRC/Radio Bearer Setup

RRC/Radio Bearer Setup Complete
RANAP/RAB Assignment Response
2 1 58

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

2 HSUPA RRM
2.17 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
HSUPA to DCH Fallback
CAC OK ?
NoFallBack
edchToDchFallbackSteps
No
Yes
HSUPA/HSDPA RB
established
2 1 59
MultiStep
MonoStep
DCH/HSDPA RB
to established
DCH/DCH RB
to established

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)

2 HSUPA RRM
2.18 Always On: degraded2AOnOnly - URA/Cell_PCH used

Always-on (degraded2AlwaysOnOnly, PchRrcStates none)
Low activity / Inactivity
Activity (UL or DL)
Downsize
(step 1)
Downsize
(step 2)
Downsize
(step 3)
Inactivity
HSDPA + E-DCH
CELL_FACH
CELL_PCH / URA_PCH
Downsize timer Step 1
timerT1ForHsdpaAndEdch
(AlwaysOnTimer)
timerT1ForHsdpaAndEDch
Downsize
timer
Step 2
(fachToCellPchTimer,
fachToUraPchTimer)
Downsize
timer
Step 3
(cellPchToIdleTimer,
uraPchToIdleTimer)
t
Traffic UL/DL
isAlwaysOnAllowed
(UlUserService)
2 1 60
isAlwaysOnAllowed
(UlRbSetConf)
PchRrcStates

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.

2.18 Always On
2.18.1 degraded2AOnOnly - URA/Cell_PCH not used
Always -on (degraded2AlwaysOnOnly , PchRrcStates = none )
Activity (UL or DL)
Low activity /
Inactivity
Downsize
Release
Inactivity
HSDPA + -E DCH
Downsized RB (CELL_FACH)
t
Downsize
timer
Release timer
(timerT2)
(timerT1ForHsdpaAndEdch)
(AlwaysOnTimer)
Traffic UL/DL
isAlwaysOnAllowed
(UlUserService)
2 1 61
isAlwaysOnAllowed
(UlRbSetConf)
PchRrcStates

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

2.18 Always On
2.18.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
isAlwaysOnAllowed
(UlUserService)
2 1 62
isAlwaysOnAllowed
(UlRbSetConf)
PchRrcStates

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.

3 HSUPA Mobility
2 1 63


3 HSUPA Mobility
3.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
E-DCH non-serving RL of non-serving NodeB
Cell of DCH AS (but not in E-DCH AS)

Cell of E-DCH active set (and of DCH AS)
RL1
RL4
D
F
E-DCH serving cell
RL3
H
RL2
Active Set
E-DCH Active Set

Iub
E-DCH serving RLS
E-DCH non-serving RLS
Fill up the table

2 1 64

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

3 HSUPA Mobility
3.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
2 1 65

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

3 HSUPA Mobility
Event1J
Event1J
Event1J
CPICH_Ec/No
Event1J
3.3 E-DCH Active Set Management: Event 1J

isRrcEdchEvent1JAllowed
E-AS Cell
amountRep1J
(FullEventRepCritShoMgtEvent1J)
AS Cell
maxNbReportedCells1J
entering reporting range

leaving reporting range
InE-AS Cell
repActThresh1J
timeToTrigger1J
(FullEventHoConfShoMgtEvent1J)
repInterval1J
10 LogM AS + CIO AS 10 LogM InEAS + CIO InEAS H 1J /2 )

hysteresis1J (FullEventHoConfShoMgtEvent1J)
neighboringCellOffset (UMTSFddNeighboringCell)
2 1 66

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.

3 HSUPA Mobility
Event1D
3.4 E-DCH Active Set Management: Primary Cell Change
CPICH_Ec/No
R6 cell
NotBest Cell
new Primary Cell

not support current
E-DCH Configuration
R99/R5 cell
Best Cell
E-DCH Configuration changed to match

E-DCH capabilities of the new Primary
Cell.
E-AS not Compatible
More Restrictive
new Primary Cell
the E-DCH RB
reconfigured to UL DCH
E-AS Compatible
Remove All E-AS cells

not compatible
2 1 67
Reconfigure All E-AS cells


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
3 HSUPA Mobility
3.5 Soft HO Data Transmission Example

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

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 desynchronization 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 EDCH TTIs) applies for both 10ms and 2ms E-DCH TTI.

3 HSUPA Mobility
3.6 Manage UL Noise Rise due to E-DCH Non-Serving RL : iCEM case

E-DCH serving UE

E-DCH cell considered
E-DCH non- serving UE
IF
E DCH Rx Power (
E DCH Rx Power (
THEN
+
+
)
+
>
targetNonServingToTotalEDCHPowerRatio
(FDDCell)
Down sent on Common E-RGCH for non-serving UE in non-serving NodeB

Down sent on Dedicated E-RGCH for non- serving UE in serving NodeB
2 1 69

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.

3.6 Manage UL Noise Rise due to E-DCH Non-Servin RL
3.6.1 xCEM case

E-DCH serving UE

E-DCH cell considered
E-DCH non- serving UE
IF
THEN
IF
THEN
E DCH Rx Power (
E DCH Rx Power (
)
+
>
targetNonServingToTotalEDCHPowerRatio
(FDDCell)
Down sent on Common E-RGCH for non-serving UE in non-serving NodeB
E DCH Rx Power (
E DCH Rx Power (
)
+
>
edchSofterHoLimit
(EdchConf)
Down sent on Dedicated E-RGCH for non-serving UE in serving NodeB
2 1 70

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.

3 HSUPA Mobility
3.7 E-DCH Macro Diversity RAN Model

RNC
RadioAccessService
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed
NodeB
FDDCell
targetNonServingToTotalEdchPowerRatio
DedicatedConf
EdchRncConf
maxNumberOfRlEdch
HoConfClass
MeasurementConfClass
UsHoConf/
PsHSDPA
CsSpeechPlusHSDPA
FullEventRepCritShoMgt
FullEventHoConfShoMgt
FullEventHoConfShoMgtEvent1J
hysteresis1J
timeToTrigger1J
2 1 71
NodeBConfClass
iubEdchDelayVariation
BTSEquipment
FullEventRepCritShoMgtEvent1J
amountRep1J
maxNbReportedCells1J
repActThresh1J
repInterval1J
BTSCell
EdchConf
edchSofterHoLimit
nonServingEHICHPowerOffset
commonERGCHPowerOffset
edchNumCommonRgPerCode

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.

3 HSUPA Mobility
3.8 Intra-Freq Mobility : Primary Cell Change

Core Network
Core Network
Serving
RNC
FDD1
Serving
RNC
FDD1
FDD1
FDD1
Primary
Cell
Primary
Cell
Primary Cell
Change
E-DCH
HS-DSCH
UE
2 1 72
DCH
E-AGCH
UE

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.

3 Intra-Freq Mobility : Primary Cell Change
3.8.1 Call Flow

source Node B
RNC
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
2 1 73

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
2 1 74


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


3 HSUPA Mobility
3.9 Intra-Freq Mobility over Iur

Core Network
isHsdpaOverIurAsSrncAllowed
isEdchOverIurSrncAllowed
isHsdpaOverIurAsDrncAllowed
isEdchOverIurDrncAllowed
isMACShHsdpaAllowed
Iur
Serving
RNC
FDD1
FDD1
Primary
Cell
Primary Cell
Change
Drift
RNC
FDD1
FDD1
Neighbor
Primary
Cell
isHsdpaAllowed
isEdchAllowed
(NeighboringRNC)
isEdchAllowed
edchMinSfCapabilities
isEdchTti2msAllowed
E-DCH
(RemoteFddCell)
HS-DSCH
UE
2 1 76
DCH

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, its 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.

3 HSUPA Mobility
3.10 Inter-Freq Intra-RNC Mobility

Core Network
isEdchHhoWithMeasAllowed
isIrmCacForInterFreqIntraRncEnable
Core Network
Serving
RNC
FDD1
Serving
RNC
FDD2
FDD1
FDD2
Primary
Cell
Primary
Cell
iMCTA
P-CPICH
E-DCH
HS-DSCH
UE
2 1 77
DCH
UE

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

3 HSUPA Mobility
3.11 Inter-Freq Inter-RNC Mobility: Without Iur OR

Core Network
1
Serving
RNC
isInterFreqHandoverOverIurAllowed
(NeighboringRNC)
= False
SRNS Relocation
2
no Iur
RNC
FDD1
2
Serving
RNC
FDD1
1
RNC
FDD2
FDD2
iMCTA
Primary
Cell
Primary
Cell
P-CPICH
E-DCH
HS-DSCH
UE
2 1 78
DCH

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

3 Inter-Freq inter-RNC Mobility
3.11.1 Inter-Freq Inter-RNC Mobility: With Iur AND

Core Network
1
Serving
RNC
isInterFreqHandoverOverIurAllowed
(NeighboringRNC)
= True
Iur
FDD1
FDD1
1
Drift
RNC
FDD2
FDD2
iMCTA
Primary
Cell
Primary
Cell
P-CPICH
E-DCH
HS-DSCH
UE
2 1 79
DCH

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.

3 HSUPA Mobility
3.12 Inter-RAT Mobility

Nothing specific compared to R99 or HSDPA 3G to 2G HHO
activationHoGsmPsAllowed
isInterFreqMeasActivationAllowed
isBlindHoRescueAllowed
2 1 80
isPatternAllowed
isGsmCmodeActivationAllowed
(CmodePatternSeqInfo)
(DlUserService)

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
2 1 81




for this module
2 1 82


End of Module
Module 2
2 1 83


Section 3
Appendix
Module 1
9300 W-CDMA

3JK11638AAAAWBZZA Edition 1
Section 3 Pager 1
Blank Page
32
Appendix
Document History
Edition
Date
Author
Remarks
01
2009-02-26
El Abed, Achrafe
Charneau, Jean-Nol
First edition

Section 3 Pager 2
Module Objectives
Describe HSDPA CQI mapping tables
Describe HSUPA E-TFCI and grants
Describe HSDPA modulation usage versus codes.
33
Appendix

Section 3 Pager 3
34
Appendix

Section 3 Pager 4
Table of Contents
Page

1 HSDPA : CQI Mapping Tables (3GPP)
1.1 CQI mapping table for UE categories 1 to 6
1.2 CQI mapping table for UE categories 7 to 8
1.3 CQI mapping table for UE category 9
1.4 CQI mapping table for UE category 10
1.5 CQI mapping table for UE category 11 and 12
2 HSUPA : E-TFCI and Grant
2.1 E-DCH Transport Blocks Tables
2.2 E-DPDCH power vs Transport Block Size
2.3 Absolute Grant Table
3 Flexible HSDPA modulation usage versus codes (xCEM)
3.1 HSDPA modul. and code / CQI : 25.214 Mapping Table
3.2 Flexible resources usage
3.3 TFRC Selection for Flexible HSDPA
End of Module
35
Appendix

Section 3 Pager 5
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

36
Appendix

Section 3 Pager 6
37
Appendix

Section 3 Pager 7
1 HSDPA : CQI Mapping Tables
1.1 HSDPA CQI Mapping Tables
38
Appendix

Section 3 Pager 8
new
1.1 CQI mapping table A for UE categories 1 to 6
39
Appendix

Section 3 Pager 9
new
1.2 CQI mapping table B for UE categories 7 to 8
3 10
Appendix

Section 3 Pager 10
new
1.3 CQI mapping table C for UE category 9
3 11
Appendix

Section 3 Pager 11
new
1.4 CQI mapping table D for UE category 10
3 12
Appendix

Section 3 Pager 12
new
1.5 CQI mapping table E for UE category 11 and 12
3 13
Appendix

Section 3 Pager 13
new
1.6 HSDPA CQI Mapping Table F
3 14
Appendix

Section 3 Pager 14
new
1.7 HSDPA CQI Mapping Table G
3 15
Appendix

Section 3 Pager 15
new
1.8 HSDPA CQI Mapping Table H & I
3 16
Appendix

Section 3 Pager 16
new
3 17
Appendix

Section 3 Pager 17
2.1 E-DCH Transport Blocks Tables

2
x 10
3GP P TB ta ble (TTI 10 ms )
1.8
10ms TtiTa ble0
10ms TtiTa ble1
Tra ns ort block s ize (bits )
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
Param identity (Customer

Class 3)
edchTfcsTableIndex
3 18
Default value
10msTtiTable1
20
40
60
80
100
Tra ns ort block s iz e index
120
140
Range
Comment
2msTtiTable0,
2msTtiTable1,
10msTtiTable0,
10msTtiTable1
2ms tables not

supported. Table1
more suitable for RLC
PDU size 336 bits.
Appendix

Section 3 Pager 18
2.2 E-DPDCH power vs Transport Block Size
The higher the

transport block size
is, the higher is the
required power
In order not to
signal all power
offsets, only a
subset are signaled
as reference.
The remaining ETFCI are
interpolated as
specified by 3GPP.
E-DP DCH power vs . trans port bloc k s ize

30
E-DP DCH power re lativ to DP CCH (dB)
25
20
15
10
0.2
0.4
0.6
0.8
1
1.2
TB s ize (bits )
1.4
1.6
1.8
2
x 10
Reference signaled E-TFCI

3 19
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 .

Section 3 Pager 19
2.3 Absolute Grant Table

Absolute grant information

are signaled through the EAGCH. It contains:
The E-RNTI, i.e. UE identity
The grant value index
between 0 and 31.
Depending on the TTI

length, it is transmitted on
one sub-frame (3 slots) or
one frame (15 slots).
Once transmitted, no need
to transmit it again, unless
grant modification needed
3 20
Absolute Grant Value

2
(168/15) x6
2
(150/15) x6
(168/15)2x4
2
(150/15) x4
2
(134/15) x4
2
(119/15) x4
2
(150/15) x2
2
(95/15) x4
2
(168/15)
2
(150/15)
2
(134/15)
2
(119/15)
(106/15)2
2
(95/15)
2
(84/15)
2
(75/15)
2
(67/15)
2
(60/15)
2
(53/15)
(47/15)2
2
(42/15)
2
(38/15)
2
(34/15)
2
(30/15)
2
(27/15)
(24/15)2
2
(19/15)
2
(15/15)
2
(11/15)
(7/15)2
ZERO_GRANT*
INACTIVE*
Appendix

Section 3 Pager 20
Index
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
3 Flexible HSDPA modulation usage

versus codes (xCEM)
3 21
Appendix

Section 3 Pager 21
3.1 HSDPA modul. and code / CQI : 25.214 Mapping Table

CQI value
Transport
Block Size
N/A
137
Reference power
Number of
Modulation
adjustment
HS-PDSCH
NIR
XRV
Out of range
1
QPSK
28800
For each UE
category
Condition: BLER
10%
461
QPSK
650
QPSK
15
3319
QPSK
16
3565
16-QAM
23
9719
16-QAM
24
11418
16-QAM
25
14411
10
16-QAM
26
17237
12
16-QAM
27
21754
15
16-QAM
28
23370
15
16-QAM
29
24222
15
16-QAM
30
25558
15
16-QAM
3 22

Tables specified
in
TS 25.214
Example for UE
category 10
Poor granularity :
performances are
reduced by using
the 25.214
example.
xCEM uses a table
with much more
possibilities
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.

Section 3 Pager 22
3.2 Flexible resources usage

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

=> better spectrum efficiency and cell throughput
3 23
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).

Section 3 Pager 23
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
TBS1 ; TBS2
CQI =16
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.
3 24
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

Section 3 Pager 24
End of Module
Module 3
3 25
Appendix

Section 3 Pager 25
Section 4
Glossary
Module 1
9300 W-CDMA

Section 4 Pager 1
Blank Page
42
Glossary
Document History
Edition
Date
Author
Remarks
01
2010-04-30
Elsner, Bernhard
Charneau, Jean-Nol
First edition

Section 4 Pager 2
Abbreviations and Acronyms

#
to notes
view!
16-QAMSwitch
16 Quadrature
Amplitude
Modulation
1xEV-DO 1x EVolution Data Only
1xEV-DV 1x EVolution Data and Voice
1xRTT
1 times 1.25MHz Radio Transmission
Technology
3GPP
3rd Generation Partnership Project
3xEV-DV 3x Evolution Data and Voice
A
AAL2
AAL5
ACK
AICH
AM
AMC
AMD
AMR
AO
ARQ
AS
ASC
ATM
ATM Adaptation Layer type 2

ATM Adaptation Layer type 5
ACKnowledgment
Acquisition Indicator CHannel
Acknowledged Mode
Adaptive Modulation and Coding
Acknowledged Mode Data
Adaptive Multi-Rate
Always-On
Automatic Repeat Query
Access Stratum, Active Set
Access Service Class
Asynchronous Transfer Mode
B 43
BCCHGlossary
Broadcast Control CHannel
BCH
Broadcast CHannel
BER
Bit Error Rate
BFN
NodeB Frame Number
BLER
BLock Error Rate
BMC
Broadcast Multicast Control
BPSK
Binary Phase Shift Keying
BR
Bit Rate
BTS
Base Transceiver Station
C
CAC
CC
CCCH
CCP
CCPCH
CCTrCH
CDMA
CEM
CFN
CID
CK
CM
CmCH-PI
CP
CP
CPCH
CPICH
CQI
CRC
C-RNC
C-RNTI
notes
updated
CS
CTCH
D
DCCH
DCH
DL
DPCCH
DPCH
DPDCH
D-RNC
DS
DS-CDMA
DSCH
DTCH
DTX
E
E1
Dedicated Control CHannel

Dedicated CHannel
Downlink
Dedicated Physical Control CHannel
Dedicated Physical CHannel
Dedicated Physical Data CHannel
Drift-Radio Network Controller
Delay Sensitive
Direct Sequence-Code Division
Multiple Access
Downlink Shared CHannel
Dedicated Traffic CHannel
Discontinuous Transmission
EDGE
EGPRS
Standard European PCM link (2.048

Mbps)
Enhanced Data for Global Evolution
EDGE GPRS
F
FA
FACH
FBI
FDD
FDMA
FIFO
FP
Frequency Allocation
Forward Access CHannel
FeedBack Information
Frequency Division Duplex
Frequency Division Multiple Access
First In First Out
Frame Protocol
Call Admission Control

Chase Combining
Common Control CHannel
Communication Control Port
Common Control Physical CHannel
Coded Composite Transport CHannel
Code Division Multiple Access
Channel Element Module
Connection Frame Number
Channel IDentifier
Ciphering Key
Compressed Mode
Common transport CHannel Priority
Indicator (SPI)
NodeB Control Port
Control Plane
Common Packet CHannel
Common PIlot CHannel
Channel Quality Indicator
Cyclic Redundancy Check
Controlling-Radio Network Controller
Cell-Radio Network Temporary
Identity
Circuit Switch
Common Traffic CHannel
G
GBR
GMM
GPRS
GSM
GTP
Guaranteed Bit Rate

Global Mobility Management
General Packet Radio Service
Global System for Mobile
communications
GPRS Tunneling Protocol
H
HARQ
HFI
HFN
HO
H-RNTI
Hybrid ARQ
HARQ Failure Indication
Hyper Frame Number
HandOver
HS-DSCH Radio Network Temporary
Identifier
HSDPA
High Speed Downlink Packet Access
HS-DPCCH
High Speed Dedicated Physical
Control CHannel
HS-DSCH High Speed Downlink Shared
CHannel
HS-PDSCH High Speed Physical Downlink
Shared CHannel
HS-SCCH High Speed Shared Control Channel
HSUPA
High Speed Uplink Packet Access

Section 4 Pager 3
Abbreviations and Acronyms [cont.]

I
IE
IK
ILPC
IMA
iMCTA
Information Element
Integrity Key
Inner Loop Power Control
Inverse Multiplexing ATM
intelligent Multi Carrier Traffic
Allocation
iMCRA
intelligent Multi Carrier RRC Allocation
IMEI
International Mobile Equipment
Identity
IMSI
International Mobile Subscriber
Identity
IMT-2000 International Mobile
Telecommunication for year 2000
IP
Internet Protocol
IR
Incremental Redundancy
iRM
intelligent RAB Mapping
Iu
Interconnection point between RNC
and 3G Core Network
Iub
Interface between Node B and RNC
Iur
Interface between two RNCs
notes
updated
NBAP
NDI
Node B Application Part

New Data Indicator
NDS
Node B
Non-Delay Sensitive
Logical node responsible for radio
Tx/Rx to/from UE
Non Return to Zero
NRZ
O
OAM
OCNS
OLPC
OLS
OVSF
Operation Administration and

Maintenance
Orthogonal Channel Noise Simulator
Outer Loop Power Control
Olympic Level Service
Orthogonal Variable Spreading
Factor
P
PA
Power Amplifier
PCCH
Paging Control CHannel
P-CCPCH Primary-Common Control Physical
CHannel
PCH
Paging CHannel
PCM
Pulse Code Modulation
PCPCH
Physical Common Control CHannel
PDP
Packet Data Protocol
PDU
Protocol Data Unit
PI
Paging Indicator
PI
Priority Indicator
PICH
Paging Indicator CHannel
PIR
Partial Incremental Redundancy
PLMN
Public Land Mobile Network
PMM
Packet Mobility Management
PN
Pseudo Noise
PQ
Priority Queue
PRACH
Physical Random Access CHannel
PS
Packet Switch
P-SCH
Primary-Synchronization CHannel
PSK
Phase Shift Keying
K
Kbps
Kilobit per second
kHz
kiloHertz
4
KPI 4Glossary
Key Performance Indicator
Ksps 9300 W-CDMA
Kilo
symbol per second
L
L1
L2
L3
LA
LAC
LAI
LAN
LSB
Layer 1 (Physical Layer)

Layer 2 (Data Link Layer)
Layer 3 (Network Layer)
Location Area
Location Area Code
Location Area Identity
Local Area Network
Least Significant Bit
M
MAC
Mbps
MBR
MCC
MCPA
Mcps
MHz
MIMO
MIR
MM
MNC
MOC
MOI
MOS
MRC
MSB
Medium Access Control

Megabit per second
Maximum Bit Rate
Mobile Country Code
Multi Carrier Power Amplifier
Megachip per second
MegaHertz
Multiple In Multiple Out
Mix Incremental Redundancy
Mobility Management
Mobile Network Code
Managed Object Class
Managed Object Instance
Mean Opinion Score
Maximum Ratio Combining
Most Significant Bit
R
R4
R5
R6
RA
RAB
RAC
RACH
RAN
RANAP
N
NACK
NAS
Negative ACKnowledgement
Non Access Stratum
RB
RF
RL
Q
QId
QoS
QPSK
Queue Identity
Quality of Service
Quadrature Phase Shift Keying
Release 4
Release 5
Release 6
Routing Area
Radio Access Bearer
Routing Area Code
Random Access CHannel
Radio Access Network
Radio Access Network Application
Part
Radio Bearer
Radio Frequency
Radio Link

Section 4 Pager 4
Abbreviations and Acronyms [cont.]

RNSAP
Radio Network
Subsystem
Switch
to notes
view!Application
RNTI
RRC
RRM
RTWP
RTT
RV
RX
Part
Radio Network Temporary Identity
Radio Resource Control
Radio Resource Management
Received Total Wideband Power
Radio Transmission Technology
Redundancy Version
Receiver / Reception
TrCH
TS
TTI
TX
notes
updated
Transport CHannel
Time Slot
Transmission Time Interval
Transmitter / Transmission
U
UARFCN UMTS Absolute Radio Frequency
Channel Number
UDP
User Datagram Protocol
UE
User Equipment
UM
Unacknowledged Mode
UMTS
Universal Mobile Telecommunication
System
UP
User Plane
UPH
UE Power Headroom
URA
UTRAN Registration Area
U-RNTI UTRAN-Radio Network Temporary
Identity
UTRAN
Universal Terrestrial Radio Access
Network
Uu
the radio interface between UTRAN
and UE
S
SA
Service Area
SAP
Service Access Point
SAW
Stop And Wait
S-CCPCH Secondary-Common Control
Physical CHannel
SCH
Synchronization CHannel
SCR
Sustainable Cell Rate
SDU
Service Data Unit
SF
Spreading Factor
SFN
System Frame Number
SHO
Soft HandOver
SI
System Information
SIM
Subscriber Identity Module
V
SIR
Signal to Interference Ratio
5 Session Management
VCC
Virtual Channel Connection
SM 4Glossary
UA06 HSxPA
VoIP
Voice over IP
SNR 9300 W-CDMA
Signal
to Algorithms
NoiseDescription
Ratio
SPI
Scheduling Priority Indicator (CmCHW
PI)
W-CDMA Wideband-CDMA
SRLR
Synchronous Radio Link
Reconfiguration
S-RNC
Serving-Radio Network Controller
S-SCH
Secondary-Synchronization CHannel
STTD
Space Time Transmit Diversity
STSR sectorial transmit and sectorial receive

SW
T
TAF
TB
TBS
TC
TCP
TDD
TDM
TDMA
TF
TFC
TFCI
TFI
TFO
TFRC
TFRI
TFS
THP
TPC
Scheduling Weight
That's All Folks!

Transport Block
Traffic Class
Transmission Control Protocol
Time Division Duplex
Time Division Multiplexing
Time Division Multiple Access
Transport Format
Transport Format Combination
Transport Format Combination
Indicator
Transport Format Indicator
Tandem Free Operation
Transport Format and Resource
Combination
Transport Format and Resource
Indicator
Transport Format Set
Traffic Handling Priority
Transmit Power Control
Section 4 Pager 5
End of Module
Module 4
46
Glossary

Section 4 Pager 6
Section 6
intelligent Multi Carrier RRC Allocation
Module 1
9300 W-CDMA
UA07 R99 Algorithms Description

Section 6 Pager 1
Blank Page
62
Call Admission
9300 W-CDMA UA07 R99 Algorithms Description
Document History
Edition
Date
Author
Remarks
01
2009-02-29
El Abed, Achrafe
Charneau, Jean-Nol
First edition
02
2009-04-10
Charneau, Jean-Nol
Parameter name correction:

maxDlEstablishmentRbRate & maxUlEstablishmentRbRate

Section 6 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
63
Call Admission

Section 6 Pager 3
64
Call Admission

Section 6 Pager 4
Table of Contents
Page

1 iMCRA overview
1.1 Why intelligent Multi Carrier RRC Allocation?
1.2 Redirection types
1.3 Twin cells definition
2 iMCRA capabilities
2.1 UE capabilities and call type
2.2 Cell capabilities and faType
3 iMCRA algorithms
3.1 CapaOnly
3.2 CapaAndEstCause
3.3 PreferredFa
3.4 CAC
4 iMCRA RAN model
4.1 iMCRA: RAN Model
5 iMCRA exercises
5.1 Exercise 1
5.2 Exercise 2
65
Call Admission

Section 6 Pager 5
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

66
Call Admission

Section 6 Pager 6
1 iMCRA overview
67
Call Admission

Section 6 Pager 7
1 iMCRA overview
1.1 Why intelligent Multi Carrier RRC Allocation?

R99
R99
R99
R99
R99
3G F3
R99
R99
R99
notes
updated
R99
3G F2
HSDPA
HSDPA
HSDPA
HSDPA
HSDPA
3G F1
R99
R99
R99
Why iMCRA ?
R99
R99
R99
R99
R99
R99
R99
Traffic Segmentation
UE & Cell Capability
isRrcRedirectionInterFreq(RadioAccessService)
RRC CAC Failure

Load balancing
68
Call Admission
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 6 Pager 8
1 iMCRA overview
1.2 Redirection types

PreferredFa (Frequency Allocation)
Carrier Allocation
Preferences
capaAndEstCause
Based on UE
Capabilities and
call type
capaOnly
Based on UE HSPA
Capabilities only
rrcRedirectionType(InterFreqHhoFddCell)
cac
On RRC Call admission
failure
69
none
Algorithm disabled
Call Admission
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 6 Pager 9
1 iMCRA overview
1.3 Twin cells definition

Up to 5 twin cells can be defined (co-located inter-frequency cell plus cells
from other Node B for blind redirection referenced by Cell Id)
NodeB1
FDD1
twinCellList(InterFreqHhoFddCell)
CellId xyz
FDD2
FDD3
FDD4
FDD5
6 10
Call Admission

Section 6 Pager 10
NodeB 2
6 11
Call Admission

Section 6 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 Combination
UE Release
UE Capability
Indication
R99
N/A
Higher than R6
Absent
R5
N/A
Higher than R6
HS-DSCH
Higher than R6
HS-DSCH+EDCH
6 12
UE Capability
Deduced
Establishment Cause
Call Type
Originating
Conversational Call
Conversational
Terminating
Conversational Call
DCH
Originating Interactive
Originating Background
Originating Streaming
HSDPA
Terminating Interactive
DATA
Terminating Background
HSUPA
Terminating Streaming
Other Causes
Other
Call Admission
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.

Section 6 Pager 12
2.2 Cell capabilities and faType
For UE Capability / UE Capability+Establishment Cause

Algorithms, the cell capability is determined by
the HSDPA / EDCH activation parameters
For the faType,

cells capability is defined:
RadioAccessService
RRCRedirectionConfClass 0..6
Frequency Allocation 1..6
Cell Concept
Cell Capability
Indication
Cell Configuration
R99
DCH Capable
hsdpaActivation = False
edchActivation = False
HSDPA
HSDPA Capable
hsdpaActivation = True
edchActivation = False
HSxPA
HSUPA Capable
hsdpaActivation = True
edchActivation = True
6 13
faType(InterFreqHhoFddCell)
Conversational
Call Admission

Section 6 Pager 13
Data
Other
3 iMCRA algorithms
6 14
Call Admission

Section 6 Pager 14
3 iMCRA algorithms
3.1 CapaOnly
Select UE Capability
compatible Cells among
rrcRedirectOrigCellColorThreshold
originating and twin cells
(InterFreqHhoFddCell)
If originating cell among
candidates and cell color
better than threshold, setup
UE capability
Target FA
Fallback FAs
DCH
DCH Cells
Originating &
all twin cells
HSUPA then
DCH Cells
HSDPA then
DCH Cells
HSDPA
HSUPA
HSDPA Cells
HSUPA Cells
call on originating cell
Else select cells with lowest

load color (Green<Yellow<Red)
selected ones, setup call in it.
Else select the final target cell
with round robin mechanism
(dlFrequencyNumber >
originating one)
6 15
Call Admission

Section 6 Pager 15
3 iMCRA algorithms
3.2 CapaAndEstCause
Select UE capability & call
type compatible Cells among
UE capability
DCH
HSDPA
HSUPA
Call type
Target FA
Fallback
FAs
Conversational
DCH
Data
DCH
candidates and cell color
Other
Originating
better than threshold, setup
Conversational
DCH
Data
HDSPA
Other
Originating
Conversational
DCH
Data
HSUPA
Other
Originating
originating and twin cells

call on originating cell

Same as in
capaOnly
load color (Green<Yellow<Red)

originating one)
6 16
Call Admission

Section 6 Pager 16
3 iMCRA algorithms
3.3 PreferredFa
Call Type
Target FA
Fallback FAs
Conversational
Select FAs with

faType set to
Conversational
FAs of type other;

if none FAs of type
Data
Data
Select FAs with

faType set to
Data
FAs of type other;

if none FAs of type
conversational
Other
Select cells with

faType set to
others
6 17

candidates & cell color better
than threshold, setup call on
originating cell

load color (Green
<Yellow<Red)

originating one)
Call Admission

Section 6 Pager 17
3 iMCRA algorithms
3.4 CAC
RNC
If CAC failure occurs,

select cells with lowest
cell color (green < yellow < red)
RRC Connection Request

CAC Failure on Originating Cell
6 18
If more than one cell selected, select

the final target cell with round robin
mechanism (dlFrequencyNumber>
originating one)
Call Admission

Section 6 Pager 18
4 iMCRA RAN model
6 19
Call Admission

Section 6 Pager 19
4 iMCRA RAN model
4.1 iMCRA: RAN Model

New UA7.0 parameter
Removed parameter
RNC
New/Update UA7.0 Object

UA6.x Object
NodeB
RadioAccessService
isRrcRedirectionInterFreq
FddCell
layerPreferredForR99
RrcRedirectionConfClass 0..6
InterFreqHhoFddCell
rrcRedirectionConfClassId
rrcRedirectionType
twinCellList
rrcRedirectOrigCellColourThreshold
isRedirectionBasedOnEstablishmentCause
isRedirectionForTrafficSegmentation
twinCellId
6 20
FrequencyAllocation 1..6
Call Admission

Section 6 Pager 20
dlFrequencyNumber
ulFrequencyNumber
faType
fddFrequencyUserLabel
5 iMCRA exercises
6 21
Call Admission

Section 6 Pager 21
5 iMCRA exercises
5.1 Exercise 1
Suggest the parameters values for the 3 different configuration strategies:
I.
II.
III.
Always perform redirection based on UE type and Establishement cause

Always perform redirection based on call type only
Perform redirection based on load only
Parameter
Value I.
Value II.
rrcRedirectionType
rrcRedirectOrigCellColourThresh
old
faType FDD1
faType FDD2
faType FDD3
6 22
Call Admission

Section 6 Pager 22
Value III.
5 iMCRA exercises
5.2 Exercise 2
R5 (HSDPA) UE
MO I/B
Config 1
Config 2
True
True
FDD1
rrcRedirectionType
capaAndEstCa
use
PreferredFa
FDD2
rrcRedirectOrigCellColour
Threshold
Yellow
Yellow
Cell Type
faType
FDD1 CellA
HSUPA
Data
FDD2 Cell B
HSUPA
Data
FDD3 Cell C
HSUPA
Other
FDD4 Cell D
R99
Data
FDD5 Cell E
R99
Other
FDD6 Cell F
R99
Conversational
FDD3
FDD4
FDD5
FDD6
Question: For both configuration scenarios determine which is the target cell
for the RRC Establishment.
6 23
Call Admission

Section 6 Pager 23
Module Summary

Benefits of intelligent Multi Carrier RRC Allocation
Redirection types
iMCRA capabilities
iMCRA algorithm types
iMCRA RAN model
6 24
Call Admission

Section 6 Pager 24


for this module
6 25
Call Admission

Section 6 Pager 25
End of Module
Module 1
6 26
Call Admission

Section 6 Pager 26
Last But One Page

1
@@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
@@COURSENAME - Page 2

HSxPA Algorithms Description

Uploaded by

Copyright:

Available Formats

HSxPA Algorithms Description

Uploaded by

Document Information

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

HSxPA Algorithms Description

Uploaded by

Copyright:

Available Formats

9300 WCDMA

TMO18256 9300 WCDMA UAO7

All Rights Reserved Alcatel-Lucent 2010

All rights reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

Terms of Use and Legal Notices

All rights reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

4. Topic/Section is Positioned Here

5. Topic/Section is Positioned Here

Module 1. HSUPA TMO18256

6. Topic/Section is Positioned Here

Module 1. Appendix TMO18256

7. Topic/Section is Positioned Here

2. Topic/Section is Positioned Here

Module 1. iMCRA TMO18256

3. Topic/Section is Positioned Here

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Course Outline [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

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

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Course Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

About this Student Guide

All Rights Reserved Alcatel-Lucent 2010

Where you can get further information

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

All Rights Reserved Alcatel-Lucent 2010

About this Student Guide [cont.]

Switch to notes view!

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

At the end of each

section you will be asked to fill this questionnaire

Surname, First name :

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Self-assessment of Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved Alcatel-Lucent 2010

Do not delete this graphic elements in here:

TMO18256 D0 SG DEN I1.0

All Rights Reserved Alcatel-Lucent 2010