Vdocuments - MX Hspa-Features

Course Content
Radio Resource Management Overview

Parameter Configuration
Common Channels & Power Control
Load Control
Admission Control
Packet Scheduling
Handover Control
Resource Manager
HSDPA RRM & parameters
HSUPA RRM & parameters
HSPA+ features & parameters
1 © Nokia Siemens Networks RN3167BEN30GLA1

Classification : Interne
HSPA+ features & parameters:

Module Objectives
At the end of the module you will be able to:
• List the mayor data rate boosters of HSDPA & HSUPA and explain their
principles
• Explain how different HSPA+ features improve the spectrum efficiency
• Describe the prerequisites and main parameters needed for the described
HSPA+ features

HSPA+ RRM: Contents
• HSDPA Improvements:
– 64QAM (RAN1643)
– MIMO (RAN1642)
– MIMO 42Mbps with 64QAM (RAN1912)
– Dual-Cell HSDPA (RAN1906)
– DC-HSDPA with MIMO 84Mbps & 64QAM (RAN1907)
– Flexible RLC in DL (RAN1638)
– Dual Band HSDPA (RAN2179)
• HSUPA Improvements:
– Frequency Domain Equalizer (RAN1702)
– HSUPA Interference Cancellation Receiver (RAN1308)
– HSUPA 16QAM (RAN1645)
– Flexible RLC in UL (RAN1910)
– HSUPA Downlink Physical Channel Power Control (RAN971)
– Dynamic HSUPA BLER (RAN2302)
HSPA+ RRM: Contents
• Other features:
– Continuous Packet Connectivity CPC (RAN1644)
– CS Voice over HSPA (RAN1689)
– Fast Dormancy (RAN2136)
– Fast Dormancy Profiling (RAN2451)
– Multi-Band Load Balancing MBLB (RAN2172)
– High Speed Cell_FACH (DL) (RAN1637)
– High Speed Cell_FACH (RAN1913)

Multicarrier HSPA Evolution in Release 9/10 & beyond

• 3GPP Rel. 7 UE can receive and transmit only on 1 frequency even if
the operator has total 3-4 frequencies
Uplink Downlink
1 x 5 MHz 1 x 5 MHz
• Rel. 8 brought DC-HSDPA, Rel. 9 defined DC-HSUPA

• Further Releases will bring multicarrier HSDPA & HSUPA which
allows UE to take full benefit of the operator’s spectrum
Uplink Downlink
42 x 5 MHz 48 x 5 MHz

HSPA Data Rate Evolution

• HSPA has data rate evolution beyond 100 Mbps
RU20 / RU30 / RU40 / RU50 3GPP R10 3GPP R11
3GPP R9
3GPP R8
3GPP R7 336 Mbps
3GPP R6 168 Mbps
3GPP R5 84 Mbps
42 Mbps 8-carrier
21-28 Mbps 4-carrier HSDPA
14 Mbps DC-HSDPA HSDPA
14 Mbps DC-HSDPA, + 64QAM + 64QAM
64QAM or + 64QAM
+ 64QAM + MIMO + MIMO (2x2)
16QAM + MIMO
MIMO (2x2) or
+ MIMO (2x2)
(2x2) 4-carrier
(2x2) HSDPA
+ 64QAM
+ MIMO (4x4)
70 Mbps
23 Mbps
23 Mbps
11 Mbps DC-HSUPA
11 Mbps DC-HSUPA
5.8 Mbps DC-HSUPA + 64QAM
0.4 Mbps 16QAM + 16QAM
16QAM + 16QAM + MIMO (2x2)

HSPA+ RRM: Contents
– 64QAM (RAN1643)
– MIMO
– MIMO 42Mbps with 64QAM
– Dual-Cell HSDPA
– DC-HSDPA with MIMO 84Mbps & 64QAM
– Flexible RLC in DL
– Dual Band HSDPA
• HSUPA Improvements
• Other features

64QAM: RAN1643 Modulation Coding rate 15 codes

HSDPA64QAMAllowed
WCEL; 0 (Disabled), 1 (Enabled) 1/4 1.8 Mbps
64QAM QPSK 2/4 3.6 Mbps
6 bits/symbol 3/4 5.4 Mbps
2/4 7.2 Mbps
16QAM 3/4 10.8 Mbps
4/4 14.4 Mbps
3/4 16.2 Mbps
64QAM 5/6 18.0 Mbps
4/4 21.6 Mbps
• optional Feature;
RNC License Key required (ON-OFF) HS- max. HS- min. *
MIMO Peak
DSCH DSCH Inter-TTI Modulation
• HSDPA peak rate up to 21.1 Mbps category Codes interval
support Rate
• UE categories 13,14,17 & 18 supported 13 15 1 QPSK/16QAM/ No 17.4 Mbps
• optional feature for UE 64QAM
14 15 1 QPSK/16QAM/ No 21.1 Mbps
Prerequisites: 64QAM
• Flexible RLC, HSDPA 14.4 Mbps, 17 15 1 QPSK/16QAM/ 64QAM or 17.4 or 23.4
Dynamic Resource Allocation, HSUPA Dual-Stream MIMO Mbps
18 15 1 QPSK/16QAM/ 64QAM or 21.1 or 28
Dual-Stream MIMO Mbps

64QAM: Channel Quality Requirements

• good channel conditions required to apply / take benefit of 64QAM  CQI  26 !
– 64QAM requires 6 dB higher SNR than 16QAM
– average CQI typically 20 in the commercial networks
2/4 3/4 5/6 4/4

1/6 1/4 2/4 3/4 2/4 3/4
CQI > 15 CQI > 25

QPSK 16QAM 64QAM
some gain from only available with
no gain from 64QAM 64QAM 64QAM
0 Mbps 10 Mbps 14 Mbps 21 Mbps

64QAM: CQI TB Size # codes Modulation  CQI TB Size # codes Modulation 

CQI Tables 1 137 1 QPSK 0 1 136 1 QPSK 0
2 173 1 QPSK 0 2 176 1 QPSK 0
3 233 1 QPSK 0 3 232 1 QPSK 0
4 317 1 QPSK 0 4 320 1 QPSK 0
5 377 1 QPSK 0 5 376 1 QPSK 0

TS 25.214: 6 461 1 QPSK 0 6 464 1 QPSK 0
Annex Table 7d 7 650 2 QPSK 0 7 648 2 QPSK 0
Cat 10 UE 8 792 2 QPSK 0 8 792 2 QPSK 0
9 931 2 QPSK 0 9 928 2 QPSK 0
10 1262 3 QPSK 0 10 1264 3 QPSK 0
11 1483 3 QPSK 0 11 1488 3 QPSK 0
12 1742 3 QPSK 0 12 1744 3 QPSK 0
13 2279 4 QPSK 0 13 2288 4 QPSK 0
14 2583 4 QPSK 0 14 2592 4 QPSK 0

TS 25.214: 15 3319 5 QPSK 0 15 3328 5 QPSK 0
Annex Table 7f 16 3565 5 16-QAM 0 16 3576 5 16-QAM 0
Cat 13 UE 17 4189 5 16-QAM 0 17 4200 5 16-QAM 0
18 4664 5 16-QAM 0 18 4672 5 16-QAM 0
19 5287 5 16-QAM 0 19 5296 5 16-QAM 0
20 5887 5 16-QAM 0 20 5896 5 16-QAM 0
21 6554 5 16-QAM 0 21 6568 5 16-QAM 0
22 7168 5 16-QAM 0 22 7184 5 16-QAM 0
23 9719 7 16-QAM 0 23 9736 7 16-QAM 0
24 11418 8 16-QAM 0 24 11432 8 16-QAM 0
25 14411 10 16-QAM 0 25 14424 10 16-QAM 0
26 17237 12 16-QAM 0 26 15776 10 64-QAM 0

TS 25.214 Annex Table 7g 64-QAM
27 21754 15 16-QAM 0 27 21768 12 0
Cat 14 UE: 28 23370 15 16-QAM 0 28 26504 13 64-QAM 0
CQI29: 14 Codes; 32257 bit 29 24222 15 16-QAM 0 29 32264 14 64-QAM 0
CQI30: 15 Codes; 38582 bit 30 25558 15 16-QAM 0 30 32264 14 64-QAM -2

64QAM: Link Simulations

• UE peak data rate increased to 21.1 Mbps (L1 - theoretical)
• Max application level throughput ~17.9 Mbps (ideal channel)
• 64QAM is applicable for better radio conditions

64QAM
Parameter – Bitrate control
MaxBitRateNRTMACDFlow
can be used to restrict the maximum bit rate of NRT MAC-d flow.
The bit rate used in the reservation of the resources for the MAC-d
flow is the minimum value of 1) max. bit rate based on UE capability,
2) max. bit rate of the RAB, 3) activated HSDPA bit rate features and
4) the value of this parameter.
This parameter does not limit the maximum instantaneous bit rate on
air interface.
The value of the parameter is compared to the user bitrate of the NRT
MAC-d flow excluding MAC-hs header, RLC header and padding.
*65535  parameter does not
WCELRNHSPA; 128..2112083968; 128; 65535* restrict the maximum bit rate,
but the maximum bit rate is
restricted by other limits.
Features enabled Suggested Parameter Setting
Range & Default value
No license for HSDPA 15 codes 3456 kbps changed with RU30 to:
0128...83968 ; 128; 0 =
10 / 15 codes 6784 kbps same meaning as 65535 in
10 / 15 codes & 10Mbps per user 9600 kbps RU20 (HSDPA peak rate not
limited by the RNC)
10 / 15 codes & 14Mbps per user 13440 kbps
10 / 15 codes & 64 QAM 21120 kbps
MIMO 27904 kbps
DC HSDPA 42112 kbps
DC HSDPA & MIMO 84224 kbps

HSPA+ RRM: Contents
– 64QAM
– MIMO (RAN1642)
– Dual-Cell HSDPA
– Dual Band HSDPA
• Other features

MIMO Principle (1/2)

Signal from jth Tx antenna
Sj
T1 R1
MIMO
Input T2 R2 Output
Processor
• •
• •
• •
MxN
Tm MIMO Rn
system
• MIMO: Multiple-Input Multiple Output
• M transmit antennas, N receive antennas form MxN MIMO system
• huge data stream (input) distributed toward m spatial distributed antennas; m parallel bit streams
(Input 1..m)
• Spatial Multiplexing generate parallel “virtual data pipes”
• using Multipath effects instead of mitigating them

MIMO Principle (2/2)

Signal from jth Tx antenna Signal at ith Rx antenna
Sj h1,1
Yi
T1 hn,1 h2,1 h1,m
R1
h1,2 MIMO
h2,2 P
r
Input hn,2 o
T2 h2,m R2
c
Output
e
• • s
• • s
• hn,m • o
r
Tm MxN Rn
MIMO
h1,1 h1,2  h1,m • Receiver learns Channel Matrix H
h2,1 h2,2  h2,m • inverted Matrix H-1 used for recalculation
H= 





of original input data streams 1..m
  
m
hn,1 hn,2  hn,m
yi   hi , j  s j  ni ni: Noise at receiver
j 1
MIMO: RAN1642
MIMOEnabled
• RU20 (3GPP Rel. 7) introduces 2x2 MIMO with 2-Tx/2-Rx WCEL; 0 (Disabled), 1 (Enabled)
– Double Transmit on BTS side (D-TxAA), 2 receive antennas on UE side
– System can operate in dual stream (2x2 MIMO) or single stream (Tx diversity) mode
• MIMO 2x2 enables 28 Mbps peak data rate in HSDPA WBTS: 2 Tx-
– 28 Mbps peak rate in combination with 16QAM antennas
– 64QAM: no simultaneous support of 64QAM & MIMO (not yet)
– Dual-Cell HSDPA: not possible to enable MIMO & DC-HSDPA in a cell in parallel
• Benefits: MIMO increases single user peak data rate,
overall cell capacity, average cell throughput & coverage
• UE categories for MIMO support: Cat. 15, 16, 17 & 18
HS- max. HS- min. *
MIMO Peak
DSCH DSCH Inter-TTI Modulation
UE: 2 Rx- category Codes interval
support Rate
antennas 15 15 1 QPSK/16QAM Yes 23.4 Mbps
16 15 1 QPSK/16QAM Yes 28 Mbps
17 15 1 QPSK/16QAM/ 64QAM or 17.4 or 23.4
• optional Feature (ASW) Dual-Stream MIMO Mbps
• RNC License Key required (ON-OFF) 18 15 1 QPSK/16QAM/ 64QAM or 21.1 or 28
Dual-Stream MIMO Mbps
Prerequisites:
• double Power Amplifier units & antenna lines per cell;
• must be enabled: HSDPAEnabled, HSUPAEnabled, HSDPA14MbpsPerUser, HSDPADynamicResourceAllocation,
FDPCHEnabled, HSDPAMobility, FDPCHEnabled, FRLCEnabled; must not be enabled: DCellHSDPAEnabled

MIMO
S-CPICH Power & Code allocation
• MIMO enabled cell: S-CPICH is broadcast for DL channel estimation in UE S-CPICH tx power =
– S-CPICH transmission power is controlled with existing parameter PtxPrimaryCPICH
• UE must be able to estimate each of the 2 signals separately -10..50; 0.1; 33 dBm
– P-CPICH is broadcast along with data stream 1

– S-CPICH (new with RU20) is broadcast along with data stream 2
– SF 256 spreading code must be allocated in DL to support S-CPICH transmission
SF 16,0
SF 32
S-CCPCH
SF 64
E-RGCH
HS-SCCH E-HICH
SF 128
SF 256
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
depending on
FACH / PCH
configuration

MIMO 2x2 / 28 Mbps RNC checks following conditions, before

