UA7.1.2 81204 DualCell HSDPA VDF Workshop Final

UA7.1.2 81204 Dual Cell HSDPA Operation

VDF Workshop

Priscille Cochois

TIS/ONE – Performance

July 2010

Agenda

1. Feature Description

2. Upgrade Procedure

3. Activation Strategy

4. Feature Assessment

5 | 81204 – Dual Cell HSDPA Operation | July 2010 All Rights Reserved © Alcatel-Lucent 2010, XXXXX

Feature Description

1


One UE can be scheduled simultaneously on two 5MHZ adjacent carriers by this

3GPP Rel’ 8 feature

Benefits:

Two data streams can then be received on the UE side doubling the data

rate even in cell edge conditions

On medium load, Dual Cell HSDPA Operation provides the efficient load

balancing mechanism, as the scheduler can choose on a per 2msec TTI basis

the least loaded carrier to maximize the system performance

Feature Description

Feature Value and Benefits

Dual-Cell HSDPA

Node-B

F1

UEF2

DLDL

5 MHz 5 MHz

UL

5 MHz

2.1 GHzUL

UTRAN configures one of the carriers as the serving cell for the uplink


Feature Description

Feature Value and Benefits

� Significant boost in theoretical peak rate (maximum 42 Mbps @ L1) without

relying on complex receiver types

� Enabler for very high peak rate demonstration on field (does not require specific

propagation condition with spatial de-correlation properties like MIMO does)

� Higher user data rate across the whole cell area including cell edge (x2)

� No need for very high SNR as for MIMO and 64QAM

� Significant improvement in HSDPA carrier load balancing, i.e. radio resource

usage efficiency

� iMCTA based Load balancing mechanisms are not efficient in matching the available

UTRAN air-interface capacity to the dynamically changing load generated by bursty PS

traffic

� Carrier aggregation is backward compatible with R7/R6/R5 and R99 devices

and deployed Node B HW assets can be reused

� Applicable to all installed Node B with 2 “adjacent” carriers in same frequency bands


Feature Description

Dual Cell HSDPA Operation : Characteristics (1/6)

� Dual Cell HSDPA Operation only applies to downlink HS-DSCH

� Uplink traffic is carried in one carrier only

� Two cells are on the same NodeB, covering the same sector

� Two cells operate in the same frequency band and are on adjacent carriers

� Two cells operate with the single TX antenna

� One cell which is Anchor carrier (serving cell) for one Rel’8 UE, can be

Supplementary carrier (secondary serving cell ) for another Rel’8 UE at the

same time

� In UA7.1.2 due to lack of support for MIMO in ALU UTRAN, only DC call is

allowed by UTRAN even if UE is capable of supporting either MIMO or DC

� 3GPP Compliance: Rel’8, June 2009 + essential corrections in Sept 2009

(limited to NBAP and RRC protocols support in UA7.1.2)


Feature Description


UE

Dual Cell Operation Involved L1 Channels


Feature Description


� Supported channel cards are xCEM and eCEM in UA7.1.x time frame

� Support for this feature on iCEM is not provided

� Common priority queue belonging to the anchor carrier (and MAC-ehs entity)

for both carriers

� Separate MAC-ehs PDUs for different carriers

� Independent scheduler and HARQ entity for each carrier/ cell

� Max throughput achieved only with Hybrid /Native IP on Iub (x/eCCM with

MDA-GE interface) but ATM (iCCM) also supported

� Only supported with E-DCH in UL with following RAB combinations

� PS I/B (E-DCH/HS-DSCH) + SRB on DCH (for E-DCH 10msec/ 2msec TTI)

� PS I/B (E-DCH/HS-DSCH) + SRB on E-DCH (for E-DCH 2msec TTI Cat 6 UE)


Feature Description


� Two schedulers are aware if the GBR is being achieved for a given user by

using the aggregate throughput that is being served for that user but

resulting user ranking is performed on individual cell basis

� Following HsdschServiceParameterSet parameters (belonging to serving cell)

are shared by both schedulers (corresponding to SPI sent by RNC):

