RU20 Features and Parameters - Training

Soc Classification level Presentation / Author / Date 1 © Nokia Siemens Networks

RU20 Delta Radio Planning and Dimensioning Training

Module 1 – Features

Version 1.3 (30.5.2010)


Other related material (and References)

RU20 Delta Planning Guide, HSPA Planning Guide (RU10), 3G Radio Network Planning Guidehttps://sharenet-ims.inside.nokiasiemensnetworks.com/Open/413323618

Multilayer planning guide (+ Different Project related material )https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/413911862

WCDMA900 Planning Guide_v2.1 / Introduction of WCDMA900 as a capacity layerhttps://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/375187097

RU20 Operating documentation in NOLS (www.online.nokia.com)

Other RU20 links:NOLS RU20 feature trainings, C. Johnson - https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/RU20_Training_ParisRU20 P3 Enabling - https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/410507814RU20 on top P3 Enabling - https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/413786267


RU20 Delta Training Agenda – Day 1-2 Features

• HSPA+ features– Intro to HSPA evolution– HSDPA 64 QAM– DC-HSDPA 42Mbps (RU20 on top)– MIMO (RU20 on top)– Flexible RLC(DL)– CS Voice over HSPA (RU20 on top)– Continuous Packet Connectivity– Fractional DPCH

• Other RU20 features– HSUPA 5.8 Mbps, HSUPA 2ms TTI– 24kbps Paging Channel– Fast L1 synchronisation– HSPA 72 Users per Cell– Common channel setup (RU10 on top)– Direct resource allocation for HSPA (RU20 on top?)– Power saving mode

Day 1

Day 2


Feature inter-dependence

X

X X

X

X X


Content

• HSPA+ features– HSDPA 64 QAM

– DC-HSDPA 42Mbps

– MIMO

– Flexible RLC (DL)

– CS Voice over HSPA

– Continuous Packet Connectivity, Fractional DPCH

• Other RU20 features


HSPA+

HSPA enhancements in 3GPP Release 7 and beyond

• User data rates

• Voice capacity

• Battery life

• Latency

• Network throughput

• Flat architecture (iHSPA)

Pre – LTE ?


HSPA+ features3GPP Features

Release 7 Continuous packet connectivity

F-DPCH (Rel 7 version)

HSDPA 64-QAM

MIMO (16-QAM)

Flexible RLC (DL)

CS Voice over HSPA

Flat architecture (iHSPA)

Release 8 Flexible RLC (UL)

MIMO & HSDPA 64-QAM

DC-HSDPA (64-QAM)

Release 9 MIMO & DC-HSDPA (64-QAM)

DC-HSDPA Multi-band, (> 2 carriers?)


Multicarrier HSPA Evolution in Release 9/10

1 x 5 MHz

Uplink Downlink

1 x 5 MHz

4 x 5 MHz

Uplink Downlink

4 x 5 MHz

• HSPA release 7 UE can receive and transmit only on 1 frequency even if the operator has total 3-4 frequencies

• HSPA release 8 brought dual cell HSDPA

• Further HSPA releases will bring multicarrier HSDPA and HSUPA which allows UE to take full benefit of operator’s spectrum


HSPA Data Rate Evolution

14 Mbps

21-28 Mbps

Downlink

3GPP R53GPP R6

3GPP R7

Uplink

42 Mbps84 Mbps

3GPP R83GPP R9

168 Mbps

3GPP R10+

14 Mbps

0.4 Mbps

5.8 Mbps

11 Mbps11 Mbps

23 Mbps

54 Mbps

DC-HSDPA

MIMO 64QAM

DC-HSDPA + MIMO

4-carrier HSDPA

DC-HSUPA 4-carrier HSUPA

16QAM

64QAM or MIMO 16QAM

• HSPA has data rate evolution beyond 100 Mbps


HSPA and LTE Spectral Efficiency Evolution

Evolution of HSPA efficiency

0.55

1.06 1.111.31

1.44 1.52

1.74

0.33 0.33 0.330.53

0.65 0.650.79

0.00.20.40.60.81.01.21.41.61.82.0

HS

PA

R6

HS

PA

R6

+ U

Eeq

ualiz

er

HS

PA

R7

64Q

AM

HS

PA

R8

DC

-H

SD

PA

+ 3

i, U

LIC

HS

PA

R9

DC

-H

SD

PA

+M

IMO

,U

L pr

ogre

ssiv

eP

C

HS

PA

R10

QC

-H

SD

PA

+M

IMO

LTE

R8

bp

s/H

z/ce

ll

DownlinkUplink

Today RU20

RU20 /30

RU30+


Content


– DC-HSDPA 42Mbps

– MIMO






Background (I)

• 64QAM for HSDPA is a 3GPP release 7 capability

• The feature allows 6 bits to be transmitted per modulation symbol

• Peak throughput can be increased by a factor of 1.5 relative to when using 16QAM (peak physical layer throughput of 21.1 Mbps)

• The practical achievable throughput is limited by the air-interface conditions

64QAM

QPSK 16QAM 64QAM

2 bits per symbol 4 bits per symbol 6 bits per symbol

poor to moderate channel conditions

good channel conditions

very good channel conditions


Background (II)

• Principle for switching between 16QAM and 64QAM is the same as that used to switch between QPSK and 16QAM– When channel conditions are sufficiently good, and Node B has sufficient data

within its buffer, then 64QAM is used rather than 16QAM

• As channel conditions improve from being poor according to link adaptation,– the number of codes is increased while using QPSK

if all available codes are used then the coding rate is increased, i.e. the transport block size is increased while continuing to use QPSK with all available codes

– if the coding rate becomes too high then the modulation scheme is switched from QPSK to 16QAM (decreasing the coding rate by increasing the physical channel capacity) the transport block size is then further increased while using 16QAM with all available

codes

– if the coding rate becomes too high then the modulation scheme is switched from 16QAM to 64QAM the transport block size is then further increased while using 64QAM with all available

codes

64QAMIm

prov

ing

Cha

nnel

Con

ditio

ns


Requirements

UE Requirements

• UE must be HSDPA category 13, 14, 17 or 18

Network Hardware Requirements

• Flexi Node B must have release 2 hardware

• UltraSite Node B must have EUBB

• RNC must have CDSP-DH cards and Peak Rate upgrade activated to support the peak rate

Feature Requirements

• The following features must be enabled:

• HSDPA 16QAM; HSDPA 14 Mbps per User; Downlink Flexible RLC

• Feature is licensed using an RNC ON/OFF license

64QAM


UE Categories

• UE categories 13, 14, 17 and 18 support 64QAM (3GPP release 7)

• 64QAM is not supported with MIMO in release 7 of the specifications

Extracted from 3GPP TS 25.306 release 7

64QAM support

64QAM


64QAM Throughputs (I)

Physical Layer (based upon Physical Channel capability)

• Chip Rate = 3.84 Mcps

• Spreading Factor = 16

=> Symbol Rate = 240 ksps

• Number of HS-PDSCH codes = 15

=> Aggregate Symbol Rate = 3.6 Msps

• Number of bits per Symbol = 6

=> Bit Rate = 21.600 Mbps (peak)

Physical Layer (based upon UE maximum transport block size)

• Category 14 and 18 maximum transport block size = 42 192 bits

• Transmission Time Interval = 2 ms

=> Bit Rate = 21.096 Mps (peak)

64QAM

coding rate of 0.98


CQI Mapping Tables (I)

• CQI mapping tables are defined for CQI reporting (Reported CQI)

• CQI mapping tables F and G are applicable when 64QAM is used

• Recall that:

• UE categories 13 and 17 have maximum transport block sizes of 35280 bits

• UE categories 14 and 18 have maximum transport block sizes of 42192 bits

64QAM


CQI Mapping Tables (II)

• CQI mapping tables do not include the maximum transport block sizes

• Table F does not include the use of 15 codes

• Node B is left with the decision of when to schedule the maximum transport block sizes

64QAM

Table F Table G


0

5

10

15

20

25

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35

CQI

MA

C-d

flo

w t

hro

ug

hp

ut,

Mb

ps

Cat-10 (Com) Cat-13, 17 (Com)Cat-14,18 (Com) Cat 10 (Rep)Cat 13, 17, 19, 23 (Rep) Cat 14, 18, 20, 24 (Rep)

Compensated CQI

• Compensated CQI is the result of CQI compensation algorithm in BTS

• Compensated CQI is in range 1-35

• Maximum 64-QAM bit rate requires compensated CQI of 32

QPSK 16-QAM 64-QAM Modulation forCat 13-18

64QAM


Link level performance of HSDPA 64-QAM

• 64-QAM usage is possible only with high SINR levels

• High SINR requires high orthogonality

• In practice this is achieved only in micro cell or LOS conditions

• No link adaptation used in the simulation!

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 230123456789

1011121314151617181920

SINR [dB]

Thr

ough

put [

Mbp

s]

16QAM-17548bit, 12Codes, CR 0.76










64 QAM TFC with possibility to outperform 16QAM

PEDA3km/h

SINR without SF16??

64QAM


Effect of cell range and capacity

• The HSDPA 64-QAM can not be used in cell edge conditions No effect on cell range

• The usage of 64-QAM in macro cells is low Minor effect on cell capacity

• The usage of 64-QAM in micro cells can be higher Some effect on cell capacity depending on environment

• Advanced algorithms in terminal increases the usage of 64-QAM– RX-diversity, chip level equaliser, SCH interference cancellation

28

6

38

3

0

5

10

15

20

25

30

35

40

45

50

sectorized Macro Micro Manhattan Grid

64 Q

AM

Usa

ge

[%]

SISO

RxDiv

64QAM


HSDPA 64QAM Throughput – Max in labHSUPA enabled, MaxNbrOfHSSCCHCodes = 3, 72 user enabled

TB Size

# of HS-PDSCH codes available

37224 14 15

37896 14 15

38576 14 15

39272 n/a 15

39984 n/a 15

40704 n/a 15

41440 n/a 15

42192 n/a 15

• Optimal indoor conditions

• Ave. DL application throughput = 18.9 Mbps

• TBS 40704 reached with 15 codes (Cat 14 HSDPA UE)– Limited by BTS to max. coding rate 0.95

Retransmission rate ~ 0-2%

100M file downloaded (FTP):

Ave. DL application throughput = 18.9 Mbps

Ref: 64QAM tests in NTN-Espoo (5/2010), NPO


Data rate test (Indoor site) - Example

• HSPA+64QAM indoor peak data rate is 20.8M,average data rate is 18.3M

• Compared with 16QAM– In indoor the gain on peak data and average data rate is 35%

Test

scenario

64QAM cell (CAT14)

average data rate (Mbps)

16QAM cell(CAT14)

average data rate (Mbps) Note

Office 18.23 13.57 •Dual Iub site

•HSPA single carrier

•Single user

Meeting

room

18.05 13.58

lobby 18.3 13.57

Ref: HSPA+ 64QAM CUC ShangHai Trial Summary


Data rate test (Outdoor network) - Example

• Verification 64QAM coverage range and HSPA+ 64QAM user’s throughput performance change compared to 16QAM user in different radio condition

• Compared to non-64QAM network,64QAM network’s average throughput have around 6% gain

• As network load increase– the average network CQI will decrease

– the proportion to use 64QAM will decrease

– average throughput of whole network will also decrease

Modulation loadKPI

AVE.RSCP(dBm) AVE.Ec/No(dB) AVE.CQI AVE.Tput(Mbps)

64QAM on

no -64.85 -9.58 24.41 9.34

40% -64.17 -10.21 21 7.7

70% -66.85 -10.47 20.47 7.04

64QAM off

no -66.97 -9.43 25.45 8.84

40% -68.38 -10.16 21.12 7.34

70% -68.26 -10.64 20.5 6.15

Ref: HSPA+ 64QAM CUC ShangHai Trial Summary


Enabling 64QAM (I)

HSDPA64QAMallowed

(WBTS)

This parameter defines whether RNC allows to use 64QAM modulation for HSDPA.If the parameter is enabled, then RNC can use feature HSDPA 64QAM on the BTS. If the parameter is disabled, then RNC cannot use feature HSDPA 64QAM.

Name Range Description

0 (Disabled), 1 (Enabled)

Default

0

• RNC databuild parameter used to enable/disable

• Feature is disabled by default

64QAM


Enabling 64QAM (II)

MaxBitRateNRTMACdflow

(RNC)

Maximum value of parameter depends on which features are licensed:

- no license for HSDPA 15 Codes, then the maximum value is 3456 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence), then the maximum value is 6784 kbps.

- license for HSDPA 15 Codes (10 codes or 15 codes licence) & 10Mbps per User, then max. = 9600 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence) and 14Mbps per User, then max. = 13440 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence) and 64QAM, then max. = 21120 kbps


128 to 21120, step 128 kbps,

65535 (parameter does not limit bit rate)

Default

65535

• MaxBitRateNRTMACdflow must be set to 21120 kbps (or 65535) if 64QAM peak bit rates are to be maintained

64QAM

Parameter can be used to restrict the max. 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 of max bit rate based on UE capability, max bit rate of the RAB, activated HSDPA bit rate features and the value of this parameter. This parameter does not limit the max instantaneous bit rate on air interface. Value of the parameter is compared to the user bitrate of the NRT MAC-d flow excluding MAC-hs header, RLC header and padding (parameter value includes just RLC PDU payload).


Connection Establishment

• Radio Bearer Reconfiguration message from the RNC includes a flag to inform the UE of whether or not 64QAM will be used

• Allows the UE to determine:

• which transport block size table to use

• which HS-SCCH format to use

64QAM


Content


– DC-HSDPA 42Mbps

– MIMO






Background (I) DC HSDPA

5 MHz 5 MHz

F1 F2

MIMO (28 Mbps), or64QAM (21 Mbps)

10 MHz

DC HSDPA and64QAM (42 Mbps)

2 UE, each using 5 MHz RF ChannelPeak Connection Throughput = 28 Mbps

1 UE, using 2 × 5 MHz RF ChannelsPeak Connection Throughput = 42 Mbps

F1 F2

Dual Cell ApproachBasic Approach

• The release 8 version of the specifications allow 2 adjacent channels to be combined to generate an effective HSDPA channel bandwidth of 10 MHz– Prior to 3GPP Release 8, HSDPA channel bandwidths are limited to 5 MHz

• RU20 implementation of Dual Cell HSDPA is based upon release 8 of 3GPP– Release 8 version of the specifications allow Dual Cell HSDPA to be combined

with 64QAM but not with MIMO (Release 9 allows combination with MIMO)


Background (II) DC HSDPA

F1 F2F1 F2 F1 F2

Channel conditions good on both RF carriers

Channel conditions good on RF carrier 1

Channel conditions good on RF carrier 2

UEx UExUE1UE1 UE1

• The release 9 version of the specifications allow 2 non-adjacent channels (potentially in different operating bands) to be combined to generate an effective HSDPA channel bandwidth of 10 MHz– Discussions are ongoing within 3GPP for introducing the capability to combine 4

RF channels to provide a 20 MHz aggregate channel bandwidth

• The combination of multiple RF carriers provides greater flexibility to the HSDPA Scheduler– the scheduler can allocated resources in the frequency domain as well as in the

code and time domains


Physical Channels• The primary serving cell provides the full set of physical channels

– Inner loop power control is driven by the primary serving cell– HARQ ACK/NACK and CQI are reported to the primary serving cell– Uplink data is sent to the primary serving cell

• The secondary serving cell provides only the downlink HS-SCCH and HS-PDSCH

• The return channel must be HSUPA

DC HSDPA

HS-SCCH

HS-SCCHHS-PDSCH

HS-PDSCHHS-DPCCHDPCCH

F-DPCH

E-DPDCHE-DPCCH

Downlink Channels

Uplink Channels

Primary RF CarrierServing cell

Secondary RF CarrierSecondary Serving cell


HS-DPCCH

• HS-DPCCH is responsible for signalling– CQI reports

– HARQ ACK/NACK

• For DC-HSDPA there is a requirement to signal CQI and ACK/NACK information for both cells with the cell pair

• Physical channel capacity of the HS-DPCCH remains the same so the level of redundancy is reduced

• ACK/NACK coding is modified to incorporate information applicable to second cell

• CQI raw data increases from5 to 10 bits meaning that codingrate increases from rate 1/3 to rate ½– Coding is different to MIMO although

MIMO can also involve 2 CQI reportsand 2 ACK/NACK

DC HSDPA

ACK / NACK CQI

Channel Coding

Channel Coding

Physical Channel Mapping

w0..w9 b0..b19

a0..a9


Flexible Configuration

• The flexible configuration requires the HSUPA and F-DPCH features to be enabled on both RF carriers belonging to a cell pair

• The flexible configuration allows both cells to simultaneously act as:– primary serving HSDPA cell for some DC-HSDPA capable UE

– secondary HSDPA serving cell for other DC-HSDPA capable UE

– single carrier HSDPA/HSPA serving cell for non DC-HSDPA capable UE

– member of the Active Set for other UE

DC HSDPA

DC-HSDPA UE1

DC-HSDPA UE2

HSPA UE1

HSPA UE2

Pri. Serving Cell

Pri. Serving Cell Serving Cell

Serving Cell

Sec. Serving Cell

Sec. Serving Cell


Fixed Configuration DC HSDPA

• The fixed configuration applies when the HSUPA and F-DPCH features are enabled on only 1 of the 2 RF carriers belonging to a cell pair

DC-HSDPA UE1

HSPA UE1

HSPA UE2

Serving Cell

Serving Cell

Serving Cell

Sec. Serving Cell

• In the case of the fixed configuration, the RF carrier with HSUPA and F-DPCH enabled can act as:

• primary serving HSDPA cell for DC-HSDPA capable UE

• single carrier HSDPA/HSPA serving cell for non DC-HSDPA capable UE

• member of the Active Set for other UE

• The RF carrier with HSUPA and F-DPCH disabled can act as:

• secondary serving HSDPA cell for DC-HSDPA capable UE

• single carrier HSDPA/HSPA serving cell for non DC-HSDPA capable UE

• member of the Active Set for other UE


HSDPA Scheduler (I)

• 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 and DC-HSDPA UE on both RF carriers

• Link Adaptation is completed in parallel for each RF carrier

DC HSDPA

Shared Scheduler per DC-HSDPA

cell pair

HSDPA UE1 on f2

HSDPA UE3 on f1

DC-HSDPA UE2 with primary serving cell on f2

DC-HSDPA UE4 with primary serving cell on f1


HSDPA Scheduler (II)

• Round Robin, Proportional Fair or PF-RAD-DS schedulers can be used• A scheduler metric is calculated for each RF carrier

– The instantaneous Transport Block Size (TBS) is generated separately for each cell by Link Adaptation

– The Average TBS is based upon the previously allocated TBS in both cells belonging to the DC-HSDPA cell pair, i.e. it represents the total average throughput allocated to the UE

• Thus, a UE which is scheduled high throughput in cell 1 (possibly because it is the only active UE) will have a reduced scheduling metric for being allocated resources in cell 2 Traffic balancing

DC HSDPA

Cell2Cell1

Cell1Cell1 TBS Average

TBS Metric

Cell2Cell1

Cell2Cell2 TBS Average

TBS Metric

Shared Scheduler per DC-HSDPA

cell pair

DC-HSDPA UE


HSDPA Scheduler (III)TTI 1 TTI 2 TTI 3 TTI 4

UE3 Es/NoUE2 Es/No

Scheduled user on f2

TTI 1 TTI 2 TTI 3 TTI 4

UE1 Es/NoUE2 Es/No

Scheduled user on f1

f2

f1 UE1 SC

UE2 DC

UE3 SC

• Single cell and dual cell users are scheduled in fair manner simultaneously in both cells.

• Proportional fair scheduler decides the scheduled users on each cell separately per TTI

• Dual Cell HSDPA user is included in scheduling in both cells.

• Fairness of a dual cell user takes into account the scheduling decisions in both cells.

• Based on cell specific scheduling decisions per TTI, the DC user can be scheduled in none of the cells, in one of the cells or in both of the cells.

TTI 5

TTI 5UE3 UE2 UE3 UE3UE2

UE1 UE2 UE2 UE2UE1

Dual cell Tx for UE2 on TTI 2 and TTI 4. Single cell

Tx for UE2 on TTI5

DC HSDPA


HSDPA Scheduler (IV)

Shared functionality per DC cell pair Separate functionality per DC cell

Link adaptation

HARQ process

ACK1/NACK1, ACK2/NACK2 transmission (HS-DPCCH in serv. cell)

CQI1, CQI2 report transmission (HS-DPCCH in serv. cell)

priority queue (per MAC-d flow)

Shared Scheduler: Proportional Fair (per cell)/Round Robin (per cell)

HS-DPCCH (Serv. Cell)Adaptation of TBS

according to HARQ rate

DC HSDPA


Channel type selection, DC-HSDPAactivation• Allocation of DC HSDPA is tried always when it is possible

– When existing algorithms trigger channel type switch from DCH to HS-DSCH (DL) or from DCH to E-DCH (UL)

– In fixed DC HSDPA configuration UE is currently in potential primary cell

– PS NRT service

• DC HSDPA can be configured to the UE by including Downlink secondary cell info FDD IE into one of the following messages– Active Set Update

– Cell Update Confirm

– Physical Channel Reconfiguration

– Radio Bearer Reconfiguration

– Radio Bearer Setup

– RRC Connection Setup

– Transport Channel Reconfiguration

• DC HSDPA configuration is removed from the UE by leaving out the Downlink secondary cell info FDD IE from the RRC messages

DC HSDPA


Supported RAB Combinations

• DC-HSDPA is not allocated to a standalone SRB

• DC-HSDPA supports up to 3 Interactive or Background RAB mapped to HSPA– Streaming RAB can be configured but must be inactive (mapped to

DCH 0/0 kbps instead of HSPA)

– A maximum of 4 MAC-d flows per UE can be configured

– Establishment of a conversational or streaming RAB triggers the release of the DC-HSDPA configuration

– DC-HSDPA can be configured after the release of a conversation or streaming RAB

DC HSDPA


Connection Establishment

• RRC Connection Request message includes a flag to indicate whether or not the UE supports DC-HSDPA

DC HSDPA

• RRC Connection Setup Complete message includes UE HSDPA Category information

Used by network when DC-HSDPA is enabled

Used by network when DC-HSDPA is disabled


Mobility with DC-HSDPA layer• Directed RRC connection setup (for HSDPA) (IDLE CELL_DCH)

– DC-HSDPA UE to primary DC-HSDPA layer (F-DPCH and HSUPA enabled)

• HSPA layering for UEs in common channels (CELL_FACH CELL_DCH)– DC-HSDPA UE to primary DC-HSDPA layer

• DC-HSDPA Capability Based Handover (CELL_DCH)– DC-HSDPA UE to DC-HSDPA layer– Non- DC-HSDPA UEs away from DC-HSDPA layer

• Service and load based HO and HSPA capability based handover are not triggered when DC-HSDPA is allocated for the UE

• DC-HSDPA can not be active during HSDPA inter-frequency handover– DC-HSDPA requires HSUPA

• DCellHSDPAFmcsId identifies the measurement control parameter set (FMCS object) controlling the intra-frequency measurements of a user having DC HSDPA allocated - Proposal– The RNC uses periodical intra-frequency CPICH Ec/No and RSCP

measurement when HS-DSCH is allocated for the RRC connection ??(More details in Multilayer planning guideline and presentation)

DC HSDPA


Number of HSPA users

• DC HSDPA user is counted only in the primary cell

• HS-DSCH MAC-d flow of the certain DC HSDPA user is counted only in the primary cell

• SC HSDPA and certain DC HSDPA user are counted once per scheduler– new RNW-parameter MaxNumbHSDPAUsersS is used for defining the

maximum allowed number of SC HSDPA and DC HSDPA users in the scheduler

