UMT IRC APP 016664 - HSDPA Engineering Guide v01.06 EXT Nortel

HSDPA Engineering Guide
Document number: UMT/IRC/APP/016664

Document issue: 01.06 / EN
Document status: Preliminary
Date: 20/Jan/2006
External Document
Copyright
2005 Nortel Networks, All Rights Reserved.

Printed in France
NORTEL CONFIDENTIAL
The information contained in this document is the property of Nortel Networks. Except as specifically authorized in
writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential
and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for
evaluation, operation and maintenance purposes only.
The content of this document is provided for information purposes only and is subject to modification. It does not
constitute any representation or warranty from Nortel Networks as to the content or accuracy of the information
contained herein, including but not limited to the suitability and performances of the product or its intended
application.
This is the Way. This is Nortel, Nortel, the Nortel logo, and the Globemark are trademarks of Nortel Networks. All
other trademarks are the property of their owners.
Nortel confidential
UMT/IRC/APP/016664 01.06 / EN Preliminary 20/Jan/2006 Page 2/141
PUBLICATION HISTORY
20/Jan/2005
Issue 01.06 / EN, Preliminary
Document update / UA4.2 CuR

25/Nov/2005
Issue 01.05 / EN, Draft
Document update / External Version

18/Oct/2005
Document updated after review for external version / External Version

04/Oct/2005
Document updated for W.39 Load / External Version

02/Sep/2005
Document updated after review

19/Aug/2005
Document Creation

Nortel confidential
CONTENTS
1 INTRODUCTION............................................................................................................................9
1.1 OBJECT....................................................................................................................................9
1.2 SCOPE OF THIS DOCUMENT .......................................................................................................9
1.3 NOMENCLATURE.......................................................................................................................9
2 RELATED DOCUMENTS............................................................................................................11
2.1 REFERENCE DOCUMENTS........................................................................................................11
3 HSDPA OVERVIEW....................................................................................................................12
3.1 SYSTEM OVERVIEW.................................................................................................................12
3.1.1 New transport and physical channels ...........................................................................14
3.1.2 Fast link adaptation.......................................................................................................16
3.1.3 Fast Retransmission Mechanism (HARQ) ....................................................................17
3.1.4 Fast scheduling.............................................................................................................22
3.2 DEPLOYEMENT SCENARIOS.....................................................................................................26
3.2.1 Dual Carrier ...................................................................................................................26
3.2.2 Single carrier .................................................................................................................27
3.3 HSDPA RESOURCES..............................................................................................................27
3.3.1 OVSF Codes .................................................................................................................27
3.3.2 Power ............................................................................................................................28
3.3.3 HSDPA Channels & CQI...............................................................................................29
3.4 UE CATEGORIES ....................................................................................................................36
3.5 CALL MANAGEMENT................................................................................................................37
3.5.1 Traffic segmentation......................................................................................................38
3.5.2 HSDPA CAC .................................................................................................................41
3.5.3 Call Setup (Dataflow) ....................................................................................................43
3.5.4 Call Release (Dataflow) ................................................................................................45
3.5.5 HSDPA related Transitions ...........................................................................................46
4 HSDPA CONFIGURATION.........................................................................................................51
4.1 RAN MODEL AND PARAMETERS ..............................................................................................51
4.1.1 RRM Impact ..................................................................................................................51
4.1.2 BTS Impact....................................................................................................................64
4.1.3 IuB Impact .....................................................................................................................65
4.2 HSDPA ACTIVATION...............................................................................................................66
6 UA4.2 HSDPA SPECIFIC FEATURES & IMPACT ON EXISTING ALGORITHMS...................68
6.1 ALWAYS ON ...........................................................................................................................68
6.1.1 Mechanism....................................................................................................................68
6.1.2 Activation & Mode .........................................................................................................68
6.1.3 Reminder for timer usage..............................................................................................72
6.1.4 Parameters Settings and Recommendations ...............................................................72
6.2 IRM ALGORITHMS...................................................................................................................73
6.2.1 Irm Scheduling Downgrade/Upgrade Interworking.......................................................73
6.2.2 iRM Cac/iRM Pre-Emption Interworking .......................................................................73
Nortel confidential
6.2.3 RB Adaptation Interworking ..........................................................................................73
6.3 MOBILITY PROCEDURES..........................................................................................................73
6.3.1 Intra-Frequency Mobility................................................................................................74
6.3.2 Inter-Frequency Mobility................................................................................................76
6.3.3 Inter-System Mobility.....................................................................................................76
6.3.4 U-Plane Traffic Handling...............................................................................................77
6.3.5 Summary of inter-frequency and inter-RAT scenarios..................................................78
6.4 POWER MANAGEMENT ............................................................................................................78
6.4.1 Introduction....................................................................................................................78
6.4.2 Flexible power management feature.............................................................................78
6.4.3 HS-SCCH power control feature...................................................................................94
6.4.4 Parameters Settings and Recommendations ...............................................................95
6.5 TRANSPORT ...........................................................................................................................98
6.5.1 Iub Bandwidth Limitation: Why this feature is needed?................................................98
6.5.2 Feature Description.......................................................................................................99
6.5.3 Case of Drift Iur .......................................................................................................... 101
6.5.4 Parameters Settings and Recommendations ............................................................ 102
7 HSDPA THROUGHPUT OPTIMIZATION ................................................................................ 108
7.1 POWER ALLOCATION AND USER THROUGHPUT...................................................................... 108
7.2 CQI SELECTION AT UE........................................................................................................ 111
7.3 CQI ADJUSTMENT BASED ON BLER...................................................................................... 111
7.4 BTS CREDIT ALLOCATION..................................................................................................... 113
7.5 HARQ RETRANSMISSIONS ................................................................................................... 113
7.6 RLC SETTINGS FOR UL DCH............................................................................................... 114
7.7 DL RLC SETTINGS FOR HSDPA........................................................................................... 117
7.8 OPTIMISED TCP SETTINGS................................................................................................... 117
7.9 PARAMETERS SETTINGS ...................................................................................................... 118
8 HSDPA CAPACITY ASPECTS................................................................................................ 119
8.1 CEM CAPACITY................................................................................................................... 119
8.1.1 Product limits.............................................................................................................. 119
8.1.2 Capacity analysis ....................................................................................................... 119
9 PRODUCT RECOMMENDATIONS.......................................................................................... 129
9.1 HSDPA COMPATIBILITY WITH UTRAN NETWORK ELEMENTS................................................. 129
9.1.1 RNC............................................................................................................................ 129
9.1.2 BTS ............................................................................................................................ 129
9.2 HSDPA COMPATIBILITY WITH MODULES ............................................................................... 130
9.2.1 RNC............................................................................................................................ 130
9.2.2 BTS ............................................................................................................................ 130
9.3 HSDPA SYSTEM IMPACT................................................................................................ 131
9.3.1 RNC functions ............................................................................................................ 131
9.3.2 BTS functions............................................................................................................. 131
9.4 HSDPA AND UTRAN INTERFACES ...................................................................................... 135
9.4.1 Radio Interface........................................................................................................... 135
9.4.2 IuB.............................................................................................................................. 135
9.4.3 Iu-CS.......................................................................................................................... 136
9.4.4 Iu-PS .......................................................................................................................... 136
Nortel confidential
9.4.5 Iu-R............................................................................................................................. 136
9.4.6 Iu-PC.......................................................................................................................... 136
10 ABBREVIATIONS AND DEFINITIONS.................................................................................... 137
10.1 ABBREVIATIONS................................................................................................................... 137
10.2 DEFINITIONS........................................................................................................................ 140

Nortel confidential
TABLES
Table 1: Number of processes per UE category 17
Table 2: RV coding for 16QAM 18
Table 3: RV coding for QPSK 18
Table 4: RV update table in the MIR case (Trv[i]) 19
Table 5: RV update table in the PIR case (Trv[i]) 19
Table 6: UE capabilities 37
Table 7: RB Configuration and system behaviour 38
Table 8: RRC Connection Request and suitable layer 40
Table 9: HSDPA related Transitions 47
Table 10 : Always-on timer usage 72
Table 11: CQI update summary 91
Table 12: CQI Mapping 92
Table 13: HS-SCCH power offset table according the averaged CQI 95
Table 14: UL rate required vs. DL rate 117
Table 15: Parameters summary for optimized throughput 118
Table 16: H-BBU limitations 119

Nortel confidential
FIGURES
Figure 1: R99 principle ......................................................................................................................................... 12
Figure 2: HSDPA principle................................................................................................................................... 12
Figure 3: HSDPA layer2/layer1 flows .................................................................................................................. 13
Figure 4: Mac-hs entity on UTRAN side.............................................................................................................. 13
Figure 5: Transport channel configuration............................................................................................................ 15
Figure 6: HSDPA channels and associated R99 channels..................................................................................... 15
Figure 7: Example of AMC : Throughput versus Ior/Ioc (radio condition) .......................................................... 16
Figure 8: RV parameters assignment algorithm.................................................................................................... 20
Figure 9: ACK/NACK/DTX management for HARQ processes.......................................................................... 21
Figure 10: Scheduler overview............................................................................................................................. 23
Figure 11: HSDPA on dedicated layer.................................................................................................................. 26
Figure 12: Example of OVSF tree usage with HSDPA ........................................................................................ 27
Figure 13: OVSF allocation strategy..................................................................................................................... 28
Figure 14: Timing relationship at NodeB between physical channels .................................................................. 29
Figure 15: HS-SCCH structure ............................................................................................................................. 30
Figure 16: HS-PDSCH structure........................................................................................................................... 30
Figure 17: HS-DPCCH structure .......................................................................................................................... 31
Figure 18: CQI Processing.................................................................................................................................... 32
Figure 19: CQI offset computation based on BLER............................................................................................. 34
Figure 20: Scheduler and Flow Control disabled.................................................................................................. 36
Figure 21: HSDPA Call setup / initial connection (Cell_DCH)............................................................................ 43
Figure 22: HSDPA Call setup / RAB allocation phase (call establishment done on DCH).................................. 44
Figure 23: Call release (RAB release case)........................................................................................................... 46
Figure 24: RRM new HSDPA subtree .................................................................................................................. 51
Figure 25: FDDCell HSDPA Related new objects ............................................................................................... 51
Figure 26: HSDPARncConf subtree ..................................................................................................................... 53
Figure 27: HSDPA Radio Bearer subtree ............................................................................................................. 55
Figure 28: HSDSCHx4SRBDCCH3_4K subtree.................................................................................................. 58
Figure 29: HSDPA RLC subtree........................................................................................................................... 60
Figure 30: HSDPA UsHoConf subtree ................................................................................................................. 61
Figure 31: HSDPA BTS new object ..................................................................................................................... 64
Figure 32: IuB HSDPA new object....................................................................................................................... 65
Figure 33: Always-on for HSDPA (degraded2AlwaysOn mode) ......................................................................... 70
Figure 34: Always-on for HSDPA (releaseOnly mode)........................................................................................ 71
Figure 35: HS-DSCH link is deleted and re-established on new primary (nominal case) .................................... 75
Figure 36: Summary of Inter-freq/inter-RAT mobility......................................................................................... 78
Figure 37: Power allocation at RNC level ............................................................................................................ 79
Figure 38: Physical shared channel reconfiguration message............................................................................... 81
Figure 39: Power allocation at NodeB level ......................................................................................................... 81
Figure 40: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)........................... 83
Figure 41: Common measurement ........................................................................................................................ 84
Figure 42: Power measurement process................................................................................................................ 85
Figure 43: Power distribution between HS-DSCH and HS-SCCH channels ........................................................ 86
Figure 44: measurementPowerOffset transmission............................................................................................... 87
Figure 45: HS-DSCH power management for 1st transmission............................................................................ 89
Figure 46: Mac-hs transport block adaptation according to the number of Mac-d PDU to transmit .................... 91
Figure 47: HS-DSCH power management for retransmission.............................................................................. 93
Figure 48: Remaining power for multi-users per TTI scheduling......................................................................... 94
Figure 49: HS-SCCH power control overview..................................................................................................... 95
Figure 50: discard and backpressure thresholds.................................................................................................... 99
Figure 51: example of traffic regulation with backpressure................................................................................ 101
Figure 52: feature behaviour on Iur .................................................................................................................... 102
Figure 53: example of transport topologies "with ATM priority"....................................................................... 102
Figure 54: example of transport topology "without ATM priority".................................................................... 103
Figure 55: User multiplexing in Code and Time domains .................................................................................. 108
Nortel confidential
Figure 56: User throughput vs. HSDPA power, UE cat 6................................................................................... 109
Figure 57: HARQ BLER vs. User RLC Throughput, UE cat 12, drive test........................................................ 111
Figure 58: User throughput vs. BLER on HS-PDSCH, UE cat 12 ..................................................................... 112
Figure 59: User throughput vs. status prohibit timer, UE cat 6........................................................................... 115
Figure 60: User throughput vs. polling timer vs. UL BLER............................................................................... 115
Figure 61: User throughput vs. receive window size at UE................................................................................ 116
Figure 62: H-BBU resource allocation modes .................................................................................................... 120
Figure 63: iCEM consumption for a PS RB DL 128 kbps / UL 384 kbps (R99 Case) ....................................... 121
Figure 64: iCEM consumption for a PS RB HSDPA / UL 128 kbps (HSDPA Case)......................................... 122
Figure 65 : Comparison between the CEM R99 Capacity and the CEM HSDPA Capacity for same input traffic
and same CEM configuration (same hardware) .......................................................................................... 122
Figure 66: CEM Capacity vs. HSDPA Penetration............................................................................................. 123
Figure 67: CEM Admission Blocking type (R99 or HSDPA) versus HSDPA Penetration Factor ..................... 124
Figure 68: CEM Capacity figures for different configurations depending on the HSDPA penetration factor (UL
64 kbps)....................................................................................................................................................... 124
Figure 69: Admission blocking by service vs HSDPA penetration factor .......................................................... 126
Figure 70: CEM Capacity figures for different configurations depending on the HSDPA penetration factor (UL
128 kbps)..................................................................................................................................................... 127

Nortel confidential
1 INTRODUCTION
1.1 OBJECT
The objective of this document is to describe from an engineering point of view the
HSDPA system.
This includes a system description, configuration aspect and optimization settings.

1.2 SCOPE OF THIS DOCUMENT
The following features are described in the document:

Feature Id Feature description Section
27935 Multi carrier HSDPA Traffic segmentation 3.5.1
27942 Always-on On HSDPA 6.1
27936
HSDPA Intra-frequency Mobility
6.3.1
27937
HSDPA Alarm Mobility - inter RAT: 3G to 2G only and blind
6.3.3
27943
Iub Bandwidth Limitation Handling
6.5
27930 HSDPA Service
3.5
27931 HSDPA Flexible resources Mgt
6.4.2
27932 HSDPA Step 1
9
27939 HS-SCCH Power Control
6.4.3
27940 H-BBU Pool Across Sectors
9
27941 Node-B Module Operation For HSDPA
9
27945 HSDPA Radio Bearer
3.1.1

1.3 NOMENCLATURE
The parameter names are written in bold italic.
The objects names are written in bold.
The parameters properties are presented as follow:
Nortel confidential
Parameter Object
Range & Unit
User
Class
Granularity
Value

The protocol messages are written in CAPITAL LETTERS.
The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.
The datafill rules are presented as the following:
Rule:

The system restrictions are presented as the following:
Restriction:

The engineering recommendations on parameter value are presented as the
following:
Engineering Recommendation:

Some parameters values can not be provided in this document; in that case, the
following abbreviations are used:
o N.A.: Not Applicable.
o N.S.: Not Significant.
o O.D.: Operator Dependant (depends on operator network specific
configuration. Example: addressing parameters).

Nortel confidential
2 RELATED DOCUMENTS
2.1 REFERENCE DOCUMENTS
[R1] UMT/DCL/DD/0020 UTRAN Parameters User Guide
[R2] 3GPP TS 25.308 UTRA High Speed Downlink Packet Access
(HSPDA); Overall description; Stage 2
[R3] 3GPP TS 34.108 Common Test Environments for User Equipment
(UE) Conformance Testing
[R4] 3GPP TS 25.212 Multiplexing and channel coding (FDD)
[R5] 3GPP TS 25.214 Physical layer procedures (FDD)
[R6] UMT/BTS/DD/012447 NodeB HSDPA functional specification
Commercial release
[R7] UMT/BTS/DD/008196 Mac-hs Scheduler
[R8] UMT/BTS/DD/012545 Variable Length CQI averaging
[R9] UMT/IRC/APP/0164 Iub transport Engineering Guide
[R10] NTP 411-8111-575 HSDPA Feature Activation Procedure
[R11] UMT/SYS/DD/013319 HSDPA System Specification

Nortel confidential
3 HSDPA OVERVIEW
3.1 SYSTEM OVERVIEW
3GPP has standardized HSDPA in Release 5 [R2] in order to increase maximum user
throughput for downlink packet data (streaming, interactive and background traffic
classes) and decrease downlink packet transmission delay. This Release 5 is fully
compatible with the previous Release 99 (R99).

In R99, data are transmitted on a dedicated channel with a given user throughput and
a downlink transmitted power controlled according to the radio conditions:

Power Power
Control Control
Data Power
Unused Power Data
Unused
Same Throughput

Figure 1: R99 principle

In HSDPA, data are transmitted on a shared channel by using all the available power
and by controlling the downlink user throughput according to the radio conditions:

Rate Rate
Adaptation Adaptation 100% Power
100%

Figure 2: HSDPA principle

Typically, a user in good radio conditions will receive his data with a high bit rate
whereas a user in bad radio conditions will receive his data with a lower bit rate.

The efficiency of this rate adaptation is due to a new MAC entity, the Mac-hs layer,
located in the NodeB (see the two following figures), near the physical channel, which
allows a high reactivity in the resource allocation according to the RF conditions
Nortel confidential
changes. This Mac-hs layer manages the scheduling of users and the retransmissions
of packets.

HS-DSCH
Associated
Uplink
Signaling
Associated
Downlink
Signaling
DCCH DTCH DTCH MAC Control MAC Control CCCH CTCH BCCH PCCH MAC Control
RRC (RNC)
RRC (RNC)
RLC (RNC)
RLC (RNC)
HS-PDSCH
FACH
S-CCPCH
FACH
S-CCPCH
RACH
PRACH
RACH
PRACH
DSCH
PDSCH
DSCH
PDSCH
DCH
DPCH
CPCH
PCPCH
CPCH
PCPCH
PCH
S-CCPCH
PCH PCH
S-CCPCH HS-DPCCH HS-SCCH
MAC-c/sh
(C-RNC)
MAC-c/sh
(C-RNC)
DCH
DPDCH/DPCCH
R99 L1: Channel Coding / Multiplexing (NodeB)
R99 L1: Channel Coding / Multiplexing (NodeB)
R5 L1: HSDPA (NodeB)
R5 L1: HSDPA (NodeB)
MAC-d
(S-RNC)
MAC-hs
(NodeB)
MAC-hs
(NodeB)

Figure 3: HSDPA layer2/layer1 flows

Figure 4: Mac-hs entity on UTRAN side

HSDPA benefits are based on:
New transport and physical channels.
Nortel confidential
Fast link adaptation.
Fast retransmission mechanism (HARQ).
Fast scheduling.

3.1.1 NEW TRANSPORT AND PHYSICAL CHANNELS
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.

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 are for him and to decode them
correctly.

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.

HS-DSCH channel is always associated to a DCH. This induces the following
transport channel configuration for any UE established in HSDPA (see the following
figure):
one DCH handling the signaling in both UL and DL,
one DCH transporting the UL traffic,
one HS-DSCH for the DL traffic.

Nortel confidential

Figure 5: Transport channel configuration

The following figure summarizes the different channels needed for a HSDPA call:

NodeB
HSDPA UE
HS-PDSCH for data (I/B) traffic HS-PDSCH for data (I/B) traffic
HSDPA channels HSDPA channels
HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-SCCH signaling part (UE id, ) associated
to HS-PDSCH
HS-DPCCH Feedback information HS-DPCCH Feedback information
Associated DPCH for data, speech + SRB traffic Associated DPCH for data, speech + SRB traffic

Figure 6: HSDPA channels and associated R99 channels

In this release of HSDPA, UE categories 6 and 12 are supported, allowing a maximum
data rate in downlink of respectively 3.65Mbit/s and 1.8Mbit/s. As a consequence the
following radio bearers are be supported:
Interactive or background / UL:8 DL: [max bit rate for UE categories 12 and 6]
/ PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH (see below)
Interactive or background / UL:32 DL: [max bit rate for UE categories 12 and
6] / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
Nortel confidential

The maximum bit rate that can be achieved in the UL can be the bottleneck for the
maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP
acknowledgements due to low bandwidth in the UL will limit the DL throughput, even if
the RF conditions would allow more.

In UA04.2, Nortel implements the RB adaptation feature that dynamically adapts the
UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from
32kbps up to 384kbps, but 8kbps is not eligible. Therefore, although UL:8 DL:[max bit
rate for UE categories 12 and 6] will be allocated by the RNC if UL:8 is explicitly
requested in the RAB assignment, it is not recommended to do so, otherwise the user
will experience low throughput in the DL.

3.1.2 FAST LINK ADAPTATION
Every TTI, Adaptive Modulation and Coding (AMC) is updated according to the radio
conditions experienced by the UE and his category (see UE categories section).
AMC (number of codes, code rate and modulation type) is chosen among 30
possibilities corresponding to one CQI in order to reach the maximum bit rate while
guarantying a certain QoS (10% BLER for example). All UE categories have to
support QPSK and 16QAM modulation except categories 11 and 12 which only
support QPSK (16QAM modulation allowing higher bit rate). The following figure
illustrates the AMC by showing the throughput versus the radio conditions (Ior/Ioc):

QPSK
QPSK
QPSK
16QAM
16QAM
-20 -15 -10 -5 0 5
0
100
200
300
400
500
600
700
800
Ior/Ioc (dB)
T
h
r
o
u
g
h
p
u
t

(
k
b
p
s
)
AMC Illustration
QPSK
QPSK
QPSK
16QAM
16QAM
QPSK
QPSK
QPSK
16QAM
16QAM
-20 -15 -10 -5 0 5
0
100
200
300
400
500
600
700
800
Ior/Ioc (dB)
T
h
r
o
u
g
h
p
u
t

(
k
b
p
s
)
AMC Illustration

Figure 7: Example of AMC : Throughput versus Ior/Ioc (radio condition)

Nortel confidential
3.1.3 FAST RETRANSMISSION MECHANISM (HARQ)
The HARQ (Hybrid Automatic Repeat Query) is a retransmission mechanism which
consists in:
retransmitting by the NodeB the data blocks not received or received with
errors by the UE;
combining by the UE the transmission and the retransmissions in order to
increase the probability to decode correctly the information.

3.1.3.1 NUMBER OF HARQ PROCESSES
There is an HARQ process assigned per transport block for all the transmissions. The
number of processes per UE is limited and depends on its category. The number of
processes per UE category is the one given in [R3]:

Ue Category 1 2 3 4 5 6 7 8 9 10 11 12
Number of HARQ Processes 2 2 3 3 6 6 6 6 6 6 3 6
Table 1: Number of processes per UE category

Once this number is reached, the UE should not be eligible by the scheduler for new
transmissions unless one of them is reset (ACK reception, discard timer expiration,
max number of retransmissions reached).

3.1.3.2 RV PARAMETERS
The IR (Incremental Redundancy) 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
(see [R4] for details):
s is used to indicate whether the systematic bits (s=1) or the non-systematic
bits (s=0) are prioritized in transmissions.
r (range 0 to rmax-1) changes the initialization Rate Matching parameter value
in order to modify the puncturing or repetition pattern.
The b parameter 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 for averaging
LLR at the turbo decoder input.