� serviceBFactor, serviceFilterFactor, serviceHighRate, serviceKFactor,

serviceLowRate, serviceMaxDelay, serviceMaxRate, serviceMinRate

� Even though both schedulers are independent, ALU recommends to

configure same scheduler type (HsdpaSchedulerAlgorithmXcem) and QoS

parameters between the two cells

� NBAP common measurements (including HS-DSCH Required Power) are

reported independently for each cell

� Both schedulers shall not approach the common priority queue at the same

time (to avoid duplication of TB information on air) but can do so in same

TTI


Feature Description


Priority Queue

MAC-ehs PDU Assembly

MAC-d PDUs

HARQ Entity A

HARQ Entity B

MAC-ehsPDU A

MAC-ehsPDU B

To Transport Sub-layer Processing

Node B

Reordering Buffer

HARQ Entity A

HARQ Entity B

From Transport Sub-layer Processing

UE


Feature Description


Common reordering buffer across multiple carriers (as per 3GPP TS25.321

v8.10.0 §9.1.4)

� HSDPA Dual Cell doesn’t change the 3GPP limit of maximum 26 MAC-d PDUs in

one MAC-ehs PDU (per TTI)

� In order to handle this limitation, each HSDPA scheduler shall not send more

than 13 reordering SDUs in a Mac-ehs PDU in case of dual cell operation

� Depending on the HS-DSCH physical layer category, the maximum number of

MAC-ehs PDUs that can be transmitted in a TTI per UE is one or two … two for

DC capable UEs (Cat. 21-24) and one for all non-DC capable UEs (Cat. 1-20)

� The reordering SDUs in one TTI can belong to different priority queues (at most

3 priority queues). If reordering SDUs in one TTI belong to more than 3 priority

queues or are in greater number than 26, then UE behaviour is unspecified

� ALU iBTS implementation allows only up to 1 priority queue per TTI

� The MAC-ehs header is of variable size as per 3GPP


Feature Description

Dual Cell HSDPA Operation : Flexible RLC

� Dual Cell HSDPA operation adds a new flag in UA7.1.2 for flexible RLC and

MAC-ehs capability implemented by UA7.0 feature PM34388

� isLiForFlexibleRlcActivated

This flag enables / disables the configuration of 15 bits LI for flexible RLC:

If (isLiForFlexibleRlcActivated == TRUE)

RNC uses the value of (macEhsMaximumPduSizePsIb / Str) to determine the required

LI (i.e. 7 vs 15 bits). LI will be set to 15 bits for RLC PDU size over 126 bytes

Else

RNC RLC does not support LI and 7Bit is used to configure the UE RLC LI only (UA 7.0

behavior)

� When isLiForFlexibleRlcActivated == TRUE, the flexible RLC feature makes use

of the LI to support the concatenation of multiple RLC SDUs per PDU. A

positive effect is that the resulting RLC PDU would tend to be closer to the

optimum RLC PDU size (i.e. macEhsMaximumPduSizePsIb)


Feature Description

Dual Cell HSDPA Operation : When UE is configured to support Dual Cell Operation

� It can be served dynamically (on per TTI granularity) on either or both of the

allocated cells at the same time

� The UE shall simultaneously monitor HS-SCCH sets in both serving and

secondary serving HS-DSCH cells, and receive HS-DSCH if it is scheduled in

either or both at the same time.

� The maximum size of the HS-SCCH set in a secondary serving HS-DSCH cell is 4

and the maximum number of HS-SCCHs monitored by the UE across both anchor

HS-DSCH cell and supplementary HS-DSCH cell is 6 as per 3GPP

� It should have the capability to feedback ACK/NACK and CQI for both the cells

simultaneously via modified encoding on HS-DPCCH in UL

� Legacy mobility procedures are supported based on the serving cell only. The

secondary serving HS-DSCH cell does not belong to the active set of the UE

� DL compressed mode applies to both cells in the same way. So both HSDPA

schedulers obey same DL CM pattern to create TX gaps at same time


Feature Description

Dual Cell HSDPA Operation : HS-DPCCH

� HS-DPCCH is configured only on one of the carriers in UL

