Tmo18256 v2.0 Hspa Algo SG Ua08 Ed2 Ce PDF

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms
of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from
time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment
constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided
in this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other
authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable
permission to access and use the Content solely for your personal training and non-commercial use. This permission may be
terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must immediately cease
use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and
Alcatel-Lucent’s corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws,
including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights
laws (collectively, "IP Rights"). In addition to Alcatel-Lucent’s IP Rights in the Content, in part and in whole, Alcatel-Lucent,
and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and
presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these
Terms of Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification,
publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative
works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way
exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited
and shall not be made without Alcatel-Lucent’s prior written consent. All characters appearing in this training course are
fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks
are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos,
marks, trademarks, slogans and product designations in any fashion. Granting of the right to access and use the Content for
training purposes does not confer upon you any license under any of Alcatel-Lucent’s or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES
AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute
or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision
that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal
Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder
without Alcatel-Lucent’s prior written consent. Nothing herein shall be deemed an employment agreement or an offer of
employment or an alteration in any way of a user’s terms of employment with or within Alcatel-Lucent.
Copyright © 2011 Alcatel-Lucent. All Rights Reserved

Welcome to UTRAN
UA08 HSxPA Algorithms Description
1. HSxPA Algorithms Description

1. HSDPA
2. HSUPA
3. iMCRA_Step2
4. Appendix
5. Glossary

UTRAN
UA08 HSxPA Algorithms Description
Upon completion of this course, you should be able to:
l describe HSDPA activation principles, HSDPA resource allocation parameters, and HSDPA mobility
features
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

TMO18256_V2.0-SG Edition 2
Thank you!

TMO18256_V2.0-SG-UA08-Ed2 Module 1.1 Edition 2
Section 1 · Module 1 · Page 1
This page is left blank intentionally
Document History
Edition Date Author Remarks
01 YYYY-MM-DD Last name, first name First edition


Page
1 HSDPA principles 7
1.1 HSDPA distributed architecture 8
1.2 HSDPA evolution (HSDPA+) 9
1.3 HSDPA UE categories 10
1.4 UE categories and CQI 12
1.5 HSDPA activation flags 13
1.6 Multi-Mode BBU resource allocation 14
1.7 HSDPA/E-DCH service indicator broadcast 15
1.8 Dual cell / dual carrier 16
1.8.1 Simultaneous DC-HSDPA users 17
1.8.2 DC-HSDPA is applicable to multi-RAB 18
1.8.3 DC-HSDPA considerations 19
1.8.4 HSDPA dual cell activation 20
1.9 Transport channel 21
1.10 Physical channels 22
1.11 DL OVSF code tree 23
1.12 (E)-FDPCH 24
1.12.1 User multiplexing with E-FDPCH 25
1.12.2 SRB over HSPA with (E)F-DPCH 26
1.12.3 Criteria for SRB mapping on HSPA 27
1.12.4 Criteria for SRB mapping on HSPA 28
1.12.5 Radio configuration for SRB on HSPA 29
1.12.6 SRB on HSPA in mobility 31
1.12.7 RAN model 33
1.13 HSDPA key features 40
1.14 NodeB scheduler 41
1.15 AMC principles 42
1.15.1 QPSK & 16QAM modulation schemes 43
1.15.2 64 QAM On HSDPA 44
1.16 HARQ types 45
1.16.1 Two H-ARQ combining techniques 46
1.16.2 H-ARQ combining performances 47
1.16.3 Constellation re-arrangement (16QAM only) 48
1.16.4 Redundancy version parameters 49
1.16.5 HARQ stop and wait principles 50
1.16.6 Number of harq processes per UE category 51
1.16.7 HARQ mechanisms 52
1.17 Multi-RAB handling on HSDPA 53
1.18 User services supported with HSDPA – Stand-alone 54
1.19 User services supported with HSDPA - Combination 55
2 HSDPA scheduler 56
2.1 QoS mapping 57
2.2 Scheduling Priority Indicator (SPI) 58
2.3 UE, QId and SPI 59
2.4 Scheduling priority of GBR & retransmissions 60
2.5 User throughput & UE category management 61
2.6 Scheduler xCEM or eCEM 62
2.6.1 SNR ESTIMATION FOR HS-PDSCH 63
2.6.2 TFRC SELECTION 64
2.6.3 TFRC SELECTION summary 65
2.6.4 QoS management for proportional throughput scheduler 66
2.6.5 QoS management for Crmax scheduler 67
3 CQI & MAC-HS BLER management 68
3.1 CQI modification principles 69
3.2 HS-DPCCH detection based on CQI 70

Page
3.3 HSDPA BLER as per 3 GPP 71

3.4 OuterLoopLikeAlgorithm 72
4 HSDPA codes management 73
4.1 HSDPA codes allocation overview 74
4.2 Fair sharing 75
4.3 Fair sharing - RAN model 76
4.4 Dynamic code tree management 77
4.4.1 HS-PDSCH OVSF codes allocation 78
4.4.2 HS-PDSCH codes preemption / reallocation 79
4.4.3 DCTM – RNC RAN model 80
4.4.4 DCTM – NodeB RAN model 81
5 HSDPA power management 82
5.1 HSDPA DL power reservation at RNC 83
5.2 HSDPA DL power available at NodeB 84
5.3 Dynamic PA power sharing R99/HSPA carriers 85
5.3.1 Impact on DCH DL CAC and DL iRM 86
5.4 HSDPA power distribution 87
5.5 HS-SCCH power for xCEM or eCEM 88
5.6 HS-PDSCH power for x/eCEM 89
5.7 Exercise 90
5.8 HS-DPCCH power 91
5.9 HSDPA power - RAN model 92
6 HSDPA CAC & call management 93
6.1 RAB matching and CAC 94
6.2 HSDPA CAC 95
6.2.1 Fair bit rate 96
6.2.2 Call admission control & power reservation 97
6.2.3 Call admission control & codes reservation 98
6.3 HSDPA to DCH fallback 99
6.4 Initial rate capping during RB reconfiguration 100
6.5 Always on for HSDPA/DCH: mono-service PS/mono-RAB 101
6.6 AON for HSDPA/DCH: multi-service PS/Multi-RAB PS 102
7 Other HSDPA features 103
7.1 Fixed RLC and MAC-hs 104
7.2 Flexible RLC and MAC-ehs 105
7.3 64 QAM on HSDPA activation flags 106
8 HSDPA mobility 107
8.1 3G->2G HHO 108
8.2 3G->3G Intra-RNC Inter-freq HHO 109
8.3 3G->3G Inter-RNC Inter-freq HHO 110
8.4 HSDPA over Iur 111
8.4.1 64-QAM over Iur: not supported 112
9 iCEM appendixes 113
9.1 Multiple xCEM per carrier 114
9.2 H-BBU resource allocation 115
9.2.1 Parameters involved in CEM configuration 116
9.3 HARQ types 117
9.3.1 Optimal redundancy version for HARQ retransmission 118
9.3.2 Redundancy version parameters 119
9.3.2.1 Channel coding: recall 120
9.3.2.2 Redundancy version selection per HARQ process 121
9.4 Scheduler iCEM 122
9.4.1 Schedulers using cost function C1 only 123
9.4.2 Schedulers using cost functions C1 and C2: C1 124
9.4.3 Schedulers using cost functions C1 and C2: C2 125
9.4.4 TFRC SELECTION 126
9.5 CQI adjustment based on BLER: blerRangeBasedAlgo 127
9.6 CQI adjustment based on BLER: OuterLoopLikeAlgorithm 128
9.7 CQI adjustment based on BLER: Dynamic BLER adjustment 129
9.7.1 CQI adjustment step 130
9.8 HS-SCCH power control for iCEM 131
9.9 HSDPA DL power available at NodeB – iCEM case 132
9.10 HS-PDSCH power for iCEM - 1st transmission 133
9.11 HS-PDSCH power for iCEM - Retransmissions 134
9.12 HSDPA full power usage 135
9.13 HSDPA flexible modulation 136
9.14 Transport block size optimization: CQI 1 to 15 137

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. In some documents you might see MAC-
hs. It has been replaced by MAC-ehs in UA07!
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:
l Fast repetition layer handled by HARQ processes
l Adaptive Modulation and Coding
l New transport channel High Speed Downlink Shared Channel (HS-DSCH)
l Flow control procedure to manage Node B buffering
Some new L1 new functionalities are introduced compared to R4:

l 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
l New channel coding chain for HS-DSCH transport channel and HS-SCCH physical channel
Other features related to HSDPA:

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:
l It allows coping with MAC-d PDU of different sizes
l It brings the capability to segment MAC-d PDUs
l 64-QAM requires Mac-ehs

Twelve categories have been specified by Release 5 for HSDPA UEs according to the value of several parameters
among which are the following:
l Maximum number of HS-DSCH codes that the UE can simultaneously receive (5, 10 or 15)
l 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.
l Supported modulations (QPSK only or both QPSK and 16QAM/64QAM)
l 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.

Evolved UE categories have been introduced to support the 64QAM and MAC-ehs:
l 13 and 14 (64-QAM only),
l 17 and 18 (64-QAM or MIMO).
Note that MIMO is not supported in UA08.1

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

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.

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:
l at BTS level, set hsdpaResourceActivation to TRUE.
l at RNC level, set isHsdpaAllowed to TRUE
l 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:
l deactivation
at RNC level: setting isHsdpaAllowed to FALSE deactivates HSDPA and leaves the HSDPA
dedicated resources preserved,
l deactivationat 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.

Starting UA6.0, M-BBU functionality is activated by default (no means to deactivate it).
HSDPA is supported by Alcatel-Lucent BTS within the following system limits:

l For HSDPA managed by x/eCEM :
n All cells of a given LocalCellGroup are managed by M-BBUs on a same x/eCEM (cannot be split
between several xCEM or eCEM). All HSDPA resources of the xCEM or eCEM are seen as a single pool
of capacity
n Maximum 2 LocalCellGroup (up to 6 HSDPA Cells) per xCEM or eCEM board.

This feature allows the mobile to display an indication when it is under HSxPA coverage.
l UTRAN broadcasts an HSDPA cell indicator information element in SIB 5 for cells that are HSDPA capable.
l 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:
l Off:the ‘hsdpaServiceIndicator’ (or respectively the ‘edchServiceIndicator’ ) information is not broadcasted
in SYSINFO message
l 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.
l 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)

When an UE is in Dual Cell mode this means that it will de able to almost double its downling speed.
This feature corresponds to Dual-Cell HSDPA operation in the 3GPP Rel-8 standard. This means that
simultaneous downlink HS-DSCH transmission from two cells, handled by the same BTS, covering the same
geographical area and with adjacent carriers, is supported to a given UE. The two cells involved in the DC
connection of a given UE are referred to as the Anchor (serving) HS-DSCH cell and the secondary HS-DSCH cell.
The secondary HS-DSCH cell is only used for HS-DSCH transmission to the UE.
In fact this UE will be always listening to one and only one cell. There is no soft HO in HSDPA. When we say
« listen » we mean that the UE is decoding the HS-SCCH channel from the Anchor cell. In some TTI, the shared
channel (HS-PDSCH) can be sent over two cells on two adjacent frequencies (carriers).
The UE, in function of its category, can receive over up to 15 SF16 codes on the Anchor cell and simultnously
over up to another 15 codes on the supplementary cell.
The two cells must be on the same nodeB.

The maximum number of simultaneous Dual Cell HSDPA users per board is configurable (when this value is
reached, the next DC capable UE will be configured with legacy HSDPA calls). The maximum value is 15 for all
types of board (xCEM, eCEM, UCU-III).
OA&M maximum range shows higher values than 15 (42 for xCEM, 64 for eCEM, 42 for UCU-III) but the Node B
has an internal limit to 15. The effective maximum number is minimum (15, OA&M parameter value).
1 DC-HSDPA user is counted as 2 HSDPA connections, among 128 available. This means the numbers of
simultaneous SC-HSDPA users and DC-HSDPA users satisfy the following condition
(Number of SC-HSDPA users + (2 * number of DC-HSDPA users)) <= 128