Nortel confidential
These three parameters are indicated to the UE by the Xrv value sent on the HS-
SCCH (see section 3.3.3 "HSDPA Channels & CQI). The coding tables of Xrv are
given hereafter:

Xrv (Value) s r b
0 1 0 0
1 0 0 0
2 1 1 1
3 0 1 1
4 1 0 1
5 1 0 2
6 1 0 3
7 1 1 0
Table 2: RV coding for 16QAM

Xrv (Value) s r
0 1 0
1 0 0
2 1 1
3 0 1
4 1 2
5 0 2
6 1 3
7 0 3
Table 3: RV coding for QPSK

The determination of the s, r and b parameters will be based on the Xrv update, but
not necessarily in the increasing order. The update indeed follows a predefined order
stored in a table (called hereafter Trv). The only requirement to fill this table is that
Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be the
nominal configuration).

A configurable parameter (CC/PIR/MIR) indicates the possibility of switching between
Chase Combining, a Partial IR or a mix between Partial and Full IR sequence. It
implies that 3 different tables must be stored (see below), chosen accordingly:
Nortel confidential
The Chase Combining option corresponds to the first redundancy version
always applied for all (re)transmissions.
The PIR indicates that for all redundancy versions, the systematic bits must
be transmitted (blocks are self-decodable). Only the RV with s = 1 must be
taken into account.
The MIR corresponds to a sequence where both systematic and
nonsystematic bits can be punctured. All possible redundancy versions are
assumed and it corresponds to default Nortels version.

i 1 2 3 4 5 6 7 8
Xrv(QPSK) 0 2 5 6 1 3 4 7
Xrv(16QAM) 6 2 1 5 0 3 4 7
Table 4: RV update table in the MIR case (Trv[i])

i 1 2 3 4 5 6
Xrv(QPSK) 0 2 4 6
Xrv(16QAM) 6 2 5 0 4 7
Table 5: RV update table in the PIR case (Trv[i])

The rules to compute the Xrv parameters then are (see the following figure):
For the first transmission, Xrv is initialized to Trv[0].
Upon reception of a NACK, Xrv is assigned the next value in the table (once
the last value of the table, Nmax, has been set, the next value should be the
first one again).
In case of no reception of ACK/NACK (DTX indication), the parameters must
not be updated so that the same information not received by the UE should be
sent again (this ensure no systematic bits are lost, because all blocks may not
be self-decodable).

Nortel confidential
New transmission ?
Xrv = Trv[0]
k = 0
Y
N
DTX indication ? Xrv(n) = Xrv(n-1)
Y
N
k = k + 1
Xrv(n) = Trv[k mod Nmax]
Nmax = 1 (CC)
= 4 (PIR - QPSK)
= 6 (PIR 16QAM)
= 8 (MIR)

Figure 8: RV parameters assignment algorithm

3.1.3.3 STATE OF HARQ PROCESSES
The following figure describes the different states of HARQ processes and possible
actions related to these.

Nortel confidential
ACK/NACK/DTX ?
HARQ process assigned
by the scheduler
Y
Update of RV parameters
Data transmission
Wait for ACK/NACK
reception
Insertion of DTX
indication
Reset HARQ process
Remove Mac-d PDU
Update structures
Nret = Nret +1
Nret > Nret_max ?
Wait for
retransmission
NACK
DTX
N
WACK state
NACK/DTX state
ACK

Figure 9: ACK/NACK/DTX management for HARQ processes

Once a UE is scheduled, an HARQ process is assigned that may correspond to either
a new Transport Block or a retransmission. The RV parameters are computed
accordingly as described before (see RV PARAMETERS section) and data is
transmitted. The HARQ process is then waiting for feedback information
(ACK/NACK/DTX) and is set in the so-called WACK state (Waiting for
Ack/Nack/DTX). The exact timing for reception of the feedback information must be
computed thanks to the chip offset and relatively to the TTI corresponding to the
transmission.

Upon reception of the feedback information, three behaviors occur:
In case of an ACK, the HARQ process is reset and corresponding Mac-d
PDUs are removed from memory. This HARQ process can now be used for a
new transmission.
In case of a NACK, the number of retransmissions must be incremented. If the
maximum number of retransmissions is not reached, the HARQ process is set
in the so-called NACK state and then inserted in the NACK list of HARQ
processes.
In case of a DTX indication, the same actions as for a NACK reception are
done, except that a parameter must be updated to notify DTX detection (this
Nortel confidential
changes the RV parameter update, see RV PARAMETERS section). The
process is then set in the DTX state.

The processes in the NACK or DTX state are just waiting for being re-scheduled for a
new retransmission.

3.1.4 FAST SCHEDULING
3.1.4.1 PRINCIPLES
The aim of the Mac-hs scheduler is to optimize the radio resources occupancy
between users. Every TTI, it must then select Queue IDs for which data is going to be
transmitted and the amount of corresponding Mac-d PDUs to transmit.

The scheduler first receives as input every TTI the number of codes available and the
remaining power for HS-PDSCH and HS-SCCH (see POWER MANAGEMENT
section). The received ACK/NACK and CQI must also be provided to the scheduler
when available. Thanks to this information, UE capabilities, configuration parameters
provided by the RNC and taking into account the previously scheduled data, the
scheduler can select the subflows of the users to schedule in order to optimally use
available resources. The main concepts of the scheduler are:
Retransmissions are of higher priority than new transmissions and should be
scheduled first.
Users with higher priority (CmCH-PI) and better CQI are favoured and get
most part of the bandwidth.
The transport blocks should always be optimized according to the transmitted
CQI when possible (if enough codes and power are available and if theres no
CPU limitation).
No queue ID should be left starving, i.e. the scheduler should always allocate
even a small part of radio resources to all users (even those with low priority
and bad CQI).

3.1.4.2 ALGORITHM
The architecture of the scheduler is presented hereafter (see [R7] for more details on
the algorithm):
Nortel confidential

Figure 10: Scheduler overview

Before entering the scheduler, the Mac-d PDUs for each queue ID of each user are
classified according to their corresponding priority (CmCH-PI). Every TTI, the
scheduler is launched in order to efficiently assign the available resources (number of
codes and remaining power) to the different users.

The first step consists in managing the retransmissions. The NACKed blocks are
scheduled first, in a FIFO order when possible (in case the UE capabilities prevent
from receiving data in the corresponding TTI, it is not retransmitted in that TTI). Then,
once retransmissions are handled, the remaining number of codes and power are
computed and constitute the input of the next step.

The scheduling of first-transmitted data is based on a two-stage solution:
The first stage selects one priority queue among the active ones.
The second stage consists in selecting the user(s) within the chosen priority
queue to schedule.

These two steps are repeated as long as some resources remain (codes, power and
CPU) and if data can be scheduled for the corresponding TTI.

3.1.4.3 FIRST STAGE
The following paragraph describes the general behavior. In this version, as only one
priority queue is available, this first stage is transparent.
Nortel confidential

The selection of a priority queue is based on a cost function that takes into account
credits assigned to each priority queue and the number of Mac-d PDUs already
transmitted in the last TTI for these queues. The aim is to provide some throughput
per queue according to its priority: the higher the priority, the higher the allocated
bandwidth.

The credits per queue then depend on their respective priority, on the number of
active priority queues but shall also be proportional to the number of active QIDs per
priority queue (in order to ensure the bandwidth of high priority QIDs remains more
important that low priority ones independently on the number of UEs per priority
queue).

The credits per priority queues are recomputed any time the status of a priority queue
changes (active/inactive) or if the number of active QIDs in a queue changes. When
credits are recomputed, the ratio between queues initially setup is kept.

3.1.4.4 SECOND STAGE
Once a priority queue has been selected, one or more users within that queue are
scheduled. The selection of one QID is done according to another cost function that
takes into account the processed CQI (noted CQI
processed
in CQI section) and the
number of Mac-d PDUs transmitted in the last TTI. This ensures that all users are
selected but that the bandwidth allocated to the priority queue is separated between
users according to their CQI (the higher the CQI, the higher the available throughput).

A user can only be considered as candidate if it is allowed to receive some data in the
current TTI, i.e. if several criteria are respected (CQI
processed
0, min inter TTI distance,
AckNack repetition factor, one HARQ process available, UE not already scheduled for
retransmissions).

For each candidate user, HS-SCCH power is determined (see POWER
MANAGEMENT section) and power checking is done on both the current TTI and the
previous one (HS-SCCH and corresponding HS-PDSCH only overlap by 1 slot). If
there is not enough power to transmit the HS-SCCH in the current TTI, the user is not
selected.