� CQI/ACK/NACK for both carriers must be transmitted on this HS-DPCCH channel

� CQI reporting mapped on 20 bits of HS-DPCCH per TTI

� A special bit mapping is used to combine the CQI from both carriers into 20 bits

� ACK/NACK signaling mapped on 10 bits of HS-DPCCH per TTI

� Uses 10 code words to signal all combinations of ACK, NACK and “no transmission” for

the two carriers (see next slide)

CQI

Subframe #0 Subframe #i Subframe #4

1 radio frame = 10ms

Tslot = 2560 chips

= 10 bits

ACK/NACK

2.Tslot = 5120 chips

= 20 bits


Feature Description

Dual Cell HSDPA Operation : ACK / NACK Encoding

The composite HARQ acknowledgement message to be transmitted

shall be coded to 10 bits as shown in Table below

HARQ-ACK message to be transmitted

w0 w1 w2 w3 w4 w5 w6 w7 w8 w9

HARQ-ACK when UE detects a single scheduled transport block on the serving HS-DSCH

cell

ACK 1 1 1 1 1 1 1 1 1 1

NACK 0 0 0 0 0 0 0 0 0 0

HARQ-ACK when UE detects a single scheduled transport block on the secondary serving HS-DSCH cell

ACK 1 1 1 1 1 0 0 0 0 0 NACK 0 0 0 0 0 1 1 1 1 1

HARQ-ACK when UE detects a single scheduled transport block on each of the serving and secondary serving HS-DSCH cells

Response to transport block

from serving HS-DSCH cell

Response to transport block from secondary

serving HS-DSCH cell

ACK ACK 1 0 1 0 1 0 1 0 1 0 ACK NACK 1 1 0 0 1 1 0 0 1 1

NACK ACK 0 0 1 1 0 0 1 1 0 0

NACK NACK 0 1 0 1 0 1 0 1 0 1 PRE/POST indication

PRE 0 0 1 0 0 1 0 0 1 0

POST 0 1 0 0 1 0 0 1 0 0


Feature Description

Dual Cell HSDPA Operation : Timing Relationship

� When the UE is configured with a secondary serving HS-DSCH cell, it shall not

assume the presence of any common physical channel from that cell other than

CPICH

� Tcell values for two cells under Dual Cell Operation should be same

� Time alignment error which is defined as the delay between the signals from

the two cells at the antenna ports shall not exceed ¼ Tc (i.e. 65x10^-9sec)

� Such stringent requirement stipulate use of configurations where both dual

cells follow same transmit path (STSR2, STSR3, STSR2+1 or STSR2+2).

� STSR1+1 is also supported given BTS checks where iTRM/iTRM2 mixity not

allowed; both PAs should be from same vendor and type (band/power) when

iTRM used while in case of xTRM only PA should be same type (power/ band)

else Alarm <INVALID CONFIGURATION DATA> sent and MIB status set to KO

� Timing alignment is needed when DC-HSDPA cells in one sector are served by

two different Tx paths. The delay calculations and compensations are ensured

digitally via the xCEM and xTRM modules


Feature Description

Dual Cell HSDPA Operation : UE Categories (1/2)

4219215Category 24

QPSK, 16QAM,

64QAM

3528015Category 23

2795215Category 22–

QPSK, 16QAM2337015Category 21

Supported

modulations

simultaneous

with MIMO

Supported

modulations

without MIMO

operation

Maximum nb of bits

of an HS-DSCH

transport block

received within a TTI

Maximum nb

of HS-DSCH

codes

received

HS-DSCH

categoryCat 21 UE supports code rates up to 0.823 with 16QAM

Cat 23 UE supports code rates up to 0.823 with 64QAM

� New UEs of categories 21, 22, 23 or 24 support dual cell operation without

simultaneous support of MIMO

� CQI mapping tables used for these categories

are the same as for Rel’5 and Rel’7 UE

categories

� Any combination of 64 QAM and 16

QAM/QPSK between anchor carrier and

supplementary carrier are supported


Feature Description

Dual Cell HSDPA Operation : UE Categories (2/2)

