W-Cdma Ua07 Hsxpa Algo - Tmo18256 D0sgdeni1.0

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
HSUPA
EmptyHSDPA
page
shared channel dedicated channel
TTI = 2 ms TTI = 10 ms or
TTI = 2 ms optinonal
Switch to notes view!
sf = 16 sf = 2 to 256
no pc pc
no sfho sho
2 All Rights Reserved © Alcatel-Lucent 2010

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

Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2010
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 Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.

Blank Page

9300 WCDMA

Course Outline
Section
About This1.Course
HSDPA
4. Topic/Section is Positioned Here
Module 1. HSDPA TMO18256
Course outline
Technical support
Section 2. HSUPA 5. Topic/Section is Positioned Here
Course objectives
Module 1. HSUPA TMO18256
Section 3. Appendix
1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here
Xxx Module 1. Appendix TMO18256
Xxx
Section 4. Glossary 7. Topic/Section is Positioned Here
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
Switch used
to notes in this guide
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

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

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

About this Student Guide [cont.]

9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?

Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Yes (or No (or

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

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

Instructional objectives Globally globally Comments
yes) no)

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


Do not delete this graphic elements in here:
11
Section 1
HSDPA 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

HSDPA Algorithms Description Module 1
9300 W-CDMA UA07 HSxPA Algorithms Description
Document History
Edition Date Author Remarks
01 2010-04-30 Elsner, Bernhard First edition

Charneau, Jean-Noël

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


Module Objectives [cont.]

9300 W-CDMA UA07 HSxPA Algorithms Description This page is left blank intentionally

Table of Contents
Page
1 HSDPA Activation 7
1.1 HSDPA Distributed Architecture 8
1.2 HSDPA Activation Flags 9
1.3 64 QAM On HSDPA Activation Flags 10
1.4 HSDPA Capable-UE Supported 11
1.5 H-BBU Resource Allocation 12
1.5.1 M-BBU Resource Allocation – xCEM case 13
1.5.2 Multiple xCEM per carrier 14
1.5.3 Parameters involved in CEM configuration 15
1.6 HSDPA/E-DCH Service Indicator broadcast 16
1.7 Transport Channel 17
1.8 Physical Channels 18
1.9 DL OVSF Code Tree 19
1.10 HSDPA Key Features 20
1.11 AMC Principles 21
1.12 UE Capabilities and Max Bit Rates 22
1.13 HARQ Types 23
1.14 Modulation Schemes 24
1.15 Constellation Rearrangement (16QAM) 25
1.16 64 QAM On HSDPA 26
1.17 Redundancy Version Parameters 27
1.18 Flexible RLC and MAC-ehs 28
1.19 HARQ Stop and Wait Principles 30
1.20 HARQ Mechanisms 31
1 1 5 1.21 Optimal Redundancy Version for HARQ retransmission
32
1.22
9300 W-CDMA UA07 Channel
HSxPA Algorithms Coding
Description : Recall 33
1.23 Selection of the Redundancy Version per HARQ process 34
1.24 Multi-RAB handling on HSDPA 35
1.25 Multi-RAB and GBR handling on HSDPA 36
1.26 User Services supported with HSDPA 37
2 HSDPA RRM 38
2.1 RAB Matching and CAC 39
2.2 HSDPA to DCH Fallback 40
2.3 Fair Sharing 41
2.3.1 Call Admission Control & Power Reservation 42
2.3.2 Call Admission Control & Codes Reservation 43
2.3.3 Fair Sharing - RAN Model 44
2.4 Initial Rate Capping during RB reconfiguration 45
2.4.1 Initial Rate Capping during RB reconfig: RAN Model 46
2.5 QoS Mapping 47
2.6 Scheduling Priority Indicator (SPI) 48
2.7 UE, QId and SPI 49
2.8 NodeB Scheduler 50
2.9 Dynamic Code Tree Management 51
2.9.1 HS-PDSCH OVSF Codes Allocation 52
2.9.2 HS-PDSCH Codes Preemption / Reallocation 53
2.9.3 DCTM – RNC RAN Model 54
2.9.4 DCTM – NodeB RAN Model 55
2.10 HSDPA DL Power Reservation at RNC 56
2.11 Dynamic PA Power Sharing R99/HSPA Carriers 57
2.11.1 Impact on DCH DL CAC and DL iRM 58
2.12 HSDPA DL Power Available at NodeB 59
2.13 HSDPA Power - RAN Model 60
2.14 HSDPA Power Distribution 61
2.15 HSDPA Full Power Usage 62

Table of Contents [cont.]
Page
2.16 HS-SCCH Power Control 63
2.17 HS-PDSCH Dynamic Power Allocation for 1st Transmission 64
2.18 UE Capabilities and Max Bit Rates 65
2.19 HSDPA Flexible Modulation 66
2.20 CQI Modification Principles 67
2.21 HS-DPCCH detection based on CQI 68
2.22 CQI adjustment based on BLER: blerRangeBasedAlgo 69
2.23 CQI adjustment based on BLER: OuterLoopLikeAlgorithm 70
2.24 CQI adjustment based on BLER: Dynamic BLER Adjustment 71
2.24.1 CQI adjustment based on BLER: Dynamic BLER Adjustment 72
2.25 HS-PDSCH Power Adaptation for Retransmissions 74
2.26 HS-DPCCH Power 75
2.27 Scheduler iCEM 76
2.27.1 Schedulers using Cost Function C1 only 77
2.27.2 Schedulers using Cost Functions C1 and C2: C1 78
2.27.3 Schedulers using Cost Functions C1 and C2: C2 79
2.27.4 C2 Parameters 80
2.28 Scheduler xCEM 85
2.28.1 SNR ESTIMATION FOR HS-PDSCH 86
2.28.2 TFRC SELECTION 87
2.28.3 TFRC SELECTION Summary 88
2.28.4 SPI management for GBR Mac-d flows 89
2.28.5 SPI management for non GBR Mac-d flows 90
2.28.6 SPI management 91
1 1 6 2.29 Scheduler: SPI management All Rights Reserved © Alcatel-Lucent 2010 92
2.30
9300 W-CDMA UA07 Dynamic MAC-d PDU size
HSxPA Algorithms Description 93
2.30.1 MAC-d PDU size 94
2.30.2 MAC PDU size Configuration 95
2.30.3 How to configure a Mac-d PDU size of 656 bits 96
2.30.4 MAC-d PDU size Selection 97
2.30.5 MAC-PDU size : Mobility HSDPA-HSDPA 98
2.30.6 MAC-PDU size : Mobility HSDPA - R99 101
2.30.7 MAC-PDU size : Mobility Over Iur 102
2.30.8 Mac-d PDU size reconfiguration 104
2.31 Transport Block Size Optimization: CQI 1 to 15, all UE cat. 105
2.32 High Quality UL R99 RAB for High HSDPA DL Rate - Issue 106
2.32.1 UA05.1 Solution 107
2.32.2 UA06 Solution 108
2.33 Always On for HSDPA/DCH: Mono-Service PS / Mono-RAB 109
2.34 Always On for HSDPA/DCH: Multi-Service PS / Multi-RAB PS 110
3 HSDPA Mobility 111
3.1 3G->2G HHO 112
3.2 3G->3G Intra-RNC Inter-freq HHO 113
3.3 3G->3G Inter-RNC Inter-freq HHO 114
3.4 HSDPA over Iur 115
3.4.1 64-QAM over Iur: Not Supported 116
3.4.2 Iub Bandwidth Management 117

1 HSDPA Activation


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

HS-DSCH HS-DSCH
RLC RLC
New MAC-ehs Layer
MAC-d MAC-d
Replaces MAC-hs
HS-DSCH Flow control HS-DSCH
MAC-ehs MAC-ehs FP FP
L2 L2
PHY Uu PHY L1 Iub L1
UE NodeB RNC
HSDPA is an increment on UTRAN procedures, and is fully compatible with R4 layer 1 and layer 2. It is based
on the introduction of a new MAC entity (MAC-hs) in the Node B, that is in charge of scheduling / repeating
the data on a new physical channel (HS-DSCH) shared between all users. MAC-hs has been replaced by MAC-
ehs in UA07!
This has a minor impact on network architecture. There is no impact on RLC protocol and HSDPA is
compatible with all transport options (AAL2 and IP).
On the Node B side, MAC-ehs layer provides the following functionalities:
Fast repetition layer handled by HARQ processes
Adaptive Modulation and Coding
New transport channel High Speed Downlink Shared Channel (HS-DSCH)
Flow control procedure to manage Node B buffering
Some new L1 new functionalities are introduced compared to R4:

3 new physical channels: HS-PDSCH to send DL data, HS-SCCH to send DL control information relative
to HS-PDSCH, and HS-DPCCH to receive UL control information
New channel coding chain for HS-DSCH transport channel and HS-SCCH physical channel
In UA07 the following new 3GPP R7 features have been introduced:

Flexible RLC: instead of using fixed RLC PDU sizes (320 bits or 640 bits), the size of a RLC PDU can vary.
The maximum size is determined by the RNC based on the data rate offered over the radio. The size can
vary during the transfer.
MAC-ehs: enhanced MAC-hs layer that brings several enhancements and simplifications:
It allows coping with MAC-d PDU of different sizes
It brings the capability to segment MAC-d PDUs
64-QAM requires Mac-ehs

1 HSDPA Activation
1.2 HSDPA Activation Flags
RNC
NodeB BTSEquipment RadioAccessService UmtsNeighboring
FddCell BTSCell RemoteFDDCell
hsdpaActivation hsdpaResourceActivation 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 is64QamAllowedForUeCategory
= capable?
UE 64QAM (HsdpaRncConf)
YES
NO
NodeB 64 QAM Activated?
YES
NO
UE CAT 64-QAM Eligible?
YES
Node B 64-QAM Eligible QPSK / 16-QAM
1 1 10 All Rights Reserved © Alcatel-Lucent 2010

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
doesn’t use this IE but the HS-DSCH physical layer category IE, corresponding to the HS-DSCH category
supported by the UE when MAC-ehs is not configured)
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
TTI # (3*2 MS)
1.4 HSDPA Capable-UE Supported
slide + notes
HS-DSCH Category HS-PDSCH Max Number Inter-TTI Min Interval Modulation Max Peakupdated
Rate
Category 1 5 3 QPSK & 16-QAM 1.2 Mbps
Category 11 5 2 QPSK only 0.9 Mbps
Category 12 5 1 QPSK only 1.8 Mbps
• QPSK mandatory for HSDPA capable UE

• 16/64QAM optional

Twelve categories have been specified by Release 5 for HSDPA UEs according to the value of several
parameters among which are the following:
Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15)
Minimum inter-TTI interval, which defines the minimum time between the beginning of two
consecutive transmissions to this UE. If the inter-TTI interval is one, this means that the UE can
receive HS-DSCH packets during consecutive TTIs, i.e. every 2 ms. If the inter-TTI interval is two,
the scheduler needs to skip one TTI between consecutive transmissions to this UE.
Supported modulations (QPSK only or both QPSK and 16QAM/64QAM)
Maximum peak data rates at the physical layer (number of HS-DSCH codes x number of bits per HS-
DSCH / Inter-TTI interval).
These twelve categories provide a much more coherent set of capabilities as compared to R99 which gives
UE manufacturers freedom to use completely typical combinations.
New UE categories have been introduced to support the 64QAM and MAC-ehs:
- 13 and 14 (64-QAM only),
- 17 and 18 (64-QAM or MIMO).
Note that MIMO is not supported in UA07.

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