– max two cell per scheduler with DC HSDPA

DC HSDPA


Requirements

UE Requirements

• UE must support dual cell HSDPA




• RNC must be equipped with CDSP-DH cards



• Fractional DPCH, Downlink Flexible RLC, Shared Scheduler for Baseband Efficiency, HSDPA 15 codes, HSDPA 14 Mbps per User, HSUPA

DC HSDPA

• The dual cell HSDPA feature is optional and requires a long term RNC license for a specific number of cells


UE Categories

• HSDPA UE categories 21 to 24 support DC-HSDPA

• Maximum transport block sizes are supported by UE categories 22 and 24

• Maximum transport block sizes are the same as those used for MIMO

• Peak throughput of dual cell HSDPA equals peak throughput of dual stream MIMO (when using same modulation scheme)

Extracted from Rel. 8 version of 3GPP TS 25.306

DC HSDPA


DC-HSDPA Throughputs (I)






=> Aggregate Symbol Rate per RF Carrier = 3.6 Mbps


=> Aggregate Bit Rate per RF Carrier = 21.6 Mbps

• Number of RF Carriers = 2



• Category 24 maximum transport block size = 42 192 bits


=> Bit Rate per transport block = 21.096 Mbps

• Number of Transport Blocks = 2


coding rate of 0.98

DC HSDPA


MAC-ehs PDU

• MAC-ehs header fields– Logical Channel Identifier (LCH-ID) – 4 bits

– Transmission Sequence Number (TSN) – 6 bits

– Segmentation Index (SI) – 2 bits

– Length (L) – 11 bits

– Flag (F) – 1 bit

• TSNn and SIn fields are only required if LCH-Idn <> LCH-Idn-1

24 bits total, or

16 bits without the TSN and SI

LCH-ID1

TSN1

SI1

L12

LCH-ID2

L2F1 F2

LCH-ID3

L3 F3

LCH-ID4

L4 F4

Total header size = 72 bits when MAC-ehs PSU accomodates 4 re-ordering PDU with the same LCH-Id

Maximum transport block size = 42192 bits; Maximum RLC PDU size = 11216 bits

So total RLC payload size = 3 × 11216 + 8472 = 42120 bits

DC HSDPA

5584 bits


DC-HSDPA Throughputs (II)

RLC Layer (based upon maximum transport block size payload)

• Maximum transport block size payload = 2 × 42120 bits

• RLC header size per transport block = 4 × 16 = 64 bits

=> RLC payload = 2 × 42056 bits


=> Peak instantaneous bit rate = 42.056 Mbps

• MAC-ehs re-transmission rate = 10 %

• RLC re-transmissions rate = 1 %

=> Net Bit Rate = 37.43 Mbps

Application Layer (based upon TCP/IP protocol stack)

• IP header size = 20 bytes

• TCP header size = 36 bytes

• MTU Size = 1500 bytes

=> TCP/IP overhead = 3.7 %

=> Application throughput = 36.032 Mbps

DC HSDPA


Reported CQI

• UE categories 21 to 24 are specified to use CQI mapping tables C and D when 64QAM is not configured

• Otherwise CQI mapping tables F and G are used

DC HSDPA


CQI Reporting (III)


• Table F does not include the use of 15 codes


Table F Table G

DC HSDPA


Performance

• DC-HSDPA improves user bit rates and cell capacity by allowing dynamic usage of two HSDPA carriers for a HSDPA user

• Improvement is due to multiple mechanisms– Higher peak bit rate via combination of bit rate of two carriers

– Cell capacity gain via statistical multiplexing of larger number of users

– Performance improvement in fading conditions by frequency selective scheduling and carrier specific link adaptation separate CQI for both carriers

DC HSDPA


Cell edge throughput and capacity

• DC HSDPA compared to two separate carriers

• Example simulation results show >25% increase on cell edge throughput and >20% on cell throughput

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 50

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

DL user throughput (Mbps)

cdf

Throughput Gain over entire Cell Range (8 users)

PedA, DC; mean = 1.64

PedA, 2xSC; mean = 1.35PedB, DC; mean = 1.23

PedB, 2xSC; mean = 1.04

183,6723,11490th

281,2190,95050th

280,4800,37410th

DC Gain(%)

PedA, DC(Mbps)

PedA, 2xSC(Mbps)

Percentile

183,6723,11490th

281,2190,95050th

280,4800,37410th

DC Gain(%)

PedA, DC(Mbps)

PedA, 2xSC(Mbps)

Percentile

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 50

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

DL user throughput (Mbps)

cdf

Throughput Gain over entire Cell Range (8 users)

PedA, DC; mean = 1.64

PedA, 2xSC; mean = 1.35PedB, DC; mean = 1.23

PedB, 2xSC; mean = 1.04

183,6723,11490th

281,2190,95050th

280,4800,37410th

DC Gain(%)

PedA, DC(Mbps)

PedA, 2xSC(Mbps)

Percentile

183,6723,11490th

281,2190,95050th

280,4800,37410th

DC Gain(%)

PedA, DC(Mbps)

PedA, 2xSC(Mbps)

Percentile

2 4 6 8 10 12 14 16 18 200

2

4

6

8

10

12

14

number of users

me

an

DL

ce

ll th

rou

gh

pu

t (M

bp

s)

Receiver Diversity Gain (1Rx MMSE vs. 2Rx MMSE)

PedA 1Rx, DC

PedA 1Rx, 2xSCPedA 2Rx, DC

PedA 2Rx, 2xSC

18-24% cell throughput

gain from DC at 20 PedA

UEs

(ca. 1.8-2 Mbps

throughput increase)

DC HSDPA


Performance comparison to MIMO• DC and MIMO offer a similar sector DL throughput increase

• The mapping of DC and MIMO throughput increase onto cell range gain occupied by different cost & performance factors

0 5 10 15 20 250

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

DL cell throughput (Mbps)

cd

f

Comparative DC vs. MIMO Performance (PedA, 8 users)

DC; mean = 12.71

2xSC; mean = 10.422xSC MIMO; mean = 12.27

•DC HSDPA gain 22%•MIMO gain 18%

DC MIMO no/negligible additional HW/SW cost antenna & HW cost (if not provided)

rise of interf. margin in secondary cell, coverage gain decreasing with cell load

additional spatial signal dimension, no rise of interf. margin in other cells

throughput gain uniformly mappable to coverage gain of DC UEs over cell area

throughput gain not uniformly mapped to coverage gain over cell area

+_

+

+

_

_

DC HSDPA


Enabling the Feature (I)

DCellHSDPAEnabled

(WCEL)



Default

0 (Disabled)

• The DCellHSDPAEnabled parameter must be set to enabled for both cells belonging to the cell pair

The parameter indicates whether or not the DC HSDPA feature is enabled in the cell. Before the feature is enabled in the cell, the system checks that the maximum amount of DC HSDPA-capable cells is not exceeded. If it is not possible to enable DC HSDPA for a new cell then the cell setup does not succeed and error is printed out.

• Two cells form a potential DC HSDPA cell pair when they have adjacent RF carriers, belong to the same sector and have the same Tcell value

• WCEL - UARFCN parameter defines the downlink channel number and the downlink carrier frequency of the cell

• WCEL - SectorID parameter gives a unique identifier to a sector of the base station where the cell belongs to

• WCEL - Tcell parameter defines the start of SCH, CPICH, Primary CCPCH and DL Scrambling Code(s) in a cell relative to BFN

DC HSDPA


Enabling the Feature (II)

MaxBitRateNRTMACDFlow

(RNC)


128..42112, step 128,

65535 (no restriction)

Default

65535

• The MaxBitRateNRTMACDFlow parameter should be configured to 42112 kbps (or 65535) to allow the peak throughput

The parameter can be used to limit the maximum bit rate of NRT MAC-d flow. The bit rate used in the reservation of resources for the MAC-d flow is the minimum of max. bit rate based on UE capability, max. bit rate of RAB, activated HSDPA bit rate features and the value of this parameter. This parameter does not limit the max. instantaneous air interface bit rate. Value of the parameter is compared to the user bitrate excluding MAC-hs header, RLC header and padding (includes just RLC PDU payload).

Maximum value depends on the features licensed: - no license for HSDPA 15 Codes, max. is 3456 kbps - license for HSDPA 15 Codes, max. is 6784 kbps- license for HSDPA 15 Codes and 10Mbps per User, max. is 9600 kbps - license for HSDPA 15 Codes and 14Mbps per User, max. is 13440 kbps - license for HSDPA 15 Codes and 64QAM, max. is 21120 kbps - license for DC HSDPA, max. is 42112 kbps

If the value 65535 is used, then this parameter does not restict the maximum bit rate.

DC HSDPA


Enabling the Feature (III)

• HSDPA serving cell change must be enabled using the HSDPAMobility parameter

• Downlink Flexible RLC must be enabled using the FRLCEnabled parameter

• HSDPA 14 Mbps per User must be enabled using the HSDPA14MbpsPerUser parameter

• The HSDPA 15 codes feature must be enabled with at least a 10 code license and these codes must be enabled using the HSPDSCHCodeSet parameter

• HSUPA must be enabled for at least one of the RF carriers using the HSUPAEnabled parameter

• F-DPCH must be enabled for at least one of the RF carriers using the FDPCHEnabled parameter (if enabled for only one RF carrier, must be same as that used for HSUPA)

• The HSPAQoSEnabled parameter must be configured with the same value in both cells of a cell pair

DC HSDPA


SectorID Configuration DC HSDPA

• Cells which are paired for DC-HSDPA must belong to the same sector

SectorID = 1

RF Carrier 2SectorID = 2

SectorID = 3

SectorID = 1

SectorID = 2

SectorID = 3

RF Carrier 1


Tcell Configuration (I) DC HSDPA

• 2+2+2 Node B with DC-HSDPA requires:

• each cell belonging to the same sector must have the same Tcell value

• Tcell values belonging to different sectors must belong to different Tcell groups

• Configuration requires 3 HSDPA Efficient Baseband Schedulers

• RF carriers 1 and 2 must be adjacent

Tcell = 0

RF Carrier 2Tcell = 3

Tcell = 6

Tcell = 0

Tcell = 3

Tcell = 6

Tcell Groups• Group 1: Tcell values 0, 1, 2 • Group 2: Tcell values 3, 4, 5• Group 3: Tcell values 6, 7, 8• Group 4: Tcell value 9

RF Carrier 1


Tcell Configuration (II) DC HSDPA

• 3+3+3 Node B with DC-HSDPA requires:

• each DC-HSDPA cell belonging to the same sector to have the same Tcell value

• DC-HSDPA Tcell values belonging to different sectors must belong to different Tcell groups

• Configuration requires 4 HSDPA Efficient Baseband Schedulers

• RF carriers 1 and 2 must be adjacent

• Cells belonging to RF carriers 1 and 2 must be within the same LCG

• Cells belonging to RF carrier 3 must be within a second LCG

Tcell = 3

RF Carrier 2Tcell = 9

Tcell = 6

Tcell = 3

Tcell = 9

Tcell = 6

RF Carrier 1

Tcell = 0

Tcell = 2

Tcell = 1

RF Carrier 3


Connection Establishment (I)

• RRC Connection Request message includes a flag to indicate whether or not the UE supports DC-HSDPA

DC HSDPA

• RRC Connection Setup Complete message includes UE HSDPA Category information

Used by network when DC-HSDPA is enabled

Used by network when DC-HSDPA is disabled


Maximum Number of Connections (I)

MaxNumbHSDPAUsersS

(WCEL)


1 to 511, step 1, 0 (unrestricted)

Default

0

• DC-HSDPA connections are only counted within the Serving Cell, i.e. they do not impact the number of connections within the Secondary Serving Cell

• The MaxNumberHSDPAUsers parameter defines the maximum number of HSDPA connections per cell

• The MaxNumbHSDPAUsersS parameter defines the maximum number of HSDPA connections per scheduler

Defines the maximum number of SC HSDPA and DC HSDPA users in the MAC-hs/ehs specific BTS scheduler. Certain SC HSDPA and certain DC HSDPA user are counted once per scheduler. SC HSDPA and DC HSDPA user is a user that has one or more HS-DSCH MAC-d flows established. RNC does not exceed the maximum number but admission of SC HSDPA and DC HSDPA user is inhibited in the scheduler if the maximum number is to be exceeded. This parameter is defined per cell and because scheduler consists of several cells, lowest parameter values of cells forming scheduler shall be used.

DC HSDPA


Maximum Number of Connections (II)

MaxNumbHSDSCHMACdFS

(WCEL)


1 to 1023, step 1, 0 (unrestricted)

Default

0 Defines the maximum allowed number of HS-DSCH MAC-d flows of SC HSDPA and DC HSDPA users in the MAC-hs/ehs specific BTS scheduler. HS-DSCH MAC-d flow of the certain SC HSDPA and DC HSDPA user is counted once per scheduler. Each HS-DSCH MAC-d flow of each SC and DC HSDPA user is counted when the total number of HS-DSCH MAC-d flows in the scheduler is calculated. RNC does not exceed the maximum number but admission of SC HSDPA and DC HSDPA user is inhibited in the scheduler if the maximum number is to be exceeded. This parameter is defined per cell and because scheduler consists of several cells, lowest parameter values of cells forming scheduler shall be used.

• MAC-d flows are only counted within the Serving Cell, i.e. they do not impact the number of MAC-d flow within the Secondary Serving Cell

• The MaxNumbHSDSCHMACdFS parameter defines the maximum number of MAC-d flows per scheduler

DC HSDPA


Power Saving Mode

PWSMSDLimitDCHSDPA

(WCEL)


0 to 300, step 1

Default

5

• DC-HSDPA has an impact upon the Power Saving Mode for BTS (RAN955)

• The number of DC HSDPA users in a cell must be lower than or equal to the value of the PWSMSDLimitDCHSDPA parameter before shutdown is possible

• Each DC HSDPA user is counted separately in the primary and secondary cells

• This new criteria is an addition to the existing crieteria, and all criteria must be fulfilled to shutdown a cell

• The PWSMAVLimitDCHSDPA parameter defines the corresponding threshold for activating a cell in terms of the minimum number of DC-HSDPA capable UE

This parameter defines the limit for DC HSDPA user amount for cell shutdown decision.

PWSMAVLimitDCHSDPA

(WCEL)


0 to 300, step 1

Default

10 This parameter defines the limit for DC HSDPA user amount for cell activation decision.

DC HSDPA


Content


– DC-HSDPA 42Mbps

– MIMO






Intro to MIMO

MIMOMultiple Input Multiple

Output

MIMO

SISOSingle Input Multiple

Output

SIMOSingle Input Multiple

Output

MISOMultiple Input Single

Output


Background

• Downlink MIMO (Multiple Input Multiple Output) is a 3GPP release 7 capability

• The feature is based upon the use of 2 transmit antenna at the Node B and 2 receive antenna at the UE (downlink 2x2 MIMO)

• Peak throughput can be doubled when the UE is in good radio conditions, i.e. peak throughput with 16QAM and 15 codes increases from 14 Mbps to 28 Mbps

• NSN feature is based upon single user MIMO rather than multi-user MIMO

• Single User MIMO can switch between two modes:

MIMO

Spatial Diversity (single stream) Spatial Multiplexing (dual stream)

TB1TB1

Propagation Channel

TB1+TB2 TB1 -TB2

Propagation Channel

Improves SNR at UE Improves throughput at UE


Background

• Target of MIMO is to match the transmitted signal to the channel status– Channel knowledge from UE utilised

MIMO

Diversity gain–Mitigation of effect of multipath fading Improved SINR

–Requires decorrelated antenna locations/polarisations

Array (beam-forming) gain–Direct the signal to optimum direction from signal level and interference point of view Improved SINR

Spatial multiplexing gain–Transmit parallel data streams in optimal conditions Higher peak data rate


MIMO usage

• In performance simulation MIMO (Rel 7) usually loses to Dual Cell (Rel 8). But: – Several operators want to have MIMO and show 28 Mbps peak rate

now!

– Frequency allocation may not allow dual cell

– 3GPP Rel 9 will have MIMO + 64 QAM + Dual cell, where there is a clear benefit from MIMO for the peak user data rates

• MIMO is supported by Flexi SM Rel 2 and Ultrasite with EUBB in RU20 (EP1)– Rel 1 and Rel 2 RF modules can be used

MIMO


MIMO in RU20

• MIMO does not support 64-QAM HSDPA– MIMO is preferred over 64-QAM when both supported

• MIMO and DC-HSDPA are supported in the same cell– Preference between MIMO and DC-HSDPA can be defined with the new RNC

object class parameter DCellVsMIMOPreference

• MIMO can be used only with NRT PS services

• Only one layer can be configured MIMO capable in the BTS

• MIMO supports the following Radio Bearer and SRB mappings– User plane radio bearer mapped onto HS-DSCH in DL and E-DCH in UL

– MIMO is not used if UL SRB cannot be mapped onto E-DCH SRB mapped onto DCH in DL and E-DCH in UL (SRB mapped onto HS-DSCH in DL and E-DCH in UL) (Not Quallcom MDM8200)

• The same power is allocated to S-CPICH and P-CPICH– PtxPrimaryCPICH used for both

MIMO


TBS2

UE

Single

Stream

UE

Dual

StreamTBS1

HS-DPCCH (FBI)

CQI1,CQI2, (N)ACK(s), Rank 2, PCI

Rank 1, TF1, PCI

TTI n

TBS1

TBS1

CQI1, (N)ACK(s), Rank 1, PCI

HS-SCCH

Rank 2, TF1, TF2, PCI

HS-DPCCH (FBI)

HS-SCCH

Node B indicates the used parameters to UE

TBS2

UE

Single

StreamUE

Single

Stream

UE

Dual

StreamUE

Dual

StreamTBS1

HS-DPCCH (FBI)

CQI1,CQI2, (N)ACK(s), Rank 2, PCI

Rank 1, TF1, PCI

TTI n

TBS1

TBS1

TBS1

TBS1

CQI1, (N)ACK(s), Rank 1, PCI

HS-SCCH

Rank 2, TF1, TF2, PCI

HS-DPCCH (FBI)

HS-SCCH

Node B indicates the used parameters to UE

MIMO channels

• No new channels required, but new information added– HS-DPCCH can carry two sets of CQIs, ACKs, Rank and PCI

Channel quality estimate to BTS

– HS-SCCH can carry Rank, two TFs and PCI Used Transport format to UE

MIMO


MIMO modes

• Single stream MIMO– Provides diversity and array gain

• Dual stream MIMO provides spatial multiplexing gain

• MIMO mode selected adaptively by the scheduler

MIMO


MIMO mode (rank) selection at UE