� HS-DSCH Physical Layer Category Algorithm

� If MAC-hs is configured by UTRAN (i.e. Rel’6), a Rel’8 UE uses the category it has signalled in the IE “HS-DSCH physical layer category”

� If MAC-ehs is configured without Dual Cell HSDPA Operation (i.e. Rel’7), the UE uses the category it has signalled in the IE “HS-DSCH physical layer category extension”

� If Dual Cell HSDPA Operation is configured (i.e. Rel’8), the UE uses the category it has signalled in the IE “HS-DSCH physical layer category extension2”


Feature Description

Dual Cell HSDPA Operation : Call Processing

� Support one PS I/B RAB on EDCH/HSDPA

� 2nd PS RAB addition will trigger Dual Cell Mode -> Single Cell Mode

reconfiguration

� CS RAB addition will trigger Dual Cell Mode -> Single Cell Mode reconfiguration

� 2nd PS RAB release with one PS RAB remaining will trigger Single Cell Mode ->

Dual Cell Mode reconfiguration (if supported by UE, NodeB and RNC)

� CS RAB release with one PS RAB remaining will trigger Single Cell Mode -> Dual

Cell Mode reconfiguration

� Secondary cell CAC failure will trigger Dual Cell Mode -> Single Cell Mode

� Secondary cell RL Failure Indication will trigger Dual Cell Mode -> Single Cell

Mode reconfiguration

� Serving cell mobility to DRNC will trigger {Dual Cell Mode, MAC-ehs} -> {Single

Cell Mode, MAC-hs} reconfiguration

Restricted RAB support in UA7.1.2

Applicable since UA7.1.2 onwards


Feature Description

Dual Cell HSDPA Operation : HW Capacity

In UA7.1.x, maximum number of HSDPA-DC users is limited to 4 per xCEM/ eCEM

(5th DC capable UE will be configured with SC call)

xCEM and eCEM DC user capacity will be increased to a value higher than 4 since

UA08. However whatever the actual supported number the following relation will

always exist between legacy single carrier and Rel’8 dual carrier users

(Number of HSDPA-SC Users + (2 * Number of HSDPA-DC Users)) <= 128

as each DC user consumes 2 HSDPA connections

xCEM/eCEM: up to 28.8 Mbps MAC-ehs throughput per sector/2 carriers can be

supported in UA7.1.2 by default (this can be increased to ~40 Mbps with feature

113511)


Feature Description

Dual Cell HSDPA Operation: Call Admission Control (interaction with UA6.0 PM33694)

•RNC Call admission Control (CAC)

Code CAC is based on the number of HS-PDSCH codes to reserve per HS-DSCH RB according to fair bit rate /2. Power CAC is based on the power reserved for the PS I/B HS-DSCH RAB according to fair bit rate /2. In case Fair sharing is disabled, CAC based upon serving cell configured maximumNumberOfUsers count will be applied

•Node B Call admission Control (CAC)

iBTS considers each DC user consuming two HS-DSCH radio-links. iBTS also limits the number of simultaneous HS-DSCH radio-links (per Node B and per M-BBU (xCEM) / eCEM). If this capacity limit is reached, the radio-link setup/reconfiguration is rejected. This may trigger retry for single cell HSDPA call or fallback to DCH/iMCTA/Pre-emption depending upon the failure cause

fair bitrate = min (MBR, minBR)

fair bitrate =

minHsDschReservationForCac

isminBRused

no

yes

0

minBR (TC, THP,

ARP)

Min()

MBR

no

yes

=0 ? / 2

Fair bitrate / 2 is used on the anchor cell to derive

the needed code & power

Fair bitrate / 2 is used on the secondary cell to

derive the needed code & power

Fair Sharing A lgorithm Prior to Dual Cell operation

serving


Upgrade Procedure

2


Upgrade Procedure

� At RNC side, set isHsdpaDualCellAllowed to FALSE

� At FDDCell level, set the parameter isHsdpaDualCellActivated to FALSE

Parameter dualCellId should be empty to satisfy WiPS check!

� At RNC, set isLiForFlexibleRlcActivated to FALSE