MIMO allocation to a UE:
Allocation of MIMO for a UE (if at least one of the conditions is false during
Start active MIMO allocation, MIMO will be deactivated)
no
MIMOEnabled
MIMO Parameter Enabled WCEL; 0 (Disabled),
yes 1 (Enabled)
optional
no
feature for BTS is MIMO capable
UE yes
no
UE is MIMO capable
yes
no
RAB configuration for UE allows MIMO
yes
no
Streaming RAB state changes to inactive
yes
FDPCHEnabled no
WCEL; 0 (Disabled), SRB* can be mapped to HSPA (F-DPCH)
1 (Enabled)
yes
FRLCEnabled no
WCEL; 0 (Disabled),
MAC-ehs can be allocated (Flexible RLC)
1 (Enabled) yes
yes – allocate MIMO no – do not allocate MIMO

* i.e. SRB must be mapped to HSPA

MIMO: Layering & Mobility
Layering: MIMO
• RU20 MIMO supports following site configurations: Layer
– 1/1/1
– 2/2/2
– 3/3/3
• more than one MIMO layer not possible in RU20.
Mobility
• Once allocated to a UE, MIMO will be kept also during
mobility procedures
– Service Cell Change can be used to allocate / de-allocated
MIMO for a UE
– If target cell is not supporting MIMO or MIMO can not be
enabled, RNC deactivates MIMO for the UE
• Compressed Mode is started for a UE having MIMO
allocated
• MIMO Mobility over Iur interface NOT supported in RU20

MIMO 2x2 / 28 Mbps

Performance
mean cell throughput vs. UE throughput at the Cell Edge,
various scheduling schemes middle of the cell & cell center
Single-stream Dual-stream Single-stream Dual-stream

CLM: Closed Loop Mode; Single-Stream with Rx- & Tx-Diversity

HSPA+ RRM: Contents
– 64QAM
– MIMO
– MIMO 42Mbps with 64QAM (RAN1912)
– Dual-Cell HSDPA
– Dual Band HSDPA
• Other features

RAN1912: MIMO 42Mbps with 64QAM

64QAM
6 bits/symbol 2x2 MIMO & 64QAM WBTS: 2 Tx-
antennas
 up to 42 Mbps
2x2 MIMO
MIMOWith64QAMUsage
Basics: WCEL; 0 (Disabled), 1 (Enabled)
• optional Feature; RNC License Key required (ON-OFF)
• RU20 enables either 2x2 MIMO (RAN1642) or 64QAM (RAN1643)
• RU30 enables simultaneous 2x2 MIMO and 64QAM operation (RAN1912)
• Peak Rates: up to 2 x 21 Mbps = 42 Mbps
• 3GPP Rel. 8 HS-
DSCH
max. HS-
DSCH
MIMO
Modulation suppor
Peak
• new UE Categories: 19, 20 category Codes t
Rate
Requirements 19 15 QPSK/16QA Yes 35.3 Mbps

M/ 64QAM
• Flexible RLC, F-DPCH, MIMO 28 Mbps, HSDPA 64QAM 20 15 QPSK/16QA Yes 42.2 Mbps
M/ 64QAM

Allocating MIMO 42Mbps with 64QAM
• 64QAM is allocated with MIMO whenever possible

• Switching can occur when conditions change, i.e. when it becomes possible
to support MIMO with 64QAM, or when it is no longer possible to support
MIMO with 64QAM
• The conditions required to support MIMO 42Mbps with 64QAM are:
– it must be possible to support MIMO
– it must be possible to support HSDPA 64QAM
– The WCEL MIMOWith64QAMUsage parameter must be set to enabled
– The BTS and UE must support simultaneous use of MIMO and 64QAM
• If MIMO with 64QAM is not possible but MIMO without 64QAM, or 64QAM
without MIMO is possible, MIMO shall be preferred

HSPA+ RRM: Contents
– 64QAM
– MIMO
– Dual-Cell HSDPA (RAN1906)
– Dual Band HSDPA
• Other features

DC-HSDPA Principles (1/2)

• prior to 3GPP Release 8, HSDPA channel bandwidths limited to 5 MHz
• Dual-Cell HSDPA: 3GPP Rel. 8 allows 2 adjacent channels to be combined
 effective HSDPA channel bandwidth of 10 MHz (RU20 feature)
• 3GPP Rel. 8: Dual Cell HSDPA can be combined with 64QAM but not with MIMO
(Release 9 allows combination with both, 64QAM & MIMO)
 42 Mbps HSDPA peak rate DCellHSDPAEnabled
WCEL; 0 (Disabled), 1 (Enabled)
Basic Approach Dual Cell Approach

2 UE, each using 5 MHz RF Channel 1 UE, using 2 × 5 MHz RF Channels
Peak Connection Throughput = 28 Mbps Peak Connection Throughput = 42 Mbps
5 MHz 5 MHz 10 MHz
F1 F2 F1 F2
MIMO (28 Mbps), or DC-HSDPA & 64QAM

64QAM (21 Mbps) (42 Mbps)

DC-HSDPA Principles (2/2)
• DC-HSDPA provides greater flexibility to the HSDPA Scheduler, i.e. the scheduler can
allocated resources in the frequency domain as well as in the code and time domains
Gains of DC-HSDPA:
1) Improved Load Balancing
2) Frequency Selectivity
3) Reduction of Latency
4) Higher Peak Data Rates
5) Improved Cell Edge
“User Experience”
Channel conditions good Channel conditions good Channel conditions good

on both RF carriers on RF carrier 1 on RF carrier 2
F1 F2 F1 F2 F1 F2
UE1 UE1 UEx UEx UE1

DC-HSDPA: UE Cat & Requirements
• RU20 (3GPP Rel. 8) introduces DC-HSDPA (RAN1906)

• DC-HSDPA & 64QAM enable DL 42 Mbps peak rates
• UE categories for DC-HSDPA support: Cat. 21, 22, 23 & 24
• optional feature; requires long term
RNC license for specific number of cells HS- max. HS-
MIMO Peak
• following features must be enabled: DSCH DSCH Modulation
support Rate
category Codes
• HSDPA (HSDPAEnabled)
23.4
• HSUPA (HSUPAEnabled)* 21 15 QPSK/16QAM No
Mbps
• HSDPA 15 codes (HS-PDSCHcodeset) 22 15 QPSK/16QAM No 28 Mbps
• HSDPA 14 Mbps per User (HSDPA14MbpsPerUser) QPSK/16QAM/ 35.3
• HSDPA Serving Cell Change (HSDPAMobility) 23 15
64QAM
No
Mbps
• Fractional DPCH (FDPCHEnabled) QPSK/16QAM/ 42.2
24 15 No
• DL Flexible RLC (FRLCEnabled) 64QAM Mbps
• Shared Scheduler for Baseband Efficiency
• HSPAQoSEnabled must be configured with the same value
in both DC-HSDPA cells
• MaxBitRateNRTMACDFlow (def. 65535 = not restricted)
should be configured to allow the peak throughput
• RU20: MIMO + DC-HSPDA must not be enabled for all cells belonging to the Node B
(MIMOEnabled); ;
• RU340: MIMO + DC-HSDPA possible DC-HSDPA + MIMO possible in RU340
27 © Nokia Siemens Networks * at

RN3167BEN30GLA1 least 1 of the RF carriers
DC-HSDPA: Requirements
SectorID = 1 SectorID = 3
• DC HSDPA cells require:
• adjacent RF carriers  UARFCN SectorID = 2
• same sector  SectorID RF Carrier 2
• same Tcell value
SectorID = 1 SectorID = 3
SectorID = 2
RF Carrier 1
DC-HSDPA: Tcell Configuration (I)

• 2+2+2 Node B with DC-HSDPA Tcell = 0 Tcell = 6
requires:
Tcell = 3
• each cell belonging to the same sector
RF Carrier 2
must have the same Tcell value
• Tcell values belonging to different sectors
must belong to different Tcell groups
Tcell = 0 Tcell = 6
• Configuration requires 3 HSDPA Efficient Tcell = 3
Baseband Schedulers
RF Carrier 1
• RF carriers 1 & 2 must be adjacent
Tcell: defines start of SCH, CPICH, Primary CCPCH & DL Scrambling Code(s) in a cell relative to BFN

DC-HSDPA: Tcell Configuration (II) Tcell Groups

• Group 1: Tcell values 0, 1, 2
• 3+3+3 Node B with DC-HSDPA • Group 2: Tcell values 3, 4, 5
requires: • Group 3: Tcell values 6, 7, 8
• each DC-HSDPA cell belonging to • Group 4: Tcell value 9
same sector to have same Tcell value
• DC-HSDPA Tcell values belonging to
different sectors must belong to Tcell = 0 Tcell = 1
different Tcell groups
• Configuration requires 4 HSDPA Tcell = 2
Efficient Baseband Schedulers RF Carrier 3
• RF carriers 1 & 2 must be adjacent

Tcell = 3 Tcell = 6
• Cells belonging to RF carriers 1 & 2
must be within the same LCG Tcell = 9
• Cells belonging to RF carrier 3 must be RF Carrier 2
within a further LCG
Tcell = 3 Tcell = 6
Tcell = 9
RF Carrier 1
LCG: Local Cell Group

DC-HSDPA: HSDPA Scheduler
• A single HSDPA shared scheduler for baseband efficiency is required per DC-HSDPA cell pair
• 3 HSDPA shared schedulers are required for a 2+2+2 Node B configuration with DC-HSDPA
• Each scheduler is able to serve both HSDPA & DC-HSDPA UE on both RF carriers
• Link Adaptation is completed in parallel for each RF carrier
HSDPA UE on f2
Shared Scheduler DC-HSDPA UE with

per DC-HSDPA cell serving cell on f2
pair
HSDPA UE on f1
DC-HSDPA UE with
serving cell on f1

HSPA+ RRM: Contents
– 64QAM
– MIMO
– Dual-Cell HSDPA
– DC-HSDPA with MIMO 84Mbps & 64QAM (RAN1907)
– Dual Band HSDPA
• Other features

DC-HSDPA with MIMO & 64QAM

64QAM DC-HSDPA, WBTS: 2 Tx-
6 bits/symbol antennas
2x2 MIMO & 64QAM
 up to 84 Mbps
2x2 MIMO
Basics:
• enables simultaneously: DC HSDPA, MIMO & 64QAM
• MIMO uses Single Stream or Double Stream transmission
• DC-HSDPA uses 2 cells (in 1 sector) at same BTS;
same frequency band & adjacent carriers to a UE
• 64QAM  6 bits/symbol Dual-Cell (DC-)
HSDPA
Benefits:
• higher Peak Rate: up to 2 x 2 x 21 Mbps = 84 Mbps
• better Coverage due to DC-HSDPA & MIMO
• More robust transmission due to MIMO & DC HSDPA usage

w/o
42 Mbps 42 Mbps 56 Mbps 64QAM
MIMO + 64QAM DB-DC-HSDPA + 64QAM DC-HSDPA + MIMO

RASN1912 / 3GPP Rel. 87 RASN2179 / 3GPP Rel. 9 3GPP Rel. 9
max. Peak Rate 84 Mbps both supported

in RU340 by RAN1907
DC-HSDPA + MIMO + 64QAM
3GPP Rel. 9
Feature Enabling:
• DC-HSDPA with MIMO 84 Mbps: optional feature; DCellAndMIMOUsage
but: w/o own license; required licenses: WCEL; 0 (DC-HSDPA & MIMO disabled),
 RAN1642 MIMO (28 Mbps) 1 (DC-HSDPA & MIMO w/o 64QAM enabled),
 RAN1643 HSDPA 64QAM 2 (DC-HSDPA & MIMO with 64QAM enabled)
 RAN1906 DC-HSDPA 42 Mbps
• DC-HSDPA + MIMO can be enabled w/o 64QAM MIMOWith64QAMUsage
 Peak Rate up to 56 Mbps WCEL; 0 (Disabled), 1 (Enabled)
• to enable Peak Rate = 84 Mbps 
DCellAndMIMOUsage must be enabled &
MIMOWith64QAMUsage = 2
DC-HSDPA: UE Categories & Requirements

MaxBitRateNRTMACDFlow*
Requirements can be used to restrict max. bit rate of NRT
MAC-d flow
• RAN1642 MIMO 28 Mbps UE Categories WCELRNHSPA; 0128... 83968 ; 128; 0
• RAN1638 Flexible RLC (3GPP Rel. 9; TS 25.306) value 0 / 65535 (before): HSDPA peak rate
• RAN1906 DC HSDPA not limited by the RNC
• RAN1643 64QAM HS- max. HS- DC-

MIMO Peak
• RAN1912 MIMO 42Mbps + 64QAM DSCH DSCH Modulation
support
HSDPA
Rate
category Codes support
QPSK/16QAM 35.3
19 15 Yes No
64QAM with MIMO / 64QAM Mbps
(w/o DC-HSDPA) QPSK/16QAM 42.2
20 15 Yes No
/ 64QAM Mbps
23.4
DC-HSDPA 21 15 QPSK/16QAM No Yes
Mbps
(w/o MIMO, 64QAM) 22 15 QPSK/16QAM No Yes 28 Mbps
QPSK/16QAM 35.3
23 15 No Yes
/ 64QAM Mbps
DC-HSDPA with 64QAM
QPSK/16QAM 42.2
(w/o MIMO) 24 15
/ 64QAM
No Yes
Mbps
46.7
25 15 QPSK/16QAM Yes Yes
DC-HSDPA with MIMO Mbps
(w/o 64QAM) 26 15 QPSK/16QAM Yes Yes 56 Mbps
27 15
QPSK/16QAM
Yes Yes 70.6
/ 64QAM Mbps
28 15
QPSK/16QAM
Yes Yes 84.4
/ 64QAM Mbps
* parameter value range has been updated