1 HSDPA Activation
1.5 H-BBU Resource Allocation
– iCEM case BTSEquipment
UL
HS-DPCCH MAC-hs BTSCell
• HARQ
DL
• Scheduler
HS-DPDCH(s)
HS-SCCH(s) • Link Adaptation (AMC) HsdpaConf
HsdpaResourceId
BTS
H-BBU
iCEM128
H-BBU
iTRM MCPA DDM
H-BBU
iCEM128
D-BBU
H-BBU
iCCM iTRM MCPA DDM
DONT SUPPORT iCEM64
HSDPA
D-BBU
iCEM128
D-BBU iTRM MCPA DDM
D-BBU
CEMa
D-BBU
Digital Shelf Radio Shelf

PHASED OUT
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
notes
updated
xCEM
BTSEquipment
64CE BBU
BBU BBU
BBU UA
05
DCH DCH
DCH
DCH
xCEM HsXpaResource
BBU
BBU BBU
BBU
BBU BBU
HSDPA
BBU
HSUPA BBU
HSDPA HSUPA
DCH DCH
DCH
DCH
THE SUPPORTED
BBU
BBU BBU
BBU NOW
HSDPA HSDPA
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
xCEM
BBU
BBU BBU
BBU
Multimode Multimode
Multimode – DPCCH, DPDCH
Multimode
(DCH + SRB + CCH)
– all HSDPA channels
BBU
BBU BBU
BBU – all HSUPA channels
Multimode Multimode
Multimode
Multimode

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

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

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

The xCEM board has been introduced with the configuration rule that HSPA baseband resources for one
carrier cannot be shared across xCEM. R99 traffic is however allocated in load balancing. This feature
introduces new HSPA high capacity Node B baseband configurations including up to 3 xCEM per carrier.
HSxPA baseband resources for each a cell (HSDPA/HSUPA schedulers, encoding and decoding MAC and radio
resources) are still processed on the same board. However the HSPA resources of the cells belonging to
the same carrier can be distributed on different boards.
R99 traffic can still be allocated in a load balancing fashion as in previous release independently of the
HSPA resource location.
The operator has the possibility to configure HSPA resource (group of several HSPA cells) and the mapping
to the configured xCEM. Each group can be configured with a weight influencing the HSPA resource re-
configuration in case of missing board. The resource assignment algorithm can then take the expected
traffic load of a given cell (configured weight) into account and avoid as much as possible the
combination of 2 cells with heavy load on the same board.
In case of multiple xCEM per carrier, iCEM mixture is not supported. Moreover, in case of iCCM, a maximum
of 3 xCEM per Node B can be supported.
The feature allows to guaranty that sufficient baseband processing capacity can be used to target very high
HSDPA data rate (e.g. with 64QAM) in highly loaded sites with high probability of concurrent traffic in all
sectors. It also allows higher HSDPA capacity for sites with more than 3 sectors.

1.5.3 Parameters involved in CEM configuration
slide
BTSEquipment updated
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
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
notes
updated
isHsxpaServiceIndicatorEnabled
(RadioAccessService)
RNC RNC LEV
SIB5 SIB5
NodeB NodeB
non HSDPA
HSDPA cell
cell
HSDPA UE Auto hsdpaServiceIndicatorMethod Auto HSDPA UE

edchServiceIndicatorMethod
(FDDCell)
BTS LEV
HSDPA HSDPA
OK! 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 E-
DCH)) is not operational on the corresponding cell.
Auto: the ‘hsdpaServiceIndicator’ (or respectively the ‘edchServiceIndicator’) information is
broadcasted to the UE indicating the current state of the corresponding service: HSDPA_CAPABLE if
service is operational, HSDPA_NOT_CAPABLE otherwise (or respectively EDCH_CAPABLE if service is
operational, EDCH_NOT_CAPABLE otherwise)

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

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

In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on the DPDCH (Dedicated
Physical Data CHannel). In HSDPA, downlink data are sent on a HS-DSCH (High Speed – Downlink Shared
CHannel) which is mapped on one or several HS-PDSCH (High Speed – Physical Downlink Shared CHannel).
Users are multiplexed on the HS-DSCH channel in time and code. Transmission is based on shorter sub-
frames of 2ms (TTI) instead of 10ms in R99. A HS-PDSCH corresponds to one channelization code of fixed
spreading factor SF=16 from the set of channelization codes reserved for HS-DSCH transmission.
In downlink, the HS-PDSCH are transmitted with the HS-SCCH (High Speed – Shared Control CHannel)
channel. This channel is broadcasted over the cell but his information concerned only the user who has to
receive the HS-PDSCH. The HS-SCCH allows the user to know if the HS-PDSCH is for him and to decode them
correctly. The HS-SCCH is a fixed rate (60 kbps, SF=128) downlink physical channel used to carry downlink
signaling related to HS-DSCH transmission.
Radio conditions information and acknowledgement are reported by the UE to the NodeB through the HS-
DPCCH channel. This channel allows the NodeB to adapt the downlink data rate and to manage
retransmission process. The HS-DPCCH is divided in two parts. The first one is the Channel Quality Indicator
(CQI) which is a value between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30
= good radio conditions). The second one is the acknowledgement information: if data are well received by
the UE, the UE sends to the NodeB an Ack, otherwise a Nack.

1 HSDPA Activation
1.9 DL OVSF Code Tree
SF128
SF256
SF16
SF32
SF64
SF4
SF8
0 Common channels (including S-CCPCH/1)
0
0
1 4 S-CCPCH/0
0
2 2
1 S-CCPCH/2
3
1 5 STATIC
4 6 Allocation
2
5 3 HS-SCCH
1
6 4 CODES
7
3 SHARED FOR TTI
7
DYNAMIC
2 SEC
8
4 Allocation
9 Free OVSF codes
2 numberOfHsScchCodes
10
5
11
12
STATIC or DYNAMIC
6 Allocation
13 HS-PDSCH
3
numberOfHsPdschCodes
14
7
15
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
slide
updated
RNC Capacity Request Capacity Allocation

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

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

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
1.12 UE Capabilities and Max Bit Rates
notes
updated
Category 6 UE CQI Mapping Table
CQI Value HS-PDSCH Number RLC Throughput Modulation
0 out of range
S oft CQI vs C/I - P edes trian_a 1 RX
1 1 0 kbps QPSK 25
2 1 0 kbps QPSK
3 1 0 kbps QPSK
4 1 0 kbps QPSK
5 1 144 kbps QPSK
20
6 1 144 kbps QPSK
7 2 144 kbps QPSK
s oftCQI
8 2 288 kbps QPSK
9 2 288 kbps QPSK
10 3 432 kbps QPSK 15
11 3 576 kbps QPSK

12 3 720 kbps QPSK
13 4 864 kbps QPSK
14 4 1008 kbps QPSK
10
15 5 1296 kbps QPSK -10 -8 -6 -4 -2 0 2 4 6 8 10
C/I (dB)
16 5 1440 kbps 16-QAM
... ... ... ...
29 5 3024 kbps 16-QAM
30 5 3024 kbps 16-QAM
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 HS-
DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The NodeB takes this input
into consideration in order to adapt the throughput to the UE.
Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.

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

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
1010 1000 0000 0010

10 00
I
I
1110 1100 0100 0110
11 01
1111 1101 0101 0111

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

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 Q
1011 1001 0001 0011 1110 0110 0100 1100
1010 1000 0000 0010 1010 0010 0000 1000
b=0 b=1
I I
1110 1100 0100 0110 1011 0011 0001 1001
1111 1101 0101 0111 1111 0111 0101 1101
Q Q
1000 1010 0010 0000 0010 1010 1000 0000
1001 1011 0011 0001 0110 1110 1100 0100
b=2 b=3
I I
1101 1111 0111 0101 0111 1111 1101 0101
1100 1110 0110 0100 0011 1011 1001 0001

This function only applies to 16 QAM modulated bits. In case of QPSK it is transparent. The following table
describes the operations that produce the different constellation versions.
The input bit sequence is composed of a set of four consecutive bits nk, nk+1, nk+2, nk+3 (with k mod 4 = 0).
b Output bit sequence Operation
0 nk, nk+1, nk+2, nk+3 none
1 nk+2, nk+3, nk, nk+1 swapping MSBs with LSBs
2 nk, nk+1, nk+2, nk+3 inversion of the logical values of LSBs
3 nk+2, nk+3, nk, nk+1 swapping MSBs with LSBs & LSBs values inversion

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

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

1 New UE categories supporting the 64QAM are introduced.
2 New CQI mapping tables is introduced allowing higher Transport Blocks (TB) by using 64QAM modulation
3 New Look Up Tables are used to allow scheduler selecting the higher TB size for 64QAM modulation
format.
4 New format for the HS-SCCH is defined allowing to indicate any of the 3 modulation schemes (QPSK,
16QAM and 64QAM) used on the HS-PDSCH in the current TTI.
5 New slot format for the HS-PDSCH is defined with 960 bits/slot.
6 Mac-ehs has to be configured in order to allow the usage of 64QAM because the selection of the
modulation scheme is done in the MAC-ehs as part of the Transport Format Resource Combination (TFRC)
selection function (Note that the MAC-ehs can be configured by the RNC without allowing the usage of
64QAM).
New UE categories have been introduced to support the 64QAM :-13 and 14 (64-QAM only), -17 and 18 (64-
QAM or MIMO). These UE categories are MAC-ehs capable MIMO is not supported in UA07.

SYSTYMATIC
BITS (S) CONSTLATION REARRANGMENT
1 HSDPA Activation
FOR THE TURBO CODING
1.17 Redundancy Version Parameters
Kmax
RV Coding MIR RV Update Table
16QAM XRV s r b QPSK XRV s r k 0 1 2 3 4 5 6 7
0 1 0 0 0 1 0 QPSK XRV 0 2 5 6 1 3 4 7
1 0 0 0 1 0 0
16QAM XRV 6 2 1 5 0 3 4 7
2 1 1 1 2 1 1
3 0 1 1 3 0 1
TRV[k]
4 1 0 1 4 1 2
5 1 0 2 5 0 2 RV Update
6 1 0 3 6 1 3
7 1 1 0 7 0 3 YES XRV=TRV[0]
New Tx?
k=0
NO
Kmax
PIR RV Update Table YES

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

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 new
The RLC SDU

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

MAC-d PDU the result of the TRFC
selection algorithm. A non
negligible number of
padding bits may be
MAC-hs
MAC-hs PDU header MAC-hs SDU Pad. required to fit the
Transport Block Size.
Transport Block Size (based on TRFC selection)
In case of very bad radio

condition, the selected
Transport Block Size may
be too small to contain a
fixed-size MAC-d PDU: the
UE is not scheduled
•
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.] new
No need for padding

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

(=MAC-ehs SDU)
Reordering SDU2
MAC-ehs
Pad-
MAC-ehs header
header ReorderingSDU 1 MAC-ehs ……
PDU 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
•
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
TB1 HARQ
Update RV Parameters
TB2 HARQ
Transmit Data
HSDSCH
Wait for ACK/NACK Reception
Insert DTX
ACK ACK/NACK/DTX? DTX
Indication
NACK
Reset & Free ACK/NACK

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

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
notes
updated
Ack Data 1 RV0 RV1 RV2
Data 1 Process 0
Nack Data 2
Process 1
Data 2 Ack Data 3 Process 2
Process 3
Data 3 Ack Data 4
Data 4
Transmissions
Ack Data 5 To next step
Data 5 Nack Data 2 (demultiplexing)
combining
Data 2 Nack Data 6 Data 1
Data 6 Ack/nack Ack Data 3

Data 7
Data 7 Ack Data 4
Data 8
Data 8 Ack Data 5
Data 2
Data 2 Ack Data 7
Data 6
Data 6 Ack Data 8
Data 9 combining
Data 9 Ack Data 2
Data 10
Data 10 Ack Data 6
Data 11
Data 11 Ack Data 9
Data 12
Data 12 Ack Data 10
Data 13
Data 13 Data 11
Data 12
Data 13
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
if = drType or DRWithPowerAdaptation
(hsdpaConf)
k 0 1 2 3 4 5
First RTx? PIR QPSK XRV 0 2 4 6
16QAM XRV 6 2 5 0 4 7
YES
k 0 1 2 3 4
FIR QPSK XRV 0 5 1 3 7
16QAM XRV 6 1 3
Dynamic
RV Table
Selection
k 0 1 2 3
CC+CoRe
16QAM XRV 6 5 0 4
maximum number of bits per HARQ

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

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 Virtual Second Rate

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