The multi-service calls (CS+PS), the standalone PS Streaming over HSDPA, the standalone SRB over HSPA and
the PS I/B RAB with the signaling indicator set to SIGNALLING are not eligible for HSDPA-DC and will be set up
as legacy HSDPA calls.

Consider the following factors when deploying DC-HSDPA:
l Proportion of DC-HSDPA users on the network: A higher proportion of DC-HSDPA users results in
better system throughput gains.
l Uplink capabilities: UL is used to acknowledge the DL. We estimate that UL should be around 8% of the
DL to acknowledge efficiently. If dedicated channels (DCHs) are used on the uplink, the downlink peak rates
for DC-HSDPA users are restricted, resulting in decreased gains. HSUPA is recommended on the uplink for
DC-HSDPA.
l Bandwidth over the Iub interface: If the bandwidth over the Iub interface is inadequate (Iub over a
couple of E1/T1), DC-HSDPA cannot be efficient.
l Packet
loss rate on the core network: If the core network has a high packet loss rate, this will decrease
DC-HSDPA gains.

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

From a Radio Bearer perspective, a HSDPA data session implies:
lA 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
l 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:
l Short fixed TTI value of 2 ms,
l One Transport Block (data block) per TTI,
l Fixed length CRC (24 bits) per data block,
l Type of channel coding: turbo code rate 1/3
n Effective code rate achieved with rate matching
n Dynamic redundancy version.
l Every TTI, Adaptive Modulation and Coding (AMC) is updated according to the radio conditions experienced
by the UE and his category.
n 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)

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.

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:
l Reservation
of the HS-PDSCH codes is static and the number of HSPDSCH codes is defined by the
parameter numberOfHsPdschCodes.
l HSDPAcodes 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.
l 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):
l Reservation of HS-PDSCH codes is dynamic and depends on the R99 traffic.
l Codes not used by R99 can be used for HS-PDSCH channels.
l Nevertheless, some codes needed to be kept free in order to anticipate the admission of a R99 call.
l 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):
l 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.
l 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.
l Asthe 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.

F-DPCH was introduced in 3GPP Rel.6 mainly to support higher VoIP over HSDPA capacity but can be used as
well for other traffic types mapped on HSPA. Enhancements were approved in Rel.7 to ease the implementation
and improve the efficiency in soft handover.
Thanks to this new channel, several HSPA users can be multiplexed into one SF256 code leading to an OVSF
code savings in downlink. In code limited regime, this savings can be translated into a cell capacity gain.
The control information is limited to TPC bits only:

l TFCI bits are not required as there is no DPDCH in DL
l Pilot bits have been removed, DPCH synch estimation is performed on the TPC bits
Based on the SRB RAB matching algorithm, SRBs are mapped onto UL and DL transport channels:
l DL: SRBs are mapped on HS-DSCH in DL
l UL: SRBs are mapped on E-DCH in UL

The allocation of OVSF codes is done by the CRNC in several steps:
1. Find an OVSF code where it is possible to allocate the F-DPCH for this user.
2. Select a position in this OVSF code.
3. Determine the F-DPCH slot format from the position that has been allocated.
When a code is needed to a new F-DPCH user, the CRNC shall find the first SF256 code from CCh,256,0 that
fulfills the following conditions:
l C1 – The OVSF code is free (not allocated or blocked).
l C2– The OVSF code is already allocated to one or more F-DPCH users, is not full (has less than 10 F-DPCH
users) and contains a free slot format entry allowed for the new user.
Each SF16 freed allows one to have 16 SF256 codes . So, with 40 HSDPA users, we need 40 SF256 codes
without FDPCH. Which means that we need to free 3 SF16 codes.
But if we use the FDPCH feature, then each SF256 can multiplex 10 users. So, we need to free only 1 SF16 for
up to 10 (already available SF256) + 160 (16 new SF 256 freed) = 170 HSDPA users!

Question:
If a UE does not have a DCH, do you think that SRB over HSDPA will benefit from macro diversity (Soft HO)?

The criteria for the SRB to be mapped on HSPA are the following (these are applicable to all the cells of the
active set, unless otherwise stated):
MAC-ehs must have been selected for the call.
The UE supports F-DPCH (RRC CONNECTION REQUEST message):
l Support for F-PDCH IE = ‘True’
l UE Capability Indication IE = ‘HS-DSCH+E-DCH’
l Access Stratum Release Indicator IE = ‘REL-7’ (or later)
F-DPCH is configured on all cells of the active set through appropriate OAM parameter:
l isSrbOverHspaEnabled set to True in objects RadioAccessService, FDDCell, NeighbouringRNC and
RemoteFDDCell.
l For case of NeighbouringRNC and RemoteFDDCell, this attribute is not used for UA08, as there is no F-
DPCH support over Iur.
Radio conditions are good enough:
l For call setup, these are based on Measured Results on RACH IE in the RRC CONNECTION REQUEST
message.
l The value is either RSCP or Ec/No, according to the configuration and is compared to newly introduced
thresholds srbOverHspaRscpThreshold and srbOverHspaEcNoThreshold (hysteresis is also introduced
through parameters srbOverHspaRscpHysteresis and srbOverHspaEcNoHysteresis).
l For other triggers, radio conditions are verified each time measurements are received from the serving cell,
either triggered or periodic event (as for RACH, the value is compared with the respective threshold).
l If the radio conditions are below threshold – hysteresis, the SRB is reconfigured on DCH.

Parameters are introduced in RadioAccessService object to enable/disable SRB on HSPA per traffic class (in case
of multi-service, SRB on HSPA is allowed if it is enabled on each service individually):
l isSrbOverHspaEnabledForPsIb
l isSrbOverHspaEnabledForPsConversational
l isSrbOverHspaEnabledForPsStreaming
l isSrbOverHspaEnabledForCs
l isSrbOverHspaEnabledForSignaling
The establishment cause is checked, in case of an RRC connection procedure (it is not used for other triggers)
and SRB will be mapped onto HSPA according to the table in this slide.
All these criteria (last one only applicable to the RRC connection phase) are applied each time there is a change
in the call:
l RRC connection setup
l RAB establishment, release and modification
l Mobility
l Always-On
l Reception of Measurement Reports
isSrbOverHspaEnabledForCs indicates if SRB on HSPA with F-DPCH is allowed for configurations with CS.
At call setup, upon reception of the RRC CONNECTION REQUEST message, the RNC checks the different criteria
and, if all the conditions are fulfilled, the call is fully established on F-DPCH/HSPA.
As the UE category is not known at this stage, the call is established on E-DCH using 10-ms TTI (lowest
category 11 for HSDPA and category 1 for E-DCH is assumed).
After reception of RRC CONNECTION SETUP COMPLETE, the UE category is checked (‘Physical Channel
Capability’ in UE Radio Access Capacity IE) and if the E-DCH category is 2, 4 or 6, the UE will be reconfigured to
2-ms TTI at the next RAB establishment, if possible.

Even though SRB might be mapped on HS-DSCH/E-DCH without F-DPCH, no such configuration has been
defined in 3GPP specifications. So in order to avoid IOT problems with some mobiles (most likely bugs
because configuration is not tested), it has been decided to mandate F-DPCH when mapping SRB on HSPA).
For the DL, there is one dedicated priority queue per SRB and all these priority queues are mapped onto
one HS-DSCH MAC-d flow.
The Scheduling Priority of these priority queues are determined in the following way:
From OAM configuration for SRB#1 (through parameter srbOverHsdpaSpi)
The SPI of SRB#2, SRB#3 and SRB#4 are deduced by the RNC:
SPI(SRB#2) = SPI(SRB#1)-1,SPI(SRB#3) = SPI(SRB#1) - 2 and SPI(SRB#4) = SPI(SRB#1) – 3
Parameter srbOverHsdpaSpi should be set to a high value as it is not desirable having low priority for
the SRB on HS-DSCH to avoid SRB traffic delay and possible call drops.
For the UL, SRB will be configured in non-scheduled mode (with max PDU size defined by parameters
maxMacePduContentsSizeForNonScheduledModeTti2 and
maxMacePduContentsSizeForNonScheduledModeTti10) and will use one E-DCH MAC-d flow.
The MAC-e non scheduled mode was used solely to carry SRBs on E-DCH in order to maximize the E-DCH
performances when using 2SF2+2SF4 in case of UE category 6. Now, it may be used in all new cases
of SRBs mapped onto EDCH, introduced by this feature.
For the physical channels, F-DPCH is used in DL and DPCCH is used in UL (they are necessary to perform
power control).

The cell resource management introduced by feature PM33694 – Fair Sharing of Resources HSDPA vs DCH is
applicable for the new SRB on HSDPA.
If Fair Sharing is activated:

l Power and codes resource management applies as defined by PM33694 for SRB configured over HSDPA.
Regarding the cell resource management that is done internally in the RNC, the SRB contribution on power and
code consumption is taken into account as for any other TRB on HSDPA.
l The new parameters srbOverHsdpaGbr and initialActivityFactorSrb are used to estimate the power and code
needed for this SRB on HSDPA.
If Fair Sharing is not activated:

l There is no specific resource reserved for SRB on HSDPA.
l The CAC for HSDPA calls is based on a comparison between the current number of HSDPA users and a
maximum configurable number of HSDPA users.
l The number of HSDPA MAC-d flow is not incremented for this new SRB on HSDPA.

As there is no DCH with F-DPCH, there is no DCH FP, so the OLPC command to drive the SIR Target of the UL
DPCCH shall be sent by the RNC on E-DCH FP
For the Node Bs not having E-DCH FP (only containing cells in the DCH active set, with DL F-DPCH / UL DPCCH
configuration) no data traffic is sent through this Node B. So, the RNC has no possibility of updating the SIR
Target by OLPC commands and there is a risk that the NodeB sends TPC_down.
To avoid this issue, the RNC configures a SIR Target to MAX_SIR_TARGET value for the DCH radio links when
the call is configured with F-DPCH (the Node B will always send TPC_up, which will be ignored by the UE if
another Node B sends TPC_down).
OLPC: Outer Loop Power Control

Please notice that the SRB is received only from the Primary cell. It does not benefit from the Macro diversity.
In this example, cells 2 and 3 are in the Active Set. So they are candiates for the 1D Event. If this event (1D –
Primary cell change) the HSDPA channels move to the new primary cell, Cell 2 for example). The SRB moves
also to this cell.

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:
l FlowControl: new control frames are exchanged in the user plane between Node B and RNC to manage the
data frames sent by the RNC.
l Scheduler: determines for each TTI which users will be served and how many data bits they will receive.
l Hybrid Automatic Repeat Query: retransmissions management.
l AdaptiveModulation and Coding: new channel coding stages and radio modulations schemes are introduced
to provide data throughput flexibility.
l Feedback demodulation and decoding in UL.

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:
l C1 depends on the scheduler type. It takes into account the radio criterion.
l C2 takes into account the priority of the QID and mainly depends on the base credits assigned to this SPI
priority and the average CQI. This is only used by Alcatel-Lucent and Proportional Fair schedulers.
The resulting cost is a function of these two costs, and is different according to the scheduler type. Indeed, for
Alcatel-Lucent Proportional Fair scheduler, the resulting cost should be equal to α*C1+β*C2, while for the
classical Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The QId with
the smallest cost is scheduled first. Costs are updated after the QId has been served.
Note : when the UE is in compressed mode or in non HSDPA synchronised state (see chapter HS-DPCCH
detection based on CQI, for more details), then the Node B will not schedule it.

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.

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.

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

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

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.

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

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

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

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:
ls is used to indicate whether the systematic bits (s=1) or the non-systematic bits (s=0) are prioritized in
transmissions.
l-r (range 0 to rmax-1) changes the initialization Rate Matching parameter value in order to modify the
puncturing or repetition pattern.
l- 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.

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):
l 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.
l Incase of NACK reception, the number of retransmissions must be incremented. If the maximum number of
retransmissions (harqNbMaxRetransmissions for iCEM or harqNbMaxRetransmissionsXcem for
xCEM or eCEM) is not reached, the HARQ process is inserted in the “NACK list” of HARQ processes asking
for retransmission.
l 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.