As per UA7.1.2 RAN model these are the default settings for these flags

With HSDPA-DC deactivated, any Rel-8 capable UE will be treated as Rel-7

(assuming 64-QAM is activated) else as Rel-6 (also see slide on UE categories)


Activation Strategy

3


Feature Configuration / Activation

Interaction with other features

Mandatory features (MUST have before enabling PM81204)

1. UA07 PM34388 (RLC Flexible and Mac-ehs)

2. UA07 PM104367 (Interface upgrade to 3GPP Rel-8)

Restriction with features (MUST NOT have before enabling PM81204)

1. UA06 PM33970 (6 sectors Softer Handover) & UA06 PM29808 (PA power pooling)

Optional features (MAY have before enabling PM81204)

1. UA07 PM34386 (64 QAM for HSDPA)

2. UA07 PM34391 (Multiple xCEM per Carrier)

3. UA07 PM113511 HSDPA aggregate throughput increase to 40 Mbps per board

4. UA06 PM33694 Fair Sharing between R99 and HSDPA

5. UA07 PM75998 Radio Measurement Frequency Increase Tx Power

6. UA07 PM81213 Load balancing between HSPA carriers

Performance/Capacity

Anchor selection/ iMCRA



Pre-requisites

The following pre-requisites are needed in order to be able to reach stable maximum peak throughput (theoretical 21*2 = 42Mbps at L1)

Without this feature xCEM/ eCEM aggregate throughput will be limited to 28.8Mbps113511 “HSDPA aggregate

throughput increase to 40

Mbps ” enabled

1- Feature

HSDPA-DC is supported on xCEM in UA7.1.2 for iBTS, with e-CEM HW available from

UA7.1.3

xCEM/e-CEM with iBTS3- Hardware

3GPP R8 UE3- Hardware

RNS upgraded in UA7.1.2 or

later

2- Software

To achieve maximum possible throughput for each DC enabled pair of cells, feature “Multiple

xCEM per Carrier” should be configured

34391 “Multiple xCEM per

Carrier” enabled

1- Feature

MAC-ehs is a pre-requisite for HSDPA DC (MAC-ehs is an enhancement of MAC-hs

protocol that allows higher throughputs thanks to flexible (and thus bigger) RLC PDU size,

relaxing UE processing constraints and RLC window blocking issues). The events leading to

de-configure MAC-ehs shall also lead to de-configure HSDPA DC.

RadioAccessService / isMacehsAllowed = TRUE

FddCell / isMacehsAllowed = TRUE

34388 "L2 improvements :

flexible RLC & MAC-ehs"

enabled

1- Feature

RadioAccessService / isDl64QamOnRncAllowed = TRUEHsdpaRncConf / is64QamAllowedForUeCategory = 1 for Rel’8 UE Cat 23 & 24

FDDCell / isDl64QamAllowed = TRUE

34386 "64 QAM for HSDPA "

enabled

1- Feature

CommentPre-requisiteDomain



Pre-requisites

DC is only supported with E-DCH in UL and RNC checks the sector is E-DCH capable

as part of setting up DC PRL

UL bearer allowing:

- throughput high enough to

acknownledge the high DL

throughput

- UL MAC-es BLER ~0%

4- Setting

Fair Sharing enabled (Dynamic codes managment part):

BTSEquipment / hsdpaCodeTreeManagementActivation = True

FDDCell / isHsxpaR99ResourcesSharingOnCellAllowed = True

1 SF16 used for CCCH including S-CCPCH, HS-SCCH and DL HSUPA codes (for

ex: 1 S-CCPCH + 2 HS-SCCH + 1 E-AGCH + 1 E-HICH/E-RGCH)

Maximum number of HS-PDSCH

codes (15)

4- Setting

DCPS (Dual Core Packet Server) allows to support higher throughput than PSFP in

the RNC

RNC Packet server : DCPS3- Hardware

xCCM FE interface limits the throughput to 30Mbps, so xCCM MDA GE interface is

required to extend applicative throughput to a maximum of 37Mbps

Hybrid/ Native IP Iub (xCCM on

NodeB and GIGe on RNC needed)

