Huawei 2008 W-CDMA (UMTS) HSDPA RRM and parameters -- how to make HSDPA work better (very good)

Confidential Information of Huawei. No Spreading Without Permission

www.huawei.com

Copyright © 2008 Huawei Technologies Co., Ltd. All rights reserved.

HSDPA RRM and

Parameters


Page1Copyright © 2008 Huawei Technologies Co., Ltd. All rights reserved.

Contents

1. HSDPA Channel Type Mapping

2. HSDPA Code Resource Management

3. HSDPA Power Management

4. HSDPA Mobility Management

5. HSDPA Channel Switching

6. HSDPA Mac-hs Scheduling Algorithm

7. HSDPA TFRC Selection

8. HSDPA Flow control



Mapping signaling and traffic

onto HSDPA! UMTS network could provide multi-services such as CS service, PS service and signaling

! In most case, CS service with high requirement of transmission quality will be mapped

onto DCH

! PS service such as PS conversational service i.e. VOIP, streaming service, BE service and

signaling ) could be mapped onto HS-DSCH

! The following figure show mapping between service and bearer




onto HSDPA! PS conversational services may be mapped onto the DCH, HS-DSCH, or E-DCH

! If Voip channel type = DCH

" Both uplink and downlink are mapped onto DCH

! If Voip channel type = HSDPA

" Uplink is beared on DCH, downlink mapped onto HS-DSCH

! If Voip channel type = HSPA

" Uplink is beared on E-DCH, downlink mapped onto HS-DSCH

VoipChlType --- UL_DCH / DL_DCH, UL_DCH / DL_HS-PDSCH, UL_EDCH / DL_HSP-DSCH

MML: SET FRCCHLTYPEPARA

For Ps conversational service

VoIP stands for Voice over IP, a PS conversational service. It uses IP data packets

to encapsulate voice data and transports them on the IP network to

implement the conversational services.




onto HSDPA! During the setup of an RRC connection, the single SRB can be carried on the

CCH, DCH, HS-DSCH, or E-DCH

! If the selected channel type is FACH, the SRB is carried on the CCH in both

the uplink and the downlink

! If the selected channel type is DCH, then

" In the downlink, if Srb channel type RRC effect flag is set to TRUE and Srb

channel type is set to HSDPA or HSPA, the SRB is carried on the HS-DSCH;

otherwise, on the DCH

" In the uplink, if Srb channel type RRC effect flag is set to TRUE and Srb

channel type is set to HSPA, the SRB is carried on the E-DCH; otherwise, on the

DCH




onto HSDPA! SRB may be mapped onto the DCH, HS-DSCH, or E-DCH, RACH/FACH

!If SRB channel type = DCH

" Both uplink and downlink are mapped onto DCH

! If SRB channel type = HSDPA

" Uplink is mapped on DCH, downlink mapped onto HS-DSCH

! If SRB channel type = HSPA

" Uplink is mapped on E-DCH, downlink mapped onto HS-DSCH

Bandwidth allocation

Bearer types for SRB

SigChType --- FACH ,DCH-3.4kbps-signaling, DCH-

13.6kbps-signaling, DCH-27.2kbps-signaling

SrbChlType --- UL_DCH / DL_DCH, UL_DCH / DL_HS-

PDSCH, UL_EDCH / DL_HS-PDSCH


MML: SET RRCESTCAUSE

! With SRB over HSPA, call setup delay is reduced, moreover compared with SRB

over DCH , code resource is saved




onto HSDPA! During the setup of an RRC connection, the single SRB can be carried on the CCH, DCH,

HS-DSCH, or E-DCH

! If the selected channel type is FACH, the SRB is carried on the CCH in both the uplink and

the downlink

! If the selected channel type is DCH, then

" In the downlink, if Srb channel type RRC effect flag is set to TRUE and Srb

channel type is set to HSDPA or HSPA, the SRB is carried on the HS-DSCH; otherwise,

on the DCH

" In the uplink, if Srb channel type RRC effect flag is set to TRUE and Srb channel

type is set to HSPA, the SRB is carried on the E-DCH; otherwise, on the DCH

Bearer types for SRB SrbChlTypeRrcEffectFlag --- TURE, FALSE MML: SET FRCCHLTYPEPARA



Mapping signaling and traffic onto

HSDPA! PS streaming services can be mapped onto the DCH, HS-DSCH, or E-DCH

" The cell supports HSDPA

" PS_STREAMING_ON_HSDPA_SWITCH is selected

" If the maximum DL service rate is higher than or equal to DL streaming traffic

threshold on HSDPA

then PS streaming service is carried on the HS-DSCH. Otherwise, it is carried on the DCH

PS_STREAMING_ON_HSDPA_SWITCH --- Enable , DisableAlgorithm switch

for streaming

over HSPA

UlStrThsOnHsupa --- 8, 16, 32, 64, 128, 144, 256, 384kbps

Bit rate threshold

for streaming

over HSPA

PS_STREAMING_ON_E_DCH_SWITCH --- Enable , Disable

DlStrThsOnHsdpa --- 8, 16, 32, 64, 128, 144, 256, 384kbps MML: SET FRCCHLTYPEPARA

MML: SET CORRMALGOSWITCH

PS streaming services can be mapped onto the DCH, HS-DSCH, or E-DCH

" If the maximum UL service rate is higher than or equal to UL streaming

traffic threshold on HSUPA

" The cell supports HSUPA

" PS_STREAMING_ON_E_DCH_SWITCH is selected

then the service is carried on the E-DCH. Otherwise, the service is carried on the DCH




onto HSDPA! The IMS signaling can be mapped on the DCH, HS-DSCH, or E-DCH

! If IMS channel type = DCH

" Both uplink and downlink are mapped on DCH

! If IMS channel type = HSDPA

" Uplink is mapped on DCH, downlink mapped on HS-DSCH

! If IMS channel type = HSPA

" Uplink is mapped onto E-DCH, downlink mapped on HS-DSCH

Bearer types for IMS

signaling

ImsChlType --- UL_DCH / DL_DCH, UL_DCH / DL_HS-

PDSCH, UL_EDCH / DL_HS-PDSCH


IMS signaling (SIP SDP) is an PS RAB to UTRAN, and only setup on DCH and use the fixed

configuration before RAN10.0

SIP / SDP characteristics based on Huawei research

- The traffic in the SIP/SDP setup phase is about 70Kbits and the setup time is generally less

than 3s, therefore, mean bit rate is 23.3Kbps

- Very low traffic exists on SIP / SDP after connection establishment

It is more suitable for HSPA to bear IMS Signaling

UTRAN PS

Domain

IMS PS

Domain

UTRAN

)

UE UTRAN PS

Domain

IMS PS

Domain

UTRAN

Session control Signaling (SIP / SDP)

Media ( RTP)

UE

Real Time Media Control (RTCP)

UE UE




onto HSDPA! PS interactive and background services (i.e. BE service) can be mapped onto the