Then for the UE with the lowest cost within the remaining candidates UEs, the number
of PDU to transmit as well as the number of codes and the transmitted power are
chosen according to the processed CQI in order to fit as well as possible to what the
UE can correctly receive (see POWER MANAGEMENT section for more details on
the algorithm):
Nortel confidential
If there doesnt remain enough power to transmit the HS-PDSCH, another
configuration requiring less power is selected if possible (transport block size
reduced, corresponding to a smaller CQI referred as CQI
applied
in Section 6.4
Power Management.
If there doesnt remain enough codes to transmit the HS-PDSCH, the
configuration is changed (transport block size reduced, corresponding to a
smaller CQI) to use the remaining codes. The power is then updated
accordingly.

Anytime a UE is scheduled, its cost is recomputed according to the transmitted
number of MAC-d PDUs.

Another priority queue must be selected when no more QID in the current priority
queue can be scheduled (all HARQ processes used for the corresponding UE, min
inter TTI distance not compliant with that TTI, no other QID). As only one priority
queue is available in this version, the first stage is not recalled and the TTI processing
is considered as complete.

The cost of each QID of the selected priority queue is updated anytime another queue
must be selected (according to previous criteria) or at the end of a TTI (no more HS-
SCCH/HS-PDSCH code, power or CPU).

Nortel confidential
3.2 DEPLOYEMENT SCENARIOS
3.2.1 DUAL CARRIER
The preferred scenario is to deploy a new layer dedicated to HSDPA on a new
frequency. This layer may be deployed either widely or restricted to some hot-spots.

Layer with HSDPA configured
Layer without HSDPA

Figure 11: HSDPA on dedicated layer

The advantage of this scenario is that there is no impact of HSDPA on the layer that is
already deployed. A Node B can handle HSDPA and non-HSDPA cells at the same
time so there is no need for dedicated NodeB to HSDPA. However if no PA are added
then HSDPA layer will use part of the current power capacity and this will reduce the
coverage of the existing cells. Mobiles are spread over the two layers thanks to the
Traffic Segmentation feature at RRC connection establishment, based on the release
of the mobile and potentially on the traffic class indicated in the establishment cause.

An HSDPA cell is not restricted to HSDPA services: it offers all UA4.2 services (on
Cell_DCH and Cell_FACH) so there is no need to handover to the R99 layer to
establish these services. However mobility between the two layers is managed
through a cell reselection when the mobile is in an HSDPA call. This cell reslection is
not based on quality criteria like in R99. Indeed, mobiles leaving the coverage of the
HSDPA layer will lost his session from a UTRAN point of view but keep his PDP
context from a core network point of view, so that it will perform a cell reselection on
R99 layer.. It is also possible to configure a handover towards 2G (GPRS/EDGE)
when alarm conditions are triggered but it will be a blind handover if the mobile is not
able to perform measurements without compressed mode. For mobiles in Cell_DCH
or Cell_FACH state, mobility is managed as usual even if they are on the HSDPA
layer.

Nortel confidential
Another possible scenario is to deploy HSDPA on a separate cluster (managed or not
by a dedicated RNC) but in this case Traffic Segmentation cannot be used as it
assumes a twin-cell topology (see 3.5.1 for more details on Traffic Segmentation).

3.2.2 SINGLE CARRIER
Even though deploying HSDPA on a separate layer is the preferred option, HSDPA
can be configured on any cell and shared his resources with R99. The drawback of
this scenario is that HSDPA traffic may impact R99 traffic by generating high
interferences and may need to re-engineer the layer. If HSDPA is not deployed
everywhere in the layer then an automatic channel type switching between DCH and
HSDPA is performed when the UE enters in or leaves an HSDPA cell.

3.3 HSDPA RESOURCES
3.3.1 OVSF CODES
3.3.1.1 CELL CONFIGURATION
The following figure presents the cell configuration. This configuration provides up to
15 SF16 codes for HS-PDSCH and up to 4 SF128 for HS-SCCH. The common
channels (CPICH, P-CCPCH, S-CCPCH, ) take the equivalent of a SF32. All
remaining OVSF codes can be used for non-HSDPA services (speech, multi-RABs..):

Figure 12: Example of OVSF tree usage with HSDPA

Nortel confidential
3.3.1.2 HSDPA CODE ALLOCATION
In the OVSF code tree, all the common channels are allocated in the top of the tree,
as illustrated by the figure below. In Nortel implementation, the HS-PDSCH SF16
codes are allocated and reserved by the RNC at the bottom of the tree. Immediately
above, the HS-SCCH SF128 codes are allocated. These codes are allocated at cell
setup and cannot be used or preempted for other services.

SF = n SF = 4 SF = 2 SF = 1
C
n,n-1
C
n,0
C
4,3
= (1,-1,-1,1)
C
2,1
= (1,-1)
C
4,2
= (1,-1,1,-1)
C
1,0
= (1)
C
4,1
= (1,1,-1,-1)
C
2,0
= (1,1)
C
4,0
= (1,1,1,1)
SF = n SF = 4 SF = 2 SF = 1
C
n,n-1
C
n,0
C
4,3
= (1,-1,-1,1)
C
2,1
= (1,-1)
C
4,2
= (1,-1,1,-1)
C
1,0
= (1)
C
4,1
= (1,1,-1,-1)
C
2,0
= (1,1)
C
4,0
= (1,1,1,1)
Common channels
n SF128 HS-SCCH
m SF16 HS-PDSCH

Figure 13: OVSF allocation strategy

All the remaining codes are therefore contiguous and left for further DCH allocations.
This includes associated DCH as well as any other calls mapped on DCH (e.g. speech
calls, streaming, etc).
Note that the maximum configuration (15 HS-PDSCH codes and 4 HS-SCCH codes)
is not a valid one as it will leave no room in the OVSF tree for DCH (due to CCH
occupancy) so it would not even be possible to allocate associated SRB for HSDPA
calls.
Note that OCNS code allocation is done before HSDPA configuration and it may lead
to a conflict as HSDPA codes are always allocated from the bottom and need to be
contiguous. In this case the HSDPA configuration will fail. The operator has to modify
OCNS configuration to make it use non-conflicting codes.

3.3.2 POWER
In HSDPA, PA power has to be shared between common channels, DCH channels
and HSDPA channels. In order to manage correctly this new power partition, some
new margins or thresholds are added at RNC and NodeB level:
At RNC level, a minimum power can be reserved for HSDPA.
At NodeB level, a DCH margin allows to take into account the R99 power
fluctuation due to power control.

For more details, see section 6.4 Power Management.
Nortel confidential

3.3.3 HSDPA CHANNELS & CQI
3.3.3.1 PHYSICAL CHANNELS
The following flowchart describes the timing relations between the different physical
channels:

HS-SCCH#2
ACK ACK ACK
7,5 slots
HS-SCCH#1
HS-PDSCH
N_acknack_transmit = 2
2 ms
HS-DPCCH
2 slots

Figure 14: Timing relationship at NodeB between physical channels

The mobile receives a HS-SCCH subframe (see the following figure) containing
control information among which:
Channelization-code-set information (7 bits slot #0 of subframe)
Modulation scheme information (1 bit slot #0 of subframe), i.e.
QPSK/16QAM
Transport-block size information (6 bits slots #1 & #2 of subframe)
Hybrid-ARQ process information (3 bits slots #1 & #2 of subframe)
Redundancy and constellation version (3 bit slots #1 & #2 of subframe)
New data indicator (1 bit slots #1 & #2 of subframe)
UE identity (16 bits used as a mask in slots #0, #1 & #2 of subframe), i.e.
subset of the HRNTI

The SF is fixed to 128. It indicates to which UE data is intended to, on which codes
and with which parameters. There are as many HS-SCCH transmitted during a TTI as
scheduled user number.

Nortel confidential
Data
Slot #0 Slot #1 Slot #2
1 HS-SCCH subframe = 2ms
T
slot
= 2560 chips = 40 bits

Figure 15: HS-SCCH structure

A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been
assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this
slot #0, other information are given in slots #1 and 2): the mobile receives a transport
block on one or several HS-PDSCH (see the following figure).

M= 2 for QPSK
(960 coded bits per TTI)
M = 4 for 16QAM
(1920 coded bits per TTI)
Data
Slot #0 Slot #1 Slot #2
1 HS-PDSCH subframe = 2ms
Tslot = 2560 chips = M*10*2
k
bits (k = 4, SF16)

Figure 16: HS-PDSCH structure

The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload. The
SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One
HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of
codes is given by UE capabilities).

When addressed on HS-SCCH, the UE will then send feedback frame(s) on HS-
DPCCH (SF = 256), roughly 7.5slots after HS-PDSCH frame, containing (see the
following figure):
The HARQ Ack/Nack;
The CQI (Channel Quality Indication).

Nortel confidential
CQI
Subframe #0 Subframe #i Subframe #4
1 radio frame = 10ms
Tslot = 2560 chips
= 10 bits
ACK/NACK
2.Tslot = 5120 chips
= 20 bits

Figure 17: HS-DPCCH structure

The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the
N_acknack_transmit parameter, as specified in [R5] 6A.1.1. The CQI is only sent in
some specific subframes, as specified in [R5] 6A.1.1, depending on the following
parameters:
The CQI feedback cycle: k,
the repetition factor of CQI: N_cqi_transmit.

For more details on physical channel management, see [R6].

3.3.3.2 CQI
The HS-DPCCH channel contains the CQI computed by the mobile from P-CPICH
power measurements. This CQI after demodulation and decoding by the NodeB
(noted CQI
reported
) is not directly used by the scheduler. As shown by the following
figure, the CQI
reported
undergoes two processing: a CQI averaging and a CQI
adjustment based on BLER and DTX.

Nortel confidential
HS-DPCCH demodulation
and CQI decoding
CQI averaging over several TTI
in order to improve the reliability
of this measurement.
CQI provides to scheduler every TTI
CQI adjustment based on BLER
(to reach a BLER target)
and DTX (in order to deactivate deficient ue
by artificially setting its CQI to 0)
CQI
reported
CQI
averaged
CQI
processed

Figure 18: CQI Processing

3.3.3.2.1 CQI AVERAGING
An averaging over several TTI must be done on the CQI values (CQI
reported
) in order to
improve the reliability of this measurement. The resulting value (CQI
averaged
) should
nevertheless be provided to entities needing this information (scheduler, etc) every
TTI (the default CQI feedback cycle is equal to 2 ms). The chosen algorithm consists
in a flexible averaging window which length will be based on CQI correlation
estimation without noise level estimation (see [R8] for details).

3.3.3.2.2 CQI ADJUSTMENT
Two algorithms have been introduced to handle bad UE behaviors that would
dramatically disrupt the system. Note that in the nominal case, these algorithms
should not have any impact.

The purpose of these algorithms is respectively to:
Adjust the received CQI (CQI
averaged
) in order to maintain an acceptable BLER
on first transmission.
Isolate a deficient UE which never responds (constant DTX detection).

Both algorithms are processed just after the CQI averaging and can be processed in
any order. The resulting CQI from both steps (referred as CQI
processed
in the document)
Nortel confidential
constitutes the input of both flow control and scheduler algorithms (except HS-SCCH
power control).

3.3.3.2.3 CQI ADJUSTMENT ACCORDING TO BLER
The first algorithm works on ACK/NACK statistics. The purpose is to correct some bias
on the reported CQI that would lead to excessive BLER. Note that according to the
specifications, the target on the first transmission when applying the reported CQI
would be a 10% BLER. The idea is then to continuously compute the BLER and
modify the reported CQI accordingly in order to reach such target.

It then just consists in computing an offset to apply to the reported CQI (after
averaging), referred in the following as CQI (CQI
output
= CQI
averaged
+ CQI). In case
the input CQI equals 0, the offset doesnt apply even if positive and the CQI remains
equal to 0. In case CQI
output
becomes inferior or equal to 0, the UE is not scheduled. In
case CQI
output
becomes higher than 30, it is processed as a CQI 30.

It is continuously updated with the following rules:
A buffer of fixed size (= BufferSize) is created for each UE to compute the
BLER.
Anytime an ACK/NACK is received related to the 1st transmission of a
transport block, the buffer is updated to store this information.
o DTX is not taken into account in the buffer.
o The feedback for retransmissions is not either taken into account.
The buffer is filled in a circular manner (i.e. the new value replaces the oldest
one when the buffer is full).
When at least BufferSize stats have been received (the buffer is full), the
number of NACK (NackNb) indication within the last BufferSize ones is
computed. The offset is then updated according to the following rules:
o 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.
o If NackNb > NackNbmax, the BLER is too high. Performances are
then degraded. CQI is decreased by 1 and the buffer is reinitialized.
o 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
reinitialised.

Note that the buffer is only reinitialized when CQI is updated. This allows waiting for
a certain time (BufferSize) before taking a new decision, and thus really evaluating the
effect of the new offset value. If the offset has not been updated, the buffer remains
Nortel confidential
filled in a circular manner in order to react as soon as the situation changes (and not
wait for a new period before identifying the problem). The offset is bounded and fits in
the range [-30.. +30].

This is illustrated by the following flowchart.

ACK or NACK received (DTX are
not taken into account
End
Y
Is it the
acknowledgement
of a 1st
transmission ?
Update of statistics buffer
(sliding window like)
StatNb = min(StatNb +1, BufferSize)
N
CQI : offset to apply to averaged CQI
NackNb : number of Nack in the Stats buffer
StatNb =
BufferSize ?
NackNb
NackNbmin ?
NackNb >
NackNbmax ? CQI = CQI + 1
CQI = CQI - 1
No CQI update
Reinit buffer
StatNb = 0
N
N
N
Y
Y
Y
Y

Figure 19: CQI offset computation based on BLER

The default values assumed in a first approach are:
BufferSize = 100
NackNbmin = 0
NackNbmax = 30

Nortel confidential
Tests must be done to tune these values. The higher the BufferSize the better the
statistic but the longer the decision. A compromise must then be done between good
precision (BufferSize high and NackNbmax/min close to 10%) and reactivity.

3.3.3.2.4 DEFENSE BASED ON DTX DETECTION
The second algorithm is more a defense mechanism against a deficient UE which
would systematically not detect the HS-SCCH. The purpose is that upon detection of
such UE (based on DTX statistic), it is deactivated by artificially setting its post-
processed CQI to 0. That disables both the scheduler and the flow control algorithm.
The UE would then be released by higher layers as its throughput equals 0.

More in detail, the following steps are processed (see the following figure):
As before, a buffer of fixed size (BufferSize) is created for each UE.
Anytime a feedback information is received, the buffer is updated:
o ACK, NACK and DTX are taken into account.
o Feedback of all transmissions is considered (1st and retransmissions)
as based on the HS-SCCH only.
The buffer is also filled in a circular manner.
As soon as the buffer is full, the evaluation may begin.
If the buffer only contains DTX indications, the UE is considered as deficient
and its CQI is set to 0. No recovery is then possible.
If at least one ACK/NACK has been received in the last BufferSize
transmissions, the UE is considered as valid and nothing is done.

Nortel confidential
ACK/NACK/DTX received
Permanently set the CQI of
corresponding UE to 0
(scheduler and flow control disable
N
Only DTX in
the buffer ?
Y
Update of statistics buffer
(sliding window like)
StatNb = min(StatNb +1, BufferSize)
StatNb =
BufferSize ?
End
N
Y

Figure 20: Scheduler and Flow Control disabled

Default value:
BufferSize = 100

Note: buffers of both algorithms are independent!

3.4 UE CATEGORIES
3GPP has standardized several UE categories to accommodate a large spectrum of
HSDPA mobile implementations (See [R5]). The UE category provides the mobile
capabilities like max number of HS-PDSCH codes supported, modulation schemes
(16QAM, QPSK), MAC-HS transport block size, etc. Each UE category has a table
with 30 CQI (channel quality indicator) values. Each CQI value provides complete
information regarding the HS-DSCH to be received by UE in DL in the next TTI as
shown below:

Nortel confidential
Category 9
Category 10
Category 1-6
Category 11-12
15
...
12
10
...
5
...
5
5
4
...
2
2
2
1
1
1
1
1
1
Number of
HS-PDSCH
16-QAM 0.89 12160 25558 30
...
16-QAM 0.75 8160 17237 26
16-QAM 0.75 6720 14411 25
...
16-QAM 0.75 3360 7168 22
...
16-QAM 0.37 1660 3565 16
QPSK 0.69 1440 3319 15
QPSK 0.67 1120 2583 14
...
QPSK 0.48 320 931 9*
QPSK 0.41 320 792 8
QPSK 0.34 160 650 7*
QPSK 0.48 160 461 6*
QPSK 0.39 160 377 5
QPSK 0.33 0 317 4*
QPSK 0.24 0 233 3*
QPSK 0.18 0 173 2*
QPSK 0.14 0 137 1*
Modulation Code rate
Throughput
RLC level
kb/s
Transport Block
Size
CQI value
15
...
12
10
...
5
...
5
5
4
...
2
2
2
1
1
1
1
1
1
Number of
HS-PDSCH
16-QAM 0.89 12160 25558 30
...
16-QAM 0.75 8160 17237 26
16-QAM 0.75 6720 14411 25
...
16-QAM 0.75 3360 7168 22
...
16-QAM 0.37 1660 3565 16
QPSK 0.69 1440 3319 15
QPSK 0.67 1120 2583 14
...
QPSK 0.48 320 931 9*
QPSK 0.41 320 792 8
QPSK 0.34 160 650 7*
QPSK 0.48 160 461 6*
QPSK 0.39 160 377 5
QPSK 0.33 0 317 4*
QPSK 0.24 0 233 3*
QPSK 0.18 0 173 2*
QPSK 0.14 0 137 1*
Modulation Code rate
Throughput
RLC level
kb/s
Transport Block
Size
CQI value
Category 7-8

Table 6: UE capabilities

At the high end, UE category 10 can achieve a max RLC throughput = 12 Mbps using
16QAM modulation and 15 OVSF codes SF16 (i.e. entire code tree). At the low end,
UE category 12 achieves a max RLC throughput = 1.4 Mbps with QPSK modulation
and using 5 OVSF codes SF16.

3.5 CALL MANAGEMENT
HSDPA only applies to the PS domain meaning that all the CS domain RABs are
supported on dedicated channels.
The Utran supports only the Traffic Classes Interactive & Background on HSDPA. So,
the TC Streaming is served on DCH.
Moreover, only the mono RB PS I/B are mapped on HSDPA implying that any
combination of RB PS I/B with RB CS call or with any other RB PS I/B (Multi PS) is
served on DCH.

Nortel confidential
RB configuration System behavior
All RABs DCH available in HSDPA Cell
Supported: no impact coming from HSDPA. All RAB
combinations existing in this release are available on
DCH in an HSDPA cell (either for a mobile that does
not support HSDPA or for a RAB combination that is
not supported on HSDPA)
PS I/B on HSDPA Supported on HSDPA
PS Streaming on HSDPA
Speech on DCH + PS I/B on HSDPA
CSD/DCH + PS I/B on HSDPA
(PS I/B+PS I/B) on HSDPA
(PS I/B+PS Streaming) on HSDPA
Speech on DCH + (PS+PS) on HSDPA
Not supported on HSDPA all channels are mapped
on DCH
Table 7: RB Configuration and system behaviour

3.5.1 TRAFFIC SEGMENTATION
In case HSDPA is deployed on one frequency layer on top of the R99 layer, it shall be
possible to re-direct UEs on the proper frequency layer at call setup depending on its
capabilities and requested establishment cause:
an HSDPA capable UE camping on a R99 cell is re-directed to the HSDPA
layer
similarly, a R99 UE camping on a HSDPA cell can be re-directed to the R99
layer.
This feature impacts the choice of the target cell and the frequency layer at the call
establishment.
The main benefits are to allow HSDPA capable mobiles to benefit from HSDPA
service and to avoid loading the HSDPA layer with R99 mobiles.

3.5.1.1 TRAFFIC SEGMENTATION MECHANISM
The redirection is performed by the RNC at the call setup phase based on the twin-
cells configuration which is not compatible in this case with the f1/f2 mobility-capacity
inter-frequency hard hand over.
No redirection is performed by the RNC during the call meaning for example that
even if a mobile, initially on HSDPA layer, reselects the R99 layer in AO cell_fach
state for traffic resuming, it will be served using the DCH layer.
Emergency calls are never redirected and are served on the layer selected by the
mobile to limit the probability of call setup failure.
Nortel confidential

3.5.1.1.1 TRAFFIC SEGMENTATION CRITERIA:
Two filtering can be operated in order to execute the redirection on the suitable layer:
First criterion is based on the Access Stratum Release Indication IE in the
RRC Connection Request message for the identification of the R99/R4
mobiles versus the R5 mobiles
Second optional criterion is based on the Establishment Cause IE in the RRC
Connection Request message to distinguish the calls I/B potentially served on
HSDPA from the others.
This filtering is not necessarily representative of the services setup
during the life of the RRC connection (for example the addition of a
CS call on top of a hsdpa connection implies the switching of the PS
connection on dch channel in the hsdpa layer).

3.5.1.2 TRAFFIC SEGMENTATION PROCEDURE
At the reception of the RRC Connection Request, the RNC identifies:
the UE Release via the Access Stratum Release indicator IE knowing that
R99/R4 mobiles dont support HSDPA configuration
the requested service via the Establishment Cause IE knowing that traffic
class Conversational and Streaming cant be served on HSDPA. This filtering
is optional depending on the setting of the parameter
isRedirectionBasedOnEstablishmentCause
So, based on the information of Access Stratum Release indicator and Establishment
Cause IE, the RNC can start the redirection procedure for the R5 mobiles requesting a
PS I/B session.
The redirection consists in indicating the target frequency in the RRC Connection
Setup message via the Frequency Info IE, frequency corresponding to the one of the
twin cell.
The UE will send the RRC Connection Setup Complete towards the twin cell on the
right layer.

Hereafter the static mapping between the Establishment cause sent by the mobile in
the RRC Connection Request and the suitable layer pointed by the RNC :

Nortel confidential
Cause Suitable layer Meaning
Originating Conversational Call DCH
Originating Streaming Call DCH
Originating Interactive Call HSDPA
Originating Background Call HSDPA
Originating Subscribed traffic Call HSDPA
Request for access following a request for
service expressed by the mobile user
Terminating Conversational Call DCH
Terminating Streaming Call DCH
Terminating Interactive Call HSDPA
Terminating Background Call HSDPA
Request for access, following a paging
indication received by the mobile.
Emergency Call
DCH or HSDPA
(i.e. no re-direction)
Speech emergency mobile originated call
Inter-RAT cell re-selection
DCH or HSDPA
User location registration following an inter-
system cell reselection
Inter-RAT cell change order
DCH or HSDPA
User location registration following an inter-
system cell change commanded by the
source system
Registration HSDPA
Request for user registration, following a
mobile power-on
Detach
DCH or HSDPA
Request for user de-registration, following a
mobile power-off
Originating High Priority
Signalling
HSDPA
Originating Low Priority
Signalling
DCH or HSDPA
Access request for signalling exchange, e.g.
SMS,...
Call re-establishment CS case
DCH or HSDPA
Access requested for service re-
establishment (due to loss of radio
connection)
Call re-establishment PS case
DCH or HSDPA
Routing Area update due to "directed
signalling call re-establishment" RRC release
Terminating High Priority
Signalling
DCH or HSDPA
Terminating Low Priority
Signalling
DCH or HSDPA
Access request for network initiated signalling
exchange, e.g. SMS, ...
Terminating cause unknown
DCH or HSDPA
This cause is received when no paging cause
is provided from the Core Network.
Table 8: RRC Connection Request and suitable layer

Nortel confidential
3.5.1.2.1 PARAMETERS:
isRedirectionForTrafficSegmentation: This parameter is used by the traffic
segmentation feature, in order to redirect mobiles to the adequate layer according to
the UE release indicator.
Parameter isRedirectionForTrafficSegmentation Object InterFreqHhoFddCell
Range & Unit Boolean
{True, False}
User Customer
Class 3
Granularity FDDCell
Value

isRedirectionBasedOnEstablishmentCause: This parameter is used by the traffic
segmentation feature in order to take into the establishment cause if the redirection
algorithm.
Parameter isRedirectionBasedOnEstablishmentCause Object InterFreqHhoFddCell
{True, False}
User Customer
Class 3
Granularity FDDCell
Value

3.5.2 HSDPA CAC
3.5.2.1 RAB MATCHING
Any PS RAB request with Interactive or Background traffic class is matched to the
HSDPA Radio Bearer configuration if the mobile is HSDPA capable and the primary
cell of the active set supports HSDPA. If it is not the case, the request is mapped on
DCH as usual (iRM CAC is performed).

3.5.2.2 ADMISSION PHASE
As today, this mechanism is triggered by the reception of RAB Assignment Request
and follows the RAB matching process.

In this implementation, the specific CAC admission process in the RNC for HSDPA is
based on the number of simultaneous authorized users per cell to limit the
degradation of the quality of service. So, iRM CAC is not played for HSDPA RAB.

Any 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
doesnt take into account any other criterion like RF power,
Nortel confidential
In case the admission process fails, there is no fallback on DCH. The RAB request will
be rejected.

Once HSDPA CAC has been done, the RNC performs the admission on the
associated DCHs :
Regarding DL SRB admission, CAC is performed as usual
Regarding UL admission, CAC is performed as usual.

3.5.2.2.1 PARAMETER
maximumNumberOfUsers: Used for the HSDPA CAC done by the RNC. The
number of users is per cell
Parameter maximumNumberOfUsers Object HsdpaCellClass
Range & Unit Integer
[0..50]
User customer
Class 0
Granularity RNC
Value 20

Nortel confidential
3.5.3 CALL SETUP (DATAFLOW)
3.5.3.1 INITIAL CONNECTION PHASE:
There is nothing specific to HSDPA in this phase.
In the scenario of a mobile being redirected due to the traffic segmentation feature, the
target frequency is indicated in the RRC Connection Setup (frequency info IE) but the
call flow is the same.

SGSN Node B RNC UE
RRC/ RACH / RRC connection Request
SCCP/ Connection Request (Initial UE msg (Activate PDP Context Request))
SCCP/ Connection Confirm
RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,
RRC state = CELL_DCH, [frequency info])
RRC/ RACH / RRC Connection Setup Complete
RRC/ RACH / Initial Direct Transfer (Activate PDP Context Request, PS domain)
The RRC Connection Setup message contains the
signalling bearers (DCCH) definition. A UTRAN
Radio Network Temporary Identity is also
allocated to the UE.
The target RRC state is set to CELL_DCH by the
RNC
If the mobile is redirected for traffic segmentation
reason then frequency info is included
In addition to the initial NAS message, the Initial Direct Transfer message
also contains the CN domain identity, used by the RNC to route the NAS
message to the relevant CN domain (i.e. CS or PS)
The RRC Connection Request message initiated
by the UE contains the establishment cause.
The initial UE message is piggybacked in the
SCCP connection resquest
NBAP/ RL Setup Request)
NBAP / RL Setup

Figure 21: HSDPA Call setup / initial connection (Cell_DCH)

Nortel confidential
3.5.3.2 RAB ALLOCATION PHASE:
In this phase, only the NBAP Radio Link Reconfiguration procedure and RRC Radio
Bearer Reconfiguration are modified because of HSDPA.

SGSN Node B RNC UE
SM/ Activate PDP Context
GMM/ Authentication and Ciphering
GMM/ Authentication and Ciphering
The UE is authenticated by the SGSN
RANAP/ Security Mode Command
RANAP/ Security Mode
RRC/ Security Mode Command
RRC/ Security Mode Complete
The ciphering and integrity procedures are activated by the MSC
The RNS supports the following algorithms:
UIA1 for integrity
UEA1 for ciphering
RANAP/ RAB Assignment Response
RANAP/ RAB Assignment Request (RAB param, binding Id)
The Radio Access Bearer assignment procedure
The RAB is now established. the mobile is now waiting for end-to-end
service accept.
RRC/ RB Setup (DCCH + DTCH,
HS-DSCH information)
RRC/ RB Setup Complete
The UE is provided with the new radio link
configuration. A new RAB (corresponding to the
new DTCH) is added to the current configuration
NBAP/ Radio Link Reconfiguration Request (
HS-DSCH Radio Link)
NBAP/ Radio Link Reconfiguration Ready (HS-SCCH codes allocated)
A HS-DSCH Radio Link is created as well as the
associated DCH
FP/ DL Synchronisation (CFN)
FP/ UL Synchronisation (ToA)
The DCH is synchronised
RANAP/ Common Id
"Common Id" is used to provide the RNC with the user IMSI
NBAP/ Radio Link Reconfiguration Commit (
CFN)

Figure 22: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)

Nortel confidential
3.5.4 CALL RELEASE (DATAFLOW)
The call release is initiated either by the mobile or the network through a PDP context
de-activation procedure, or by the RNC (Always-On step 2) through Iu Release
Request.
Depending on the Core Network implementation, the UTRAN is released, either using
an Iu release or a RAB release procedure.

3.5.4.1 IU RELEASE CASE
In such a case, the UTRAN resource release is requested by the Core Network
through an Iu Release Command message.
On reception of this message:
the RRC connection is released
the HSDPA and associated DCH are released. A Radio Link Deletion request
is sent to each of the BTS being part of the active set, including the BTS
which supports the HS-DSCH.

3.5.4.2 RAB RELEASE CASE
In such a case the UTRAN resource release is requested by the Core Network
through an RAB Assignment Request (cause RAB to release) message.
On reception of this message, as illustrated in the following picture:
the RNC attempts a Radio Link Reconfiguration to remove the HSDPA MAC-d
flow from the cell supporting it and
a RB Release removes the HSDPA RB.

Nortel confidential
SGSN Node B RNC UE
GMM/ Deactivate PDP
GMM/ Deactivate PDP context
The SGSN asks for the release of the corresponding RAB.
In this example, this is the only RAB supported by the mobile
RANAP/ RAB Assignment request (RAB to release)
RANAP/ RAB Assignment request response
NBAP/ Radio Link Reconfiguration Prepare
(remove HSDPA MAC-d flow)
The radio link is re-configured (only primary cell).
RRC/ RRC Connection Release
NBAP/ Radio Link Deletion
NBAP/ Radio Link Deletion
SCCP/ Released
RANAP/ Iu Release Complete
RANAP/ Iu Release Command
If isRABRelMgtAllowed is set to "false", the RNC requests for a
global Iu Release.
RRC/ RRC Connection Release Complete
Release of radio bearer and RRC connection
RANAP/ Iu Release Request
NBAP/ Radio Link Reconfiguration Ready
NBAP/ Radio Link Reconfiguration Commit
([activation CFN])
RRC/ RB Release (remove HSDPA ; [activation CFN])
RRC/ RB Release Complete
All the RLs of the active set are deleted
(so may imply several Node Bs)

Figure 23: Call release (RAB release case)

3.5.5 HSDPA RELATED TRANSITIONS
The following table gives the different hsdpa related transitions under certain
conditions such as:
the primary cell of the active set has to support hsdpa configuration, otherwise
any connection is mapped on dch
prior to the automatic switching hsdpadch due to incoming call/connection,
if the iRM cac is not successful, the incoming call/connection is rejected and
the on-going PS is maintained on hs-dsch
prior to the automatic switching dchhsdpa (for example due to CS/PS
release when in multiservice or in multiPS), if the hsdpa cac based on the
maximum number of users using hsdpa is not successful, the remaining PS
connection is rejected and no fallback on dch is performed.
Nortel confidential

Transition to CS Addition CS Release PS Addition PS Release CSD Addition CSD Release
PS I/B on HSDPA
switching from PS I/B
on hs-dsch to PS I/B
on dch for combination
CS + PS I/B on dch
N.A.
switching from PS I/B
on hs-dsch to PS I/B on
dch for MultiPS
combination
Idle Mode
switching from PS I/B on
hs-dsch to PS I/B on
dch for CSD + PS I/B on
dch
N.A.
CS + PS I/B on DCH N.A.
switching from PS
I/B on dch to PS
I/B on hs-dsch
CS + MultiPS on dch
CS Call only on
dch
N.S. N.A.
Multi PS on DCH CS + MultiPS on dch N.A. N.S.
switching from PS
I/B on dch to PS
I/B on hs-dsch
N.S. N.A.
CS on DCH N.S. Idle Mode CS + PS on dch N.A. N.S. N.A.
CSD on DCH N.S. N.A. CSD + PS on dch N.A. N.S. Idle Mode
CSD + PS I/B N.S. N.A. N.S.
CSD call only on
dch
N.S.
switching from PS
I/B on dch to PS
I/B on hs-dsch
CS + MultiPS N.S. MultiPS on dch N.S.
CS + PSI/B on
dch
N.S. N.A.
Table 9: HSDPA related Transitions

where
N.S.: Not Supported
N.A.: Not Applicable

Nortel confidential
Note: HSDPA configuration doesnt support the Traffic Class Streaming and any of its
combination.

3.5.5.1 RLC RECONFIGURATION PROCEDURE
It is possible to trigger an RLC reconfiguration after a channel type switching between
DCH and HS-DSCH. This reconfiguration is optional and is useful to tune the RLC
settings (like timers) to the characteristics of the transport channel. It only applies to
the RB corresponding to the PS I/B RAB (so only RLC AM parameters) and RLC PDU
size cannot be changed.

When it is associated to a RB Reconfiguration procedure (due to mobility or Always-
On), it is done simultaneously with the transport channel reconfiguration (synchronous
reconfiguration).

When it is associated to a RB addition/deletion (due to RAB assignment/release, with
PS I/B RAB already established and not affected), it cannot be performed
simultaneously with the RB addition/deletion . It is performed afterwards as a stand-
alone procedure, using a RB Reconfiguration procedure. It is possible to use either a
synchronous or an asynchronous procedure.

Summary of RLC Reconfiguration procedure events during hsdpa related transitions:
dch hs-dsch:
o case of mobility to or from a non-hsdpa cell:
RLC Reconfiguration is simultaneously performed with the
synchronized RB Reconfiguration procedure via the parameter
deltaCfnForHsdpaChannelTypeSwitching and is conditioned to the
activation flag value isRLCReconfigurationForChannelTypeSwitching
o case of addition/release CS/PS when PS hsdpa is on-going:
RLC Reconfiguration is performed in a synchronous way after the RB
Reconfiguration to setup the new transport channel information. The
RLC reconfiguration is triggered via the parameter
deltaCfnForHsdpaRLCReconfiguration (if
deltaCfnForHsdpaRLCReconfiguration=0, the rlc reconfiguration
becomes an a-synchronous procedure).
fach hs-dsch:
RLC Reconfiguration is simultaneously performed with the a-synchronized RB
Reconfiguration procedure and is conditioned to the activation flag value
isRLCReconfigurationForChannelTypeSwitching.
Nortel confidential
hs-dsch hs-dsch:
No RLC Reconfiguration because the transport channel keeps unchanged but
the establishment of the radio link on the new primary cell supporting hsdpa
needs a synchronized RB reconfiguration via the parameter
deltaCfnForHsdpaMobility.

V4.2 Restriction:
The transitions involving (fach dch) or (dch dch) transport channel
switching are not eligible for RLC Reconfiguration.
DL RLC PDU size is not changed (such a reconfiguration needs to re-
establish the RLC entities so lose all PDUs under transmission).
The RNC RLC Queue Size is never reconfigured. The implication is that if a
R5 mobile is performing the RAB Assignment procedure in non-HSDPA cell,
the RLC Queue Size of the resulting (DCH) RBSetConf would be retained for
the duration of the call, even if the user is subsequently transitioned to a
HSDPA cell.

3.5.5.1.1 PARAMETERS:
deltaCfnForHsdpaMobility: Delta CFN used for HS-DSCH creation when primary
cell is changed.
Parameter deltaCfnForHsdpaMobility Object HsdpaRncConf
[0..255]
User Manufacturer
Class 3
Granularity RNC
Value 45

deltaCfnForHsdpaChannelTypeSwitching: Delta CFN used for SRLR due to
channel type switching between DCH and HS-DSCH
Parameter deltaCfnForHsdpaChannelTypeSwitching Object HsdpaRncConf
[0..255]
User Manufacturer
Class 3
Granularity RNC
Value 80

Nortel confidential
isRLCReconfigurationForChannelTypeSwitching: Activation of the RLC
reconfiguration after a channel type switching related to release or addition of another
RAB.
Parameter isRLCReconfigurationForChannelTypeSwitching Object HsdpaRncConf
{True, False}
User Manufacturer
Class 3
Granularity RNC
Value True

deltaCfnForHsdpaRLCReconfiguration: Delta CFN used for RLC reconfiguration
when done in stand-alone (0 means asynchronous reconfiguration).
Parameter deltaCfnForHsdpaRLCReconfiguration Object HsdpaRncConf
[0..255]
User Manufacturer
Class 3
Granularity RNC
Value 0

Nortel confidential
4 HSDPA CONFIGURATION
4.1 RAN MODEL AND PARAMETERS
4.1.1 RRM IMPACT
4.1.1.1 NEW OBJECTS AND INSTANCES

Figure 24: RRM new HSDPA subtree

FddCell FddCell
NodeB NodeB
RNC
NodeB
FddCell
HSDPA
Resource
Radio Access
Service
HSDPA
Cell Class
1..1
FddCell FddCell
NodeB NodeB
RNC
NodeB
FddCell
HSDPA
Resource
Radio Access
Service
HSDPA
Cell Class
1..1

Figure 25: FDDCell HSDPA Related new objects

Radio Access
Service
HSDPA User
service

HSDPA RNC
Conf

DlUserService/
HSDSCHx
4SRBDCCH3 4K
DlRbSetConf/
HSDSCH
RlcConfClass/
TRBHSDPAAM

UsHoConf/
HSDSCHx
4SRBDCCH3 4K

DlUsPowerConf/
HSDSCHx
4SRBDCCH3 4K
Nortel confidential
4.1.1.2 RADIO ACCESS SERVICE HSDPA PARAMETERS
param identity user class Recommended Value Unit
isHsdpaAllowed Customer 3 true

4.1.1.3 HSDPA USER SERVICE PARAMETERS
cqiRepetitionFactor Customer 3 1
ackNackRepetitionFactor Customer 3 1
cqiFeedbackCycleK Customer 3 2 ms
discardTimer Customer 3 500 ms
hsScchPowerOffset Customer 3 <unset> dB
macHsWindowSize Customer 3 32
measurementPowerOffset Customer 3 15 0,5 dB
nackPowerOffset Customer 3 7
cqiPowerOffset Customer 3 6
ackPowerOffset Customer 3 6
TimerT1 Customer 3 100 ms

Note:
cqiPowerOffset, ackPowerOffset and nackPowerOffset parameters are
configured with 3GPP defined signalling values matching quantized amplitude
ratios:
3GPP Signalling values for
ACK
,

NACK
and
CQI
Quantized amplitude ratios
8 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 5/15

Maximum Power Offset value:

20
10
PowerOfset
= 30/15
<=> deltaPowerOffset = 20 log
10
(2) = 6 dB

Nortel confidential
4.1.1.4 HSDPA RNC CONF SUBTREE
HSDPA
RncConf
HsdschFlow
Information
Source
Conformance
Information
SpiConfiguration
03

Figure 26: HSDPARncConf subtree

4.1.1.4.1 HSDPA RNC CONF PARAMETERS
deltaCfnForHsdpaChannelTypeSwitching Manufacturer 3 80
deltaCfnForHsdpaMobility Manufacturer 3 45
deltaCfnForHsdpaRLCReconfiguration Manufacturer 3 0
isRLCReconfigurationForChannelTypeSwitching Manufacturer 3 true flag
maxIubHsDschFrameSize Manufacturer 3 1480 bytes
nbOfSpiConfiguration Manufacturer 3 0
suspendTimeOffset Manufacturer 3 30
frame
(10ms)

4.1.1.4.2 HSDSCH FLOW INFORMATION PARAMETERS
maxNumberOfRetryRequest Customer 3 20
minTimeBetweenRequest Customer 3 500

4.1.1.4.3 SOURCE CONFORMANCE INFORMATION PARAMETERS
maximumBucketSize Customer 3 250000 bytes
maximumTokenGenerationRate Customer 3 500000 bytes/s
sourceConformanceStatus Customer 3 Off
Nortel confidential

4.1.1.4.4 SPI CONFIGURATION PARAMETERS
table identity param identity user class Recommended Value
SpiConfiguration/0 backgroundSpi Customer 3 0
SpiConfiguration/0 interactiveSpi Customer 3 0
SpiConfiguration/0 priorityLevel Customer 3 1
SpiConfiguration/0 streamingSpi Customer 3 0

Note: One instance of SpiConfiguration is configured per priority level.

V4.2 Restriction:
Spi Configuration feature is not supported. All Spi values have to be set to the same
value and HsdpaRncConf nbOfSpiConfiguration is kept to 0.

4.1.1.5 HSDPA CELL CLASS PARAMETERS
maximumNumberOfUsers Customer 0 20
minimumPowerForHsdpa Customer 0 <Unset> dB
numberOfHsPdschCodes Customer 0 5
numberOfHsScchCodes Customer 0 1

Note:
OAM minimumPowerForHsdpa value is relative to maximum power. The following
formula is used to get the power reserved for HSDPA traffic:
P
minhsdpa
[dBm] = Pmax [dBm] - minimumPowerForHsdpa [dB]

Nortel confidential
Then the less power we want to reserve for HSDPA, the maximum value is to be
configured for minimumPowerForHsdpa (OAM parameter).
The recommended value <unset> deactivated HSDPA power reservation.

Note: in RNC MIB, minimumPowerForHsdpa unit is 0.1dB (value multiplied by 10
during OAM/RNC mediation).

4.1.1.6 ALWAYS ON TIMER HSDPA PARAMETERS
timerT1ForHsdpa Customer 3 10000 ms
timerT2ForHsdpa Customer 3 60000 ms

4.1.1.7 HSDPA RADIO BEARER SUBTREE
One downlink radio bearer instance is dedicated to HSDPA.

DlRbSetConf/
HSDSCH
DlDynamic
ParameterPerDch

Figure 27: HSDPA Radio Bearer subtree

Nortel confidential
4.1.1.7.1 HSDSCH DL RADIO BEARER PARAMETERS
allowedDlRbSetForMatching Customer 3 <unset>
dlBlerQuality Customer 3 -2
dlOutOfOrderSduDeliveryMethod Manufacturer 3 InSequence
dlRbRateAdaptationDownsizeThreshold Customer 3 unset Kbytes/s
dlRbRateAdaptationUpsizeThreshold Customer 3 unset Kbytes/s
dlRlcQueueSize Manufacturer 3 64 nb of SDU
dlSrbErrorMatching Manufacturer 3 0
dlSyncRetryPeriod Manufacturer 3 100
enabledForRABMatching Customer 3 true
endpoint Manufacturer 3 5 ms
isAdaptiveRlcStatusFilterEnabled Manufacturer 3 false
isAlwaysOnAllowed Customer 3 Degraded2AlwaysOnOnly
isDlRbRateAdaptationAllowedForThisDlRbSetConf Customer 3 False
isDlReferenceTransportChannelAllowed Customer 3 False
isThisRbRateAdaptationDlRbSetTargetAllowed Customer 3 False
iubIurTransportQosId Customer 3 2
iuCsTransportQosId Customer 3 1
maxDlSyncRetries Manufacturer 3 5
nInit Manufacturer 3 3
periodicDlSyncInterval Manufacturer 3 10 s
qaal2EquivalentBitRate Customer 3 0
Nortel confidential
qaal2EquivalentSSSARSDULength Customer 3 1 bit/s
reEstablishTimer Customer 3 reestablishTimerUseT315 bytes
rlcConfClassId Customer 3 RlcConfClass/TRBHSDPAAM
rncWs Manufacturer 3 3 ms
slidingWindowSize Manufacturer 3 3
startPoint Manufacturer 3 50 ms
syncWaitInterval Manufacturer 3 100 ms
tInit Manufacturer 3 500 ms

Nortel confidential
4.1.1.7.2 DL DYNAMIC PARAMETER PER DCH PARAMETERS
dlFpMode Customer 3 dlFpModeSilent
dlRateMatchingAttribute Customer 3 256

4.1.1.8 HSDPA USER SERVICE SUBTREE
One downlink user service instance is dedicated to HSDPA.
DlUserService/
HSDSCHx
4SRBDCCH3_4K
IntraFreqTarget
CellParams
IrmScheduling
DowngradeTran
CodePower
LowRbA

Figure 28: HSDSCHx4SRBDCCH3_4K subtree

Nortel confidential
4.1.1.8.1 HSDSCHX4SRBDCCH3_4K DL USER SERVICE PARAMETERS
isGsmCModeActivationAllowed Customer 3 false
isInterFreqCModeActivationAllowed Customer 3 false
cmodePCDeltaSir1 Manufacturer 3 0 dB
cmodePCDeltaSirAfter1 Manufacturer 3 0 dB
cmodePCItp Manufacturer 3 cmodeItpMode0
cmodePCRpp Manufacturer 3 cmodeRppMode0
dlRbSetConfId Manufacturer 3 17
dlReferencePower Customer 3 -12,5 dB
powerBalancingRequired Customer 3 true
isAlwaysOnAllowed Customer 3 true
isDlRbRateAdaptationAllowedForThisDlUserService Manufacturer 3 false
isIrmSchedulingAllowed Customer 3 false
isIrmSchedulingUpgradeAllowedFromThisUS Customer 3 false
isIrmSchedulingUpgradeAllowedToThisUS Customer 3 false
isTransCodePowerIrmSchedulingDowngradeAllowedFromThisDlUserService Customer 3 false
minimumCpichEcNoValueForHO Customer 3 -13 dB
minimumCpichRscpValueForHO Customer 3 -100 dBm
po1ForTfciBits Manufacturer 3 0
po2ForTpcBits Manufacturer 3 24
po3ForPilotBits Manufacturer 3 0

Nortel confidential
4.1.1.8.2 INTRAFREQTARGETCELLPARAMS PARAMETERS
minimumCpichEcNoValueForHho Customer 3 -13 dB
minimumCpichRscpValueForHho Customer 3 -100 dBm

Note: IrmSchedulingDowngradeTransCodePower and LowRbA objects are
mandatory but useless as IRM scheduling is not supporter on HSDPA service.

4.1.1.9 HSDPA RLC PARAMETERS
RlcConfClass/
TRBHSDPAAM
DlRlcAckMode

Figure 29: HSDPA RLC subtree

Only RLC Acknowledge mode is used for HSDPA.

epcTimer Customer 3 <unset>
lastRetransPuPoll Customer 3 true
lastTransPuPoll Customer 3 true
maxDat Customer 3 10
maxNbrOfResetRetrans Customer 3 6
misPuIndic Customer 3 true
nbrOfPuBetweenPolling Customer 3 128
nbrOfSduBetweenPolling Customer 3 <unset>
pollingTimer Customer 3 150 ms
Pollwindow Customer 3 pollWindow80
prohibitedPollingTimer Customer 3 70 ms
prohibitedStatusTimer Customer 3 70 ms
Nortel confidential
receptionWindowSize Customer 3 2047
resetTimer Customer 3 500 ms
timerPollPeriod Customer 3 <unset>
timerStatPeriod Customer 3 <unset>
transmissionWindowSize Customer 3 2047

4.1.1.10 HSDPA USHOCONF SUBTREE
UsHoConf/
HSDSCHx
4SRBDCCH3_4K
AlarmHardHoConf
FastAlarmHard
HoConf
SoftHoConf
FullEventHOConf
ShoMgt
FullEventHOConf
HhoMgt

Figure 30: HSDPA UsHoConf subtree

4.1.1.10.1 USHOCONF PARAMETERS
FastAlarmHhoStrategy Customer 3 interFrequency N.A.

4.1.1.10.2 SOFTHOCONF PARAMETERS
legAdditionDelta Customer 3 4 dB
legDroppingDelta Customer 3 8 dB
MaxActiveSetSize Customer 3 4
shoLinkAdditionAbsoluteThresholdEnable Customer 3 False
shoLinkDeletionAbsoluteThresholdEnable Customer 3 True
shoLinkDeletionDelayEnabled Customer 3 False
shoLinkDeletionDelayTimeOut Customer 3 4000
shoAlgorithmExtension Manufacturer 3 <unset>
Nortel confidential

4.1.1.10.3 SHOLINKADDITIONPARAMS PARAMETERS
shoLinkAdditionActiveSetSizeConsideration
Customer 3 alwaysApplyAlgoExtension
shoLinkAdditionCpichEcNoThreshold
Customer 3 -11 dB
shoLinkAdditionCpichRscpThreshold
Customer 3 -115 dBm

4.1.1.10.4 SHOLINKDELETIONPARAMS PARAMETERS
shoLinkDeletionActiveSetSizeConsideration
Customer 3 alwaysApplyAlgoExtension
shoLinkDeletionCpichEcNoThreshold
Customer 3 -16 dB
shoLinkDeletionCpichRscpThreshold
Customer 3 -115 dBm

4.1.1.10.5 ALARMHARDHOCONF PARAMETERS
Cap2MobDeltaEcNoBorder
Customer 3 16 dB
Counter
Customer 3 5
cpichEcNoThreshold
Customer 3 -15 dB
cpichRscpThreshold
Customer 3 -100 dBm
Mob2CapDeltaEcNoBorder
Customer 3 6 dB
nbConditionsFullfilledBeforeBlindInterFreqHo
Customer 3 5
stepDown
Customer 3 2
stepUp
Customer 3 1

4.1.1.10.6 FASTALARMHOCONFPARAMETERS
BlindHhoTimerForFdd Customer 3 8000 ms
BlindHhoTimerForGsm Customer 3 8000 ms
Counter Customer 3 5
cpichEcNoThreshold Customer 3 -15 dB
cpichRscpThreshold Customer 3 -100 dBm
stepDown Customer 3 2
stepUp Customer 3 1
Nortel confidential

4.1.1.10.7 FULLEVENTHOCONFSHOMG PARAMETERST
cpichEcNoReportingRange1A Customer 3 4.5 dB
cpichEcNoReportingRange1B Customer 3 6 dB
cpichEcNoThresholsUserFreq1E Customer 3 -11 dB
cpichEcNoThresholsUserFreq1F Customer 3 -15.5 dB

4.1.1.10.8 FULLEVENTHOCONFHHOMGT PARAMETERS
IntraFreqInterRnc_cpichEcNoReportingRange Customer 3 0
timerAlarmHoEvent Customer 3 2500

4.1.1.11 DLUSPOWERCONF
algo1DeltaTargetPower
Customer 3 6 dB
algo2DeltaTargetPower
Customer 3 3 dB
initialDlEcnoTarget
Customer 3 -24 dB
maxDlTxPower
Customer 3 -10 dB
minDlTxPower
Customer 3 -18 dB
dlIrmSchedDowngradeTxcpTrigger_threshold_delta
Customer 3 unset 0,5 dB
dlIrmSchedDowngradeTxcpTrigger_timeToTrigger
Customer 3 unset ms
dlIrmSchedDowngradeTxcpAllowed
Customer 3 false

4.1.1.12 FDDCELL IMPACT
4.1.1.12.1 HSDPA FDD CELL PARAMETERS
hsdpaActivation Customer 2 true

4.1.1.12.2 HSDPA RESOURCE PARAMETERS
Nortel confidential
hsdpaCellClassId Customer 2 hsdpacellclass/0 pointer

4.1.1.12.3 INTERFREQHHOFDDCELL HSDPA PARAMETERS
isRedirectionForTrafficSegmentation Customer 3 false
isRedirectionBasedOnEstablishmentCause Customer 3 false

4.1.2 BTS IMPACT
4.1.2.1 NEW OBJECT
BTSEquipment
HSDPA Conf
FddCell FddCell BtsCell
BTSEquipment
HSDPA Conf
FddCell FddCell BtsCell

Figure 31: HSDPA BTS new object

4.1.2.3 BTSCELL HSDPA PARAMETERS
hsdpaResourceActivation Customer 0 true

4.1.2.4 HSDPACONF PARAMETERS
dchPowerMargin Customer 3 20 %
harqNbMaxRetransmissions Customer 3 7
harqType Manufacturer 3 mirType (1)
hsdpaResourceId Customer 0
Nortel confidential
hsdschInterval Customer 3 50 ms
hsscchPcOffset
Customer 3
[0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0 -3.0 -3.0 -5.0 -5.0 -
8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -
8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -
8.0 -8.0 -8.0 -8.0 -8.0]
dB
maxRateGrowth Manufacturer 3 8

Note: The following rule needs to be respected :
2*HSDSCH_Interval*MaxRateGrowth/4 < discardTimer
2*HSDSCH_Interval*MaxRateGrowth/4 < suspendTimeOffset

4.1.3 IUB IMPACT
4.1.3.1 NEW OBJECT
Inode/EM
RncIn
Fc

Figure 32: IuB HSDPA new object

4.1.3.2 FC HSDPA PARAMETERS
iubFlowControlActivation N.A. N.A. discardAndBackPressure
qosDiscardThreshold N.A. N.A. 0,300,500,0 % one value per qosId
qosBackPressureThreshold N.A. N.A. 0,95,95,0 % one value per qosId

4.1.3.3 IUB TRANSPORT RECOMMENDATIONS
One IuB HSDPA dedicated VCC needs to be configured per BTS with qosId=2 and
serviceCategory UBR.
Nortel confidential
If more than one E1 per BTS is configured, IMA is mandatory.

For more transport details, refer to [R9] UA4.2 IuB Transport Engineering Guide.

4.2 HSDPA ACTIVATION
Refer to [R10] NTP 411-8111-575 HSDPA Feature Activation Procedure posted at
www.nortel.com.

Nortel confidential

Nortel confidential
6 UA4.2 HSDPA SPECIFIC FEATURES & IMPACT
ON EXISTING ALGORITHMS
6.1 ALWAYS ON
6.1.1 MECHANISM
The always-on mechanism applies to HSDPA the same way as for R99 radio bearers.
In R99, Always-on is applicable only for Interactive/Background traffic.
In UA4.2, only Interactive/Background traffic is mapped on HSDPA. Then,
Always-on applies to all traffic carried by HSDPA.

In the both cases, Always-on allows to optimize radio resource usage for bursty traffic
(low activity factor):
In DL, the HSDPA CAC allows a limited number of users connected
simultaneously on HSDPA (H-BBU hardware limitation). Thats why we should
not keep users connected too long if they are not transmitting, preventing
other users from being accepted on HSDPA.
In UL, the matter is the same as for R99 traffic because UL traffic associated
to HSDPA is carried on a DCH. Keeping users connected too long on HSDPA
is a waste of radio resources (CEM).

Moreover, for HSDPA, specific signalling procedure for HS-DSCH Flow Control
mechanism induces additional RNC processing during entire connection time, even
inactivity periods (periodic message during all connection time on HSDPA).

The monitoring of user activity at RLC level (DTCH) for both UL and DL is the same as
for R99. Nevertheless, some new parameters appear. Lets introduce them in the next
chapters.

6.1.2 ACTIVATION & MODE
6.1.2.1 ACTIVATION
Always-on has to be activated on HSDPA. 3 parameters are to be set:

Nortel confidential
First, Always-on has to be activated on RNC :
Parameter isAlwaysOnAllowed Object AlwaysOnConf
{True, False}
User Customer
Class 3
Granularity N.A.
Value False (de-activate the feature)
True (activate the feature)

Then, Always-on has to be activated on user service :
Parameter isAlwaysOnAllowed Object DlUserService
{True, False}
User Customer
Class 3
Granularity DlUserService
Value True (new instance DlUserService/27)

The suitable Always-on mode has to be set on RB configuration:
Parameter isAlwaysOnAllowed Object DlRbSetConf
Range & Unit Enumeration
{disabled, degraded2AlwaysOnOnly, releaseOnly}
User Customer
Class 3
Granularity DlRbSetConf
Value degraded2AlwaysOnOnly (new instance DlRbSetConf/17)

For HSDPA, the only supported mode for Always-on Step 1 (Downsize) is
CELL_FACH.
Parameter preferredTransportTypeForAlwaysOn Object AlwaysOnConf
Range & Unit Enumeration
{Fach, Dch}
User Customer
Class 3
Granularity N.A.
Value Fach

6.1.2.2 DOWNSIZE / RELEASE (2 STEPS)
There are 2 steps in the Always-on mechanism for the downsize part:
o Step 1: The user is first downsized after a period T1 of low activity (or
inactivity). The associated timer for HSDPA is a new parameter:
timerT1ForHsdpa.
o Step 2: The user is then released after a period T2 of inactivity. The
associated timer for HSDPA is the existing parameter: timerT2.

Nortel confidential

Figure 33: Always-on for HSDPA (degraded2AlwaysOn mode)

The downsize condition is the same as for R99.
When downsizing to CELL_FACH, if no resource are available (CAC failure on
FACH), the call is released (as in R99).

6.1.2.3 RELEASE (1 STEP)
In this mode, the Always-on feature directly releases the user after a period T2 of
inactivity. The timer used is a new parameter timerT2ForHsdpa.
Activity (UL or DL)
Low activity /
Inactivity
Downsize timer
(timerT1ForHsdpa)
HSDPA + UL DCH
Downsized RB (CELL_FACH)
Release timer
(timerT2)
t
Always-on (degraded2AlwaysOnOnly)
Downsize
Release
Inactivity
t
Traffic UL/ DL
Nortel confidential

Figure 34: Always-on for HSDPA (releaseOnly mode)

6.1.2.4 UPSIZE
For Always-on upsize, the mechanism and the parameters are the same as for R99.
When upsizing to HSDPA, if no resource are available, UE is kept in CELL_FACH
state and will retry to do an upsize later, if upsize conditions are still fulfilled.

6.1.2.5 OTHER TRANSITIONS
When an HSDPA capable UE in Always-on downsized state (on CELL_DCH) moves
to an HSDPA cell, the RB is reconfigured to HSDPA. If HSDPA CAC fails, the RAB is
released.

Activity (UL or DL) Low activity
Release timer
(timerT2ForHsdpa)
t
Always-on (releaseOnly)
Release
Inactivity
t
Traffic UL/ DL
HSDPA + UL DCH
Nortel confidential
6.1.3 REMINDER FOR TIMER USAGE

Always-on mode T1 T2
degraded2AlwaysOn timerT1ForHsdpa timerT2 HSDPA
releaseOnly timerT2ForHsdpa
degraded2AlwaysOn timerT1 timerT2 R99
releaseOnly timerT2
Table 10 : Always-on timer usage

6.1.4 PARAMETERS SETTINGS AND RECOMMENDATIONS
Parameter timerT1ForHsdpa Object AlwaysOnTimer
Range & Unit [10..3600000] (ms)
User Customer
Class 3
Granularity OLS
Value 10000

10000 (i.e. 10 s) is the recommended value, to allow relative early transition to
CELL_FACH if UE is inactive. This avoids UE processing waste on HS-SCCH
decoding if inactive. Delay for transition from CELL_FACH to CELL_DCH is fast (<
600 ms) in case the user becomes active again.

The timeT2ForHsdpa is only used in case the always on mechanism is configured to
release the call without going through the downsized state (release only).
Parameter timerT2ForHsdpa Object AlwaysOnTimer
Range & Unit [10..10800000] (ms)
User Customer
Class 3
Granularity OLS
Value 60000

10000 (i.e. 10s) is the recommended value. This is the same value as for
timerT1ForHsdpa .which is the time the system keeps the user connected on the
HSDPA channel.

Nortel confidential
6.2 IRM ALGORITHMS
6.2.1 IRM SCHEDULING DOWNGRADE/UPGRADE
INTERWORKING
HSDPA links are not eligible to iRM scheduling downgrade/upgrade procedures.

6.2.2 IRM CAC/IRM PRE-EMPTION INTERWORKING
HSDPA links are not eligible to iRM Cac/iRM Pre-Emption procedures since the
throughput adaptation is provided by the Mac-hs scheduler i.e. the more users
multiplexed on HS-DSCH, the less users will be allocated high bit rates.

However, as it is possible to reserve some power for HSDPA users, this power shall
be consider as consumed in cell colour calculation for the HSDPA cells. In the same
way, OVSF codes reserved for HS-PDSCH and HS-SCCH are considered to be used
in the cell colour calculation. On the Iub, the Iub load colour takes into account the
actual traffic on the link on a selected set of VCC QoS, so may include or not HSDPA
traffic according to operators provisioning.

6.2.3 RB ADAPTATION INTERWORKING
HSDPA links are not eligible to RB Adaptation procedures.

Note: the RB Adaptation is applied independently on the UL links (mapped on dch
channels).

6.3 MOBILITY PROCEDURES
This section describes the existing mobility procedures for HSDPA calls.
If there is any error during any HSDPA mobility procedure or if it is not possible to re-
establish HS-DSCH on the new primary (CAC failure), the RAB is released.
Mobiles can be spread over the HSDPA and the not-HSDPA layers thanks to the
Traffic Segmentation feature at RRC connection establishment. However, note that
the intra-RNC inter-frequency HO for capacity/mobility layers cannot be used with
Traffic Segmentation (if one of the two twin cells is HSDPA configured).

Nortel confidential
6.3.1 INTRA-FREQUENCY MOBILITY
6.3.1.1 MOBILITY OF ASSOCIATED DCH
Soft and softer handovers are handled normally on the associated DCHs and the
Active Set is managed as usual.

For more details, see the Mobility chapter in [R1]

6.3.1.2 MOBILITY OF HS-DSCH
As defined by 3GPP, HS-DSCH is established in only one cell so is never in soft
handover. In Nortel implementation, the serving HS-DSCH RL always follows that of
the primary cell.
Mobility is done as long as the target cell is HSDPA capable.
When the primary cell changes:
If the former primary is no longer present in the new Active Set (following an
Active Set Update procedure), the HS-DSCH link is immediately released
(RNSAP RL Deletion) before the RRC Measurement Control procedure. A
new HS-DSCH link is then setup using a normal SRLR procedure on the
new primary cell, after the Measurement Control.
If the former primary remains in the Active Set, the HS-DSCH RL is deleted on
the former primary (right after the RRC Measurement Control procedure) and
it is re-established under the new one synchronously via the RRC RB
Reconfiguration message.
If the new primary cell does not support HSDPA then the RB is reconfigured
to DCH. iRM CAC is performed and if there is a CAC failure the call is
dropped.
If the new primary cell supports HSDPA while the former did not, then the RB
is reconfigured to HS-DSCH. This is also applicable to the case where the UE
was downgraded on DCH because of Always-On step1.

During the reconfiguration, data transfer is suspended by the RNC. Data that were in
the Mac-hs buffer of the former cell are discarded (except if both cells are managed by
the same HBBU board). User data are not lost thanks to RLC retransmissions but if
the primary cell changes too often, the data throughput can be impacted.

Nortel confidential

Figure 35: HS-DSCH link is deleted and re-established on new primary (nominal case)

In case of TMA usage, externalAttenuationMainDivUL/DL values need to be
accurately filled with cable losses. Otherwise, HSDPA mobility can be highly impacted
(UL reception asymmetry for soft handover).

6.3.1.3 MOBILITY OVER IUR
HS-DSCH is currently not managed over Iur:
If the primary cell moves under the control of a drift RNC, then the serving
RNC acts as if this cell was not supporting HSDPA (the RNSAP RL Setup with
an HS-DSCH link would be refused). The RB is then reconfigured to DCH
(iRM CAC is performed).
When the mobile comes back under the serving RNC (the primary cell is in
that RNC) and the primary cell supports HSDPA, the radio bearer is
reconfigured to HS-DSCH.

RNC Node B
source
Node B
target
UE
RB Reconfiguration (Activation CFN)
RL Reconfiguration Ready
Measurement Control (new neighbouring list)
RL Reconfiguration Prepare (HS-DSCH information)
RB Reconfiguration Complete
Primary cell change
RL Reconfiguration Ready
RL Reconfiguration Prepare
(MAC-d flow to Delete)
RL Reconfiguration Commit (Activation CFN)
Activation CFN
RL Reconfiguration Commit
(Activation CFN)
Nortel confidential
6.3.2 INTER-FREQUENCY MOBILITY
Inter-frequency hard handover is not supported for HSDPA calls.
If the mobile leaves the coverage of the HSDPA layer, the call is dropped from the
source RNC perspective but the PDP context is still active (transparent to the user):
The UE may perform a 3G cell reselection on a second frequency and then
resume the 3G call. If the reselected primary cell is HSDPA capable, the call
will be reconfigured to HSDPA after its re-establishment.
The UE may be handed to 2G, either in blind mode or selecting the best cell
(this last option is only possible when the mobile can make 2G measurements
without compressed mode).

When the UE is on DCH and it performs an inter-frequency hard handover towards an
HSDPA cell, the HHO will end on a DCH configuration even if all conditions to swap to
HSDPA are fulfilled. Following the inter-frequency procedure, a primary radio link
update procedure shall be performed, and it may lead to a HSDPA configuration.
In the case of an incoming handover from another UTRAN, the call will be also
established on DCH. After the handover completion, the RNC will perform an UE
Capability Enquiry procedure. If the UE is HSDPA capable then the RB is reconfigured
to HSDPA (if the target cell is configured with HSDPA and if it is a mono PS I/B call).

6.3.3 INTER-SYSTEM MOBILITY
The RNC will not configure Compressed Mode when the call is on HSDPA. This does
not prevent non-HSDPA calls from using CM. This also does not prevent mobiles that
do not need CM to perform measurements to be handled normally (and perform
mobility procedures with measurements) for the inter-RAT mobility.
If a call is switched from DCH to HS-DSCH while Compressed Mode is active (it was
activated when the call was on DCH), CM is deactivated at HS-DSCH Activation Time.

6.3.3.1 3G TO 2G HANDOVER
Handover is supported for 3G-2G mobility.
The UE may be handed to 2G, either in blind mode or selecting the best cell (this last
option is only possible if the mobile can make 2G measurements without compressed
mode). The Compressed Mode is not supported for HSDPA calls in the current
release.
If there are measurements available and valid, they must be used to determine the
target GSM cell as usual.
The handover is triggered on the same alarm conditions than for non-HSDPA calls.

Nortel confidential
6.3.3.2 2G TO 3G HANDOVER
From the target RNC, this is seen as a new Mobile Originated PS call. The same rules
as the initial admission apply, leading possibly to the allocation of HS-DSCH to the
incoming UE.

6.3.4 U-PLANE TRAFFIC HANDLING
There are 2 aspects to consider during HSDPA mobility:
1. Traffic handling policy toward the source cell.
This policy is only applicable when the old serving HS-DSCH RL is still part
of the Active Set. At time (Activation Time Suspend Time Offset), the RNC
no longer sends data to the source cell.

2. HS-DSCH credit acquisition policy from the target cell.
Based on the following NodeB behaviour specifications:
All HS-DSCH Capacity Requests that are sent to the NodeB before
the starting activation time are silently discarded.
When the credits are not yet explicitly granted, the NodeB silently
discards HS-DSCH data coming from the RNC (i.e. no HS-DSCH
Capacity Allocation is sent to the RNC).
After the activation time, on the first HS-DSCH Capacity Request with
nonzero BO, the NodeB immediately replies with HS-DSCH Capacity
Allocation.
In the steady-state (after that first HS-DSCH Capacity Request
message), the NodeB will reply to each non-zero BO HS-DSCH
Capacity Request only if the buffer allows it. If not, the NodeB updates
the BO information, drops the Request and waits for the next one.
The NodeB periodically sends a new HS-DSCH Capacity Allocation to
the RNC based on the BO that is piggy-backed in each HS-DSCH
data frame (no need to wait for a Capacity Request).

The RNC HS-DSCH initial credit acquisition policy is as followed:
1. If an initial HS-DSCH credit is explicitly returned by the NodeB in the NBAP
RL Reconfiguration Ready message, the RNC will start to use that credit at
the activation time. Otherwise, the RNC will assume that the credits are set to
zero. This is applicable to both intra and inter-NodeB mobility cases.
2. At the activation time, if the HS-DSCH credit is zero and there are outstanding
data to be transmitted, the RNC will initiate the HS-DSCH Capacity Request
toward the target cell in the u-plane nothing will be sent before the activation
time.
Nortel confidential

6.3.5 SUMMARY OF INTER-FREQUENCY AND INTER-RAT
SCENARIOS

Figure 36: Summary of Inter-freq/inter-RAT mobility

6.4 POWER MANAGEMENT
6.4.1 INTRODUCTION
The HSDPA principle is to allocate the power not used by DCH calls to HSDPA
channels. This implies an accurate power management in order to not impact DCH
calls and to allow the highest data rate on HSDPA channels.

Power management is based on two features:
the flexible power management feature,
the HS-SCCH power control feature.

6.4.2 FLEXIBLE POWER MANAGEMENT FEATURE
6.4.2.1 AIM
The aim of this feature is to adapt the power allocated to HSDPA channels according
the DCH power variation without impacting DCH calls.

HSDPA Layer
Non HSDPA Layer
2G Layer
HO on Alarm
(blind if mobile needs CM)
Cell Reselection by UE if
coverage is lost
1
1
2
2
Nortel confidential
6.4.2.2 POWER ALLOCATION
6.4.2.2.1 RNC LEVEL
First, the RNC reserves power for common channels. Typically, the common channels
power is equal to about 20-25% of the maximum cell power noted P
MaxCell
in the
following figure.

P
maxHsdpa
CCC
SHO margin
R
N
C
OCNS (opt.)
P
minHsdpa
P
MaxCell
P
traffic

Figure 37: Power allocation at RNC level

When OCNS is required (for cell loading during acceptance or trial tests), his power is
defined as a percentage of the power not used by common channels such as:
P
OCNS
= (P
MaxCell
- P
CCC
) x OCNSpower

where OCNSpower = [0 100]%

It is possible to reserve a minimum power for HSDPA noted P
minHsdpa
that is subtracted
from the power of the DCH pool. This power is defined through the
minimumPowerForHsdpa parameter such as:
P
minHsdpa
= P
MaxCell
minimumPowerForHSDPA

So, the higher this parameter, the lower the minimum power for HSDPA. This power is
reserved for the purposes of the Call Admission Control (CAC) only and then can not
be guaranteed at NodeB level if some DCH users need more power. This reservation
limits the DCH admission. This power is reserved after OCNS one (if OCNS is
activated in the cell) and this may lead to refuse the configuration of HSDPA if there is
not enough power.

Nortel confidential
Rule: Relationship between OCNS power and minimum power for HSDPA
The minimum power for HSDPA P
minHsdpa
is reserved after OCNS one (if OCNS is
activated in the cell) and this may lead to refuse the configuration of HSDPA if there is
not enough power.
P
minHsdpa
< P
MaxCell
- P
OCNS
- P
CCC

Note: the activation of OCNS with HSDPA requires modifications of OCNS
parameters:
OCNSChannelizationCodeNumber (Manufacturer attribute,
OCNSChannelParameters Object) must be changed from 7 to 1, so as to
enable the compatibility of OCNS and HSDPA codes allocations.
If additional R99 calls are to be established on the same HSDPA/OCNS cell,
the parameter OCNSSpreadingFactor (Manufacturer attribute, FDDCell
Object) must be changed from spreadingFactor8 to a higher value
(recommended spreadingFactor32, but not higher).

The minimum power for HSDPA is managed by the RNC as the SHO margin. It is a
power reservation used only for CAC and can not be guaranteed at NodeB level. The
SHO margin allows to reserve power for the users in soft handover and can not be
used for users in first admission. This power is a percentage of the traffic power:
P
SHO
= (1 - CallAdmissionRatio).P
traffic

with P
traffic
= P
MaxCell
- P
CCC
- P
OCNS
P
minHsdpa

Recommended value for CallAdmissionRatio is 85%

This leads to define the maximum power that the RNC can allocated to HSDPA
channels: P
maxHsdpa
. This maximum power is computed at the RNC and given to
NodeB during the cell setup inside the physical shared reconfiguration channel NBAP
message. This upper limit for HSDPA correspond to the maximum downlink transmit
power of the cell minus the power needed for the common channel, the power for
eventual OCNS and the power reserved for SHO:
P
maxHsdpa
= P
MaxCell
- P
SHO
- P
CCC
- P
OCNS

This maximum power is transmitted from the RNC to the NodeB in the information
element (IE) HS-PDSCH_and_HS-SCCH_total_power through the PHYSICAL
SHARED CHANNEL RECONFIGURATION MESSAGE during the cell setup. If it is
not present, HSDPA can be allocated the whole power. The number of HS-PDSCH
and HS-SCCH reserved in the cell are also sent through this message, respectively in
Nortel confidential
the IE HS-PDSCH_FDD_code_information and HS-SCCH_FDD_code_information
(see the following figure).

PHYSICAL SHARED CHANNEL
RECONFIGURATION MESSAGE
during Cell Setup
HS-PDSCH_FDD_code_information
HS-PDSCH_and_HS-SCCH_total_power
HS-SCCH_FDD_code_information
HS-PDSCH_FDD_code_information
HS-PDSCH_and_HS-SCCH_total_power
HS-SCCH_FDD_code_information

Figure 38: Physical shared channel reconfiguration message

6.4.2.2.2 NODEB LEVEL
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 DCH
margin (see the following figure). HSDPA channels can not use this margin. If the
power for DCH calls exceeds the DCH power margin then HSDPA will reduce his
power to provide DCH calls with power resource.

CCC
DCH margin
DCH N
o
d
e
B
OCNS (opt.)
P
TotNonHsdpa
P
MaxCell
P
Remain
P
TotNonHsdpaWithMargin

Figure 39: Power allocation at NodeB level

The power consumed by this DCH margin depends on the dchPowerMargin
parameter. This parameter is a percentage of the non HSDPA power minus the P-
CPICH power:
P
DCHmargin
= dchPowerMargin.(P
TotNonHsdpa
P
CPICH
)
Nortel confidential

where P
TotNonHsdpa
is the sum of the DCH power, OCNS power and common channels
power:
P
TotNonHsdpa
= P
DCH
+ P
OCNS
+ P
CCC

The dchPowerMargin parameter should 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.

The remaining power P
Remain
is the power usable by HSDPA:
P
Remain
= P
MaxCell
P

with P
= P
TotNonHsdpa
+ P
DCHmargin

Note that the common channels power used by the NodeB is fewer than power
reserved by RNC because of time multiplexing of several common channels.

6.4.2.2.3 POWER AVAILABLE FOR HSDPA CHANNELS
Flexible power management feature consists in using for HSDPA all the remaining
power left by dedicated and common channels according the RNC upper limit. Then,
the power available for HSDPA is defined by:
P
HSDPA
= min(P
Remain
, P
maxHsdpa
)

6.4.2.3 POWER MEASUREMENTS
The computation of the available HSDPA power requires some power measurements.

6.4.2.3.1 TRANSMITTED CARRIER POWER
The transmitted carrier power P
TotCell
(see the following figure) is the total cell power
consumed by all codes. This transmitted carrier power is measured and
communicated within the BTS every 100ms through a Power Management Message
(PMM) ATM cell.

6.4.2.3.2 AVERAGED HSDPA POWER
The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes
P
TotHsdpa
(see the following figure) is computed and updated any TTI. An exponential
Nortel confidential
averaging is applied, whose coefficient is chosen to be coherent with the PMM
measurement. Any TTI, the following processing must then be done:
P
TotHsdpa
(TTI) = Rho.P
TotHsdpa
(TTI 1) + (1 Rho).P
InstHsdpa
(TTI)

where P
InstHSDPA
corresponds to the total transmitted power of HSDPA over the TTI in
linear, and Rho is the weighting factor (Rho = 0.9775). P
TotHSDPA
should be initialized
with the instantaneous value.

Power
consumed by
all codes
N
o
d
e
B
P
MaxCell
P
TotCell

Power
consumed by
non HSDPA
codes
N
o
d
e
B
P
MaxCell
P
TotCell
HSDPA
P
TotHsdpa

Figure 40: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)

6.4.2.3.3 TOTAL NON HSDPA POWER
The total power not used by HSDPA (P
TotNonHsdpa
) is then computed over the last
period by subtracting the total HSDPA power to the total cell power:
P
TotNonHsdpa
= P
TotCell
- P
TotHsdpa

This measurement is reported (see the following figure) from the NodeB to the RNC
through a COMMON MEASUREMENT message in the element information (IE)
Transmitted_carrier_power_of_all_codes_not_used_for_HS-PDSCH_or_HS-
SCCH_Transmission defined as a percentage of the max cell power. This
measurement is used by the RNC CAC on DCH (only for HSDPA cell) instead of
Transmitted_Carrier_Power measurement (this latest continues to be reported and is
still used for non-HSDPA cells). The measurement period is 100ms but the report
periodicity (for these two measurements) toward RNC is much higher (1mn).

Nortel confidential
COMMON MEASUREMENT
Transmitted_carrier_power_of_all_codes_not_used_
for_HS-PDSCH_or_HS-SCCH_Transmission

Figure 41: Common measurement

6.4.2.3.4 AVAILABLE HSDPA POWER
The available power for HSDPA for the next 100ms period can then be computed. It
corresponds to the difference between the maximum available power in the cell
P
MaxCell
and the total non HSDPA power with DCH margin P
. It is
bounded by P
MaxHsdpa
:
P
HSDPA
= min(P
MaxCell
- P
, P
MaxHsdpa
)
with P
= (1+ DchPowerMargin/100) * (P
TotNonHsdpa
- P
CPICH
) + P
CPICH

Nortel confidential
The following flowchart summarize this measurement process:

Update transmitted HSDPA
power (P
TotHsdpa
) any TTI
PMM ATM cell reception any 100ms
Y
ATM cell received ?
Recovery in the ATM payload of the
Transmitted Carrier Power of the
corresponding cell P
TotCell
N
Computation of the Transmitted carrier
power on non HSDPA channels
P
TotNonHsdpa
= P
TotCell
- P
TotHsdpa
P
TotCell
P
TotHsdpa
P
TotNonHsdpa
Assume a margin on the non HSDPA power.
P
Rem
= P
MaxCell
P
Computation of the total HSDPA power available :
P
HSDPA
= min(P
Rem
, P
MaxHsdpa
)
Transmit P
TotNonHsdpa
every
100ms to CallP (common
measurement process)
Use P
HSDPA
as scheduler input
until next refresh
P
HSDPA

Figure 42: Power measurement process

6.4.2.4 HSDPA POWER DISTRIBUTION
6.4.2.4.1 HS-SCCH POWER
The available power for HSDPA P
HSDPA
is shared between HS-SCCH and HS-DSCH
channels (see the following figure).

Nortel confidential
CCC
DCH margin
P
Hsdpa
DCH N
o
d
e
B
OCNS (opt.)
HS-DSCH
HS-SCCH

Figure 43: Power distribution between HS-DSCH and HS-SCCH channels

A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
P
HS-SCCH
< P
HSDPA

If not, the scheduler will try to schedule another user.

The power allocated to HS-SCCH is explained in section dedicated to the feature HS-
SCCH power control.

6.4.2.4.2 HS-DSCH POWER
The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH:
P
Temp
= P
HSDPA
P
HS-SCCH

HSDPA UE needs to have a power as reference in order to adapt his reported CQI to
the radio link condition (in the same radio condition, the reported CQI will be higher if
more power is used to transmit the HS-DSCH channel). Then, the CQI is chosen to
insure a transmission with a BLER < 10% assuming a downlink power equals to:
P
HS-DSCH
[dBm] = P
P-CPICH
[dBm] + [dB] + (CQI
processed
)[dB]

where
P
P-CPICH
is the power of the P-CPICH channel,
is the measurement power offset
is the reference power offset given by the tables of CQI [R5].

Nortel confidential
This reference power P
HS-DSCH
is defined by a power offset compared to the P-CPICH
power. This power offset corresponds to the measurementPowerOffset parameter.
The mobile is able to compute this reference power thanks to the P-CPICH power
measurement and to the measurementPowerOffset parameter. The
measurementPowerOffset parameters is sent from the RNC to the NodeB through
the HS-DSCH FDD INFORMATION message during the Radio Link
Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HS-
PDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration
(see the following figure). In case this parameter is not present in the setup message,
the configuration must then be rejected.

DOWNLINK HS-PDSCH
INFORMATION
during Radio Bearer
Setup/Reconfiguration
HS-DSCH FDD
INFORMATION
during Radio Link
Setup/Reconfiguration
measurementPowerOffset

Figure 44: measurementPowerOffset transmission

In fact, this power can be seen as the HS-DSCH power required by the mobile
corresponding to his reported CQI. From a NodeB point of view, this power is the
maximum power that can be allocated to one HSDPA user even if more power could
be used.

Note that the reference power offset is the one corresponding to the processed CQI
(CQI
processed
) and not the reported CQI (CQI
reported
). See CQI section for more details.

6.4.2.4.3 HS-PDSCH POWER
The power HS-DSCH is equally distributed around the physical channels HS-PDSCH:
P
HS-PDSCH
[dBm] = P
HS-DSCH
[dBm] - 10.log(#codes)

6.4.2.5 HS-DSCH POWER MANAGEMENT
The HSDPA UE requests to the NodeB a CQI corresponding to a reference power
P
HS-DSCH
. The power effectively available at NodeB level can be lower than this
requested power. Then power adjustments are needed. Other resource limitations as
codes limitation can lead to adjust the HS-DSCH power. The following section
Nortel confidential
presents how the scheduler manages the HS-DSCH power according the available
resources.

6.4.2.6 FIRST TRANSMISSION
The transport formats always remain based on the CQI mapping tables. Two different
CQI correspond to different transport formats with the same power to reach the same
performance level, but could also correspond to two different powers with the same
transport format. A step of 1dB is considered to go from one CQI to the next one.

The transport format is determined according to the processed CQI, CQI
processed
. In
case of a lack of resources (codes or power), the applied CQI, CQI
applied
, is then
modified according to the previous rule to take this into account. It is done in four
steps:
Power limitation management,
codes limitation management,
lack of MAC-d PDU in buffer or transport block size limitation (multi-cell per
HBBU for instance),
optimization of CQI according to MAC-d PDU size.

Nortel confidential
The whole process is described in the following figure:
Y
UE selected
P
temp
= P
HSDPA
P
HS-SCCH
P
HS-DSCH
= P
P-CPICH
+ + (CQI
processed
)
P
HS-DSCH
< P
temp
?
P
HS-DSCH
= P
P-CPICH
+
RP
= round(10.log(P
temp
/ P
HS-DSCH
))
CQI
1
= CQI
processed
+
RP
RP
= 0
CQI
1
= CQI
processed
CQI
1
> 0 ?
n
codes
= f(CQI
1
)
UE not scheduled
Y
N
N
Y n
Codes
<
n
CodesRemain
?
Select the highest CQI (CQI
2
) which number
of codes equals the remaining number of
codes
RC
= CQI
2
CQI
1
N
RC
= 0
CQI
2
= CQI
1
Enough PDU available ?
TrBlk size manageable ?
Select the highest CQI (CQI
3
)
fulfilling both criteria
RO
= CQI
3
CQI
2
N

RO
= 0
CQI
3
= CQI
2
Y
CQI
applied
= f(CQI
3
, MAC-d PDU size)
RCqi
= CQI
applied
CQI
3
P
HS-DSCH
= P
P-CPICH
+ + (CQI
3
) +
RP
+
RC
+
RO
+
RCqi
P
HS-DSCH
= min(P
Temp
, P
HS-DSCH
)
P
Remain
= P
Temp
P
HS-DSCH
[n
Codes
, n
PDU
] = f(CQI
applied
)
UE scheduled
P
o
w
e
r

l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
C
o
d
e

l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
O
t
h
e
r
l
i
m
i
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
C
Q
I

o
p
t
i
m
i
z
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t

Figure 45: HS-DSCH power management for 1st transmission
Nortel confidential

6.4.2.6.1 POWER LIMITATION
In case there doesnt remain enough power to transmit data corresponding to the
processed CQI to a selected UE, the transport format is modified in order to reduce its
power (Ptemp refers to the available power at NodeB level and PHS-DSCH to the
needed power by the UE). The excess power, corresponding to the total needed
power minus the maximum allowed power, is computed (RP). This value, expressed
in dB, then directly indicates the number of CQI levels one should decrease in order to
remain at the same level of performances. In case the resulting value is not valid CQI
(0), the UE is not scheduled; otherwise the new configuration is the one considered
for the next checking. Note that in case the initial processed CQI is such that the
associated reference power adjustment is different from 0 (depending on UE category
and associated CQI mapping table given in [R5]), it must not be considered to
compute the CQI decrease, as described in the previous figure.

6.4.2.6.2 CODES LIMITATION
If the resulting configuration, corresponding to the derived CQI from the previous step
(CQI1), leads to a number of necessary HS-PDSCH codes higher than the remaining
one, the CQI is also reduced in order to reach the exact number of remaining codes. A
power offset equal (in dB) to the difference between the input and output CQI is then
applied (1dB per CQI rule). Note that if this power reduction leads to a power inferior
to the minimum manageable one by the H-BBU, it is then set to this minimum power.

6.4.2.6.3 OTHER LIMITATIONS
Less available PDUs than required
In case there are less Mac-d PDU available in the buffer than what would have
allowed the scheduler to transmit relatively to the derived CQI from previous steps
(CQI
2
), the configuration is then chosen to match to the lowest CQI (CQI
3
) than
enables to transmit this number of PDU (see the following figure). The power must of
course be decreased accordingly with the same rules than before.

Nortel confidential
320 16 21 Padding
Mac-d PDU
Mac-hs transport block(CQI
2
)
320 16
320 16 21 Padding
Mac-d PDU
Mac-hs transport block(CQI
3
)
320 16

Figure 46: Mac-hs transport block adaptation according to the number of Mac-d PDU to
transmit

Limited processing resource
The processing resource may be limited in the H-BBU pool configuration for instance
[R6]. All transport block sizes may then not be handled. In case the one corresponding
to the last processed CQI is not manageable, the CQI is reduced to the highest one
that fits with the available resources. The power is decreased as well accordingly.

6.4.2.6.4 CQI OPTIMIZATION ACCORDING TO MAC-D PDU SIZE
A last optimization is considered according to the resulting CQI from previous steps
(CQI
3
). Indeed, the Mac-d PDU size may not allow all CQI to be used or may lead to
an un-optimized solution. As the only supported Mac-d PDU size is 336 bits, the rules
described below must apply, summarized in the following table:

Reported CQI 1 2 3 4 6 7 9 29
(1)
30
(1)

Applied CQI 5 5 5 5 5 5 8 28
(1)
28
(1)

Power Offset (dB)
(2)
+4 +3 +2 +1 -1 -2 -1 -1
(1)
-2
(1)

(1)
: UE Cat 10 only
(2)
: if minimum or maximum power are reached
Table 11: CQI update summary

CQI < 5 (and 0)
If one assumes a Mac-d PDU size of 336 bits, the transport block size corresponding
to CQI < 5 is too short to transmit such a Mac-d PDU (transport block sizes are equal
to 137, 173, 233, 317 bits respectively for CQI 1, 2, 3 and 4). It is then envisaged to
apply the first available configuration corresponding to CQI = 5 (1 PDU transmitted).
Power adjustment is then applied when possible, keeping the same 1dB/CQI rule. If
Nortel confidential
there doesnt remain enough power to increase the transmitted one accordingly, it is
then set to the available one. It will take a bit longer to correctly decode the block but
thanks to retransmissions, it will hopefully occur.

CQI = 6, 7 and 9
In case the CQI 6 or 7 (resp. 9) are reported, the applied transport block size
corresponds to the CQI 5 (resp. 8) one. The same number of Mac-d PDUs is
transmitted but with a reduced number of padding bits, an increased coding rate or
fewer codes used; performance is then improved. The transmitted power is then
decreased accordingly (-1dB per decreased CQI), bounded by the minimum
manageable power. The following table illustrates this for the different concerned CQIs
(considering that the only supported Mac-d PDU size is 336 bits and the Mac-hs
header is of length 21 bits), whatever the UE category is.

2 1 0.34 293 650 CQI 7
2 2 0.41 99 792 CQI 8
2 2 0.48 238 931 CQI 9
1 1 0.48 104 461 CQI 6
1 1 0.39 20 377 CQI 5
Number of
HS-PDSCH
Number of
Mac-d PDU
transmitted
Coding rate
(1st
transmission)
Number of
padding bits
Transport
Block Size
2 1 0.34 293 650 CQI 7
2 2 0.41 99 792 CQI 8
2 2 0.48 238 931 CQI 9
1 1 0.48 104 461 CQI 6
1 1 0.39 20 377 CQI 5
Number of
HS-PDSCH
Number of
Mac-d PDU
transmitted
Coding rate
(1st
transmission)
Number of
padding bits
Transport
Block Size

Table 12: CQI Mapping

CQI = 29 and 30 with UE category 10
A maximum of 70 Mac-d PDU can be set in a transport block. When applying the CQI
29 and 30 for a UE category 10, it would lead to 72 and 76 PDU respectively with the
Mac-d PDU size of 336 bits. The configuration of CQI 28 (69 PDU) is then applied
when CQI 29 and 30 are reported for a UE category 10, with a decrease in applied
power of 1dB and 2dB respectively.

6.4.2.7 RETRANSMISSION
The retransmissions are scheduled first. The transport format, the number of codes
and the modulation are not changed according to the first transmission. The
redundancy version is updated [R6]. Due to some resource variation, it may not be
possible to manage the retransmission. These two limitations are described hereafter.

6.4.2.7.1 PROCESSING RESOURCE LIMITATION
In some cases, there may not remain enough processing resources to handle this
retransmission (transport block size too high). This happens in the multi-cell per HBBU
case, when the number of active cells between the first transmission and the current
Nortel confidential
retransmission increased. In that case, the corresponding HARQ process is freed and
corresponding Mac-d PDU may be discarded [R6].

6.4.2.7.2 POWER LIMITATION
The transmitted power should remain equal to the first transmission, except in some
particular cases. The following rules then apply (see the following figure):
If theres enough power to transmit the block with the same power as the first
transmission, the UE is scheduled and the same power is applied.
If there doesnt remain enough power to apply the same power than the first
transmission and if no UE has already been scheduled in this TTI, the UE is
scheduled and the applied power is then equal to the remaining power. As the
update period of the total HSDPA remaining power equals 100ms and as the
HS-SCCH power is constant, if the UE is not scheduled during that TTI, it
wont be scheduled for the whole period.
If there doesnt remain enough power to apply the same power than the first
transmission and if another UE has already been scheduled in the TTI, the UE
is not scheduled. This block should then automatically be selected first for the
next TTI and the second criteria will then apply.

Y
Block selected
(retransmission nb > 0)
1st Tx Power <
Remaining power
?
N
Block scheduled
Transmitted Pwr = 1st Tx power
Is there another
UE scheduled in
the TTI ?
Block scheduled
Transmitted Pwr = Remaining power
Block not scheduled
Y
N

Figure 47: HS-DSCH power management for retransmission

6.4.2.8 MULTI-USERS PER TTI
Once a user has been chosen to be scheduled at the next TTI, the Mac-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 (as
described in the previous section). Once a user has been scheduled, the scheduler
will try to serve another user in the same TTI with the power that remains (P
Remain
in
the following figure), if there is still a free HS-SCCH code for this TTI.
Nortel confidential

CCC
DCH margin
P
Remain
DCH
N
o
d
e
B
OCNS (opt.)
HS-DSCH
HS-SCCH

Figure 48: Remaining power for multi-users per TTI scheduling

6.4.3 HS-SCCH POWER CONTROL FEATURE
The aim of this feature is to adjust, according to the radio condition, the power
allocated to HS-SCCH in order
to save power for data or other UE,
to have a good detection probability of HS-SCCH

HS-SCCH power control is not a true power control mechanism but rather a power
mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is
derived from the averaged CQI (noted CQI
averaged
), not from CQI computed for CQI
adjustment according to BLER or power and code limitation or CQI optimization, 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 such as:
P
HS-SCCH
= P
P-CPICH
+ hsScchPcOffset(CQI
averaged
)

where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each
CQI (see the following figure).

Nortel confidential
CQI
averaged
hsScchPcOffset relativ to PCPICH Power
1 hsScchPcOffset(1)
2 hsScchPcOffset(2)
.
30 hsScchPcOffset(30)
Table 13: HS-SCCH power offset table according the averaged CQI

Disabling the power control consists in setting all hsScchPcOffset to the same value.
The following figure summarizes the HS-SCCH power control:

C
Q
I r
e
p
o
r
t
e
d
P
HS-SCCH
= P
P-CPICH
+ hsScchPcOffset(CQI
averaged
)
CQI
averaged
hsScchPcOffset(CQI
averaged
)

Figure 49: HS-SCCH power control overview

Rule: Dependency between hsScchPcOffset and measurementPowerOffset
The hsScchPcOffset parameters depend on the averaged CQI reported by the UE
and averaged by 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.

The following section gives the properties of the parameters describe previously.

Parameter dchPowerMargin Object HsdpaConf
Range & Unit Integer (%)
[0 100]
User Customer
Class 3
Granularity BTSCell
Value 20

Nortel confidential
Engineering Recommendation: dchPowerMargin versus cell load
The recommended value for dchPowerMargin is set to 20% for high cell load. At low
load, 10% could be used due to smaller power fluctuation.

Parameter hsScchPcOffset Object HsdpaConf
Range & Unit List[1..30]
[-28.0..28.0] dB
User Custumer
Class 3
Granularity BTSCell
Value 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -3.0 -3.0 -5.0 -5.0 -8.0 -8.0 -8.0 -8.0 -8.0 -
8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0

Engineering Recommendation: hsScchPcOffset value versus environment
L1 simulations have shown that required HS-SCCH power has to be equal to up to
10% of PA power in outdoor environment and up to 3% in indoor environment. This is
the reason why HS-SCCH power control is not required in indoor. hsScchPcOffset
could be set to about -5dB.

Parameter minimumPowerForHsdpa Object HsdpaCellClass
Range & Unit Integer (dB)
[0 50]
User Custumer
Class 0
Granularity FDDCell
Value Unset or 50

Engineering Recommendation: minimumPowerForHsdpa
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 : P
minHsdpa
= P
MaxCell
minimumPowerForHsdpa =
45dBm 50dB = -5dBm = 0.3mW).
2) minimumPowerForHsdpa = unset so that no minimum power is reserved for
HSDPA.

Parameter numberOfHsPdschCodes Object HsdpaCellClass
[1 15]
User Customer
Class 0
Granularity FDDCell
Value 5

Nortel confidential
Engineering Recommendation: numberOfHsPdschCodes
The number of HS-PDSCH codes reserved in the HSDPA cell
(numberOfHsPdschCodes) has to be chosen according to the number of HS-SCCH
codes (numberOfHsScchCodes) reserved and on the UE categorie. For example, if
only one HS-SCCH codes (one user per TTI) is reserved and UE Category 12 (5 HS-
PDSCH codes max), there is no need to reserved more than 5 HS-PDSCH codes. In a
trial context, we suppose 2 HS-SCCH codes (up to 2 UE per TTI) and UE category 10
(5 HS-PDSCH codes max). So 10 HS-PDSCH codes are required.

Parameter numberOfHsScchCodes Object HsdpaCellClass
[1 4]
User Customer
Class 0
Granularity FDDCell
Value 1

Engineering Recommendation: numberOfHsScchCodes
The number of HS-SCCH codes numberOfHsScchCodes defines the number of UE
that could be scheduled during a TTI. When a UE is scheduled, the HS-SCCH
channel requires up to about 10% of PA power. If n UE are scheduled during a TTI,
n*10% of PA power is needed. The cases n = 3 or 4 can lead to have not enough
power for HSDPA traffic. Moreover, the more UE are scheduled, the more HS-PDSCH
codes are needed. This is the reason why the number of HS-SCCH codes is set to 2.

Parameter measurementPowerOffset Object HsdpaUserService
Range & Unit Integer (0.5 dB)
[-12..26]
User Customer
Class 3
Granularity RNC
Value 15

Engineering Recommendation: measurementPowerOffset
measurementPowerOffset parameter defines the reference power used by the UE to
compute his CQI and the maximum power that the NodeB can allocated to one UE.
The value 7.5dB allows to allocate up to about 60% of PA power (PA = 45dBm and
Cpich power = 35dBm) for the HS-DSCH channel. A lower value favours the
scheduling of 2 UE per TTI by limiting the power per HSDPA user. For first
deployments, the probability to have 2 UE scheduled in the same TTI will be low. Then
with this value, the HSDPA user throughput is not limited by power.

Nortel confidential
6.5 TRANSPORT
6.5.1 IUB BANDWIDTH LIMITATION: WHY THIS FEATURE IS
NEEDED?
6.5.1.1 BEFORE UA4.2: IUB CONGESTION IS CONTROLLED BY AAL2
CAC.
Case of DS traffic:
the RB activity is more or less constant and predictable. Therefore EBR can
be set properly and call admission control is enough to manage Iub
congestion in an efficient way.
Case of NDS traffic:
the RB activity is not constant and very unpredictable, due to the diversity of
applications (ftp, streaming, web, email, etc.). Therefore it is very difficult to
control Iub congestion at call admission with a deterministic cost per RB.

The efficient control of Iub congestion via AAL2 CAC requires to set very conservative
EBR, which means a lot of call rejections and a small Iub usage.
Settings aggressive EBRs provides acceptable Iub capacity but potentially huge Iub
congestion: peaks of NDS traffic increase delays spent in ATM buffers. When delays
become high, the DCHFPs are received late (hence are lost and BLER increases).
When the congestion increases, ATM buffer are full. The loss of ATM cells causes
also the loss of DCHFPs. The combination of BLER increase and delay increase
causes RLC window to stall. From an end to end point of view, the increase of delays
causes TCP to slow down. As a result, the end user perception is bad (small
throughput) and the Iub usage not optimal

6.5.1.2 IN UA4.2: INTRODUCTION OF NEW HSDPA FLOW
The introduction of HSDPA increases the Iub congestion problems due to the huge
throughput (up to 3.4Mbit/s at RLC) per user. Also the credits allocated by the NodeB
(capacity allocation) are based on the RF conditions and do not take into account Iub.
If the Iub bandwidth is small compared to the RF capacity, bursts of traffic higher than
Iub bandwidth can be sent even by a single user (note: 1 UE cat 6 at 3.4Mbit/s
requires 2.3E1).
Note that AAL2 CAC does not regulate HSDPA like NDS: HSDPA are not CACed with
EBR but on a max number of HSDPA users.

Nortel confidential
6.5.1.3 GOAL OF IUB BANDWIDTH LIMITATION
It controls Iub congestion thanks to the regulation of the DL PDUs received in excess
at the RNC side. This regulation works for NDS and HSDPA.

6.5.2 FEATURE DESCRIPTION
A continuous monitoring of DS, NDS and HSDPA traffic in DL at FP level is done by
the PMC PC. The feature works with thresholds, which represent the peak of traffic
allowed on Iub:
2 Discard thresholds: Th1 for DS+NDS and Th2 for DS+NDS+HSDPA
o When DS+NDS reaches Th1, NDS FPs are deleted by PMC PC.
o When DS+NDS+HSDPA reaches Th2, HSDPA FPs are deleted by
PMC PC.
2 Back Pressure thresholds: Xoff1 for NDS and Xoff2 for HSDPA (eg.
Xoffi=95% Thi)
o When DS+NDS reaches Xoff1, PMC PC ask PMC RAB to stop
transmission of NDS FPs during Txoff1
o When DS+NDS+HSDPA reaches Xoff2, PMC PC ask PMC RAB to
stop transmission of HSDPA FPs during Txoff2

Th0=Sum(ECR_GCAC)
Th1
Xoff1
Th2
Xoff2
10ms
Eg. 43cells for 1 E1
Eg. 4*Th0=172cells
Eg. 6*Th0=258cells
Eg. 95%*Th2=245cells
Eg. 95%*Th1=163cells
time

Figure 50: discard and backpressure thresholds

DS traffic is not regulated by Iub bandwidth limitation (DS regulation is done by
AAL2 CAC)
The algorithm works with 10ms granularity: the thresholds are expressed in amount
of data (eg. ATM cells) sent in 10ms. Each 10ms, the algorithm takes into account the
transmission of ATM cells on the physical bandwidth.
Nortel confidential
The regulation is done for AAL2 traffic only. The Iub bandwidth (noted Th0 ) for
AAL2 traffic is given to the RNC through the PCR&SCR parameters defined for the
AAL2 VCCs in the RNC. Th0=sum(ECR_GCAC).
If we have typically 5% of AAL5 traffic (compared to AAL2) in DL, then SCR&PCR
need to be set so that Th0=95%*Iub_bandwidth*10ms; for 1E1 (4528cells/s),
Th0=43cells

SCR&PCR parameters of RNC UP VCCs must be properly set to have Sum(ECR
GCAC) as close as possible to 95% of the NodeB Iub bandwidth

Th2 is set as a multiple of Th0. In the system, we define a parameter qosDt(2) :
Th2=qosDt(2)*Th0
Th1 is set as a multiple of Th0-DS_traffic. In the system, we define a parameter
qosDt(1) : Th1=qosDt(1)*(Th0-DS_traffic). DS_traffic is measured within a period
of 1s. Therefore Th1 may change in time.
The regulation is not done for small FP sizes (less than 50bytes). This avoids the
regulation of control frames (eg. Flow control)
Thanks to backpressure, the discard does not happen
The Xoffi thresholds (i=1 or 2) are set thanks to the parameters qosBPt(i) :
Xoffi=qosBPt(i) * Thi
When Xoffi is reached, the RLC layers of each RB belonging to QoSi, stop the
transmission during Txoffi. Txoffi is calculated by the system from Thi:
Txoffi=ceil((Xoffi / 2)/Th0)*10ms.
During Txoff, the RLC buffer may overflow, unless the TCP window is set lower than
RLC: slowing down RLC slows down the generation of TCP Ack (by UE). TCP is
paced at the rate UE receives data.

Restriction:
The feature does not work when DS/NDS/HSDPA physical bandwidths are separated
(this is the case of multi-PCMs without IMA)

Nortel confidential
The following picture shows an example of traffic regulation (with backpressure) for
DS and HSDPA traffic (no NDS):

Th0=Sum(ECR_GCAC)
Xoff2=qosBPt(2)*qosDt(2)*Th0
qosBPt(2)=95%; qosDt(2)=6
Txoff2=30ms
DS traffic
HSDPA traffic
DS+HSDPA traffic
HSDPA
traffic is
stopped
HSDPA
traffic is
resumed
Txoff2=30ms
HSDPA
traffic is
stopped
10ms 20ms 30ms 40ms 50ms 0ms

Figure 51: example of traffic regulation with backpressure

6.5.3 CASE OF DRIFT IUR
Note: HSDPA is not supported on Iur.

When Iub congestion takes place on Serving Iub (blue mobile in the picture below),
the traffic is regulated.
When Iub congestion takes place on Drift Iub (red mobile in the picture below), the
SRNC is not informed of the congestion.
Therefore it sends the traffic on the Serving Iub and on Iur. In order to receive the
same information in each RL of the active set, the traffic on the Drift Iub is also not
regulated (otherwise it would be discarded).
The amount of not regulated Drift Iub traffic shall be small (eg. 5% of the Iub traffic)
therefore its impact on the overall Iub delays.

Nortel confidential
SRNC DRNC
Iub Iub
Iur
SRNC DRNC
xoff

Figure 52: feature behaviour on Iur

6.5.4.1 INTRODUCTION
The thresholds must be set:
to avoid loss of data on Iub. This requires to control the max number of ATM
cells sent in buffers (must be less than max buffer size). The NDS queuing
delays must be also controlled to avoid DCHFP received outside TOAWS
window (and therefore lost). This constraint does not exist for HSDPA.
to control Iub jitter contribution to end to end delays (for KPI).

We do the difference between 2 cases:
Case with ATM priority : DS has highest ATM priority compared to NDS;
idem for NDS vs HSDPA. DS is not influenced by the presence of NDS and
HSDPA. NDS is not influence by the presence of HSDPA. The following
pictures show 2 typical transport topologies where DS/NDS/HSDPA have
different ATM priorities (case with and without shaped NodeB VP)

STM1
E1 PP7K
RNC
STM1
E1 PP7K
RNC
STM1
Shaped VP
ATM
E1
PP7K
RNC
STM1
Standard VPT
STM1
Shaped VP
ATM
E1
PP7K
RNC
STM1
Standard VPT

VCCs

Figure 53: example of transport topologies "with ATM priority"

Case without ATM priority : this is the case when the RNC faces directly
an ATM backbone doing policing, with a shaped VP. However the standard
Nortel confidential
VPT is not supported by the RNC. With basic VPT, the VCCs priorities are not
taken into account.

STM1
Shaped VP
ATM
E1
RNC
Basic VPT
STM1
Shaped VP
ATM
E1
RNC
Basic VPT

Figure 54: example of transport topology "without ATM priority"

6.5.4.2 ENGINEERING RULES
6.5.4.2.1 CASE WITH ATM PRIORITY
Max ATM buffer size: Xoffi represents the max amount of data waiting in the
ATM buffers of QoSi, in the ATM switch doing the regulation at the NodeB
bandwidth (eg: the ATM switch interfacing the NodeB E1s, or the ATM switch
doing VP shaping at the NodeB Iub bandwidth). To avoid loss of ATM cells,
Xoffi must be smaller than the max ATM buffer size managing QoSi.
NDS Iub DL queuing delay: max time spent by ATM cells in buffer
Qd1=10ms*[MaxCells1/(Th0-DS traffic)]=10ms*qosBPt(1)*qosDt(1). Lets note
delta_Iub the delay between 2 adjacent NodeBs. To receive DCHFPs within
TOAWS, we must have: Qd1TOAWS-Delta_Iub, therefore:
qosBPt(1)*qosDt(1)(TOAWS-Delta_Iub)/10ms.
HSDPA Iub DL queuing delay: the max time spent by ATM cells in the HSDPA
buffer is equal to Qd2=max(0;10ms*[MaxCells2/(Th0- DS&NDS traffic)]).
HSDPA has no delay constraint coming from HS-DSCHFP. However for end
to end performance, a max Iub delay can be considered, for instance 100ms:
Qd2100ms, hence:
qosBPt(2)*qosDt(2) max(0;10*[1-DS&NDStraffic/Th0]).

6.5.4.2.2 CASE WITHOUT ATM PRIORITY
Max ATM buffer size: the max number of cells in the buffer (common for all
flows) is equal to
Xoff1+Xoff2(qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2))*Th0, and must be
smaller than MaxBufferSize of the RNC VP.

DS/NDS/HSDPA Iub DL queuing delay: without ATM priority, NDS and
HSDPA impact DS delays. Like NDS, the max delay allowed by DS comes
from the DCHFP synchronization mechanism. We must have:
qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2)(TOAWS-Delta_Iub)/10ms.
Nortel confidential

With such settings, Iub jitter would contribute up to TOAWS (eg. 50ms) to DS
end to end delay. If this additional delay is not acceptable for the end to end
DS delay budget, more constaining delays can be used. For instance, if we
want to have Iub jitter less than 20ms for DS, then:
qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2) 2.

6.5.4.3 NUMERICAL EXAMPLE
Lets give a numerical example for a NodeB with 2 IMA E1s
(Th0=2*4490*95%*10ms=85cells). DS+NDS traffic=50% of Iub bandwidth
=1.9Mbit/s=45cells each 10ms. TOAWS=50ms. Delta_Iub=15ms.

6.5.4.3.1 CASE WITH ATM PRIORITY
> In our example, the NodeB is connected to the RNC via a PP7K with MSA32 card
Delay requirements: Qd1TOAWS-Delta_Iub=35ms, Qd2100ms imposes:
qosBPt(1)*qosDt(1)3.5 and qosBPt(2)*qosDt(2)5. If we use
qosBPt(1)=qosBPt(2)=95%, then we can use: qosBPt(1)=3.5 and qosBPt(2)=5
the NodeB is connected to 1 PP7K with default MSA32 buffer sizes (UBR effective
buffer size=630cells). For Xoff2=95%*5*Th0, the max number of ATM cells in the
PP7K HSDPA VCC buffer is equal to: 95%*5*Th0=404cells. The default MSA32
buffer size is large enough to keep CLR=0. Note however that with more than 3 E1,
the default ATM buffer size of the HSDPA VCC must be increased!

6.5.4.3.2 CASE WITHOUT ATM PRIORITY
> The NodeB VP is shaped at the RNC (basic VPT)
Let use qosDt(1)=3 and qosDt(2)=5. How to set BP thresholds?
Delay requirements: Qd20ms imposes: qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2)2.
We can use: qosBPt(1)=1/3 and qosBPt(2)=1/5.
The max number of ATM cells in the IN 16pOC3 VP buffer is equal to
(qosBPt(1)*qosDt(1)+qosBPt(2)+qosDt(2))*Th0=170cells. The effective VP ATM
buffer size must be set higher than this value to guarantee CLR=0!