DC-HSDPA: Mobility
Hard
Handover HHO
• DC-HSDPA with MIMO can be maintained, activated or de-activated during mobility

• Availability of DC-HSDPA with MIMO checked in target cell when SCC or HHO initiated
• If DC-HSDPA with MIMO cannot be used in the target cell mobility proceeds without it:
– DC-HSDPA or MIMO is used if possible, according to the parameter DCellVsMIMOPreference
• If HSUPA IFHO can be used DC-HSDPA & MIMO is not be deactivated but is maintained
during Inter-Frequency measurements
• If HSUPA IFHO cannot be used, E-DCH to DCH switch is completed before inter-frequency
measurements; DC-HSDPA with MIMO is deactivated at the same time
• DC-HSDPA with MIMO is not supported across the Iur
• S-RNC does not configure DC-HSDPA with MIMO if there are radio links over the Iur in the
active set
defines whether RNC primarily activates DC-HSDPA
DCellVsMIMOPreference
or MIMO for a UE, which supports both DC-HSDPA &
WCELRNHSPA; DC-HSDPA preferred (0), MIMO in case simultaneous usage of DC-HSDPA &
MIMO preferred (1) MIMO is not possible.
SCC: Serving Cell Change

DC-HSDPA: Gain in Throughput & Coverage

Gain of DC-HSDPA &
MIMO compared to
SC-HSDPA:
• Throughput: + 220%
• Coverage: + 57%
Furthermore:
More Throughput
Some 29% more

subscriber can be served
more Coverage
SC-HSDPA: Single Carrier HSDPA

DC-HSDPA: Dual-Carrier HSDPA
TP: Throughput

HSPA+ RRM: Contents
– 64QAM
– MIMO
– Dual-Cell HSDPA
– Flexible RLC in DL (RAN1638)
– Dual Band HSDPA
• Other features

Flexible RLC (DL): RAN1638

• included in RU20 basic software package – no license needed
• HW Prerequisites: Flexi Rel2, UltraSite with EUBB FRLCEnabled
• Flexible RLC used, if: RNCRNFC; 0 (Disabled), 1 (Enabled)
– Cell Flexible RLC capable & enabled
– UE supports Flexible RLC
– AM RLC is used
– HS-DSCH & E-DCH selected as transport channels
– Dynamic Resource Allocation enabled
prior Rel. 7 Rel. 7 Flexible RLC
PDCP IP packet (max. 1500 byte) IP packet (max. 1500 byte)
segmentation no segmentation
RLC ••• IP packet (max. 1500 byte)

RLC PDU: 336 bit or 656 bit adapts RLC-PDU size to
16 bit RLC Header  4.8% or 2.4% Overhead actual size of higher layer data unit
concatenation segmentation
MAC-hs TBS (depending on scheduling)
AM: Acknowledged Mode

DL Flexible RLC
Background
• Prior to Rel. 7: RLC layer segments high layer data units (IP packets) in RLC PDU
sizes of 336 and 656
– 336 is 320 net bit plus 16 bit RLC OH
– 656 is 640 net bit plus 16 bit RLC OH
• On MAC-d layer did not increase Overhead
– Data was passed directly to MAC-hs layer (MAC-d)
• Several MAC-d PDUs were concatenated to form a MAC-hs data block
• BTS selects proper MAC-hs data block size based on
– available user date in BTS buffer and
– radio conditions for that UE
• With DL Flexible RLC the RNC adapts the RLC-PDU size to the actual size of the
higher layer data unit (IP)
– maximum size of 1500 Byte is supported (IP packet length in Ethernet)

DL Flexible RLC
Advantages
• Major improvements with DL Flexible RLC
– less processing in RNC & UE
– higher end user application throughput
– lower latency for packet access
– Significantly lower Overhead
– Much less padding bits
– Lower risk for RLC stalling because of too small transmission windows
50%
45%
Rel. 6 with RLC PDU Size of 336 bits
40%
Rel. 6 with RLC PDU Size of 656 bits
Overhead
35%
Rel. 7 Flexible RLC
30%
25%
20%
15%
10%
5%
0%
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
IP packet size [byte]

HSPA+ RRM: Contents
– 64QAM
– MIMO
– MIMO 42Mbps
– Dual-Cell HSDPA
– DC-HSDPA with MIMO 84Mbps
– Dual Band HSDPA (RAN2179)
• Other features

DBandHSDPAEnabled
Dual Band HSDPA: RAN2179 WCEL; (0) Disabled, (1) Enabled
• Included in RU40 application software package – license required
• HW prerequisites: Flexi rel.2
• Can be used if: DC-HSDPA and HSPA Peak Rate Upgrade features are active
Brief Description:
• This feature introduces for a single UE the possibility of using simultaneously two carriers
in DL that are situated on two different WCDMA frequency bands
• Feature enables achieving 42 Mbps peak rate for user in DL (assuming 64QAM and 15
codes usage on both frequencies)
• Comparing to single carrier case gives possibility to increase cell throughput
• Feature is much similar to DC-HSDPA in function
• Feature restricts single carrier usage in UL (DB or DC-HSUPA is not allowed)
Motivations and Benefits:
• High Throughputs – This feature enables throughputs as high as 42 Mbps.
• Better Coverage – Dual Band allows using two different frequency bands. For cases
where high coverage is needed, lower Band of the two can be used to enhance coverage.
• Configurations flexibility – This feature with carriers from 2 different frequency bands
allows more flexibility in spectrum assignments
Dual Band HSDPA: With and Without the Feature

Without DB-HSDPA feature there is no With DB-HSDPA feature there is
possibility to establish data connection possibility to establish data connection
with to different band at the same time with to different band at the same time
*Presented frequency bands are only exemplary detailed configurations options presented later on
DC-HSDPA DL transmission options DB-HSDPA DL transmission options
2 x 5 MHz 2 x 5 MHz 2 x 5 MHz
f1 f2 f1 f2 f1 f2
U2100 U900
U2100 U900
SC-HSDPA DL transmission options
5 MHz 5 MHz
f1 f1
U2100 U900

HSPA+ RRM: Contents
• HSDPA Improvements
• Other features

HSPA+ RRM: Contents
– HSUPA Interference Cancellation Receiver
– HSUPA 16QAM
– Flexible RLC in UL
– HSUPA Downlink Physical Channel Power Control
– Dynamic HSUPA BLER
• Other features

Frequency Domain Equalizer fdeEnabled

BTSSCW; 0 (Disabledfalse), 1 (Enabledtrue)
Basics:
• before RU30: Node B receiver based on RAKE receiver technology
RAKE unable to receive high data rates even in total absence of other cell
interference  short spreading codes (SF2) vulnerable to ISI
• RU30 introduces:
 RAN1702: Frequency Domain Equalizer FDE
 RAN1308: HSUPA Interference Cancellation IC
• FDE can remove ISI, leaving other users of same cell & surrounding
cells to be main limiting factors for UL data rates
• Interference from other users of the own cell can reduced by HSUPA IC
• FDE is prerequisite for UL 16QAM (RU430)
• removes ISI
UL RAKE UL FDE
• enables higher
Noise Noise
PrxMaxTargetBTS PrxMaxTargetBTS throughput
Power Power
• prerequisite for
HSUPA 16QAM
4 Mbps 8 Mbps
FDE: Frequency Domain Equalizer

IC: Interference Cancellation
ISI: Inter-Symbol-Interference

Frequency Domain Equalizer

Challenges for UMTS receiver
• Multipath delays --> handled by time delay synchronization

• Phases of the multipath component --> handled by carrier phase synchronization
• Amplitudes of the multipath components --> handled by amplitude tracking


Only Rrake receiver was used in RU20 & earlier releases
RAKE delivers adequate performance for data rates below 2 Mbps; its main tasks are:
 Identify the time delay positions at which significant energy arrives and allocate
correlation receivers, i.e. Rake fingers, to those peaks.
 Within each correlation receiver, track the fast-changing phase and amplitude
values originating from the fast fading process and utilize them.
 Combine the demodulated and phase-adjusted symbols across all active fingers
and present them to the decoder for further processing.


FDE = linear equalizer + fast convolution
• FDE (LMMSE) provides optimal linear estimate of transmitted signal accounting for both:
• Channel impact (fading)
• Interference + noise
• FDE is a combination of linear equalization & fast convolution.
• Convolution is relatively demanding in terms of computation
• Convolution can be replaced by multiplication if completed in the frequency domain  FFT
• FDE reduces the effects of ISI arising from user’s own signal due to multipath propagation.
• FDE applied to users with granted 2xSF2 + 2xSF4 (QPSK or 16-QAM)  up to 11.5 Mbps.
signal FFT
Despreading
IFFT and bits
detection
Channel MMSE filter
pilot coefficient
estimation
calculation Time domain
FDE scheme
Frequency domain
(I)FFT: (Inverse) Fast Fourier Transformation

ISI: Inter-Symbol-Interference
LMMSE: Linear Minimum-Mean-Square-Error

Frequency Domain Equalizer ETFCIBoost

E-DPCCH boosted mode RNC; 0..127; 1; 1032
 FDE sensitive to channel estimation => E-DPCCH boosted mode used for channel & SIR estimation
 E-DPCCH boosted mode  E-DPCCH bound to E-DPDCH power (not to DPCCH, as usual)
 Starting from ETFCIBoost E-TFCI Default value, UE selects 16QAM & start to use boosted mode.
 Boosted mode introduction to increase E-DPCCH power proportionally to high data rates. High data rates are
source of high self interferences  boosted E-DPCCH useful for E-DPDCH channel estimation & demodulation.
 not mandatory for UE to support E-DPCCH power boosting (requires Rel. 7 or newer UE)
 UE indicates support of E-DPCCH power boosting within RRC Connection Setup Complete message
 RNC signals E-DPCCH power boosting parameters to UE boosted mode
non-boosted mode
non-boosted m ode boosted mode
E-DPDCH
E-DPDCH
E-DPDCH
E-DPDCH E-DPCCH
E-DPCCH E-DPCCH
E-DPCCH
DPCCH DPCCH DPCCH DPCCH
low E-TFC high E-TFC low E-TFC high E-TFC

HSPA+ RRM: Contents
– Frequency Domain Equalizer
– HSUPA 16QAM
• Other features

HSUPA Interference Cancellation Receiver
Basics:
• reduces UL Intra-cell interference with non-linear Interference Cancellation IC
method called Parallel Interference Cancellation (PIC)
• RAN1308: Basic PIC decreases interference from HSUPA 2 ms TTI users to
other UL channels
• improved coverage e.g. for AMR calls existing in parallel with peak rate users
• RAN2250: Enhanced PIC (RU450) decreases interference from HSUPA 2 ms
TTI users on each other
• larger peak HSUPA data rates (also 16-QAM)
• Improving FDE & HSUPA 16QAM (RU430)
• Feature activated by BTS license key
IC users: Non-IC users:

• Users mapped on E-DCH with 2ms TTI for • Rest of 2ms TTI E-DCH users, all 10ms TTI
which Interference Cancellation IC is applied – E-DCH users and all DCH users
usually users with the highest power • Interference is reduced for non-IC users only
• IC users do not get any direct benefit from IC
(indirectly from lower Tx power of other users)

Basic Parallel Interference Cancellation (PIC) method

• UL signal received with Rake Receiver or FDE technique
• Turbo decoding  obtain 2 ms TTI E-DCH signals
• Decoded data used to reconstruct original 2 ms TTI signals (interference for other users)
Reconstruction includes turbo encoding spreading & modulation.
• Cancel interference from 2 ms TTI user: Reconstructed signals are summed up & subtracted
from the original antenna signal  non-IC users’ signal (residual signal)
• Non-IC users signals are demodulated on the residual signal, benefiting from a lower
interference level  improving cell coverage & capacity
UL signal from
antenna
“Non-IC users”
10ms HSUPA,
Re-modulate
De-modulate
2ms HSUPA 2ms HSUPA  De-modulate
other
DCH
user data
“IC users” 2ms HSUPA

2ms HSUPA Interference cancelled
user data  Non-IC users signal
(Residual signal)
FDE: Frequency Domain Equalizer
PIC: Parallel Interference Cancellation

Enhanced PIC method

Basic PIC: IC users do not benefit directly from reduced interference
 their signals are demodulated in parallel on the original antenna signal
Enhanced PIC (RAN2250):
• demodulate IC users’ signals again after residual signal reconstruction for these signals
(to gain from IC of Basic PIC).
• Residual Stream Reconstruction RSR: individual residual signal generated for each
2 ms TTI user, adding its reconstructed signal to common residual signal.
 interference from 2 ms TTI users canceled from other 2 ms TTI users’ signals “Non-IC users”
2ms HSUPA
10ms HSUPA,
UL signal from interference De-mod
cancelled all others
DCH
antenna
user data
Re-modulate Common
De-modulate
2ms HSUPA 2ms HSUPA  Residual signal
“IC users”
De-mod 2ms HSUPA

RSR
First stage 2ms HS user data
detected
FDE: Frequency Domain Equalizer IC users data 2nd stage detected
PIC: Parallel Interference Cancellation Individual IC users data
RSR: Residual Stream Reconstruction Residual signal

Effect of IC / HSUPA scheduling with Basic PIC