CCH, DCH, HS-DSCH, or E-DCH

" Low-rate PS services have relatively small amount of data. Therefore, such PS

services can be carried on the CCH to save radio resources

# If the maximum DL service rate is lower than DL BE traffic DCH decision threshold, the

maximum UL service rate is lower than UL BE traffic DCH decision threshold, and the RRC

connection is set up on the CCH, then the service is carried on the CCH.

" Otherwise, further decision need to be made as follows:

# If the maximum DL service rate is higher than or equal to DL BE traffic threshold on HSDPA,

then the service is carried on the HS-DSCH. Otherwise, the service is carried on the DCH

# If the maximum UL service rate is higher than or equal to UL BE traffic threshold on HSUPA,

then the service is carried on the E-DCH. Otherwise, the service is carried on the DCH




onto HSDPA

DL BE traffic threshold on HSDPA --- 8, 16, 32, 64, 128,

144, 256, 384, 768, 1024, 1536, 1800, 2048, 3648, 7200,

10100, 14400kbps

UL BE traffic DCH decision threshold --- 8, 16kbps

Bit rate

threshold for BE

service over

HSPA

UL BE traffic threshold on HSUPA --- 8, 16, 32, 64, 128,

144, 256, 384, 608, 1450, 2048,2890, 5760kbps

DL BE traffic DCH decision threshold --- 8, 16kbps MML: SET FRCCHLTYPEPARA



Contents











HSDPA Code Resource Allocation

! The codes of the HS-PDSCH can be allocated in three ways:

" Static HSDPA code allocation

# In static allocation, the RNC reserves codes for the HS-PDSCH

# The DPCH, HS-SCCH, and common channels use the remaining codes

" RNC-controlled dynamic allocation

# In RNC-controlled dynamic allocation, the RNC adjusts the reserved HS-PDSCH

codes according to the real-time usage status of the codes

" NodeB-controlled dynamic allocation

# NodeB-controlled dynamic allocation allows the NodeB to use the HS-PDSCH

codes allocated by the RNC

# The NodeB can dynamically allocate the idle codes of the current cell to the HS-

PDSCH

! The channelization codes are constant resources consisting of the following three parts:

" channelization codes for HS-PDSCH

" channelization codes for Common channels and HS-SCCH

" channelization codes for DPCH

! The resources are reserved for the common channels and the HS-SCCH. The parameter of

the codes reserved for the HS-SCCH can be configured on the RNC LMT.




!Static HSDPA Code Allocation

"Static HS-PDSCH code allocation

# Spreading factor =16

# Allocate continuously

"Static HS-SCCH code allocation

# Spreading factor =128

# Allocate with common channel

PS_STREAMING_ON_HSDPA_SWITCH --- 1~15

Allocate Code Mode --- Manual, Automatic

Code Resource

Allocation Parameters

Code Number for HS-SCCH --- 1~15 MML: ADD CELLHSDPA




!RNC-controlled dynamic allocation

"In the RNC-controlled dynamic allocation, the RNC adjusts the reserved HS-

PDSCH codes according to the real-time usage status of the codes

"Min. number of codes, defined by the code min number for HS-PDSCH

parameter, are reserved for HS-PDSCH in a cell

Code Max Number for HS-PDSCH--- 1~15

MML: ADD CELLHSDPACode Min Number for HS-PDSCH --- 1~15 Code Resource





! When R99 code consumption is reduced, RNC increases the codes reserved

for HSDPA if following conditions are met

" the shared code neighboring to the codes reserved for HS-PDSCH is idle

" At least another free code that reserved for R99 handover users. This idle code SF is

equal or less than cell LDR SF reserved threshold

* the solid dots represent the occupied codes and the circles represent the idle codes




!When the re-allocation of R99 code resource is trigger by some voice calls coming

!RNC re-allocates one shared code from HS-PDSCH to R99 if the rest idle code SF is

greater than Cell LDR SF reserved threshold

* the solid dots represent the occupied codes and the circles represent the idle codes

MML: ADD CELLLDRCell LDR SF reserved threshold --- SF8, SF16,

SF32, SF64, SF128, SF256

Code Resource





! NodeB-controlled dynamic allocation

" NodeB-controlled dynamic allocation allows the NodeB to use the HS-PDSCH

codes that are allocated by the RNC. The NodeB can dynamically allocate the

idle codes of the current cell to the HS-PDSCH channel

" The NodeB periodically detects the SF16 codes apart from the RNC-allocated

HS-PDSCH codes every 2 ms. If the codes or sub-codes are allocated by the

RNC to the DCH or common channels, they are identified as occupied.

Otherwise, they are identified as unoccupied. Therefore, the HS-PDSCH codes

available for the HS-PDSCH channel include the codes allocated by the RNC

and those consecutive and unoccupied SF16 codes




! NodeB-controlled dynamic allocation

" For example, if the RNC allocates five codes to the NodeB, that is, No.11 to 15

SF16 codes are allocated to the HS-PDSCH. Suppose in a 2 ms TTI, No. 0 to 5

SF16 codes are allocated to the DCH and common channels. No. 0 to 5 SF16

codes are occupied. Therefore, in the current TTI, the HS-PDSCH can use No. 6

to 15 SF16 codes

" If the DCH codes allocated by the RNC are temporarily occupied by the HS-

PDSCH during the setup of radio links, the NBAP message returned to the RNC

indicates that the radio link is set up successfully. From the next 2 ms TTI, the

HS-PDSCH no longer uses these codes until they are released from the DCH

MML: SET MACHSPARADynamic codes switch--- OPEN, CLOSECode Resource Allocation

Parameters



Contents











HSDPA Power Allocation

! HS-PDSCH and HS-SCCH shared power with R99 channels

! The downlink power consists of the following parts

" Power for common channel

" Power for DPCH

" Power for DL HSDPA channel, such as HS-PDSCH, HS-SCCH

" A configurable margin is used to keep the system in stable status

Power Margin --- [0~100%]

MML: ADD CELLHSDPAThe Offset of HSPA Total Power --- [-5dB~0dB]Power Resource


Max Power per H user --- [1%~100%]

MML: SET MACHSPARA

! The cell total transmit power is the constant resources. The DL power consists of the

following three parts:

" Power of the HSPA DL physical channel (HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH and

E-HICH)

" Common channel power

" DPCH power

Time

Allowed power for HSDPA

Total Power

DPCH

Power for CCH

Higher power

utility

efficiency

Time

Power margin for DCH

power control



HSDPA Power Control! HS-DPCCH Power Control

" Power Offset of ACK, NACK and CQI (Non SHO & SHO)

# There is no separate power control for HS-DPCCH but setting several power offsets between

HS-DPCCH and UL associated DPCCH, namely ACK, NACK, CQI

The CQI feedback in the uplink is determined by the following parameters:

! CQI_Repetition_Factor

! CQI_Power_Offset

! CQI_feedback_cycle