6.5.4.4 ATM BUFFER RECOMMENDATIONS
The complete ATM buffer recommendations can be found in the Iub TEG. following
parts provide ATM buffer recommendations for 2 typical cases:
1. case where the NodeB is connected to the RNC via a PP7K with MSA32 card
(case with ATM priority)
Nortel confidential
2. case where the RNC manages VP shaping (basic VPT; case without ATM
priority)

6.5.4.4.1 CASE WHERE THE NODEB IS CONNECTED TO THE RNC VIA A
PP7K MSA32 CARD
Relation between min buffer size, #E1s and Iub bw parameters:
HSDPA Buffer size #E1*43*qosBPt(2)*qosDt(2)
With the default recommended thresholds with ATM priority qosBPt(2)=500 and
qosDt(2)=95%, this leads to:
HSDPA Buffer size #E1*204 cells
With the default HSDPA buffer size in PP7K (MSA32):
> ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim)=SameAsCA
> ATTRIBUTE AtmIf CA UBR txQueueLimit (txql)=1792
> By default UBR is at Discard Priority 3, this means that ATM cells received beyond
35% of the txQueueLimit are discarded. The effective HSDPA buffer size is
therefore: 35%*1792= 630 cells
> When the number of E1 per NodeB is lower or equal to 630/204=3, no ATM cell
can be lost in ATM buffer.
> With more than 3 E1, there is a risk (depending on the real HSDPA traffic) to loose
ATM cells in the default HSDPA buffer size (case of MSA32)

