34386 64 QAM for HSDPA

Agenda

1. Feature Overview
2. Activation Strategy

3. Feature Assessment
1
Feature Overview

3/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010 All Rights Reserved © Alcatel-Lucent 2008, XXXXX
Feature overview

In UA6.0 or with 64QAM disabled: The scheduler is able to use QPSK and 16QAM
modulation to transmit the HS-DSCH
In UA7.0 and with 64QAM enabled: The scheduler can also use the 64QAM to transmit the
HS-DSCH

64-QAM provides 6 bits per symbol compared to 4 bits for the 16QAM:
Q

16-QAM 64-QAM

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

Goal of 64QAM feature:

- 64QAM allows higher peak throughputs in very good radio conditions:

At physical layer: 21.6 Mbps with 64QAM instead of 14.4 Mbps with 16QAM

- 64QAM can also be used in code limited situations to increase the data rate for users in
good radio conditions.
Feature overview

Impact of 64QAM feature on the system:

1- New UE categories supporting the 64QAM are introduced.

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

New UE categories have been introduced to support the 64QAM :

- 13 and 14 (64-QAM only),
- 17 and 18 (64-QAM or MIMO)

These UE categories are MAC-ehs capable

MIMO is not supported in UA7

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

 Feature description : 2- New CQI tables
To support 64QAM, new CQI tables have been introduced:
Category Used CQI mapping table
64QAM/MIMO not 64QAM MIMO configured
configured configured In case of type B or single In case of dual
transport block type A transport block
CQI reports type A CQI
reports
1-6 A N/A
7 and 8 B N/A
9 C N/A
10 D N/A
11 and 12 E N/A
13 C F N/A
14 D G N/A
15 C N/A C H
16 D N/A D I
17 C F C H
18 D G D I

These CQI mapping tables are used to translate the reported CQI into a recommended TFRC
(TBS, modulation, number of HS-PDSCH codes)
The new tables allow the 64QAM capable UE to propose the usage of TFRC including 64QAM.
With a high CQI value (good channel quality), the UE can indicate that 64QAM can be used.
The CQI gives an indication to the Node B of the channel quality. It corresponds to an evaluation done by the UE of how many bytes (transport block
size) can be sent on the HSDSCH with no more than 10% BLER on first HARQ transmission, given the channel quality. The mapping of the CQI
value on a transport block size is given in 25.214 section 6A.2.3, and depends whether 64-QAM or MIMO are configured for the call (new tables F,
G, H and I have been defined for 64-QAM and MIMO):
 Feature description : 3- New LUT

New LUT are used to allow scheduler selecting the higher TB size for 64QAM modulation
format.

TFRC selection With 64QAM

larger TB size
45000
can be selected
40000 at high CQI
35000
selected transport block size

30000

25000

20000

15000

10000

5000

0
0 5 10 15 20 25 30

actual CQI

Cat.14 Cat.10
 Feature description : 2- New LUT (Maximum Transport Block Size)
1 In UA7.0, the maximum Transport Block Size can be higher thanks to mac-ehs and 64QAM.
Note that the max TBS used by the xCem is lower than the max capability of the ue category defined by the
3GPP in order to maximize the applicative throughput (trade-off between higher TBS and lower Bler).
With Mac-ehs, max applied TBS is:
2- either a little bit lower because of the optimization of the number of
padding bits in the mac-hs frame (higher throughput)
3- or higher in order the increase the throughput
336 656 mac-ehs mac-ehs + 64QAM

45000 1

39984
40000

35280
35000
3

27464

27464
26490
26504
Max applied TBS (bits)

30000

23792
2
25000
20251
19891
19904

20000
14155
13904
13940

15000
7298
7168

7152

10000

3576
3440
3319
5000

0
1 to 6 7 to 8 9 10 11 to 12 13 14
UE Category
 Feature description : 4- New HS-SCCH format for 64QAM