• Part of received total wideband power is cancelled
– RTWP = PNoise + PR99 + P10ms + P2ms
– Residual RTWP = PNoise + PR99 + P10ms + (1-β) * P2ms
• Achievable interference reduction factor β highly dependent on:
– Quality of signal that should be cancelled (2ms TTI UEs) BTS uses 2 scheduling targets
– Data rate of UE to be cancelled for HSUPA:
– Radio channel of the UE: Multi-path profile, UE Velocity RTWP < PrxMaxOrigTargetBTS
Residual RTWP < PrxMaxTargetBTS
RTWP Residual PrxMaxOrigTargetBTS
RTWP WCEL; 0..30; 0.1; 8 dB
PrxMaxOrigTargetBTS
PrxMaxTargetBTS
HSUPA 2 ms WCEL; 0..30; 0.1; 6 dB
PrxMaxTargetBTS
HSUPA 2 ms
HSUPA HSUPA
10 ms 10 ms
R99 users R99 users
Noise Noise
RTWP: Received Total Wide Band Power

PIC pool & state

PIC pool:
•set of cells within 1 BTS that are candidates for
interference cancellation (IC)
f1 f2 •supports up to 6 cells
•3 cells may perform IC simultaneously
•PIC pool configuration done by operator via BTS
configuration
•max. 4 PIC pools per BTS
AssignedPICPool
•AssignedPICPool indicates WCEL; 0 (off); 1; 2; 3; 4
which PIC pool the cell belongs to
•Basic PIC functionality takes fixed number of CE per
PIC pool: 48 CE
•PIC-state of a cell in a PIC-Pool can be changed by
AdminPICState*.
• “PIC-deactivated”, “PIC-activated”, “PIC-automatic”
• PIC state change of cells with “PIC-Automatic” is
cells in PIC pool controlled by BTS
• Cells with highest traffic shall be selected for IC
cells performing Interference • Cell are deselected for IC if traffic has decreased
Cancellation
AdminPICState
WCEL; 0 (ActivateEnabled), 1
*There may be restriction in WBTS for changing the PICState. If (DeactivateDisabled), 2 (Automatic)
the change is not possible, then the PICState remains.
PIC: Parallel Interference Cancellation

HSPA+ RRM: Contents
• Other features

HSUPA 16QAM: RAN1645 HSUPA16QAMAllowed

WCEL; Disabled (0), Enabled (1)
Brief description of 16 QAM in UL
 Dual 4PAM modulation is used (4PAM→ 4 symbols & 2 bits per symbol) Dual 4PAM
 Variable SF≥2 for Bit Rate (BR) adjustment 4 bits/symbol
 Multicode operation is needed to maximise Bit Rate after max SF is used
(max 4 data codes in parallel when no DPDCH configured)
 With W=3.84Mcps→Symbol rate=2·W/SF2+ 2·W/SF4=5760 ksps
 BRmax=2·5760ksps=11520 kbps
Motivation & benefits

 Using higher order modulation, more symbols can be transmitted, therefore
more bits can be assigned to each symbol, while the duration of symbol is
kept. This results in higher Bit Rate.
 Most beneficial with low intra-cell interferences.
 Interference cancellation techniques are welcome to lower the intra-cell
noise.
Drawbacks
 Reduction of the Euclidean distance between adjacent symbols. This
results in stricter requirement in SNR per symbol to achieve the same BER
 RoT limit requirement rises high, as the own signal interferences from
16QAM are high. Therefore this feature is dedicated for micro, pico cells.

HSUPA 16QAM: Spreading for E-DPDCH/E-DPCCH

Multi-code transmission
Eb Es Ec
SF=2
Cch,2,1 bed,1
4 symbols
E-DPDCH1 4PAM modulation
+ mapper
SF=4
Cch,4,1 bed,3

4 symbols E-DPDCH3 4PAM modulation
I
mapper
Cch,256,1 bec
E-DPCCH BPSK modulation
mapper = 16
I+jQ
symbols
S =16QAM
SF=2
Cch,2,1 bed,2
4 symbols E-DPDCH2 4PAM modulation

mapper
+ SF=4
Cch,4,1 bed,4

Q
E-DPDCH4 4PAM modulation
4 symbols mapper
Cch,256,0 bc j
DPCCH BPSK modulation

mapper

HSUPA 16QAM: Switching Point to 16QAM

ECR vs RLC bitrate for 2ms TTI
1 Switch to 16 QAM when:
RLC Bit Rate>4000kbps (when Effective Code Rate
0.9
0.8
QPSK>0.712, then switch to 16QAM)
0.7
UE selects 16QAM when E-TFCI is >103 (Table2) or
0.6
Switch >69 (Table3)
ECR [-]
0.5
Channel Bits per TTI vs RLC bitrate for 2ms TTI
to
0.4
Switch 16QA
to 2xM2+2xM4
0.3 16QAM
M Table 2
Code and Modulation Combination

0.2
Table 3
0.1
0
0 2000 4000 6000 8000 10000 12000 Table 2
RLC bitrate [kbps] Table 3
2xN2+2xN4
16QAM:
2xN2
2xM2 means 2*SF2 modulated with 4PAM Switch to
2xM4 means 2*SF4 modulated with 4PAM 2xN4 16QAM
N4
QPSK: N8
N16
N32
2000 4000 6000 8000 10000 12000
2xN2 means 2*SF2 modulated with BPSK RLC bitrate [kbps]
2xN4 means 2*SF4 modulated with BPSK

HSPA+ RRM: Contents
– HSUPA 16QAM
• Other features

Flexible RLC in UL: RAN1910

• Included in RU40 basic software package – no license needed
• Can be used if: Flexible RLC in DL and Basic HSUPA are both active
Prior Rel.8 Rel.8 Flexible RLC in UL
TCP/IP TCP/IP
header
TCP/IP Payload header
TCP/IP Payload
MTU: 1500 bytes MTU: 1500 bytes
RLC SDU RLC SDU
MAC-es/e RLC MAC-is/i RLC

headers PDUs Paddings headers PDU Padding
19 MAC-es/e 19 fixed RLC PDUs One MAC-is/i One RLC PDU is

headers required (656 bits each) required header required required per 1500
+ optional padding per 1500 bytes IP packet + optional padding bytes IP packet
Control data = 3.72% of whole transport block Control data = 0.27% of whole transport block
• When the transmission error occurs one small RLC PDU • It corresponds to 93% drop of control data for typical IP
needs to be retransmitted packet size of 1500 bytes
• When the transmission errors occur one big RLC PDU
needs to be retransmitted
Flexible RLC in UL: Background

• UE selects the E-TFC and TBS according to current grant on TTI basis
• RLC operations (segmentation and concatenation) on RLC SDUs are performed to
fit maximum RLC PDU size
• New MAC-is/i are introduced in order to handle flexible instead of fixed size RLC
PDUs
– MAC-i is introduced in the UE and BTS
– MAC-is is introduced in the UE and RNC
UE BTS RNC
RLC RLC
MAC-d MAC-d
MAC-is/i MAC-i MAC-is
Uu Iub
Flexible RLC in UL: Advantages

• Relative overhead and padding depends on the number of used PDUs
• For the typical IP packet size the relative overhead and padding is reduced from
3.72% to 0.27%, it relates to 93% of drop of control data
25%
Fixed RLC PDU
Relative overhead and padding
Flexible RLC PDU

20%
Length indicator changed
RLC PDU changed Relative overhead and
from 7 to 15 bits
from 336 to 656 bits padding is equal to 3.72%
15%
Relative overhead and

padding is equal to 0.27%
10%
5%
0%
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
RLC SDU size [bytes]
• Cell throughput for UE categories VIII and IX is increased

• Peak RLC throughput for UE categories VIII and IX is also increased
HSPA+ RRM: Contents
– HSUPA 16QAM
• Other features

HSUPA Downlink Physical Channel Power Control: RAN971
• Included in RU40 basic software package – no license required

• Can be used if: Basic HSUPA, HSUPA BTS Packet Scheduler and HSUPA Basic RRM
are active
Brief description:
• This feature introduces power control for following
downlink physical control channels:
– E-DCH Absolute Grant Channel (E-AGCH)
– E-DCH Relative Grant Channel (E-RGCH)
– E-DCH Hybrid ARQ Indicator Channel (E-HICH)
– Fractional Dedicated Physical Channel (F-DPCH)
• Controlling the transmit powers of the HSUPA downlink control channels based on the
feedback received from UE
Motivation and benefits:
• Reduction of average downlink power need
• The coverage area for 2ms E-DCH TTI may be increased
• Increased number of CS Voice over HSPA (RU20 – 72 users, RU40 – 128 users)

HSUPA Downlink Physical Channel Power Control: RAN971

Prior to RU40 RU40 HSUPA Downlink Physical
Channel Power Control
Transmitted Power of HSUPA Downlink Physical Transmitted Power of HSUPA Downlink Physical
channels is controlled through Power Offsets channels is controlled dynamically.
between HSUPA DL channels and: Value of Tx power is changed and is
• CPICH – RU10 incremented for the UE which are at a bigger
• DL DPCCH – RU20 & RU30 distance from the NodeB
E-AGCH Power Offset TX power is controlled dynamically
NodeB Tx Power NodeB Tx Power Level

RU10
35.00 35.00
30.00
NodeB Tx Power Level [dBm]

30.00
25.00
25.00
20.00
Tx power [dBm]
20.00 15.00
15.00 10.00
10.00
E-RGCH Power Offset / 5.00
E-HICH Power Offset 0.00

5.00 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.369
-5.00
0.00 -10.00
Distance from NodeB [km] UE Distance from NodeB [km]
CPICH E-AGCH E-EGCH/E-HICH CPICH E-AGCH E-RGCH/E-HICH
• Better common control channels power utilization

• The saved power of the DL HSUPA control channels provides increased HSDPA capacity
HSPA+ RRM: Contents
– HSUPA 16QAM
• Other features

Dynamic HSUPA BLER: RAN2302 HSUPADynBLEREnabled

WCEL; 0 (Disabled), 1 (Enabled)
Without the Dynamic HSUPA BLER With the Dynamic HSUPA BLER feature
feature the BLER target evaluation is the the BLER target is optimized for different
same regardless to: user scenarios and radio conditions:
• UE - BTS distance (cell edge / close to the • Close to BTS: optimizing BLER to get peak
BTS) rates
• Bursty / continuous data transmission • Cell edge continuous data transmission:
optimizing radio coverage and cell capacity
• Bursty traffic: optimizing latency
OLPC algorithm (RNC) enhancement
Support for different BLER targets adapted
to current radio transmission conditions
HSUPA
10%BLER 1%BLER
10%BLER
10%BLER
10%BLER
after 1st
69 © Nokia Siemens Networks RN3167BEN30GLA1 NACK
HSPA+ RRM: Contents
• Other features:

HSPA+ RRM: Contents
• Other features:
– CS Voice over HSPA
– Fast Dormancy
– Fast Dormancy Profiling
– Multi-Band Load Balancing MBLB
– High Speed Cell_FACH (DL)
– High Speed Cell_FACH

CPC: Continuous Packet Connectivity

Introduction
• Discontinuous UL DPCCH Transmission & Reception during UE UL traffic inactivity
(UL DPCCH gating + DRX at BTS) CPCEnabled
– CQI reporting reduction (switched from periodical to synchronized with DPCCH burst)
RNCWCEL; 0 (Disabled),
– Stopping E-DPCCH detection at NodeB during DPCCH inactivity
1 (Enabled)
• Discontinuous DL Reception (DRX at UE)
– Stop receiving HS-SCCH, E-AGCH & E-RGCH when not needed
• Faster response times
– Increased number of low activity packet users in CELL_DCH state
Motivation / Benefits:
• Increased capacity for low data rate applications
• Longer battery life
• Network:
– optional feature; ON-OFF RNC License CPC “Sub-features”:
• Prerequisites: • UL DPCCH Gating (UL DTX)
– UE must support CPC
– F-DPCH enabled • CQI Reporting reduction
• Discontinuous UL Reception (MAC DTX)
• Discontinuous DL Reception (DL DRX)

CPC: UL Gating (UL DTX)
UL Gating (UL DTX): reduces UL control channel (DPCCH) overhead

• no data to sent on E-DPDCH or HS-DPCCH  UE switchs off UL DPCCH
• DPCCH Gating is precondition for other 3 sub-features
Rel99 Service DPDCH

Voice (20ms) DPCCH
E-DPDCH
Rel6 Voice 2ms
(Rel6 VoIP) DPCCH
Rel7 Voice 2ms

E-DPDCH
(Rel7 VoIP)
DPCCH
UL DPCCH Gating

CPC: UL Gating
UL DPCCH Gating (UL DTX)
• UE specific Packet Scheduler provides CPC parameters
• These are service & UL TTI specific & part of parameter groups
– Voice 2ms, 10ms; RNCRNHSPA: CPCVoice10msTTI, CPCVoice2msTTI
– Streaming 2ms, 10ms; RNCRNHSPA: CPCStreaming10msTTI, CPCStreaming2msTTI
– Interactive, Background 2ms, 10ms; RNCRNHSPA: CPCNRT10msTTI, CPCNRT2msTTI
Following parameters are parameters from CPCNRT2msTTI group (per sub-feature):
DPCCH Gating (UL DTX):
• N2msInacThrUEDTXCycl2: number of consecutive E-DCH TTIs without an E-DCH transmission, after
which the UE should immediately move from UE DTX Cycle 1 to UE DTX Cycle 2. RNCRNHSPA; Range:1
(0), 2 (1), 4 (21), 8 (32), 16 (43), 32 (54), 64 (65), 128(76), 256 (87); default: 64 (65) TTIs
• N2msUEDPCCHburst1: UL DPCCH burst length in subframes when UE DTX Cycle 1 is applied.
RNCRNHSPA; Range:1 (0), 2 (1), 5 (2); default: 1 (0) subframes
• N2msUEDPCCHburst2: UL DPCCH burst length in subframes when UE DTX Cycle 2 is applied.
RNCRNHSPA; Range:1 (0), 2 (1), 5 (2); default: 1 (0) subframes
• N2msUEDTXCycle1: UL DPCCH burst pattern length in subframes for UE DTX Cycle 1. RNCRNHSPA;
Range: 1 (0), 4 (1), 5 (2), 8 (3), 10 (4), 16 (5), 20 (6); default: 8 (3) subframes
• N2msUEDTXCycle2: UL DPCCH burst pattern length in subframes for UE DTX Cycle 2. RNCRNHSPA;
Range: 4 (0), 5 (1), 8 (2), 10 (3), 16 (4), 20 (5), 32 (6), 40 (7), 64 (8), 80 (9), 128 (10), 160 (11); default: 16 (4)
subframes