Recommendation
Queue limit of the HSDPA VCC (case no VPT, PP7K with MSA32)
If #E1>3 (but <7): ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim)=2*1792.
If #E1 7: ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim)= #E1*583

6.5.4.4.2 CASE WHERE THE RNC MANAGE VP SHAPING
> Relation between VPC min buffer size, #E1s and Iub bw parameters:
VPC Buffer size #E1*43*(qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2))
> With the default recommended thresholds without ATM priority
qosBPt(1)=300, qosDt(1)=33%, qosBPt(2)=500, qosDt(2)=20% this leads to:
VPC Buffer size #E1*86
> With the default VPC rtVBR buffer size in IN (16pOC3):
> ATTRIBUTE AtmIf Vpc Vpd Tm txQueueLimit (txQlim)=SameAsCA
> ATTRIBUTE AtmIf CA rtVBR txQueueLimit (txql)=autoconfigure
Nortel confidential
> The effective VPC buffer size (for CC3) is: 35%*88= around 31 cells, which is too
small compared to the requirements.
> By setting the VPC rtVBR txQueueLimit to 4000, the corresponding buffer size is
adjusted to values dictated by the PCR e.g. if PCR= #E1*4490cells/s, the effective
buffer size (for CC3) is equal to 35%*#E1*270cells=#E1*94, which fits the buffer
size requirements.