The mobile receives a HS-SCCH subframe containing control information among which:
• Channelization-code-set information (7 bits – slot #0 of subframe)
• 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 H-RNTI
• Modulation scheme information (1 bit – slot #0 of subframe):
value 0 is QPSK and
value 1 is 16QAM or 64QAM
 If 64QAM has been configured for the HS-DSCH, the modulation scheme information bit
can only tell the UE whether QPSK is used (value 0) or not (value 1). The choice
between 16QAM and 64QAM is known from the last bit of channelization code set
information.
 Feature description : 5- New Slot format for the HS-PDSCH
A HS-PDSCH may use QPSK, 16QAM or 64QAM modulation symbols.
In the figure, M is the number of bits per modulation symbols:
M=2 for QPSK,
M=4 for 16QAM and
M=6 for 64QAM

The slot formats are shown in the table: Slot format #i Channel Bit Channel Symbol SF Bits/ HS-DSCH Bits/ Ndata
Rate (kbps) Rate (ksps) subframe Slot
0(QPSK) 480 240 16 960 320 320
1(16QAM) 960 240 16 1920 640 640
2(64QAM) 1440 240 16 2880 960 960

The theoretical peak data rate at physical layer is :

 21.6 Mbps = 2880 x 15 codes / 2ms with 64QAM instead of
 14.4 Mbps = 1920 x 15 codes / 2ms with 16QAM
 Feature description : 6- Mac-ehs configuration

For more details concerning the Mac-ehs configuration,

see the FSM “UA7.0_HSDPA_34388_FlexibleRLCandMac-ehs_FSM”
Feature configuration
The 64QAM modulation is configured if the following conditions are fulfilled:

1- The NodeB is 64QAM capable:

The NodeB indicates to the RNC its 64QAM capability through the “SixtyfourQAM DL Capability” IE in the
NBAP “Audit Response” or “Resource Status Indication” messages
2- The UE is 64QAM capable:
The UE informs the RNC of its capabilities in the “RRC Connection Setup Complete” message:
- “MAC-ehs support” IE concerning the support of the MAC-ehs/RLC flexible size feature (3GPP R7).
- “HS-DSCH physical layer category extension” IE corresponding to the HS-DSCH category supported by
the UE when Mac-ehs is configured (If the Mac-ehs is not configured, the SRNC doesn’t use this IE
but the HS-DSCH physical layer category IE, corresponding to the HS-DSCH category supported by
the UE when MAC-ehs is not configured)
3- The NodeB is allowed to used the 64QAM:
RadioAccessService.isDl64QamOnRncAllowed = True
FDDCell.isDl64QamAllowed = True
Mac-ehs enabled
4- The UE category is allowed to used the 64QAM:
HsdpaRncConf. is64QamAllowedForUeCategory = 1 for all the UE categories supporting 64QAM,
that is to say 13,14,17,18

If all these conditions are fulfilled, then the NodeB will send the new HS-SCCH to inform the UE of the
modulation used (QPSK, 16QAM or 64QAM) depending on the TFRC selection algorithm
 Mobility & Iur
Mobility:
xCem  iCem:
Mac-ehs and then 64 QAM is only supported by xCEM
In case of call mobility toward a cell where HSDPA is managed by iCEM, a reconfiguration
disabling 64QAM is triggered and vice versa.

On iCEM UE category 13 and 17 are handled as category 9, UE category 14 and 18 are handled
as category 10.

xCem  xCem
Mobility of a 64-QAM capable UE between two 64-QAM capable serving cell is supported.

Iur:
64 QAM is not supported over Iur (because mac-ehs is not supported over Iur) .
OMC-R Model

New parameters in UA7

Not used

Node
RNC FDDCell
B
isDl64QamAllowed

RadioAccessService HsdpaRncConf
isDl64QamOnRncAllowed is64QamAllowedForUeCategory

UmtsNeighbouring RemoteFDDCell
isDl64QamAllowed
NeighbouringRNC
isIurDlQam64Allowed
isIncoming3Gto3GWithIur64QAMAllowed
3
Activation Strategy

17/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010

 Activation

Activation of Layer 2 Improvement feature (before 64QAM activation)

 RadioAccessService.isMacehsAllowed = TRUE
 FddCell.isMacehsAllowed = TRUE
Activation at RNC level
 RadioAccessService. isDl64QamOnRncAllowed = TRUE
 HsdpaRncConf. is64QamAllowedForUeCategory = 1 for all the UE categories
supporting 64QAM, that is to say 13,14,17,18
Activation at FDDCell level
 FDDCell.isDl64QamAllowed = TRUE

The recommendation is to enable the 64QAM feature everywhere since no degradation is

expected.
Nevertheless, we can keep in mind that the usage of Layer 2 Improvement and 64QAM
can lead to an increase of the CPU consumption of the RNC packet server. If the CPU
consumption becomes critical, the recommendation should to use DCPS instead of PSFP
 Pre-requisites
The following pre-requisites are needed in order to be able to use 64QAM
Domain Pre-requisite Comment

1- Feature 34386 "34386 64 QAM for RadioAccessService / isDl64QamOnRncAllowed = TRUE

HSDPA " enabled HsdpaRncConf / is64QamAllowedForUeCategory = 1 for Cat. 13,14,17,18
FDDCell / isDl64QamAllowed = TRUE

1- Feature 34388 "L2 improvements : flexible
RLC & MAC-ehs" enabled
64QAM can be configured only if MAC-ehs is configured first
MAC-ehs is a pre-requisite for 64-QAM (MAC-ehs is an enhancement of MAC-hs protocol that allows
higher throughputs thanks to flexible RLC PDU size (and thus bigger), relaxing UE processing
constraints and RLC window blocking issues). The events leading to de-configure MAC-ehs shall also
lead to de-configure 64QAM.

RadioAccessService / isMacehsAllowed = TRUE

FddCell / isMacehsAllowed = TRUE

2- Software RNS upgraded in UA7

3- Hardware 3GPP R7 UE

3- Hardware xCEM with iBTS and UCUIII with

oneBTS
 Pre-requisites
The following pre-requisites are needed in order to reach the maximum throughput with
64QAM
Domain Pre-requisite Comment

1- Feature UTRAN Licensing feature (34454)

configured to allow max throughput

2- Software SGSN R6 and GGSN R6 No need to have SGSN R7 or GGSN R7

3- Hardware Hybrid Iub or Native IP Iub (xCcm on In order to achieve high throughput, ATM BW (8 E1s) is not sufficient and Hybrid Iub is
NodeB and GIGe on RNC needed) recommended.

3- Hardware RNC Packet server : DCPS or PSFP DCPS (Dual Core Packet Server) allows to support higher throughput than PSFS in the RNC
but nevertheless PSFP is enough (PSFP can support up to 2 R7 ue using 64QAM at the max
throughput in 2 different BTS with the same PMC-RAB (worst case))

4- Setting Maximum number of HS-PDSCH codes Fair Sharing enabled (Dyn codes mgt part):
(15) BTSEquipment / hsdpaCodeTreeManagementActivation = True
FDDCell / isHsxpaR99ResourcesSharingOnCellAllowed = True

1 SF16 used for ccc including multiple S-CCPCH, HS-SCCH and DL HSUPA codes (for ex: 1
S-CCPCH + 2 HS-SCCH + 1 E-AGCH + 1 E-HICH/E-RGCH)

4- Setting Avoid PA power saturation PA power saturation leads to a unstable CQI at 30 impacting the throughput.
A "backoff power" of -2dB is yet implemented to avoid this issue by reducing the allocated
power (when coding rate is higher than 0.88).
If needed, maxHspaPowerOffset can also be changed to reduce the available power
(PmaxHsdpa = Pcell - maxHspaPowerOffset)

4- Setting UL bearer allowing: HSUPA with 10ms TTI (2ms TTI is not mandatory)
- throughput high enough to or UL 384 (if rab adaptation is disabled) with minSirTargetHsdpa = 4.7dB
acknownledge the high DL throughput
- UL BLER around 0%
 Pre-requisites
The following pre-requisites are needed in order to reach the maximum throughput with
64QAM
Domain Pre-requisite Comment

4- Setting Correct L2I setting RadioAccessService / HsdpaRncConf / DlRlcQueueSizeForUeCat = 512 RLC SDU for Cat.14
RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode / prohibitedStatusTimer = 10ms

4- Setting Correct ATM setting RadioAccessService/ HsdpaRncConf / minimumHsdschCreditPerTtiInBytes = 2296

RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1520
Maximum value for txQueueLimit of Access Node according to the ATM card

4- Setting Correct Hybrid Iub setting RadioAccessService/ HsdpaRncConf / minimumHsdschCreditPerTtiInBytes = 1456

RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1472

4- Setting Correct Iub congestion If not correctly set, the throughput can fluctuate very strongly and we couldn’t get more than 2 or 3Mbps max
management setting (some time less than 1M)

RNC/ RNCEquipment / INode / EM / RncIn / Cm / activation = discardAndBackPressure

RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolCellColor = enabled
RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolQosBackPressureThreshold = 0,0,95,95
RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolQosDiscardThreshold = 0,0,350,500
RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa congDRTAllowed = enabled (no impact on
performances
RNC/ RNCEquipment / INode / EM / RncIn / Cm / Hsdpa congFSNAllowed = enabled (no impact on
performances)

5- RF High CQI Throughput becomes higher for Cat.14 compared to Cat.10 when CQI > 23

6- Traffic Low cell load In order to have no resource limitation

 Pre-requisites
The following pre-requisites are needed in order to reach the maximum throughput with
64QAM
Domain Pre-requisite Comment

7- Core Correct Ethernet switch (PSAX, Omniswitch)

configuration

7- Core Correct FTP server configuration If the FTP server has a limited configuration and could not be changed, high throughput could be
achieved by establishing 2 (or more) FTP sessions in parallel

7- Core Correct GGSN configuration In order to avoid any DL throughput limitation

7- Core Correct SGSN configuration In order to avoid any DL throughput limitation

7- Core Correct User Equipment and PC client In order to avoid any DL throughput limitation
configuration

7- Core Correct VPN and Firewall configuration In order to avoid any DL throughput limitation

7- Core No Maximum Bit Rate (MBR) limitation Ranap MBR higher than the max throughput and Iu Source Conformance disabled (If Source
Conformance is On, the RNC will limit the HSDPA throughput to
min(MBR;maximumTokenGenerationRate))
4
Feature Assessment

23/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010

4.1 Simulation and Lab results

24/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010

Expected behavior
64 QAM can bring gains in 2 cases:
 Without codes limitation, for a user in very good RF conditions in order to reach the maximum
throughput (up to 20Mbit/s @mac-hs level for cat. 14) leading to increase the user throughput and
then the cell throughput
 With a code limited situation, the 64QAM modulation can be used, instead of QPSK or 16QAM, to
increase the data rate for users in very good radio condition

Depending of the UE Category distribution, the following behavior can be observed on field:
 Increase of 64QAM usage, decrease of 16QAM usage
 Increase of the nb of HS-PDSCH codes used and HSDPA throughput
 Power could be reduced for very high CQI : allocated power is reduced by 2dB (backoff power) when
the coding rate is higher than 0.88 in order to avoid EVM issue
Expected gain - Simulation
In macro layer assuming advanced receiver type 3 (equalization and receive diversity) on
the UE side, it is estimated that around 18% of the users can use the 64QAM in order to
increase their throughput. On average 3 to 5% cell throughput gain could be expected.
For indoor coverage the SNR distribution is typically much more favorable and could lead
to have around 45% of the users eligible to 64QAM allowing an increase of the cell
throughput as shown in the chart below.

Note that those performance estimations are

very sensitive to the UE receiver implementation.
Expected gain - Simulation
Single micro-cell scenario, advanced receivers required

10000

9000
8000
7000
throughput/ kbps

6000

5000

4000
3000
2000
1000

0
Cat 10/ 15 users Cat 14/ 15 users

average user throughput 95% user throughput ave. cell throughput

Without 64-QAM With 64-QAM Gain

Average Cell Throughput 6.9 Mbit/s 7.65 Mbit/s 10.7%

95%-tile Throughput 7.1 Mbit/s 8.7 Mbit/s 22.5%

 UIIV results : FTP throughput for UE Cat.14
1 UE cat 14 - AWGN
FTP Tpt vs CQI
20000

18000
Max Tpt: 18.6Mbps @ FTP

16000 CN Nortel,
Cabled environment with fading simulator,
14000 QCT UE,
FTP Throughput (kbps) 15 HS-PDSCH codes
12000

10000

8000

6000 AWGN

PA3
4000

PB3
2000

0
4 6 8 10 12 14 16 18 20 22 24 26 28 30
CQI

FTP throughput decreases very fast with CQI:

 15.7 Mbit/s at CQI 29,
 13.8 Mbit/s at CQI 28, Extracted from UMT/RAN/DJD/029327
UA07 HSPA Radio Performance Report -
 12.3 Mbit/s at CQI 27 UIIV Velizy team.
UIIV results : UE Category comparison

Ue category comparison - 1 UE
Flexible RLC - AWGN

18000

16000
CAT14

14000 CAT10

CAT9
FTP Throughput (kbps)

12000

10000
,
8000
QCT UE,
15 HS-PDSCH codes
6000

4000

2000

0
4 6 8 10 12 14 16 18 20 22 24 26 28 30
CQI

64 QAM (Cat 14) provides higher throughput than

16 QAM (Cat10) above CQI 25 Extracted from UMT/RAN/DJD/029327
UA07 HSPA Radio Performance Report -
UIIV Velizy team.
 UIIV results : UE Category comparison (1UE – PA3)

Ue category comparison - 1 UE
Flexible RLC - PA3
12000

CAT14
10000
CAT10

CAT9

8000
FTP Throughput (kbps)

CN Nortel,
Cabled environment with fading simulator,
6000 QCT UE,
15 HS-PDSCH codes

4000

2000

0
4 6 8 10 12 14 16 18 20 22 24 26 28
CQI

64 QAM (Cat 14) provides higher throughput than Extracted from UMT/RAN/DJD/029327
16 QAM (Cat10) above CQI 23 in PA3 UA07 HSPA Radio Performance Report -
UIIV Velizy team.
4.2 Fields results (summary)

31/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010

 Field results – Static tests

Customer #1 Test conditions:

- 6 parallel FTP by Filezilla + 2 File Dld from Microsoft Server + Video Streaming (YouTube)
- Live condition (with no traffic)
- UTRAN UA7

Average FTP Throughput Maximum FTP throughput

Test 1 12.65 Mbps 14.62 Mbps

Test 2 13.20 Mbps 16.40 Mbps

Test 3 13.37 Mbps 14.31 Mbps

Average 13.1 Mbps 15.1 Mbps

No information concerning the CQI

 but according to the Lab results, the max CQI seems to be around 28-29 (very good RF
conditions)
 Field results – Static tests

Customer #2 Test conditions:

- Customer internal tool performing 1 FTP DL Transfer of a 2 Mbytes file size
- Also tested with Filezilla (2 Filezilla in parallel in order not to relax the pace, 10 files
downloaded in parallel from each Filezilla)
- Live condition (with no traffic)
- Indoor BTS
- Utran UA7.1

Average FTP Throughput

Average 18 Mbps

CQI 29-30 ; RSCP -70dBm

 Field results – Static tests

Customer #3 Test conditions:

- 15min endurance test
- Sierra data card.
- Outdoor STSR1
- MaxTxPower 43dBm, CPICH Power 33dBm
- Proportional Troughput, MAC-hs BLER Target 20%, Measurement Power Offset 8dB
- EDCH TTI2ms SRB over EDCH On
- Utran UA7.1

Average FTP Throughput

(DU Meter)

Average 19.38 Mbps

 Field results – Static tests

Customer #4 Test conditions:

- Tool for measurement : DU Meter, TEMS traces
- UE : Commercial datacard (chipset Huawei)
- Method : Parallel transfer of 10 300Mb-files
- Radio Conditions : CQI 30 reached briefly.
- STSR2 paRatio 50%
- Outdoor
- maxPowerAmplification = max60W,
- pCpichPower = 31 dB radiated at antenna connector (~%10 of maxTxPower)
- Measurement Power offset = 8dB
- see details in the section 4.4

Average FTP Throughput

(DU Meter)

Average 18.10 Mbps

 www.alcatel-lucent.com
www.alcatel-lucent.com

36/75 | FSM UA7.0 - 34386 64 QAM for HSDPA | July 2010