CPC: UL Gating / DPCCH Gating

UL Gating, E-DCH 2ms TTI example: CPCNRT2msTTI
N2msInacThrUEDTXCycl2
RNCRNHSPA; 1, 2, 4, 8, 16, 32, 64, 128, 256; 64 TTIs
CFN 10ms Radio Frame 10ms Radio Frame 10ms Radio Frame
Inactivity Threshold for UE cycle 2

E-DPDCH
Tx, 2ms TTI
no data on E-DPDCH
DPCCH N2msUEDPCCHburst1
RNCRNHSPA; 1, 2, 5; 1 subframe(s)
pattern
N2msUEDPCCHburst2
synch reference RNCRNHSPA; 1, 2, 5; 1 subframe(s)
UE_DTX_Cycle_1
N2msUEDTXCycle1
UE_DTX_Cycle_2 RNCRNHSPA; 1, 4, 5, 8, 10, 16, 20; 8 subframes UE_DTX_Cycle_2
N2msUEDTXCycle2
RNCRNHSPA; 4, 5, 8, 10, 16, 20, 32, 40,
DPCCH with 64, 80, 128, 160; 16 subframes
E-DCH, 2ms TTI
2ms subframe cycle 1 cycle 2
UE_DTX_DRX_offset is UE specific offset granted from BTS switch to UE cycle 2

CFN: Connection Frame Number; used for any synchronized procedure in UTRAN
Pre/Postambles not shown here

CPC: Reduced CQI Reporting
CQI Reporting reduction:

• CQI Reporting Reduction reduce the Tx power of the UE by reducing the CQI reporting; this means
to reduce the interference from HS-DPCCH in UL when no data is transmitted on HS-PDSCH in DL
• Reduced CQI reporting takes place only if the CQI reporting pattern defined by the last HS-DSCH
transmission and CQI cycle overlaps the UL DPCCH burst of the UE DTX pattern
• N2msCQIDTXTimer: defines the number of subframes after an HS-DSCH reception, during which the CQI
reports have higher priority than the DTX pattern. RNCRNHSPA; 0 (0), 1 (1), 2 (2), 4 (3), 8 (4), 16 (5), 32 (6),
64 (7), 128 (8), 256 (9), 512 (10), Infinity (11); 64 (7) subframes
• N2msCQIFeedbackCPC: defines the CQI feedback cycle for HSDPA when the CQI reporting is not reduced
because of DTX. RNCRNHSPA; 0 (0), 2 (1), 4 (2), 8 (3), 10 (4), 20 (5), 40 (6), 80 (7), 160 (8); default: 10 (4) 8
(3) ms; Note: Bigger CQI reporting cycles 10ms are not recommended.

CPC: Reduced CQI Reporting

CQI Reporting Reduction reduces the CQI reporting when there • Reduction of interference
are no data transmitted on HS-DSCH for a longer period of time from UL HS-DPCCH
• Reduced CQI reporting
takes place only if the CQI
N2msCQIDTXTimer reporting pattern defined by
RNCRNHSPA; 0, 1, 2, 4, 8, 16, 32, 64, 128,
256, 512, infinity; 64 subframes the last HS-DSCH
transmission and CQI cycle
HS-DSCH reception CQI_DTX_TIMER
overlaps the UL DPCCH
CQI_DTX_Priority set to 0
burst of the UE DTX pattern
ACK/NACK
7.5
transmission slots
CQI_DTX_Priority set to 1
DPCCH
pattern
UE_DTX_cycle_1 UE_DTX_cycle_1
UE_DTX_cycle_2 UE_DTX_cycle_2 UE_DTX_cycle_2

CQI transmission
CQI period 2ms
CQI period 4ms
CQI period 8ms
CQI transmission time defined by CQI period, but not overlapping with
DPCCH transmission no CQI transmission
CQI Transmission N2msCQIFeedbackCPC

CQI feedback cycle (when CQI reporting not reduced)
RNCRNHSPA; 0, 2, 4, 8, 10, 20, 40, 80, 160 ; 108 ms

CPC: Discontinuous UL & DL Reception

(MAC DTX & DL DRX)
During E-DCH inactivity, E-DPCCH detection happens at the BTS only every MAC_DTX_Cycle subframes. It is
stopped at Node B after MAC_inactivity_threshold subframes of E-DCH inactivity. As a consequence, the UE
experiences a delay regarding the transmission start time. The UE-specific offset parameter UE_DTX_DRX_Offset
allows to stagger the processing of several UEs in time to save the BTS resources.
Discontinuous UL Reception (MAC DTX):
• N2msMACDTXCycle: length of MAC DTX Cycle in subframes. This is a pattern of time instances where
the start of the UL E-DCH transmission after inactivity is allowed. RNCRNSHPA; Range: 1 (0), 4 (1), 5 (2), 8
(3), 10 (4), 16 (5), 20 (6); default: 8 (3) subframes
• N2msMACInacThr: E-DCH inactivity time in TTIs after which the UE can start E-DCH transmission only at
given times. RNCRNHSPA; iInfinity (0), 1 (1), 2 (2), 4 (3), 8 (4), 16 (5), 32 (6), 64 (7), 128 (8), 256 (9), 512
(10) TTIs; default: Infinity (0)
Discontinuous DL Reception (DL DRX):
• N2msInacThrUEDRXCycle: number of subframes after an HS-SCCH reception or after the first slot of an
HS-PDSCH reception, during which the UE is required to monitor the HS-SCCHs in the UE's HS-SCCH set
continuously. RNCRNHSPA; Range: 0 (0), 1 (1), 2 (2), 4 (3), 8 (4), 16 (5), 32 (6), 64 (7), 128 (8), 256 (9),
512 (10); default: 64 (7) subframes
• N2msUEDRXCycle: HS-SCCH reception pattern (UE DRX Cycle) length in subframes. This parameter is a
multiple or a divisor of the parameter UE DTX Cycle 1. If the value is not allowed, the parameter value minus
1 is used to calculate a new value, and so on. RNCRNHSPA; Range: 0.5 (0), 1 (1), 2 (2), 3 (3), 4 (4); default:
2 (2)
subframes

CPC: Discontinuous UL Reception

Discontinuous UL Reception (MAC-DTX) – NSN implemented parameters
N2msMACInacThr
RNCRNHSPA; iInfinity, 1, 2, 4, 8, 16, 32, 64, 128,
256, 512; iInfinity subframes
DTX N2msMACDTXCycle
length of MAC DTX Cycle
UE can transmit E-DPDCH data RNCRNHSPA; iInfinity, 1, 4,
5, 8, 10, 16, 20; 8 subframes
only at predefined time instances.

CPC: Discontinuous DL Reception

Discontinuous DL Reception (DL DRX)
• When the UE DRX is enabled, the UE may turn off the receiver when there is no need to receive
anything in DL
• The DL DRX can be enabled only in conjunction with UL DTX
N2msInacThrUEDRXCycle
UE DRX Inactivity threshold
RNCRNHSPA; 0, 1, 2, 4, 8, 16, 32, 64, 128,
256, 512; 64 subframes
DRX
N2msUEDRXCycle
length of UE DRX Cycle DL DRX
RNCRNHSPA; 0.5, 1, 2, 3, 4; 2 subframes only with UL DTX !
• N2msInacThrUEDRXCycle: number of subframes after an HS-SCCH reception or after the 1st slot of an HS-PDSCH reception,
during which the UE is required to monitor the HS-SCCHs in the UE's HS-SCCH set continuously; UE DRX Inactivity threshold;
RNCRNHSPA; 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512; 64 subframes
• N2msInacThrUEDRXCycle: HS-SCCH reception pattern (UE DRX Cycle) length in subframes; RNCRNHSPA; 0.5, 1, 2, 3, 4; 2
subframes

CPC & Power Control

Power Control
• New parameter introduced to control step size for DL Inner Loop PC
DLInLoopPCStepSizeCPC
RNCRNSPA: 0.5..2; 0.5; 1.5 dB
DLInLoopPCStepSizeCPC:
used by the WCDMA BTS to calculate the power increase/decrease step size when receiving TPC commands.
It is applied when CPC (UE DTX, etc.) is activated for the UE.
Note: If CPC is not used for a UE, BTS applies DownlinkInnerLoopPCStepSize
DownlinkInnerLoop
PCStepSize
RNCRNAC : 0.5..2; 0.5; 1 dB

CPC: Extra-inactivity timer for

Transition from CELL_DCH to CELL_FACH
InactivityTimerUL_DLDCH
RNCRNHSPA; structured parameters
CELL_ Range: 0 .. 20 s; Step: 1 s; default:
DCH UE Node B RNC • for 8, 16 & 32 kbps: 5 s
• for 64 kbps: 3 s
• for 128, 256, 320 & 384 kbps: 2 s
PDU Transport on the DCH/DPCH
All data sent &
RLC-U buffer empty
Start
Inactivity detected
InactivityTimerULDCH
InactivityTimerDLDCH
Radio Bearer Reconfiguration Expiry
CELL_
FACH Radio Bearer Reconfiguration Complete
as soon as L2 in RNC indicated RB inactivity, RNC allocates “extra - InactCPCNoBatOptT: 180 s

inactivity timer” to keep the UE in Cell_DCH
InactCPCBatOptT: 90 s
This depends on: InactNonCPCNoBatOptT: 0 s
– CPC is allocated for a UE or not (CPC or NonCPC)
InactNonCPCBatOptT: 0 s
– UE Device Type – RNC knows from UE capabilities
all parameters: RNCRNHSPA; 0s..48h
 UE benefits / does not benefit from Power Consumption Optimization
(BatOpt / NoBatOpt) & infinity; several steps;

HSPA+ RRM: Contents
• Other features:
– Continuous Packet Connectivity CPC
– Fast Dormancy

CS Voice Over HSPA (RAN1689) HSPAQoSEnabled

RNCWCEL; 0..4*; 1; 0 = disabled
Requirements 0 = QoS prioritization is not in use for HS transport
1 = QoS prioritization is used for HS NRT channels
Network: 2 = HSPA streaming is in use
• optional RU20 feature; ON-OFF RNC License 3 = HSPA CS voice is in use
4 = HSPA streaming & CS voice are in use
UE:
• must support CSvoiceOverHSPA QoSPriorityMapping
• optional feature in Rel. 7/8 RNCRNPS; 0..15; 1; 14 for CS Voice over HSPA
• Priority must be lower than SRB (15)
required Network Features: • Priority must be higher than Streaming 13)
• HSDPA Dynamic Resource Allocation
• QoS Aware HSPA Scheduling
• CPC
• F-DPCH
• HSPA with simultan. AMR Voice
• SRB must be mapped to HSPA
• supported RAB combinations: for Voice, SRB
• Speech CS RAB & other services
• Speech CS RAB + PS streaming PS RAB
• Speech CS RAB + 1...3 IA/BG PS RABs
• Speech CS RAB + PS Streaming PS RAB + Codecs supported for CS Voice Over HSPA:
1...3 IA/BG PS RABs • AMR (12.2, 7.95, 5.9, 4.75), (5.9, 4.75) & (12.2)
• Load based AMR selection algorithm not used • AMR-WB (12.65, 8.85, 6.6)
while CS Voice is mapped on HSPA
* if HSPA streaming or CS voice is activated, then QoS
BG: Background prioritization for NRT HSPA connections is in use, too
IA: Interactive

Enabling the feature: CS Voice Over HSPA

Pre-conditions
• CS voice over HSPA license exists & state is 'On‘

• HSDPA with Simultaneous AMR Voice Call license exists & state is 'On'
• HSUPA with Simultaneous AMR Voice Call license exists & state is 'On'
• AMRWithHSDSCH & AMRWithEDCH: HSPA with Simultaneous AMR Voice Call enabled
• HSDPAenabled & HSUPAenabled : HSPA enabled in all Active Set cells
• HSDPA Dynamic Resource Allocation license exists & state is 'On‘
• HSDPADynamicResourceAllocation is enabled
• QoS Aware HSPA Scheduling license exists & state is 'On‘
• HSPAQoSEnabled is set to “HSPA CS voice” in all Active Set cells
• CPC & Fractional DPCH licenses exists & state is 'On‘
• CPCEnabled in all Active Set cells
• FDPCHEnabled: Fractional DPCH enabled in all Active Set cells

CS Voice Over HSPA

Efficiency
• Two different voice transmission scenarios are being considered with IP:
– VoIP – UE connects with network as in standard Packed Data transmission and by using “web
communicators” a connection can be established
(hard to establish appropriate charging schemes)
– CS voice over IP – voice is being carried by HSPA transport channels transparent for the user
Assumed IP
Header
Compression
[REF. WCDMA for UMTS – HSPA Evolution and LTE, HH AT]

CS Voice Over HSPA

Concept / Protocol Stack
• In UL there is a so called Dejitter buffer implemented in RNC PDCP
• used to align the UL data stream before routing to MSC or MSS system
• In DL MAC-ehs is used to support flexible RLC PDU sizes CS
• supporting different AMR rates RAN Core
CS Voice
CS Dejitter
CS Voice over buffer
over Core HSPA
DCH RAN PDCP
TM RLC UM RLC
DCH HSPA
• Inter system mobility between 2G & 3G is as today, the CS Voice Over HSPA is just RAN internal
mapping and it is not visible outside of the RAN. Handover signaling is not affected and RAN provides the
measurement periods for UE using compressed mode as today
• AMR rate adaptation can be used to provide even higher capacity gains by lowering the AMR coding rate
• Voice related RRM algorithms like pre-emption are expanded to cover also the Voice Over HSPA
• Air interface capacity gain of the feature depends on parameterisation of HSUPA including CPC
parameters, allowed noise rise and voice activity