bits RM P1_1 RM P1_2
Data Coding Modulation
1/3
Parity 2 NP1
bits RM P2_1 RM P2_2
NIR
NRM1 NDATA
NPUNC2
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
No Use RV tables of HARQ type

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

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

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
isMultiRabOnHsdpaAllowed (RadioAccessService)
updated
enabledForRabMatching (multi-RAB DlUserService)
enabledForRabMatching (multi-RAB UlUserService)
isGbrOnHsdpaAllowed (RadioAccessService)
cmCH-PI 6
cmCH-PI 4
cmCH-PI 4
cmCH-PI 6
GBR QIx priority
UEN
RNC
>
Core Network Non GBR QIy priority UE0
PDU flow0
PDU flow0
PDU flow1
CID m
CID l
CID n
If not All GBR flows satisfied
Higher SPI and smaller GBR served first

QI0 QI0 QI1 QI2
NodeB
SP4 SP6 SP4 SP6
Streaming, Interactive, Background

HS-DSCH
DCH 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

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


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

Capacity
YES
hsdpaNumberUserCapacityLicensing
HSDPA RAB R99 RAB
HSDPA CAC
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 DCH RB
established 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. 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 « HS-DSCH required power » for GBR (PS Str) + minBr (PS I/B)
False « HS-DSCH required power » for minBR (PS I/B)
GBR On GBR info sent to NodeB (GBR or minBR)
hsdschReqPwFilterCoeff
FS On « HS-DSCH required power » hsdschReqPwReportingPeriod
(NBAPMeasurement)
hsdpaCodeTreeManagementActivation
(BTSEquipment)
OVSF I/B MinBR
STR GBR
TC/ARP/THP isHsxpaR99ResourcesSharingOnCellAllowed
Used DlPowerSelfTuningForPsIbOnHsdpaEnabled
(FDDCell)
NodeB dynamic OVSF codes management:

HSDPA RNC
Power CAC Monitor the DL OVSF code tree occupancy
Used Determine the codes available for HS-
PDSCH scheduling
Initial Radio Resources
(power, codes)
Reconfigure the H-BBU accordingly via a
new internal message
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
STR GBR
TC/ARP/THP
Min(RANAP MBR)
minBrForHsdpa
RANAP GBR
HSDPA RNC
CAC (Power)
Ps I/B
Traffic Power Ps Str
(SHO reserved)
dlTxPowerEstimation*
x
fair bitrate
x
Traffic
P traffic admission Pres
Power initialActivityFactorForIb
Pused
R99 used
+
Overhead HSDPA Required Power (GBR)
Power +
(CCC+OCNS
HSDPA Reserved Power (non GBR
+ E-DCH)
with minBR)
(*) is an power relative to P-CPICH power

Fair Bitrate
For streaming services, this fair bitrate is derived from RANAP GBR (including radio protocols overheads).
For I/B services, the fair bitrate is given by the parameter minBrForHsdpa, offering a differentiation per
OLS (in fact ARP, THP and Traffic Class).
If the minBrForHsdpa is above RANAP MBR then the minBrForHsdpa for this RAB is “downgraded” to the
MBR.
For minBrForHsdpa = 0, the operator can choose to reserve a minimum amount of resources defined by the
parameter minHsDschReservationForCac.
Power reservation: At admission, power is reserved for each RB mapped on HS-DSCH. The reservation is
done or updated each time a MAC-d flow is setup, deleted or reconfigured or on mobility of the serving HS-
DSCH cell.
The power to reserve for this HS-DSCH RAB is 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
minHsDschReservationForCac
minBrForHsdpa ≠ 0 or
if minBrForHsdpa = 0
I/B MinBR
STR GBR
TC/ARP/THP
HSDPA RNC
CAC (Codes) x reservationFactorOnCodesForGbrTraffic
x initialActivityFactorForIb
minBR > 0
For UE category 11 and 12: 1..15

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

Nb of SF16 codes = fair bitrate / ovsfCodesThroughput16QamUe

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 FDDCell Parameter for ‘GBR on HSDPA’ in UA06.0
isHsxpaR99ResourcesSharingOnCellAllowed Parameter for ‘Fair Sharing’ in UA06.0

isDlPowerSelfTuningForPsIbOnHsdpaEnabled
hsxpaR99ResourcesSharingId
RadioAccessService
isGbrOnHsdpaAllowed
isMultiServiceWithDchStrAndHsDschIbAllowed
TrafficClassBasedQos ArpBasedQos ThpBasedQosl

minBrForHsdpa
DedicatedConf MeasurmentConfClass NBAPMeasurment

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


2 HSDPA RRM
2.4 Initial Rate Capping during RB reconfiguration 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
= True New set of capping parameters
maxDlEstablishmentRate maxUlEstablishmentRate
(CacConfClass) (CacConfClass)
A parameter for each scenario and direction (UL/DL):
• Always-On Capping: Cell_FACH or PCH state to Cell_DCH
• Fallback Capping: HSDPA/HSUPA to DCH/DCH or to HSDPA/DCH

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

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

2.4 Initial Rate Capping during RB reconfiguration
2.4.1 RAN Model new
RAS
DedicatedConf/CacConfClass DchRateCapping
•maxDlRateHsdpaAndDchToDchAndDch
•maxDlRateHsdpaAndEdchToDchAndDch
•maxDlEstablishmentRbRate
•maxDlRateRabEstablishDchAndDch
•maxUlEstablishmentRbRate
•maxDlRateTransitionToDchDlTriggerDchAndDch
•maxDlRateTransitionToDchUlTriggerDchAndDch
•maxUlRateHsdpaAndDchToDchAndDch
•maxUlRateHsdpaAndEdchToDchAndDch
•maxUlRateHsdpaAndEdchToHsdpaAndDch
•maxUlRateRabEstablishDchAndDch
•isOamCappingOfDataAllowed
•maxUlRateRabEstablishHsdpaAndDch
•isUlRbRateAdaptationAllowed
•maxUlRateTransitionToDchDlTriggerDchAndDch
•isDlRbRateAdaptationAllowed
•maxUlRateTransitionToDchDlTriggerHsdpaAndDch
•maxUlRateTransitionToDchUlTriggerDchAndDch
•maxUlRateTransitionToDchUlTriggerHsdpaAndDch

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
=> emails • Privileged
users
• Web Browsing
• Video Streaming
3GPP
TC: Traffic Class OLS: Olympic Level Service (gold, silver,bronze)

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

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

2 HSDPA RRM
2.6 Scheduling Priority Indicator (SPI)
slide
From Used as inputs to RRM algorithms to OLS: updated
From RAB Request • Used as input to iRM Tables & AO
RAB assignment provide user QoS differentiation • Subscriber Differentiation
assignment Request
MLP:
Traffic ARP THP OLS MLP SPI • Used to prioritize the different PS I/B RABs assigned
to the same user (at the MAC layer).
class
• Service Differentiation
Streaming 1 N/A Gold N/A 15
SPI:
Streaming 2 N/A Silver N/A 14 • Derived SPI is provided by the RNC to the BTS per
MAC-d for MAC-(e)hs prioritization in the HSDPA
Streaming 3 N/A Bronze N/A 13 scheduler
• Subscriber Differentiation
Interactive 1 1 Gold 8 12
Interactive 1 2 Gold 7 11
Interactive 1 3 Gold 6 10 RadioAccessService
Interactive 2 1 Silver 5 9
Interactive 2 2 Silver 4 8 TrafficClassBasedQos0..3
Interactive 2 3 Silver 3 7
Interactive 3 1 Bronze 2 6 iuPriorityLevel
Interactive 3 2 Bronze 2 5 ArpBasedQos 3
Interactive 3 3 Bronze 2 4
iuThp ThpBasedQos 3
Background 1 N/A Gold 1 3
mlp
Background 2 N/A Silver 1 2 ols
Background 3 N/A Bronze 1 1 spi
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
UE0 UEN
cmCH-PI 4
cmCH-PI 6
cmCH-PI 4
cmCH-PI 6
RNC
PDU flow0
PDU flow0
PDU flow1
CID m
CID n
CID l
QI0 QI0 QI1 QI2

NodeB
SP4 SP6 SP4 SP6

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 QIdK QIdN

available codes
available power
UE capabilities
ACK/NACK/CQI HARQ
Compressed Mode information
Min COST value
UE HSDPA synchronisation state
COST = f(C1, C2)
C1 = f(Scheduler Type)
C2 = f(SPI, CQI, UE Category)
NodeB Scheduler

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

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
notes
RNC
updated
SF4
free
SF8 RadioAccessService
SF16
SF32
HS-PDSCH
HsdpaCellClass
SF64
SF128 cmCH numberOfHsPdschCodes

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

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
FREE CODES threshCodesToTriggerReallocation
numCodesForDchAfterReallocation
numCodesForDchAfterStealing
threshCodesToTriggerStealing
time
Number of HS-PDSCH codes HS-PDSCH HS-PDSCH HS-PDSCH
preemption preemption reallocation
maxNumberOfHsPdschCodes
minNumberOfHsPdschCodes
time

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
HsdpaCellClass hsdpaCellClassId hsdpaResource
isCellHsPdschDynamicManagementActive
HsPdschDynamicManagement
minNumberOfHsPdschCodes maxNumberOfHsPdschCodes
numCodesForDchAfterReallocation numCodesForDchAfterStealing
threshCodesToTriggerReallocation threshCodesToTriggerStealing
spreadingFactorLevelForOvsfMonitoring 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
hsdpaCodeTreeManagementActivation
BTSCell
HsdpaConf HsdschServiceParameterSet
iCEM xCEM
hsdpaGbrNbNeededTtiForgettingFactor Used by serviceFilterFactor
hsdpaGbrNbUePerTtiForgettingFactor MAC-(e)hs scheduler serviceHighRate
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi 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
RNC
RadioAccessService PMaxCell
SHO margin
HsdpaCellClass
PmaxHspa
PminHsdpa
minimumPowerForHsdpa
OCNS (opt.)
PminHsdpa = CCCRNC
PMaxCell - minimumPowerForHsdpa
<unset> PmaxHspa =
when Fair Sharing is enabled 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 E-
HICH Total Power » IE in the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message as
Pmaxcell – maxHspaPowerOffset.
if maxHspaPowerOffset =0, the Node B can use all the available remaining power for HSDPA
transmission
if maxHspaPowerOffset >0, the operator has the ability to reserve an amount of power
which cannot be used by HSDPA

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

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

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 Dynamic PA Power Sharing R99/HSPA Carriers
2.11.1 Impact on DCH DL CAC and DL iRM
100%
paRatio (F2)
paRatio (F2)
HSDPA UA06
HSDPA P traffic (F2)
= (Max Tx Power (F2) – Min Pw Hsdpa (F2))
PA Power Ratio
GBR,
/ (1+ paOverbookingRatio
paOverbookingRatio /100)
R99
Fixed - P CCC (F2) x Activity Factor Cch
activityFactorCcch
partitioning GBR, – P E-DCH - P OCNS
Power
paRatio (F1)
R99
paRatio (F1)
not used
P_traffic
R99 R99
= Max (R99+HSDPA) traffic allowed
0%
UA05
P traffic(F2)
= Max TxPower(F2)
– Min Pw Hsdpa(F2)
- P CCC(F2) x Activity Factor Cch
- P E-DCH-P OCNS

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

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 FDDCell
isPowerPoolingActivated
activityFactorCcch
HsdpaCellClass EdchCellClass
minimumPowerForHsdpa eagchErgchEhichTotalPower
maxHspaPowerOffset
paOverbookingRatio
BTSEquipment Class2CellReconfParams
paPoolingActivation maxTxPowerPerOls
Class3CellReconfParams
BTSCell maxTxPowerPerOls
paRatio
PaResource
HsdpaConf
dchPowerMargin maxPowerAmplification


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

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
iCEM Activation* : updated
hsdpaFullPowerUsage
(HSDPAConf)
Raw HS-DSCH power

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

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

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

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

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
RLC
∆ALU CQI = ∆ dB Throughput Available
Power
NO
OK
RadioAccessService
PHS-DSCH = PP-CPICH + Γ + ∆(CQI)
HsdpaUserService measurementPowerOffset
∆ 3GPP(CQI, UEcategory) + ∆ ALU(CQIselected - CQIreported)

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
2.18 UE Capabilities and Max Bit Rates
Category 6 UE CQI Mapping Table
CQI Value HS-PDSCH Number RLC Throughput Modulation
0 out of range
1 1 0 kbps QPSK
2 1 0 kbps QPSK S oft CQ I vs C/I - P e de s tria n_a 1 RX

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

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

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