Recommendation
Queue limit of the VPC (case VPT)
ATTRIBUTE AtmIf Vpc Vpd Tm txQueueLimit (txQlim)=4000

6.5.4.5 PARAMETERS
Parameter iubFlowControlActivation
(iubFcAct)
Object IubTransportFlowControl
(Fc)
Range & Unit disabled = 0,
discardOnly = 1,
discardAndBackPressure= 2
User
Class NA
Granularity RNC
Value 2

Backpressure must be activated (iubFcAct=2)

Parameter qosDiscardThreshold
qosDt(0to4)
(Fc)
Range & Unit 0..1000
Unit= %
User
Class NA
Granularity RNC
Value qosDt(0)=qosDt(4)=0
Case with ATM priority :
*qosDt(1)=350
*qosDt(2)=500
Case without ATM priority :
*qosDt(1)=300
*qosDt(2)=500

Nortel confidential
Parameter qosBackPressureThreshold
qosBPt(0to4)
(Fc)
Range & Unit 0..100
Unit= %
User
Class NA
Granularity RNC
Value qosBPt(0)=qosBPt(4)=0
Case with ATM priority :
*qosBPt(1)=qosBPt(2)=95
Case without ATM priority :
*qosBPt(1)=1/3=33%
*qosBPt(2)=1/5=20%