3- Hardware

3GPP Rel’7 SGSN and Rel’6 GGSNSGSN and GGSN2- Software

Discussed further in feature 113511UTRAN Licensing feature (34454)

configured to allow max throughput

1- Feature




Pre-requisites

In order to have no resource limitation of power or codeLow cell load6- Traffic

64-QAM modulation use (among other factors) depends upon codes available for HS-PDSCH and CQI

Code available 15 => 64QAM is activated from CQI 26



High CQI5- RF

If not correctly set, the throughput can fluctuate very strongly as observed in 64-QAM FA

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

RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolCellColor = enabled

RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolQosBackPressureThreshold = TBD

RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolQosDiscardThreshold = TBD

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)

Correct Iub congestion

management setting

4- Setting

RadioAccessService/ HsdpaRncConf / minimumHsdschCreditPerTtiInBytes = 1456

RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1472

RadioAccessService / HsdpaRncConf / hsdschCreditCapInNominalRatePercentage = 100%

Correct Hybrid/Native

IP Iub setting

4- Setting

RadioAccessService / HsdpaRncConf / DlRlcQueueSizeForUeCat = 2048 for Cat.21 .. 24

RadioAccessService / RlcConfClass / DlRlcAckFlexibleMode / prohibitedStatusTimer = 10ms

RadioAccessService / HsdpaRncConf / macEhsMaximumPduSizePsIb = 506 Bytes

Correct L2I setting4- Setting




Pre-requisites

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

No Maximum Bit Rate (MBR) limitation7- Core

In order to avoid any DL throughput limitationCorrect VPN and Firewall configuration7- Core

In order to avoid any DL throughput limitationCorrect User Equipment and PC client

configuration

7- Core

In order to avoid any DL throughput limitationCorrect SGSN configuration7- Core

In order to avoid any DL throughput limitationCorrect GGSN configuration7- Core

If the FTP server has a limited configuration and could not be changed, high throughput

could be achieved by establishing 4 (or more) FTP sessions in parallel.

Correct FTP server configuration7- Core

Correct Ethernet switch (PSAX,

Omniswitch) configuration

7- Core




OAM Checks

NodeB Parameters Check

� Two BtsCells are considered associated for DC-HSDPA if they share the same

sector (i.e. sharing the same antennaConnection) and have adjacent

frequencies i.e. dlFrequencyNumber of both cells have to be within 5.1MHz

� They must also share the same HsxpaResourceId to allow that HSxPA services

of both cells would be placed on the same modem board (xCEM or eCEM)

WiPS Parameter Check

� If the flag isHsdpaDualCellActivated is set to FALSE then

- dualCellId should be empty

� If the flag isHsdpaDualCellActivated is set to TRUE then

– dualCellId is filled with value (different than empty)– tCell value is same for both Cells–maxNumberSectorsSofterHo value is not ‘max6Sectors’



Dual Cell HSDPA Operation : Call setup

RNC places call on Dual Cell HSDPA Operation if all following conditions are met

� Features 81204 and 34388 are enabled at RNC level

� UE indicates 3GPP Rel ≥ 8 and multiCellSupport = true in its UE capability

� Dual Cell HSDPA Operation and Flexible MAC-ehs are activated at cell level

� hsdpaPlusPreferredMode at FDDcell is set to dualCellPreferred

� Both Anchor and Supplementary Cells are EDCH / HSDPA capable

� isDualCellAllowedForUeCategory (RNC, 64 bits):

0000000000000000000000000000000000000000111100000000000000000000

� dualCellId in the MIB matches the logical Cell Id received from RSI or Audit

response message of the given NodeB

� tCell attribute in MIB matches between serving and secondary cells



OMC-R parameters

The following feature activation flags will turn on PM81204 feature

RNC:

� RadioAccessService/isHsdpaDualCellAllowed = True

� RadioAccessService/HsdpaRncConf/isDualCellAllowedForUeCategory =

0000000000000000000000000000000000000000111100000000000000000000

CELL

� FDDCell/isHsdpaDualCellActivated = True