CS Voice Over HSPA

Admission Control: PtxNCTDCH + PtxNCTHSDPA + Pnew < PtxTargetTot
CS Voice over HSPA connection
&& PtxNCTHSDPA + Pnew < PtxMaxHSDPA
admitted if:
PtxMaxHSDPA PtxTargetTotMax
max. allowed max. target pwr for NCT* load
PtxCellMax WCEL; -10..50; 0.1; 4132767 dBm
HSDPA power HSDPA PS streaming Special value: Use of dynamic DL
WCEL; 0..50 dBm;
target power is disabled
0.1 dB; 43 dBm PtxTargetTotMax
NCT Tx power target
HSDPA NRT PtxTargetTot for DCH + HSPA
PtxTargetTotMin
PtxTargetTotMin
PtxNCTHSDPA HSDPA voice + SRBs min. target pwr for NCT* load
PtxTarget WCEL; -10..50; 0.1; 4032767 dBm
Special value: Use of dynamic DL
DCH PS streaming NCT Tx power target target power is disabled
for DCH
DCH NRT
DCH RT + SRBs PtxTargetTot
PtxNCTDCH (excluding PS streaming)
is calculated always when
Common Channels NCT* load services
are admitted
PtxNCTHSDPA: power used by HSDPA conversational services
PtxNCTDCH: power used by DCH services associated as NCT load * Non-Controllable Traffic NCT: CS services & PS conversational services

Dynamic target power for NCT load

The min. & max. value for dynamic target power Rules:
for NCT load (CS services & PS conversational
PtxTargetTotMin  PtxTargetTot 
services) can be set :
PtxTargetTotMax
PtxTargetTotMin PtxTargetTotMin  PtxTargetTotMax
WCEL; -10..50 dBm; 0.1 dBm; 4032767 dBm
PtxTarget  PtxTargetTotMin
PtxTargetTotMax PtxTargetTotMax  PtxCellMax
WCEL; -10..50 dBm; 0.1 dBm; 4132767 dBm
Dynamic target power is used when in cell there are SRBs or conversational services (NCT load) mapped to HS-
DSCH transport channel. Dynamic target power varies between PtxTargetTotMin & PtxTargetTotMax depending on
the mix of services mapped to DCH & HS-DSCH transport channels.
However, NCT load caused by services mapped to DCH transport channels must still stay below PtxTarget.
Power margin between PtxCellMax & PtxTargetTotMax is needed to protect the already admitted services
mapped to HS-transport channels by giving time for the overload control to adjust PS DCH load before high priority
HS-DSCH load is affected.
PtxTargetTot is calculated whenever a NCT connection is admitted
PtxTargetTotMax
PtxTargetTot = PtxTargetTotMax - PtxNCTDCH ( PtxTarget
-1
)
PtxNCTDCH: power used by DCH services associated as NCT load
NCT: Non-Controllable Traffic

PtxTargetPS Target Calculation
• The introduction of CS Voice over HSPA impacts the calculation of the target for PtxTargetPS
• The original calculation in RAS06 was:
PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc) x WeightRatio]
• This calculation shares the power left over from non-controllable load between HSDPA & NRT
DCH connections
• The calculation was updated in RU10 to account for HSDPA streaming:
PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc- Ptx_hsdpa_stream) x WeightRatio]
• The updated calculation reduces the quantity of power to be shared by effectively including HSDPA
streaming power as non-controllable power
• The calculation is further updated when CS Voice over HSPA is enabled
PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc- Ptx_hsdpa_stream- Pnc_hsdpa) x WeightRatio]
CS Voice over HSPA transmit

power

UL Power Allocation: dynamic threshold PrxTargetAMR

• PrxTargetAMR is used for the admission of UL PrxTargetMax
max. UL target power for CS
DCH & E-DCH, SRB & CS AMR connections speech service allocation
• PrxTargetAMR shall be applied always, w/o WCEL; 0..30; 0.1; 465535 dB
considering the activation of the feature CS voice
over HSPA.
• PrxTargetAMR varies between PrxTarget & PrxTargetMax
PrxTargetMax depending upon the UL load of HSUPA NRT
PrxTargetAMR
data services
• PrxTargetAMR is calculated by cell specific AC PrxTarget
inside RNC HS/DCH CS AMR
• NCT can always use power up to PrxTarget DCH CS data PrxTargetPS
• Standalone SRB & CS AMR can be admitted
even if the NC interference power exceeds DCH PS NRT
PrxTarget as long as the RSSI is below PrxDataDCHNST
PrxTargetAMR HSUPA PS streaming
• SCT load of the HSUPA & UL DCH streaming DCH PS streaming
services can take all power left from the NCT
load up to PrxTarget other interference,
Noise power
• DCH PS NRT services can use power up to
dynamic UL DCH target PrxTargetPS
Semi-Controllable Load Controllable Load
• HSUPA PS NRT services can take all power left
from all other services Non-Controllable Load
NST: Non-Scheduled Transmission
SCT: Semi-controllable traffic

HSUPA Non-Scheduled Transmission NST

• NST is used for the UL of CS Voice over HSPA
• HSUPA TTI = 2 ms  1 HARQ process is allocated for the E-DCH MAC-d flow
• EDCHMuxVoiceTTI2 & EDCHMuxVoiceTTI10 define whether or not other E-DCH MAC-d flow data
can be multiplexed within the same MAC-e PDU as CS Voice
• The max. Number of Bits per MAC-e PDU for NST indicates the number of bits allowed to be included
in a MAC-e PDU per E-DCH MAC-d flow configured for non-scheduled transmissions
• Generally the MAC-d flow of the SRB has higher SPI value, being prioritized over the CS voice in the
E-TFC selection
•  The max. SRB bit rate will be limited so that the at least 1 CS voice frame can always transmitted
together with the signaling when the max. puncturing is applied, for minimizing the CS voice delay
• 2 ms TTI is selected whenever possible, otherwise 10 ms TTI is used
The maximum target value for the RTWP in UL for CS speech service allocation:
PrxTargetMax
defines the max. target value for the RTWP in the UL resource allocation for the CS speech services. A dynamic target
of RTWP is applied in the resource allocation for the CS speech services and for the establishment of the link.
Dynamic target is the closer to the value of this parameter, the less there is PS NRT R99 data traffic and RT data R99
and HSPA traffic in the cell. Establishment of the stand alone signaling link or a single service CS speech can be
admitted in UL even the received non-controllable interference exceeds the value of the parameter "Target for received
power" so long as the RTWP keeps below the dynamic target value defined with this parameter.
WCEL: 0..30 dB; 0.1 dB; 465535 dB
NST: Non-Scheduled Transmission

HSPA+ RRM: Contents
• Other features:

Fast Dormancy: Background (1/2)

Smart phones with many applications, requiring frequent UTRA RRC Connected Mode
transmission of small amount of data# (always-on) URA_PCH CELL_PCH
To save battery power, 3GPP defines transition from states
with high power consumption (Cell_DCH, Cell_FACH) to
those with low consumption (Cell_PCH, URA_PCH) CELL_FACH
CELL_DCH
approx. battery consumption in different RRC states:
•Idle = 1 (relative units)
•Cell_PCH < 2*1
•URA_PCH ≤ Cell_PCH*2
•Cell_FACH = 40 x Idle Idle Mode
•Cell_DCH = 100 x Idle Typical terminal power consumption
300
250
Power consumption [mA]
200
150
100
50
0
URA_PCH / Cell_FACH Cell_DCH
Cell_PCH / Idle
*1 depends on DRX ratio with Idle & mobility
*2 < in mobility scenarios, = in static scenarios
# e.g. sending frequent ‘polls’ or ‘keep-alives’

Fast Dormancy: Background (2/2)
Problem for UE:

many networks with rel. long inactivity timers for Cell_DCH UTRA RRC Connected Mode
& Cell_FACH and/or PCH states not activated URA_PCH CELL_PCH

UE vendors introduced proprietary Fast Dormancy:
•UE completes data transfer CELL_DCH CELL_FACH
•UE sends Signaling Connection Release Indication SCRI
(simulating a failure in the signaling connection)
•RNC releases RRC connection  UE to RRC Idle mode
Disadvantages: Idle Mode
•increasing signaling load due to frequent packet
connection setup (PS RAB),
•large number of “signaling connection failures”
•increased latencies

Fast Dormancy: Principle

3GPP Rel. 8: Fast Dormancy
UTRA RRC Connected Mode
•modifying SCRI message; new cause value indicating
packet data session end URA_PCH CELL_PCH
•RNC can keep UE in RRC connected mode, moving it into
CELL_PCH/URA_PCH
 CELL_DCH CELL_FACH
UE battery life remains prolonged because power
consumption in CELL_PCH/ URA_PCH is low
Network again in charge of RRC state; clarification of
“signaling connection failures” Idle Mode
Reduction of signaling load & latency times
Cause value of
3GPP TS 25.331 ‘UE Requested
10.3.3.37a Signalling Connection Release Indication Cause PS Data Session
„This IE is used to indicate to the UTRAN that there is no more PS data for a prolonged period.“ End’ defined
SRCI: Signalling Connection Release Indication

Fast Dormancy
FastDormancyEnabled
SIB1: T323 BTS
RNFC; 0 (Disabled), 1 (Enabled)
MSActivitySupervision SCRI: „UE Requested PS Data Session End”

MSActivititySupervision
RNC; 0..1440; 1; 29 min „Physical Channel Reconfig.”  move to CELL_PCH
UE RNC
RAN2136: Fast Dormancy (FD)
• Basic SW; no activation required; enabled by default
• MSActivitySupervision to be configured with value > 0 to enable PCH states
• Enabling FD results in T323 being broadcast within SIB1
T323:
• Inclusion of T323 within SIB1 allows UE to detect that network supports FD
• Setting a min. delay between 2 SRCI messages for FD; prevents, that UE is sending a flow of SCRI
messages, if network is temporarily unable to move UE to a battery-saving state
Fast Dormancy - RNC Actions:

T323
After receiving SCRI message with cause value ‘UE Requested PS Data Session End’:
RNC; 0..7; 1; 10 s
(hardcoded) •FD functionality overrides inactivity timers
•RNC instructs UE to make state change to CELL_PCH/URA_PCH
If RNC receives an SCRI message without a cause value then the existing legacy
functionality is applied & the UE is moved to RRC Idle mode
SRCI: Signalling Connection Release Indication

HSPA+ RRM: Contents
• Other features:
– Fast Dormancy

Fast Dormancy Profiling: RAN2451

• Included in RU40 application software package – license is required
Brief description:
• Identifies legacy Fast Dormancy phones which cause unnecessary signaling load
• Provides with better network resources utilization due to shorter inactivity timers
• Less signaling load because LFD (Legacy Fast Dormancy) Phones are being forced
to stay in Cell_PCH
Benefits:
• Signaling load reduction on Iub, UU and Iu interfaces
• Signaling load reduction in the RNC
• Longer UE battery life
Overview: • RAN supports Fast dormancy
• Application has no more data to transfer
• UE wants go to more battery efficient RRC state
SCRI
RNC: Data session ended SIB1 contains info about T323 Go to URA/Cell_PCH
RNC: UE move to more battery efficient state
Fast Dormancy Profiling: Background

Legacy Fast Dormancy phone detection:
• The UE is detected as Legacy Fast Dormancy phone (LFDphone) when network receives
RRC:Signaling Connection Release Indication without any cause
• If the Fast Dormancy Profiling feature is activated then RRC state transition is performed
according to Fast Dormancy functionality
SCRI - without any cause
RNC checks if
the license is ON
If the license is available - Go to Cell_PCH

Handling the PS Connection Establishment:
• The LFD Phone after sending SCRI without any cause may still silently goes to Idle
• After receiving RRC: Initial Direct Transfer, RNC checks if Iu-PS connection already exists
• If yes, then all existing PS RAB resources locally and the old Iu connection are released
• New Iu connection is established for pushing RRC: Initial Direct Transfer to SGSN
Iu
RNC checks
if Iu-PS RRC: Initial Direct Transfer
connection
for this UE
already
exists
Fast Dormancy Profiling: Principle

Shorter Inactivity Timers for LFD Phone and Smartphones:
• Shorter inactivity timers should be used for moving smartphones and LFD Phones to
Cell_PCH state - saving UE battery
• It gives possibility to avoid unnecessary movement to IDLE_mode – less signaling load
Higher Traffic Volume Thresholds for LFD Phone and Smartphones:
• Higher traffic volume thresholds should be used for moving smartphones and LFD Phones
to Cell_DCH state
• It gives possibility to avoid unnecessary movement to Cell_DCH – only for sending keep-
alive message
• Stored IMSI gives possibility to faster usage of higher traffic volume thresholds

HSPA+ RRM: Contents
• Other features:
– Fast Dormancy

Multi-Band Load Balancing MBLB

Brief description:
 RU30 (RAN 2172); optional RAN feature; RNC level license
 RU20 & earlier, Intra-/Inter-band Redirections/Handover:
Capability based redirection (e.g. HSPA/non HSPA capable UEs  HSDPA/non HSPA)
HSPA capability based IFHO (pushes HSPA capable UEs to HSPA layers;
no load check in target cells before HO)
Load based HO (moves non-HSPA calls; HSPA load can’t trigger load based HO)
 New/extended in RU30: HSPA+ capable Inter-Band Handovers/ Redirections