Please notice that only the xCEM & eCEM cards allocate more than 6 harq process’:
l The iCEM card handles UE categories from 13 to 24 as UE category 10 (6 Harq process’).
l The UCU-III card handles UE categories 19-24 as UE category 18 (6 Harq process’).
l Forx/eCEM cards, category 21 to 24 have 12 processes when configured with dual cell call (6 for each cell)
else these also have 6 processes for single carrier HSDPA calls.

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

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.

UE are basically classified into 4 categories (TS 25.306):
l those that can support a maximum of 32kbps on DCH with a simultaneous HS-DSCH configuration,
l those that can support a maximum of 64kbps,
l and those that can support a maximum of 384kbps.
As a consequence:
l UE with a maximum capability of 32kbps does not support:
n PS Streaming DL:64kbps/128kbps/256kbps+PS I/B (HS-DSCH)
n CSD 64 + PS I/B (HS-DSCH)
n PS Streaming DL:128kbps/256kbps+PS I/B (HS-DSCH)
n 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.

UE are basically classified into 4 categories (TS 25.306):
l those that can support a maximum of 32kbps on DCH with a simultaneous HS-DSCH configuration,

l and those that can support a maximum of 384kbps.
As a consequence:
n PS Streaming DL:64kbps/128kbps/256kbps+PS I/B (HS-DSCH)

n CSD 64 + PS I/B (HS-DSCH)
n PS Streaming DL:128kbps/256kbps+PS I/B (HS-DSCH)
n PS Streaming DL:256kbps+PS I/B (HS-DSCH)
There is no limitation for UE with a maximum capability of 384kbps.
The DL capability with simultaneous HS-DSCH configuration IE is ignored by the RNC in UA05. Consequently, there will be a
failure if the RNC attempts to establish one of the previously listed combinations for the corresponding UE. To avoid this
situation, it is possible to fallback all (CS+)PS Streaming+PS I/B combinations to DCH.
When the multi-RAB on HSDPA is activated (isMultiRabOnHsdpaAllowed set to True), it is recommended to ensure that
the related DlUserService are enabled for RAB Matching:
• Speech + HSDPA
• CSD + HSDPA
• PS Streaming (DCH or HSDPA) + HSDPA
• Speech + PS Streaming (DCH or HSDPA) + HSDPA

There are mainly two reasons why operators wish to implement QoS differentiation:
l Service differentiation:
n 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.
n 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.
l QoS differentiation can be implemented by means of three different QoS attributes :
n 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.
l Alcatel-Lucent RNC makes use of different parameters to prioritize subscribers or services :
n 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.
n 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.
n Scheduling Priority Indicator (SPI) is used in the HSDPA packet scheduler to prioritize the different
MAC-d entity.

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

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:
l CmCH-PI: Common Transport Channel Priority Indicator (ó SPI)
l SPI: Scheduling Priority Indicator (ó CmCH-PI)

1) GBR priority:
Before UA06:
GBR only possible over DCH Transport channel
Since UA06:
l 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)
l GBR queues are given priority over non-GBR traffic and within GBR queues higher SPI traffic is served first
l Within each SPI, if not all the GBR flows satisfied then the priority is given to those with least demanded
bandwidth
l 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
l Activated by simple RNC switch attribute
n isGbrOnHsdpaAllowed under RadioAccessService
Benefits:
l Allows support of following radio access bearers over HSDPA
PS Streaming (non-buffered delay sensitive applications)
n
n PS Interactive/ Background with minimum bit rate (minBR) constraint

l 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
l Efficient use of air-interface resources by HSDPA made available to real-time services, enhancing capacity in
mixed configuration and off-loading such users from DCH in multi-layer configuration
2) Retransmissions priority:
With iCEM, retransmissions are always transmitted before first transmissions.
With xCEM or eCEM, 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.

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.
l hsdpaSpiRelativeWeight is a table of maximum 16 weight values (between 1 and 100) each one
corresponding to a SPI value.
l 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 :
l ueCategoryEquity: UE categories with same SPI will reach the same throughput in average at the same
CQI.
l ueCategoryProportionality: UEs throughput will depend on their category. With same SPI, their ratio
throughput will then be proportional to the ratio of transport block size of corresponding CQI (when UEs
have the same CQI).
The hsdpaUeCategoryThroughputWeighting (iCEM) and

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

With xCEM, two sheduler types are possible :
l proportionalThroughput allows a relative differentiation between users (based on SPI weight)
l CRmax allows a absolute differentiation between users
According to the 3GPP (X[R02]X), the UE has to report a CQI assuming a BLER 1st TX of 10%.
Contrary to iCEM, xCEM or eCEM does not directly use the CQI. The received CQI information is mapped to SNR values (SNR MAP,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.
l 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
l CostpropTh = (1/(ServiceBFactor(u,q)*100)) * J(u,q) / CR(u,q) for GBR MAC-d flows when R < serviceMinRate(R = Nbr PDU (ACK) x
PDU size / TTI)
l 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.
l 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 or eCEM). The job size is calculated by the MAChs internally for
each user and queue
l Channel rate CR(u) is the spectral efficiency (SE) times the number of available HSDPA code
Note that the cost functions for PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
l with PropTh, all the relative weights hsdpaSpiRelativeWeight have to be set with the same value (the value 100 disables totally the SPI
management algorithm) or all the SPI have to be set with the same value (e.g. 0).
l with Crmax, the Scheduling Weight has to be equal to 1 by setting serviceBFactor to 1

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

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 or eCEM 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 or eCEM 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:
l the UE capability
l the buffer occupancy of the selected priority queue
l the number of available HS-PDSCH codes
l the spectral efficiency SE

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

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

With CRmax: for a given SPI, priority of the queue is increased (or decreases) by multiplying the cost function
by a Scheduling Weight (SW)
(SW) if the MAC-d throughput R is lower (or higher) than the parameter serviceMinRate (or
serviceMaxRate). The parameters serviceBFactor and serviceKFactor are shaping factors for increasing
and decreasing the priorities:
l 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.
l ifserviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In this
case the priority of a user is neither decreased nor increased.
The Scheduling Weight is computed as follow:
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:

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.
l 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.
l Thetransport 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:
n power limitation management
n codes limitation management
n lack of MAC-d PDU in buffer
n optimization of CQI according to MAC-d PDU size

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.
l This algorithm manages two states: HSDPA Synchronized and HSDPA-Not Synchronized.
n The initial state is considered as not synchronized (HSD _OUT_SYNC), i.e. nothing has been yet
received on HS-DPCCH.
n To acquire the synchronization on the HS-DPCCH (HSD_IN_SYNC), N successive CQI must be
detected.
n 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.
n If M successive expected CQI are not detected (DTX), the UE falls into the HSD_OUT_SYNC state.
n 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:
l bit 1 = 0 ⇒ ON - HS-DPCCH synchronization based on CQI is activated
l 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.

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.

Concerning the parameter hsdpaCqiBLERAdjustmentAlgorithmXcem, the value constBLERTarget starting
UA06.0 activate the algorithm. The value deactivated inhibits the CQI Adjustment based on BLER but is not
recommended.
hsdpaBLERTargetUpperLimitXcem: 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.

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:
l BaseHSDPA CAC on resource consumption (power and codes) in order to guarantee a given HSDPA QoS to
each HSDPA user (GBR or MinBR)
l 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)
l Self-tuneHSDPA 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:
l Monitor the DL OVSF code tree occupancy
l Determine the codes available for HS-PDSCH scheduling
l 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.

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

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:
l 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
l maxNumberOfHsPdschCodes represents the maximum number of OVSF codes that can be allocated for
HSDPA traffic in the cell whatever the R99 DCH traffic value.

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.

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:
l To have normal feature behavior:
n numCodesForDcfhAfterReallocation <= threshCodesToTriggerReallocation
n numCodesForDchAfterStealing >= threshCodesToTriggerStealing
l To avoid ping-pong:
n numCodesForDchAfterReallocation >= threshCodesToTriggerStealing
n numCodesForDchAfterStealing <= threshCodesToTriggerReallocation
l To be in line with monitoring line
n numCodesForDchAfterReallocation <= spreadingFactorLevelForOvsfMonitoring
n numCodesForDchAfterStealing <= spreadingFactorLevelForOvsfMonitoring
n threshCodesToTriggerReallocation <= spreadingFactorLevelForOvsfMonitoring
n threshCodesToTriggerStealing <= spreadingFactorLevelForOvsfMonitoring
l To be coherent at cell setup
n minNumberOfHsPdschCodes <= numberOfHsPdschCodes
n numberOfHsPdschCodes <= maxNumberOfHsPdschCodes

The feature Fair Sharing and Dynamic Code Tree Management can not be activated in the same time in a cell
because they are incompatible. Before activating one, the other has to be deactivated.
The parameter hsdpaCodeTreeManagementActivation activates the NodeB part of the Fair sharing feature:
l If True, HS-PDSCH code are determined by CCM and HBBU is dynamically reconfigured.
l 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.

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
l TheRNC 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.
n if maxHspaPowerOffset =0, the Node B can use all the available remaining power for HSDPA
transmission
n if maxHspaPowerOffset >0, the operator has the ability to reserve an amount of power which cannot
be used by HSDPA

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

Multi-carrier PA Power Pooling from UA06:
Aim:
l 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
l Optimize
usage of available DL power, by allowing dynamic PA power sharing between F1 and F2
Improve HSDPA performance
l Guarantee that this feature has no impact on R99 traffic
Main characteristics:
l 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.
l 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).
l Feature impact on R99 power allocation:
n With this feature HSDPA traffic may use an important part of PA power
n But, R99 traffic has full priority for power allocation (as in UA05)
l Featureimpact 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.
n F1: No impact (since R99 traffic has full priority for power allocation)
n 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.

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

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.

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

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

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

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.

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):
l 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.
l 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:
l Once the RNC CAC passed, the Node B is requested for CEM resources allocation through Radio Link
Reconfiguration procedure
l The HSDPA CEM resources is handled by the H-BBU function for the iCEM or the M-BBU for the xCEM or
eCEM
l If the H-BBU or M-BBU limit is reached, the BTS will send a RL Reconfiguration Failure (meaning NodeB CAC
failure)
l 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.
n 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 or eCEM 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.

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

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

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

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:
l RAB assignment (to establish or to release)
l IU release
l Primary cell change
l Inter-RNC UE involved Hard Handover
l 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:
l RAB assignment (to establish or to release a second RAB)
l Primary Cell change
l 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.

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

Analog to R99 cases but with specific timer parameters

Analog to R99 cases but with specific timer parameters

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

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

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:
l Intra-Node mobility from Mac-hs to Mac-ehs capable cell: the RB remain configured with Mac-hs.
l 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:

l Inter RNC with IUR mobility (SRNS Relocation - UE not involved)
l TheRB remains with Mac-hs (as it was before SRNS relocation took place, refer to the restriction: not
supported over IUR).
l 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.

The 64QAM modulation is configured if the following conditions are fulfilled:
l1 MAC-ehs configured : The feature Flexible RLC and MAC-ehs must be configured.isMacEhsAllowed =
True and isMacEhsAllowed = True.
l2 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
l3 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)
l4 The NodeB is allowed to used the 64QAM: RadioAccessService.isDl64QamOnRncAllowed = True
and FDDCell.isDl64QamAllowed = True.
l5 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.