• UE reports the preferred MIMO rank (# of streams encapsulated in the used CQI format)

– MIMO mode selection (at the UE) depends on radio conditions of UE

– It maximizes the supportable transport block size.

0 5 10 15 20 25 300

5

10

15

20

25

SINR [dB]

Avera

ge b

itra

te [

Mbps]

SingleOnly

DualOnly

Dual stream

Single stream

Example - UE Cat. 15

Dual-streamSingle-stream

Switching between single and dual-stream on RF Conditions

MIMO


Single Stream vs Dual Stream Selection in BTS scheduler

• Dual stream is selected if:– UE preference is Dual Stream (indicated by CQI)

– CQI difference in dual stream CQI report < mimoDeltaCQIThreshold

– Buffer status > TBS1+TBS2 - mimoDualStreamOffset bits

• Otherwise single stream is selected

mimoDeltaCQIThreshold

(Hard Coded in Node B)


0 to 20, step 1

Default

2 This parameter defines maximum difference between dual stream CQI reports to allow dual stream transmission

mimoDualStreamOffset



0 to 84384, step 1

Default

0 If this parameter is 0, priority queue must have at least as much data in buffer as the dual stream UE can receive according to CQI reports in order to allow dual stream transmission.

MIMO


Dual stream MIMO Usage and CQI’s

• MIMO is reporting CQI and CQI 2 (from 0-14) – When difference between the CQI’s is less than 2 – secondary stream can be

allocated. In radio conditions with high difference between CQI values, only single stream is allocated

– MIMO usage indicates how often second stream is allocated

Higher MIMO usage when both CQI shows high (12-14)

value close to equal Low MIMO usage when difference between CQI’s

increase

MIMO Usage


MIMO TransmitterWhen using Spatial Diversity (single stream) only the primary TB is sent

• weights, w1 and w2 are applicable

When using Spatial Multiplexing (dual stream) primary and secondary TB are sent

• weights, w1, w2, w3 and w4 are applicable

• contributions from both transport blocks are sent from both antenna

• Same spreading and scrambling codes are applied each TB

• Different CPICH transmitted from each antenna (see VAM)

• Each antenna served by a different power amplifier (not shown in figure)

MIMO


MIMO Weights• The UE uses the CPICH transmitted from each antenna to identify the preferred weights to maximise the

aggregate transport block size

• The UE signals the preferred weights using the Precoding Control Information (PCI) within the HS-DPCCH

• It’s only necessary to signal w2 because w1 and w3 are fixed while w4 is calculated from w2

• Weights applied to each transport block are orthogonal to one another

w1

w3

w4

Set 1 Set 2 Set 3 Set 4

Antenn

a 1A

ntenna 2

MIMO

w2


Precoding Control Information (PCI)

• UE informs the Node B of which weights should be used within the HS-DPCCH

• w2 is signalled as Precoding Control Information (PCI)

Channel Coding

Map onto HS-DPCCH

w0…w9

HARQ-ACK

Channel Coding

b0…b19

CQIa0…a4 Channel Coding

Map onto HS-DPCCH

w0…w9

HARQ-ACK

Concatenation

pci0,pci1

Type A CQI

cqi0…cqi7

PCI

a0…a9 or a0…a6

Type B CQI

cqi0…cqi4

Channel Coding

b0…b19

or

Without MIMO

With MIMO

MIMO


HS-SCCH Coding Type 3

• When 1 transport block is sent:

• Channelisation code set (7 bits)

• Modulation scheme and Number of TB (3 bits)

• Precoding Weight (2 bits)

• Transport block size (6 bits)

• Hybrid ARQ process (4 bits)

• Redundancy and constellation version (2 bits)

• UE identity (16 bits)

• When 2 transport blocks are sent:

• Channelisation code set (7 bits)

• Modulation scheme and Number of TB (3 bits)

• Precoding Weight (2 bits)

• Transport block size for primary TB (6 bits)

• Transport block size for secondary TB (6 bits)

• Hybrid ARQ process (4 bits)

• Redundancy and constellation version for the primary TB (2 bits)

• Redundancy and constellation version for the secondary TB (2 bits)

• UE identity (16 bits)

Total of 40 information bits coded to 120 bits

Total of 48 information bits coded to 120 bits

HS-SCCH uses SF128

=> 120 physical channel bits available per 2 ms TTI

MIMO

MIMO


CPICH for MIMO (I)

P-CPICH1

CCH, DCH on STTD

Pmax,1

P-CPICH2

PA1

BT

S T

x p

ow

er (

W)

HSDPA

MIMO or STTD

HSDPA

MIMO or STTD

PA2

Pmax,2

PA2

P-CPICH

Pmax,1

PA1

Pmax,2

CCH, DCH etc.

HSDPA

MIMO

HSDPA

MIMO

Unused power

S-CPICH

HSDPA

Non - MIMO

BT

S T

x p

ow

er

(W)

P-CPICH on both antennas (STTD) • Default MIMO configuration by 3GPP

specifications

• Non MIMO channels transmitted with open loop Tx diversity (STTD)

• Primary CPICH sent from both antennas for UE phase reference

• Both MIMO & NON-MIMO UEs use these

• Good power budget

• STTD has strong (negative) impact on Equalizer Receiver performance (up to 40% TP loss compared to no STTD)

P-CPICH + S-CPICH• Second supported option for MIMO by

3GPP, however with no performance requirements (25.101)

• STTD is not used

• P-CPICH sent from Ant1, S-CPICH from Ant2

• MIMO UEs see both antennas and both CPICHs• Non-MIMO UEs see only Ant1 and P-CPICH• All non-MIMO data sent from antenna 1 only• Bad power budget

CCH, DCH on STTD

Not useful

for the legacy UE issues

MIMO

NSN Solution


CPICH for MIMO (II)

• The first CPICH option is used for Space Time Transmit Diversity (STTD)– STTD is not supported by NSN

Practical experience has demonstrated that HSDPA UE with advanced receivers have poor performance when STTD is active within the cell

throughput loss of up to 40 %

• NSN implementation is based upon the second CPICH option

• The drawback associated with the second option is that non-MIMO transmissions are only transmitted by the first PA/antenna– non-MIMO transmissions require the primary CPICH as a phase reference

– this can leave the second PA/antenna under utilised proprietary solution used to balance the power

MIMO


Balancing PA Utilisation (I)

• When using the Secondary CPICH option, there is a danger that the second PA is under utilised while the first PA is heavily loaded

• NSN uses a proprietary solution known as Virtual Antenna Mapping (VAM) to balance the load of each PA

Tx Power

P-CPICH S-CPICH

CCH, DCH

HSDPA MIMO

HSDPA MIMO

20 W

PA1 PA2

Unused Power

Loaded with MIMO UE

Tx Power

P-CPICH S-CPICH

CCH, DCH

HSDPA non-MIMO

20 W

PA1 PA2

Unused Power

Loaded with non-MIMO UE

MIMO


MIMOBalancing PA Utilisation (II) – VAM

• VAM allows transmissions for both non-MIMO and MIMO connections through both PA/antenna– Improves the utilisation of PA resources, higher power allocation for non-MIMO users

• S-CPICH transmitted only when active MIMO radio link in the cell (S-CPICH gating)– No interference from S-CPICH in cell without MIMO users

Tx Power

P-CPICH

CCH, DCH,HSDPA

MIMO 1

20 W

PA1 PA2

VAM

PA1

PA2

Antenna 2

Antenna 1

P-CPICH

S-CPICH

MIMO 2

MIMO 1

DCH, CC

HSDPA

S-CPICH

MIMO 2

P-CPICH

MIMO 1

S-CPICH

MIMO 2

CCH, DCH,HSDPA


Balancing PA Utilisation (III)

PA1 PA2

f1

f2

f3

f2

1st Tx MIMO&VAM

MIMO and non-MIMO traffic

2nd Tx MIMO&VAM


1Tx

non-MIMO traffic

1Tx

non-MIMO traffic

ff1 f2 f3

PA1 PA2

f1

f2

f1

f2

1st Tx MIMOwith VAM


2nd Tx MIMOwith VAM


1st TxVAM

non-MIMO traffic

2nd Tx VAM

non-MIMO traffic

ff1 f2

f

PA1 PA2

f1 f1

1st Tx MIMOwith VAM


f12nd Tx MIMOwith VAM


1+1+1 2+2+2 3+3+3

MIMO

• Allocation of traffic to PAs

• Non-MIMO traffic can use both PAs for same carrier (more power) or separate carriers


CPICH for MIMO (I)

• Channelisation code allocation for the secondary CPICH is completed during cell setup if MIMO is enabled

– Secondary CPICH channelisation code is not released or reconfigured as long as MIMO is enabled in the cell

– Code tree optimisation is not applied to Secondary CPICH

• UE with MIMO connections are provided with information regarding the S-CPICH during connection establishment

• For non-MIMO UE, the S-CPICH plays no role but appears as additional interference

– The S-CPICH has the same power as the P-CPICH, i.e. a total of 20 % of the PA power is utilised by the primary and secondary CPICH with default settings

– S-SPICH is transmitted only when there is active MIMO radio link in the cell (CN4063 S-CPICH gating for MIMO)

– Other Common Channels are scaled relative to the CPICH

MIMO


CPICH for MIMO (II)

• Transmit powers of the primary and secondary CPICH are configured using the same parameter

MIMO

PtxPrimaryCPICH

(WCEL)


-10 to 50, step 0.1 dBm

Default

33 dBm(36 dBm for

2 x 20W carrier)

Transmission power of the primary common pilot channel. The parameter also defines the transmission power of the secondary common pilot channel (S-CPICH) used for MIMO. Secondary CPICH power is relevant only if MIMO is used in the cell.

Note: The cell is blocked if the WCDMA BTS does not support the used value. Typical supported range is (Cell max power - 18dB)..(Cell max power - 3dB)


CPICH power allocation• When VAM is used: P-CPICH and S-CPICH are transmitted from both PAs with

same power configured with PtxPrimaryCPICH, – PtxPrimaryCPICH = 33 dBm P-CPICH and S-CPICH are both transmitted with 2W+2W

power• When VAM is not used: P-CPICH and S-CPICH are transmitted from separate

PAs with same power configured with PtxPrimaryCPICH– PtxPrimaryCPICH = 36 dBm (10% of total power of 2 PAs) P-CPICH and S-CPICH are

transmitted with 4W power

Tx Power

P-CPICH

MIMO 1

20 W

PA1 PA2

S-CPICH

MIMO 2

P-CPICH

MIMO 1

S-CPICH

MIMO 2

CCH, DCH,HSDPA

CCH, DCH,HSDPA

Tx Power

P-CPICH

20 W

PA1 PA2

P-CPICH

CCH, DCH,HSDPA

CCH, DCH,HSDPA

2W

2W

2W

2W 2W 2W

Tx Power

P-CPICH

MIMO 1

20 W

PA1 PA2

MIMO 2

CCH, DCH,HSDPA

4W S-CPICH 4W

With VAM, MIMO RL With VAM, no MIMO RL Without VAM


Example Code Allocation

Cch,256,0

Cch,256,1

Cch,256,2

Cch,256,3

Cch,128,4

PrimaryCPICH

P-CCPCH

AICH

PICHCch,64,1

Cch,256,15

S-CCPCH 1

E-AGCH (10 ms)

HS-SCCH

E-HICH & E-RGCH

Cch,128,5

Cch,16,0

E-AGCH (2 ms)

Secondary CPICH

F-DPCHCch,256,14• Use of 15 HS-PDSCH codes for MIMO requires that channelisation code [16,1] is not occupied

• HS-SCCH codes 2,3 and 4 can occupy [16,1] provided that the ‘HSPA 72 Users per Cell’ feature is enabled to allow dynamic code allocation for the HS-SCCH

• In this example, the channelisation code for the 24 kbps paging channel (SF128) does not fit under channelisation code [16,0]

MIMO


MIMO channel type selection

• RNC activates MIMO when HS-DSCH MAC-d flow is established for NRT RAB, if– MIMOEnabled parameter "Enabled"– BTS MIMO capability "MIMO Capable"– RAB configuration of the UE changes so that MIMO is supported– Flexible RLC (MAC-ehs) can be configured– UL SRB can be mapped to HSUPA

HSUPA 2 ms TTI feature & 2 ms TTI selectedOR F-DPCH feature & HSUPA 2 ms or 10 ms selected

– Note: Qualcomm Rel-7 chip (MDM8200) based terminal support MIMO only with UL SRB on HSUPA 2 ms + DL SRB on DCH (no F-DPCH)

• MIMO does not introduce new triggers– to start channel type switch from DCH to HS-DSCH/E-DCH (RB)– to F-DPCH (SRB)– to change the fixed RLC to the flexible RLC

MIMO


Mobility with MIMO layer

• MIMO shall be supported in 3+3+3 configuration– Only one layer can be configured MIMO capable in the BTS

• MIMO Capability Based Handover (CELL_DCH)– MIMO UE to MIMO layer– Non-MIMO UEs away from MIMO layer

• HSPA layering for UEs in common channels (CELL_FACH CELL_DCH)– MIMO UE to MIMO layer– Non-MIMO services from the MIMO layer

• Directed RRC connection setup (IDLE CELL_DCH)– MIMO UEs are not distinguished, MIMO capability is not available in RRC

CONNECTION REQUEST message

• Service and load based HO, and Directed RRC connection setup (for HSDPA) do not direct any UE to MIMO layer

• MIMO can not be active during HSDPA inter-frequency handover– Requires HSUPA

MIMO

(more in Multilayer Planning Guideline)


UE Categories

• HSDPA UE categories 17-20 support MIMO

• RU20 supports maximum transport block sizes of Cat 17-18

• Maximum transport block sizes are the same as those used for DC-HSDPA with 16-QAM

• Peak throughput of dual cell HSDPA equals peak throughput of dual stream MIMO (when using 16-QAM)

Extracted from Rel. 8 version of 3GPP TS 25.306

MIMO


MIMO Throughputs (I)






=> Aggregate Symbol Rate per RF Carrier = 3.6 Mbps


=> Aggregate Bit Rate per RF Carrier = 14.4 Mbps

• Number of parallel MIMO streams = 2





=> Bit Rate per transport block = 13.98 Mbps

• Number of Transport Blocks = 2


coding rate of 0.97

MIMO


MAC-ehs PDU

• MAC-ehs header fields– Logical Channel Identifier (LCH-ID) – 4 bits

– Transmission Sequence Number (TSN) – 6 bits

– Segmentation Index (SI) – 2 bits

– Length (L) – 11 bits

– Flag (F) – 1 bit

• TSNn and SIn fields are only required if LCH-Idn <> LCH-Idn-1

24 bits total, or

16 bits without the TSN and SI

LCH-ID1

TSN1

SI1

L12

LCH-ID2

L2F1 F2

LCH-ID3

L3 F3

Total header size = 24 + 2*16 = 56 bits when MAC-ehs PSU accomodates 3 re-ordering PDU with the same LCH-Id

Maximum transport block size = 27952 bits; Maximum RLC PDU size = 11216 bits

So total payload size = 27896 bits = 2 × 11216 + 5464 bits

MIMO


MIMO Throughputs (II)


• Maximum transport block size payload = 2 × 27 896 bits

• RLC header size per transport block = 3 × 16 = 64 bits

=> RLC payload = 2 × 27 832 bits












MIMO


Reported CQI

• UE categories 17 to 20 are specified to use CQI mapping tables

• C and D in single stream mode

• H and I in dual stream mode

MIMO


CQI for MIMO (I)

• MIMO connections report CQI values on the HS-DPCCH

• MIMO connections use two types of CQI (UE sends both)

• Type A – applicable to dual stream, with support for single stream

• Type B – applicable to single stream

CQI =CQIs when 1 TB preferred by UE (range 0 to 30)

15 × CQI1 + CQI2 + 31 when 2 TB preferred by UE (range 31 to 255)

Type A

CQI1 corresponds to TBS which could be received using the preferred primary precoding vector (range 0 to 14)

CQI2 corresponds to TBS which could be received using the precoding vector which is orthogonal to the preferred primary precoding vector (range 0 to 14)

CQIS corresponds to TBS which could be received using the preferred primary precoding vector (0 to 30)

CQI = CQIs (range 0 to 30)

Type B

MIMO

RANK 2 indicated

RANK 1 indicated


CQI for MIMO (II)• The RNC informs the UE of:

– CQI feedback cycle (range: 0,2,4,8,10,16,20,32,40,64,80 ms)– CQI repetition factor (range: 1,2,3,4)– N_cqi_typeA/M_cqi ratio (range: 1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10, 1/1)

• These parameters define the pattern with which the CQI reports are sent• UE indicates dual stream or single stream within type A according to the

current channel conditions• Type B is sent periodically for single stream ‘fall back’ in case the Node B

decides to use single stream while the UE is reporting a dual stream

Complete cycle of 10 × 4 = 40 TTI = 80 ms

New CQI sent every 4 TTI = 8 ms

Type A CQI Type B CQI

Example:

CQI feedback cycle = 8 ms

CQI repetition factor = 2

N CQI type A / M = 9/10

New for MIMO

MIMO


CQI for MIMO (III)

• The rate at which type A and type B reports are sent is defined by the Node B parameter shown below

MIMONMRatio


This parameter defines the MIMO N/M Ratio (TypeA/TypeB ratio). The parameter is needed in the RAKE to decode single and dual CQI reports and in TCOM to signal it to RNC which signals it to UE.

For example 9/10 means a cycle of 9 Type A reports, then one Type B report.


1 = 1/2

2 = 2/3

3 = 3/4

4 = 4/5

5 = 5/6

Default

9 = 9/106 = 6/7

7 = 7/8

8 = 8/9

9 = 9/10

10 = 1/1

MIMO


CQI Reporting (III) Type A


• CQI compensation


MIMO


CQI Reporting (III) Type B MIMO

Table C (UE Categories 15 and 17) Table D (UE Categories 16 and 18)


Performance

• MIMO improves user bit rates and cell capacity by allowing dynamic usage of one or two parallel data transmissions for a HSDPA user– Rel-7 version of MIMO supports only 16-QAM 64-QAM non-MIMO

can offer better performance

• Improvement is due to multiple mechanisms– Higher peak bit rate via combination of data streams

– Utilisation of diversity and beam-forming effects

MIMO


MIMO peak performance

Once in optimal location – MIMO can provide high throughput (With FTP & NDIS)• Very sensitive for location – small movement can make the difference

• 100M file downloaded (FTP), Average DL application throughput 23.4 Mbps

TBS for b

oth

strea

ms

DL ap

p. T

p.

Ave DL app thru = 23.4 Mbps

Max DL app thru = 24.6 Mbps

CQI for

bot

h str

eam

s

MIM

O Usa

ge

Both streams having high and equal CQI

Retransmission rate close to 0 %

MIMO


CQI's & MIMO usage - Location 1

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89

Ave

rag

e C

QI

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

MIM

O u

sag

e (%

)

MIMO Use (%) Ave. CQI (type A) Ave. CQI2

MIMO vs. 64QAM – Location 1MIMO CQI’s & MIMO usage

• Picture below show Average MIMO CQIs (for both streams) and MIMO usage– Dual stream is allocated if difference between CQI’s less than 2

For 64QAM

• Ave CQI 28.5 with VAM


CQI's & MIMO usage - Location 4

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

1 10 19 28 37 46 55 64 73 82 91 100 109 118 127 136 145 154 163 172 181

Ave

rag

e C

QI

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

MIM

O u

sag

e (%

)

MIMO Use (%) Ave. CQI (type A) Ave. CQI2

MIMO vs. 64QAM – Location 4MIMO CQIs & MIMO usage

For 64QAM

• Ave CQI 25.3

• Picture below show Average MIMO CQIs (for both streams) and MIMO usage– Dual stream is allocated if difference between CQI’s less than 2

Difference between CQI’s higher than 2

(Ave 3.6). Resulting low usage and low

throughput


MIMO vs. 64QAM – Average DL application throughput - SummaryResult show average DL application throughput of each case (2 download per case)

• 100 M file download (FTP & NDIS)

MIMO vs. 64QAM - DL application throughput

0

5

10

15

20

25

Reference Stationary_1 Stationary_2 Stationary_3 Stationary_4 Stationary_5 Stationary_6 Stationary_7

DL

ap

p t

hru

(M

bp

s)

MIMO

64QAM

64QAM w ithout VAM

Average of 2 download cases


MIMO vs. 64QAM - Drive test resultsDL application throughput

MIMO vs. 64QAM drive - application throughput

0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

16000000

18000000

20000000

1 17 33 49 65 81 97 113 129 145 161 177 193 209 225 241 257 273 289 305

DL

ap

p t

hru

MIMO drive1_app thru DL 64QAM drive1_app thru DL 64QAM without VAM drive1_app thru DL

Picture below show drive test throughput results from each case

• 64QAM with VAM (Yellow) show highest throughput results almost all the time along the route while MIMO (blue) show worst results

Not sync with GPS


SISO RxDiv CLM1 MIMO0

500

1000

1500

2000

2500

3000

1x1 1x2 2x2 2x2

PF UE throughput: cell edge (5% fractile), mean, and cell center (95% fractile)

kbps

cell edge (5% fractile)

mean

cell center(95% fractile) MIMO dual stream brings high gain for the UEs inside the cell

MIMO dual stream brings UE TP gain with respect to single stream transmission (modeled by CLM1).

UE AT CELL EDGE:

MIMO single stream is observed to bring benefits with respect to SISO x 1.

2x2 CLM1 is not exactly equivalent to MIMO single-stream transmission, though at 3km/h, with a very good approximation they have the same performance

Performance – User throughput MIMO


SISO RxDiv CLM1 MIMO0

1

2

3

4

5

6

7

1x1 1x2 2x2 2x2

Mean cell throughput

Mbp

s

RR

PF-RAD-DS

PF

This graph shows mean cell TP v/s various scheduling schemes:

Mean cell TP increases if the Rx / Tx scheme becomes more advanced.

MIMO single stream contributes the most to gain of mean cell TP.

MIMO dual stream has minor impact as compared to single stream.

MEAN CELL TP GAINS FOR PED A3 ARE :

RR – 85 %

PF – 54 %

PF-RAD – 57 %

Initial values that will be used to scale Sp. Eff. For UE of MIMO

Performance – Cell throughput MIMO


Remaining MIMO performance challenges

Original: choosebest beam out of 4

With VAM:best beam out of 2

Sometimes several UEsneed data in same 2 msinterval. With MIMO, this

causes capacity loss.

Overhead

DataNo MIMO MIMO

1) Double Pilot power overhead (8% capacity loss in the worst case)

2) Decreased MIMO gain in celledge (~12-15% instead of 20%)

3) Capacity loss of 0-10% due toloss in code multiplexing

Compensated if double total BTS power can be used compared to reference case

Highly dependent on traffic mix

Solved for non-MIMO trafficwith S-CPICH gating


RequirementsUE Requirements

• 3GPP Rel-7 (Cat-15, Cat-16, Cat-17, Cat-18) or Rel-8 (Cat-19, Cat-20) with 16-QAM only

Network Hardware Requirements• Flexi Node B must have release 2 system module. RF module can be release 1 but cannot be mixed release 1 and

release 2

• UltraSite Node B must have EUBB, WTRB or WTRD

• Double PA units and antenna lines

• RNC must have CDSP-DH cards to support the peak rate



• HSDPA, HSDPA Serving Cell Change, HSDPA Soft/Softer Handover, HSDPA Dynamic Resource Allocation, HSUPA, Flexible RLC*, HSDPA 14 Mbps per User, HSUPA 2 ms TTI

• Feature is licensed using an RNC capacity (Cell) license

• * UEs not supporting F-DPCH can also use MIMO

MIMO


Enabling MIMO (I)

MIMOEnabled

(WCEL)

Parameter enables / disables the use of HSDPA MIMO in the cell.



Default

0



MIMO

Requires also:

- FDPCHEnabled Enabled

- FRLCEnabled Enabled

- HSDPA14MbpsPerUser Enabled

- DCellHSDPAEnabled Disabled

- NBAPCommMode 0 (UltraSite BTS, FlexiBTS, PicoBTS)


Enabling MIMO (II)

MaxBitRateNRTMACdflow

(WCEL)

Maximum value of parameter depends on which features are licensed:

- no license for HSDPA 15 Codes, then the maximum value is 3456 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence), then the maximum value is 6784 kbps.

- license for HSDPA 15 Codes (10 codes or 15 codes licence) & 10Mbps per User, then max. = 9600 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence) and 14Mbps per User, then max. = 13440 kbps

- license for HSDPA 15 Codes (10 codes or 15 codes licence) and 64QAM, then max. = 21120 kbps

- license for MIMO, then the maximum value is 27904.


128 to 21120, step 128 kbps,

65535 (parameter does not limit bit rate)

Default

65535

• MaxBitRateNRTMACdflow must be set to 27904kbps (or 65535) if MIMO peak bit rates are to be maintained

Parameter can be used to restrict the max. 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 of max bit rate based on UE capability, max bit rate of the RAB, activated HSDPA bit rate features and the value of this parameter. This parameter does not limit the max instantaneous bit rate on air interface. Value of the parameter is compared to the user bitrate of the NRT MAC-d flow excluding MAC-hs header, RLC header and padding (parameter value includes just RLC PDU payload).

MIMO


Content


– DC-HSDPA 42Mbps

– MIMO






Background (I) FLEX RLC

Segmentation

Pre-Release 7 Approach

RNC

Node B

RNC

Segmentation / Concatenation

Node B

Flexible RLC Approach• Prior to 3GPP Rel. 7, the RLC

layer within the RNC segmented large higher layer packets into many small packets

• The Node B then had to concatenate and pad these small packets to fit within the variable size HSDPA transport block

• Flexible RLC allows the RNC to become relatively transparent

• The Node B segments the higher layer packets such that they fit within the HSDPA transport block

• There is a reduced requirement for RLC headers and padding

• Also reduces the processing requirement in the RNC and UE

Concatenation / Padding


Background (II)

• Graph below illustrates the difference in RLC overhead (header and padding) when using:– Fixed RLC PDU sizes of 336 bits and 656 bits

– Flexible RLC

• Overhead is significantly less for Flexible RLC

FLEX RLC

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500

Rel. 6 with RLC PDU Size of 336 bits

Rel. 6 with RLC PDU Size of 656 bits

Rel. 7 Flexible RLC

Assumes 16 bit RLC header in all cases, i.e. does not account for the Length Indicator

Higher Layer Packet Size (bytes)

RLC

Ove

rhea

d


Protocol Stack Changes

WCDMA L1

UE SRNCNode B

MAC-ehs

RLCMAC-d

WCDMA L1

MAC-ehs

Transport

Frame Protocol

Transport

Frame Protocol

RLCMAC-d

FLEX RLC


Flexible RLC Approach

WCDMA L1

UE SRNCNode B

MAC-hs

RLCMAC-d

WCDMA L1

MAC-hs

Transport

Frame Protocol

Transport

Frame Protocol

RLCMAC-d

New layer

Modified layer

Iub

IubUu

Uu

• Flexible RLC introduces changes to the RLC, Frame Protocol and MAC layers within the protocol stack


Maximum RLC PDU Size

FRLCPDUMaxSize

(RNC)


320 to 5568 bits, step 1 bit

Default

5568 bits

• 3GPP supports a maximum RLC PDU size of 1504 bytes (12032 bits)

• Flexi Release 2 hardware supports a maximum Frame Protocol PDU size of 1428 bytes

• This limits the maximum allowed RLC PDU size

• The RNC ciphering algorithm simultaneously processes 2 equal sized PDU which are subsequently packed into the same Frame Protocol PDU

• RNC databuild parameter, FRLCPDUMaxSize defines the maximum RLC payload within an RLC PDU

This parameter defines maximum size of AMD PDU without the AMD PDU header part in case the flexible RLC PDU size is configured.

• The default value of 5568 bits corresponds to 696 bytes, which multiplied by 2 generates a size of 1392 bytes

• This allows for up to 36 bytes for the Frame Protocol and RLC headers

FLEX RLC

Non-Configurable


MAC-ehs PDU (I)• Without Flexible RLC, MAC-d PDU are concatenated within an HSDPA transport

block. Segmentation of RLC PDU is not allowed

• With Flexible RLC, MAC-d PDU are concatenated if the HSDPA transport block size exceeds the maximum RLC PDU size. Segmentation is allowed if the RLC PDU size exceeds the HSDPA transport block size

• Padding is less likely with Flexible RLC because MAC-d PDU can be segmented to the correct size

MAC-hs header

RLC payloadRLC header Padding

MAC-ehs header

RLC payloadRLC header

FLEX RLC

MAC-ehs header

RLC payloadRLC header RLC payloadRLC header

Padding

Padding


Flexible RLC Approach

MAC-hs

MAC-ehs

Each MAC-d PDU, or segment of MAC-d PDU is known as a

‘Re-ordering SDU’