30 5 3024 kbps 16-QAM

The maximum achievable data rate depends on the UE category but also on the instantaneous radio
conditions it is exposed to. Each UE category has therefore a reference table specifying the supported
combinations between the reported CQI values, the number of codes and the radio modulation (QPSK or
16/64-QAM).
Instantaneous radio channel conditions are known at the UTRAN level thanks to the periodical decoding of
the Channel Quality Indicator sent by the UE to the NodeB onto the HS-DPCCH. The UE first estimates the
Carrier over Interference ratio (C/I). From this estimate the UE then determines a CQI (with a maximum HS-
DSCH BLER target of 10%) and then it sends this indication back to the NodeB. The NodeB takes this input
into consideration in order to adapt the throughput to the UE.
Note: a UE reporting a CQI value of 0 is not scheduled by the NodeB.

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

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

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
CQIreported on first transmission
CQI adjustment based on BLER
CQIprocessed
Scheduler
CQI update due to:

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

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
NO YES
N successive
CQI detected?
M successive
NO
DTX detected?
YES
HSD_IN_SYNC
N=M=2
UE scheduled
(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
2.22 CQI adjustment based on BLER: blerRangeBasedAlgo
bufferSize
nackNbMin hsdpaCqiBLERAdjustmentAlgo = blerRangeBasedAlgo
bufferSize
nackNbMax
(HsdpaConf)
(static)
1 2 buffer is full
3
AC K 4
ACK
AC CK
NA
K NbNACK <= Yes
CQIprocessed = CQIreported+1
nackNbMin ?
1st Transmission No
ACK/NACK
Buffer
NbNACK > Yes
CQIprocessed = CQIreported-1
nackNbMax ?
No
empty the buffer

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
0 #CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
NACK NACK ACK

DeltaCqiCur
0 #CQIreported
- hsdpaBLERStepSiz
e hsdpaBLERTargetUpperLimit
-5
hsdpaBLERStepSiz x
e 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.
That’s why UA4.2 algo is recommended because his performances are good in most cases.
hsdpaBLERTargetUpperLimit: defines the expected BLER target
hsdpaBLERObservationWindow: corresponds to the update period of the CQI offset
hsdpaBLERStepSize: it corresponds to the step applied upon reception of NACK. In case of ACK, the step is
a function of this parameter and of the BLER target.
All these parameters are defined per BTSEquipment -> BTSCell -> HsdpaConf object.

2 HSDPA RRM
2.24 CQI adjustment based on BLER: Dynamic BLER
Adjustment
hsdpaCqiBLERAdjustmentAlgo = dynamicOuterLoopAlgo
DeltaCqi
DeltaCqicur
0 #CQIreported
DeltaCqicur
DeltaCqicur
hsdpaBLERObservationWindow
DeltaCqiCur
+5
NACK NACK ACK

DeltaCqiCur
0 #CQIreported
- hsdpaBLERStepSi
ze hsdpaBLERStepSi x hsdpaBLERTargetXXLi
upStepXXBLERTarget = ze mit
-5 100 - hsdpaBLERTargetXXLimit
Low Medium High

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 CQI adjustment based on BLER: Dynamic BLER Adjustment
2.24.1 CQI adjustment based on BLER: Dynamic BLER
Adjustment
Start
Nack DTX
Ack/Nack?
Ack End
hsdpaAdjustBLERToChannelVariation
deltaCqiCur -= downStep
ueSpeed ≤ ueSpeedThd
Yes And No
adjustToChVar = True
Or
cqiAverage ≥ cqiThdHigh
deltaCqiCur += upStepLowBLERTarget Yes No

cqiThdLow < cqiAverage
deltaCqiCur += upStepMediumBLERTarget deltaCqiCur += upStepHighBLERTarget

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

2.24 CQI adjustment based on BLER: Dynamic BLER Adjustment
2.24.1 CQI adjustment based on BLER: Dynamic BLER
Adjustment [cont.]
hsdpaCqiBLERAdjustmentAlgorithmXcem
constBLERTarget
dynamicHarqTxTarget
outerLoopLikeAlgo algorithm
UE is Scheduled hsdpaBLERTargetUpperLimitXcem
Transmit Data See Previous Slide
Insert DTX
Indication
NACK
Reset & Free

HARQ Process Nret = Nret + 1
YES 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)

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
OVSFd βd
DPDCH x x
∑ I
RNC
Modulation
OVSFc βc
DPCCH x x RadioAccessService
HS-DPCCH
OVSFhs
x
βhs
x
∑ Q
HsdpaUserService
βhs NACK
βhs CQI ackPowerOffset
βhs ACK cqiPowerOffset
NACK
βc CQI nackPowerOffset
ACK
DPCCH

Radio conditions information and acknowledgements are reported by the UE to the Node B through the HS-
DPCCH channel. This channel allows the Node B to adapt the downlink data rate and to manage
retransmission process. The HS-DPCCH is divided in two parts. The first one is the Channel Quality Indicator
(CQI) which is a value between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30
= good radio conditions). The second one is the acknowledgement information: if data are well received by
the UE, the UE sends to the Node B an Ack, otherwise a Nack.
The HS-DPCCH BLER should be low enough to ensure correct HS-DSCH transmission. A correct demodulation
of CQI ensures suitable transport block transmission. A correct ACK/NACK demodulation ensures a good H-
ARQ efficiency.
The power allocated to the HS-DPCCH is derived from the power of the associated DPCCH taking into
account three specific power offsets. These power offsets should not be set too high in order not to impact
the uplink coverage and capacity.
Offset values are sent to the UE via RRC signaling. These signaled values correspond to predefined (3GPP
standards) quantized amplitude ratios 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 Min COST value
COST = C1 = C1 = C1 = γ x C1 x C2 = α*C1+β*C2
UE #0 UE #1 UE #N
• power • power • power
• codes • codes • codes
• number of bits • number of bits • 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

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
2.27.2 Schedulers using Cost Functions C1 and C2: C1
CLASSICAL PROPORTIONAL FAIR
to favor mobiles that report a high CQI versus their averaged CQI to
Goal
take benefit from instantaneous good radio conditions vs average
conditions
Cost function C1 C1T = CQIavT / CQIinstT

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

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
2.27.3 Schedulers using Cost Functions C1 and C2: C2
C2 = f(N_bits_transmitted, SPI weight, average CQI)
TC CQIAV
C2
CQIAV TC
SPI QIdN
ARP THP SPI
QIdM
ARP THP
WEIGHT TBSAV
TBSAV WEIGHT
THROUGHPUTN
THROUGHPUTM

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
HsdpaConf hsdpaSpiRelativeWeight
hsdpaUeCategoryThroughputWeighting ueCategoryProportionality
ueCategoryEquity
Th(QId1) Weight[SPI(QId1)] TBS[CQIav(QId1)]
= x
Th(QId2 ) Weight[SPI(QId2)] TBS[CQIav(QId2)]
Th(QId1) Weight[SPI(QId1)] TBScat12[CQIav(QId1)]

= x
Th(QId2) Weight[SPI(QId2)] TBScat12 [CQIav(QId2)]

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
QId0 QId1 QId2 QId3

Retransmissions First
New Transmissions
hsdpaSchedulerAlgorithm
(HsdpaConf)
Min COST value

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

Exercise
Define the SPI value for each Qid
Assuming hsdpaSchedulerAlgorithm = Round Robin, find which UE is scheduled
at each TTI: Cost
SPI QId 1st 2nd 3rd 4th 5th 6th 7th 8th 9th
TTI TTI TTI TTI TTI TTI TTI TTI TTI
UE0 ? 0
UE1 ? 1
UE2 ? 2
UE3 ? 3
Assuming hsdpaSchedulerAlgorithm = CQI, find which UE is scheduled at each
TTI: Cost
SPI QId 1st 2nd 3rd 4th 5th 6th 7th 8th 9th
UE0 ? 0
UE1 ? 1
UE2 ? 2
UE3 ? 3

Exercise
Assuming hsdpaSchedulerAlgorithm = Alcatel-Lucent, calculate throughput
relative ration for each QId
SPI 1 2 3 4 5 6 7 8 9 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 2nd 3rd 4th 5th 6th 7th 8th 9th
QId0/
QId1
QId0/
QId2
QId0/
QId3
QId1/
QId2
QId1/
QId3
QId2/
QId3
CQI management up to CQI 15 (all UE categories)
Transport Block Size

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

Exercise
hsdpaUeCategoryThroughputWeighting = ueCategoryProportionality
Throughput relative ratio (C2 based)

1st 2nd 3rd 4th 5th 6th 7th 8th 9th
QId0/
QId1
QId0/
QId2
QId0/
QId3
QId1/
QId2
QId1/
QId3
QId2/
QId3

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

Num of 336
CQI Num of HS -
bit MAC -d Modulation
PDU
16 3565 3440 10 16-QAM 5

17 4189 4115 12 16-QAM 5
18 4664 4420 13 16-QAM 5
19 5287 5101 15 16-QAM 5
20 5887 5782 17 16-QAM 5
21 6554 6438 19 16-QAM 5
22 7168 7168 21 16-QAM 5
23 9719 9546 28 16-QAM 7
24 11418 11216 33 16-QAM 8
25 14411 14155 42 16-QAM 10
26 17237 51 16-QAM 12
27 21754 64 16-QAM 15
28 21754 (-1dB) 23370 64 16-QAM 15
29 21754 (-2dB) 23792 64 16-QAM 15
30 23792 (-1dB) 64 16-QAM 15

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)
CRmax proportionalThroughput
Min COST value
CostCRmax = SW(u,q) . J(uq,) / CR(u,q) CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q)
UE #0 UE #1 UE #N
• power • power • power
• codes • codes • codes
• number of bits • number of bits • 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 MAC-
d PDUs times the PDU size divided by TTI duration to get the bit rate. The scheduling weight can be
controlled by the OMC parameters serviceMinRate, serviceMaxRate, serviceBFactor and serviceKFactor.
Job size J(u,q) represents the average throughput of the priority queue (this throughput is smoothed, using
an exponential filtering, by the OAM parameter hsdpaSchedulerWeightingFactorXcem for xCEM). The job
size is calculated by the MAChs internally for each user and queue
Channel rate CR(u) is the spectral efficiency (SE) times the number of available HSDPA 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)

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

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
Allfor the
Rights next round
Reserved of scheduling.
© Alcatel-Lucent 2010
2.28 Scheduler xCEM
2.28.3 TFRC SELECTION Summary

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

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
SNR TC
SPI QIdN
ARP THP SPI
QIdM
ARP THP
WEIGHT SE
SE WEIGHT
THROUGHPUTN
THROUGHPUTM

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 serviceMinRate
serviceMaxRate QId0 QId1 QIdN
serviceLowRate non GBR Mac-d flow