Thanks to Compress Mode in MAC-(e)hs a UE can performed a HHO to 2G with measurements when on a
HSDPA RAB.
l CM for 2G neighboring cells measurements is activated when UE is having a PS RAB on 3G if:
n isInterFreqMeasActivationAllowed = True
n isGsmCmodeActivationAllowed = True
n isPatternAllowed = True
Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering.
l 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

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

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
isHsdpaHhoWithMeasAllowed
l 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:
n HSDPA to DCH
n DCH to DCH
l 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).

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:
l The HSxPA-capabilities of the mobile
l 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.

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.
l 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.
l isHsdpaOverIurAsSrncAllowed: This parameter allows RNC to enable/disable HSDPA over Iur when acting as
a Serving RNC.
l isHsdpaOverIurAsDrncAllowed: This parameter allows RNC to accept/reject HSDPA reconfiguration over Iur
when acting as a Drift RNC.
l isHsdpaAllowed: This parameter defines the HSDPA capabilities of neighboring RNC to which Iur link is
provisioned.
l Incase, 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,

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.

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.

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:
l D-BBU: BBU managing dedicated services,
l 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:
l For HSDPA managed by iCEM/iCEM2 :
n A given HSDPA Cell is managed by one single H-BBU and cannot be split between several H-BBU.
n From one to three cells per H-BBU. All the cells must belong to same LocalCellGroup.

l Parameter hspaHardwareAllocation (under BTSEquipment/RfCarrier) coherent with the type of CEM
boards in the NodeB (iCEM /xCEM).
l 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.
l 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.
l Number of D-BBU (on iCEM) and M-BBU for DCH traffic (on xCEM) in accordance to parameter
minimumR99ResourceRequired.
l 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:
n UTRAN Sharing: this parameter can be used to discriminate the resources allocated to each PLMN.
n 3 carriers on local cells (STSR2+1 or STSR3): 2 LCG must be pooled together; the 3 rd LCG is
supported on separate CEM boards. There is no constraint to choice the 2 LCG that are pooled.
n In 6 sectors with 2 carriers, the LCG can be pooled per carrier or per cluster.

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.

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.
l The different HARQ types (each one being associated to a restricted redundancy version set) that can be
selected are:
n Chase Combining (CC): same redundancy version than first transmission is applied (QPSK only).
¡ RV = 0
n CC + Constellation rearrangement (CC+CoRe): same puncturing pattern is applied but
constellation rotation is performed (16QAM only).
¡ RV [0; 4; 5; 6].
n Partial Incremental Redundancy (PIR): systematic bits are prioritized.
¡ RV [0; 2; 4; 6] in QPSK and [0; 2; 4; 5; 6; 7] in 16QAM.
n Full Incremental Redundancy (FIR): parity bits are prioritized.
¡ RV [1; 3; 5; 7] in QPSK and [1; 3] in 16QAM
l To enable this feature the harqType parameter should be set to drType
n Other possible values are mirType, pirType, ccType

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:
ls is used to indicate whether the systematic bits (s=1) or the non-systematic bits (s=0) are prioritized in
transmissions.
l-r (range 0 to rmax-1) changes the initialization Rate Matching parameter value in order to modify the
puncturing or repetition pattern.
l- 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.

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

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.
l The different HARQ types (each one being associated to a restricted redundancy version set) that can be
selected are:
n Chase Combining (CC): same redundancy version than first transmission is applied (QPSK only).
¡ RV = 0
n CC + Constellation rearrangement (CC+CoRe): same puncturing pattern is applied but
constellation rotation is performed (16QAM only).
¡ RV [0; 4; 5; 6].
n Partial Incremental Redundancy (PIR): systematic bits are prioritized.
¡ RV [0; 2; 4; 6] in QPSK and [0; 2; 4; 5; 6; 7] in 16QAM.
n Full Incremental Redundancy (FIR): parity bits are prioritized.
¡ RV [1; 3; 5; 7] in QPSK and [1; 3] in 16QAM

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

Round Robin: serve UEs one after the other
l Advantage: all UEs are served
l 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)
l Advantage: choosing UEs on radio conditions improves effective throughput by inducing smaller probability
to get errors and thus triggering less retransmissions
l Drawback: selecting UEs according to radio conditions induces UEs in bad conditions to never be served
Fair: all UEs benefit from the same throughput
l Advantage: all UEs are served
l Drawback: allocated resources are not adapted to the amount of data to be sent per UE

Proportional Fair: favor UEs that report a high CQI versus their averaged CQI to take benefit from instantaneous
good radio conditions vs. average conditions
l 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
n CQIinst is the latest CQI reported (considered before CQI BLER adjustment)
l 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
l Advantage: UE selection is a tradeoff between throughput optimization and equity among UEs
n Nbits is the number of transmitted bits in the TTI
n Nbitsopt is the number of bits the UE can transmit at the reported CQI

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

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

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%).
l 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:
lA buffer of fixed size (= BufferSize) is created for each UE to compute the BLER.
l 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.
l Whenthe 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:
n 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.
n If NackNb > NackNbmax, the BLER is too high. Performances are then degraded. ∆CQI is
decreased by 1 and the buffer is reinitialized
n 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.

From 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.
l BLERTarget 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.
l 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.

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:
l hsdpaBLERTargetUpperLimit: defines the Upper BLER target.
l hsdpaBLERTargetLowerLimit: defines the Lower BLER target.
l hsdpaBLERTargeMediumLimit: defines the medium BLER target.
l hsdpaBLERObservationWindow: corresponds to the update period of the CQI offset
l 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.
l hsdpaCqiBLERAdjustmentAlgo: this parameter is used to deactivate the feature:
n 0: deactivated.
n 1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no possible parameterization, for iso-
functional introduction.
n 2: outerLoopLikeAlgo. It corresponds to the UA05.x algorithm, allowing a single BLER target.
n 3: dynamicOuterLoopAlgo. It corresponds to the UA06.0 evolution, with dynamic BLER target
switching.

Better throughput will be achieved:
l with High Target BLER for high UE speed and low CQI
l with Low Target BLER for low UE speed or high CQI
cqiThdHigh, medium and low are hardcoded in the CEM cards as shown:
cqiThdHigh
hdHigh
cqiThdLow

The aim of this feature is to adjust, according to the radio condition, the power allocated to HS-SCCH in order:
l to save power for data or other UE
l 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.

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.
l HSDPAchannels 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.
l 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.
l Then, the power available for HSDPA is defined by: PHsdpa = min(PRemain, PmaxHspa) where
n PRemain is the remaining power available for HSDPA from the NodeB perspective
n PmaxHspa is the maximum power that can be allocated for HSDPA from an RNC perspective

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

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
l Step and Const are constants values provided by studies are: Step = 0.5, Const = 3
l “Step”is positive, it helps handling the erroneous CQI and allows consuming right power according to new
conditions.
l “Const”illustrates the gain brought by redundancy versions recombining and should be positive; a negative
value could also be set to enforce first retransmission to be decoded while consuming maybe unnecessary
power.
This feature can be used with any HARQ Retransmission type thanks to harqType: MIRWithPowerAdaptation,
PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation.
Note : for xCEM, all available HSDPA power is used and shared between the different users. So, we do not need
this feature, which is valid for iCEM, as iCEM uses power for HSDPA according to a dedicated formula.

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

In UA05.x, the mapping between number of HS-PDSCH codes and modulation is fixed, that is to say :
l QPSK for less than 5 HS-PDSCH codes
l 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:
l Code limitation: When the number of available codes is limited, 16QAM modulation is preferred in order
to transmit a higher number of bits.
n 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).
l TBS boost: When it remains some HS-PDSCH codes, QPSK modulation is preferred in order to transmit a
higher number of bits.
n Ex : if 14 codes are available, the TFRC selected will be (6101 bits , 14 codes, QPSK) instead of (5101
bits , 5 codes, 16QAM)

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

Document History


Page
1 HSUPA principles 7
1.1 HSUPA main characteristics 8
1.2 HSUPA activation flags 9
1.3 E-DCH capable UE supported 10
1.4 Multi-Mode BBU resource allocation 11
1.5 E-DCH/HSDPA service indicator broadcast 12
1.6 Scheduling 13
1.7 Physical channels 14
1.8 Multiple E-AGCH and E-RGCH 15
1.9 Physical channels role 16
1.10 Transport channel 17
1.11 E-DCH 2 ms TTI activation 18
1.12 HARQ 19
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ 20
1.13 MAC-e non-scheduled mode 21
1.14 User services supported with HSUPA 22
2 HSUPA scheduler 23
2.1 Grant allocation 24
2.2 Priority info support 25
2.3 Scheduler x/eCEM: principle 26
2.3.1 x/eCEM MAC-e scheduler 27
2.3.2 Scheduling weight (SW) 28
2.3.3 Degrant mechanism 29
3 HSUPA radio load & interference management 31
3.1 UL radio load monitoring: needed for E-DCH scheduling 32
3.2 UL radio load monitoring: defense mechanism 33
4 HSUPA power management 35
4.1 DL power management: RNC level 36
4.2 DL power management: NodeB level 37
4.2.1 E-DCH signaling channels power control parameters 38
4.3 UL power management 39
4.3.1 Closed loop power control 40
4.3.2 Scheduling and power offset 41
4.3.3 UL outer loop power control on UL DPDCH (UA05.0) 42
4.3.4 UL OL power control on HARQ retransmission (UA05.1) 43
4.3.4.1 SIR target update decision 44
4.3.5 E-DCH adaptive HARQ control 45
4.3.6 E-DCH adaptive HARQ control – UA08 46
4.3.6.1 Enhanced user activity detection 47
4.3.6.2 Optimized edch harq retrans at cell edge 50
4.3.7 Specific case of SRB on E-DCH 54
4.3.8 Fast decrease of E-DCH partial SIR target 55
4.3.9 Fast decrease of E-DCH partial SIR target – UA08 56
4.3.10 E-DCH partial SIR target in case of soft HO - Definition 57
4.3.11 E-DCH partial SIR target in case of soft HO - Calculation 58
4.3.11.1 E-DCH partial SIR target in case of Soft HO - Exercise 59
4.4 Radio link control - DL/UL imbalance detection 60
5 HSUPA CAC & call management 61
5.1 HSUPA CAC 62
5.2 E-DCH NodeB CAC in UA08 63
5.3 Improved Cac for 2ms Tti users 66
5.4 RAB allocation phase 71
5.5 HSUPA to DCH fallback 72
5.6 Always on: degraded2AOnOnly - URA/cell_PCH used 73
5.6.1 degraded2AOnOnly - URA/cell_PCH not used 74

Page
5.6.2 Always on: releaseOnly - URA/cell_PCH not used 75

6 HSUPA mobility 76
6.1 E-DCH radio links set, E-DCH active set: definitions 77
6.2 E-DCH serving NodeB, E-DCH non-serving NodeB 78
6.3 E-DCH active set management: event 1J 79
6.4 E-DCH active set management: primary cell change 80
6.5 Soft HO data transmission example 81
6.5.1 x/eCEM case 82
6.6 E-DCH macro diversity RAN model 83
6.7 Intra-freq mobility: primary cell change 84
6.7.1 Call flow 85
6.7.2 Exercise 86
6.8 Intra-freq mobility over Iur 88
6.9 Inter-freq intra-RNC mobility 89
6.10 Inter-freq inter-RNC mobility: Without Iur OR 90
6.10.1 Inter-freq inter-RNC mobility: with Iur AND 91
6.11 Inter-RAT mobility 92
7 iCEM appendixes 93
7.1 Multiple E-AGCH and E-RGCH 94
7.2 E-BBU resource allocation – iCEM case 95
7.3 Scheduler iCEM: principle 96
7.3.1 iCEM MAC-e scheduler 97
7.4 UL Radio load monitoring: defense mechanism 98
7.5 UL radio load : self-interference issue with E-DCH 99
7.6 Self-interference issue on UL noise rise 100
7.6.1 First solution 101
7.6.2 Second solution 102
7.7 UL noise rise due to E-DCH non-serving RL : iCEM case 103