Target cell selection can depend on:
 UE capability & service,
 frequency band,
 target/source cell load,
 UE distance from source/target cells.
Motivation & benefits:
 Better frequency resource utilization, directing UE to different frequency bands/layers in multi-band
networks. Capability, service, load & distance based HO are now possible for HSPA+ between
e.g. UMTS 2100 & 900/850 cells
DCH/HSPA cell (band Z) DCH/HSPA cell (band Z)
DCH/HSPA cell (band Y, RF2) DCH/HSPA cell (band Y, RF1)
DCH/HSPA cell (band X)

MBLB (RU30; RAN 2172) includes RAN2289 Blind IFHO in RAB setup phase.
• MBLB can trigger in 4 different phases which all can be activated separately:
RAN 2172
Multi-band Load Balancing
RAN2289
Blind IF-HO Inactivity Layering in Mobility

at RAB setup triggered state change triggered
• either first RAB, or AMR RAB for a • inactivity detected for last • state transitions*: CELL_ • addition of cell to AS which has
UE which already has an NRT RAB active PS NRT MAC-d flow FACH, URA_PCH or different preferred layer def.
• blind Handover • IFHO with CM measurements CELL_PCH  CELL_DCH* • IFHO with CM measurements
IF-HO to higher prioritised frequency layer in same or different band

Each type can be enabled on cell level independently on others, by corresponding
source cell WCEL parameter (enabling in target cell not needed):
MBLBRABSetupEnabled MBLBInactivityEnabled MBLBStateTransEnabled MBLBMobilityEnabled
for all: WCEL; 0 (Disabled), 1 (Enabled)
* doesn’t include transition from RRC Idle mode

AS: Active Set
MBLB: Blind IFHO & Layering in State Change modes

Redirection/Blind IFHO to
DCH/HSPA cell (band Z) DCH/HSPA cell (band Z) higher priority layer cell, at:
Connection setup OR
DCH/HSPA cell (band Y, RF2) DCH/HSPA cell (band Y, RF1) CTS FACH/PCH/URA  DCH

MBLBRABSetupEnabled MBLBStateTransEnabled
Enabling Blind IFHO at RAB Setup Layering in State Change
WCEL; 0 (Disabled), 1 (Enabled)) WCEL; 0 (Disabled), 1 (Enabled))
Blind IFHO & Layering in State Change extends existing redirection scenarios.
Both triggers utilize blind IFHO mechanism (w/o CM activation).
Target can be IF-neighbor in same or different BTS / frequency / frequency band.
IF-neighbour must have higher priority ( preference score) than source cell.
MBLB adds IF-RACH measurements to have target cell info before blind HO decision*.
Intra-freq. RACH measurement quantity (SIB11/11bis/12) to be modified from EcNo to RSCP.
RSCP is used as pathloss equivalence indicating UE position within a cell RACHIntraFreqMesQuant
RSCP (Target Cell) must be > BlindHORSCPThrTarget WCEL; EcNo (0), RSCP (1)
BlindHORSCPThrTarget
HOPIWCEL; -115..-25; 1; -95 dBm
CTS: Channel Type Switching

* requires UE Rel. 6 or newer

MBLB: HSDPA Inactivity or Mobility triggered modes

CM IF-HO to higher priority
DCH/HSPA cell (band Z) DCH/HSPA cell (band Z) layer cell, on:
HS-DSCH HSDPA traffic inactivity
:
DCH/HSPA cell (band Y, RF2) DCH/HSPA cell (band Y, RF1) (instead CTS to FACH)
HS-DSCH

MBLBInactivityEnabled MBLBMobilityEnabled
Inactivity triggered Mobility triggered
WCEL; 0 (Disabled), 1 (Enabled)) WCEL; 0 (Disabled), 1 (Enabled))
Extending event triggered scenarios (on HSDPA traffic Inactivity) & adding new HSDPA mobility
triggers.
Target cell can be any Intra-RNC, IF-neighbour cell (same/different BTS, same/different freq. band)
which is not in overload state1). It must have higher priority ( preference score) than source cell.
HSDPA Inactivity triggered when for UEs last active PS NRT MAC-d flow & corresponding UL PS
NRT DCH/E-DCH MAC-d flow can be released
Mobility triggered HO:
Adding new cell to AS (Event 1A/1C), with different preferred layer def. than the currently used.
Removing cell from AS (Event 1B/1C) which has preferred layer def. currently used by UE
SRNC relocation completed
UE detected to have high mobility (using criteria for URA_PCH)
1)
Overload state is checked prior HO. CTS: Channel Type Switching


HSDPA inactivity or Mobility triggered modes
MBLBRABSetupEnabled MBLBStateTransEnabled MBLBInactivityEnabled MBLBMobilityEnabled
State transition Inactivity Mobility Fast Mobility

RAB Setup to Cell_DCH detected detected detected
1) Target cell is source cell’s ADJI with

BlindHOTargetCell set to “Enabled”
2) Cells in inter-frequency measurement report
Preference Score
PrefLayerWeight own parameters for FM UE
BandWeight
RSCPWeight
LoadWeight LoadWeight
Quality Criteria checking
Blind HO Layering IFHO with CM
BlindHOTargetCell
ADJI; 0 (Disabled), 1 (Enabled)

Frequency layer priority - Preference Score (1/5)
Each carrier (& frequency band) used in RNS can be differently prioritised. Carrier/frequency layer
priority (preference score) is effected by:
 Pref. Freq. weight: Selection of carrier preferred for configurations  UE capability & used RAB
 Band weight: RNC level selection of one preferred frequency band
 RSCP weight: High &/or low band preference depending on UE distance from source cell
 Load weight: HSDPA cell or carrier / freq. layer load preference (load balance / overload)
Each factor represented by weight is OAM configurable. Candidates for MBLB are IF neighbours on
freq. layer higher prioritised then source cell layer, in bands supported by UE
Not considered for
Not considered non-HSPA UEs or
for fast moving other with CS RAB in
UEs DCH cell
Freq layer priority = Preferred Freq + Freq Band + RSCP + Load

(Preference Score) weight weight weight weight
= = = =
0 0 0 0
or or or or
LaySelWeightPrefLayer LaySelWeightBand LaySelWeightRSCP >=LaySelWeightLoad