serviceHighRate
serviceBFactor serviceMaxRate
serviceKFactor
(HsdschServiceParameterSet)
COST x SW
Decrease OR Increase
COST
MAC-(e)hs GBR -serviceLowRate
serviceLowRate
Throughput R
<
serviceMinRate
GBR Mac-d flow OR
Throughput R
>
serviceMaxRate
MAC-(e)hs GBR +serviceHighRate
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 parameters serviceBFactor and serviceKFactor are shaping factors for increasing
and decreasing the priorities:
the larger the values for serviceBFactor and serviceKFactor the more the priority is decreased or
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
if serviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In
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
HS-SCCH transmit power No

UE is removed from scheduling list
<
Available power
Yes HS-S
CC
P-CP H
ICH
+ distance
0 dB
HS-SCCH to P-CPICH
Power Offset
-
iCEM xCEM
ReTx are always transmitted before 1st Tx 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 HS-
SCCH 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
eligibleUeCategoryForHighPerformance
RLC SDU Mac-d SDU = Mac-d PDU
minimumUserMbrForHighPerformance
21 320 16 320 16 320 16 Padding
isHighPerformancePduSizeReconfAllowed
Mac-hs PDU = 1TTI
Mac-hs SDU
21 640 16 640 16 640 16 Padding

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

= ƒ (Mac-d PDU size)
MAC-d PDU
= 336 bits
or = ƒ (UE cat.)
= 656 bits

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 minimumUserMbrForHighPerformance
Network (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)
Bit string of 64 bits

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

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

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

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 HS- isHighPerformancePduSizeReconfAllowed

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

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 isHighPerformancePduSizeReconfAllowed
depending on isHighPerformancePduSizeReconfAllowed = False
Cat. 656
Cell 656 Mac-d PDU size is not reconfigured (656) Cell 656

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 isHighPerformancePduSizeReconfAllowed
depending on isHighPerformancePduSizeReconfAllowed = True
Cat. 656
Cell 656 Mac-d PDU size is reconfigured (636) Cell 336

3
Cell 336 Mac-d PDU size is reconfigured (656) Cell 656

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


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 MAC-d PDU size is reconfigured (336 656) Cell 656

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 = False
SRNC DRNC
Iur
Iub Iub
NodeB NodeB
SRNS Cat. 656 DRNS
Mobility of a 656 bits MAC-d flow is refused 656 not supported

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

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 = True
SRNC DRNC
Iur
Iub Iub
NodeB NodeB
SRNS Cat. 656 DRNS
656 not supported

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

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

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.
Mac-hs PDU = 1TTI
BTSEquipment
Mac-hs SDU
BTSCell
21 320 16 320 16 320 16 Padding HsdpaConf
HsdpaUeCategoryTransportBlockOptimisation
Num of 336
CQI Num of HS -
bit MAC -d Modulation
PDU
1 377 1 QPSK 1
2 377 1 QPSK 1
ueCategory1
3 377 1 QPSK 1
ueCategory2
4 377 1 QPSK 1
ueCategory3
5 377 365 1 QP SK 1
6 377 1 QPSK 1
7 377 1 QPSK 2
8 792 699 2 QPSK 2
9 792 2 QPSK 2 ueCategory12
10 1262 1036 3 QPSK 3
11 1483 1380 4 QPSK 3
12 1742 1711 5 QPSK 3
13 2279 2046 6 QPSK 4
14 2583 2404 7 QPSK 4
15 3319 3090 9 QPSK 5

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
2.32 High Quality UL R99 RAB for High HSDPA DL Rate - Issue
UE Node B RNC CN Application
Server
DL RLC PDU TCP data

(App. Data)
App. 1
TCP UL radio problem
ACKs UL RLC PDU
2 (App. Data)
STATUS = NACK
n
1 UL TCP ACKs stored
Re-Tx
Burst of TCP
ACKs
CN discards application packets

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 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 UlUserService
CS_AMR_NBxSRB_3_4K
CS_64KxSRB_3_4K
initialSirTargetHsdpa (UlUsPowerConf) PS_128K_IB_MUXxSRB_3_4K
PS_128K_IBxSRB_3_4K
(NBAP) PS_384K_IBxSRB_3_4K
StandaloneSRBDCCH3_4K
...
UL SIR Target
maxSirTargetHsdpa (UlUsPowerConf)
minSirTargetHsdpa (UlUsPowerConf)
TTI

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 pchRrcStates = none
HSDPA/DCH timerT1ForHsdpa timerT2

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

Analog to R99 cases but with specific timer parameters

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 timerT2ForHsdpa
PS I/B MUX PMM-idle
CELL_DCH AO Step3
Multi-Service CS+PS / Mono-RAB PS I/B HSDPA

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

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

CS + PS I/B MUX timerT2ForHsdpa MM-connected

HSDPA/DCH +
CELL_DCH AO Step3 PMM-idle

Analog to R99 cases but with specific timer parameters

3 HSDPA Mobility


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

activationHoGsmPsAllowed
isInterFreqMeasActivationAllowed
isPatternAllowed isGsmCmodeActivationAllowed
(CmodePatternSeqInfo) (RadioAccessService)

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 FDD Cell F2
HS
-PD P-CPICH
CH
As
CH
SC
DS
so
1 H
DP
3
ci
-P
at
HS
ed
ed
at
DP
ci
so
CH
As
2 Radio Bearer Reconfiguration
isHsdpaHhoWithMeasAllowed
is3Gto3GWithoutIurAllowedforCS
isIrmCacForInterFreqIntraRncEnable is3Gto3GWithoutIurAllowedforPS
(RadioAccessService) (RadioAccessService)

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
FDD Cell F1 FDD Cell F2
HS P-CPICH
-PD
As
CH
CH
SC
so
DS
H 3
DP
ci
-P
at
ed
HS
ed
at
DP
ci
so
CH
As
2 Radio Bearer Reconfiguration
is3Gto3GWithoutIurAllowedforPS

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

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

2 (Event 1d)
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
Radio Link
3 Reconfiguration
HS-DSCH
HS-DSCH
SRNC 4 DRNC
Associated DCH
16 QAM
64
QA
HS
CH
- PD
As
CH
DS
so
SC
DP
5
-P
ci
HS
at
ed
AM
ed
at
ci
Q
DP
so
CH
16
As
Primary Cell change

2 (Event 1d)
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
Iub Bearer
Capacity Allocation
isMacShHsdpaAllowed
Iur Bearer
= true
Iur Capacity Allocation
Xoff message (link to Iub)
SRNC
Xoff period
Usable credit 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


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


End of Module
Module 1


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

3JK11637AAAAWBZZA Issue 1
Blank Page

HSUPA Algorithms Description Module 2
Document History


Module Objectives
Describe HSUPA activation principles and associated parameters

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




Table of Contents
Page
1 HSUPA Activation 7
1.1 HSUPA Activation Flags 8
1.2 E-DCH Capable UE Supported 9
1.3 E-BBU Resource Allocation – iCEM case 10
1.4 Multi-Mode BBU Activation – xCEM case 11
1.5 E-DCH/HSDPA Service Indicator broadcast 12
1.6 Scheduling 13
1.7 Physical Channels 14
1.8 Multiple E-AGCH and E-RGCH 15
1.9 Physical Channels Role 16
1.10 Transport Channel 17
1.11 E-DCH 2 ms TTI activation 18
1.12 HARQ 19
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ 20
1.13 MAC-e non-scheduled Mode 21
2 HSUPA RRM 22
2.1 Grant Allocation 23
2.2 E-TFCI Table Configuration 24
2.3 E-DCH Scheduler iCEM: Principle 26
2.4 E-DCH Scheduler xCEM: Principle 27
2.5 Priority Info Support (iCEM and xCEM) 29
2.5.1 iCEM MAC-e Scheduler 30
2.5.2 xCEM MAC-e Scheduler 31
2.6 UL Radio Load Monitoring: needed for E-DCH scheduling 33
2 1 52.7 UL Radio Load Monitoring: Defense Mechanism
All Rights Reserved © Alcatel-Lucent 2010 34
2.8
HSUPA AlgorithmsUL Radio
Description Load
Module 2 :
Self-interference issue with E-DCH 35
2.9 Self-interference issue on UL Noise Rise 36
2.9.1 First solution 37
2.9.2 Second Solution 38
2.10 DL Power Management: RNC level 39
2.11 DL Power Management: NodeB level 40
2.11.1 E-DCH signaling channels Power Control Parameters 41
2.12 UL Power Management 42
2.12.1 Closed Loop Power Control 43
2.12.2 Scheduling and Power Offset 44
2.12.3 UL Outer Loop Power Control on UL DPDCH (UA05.0) 45
2.12.4 UL OL Power Control on HARQ retransmission (UA05.1) 46
2.12.6 E-DCH Adaptive HARQ Control (UA06) 48
2.12.7 Specific case of SRB on E-DCH 49
2.12.8 Fast Decrease of E-DCH Partial SIR Target if Good Radio 50
2.12.9 E-DCH Partial SIR Target in case of Soft HO 51
2.13 Radio Link Control - DL/UL Imbalance Detection 53
2.14 User Services supported with HSUPA 54
2.15 HSUPA CAC 55
2.16 RAB Allocation Phase 56
2.17 HSUPA to DCH Fallback 57
2.18 Always On: degraded2AOnOnly - URA/Cell_PCH used 58
2.18.1 degraded2AOnOnly - URA/Cell_PCH not used 59
2.18.2 Always On: releaseOnly - URA/Cell_PCH not used 60
3 HSUPA Mobility 61
3.1 E-DCH Radio Links Set, E-DCH Active Set: Definitions 62
3.2 E-DCH serving NodeB, E-DCH non-serving NodeB 63
3.3 E-DCH Active Set Management: Event 1J 64
3.4 E-DCH Active Set Management: Primary Cell Change 65
3.5 Soft HO Data Transmission Example 66

Page
3.6 Manage UL Noise Rise due to E-DCH Non-Serving RL : iCEM case 67
3.6.1 xCEM case 68
3.7 E-DCH Macro Diversity RAN Model 69
3.8 Intra-Freq Mobility : Primary Cell Change 70
3.8.1 Call Flow 71
3.9 Intra-Freq Mobility over Iur 74
3.10 Inter-Freq Intra-RNC Mobility 75
3.11 Inter-Freq Inter-RNC Mobility: Without Iur OR 76
3.11.1 Inter-Freq Inter-RNC Mobility: With Iur AND 77
3.12 Inter-RAT Mobility 78