Fast Scheduling
In HSUPA, fast scheduling is used to allocate system resources in the NodeB through signaling at the physical
layer. By exploiting the burst transmission, the scheduler performs rapid resource allocation between UEs to
adapt to cell interference variations. This improves user experience and increases the system capacity.
Fast HARQ
Similar to HSDPA, HSUPA also introduces fast HARQ, which allows the NodeB to rapidly request retransmission
of erroneously received data. HARQ reduces the number of retransmissions at the RLC layer and shortens the
transmission delay. The NodeB performs soft combining of data erroneously received and data retransmitted
from the UE before decoding. The combining uses the information transmitted each time and thus increases the
success rate of decoding.
Shorter TTI
HSUPA allows a 2 ms TTI, which further reduces the transmission delay and scheduling delay.
Macro Diversity
HSUPA supports soft handover. The cells in the active set can receive data from UEs. Macro diversity increases
the probability of proper data reception, improves the quality of data transmission, and greatly enhances the
service stability of users at the cell border.

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

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:
l the Access Stratum Indicator which is part of the RRC connection request message,
l 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:
l How many codes the UE can transmit simultaneously
l Is the UE able to support 10 ms and 2 ms TTI
l What is the maximum throughput transmitted
In term of bit rates, we can expect a maximum of:

l2 Mbits /s for TTI = 10 ms
l 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.

Since UA06:
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:

l For HSUPA managed by x/eCEM :
n All cells of a given LocalCellGroup are managed by M-BBUs on a same x/eCEM (cannot be split
between several x/eCEM). All HSUPA resources of the x/eCEM are seen as a single pool of capacity
n Maximum 2 LocalCellGroup (up to 6 HSUPA Cells) per x/eCEM board.
n For a given LocalCellGroup, HSDPA & HSUPA resources must be located on the same x/eCEM
board.

This feature allows the mobile to display an indication when it is under HxDPA coverage.
l UTRAN also broadcasts an E-DCH cell indicator information element in SIB 5 for cells that are E-DCH
capable.
l 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:
l Off:the ‘edchServiceIndicator’ (or respectively the ‘hsdpaServiceIndicator’ ) information is not broadcasted
in SYSINFO message
l 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.
l 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)

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:
l It manages E-DCH cell resources between UEs
l 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:
l4 levels of priority (SPI),
l 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.

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

x/eCEM
On x/eCEM, up to 3 E-AGCH channels can be configured per cell. However, since on CEM 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 x/eCEM, if low E-DCH traffic is
expected, it is recommended to set maxNrOfEagch = 1.
On x/eCEM, up to 4 E-RGCH/E-HICH channels (i.e. OVSF codes) can be configured per cell. For x/eCEM, 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 x/eCEM), it is recommended to set maxNrOfErgchEhich = 3.
Note that since UA07, it is recommended to set maxNrOfErgchEhich to 1 in order to save DL codes and to favor
HSDPA+ performances.

We can divide the new set of channels into 2 categories: traffic & scheduling.
Scheduling channels
l 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).
l 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
l 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.
l 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.
l 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).

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:
l Only for UL
l 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
l Transport block size and Transport Block set size are free attributes of the transport format.
l Possibility
of HARQ process with retransmission procedures applied at Node B. Max number of
retransmission must be defined. Each transmitted blocks are numbered.
n Three HARQ types can be used: Chase Combining/cc, partial incremental redundancy/pir and full
incremental redundancy/fir
l Turbo coding with rate 1/3 is used
l CRC is 24 bits length
l 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.

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

edchHarqMaxRetrans represents the maximum number of retransmission at Edch HARQ level. When this
maximum is reached the corresponding MAC-e block is flushed and the HARQ process is freed.

Higher reactivity and lower RTT with 2ms TTI.

MAC-e Non-scheduled mode is supported by x/eCEM only (Non scheduled means sending data by UE without
waiting for E-AGCH from Node B).
This feature is used to carry SRB on E-DCH
l Allow to maximize the E-DCH performances when using 2SF2 (TRB) + 2SF4 (TRB + SRB).
l The cell should be 2ms TTI capable
l Used only for UE cat6
Non scheduled Mode is selected by the RNC in case of SRB on E-DCH
l 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)
l The UE is allowed to send data in the limit of resources allocated by the RNC without asking for a grant
before
l This grant is on top of SG (Serving Grant) and can be used by the UE for only non-scheduled data (SRB in
our case)
isSrbOnEdchAllowedWhenTrbOnEdch: Enable the possibility to map SRB on E-DCH in the UL for Cat 6 UE,
while the call is handling RAB(s) over E-DCH
srbQos.srbSpi: SPI used for SRB on E-DCH during a call
isSrbOnEdchForAllEdchCategory: SRB on E-DCH for all E-DCH categories
l False: E-DCH cat 6 UE only
l True: All E-DCH categories
isSrbOnEdchForAllMinSf: SRB on E-DCH for all NodeB minSF
l False: 2 SF2 + 2 SF4 minSF only.
l True: All NodeB minSF
isSrbOnEdchForAllEdchTti: SRB on E-DCH for all E-DCH TTI
l False: 2 ms TTI only and 2 ms supported on NodeB
l True: 2 ms and 10 ms allowed to use SRB on EDCH

Unlike multi service on HSDPA, there is no activation flag to enable or disable the multi RAB on HSUPA.
The activation is to be done thought the parameter enabledForRabMatching in UluserService Object for the following
instances:
l Speech + E-DCH
l CSD + E-DCH
l PS Streaming + E-DCH
l 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) :
l PS Streaming UL:128kbps+PS I/B (E-DCH)
l Corresponding combination with CS is not supported either.
As a consequence, there will be a failure if the RNC attempts to establish the previous combination.
To workaround this issue, it is possible to fallback all (CS+)PS Streaming + PS I/B combinations to DCH.
This workaround is not activated by default but there is a flag to activate it, isMonoDirectionalHsdpaRabAllowed
(RadioAccessService). When set to False, the combinations (CS+)PS Streaming + PS I/B HSDPA are fallbacked on
(CS+)PS Streaming + PS I/B DCH.
Multiple PS I/B on HSUPA Will now be possible with the upgrade to UA7.1 if isMultiRabOnEdchAllowed is set to True:
l Support of multiple PS I/B RABs on E-DCH requires the support of an additional MAC-d flow.
l This feature aims at providing support of PS I/B+PS I/B and related combinations with CS on HSUPA
l RAB combinations shall be then supported for 2ms and for 10ms TTI as well.
Note: isMultiRabOnEdchAllowed can be set to TRUE only if isMultiRabOnHsdpaAllowed is set to TRUE.

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:
l to ensure some fairness between al users.
l to
prevent the global UL interferences level from exceeding a threshold (RTWPmax standing for Received
Total Wideband Power).
l to make sure each UE will adapt its throughput on E-DPDCH according to the grants it has received.

Restriction: Only 4 priority levels are considered by CEM cards.
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 x/eCEM.
Priority Info is taken into account by HSUPA 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.

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:
l Cell resources: CE processing, maximum RTWP
l Measurements: RTWP, E-DCH load
l UE status: UE category, SI
l NodeB resources
l E-DCH processing resources are pooled across cells handled by one x/eCEM.
l 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.
l The target UL load Ltarget is derived and is defined as the most restricting criterion among above limitations
l Measurements
l RTWP is reported every 100ms to the MAC-e scheduler.
l x/eCEM estimates every 10ms the average total UL load LE-DCH generated by E-DCH serving users.
l 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.
l UE specific information
l Happy bit status
l Scheduling information
l Reference scheduling grant SGref, i, taken from previous scheduling interval
l Average transport block size i.e. PHY throughput

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:
l Reduce non-serving users if any
l Reduce serving users:
n 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
n The scheduler de-grants the UE with lowest priority and update Lh and repeats the procedure as long
as Lh>La.

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:
l 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.
l ifserviceBFactor is set to one serviceMinRate and serviceMaxRate are not taken into account. In this
case the priority of a user is neither decreased nor increased.
The Scheduling Weight is computed as follow:
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:

The B and K factors increase or decrease the priority of a user depending on its measured data rate
l The priority becomes the higher the more the data rate R falls below Rmin
l The priority becomes the smaller the more the data rate R exceeds Rmax
l At R = Rmin, the priority is 1 for all B and K factors
l At R = Rmax, the priority is 1/B for all K factors
The MAC-e scheduler de-grants the UE with lowest priority and updates the hypothetical load and repeats the
procedure as long as Lhypothetical > Lavailable. Each UE will be de-granted by 1 step at the maximum.
l When average throughput for MAC-d flow#i is lower than serviceMinRate (configured per Scheduling
Priory Level) the MAC-e scheduler shall increase the rank until the average throughput is equal to the
serviceMinRate. The resources are taken from the MAC-d flows that have an average throughput higher
than their serviceMinRate and especially those with an average throughput higher than their
serviceMaxRate. In overload situation, UEs in bad RF conditions will remain with throughput lower than
serviceMinRate. However, this behavior can be overruled by adjusting the serviceBFactor and
serviceKFactor to allow UE with bad RF conditions to achieve serviceMinRate.
l When average throughput for MAC-d flow#i is higher than serviceMaxRate (configured per Scheduling
Priory Level) the MAC-e scheduler shall decrease the rank until resources are given to those with average
throughput lower than serviceMinRate.
When the average throughput is between serviceMinRate and serviceMaxRate, a given {UE, MAC-d flow}
will be ranked higher if RF conditions are better. {UE, MAC-d flow} with same RF conditions, but different SPI,
will be ranked considering edchSpiRelativeWeight.

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

Rise Over Thermal: RoT = RTWP / Thermal Noise
l The RNC calculates RoT using Thermal Noise value.
Two thresholds are defined:

l Max RTWP for total UL traffic (R99/E-DCH).
l 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).
l RTWP measure is regularly sent by the BTS to the RNC for cellColour.
l 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

A defense mechanism is introduced in the BTS :
l 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 totalRotMax setting.
In this case:
n an alarm is raised
n all E-DCH UEs are de-granted
n all active HARQ processes are acknowledged to avoid retransmissions.
l The alarm is reset when:
n the RoT is below totalRotMax
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.

The scheduler used as resource the load on the Uu interface (UL Load = 1-10^(-RoT/10) so related to the RoT)
and the CEM resources. The available maximum transmission rate is controlled by the HSUPA scheduler in the
CEM board. If the cell resource is enough, the service configured can get a higher bit rate (limited by the
Maximum bit rate MBR). If the cell resource is congested, the bit rate is low (not higher than the GBR for STR
services).
When the totalRoTMax is high, there is more available resources and the rate scheduled is higher.
This RoT is creating UL interferences. In an HSUPA-capable cell suffering from strong interference, the cell
throughput is extremely low, resulting in an adverse HSUPA-user experience.
This can create also issues on BTS reception for non closed loope power controlled messages. Especially the RRC
connection Request. This might create UL coverture issues and bad MTC Call Setup Success Rate.

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

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.
l The power that is not used by these channels can be used for HSDPA DL channels (HS-SCCH and HS-
PDSCH).
In this release:
l These channels are not power controlled for iCEM board but power controlled for x/eCEM board:
n Therefore Power Control Mode parameters are set to fixed value for iCEM:
¡ eagchPowerControlMode
¡ ehichPowerControlMode
¡ ergchPowerControlMode
l 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.
l ehichPowerSignature is the power allocated for one E-HICH signature (up to 15 (resp 40) E-HICH
signatures can be used for iCEM (resp x/eCEM)).
l ergchPowerSignature is the power allocated for one E-RGCH signature (up to 15 (resp 40) E-HICH
signatures can be used for iCEM (resp x/eCEM). Only the common E-RGCH is used in case of iCEM.
l One HICH/RGCH is defined for iCEM per cell and up to 4 HICH/RGCH can be defined per cell for x/eCEM.
l E-DCH DL Channels PC can be enabled for x/eCEM when eagchPowerControlModeXcem parameter is set
to Dynamic.

x/eCEM (iBTS) Behavior:
E-AGCH, E-RGCH and E-HICH transmitted by the serving cell can be power controlled as well on x/eCEM, 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:
l The AGCH is only sent by the serving radio leg
l Since HS-DSCH is the DL RB for HSUPA CQI is always available
l 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.

E-DCH is power controlled as for R99:
l Theinner loop power control (cell level) is based on the DPCCH SIR estimation and comparison with the
SIR target (±1 dB at each slot).
l Theouter 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:
l 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
l The user is allowed to use a subset of authorized E-TFCI.
n 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.
n 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.

The E-DPCCH is power controlled relatively to the uplink DPCCH by the means of a pre-defined offset ΔE-DPCCH.
The E-DPDCH is also power controlled relatively to the uplink DPCCH.
l 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.
n The power offset needed for each E-DCH TFC is interpolated from the reference E-TFC(s) than are
provisioned by the operator. The UE selects one of the E-TFC than fits its needs – possibly the
highest- and that it is allowed to use according to its grants.
These offsets are not reconfigured during the call.

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:
l UE Tx power and audio quality (for speech)
l UE Tx power and RLC retransmissions (for data)
Principle:
l RNC monitors BLER on each UL transport channel, using CRC Indicator of selected UL DCH Iub data frame
l 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.

UL Outer-Loop Power Control (UL OLPC) for E-DCH in UA05.1
l Handled by “E-DPDCH Retransmissions for DPCCH SIR Adaptation” (34172) feature
l 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.
l 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)
l 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