CQI_feedback_cycle refers to the cycle of UE providing CQI feedback. In each cycle, the CQI

is repeatedly sent within the CQI_Repetition_Factor consecutive subframes which is

equal to 1 frame

In each subframe, the CQI transmission power is equal to the associated UL DPCCH power plus

the CQI power offset

The NACK/ACK feedback in the uplink is determined by the following parameters:

! ACK-NACK_Repetition_Factor

! ACK/NACK_poweroffset

! HS-DPCCH_Preamble_Transmission_Indication

At the end of about 19,200 chips (i.e.5ms) after the UE receives HS-PDSCH subframes in the

downlink, the UE provides HARQ NACK or ACK feedback in the uplink within ACK-

NACK_Repetition_Factor consecutive HS-DPCCH subframes.

The transmit power of the UE is equal to the associated UL DPCCH transmit power plus the

ACK_Poweroffset or NACK_Poweroffset, for NACK or ACK feedback respectively


Several power offsets are set between the HS-DPCCH and the associated UL DPCCH. When

ACK/NACK and CQI are carried on the HS-DPCCH, their power offsets, that is, ACK,

NACK, and CQI, are set in one HS-DPCCH TTI

The transmit power of the HS-DPCCH is calculated with the following formula:

where

PUL DPCCH is the transmit power of the associated UL DPCCH

For the first slot of a TTI, HS-DPCCH means ACK when the UE responds with ACK or means

NACK when the UE responds with NACK.

For the second and third slots of a TTI, HS-DPCCH means CQI.



HSDPA Power Control

! HS-DPCCH Power Control

" In soft handover area, the UL combining gain reduces the necessary transmission power

of UL DPCCH. While HS-DPCCH does not has the UL combining gain, to maintain the

receiving quality of the HS-DPCCH, higher power offset is needed. Thus, when UE enters or

leaves the soft handover area, the power offset for ACK/NACK and CQI may have a change

correspondingly

CQI Power Offset --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15CQI Power Offset multi-RLS --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15

Parameters for CQI

power offset

NACK poweroffset1 / ACK poweroffset2 / ACK poweroffset3 --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15NACK poweroffset1 multi-RLS / ACK poweroffset2 multi-RLS / ACK poweroffset3 multi-RLS --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15

Parameters for

NACK power offset

MML:ADD CELLHSDPCCH

ACK poweroffset1 / ACK poweroffset2 / ACK poweroffset3 --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15ACK poweroffset1 multi-RLS / ACK poweroffset2 multi-RLS / ACK poweroffset3 multi-RLS --- 5/15, 6/15, 8/15, 9/15, 12/15, 15/15, 19/15, 24/15, 30/15

Parameters for

ACK power offset



HSDPA Power Control

!HS-SCCH Power Control

"Fixed Power

# Set fixed power for each HS-SCCH by O&M

# Simple to configuration, but low utilization of the power

"Based on CQI

# If the HS-SCCH Power Control Method parameter is set to CQI, the NodeB adjust the

transmission power of HS-SCCH, depending on the following information

– CQI reported by UE

– DTX detected by NodeB

– Target frame error rate ( FER ) of HS-SCCH

HS-SCCH FER --- 1‰~999 1‰

HS-SCCH Power --- -10 dB to 10 dB

MML: SET MACHSPARAHS-SCCH Power Control Method --- FIXED, CQIHS-SCCCH power

control parameters

The process of power control adjustment within an adjustment period is as follows:

1 NodeB acquires the PHS-SCCH,init, PHS-SCCH,min and PHS-SCCH,max according to

the reported CQI

1 PHS-SCCH,init is the initial HS-SCCH transmit power, which is an offset relative to

the P-CPICH transmit power

2 PHS-SCCH,min is the minimum HS-SCCH transmit power, which is an offset relative

to the P-CPICH transmit power. PHS-SCCH,min is set to -10 dB

3 PHS-SCCH,max is the maximum HS-SCCH transmit power, which is an offset relative

to the P-CPICH transmit power


2 NodeB calculates the HS-SCCH power for the Nth scheduling period by using the

following formula:

PHS-SCCH(n) = FUNC(PHS-SCCH(n-1), CQI(n-1), CQI(n), NDTX, Cpc, FERT, Sbase, Smax,u)

where:

Cpc is the HS-SCCH power adjustment period, indicating the number of transmitted HS-

SCCH frames. After the period, the power adjustment is performed at once. Cpc is set to

3 TTI.

Sbase is the step of power adjustment within an HS-SCCH power adjustment period. Sbase

is set to 0.02 dB.

Smax,u is the maximum allowed power step-up within a power adjustment period. Smax,u

is set to 0.5 dB.

NDTX is the number of DTXs.

FERT represents HS-SCCH FER and can be set on the NodeB LMT

3 NodeB limits the HS-SCCH power for the Nth schedule time by PHS-SCCH,min and

PHS-SCCH,min . That is, limit the HS-SCCH power in the range [PHS-SCCH,min , PHS-

SCCH,min]



HSDPA Power Control

! HS-PDSCH Power Control

" Power is allocated in NodeB, Mac-hs allocates HS-PDSCH power for different

HSDPA users with scheduling algorithm

" When configured by static HSDPA power allocation algorithm, the total power of

HS-PDSCH and HS-SCCH shall not exceed the maximum transmission power

" When configuredby dynamic HSDPA power allocation algorithm, the maximum

transmission power is the remaining power excluding R99 power and power

margin



HSDPA Power Control

! The initial transmit power of the downlink F-DPCH, PF-DPCH,Initial is calculated with the

following formula:

! To prevent waste of downlink power while adding a new radio link to the active set,

a power adjustment for the new radio link is used. Based on the calculation used for

calculating the initial transmit power of the F-DPCH, the power of the new radio link

is decreased by a power offset, which is 15 dB. This parameter is only available when

the branch parameter DOWNLINK_POWER_BALANCE_SWITCH is set to ON

where:

! PCPICH is the P-CPICH transmit power in a cell. It is defined by the PCPICH transmit

power parameter

! (Ec/No)CPICH is the ratio of received energy per chip to noise spectral density of CPICH

received by the UE

! is the orthogonality factor in the downlink. Orthogonal codes are employed in the

downlink to separate the physical channels, and without any multi-path propagation, the

orthogonality remains when the NodeB signal is received by the UE. If there is sufficient

delay spread in the radio channel, part of the NodeB signals will be regarded as multiple

access interference by the UE. The orthogonality of 0 corresponds to perfectly orthogonal

users. In the Huawei implementation, is set to 0.

! Ptotal is the downlink transmitted carrier power measured at the NodeB. This power is

reported to the RNC.

! (Ec/N0)F-DPCH is the Ec/No required for the TPC symbol error rate of the F-DPCH stipulated

by the protocol, that is, a symbol error rate of 4%. This Ec/No is set to -17 dB.



HSDPA Power Control