1 HSUPA Activation


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

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

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

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

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
slide + notes
updated
xCEM
BBU
BBU BBU
BBU
DCH DCH
DCH
DCH
iCEM
BBU
BBU BBU
BBU
HSDPA HSUPA
HSUPA
HSDPA
– DPCCH, DPDCH (DCH

+ SRB + CCH)
– all HSDPA channels
– all HSUPA channels
xCEM -Up to 256 DCH calls with any 128 of
them supporting HSDPA and/or
BBU
BBU BBU
BBU HSUPA.
Multimode Multimode
Multimode
Multimode -Up to 6 cells belonging to 2 LCGs
BBU
BBU BBU
BBU Up to 64 calls (DCH or
Multimode Multimode
Multimode HSDPA or mix of
Multimode
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
E-DCH cell
cell
HSxPA UE Auto hsdpaServiceIndicatorMethod Auto HSxPA UE

edchServiceIndicatorMethod
(FDDCell)
E-DCH E-DCH
OK! 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 2
• Absolute Grant
• Ack / Nack 5
• Relative Grants 6
EE--DPCCH
DPCCH E-DPDCH E-AGCH E-DPCCH E-DPDCH E-HICH E-RGCH
00 1 2 3 4 5 6
DL DL DL
• Scheduling info
1
• Format definition 3
• Traffic data 4
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
1.7 Physical Channels
slide + notes
updated
E-DPDCH E-DCH Dedicated Physical Data Channel UL
Carries the actual Traffic
DTCH E-DPCCH E-DCH Dedicated Physical Control Channel UL
Traffic
TRB Describes the E-DPDCH
E-HICH E-DCH HARQ Indicator Channel DL
Ack/Nack from BTS
E-DCH E-AGCH E-DCH Absolute Grant Channel DL

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

HSUPA includes a new set of new physical channels. Here are the basic functions of each channel:
E-DPDCH (E-DCH Dedicated Physical Data Channel) carries the actual UL Traffic
The number of E-DPDCH per UE depends of its E-DCH category.
E-DPCCH (E-DCH Dedicated Physical Control Channel) associated to the E-DPDCH to control it
There is up to 1 E-DPCCH channel per UE
E-HICH (E-DCH HARQ Indicator Channel) to indicate in DL to the UE if the UL transmission are well
received (ACK/NACK channel).
In UA05 up to 3 E-HICH maximum can be configured per BTS.
E-AGCH (E-DCH Absolute Grant Channel) and E-RGCH (E-DCH Relative Grant Channel) to indicate in DL
to the UE (individually or per group) what are their allocated UL resources. This indication can be done
using an explicit value (through e-AGCH) or relatively to the last allocated UL resources (with e-RGCH).

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

Associated DCH
Non serving users shall get uniformly assigned to
signatures reserved for common RG

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

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

Mobile
describes format and sends data

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

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
notes
updated
UE E-
1 A
GC - 2ms TTI
UE
2 UE H
3
10
m
UE
4U
- 8 HARQ process
xCEM s E5
Cat. 2, 4 & 6 - Special ETFC table
isEdchTti2msAllowed = True - Node B reports 1 FP each 2 ms
- In case of mobility, the RNC
isEdchTti2msAllowed = True reconfigure the TTI depending on
(EdchCellClass) Same Scheduling period
Primary cell capability
Cat. 1, 3 & 5 - 10ms TTI
When 2ms TTI is not activated all UEs are configured with 10ms TTI

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
UE has resources for

transmission
E-HICH
Transmit Data ACK/NACK
Insert DTX
Indication
NACK
RadioAccessService
Reset & Free
HARQ Process
Nret = Nret + 1 UlRSetConf
YES Nret > Nret_max NO

EdchParameters
edchHarqMaxRetrans

edchHarqMaxRetransrepresents the maximum number of retransmission at Edch HARQ level.

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

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

Higher reactivity and lower RTT with 2ms TTI.

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 E-DCH (S
) RB)
isEdchTti2msAllowed = True
ttiType = 2 xCEM
E-
E-
Cat. 6
AG
DC F2+
)
SRB
CH
H(
DC 2S
(T
)
( SG
RB
RB
(T )
)
H (S G
+
C 2S
E-D GCH
SR
F4
B)
E-A
Other Cat.
Cat. 6
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 HSUPA RRM
2.1 Grant Allocation
Total interference contribution Allocated Power / interference

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

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

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

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

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 Comments
1*SF4 10 1
1*SF4 2 2 1*SF4 with 2ms is not
supposed to be common; in
this case NodeB category is
assumed to correspond to
2*SF4 and 2ms TTI
2*SF4 10 3
2*SF4 2 2
2*SF2 10 5
2*SF2 2 4
All other cases 16 In this case virtual UE
category=UE category


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 E-
DCH TTI
UECategory5EdchTti10ms

2 HSUPA RRM
2.3 E-DCH Scheduler iCEM: Principle
Number of UE asking for Grants

UE max bit rate capability
E-BBU capacity
UL radio load Scheduling Information from UE:
UE power headroom
available for E-DCH UE User Buffer
Happy Bit
iCEM
E-DCH Scheduler
Grants allocated
Per UE
periodicityOfSchedInfoGrant
happyBitDelay
periodicityOfSchedInfoNoGrant
(EdchClass)
(EdchClass)

The scheduling process will distribute grants to UE according to :

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

2 HSUPA RRM
2.4 E-DCH Scheduler xCEM: Principle
Number of UE asking for Grants

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

allocated
Per UE periodicityOfSchedInfoGrant
happyBitDelay
periodicityOfSchedInfoNoGrant
(EdchClass)
(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 FddCell→TotalRotMax
and FddCEll→RtwpRef. RTWPref will be adjusted according to self-learned RTWP value in the NodeB,
as well as the resulting RoT.
The target UL load Ltarget is derived and is defined as the most restricting criterion among above
limitations
Measurements
RTWP is reported every 100ms to the MAC-e scheduler.
xCEM estimates every 10ms the average total UL load LE-DCH generated by E-DCH serving users.
The available E-DCH load is derived and corresponds to Lavailable, E-DCH = Ltarget - Lnon E-DCH. If Lavailable,
E-DCH <= 0, then the cell is overloaded.
UE specific information
Happy bit status
Scheduling information
Reference scheduling grant SGref, i, taken from previous scheduling interval
Average transport block size i.e. PHY throughput

2 HSUPA RRM
2.4 E-DCH Scheduler xCEM: Principle [cont.]

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
YES (edchConf)
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 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
USER PRI
For each SPI we configure a E-DCH

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

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

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

Fair but Proportional to
(edchConf)

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
Received Amount of
Available load Estimation La xCEM data from the last
MAC-e Scheduler scheduling period
Hypothetical load Lh
Happy Bit
Lh ≤ La Lh > La
REQUESTED INTERFERENCE
LOAD LOAD
All requests 1. Reduce Non-Serving Users

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

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.] new
serviceMinRate serviceMinRate
serviceMaxRate QId0 QId1 QIdN
serviceLowRate non GBR MAC-d flow

serviceHighRate
serviceBFactor serviceMaxRate
serviceKFactor
(edchServiceParameterSet)
COST x SW
Decrease OR Increase
COST
MAC-hs GBR - serviceLowRate
serviceLowRate
Throughput R
<
serviceMinRate
GBR MAC-d flow OR
Throughput R
>
serviceMaxRate
MAC-hs GBR + serviceLowRate
serviceHighRate

For a given SPI, priority of the queue is increased (or decreases) by multiplying the cost function by a
Scheduling Weight (SW) if the MAC-d throughput R is lower (or higher) than the parameter serviceMinRate (or
serviceMaxRate). The parameters serviceBFactor and serviceKFactor are shaping factors for increasing and
decreasing the priorities:
the larger the values for serviceBFactor and serviceKFactor the more the priority is decreased or
increased, if the measured average throughput R falls below serviceMinRate or exceeds
serviceMaxRate.
if serviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In
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 1. Reduce Non-Serving Users
serviceKFactor 2. Reduce Serving Users:
serviceMaxRate •UEs ranking according to:
serviceMinRate • Throughput eDchSpiRelativeWeight
(EdchServiceParameterSet) • Relative Weight RWj (EdchConf)
• Scheduling Weight SWi
Rmax Rmax
Rmax Average Tput
Rmin Rmin
Average Tput Average Tput
Rmin
PFi SWi = 1 SWi

SWi UE is downgranted only according to RWi PFi
This UE will be the last to be down-granted This UE will be the first to be down-granted
The scheduler de-grants the UE with lowest priority and update Lh and repeats the procedure as long as Lh>La
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) Priority Weighting (Rmin = 40 kbps, Rmax = 60 kbps)
B = 7, K = 7 B = 5, K = 7 B = 3, K = 7 B = 1, K = 7 B = 7, K = 7 B = 7, K = 5 B = 7, K = 3 B = 7, K = 1
7 7
6 6
5 5
Priority
Priority
4 4
3 3
2 2
1 1
0 0
20 30 40 50 60 70 80 20 30 40 50 60 70 80
Data Rate [kbps] Data Rate [kbps]

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

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
RoT (BTSCell)
All users are de-granted

All HARQ acked
rtwpTimeDetection
rtwpMargin
totalRotMax
Time
ALARM

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
DPDCH UL Inner-Loop Power Control)
DPCCH DPCCH
SIR SIR
Part of user signal power seen as

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

ICEM PROBLEM
AND SOLVED IN
XCEM

2 HSUPA RRM
2.9 Self-interference issue on UL Noise Rise
High rate transmission on E-DCH
or “SIR”: DPCCH SIR used in

UL Inner-Loop Power Control
Increase of “Self-interference”
UL Inner-Loop Power Control:

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

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

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
4
x 10 3GP P TB table (TTI 10 ms ) E-DP DCH power vs . trans port block s ize
2 30
1.8
10ms TtiTable0 25
E-DP DCH power relativ to DP CCH (dB)

1.6
10ms TtiTable1
1.4
Trans ort block s ize (bits )
20
1.2
1
Max E-DCH TBS 15
0.8
10
0.6
0.4
5
0.2
0 0
0 20 40 60 80 100 120 140 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Trans ort block s ize index TB s ize (bits ) 4
x 10
E-TFCI = 89
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 e-codec (MAC-e Scheduler) Total

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

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

“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
notes
updated
SHO margin P MaxCell
Max Power for

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

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
BTSCell
E-AGCH eagchPower
E-DCH
EdchConf
RadioAccessService E-HICH ehichPowerSignature
EdchRncConf
no PC for iCEM = fixed
eagchPowerControlMode
ehichPowerControlMode
eagchPowerControlActivated ergchPowerControlMode
PC for xCEM = dynamic
eagchPowerControlModeXcem

At NodeB level, the DL power for E-AGCH, E-RGCH/E-HICH channels is dynamically allocated on a 2ms basis
when there is a need to address E-DCH users on these channels.
The power that is not used by these channels can be used for HSDPA DL channels (HS-SCCH and HS-
PDSCH).
In this release:
These channels are not power controlled for iCEM board but power controlled for xCEM board:
Therefore Power Control Mode parameters are set to fixed value for iCEM:
eagchPowerControlMode
ehichPowerControlMode
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) = eagchPowerOffset
PEDCH(k) + POEAGCH EdchConf
PEDCH(k)
E-HICH PEHICH signature(k) = ehichErrorProbability

minPowerCorrection
PEDCH(k) + POEHICH signature
maxPowerCorrection
pMinDlEDCH
E-RGCH PERGCH signature(k) = nonServingEHICHPowerOffset
PEHICH signature(k) + POERGCH/EHICH powerOffsetERGCHServingNoSHO
commonERGCHPowerOffset

xCEM (iBTS) Behavior:

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

2 HSUPA RRM
2.12 UL Power Management
notes
ILPC SIR Target Update
updated
NodeB level
OLPC
βc SIR
estimation
R99
βd
BLER
R5 β hs estimation
RNC level
E-DCH Throughput
deltaEdpcch
R6 β ec E-DPCCH PO
β ed E-DPDCH PO + E-DCH TBS
referenceEtfciPowerOffset
edchTfcsTableIndex
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 Log Transp Phys RNC calculates the BLER (CRC)

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

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


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

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

The E-DPCCH is power controlled relatively to the uplink DPCCH by the means of a pre-defined offset ∆E-
DPCCH. 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)
E-DCH OL Power Control

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

DCH 1 OLPC DCH 2 OLPC
isUlOuterPCActivated (UlOuterLoopPowerCtrl) SIR Target OLPC

Update 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 E-DCH E-DCH OL Power Control

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

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

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

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

E-DCH RLC User
in the cell •1000

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

2.12.5 UL OL Power Control on HARQ retransmission (UA05.1) [cont.]
SIR Target
NodeB 1
UL OLPC Master •• Update of SIR

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

DCH)
CRCI of UL DCH 2 N of HARQ