Update of SIR Target, according to all Partial SIR Targets:
l if at least 1 Partial SIR Target increased since previous update:
n SIR Tg = max { Partial SIR Targets }

l if all Partial SIR Targets decreased:
n SIR Tg = min { Partial SIR Targets }

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

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:
l 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.
l Current UL Radio Load Color.
The UL Radio Load Color is derived from the non E-DCH UL radio load of the cell. For a detailed description of
the calculation of UL Radio Load Color.
Below figure shows how Cell State is determined according to the current number of “active E-DCH users” and
UL Radio Load Color of the cell. Note that maxNumActive- EdchUsersPerCellForS1 and
maxNumActiveEdchUsersPerCellForS2 parameters are used to set the thresholds for Cell State change on
number of “active E-DCH users” criterion.
The Partial SIR Target related to the E-DCH transport channel (note: in case of SRB on E-DCH, there are two
Partial SIR Targets related to E-DCH.
NHARQ Target, which is used as an input to compute the Partial SIR Target related to the E-DCH transport
channel, can take three different values depending on the current Cell State:
Cell State = S1 ⇒ NHARQ Target = nHarqRetransTargetS1
iCEM : Adaptive HARQ control is not used, because lab tests shown that there is no gain, and we can even have
degradation. So, we use value corresponding to S1 state.

Prior to UA08, a serving E-DCH user is counted as active if he has established an E-DCH serving radio link and is
in CELL_DCH state. Since this E-DCH user count may not provide an accurate view of the cell load (e.g. DL
transfer with only RLC and TCP acknowledgments in UL or web browsing application with inactivity periods
before transition to other RRC states), the tuning of the feature is difficult as it requires call profile knowledge
and stability during the day.
To improve this behavior, the way of counting the number of active E-DCH users is changed. Thus, a user is
counted as active if he exceeds a certain data rate.
The throughput Rj,i of each MAC-d flow i for each eligible user j (serving E-DCH user in CELL_DCH) shall be
measured over a certain measurement window averageWindow.
Lj: set containing the MAC-d flows of user j carrying streaming or interactive/background traffic over E-DCH.

An E-DCH user j is reported as "inactive" when its measured throughput Rj by U-Plane falls below OAM
parameter thrThresholdForInactiveState for a duration of timeToTriggerForInactiveState and the user was in
"active" state before.
Uplane will actually count the number of windows for which the user is inactive as follows:
floor (timeToTriggerForInactiveState/ averageWindow) = floor (1000/300) = 3 => 3 windows of 300ms.
An E-DCH user j is reported as "active" when its measured throughput Rj by U-Plane rises above OAM parameter
thrThresholdForActiveState and the user was in "inactive" state before.

When Event 6A is sent, the S_POWER_LIMITATION state is set to TRUE. This means than the UE normally is on
the cell edge, from UL point of view.
The parameter useOptimizedEdchHarqRetransAtCellEdge enables or disables the increase of the number

of target HARQ transmissions when the E-DCH UE is in power limitation.

N bits, MAC-es/is PDU,i is the number of bits contained in the received MAC-es or MAC-is PDU at RNC of logical channel
i during period averageWindow less the transmission sequence number (TSN) header and segmentation
status (SS) header in case of MAC-is PDU.
The filter factor f shall be set to OAM parameter filterFactorMacdThr and n denotes the actual
averageWindow interval.
The initial value of Rave,i shall be set to Ri
TBmax is the maximum number of bits of an E-DCH transport block (this MAC-e/i PDU size depends on the UE
category and the TTI).
L is the set containing all configured channels of the UE.

If S_POWER_LIMITATION = TRUE, the number of target HARQ retransmissions MOLPC, target is chosen depending
on the actual throughput ratio rthr:
If (rthr <= edchThrRatioForHarqRetransTarget1) AND (rthr > edchThrRatioForHarqRetransTarget2 +
hyst2_thr_ratio):
MOLPC,target = max(nHarqRetransPowerLimitTarget1, Last Actual Num HARQ ReTx Target )
l Else if (rthr > edchThrRatioForHarqRetransTarget1 + hyst1_thr_ratio):
M OLPC,target = Last Actual Num HARQ ReTx Target

l Else if (rthr <= edchThrRatioForHarqRetransTarget2)
M OLPC,target = max(nHarqRetransPowerLimitTarget2, Last Actual Num HARQ ReTx Target)

l Else do nothing (i.e. the standard OLPC mechanism applies)
Last Actual Num HARQ ReTx Target is the actual number of target HARQ transmissions according to the
standard OLPC mechanism.
To limit the number of ping-pongs, this mechanism is implemented:

l If S_POWER_LIMITATION == TRUE and an update of the number of target HARQ retransmissions was
done. The next update is not possible before a certain time defined by:
guardTimeForNHarqTargetChange
l At reception of a measurement report 6B (S_POWER_LIMITATION = FALSE), the number of target HARQ

retransmissions shall be set to the last actual number of HARQ retransmissions. At the same time, a timer
= 4 x guardTimeForNHarqTargetChange shall be started. Once a further measurement report 6A is
received (S_POWER_LIMITATION = TRUE ) when the timer is still running, an update of MOLPC,target shall
not be possible before this timer elapsed.

ueOffsetFromMaxPwr6A: Represents an offset in dB from the UE maximum power. It is used to determine
the absolute power for the UE measurement event 6A (absolute power = UEs maximum power -
ueOffsetFromMaxPwr6A).
ueOffsetFromMaxPwr6B: Represents an offset in dB from the UE maximum power. It is used to determine
the absolute power for the UE measurement event 6B (absolute power = UEs maximum power -
ueOffsetFromMaxPwr6B).
filterFactorMacdThr: Filter factor for the MAC-d throughput which is used to determine the switching points
for the change of the number of target HARQ retransmissions in case of UE power limitation
edchThrRatioForHarqRetransTarget1: Throughput ratio for switching the number of target HARQ
retransmissions to value nHarqRetransPowerLimitTarget1
edchThrRatioForHarqRetransTarget2: Throughput ratio for switching the number of target HARQ
retransmissions to value nHarqRetransPowerLimitTarget2.
nHarqRetransPowerLimitTarget1: Number of target HARQ retransmissions when the UE is in power
limitation and its throughput ratio falls below edchThrRatioForHarqRetransTarget1.
nHarqRetransPowerLimitTarget2: Number of target HARQ retransmissions when the UE is in power
limitation and its throughput ratio falls below edchThrRatioForHarqRetransTarget2.
timeToTrigger6A: Time-to-trigger value for UE measurement event 6A.
timeToTrigger6B: Time-to-trigger value for UE measurement event 6B.
filterFactorUeTxPower: Filter factor for UE internal measurement “UE transmitted Power”.

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.

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.

The improvement introduced by this feature is to make UL SIR decrease rapidly also for non active users.
The introduction of a timer to manage the case where nothing is received by the RNC was the solution
encountered to enhance the “Fast Decrease” mechanism.
It will be possible in UA08 to make E-DCH OLPC more efficient in order to help enhance cell capacity with
minimal impact on user throughput. UE power is reduced by a significant amount upon traffic inactivity in order
to quickly reduce interference to other users residing in the same cell.
User inactivity is defined as non received MAC-d PDUs for a call, on all the existing MAC-d flows, including E-DCH,
SRB and DCH RABs.
The activation parameter of the fast decrease of the E-DCH partial SIR target in UA08 is
isEdchFastSirTargetDecreaseAllowed.
Traffic inactivity must persist for a configurable period of time before applying the fast decreased power. This
can be configured using the parameter eDCHOlpcInactivityTimeThreshold.
The decrease of the UL SIR target due to inactivity is set to an optimum value so that it does not adversely
impact the performance of UL physical control channels. This can be configured using the parameter
eDCHOlpcInactivitySIRDecreaseLimit.
Finally, the preserved UL SIR target values of all existing MAC-d flows shall be restored following detection of
activity, i.e. receipt of MAC-d PDUs at RNC on any MAC-d flow. Initial power (saved right before fast decrease
process) is reinstated as soon as traffic resumes, on any of the RABs.

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

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.

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.

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

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 :
l the HSUPA iCEM resources are handled by E-BBU function
n A maximum number of user per E-BBU is defined (edchMaxNumberUserEbbu parameter)
n 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.
l the HSUPA xCEM resources are handled by M-BBU function
n A maximum number of user per xCEM board is defined (edchMaxNumberUserXcem parameter)
Unlike in UA05, edchMaxUsersPerCell: and edchMaxNumberUserNodeB are not more used.

m10ms is the current number of 10-ms TTI users.
n2ms is the current number of 2-ms TTI users.
maxNbEdchCreditsForXcem, maxNbEdchCreditsForEcem are OMC parameters defined to limit the number of 2-
msTTI users and preserved the capacity of the board in terms of E-DCH users (2ms + 10ms).
This E-DCH enhanced Node B CAC improves the control of E-DCH performance, by giving some means to the
operator to limit the maximum number of E-DCH 2-ms TTI connections handled per xCEM or eCEM.

E-DCH NodeB CAC applied to xCEM consists in 3 aspects:
l LimitingE-DCH user acceptance according to the check n10ms+4n2ms ≤ 128-GRakeCost1 (this is the
maximum capacity of the modem); if this check is not satisfied, the NodeB rejects the Radio Link setup
requested by the RNC, with a cause value that triggers a new attempt using DCH
“ul_radio_resources_not_available”.
l Limitingthe acceptance of 2-ms TTI E-DCH users according to the check n10ms+4n2ms ≤
maxNbEdchCreditsForXcem, which is a threshold, configurable between 0 and 128 by the operator. If this
check is not satisfied but the check above is fulfilled, only 10-ms TTI can be accepted, so that if the Radio
Link Setup requested by the RNC asked for a 2-ms TTI, it is rejected by the NodeB, with a cause value that
triggers a new attempt using a 10-ms TTI (“not enough User Plane Processing Resources”).
l When setting up an E-DCH call, the RNC initially favors a 2-ms TTI, provided the UE supports it. If the
NodeB rejects the Radio Link Setup Request, as described above, the RNC reattempts the establishment
using a 10-ms TTI or DCH.
This feature thus allows one to benefit from the 2-ms TTI advantages, while maintaining the possibility to still
set up up to 128 E-DCH connections, despite the limit of 32 2 ms. The threshold operates as the trade-off point
between capacity and performance. In case of high load (number of used credits above the threshold), only 10
ms is accepted. When a call previously set up using a 2-ms TTI is released or transferred to CELL_FACH state, it
frees 4 credits. If the overall load remains above the threshold, a new call will be set up using a 10-ms TTI,
consuming a single credit. Thus, progressively, 2-ms TTI calls are exchanged with 10-ms TTI calls. Conversely,
when the load decreases (goes below the threshold), 10-ms TTI calls can be progressively exchanged for 2-ms
TTI calls.
For eCEM, the same principle applies with however one major difference: the eCEM can handle as many 2 ms
TTI users as 10 ms TTI users from HW point of view.

Please notice:
l The configurable credits are defined in temporary fields. They will be replaced with correctly named
parameters later in UA09.
n maxNbEdchCreditsForXcem is reserved2 byte0

n maxNbEdchCreditsForEcem is reserved2 byte0
l They are all class 3.

xCEM:
l If HsupaCellParams::EdchMaxThroughput = MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCACXCem
l Else, if HsupaCellParams::EdchMaxThroughput ≠ MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = relativeRequestedDecodingRateLimitForCAC*
HsupaCellParams::EdchMaxThroughput
eCEM
l If HsupaCellParams::EdchMaxThroughput = MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCACECem
l Else, if HsupaCellParams::EdchMaxThroughput ≠ MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit =
relativeRequestedDecodingRateLimitForCAC*HsupaCellParams::EdchMaxThroughput
HsupaCellParams::EdchMaxThroughput is the maximum MAC-e/i throughput per xCEM/eCEM board

defined by the resource allocation algorithm.
UCU-III
The total requested decoding rate limit per UCU board shall be directly configured as:
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCAC

If Total_requested_decoding_rate > Requested_decoding_rate_limit
Resource_limit_ind = TRUE
If Total_requested_decoding_rate <= Requested_decoding_rate_limit

Resource_limit_ind = FALSE; after a guard timer of 1 s is elapsed
The actual total requested decoding rate shall be determined per baseband board at each EDCH scheduling
interval as follows:
Total_Requested_decoding_rate = TBsum / EDCH_scheduling_interval
Where:
n TBsum comprises all transport block sizes TBi and TBj for all serving users ui and all non-serving
users uj served by one baseband board that are received within the time EDCH_scheduling_interval
regardless whether a valid E-DPDCH scheduler data packet was received or not.
n EDCH_scheduling_interval is the time between two runs of the E-DCH scheduler. It is hard-coded to
40 ms.

If “improved CAC Scheme for 2ms TTI users” is enabled, the Node B shall maintain a combined state:
Block_2msTTI_users for each radio cell:
l Block_2msTTI_users = Resource_limit_ind
If Block_2msTTI_users = TRUE:
l Onreception of NBAP Radio Link Reconfiguration Prepare message for 2-ms TTI, the Node B shall respond
with an NBAP Radio Link Reconfiguration Failure message with cause “Not enough User Plane Processing
Resources”
l Onreception of NBAP Radio Link Setup/Addition request message for 2-ms TTI, the Node B shall respond
with an NBAP Radio Link Setup/Addition Failure message with cause “Not enough User Plane Processing
Resources”
Note: In case of multiple xCEM/eCEM/UCU-III boards, if possible, non serving RLs should be set up on a
board for which Block_2msTTI_users flag is FALSE.
In case a 2-ms TTI E-DCH call cannot be admitted, the call shall be handled as follows:
l For the E-DCH serving RLS, the call shall be set up as a 10-ms TTI E-DCH call.
l Fora non-serving radio link, the failed radio link is added to the DCH active set but not added to the E-DCH
active set.

In case the DRNC receives an NBAP Radio Link Reconfiguration Failure message with cause value "Not enough
User Plane Processing Resources", it shall send the RNSAP Radio Link Reconfiguration Failure message with
cause value "E-DCH TTI2ms not supported" to the SRNC.
The SRNC shall reconfigure to 10-ms TTI and resend the request message. If this fails too, the SRNC shall fall
back to DCH.
In case the DRNC receives an NBAP Radio Link Setup/Addition Failure message with cause value "Not enough
User Plane Processing Resources", it shall send the RNSAP Radio Link Setup/Addition Failure message with
cause value "E-DCH TTI2ms not supported" to the SRNC.
The failed radio link is added to the DCH active set but not added to E-DCH active set. The DRNC informs the
SRNC by setting the corresponding E-DCH IE to FALSE in the response message.

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

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:
l RAB assignment (to establish or to release)
l IU release
l Primary cell change
l Inter-RNC UE involved Hard Handover
l Alarm Hard Handover
HSDPA is directly reconfigured into DCH whereas 2 steps can be provisioned for HSUPA through
edchToDchFallbackSteps parameter:
l MonoStep to directly reconfigure HSUPA into DCH
l MultiStep to try and reconfigure first into HSDPA (and then into DCH in case of HSDPA CAC failure)

When Cell/URA_PCH states are activated, Always-on mechanism is using 3 steps for the downsize part:
l 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
l Step2: 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
l 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.

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:
l timerT1ForHsdpaAndEdch for Cell_DCH to Cell_FACH transition
l timerT2 for Cell_FACH to PM-Idle transition

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.

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:
l E-DCH AS is still not full
l Cellto 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.

E-DCH serving NodeB
• E-DCH serving cell:
n E-DCH serving cell = Primary Cell (ALU impl.)
n 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:
n 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:
n Same E-HICH information is transmitted to UE on all cells of the considered non-serving NodeB
included in E-DCH AS.
n Only “ACK” E-HICH is allowed.
• E-RGCH:
n 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).

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