� FDDCell/dualCellId = <C-ID of the paired cell>



RNC OAM Impacts

RNC

RadioAccessService

HsdpaRncConf

NodeB

FDDCell

DualCellIdisHsdpaDualCellActivatedhsdpaPlusPreferredMode

parameter : Modified parameter already present in UA7.1

parameter : New parameter from UA7.1.2

rlcRetransmissionBufferInKbytes[ ] dlRlcQueueSizeForUeCat[] isLiForFlexibleRlcActivatedisDualCellAllowedForUeCategory

isHsdpaDualCellAllowed



OMC-R parameters : Additional MIB Data

The following additional parameters need to be set in order for the feature to

handle high volumes of traffic properly

RadioAccessService/HsdpaRncConf/rlcRetransmissionBufferInKbytes =

[500,1050,1050,1050,1050,1050,1050,1050,1050,1050,1050,1050,1050,1050,1050

,1050]

Assume RTD (Round Trip Delay) = 200 ms

42 Mbps * 200ms = 42,000,000 bits/s * 0.2 s = 8,400,000 bits ==> 1050 Kbytes

RadioAccessService/HsdpaRncConf/dlRlcQueueSizeForUeCat =

[256,256,256,256,256,256,256,256,256,256,256,256,512,512,256,256,512,512,51

2,512,2048,2048,2048,2048] (this is recommended to be 2048 for the new UE

categories)

RadioAccessService/HsdpaRncConf/isLiForFlexibleRlcActivated = True



Hardware Configuration

To achieve 40 Mbps Mac-ehs throughput per sector/2 carriers for xCEM or

eCEM, each xCEM/eCEM board should have one dual cell pair only

Cell 1 Cell 2 Cell 3

xCEM (a)


xCEM (b) xCEM (c)



xCEM (a)

xCEM (b)

No Dual cell operation!!

40 Mbps shared between S1, S2 and S3



xCEM (a)

F1

F2



eCEM (a)

F1

F2


xCEM (a)


eCEM (b)

40 Mbps for S1 and 40 Mbps shared between for S2 and S3

Medium baseband capacity

Very high baseband capacity

High baseband capacity



Examples of DC-HSDPA deployment scenarios

Joint Scheduler can allocate on each carrier power and code on a per TTI basis for optimal

system performance

Scenario 2: 3 carrier case with two HSxPAcarriers for data traffic

Inter-freq mobility is not be fully efficient to balance the load between carriers with bursty data traffic

Scenario 1: Two carrier case including one HSPA preferred layer

F2 (HSDPA)

F1

F2

F1

HSDPA is configured on F1 & iMCTA/iMCRA still configured to allocate HSPA users on F2

DC users, anchored in F2, can take advantage of unused power & code resources in F1 (Rel’99)

PA power pooling has to be disabled (STSR2)

HSxPA F2 HSxPA F1

R99 F0

DC

DC


Feature Assessment

4


Expected gain - Simulation

Results for Multi-Carrier Simulations with Full buffer traffic model

12 cell network and 60

FTP users (continuous

download) moving

according to channel

profile

Propagation profile mix:

AWGN (25%) - PedA3

(37%) - PedA30 (13%) -

VehA30 (12%) - VehA120

(13%)

⇒ Gain in term of cell

throughput ~7,6% with

DC-HSDPA

Per carrier user and cell throughput comparison (~5 FTP users

per cell): Cat 14 (64QAM) versus Cat 24 (DC+64QAM)

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

0 2000 4000 6000 8000

Throughput in kbps

CDF

cat-24 user per carrier

cat-24 cell

cat-14 user

cat-14 cell


Expected gain - UIIV results

UDP throughput for UE Cat 24 – Mono

In Velizy lab, best E2E Dual Cell HSDPA performance reached using UTRAN configuration (iBTS STSR2 with 45W MCPA, xCCM with MDA-GE and one xCEM, RNC, Hybrid Iub), Nortel Core and QCT 8220 Cat 24 test UE. The max DL throughput reached was ~ 39Mbps at UDP.

Also note that

Max xCEM HW capacity set to 39.6Mbps