!Downlink open loop power control on F-DPCH

"The maximum and minimum values of the transmit power range of

downlink F-DPCH is calculated with the following formulas:.

# Maximum transmit power value = PCPICH + FDPCH maximum reference power +

F-DPCH Power Offset

# Minimum transmit power value = PCPICH + FDPCH minimum reference power +

F-DPCH Power Offset

Soft handover initial power offset --- 0dB ~ 25dB

FDPCH minimum reference power --- -35dB ~ 15dB

MML: SET FDPCHRLPWRFDPCH maximum reference power --- -35dB ~ 15dB F-DPCH initial

transmission power

parameters



Contents











HSDPA Mobility Management

! HSDPA connection

" One HSDPA user has up to one HSDPA connection with network at the

same time

" HSDPA connection HO means HO caused by moving

! DPCH connection

" DPCH connection has same function as R99 HO, Containing SHO, HHO

and inter-RAT HO

! Both HSDPA connection and DPCH connection HO are based on UE

measurement report and other information, and they are controlled by

UTRAN side



Intra-frequency Handover of HSDPA

before handover after handover

Cell 2(HSDPA)Cell 1(HSDPA) Cell 2(HSDPA)Cell 1(HSDPA)

The 1D event is triggered by

cell 2

Cell 2(R99)Cell 1(HSDPA) Cell 2(R99)Cell 1(HSDPA)




Soft handover

The 1B (remove) is triggered

by HSDPA cell

Soft handover

HSDPA cell is added into active set

The 1D event is triggered by HSDPA

cell



Intra-frequency Handover of HSDPA

MML: SET HOCOMMThe timer length of D2H Intra-handover --- 0s ~ 999s Parameter



! If all the cells in the active set support the F-DPCH after the active set is updated and the

SRB is carried on the DCH, the SRBD2HHoTimer starts. After this timer expires, the RNC

decides whether to switch the SRB to the HS-DSCH

! After the UE is handed over to an HSDPA cell from an R99 cell, the D2HRetryTimer

starts. After this timer expires, the RNC decides whether to switch the SRB to the HS-DSCH

and whether to set up the F-DPCH. D2HRetryTimer is set through The timer length of

D2H Inter-freq handover and The timer length of D2H Intra-freq handover

Handover Between a Cell Supporting the

F-DPCH and a Cell Not Supporting the F-DPCH

MML: SET HOCOMMThe timer length of Srb Over Hspa Retry Delay[100ms] --- 0s ~ 60s

Parameter



Inter-frequency Handover of HSDPA

! Inter-frequency handover can be triggered on the basis of coverage, load, and

Hierarchical Cell Structure (HCS).

!The introduction of HSDPA does not affect the triggering conditions and

decisions of these types of inter-frequency handover

Inter-Frequency Handover Between HSDPA Cells The UE moves from one HSDPA cell to another HSDPA cell.Event 2B is triggered

Scenario 3

Inter-Frequency Handover from an R99 Cell to an HSDPA CellThe UE moves from a non-HSDPA cell to an HSDPA cell.Event 2B is triggered

Scenario 2

Inter-Frequency Handover from an HSDPA Cell to an R99 Cell The UE moves from an HSDPA cell to a non-HSDPA cell.Event 2B is triggered

Scenario 1

DescriptionScenario





Cell 2(HSDPA)Cell 1(HSDPA) Cell 2(HSDPA)Cell 1(HSDPA)

Inter-frequency handover

2B is triggered by HSDPA

cell (cell2)



Inter-frequency handover

2B is triggered by R99 cell Inter-frequency handover

The 2B event is triggered by

HSDPA cell






The timer length of D2H Inter-handover--- 0s ~ 999s MML: SET HOCOMMParameter



Inter-RAT Handover of HSDPA

! The introduction of HSDPA does not affect the inter-RAT handover algorithms.

! The switch CM permission ind on HSDPA decides whether the Compressed

Mode (CM) can be used on HSDPA. For detailed information about the switch, see

Inter-Frequency Handover of HSDPA

! When the UE handover to a cell supporting the F-DPCH from another system and

a UL or DL event 4A is reported, the RNC decides whether to change the bearing

mode of TRB and SRB.

! If the TPC command is carried on the F-DPCH between the UE and the UTRAN, the

SRB and the TRB are carried on the HS-DSCH. If a cell not supporting the F-DPCH

is added to the active set, all the F-DPCHs are deleted. In addition, new DPCHs

between the UE and all the cells in the active set are set up to carry the SRB and

TPC commands. In this case, the TRB is still carried on the HS-DSCH.



Contents











HSDPA Channel Switching

!With introducing HSDPA technology, the UE has one more RRC state

CELL_DCH (with HS-DSCH)

CELL_PCH CELL_FACH

CELL_DCH

CELL_DCH(with HS-DSCH)

HS-DSCH FACHCell-DCH ( with HS-DSCH ) Cell-FACH

HS-DSCH DCHCell-DCH ( with HS-DSCH ) Cell-DCH

Channel SwitchingUE State Transition




" Channel Switching between HS-DSCH and DCH

# Channel Switch from HS-DSCH to DCH

– Mobility

# Channel Switch from DCH to HS-DSCH

– Mobility

– Timer (H Retry Timer)

– Traffic Volume

~ The UE is rejected by the admission control algorithm when it attempts to access

an HSDPA cell. If the activity of the UE that performs data services increases and

the RNC receives an event 4A report, the RAN tries to hand over the UE from the

DCH to the HS-DSCH

– Channel switching from DCH to HS-DSCH needs to implement the process of

HSDPA directed retry




MML:SET COIFTIMER H Retry Timer Length --- 0 ( disable ), 1 180s

MML: SET CORRMALGOSWITCH

PS _Non_ BE _ State_ Trans _Switch --- Enable , Disable

PS _ BE _ State_ Trans _Switch --- Enable , Disable

HSDPA_ State_ Trans _Switch --- Enable , DisableParameters




! Channel Switching between HS-DSCH and FACH

" Since the HSDPA UE occupies the DPCH, the RAN will switch the transport

channel from HS-DSCH to FACH to reduce occupation of the DPCH when

the following conditions are met

# The HS-DSCH carries the BE service for the UE

# There is a few data flow of any of the services for a certain length of time

" By contrary, if data service activity increased, for example, when the RNC

receives a 4A event measuring report ,state transfer is triggered for Cell-

FACH to Cell-DCH ( with HS-DSCH )




Realtime Traff DCH Or HSPA To FACH Transition Timer --- 1s~65535s

BE HS-DSCH To FACH 4b Pending Time After Trigger --- 250, 500, 1000, 2000, 4000, 8000, 16000ms

BE HS-DSCH To FACH 4b Time To Trigger --- 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000ms

BE HS-DSCH to FACH 4B threshold --- 8 16 32 64128 256 512 1024 2k 3k 4k 6k 8k 12k16k 24k 32k 48k 64k 96k 128k 192k