CRCI of UL DCH 1
Retransmissions IE

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 red UL Radio Load Color
Cell State = S1 ⇒ NHARQ Target = nHarqRetransTargetS1

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

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:

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

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) + 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 E-
DCH Data Frame is received with at least one HARQ retransmission or with an HFI, and the Partial SIR Target is
then updated according to the usual formula.

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

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).
CELLA CELLB CELLC

A A A
B B B
C C C
D D D
E E E
HFI=1/4=NON DECODED PACKET/WELL RECIEVED ACKNOLAGE

SERVING RATIO = 2/4 = WELL DECODED PACKETS/

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

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

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 VS.EdchLinkImbalance ++


2 HSUPA RRM
2.14 User Services supported with HSUPA
isMonoDirectionalHsdpaRabAllowed
enabledForRabMatching (UlUserService)
HSxPA
Stand-alone
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
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 E-
DCH information, which defines the modification of transmission capabilities in uplink in terms of DPCH in
case an E-DCH is configured simultaneously.
TS 25.306 indicates that UE can only support a maximum of 64kbps on DCH with a simultaneous E-DCH
configuration Hence the following combination is not supported (ie. no automatic fallback to 64kbps on DCH) :
• PS Streaming UL:128kbps+PS I/B (E-DCH)
• Corresponding combination with CS is not supported either.
As a consequence, there will be a failure if the RNC attempts to establish the previous combination.
To workaround this issue, it is possible to fallback all (CS+)PS Streaming + PS I/B combinations to DCH.
This workaround is not activated by default but there is a flag to activate it,
isMonoDirectionalHsdpaRabAllowed (RadioAccessService). When set to False, the combinations (CS+)PS
Streaming + PS I/B HSDPA are fallbacked on (CS+)PS Streaming + PS I/B DCH.

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

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

Radio Link Reconfiguration Prepare
Radio Link Reconfiguration Ready

Radio Link Reconfiguration Commit
Radio Bearer setup
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
slide
UE NodeB RNC SGSN updated
RANAP/RAB Assignment Request

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

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

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

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

established to established to established

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 Downsize
(step 2) (step 3)
Inactivity
HSDPA + E-DCH CELL_FACH t

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

(UlUserService) (UlRbSetConf) (RadioAccessService)

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 )
Low activity /
Activity (UL or DL) Inactivity
Downsize
Release
Inactivity
HSDPA + -E DCH
Downsized RB (CELL_FACH)
t
Downsize Release timer
timer (timerT2)
(timerT1ForHsdpaAndEdch)
(AlwaysOnTimer)
t
Traffic UL/DL


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


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


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
C
E-DCH non-serving RL of non-serving NodeB
Cell of DCH AS (but not in E-DCH AS) B

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

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

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

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
3.3 E-DCH Active Set Management: Event 1J
Event1J
Event1J
Event1J
Event1J
isRrcEdchEvent1JAllowed
CPICH_Ec/No
amountRep1J
E-AS Cell (FullEventRepCritShoMgtEvent1J)
AS Cell
entering reporting range maxNbReportedCells1J

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

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
3.4 E-DCH Active Set Management: Primary Cell Change
Event1D
CPICH_Ec/No
R6 cell new Primary Cell R99/R5 cell

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

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

More Restrictive E-AS Compatible 2 ms tti should be
new Primary Cell in all AS in
Remove All E-AS cells
HSUPA, otherwise
NBRs would be
not compatible Reconfigure All E-AS cells
excluded
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 Transport Channels
E-AGCH
1. Absolute Grant Serving RNC
E-DCH FP
E-DCH
E-DPCCH 5. Void !
UE
cell
2a. E-TFCI(1) 9a. Data Tx(2) Ctxt
6a. E-TFCI(2) RLS 13a. Void
10a. E-TFCI(1)
E-DPDCH
3a. Data Tx(1)
7b. Data Tx(2)
11a. Data Tx(1)
E-HICH
4a. NACK(1)
8a. ACK(2)
UE 14. Data
12a. NACK(1)
Reordering/
Non- Combining
E-DPCCH
2b. E-TFCI(1) serving
6b. E-TFCI(2) E-DCH
cell E-DCH FP
10a. E-TFCI(1)
5. Void
E-DPDCH RLS 9b. Data Tx(2)
3b. Data Tx(1)
13b. Data Tx(1)
7b. Data Tx(2)
11b. Data Tx(1)
E-HICH
4b. NACK(1)
8b. ACK(2)
12b. ACK(1)

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

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

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

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

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 radio link E-DCH serving UE

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

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 NodeB
isEdchRlAddOrSetupDefenseAllowed
isRrcEdchEvent1JAllowed
FDDCell
targetNonServingToTotalEdchPowerRatio
DedicatedConf EdchRncConf
maxNumberOfRlEdch
HoConfClass MeasurementConfClass NodeBConfClass

iubEdchDelayVariation
UsHoConf/ FullEventRepCritShoMgt
PsHSDPA
CsSpeechPlusHSDPA BTSEquipment
…
FullEventHoConfShoMgt FullEventRepCritShoMgtEvent1J BTSCell
amountRep1J
maxNbReportedCells1J
EdchConf
FullEventHoConfShoMgtEvent1J repActThresh1J
repInterval1J edchSofterHoLimit
hysteresis1J
nonServingEHICHPowerOffset
timeToTrigger1J
commonERGCHPowerOffset
edchNumCommonRgPerCode
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 Serving
RNC RNC
FDD1 FDD1 FDD1 FDD1