MAC-ehs PDU (II)• The MAC-ehs header includes:

• Logical Channel Identifier (LCH-ID) (4 bits) extracted from FP Data Frame header

• Transmission Sequence Number (TSN) (6 bits) per priority queue

• Segmentation Index (SI) (2 bits) provides segmentation information

• Length (L) (11 bits) of re-ordering SDU in bytes

• Flag (F) (1 bit) indicates whether or not there are further MAC-ehs header fields

• TSN1 and SI1 fields are always required but subsequent TSN and SI fields are only required if LCH-Idn <> LCH-Idn-1

• MAC-ehs header size = 24 + (n × 24) + (m × 16),where, n is the number of additional re-ordering SDU with different LCH-Id, andm is the number of additional re-ordering SDU with the same LCH-Id

LCH-ID1

TSN1

SI1

L12

LCH-ID2

L2F1 F2

LCH-ID3

L3 F3

LCH-ID4

L4 F4

Total header size = 72 bits when MAC-ehs PDU accomodates 4 re-ordering SDU with the same LCH-Id

FLEX RLC


MAC-ehs PDU (III)

• Example shown below for 64QAM maximum transport block size of 42192 bits

• Maximum RLC PDU size is 11216 bits when assuming a 2 byte RLC header

• 64QAM maximum transport block size can accommodate 3 complete RLC PDU with maximum size plus a section of a 4th RLC PDU (4 re-ordering SDU)

• MAC-ehs header is then 24 + (0 × 24) + (3 × 16) = 72 bits, assuming that all RLC PDU belong to the same logical channel

• MAC-ehs payload is 42192 - 72 = 42120 bits

• RLC payload = 42120 – (4 × 16) = 42056 bits

LCH-ID1

TSN1

SI1

L12

LCH-ID2

L2F1 F2

LCH-ID3

L3 F3

LCH-ID4

L4 F4

FLEX RLC

MAC-ehs header

MAC-ehs payload


Requirements FLEX RLC

UE Requirements

• UE must support Flexible RLC, 3GPP Rel. 7






• HSDPA; HSUPA; HSDPA Dynamic Resource Allocation

• Feature itself is included as basic software and is not licensed

• Both 64QAM and MIMO require the Flexible RLC feature


Enabling Flexible RLC

FRLCEnabled

(RNC)

This parameter enables/disables the use of the Flexible RLC feature.If the parameter is enabled (1), then feature Flexible RLC is used in the RNC. If the parameter is disabled (0), then feature Flexible RLC is not used in the RNC



Default

0



FLEX RLC

• Downlink Flexible RLC is then used when:

• HS-DSCH serving cell is capable of Flexible RLC

• UE is capable of Flexible RLC

• HS-DSCH is selected as the downlink transport channel type

• E-DCH is selected as the uplink transport channel type

• AM RLC is used

• FRLCEnabled is set to value 1 (Enabled)

• HSDPA Dynamic Resource Allocation is enabled


Connection Establishment FLEX RLC

• The UE is informed of whether fixed or flexible sized RLC PDU will be used within the Radio Bearer Setup or Radio Bearer Reconfiguration messages

• RRC Connection Request message includes a flag to indicate whether or not the UE supports Flexible RLC and MAC-ehs

• The same information can be signalled within the RRC Connection Setup Complete message


Content


– DC-HSDPA 42Mbps

– MIMO






Background• Historically,

– HSPA has been associated with PS applications (RT and NRT)– CS voice has been transferred using DCH transport channels

• CS Voice over HSPA uses HSPA transport channels to carry CS voice traffic

• The RNC maps CS voice onto HSPA, i.e. it is transparent to the core network

• The air-interface does not change but there are changes to layer 2– The inclusion of a de-jitter buffer helps to ensure that received speech frames

are forwarded to the higher layers at a constant periodic rate

VOICE HSPA

DCH

CS Core

TM RLC

Dejitter buffer

UM RLC

PDCP

HSPA

RAN

CS Core

RANCS

Voice over DCH

CS Voice over HSPA


Protocol Stacks VOICE HSPA

WCDMA L1

UE

SRNC

Node B

MAC-ehs

RLCMAC-d

WCDMA L1

MAC-ehs

Transport

Frame Protocol

Transport

Frame Protocol

RLCMAC-d

Downlink

IubUu

PDCPPDCPDe-Jitter Buffer

WCDMA L1

UE

SRNC

Node B

MAC-e/es

RLCMAC-d

WCDMA L1

MAC-e

Transport

Frame Protocol

Transport

Frame Protocol

RLCMAC-d

Uplink

IubUu

PDCPPDCP

De-Jitter Buffer

MAC-es


Protocol Stack Overheads• PDCP layer adds an 8 bit header• PDCP PDU size must be a multiple of 8 bits so padding is added if

necessary• Unacknowledged Mode (UM) RLC layer adds an 8 bit header• Total MAC-d PDU size when using 12.2 kbps AMR is 244 + 20 = 264 bits• Headers and padding generate an 8 % overhead

– Percentage overhead is greater for lower AMR bit rates (and SID frames)

VOICE HSPA

Class A, 81 bits Class B, 103 bits Class C, 60 bits


PDCP Header (8 bits)

UM RLC Header (8 bits)



PDCP tail (4 bits)

Concatenation


CS Voice in HSDPA scheduler

• QoS Aware HSPA Scheduler (PF-RAD-DS scheduler) is required

• CS Voice RAB (MAC-d flow) is scheduled in HSDPA scheduler according to– Scheduling Priority Indication (SPI) defined with parameter PriForConvOnHSPA

(Default 14, range 0-14)

– Guaranteed bit rate GBRMACehs = NMACehs/TTIAMR = 288bit / 0.02sec = 14.4 kbps

– Discard timer from parameter DiscardTimerHSCSVoice

Guaranteed bit rate requirement (GBR)

Allocation Retention Priority (ARP)

Traffic Handling Priority (THP): Not known at MAC-hs

Traffic Class (TC): Not known at MAC-hs

RNC Node-B

AdmissionControl

AdmissionControl

Packet

Scheduler

Packet

SchedulerScheduling Priority Indicator (SPI) – 16 levels

Discard Timer (DT) (range: 20 msec to 7.5 sec)

FlowControl

FlowControl

Resource

Manager

Resource

Manager

QoS SettingsQoS Settings

QoS SettingsQoS Settings

HS-DSCH Provided Bit Rate (PBR) per SPI (cell level meas.)

Non HSDPA power measurement

HS-DSCH Required Power (RP) per SPI (to fulfill the GBR)

Reported measurements

Scheduling weights per

bearer

VOICE HSPA


Enabling the Feature

HSPAQoSEnabled

(WCEL)


0 (QoS prioritization is not in use for HS transport),

1 (QoS prioritization is used for HS NRT channels),

2 (HSPA streaming is in use),

3 (HSPA CS voice is in use),

4 (HSPA streaming and CS voice are in use)

Default

0 (QoS prioritization is not in use for HS transport),

• The HSPAQoSEnabled parameter can be used to enable the feature on a per cell basis

• Parameter requires object locking for modification

This parameter is used to control the use of HSPA QoS features. Prioritization is done according to these features for uplink when E-DCH is allocated and downlink when just/also HS-DSCH is allocated.

VOICE HSPA

• If CS voice over HSPA is enabled, then QoS prioritization of NRT HSPA connections is also enabled

• Node B type must be configured as UltraSite BTS, FlexiBTS or PicoBTS using the WBTS-NBAPCommMode parameter (rather than NB/RSxxx )


VOICE HSPA

PriForConvOnHSPA

(RNC)


0 to 14, step 1

Default

14 This parameter defines Scheduling Priority Indication (SPI) for conversational type Radio Access Bearers that are mapped to E-DCH and/or HS-DSCH transport channels. This priority is used inside RAN when resources related to this kind of Radio Access Bearer are handled.

HSPA QoS parameters

• The PriForConvOnHSPA parameter defines an SPI for the conversational traffic class on HSPA

• This parameter belongs to the QoSPriorityMapping parameter structure

• Default value provides CS Voice over HSPA with a high priority

• Priority for CS Voice over HSPA should be greater than that for PS streaming but less than that for the SRB


VOICE HSPAHSPA QoS parameters

• The DiscardTimerHSCSVoice parameter defines an discard timer value for the conversational traffic class on HSPA

• Value is used in PF-RAD-DS (Delay sensitive) scheduler to increase the scheduling metric with time in queue

Name Range Default Description

DiscardTimerHSCSVoice

(RNC - AC)

0 (Discard Timer not used), 1 (20 ms), 2 (40 ms), 3 (60 ms), 4 (80 ms), 5 (100 ms), 6 (120 ms), 7 (140 ms), 8 (160 ms), 9 (180 ms), 10 (200 ms)

2 (40 ms) This parameter defines the HSDPA Discard Timer value for the HS-DSCH MAC-d flow of the CS voice bearer. Discard Timer defines the time to live for a MAC-ehs SDU starting from the instant of its arrival into an HSDPA Priority Queue. BTS can use it as a delay information for guiding the scheduling. Attribute Transfer Delay of the CS voice RAB does not affect the value of the parameter.


MAC-e PDU (Uplink) VOICE HSPA

MAC-d PDU

N

DDI

MAC-e PDU

Padding

optional Padding

TSN

• The MAC-e/MAC-es header includes:– Data Description Indicator (DDI) (6 bits)

– Number of MAC-d PDU (N) (6 bits)

– Transmission Sequence Number (TSN) (6 bits) per priority queue

• MAC-e/MAC-es header size is 18 bits

• MAC-e PDU size (transport block size) is 18 + 264 = 282 bit

• The MAC-e PDU can accommodate multiple MAC-d PDU– SRB can be multiplexed within the same MAC-e PDU


HSUPA Transmission and scheduler VOICE HSPA

• TTI selection is completed based upon existing rules– 2 ms TTI is selected whenever possible, otherwise 10 ms TTI is used

• Non-Scheduled Transmission (NST) is used for CS Voice over HSUPA– UE can send the amount of data defined for NST without grant from

BTS

– Max number of NST bits is signalled for the E-DCH MAC-d flows of the SL and CS voice to UE using RRC Max MAC-e PDU contents size IE to BTS in the NBAP Maximum Number of Bits per MAC-e PDU for Non-

scheduled Transmission


Summary – CS Voice over HSPA bit rates

AMR rateClass A

SDUClass B

SDUClass C

SDUMAC-d

PDU sizeMAC-d

rateMAC-e/es PDU size

MAC-e/es rate

MAC-ehs size

MAC-ehs rate

(GBR)UL/DL UL/DL UL/DL UL/DL UL/DL UL/DL UL UL DL DL

AMR mode 12200 81 103 60 264 13200 282 14100 288 14400AMR mode 7950 75 84 0 176 8800 194 9700 200 10000AMR mode 5900 55 63 0 136 6800 154 7700 160 8000AMR mode 4750 42 53 0 112 5600 130 6500 136 6800AMR SID 1950 39 0 0 56 2800 74 3700 80 4000AMR-WB mode 12650 72 181 0 272 13600 290 14500 296 14800AMR-WB mode 8850 64 113 0 200 10000 218 10900 224 11200AMR-WB mode 6600 54 78 0 152 7600 170 8500 176 8800AMR-WB SID 2000 40 0 0 56 2800 74 3700 80 4000SRB 144 7200 162 8100 168 8400

VOICE HSPA


Performance

• Transfer of CS Voice data on HSPA channels utilises the higher spectral efficiency of HSPA transmission– Higher cell capacity

• Usage of CPC features with CS Voice connections improves the performance– UE battery saving up to 50% higher

– Higher cell capacity

• Call setup times lower

VOICE HSPA


Cell range

• Cell range is defined by the required transport block size– AMR 12.2 MAC-d PDU size of 264 bits

With 2 ms TTI this corresponds peak MAC-d bit rate of 132 kbps With 10 ms TTI this corresponds peak MAC-d bit rate of 26.4 kbps

– From LiBu HSDPA EbNo = 1.79 dB

SINR = 0.5 dB (-11.5 dB) HSUPA EbNo = -1.07 dB

• High DL peak bit ratecan be achievedwhen high poweravailable for HSDPA

VOICE HSPA

DL, 1.6 DL, 1.6

UL, 1.2

UL, 0.9

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

AMR on HSPA AMR on R99

Cel

l ra

ng

e /

kmDL

UL


Cell capacity

• UL capacity increase of about 50% indicated by system level simulations– > 75 users with AMR 12.2

– > 95 users with AMR 5.9

• DL capacity– 20 ms = 10 * TTI

– 4 users / TTI (code-mux)

– When > 40 users per cell Multiple speech frames/TTI

Delay increases

– Cell throughput decreasedby CS Voice over HSPA 40 * 12.2 = < 500 kbps

20 40 60 80 100 1200

2

4

6

8

10

12

# of UEs per cell

RoT

in d

B

Gating, with 8 ms cycle1&2

Normal 2Tx/1Proc 5.9 kbpsGating 2Tx/1Proc 5.9 kbpsGating 2Tx/1Proc 12.2 kbpsNormal 2Tx/1Proc 12.2 kbps

VOICE HSPA


Supported RAB Combinations

• The following RAB combinations are supported (SRB and all Radio Bearers are mapped to HSPA):– Speech CS RAB

– Speech CS RAB + Streaming PS RAB

– Speech CS RAB + 1 to 3 Interactive/Background PS RAB

– Speech CS RAB + Streaming PS RAB + 1 to 3 Interactive/Background PS RAB

– PS streaming over HSPA and multiple NRT RAB over HSPA are separate optional features

• CS Voice over HSPA supports the same AMR CODEC sets as CS Voice over DCH– AMR (12.2, 7.95, 5.9, 4.75), (5.9, 4.75) and (12.2)

– AMR-WB (12.65, 8.85, 6.6)

• The RAN580 Load Based AMR CODEC Mode Selection feature is not applicable to CS Voice over HSPA connections

VOICE HSPA


RRC Connection Establishment

• UE signals support for CS Voice over HSPA within the RRC Setup Complete message

• Rel. 7 UE uses the IE: RadioAccessCapability- PDCP Capability-reservedForFutureUse

• Rel. 8 UE uses the IE: RadioAccessCapability- PDCP Capability-SupportCSVoiceOverHSPA

• SRB should normally be allocated HSPA during RRC Connection establishment

• If SRB are allocated DCH during RRC Connection establishment, then HSPA can be allocated during RAB establishment

VOICE HSPA


Mobility with CS Voice over HSPA

• HSPA Capability Based Handover (CELL_DCH)– Enable HSPA capability based handover for plain CS voice (AMR service) with

the parameter HSCAHORabCombSupport • HSPA layering for UEs in common channels (CELL_FACH

CELL_DCH)– Can be controlled with parameter ServBtwnHSDPALayers

• Directed RRC connection setup for HSPA (IDLE CELL_DCH)– Fractional DPCH capable UEs can be directed to a HSDPA layer (CS indicated

in parameter DRRCForHSDPALayerServices)• Load based HO, and Directed RRC connection setup

– Load triggering includes RT HSPA services• CS Voice over HSPA can not be active during HSDPA inter-system or

inter-frequency handover– Requires HSUPA– Switch to DCH before measurements

• SCC interruption time is expected to be shorter than handover interruption time in GSM today

VOICE HSPA


Downlink Load Control Thresholds (I) VOICE HSPA

• RAS06 introduced Ptx_Target_PS– dynamic load control threshold for controllable DCH load

• RU20 introduces PtxTargetTot– dynamic load control threshold for non-controllable DCH and HSDPA

load

• PtxTarget also remains– static load control threshold for non-controllable DCH

• PtxTargetTot is used when there is non-controllable load on HSDPA, e.g. AMR

• If there are no such services, then PtxTarget is used• PtxTargetTotMax and PtxTargetTotMin parameters define the

upper and lower limits for PtxTargetTot


Downlink Load Control Thresholds (II) VOICE HSPA

PtxCellMaxPtxCellMax

PtxNCDCH

Common channels

HSDPA NRT

DCH NRT

HSDPA PS streaming

DCH streaming

DCH RT + SRBs(excluding PS streaming)

PtxTargetPtxTargetHSDPA voice +SRBs

DCH PS streaming

PtxNCHSDPA

PtxCDCH

PtxTargetTotMaxPtxTargetTotMax

PtxHSDPA_stream

PtxTargetTotPtxTargetTot

PtxTargetTotMinPtxTargetTotMin Applicable to non-controllable DCH transmit power

Applicable to the sum of the DCH and HSDPA non-controllable transmit powers

• The non-controllable DCH transmit power includes the common channel channel power

• The following rules must be respected within the RNC databuild

• PtxTargetTotMin <= PtxTargetTotMax

• PtxTarget <=PtxTargetTotMin

• PtxTargetTotMax <= PtxCellMax


VOICE HSPA

• PtxTargetTot is calculated whenever a non-controllable load connection is admitted

• PtxTargetTot is calculated as:

PtxTargetTot = PtxTargetTotMax - PtxNCDCHPtxTargetTotMax

PtxTarget-1( )

Downlink Load Control Thresholds (III)

• PtxTargetTot is decreases as PtxNCDCH increases

• PtxTargetTot equals PtxTarget if PtxNCDCH equals PtxTarget

• PtxTargetTot approaches PtxTargetTotMax if PtxTargetTotMax and PtxTarget are configured with similar values

• ??


VOICE HSPA

• A CS Voice over HSPA connection is admitted if both of the following are true:

PtxNCDCH + PtxNCHSDPA + Pnew < PtxTargetTot

PtxNCHSDPA + Pnew < PtxMaxHSDPA

Downlink Admission Decision

• Pre-emption can be attempted if these conditions are not true

• The RNC estimates Pnew using the expression:

Pnew = (GBR × Activity Factor) ×Existing HSDPA Power

Existing Throughput

RRMULDCHActivityFactorCSAMR

(WBTS)


0 to 100 %, step 1 %

Default

50 % The parameter defines the average UL DCH data rate in relation to its maximum allocated transport channel data rate when the DCH is transferring the RB of the CS AMR RAB.

• The activity factor is measured from existing connections but is initialised using the parameter shown below


PtxTargetPS Target Calculation

• The introduction of CS Voice over HSPA impacts the calculation of the target for PtxTargetPS

• The original calculation in RAS06 was:

VOICE HSPA

PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc- Ptx_hsdpa_stream) x WeightRatio]

PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc) x WeightRatio]

PtxTargetPSTarget = Ptx_nc + [(Pmax - Ptx_nc- Ptx_hsdpa_stream- Pnc_hsdpa) x WeightRatio]

• This calculation shares the power left over from non-controllable load between HSDPA and NRT DCH connections

• The calculation was updated in RU10 to account for HSDPA streaming:

• The updated calculation reduces the the quantity of power to be shared

• The calculation is further updated when CS Voice over HSPA is enabled

CS Voice over HSPA transmit power


Uplink Load Control Thresholds (I)

• RAS06 introduced Prx_Target_PS– dynamic load control threshold for controllable DCH load

• RU20 introduces PrxTargetAMR– dynamic load control threshold for SRB and speech connections

(both DCH and HSUPA)

• PrxTarget also remains– static load control threshold for non-controllable DCH

• PrxTargetAMR varies between PrxTarget and PrxTargetMax depending upon the uplink load of data services

• The dynamic interference target PrxTargetAMR is always applied irrespective of whether or not the CS Voice over HSPA feature is licensed

OTHER


Other interference, noise power

DCH CS data

HSUPA PS NRT

DCH PS NRT

Controllableload

Non-controllableload

DCH PS streaming

Semi-controllableload

HS/DCH SL/CS AMR

PrxDataDCHNST

PrxTargetPrxTarget

PrxTargetPSPrxTargetPS

PrxTargetAMRPrxTargetAMR

PrxTargetMaxPrxTargetMax

HSUPA PS streaming

• Non-controllable load can always use power up to PrxTarget

• Standalone SRB and CS AMR can be admitted even if the non-controllable interference power exceeds PrxTarget as long as the RSSI is below PrxTargetAMR

• Semi-controllable load (HSUPA and DCH streaming) can use any power remaining from the non-controllable load up to PrxTarget

• DCH PS NRT services can use power up to the dynamic uplink DCH target PrxTargetPS

• HSUPA PS NRT services can take all power left from all other services

OTHERUplink Load Control Thresholds (II)


PrxTargetAMR = (PrxTarget – PrxDataDCHNST) × + PrxDataDCHNST

PrxTargetMax

PrxTarget

PrxDataDCHNST = RSSI × (LnrtDCH + LPSSTR + LCSDATA)

• PrxTargetAMR is calculated whenever an SRB or Voice resource request is received

• PrxTargetAMR is calculated as:

• LnrtDCH is the own cell uplink NRT DCH load factor

• LPSSTR is the own cell uplink PS streaming DCH or E-DCH load factor

• LCSDATA is the own cell uplink CS data load factor

OTHERUplink Load Control Thresholds (III)

• PrxTargetAMR decreases as PrxDataDCHNST increases

• PrxTargetAMR equals PrxTarget if PrxDataDCHNST equals PrxTarget


• A CS Voice or SRB connection is admitted if the following is true:

LDCH + LncEDCH – LDCH_Streaming – LnrtDCH + L ≤ LminDCH

Uplink Admission Decision OTHER

Prx_nc + Prx_nc < PrxTarget

RSSI + Prx_nc < PrxTargetAMR

LDCH + LncEDCH – LDCH_Streaming – LnrtDCH + L ≤ LmaxDCH

OR

OR

AND

• LminDCH is defined by the PrxLoadMarginDCH parameter

• LmaxDCH is defined by the PrxLoadMarginMaxDCH parameter


OTHER

• The introduction of CS Voice over HSPA impacts the calculation of the target for PrxTargetPS

• The original calculation in RAS06 was:

PrxTargetPSTarget = Prx_nc + Prx_str + [(Pmax - Prx_nc- Prx_str) x WeightRatio]

PrxTargetPSTarget = Prx_nc + [(Pmax - Prx_nc) x WeightRatio]

• This calculation shares the power left over from non-controllable load between HSUPA and NRT DCH connections

• The calculation was updated in RU10 to account for HSUPA streaming:

• The updated calculation reduces the the quantity of power to be shared

• The calculation remains valid when CS Voice over HSPA is introduced but the contribution of CS Voice over HSPA connections is included within Prx_nc

PrxTargetPS Target Calculation


Requirements (I)

UE Requirements• UE must be release 7 or newer

• UE must support CS Voice over HSPA

Network Hardware Requirements• Flexi Node B must have release 2 hardware


• RNC must be equiped with CDSP-DH cards



• HSDPA, HSUPA, HSDPA Dynamic Resource Allocation, QoS Aware HSPA Scheduling, CPC, F-DPCH, HSDPA with Simultaneous AMR Voice, HSUPA with Simultaneous AMR Voice

• The CS Voice over HSPA feature is optional and requires a long term ON/OFF RNC license

VOICE HSPA


Requirements (II)

• HSDPA is enabled using the HSDPAenabled parameter

• HSUPA is enabled using the HSUPAenabled parameter

• HSDPA dynamic resource allocation is enabled using the HSDPADynamicResourceAllocation parameter

• CPC is enabled using the CPCEnabled parameter

• F-DPCH is enabled using the FDPCHEnabled parameter

• HSPA with Simultaneous AMR Voice Call is enabled using the

AMRWithHSDSCH and AMRWithEDCH parameters

• The HSDSCHQoSclasses and EDCHQOSClasses parameters determine whether or not CS conversational RAB can be mapped onto HSPA

• CS Voice over HSPA connections are handled in the same way as CS Voice over DCH connections in terms of counting against the AMR Erlangs License (RU10 RAN1198 RNC Capacity Licensing)

VOICE HSPA


Content


– DC-HSDPA 42Mbps

– MIMO