Frequency layer priority - Preference Score (2/5): Preferred Freq. weight
Each combination „UE capability – Used/Requested Service” may be redirected by Operator to preferred frequency.
E.g.: MIMO capable UE with NRT RAB should be redirected to frequency with MIMO configured cells.
•Preferences are defined in new object PFL (Preferred Frequency Layer);
•up to 8 carriers per „UE capability-Used Service” pair (PrefLayerXXX[1-8] = preferred RF freq.
UE Capability
Priority Order Service/RAB parameters included to PFL object
CS Voice Over HSPA PrefLayerCSHSNRT PrefLayerCSHSStr PrefLayerCSHSAMR PrefLayerCSHSAMR&NRT
DC HSDPA + MIMO PrefLayerDCMINRT PrefLayerDCMIStr PrefLayerDCMIAMR PrefLayerDCMIAMR&NRT
DC HSDPA * PrefLayerDCHSDNRT PrefLayerDCHSDStr PrefLayerDCHSDAMR PrefLayerDCHSDAMR&NRT
MIMO** PrefLayerMIMONRT PrefLayerMIMOStr PrefLayerMIMOAMR PrefLayerMIMOAMR&NRT
HSDPA 64QAM PrefLayer64QAMNRT PrefLayer64QAMStr PrefLayer64QAMAMR PrefLayer64QAMAMR&NRT
F-DPCH PrefLayerFDPCHNRT PrefLayerFDPCHStr PrefLayerFDPCHAMR PrefLayerFDPCHAMR&NRT
HSPA PrefLayerHSPANRT PrefLayerHSPAStr PrefLayerHSPAAMR PrefLayerHSPAAMR&NRT
HSDPA PrefLayerHSDPANRT PrefLayerHSDPAStr PrefLayerHSDPAAMR PrefLayerHSDPAAMR&NRT
R99 PrefLayerR99NRT PrefLayerR99Str PrefLayerR99AMR PrefLayerR99AMR&NRT
e.g.
LaySelWeightPrefLayer Preferred Layer
PrefLayerR99NRT
preferred RF freq. for UE
PFL; 0..10000; 1; 0 (not used) 1000 weight
capab. – RAB combination =
PFL; 0..16383; 1; -0 PrefLayerXXX[1-8] 0 = not defined  0
= preferred RF freq. >0 (RF freq number)  LaySelWeightPrefLayer


Frequency layer priority - Preference Score (3/5): Freq. Band weight
Operator can promote one frequency band among used by neighbours of source cell. The Freq Band
weight of candidate cell carrier is determined from its absolute RF number. Candidate cells in
promoted band are assigned with non-zero weight: LaySelWeightBand
PreferBandForLayering if any band preferred  PreferBandForLayering

Preferred UMTS band
RNMOBI; 0..51; 1; 0 (no band pref.)
 Freq.BandWeight (of pref. band freq.) = LaySelWeightBand
Band ID Frequency band (DL range) Freq Band LaySelWeightBand

1 RF band I (2110÷2170MHz) / IMT weight PFL; 0..10000; 1; 0 (not used)
2 RF band II (1930÷1990MHz) / PCS

3 Band III (1805÷1880MHz) / DCS
4 Band IV (2110÷2155MHz) / AWS
5 Band V (869÷894MHz) / CLR
6 Band VI (875÷885MHz)
7 Band VII (2620÷2690MHz) / IMT-E
8 Band VIII (925÷960MHz) / GSM
.. …
11 Band XI (1475.9÷1495.9MHz)
…


Frequency layer priority - Preference Score (4/5): RSCP weight
Operator can prioritise IFHO to lower/higher band in case RSCP is below/above defined thresholds.
RSCP of source cell* is used as indication of UE distance from source cell. Close UE can be moved
to higher band (smaller cell range), while distant UE to lower band to improve radio link situation
BlindHORSCPThrAbove
PFL; -1215..-25; 1; 0 dBm (not done)
RSCP of if RSCP (Source Cell) ≥ BlindHORSCPThrAbove

source cell*
 RSCPWeight (higher band freq.s) = LaySelWEightRSCP
High Band (F2)
if RSCP (Source Cell) ≤ BlindHORSCPThrBelow

1 2
 RSCPWeight (lower band freq.s) = LaySelWEightRSCP
Low Band ( F1)

RSCP BlindHORSCPThrBelow
PFL; -1215..-25; 1; -126 dBm (not done)
• These parameters can be used to optimize
weight
frequency usage in case of co-located LaySelWeightRSCP
multi-band cells: PFL; 0..10000; 1; 0 (not used)
– UEs close to BTS allocated to a high band
– Low band capacity used for distant UEs RSCPWeight applied only to following events:
• Blind HO in RAB Setup phase
• State transition to Cell_DCH state
* Source cell: best RSCP cell in RACH Intra-freq report


Frequency layer priority - Preference Score (5/5): Load weight
The Load weight is used to avoid IFHO to more loaded cells or direct traffic to balance the
load. The weight is decided based on mean HSDPA power per HSDPA NRT User.
LaySelLowLoadPref HSDPA pwr per Unused HSPA

HSPAloadLevel NRT user [W] DL pwr load lev
PFL; 0 (Disabled), 1 (Enabled)
low (= 1 – 7)?
16 Yes 1
LowLoadPreference = 1 1000 Yes No 16 >Pwr  10 Yes 2

10 >Pwr  4.2 Yes 3
Source or target cell
result or freq. layer CellWeightForHSDPALayering 4.2 >Pwr  2.2 Yes 4
average, depending on WCEL; 0.01..1; 0.01; 1 2.2 >Pwr  1.3 Yes 5
MBLB mode
1.3 >Pwr  0.8
P  * CellWeightForHSDPALayering
Yes 6
HSDPApowerPerUser  NRTHSDPA 0.8 >Pwr  0.5 Yes 7

NumberOfNRTHSDPAusers 0.5 >Pwr  0.23 Yes 8
… … …
„HSPA HSPA overload No 21
load state“
LaySelWeightLoad load unknown or No 22
non HSDPA cell
PFL; 0..10000; 1; 0 (not used)
0 if LaySelWeightLoad = 0
Load
= [ LaySelWeightLoad + (22 – HSPALoadLevel)] ● LoadLoadPreference
weight


Fast Mobility UE
UE detected to be fast moving UE with same mechanism than for URA-PCH (too
many mobility events per time)
• In CELL_DCH state, UE location is known in cell level and handover process can
calculate the velocity of the UE by AS changes needed for the UE.
• UE is fast moving: if number of complete AS changes ≥ FastUEThreshold during
time period FastUEPeriod
FastUEPeriod
WCELRNMOBI; 01..60; 1; 10 s
FastUEThreshold
WCELRNMOBI; 2..60; 1; 3
• UE fast moving  preference score is calculated taking into account PreflayerFastMovUECS #1

only the preferred layer definition for fast moving UE: PFL; 0..16383; 1; -0
• PreflayerFastMovUEPS is used for PS, and
• PreflayerFastMovUECS is used for CS PreflayerFastMovUEPS#2
PFL; 0..16383; 1; -0
• fast moving UE can have only 2 preferred frequencies in priority order
#1defines the preferred layers for fast moving UE with AMR RAB or other CS
AS: Active Set RAB, 0...1 streaming RAB + 0...3 NRT RAB(s) allocated
#2 defines the preferred layers for fast moving UE with 0...3 PS NRT RAB(s) +
0...1 PS streaming RAB allocated. (No AMR RAB or other CS RABs exists)


Preferred Frequency Layer PFL
MBLB introduces new PFL object within the RNC data build.
• Preferred Frequency Layer (PFL) object is pointed to by each WCEL.
RNC • Multiple PFL objects (50) can be defined; so different WCEL can have
different PFL parameter sets.
• However, if there is too many PFLIdentifier assigned to same geographical
WBTS
area, it may cause ping pong due the looping in preference definitions
PFL Parameters
PFLIdentifier • BlindHORSCPThrAbove
WCEL PFL set i • BlindHORSCPThrBelow
RSCP above/ •LaySelLowLoadPref
PFLIdentifier below thresholds
WCEL PFL set j •LaySelWeightLoad
• LaySelWeightBand
PFLIdentifier •LaySelWeightPrefLayer
WCEL Weight for preferred layer, •LaySelWeightRSCP
Band, RSCP & Load
•PFLFastMovUECS
Preferred Frequency layer List •PFLFastMovUEPS
for Fast Moving UEs (CS & PS)
• PFLListxxxAMR
Preferred Frequency layer List • PFLListxxxAMRNRT
for different type of UE • PFLListxxxNRT
• PFLListxxxStr X9
capabilities (MIMO, R99 etc.)

/

MBLB / PFL Example – RSCP Weight
1. UE is moved to higher band when path loss of serving cell is low
• RSCP(S_cell) > BlindHOThrAbove (e.g. -72 dBm). Higher frequency band, which get non-zero
RSCP weight value (LaySelWeightRSCP ≠ 0), are preferred.
2. UE is moved to lower band when pathloss of serving cell is high
• RSCP(S_cell) < BlindHOThrBelow (e.g. -92 dBm). Lower frequency band, which get non-zero
RSCP weight value, are preferred.
Source cell (f2)
WCEL: PFLIdentifier = 5
RSCP of BlindHOThrAbove= -72
source cell* BlindHOThrBelow= -92
LaySelWeightRSCP=100
High Band (F2) LaySelWeightPrefLayer=0
Cell_f1 freq priority =100
LaySelWeightBand=0 Cell_f2 freq priority = 0
RSCP „high”
1 2
band preferred
BlindHORSCPThrAbove
CPICH RSCP
Low Band ( F1) 2
BlindHORSCPThrBelow
1 RSCP „low” band
preferred
cell(f1)
Cell_f1 freq priority =0
RSCPWeight is applied only to the following events: Cell_f2 freq priority =100
• Blind HO in RAB Setup phase
cell(f2)
• State transition to Cell_DCH state

HSPA+ RRM: Contents
• Other features:
– Fast Dormancy

High Speed Cell_FACH (DL): RAN1637

• Included in RU30 application software package – license required
• HW prerequisites: Flexi rel.2 HSFACHVolThrDL
• Can be used if: Flexible RLC Downlink is active WCEL; Infinity, (8, 16, 32, 64, 128,
256, 512, 1024, 2048, 3072, 4096,
Brief Description: 8192, 16384, 24576, 49152) bytes
• This feature enables Fast Cell_PCH to Cell_FACH switching (transition <200ms)

• Feature reduces signaling load on Iub and Iur interfaces
• Reduces code tree occupation
• Saves BTS baseband resources
• Increases number of supported smartphones
• Increases possible throughputs on common channels to 1.80Mbps in DL
DL channel mapping:
BCCH CCCH DCCH DTCH PCCH
Logical channels
Transport channels
BCH FACH FACH FACH HS-DSCH FACH PCH
3GPP Rel7
Physical channels
P-CCPCH S-CCPCH HS-PDSCH S-CCPCH S-CCPCH
High Speed Cell_FACH (DL): With and Without the Feature

RAN1637 Data transmission RAN1637
Not activated Activated
HSDPA only on HSDPA also on

dedicated channels common channels
Common channels
Common channels
Dedicated channels Dedicated channels
Significant setup time reduction
• Cell_PCH to Cell_DCH state change • Cell_PCH to Cell_FACH state change

• Cell Update required • Cell Update not needed
• 600 ms • <200 ms
Data appears in buffer Data appears in buffer
t [ms]
Channel type Transmission/recepti t [ms] Transmission/recepti
Cell switch on in Cell_DCH on in Cell_FACH
Channel
update type switch

HSPA+ RRM: Contents
• Other features:
– Fast Dormancy

High Speed Cell_FACH: RAN1913

HSFACHVolThrDL
WCEL; (0, 8, 16, 32, 64, 128,
• Included in RU40 application software package – license required 256, 512, 1024, 2048, 3072,
4096, 8192, 16384) bytes
• Can be used if both Flexible RLC Downlink and Flexible RLC in Uplink features are active
Brief Description:
• This feature enables Fast Cell_PCH to Cell_FACH switching (transition <100ms)
• Feature enhances High Speed Cell_FACH in DL
• Increases possible throughputs on common channels to 1.45Mbps in UL
UL channel mapping:
CCCH DCCH DTCH

Logical channels
Transport channels RACH E-DCH

3GPP Rel8
Physical channels
PRACH E-DPDCH

High Speed Cell_FACH: With and Without the Feature

RAN1913 Data transmission RAN1913
Not activated Activated
HSPA only on HSPA also on

dedicated channels common channels
Common channels
Common channels
Dedicated channels Dedicated channels
Significant setup time reduction
• Cell_PCH to Cell_DCH state change • Cell_PCH to Cell_FACH state change

• Cell Update required • Cell Update not needed
• 600 ms • <100 ms
Data appears in buffer Data appears in buffer
t [ms]
Channel type Transmission/recepti t [ms] Transmission/recepti
Cell switch on in Cell_DCH on in Cell_FACH
Channel
update type switch

HSPA+ RRM: Contents
• Other features
• Appendix:
– Dynamic HSDPA BLER (RAN 2171)

RAN 2171: Dynamic HSDPA BLER
RU20 uses HSDPA BLER Targets of 10 % & 25 %:

– 10 % is applied in static channel conditions
– 25 % is applied in fading channel conditions
– these BLER targets are not configurable & independent CQI (high or low)
RU30 introduces Dynamic HSDPA BLER
•allows the use of HSDPA BLER Targets of 2 %, 6 %, 10 % & 25 %
•the Ru30 BLER Target is a function of the:
 the channel conditions (static vs fading)
 the CQI
•Thresholds defining high, medium & low CQI ranges are configurable
•Upper & lower BLER target limits for each CQI range are configurable
•Dynamic HSDPA BLER is a basic software feature; it requires no license
•The feature is installed as part of the BTS software and is always enabled
•Fallback to RU20 behavior: configuring BLER Target parameter set appropriately
•Parameters associated with this feature are Node B commissioning parameters rather than
RNC databuild parameters
•Motivation/Benefits: cell & end-user HSDPA throughputs improved by up to 8 %

HSDPA BLER as function of CQI
• The BLER Target is a function of the variance of the The look-up table below is
defined within the Node B
reported CQI
• A low variance indicates that the UE is experiencing static Variance of BLER Channel
channel conditions: Low BLER target is appropriate Reported CQI Target Type
• A high variance indicates that the UE is experiencing fading 0 to 1 2% Static
channel conditions: High BLER target is appropriate 1 to 1.5 6% Fading
• Values within the table can be overwritten by defining upper & 1.5 to 2.5 10 %
lower BLER target limits within the RNC databuild >2.5 25 %
• The RNC databuild also allows the BLER Target to be

defined as a function of the CQI, e.g. smaller BLER Targets
can be defined for higher CQI values
Variance of Reported CQI Low CQI Range Medium CQI Range High QI Range
0 to 1 BLERLOW,1 BLERMED,1 BLERHIGH,1
1 to 1.5 BLERLOW,2 BLERMED,2 BLERHIGH,2
1.5 to 2.5 BLERLOW,3 BLERMED,3 BLERHIGH,3
>2.5 BLERLOW,4 BLERMED,4 BLERHIGH,4

Dynamic HSDPA BLER: Upper & lower BLER Target limits

The table below presents the RNC databuild parameters used to define:
• the set of 3 CQI ranges
• the upper & lower BLER Target limits for each CQI range
Condition for each CQI range Upper & Lower BLER
Target Limits*
OK
Low CQI Reported CQI < medCQIRangeStart targetBLERLowCQIStaCh
medCQIRangeStart Range targetBLERLowCQIFadCh
BTSSCW; 1..30; 1; 12
Medium CQI medCQIRangeStart ≤ Reported CQI < targetBLERMedCQIStaCh
highCQIRangeStart Range highCQIRangeStart targetBLERMedCQIFadCh
BTSSCW; 1..30; 1; 25
High CQI highCQIRangeStart ≤ Reported CQI targetBLERHighCQIStaCh
OK Range targetBLERHighCQIFadCh
OK
OK targetBLERLowCQIStaCh targetBLERLowCQIFadCh Static Channel or
BTSSCW; 2; 6; 10; 25; 6% BTSSCW; 2; 6; 10; 25; 25% Fading Channel
conditions
OK targetBLERMedCQIStaCh targetBLERMedCQIFadCh OK
BTSSCW; 2; 6; 10; 25; 2% BTSSCW; 2; 6; 10; 25; 25%
OK targetBLERHighCQIStaCh targetBLERHighCQIFadCh OK
* All parameters are Node B BTSSCW; 2; 6; 10; 25; 2% BTSSCW; 2; 6; 10; 25; 25%
commissioning parameters

Dynamic HSDPA BLER: Default parameter set
• The default parameter set generates the look-up table shown below
Variance of Low Medium High

Reported CQI CQI Range CQI Range CQI Range
0 to 1 6% 2% 2%
1 to 1.5 6% 6% 6%
1.5 to 2.5 10 % 10 % 10 %
>2.5 25 % 25 % 25 %
• Configuration for fallback to RU20 behaviour is shown below
Variance of Low Medium High

Reported CQI CQI Range CQI Range CQI Range
0 to 1 10 % 10 % 10 %
1 to 1.5 10 % 10 % 10 %
1.5 to 2.5 10 % 10 % 10 %
>2.5 25 % 25 % 25 %

Vdocuments - MX Hspa-Features

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vdocuments - MX Hspa-Features

Uploaded by

Copyright:

Available Formats

Course Content

Radio Resource Management Overview

1 © Nokia Siemens Networks RN3167BEN30GLA1

HSPA+ features & parameters:

At the end of the module you will be able to:

2 © Nokia Siemens Networks RN3167BEN30GLA1

HSPA+ RRM: Contents

HSPA+ RRM: Contents

4 © Nokia Siemens Networks RN3167BEN30GLA1

Multicarrier HSPA Evolution in Release 9/10 & beyond

• Rel. 8 brought DC-HSDPA, Rel. 9 defined DC-HSUPA

5 © Nokia Siemens Networks RN3167BEN30GLA1

HSPA Data Rate Evolution

6 © Nokia Siemens Networks RN3167BEN30GLA1

HSPA+ RRM: Contents

7 © Nokia Siemens Networks RN3167BEN30GLA1

64QAM: RAN1643 Modulation Coding rate 15 codes

64QAM QPSK 2/4 3.6 Mbps

6 bits/symbol 3/4 5.4 Mbps

2/4 7.2 Mbps

16QAM 3/4 10.8 Mbps

4/4 14.4 Mbps

3/4 16.2 Mbps

64QAM 5/6 18.0 Mbps

4/4 21.6 Mbps

8 © Nokia Siemens Networks RN3167BEN30GLA1

64QAM: Channel Quality Requirements

2/4 3/4 5/6 4/4

CQI > 15 CQI > 25

0 Mbps 10 Mbps 14 Mbps 21 Mbps

9 © Nokia Siemens Networks RN3167BEN30GLA1

64QAM: CQI TB Size # codes Modulation  CQI TB Size # codes Modulation 

2 173 1 QPSK 0 2 176 1 QPSK 0

3 233 1 QPSK 0 3 232 1 QPSK 0

4 317 1 QPSK 0 4 320 1 QPSK 0

5 377 1 QPSK 0 5 376 1 QPSK 0

Annex Table 7d 7 650 2 QPSK 0 7 648 2 QPSK 0

Cat 10 UE 8 792 2 QPSK 0 8 792 2 QPSK 0

9 931 2 QPSK 0 9 928 2 QPSK 0

10 1262 3 QPSK 0 10 1264 3 QPSK 0

11 1483 3 QPSK 0 11 1488 3 QPSK 0

12 1742 3 QPSK 0 12 1744 3 QPSK 0

13 2279 4 QPSK 0 13 2288 4 QPSK 0

14 2583 4 QPSK 0 14 2592 4 QPSK 0

Annex Table 7f 16 3565 5 16-QAM 0 16 3576 5 16-QAM 0

Cat 13 UE 17 4189 5 16-QAM 0 17 4200 5 16-QAM 0

18 4664 5 16-QAM 0 18 4672 5 16-QAM 0

19 5287 5 16-QAM 0 19 5296 5 16-QAM 0

20 5887 5 16-QAM 0 20 5896 5 16-QAM 0

21 6554 5 16-QAM 0 21 6568 5 16-QAM 0

22 7168 5 16-QAM 0 22 7184 5 16-QAM 0

23 9719 7 16-QAM 0 23 9736 7 16-QAM 0

24 11418 8 16-QAM 0 24 11432 8 16-QAM 0

25 14411 10 16-QAM 0 25 14424 10 16-QAM 0

26 17237 12 16-QAM 0 26 15776 10 64-QAM 0

10 © Nokia Siemens Networks RN3167BEN30GLA1

64QAM: Link Simulations

11 © Nokia Siemens Networks RN3167BEN30GLA1

12 © Nokia Siemens Networks RN3167BEN30GLA1

HSPA+ RRM: Contents

13 © Nokia Siemens Networks RN3167BEN30GLA1

MIMO Principle (1/2)

14 © Nokia Siemens Networks RN3167BEN30GLA1