256k 384k 512k 768kbytes

MML:SET UESTATETRANSBE HS-DSCH to FACH Transition Timer --- 1s~65535s

Realtime Traff DCH Or HSPA To FACH 4b Pending Time --- 250, 500, 1000, 2000, 4000, 8000, 16000 ms

Realtime Traff DCH Or HSPA To FACH 4b Time To trigger --- 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000ms

Realtime Traff DCH Or HSPA To FACH 4b Threshold ---8 16 32 64 128 256 512 1024 2k 3k 4k

6k 8k 12k 16k 24k 32k 48k 64k 96k128k 192k 256k 384k 512k 768kbytes

Parameters



Contents











HSDPA Qos Management

! QoS Requirements of Different Services

" IMS / SRB

" Voice over IP (Conversational Service)

" Streaming Service

" BE Service

! QoS Parameters Mapped onto the MAC-hs Layer of the NodeB

" MAC-hs Discard timer

" Scheduling Priority Indicator (SPI)

" Guaranteed Bit Rate (GBR)

IMS/SRB: Signaling has a high requirement for transmission delay. If the requirement cannot be

met, the service may be affected. For example, an SRB delay may lead to a handover delay.

The average rate of signaling is lower than 20 kbit/s.

VoIP: The VoIP service is highly delay sensitive. The end-to-end delay of a voice frame should

be shorter than 250 ms. The tolerant frame error rate is about 1%. The average rate of the

VoIP service with the header compressed is about 20 kbit/s.

Streaming: The streams at the receiver end should be continuous. Compared with VoIP, the

streaming service has a relatively low delay sensitivity, because a buffer that can avoid jitter

for several seconds is configured at the receiver end. When the rate of the streaming service

is equal to or higher than the GBR, the QoS can be guaranteed.

BE (background and interactive): The data rate at the service source end can reach a high value,

for example, several Mbit/s during a burst. The BE service has a low requirement for

transmission delay but has a high requirement for reliable transmission.


MAC-hs Discard timer: An MAC-d PDU in an MAC-hs queue is discarded if the waiting time

exceeds the length of this discard timer. This timer is set on the RNC side. It is an optional IE

on the Iub interface. For the VoIP service, the timer is set to 100 ms. For the BE and

streaming services, the timer may not be set. For an MAC-hs queue configured with the

discard timer, the scheduler should send out the MAC-d PDUs before expiry of the timer.

Scheduling Priority Indicator (SPI): This parameter specifies the scheduling priority of an

MAC-hs queue. The priority is derived from the Traffic Class, Traffic Handling Priority,

and User Priority that are mapped onto this queue.

Guaranteed Bit Rate (GBR): It is configured on an MAC-hs queue basis. For the streaming

service, the GBR specifies the rate that can meet the requirement of the user for viewing

and the GBR of a queue is determined by the NAS. For the BE service, the GBR specifies the

required minimum rate for the service of the users in the RAN. The GBR of a BE service user

is set through the SET USERGBR command on the RNC side. The setting is based on the

user priority, namely, gold user, silver user, or copper user.

Services with different QoS requirements require different QoS guarantee policies. For example,

the VoIP service has a high requirement for delay. To limit the delay caused by flow control

or scheduling within a proper range, the algorithm grants the VoIP queue a priority to

occupy resources first. The streaming service has a high requirement for GBR. Therefore,

the scheduling and flow control algorithms guarantee that the average rate of the service is

not lower than the GBR during Iub traffic distribution and Uu resources allocation. The BE

service has a high requirement for reliability, which can be achieved through more

retransmissions on the Uu interface.




! Scheduling Priority Indicator (SPI) is the relative priority of the HS-DSCH FP

data frame and the SDUs included

! The SPI is set according to the following factors

" Traffic Class (TC)

" Traffic Handling Priority (THP) of the interactive service

" User Priority

! The SPI is set on the RNC LMT and sent to the NodeB through NBAP signaling

User priority

The case for mapping of traffic class, user priority, and THP to SPI

333332222211111ErrorUser

priority

15141

31211109876543210ARP

11None3

11None2

12None1Streaming

13None3

13None2

13None1Conversationa

l (VoIP)

14NoneNo ARPIMS signaling

15NoneNo ARPSRB signaling

SPITHPUser PriorityTraffic Class

2None3

5None2

8None1Background

23 to 153

323

413

53 to 152

622

712

83 to 151

921

1011Interactive

SPITHPUser PriorityTraffic Class


The case for algorithm configuration based on SPI

80%FLOW_CONTRL_DYNAMICTS_SCHEDULE42











100%FLOW_CONTRL_FREEDS_URGENT_SCHEDULE213

100%FLOW_CONTRL_FREEDS_PQ_SCHEDULE414

100%FLOW_CONTRL_FREEDS_PQ_SCHEDULE415

Weight of

SPI

Flow Control

Algorithm Switch

EPF Schedule

Algorithm Switch

Max

Retrans

mission CountSPI




MML: ADD TYPRABHSPAMAC-hs Discard timer [ ms ]--- 20, 40, 60, 80, 100, 120, 140, 160, 180, 200, 250, 300, 400, 500, 750,

1000, 1250, 1500, 1750, 2000, 2500, 3000, 3500, 4000, 4500, 5000, 7500 ms

Parameters

MML: SET SCHEDULEPRIOMAPScheduling Priority Indicator (SPI) --- 0~15

Traffic Class --- CONVERSATIONAL, STREAMING, INTERACTIVE, BACKGROUND, IMS, SRB

User Priority --- Gold, Silver, Copper

Traffic Handling Priority (THP) --- 1~15

MML: SET MACHSSPIPARAWeight of SPI (%) --- 1% ~ 100%

MAC-hs Discard timer specifies the maximum waiting time for sending a MAC-d PDU after it

is put in the MAC-hs queue. The MAC-d PDU is discarded when the timer expires.

SPI indicates the scheduling priority of the service of the user. The value 15 indicates the

highest priority and the value 0 indicates the lowest priority.

User priority is set according to the ARP

THP is valid only when the traffic class is interactive. The value 1 indicates the highest priority,

14 indicates the lowest priority, and 15 indicates no priority

Weight of SPI is used in the scheduling algorithm to select a queue to send data. To

implement differentiated services, it can adjust the proportions of the rates obtained by the

users with different SPIs in the same channel conditions. When Scheduling Method is set

to EPF, this parameter is valid in the scheduling algorithm. When Flow Control Switch is

set to SIMPLE_FLOW_CTRL or AUTO_ADJUST_FLOW_CTRL, this parameter is valid in the

flow control algorithm.



HSDPA Scheduling Algorithm

! Huawei RAN10 product supports 4 scheduling algorithms:

" Max C/I

" RR (Round Robin)

" PF (Proportional Fair)

" EPF (Enhanced Proportional Fair)

When the HS-DSCH carries only the BE service, the PF scheduling algorithm can make a