*Note: the recommended values are valid for the following assumptions
TOAWS=50ms, Delta_Iub=15ms
Qd2<100ms
DS&NDS traffic=50% Th0
Qd0<20ms (for the case without ATM priority ).

Nortel confidential
7 HSDPA THROUGHPUT OPTIMIZATION
HSDPA technology allows multiple users to share the HS-PDSCH resources in time
and code as shown in Figure 55 below.

Figure 55: User multiplexing in Code and Time domains

Using a shared resource, HSDPA user throughput is variable and depends on many
factors like UE capabilities, HSDPA power, RF conditions, number of active
users/sector, etc. In v4.2 UTRAN load, HSDPA provides only a best-effort throughput
(similar to GPRS algorithm but much higher rate) without any guarantees. In V5.0
UTRAN load some guaranteed user throughput could be possible by enhancing the
MAC-HS scheduler at BTS (if feature is confirmed). For the scope of this document
the HSDPA throughput in V4.2 UTRAN load is discussed. In the next sub-sections we
will address different factors impacting the HSDPA user throughput.

7.1 POWER ALLOCATION AND USER THROUGHPUT
In section 6.4, power management has been discussed. Here we just summarise its
throughput impact and highlight the key parameters.

Code multiplexing
HSDPA
2ms
Big shared pipe Big shared pipe
Code multiplexing
HSDPA
2ms
2ms
Nortel confidential
In the following figure, user throughput CDF vs. HSDPA power is shown.

Figure 56: User throughput vs. HSDPA power, UE cat 6

The higher the HSDPA power the higher the user throughout. We stress again that
DCH+CCCH have higher priority for power allocation and therefore HSDPA will take
only the remaining power on a best effort basis. In V4.2 UTRAN load, the power
sharing between R99 DCH and HSDPA can be performed dynamically. That is R99
DCH takes whatever power it requires and the remaining power is allocated to HSDPA
(i.e. HS-SCCH and HS-DSCH).

The key parameters controlling the HSDPA power are
measurementPowerOffset = 12 (i.e. 6 dB with step of 0.5 dB; 2 users/TTI) relative to
CPICH power; the default value of 6 dB corresponds to 40% PA max power allocated
HS-DSCH. In case R99 DCH + CCCH takes more than 60% PA power then less
power will be available to HSDPA users. This parameter is sent to UE via RB Setup
message which uses it in CQI selection process. If this parameter is set too low then
HSDPA may not use all the remaining power from R99 DCH reducing therefore the
user throughput. The HSDPA power will always be capped by CPICH power +
measurementPowerOffset regardless of the available PA power.
For single user per TTI it is recommended to set measurementPowerOffset to a high
value (i.e. 8 dB -> 70% PA) to maximise the user throughput in case power is
available. However for 2 users/TTI, such a high power allocation will lead to
throughput starvation for the 2nd user because 1st user will take all available power.
In that case (2 users/TTI), measurementPowerOffset = 6 dB (i.e. 40% PA) is more
Nortel confidential
appropriate providing similar power shares for both users hence comparable
throughputs. There is some cell throughput gain with 2 users/TTI (if available).
However, 2 users/TTI may occur with a low probability under a low HSDPA traffic
profile and mobile penetration scenario (i.e. initial HSDPA deployment). With 1
user/TTI and such a low HSDPA max power, a reduced user throughput will be
expected. The optimum value for measurementPowerOffset could be set by
monitoring the number of active HSDPA users.

minimumPowerForHsdpa = unset (i.e. no min power for HSDPA); this parameter
allocates some min power to HSDPA in order to provide some form of user throughput
guarantees. This power is accounted for in the R99 DCH power call admission control
(CAC) so it would impact DCH blocking probability.

dchPowerMargin = 20% relative to CCCH + DCH power; for dynamic power
allocation between R99 DCH and HSDPA, this parameter provides a DCH power
safety margin during the HSDPA power allocation interval (= 100 ms). The R99 DCH
traffic has higher priority than HSDPA for power allocation but it cannot preempt
HSDPA traffic once the power sharing has been decided by BTS for the next 100 ms
which is the HSDPA power allocation interval. If during the next 100 ms R99 DCH
increases its required power (e.g. due to HSDPA interference) there is a need for a
safety margin to allow R99 DCH to expand its power and maintain its BLER
requirement. This would enforce the R99 DCH higher priority over HSDPA. Note that
this DCH power margin is relative to the actual DCH+CCCH power measured by BTS
every 100 ms. If DCH power goes up so it does this safety margin.
If not enough DCH safety margin is provisioned then PA will enter overload state
reducing the power on all active transport channels (DCH and HSDPA). This would
lead to a drop in user throughput and higher BLER. On the other hand if too much
DCH safety margin is put aside then some PA power remains unused leading to a
reduced HSDPA user throughput. Through simulations it was shown that a value of
20% * (CCCH + DCH) could be used under heavy DCH cell load to absorb DCH
power fluctuations. This value avoids any PA overload conditions while not being too
conservative. Under low/medium DCH cell load a value of 10% * (CCCH + DCH)
could be used instead.

PA overload = 90% of total PA power; this parameter is used to record PA overload
condition. Whenever the instantaneous PA power goes over this threshold then a PA
overload counter is incremented. This parameter is used in the context of dynamic
power allocation between R99 DCH and HSDPA. In case dchPowerMargin is set too
low, PA overload may occur due DCH power expansion. This parameter would signal
that PA overload has occurred requiring therefore an increase of dchPowerMargin
value.

Nortel confidential
7.2 CQI SELECTION AT UE
UE monitors continuously (i.e. every 2 ms) CPICH received power (i.e. EcNo and
RSCP) and derives the next CQI value to be sent to BTS based on some mapping
tables CPICH EcNo (or RSCP) vs. CQI (UE implementation dependent). These
mapping tables assume a BLER = 10% on the first transmission of HS-PDSCH
(quality requirement). However the mapping tables are based on off-line simulations
and therefore they do not account for the actual RF conditions. Due to the variability of
RF environment, it is possible that BLER on HS-PDSCH is larger than target of 10%
leading to lower than expected throughput as seen in the graph below.

Figure 57: HARQ BLER vs. User RLC Throughput, UE cat 12, drive test

We see that at times the radio BLER is as high as 40% reducing therefore the user
throughput.

7.3 CQI ADJUSTMENT BASED ON BLER
To account for these CQI uncertainties, BTS has a CQI adjustment algorithm based
on BLER. Basically BTS monitors the ACK/NACKs received on HS-PDCCH channel in
Nortel confidential
UL and derives the BLER on HS-PDSCH for the first transmissions (subsequent
HARQ retransmissions not accounted). BTS increases a buffer with each new
transmission and monitors the incoming ACK/NACK corresponding to it. There is an
upper threshold of NACKs found in each buffer which would trigger a CQI reduction by
1. Also there is a lower threshold of NACKs which would trigger a CQI increase by 1.
The algorithm aims of bounding the BLER on HS-PDSCH hence optimising the
throughput. There is an obvious trade-off between the BLER estimation accuracy by
BTS and reactivity of this algorithm i.e. the larger the buffer size is the more accurate
BLER estimation is but the longer it takes. Default values are
buffer size = 100 MAC-HS PDUs
lower threshold = 0
upper threshold = 30 NACKs per buffer

With these settings the BLER on HS-PDSCH should be bounded between 0 and 30%.
It is interesting to note that the optimum BLER target (i.e. max throughput) on HS-
PDSCH is 30% as shown by the graph below.

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5
850
900
950
1000
BLER Target
T
h
r
o
u
g
h
p
u
t

(
k
b
/
s
)
Thr vs. Bler Target

Figure 58: User throughput vs. BLER on HS-PDSCH, UE cat 12

Therefore it seems that the max user throughput is achieved at a BLER target = 30%
higher than the 10% recommended by 3GPP. The reason behind this is that a higher
CQI (and raw MAC-HS throughput) is allocated to a user running with BLER=30%
than with BLER=10% and this overcompensates for the throughput reduction due to
more MAC-HS retransmissions at higher BLER.
Nortel confidential
In addition to this, BTS also implements a CQI averaging process to reduce the CQI
mismatch (due to RTD delay) between UE and BTS. There is a trade-off at hand here.
By averaging several CQIs over a time window the MAC-HS scheduler could loose
visibility of fast fade rising hence reducing the multi-user diversity gain and user
throughput. Therefore a short averaging would be required here (e.g. 5 x TTIs) to
reduce this side effect.

7.4 BTS CREDIT ALLOCATION
Periodically BTS sends capacity/credits allocations to RNC allowing it to transmit data
in DL. In case the time period between subsequent capacity allocations is too high,
BTS buffer could become empty and throughput degrades. On the other hand if this
period is too small then too much Iub signalling is generated impacting RNC and BTS
capacity. The parameter controlling this capacity allocation is
hsdschInterval = 50 ms (recommended value)

To compensate for potential throughput variations during hsdschInterval, BTS uses an
overestimating capacity factor which increases the allocated capacity over the
estimated value. This would reduce the probability of BTS buffer being empty. This
parameter is
maxRateGrowth = 8 (default value; i.e. 2 times estimated value)

Excessive buffering at BTS is not required to avoid BTS buffer overflow. Also during
primary cell change this may lead to packet discard at old BTS. The above parameter
values provide good trade-off for BTS capacity/credit allocation.

7.5 HARQ RETRANSMISSIONS
HARQ performs fast retransmissions between UE at BTS for each MAC-HS PDU
which is NACked by UE. The max delay between two subsequent retransmissions is
12 ms (i.e. 6 x TTIs). Due to the short delay and soft combing of these HARQ
retransmissions they are more efficient than RLC retransmissions (still possible).
Therefore enough HARQ retransmissions should be allowed to recover most of the
radio errors. Thus the radio errors recovery process is mainly done at HARQ level
which increases the throughput. The retransmission process of each MAC-HS PDU is
controlled by the following parameters at BTS
harqNbMaxRetransmissions = 7 (default); max number of allowed HARQ
retransmissions (incl. 1
st
transmission). The 3GPP standard allows up to 15
HARQ retransmissions per MAC-HS PDU.

If harqNbMaxRetransmissions is too small then some radio errors cannot be
recovered at HARQ layer leading to RLC retransmissions which takes longer reducing
Nortel confidential
therefore the throughput. On the other hand if harqNbMaxRetransmissions is too
large it could stall other transmissions (e.g. for other or the same users) sharing the
HSDPA pipe. Very high harqNbMaxRetransmissions would also increase the RLC
timers in both UL and DL reducing the recovery speed of radio errors in TCP ACKs
sent in UL direction.
Lab experiments show that harqNbMaxRetransmissions = 7 is sufficient to recover
from all radio errors. Note that each retransmitted MAC-HS PDU is soft combined by
UE at HARQ level providing a more efficient recovery process. However difficult radio
environments (i.e. street corner, correlated fading) may require higher number of
HARQ retransmissions (up to 15).
TimerT1 = 100 ms (default value); this is a stall avoidance timer running at
BTS; if this timer expires and the corresponding MAC-HS PDU has not been
ACKed by UE then BTS stops retransmitting this PDU. This timer is linked to
harqNbMaxRetransmissions by the following formula:
TimerT1 harqNbMaxRetransmissions * 12 ms

discardTimer = 500 ms (default 3000); if this timer expires and the
corresponding MAC-HS PDU has not been ACKed by UE then this PDU will
be discarded. The RLC layer will retransmit it so no packet loss occurs. The
discardTimer > TimerT1 to allow HARQ recovery before discarding it.
Typically RLC layer will retransmit a MAC-d PDU after timer poll prohibit = 300
ms expires. To avoid duplicated PDUs in BTS buffer it is recommended to
keep discardTimer >= 500 ms.

macHsWindowSize = 32 MAC-HS PDUs (default value); This parameter
defines the receiver and transmitter MAC-hs PDU window size.

7.6 RLC SETTINGS FOR UL DCH
The round trip delay (RTD) is shorter when HSDPA is used in DL due to shorter DL
TTI = 2 ms (compared to 20 ms or 10 ms used for R99 DCH channels). With HSDPA
typical RTD = 75 ms while with R99 DCH the RTD > 150 ms. Consequently shorter
RLC timers could be used whenever HSDPA is used in DL therefore increasing the
speed of radio error recovery (mainly in UL direction as HARQ takes care of DL).
Faster UL error recovery means higher DL throughput because TCP ACKs are
delivered in time to TCP sender avoiding TCP throughput stalling. In this section the
RLC settings for UL DCH are discussed.

Nortel confidential
The Figure below shows the HSDPA user throughput vs. status prohibit timer value.

Figure 59: User throughput vs. status prohibit timer, UE cat 6

It shows that status timer prohibit < 80 ms is required to fully achieve max HSDPA
throughput. The recommended value is
status timer prohibit = 70 ms

The next Figure shows the user throughput vs. polling timer vs. UL BLER:

RLC & BLERTarget optim, UL128
2400
2500
2600
2700
2800
2900
3000
3100
'BLER Target 2% BLER Target 1% BLER Target 0, 5%
T
h
r
o
u
g
h
p
u
t

k
b
p
PT 350; TPP 200; TSP 200 PT 150; TPP 100; TSP 100
PT 150; TPP 70; TSP 70 Fixed UL SIR (no BLER)

Figure 60: User throughput vs. polling timer vs. UL BLER

Nortel confidential
It shows that RTD = 75 ms < polling timer < 150 ms for optimum HSDPA throughput.
The recommended value is
polling timer = 150 ms

It is also apparent that a lower UL BLER target = 1% increases the HSDPA
throughput. A lower UL BLER would reduce the TCP ACK delay hence increase the
TCP throughput in DL. The UL BLER reduction could reduce somehow the coverage
due to increased UL SIR target.

The conclusion of this section points to different RLC parameters for UL DCH
depending on the DL channel i.e. PS R99 DCH or HSDPA. In case HSDPA is used in
DL the RLC parameters of the associated UL DCH could be reduced to the values
presented above to match to smaller RTD. Therefore RNC should differentiate UL
DCH radio bearer parameters depending on the pairing DL channel.

In the next Figure we show the HSDPA user throughput vs. RLC receive window size
at UE.

Figure 61: User throughput vs. receive window size at UE

The larger the receive window size is the higher the DL throughput is because the DL
reception is not stalled in case there are outstanding PDU (i.e. not ACKed yet). The
recommended value is
RLC receive window size = RLC transmit window size = 2047 MAC-d
PDUs

Nortel confidential
UE supports concatenated SDUs hence combining several TCP ACKs in one MAC
PDU in UL direction. This reduces the UL bandwidth required to carry all TCP ACKs
generate by DL HSDPA throughput. Note that if UL rate is too low then TCP ACKs are
delayed stalling therefore DL throughput on HSDPA. The UL rate required for a certain
DL rate is shown in the Table below:

UL Rate required DL rate
64 kbps < 1.7 Mbps
128 kbps < 4 Mbps
Table 14: UL rate required vs. DL rate

7.7 DL RLC SETTINGS FOR HSDPA
When HSDPA is used in DL most of the radio errors are recovered by HARQ layer
between UE and BTS. Therefore RLC retransmissions and recovery is rarely needed.
However in order to not trigger spurious DL RLC retransmissions the RLC timers
should be large enough to allow HARQ layer to fully recover all errors. A key timer
used at HARQ is TimerT1 = 100 ms (see section 7.5) which gives the max time BTS
will try to retransmit a MAC-HS PDU. Hence
DL RLC status timer prohibit > TimerT1 + RTD = 100 ms + 75 ms = 175 ms (current value 200 ms)

DL RLC polling timer > status timer prohibit + RTD = 175 ms + 75 ms = 250 ms (current value 300 ms)

So it seems that no change is needed for the current DL RLC timers.

7.8 OPTIMISED TCP SETTINGS
The TCP settings are also important to provide an optimum E2E throughput on
HSDPA. The following TCP settings need to be optimized:
Large TCP receive window size >128 Kbytes; scaling window feature may
need to be enabled to reach such a large window size.
TCP segment size = 1460 bytes to reduce TCP/IP overhead
Network Round Trip Time < 100 ms (at TCP layer) to sustain high throughput
Faster TCP slow start allowing 2 MTUs per TCP ACK; small file/page < 500
kbytes could reach quicker peak throughput

Nortel confidential
7.9 PARAMETERS SETTINGS
A summary of all the parameters discussed in this throughput optimization section is
provided below together with their recommended values.

Parameter Object User Class
Recommended
Value
Unit
measurementPowerOffset HsdpaUserService Customer 3 12 0.5 dB
minimumPowerForHsdpa HsdpaCellClass Customer 0 <unset> dB
dchPowerMargin HsdpaConf Customer 3 20 %
PA_Overload HsdpaConf Manufacturer 3 90 %
Buffer_Size HsdpaConf Manufacturer 3 100
MAC-d
PDU
Lower_Threshold HsdpaConf Manufacturer 3 0
Upper_Threshold HsdpaConf Manufacturer 3 30 NACKs
hsdschInterval HsdpaConf Customer 3 50 ms
maxRateGrowth HsdpaConf Manufacturer 3 8
harqNbmaxRetransmissions HsdpaConf Customer 3 7
timerT1 HsdpaUserService Customer 3 100 ms
discardTimer HsdpaUserService Customer 3 500 ms
macHsWindowSize HsdpaUserService Customer 3 32
MAC-d
PDUs
StatusTimer Prohibit UlDchUeConf Customer 3 150 ms
Polling timer UlDchUeConf Customer 3 70 ms
Receive Window Size DlDchUeConf Customer 3 2047
MAC-d
PDU
Transmit Window Size DlDchUeConf Customer 3 2047
MAC-d
PDU
Table 15: Parameters summary for optimized throughput

Nortel confidential
8 HSDPA CAPACITY ASPECTS
8.1 CEM CAPACITY
8.1.1 PRODUCT LIMITS
The CEM capacity for HSDPA is given by the H-BBU limitation in terms of:
Maximum number of users
Maximum number of OVSF codes
Throughput

The capacity figures are given in the following table:

UA4.2 UA5.0
Maximum number of users 20 64
Maximum number of OVSF Codes
(limitation here given by cell)
15 SF 16 (HS-PDSCH) +
4 SF 128 (HS-SCCH)
15 SF 16 (HS-PDSCH) +
4 SF 128 (HS-SCCH)
Throughput (Mbps) 10.8 (*) 10.8
Table 16: H-BBU limitations

(*) In the case of a H-BBU shared among 3 cells and if the 3 cells are active (at least 1
user active / cell), then the resource is shared fairly between the 3 cells (3.6 Mbps /
cell)

8.1.2 CAPACITY ANALYSIS
8.1.2.1 PRINCIPLES FOR HSDPA MANAGEMENT
The HSDPA support on UMTS BTS requires Nortel second generation of CEM i.e.
iCEM64 or iCEM128. Nortel CEM Alpha is not HSDPA hardware ready.
Nevertheless, HSDPA support on Nortel UMTS BTS is possible assuming already
installed CEM Alpha modules. CEM Alpha and iCEM modules can coexist within the
Node B digital shelf while providing HSDPA service with Nortel UMTS BTS.
One iBBU can manage either DCH resources (D-BBU) or HSDPA resources (H-BBU)
but not both at the same time.
Nortel confidential
The partition between H-BBU and D-BBU is done by the BTS at BTS startup using
OMC-B configuration information. Once this allocation is done, it can only change after
a BTS-iCCM reset or an iCEM plug-in or plug-out.
For HSDPA, we can have 2 configurations:
1 H-BBU shared among cells of the Node B
1 H-BBU dedicated for each cell (1 H-BBU / Cell)
A cell can not be shared among several H-BBU.
In case of 1 H-BBU shared among the 3 sectors, the sharing of the resource is done
on the base of the TTI the following way:
If only 1 cell is active for given TTI, 100% of the resources are allocated to this
cell
If 2 cells among 3 are active, then the resources are shared equally (50% for
each), no matter the number of active users in each cell,
If the 3 cells are active, the resources are shared between the 3 cells (33% for
each cell).

Cell 0
Cell 2
Cell 1
H
-
B
B
U
D
-
B
B
U
H
-
B
B
U
H
-
B
B
U
D
-
B
B
U
D
-
B
B
U
Mode 2 : 1 H-BBU / Cell
H
-
B
B
U
D
-
B
B
U
D
-
B
B
U
Mode 1 : 1 H-BBU / Node B
3
3
%

3
3
%

3
3
%

5
0
%

5
0
%

1
0
0
%