– Continuous Packet Connectivity

– Fractional DPCH



• 3GPP Release 7 introduces Continuous Packet Connectivity (CPC)

• CPC includes the following sub-features:– Uplink DTX

– Downlink DRX

– Uplink DRX

– CQI reporting reduction

– New uplink DPCCH slot format

– HS-SCCH less operation

• CPC– saves air-interface capacity and UE power consumption in CELL_DCH

– allows CPC capable UE to remain in CELL_DCH for longer faster response times for user

– is an optional feature for Release 7 UE, i.e. not all UE will support CPC

– is applicable to the HSPA only configuration, i.e. SRB on HSPA and F-DPCH

Background (I) CPC

Supported in RU20

Not Supported in RU20


Background (II) CPC

• CPC eliminates the requirement for continuous transmission and reception during periods when data is not transferred

• Exploits discontinuities in packet data services

• Designed to work with VoIP

UE Power Saving Inactive HSPA UE require less resource

Increased talk time

USER GAIN SYSTEM GAIN

Reduced delay for re-starting data transfer

Increased Capacity

Potential to keep more inactive UE

in CELL_DCH

HS-SCCH Less Operation

Uplink DTX

Downlink DRX

Reduced CQI Reporting

New Uplink DPCCH Slot Format

Uplink DRX


Requirements

UE Requirements• Release 7, or newer

• Support for CPC





• HSDPA, HSUPA, F-DPCH

• The CPC feature is optional and requires a long term RNC license

CPC



• The CPCEnabled parameter must be set to enabled

• This parameter is online so does not require object locking for modification

CPCEnabled

(WCEL)



Default

0 This parameter enables / disables the use of Continuous Packet Connectivity in the cell. If the parameter is enabled, the RNC activates Continuous Packet Connectivity feature if possible for UEs which support the feature. The following subfeatures are part of Continuous Packet Connectivity feature:- DPCCH Gating (UL DTX), - CQI Reporting reduction, - Discontinuous UL Reception (MAC DTX) and - Discontinuous DL Reception (DL DRX).Also UEs can be kept longer in Cell_DCH state because of discontinuous transmission and reception.

CPC

• The FDPCHEnabled parameter must also be set to enabled


Information Received from UE

• The UE signals its support for Discontinuous DPCCH transmission within the RRC Connection Request message

CPC

• The UE signals whether or not it benefits from network based battery power consumption optimisation within the RRC Connection Setup Complete message


Activating CPC for a New Connection

• The UE-specific packet scheduler activates CPC in the following phases:– in the first RAB setup phase

– in the state transition to Cell_DCH phase

– when the hard handover is done.

• UE specific PS requests CPC activation from the cell specific PS

• UE specific PS checks that CPC can be activated in all cells of the active set

• The Fractional DPCH is required to use discontinuous downlink DPCCH and to achieve any gain from discontinuous uplink transmission

• CPC is deactivated by the RNC when the Node B is completing round trip time measurements (otherwise measurements can become inaccurate)

CPC

Cell level requirements for CPC are OK for all cells in the active set

DPCCH Discontinuous Transmission Support IE received

from the UE

F-DPCH can be used

Round Trip Time measurements are not active in the cell

CPC can be activated

CPC cannot be activated

Yes

Yes

Yes

Yes

No

No

No

No

Start


Activating CPC for an existing Connection

• The UE specific PS checks whether or not CPC can be activated for a UE after any of the following events:– a cell is removed from active set

– fractional DPCH is activated

– compressed mode ends without a subsequent hard handover

– round trip time measurements end

• When the UE-specific packet scheduler notices that the CPC needs to be activated for the UE, it sends the CPC-related parameters to the UE and to all BTSs in the active set– 'DTX-DRX timing information' IE

CPC


CPC de-activation

• The BTS can deactivate CPC based on speed and quality (UL sync, SIR etc.)– UL DTX/DL DRX operations can be deactivated and activated also by the

serving BTS with fast L1/L2 signaling (HS-SCCH)

• If the RNC notices that quality deteriorates, the RNC switches SRBs away from HSPA, which deactivates the CPC

• The UE-specific packet scheduler might deactivate CPC for the UE because– CPC cannot be activated to the new cell that needs to be added to the active

set– Fractional DPCH is deactivated.– Compressed mode is started

• De-activation can trigger– State change to CELL_FACH– E.g. RADIO BEARER RECONFIGURATION without including 'DTX-DRX timing

information' IE From this, the UE should interpret that CPC is deactivated

CPC


Dependency upon Connection Type

• A large set of the CPC parameters are defined on a per connection type basis– CS speech using 2 ms TTI for HSUPA

– CS speech using 10 ms TTI for HSUPA

– PS streaming using 2 ms TTI for HSUPA

– PS streaming using 10 ms TTI for HSUPA

– NRT data using 2 ms TTI for HSUPA

– NRT data using 10 ms TTI for HSUPA

CPC


Content

• HSPA+ features– HSDPA 64 QAM– DC-HSDPA 42Mbps– MIMO– Flexible RLC (DL)– CS Voice over HSPA– Continuous Packet Connectivity

UE Battery Power Consumption Uplink Gating Downlink DRX Uplink DRX CQI Reporting Reduction

– Fractional DPCH



UE Battery Power Consumption

V2msCPCOptObjective

(RNC)


0 (RTT),

1 (Battery)

Default

1 The parameter defines the CPC Optimization objective for UE supporting and using CPC. The Optimization objective can be:

- Round Trip Time (RTT) optimization

- Battery power consumption optimization

The RNC delivers the parameter value to the BTS which takes care of the optimization. This parameter is used when 2 ms TTI is used on E-DCH with CS voice over HSPA feature.

CPC

CPCVoice2msTTI

• The V2msCPCOptObjective parameter determines whether or not UE battery power consumption optimisation is applied to devices which have CPC activated

• UE battery power consumption optimisation involves applying a shorter extended inactivity time for UE in CELL_DCH, i.e. UE are moved to CELL_FACH or RRC Idle mode sooner


Extended Inactivity Timers (I)

• Extended CELL_DCH inactivity timers are applied to interactive and background connections– State transitions to CELL_FACH/CELL_PCH are not supported for CS

Voice over HSPA connections– It is not feasible to maintain GBR allocations for inactive streaming

connections

• The standard set of criteria for low throughput and low utilisation are applicable– Both uplink and downlink criteria need to be satisfied– HSPA MAC-d flow low utilisation

HSDPA MAC-d flow low utilisation HSUPA MAC-d flow low throughput

– HSPA MAC-d flow low throughput HSDPA MAC-d flow low throughput HSUPA MAC-d flow low throughput

CPC

All Connection Types


Extended Inactivity Timers (II)

MACdFlowThroughputAveWin

No data in RLC buffer (DL)

HSDPA low utilisation

EDCHMACdFlowThroughputAveWin

HSUPA low throughput

EDCHMACdFlowThroughputTimetoTrigger

3 sec

3 sec 5 sec

Extended CPC inactivity timers (0/90/180 sec)

Move to CELL_FACH

MACdFlowUtilRelThr256 bps

256 bps EDCHMACdFlowThroughputRelThr

CPCH

SD

PA

HS

UP

A

Rb

Time


Extended Inactivity Timers (III)

• The value of the increased inactivity timer is selected using the flow chart shown to the right (assuming xxmsCPCOptObjective is set to 1)

• The UE is moved to CELL_FACH if the selected parameter has a value of 0

• Otherwise, the connection is maintained in CELL_DCH and the extended inactivity timer is started

• The UE is moved to CELL_FACH if the extended inactivity timer expires prior to any further activity

CPC

HSPA MAC-d Low Utilisation/Throughput Indication

Streaming RB exists for the user?

Reconfigure Streaming RB to DCH 0/0

CPC currently active for the UE?

Set timer = InactNonCPCBatOptT

Set timer = InactNonCPCNoBatOptT

Device benefits from Battery

Power Optimisation?

Set timer = InactCPCBatOptT

Set timer = InactCPCNoBatOptT

Device benefits from Battery

Power Optimisation?

Yes

Yes

Yes Yes

No

No

NoNo


90 sec

180 sec

0 sec

0 sec


Content



– Fractional DPCH



Uplink Gating

• Uplink gating is the fundamental sub-feature of CPC. It is a precondition for the other CPC sub-features– Without uplink gating, the uplink DPCCH is transmitted continuously

• Uplink DPCCH contains:– Pilot bits

– Transmit Power Control (TPC) bits

– Feedback Information (FBI) bits when closed loop transmit diversity is used

• With uplink gating, during periods of E-DCH and HS-DPCCH inactivity, the uplink DPCCH is transmitted only in short bursts

• The DPCCH is transmitted during periods of E-DCH or HS-DPCCH activity

• Uplink gating has a negative impact upon power control

• Pre-ambles and post-ambles are used to help power control maintain tracking

CPC

CPCVoice2msTTI


Uplink Gating Patterns

V2msInacThrUEDTXCycl2

(default 32 TTI)

V2msUEDTXCycle1

(default 8 subframes)

V2msUEDTXCycle2

(default 16 subframes)

V2msUEDPCCHburst1

(default 1 subframe) V2msUEDPCCHburst2

(default 1 subframe)

V2msUEDTXLongPreamble

(default 4 slots)

V2msUEDTXCycle1

DPCCH postamble DPCCH preamble

DPCCH when E-DCH is active E-DCH is active

DPCCH Burst

CPCVoice2msTTI

Switching from burst 1 to burst 2

EDCH becomes inactive

2 ms = 3 slots = 1 TTI

fixed by 3GPP (2 slots)

fixed by 3GPP (1 slot)


UE DTX/DRX Offset

• The use of a connection specific DTX/DRX offset allows the Node B to distribute its processing requirements, i.e. it receives the DPCCH bursts from different UE at different times

• 3GPP specifies that the first subframe in each uplink DPCCH burst pattern shall be such that the CFN and DPCCH subframe number S verify

CPC


• The UE specific PS generates the UE DTX/DRX Offset to distribute the Node B processing load

((5 × CFN – UE_DTX_DRX_Offset + S) MOD UE_DTX_cycle_1) = 0


Content



– Fractional DPCH



Downlink DRX

• Downlink DRX allows the UE to temporarily deactivate its receiver

• The general concept of combining uplink gating with downlink DRX allows the UE to deactivate both its transmitter and receiver during periods of inactivity– Downlink DRX can only be used in combination with uplink gating

– It uses the same UE DTX/DRX Offset as uplink gating

– It’s period must be an integer multiple or divisor of V2msUEDTXCycle1

• Downlink DRX is only applied to UE which benefit from UE battery power consumption optimisation

CPC

CPCVoice2msTTI


HS-SCCH Reception Pattern CPC

• The HS-SCCH reception pattern defines the set of subframes during which the UE receives the HS-SCCH

• The HS-SCCH reception pattern is the set of subframes whose HS-SCCH discontinuous reception radio frame number CFN_DRX and subframe number S_DRX verify:

CPCVoice2msTTI

((5 × CFN_DRX – UE_DTX_DRX_Offset + S_DRX) MOD UE_DRX_cycle) = 0

V2msUEDRXCycle

(RNC)


0 (0.5), 1 (1), 2 (2), 3 (3), 4 (4)

Default

1 The parameter defines the 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.CPCVoice2msTTI

• The HS-SCCH reception pattern defines the set of subframes during which the UE receives the HS-SCCH

• The default value of V2msUEDRXCycle means that the UE receives the HS-SCCH in every subframe


Downlink DRX Patterns

• The UE continues to receive the F-DPCH as normal

• The UE monitors the HS-SCCH– for the number of subframes after an HS-SCCH/HS-PDSCH reception defined

by V2msInacThrUEDRXCycle

– periodically within the HS-SCCH reception pattern

• The UE receives the HS-PDSCH when indicated by the HS-SCCH

• The UE receives the E-HICH after sending E-DCH data

V2msUEDRXCycle

CPCVoice2msTTI

Dow

nlin

k R

ecei

ve

HS-PDSCH

HS-SCCH

V2msInacThrUEDRXCycle

HS-SCCH received HS-SCCH monitored

HS-PDSCH received


Downlink DRX Parameters CPC

V2msInacThrUEDRXCycle

(RNC)


0 (0), 1 (1), 2 (2), 3 (4), 4 (8), 5 (16), 6 (32), 7 (64), 8 (128), 9 (256), 10 (512)

Default

6 The parameter defines the 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. This is part of Discontinuous DL Reception (DL DRX) subfeature.

CPCVoice2msTTI

CPCVoice2msTTI

• The V2msInacThrUEDRXCycle parameter is shown below with a default value of 6 subframes, i.e. the UE continues to monitor the HS-SCCH for 6 subframes after an HS-SCCH/HS-PDSCH reception


E-RGCH and E-AGCH Monitoring

• The UEDRXGrantMonit parameter defines whether or not UE are required to monitor the E-AGCH and E-RGCH from cells within the serving radio link set

• It does not impact E-RCGH reception from cells outside the serving radio link set

UEDRXGrantMonit

(RNC)


0 (True),

1 (False)

Default

0 The parameter defines the UE DRX Grant Monitoring for Continuous Packet Connectivity when schedule transmission (interactive or backgroung traffic class) is used on E-DCH.

CPC


• If UEDRXGrantMonit is set to TRUE then the UE monitors the E-AGCH and E-RGCH from the serving set cells at similar times to monitoring the HS-SCCH

• In addition, the UE monitors the grant channels when:

• at least one MAC-d flow uses scheduled transmissions and TEBS > 0, or

• a scheduled E-DCH transmission has been performed in any of the Inactivity Threshold for UE Grant Monitoring previous TTI, or

• the start of E-AGCH and E-RGCH commands overlap with an E-HICH corresponding to a scheduled E-DCH transmission


Content



– Fractional DPCH



Uplink DRX CPC

• Uplink DRX helps the Node B to use resources more efficiently, i.e. it prevents the Node B from having to receive continuously

• After periods of inactivity, the Node B only receives during specific TTI

• UE is able to start new transmissions during those TTI during which the Node B is receiving

• UL DRX may also be used to force the UE to bundle voice packets

• UE specific offset parameter UE_DTX_DRX_Offset (same as that used for uplink gating) allows the timing of UE to be staggered to help Node B processing

• Uplink DRX can result in a delayed transmission from the UE buffer while the UE waits for the next E-DPCCH reception at the Node B

CPCVoice2msTTI


Uplink DRX Patterns CPC

V2msMACInacThr

V2msMACDTXCycle

Inactivity timer starts

UE has data in buffer but not allowed to transmit immediately

UE buffer

E-DCH transmission

E-DPCCH detection at Node B

Inactivity timer starts

CPCVoice2msTTI

• Continuous detection of E-DPCCH at the Node B is stopped after V2msMACInacThr subframes of inactivity

• During periods of E-DCH inactivity, the Node B attempts to receive the E-DPCCH only once every V2msMACDTXCycle subframes


Uplink DRX Parameters CPC

V2msMACDTXCycle

(RNC)


0 (1), 1 (4), 2 (5), 3 (8), 4 (10), 5 (16), 6 (20)

Default

3 The parameter defines the length of MAC DTX Cycle in subframes. This is a pattern of time instances where the start of the uplink E-DCH transmission after inactivity is allowed. This is part of Discontinuous UL Reception (MAC DTX) subfeature.

This parameter is used when 2 ms TTI is used on E-DCH with CS voice over HSPA feature.

CPCVoice2msTTI

V2msMACInacThr

(RNC)


0 (Infinity), 1 (1), 2 (2), 3 (4), 4 (8), 5 (16), 6 (32), 7 (64), 8 (128), 9 (256), 10 (512)

Default

0 The parameter defines E-DCH inactivity time in TTIs after which the UE can start E-DCH transmission only at given times. This is part of Discontinuous UL Reception (MAC DTX) subfeature.

This parameter is used when 2 ms TTI is used on E-DCH with CS voice over HSPA feature. CPCVoice2msTTI

CPCVoice2msTTI


Content



– Fractional DPCH



CQI Reporting Reduction

• The benefits of CPC are limited when CQI reporting is not reduced– uplink DPCCH has to be transmitted at the same time as the HS-

DPCCH to provide TPC commands for the F-DPCH

• This CPC sub-feature reduces the CQI reporting rate when there is no data transmitted on the HS-DSCH

• CQI reporting reduction is applied after a specific number of subframes following the last HS-DSCH activity. Number of subframes defined by V2msCQIDTXTimer

• CQI reports are then generated whenever the CQI feedback cycle overlaps with an uplink DPCCH transmission

CPC

CPCVoice2msTTI


CQI Reporting Reduction Patterns CPC

V2msCQIFeedbackCPC

V2msCQIDTXTimer

7.5 slots

HS-DSCH Reception

HS-DPCCH ACK/NACK transmission

DPCCH pattern

CQI DTX Priority = 0

UE DTX cycle1UE DTX cycle2

CQI DTX Priority = 1

CQI Transmission

CPCVoice2msTTI

• CQI DTX Priority = 1 indicates that CQI reports have greater priority than the uplink DPCCH burst pattern

• CQI DTX Priority = 0 indicates that CQI reports have lower priority than the uplink DPCCH burst pattern


CQI Reporting Reduction Parameters CPC

V2msCQIDTXTimer

(RNC)


0 (0), 1 (1), 2 (2), 3 (4), 4 (8), 5 (16), 6 (32), 7 (64), 8 (128), 9 (256), 10 (512), 11 (Infinity)

Default

6 The parameter defines the number of subframes after an HS-DSCH reception during which the CQI reports have higher priority than the DTX pattern. This is part of CQI Reporting reduction subfeature.

This parameter is used when 2 ms TTI is used on E-DCH with CS voice over HSPA feature.CPCVoice2msTTI

V2msCQIFeedbackCPC

(RNC)


0 (0), 1 (2), 2 (4), 3 (8), 4 (10), 5 (20), 6 (40), 7 (80), 8 (160)

Default

4(10 ms)

The parameter defines the CQI feedback cycle for HSDPA when the CQI reporting is not reduced because of DTX. This is part of CQI Reporting reduction subfeature. This parameter is used when 2 ms TTI is used on E-DCH with CS voice over HSPA feature. Note! Bigger CQI reporting cycles 10ms are not recommended. CPCVoice2msTTI

CPCVoice2msTTI


Content


– DC-HSDPA 42Mbps

– MIMO



– Continuous Packet Connectivity Parameters for other connection types

– Fractional DPCH



CS Speech over HSPA with E-DCH 10 ms TTI

• The parameters below belong to the CPCVoice10msTTI parameter structure

• V10msCPCOptObjective

• V10msCQIDTXTimer

• V10msCQIFeedbackCPC

• V10msMACDTXCycle

• V10msMACInacThr

• V10msInacThrUEDRXCycle

• V10msUEDRXCycle

• V10msInacThrUEDTXCycl2

• V10msUEDTXCycle1

• V10msUEDTXCycle2

• V10msUEDPCCHburst1

• V10msUEDPCCHburst2

• V10msUEDTXLongPreamble

CPC

UE Battery Optimisation

Uplink Gating

Downlink DRX


Uplink DRX


PS Streaming over HSPA with E-DCH 2 ms TTI

• The parameters below belong to the CPCStreaming2msTTI parameter structure

• S2msCPCOptObjective

• S2msCQIDTXTimer

• S2msCQIFeedbackCPC

• S2msMACDTXCycle

• S2msMACInacThr

• S2msInacThrUEDRXCycle

• S2msUEDRXCycle

• S2msInacThrUEDTXCycl2

• S2msUEDTXCycle1

• S2msUEDTXCycle2

• S2msUEDPCCHburst1


• S2msUEDTXLongPreamble

CPC


Uplink Gating

Downlink DRX


Uplink DRX


PS Streaming over HSPA with E-DCH 10 ms TTI

• The parameters below belong to the CPCStreaming10msTTI parameter structure

• S10msCPCOptObjective

• S10msCQIDTXTimer

• S10msCQIFeedbackCPC

• S10msMACDTXCycle

• S10msMACInacThr

• S10msInacThrUEDRXCycle

• S10msUEDRXCycle

• S10msInacThrUEDTXCycl2

• S10msUEDTXCycle1

• S10msUEDTXCycle2



• S10msUEDTXLongPreamble

CPC


Uplink Gating

Downlink DRX


Uplink DRX


NRT Data over HSPA with E-DCH 2 ms TTI

• The parameters below belong to the CPCNRT2msTTI parameter structure

• N2msCPCOptObjective

• N2msCQIDTXTimer

• N2msCQIFeedbackCPC

• N2msMACDTXCycle

• N2msMACInacThr

• N2msInacThrUEDRXCycle

• N2msUEDRXCycle

• N2msInacThrUEDTXCycl2

• N2msUEDTXCycle1

• N2msUEDTXCycle2

• N2msUEDPCCHburst1

• N2msUEDPCCHburst2

• N2msUEDTXLongPreamble

CPC


Uplink Gating

Downlink DRX


Uplink DRX


NRT Data over HSPA with E-DCH 10 ms TTI

• The parameters below belong to the CPCNRT10msTTI parameter structure

N10msCPCOptObjective

N10msCQIDTXTimer

N10msCQIFeedbackCPC

N10msMACDTXCycle

N10msMACInacThr

N10msInacThrUEDRXCycle

N10msUEDRXCycle

N10msInacThrUEDTXCycl2

N10msUEDTXCycle1

N10msUEDTXCycle2

N10msUEDPCCHburst1

N10msUEDPCCHburst2

N10msUEDTXLongPreamble

CPC


Uplink Gating

Downlink DRX


Uplink DRX


Content


– DC-HSDPA 42Mbps

– MIMO



– Continuous Packet Connectivity

– Fractional DPCH



Background (I)

• F-DPCH replaces the downlink DPCCH when the downlink DPDCH is not present– When both application data and SRB are transferred using HSDPA

• F-DPCH includes Transmit Power Control (TPC) bits but excludes TFCI and Pilot bits– TFCI bits - no longer required as there is no DPDCH

– Pilot bits - no longer required as TPC bits are used for SIR measurements

• F-DPCH increases efficiency by allowing up to 10 UE to share the same downlink SF256 channelisation code– Users time multiplexed one after another

F-DPCH

Tx OffTPC

Slot #i

1 time slot 2560 chips

Tx Off

256 chips


Background (II) F-DPCH

• The Fractional DPCH (F-DPCH) was introduced within the release 6 version of the 3GPP specifications

• NSN RU20 implementation is based upon the release 7 version of F-DPCH– only applicable to release 7 and newer UE

– release 6 version of F-DPCH is not supported

• RU20 F-DPCH feature also includes the functionality that allows the SRB to be mapped onto HSPA– this is a requirement for F-DPCH to be used


DPCCH Frame Structure F-DPCH

TPC


Data TFCI PilotData

Slot #iDownlink DPDCH and DPCCH

• Downlink DPCCH includes:– Transmit Power Control (TPC) bits

– Transport Format Combination Indication (TFCI) bits

– Pilot bits

• Downlink DPCCH shares the same downlink channelisation code as the downlink DPDCH

• Inefficient to dedicate that code to a single UE when DPDCH is not used


F-DPCH Frame Structure (3GPP Rel. 7) F-DPCH

• F-DPCH has 10 slot formats

• Slot format 0 is the same as that defined by 3GPP release 6

• Other slot formats shift the TPC bits across the time slot

• Provides greater flexibility in terms of time multiplexing UE

Tx Off (Noff2)

512 chips

Slot #i


Tx Off (Noff1)

256 chips

• Different F-DPCH slot formats can be used for each soft handover radio link

TPC

F-DPCH Slot Format 1


Allocation of F-DPCH Slot Format (I) F-DPCH

TPC

TPC

TPC

TPC

TPC

Slot format 0

Slot format 1

Slot format 2

Slot format 3

Slot format 4