Nominal RNC inflated rate reduced to 100%

Max TBS = 39272 reached for 64-QAM


Feature Monitoring

Dual Cell HSDPA Operation : RNC New Counters and Screenings (1/2)

non-HSDPA to Dual Cell (Inter Freq)

HSDPA to Dual Cell (Inter Freq)

Dual Cell to Dual Cell (Inter Freq)

Dual Cell to non-HSDPA (Intra Freq)

Dual Cell to HSDPA (Intra Freq)

non-HSDPA to Dual Cell (Intra Freq)

HSDPA to Dual Cell (Intra Freq)

Dual Cell to Dual Cell (Intra Freq)

Unsuccessful Reconfiguration Cell to Single Cell

Unsuccessful Reconfiguration Single Cell to Dual Cell

Successful Reconfiguration Dual Cell to Single Cell

Successful Reconfiguration Single Cell to Dual Cell

UE Category 24

UE Category 23

UE Category 22

UE Category 21

Additional Information

VS.HsdpaMobilitySuccess12950

VS.ReconfUnSucc.Hsdpa.Dual_Cell12900



950


950


950


950


950

VS.ReconfSucc.Hsdpa.Dual_Cell02899

VS.ReconfSucc.Hsdpa.Dual_Cell12899

VS.ReconfUnSucc.Hsdpa.Dual_Cell02900

VS.CallAttWithUeCatPerCell221622


13

21

20

Screening

Id




Counter NameCounter

Id


Feature Monitoring

Dual Cell HSDPA Operation : RNC New Counters and Screenings (2/2)

RLFirstSetup Failure: Multi-Cell Oper Not Available

RLReconfPrep UnSucc: Multi-Cell Oper Not Available

RLSetup Failure: Multi-Cell Operation Not Available

Dual Cell to non-HSDPA (Inter Freq)

Dual Cell to HSDPA (Inter Freq)

non-HSDPA to Dual Cell (Inter Freq)

HSDPA to Dual Cell (Inter Freq)

Dual Cell to Dual Cell (Inter Freq)

Dual Cell to non-HSDPA (Intra Freq)

Dual Cell to HSDPA (Intra Freq)

non-HSDPA to Dual Cell (Intra Freq)

HSDPA to Dual Cell (Intra Freq)

Dual Cell to Dual Cell (Intra Freq)

Dual Cell to non-HSDPA (Inter Freq)

Dual Cell to HSDPA (Inter Freq)

Additional Information

VS.RadioLinkReconfigurationPrepareUnsuccess9

40

VS.HsdpaMobilityUnsuccessful15

951

VS.RadioLinkSetupUnsuccess9

38


951


951


951


951


951


951

VS.RadioLinkFirstSetupFailure9

41


951


951


951


14

Screening

Id


Counter NameCounter

Id


Feature Monitoring

Dual Cell HSDPA Operation : NodeB Counters and Screenings

Impact on existing counters

– #10825: HsdpaTTIperUEcat

– #10826: HsdpaTxDataBitPerUEcat

In above counters new screenings have been introduced

– #10807: HsdpaRxDataBitsMAChs

– #10813: HsdpaDiscMACdPDUsTimerExpiry

– #10816: HsdpaDataBufferedNodeB

– #10821: HsdpaUEsPerLCG

– #10828: HsdpaNbUserWithDataTTI

– #10833: HsdpaGbrDeficitRatioPerSpi

– #10834: HsdpaGbrSatisfiedFlows

– #10848: HsdpaGbrFailedFlows

For above counters DC-HSDPA UE related information will be pegged only in its serving cell and not in secondary serving cell

– #10835: HsdpaUsersCapacity is updated while allocating resources for secondary serving HS-DSCH RL like it is done today for serving HS-DSCH RL

– #10318: CEMAllocDCH is updated when allocation of HSDPA resources for secondary serving HS-DSCH RL succeeds or fails


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

Date post:	18-Apr-2015
Category:	Documents
Upload:	vincenzo-guglielmi
View:	226 times
Download:	15 times

UA7.1.2 81204 DualCell HSDPA VDF Workshop Final

Documents