1 2
Primary Primary
Cell Cell
Primary Cell
Change
E-DCH
HS-DSCH
DCH
UE UE
E-AGCH
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
RNC source Node B target Node B UE
Primary cell change
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Prepare
RL Reconfiguration Ready
RL Reconfiguration Commit (Activation CFN)
RL Reconfiguration Commit (Activation CFN)
RB Reconfiguration (Activation CFN, new E-RNTI, Serving

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

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


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


3 HSUPA Mobility
3.9 Intra-Freq Mobility over Iur
isHsdpaOverIurAsSrncAllowed Core Network isHsdpaOverIurAsDrncAllowed
isEdchOverIurSrncAllowed isEdchOverIurDrncAllowed
isMACShHsdpaAllowed
(RadioAccessService) 2
Serving Iur Drift

RNC Primary Cell RNC
FDD1 FDD1
Change FDD1 FDD1
Primary Neighbor
Primary
Cell Cell
1 3
isHsdpaAllowed
isEdchAllowed
(NeighboringRNC)
isEdchAllowed
edchMinSfCapabilities
isEdchTti2msAllowed
E-DCH
(RemoteFddCell)
HS-DSCH
UE 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, it’s recommended to set the E-DCH capabilities, under remoteFddCell
object, in line with the real cell capabilities otherwise, we can use these parameters to “downgrade” the
drift cell capabilities in order to limit the E-DCH traffic over Iur or to deactivate completely the E-DCH over
Iur toward some specific drift cells. We can for example limit the E-DCH over Iur to CAT3 by setting the TTI
capabilities to 10ms and Min SF capabilities to 2SF4 even if the drift cell is 2ms capable and supporting
2SF2+2SF4.

3 HSUPA Mobility
3.10 Inter-Freq Intra-RNC Mobility
Core Network isEdchHhoWithMeasAllowed Core Network
is3Gto3GWithoutIurAllowedforPS
isIrmCacForInterFreqIntraRncEnable
Serving Serving
RNC RNC
FDD1 FDD2 FDD1 FDD2

1 2
Primary Primary
Cell Cell
iMCTA
P-CPICH
E-DCH
HS-DSCH
UE 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
is3Gto3GWithoutIurAllowedforCS Core Network isInterFreqHandoverOverIurAllowed
is3Gto3GWithoutIurAllowedforPS (NeighboringRNC)
(RadioAccessService) SRNS Relocation = False
1 2 2 1
Serving Serving
no Iur
RNC RNC RNC RNC
FDD1 FDD1 FDD2 FDD2
iMCTA
Primary Primary
Cell Cell
1 2
P-CPICH
E-DCH
HS-DSCH
UE DCH

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
is3Gto3GWithoutIurAllowedforCS Core Network isInterFreqHandoverOverIurAllowed
is3Gto3GWithoutIurAllowedforPS (NeighboringRNC)
(RadioAccessService) = True
1 2 2 1
Serving Drift
RNC
Iur RNC
FDD1 FDD1 FDD2 FDD2
iMCTA
Primary Primary
Cell Cell
1 2
P-CPICH
E-DCH
HS-DSCH
UE DCH

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



for this module


End of Module
Module 2


3
Section 3
Appendix
Module 1
9300 W-CDMA

3JK11638AAAAWBZZA Edition 1
Section 3 Pager 1
Blank Page

Appendix
Document History
01 2009-02-26 El Abed, Achrafe 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.

Appendix

Section 3 Pager 3

Appendix

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

Appendix

Section 3 Pager 5

Appendix

Section 3 Pager 6
1 HSDPA : CQI Mapping Tables (3GPP)

Appendix

Section 3 Pager 7
1 HSDPA : CQI Mapping Tables
1.1 HSDPA CQI Mapping Tables new

Appendix

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

Appendix

Section 3 Pager 9
1.2 CQI mapping table B for UE categories 7 to 8 new
3 10 All Rights Reserved © Alcatel-Lucent 2010

Appendix

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

Appendix

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

Appendix

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

Appendix

Section 3 Pager 13
1.6 HSDPA CQI Mapping Table F new

Appendix

Section 3 Pager 14
1.7 HSDPA CQI Mapping Table G new

Appendix

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

Appendix

Section 3 Pager 16
2 HSUPA : E-TFCI and Grant

Appendix

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

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

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

Appendix

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

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

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

Section 3 Pager 19
2.3 Absolute Grant Table
Absolute Grant Value Index

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

Appendix

Section 3 Pager 20
3 Flexible HSDPA modulation usage
versus codes (xCEM)

Appendix

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

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

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

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
0
10
−1
10
BLER 1stTx
−2
10
−3
10
7 7.5 8 8.5 9 9.5 10 10.5 11
3.5
RLC Throughput [Mbps]
2.5
2
5*16QAM
9*QPSK
1.5
7 7.5 8 8.5 9 9.5 10 10.5 11
Ior/Ioc [dB]
flexible resources usage and accurate performances estimation algorithm

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

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
CQI =16 TBS1 ; TBS2
QPSK ; 16 QAM
TRFC Selection
Nb of Code1 ; Nb of Code2
xCEM
Particularly:
QPSK over more than 5 codes is made available for UE category 8 or 10 in low
or medium radio condition.
16QAM can be selected even if less than 5 SF16 codes are available for UE
category 1 to 10. This allows optimizing the cell HSDPA throughput in case of
code shortage.

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

Spectral Efficiency is based on the available power
In power limited situation, Spectral Efficiency is low QPSK is selected
In non-power limited situation, Spectral Efficiency is high 16-QAM is selected
Section 3 Pager 24
End of Module
Module 3

Appendix

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

Section 4 Pager 1
Blank Page

Glossary
Document History


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

Section 4 Pager 3
Abbreviations and Acronyms [cont.]
notes
updated
I Switch to notes view! NBAP Node B Application Part
IE Information Element NDI New Data Indicator
IK Integrity Key
ILPC Inner Loop Power Control
IMA Inverse Multiplexing ATM NDS Non-Delay Sensitive
iMCTA intelligent Multi Carrier Traffic Node B Logical node responsible for radio
Allocation Tx/Rx to/from UE
iMCRA intelligent Multi Carrier RRC Allocation NRZ Non Return to Zero
IMEI International Mobile Equipment
Identity O
IMSI International Mobile Subscriber OAM Operation Administration and
Identity Maintenance
IMT-2000 International Mobile OCNS Orthogonal Channel Noise Simulator
Telecommunication for year 2000 OLPC Outer Loop Power Control
IP Internet Protocol OLS Olympic Level Service
IR Incremental Redundancy OVSF Orthogonal Variable Spreading
iRM intelligent RAB Mapping Factor
Iu Interconnection point between RNC
and 3G Core Network P
Iub Interface between Node B and RNC PA Power Amplifier
Iur Interface between two RNCs PCCH Paging Control CHannel
P-CCPCH Primary-Common Control Physical
K CHannel
Kbps Kilobit per second PCH Paging CHannel
kHz kiloHertz PCM Pulse Code Modulation
KPI 4Glossary
4
Key Performance Indicator PCPCH Physical Common Control CHannel
Ksps 9300 W-CDMA
Kilo symbol per second
PDP Packet Data Protocol
PDU Protocol Data Unit
PI Paging Indicator
L PI Priority Indicator
L1 Layer 1 (Physical Layer) PICH Paging Indicator CHannel
L2 Layer 2 (Data Link Layer) PIR Partial Incremental Redundancy
L3 Layer 3 (Network Layer) PLMN Public Land Mobile Network
LA Location Area PMM Packet Mobility Management
LAC Location Area Code PN Pseudo Noise
LAI Location Area Identity PQ Priority Queue
LAN Local Area Network PRACH Physical Random Access CHannel
LSB Least Significant Bit PS Packet Switch
P-SCH Primary-Synchronization CHannel
M PSK Phase Shift Keying
MAC Medium Access Control
Mbps Megabit per second Q
MBR Maximum Bit Rate QId Queue Identity
MCC Mobile Country Code QoS Quality of Service
MCPA Multi Carrier Power Amplifier QPSK Quadrature Phase Shift Keying
Mcps Megachip per second
MHz MegaHertz R
MIMO Multiple In Multiple Out R4 Release 4
MIR Mix Incremental Redundancy R5 Release 5
MM Mobility Management R6 Release 6
MNC Mobile Network Code RA Routing Area
MOC Managed Object Class RAB Radio Access Bearer
MOI Managed Object Instance RAC Routing Area Code
MOS Mean Opinion Score RACH Random Access CHannel
MRC Maximum Ratio Combining RAN Radio Access Network
MSB Most Significant Bit RANAP Radio Access Network Application
Part
N RB Radio Bearer
NACK Negative ACKnowledgement RF Radio Frequency
NAS Non Access Stratum RL Radio Link
Section 4 Pager 4
Abbreviations and Acronyms [cont.]
notes
updated
RNSAP Radio Network
Switch Subsystem
to notes view!Application TrCH Transport CHannel
Part TS Time Slot
RNTI Radio Network Temporary Identity TTI Transmission Time Interval
RRC Radio Resource Control TX Transmitter / Transmission
RRM Radio Resource Management
RTWP Received Total Wideband Power
RTT Radio Transmission Technology U
RV Redundancy Version UARFCN UMTS Absolute Radio Frequency
RX Receiver / Reception Channel Number
UDP User Datagram Protocol
S UE User Equipment
SA Service Area UM Unacknowledged Mode
SAP Service Access Point UMTS Universal Mobile Telecommunication
SAW Stop And Wait System
S-CCPCH Secondary-Common Control UP User Plane
Physical CHannel UPH UE Power Headroom
SCH Synchronization CHannel URA UTRAN Registration Area
SCR Sustainable Cell Rate U-RNTI UTRAN-Radio Network Temporary
SDU Service Data Unit Identity
SF Spreading Factor UTRAN Universal Terrestrial Radio Access
SFN System Frame Number Network
SHO Soft HandOver Uu the radio interface between UTRAN
SI System Information and UE
SIM Subscriber Identity Module
SIR Signal to Interference Ratio V
SM 4Glossary
5 Session Management VCC Virtual Channel Connection
SNR 9300 W-CDMA
Signal to Algorithms
UA06 HSxPA NoiseDescription
Ratio VoIP Voice over IP
SPI Scheduling Priority Indicator (CmCH-
PI) W
SRLR Synchronous Radio Link W-CDMA Wideband-CDMA
Reconfiguration
S-RNC Serving-Radio Network Controller
S-SCH Secondary-Synchronization CHannel
STTD Space Time Transmit Diversity
STSR sectorial transmit and sectorial receive
SW Scheduling Weight
T
TAF That's All Folks!
TB Transport Block
TBS Transport Block Size
TC Traffic Class
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
TF Transport Format
TFC Transport Format Combination
TFCI Transport Format Combination
Indicator
TFI Transport Format Indicator
TFO Tandem Free Operation
TFRC Transport Format and Resource
Combination
TFRI Transport Format and Resource
Indicator
TFS Transport Format Set
THP Traffic Handling Priority
TPC Transmit Power Control

Section 4 Pager 5
End of Module
Module 4

Glossary

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

Section 6 Pager 1
Blank Page

Call Admission
9300 W-CDMA UA07 R99 Algorithms Description
Document History
01 2009-02-29 El Abed, Achrafe First edition

02 2009-04-10 Charneau, Jean-Noël 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

Call Admission

Section 6 Pager 3

Call Admission
9300 W-CDMA UA07 R99 Algorithms Description This page is left blank intentionally

Section 6 Pager 4
Table of Contents
Page
1 iMCRA overview 7
1.1 Why intelligent Multi Carrier RRC Allocation? 8
1.2 Redirection types 9
1.3 Twin cells definition 10
2 iMCRA capabilities 11
2.1 UE capabilities and call type 12
2.2 Cell capabilities and faType 13
3 iMCRA algorithms 14
3.1 CapaOnly 15
3.2 CapaAndEstCause 16
3.3 PreferredFa 17
3.4 CAC 18
4 iMCRA RAN model 19
4.1 iMCRA: RAN Model 20
5 iMCRA exercises 21
5.1 Exercise 1 22
5.2 Exercise 2 23

Call Admission

Section 6 Pager 5

Call Admission

Section 6 Pager 6
1 iMCRA overview

Call Admission

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

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

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

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
capaOnly
Based on UE
Based on UE HSPA
Capabilities and
Capabilities only
call type
rrcRedirectionType(InterFreqHhoFddCell)
cac
On RRC Call admission none
failure 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
twinCellList(InterFreqHhoFddCell) FDD1
CellId xyz
FDD2
FDD3
FDD4
FDD5
NodeB 2

Call Admission

Section 6 Pager 10
2 iMCRA capabilities

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 Establishment Cause Call Type

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

HSDPA Terminating Interactive
DATA
Higher than R6 HS-DSCH Terminating Background
Terminating Streaming
Higher than R6 HS-DSCH+E- HSUPA
DCH 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 For the faType,
the HSDPA / EDCH activation parameters cell‘s capability is defined:
RadioAccessService
RRCRedirectionConfClass 0..6
Frequency Allocation 1..6

Cell Concept Cell Capability Cell Configuration
Indication
R99 DCH Capable hsdpaActivation = False faType(InterFreqHhoFddCell)
edchActivation = False
HSDPA HSDPA Capable hsdpaActivation = True
edchActivation = False
HSxPA HSUPA Capable hsdpaActivation = True Conversational
Other
edchActivation = True Data

Call Admission

Section 6 Pager 13
3 iMCRA algorithms

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
call on originating cell
UE capability Target FA Fallback FAs
DCH DCH Cells Originating & Else select cells with lowest
all twin cells load color (Green<Yellow<Red)
HSDPA HSDPA Cells HSUPA then
DCH Cells If originating cell among
HSUPA HSUPA Cells HSDPA then selected ones, setup call in it.
DCH Cells Else select the final target cell
with round robin mechanism
(dlFrequencyNumber >
originating one)

Call Admission

Section 6 Pager 15
3 iMCRA algorithms
3.2 CapaAndEstCause
Select “UE capability & call

type” compatible Cells among
UE capability Call type Target FA Fallback originating and twin cells
FAs
Conversational DCH If originating cell among
DCH
Data DCH candidates and cell color
Other Originating better than threshold, setup

call on originating cell
Conversational DCH
Same as in
HSDPA
Data HDSPA capaOnly
Else select cells with lowest
Other Originating
load color (Green<Yellow<Red)
Conversational DCH
HSUPA
Data HSUPA If originating cell among
Other Originating selected ones, setup call in it.
Else select the final target cell
originating one)

Call Admission

Section 6 Pager 16
3 iMCRA algorithms
3.3 PreferredFa
If originating cell among

candidates & cell color better
than threshold, setup call on
Call Type Target FA Fallback FAs originating cell
Select FAs with FAs of type other;
Conversational faType set to if none FAs of type
Conversational Data
Else select cells with lowest
Select FAs with FAs of type other; load color (Green
faType set to if none FAs of type <Yellow<Red)
Data
Data conversational
Other Select cells with

faType set to If originating cell among
others selected ones, setup call in it.
Else select the final target cell
originating one)

Call Admission

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

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

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

Call Admission

Section 6 Pager 18
4 iMCRA RAN model

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 FrequencyAllocation 1..6
twinCellList
dlFrequencyNumber
rrcRedirectOrigCellColourThreshold
ulFrequencyNumber
isRedirectionBasedOnEstablishmentCause
faType
isRedirectionForTrafficSegmentation
fddFrequencyUserLabel
twinCellId

Call Admission

Section 6 Pager 20
5 iMCRA exercises

Call Admission

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

II. Always perform redirection based on call type only
III. Perform redirection based on load only
Parameter Value I. Value II. Value III.

isRrcRedirectionInterFreq
rrcRedirectionType
rrcRedirectOrigCellColourThresh
old
faType FDD1
faType FDD2
faType FDD3

Call Admission

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

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

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

Call Admission

Section 6 Pager 24

for this module

Call Admission

Section 6 Pager 25
End of Module
Module 1

Call Admission

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

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

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

W-Cdma Ua07 Hsxpa Algo - Tmo18256 D0sgdeni1.0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

W-Cdma Ua07 Hsxpa Algo - Tmo18256 D0sgdeni1.0

Transféré par

Droits d'auteur :

Formats disponibles

9300 WCDMA

TMO18256 9300 WCDMA UAO7

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

2 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

3. Topic/Section is Positioned Here

5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Welcome to TMO18256 9300 WCDMA UAO7 HSxPA Algorithms Description

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

The objectives is to supply explanations about the Algorithms for

7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

9 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

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

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

Edition Date Author Remarks

01 2010-04-30 Elsner, Bernhard First edition

All Rights Reserved © Alcatel-Lucent 2010

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

Describe HSDPA activation principles and associated parameters

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

All Rights Reserved © Alcatel-Lucent 2010

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

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

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

All Rights Reserved © Alcatel-Lucent 2010

Transport channel Frame Protocols

Adaptive Modulation and Coding

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

Flow control procedure to manage Node B buffering

Some new L1 new functionalities are introduced compared to R4:

112 All Rights Reserved © Alcatel-Lucent 2010

113 All Rights Reserved © Alcatel-Lucent 2010

114 All Rights Reserved © Alcatel-Lucent 2010

117 All Rights Reserved © Alcatel-Lucent 2010

119 All Rights Reserved © Alcatel-Lucent 2010

1 1 10 All Rights Reserved © Alcatel-Lucent 2010

1 1 11 All Rights Reserved © Alcatel-Lucent 2010

1 1 12 All Rights Reserved © Alcatel-Lucent 2010

1 1 13 All Rights Reserved © Alcatel-Lucent 2010

1 1 14 All Rights Reserved © Alcatel-Lucent 2010

1 1 16 All Rights Reserved © Alcatel-Lucent 2010

1 1 17 All Rights Reserved © Alcatel-Lucent 2010

1 1 18 All Rights Reserved © Alcatel-Lucent 2010

1 1 20 All Rights Reserved © Alcatel-Lucent 2010

1 1 21 All Rights Reserved © Alcatel-Lucent 2010

1 1 22 All Rights Reserved © Alcatel-Lucent 2010

1 1 23 All Rights Reserved © Alcatel-Lucent 2010