TPC

TPC

TPC

TPC

TPC

Slot format 5

Slot format 6

Slot format 7

Slot format 8

Slot format 9

• RNC allocates F-DPCH slot format during connection establishment and soft handover radio link addition

• Absolute timing of TPC bits must not be equal for two UE using same F-DPCH channelization code

• There are up to 10 F-DPCH slot formats available in each F-DPCH code in Rel-7 version of F-DPCH– All 10 UE using the same F-DPCH code could use the same F-DPCH slot format if all UE

have different chip offset values

– If two UE have equal chip offset values then those UE must have unequal F-DPCH slot formats


Allocation of F-DPCH Slot Format (II) F-DPCH

UE1

UE2

UE1

UE2

UE1

UE2

UE1

UE2

UE1

UE2

UE1

UE2

Example 1: UE are allocated different F-DPCH slot formats

Example 2: UE are allocated different F-DPCH channelisation codes

Example 3: UE are allocated different chip offsets for timing of time slots

• 3GPP Release 7 allows the F-DPCH slot format to be different for each radio link within the active set

• Increased flexibility but can also increase response time to TPC commands

• Slot formats 0 and 9 are prioritised because they reduce the TPC command response time

• TPC response time increased by 1 time slot when using slot formats 1 to 8


Requirements

UE Requirements

• UE must be 3GPP release 7 or newer, and must support F-DPCH




• F-DPCH is supported with CDSP-C/DH DMCU cards within the RNC

• DH card supports E-DCH with 2 and 10 ms TTI for all services

• C card supports E-DCH with 2 ms E-DCH TTI only for SRB and AMR services



• HSDPA, HSUPA


• The 'Continuous Packet Connectivity’ (CPC) license controls both the CPC and F-DPCH features

F-DPCH



FDPCHEnabled

(WCEL)



Default

0 (Disabled)

• The FDPCHEnabled parameter must be set to enabled

• Enables both F-DPCH and SRB on HSPA capabilities

This parameter enables / disables the use of Fractional DPCH (F-DPCH) and mapping of signaling radio bearers on HSPA in the cell.

When the value of the parameter is set to 1 (F-DPCH functions are enabled for the cell), the system checks if activation of F-DPCH is allowed. If it is not possible to activate F-DPCH for a new cell, the activation does not succeed and an error message is printed out.

• The FDPCHEnabled parameter can be changed online without cell locking

• The FDPCHEnabled parameter can be set to 'enabled' only if:

• The state of the 'CPC' licence is 'On'

• HSDPA is enabled in the cell using RNP parameter HSDPAEnabled

• HSUPA is enabled in the cell using RNP parameter HSUPAEnabled

• Node B type is defined as WBTS using RNP parameter NBAPCommMode

F-DPCH



FDPCHAndSRBOnHSPATC

(RNC)


Bit 0: Background

Bit 1: Interactive THP=3



Bit 4: PS Streaming

Bit 5: PS Conversational

Bit 6: CS Conversational

Default

1

1

1

1

1

1

0

• The FDPCHAndSRBOnHSPATC parameter must be configured to allow the appropriate traffic classes to use F-DPCH and HSPA SRB

• Default value allows all traffic classes except CS conversational

This parameter defines the traffic classes (TC) and traffic handling priorities (THP) that can use Fractional DPCH (F-DPCH) and map SRBs on HSPA. The value 1 means that F-DPCH and SRBs on HSPA can be used for the specific TC & THP. The value 0 means that only DPCH and SRBs on DCH can be used for the specific TC & THP.

F-DPCH


Allocating F-DPCH & HSPA SRB (I) F-DPCH

• F-DPCH shall be allocated whenever possible, i.e. not only if 'CPC' or 'CS voice over HSPA' requires it

• The RNC shall allocate the F-DPCH if:– UE supports Release 7 F-DPCH– Release 7 F-DPCH is enabled in all cells of the current DCH active set– E-DCH active set is equal to DCH active set– F-DPCH is allowed for the used service as defined by the

FDPCHAndSRBOnHSPATC parameter – Any services which requires DCH do not exist (AMR on DCH)– HS-DSCH is allocated or is possible to allocate for the UE– E-DCH is allocated or is possible to allocate for the UE– SRB can be mapped to HS-DSCH– SRB can be mapped to E-DCH– Free F-DPCH slot format is available


Allocating F-DPCH & HSPA SRB (II)

• SRB can only be allocated HSUPA with 10 ms TTI only if HSDPA is allocated in the downlink

• If HSDPA is not allocated in the downlink, SRB can be allocated HSUPA with 2 ms TTI, i.e. HSUPA/DCH configuration is possible (SRB only??)

• SRB can only be allocated HSDPA if F-DPCH can be allocated

• If the UE is in soft handover, the CPICH Ec/Io of the HSDPA serving cell must be relatively strong compared to the active set cell with the highest CPICH Ec/Io

• The CPICH Ec/Io of the HSDPA serving cell must be at least equal to CPICH Ec/Io of the active set cell with the highest CPICH Ec/Io - HSDPASRBWindow

F-DPCH

HSDPASRBWindow

(RNC)


0 to 6 dB, step 0.5 dB

Default

1 dB The parameter determines the maximum allowed difference between the best cell and the SRB on HS-DSCH cell. The window is relative to the best cell in the active set. If the SRB on HS-DSCH cell change is outside the window, SRBs on HS-DSCH cell change procedure is initiated. If the SRBs on HS-DSCH cell change fails, it triggers SRBs on HS-DSCH transport channel type switch to DCH. The measured quantity is CPICH Ec/No, which is received periodically from the UE.


Allocating F-DPCH & HSPA SRB (III)

• There must be at least one cell in the active set with a CPICH RSCP greater than the threshold defined by CPICHRSCPThreSRBHSDPA

• Beneficial to have SHO for SRBs in cell edge?? Sensitivity of DCH better??

• If HSPDA is already allocated then the serving cell must have a CPICH RSCP which is greater than the threshold defined by CPICHRSCPThreSRBHSDPA

F-DPCH

CPICHRSCPThreSRBHSDPA

(RNC)


-115 to -25, step 1 dBm

Default

-103 dBm

This parameter defines the coverage area of the SRBs on HS-DSCH within the HSPA serving cell.


Allocating F-DPCH & HSPA SRB (IV) F-DPCH

• The RNC continuously monitors the rules for F-DPCH allocation

• Channel type switching from F-DPCH to DPCH is triggered if any of them are not satisfied while a F-DPCH is allocated

• Likewise, channel type switching from DPCH to F-DPCH is triggered if they are all satisfied while a DPCH is allocated

• The minimum interval between two consecutive F-DPCH allocations for a specific UE is defined by the FDPCHAllocMinInterval parameter

• A timer is started for this minimum interval after F-DPCH to DPCH switching

• The timer is stopped if a RAB establishment procedure is initiated, i.e. F-DPCH allocation is not restricted during RAB establishment

FDPCHAllocMinInterval

(RNC)


0 to 10 s, step 1 s

Default

3 sec The parameter determines the minimum interval between two consecutive Fractional DPCH (F-DPCH) allocations of the certain UE. Timer is started after every successfully executed F-DPCH to DPCH reconfiguration. During the time period, F-DPCH allocation is forbidden. If the value of the parameter is set to 0, consecutive F-DPCH allocations are not restricted. Timer should be stopped when new RAB is set up, i.e. F-DPCH allocation is not restricted in RAB setup phase.


Connection Establishment (I)

• RRC Connection Request message includes a flag which indicates whether or not the UE supports the release 7 version of the F-DPCH

• This flag was introduced within version 7.11 of 3GPP TS 25.331

• RNC can use this information to decide whether or not to allocate the F-DPCH

• The FDPCHSetup parameter can be used to instruct the RNC when to allocate the F-DPCH (assuming the UE supports the F-DPCH)

F-DPCH

Content from RRC Connection Request message


Connection Establishment (II) F-DPCH

FDPCHSetup

(WCEL)


0 (Immediate F-DPCH allocation),

1 (F-DPCH allocation after RRC connection setup),

2 (F-DPCH allocation along with user plane allocation)

Default

0 (Immediate

F-DPCH allocation),

This parameter defines the allocation procedure of Fractional DPCH (F-DPCH) in the RRC connection setup phase in the cell.

• 3 options are available:– (0) RRC Connection Setup message configures F-DPCH and UE is moved into

CELL_DCH with an HSPA SRB

– (1) RRC Connection Setup message moves the UE into CELL_FACH. F-DPCH is then allocated immediately after receiving the RRC Connection Setup Complete message

– (2) RRC Connection Setup message moves the UE into CELL_DCH and allocates a DCH connection for the standalone SRB. F-DPCH is then allocated at the same time as user plane resources

• These are only applicable to UE for which CELL_DCH is the preferred state according to the Common Channel Setup feature


Connection Establishment (III)

• The CPICH Ec/Io must exceed the value defined by the CPICHECNOSRBHSPA parameter when establishing SRB on HSPA

F-DPCH

CPICHECNOSRBHSPA

(RNC)


-24 to 0 dB, step 1 dB

Default

-6 dB This parameter defines the coverage of SRBs on HSPA within the HSPA serving cell. This is used during the state transition from IDLE, CELL_FACH, CELL_PCH and CELL_URA to CELL_DCH state.


Multiplexing with User Plane Data F-DPCH

EDCHMuxSRBTTI10MS

(RNC)


Bit 0: CS Voice

Bit 1: PS streaming

Bit 2: PS interactive THP 1



Bit 5: PS Background

Default

1

1

1

1

1

1

Defines the E-DCH MAC-d flow multiplexing list for the SRB when E-TTI equals 10 ms. Multiplexing list indicates, when it’s the first MAC-d flow for which PDUs are placed in the MAC-e PDU, the other MAC-d flows from which MAC-d PDUs are allowed to be included in the same PDU.

EDCHMuxSRBTTI2MS

(RNC)


Bit 0: CS Voice

Bit 1: PS streaming




Bit 5: PS Background

Default

1

1

0

0

0

0

Defines the E-DCH MAC-d flow multiplexing list for the SRB when E-TTI equals 2 ms. Multiplexing list indicates, when it’s the first MAC-d flow for which PDUs are placed in the MAC-e PDU, the other MAC-d flows from which MAC-d PDUs are allowed to be included in the same PDU.

• Parameters define the user plane traffic types which can be multiplexed within the same MAC-e PDU as the SRB

• Default values allow greater multiplexing flexibility when using the 10 ms TTI


Content

• HSPA+ features

• Other RU20 features– HSUPA 5.8 Mbps

– HSUPA 2ms TTI

– 24kbps Paging Channel

– Fast L1 synchronisation

– HSPA 72 Users per Cell

– Common channel setup

– Direct resource allocation for HSPA

– Power saving mode


Background HSUPA 5.8

• RAS06 and RU10 support a maximum HSUPA throughtput of 2 Mbps

• This feature increases the maximum HSUPA throughput to 5.8 Mbps– represents the theoretical maximum when using QPSK without MIMO

nor Dual Cell capabilities

• Achieving 5.8 Mbps requires the use of:– the 2 ms TTI

– SRB on HSUPA

– 2*SF2+2*SF4 code configuration


Requirements

UE Requirements

• UE must be HSUPA category 6 or 7







• HSUPA, HSUPA 2 ms TTI


HSUPA 5.8



MaxTotalUplinkSymbolRate

(WCEL)

Name Range

0 (960 kbps, SF4)

1 (1920 kbps, 2*SF4)

2 (3840 kbps, 2*SF2)

3 (5760 kbps, 2*SF2+2*SF4)

Default

0 (960 kbps, SF4)

• The MaxTotalUplinkSymbolRate parameter must be set to ‘3’


This parameter determines the planned maximum total uplink symbol rate of the E-DPDCH(s) of the UE in the cell. The lowest parameter value among the parameter values of the cells that belong to the E-DCH active set is used when the E-DCH is allocated. The signaled value is updated when a soft handover branch addition or deletion occurs and the lowest value changes. Note: Upgrade is not always possible due to capacity reasons in the RNC.

In case "HSUPA 2 Mbps" feature is active (state "On" and exist) but "HSUPA 5.8 Mbps" feature is not active, the maximum value of this parameter is "2". In case "HSUPA 5.8 Mbps" feature is active (state "On" and exist), the maximum value of this parameter is "3" and also the value "2" is allowed although the "HSUPA 2 Mbps" feature is not active. If not active, the parameter value change to "3" is not allowed.

HSUPA 5.8



HSUPA2MSTTIEnabled

(WCEL)



Default

0 (Disabled) This parameter enables/disables the use of E-DCH 2ms TTI in the cell. When the value of the parameter is set to 1, the HSUPA 2 ms TTI functions are enabled for the cell. If the parameter is enabled (1), the system checks that the license of the HSUPA 2 ms TTI feature is active (state "On" and exist). If not, this is informed by appropriate configuration error and parameter value change to enabled is not allowed.

HSUPA 5.8

• The MaxTotalUplinkSymbolRate parameter can be set to ‘3’ (5760kbps, 2*SF2+2*SF4) if:– ‘HSUPA 5.8 Mbps’ licence is 'On'

– HSDPA is enabled in the cell using the HSDPAEnabled parameter

– HSUPA is enabled in the cell using the HSUPAEnabled parameter

– BTS type is defined as ‘WBTS’ using the NBAPCommMode parameter

– HSUPA 2 ms TTI is enabled using the HSUPA2MSTTIEnabled parameter



ThresholdMaxEDPDCHSR3840kbps

(WCEL)


0 to 16000 kbps,

step 64 kbps

Default

2048 kbps

• Default value of the ThresholdMaxEDPDCHSR3840kbps parameter means that the 2×SF2 + 2×SF4 configuration is allocated when the maximum RAB bit rate exceeds 2 Mbps

This parameter defines the bit rate threshold for the maximum uplink user bit rate of the RAB when the maximum total uplink symbol rate of E-DPDCH(s) is restricted to 5760 kbps (corresponds to the spreading factor set 2*SF2). The maximum uplink user bit rate of the RAB must be below than or equal to the threshold but above the threshold defined with the ThresholdMaxEDPDCHSR3840kbps parameter until the restriction is set. The maximum total uplink symbol rate 5760 kbps is allowed (corresponds to spreading factors 2*SF2 + 2*SF4) if the maximum uplink user bit rate of the RAB is above the threshold. The parameter has also a special value which deactivates the use of the maximum uplink user bit rate of the RAB for limiting of the maximum total uplink symbol rate to 3840 kbps.

HSUPA 5.8


• The SRB must use the E-DPDCH when HSUPA is configured to allow the use of 2×SF2 + 2×SF4

• DPDCH is specified by 3GPP to use channelisation code index SF/4, i.e. code index for SF256 is 64 (blocked by the 2×SF2 + 2×SF4 configuration)

SF2 SF4 SF8

Cch,2,0

Cch,2,1

Cch,4,0

Cch,4,1

Cch,4,2

Cch,4,3

Cch,128,0

Cch,256,0

Cch,256,1

Cch,128,16Cch,256,32

DPCCH(on Q-branch)

Cch,256,33

E-DPCCH(on I-branch)

E-DPDCH(on I- and Q-branches 2SF2 + 2SF4 max)

HS-DPCCH (on Q-branch)

HSUPA 5.8Uplink Code Tree


UE Categories HSUPA 5.8

• HSUPA UE categories 6 and 7 support the 2×SF2 + 2×SF4 configuration

• HSUPA category 7 UE also supports 16QAM


Bit Rates (I)





• Number of E-DPDCH codes = 2

=> Aggregate Symbol Rate = 5.76 Msps







coding rate of 0.997

HSUPA 5.8



• Number of E-DPDCH codes = 2



• Maximum transport block size payload = 11466 bits

• Maximum number of RLC PDU of size 336 bits = 34

=> RLC payload = 10880 bits












Bit Rates (II) HSUPA 5.8


HSUPA maximum throughput (lab test) PrxMaxTargetBTS = 30 dB

Both HSUPA 5.8 Mbps and HSUPA 2 ms enabled

• HSUPA 2 ms TTI is enabled using the HSUPA2MSTTIEnabled parameter and

• MaxTotalUplinkSymbolRate parameter is set to ‘3’ (5760kbps, 2*SF2+2*SF4)

PrxMaxTargetBTS = 30 dB to avoid air interface limitations during peak bitrate testing

100M file Uploaded (FTP):

Ave. UL application throughput

= 4.7 Mbps


HSUPA throughput with different (field test) PrxMaxTargetBTS values

• Default value of 6 dB gives 3.6 Mbps average application throughput, increased to 4 Mbps with high value (> 12 dB)

• Peak throughput of 5 Mbps achieved with 30 dB

• Serving grant increased with PrxMaxTargetBTS

PrxMaxTargetBTSMAC-es

TpUL tp, ave UL NR

UL Load, ave

UE power UL SG UL TBS

UL HARQ

UL EbNo

2.00 1.0 0.9 1.15 23% -25.4 23.0 2090 8 % 0.484.00 3.5 3.1 3.35 54% -20.4 27.7 7074 9 % 1.016.00 4.4 3.6 5.75 73% -16.3 28.7 8711 8 % 3.868.00 4.2 3.6 7.80 83% -13.3 28.6 8488 6 % 6.58

10.00 4.4 3.7 9.90 90% -11.4 28.8 8811 9 % 8.8312.00 4.7 3.9 12.11 94% -8.6 29.1 9405 9 % 10.9620.00 4.80 3.95 22.25 99% -0.3 29.4 9597 10 % 21.2730.00 4.86 3.94 31.16 100% 7.2 29.7 9726 11 % 30.14

1.0

3.5

4.4 4.24.4

4.7 4.80 4.86

0.9

3.1

3.6 3.6 3.73.9 3.95 3.94

1.2

3.3

5.87.8

9.9

12.1

22.3

31.2

0.0

1.0

2.0

3.0

4.0

5.0

6.0

2 4 6 8 10 12 20 30

PrxMaxTargetBTS

Th

rou

gh

pu

t (M

bp

s)

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

UL

No

ise

Ris

e, E

bN

o (

dB

)

MAC-es Tp UL tp, ave UL NR UL EbNo

23.0

27.7

28.7 28.6 28.829.1

29.429.7

2090

7074

8711 84888811

9405 9597 9726

20.0

21.0

22.0

23.0

24.0

25.0

26.0

27.0

28.0

29.0

30.0

2 4 6 8 10 12 20 30

PrxMaxTargetBTS

Ser

vin

g g

ran

t

0.0

2000.0

4000.0

6000.0

8000.0

10000.0

12000.0

UL

TB

siz

e (b

its)

UL SG UL TBS


0

5

10

15

20

25

30

35

40

16:45:07 16:48:00 16:50:53 16:53:46 16:56:38 16:59:31 17:02:24

UL

No

ise

Ris

e (

dB

)

0

1

2

3

4

5

6

7

8

Ap

plic

ati

on

th

rou

gh

pu

t U

L (

Mb

ps

)

Noise rise NonHSPA NR App thru UL

HSUPA throughput with different (field test) PrxMaxTargetBTS values• High values (20 dB, 30 dB) cause lot of variation on uplink noise and

application throughput– Performance degradation of all users in cell

• High values (20 dB, 30 dB) increase also the nonHSPA noise caused by DPCCH+HS-DPCCH– Admission control and RNC packet scheduling

2 dB

4 dB

6 dB

8 dB

10 dB

12 dB

20 dB

30 dB30 dB


Content

• HSPA+ features


– HSUPA 2ms TTI




– LTE Interworking





Background HSUPA 2ms

• 3GPP Release 6 introduces both 10 ms and 2 ms TTI for HSUPA

• NSN RAS06 and RU10 support only the 10 ms TTI– 10 ms TTI improves cell edge performance

• NSN RU20 introduces support for the 2 ms TTI– 2 ms TTI reduces latency (original transmission and re-transmissions)

– 2 ms supports increased peak throughputs

• UL SRB are mapped onto– HSUPA when using the 2 ms TTI

– DCH when using the 10 ms TTI (NSN implementation)

• Mapping SRB onto HSUPA is mandatory for the 2×SF2 + 2×SF4 configuration– DPDCH code is blocked by E-DPDCH codes

• Downlink SRB remains on DCH


Channels and Downlink Code Tree

• Introduction of HSUPA 2 ms TTI requires the use of a second E-AGCH

• E-RGCH & E-HICH

• 2 ms and 10 ms HSUPA connections can share the same SF128 code

• Example scenario assumes no HSDPA code multiplexing, i.e. single HS-SCCH

• Code set blocks single SF16 code (Cch,16,0)

• Requirement increases when HSDPA code multiplexing is used

HSUPA 2ms

Cch,256,0

Cch,256,1

Cch,256,2

Cch,256,3

Cch,128,4

Cch,128,5

CPICH

P-CCPCH

AICH

PICHCch,64,1

S-CCPCH 1

HS-SCCH

E-HICH & E-RGCH

Cch,16,0

E-AGCH 2 msCch,256,12

Cch,256,13

E-AGCH 10 ms


E-DCH Absolute Grant Channel HSUPA 2ms

• E-AGCH is sent by the serving HSUPA cell

• Transfers a total of 6 bits per 2 ms subframe:

• Absolute Grant Value (5 bits)

• Absolute Grant Scope (1 bit) – only applicable to 2 ms TTI

• Value signals the transmit power that is allowed for the E-DPDCH relative to the DPCCH

• Scope indicates whether the grant applies to a single HARQ process or to all HARQ processes

• E-RNTI is used to mask the CRC bits

• SF256 used

• 2 ms TTI: 60 coded bits occupy the TTI

• 10 ms TTI: 60 coded bits are repeated 5 times to occupy the TTI

• Introduction of HSUPA 2 ms TTI requires the use of a second E-AGCH• Both E-AGCH are configured during cell setup and

remain as static code allocations


E-DCH Relative Grant Channel

• E-RGCH can be sent by each active set cell

• Cells belonging to the serving radio link set may command up, down and hold

• Other cells are only able to command down and hold

• Channelisation code with SF128 is allocated during cell setup

• 40 orthogonal signatures are defined to allow multiple UE to share the same channelisation code


• E-RGCH can occupy:

• 2 ms TTI serving RLS => 3 timeslots (1 subframe 2 ms)

• 10 ms TTI serving RLS => 12 timeslots (4 subframes 8 ms)

• non-serving RLS => 15 timeslots (1 radio frame 10 ms)

• RRC layer configures a ‘Signature Sequence Index’ to define a signature sequence hopping pattern which is repeated every 3 timeslots

HSUPA 2ms

2 ms TTI has reduced air-interface redundancy

Equal redundancy at non-serving RLS


E-DCH HARQ Indicator Channel

• E-HICH is a dedicated downlink channel using SF 128

• Can share the same channelisation code as the E-RGCH

• 40 orthogonal signature sequences are used to transfer up to 40 E-HICH and E-RGCH with a single SF=128 channelisation code


• Transmitted by all active set cells

• Transfers E-DCH HARQ acknowledgments

• UE continues to re-transmit until an ACK is received from at least one cell

• Single bit representing ACK/NACK is spread over the 3 or 12 timeslots

• 2 ms TTI: ACK/NACK occupies one 2 ms sub-frame (3 timeslots)

• 10 ms TTI: ACK/NACK occupies four 2 ms sub-frames (12 timeslots)

HSUPA 2ms


Selection of 2 ms TTI (I)• The TTI selection procedure is triggered during:

– uplink channel type selection (DCH vs E-DCH)– an ongoing existing HSUPA connection (TTI switching)– RAB establishment or release (TTI switching)

• The 2 ms HSUPA TTI is selected if:– HSUPA 2 ms TTI is enabled by the HSUPA2MSTTIEnabled parameter– UE supports 2 ms TTI– RAB combination supports SRB on HSUPA– the selection is from CELL_DCH then the CPICH RSCP of the HSPA serving