tradeoff between user equity and cell throughput. When the HS-DSCH carries more types

of services, such as VoIP, streaming, SRB, and IMS, the HSDPA scheduling algorithm needs

to guarantee the QoS. The reason is that such services have high requirements for delay or

GBR. Based on the PF, the EPF algorithm is designed to guarantee the QoS of these services

as follows.




$DS_PQ_SCHEDULE: SRB/IMS scheduling policy. The SRB and IMS queues are scheduled

before the VoIP, streaming and BE queues. DS means delay sensitive. PQ means priority queue.

$DS_URGENT_SCHEDULE: VoIP scheduling policy. The VoIP queues are scheduled before the

streaming and BE queues but after the SRB and IMS queues.

$TS_SCHEDULE: streaming/BE scheduling policy. The streaming and BE queues are scheduled

after the SRB, IMS, and VoIP queues. Among the streaming and BE queues, the resources for

GBR are allocated first. The remaining resources are allocated as required by golden, silver, and

copper users. TS means throughput sensitive

Queue types i.e. QOS

requirement of different

services

EPF

$To select users according to the value of R/r in descending order, where R is the maximum

data rate corresponding to the CQI, and r is the average data rate of the MAC-hs priority queue.

$The PF scheduler uses the variation in the radio channel qualities of individual users (for

example, multi-user diversity) and provides the user with an average throughput proportional to

its average CQI. This algorithm is a tradeoff between cell capacity and fairness among users.

CQI,

Average data rate of the

MAC-hs priority queue

PF

$To select users according to the waiting time of data buffered in the MAC-hs priority queue in

descending order. The waiting time is the only factor considered in this algorithm and therefore

the fairness among users can be guaranteed but the cell capacity degrades because the channel

quality is not taken into account.

Waiting time of data

buffered in the MAC-hs

priority queue

RR

$To select users according to the CQI value in descending order. The radio channel quality is the

only factor considered in this algorithm and therefore the fairness among users cannot be

guaranteed.

CQIMAX C/I

Scheduling PrincipleFactor considered in

algorithm

Scheduling

Algorithm

When the HS-DSCH carries only the BE service, the PF scheduling algorithm can make a

tradeoff between user equity and cell throughput. When the HS-DSCH carries more types

of services, such as VoIP, streaming, SRB, and IMS, the HSDPA scheduling algorithm needs

to guarantee the QoS. The reason is that such services have high requirements for delay or

GBR. Based on the PF, the EPF algorithm is designed to guarantee the QoS of the multiple

services




! EPF ( Enhanced Proportional Fair )

" The types of queues are considered

" Qos guarantee for delay-sensitive service (delay) and throughput-sensitive

service (GBR)

" Configurable for SPI

$DS_PQ_SCHEDULE: SRB/IMS scheduling policy. The SRB and IMS

queues are scheduled before the VoIP, streaming and BE queues. DS means delay sensitive. PQ means priority queue.$DS_URGENT_SCHEDULE: VoIP scheduling policy. The VoIP queues are scheduled before the streaming and BE queues but after the SRB and IMS queues. $TS_SCHEDULE: streaming/BE scheduling policy. The streaming and BE queues are scheduled after the SRB, IMS, and VoIP queues. Among the streaming and BE queues, the resources for GBR are allocated first. The remaining resources are allocated as required by golden, silver, and copper users. TS means throughput sensitive

Queue types i.e.

QOS requirement of different services

EPF

Scheduling PrincipleFactor

considered in algorithm

Scheduling Algorithm

When the HS-DSCH carries more types of services, such as VoIP, streaming, SRB, and IMS

signaling, the HSDPA scheduling algorithm needs to guarantee the QoS. The reason is that

such services have high requirements for delay or GBR. Based on the PF, the EPF algorithm

is designed to guarantee the QoS of the following services:

! SRB and IMS have high requirements for service connection delay and handover delay. In

addition, the average traffic volume and the consumption of the Uu interface are low.

Therefore, the algorithm always selects the MAC-hs queues of SRB and IMS first.

! The VoIP service is highly delay sensitive. The maximum delay of MAC-d PDUs in a queue is

specified by the discard timer of the MAC-hs queue. The scheduler needs to send out the

MAC-d PDUs before the discard timer expires. The discard timer is usually shorter than 100

ms. Therefore, the scheduler has little chance of considering the channel quality. The

scheduler always selects VoIP services after scheduling SRB and IMS services. Among MAC-

hs queues of VoIP, the selection is based on both delay and channel quality.


! The streaming service is usually the CBR (Constant Bit Rate) streaming service. If the rate of

this service is not lower than the GBR, the user can obtain good experience. Therefore, the

scheduler needs to guarantee the GBR. When the average rate of the streaming service is

lower than the GBR, the queues of the streaming service are selected first after SRB, IMS,

and VoIP. Among the MAC-hs queues of the streaming service, the selection is based on PF.

! The BE service is allocated with the remaining resource after the resource requirements of

the SRB, IMS, VoIP, and streaming services are met. Among the MAC-hs queues of the BE

service, the selection is based on PF. In addition, the resource allocation complies with the

following rules.

" Firstly, the GBR should be guaranteed first.

" Secondly, the algorithm considers the requirement for user differentiation. For all the

users in the cell, the scheduler intends to allocate the radio resource in proportion to

their Weight of SPI, which is based on user priorities, eg. gold, silver and copper.

# For example, assuming that radio resource is the bottleneck, gold , silver and

copper users of same channel quality are using FTP service simultaneously,

then the Uu throughputs of gold, silver and copper users are in proportion to

the ratio of their SPI weights.

# For another example, assuming that the silver user is using HTTP service, the

gold and copper user are using FTP service, and the silver user are reading the

HTTP page, then the gold and copper users share the radio resource, and the

Uu throughput of the gold and copper users are in proportion to the ratio of their SPI weight.




MML: SET MACHSPARAScheduling Method --- EPF (Enhanced PF), PF (PF), RR (Round Robin), MAXCI (Max C/I )

Parameters

MML: SET MACHSSPIPARAEPF Schedule Algorithm Switch --- DS_PQ_SCHEDULE, DS_URGENT_SCHEDULE, TS_SCHEDULE

EPF Schedule Algorithm Switch is valid only when Scheduling Method is set to EPF



Contents











HSDPA TFRC Selection

! Transport Format Resource Combination (TFRC) selection determines the

transport block size, modulation type, HS-PDSCH codes, and HS-PDSCH

transmission power

! The UEs estimate and send CQI to the UTRAN to aid the TFRC selection

! The CQI indicates the number of bits that can be transmitted to the UE

through certain HS-PDSCH power, a certain modulation method (QPSK or

16QAM), and a certain number of HS-PDSCH codes with an initial

transmission BLER of 10%




! TFRC selection is performed according to the following factors

" Available power of the HS-PDSCH

" Available codes of the HS-PDSCH

" CQI from the UE

" UE capability