l 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”).
l Actiontriggered: Cell ”A” is removed from the E-DCH AS and replaced by cell “B”
(provided that cell “B” supports current E-DCH Configuration).
l 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.

Primary Cell change:
When Primary Cell changes, E-DCH serving cell is changed to the new Primary Cell.
l 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.
l 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.
l E-DCH Configuration is determined by RNC at beginning of the E-DCH call,
basing on UE and E-DCH serving NodeB capabilities.
l 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/x/eCEM specificities:
iCEM and x/eCEM 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:
l iCEM handling E-DCH on E-DCH serving cell {10ms TTI, 2xSF4, IR}, “Cat 3” Ref E-TFCI table
l x/eCEM handling E-DCH on E-DCH serving cell {10ms TTI, 2xSF2, IR}, “Cat 5” Ref E-TFCI table

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.

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.

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.

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.
l 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.
l When a new primary cell is selected, the transport channel type selector is played:
n If the old primary cell was E-DCH and not the new one, the RB is reconfigured to DCH.
n If the old primary cell was not E-DCH but the new one is, the RB is reconfigured to E-DCH.
n If the new primary cell is E-DCH and the call was E-DCH, then call is kept on E-DCH.

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.

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
l E-DCH support:
l TTI capabilities (2ms or 10ms)
l 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.

In case of Intra-RNC HHO, RNC selects the target Transport Channel type based on:
l The activation flag of HSDPA HHO feature (isHsdpaHhoWithMeasAllowed)
l The activation flag of HSUPA HHO feature (isEdchHhoWithMeasAllowed)
l 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:
l HSUPA to DCH
l DCH to DCH
l Note: This parameter is not used by RNC in case of outgoing and incoming HHO (i.e. Inter-RNC HHO).
l IfHSxPA 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).

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:
l The HSxPA-capabilities of the mobile
l 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:
l an SRNS relocation if parameter isInterFreqHandoverOverIurAllowed = False, or
la Reconfiguration to uplink and downlink DCH and handover over Iur if parameter
isInterFreqHandoverOverIurAllowed = True

In case of inter-RNC handover with Iur the handover is either performed through:
l an SRNS relocation if parameter isInterFreqHandoverOverIurAllowed = False, or
la 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.

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.

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.

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:
l D-BBU: BBU managing dedicated services,
l H-BBU: BBU managing HSDPA services,
l 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:

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

The scheduling process will distribute grants to UE according to :
1. Cell’s limitations :
n the cell load level (RTWP measured periodically each 100ms)
n HW and SW resources in Node B (E-BBU capacity)
2. Fairness :
n 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
n Data payload already transferred
3. UE limitations :
n 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)
l UE with no data to transmit (inactive) will be granted ZERO_GRANT
l active UE will not be granted more than the maximum e-TFCI corresponding to the limit
DataQueueSize/Period

Only one kind of scheduler is available in UA05: the Rate Scheduler.
l Inthis scheme, all E-DCH active users (having data to transmit) are transmitting (having grants)
simultaneously.
l They share resources in a fair way,the general principle being that :
n hardware resources are shared equally between all active cells (containing at least one active user)
n hardware resources assigned to an active cell are shared equally between all active users of this cell
n the cell load (apart from R99 part) is shared equally between all active users of this cell
l From this is derived a fairness index that represents to the grant corresponding to a fair allocation between
active UE.
n 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
n 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.

A defense mechanism is introduced in the BTS :
l whenthe RoT exceeds totalRotMax plus rtwpMargin during a period greater than
trtwpTimeDetection then:
n an alarm is raised
n all active HARQ processes are acknowledged to avoid retransmissions.
l The alarm is reset when:
n 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.

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.

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.

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

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.

Document History


Page
1 What is the purpose of this feature? 7

1.1 Objectives of iMCRA 8
1.2 Behavior in UA07 10
1.3 Behavior in UA08 11
2 How does it work? 13
2.1 Call type calculation 14
2.2 Action list mapping 18
2.3 Carrier selection list processing 19
2.4 Load condition calculation 20
2.5 Target carrier selection 22
2.6 CAC failure case 25
3 Feature activation 28
3.1 RAN model 29


iMCRA step2 provides customer flexibility to define the RRC redirection policy. It also includes a new
measurement assisted mechanism for redirections.
iMCRA Step2 is a pertinent feature in a capacity context of increasing Smartphone penetration, increasing PS
Data volume, U900 deployment, carrier deployment scenarios, LTE arrival, etc.
iMCRA Step 2 introduces a new redirection algorithm as well as new configuration capabilities and
measurement assisted redirections.

The iMCRA enhances the UA07 traffic segmentation function at call establishment or in case of SRB CAC failure
by introducing an operator programmable RRC redirection matrix.
This feature will:
l enhance simultaneous load balancing between extended FDD carriers (maximum number is 12), GSM
(maximum is 1) & LTE RAT (maximum is 2).
l redirect a given call type, a group of call types deduced from the RRC information to the proper layer.
l redirect a configurable percentage of UEs to a dedicated layer.
l enhance the cell load calculation on originating carriers to ensure higher redirection success rate.
l enhance target carriers selection by ordering criteria list with condition & candidate carriers.

In UE Capability mode, only
the UE release and capabilities
are taken into account
In UE Capability and Establishment

Cause mode, the type of call
is also taken into
account
In Preferred FA Mode, only the type of

call is taken into account
Finally, in CAC Mode only,

the load is taken into account,
the call will be redirected towards the
least loaded cell

When activated, iMCRA step2 replaces the following features (meaning the user can define an action list and
carrier selection list to reproduce the function of those features):
l iMCRA Step1
l 3G/2G Redirection based on cell load (partially)
l 3G/2G Redirection for speech call
l Load Balancing between HSPA carriers (partially, iMCRA part)
GSM target cell Info List (1 to maxGSMTargetCells=32)

iMCRA CALL TYPE CALCULATION
This function calculates the iMCRA call type associated to the RRC establishment cause received in the RRC
Connection request message. It can be distinguished between iMCRA basic call types and iMCRA group call
types.
The iMCRA group call types cover a set of iMCRA basic call types.
iMCRA CARRIER SELECTION PROCESS
iMCRA has two logical sub-functions: iMCRA Service and iMCRA CAC.
iMCRA Service covers triggers of RRC Connection Request message reception.
iMCRA CAC covers failure of SRB CAC induced by any CAC failure cause.
The operator can assign one iMCRA Action List for iMCRA Service and one iMCRA Action List for iMCRA CAC per
FDD cell.
ACTION LIST MAPPING
This function provides a pointer to the iMCRA Carrier Selection List based on the iMCRA call type matching, i.e.:
l Call Type = HspaGroupCall can point to “HSPA carrier selection list”
l Call Type = DchGroupCall can point to “DCH selection list”
CARRIER SELECTION LIST PROCESSING