cell must satisfy:

HSUPA 2ms

PtxPrimaryCPICH - CableLoss – Meas CPICH RSCP < CPICHRSCPThreEDCH2MS + MAX(0, UETxPowerMaxRef - P_MAX)*

• the selection is from CELL_FACH then the CPICH Ec/Io of current cell must satisfy:

Meas CPICH Ec/Io > CPICHECNOThreEDCH2MS

set to 0 dB if no MHA


Selection of 2 ms TTI (II)

• If the 2 ms TTI allocation fails due to any of the active set cells and the active set size is more than one then a new attempt is not re-attempted until the cell which caused the failure has been removed from the active set

• If the 2 ms TTI allocation fails when the active set size is 1, a penalty time of 6 seconds is applied before a new attempt.

HSUPA 2ms

CPICHRSCPThreEDCH2MS

(RNC)


50 to 160 dB, step 1 dB

Default

136 dB This parameter defines the coverage area of the E-DCH TTI 2ms within the HSPA serving cell. The HSPA serving cell path loss must be lower than set by this parameter, otherwise the use of E-DCH TTI 2 ms is not possible.

CPICHECNOThreEDCH2MS

(RNC)


-24 to 0 dB, step 1 dB

Default

-6 dB This parameter defines the coverage of the E-DCH TTI 2 ms within the HSPA serving cell. This is used during the state transition from CELL_FACH, CELL_PCH, and CELL_URA to CELL_DCH state.


Requirements

UE Requirements

• UE must be HSUPA category 2, 4, 6 or 7






• The following feature must be enabled:

• HSUPA

HSUPA 2ms



UE Categories

• UE categories 2, 4, 6 and 7 support the 2 ms TTI

• UE categories, 2, 4 and 6 have larger maximum transport block sizes specified for 10 ms TTI, but transport block can be transferred 5 times less frequently

• UE category 7 has a larger transport block size specified for 2 ms TTI as a result of the support for 16QAM (16QAM only applicable to 2 ms TTI)

HSUPA 2ms

QPSK only

QPSK & 16QAM


E-TFCI Tables (I) HSUPA 2ms

• E-TFCI table defines the mapping between E-TFCI and transport block size

• RNC signals the E-TFCI table index to the Node B and UE

• UE uses the E-TFCI to signal the transport block size within the E-DPCCH

• 3GPP release 6 version of 25.321 specifies the E-TFCI table shown below

2 ms TTI 10 ms TTI

Table 0 Table 1 Table 0 Table 1

Optimal MAC-d PDU Sizes Arbitrary 168, 336 Arbitrary 168, 336

Maximum TB Size 11 484 11 478 20 000 19 950

• 3GPP release 7 version of 25.321 specifies 2 additional E-TFCI tables

• 2 additional tables are applicable to 16QAM (not supported in RU20)

Table used for RAS06 and RU10

2 ms TTI 10 ms TTI

Table 0 Table 1 Table 2 Table 3 Table 0 Table 1

Optimal MAC-d PDU Sizes Arbitrary 168, 336 Arbitrary 168, 336 Arbitrary 168, 336

Maximum TB Size 11 484 11 478 22 995 22 996 20 000 19 950

Table used for 2 ms TTI in RU20

Table used for 10 ms TTI in RU20


E-TFCI Tables (II) HSUPA 2ms

• RU20 uses a fixed MAC-d PDU size of 336 bits for user plane data and 144 bits for the SRB

• The combination of these two PDU sizes means that table 0 is more optimal than table 1, i.e. reduces the requirement for padding

• Maximum transport block size of 11484 bits corresponds to a peak physical layer throughput of 11484/0.002 = 5.742 Mbps



HSUPA2MSTTIEnabled

(WCEL)



Default

0 (Disabled)

• The HSUPA2MSTTIEnabled parameter must be set to enabled


This parameter enables/disables the use of E-DCH 2ms TTI in the cell. When the value of the parameter is set to 1, the HSUPA 2 ms TTI functions are enabled for the cell. If the parameter is enabled (1), the system checks that the license of the HSUPA 2 ms TTI feature is active (state "On" and exist). If not, this is informed by appropriate configuration error and parameter value change to enabled is not allowed.

• Enabling the HSUPA 2 ms TTI requires that:

• HSDPA is enabled using the WCEL-HSDPAenabled parameter

• HSUPA is enabled using the WCEL-HSUPAEnabled parameter

• NBAP is configured as WBTS using the WBTS-NBAPCommMode paramater

HSUPA 2ms


Content

• HSPA+ features


– HSUPA 2ms TTI









Background (I) 24kbps PCH

Paging Type 1 message

maxPage = 8

3GPP allows up to 8 paging records per paging message

Up to 7 paging records??

• RAS06 and RU10 support a PCH bit rate of 8 kbps– transport block size of 80 bits

– TTI of 10 ms

– PCH bit rate of 8 kbps limits the capacity of paging message to a single paging record, i.e. a single paging record can be broadcast per 10 ms TTI

• RU20 supports PCH bit rates of 8 and 24 kbps

• The 24 kbps PCH is based upon– Transport block size of 240 bits

– TTI of 10 ms


Requirements

UE Requirements

• None


• None


• None

• The 24 kbps Paging Channel feature is optional and requires an ON/OFF RNC license

24kbps PCH



PCH24kbpsEnabled

(WCEL)



Default

0 (Disabled)

• The PCH24kbpsEnabled parameter must be set to enabled

• Parameter requires object locking to modify

This parameter is used for enabling\disabling 24kbps Paging channel at a cell level.

• The NbrOfSCCPCHs parameter must be configured with a value greater than 1

24kbps PCH



NbrOfSCCPCHs

(WCEL)


1 to 3, step 1

Default

1

• The NbrOfSCCPCHs parameter should be configured with a value of:

• 2 if SAB is not being used

• 3 if SAB is being used

• Parameter requires object locking to modify

This parameter defines how many SCCPCHs are configured for the cell. If only one SCCPCH is used, it carries FACH-c, FACH-u, and PCH. If two SCCPCHs are used, the first SCCPCH always carries only PCH, and the second SCCPCH always carries FACH-u and FACH-C. If three SCCPCHs are used, the third SCCPCH carries FACH-s and FACH-c-idle. The third SCCPCH is needed only if SAB is available.

24kbps PCH


S-CCPCH Configuration 1

• This configuration limits the PCH bit rate to 8 kbps

• The PCH is multiplexed with the FACH-u and FACH-c

• The PCH always has priority

• SF64 is required to transfer the FACH-u and FACH-c bit rates

Logical channel

Transport channel

Physical channel

DTCH DCCH CCCH BCCH PCCH

FACH-u FACH-c PCH

SCCPCH 1

SF 64

24kbps PCH


S-CCPCH Configuration 2a

Logical channel

Transport channel

Physical channel


FACH-u FACH-c PCH

SCCPCH 1 SCCPCH 2

SF 64 SF 256

• PCH24kbpsEnabled is configured to disabled with this configuration

• Limits the PCH bit rate to 8 kbps

• The PCH is allocated its own S-CCPCH

• SF256 is allocated to the PCH as a result of the low bit rate

24kbps PCH


S-CCPCH Configuration 2b

Logical channel

Transport channel

Physical channel


FACH-u FACH-c PCH

SCCPCH 1 SCCPCH 2

SF 64 SF 128

• PCH24kbpsEnabled is configured to enabled with this configuration

• Increases the PCH bit rate to 24 kbps


• SF128 is allocated to the PCH to support the increased bit rate

24kbps PCH


S-CCPCH Configuration 3a

• PCH24kbpsEnabled is configured to disabled with this configuration

• Limits the PCH bit rate to 8 kbps


• SF256 is allocated to the PCH as a result of the low bit rate

24kbps PCH

Logical channel

Transport channel

Physical channel

DTCH DCCH CCCH BCCH CTCH

FACH-u PCHFACH-s

SCCPCH connected

SCCPCH idle

PCCH

FACH-c FACH-c

SCCPCH page

SF 64 SF 128 SF 256


S-CCPCH Configuration 3b

• PCH24kbpsEnabled is configured to enabled with this configuration

• Increases the PCH bit rate to 24 kbps


• SF128 is allocated to the PCH to support the increased bit rate

24kbps PCH

Logical channel

Transport channel

Physical channel

DTCH DCCH CCCH BCCH CTCH

FACH-u PCHFACH-s

SCCPCH connected

SCCPCH idle

PCCH

FACH-c FACH-c

SCCPCH page

SF 64 SF 128 SF 128


S-CCPCH Slot Format

• Slot format 4 is used for the S-CCPCH when supporting the 24 kbps PCH

• Provides a bit rate of 60 kbps at the bottom of the physical layer

No TFCI bitsNo Pilot bits

24kbps PCH


Code Allocation

• Channelisation code for 24 kbps PCH uses a larger section of the code tree

• HSDPA cannot use 15 HS-PDSCH codes when HSUPA 2 ms TTI is enabled with 24 kbps PCH

• Requirement for 2nd E-AGCH code

• Requirement for F-DPCH code

Cch,256,0

Cch,256,1

Cch,256,2

Cch,256,3

Cch,128,4

Cch,128,5

CPICH

P-CCPCH

AICH

PICHCch,64,1

Cch,256,14

S-CCPCH 1

E-AGCH

HS-SCCH

E-HICH & E-RGCH

S-CCPCH 2

Cch,128,6

Cch,16,0

24kbps PCH


PtxSCCPCH2SF128

(WCEL)


-35 to 15 dB, step 0.1 dB

Default

-2 dB The parameter defines the transmission power of the S-CCPCH channel that carries only a 24 kbps PCH (containing PCCH). This parameter is not needed if a PCH and FACHs are multiplexed into the same S-CCPCH or if 8 kbps PCH is used. The spreading factor of this S-CCPCH is 128 (30 ksps), and the proposed default value for this S-CCPCH channel is -2 dB. The transmission power value is relative to the CPICH transmission power.

24kbps PCH

• The transmit power of the S-CCPCH is defined using the parameters:

• PtxSCCPCH1, PtxSCCPCH2, PtxSCCPCH3

• PtxSCCPCH2SF128

• The PtxSCCPCH2SF128 parameter defines the transmit power of the S-CCPCH used to transfer the 24 kbps PCH

• All parameters define the transmit power of the data bits (rather than the transmit power of the TFCI and Pilot bits)

S-CCPCH Transmit Power


Effect on total CCCH power

??


Content

• HSPA+ features


– HSUPA 2ms TTI









Background FAST L1 SYNC

• Fast L1 synchronisation is a 3GPP change to the release 6 version of the specifications, i.e. it is only applicable to release 6 and newer UE

• Feature reduces connection establishment time by allowing the UE to start transmitting sooner

• UE starts to transmit as soon as downlink chip and frame synchronisation has been achieved rather than waiting until after N312 in-sync primitives have been generated– Benefit of reduced connection establishment delay

– Potential drawback of transmitting when synchronisation is unreliable

• Connection establishment delay is reduced by at least 40 ms

• Greater reductions are achieved when N312 is greater than 1

• Feature is applicable to:– RRC connection establishment

– RRC state transition from CELL_FACH to CELL_DCH

– Hard handovers


Requirements

UE Requirements

• UE must be 3GPP release 6 or newer


• None


• None

• Feature is included as part of the basic software and does not require a license

FAST L1 SYNC



PostVerifPeriodDLSynch

(RNC)



Default

1 (Enabled)

• The PostVerifPeriodDLSynch parameter must be set to enabled

• Default value of the parameter is enabled

Determines whether or not post-verification is used in the downlink chip and frame synchronization. A post-verification period can be used with the physical layer synchronization procedure A when the first radio link set is established for the UE. If the post-verification period is used, the UE starts transmission on uplink immediately when it initiates the downlink dedicated physical channel establishment. If the post-verification period is not used, the UE does not transmit on uplink until the downlink physical channel is established. If enabled with the parameter, the post-verification period is applied to the Rel-06 and later UEs.

• The PostVerifPeriodDLSynch parameter can be changed online without cell locking

FAST L1 SYNC


• Example below shown for N312 = 4

• Total delay before UE is able to start transmitting is greater than 70 ms

• Assumes that UE is in good coverage and in-sync primitives are generated on every occasion

Node B starts transmitting

UE starts receiving

1st in-sync primitive

2nd in-sync primitive

3rd in-sync primitive

40 ms window

40 ms window

40 ms window

Without Post Verification FAST L1 SYNC

4th in-sync primitive

40 ms window

UE starts transmitting

10 ms radio frames

Delay while UE receives RRC Connection Setup message on the FACH


• UE transmit timing no longer depends upon N312

• Total delay before UE is reduced by 70 ms

• UE stops transmitting after 40 ms if the post verification fails

Node B starts transmitting

Post verification check

40 ms window

With Post Verification FAST L1 SYNC

UE starts transmitting

UE starts receiving

UE stops transmitting if verification check fails

10 ms radio frames


Content

• HSPA+ features


– HSUPA 2ms TTI









Background 72 HSPA

• RU10 provides support for:– 64 HSDPA users per cell

– 20 HSUPA users per cell

• RU20 ‘RAN1686 HSPA 72 Users per Cell’ feature provides support for:– 72 HSDPA users per cell

– 72 HSUPA users per cell

– 160 HSPA users per Local Cell Group (LCG)

• In both cases, HSUPA requires HSDPA to be allocated

• The increase in HSUPA connections requires the allocation of additional codes for the E-RGCH/E-HICH

• This feature also provides support for a 4th HS-SCCH allowing up to 4 UE to be code multiplexed during the same 2 ms TTI


Requirements

UE Requirements

• None



Feature Requirements• HSDPA Dynamic Resource Allocation must be enabled

• Node B must support Continuous Packet Connectivity (CPC)


72 HSPA



HSPA72UsersPerCell

(WCEL)



Default

0 (Disabled)

• The HSPA72UsersPerCell parameter must be set to enabled

• This parameter requires object locking for modification

This parameter determines whether the “HSPA 72 users per cell“ feature is enabled in the cell or not. If this feature is enabled, maximum 72 HSDPA and 72 HSUPA users can be supported per cell.

Cell specific parameter MaxNumberHSDPAUsers limits the max. number of HSDPA users in the cell. If the value is < 72, and HSPA72UsersPerCell value is "Enabled", the value of MaxNumberHSDPAUsers should be considered as the max. number of HSDPA users.The cell specific parameter MaxNumberEDCHCell limits the max. number of HSUPA users in the cell. When the HSPA72UsersPerCell value is "Enabled", the minimum value of MaxNumberHSDPAUsers, MaxNumberEDCHCell and 72 should be considered as the maximum number of HSUPA users that can be supported per cell.

72 HSPA


Admission Control 72 HSPA

• If the HSPA72UsersPerCell parameter is set to enabled then the range of:– MaxNumberEDCHCell increases from (1 to 20) to (1 to 72)

– MaxNumberEDCHLCG increases from (1 to 24) to (1 to 160)

– The MaxNumberHSDPAUsers parameter already has a range from 1 to 255

• RNC Admission Control allows up to 72 HSDPA users per cell when the HSPA72UsersPerCell parameter is set to enabled– If MaxNumberHSDPAUsers or MaxNumberHSDSCHMACdflows is configured

with a value less than 72 then it limits the number of HSDPA connections

• RNC Admission Control allows up to 72 HSUPA users per cell when the HSPA72UsersPerCell parameter is set to enabled– If MaxNumberEDCHCell is configured with a value less than 72 then it limits the

number of HSUPA connections

– If MaxNumberEDCHLCG is configured with a value less than 160 then it limits the number of HSUPA connections


HS-SCCH Code Allocation

• The number of HS-SCCH is set using the MaxNbrOfHSSCCHCodes parameter

• The range of this parameter increases from (1 to 3) to (1 to 4) if the ‘HSPA 72 Users per Cell’ feature is licensed

• HS-SCCH codes are allocated during cell start-up

• The specified number of HS-SCCH codes are fixed at the positions shown below

• The configuration of more than a single HS-SCCH does not necessarily prevent the use of 15 HSDPA codes

• the Node B decides whether to use 1 to 4 HS-SSCH codes depending upon whether or not code multiplexing is used during a specific TTI

72 HSPA

SF16,0 SF16,1

CP

ICH

P-C

CP

CH

AIC

H

PIC

H

S-C

CP

CH

HS

-SC

CH

1

E-R

GC

H/

E-H

ICH

1

HS

-SC

CH

2

HS

-SC

CH

3

HS

-SC

CH

4

E-A

GC

H 1

0 m

s

E-A

GC

H 2

ms


E-HICH/E-RGCH Allocation (I)

• The number of E-RGCH/E-HICH codes is

• 1 if HSPA72UsersPerCell = ‘disabled’

• 1 to 4 if HSPA72UsersPerCell = ‘enabled’

• The RNC configures the appropriate number of E-RGCH/E-HICH codes

• A single E-RGCH/E-HICH code is allocated during cell start-up

• Further E-RGCH/E-HICH codes are allocated dynamically

72 HSPA

SF16,0 SF16,1

CP

ICH

P-C

CP

CH

AIC

H

PIC

H

S-C

CP

CH

HS

-SC

CH

1

E-R

GC

H/

E-H

ICH

1

HS

-SC

CH

2

HS

-SC

CH

3

HS

-SC

CH

4

E-A

GC

H 1

0 m

s

E-A

GC

H 2

ms


Content

• HSPA+ features


– HSUPA 2ms TTI








Background (I) COM CH STP

• Common Channel Setup allows connections to be established in CELL_FACH rather than CELL_DCH, i.e. using RRC Idle to CELL_FACH transition

• This allows some connections to completely avoid using CELL_DCH, e.g. location area updating procedure

• Avoiding the use of CELL_DCH removes the requirement for

• NBAP Radio Link Setup signalling

• AAL2 connection establishment (saving on both CID and ATM bandwidth reservation)

• dedicated Node B baseband processing

• dedicated spreading codes

• Avoiding the use of CELL_DCH also helps to reduce RNC ICSU processing load

CELL_DCH CELL_FACH

RRC IDLE

Conversational cause, e.g. speech, uses CELL_DCH but SRB bit rate

can be configured per cause

RRC IDLE

Registration cause for a signalling procedure can avoid

using CELL_DCH

CELL_DCH CELL_FACH

RRC IDLE

Registration cause for a data connection can subsequently

move to CELL_DCH

CELL_DCH CELL_FACH


Background (II) COM CH STP

• The Common Channel Setup feature also allows the 13.6 kbps SRB to be allocated on a per RRC Request cause value

• Connection establishment on the common channels is potentially faster than on CELL_DCH

• RACH-c and FACH-c bit rates greater than DCH SRB bit rates

• Radio Link Setup followed by Radio Link Reconfiguration is replaced with just a Radio Link Setup (when making the transition, RRC Idle -> CELL_FACH -> CELL_DCH)

• Call setup time is increased when the common channels become congested

• The Common Channel Setup feature increases the RACH/FACH load so increased emphasis should be placed upon monitoring the load after enabling the feature

• Connection types with high QoS requirements should still be established in CELL_DCH to avoid potential congestion on the common channels, i.e. DCH provides higher QoS than the common channels

• The Common Channel Setup feature also removes the configuration of the optional SRB4 (low priority NAS signalling)

• simplifies the configuration and reduces the size of the messages used to establish a connection


Requirements

UE Requirements

• None


• None


• None

• The Common Channel Setup feature is optional and requires a cell capacity based license for a specific number of cells

COM CH STP



CCHSetupEnabled

(WCEL)



Default

0 (Disabled)

• The CCHSetupEnabled parameter must be set to enabled

• This parameter can be modified online without the requirement for object locking

This parameter enables / disables the use of RRC connection setup on Common Channels (CCHSetup).

When the value of the parameter is set to 1 (CCHSetup is enabled for the cell).

COM CH STP



RRCSetupCCHEnabledR99

(RNC)



Default

0 (Disabled)

• The RRCSetupCCHEnabledR99 parameter must be set to enabled if the feature is to be enabled for release 99 UE

• Release 99 UE have separate parameter to enable the feature because there is a risk that some older UE do not support connection establishment in CELL_FACH

This parameter defines whether RRC connection setup for R99 UEs is allowed to be performed on common channels (CCH). If the value of this parameter is disabled, RRC connection setup is performed on dedicated channel (DCH) despite of the value of the Establishment Cause information element in the RRC message RRC Connection Request. If value of this parameter is enabled and the value of the Establishment Cause information element is interpreted so (parameter SRBMapRRCSetupEC), RRC connection setup can be performed on common channels.The parameter SRBMapRRCSetupEC defines preferred channel type in the RRC connection setup, either common or dedicated channel.

COM CH STP


Decision Making Process

Setup on CCH preferred for this establishment cause?

RACH and FACH Load ok?

CPICH Ec/Io ok?

Ptx_Total ok?

If Rel99 UE, then Setup on CCH is allowed?

If Rel7 UE, then Setup on HSPA/DCH not preferred?

NO

RNC receives RRC Connection Request

SRB mapped onto 13.6 kbps DCH?

NOYES

RRC Idle -> CELL_FACH

YES

RRC Idle -> CELL_DCH

SRB mapped onto HSPA?

Check Directed RRC Setup algorithm for

appropriate RF carrier

SRB on HSPA

SRB on 13.6 kbps DCH

SRB on 3.4 kbps DCH

SRB on RACH/FACH

YES NO

COM CH STP

• Four possible outcomes:

• SRB on RACH/FACH

• SRB on HSPA

• SRB on 3.4 kbps DCH

• SRB on 13.6 kbps DCH

• Mapping SRB onto HSPA requires F-DPCH to be enabled


Establishment Causes for Common Channel Setup

SRBMapRRCSetupEC

(WCEL)


Bit 0: Orig conv.Bit 1: Orig streamingBit 2: Orig interactiveBit 3: Orig backgroundBit 4: Orig subscribedBit 5: Term conversationalBit 6: Term streamingBit 7: Term interactiveBit 8: Term backgroundBit 9: Emerg call (always 0)Bit 10: Inter-RAT cell re-selBit 11: Inter-RAT cell changeBit 12: RegistrationBit 13: DetachBit 14: Orig high priority sig.Bit 15: Orig low priority sig.Bit 16: Call re-establishmentBit 17: Term high priority sig.Bit 18: Term low priority sig.Bit 19: Term cause unknownBit 20: MBMS receptionBit 21: MBMS ptp RB request

Default

• The SRBMapRRCSetupEC parameter defines the establishment causes for which the RNC attempts common channel setup

This parameter defines the Establishment Cause (EC) values which prefer SRB mapping to the common channels in the RRC connection setup. The value 0 means that the corresponding Establishment Cause prefers SRB mapping to the dedicated channel (DCH) or to the high speed packet access (HSPA, that is, on HS-DSCH/E-DCH). The value 1 means that the corresponding Establishment Cause prefers SRB mapping to the common channels. Bit 9: Emergency call does not effect, SRBs of emergency call are always mapped to DCH in the RRC connection setup.

0000000000111111011000

COM CH STP


Establishment Causes for 13.6 kbps SRB (II)

COM CH STP

• The StandaloneDCCHBitRate parameter is deleted in RU20

• This parameter previously provided a mechanism for enabling/disabling 13.6 kbps DCH SRB for all establishment causes

• StandaloneDCCHBitRate is replaced by SRBBitRateRRCSetupEC


Interaction with Directed RRC Connection Setup

• Common Channel Setup pre-empts the decision for Directed RRC Connection Setup

• If a UE triggers the transition from RRC Idle to CELL_FACH then the Directed RRC Connection Setup algorithm is not applied

• If a UE subsequently triggers the transition from CELL_FACH to CELL_DCH then the Common Channel Layer for HSDPA algorithm is applied

COM CH STP


Content

• HSPA+ features