! If there is sufficient amount of data cached in the MAC-hs queue (TBSmax <

Queue length), the data is scheduled for the UE as much as possible in the

maximum format of TFRC, that is, TBS = TBSmax

! If there is insufficient amount of data cached in the queue (TBSmax > Queue

length), the Uu resources necessary for the UE are allocated on the basis of

the amount of data in the queue

" Select the TFRC (power, code, and modulation mode) by searching the CQI-Max

TBS mapping table and taking the amount of data cached in the queue into

consideration

" The search is based on the priority defined by the Resource Allocate Method

parameter, that is, code preferable or power preferable




! TFRC Selection Process

Macro cells usually have a

poor radio environment

with limited power

resource. The downlink

power resource of a cell is

used up when the downlink

code resource is enough

Indoor pico cells usually

have a good radio

environment with

limited code resource.

The downlink code

resource of a cell is

used up when the power

resource is enough




! Example of TFRC selection process




! After TFRC is determined, the matched CQI of TBS in the CQI-

MaxTBS mapping table is determined. This CQI is expressed as

CQIused. Then, the transmit power of the HS-PDSCHs is calculated as

follows:

POWERHS-PDSCH = PCPICH + – (CQIadjusted - CQIused)

MML: SET MACHSPARAResource Allocate Method --- code priority, power priority

Parameters

MAX POWER PER HS-USER --- 1% to 100%

Within one TTI, the HS-PDSCH power and HS-SCCH power allocated to one UE cannot exceed

the value of the MAX POWER PER HS-USER parameter.

The HSDPA cell load is limited by the The Offset of HSPA Total Power parameter.

! = Max(-6, Min(13, PCellMAX - PCPICH - MPOconstant))

" PCell-MAX - PCPICH = maximum transmit power of the cell - CPICH transmit power

" MPOconstant represents HS-PDSCH MPO Constant and can be set on the RNC LMT

(MML: ADD CELLHSDPA)



Contents











Overview of NodeB HSDPA Flow

Control! HSDPA Flow control is a process used to control HSDPA data flow from RNC MAC-d to

NodeB MAC-hs according to Iub bandwidth and air interface bandwidth

! After HSDPA is introduced, users’ rate on air and on Iub is not consistent. It is necessary

to adjust rate on Iub according to its rate on air

! The signaling of HSDPA flow control process is implemented through the capacity

request and capacity allocation. The NodeB allocates the capacity for each MAC-hs

queue, and the RNC limits the downlink rate of each MAC-hs queue according to the

allocated capacity

! capacity means how much data RNC can send to NodeB in an interval



Signaling of HSDPA Flow Control

! Capacity Request includes following IEs

" CmCH-PI : Scheduling priority Indicator ( SPI ) of the queue

" Uesr buffer size: Occupancy status of RLC buffer

The RNC sends Capacity Request to the NodeB, when some RLC PDUs are

accumulated in RLC buffer or CREDITS (i.e. some control messages in the latest

Capacity Allocation) are expired

The RNC also sends Capacity Request if No RLC PDU but allocated capacity is greater

than zero, indicating the NodeB can stop Capacity Allocation



Signaling of HSDPA Flow Control

! The NodeB sends the HS-DSCH Capacity Allocation message to the RNC in

response to a HS-DSCH Capacity Request

! Capacity Allocation includes following IEs

" Maximum MAC-d PDU Length: maximum PDU size among the MAC-d PDU sizes

configured in the NBAP messages

" HS-DSCH Credits : total quantity of Mac-d PDU that CRNC can send during HS-

DSCH interval

" HS-DSCH interval : time interval during which the HS-DSCH credits granted in

Capacity Allocation can be used

" HS-DSCH Repetition : number of subsequent intervals during which the HS-DSCH

Credits IE granted in the HS-DSCH CAPACITY ALLOCATION control frame can be

used and the value 0 means that there is no limit to the repetition period



Capacity Allocation Policy

! Generally, the NodeB allocating the capacity to a MAC-hs queue considers the

data rate on the Uu interface and Iub available bandwidth

! For different service (i.e. QoS requirements), the NodeB uses different flow

control policies

" Flow control free policy for SRB, IMS signaling or VOIP

" Dynamic flow control policy (for streaming service or BE service)

! Flow control free Policy

" After the HS-DSCH bearer is set up, the NodeB sends a capacity allocation message

to the RNC, indicating that the DL traffic of the new MAC-hs queue is not limited

and the RNC MAC-d can send data as much as required

" The allocation keeps unchanged for the service

" The policy of no flow control policy is applied only to VoIP, IMS, and SRB, for these

services are delay sensitive and have a relative low rate

For VOIP, the flow control free Policy is applied to the Mac-hs queue due to

It is highly delay sensitive. Therefore VOIP service is mapped onto bearers with high

priorities to guarantee the high requirement for delay. The bearer priority of VOIP on

the Iub interface is higher than that of non-real-time service. The scheduling priority of

VOIP queue on Uu interface is also higher than that of non-real-time service queue.

Average rate of VOIP is low. The rate is about 20kbps. The probability of congestion

incurred by VOIP on the Uu interface and Iub interface is low

The IMS signaling / SRB has a low average rate. It is also highly delay sensitive. So flow

control free is also applied to them.




! Dynamic flow control

" Dynamic flow control is mainly applied to MAC-hs queues of BE

service, for theses services are not delay sensitive, the rate varies in

a wide range, and will reach a high rate during a burst

" Dynamic flow control is also applied to MAC-hs queues of

streaming service, for streaming service has a relative high rate

and may result in congestion on Uu




!Dynamic flow control

"Dynamic flow control process with adaptive Iub bandwidth is as follows:

# The congestion status of the transport network is reflected to NodeB through DRT

and FSN. The NodeB adaptively adjusts the Iub bandwidth available for HSDPA

based on the congestion detection

# Depending on the available bandwidth and rate on air interface, the NodeB

allocates bandwidth to HSDPA users and performs traffic shaping (Iub shaping) to

avoid congestion and packet loss over the Iub interface

# The RNC limits the flow of HS-DSCH data frames for each MAC-hs queue

according to the HS-DSCH capacity allocation

MML: SET MACHSSPIPARAFlow Control Algorithm Switch ---FLOW_CONTRL_FREE, FLOW_CONTRL_DYNAMIC

Parameters

We can configure the Flow Control Algorithm according to SPI.

Default configuration for Flow Control Algorithm



HSDPA Flow Control

! Dynamic flow control consists of the following modules:

" Adaptive capacity allocation

# NodeB adaptively allocates capacity to an MAC-hs queue based on its rate on air interface

# Capacity means how much data RNC can send to NodeB in an interval

" Congestion control on Iub

# The total flow of all the MAC-hs queues should not exceed the available Iub bandwidth to

avoid congestion on Iub

# NodeB provides the following functions to avoid Iub congestion:

– Adaptive adjustment of Iub bandwidth