Cell 0 & Cell 2 active / Cell 1 inactive
Cell 0 , cell 1 & Cell 2 active
Cell 0 active / Cell 1 & Cell 2 inactive
CCH
CCH CCH
CCH CCH CCH
UL
DCH
UL
DCH
UL
DCH
UL
DCH
UL
DCH
R99
UL/DL
DCH
R99
UL/DL
DCH
R99
UL/DL
DCH
R99
UL/DL
DCH
R99
UL/DL
DCH
H-BBU :
only iCEM BBU
reserved at setup
in mode 1, resources are
shared dynamically between the
3 cells, depending on their
activity, at each TTI
max capacity is 20 users in
UA4.2 and 64 users in UA5.0
D-BBU :
CEM Alpha or iCEM BBU
resources for CCH reserved at
setup
resources for DCH (HSDPA
associated UL and R99 UL/DL
DCH) allocated dynamically at
connection and freed at release.
M
a
x

u
s
e
r
s

:

2
0

(
U
A

4
.
2
)

M
a
x

u
s
e
r
s

:

2
0

(
U
A

4
.
2
)

M
a
x

u
s
e
r
s

:

2
0

(
U
A

4
.
2
)

N
o
d
e

B

D
y
n
a
m
i
c

S
t
a
t
i
c

Figure 62: H-BBU resource allocation modes
Nortel confidential

Restriction: UA4.2 w33 trial
H-BBU pool across sectors is not supported.

8.1.2.2 CEM CAPACITY ANALYSIS
Lets take an example: if we consider the R99 PS 128 kbps UL / 384 kbps DL. The
consumption of this radio bearer at the CEM level is shown on the following figure (the
common channels are not considered here):

Figure 63: iCEM consumption for a PS RB DL 128 kbps / UL 384 kbps (R99 Case)

We can have up to 16 simultaneous users in this case.

Lets now suppose that we will map the service using this radio bearer on HSDPA. For
the same hardware configuration, we have the following situation:

BBU 0
UL DL
12.5% 12.5%
1 iCEM 128 (~ 2 iCEM 64)
UL DL
BBU 1
UL consumption : 12.5% / BBU
DL consumption : 12.5 % / BBU
Up to 8 simultaneous users / BBU, 16 for 2 BBU
UL TRB
+ SRB
DL TRB
+ SRB
Nortel confidential

Figure 64: iCEM consumption for a PS RB HSDPA / UL 128 kbps (HSDPA Case)

In this case, we can only have up to 8 simultaneous users, which is half the number of
the R99 case.
When using HSDPA, the initial resources (2 BBU) are split in 2. Then, the HSDPA
radio bearer is consuming resources on both D-BBU (for the UL DCH and for the DL
SRB) and H-BBU (DL HS-DSCH). Finally, even if the DL consumption on the D-BBU
is lower than in R99 case, the UL consumption remains the same while the resources
have been divided by 2. This explains the loss of capacity found in the case study
whose results are shown on Figure 65:

Figure 65 : Comparison between the CEM R99 Capacity and the CEM HSDPA Capacity for same
input traffic and same CEM configuration (same hardware)

Lets now consider the capacity with penetration factor growing from 0 to 100%. The
results are shown on Figure 66:
BBU 0 (D-BBU)
UL DL
12.5%
1 iCEM 128 (~ 2 iCEM 64)
UL DL
BBU 1 (H-BBU)
UL consumption : 12.5% / BBU
DL consumption : 5% on H-BBU + 1.5% on D-BBU
Up to 8 simultaneous users for the 2 BBU
5%
DL SRB
1.5%
UL TRB
+ SRB
DL TRB
Nortel confidential

CEM Capacity
0
100
200
300
400
500
600
700
800
900
1000
0% 20% 40% 60% 80% 100%
HSDPA Penetration factor
#

s
u
b
s

/

N
o
d
e

B
2 BBU
3 BBU
4 BBU
H-BBU Limitation

Figure 66: CEM Capacity vs. HSDPA Penetration

For the 3 configurations, the first part of the curves indicates the loss of capacity due
to CEM resource partitioning (principle is explained above)
Then the capacity decreases slowly, when the penetration factor increases, due to the
UL 32 kbps / DL 32 kbps traffic which is mapped on UL 64 kbps when using HSDPA.
The blocking comes from D-BBU mainly.
For the 4 BBU configuration, the capacity decreases when the penetration factor goes
over 70% : this is due to the fact that above this value, the CEM blocking is mainly due
to H-BBU and no more to D-BBU.

Nortel confidential
CEM Capacity
0
100
200
300
400
500
600
700
800
900
1000
0% 20% 40% 60% 80% 100%
#

s
u
b
s

/

N
o
d
e

B
0.0%
1.0%
2.0%
3.0%
4.0%
5.0%
6.0%
7.0%
8.0%
9.0%
10.0%
B
l
o
c
k
i
n
g
# subs
R99 Blocking (VT)
HSDPA Blocking

Figure 67: CEM Admission Blocking type (R99 or HSDPA) versus HSDPA Penetration Factor

To simplify the results and withdraw the effect of the UL 32 kbps / DL 32 kbps RB, we
gathered all the input I/B traffic on a single bearer (for R99) which is DL 64 kbps/UL
64kbps. The configurations studied in this case are now 4, 5 and 6 BBUs. The results
are shown on the following graph:

CEM Capacity
400
500
600
700
800
900
1000
1100
1200
1300
1400
0% 20% 40% 60% 80% 100%
#

s
u
b
s

/

N
o
d
e

B
6 BBU
4 BBU
5 BBU
R99 capa for
3 D-BBU
R99 capa for
4 D-BBU
R99 capa for
5 D-BBU
Switch from
1 H-BBU to 3 H-BBU
H-BBU Limitation
CEM Partitioning
D-BBU Limitation

Figure 68: CEM Capacity figures for different configurations depending on the HSDPA
penetration factor (UL 64 kbps)
Nortel confidential

Compared to the previous results, we can observe:
There is no more loss of capacity on the second part of the curves (limitation
due to the UL 64 kbps)
A new area appears, for the configuration with 6 BBU. The explanation is the
following: 2 configurations are possible:
o (a) 1 H-BBU / Node B and 5 D-BBU
o (b) 1 H-BBU / Cell (i.e. 3 H-BBU) and 3 D-BBU

The first configuration (determined by CEM & Codes dimensioning tool) is (a) because
low HSDPA traffic needs only 1 H-BBU / Node B.
When the HSDPA penetration factor increases, the H-BBU load increases with the
number of simultaneous connected users, while the D-BBU load stays approximately
the same. The H-BBU blocking appears and when reaching the target of 10%, it
becomes the dimensioning one compared to D-BBU blocking (HSDPA penetration
factor is 45%).
If the penetration factor goes on growing, the capacity decreases, and at the same
time, the D-BBU load decreases until spare D-BBU unused resources are better to be
used as H-BBU to stop the loss of capacity. At this point (HSDPA penetration factor is
70%), the configuration (b) becomes better in terms of capacity than configuration (a):
the CEM & Codes dimensioning tool determines this configuration as the best one.
Then, increasing the HSDPA penetration factor above this value will have no impact
on capacity which is now due to D-BBU (UL 64 kbps). Then, the capacity curve is the
same as for the configuration 4 BBU (1 H-BBU + 3 D-BBU) because the number of D-
BBU is the same and the blocking is due to D-BBU.

Nortel confidential
The blocking is shown on the following graph :

Admission blocking (6 BBU)
0%
2%
4%
6%
8%
10%
0% 20% 40% 60% 80% 100%
B
l
o
c
k
i
n
g
Video Telephony
Voice
I/B (max)
I/B (average)
HSDPA

Figure 69: Admission blocking by service vs HSDPA penetration factor

As the last part of the exercise, lets now consider an UL 128 kbps radio bearer to
associate with the downlink HSDPA radio bearer and look at the system capacity for
4, 5 and 6 BBU configurations:

Nortel confidential
CEM Capacity
300
500
700
900
1100
1300
0% 20% 40% 60% 80% 100%
#

s
u
b
s

/

N
o
d
e

B
4 BBU
5 BBU
6 BBU
R99 capa for
3 D-BBU
R99 capa for
4 D-BBU
R99 capa for
5 D-BBU
H-BBU Limitation

Figure 70: CEM Capacity figures for different configurations depending on the HSDPA
penetration factor (UL 128 kbps)

The use of the UL 128 kbps radio bearer associated to DL HSDPA implies a regular
decrease of the capacity when HSDPA penetration factor increase.
But the steps remain the same:
Fall down of the capacity due to CEM resources partitioning
First, mainly D-BBU blocking
Then, mainly H-BBU blocking

The fourth step observed on Figure 68 does not appear in this case: whatever the
HSDPA penetration factor and up to 6 BBU configuration, only 1 H-BBU / Node B
needed.

Conclusions:
Introduction of HSDPA needs a CEM re-dimensioning to keep equivalent
capacity number, due to CEM BBU partitioning
For low HSDPA penetration factor values and in most of the cases, only 1 H-
BBU is needed to afford the capacity conditioned by the D-BBUs
depending on the input call profile, if the number of BBU is quite large (let say
at least 6 BBU), it can happen .that, for high HSDPA penetration factor values,
the 1 H-BBU / Cell configuration (i.e. a total of 3 H-BBU) is better than the 1
H-BBU / Node B configuration, in terms of capacity, for the same global
number of BBUs.
Nortel confidential

Nortel confidential
9 PRODUCT RECOMMENDATIONS
Features listed below have impacts on Nortel UTRAN products with regards to
HSDPA feature:

Feature Id Feature description
27930 HSDPA Service
27932 HSDPA Step 1
27940 H-BBU Pool Across Sectors
27941 Node-B Module Operation For HSDPA

9.1 HSDPA COMPATIBILITY WITH UTRAN NETWORK
ELEMENTS
9.1.1 RNC
HSDPA is supported on both RNC 1000 and RNC 1500 platforms for all UA04.2
supported Market Models.

9.1.2 BTS
HSDPA is supported on following BTS Platforms with associated timeframe:
From UA04.2 wk39 Trial Load (2100 Mhz ONLY):
UMTS BTS 1020 (previously known as Mono)
UMTS BTS 6020 (previously known as Street)
UMTS BTS 12010-1 (previously known as Indoor 600/700 Version 1 which is
MD)
UMTS BTS 12010-2 (previously known as Indoor Version 2)
UMTS BTS 12020-1 (previously known as Outdoor Version 1 which is MD)
UMTS BTS 12020-2 (previously known as Outdoor Version 2)
UMTS BTS 18010 (previously known as GSM/UMTS Combo Indoor)
UMTS BTS 18020 (previously known as GSM/UMTS Combo Outdoor)
From UA04.2 CuR Load:
All Cabinets mentioned above both into both 1900 Mhz and 2100 Mhz
configurations
UMTS BTS 6010 (previously known as Compact)

Nortel confidential
Note: HSDPA support on BTS 1120 (previously knows as Micro) is covered as part of
the Micro Project itself and currently under consolidation.

Furthermore the following configurations are supported, if applicable, whatever the
cabinet type may be and with associated timeframe:
From UA04.2 wk39 Trial Load:
STSR-1 and STSR-2 configurations
OTOR-1 and OTOR-2 configurations
From UA04.2 CuR Load:
BTBR-1 and BTBR-2 configurations
STSR1+1 and associated depopulations (OTOR 1+1, BTBR 1+1)
NOT supported for HSDPA into UA04.2 Loads:
OTSR configurations
OTBR configurations

Warning: As further mentioned, in case of configurations with 2 carriers, HSDPA is
ONLY supported on ONE of the two carriers for both wk39 and CuR Loads.

9.2 HSDPA COMPATIBILITY WITH MODULES
9.2.1 RNC
There are no additional requirements on RNC modules in relation with HSPDA. As
such UA04.2 and products related requirements apply.

9.2.2 BTS
9.2.2.1 HSDPA READY MODULES
CEM module from Digital Rack is the one impacted by HSDPA from a system
perspective, as such all other modules from both Digital (CCM, TRM and GPSAM),
Radio Racks (DDM, MCPA) and Antenna System are compatible with HSDPA.

Within the CEM portfolio, compatibility matrix is the following with regards to HSDPA:
CEM alpha = NOT compatible (*)
i Module iCEM 64 and 128 = Compatible
I Module version 2 iCEM-2 64 and iCEM-2 128 = Compatible
Nortel confidential

(*) Warning: This does not imply that a CEM alpha cannot be plugged into a BTS with
HSDPA activated, it can indeed not manage HSDPA resources but can still process
dedicated and/or common channels, please refer to next sections.

9.2.2.2 BTS MODULES MIXITY
As long as minimal configuration requirements described into the section below are
met, there are no specific constraints in terms of mixity in relation with HSDPA. In
other words mixity allowed is the one offered so far within Nortel BTS Cabinets.

9.2.2.3 BTS MINIMAL CONFIGURATION FOR HSDPA
In order to activate HSDPA on a BTS configuration, CEM MINIMAL requirements are:
One CEM alpha, or one iCEM (-1 / -2) 64, or one half of iCEM (-1 / -2) 128 for
NON HSDPA resources.
AND
One iCEM (-1 / -2) 64 or half or iCEM (-1 / -2) 128 for HSDPA.

9.3 HSDPA SYSTEM IMPACT
Reminder: HSDPA is an OPTIONAL feature.

9.3.1 RNC FUNCTIONS
9.3.1.1 RNC RESSOURCES MANAGEMENT
Please refer to Transport section for associated Iub Congestion Management and
CAC AAL2 related mechanisms description.

9.3.2 BTS FUNCTIONS
BTS functions mainly impacted from a system perspective by HSDPA have been
located into the BBU unit of CEM boards.

9.3.2.1 CEM AND BBU ROLES
Depending on CEM board, as illustrated below, one or two BBUs are available.
Furthermore a system constraint is that one BBU can ONLY process EITHER
Nortel confidential
common and/or dedicated services OR HSDPA services. As a matter of facts, BTS
BBUs have been specialized into:
D-BBU = DCH-BBU: BBU managing dedicated services (but can also cary
common channels)
H-BBU = HSDPA-BBU: BBU managing HSDPA services

This leads to the possible BBU distribution below:

CEM type BBU1 BBU2 Comments
CEM alpha
D-BBU D-BBU Only D-BBU for
CEM
D-BBU
iCEM (-1 or -2) 64
H-BBU
D-BBU D-BBU
D-BBU H-BBU
H-BBU D-BBU
iCEM (-1 or -2) 128
H-BBU H-BBU
Each BBU (iBBU) of
iCEM can be allocated
independently with D-
BBU or H-BBU.
Up to 1 HBBU for
iCEM64
Up to 2 HBBU for
iCEM128

9.3.2.2 BTS HSDPA SYSTEM LIMITS
HSDPA is supported by Nortel BTS within the following system limits:
ONLY one single carrier with HSDPA
A given HSDPA Cell is managed by one single H-BBU and cannot be split
between several H-BBU
From one to three cells per H-BBU
Up to three H-BBU maximum per BTS
Up to three HSDPA Cells per BTS

Warning:
Only three times one HSDPA Cells per H-BBU AND three HSDPA Cells for one H-
BBU configuration have been extensively tested within Nortel R&D Labs.

9.3.2.3 BBU ALLOCATION
Both D-BBU and H-BBU allocation is performed within a BTS shelf:
At CCM Startup
Nortel confidential
At CEM Startup if no allocation was already achieved for this CEM at
CCM Startup. This covers cases where the CEM was not enabled (HW
failure, Board locked) or not inserted (later CEM plug-in) at CCM Startup
time.

Warning: The only context where allocation information for a CEM is cleared is when
the CEM is plugged out. In order to get the allocation mechanism to be re-made is to
reset the CCM, into this case all allocations are cleared and allocation algorithm is re-
run.

D-BBU and H-BBU roles allocation algorithm relies on hsdpaResourceActivation
and hsdpaResourceId parameters of BTSEquipment/BTSCell objects and is
described here-after:

Criterias for a successful allocation are:
At least one D-BBU
Number of H-BBU to be allocated = Number of different
hsdpaResourceId among BTS Cells with their
hsdpaResourceActivation set to TRUE and within BTS HSDPA
System limits.

Nortel confidential
The Allocation Algorithm for CCM Startup is the following:
For each CEM Alpha
o Allocate BBU with D-BBU
List all BBU within iCEM per increasing slot number = {iBBU list}
For each unallocated BBU into {BBU list}
o IF
(number of D-BBU already allocated = 0)
o THEN
Allocate BBU with D-BBU
o ELSE
IF
( Number of allocated H-BBU < Number of H-BBU to be allocated )
THEN
Allocate BBU with H-BBU
ELSE
Allocate BBU with D-BBU

In case of CEMs enabled after CCM Startup, then algorithm above applies with {BBU
list} made of BBUs from those CEMs.

9.3.2.4 MCPA POWER
Nortel BTS offers one MCPA per Sector (carrying one or two carriers). As a matter of
fact Power made available by a given PA is shared by Cells associated to this sector.
So HSDPA resources will also require and use some of this available power, which
reduces power available for R99.

9.3.2.5 BTS RELIABILITY
If the last D-BBU is lost, there is no re-allocation of one H-BBU into D-BBU.
In case of CEM failures, cells allocated to H-BBU are not re-distributed among other
CEMs, which bring to a full service outage over those cells. Also no D-BBU if more
than one is preempted to be re-allocated as H-BBU.

Other BTS redundancy mechanisms remain unchanged.

Nortel confidential
9.4 HSDPA AND UTRAN INTERFACES
9.4.1 RADIO INTERFACE
Nortel RNC supports both 2100 Mhz OR (exclusive) 1900 Mhz associated carriers.

Restriction: Wk39 Trial load:
2100 Mhz ONLY is available.

Rule: Max Number of HSDPA Carriers:
In case of configurations with two carriers, HSDPA is ONLY supported on ONE of the
two carriers for both wk39 and CuR loads.

9.4.2 IUB
9.4.2.1 PHYSICAL INTERFACES IMPACTS
HSDPA is supported over all available options exception made of Multi-PCM
configuration.

9.4.2.2 ATM LAYER
From ATM connectivity point of view HSDPA impact is ad follows on a plane basis:
Control Plane: In case all BBUs (one or two depending on CEM type and if
HSDPA is applicable) of a given CEM are H-BBU, there is no need to
configure one CCP for this CEM since CCP is only used for dedicated NBAP
procedures.
Warning: In case one CCP has been configured for a CEM with H-BBU only, it
will appear as DISABLED at the W-NMS level. Reason for this is that all UEs have a
DCH part, even if they are configured in HSDPA and the H-BBU only manages the
HSDPA channels (HS-PDSCH, HS-SCCH and HS-DPCCH) while the DCH part is
managed by a D-BBU. So the context of the communication is located on a CEM
handling the DCH part of the UE (the HSDPA may be de-configured for instance while
the DCH always remain). As a matter of fact all NBAP messages intended to that UE
are then sent to the VCC of the CEM managing the DCH, so no VCC needs to be
allocated to a CEM that is only configured with H-BBUs.
User Plane: HSDPA requires at least per BTS one dedicated ATM AAL2 VCC
for User Plane associated to Qos 2.

Nortel confidential
Please refer to [R9] for further details.

9.4.3 IU-CS
Not Applicable to HSDPA context.

9.4.4 IU-PS
HSDPA does not imply new requirements from a Product and Architecture
perspectives.

9.4.5 IU-R
HSDPA is not supported over IuR interfaces.

9.4.6 IU-PC
Not Applicable to HSDPA context.

Nortel confidential
10 ABBREVIATIONS AND DEFINITIONS
10.1 ABBREVIATIONS
AICH Acquisition Indicator Channel
AM Acknowledged Mode
AS Access Stratum
BCC Base Color Code
BCH Broadcast Channel
BSIC Base Station Identity Code
CAC Call Admission Control
CBR Constant Bit Rate
CC Call Control
CEM Channel Element Module
CN Core Network
CoS Class Of service
CP Passport: Control Processor
CPCS Common Part Convergence Sublayer
CPICH Common Pilot CHannel
CS Circuit Switched
DDM Dual Duplexer Module
DL Downlink
DPCCH Dedicated Physical Control Channel
DPDCH Dedicated Physical Data Channel
DTAP Direct Transfer Application Part
FP 3GPP: Frame Protocol
FP Passport: Function Processor
GMM GPRS Mobility Management
HCS Hierarchical Cell Structure
HSDPA High Speed Data Packet Access
HHO Hard HandOver
IE Information Element
IMEI International Mobile Equipment Identification
IMSI International Mobile Subscriber Identification
RNC-AN RNC Access Node
RNC-CN RNC Control Node
RNC-IN RNC Interface Node
ITP Initial Transmit Power
Nortel confidential
ITU International Telecommunication Union
LA Location Area
LAC Location Area Code
MBG Minimum Bandwidth Guaranteed
MCPA Multi-Carrier Power Amplifier (same as PA)
MIB Management Information Base
MIB Master Information Block
MM Mobility Management
MMI Man-Machine Interface
MO Mobile Originated
MT Mobile Terminated
NAS Non Access Stratum
NCC Network Color Code
NE Network Element
NSAP Network Service Access Point
OCAN Offline Configuration of Access Network, Nortels tool for UTRAN
configuration
OVSF Orthogonal Variable Spreading Factor
PA Power Amplifier (same as MCPA)
P-CCPCH Primary Common Control Physical Channel
PCI Peripheral Component Interconnect bus
PCPCH Physical Common Packet Channel
P-CPICH Primary Common Pilot Channel
PICH Paging Indicator Channel
PLMN Public Land Mobile Network
PRACH Physical Random Access Channel
PS Packet Switched
P-SCH Primary Synchronization Channel
QoS Quality of Service
RA Registration Area
RAB Radio Access Bearer
RACH Random Access Channel
RANAP Radio Access Network Application Part
RAT Radio Access Technology
RB Radio Bearer
RL Radio Link
RLC Radio Link Control
RMS Root Mean Square
RNC Radio Network Controller
Nortel confidential
RNS One RNC + Its associated Node-B
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSSI Received Signal Strength Indicator
SAR Segmentation and Re-assembly
SCCP Signalling Connection Control Part
S-CCPCH Secondary Common Control Physical Channel
S-CPICH Secondary Common Pilot Channel
SCR Sustainable Cell Rate
SDH Synchronous Digital Hierarchy
SF Spreading Factor
SFN System Frame Number
SHO Soft HandOff
SIB System Information Block
SM Session Management
SRB Signalling Radio Bearer
SS7 Signalling System 7
S-SCH Secondary Synchronization Channel
SSCS Service Specific Convergence Sublayer
SSD Source Statistic Description
TFC Transport Format Combination
TFCS Transport Format Combination Set
TM Transparent Mode
TRB Traffic Radio Bearer
TrCH Transport CHannel
TRM TRansceiver Module
TS Time Slot
TTI Transmission Time Interval
UBR Unspecified Bit Rate
UE User Equipment
UL Uplink
UM Unacknowledged Mode
URA UTRAN Registration Area
UTRAN Universal Terrestrial Radio Access Network
VBR Variable Bit Rate
VBR-nrt Variable Bit Rate - non real time
VBR-rt Variable Bit Rate - real time
VC Virtual Channel
Nortel confidential
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VP Virtual Path
VPI Virtual Path Identifier
WG Wireless Gateway

10.2 DEFINITIONS

Nortel confidential

Z END OF DOCUMENT Y

UMT IRC APP 016664 - HSDPA Engineering Guide v01.06 EXT Nortel

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UMT IRC APP 016664 - HSDPA Engineering Guide v01.06 EXT Nortel

Hochgeladen von

Copyright:

Verfügbare Formate

HSDPA Engineering Guide

Document number: UMT/IRC/APP/016664

2005 Nortel Networks, All Rights Reserved.

Das könnte Ihnen auch gefallen