The Carrier Selection List consists of load conditions and target carrier process.
It permits users to configure criteria for target carrier selection.
The target carrier can contain an FDD cell or a GSM or LTE RAT or it can be empty.
LOAD CONDITION CALCULATION
This function will verify the Load Condition to apply for the associated target carrier list.
TARGET CARRIER LIST PROCESS
This function will select a suitable target carrier for redirection among the list of target carriers fulfilling the load
condition.

iMCRA Basic Call type and iMCRA Group Call type calculation can be split into several steps:
l Step1 RRC message derives “RRC cause Types”
l Step2 RRC cause types mapped to Basic call types
l Step3 Basic call types simplified to Group call Types

Group Call Types are listed as follows:
l MO CS Group Call: Mobile originated CS voice call over DCH or HSPA and mobile originated CS
conversational calls, if established by a UE < Rel-6.
l CS Group Call: Mobile originated or terminated CS voice or data call over DCH or HSPA.
l and Mobile originated or terminated Conversational Calls if established by a UE < Rel-6.
l DCH Group Call: CS or PS call over DCH.
l HSPA Group Call: CS or PS call over HSPA.
l PS Data Group Call: PS call over DCH or HSPA.
l CS/PS Group Call: CS or PS call over DCH or HSPA.
l All Group Call: CS or PS call over DCH or HSPA or signaling only connections.

Basic Call Types are listed as following:
l MO CS Voice Call: Mobile originated CS voice call over DCH (UEs > = Rel-6) except Ues which are VoHSPA
capable
l MT CS Voice Call: Mobile terminated CS voice call over DCH (UEs > = Rel-6) except UEs which are VoHSPA
capable
l MO CS Conversational Call: Mobile originated CS voice or data call over DCH (UEs <Rel-6)
l MT CS Conversational Call: Mobile terminated CS voice or data call over DCH (UEs <Rel-6)
l CS Voice Call: Mobile originated or terminated CS voice call on DCH, if the use of RRC establishment cause
is disabled (UEs > = Rel-6)
l CS Data Call: Mobile originated or terminated CS data call on DCH, if the use of RRC establishment cause is
disabled (UEs > = Rel-6)
l PS DCH Call: PS data call over DCH
l HSDPA Data Call: PS data call over HSDPA.
l HSxPA Data Call: PS data call over HSPA
l DC Data Call: PS data call over HSPA and dual cell option
l LTE Data Call: PS data call over HSPA and LTE redirection option
l Other Call: Signaling connections (e.g. location registrations). If the operator has disabled the use of the
RRC establishment cause by setting isRedirectionBasedOnEstablishmentCause to FALSE , then “Other
Call” includes all calls for UEs < Rel-5 and all calls for Rel-5 UEs in CS domain (for all Rel-5 UEs in the PS
domain “HSDPA Data Call” is assumed).

This function provides a pointer to the iMCRA Carrier Selection List based on the iMCRA call type matching. The
calculated iMCRA call type shall be matched with configured call type in the action list per action (basic call types
or group call types).
The first action in the list has the highest priority. Thus basic call types should be configured first before actions
for group call types. For the redirection of a certain percentage of calls according to the "Redirect Percentage"
field in the action list, the following formula applies:
l Redirect if (RedirectPercentage + (#call * RedirectPercentage) % 1 >= 1); if the load condition is fulfilled
and the call is selected according to the formula, a selected target carrier is selected. Otherwise, the RNC
will check the next load condition, if configured.
50 Action Lists can be defined at amaximum. Each action list may contain maximum 15 actions.
Carrier Selection
Algorithm
N
Call Type
in Action List?
Select next Action

List entry Y
Carrier
Selection List
Processing
N
Output: Target Carrier
End of Y Target Carrier (FDD cell or RAT)
Action List? empty?
Y N
Update redirection
percentage figure
N Redirection
required according
to percentage
Target carrier = figure? Target carrier =
originating cell originating cell
Y
End

After matching the calculated iMCRA call type with one redirection action configured in the action list, RRC
Redirection Decision shall process its associated "Carrier Selection List”.
The Carrier Selection List contains a load Rule per instance plus an associated list of allowed target carriers
(target carrier list). The target carrier list includes FDD carriers or GSM or LTE RAT.
The following figure provides an example to the Carrier Selection List. The following conditions apply:
l The first instance (#1) of the Carrier Selection List has the highest priority and is processed first (the
conditions stored in the instances (#1, #2…#y) of the Carrier Selection List are implicitly linked by an “OR”
operation = If the load condition does not match or no target carrier has been found, then the next
instance of the Carrier Selection List is processed).
lA carrier selection rule can comprise up to four load conditions, which are linked by a logical AND operation,
i.e. if all the conditions of a rule are fulfilled, the carrier(s) in the target carrier list are applied.
l Upto 150 Carrier Selection Lists can be defined per RNC (=three on average per Action List). Each Carrier
Selection List can contain up to 20 Rules with up to 4 conditions each.

This function will verify the Load Condition to apply for the associated target carrier list. The
load condition in the Carrier Selection List comprises:
lA frequency reference to an FDD frequency (F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, Fo); carrier is
a reference to a frequency object defining the carrier (F1 – F12) or it references to the originating carrier
(Fo).
lA load type (Single and Combined load type)
l An operator (=, <=, <, >, >=, TRUE); If the "operator" field of the condition is set to TRUE, then the load
condition is always true;
lA load value (Green < Yellow< Red < Black)
The RNC supports the following single load types as part of a load condition in the Carrier Selection List:
l DL POWER Load; DL OVSF Load; DL IUB Load; DL CEM Load; UL CEM Load; UL RX POWER Load; HSDPA
Load;
The RNC supports the following combined load types as part of a load condition in the Carrier Selection List:
l CEM Load = max (DL CEM and UL CEM loads); DL RADIO Load = max (DL POWER and DL OVSF loads); DL
DCH Load = max (DL RADIO, DL CEM and DL IUB loads); UL DCH Load = max (UL RX POWER and UL CEM
loads); DCH Load = max (DL DCH and UL DCH loads); HSDPA UL DCH Load = max (HSDPA Load and UL
DCH Load); HSPA Load = HSDPA load; TOTAL Load = max (DCH and HSPA loads); CALL TYPE Load - DCH
or HSDPA load;

If the target carrier list contains two or more applicable FDD cells, the following sorting rules are applied:
1. Less loaded FDD cells shall be ranked highest;
2. Among FDD cells with equal load, the RNC shall rank the originating cell first if it is applicable;
3. Among FDD cells with equal load without originating cell, the RNC shall rank the FDD cells sorted by their
dlFrequencyNumber from low to high (round robin).
The load criterion to be used for load comparison depends on the call type, the UE´s HSDPA/HSUPA capability
and the FDD cell capability. The following load criteria are fixed coded:
Call Type belonging to Sort Criterion

1st 2nd 3rd Comment
DCH group call type DCH Load Calculated DCH
cell load value
HSPA group call type HSPA Load UL DCH Load FDD cell needs to
support HSDPA. If cell
does not support
HSDPA then use DCH
load.
The 2nd and 3rd criteria are only applied, if the previous selection criterion results in multiple cells with the same
load. The calculated DCH cell load value is derived from the individual cell loads and their weighted load color.

In case of configured GSM target carrier, the RNC cannot check the GSM inter-RAT capability of the UE upon
RRC connection request. Nevertheless, the UE is redirected to GSM, which is performed by the UE via intra-
PLMN cell selection procedure. If the UE does not support the deployed GSM band, it will repeat the RRC
connection request.

Each FDD cell refers to two action lists: one is used for iMCRA Service actions and the other is used for iMCRA
CAC actions.
Each action of an action list references to a Carrier Selection List.
Multiple FDD cells can point to the same action list / Multiple actions can reference to the same Carrier Selection
List.

Document History
01 2009-02-26 El Abed, Achrafe First edition

Charneau, Jean-Noël


Page
1 HSDPA : CQI Mapping Tables (3GPP) 7

1.1 HSDPA CQI Mapping Tables 8
1.2 CQI mapping table A for UE categories 1 to 6 9
1.3 CQI mapping table B for UE categories 7 to 8 10
1.4 CQI mapping table C for UE category 9 11
1.5 CQI mapping table D for UE category 10 12
1.6 CQI mapping table E for UE category 11 and 12 13
1.7 HSDPA CQI Mapping Table F 14
1.8 HSDPA CQI Mapping Table G 15
1.9 HSDPA CQI Mapping Table H & I 16
2 HSUPA : E-TFCI and Grant 17
2.1 E-DCH Transport Blocks Tables 18
2.2 E-DPDCH power vs Transport Block Size 19
2.3 Absolute Grant Table 20
3 Flexible HSDPA modulation usage versus codes (xCEM) 21
3.1 HSDPA modul. and code / CQI : 25.214 Mapping Table 22
3.2 Flexible resources usage 23
3.3 TFRC Selection for Flexible HSDPA 24


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 :
l Reference E-TFCI (Transport block size index, range [0-127])
l 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 :
l Reference E-TFCI (Transport block size index, range [0-127])
l 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 .

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.

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:
l QPSK over more than 5 codes is made available for UE category 8 or 10 in low or medium radio
condition.
l 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).

The TFRC selection in xCEM is based on a look up tables (LUT) with four input variables
l Modulation capability of the UE
l Maximal MAC-hs payload size given by the UE capability and the queue size
l The number of available codes limited by the UE capability (W)
l Spectral efficiency (SE)
The spectral efficiency is a metric how many bits/code/TTI can be transmitted successfully in a TTI
l The CQI is not directly used in the MAC-hs but mapped to a SNR per code based on PCPICH +
measurement power offset
l 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)
l In power limited situation QPSK is preferable (lower Es/N0)
è more codes but increases the transport block size for the same power
l 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

n Spectral Efficiency is based on the available power
n In power limited situation, Spectral Efficiency is low è QPSK is selected
n In non-power limited situation, Spectral Efficiency is high è16-QAM is selected

Document History
01 2010-04-30 Elsner, Bernhard First edition

Charneau, Jean-Noël

# CS Circuit Switch
16-QAM 16 – Quadrature 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 FA Frequency Allocation
BCCH 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

I 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 Key Performance Indicator PCPCH Physical Common Control CHannel
Ksps 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
RNSAP Radio Network Subsystem 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 Session Management VCC Virtual Channel Connection
SNR Signal to Noise 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

All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent
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

Tmo18256 v2.0 Hspa Algo SG Ua08 Ed2 Ce PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tmo18256 v2.0 Hspa Algo SG Ua08 Ed2 Ce PDF

Uploaded by

Copyright:

Available Formats

Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

1. HSxPA Algorithms Description

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

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

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

3.3 HSDPA BLER as per 3 GPP 71

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

l Adaptive Modulation and Coding

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

l Flow control procedure to manage Node B buffering

Some new L1 new functionalities are introduced compared to R4:

Other features related to HSDPA:

l It brings the capability to segment MAC-d PDUs

l 64-QAM requires Mac-ehs

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Note that MIMO is not supported in UA08.1

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

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

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

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

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

The two cells must be on the same nodeB.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

The control information is limited to TPC bits only:

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

l UE Capability Indication IE = ‘HS-DSCH+E-DCH’

l Access Stratum Release Indicator IE = ‘REL-7’ (or later)

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

If Fair Sharing is activated:

If Fair Sharing is not activated:

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

OLPC: Outer Loop Power Control

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.

Copyright © 2013 Alcatel-Lucent. All Rights Reserved.