~ NodeB periodically detects Iub congestion and adaptively adjusts the available Iub bandwidth

according to the Iub state

– Iub shaping

~ Iub shaping is used to allocate Iub bandwidth to every MAC-hs queue based on the available

Iub bandwidth and ensure the total flow of the queues does not exceed the available Iub

bandwidth. Thus, congestion control is achieved on the Iub interface, which increases the

bandwidth usage and avoids overload



HSDPA Dynamic Flow Control

! Dynamic flow control policy is configured through the Flow control switch.

!If the switch is set to AUTO_ADJUST_FLOW_CTRL, the NodeB performs adaptive

capacity allocation, Iub shaping and adaptive adjustment of Iub bandwidth

" When the Iub resource is the bottleneck, the algorithm performs capacity

allocation based on the bit rate on the Uu interface and the Iub shaping of

dynamic flow control queues.

" When the congestion on the Iub interface is invisible for the NodeB, the

algorithm performs capacity allocation based on the bit rate on the Uu interface

MML: SET HSDPAFLOWCTRLPARA Flow Control Switch--- SIMPLE_FLOW_CTRL, AUTO_ADJUST_FLOW_CTRL, NO_FLOW_CONTROL

Parameters



HSDPA Dynamic Flow Control

! If the switch is set to NO_FLOW_CONTROL, the NodeB performs

adaptive capacity allocation, and does not perform Iub shaping and

adaptive adjustment of Iub bandwidth

! If the switch is set to SIMPLE_FLOW_CTRL, the NodeB performs

adaptive capacity allocation and Iub shaping, and does not perform

adaptive adjustment of Iub bandwidth

" Some Iub bandwidth should be reserved for HSDPA users. This setting is

used mainly for testing the algorithm during the design phase



HSDPA Flow Control

! MAC-hs / MAC-d flow control

" The flow control keeps the queue occupancy in a reasonable level

in order to reduce data transmission delay, L2 layer signal delay,

and discarding as the result of priority queue congestion or reset

during handover

" In this sense, the functionality is called capacity allocation adaptive

to Uu interface bit rate, where capacity allocation for each priority

queue is based on the Uu interface bit rate and the buffer

occupancy level



HSDPA Flow Control

! MAC-hs / MAC-d flow control when Iub interface resource is

not congested

" If there is not enough data in the queue, large bandwidth is

allocated

" If there is enough data in the queue, the bandwidth that is close

to the rate on the Uu interface is allocated

" If there is too much data in the queue, small bandwidth or no

bandwidth is allocated

If the resource on the Uu interface is the bottleneck, or the total traffic volume within the

NodeB (i.e. Mac-hs queue) is low, or the congestion on the Iub interface is managed

by the RNC back pressure algorithm, then the algorithm allocates the capacity based

only on the rate of each queue on the Uu interface. The MAC-hs performs flow control

for each priority queue periodically.

Whether there is enough data in the queue is judged by the time length of the priority

queue. Time length is defined as the ratio of the length of the queue to the air interface

bit rate of the queue. In this way, the average delay of MAC-d PDU at the MAC-hs

layer is limited within a hundred milliseconds.



HSDPA Flow Control

! Adaptive adjustment of Iub bandwidth available for HSDPA

" Adaptive adjustment of Iub bandwidth available for HSDPA is a

part of the mechanism to control the congestion on Iub.

" Adaptive adjustment of Iub bandwidth available for HSDPA

comprises the following process

# detection of Iub congestion

# adjustment of Iub bandwidth available



HSDPA Flow Control

! Detection of Iub congestion

" This Iub congestion detection algorithm periodically

measures the transmission delay and frame loss

" Assuming that for each MAC-d flow the HS-DSCH

data frame must be delivered to the MAC-hs layer in

FSN sequence, Iub frame loss is counted and the

frame loss ratio at the Iub level in a specific time

window is calculated

" The HS-DSCH data frame transmission delay is the

interval from the time when HS-DSCH data frame

generated in the RNC (identified as DRT) to the time

when the frame arrives at the NodeB MAC-hs layer

Frame Sequence Number: used to detect frame loss over the Iub interface.

DRT: Delay Reference Time, used to detect transmission delay over the Iub interface



HSDPA Flow Control

! Detection of Iub congestion

" Periodically the Iub congestion status is differentiated into three levels:

# Congestion due to delay means that the delay buildup is larger than the Time

Delay Threshold

# Congestion due to frame loss that means the frame loss ratio is larger than the

Discard Rate Threshold. Otherwise frame loss may be caused by an Iub bit error

# Congestion released means that there is no congestion due to delay and no

congestion due to frame loss

MML: SET HSDPAFLOWCTRLPARADiscard Rate Threshold --- 0~100%Parameters

Time Delay Threshold --- 0~500ms

The other two thresholds related to Iub congestion detection are described as follows:

Discard Rate Threshold: is used to determine whether the Iub interface is congested

because of frame loss. Generally, frame losses due to bit error are less than those due

to congestion. By default, the threshold is set to 5%. It can be adjusted on the basis of

transport network quality. The HS-DSCH frame error rate on the Iub interface within

300 ms can be a reference. If the threshold is too high, the congestion on the Iub

interface cannot be relieved in time. If the threshold is too low, the Iub interface will be

regarded as congested in the case of frame loss due to bit error. Thus, the Iub

bandwidth cannot be fully utilized.

Time Delay Threshold: is used to determine whether the Iub interface is congested

because of delay buildup. By default, this threshold is set to 20 ms. It can be adjusted

on the basis of the delay jitter allowed on the transport network. Generally, the

threshold is set to the allowed delay jitter plus several ms. If the threshold is too high,

the transmission on the Iub interface will be much delayed when the Iub interface is the

bottleneck. If the threshold is too low, the Iub interface will be regarded as congested

by mistake. Thus, the transmission resource cannot be fully utilized.



HSDPA Flow Control

! Adjustment of Iub bandwidth available

" The algorithm actively adjusts the Iub bandwidth based on the congestion

detection

# If the Iub is in the congestion due to delay, the Iub bandwidth available for HSDPA is

decreased by a step in direct proportion to the delay buildup

# If the Iub is in the due to frame loss, the Iub bandwidth available for HSDPA is decreased by a

big step regardless of the delay buildup

# If the Iub is in the congestion released, the Iub bandwidth available for HSDPA is increased by

a smaller step, applying the Policy of increasing slowly, yet decreasing fast

" In a time window of tens of seconds, if consecutive "congestion released" is

detected, the Iub resource is identified as not the bottleneck. In this case, the

MAC-hs/MAC-d flow control does not take the Iub bandwidth available for HSDPA

as the limitation of capacity allocation



Contents









Huawei 2008 W-CDMA (UMTS) HSDPA RRM and parameters -- how to make HSDPA work better (very good)

Documents

Transcript of Huawei 2008 W-CDMA (UMTS) HSDPA RRM and parameters -- how to make HSDPA work better (very good)