– HSUPA 2ms TTI








Background DRA HSPA

• Prior to RU20– a 0/0 kbps DCH is allocated during NRT PS RAB establishment in CELL_DCH– subsequently upgraded to HSPA when a capacity request is received– Likewise, RAB establishment in CELL_FACH does not allocate user plane radio

resources

• Direct Resource Allocation for HSPA allocates HSPA during RAB establishment

• Applicable to RAB establishment in both CELL_DCH and CELL_FACH• Reduces connection establishment delay• Improves end-user experience for applications which require immediate

data transfer

• Direct resource allocation for HSPA is applicable to– PS NRT connections (interactive or background traffic classes)– HSPA connections, and not HSDPA or DCH connections


Requirements

UE Requirements

• None


• None


• None

• Direct Resource Allocation for HSPA is included as part of the basic RU20 software and does not require a license

DRA HSPA



RABDRAEnabled

(RNC)


0 (Disabled),

1 (Enabled in Cell_FACH),

2 (Enabled in Cell_DCH),

3 (Enabled in Cell_FACH and Cell_DCH)

Default

0 (Disabled)

• The RABDRAEnabled parameter must be set to a value greater than 0

The parameter enables/disables the use of the DRA for HSPA. It also defines whether the DRA for HSPA is applied in Cell_FACH state, Cell_DCH state or both. If the feature is enabled, HS-DSCH and E-DCH allocation is tried for PS data of interactive and background traffic classes during the NRT RAB setup phase as follows:

Direct resource allocation is applied in the case of full HSPA (HS-DSCH/E-DCH and F-DPCH allocated) irrespective of the value of this parameter.

• RABDRAEnabled parameter provides control over which RRC states the feature is enabled

• The feature is always enabled for HSPA connections using the F-DPCH

DRA HSPA


Signalling phases

RRC connection Setup

GPRS Service request + Security

PDP Context Activation request

RAB assignment request

Radio Bearer Setup 0/0 (No UP)

Radio bearer Setup complete

RAB assignment Response

PDP context Activate accept

TVM start

Measurement Report (TVM)

RB Reconfiguration to HSPA

RB Reconfiguration Complete

HSPA bearer Setup for User traffic

RRC connection Setup

GPRS Service request + Security

PDP Context Activation request

RAB assignment request

Radio Bearer Setup to HSPA (direct)

Radio bearer Setup complete

RAB assignment Response

PDP context Activate accept

Measurement Control

TVM start if needed

HSPA bearer Setup for User traffic

Normal NRT RAB Setup HSPA Setup with DRA

DRA HSPA


Resource allocation

• If direct resource allocation fails as a result of congestion then connection establishment proceeds as in RU10, i.e. 0/0 kbps DCH is allocated for connection establishment in CELL_DCH, and traffic volume measurements are configured to trigger capacity requests

• Enhanced Priority based Scheduling (ePBS) represents NRT-over-NRT functionality– Serving RNC

direct resource allocation does not trigger NRT-over-NRT actions

– Drift RNC can not differentiate between capacity requests for direct resource allocation

and other capacity requests direct resource allocation can trigger NRT-over-NRT actions

DRA HSPA


Content

• HSPA+ features


– HSUPA 2ms TTI









Background (I)

• This feature allows the operator to automatically ‘shutdown’ cells during periods of low traffic

• power savings which translate to OPEX savings

• CPICH is gradually ramped down during shutdown procedure

• triggers inter-frequency or inter-system handovers

• ‘Shutdown’ cells can be automatically ‘re-activated’ when traffic increases

PWSM

Low traffic cell

Traffic moved

Cell shutdown


Background (II) PWSM

Complete RF carrier can be shutdown

Complete Node B can be shutdown

• Depending upon traffic levels and RNC databuild

• complete RF carrier can be shutdown

• complete Node B can be shutdown• If HSDPA layer is shutdown, then HSDPA can be automatically enabled on

another layer


Requirements

UE Requirements

• None


• None


• None

• The Power Saving Mode for BTS feature is optional and requires an ON/OFF RNC license

PWSM



PWSMInUse

(WBTS)


0 (OFF),

1 (ON)

Default

0 (OFF)

• The PWSMInUse parameter must be set to enabled

• Parameter can be modified online without object locking

The use of Power Saving Mode for BTS should be controlled in BTS level. By this parameter the Power Saving Mode (PWSM) feature can be set ON and OFF on BTS basis.

• Default value is OFF so enabling the feature requires the parameter to be changed

PWSM


Cells Groups

• Cells belonging to a PWSM BTS must be grouped using the PWSMCellGroup parameter (WCEL, range 0 to 6)

• Cell group typically corresponds to all cells belonging to a sector

• Up to 6 cell groups can be defined for each Node B

• If a cell belongs to a PWSM cell group:

• it can be targetted for shutdown and re-activation

• it can be a target cell for IFHO triggered by PWSM

• A PWSMCellGroup value of 0 indicates that the cell does not belong to a cell group

Cell Group = 1

RF Carrier 1

Cell Group = 3

Cell Group = 2

Cell Group = 1 Cell Group = 3

Cell Group = 2

Cell Group = 1 Cell Group = 3

Cell Group = 2

RF Carrier 2

RF Carrier 3

PWSM


Shutdown Order

• Cells within a PWSM cell group must be allocated a ‘shutdown order’ using the PWSMShutdownOrder parameter (WCEL, range 0 to 3)

• Value of:

• 1: cell is shutdown first

• 2: cell is shutdown second

• 3: cell is shutdown third

• Value of 0 means that the cell is categorised as a ‘Remaining Cell’

• Every cell group must have at least one ‘Remaining Cell’

• Remaining Cells are not shutdown as a result of low traffic but may be shutdown during pre-defined time intervals

Cell Group = 1Shutdown order = 2

‘Remaining Cells’

RF Carrier 1









RF Carrier 2

RF Carrier 3

PWSM


MORAN Scenario

• Multiple cell groups can be defined for each sector

• Allows the definition of cell groups per operator

• Shutdown order values are defined per cell group

Operator 1




PWSM










Operator 2


PWSMCellGroup

(WCEL)


0 to 6, step 1

Default

0 This parameter defines the Power Saving Mode (PWSM) cell group of a cell.

PWSMShutdownOrder

(WCEL)


0 to 3, step 1

Default

0 This parameter defines the shutdown and activation order inside one Power Saving Mode (PWSM) cell group.

PWSMShutdownRemCell

(WCEL)


0 (NO),

1 (YES)

Default

0 (NO) This parameter determines if a remaining cell can be shutdown or not.

Cell Groups and Shutdown Order PWSM

• The PWSMShutdownRemCell parameter determines whether or not a ‘Remaining Cell’ can be shutdown during a pre-defined time interval

• The PWSMCellGroup and PWSMShutdownOrder parameters are shown below


Shutdown of Remaining Cells (I) PWSM

• All of the following criteria must be satisfied for a ‘Remaining Cell’ to be shutdown.

• The set of criteria are checked once every 60 seconds.

1. PWSM feature is licensed and enabled (PWSMInUse parameter)

2. Shutdown of remaining cell allowed (PWSMShutdownRemCell parameter)

3. All cells within the PWSM cell group are in a working state

4. Day is as specified by PWSMWeekday parameter, or time is as specified by PWSMRemCellSDBeginHour, PWSMRemCellSDBeginMin, PWSMRemCellSDEndHour, PWSMRemCellSDEndMin parameters

5. The cell must belong to a PWSM cell group

6. There only ‘Remaining’ cells active within the cell group

7. No emergency calls and no Wireless Priority Service calls in the cell

9. No ongoing O&M operation in the cell


Shutdown of Remaining Cells (II) PWSM

• A Remaining cell can be shut down if the current day matches the value of the PWSMWeekday parameter

PWSMWeekday

(WBTS)


0 (None),

1 (Saturday),

2 (Sunday),

3 (Saturday and Sunday)

Default

0 (None) This parameter defines the days on which the remaining cells should be shut down at weekend.


PWSMRemCellSDEndHour

(WBTS)


0 to 23, step 1 hour

Default

6 hours This parameter defines the ending hour for the cell shutdown window in Power Saving Mode (PWSM) for the remaining cell.

Shutdown of Remaining Cells (III) PWSM

• If current day does not match the value of PWSMWeekday then Remaining cells can be shutdown within the time window defined by the parameters below

PWSMRemCellSDEndMin

(WBTS)


0 to 59, step 1 minute

Default

0 minutes This parameter defines the ending minute for the cell shutdown window in Power Saving Mode (PWSM) for the remaining cell.

PWSMRemCellSDBeginHour

(WBTS)



Default

22 hours This parameter defines the starting hour for cell shutdown window in Power Saving Mode (PWSM) for remaining cell.

PWSMRemCellSDBeginMin

(WBTS)



Default

0 minutes This parameter defines the starting minute for cell shutdown window in Power Saving Mode (PWSM) for remaining cell.


Shutdown of Non-Remaining Cells (I) PWSM

1. PWSM feature is licensed and enabled (PWSMInUse parameter)

2. All cells within the PWSM cell group are in a working state

3. The cell must belong to a PWSM Cell Group but must not be a Remaining cell

4. There must be at least one Remaining cell within the PWSM cell group

5. No emergency calls and no Wireless Priority Service calls in the cell

6. No ongoing O&M operation in the cell

7. If the PWSMDriftAllowed parameter is set to ‘NO’ and if there is a UE connected whose serving RNC is a different RNC then shutdown is not allowed

8. Time is within the window defined by the PWSMShutdownBeginHour, PWSMShutdownBeginMin, PWSMShutdownEndHour and PWSMShutdownEndMin parameters

9. The traffic within the cell must be sufficiently low, for a period of time defined by the PWSMDuration parameter

10. There must be sufficient spare capacity within the target cell

11. Cell must be the next cell to be shutdown according to PWSMShutdownOrder

12. If HSDPA is to be enabled in another cell as a result of the cell shutdown then enabling HSDPA in that cell must be successful for the shutdown to proceed

13. Channel type switching from HSPA to DCH must be successful for all UE connected to the cell to be shutdown

• All of the following criteria must be satisfied for a ‘Non-Remaining Cell’ to be shutdown. The set of criteria are checked once every 60 seconds.


PWSMShutdownEndHour

(WBTS)



Default

6 hours This parameter defines the ending hour for cell shutdown window in Power Saving Mode (PWSM).

Shutdown of Non-Remaining Cells (II) PWSM

• Time window for the shutdown of non-remaining cells is defined by the parameters shown below

PWSMShutdownEndMin

(WBTS)



Default

0 minutes This parameter defines the ending minute for cell shutdown window in Power Saving Mode (PWSM).

PWSMShutdownBeginHour

(WBTS)



Default

22 hours This parameter defines the starting hour for cell shutdown window in Power Saving Mode (PWSM).

PWSMShutdownBeginMin

(WBTS)



Default

0 minutes This parameter defines the starting minute for cell shutdown window in Power Saving Mode (PWSM).


PWSMDuration

(RNC)


1 to 30, step 1 Minutes

Default

5 minutes This parameter defines the time period when the shutdown criteria for low traffic have to be fulfilled in order to shutdown a cell.

PWSMDriftAllowed

(RNC)


0 (NO),

1 (YES)

Default

0 (NO) This parameter determines whether the cell shutdown is allowed with drifting UEs or not. If there are drifting UEs in a cell and the parameter has value NO, then the cell cannot be shutdown.

Shutdown of Non-Remaining Cells (III) PWSM

• Parameter below determines whether or not cell shutdown is allowed when there is a UE whose serving RNC is a different RNC

• Parameter below defines the time period during which the set of low traffic criteria must be satisfied for cell shutdown to be triggered


Low Traffic Criteria for Shutdown (I) PWSM

• The criteria for Real Time DCH are:

• the number of real time DCH within the cell must be less than the value assigned to the PWSMSDLimitRTDCH parameter

• the non-controllable downlink transmit power for real time DCH must be less than the value assigned to the PWSMSDPwrRTDCH parameter

PWSMSDPwrRTDCH

(WCEL)


0 to 50, step 1 dBm

Default

34 dBm This parameter defines the RT DCH Power limit used in cell shutdown decision.

PWSMSDLimitRTDCH

(WCEL)


0 to 128, step 1

Default

10 This parameter defines the limit for RT DCHs in cell to be shutdown.


Low Traffic Criteria for Shutdown (II) PWSM

PWSMSDLimitNRTDCH

(WCEL)


0 to 128, step 1

Default

10 This parameter defines the limit for NRT DCHs in cell to be shutdown.

• The criteria for Non-Real Time DCH is:

• the number of downlink non-real time DCH within the cell must be less than the value assigned to the PWSMSDLimitNRTDCH parameter


Low Traffic Criteria for Shutdown (III) PWSM

PWSMSDPwrRTHSDPA

(WCEL)


0 to 50, step 1 dBm

Default

34 dBm This parameter defines the RT HSDPA power limit used in cell shutdown decision.

PWSMSDLimitRTHSDPA

(WCEL)


0 to 300, step 1

Default

5 This parameter defines the limit for RT HSDPA amount for cell shutdown decision.

• The criteria for Real Time HSDPA connections are:

• the number of real time HSDPA connections within the cell must be less than the value assigned to the PWSMSDLimitRTHSDPA parameter

• the HSDPA transmit power for real time HSDPA connections must be less than the value assigned to the PWSMSDPwrRTHSDPA parameter

• Criteria are only applicable if HSDPA is enabled in the cell


Low Traffic Criteria for Shutdown (IV) PWSM

PWSMSDPwrNRTHSDPA

(WCEL)


0 to 50, step 1 dBm

Default

34 dBm This parameter defines the NRT HSDPA power per user margin for cell shutdown decision.

PWSMSDLimitNRTHSDPA

(WCEL)


0 to 300, step 1

Default

5 This parameter defines the limit for NRT HSDPA amount for cell shutdown decision.

• The criteria for Non-Real Time HSDPA connections are:

• the number of non-real time HSDPA connections within the cell must be less than the value assigned to the PWSMSDLimitNRTHSDPA parameter

• the HSDPA transmit power per user for non-real time HSDPA connections must be greater than the value assigned to the PWSMSDPwrNRTHSDPA parameter



Capacity Check on Target Cell (I) PWSM

• Capacity check is always completed for cell belonging to same Node B

• Cell is selected according to the value of the HOPI AdjiPriorityCoverage parameter

• Cell does not have to belong to the same PWSM cell group

• Cell can be different to RT and NRT connections

• These cells may not be the final cells upon which traffic is directed but are considered the highest probability target cells

• The capacity checks on the RT target cell are:

• the number of real time HSDPA connections within the cell must be less than the value assigned to the PWSMEXUsrLimit parameter

• the non-controllable downlink transmit power for RT DCH is less than the value assigned to the PWSMEXPwrLimit parameter

• The capacity check on the NRT target cell is:

• the number of non-real time HSDPA connections within the cell must be less than the value assigned to the PWSMEXUsrLimit parameter


Capacity Check on Target Cell (II) PWSM

• The parameters associated with the target cell capacity checks are shown below

PWSMEXPwrLimit

(WCEL)


0 to 50, step 1 dBm

Default

37 dBm This parameter defines the total power limit used in virtual admission control decision.

PWSMEXUsrLimit

(WCEL)


0 to 300, step 1

Default

5 This parameter defines the limit for RT HSDPA and active NRT HSDPA in cell for virtual AC decision. RT and NRT HSDPA user amount are compared separately to this parameter.

AdjiPriorityCoverage

(HOPI)


0 to 7, step 1

Default

0 The inter-frequency measurement procedure measures one frequency at a time. If there is more than one carrier frequency to be measured, the RNC selects a subset of inter-frequency neighbour cells (having the same UTRA RF channel number) which are measured first. The range of the parameter varies from zero to 7. Zero is the lowest and 7 the highest priority level.


CPICH Ramping Period

• The Cell Deletion procedure is used when shutting down a cell

• The CPICH is ramped down during a period defined by the ShutdownWindow parameter

• The gradual decrease of CPICH transmit power triggers soft handover branch deletion or inter-frequency/inter-system handover

• If there are UE in the cell after CPICH power ramp down, the RNC waits 1 s and then attempts to make a forced inter-frequency/inter-system handover

• Node B allows 10 s after power ramp down for forced handovers to complete

• Parameters which limit the number of users in Compressed Mode are ignored

• Inter-frequency handover is attempted prior to inter-system handover

• Inter-frequency handover is executed as soon as a neigbour cell is reported with the minimum CPICH Ec/Io and RSCP requirements

PWSM

ShutdownWindow

(WCEL)


5 to 45 s, step 5 s

Default

15 s This parameter defines the cell power ramp down duration for the CPICH, BCH and all other common physical and transport channels.


Handling HSPA (I) PWSM

• If the HSDPAenabled parameter has a value “enabled”, and the PowerSavingHSPAType parameter has a value “HSPA0” then HSDPA is not setup within that cell during initial cell start-up

• If the HSUPAenabled parameter has a value “enabled”, and the PowerSavingHSPAType parameter has a value “HSPA0” then HSUPA is not setup within that cell during initial cell start-up

PowerSaveHSPAType (WCEL)

Name Range

Description

0 (NoHSPA05ReConf), 1 (HSPA0), 2 (HSPA5)

Default

0

• HSPA0: A cell that is originally configured with no HSPA services. This cell can be reconfigured to provide HSPA services by PWSM for BTS feature when HSPA5 cells are shutdown due to low traffic. In activating original HSPA5 cells, the HSPA0 cells shall be reconfigured back to provide no HSPA services.

• HSPA5: A cell that is originally configured to provide HSPA services. The shutdown of this cell due to Power Saving Mode shall initiate the reconfiguration of an HSPA0 cell to provide HSPA services (i.e. reconfiguring a HSPA0 cell to modified HSPA5 cell).

• NoHSPA05ReConf: A cell that is configured according to HSPA parameters in controller DB. Power Saving Mode actions to this cell shall not initiate any HSPA05 reconfigurations.

When setting parameter PowerSaveHSPAType to value “HSPA0” in a cell there has to be at least one another cell in same Local Cell Group with PowerSaveHSPAType set to value “HSPA5”.


Handling HSPA (II) PWSM

• HSPA reconfiguration is allowed if:

• the Node B has cells on exactly 2 RF carriers

• all cells at the Node B belong to same PWSM cell group

• the value of the PWSMCellGroup parameter is not equal to 0

• all cells at the Node B belong to the same LCG

• Cells on one RF carrier all have PWSMShutdownOrder of 1 and PowerSaveHSPAType of “HSPA5”

• Cells on the other RF carrier all have PWSMShutdownOrder of 0 (remaining cells) and PowerSaveHSPAType of “HSPA0”

• HSDPA is enabled in all cells of the Node B using HSDPAenabled

• The remaining cells are not allowed to be shutdown i.e. the parameter PWSMShutdownRemCell has a value of ‘NO’ in all remaining cells


• Example scenario shown below

• HSDPA initially active on the second RF carrier

• Second RF carrier experiences low traffic

• HSDPA is enabled on first RF carrier

• First RF carrier is shutdown

PWSM

HSDPAenabled = enabled

PWSMShutdownOrder = 1

PowerSaveHSPAType = HSPA0

HSDPA Active

Cells shutdown

Handling HSPA (III)

HSDPAenabled = enabled

PWSMShutdownOrder = 0

PowerSaveHSPAType = HSPA0

HSDPA Inactive

HSDPA Active

F2

F1

F2

F1

PWSMCellGroup = 1


Re-Activation of Remaining Cells PWSM

1. Day is not as specified by PWSMWeekday parameter, and time is not as specified by PWSMRemCellSDBeginHour,

PWSMRemCellSDBeginMin, PWSMRemCellSDEndHour, PWSMRemCellSDEndMin parameters

2. No ongoing O&M operation in a cell

• All of the following criteria must be satisfied for a ‘Remaining Cell’ to be re-activated. The set of criteria are checked once every 60 seconds.

• Note that re-activation of Remaining Cells does not depend upon traffic because traffic is no longer loading the cell group, i.e. all cells within the cell group are shutdown


Re-Activation of Non-Remaining Cells PWSM

1. The traffic within the cell must be sufficiently high, for a period of time defined by the PWSMExceededTrafficDur parameter

2. No ongoing O&M operation in a cell

• All of the following criteria must be satisfied for a ‘Non-Remaining Cell’ to be re-activated. The set of criteria is checked once every 10 seconds.

PWSMExceededTrafficDur

(RNC)


10 to 300, step 10 seconds

Default

20 secs This parameter defines the time that at least one active cell in one Power Saving Mode (PWSM) cell group needs to have traffic criteria fulfilled in order to activate a previously shutdown cell.

• All traffic criteria have to be satisfied within a specific cell belonging to the PWSM cell group


High Traffic Criteria for Re-Activation (I) PWSM

• The criteria for Real Time DCH are:

• the non-controllable downlink transmit power for real time DCH must be greater than the value assigned to the PWSMAVLimitRTDCH parameter

PWSMAVLimitRTDCH

(WCEL)


0 to 50, step 1 dBm

Default

37 dBm This parameter defines the RT DCH power limit used in cell activation decision.


High Traffic Criteria for Re-Activation (II) PWSM

PWSMAVPwrRTHSDPA

(WCEL)


0 to 50, step 1 dBm

Default

37 dBm This parameter defines the RT HSDPA power limit used in cell activation decision.

PWSMAVLimitRTHSDPA

(WCEL)


0 to 300, step 1

Default

0 This parameter defines the limit for RT HSDPA amount for cell activation decision.

• The criteria for Real Time HSDPA connections are:

• the number of real time HSDPA connections within the cell must be greater than the value assigned to the PWSMAVLimitRTHSDPA parameter

• the HSDPA transmit power for real time HSDPA connections must be greater than the value assigned to the PWSMAVPwrRTHSDPA parameter



High Traffic Criteria for Re-Activation (III) PWSM

PWSMAVPwrNRTHSDPA

(WCEL)


0 to 50, step 1 dBm

Default

31 dBm This parameter defines the NRT HSDPA power per user limit for cell activation decision.

PWSMAVLimitNRTHSDPA

(WCEL)


0 to 300, step 1

Default

10 This parameter defines the limit for NRT HSDPA amount for cell activation decision.

• The criteria for Non-Real Time HSDPA connections are:

• the number of non-real time HSDPA connections within the cell must be greater than the value assigned to the PWSMAVLimitNRTHSDPA parameter

• the HSDPA transmit power per user for non-real time HSDPA connections must be less than the value assigned to the PWSMAVPwrNRTHSDPA parameter



Content

• HSPA+ features


• Other RU20 related changes


HSPA NRT over NRT (I) OTHER

• Applicable when QoS Aware HSPA Scheduling is enabled

• NRT-over-NRT for HSPA represents the HSPA equivalent of enhanced Priority based Scheduling for DCH

• HSPA NRT-over-NRT is triggered by– Maximum number of connections is reached

– Maximum Node B HSUPA capacity is reached

– Transport CID congestion

• Capability is enabled using the same parameter as for ePBS, i.e. PBSPolicy

• NRT-over-NRT is only applied when resources are required for a single service. In the case of multi-RAB, NRT-over-NRT is only applied after other RB are dropped.

• The victim candidates are found and prioritized in the following way:1. According to the IurPriority parameter

2. According to the PBSPolicy parameter

3. Accoding to the allocation time

4. According to QoS priority


Other features

• RAN1758 Multiple BSIC Identification– MaxBSICIdentTime

– MultipleBSICIdent

– Improve ISHO success rate and decrease compressed mode re-configurations in case of BSIC verification failure

• RAN1766, AMR capacity– AMRRABRNCMax

• DCHBitRateBalancing

OTHER


End of Module 1

RU20 Features and Parameters - Training

Documents

Transcript of RU20 Features and Parameters - Training