Document HSUPA

HSUPA Introduction Feature

Guide

WCDMA RAN

HSUPA Introduction Feature Guide

ZTE Confidential Proprietary 1


Version Date Author Reviewer Revision History

V7.0 2012-5-21 Huangmeiqing Xiang Zhijian

1. 1 Feature Attributes: Modified the

version information.

2. 4.24.2 Parameter Configurations:

Modified the OMC path.

3. 3.3.5 HSUPA 2ms TTI: Added 2ms

E-TTI Support Indicator for neighboring

RNC cell.

4. 3.3.10 ZWF25-01-024 HSUPA

5.76 Mbps Peak Bit Rate: Added

E-DCH SF Capability for neighboring

RNC cell.

5. 3.5.1 Introduction to HARQ: Added

E-DCH HARQ Combining Capability for

neighboring RNC cell.

6. 4.2.11 E-DCH HARQ Combining

Capability (Neighboring RNC Cell)

7. 4.2.12 E-DCH SF Capability

(Neighboring RNC Cell)

8. 4.2.13 2ms E-TTI Support Indicator

(Neighboring RNC Cell)

V8.0 2012-12-06 Huangmeiqing Xiang Zhijian 1 Feature Attributes: Modified the version

information.

V8.5 2013-12-03 Huangmeiqing Xiang Zhijian

1. Added Feature ID.

2. Added ZWF25-01-005 Flexible HSUPA

Deployment.

,

2013 ZTE Corporation. All rights reserved.

ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used

without the prior written permission of ZTE.

Due to update and improvement of ZTE products and technologies, information in this document is subjected to

change without notice.



TABLE OF CONTENTS

1 Feature Attributes ........................................................................................... 5

2 Overview ............................................................................................................ 5

3 Feature Introduction.......................................................................................... 6

3.1 Architecture of HSUPA ........................................................................................ 6

3.2 Basic Principle of HSUPA .................................................................................... 7

3.2.1 Physical Channels Introduced to HSUPA ............................................................. 7

3.2.2 Basic Principles of HSUPA ................................................................................ 11

3.3 Basic Functions of HSUPA ................................................................................ 15

3.3.1 ZWF25-01-005 HSUPA Common Carrier with R99 ............................................ 15

3.3.2 ZWF25-01-005 HSUPA Dedicated Carrier ......................................................... 15

3.3.3 ZWF25-01-003 HSUPA Cell Indicator in Idle Mode ............................................ 16

3.3.4 ZWF25-01-004 HSUPA UE Category Support ................................................... 16

3.3.5 ZWF25-01-024 HSUPA 2ms TTI ........................................................................ 17

3.3.6 ZWF25-01-014 HSUPA HARQ .......................................................................... 17

3.3.7 ZWF25-01-021 HSUPA 1.45Mbps Peak Bit Rate .............................................. 18

3.3.8 ZWF25-01-022 HSUPA 16 Users per Cell ......................................................... 18

3.3.9 ZWF25-01-023 HSUPA 2 Mbps Peak Bit Rate .................................................. 18

3.3.10 ZWF25-01-024 HSUPA 5.76 Mbps Peak Bit Rate.............................................. 18




3.3.14 ZWF25-02-001 PS Interactive/Background Service over HSUPA ...................... 19

3.3.15 ZWF25-02-002 PS Streaming Service over HSUPA .......................................... 20

3.3.16 ZWF25-02-003 RAB Combination for CS over DCH and PS over HSUPA ......... 20

3.3.17 ZWF25-02-004 RAB Combination for Multiple Packet Data Services over

HSUPA .............................................................................................................. 21

3.3.18 ZWF25-02-011 SRB over HSUPA ..................................................................... 21

3.3.19 ZWF25-05-002 HSUPA Nominal Bit Rate for I/B Service ................................... 21

3.3.20 ZWF25-01-030 HSUPA 192 Users per Cell ....................................................... 21

3.4 Key Algorithms in the RNC ................................................................................ 22

3.4.1 HSUPA Mobility Management ............................................................................ 22

3.4.2 ZWF25-04-005 HSUPA Dynamic Channel Adjustment ...................................... 26

3.4.3 ZWF25-04-007 Code Allocation for HSUPA ....................................................... 26

3.4.4 ZWF25-04-006 Power Allocation for HSUPA ..................................................... 26



3.4.5 ZWF25-04-001 Admission Control for HSUPA Service ...................................... 26

3.4.6 ZWF25-04-002 Overload Control for HSUPA Service ........................................ 27

3.4.7 ZWF25-04-003 Load Balance for HSUPA Service ............................................. 27

3.4.8 ZWF25-04-004 Congestion Control Strategy for HSUPA ................................... 27

3.4.9 ZWF25-05-001 QoS Mapping for HSUPA Service ............................................. 27

3.5 Key Calculations and Algorithms in Node B ....................................................... 27

3.5.1 Introduction to HARQ ......................................................................................... 27

3.5.2 Node B Based Quick Packet Scheduling Technology ........................................ 29

3.5.3 ZWF25-04-010 HSUPA E-AGCH CLPC ............................................................ 29

3.5.4 ZWF25-04-011 HSUPA E-RGCH/HICH CLPC ................................................... 31

4 Parameters and Configurations ................................................................. 32

4.1 Parameter List ................................................................................................... 32

4.2 Parameter Configurations .................................................................................. 33

4.2.1 HSPA Support Method ....................................................................................... 33

4.2.2 HSPA Support Method (Neighboring RNC Cell) ................................................. 33

4.2.3 E-DCH Uplink Nominal Bit Rate ......................................................................... 34

4.2.4 Support HSUPA Iur Interface Process ............................................................... 34

4.2.5 Support Hard Handover DSCR .......................................................................... 34

4.2.6 HARQ RV Configuration .................................................................................... 34

4.2.7 Four E-DPDCHs Allowed Indicator .................................................................... 35

4.2.8 Switch of supporting SRB on E-DCH ................................................................. 35

4.2.9 Cell HSUPA 2ms TTI Support Indicator ............................................................. 35

4.2.10 HSUPA Function Status ..................................................................................... 35

4.2.11 E-DCH HARQ Combining Capability (Neighboring RNC Cell) ............................ 36

4.2.12 E-DCH SF Capability (Neighboring RNC Cell) ................................................... 36

4.2.13 2ms E-TTI Support Indicator (Neighboring RNC Cell) ........................................ 36

5 Counter and Alarm .......................................................................................... 37

5.1 Counter List ....................................................................................................... 37

5.1.1 Setup/Drop Rate Statistics ................................................................................. 37

5.1.2 Throughput Statistics ......................................................................................... 52

5.1.3 Traffic Hold Time Statistics ................................................................................ 53

5.1.4 Resource Usage Statistics ................................................................................. 53

5.1.5 Moblity Statistics ................................................................................................ 56

5.1.6 Channel Switching Statistics .............................................................................. 68

5.2 Alarm List ........................................................................................................... 70

6 Glossary ........................................................................................................... 70



FIGURES

Figure 3-1 Architecture of the HSUPA Protocol................................................................... 6

Figure 3-2 Frame Structure of the E-DPDCH ...................................................................... 8

Figure 3-3 Frame Structure of the E-DPCCH ...................................................................... 9

Figure 3-4 Frame Structure of the E-AGCH ........................................................................ 9

Figure 3-5 Frame Structure of the E-RGCH .......................................................................10

Figure 3-6 Basic Principles of HSUPA ...............................................................................13

Figure 3-7 Requirements of 3GPP on HSUPA UE Categories ...........................................17

Figure 3-8 E-DCH Intra-frequency Cell Change Flow ........................................................23

Figure 3-9 Intra-cell Fallback from E-DCH to DCH .............................................................25

Figure 3-10 Inter-cell Fallback from E-DCH to DCH ...........................................................25

Figure 3-11 SHO of HSUPA HARQ ...................................................................................29

TABLES

Table 3-1 Timeslot Formats of the E-DPDCH ..................................................................... 8



1 Feature Attributes

System version: [RNCV3.12.10/RNCV4.12.10, Node B V4.12.10, OMMR V12.12.41,

OMMB V12.12.40]

Attribute: [Mandatory]

NE involved:

UE Node B RNC MSCS MGW SGSN GGSN HLR

- - - -

Note:

*-: Not involved.

*: Involved.

Dependency: [None]

Mutual exclusion: [None]

Note: None

2 Overview

High-Speed Uplink Packet Access (HSUPA) is an enhanced uplink technology

introduced by 3GPP R6 in the radio network, aiming at the further improvement of the

uplink packet access capability. HSUPA works at the frequency of 5 MHz and does not

alter the WCDMA network architecture and the access mode of the original R99/R4. By

introducing the MAC-e/es entity and physical channel to the protocol stack of the UTRAN

and adopting key technologies, such as Hybrid Automatic Repeat Request (HARQ),

Node B based fast scheduling and short frame transmission (2ms TTI), HSUPA

effectively improves the peak bit rate of the uplink channel from 384 Kbps of R99/R4 to

5.76 Mbps. HSUPA and HSDPA jointly comprise the uplink and downlink enhanced data

transmission technologies, greatly improving the system capacity and frequency

utilization rate.

The HSUPA technology has enhanced the UTRAN function of R99/R4 and is completely

compatible with the R99/R4 version. The original voice and data services can operate in



the HSUPA network.

3 Feature Introduction

3.1 Architecture of HSUPA

HSUPA is the enhanced uplink technology of the WCDMA. In system architecture,

HSUPA differs from R99/R4 in which it adds two new MAC entities. It introduces MAC-e

to the Node B and MAC-es to the SRNC. Figure 3-1 shows the architecture of the

HSUPA protocol.

Figure 3-1 Architecture of the HSUPA Protocol

From the architecture of Figure 3-1, it is obvious that HSUPA differs from R99/R4 in

which MAC-e and MAC-es have been introduced to the Node B and SRNC respectively.

The MAC-e entity of the Node B is mainly responsible for HARQ retransmission,

scheduling, and demultiplexing of MAC-e; the MAC-es entity of the SRNC is mainly

responsible for re-ordering and the macro diversity combination.

PHY PHY

EDCH FP EDCH FP

Iub UE NodeB Uu

DCCH DTCH

TNL TNL

DTCH DCCH

MAC-e

SRNC

MAC-d

MAC-e

MAC-d

MAC-es / MAC-e

MAC-es

Iur

TNL TNL

DRNC



3.2 Basic Principle of HSUPA

3.2.1 Physical Channels Introduced to HSUPA

To realize the functions and attributes of HSUPA, 3GPP R6 introduces five new physical

channels to the physical layer: In the uplink direction, it adds a dedicated data channel

E-DPDCH (up to 4 E-DPDCHs for each UE) and a dedicated control channel E-DPCCH

for the UEs especially. In the downlink direction, it adds the common physical channels

E-HICH, E-AGCH, and E-RGCH.

The E-DPDCH is an uplink physical channel for carrying the E-DCH data especially.

The E-DPCCH is an uplink control channel for carrying the E-DCH control

information especially.

The E-AGCH is a downlink common physical channel for carrying the E-DCH

absolute grant data.

The E-RGCH is a downlink physical channel for carrying the E-DCH relative grant

data especially.

The E-HICH is a downlink physical channel for carrying the E-DCH HARQ

acknowledgement indications.

3.2.1.1 Introduction to the E-DPDCH (E-DCH Dedicated Physical Data Channel)

The E-DPDCH is used to carry uplink data and its spreading factor ranges from 2 to 256.

The spread factor is in reverse proportion to the carried traffic volume. The modulation

mode of E-DPDCH is BPSK. Similar to HSDPA, the channel also introduces 2ms TTI

while reserving 10ms TTI. Figure 3-2 shows the frame structure of the E-DPDCH.



Figure 3-2 Frame Structure of the E-DPDCH

When the spreading factor is 2 or 4, the E-DPDCH supports multi-code transmission.

When adopting multi-code transmission, the E-DPDCH supports the maximum

configuration of 2 SF2 + 2 SF4. Table 3-1 shows the timeslot formats of the

E-DPDCH.

Table 3-1 Timeslot Formats of the E-DPDCH

3.2.1.2 Introduction to the E-DPCCH (E-DCH Dedicated Physical Control Channel)

Figure 3-3 shows the frame structure the E-DPCCH. The E-DPCCH is used to carry the

control information of the E-DCH.

E-TFCI: the transmission format combination indicator of the E-DCH (7bit)



RSN: HARQ retransmission sequence number (2bit)

Happy Bit: scheduling feedback bit from the UE (1bit)

Figure 3-3 Frame Structure of the E-DPCCH

The E-DPCCH adopts the spreading factor of 256 invariably. The modulation mode is

BPSK. Similar to the E-DPDCH, the E-DPCCH supports 2ms TTI and reserves 10ms

TTI.

3.2.1.3 Introduction to the E-AGCH (E-DCH Absolute Grant Channel)

The E-AGCH is a downlink common physical channel for carrying E-DCH absolute grant

information. The channel only exists in the serving cells of an E-DCH. Figure 3-4 shows

the frame structure of the E-AGCH.

Figure 3-4 Frame Structure of the E-AGCH

The E-AGCH adopts a spreading factor of 256 invariably and the modulation mode of

QPSK. The absolute grant information consists of a grant value (5 bits) and process



activation indicator (1 bit). The process activation indication bit is used to indicate

whether the absolute grant targets at a specific HARQ process or all HARQ processes.

3.2.1.4 Introduction to the E-RGCH (E-DCH Relative Grant Channel)

The E-RGCH is a downlink physical channel for carrying E-DCH relative grant

information. Figure 3-5 shows the frame structure of the E-RGCH.

Figure 3-5 Frame Structure of the E-RGCH

The E-RGCH adopts a spreading factor of 128 invariably and the modulation of QPSK. A

relative grant is transmitted using 3, 12, or 15 consecutive slots and in each slot a

sequence of 40 ternary values is transmitted. The channels are divided into two types:

E-RGCH in the serving cell and E-RGCH in the non-serving cell. The E-RGCH in the

serving cell can carry instructions (UP, HOLD, and DOWN) of increasing, keeping, and

decreasing the power of a UE. The E-RGCH in the non-serving cell is used to carry cell

payload indication information and instructions of keeping and decreasing the power of a

UE. The UE can receive relative grant information from serving cells and non-serving

cells and combine the received grant information.

The setting of TTI decides the mode in which the E-RGCH relative grant information is

sent.

When TTI is 2 ms, the relative grant information from the serving cell is sent once

every 2 ms.

When TTI is 10 ms, the relative grant information from the serving cell must be sent

within 12 timeslots, that is, the relative grant instruction is sent once every 8 ms.



The relative grant information from the non-serving cell must be sent within 15

timeslots, that is, the relative grant instruction is sent once every 10 ms.

3.2.1.5 Introduction to the E-HICH (E-DCH HARQ Acknowledge Indication

Channel)

The E-HICH is a downlink physical channel carrying HARQ confirmation indication (ACK

and NACK). An HARQ confirmation indication is carried over 3 or 12 consecutive

timeslots corresponding to TTI of 2ms or 10ms respectively. In RLS containing serving

cells, the HARQ confirmation indication value is 1 (ACK) or -1 (NACK); in RLS with

non-service E-DCH, the HARQ acknowledge indication value is 1 (ACK) or 0 (NACK).

The E-HICH adopts the spreading factor of 128 invariably and the modulation of QPSK

and has the same frame structure as the E-RGCH. If an E-RGCH and an E-HICH target

at the same UE, they share the same spreading factor of 128. They are distinguished

from each other through different signature sequences.

3.2.2 Basic Principles of HSUPA

During the working process of HSUPA, the UE first sends scheduling messages to the

Node B over the E-DPDCH. The scheduling message includes 4-bit high priority logical

channel ID, 9-bit UE buffer occupancy status (including 5-bit Total E-DCH Buffer Status,

namely TEBS, and 4-bit Highest Priority Logical Channel Buffer Status, namely HLBS),

5-bits UE power status, and the scheduling request of the Happy bit carried over the

E-DPCCH for requesting the Node B to distribute resources.

The serving Node B decides the scheduling grant according to the QoS information and

scheduling request information of the UE. The scheduling grant has the following

attributes:

The scheduling grant is limited to the selection of E-DCH TFC and is not used in the

selection of DCH TFC.

The scheduling grant controls the maximum E-DPDCH/DPCCH power ratio of the

activating process. In case of non-activating process, the power ratio is 0 and the

UE is prohibited to send data.



All grants are certain and the scheduling grant can be sent at the interval of TTI or

lower frequency.

The scheduling grant sent by the Node B can be divided into two categories: absolute

grant and relative grant. The former is the absolute limitation on the maximum resources

available to the UE; the later increases or reduces the value of the previous grant. The

absolute grant is sent by the serving cell of the serving E-DCH and is effective to a UE, a

group of UEs, or all UEs. The relative grant (updating) is sent by the serving Node B or

non-serving Node B as the supplement of the absolute grant. The scheduling mechanism

controlled by the Node B can swiftly control the Raise over Thermal (RoT).

The UE sends data after selecting Retransmission Sequence Number (RSN), HARQ RV

version, and the power difference between E-DPDCH and E-DPCCH according to the

scheduling information (consisting of absolute grant and relative grant) and the

ACK/NACK sent previously.

From the perspective of the overall UTRAN protocol, the basic working principles of the

HSUPA technology are shown in Figure 3-6.



Figure 3-6 Basic Principles of HSUPA

SRNC DRNC

MAC-es FP

MAC-d

NodeBs Iur/Iub FP

Scheduler

MAC-e

NodeBd FP

MAC-e

UE

MAC-e/ MAC-es

MAC-d

DTCHs

E-DPDCH E-DPCCH

E-AGCH (Absolute Grants, "E-RNTI" -> UE)

serving cell

E-HICH (ACK/NACKs) E-RGCH (relative grants) (ChCode, signature -> UE)

MRC MRC

1 TNL bearer per MAC-d flow

Iur/Iub FP

Figure 3-6 shows the connection between the UE that uses the E-DCH and is in the soft

handover (SHO) status and the URTAN, as well as the protocols related to the HSUPA at

both the UE and network side. Figure 3-6 shows the basic working principles of the

HSUPA.

E-DCH active set: the cell set carried by the E-DCH between the Node B and the

UE. An E-DCH active set can be a sub-set of the DCH active set.

E-DCH serving cell: the cell where the UE receives the absolute grants. The UE has

only one E-DCH serving cell.

E-DCH serving RLS: a group of RLs containing the E-DCH serving cell. It is

generally the cell set of the E-DCH active set under the Node B of the E-DCH

serving cell.



Non-serving E-DCH RLS: the E-DCH cell set of all non-serving E-DCH RLS under

the Node B which has no E-DCH serving cell.

The HSUPA is characterized by the scheduling under control of the Node B. The

following describes the scheduling process:

A UE has an E-DCH serving cell. The Node B of the E-DCH serving cell is

responsible for E-DCH scheduling. The E-DCH serving cell sends scheduling

command (namely absolute grant) over the downlink E-AGCH to the UE. The

absolute grant specifies the absolute value of the maximum resources available to a

UE. The absolute grant includes E-RNTI and maximum transmit power of the UE.

The E-DCH serving cell and non-E-DCH serving cell send relative grant over the

downlink E-RGCH to the UE. The relative grant is used to adjust the absolute grant.

The values of the relative grant include UP, HOLD, and DOWN. Only serving

E-DCH RLS can send UP; while non-serving E-DCH RLS can only send HOLD or

DOWN. When the uplink payload is too large, the non-serving E-DCH RLS sends

DOWN.

Upon receiving the grant information, the UE makes a choice in respect of the

E-TFC. It sends data (including resent data) over the E-DPDCH and sends the

E-TFC information, HARQ RV (RSN) and the Happy bit over E-DPCCH . The

Happy bit is used to inform the Node B whether the UE is satisfied with the allocated

resources and grants or not, that is, whether higher grant is needed.

The Node B performs combination for the E-DCH data received by different cells of

the Node B and submits it to the Mac-e for processing. Each UE has a Mac-e in

Node B. The Mac-e demultiplexes Mac-e PDU into MAC-es PDU and sends it to the

RNC. The Mac-e also sends the E-DCH scheduling information and HARQ

response ACK/NACK.

Each UE has a Mac-es entity in the SRNC. The Mac-es entity performs macro

diversity combination for MAC-es PDUs from different Node Bs, reorders and

divides them into Mac-d PDU, and then sends them to the Mac-d.

HSUPA also supports non-scheduling transmission which means UE can transmit at any

time without the scheduling information. The non-scheduling transmission is just like the



DPCH of R99 and is usually used to carry the service which is delay sensitive, such as

signaling, conversational service, and streaming service.

3.3 Basic Functions of HSUPA

3.3.1 ZWF25-01-005 HSUPA Common Carrier with R99

Carrier frequency sharing between HSUPA and R99 means that the cell can provide

uplink R99 service and HSUPA service simultaneously and can allocate common

resources reasonably between R99 and HSUPA. These common resources include

transmit power and downlink channels of E-AGCH, E-RGCH and E-HICH, transport

bandwidth of the Iub interface, and uplink interference of the cell.

HSUPA is generally used with HSDPA. If the operator is using the RAN of ZTE and has

purchased the license of the HSUPA basic function package, the HSUPA function can be

enabled in a cell supporting HSDPA. By configuring the parameter hspaSptMeth in

OMCR, both R99 and HSUPA services are also enabled simultaneously in a cell. The

perfect RRM algorithm of ZTE can guarantee reasonable allocation of cell common

resources between these two types of services.

If the operator wants to close the HSUPA function when the cell supports HSUPA

capability, the operator can set hsuStat to Inactive.

3.3.2 ZWF25-01-005 HSUPA Dedicated Carrier

HSUPA is generally used with HSDPA together. You can adopt the same carrier

frequency for R99 and HSUPA to realize R99 and HSUPA services simultaneously or use

different carrier frequency for them to support HSUPA/HSDPA service only.

When the operator has more frequency resources than the requirement of R99 service, it

can adopt different frequencies for HSUPA/HSDPA service. Since the frequency

utilization efficiency of the E-DCH is higher than that of the DCH, the operator can obtain

higher uplink peak rate and cell throughput, improve the QoS of the service, and reduce

the cost of high speed data service.



To realize the traditional CS service and low-speed PS service carried on the DCH, a

frequency to carry R99 service is also needed. The UMTS RAN of ZTE supports the

access to different frequencies for the users according to various service types.

If you use the UMTS RAN of ZTE and have purchased the license of the HSUPA basic

function package, you can enable the HSUPA function for a cell. By configuring the

parameter hspaSptMeth in OMCR, you can enable a cell to support HSUPA/HSDPA only.

The cell does not support the R99 service separately but supports concurrent

provisioning of the CS services and the PS services

If the operator wants to close the HSUPA function when the cell supports HSUPA

capability, the operator can set hsuStat to Inactive.

3.3.3 ZWF25-01-003 HSUPA Cell Indicator in Idle Mode

The indicator of a HSUPA cell can be broadcasted through the system message SIB5 or

SIB5bis. When searching cells, the terminal can figure out whether a cell supports the

HSUPA service according to the indicator and then selects a desired cell accordingly. For

example, a user holding the HSUPA data card can search the carrier frequency

supporting the HSUPA service within a sector. The terminal decides the policy of

selecting a cell according to the capability of cells.

3.3.4 ZWF25-01-004 HSUPA UE Category Support

The UMTS RAN of ZTE supports all HSUPA terminal category levels of the 3GPP

protocol. The category levels reflect the extent to which a terminal supports the HSUPA

service. For details, refer to 3GPP TS 25.306. RNC configures the Maximum Set of

E-DPDCHs (NBAP IE) to Node B according to the minimum SF between the SF

supported by UE category and the SF required by the MBR in RAB ASSIGNMENT

REQUEST.



Figure 3-7 Requirements of 3GPP on HSUPA UE Categories

3.3.5 ZWF25-01-024 HSUPA 2ms TTI

The UMTS RAN of ZTE supports the HSUPA with the TTI of 2ms. Each cell can be

configured supporting 2ms TTI or not by the parameter tti2msSuptInd (for neighboring

RNC cell, by the parameter edchTti2SuptInd).

When adopting 2ms short frame, HSUPA can reduce the transmission time delay. As a

result, the air interface can transmit data at a time delay shorter than that of 10ms frame,

and the frame alignment time during the data framing of the transmitter also decreases.

The use of 2ms frame can reduce the Round Trip Time (RTT) of HARQ process under

the control of the Node B and decrease the fast scheduling response time. In contrast to

10ms frame, 2ms frame can more effectively utilize the resources and obtain larger

system capacity.

The 2ms TTI HSUPA adopts the scheduling interval of 2ms. The Node B specifies the

value of Rate Grant (RG) according to the payload of the current cell and sends it to the

user. With the increase of cell load, the 2ms TTI HSUPA, in contrast to the 10ms TTI

HSUPA, can improve the performance generated from the cell throughput. Obviously, the

smaller the TTI is, the larger the performance will be.

3.3.6 ZWF25-01-014 HSUPA HARQ

HSUPA adopts a fast HARQ which allows the Node B to fast retransmit data wrongly

received. The fast HARQ is implemented in the MAC-e layer, which is terminated at the

Node B. In the traditional R99, the data packets are retransmitted by the Radial Link

Controller (RLC) under the control of the RNC. In the acknowledgement mode, the RLC



retransmits the RLC signaling and data from the Iub interface with the time delay of more

than 100 ms. The retransmission time delay of HARQ (the retransmission time delay of

10ms TTI is 40 ms and the retransmission time delay of 2ms TTI is 16 ms) is much

shorter than the retransmission time delay in the RLC layer, greatly reducing the time

delay jittering of TCP/IP service and services sensitive to response time.

3.3.7 ZWF25-01-021 HSUPA 1.45Mbps Peak Bit Rate

The UMTS RAN of ZTE supports the HSUPA peak rate of 1.45 Mbps. When a terminal

uses interactive or background services carried over the E-DCH, the peak rate on the

MAC layer can reach to 1.45 Mps.

3.3.8 ZWF25-01-022 HSUPA 16 Users per Cell

The UMTS RAN of ZTE supports the running of 16 HSUPA users in a single cell, which is

controlled by parameter of EdchTrafLimit. For details of the parameter, refer to ZTE

UMTS Admission Control Feature Guide.

3.3.9 ZWF25-01-023 HSUPA 2 Mbps Peak Bit Rate

The UMTS RAN of ZTE supports the HSUPA peak rate of 2 Mbps. When a terminal uses

interactive or background services carried over the E-DCH, the peak rate on the MAC

layer can reach to 2 Mbps.

3.3.10 ZWF25-01-024 HSUPA 5.76 Mbps Peak Bit Rate

The UMTS RAN of ZTE supports the HSUPA peak rate of 5.76 Mbps. By adopting the

2ms TTI and the multiplexing of 2 SF2 * 2 SF4, a UE can enjoy interactive or background

services carried over the E-DCH at the uplink peak rate of 5.76 Mbps. This function can

be controlled by parameter fourEChAllowedInd. For neighboring RNC cell, the cell of

E-DCH SF Capability can be configured by the parameter edchSfCap.

ZTE plays a leading role in the R&D of HSPA. The HSUPA high-performance radio

resources scheduling algorithm has solved the problem of mutual-interference between

HSDAP and HSUPA when they are transmitted by the same terminal at the maximum bit

rate. ZTE has won the recognition from the telecom industry for its achievement in this



aspect. In the telecom exhibition held in Barcelona on February 11 2008, ZTE

demonstrated its UMTS HSUPA 5.76 Mbps.



controlled by the parameter of EdchTrafLimit. For details of the parameter, refer to ZTE










3.3.14 ZWF25-02-001 PS Interactive/Background Service over HSUPA

HSUPA services are carried over the enhanced dedicated channel E-DCH. Adopting the

BPSK modulation and HARQ, the E-DCH provides higher bit rate and enables multiple

users to share the load of uplink cells, which make it suitable to carry interactive and

background services with the high bursting feature. The peak rate of the channel can

effectively improve the QoS.

The UMTS RAN of ZTE supports the maximum uplink bit rate of 5.76 Mbps. But the

actual maximum bit rate available to users depends on the capability level of the terminal,

the maximum bit rate (MBR) subscribed in the core network (CN), payload of the system,

and the radio environment at the time of access.

The RAB radio parameters of the interactive/background PS data services of the ZTE

UMTS RAN comply with 3GPP TS 34.108 protocol.



3.3.15 ZWF25-02-002 PS Streaming Service over HSUPA

The UMTS RAN of ZTE supports carrying PS streaming services over the E-DCH.

The PS streaming service requires guaranteed transmission bit rate and shorter time

delay. According to the RAB parameters assigned by the CN, the RNC sends the GBR

configured for the PS streaming service to the Node B, instructs the service to use the

non-scheduling grants, so as to guarantee that the PS streaming service enjoys the

priority in the scheduling by the Node B and meets the requirement of GBR. The

mapping of scheduling priority is related to the QoS mapping of the RRM. Refer to

section 3.4 for more details. Section of 3.5.2 provides the details on the scheduling

mechanism of the Node B.

The RAB Radio parameters of the streaming PS data services of ZTE UMTS RAN

completely comply with 3GPP TS 34.108.

3.3.16 ZWF25-02-003 RAB Combination for CS over DCH and PS over

HSUPA

The UMTS RAN of ZTE supports concurrent provisioning of the CS services and the PS

I/B/S services carried over HSUPA. The CS services include:

CS AMR voice conversation services

CS data conversation services, such as video telephony service

CS data streaming service, such as FAX service

CS WAMR voice conversation services

The current provisioning of one CS service and up to three PS services is supported.

When the CS services and the PS services carried over the HSUPA channel are

provided concurrently, the actual maximum bit rate of the uplink PS services depends on

the capability level of the terminal, the MBR subscribed in the core network (CN),

payload of the system, and the radio environment at the time of access.

The RAB radio parameters used for the concurrent carrying of CS service and PS

service over the HSUPA of the ZTE UMTS RAN comply with 3GPP TS 34.108.



3.3.17 ZWF25-02-004 RAB Combination for Multiple Packet Data Services

over HSUPA

This attribute supports the concurrent provisioning of up to three PS

interactive/background/streaming services. The MBR of each PS service depends on the

subscribed bit rate in the CN, and the total bit rate of all services cannot exceed the

highest bit rate supported by HSUPA. The highest bit rate depends on the UE category

level, load of the system, and radio environment at the time of access.

The RAB radio parameters used for carrying the multiple concurrent PS services over

the HSUPA of the ZTE UMTS RAN comply with the 3GPP TS 34.108.

3.3.18 ZWF25-02-011 SRB over HSUPA

The attribute supports carrying signaling over the E-DCH. The signaling RB has higher

requirement on time delay. Therefore, the signaling RB can be processed as a special

streaming service. In comparison with normal streaming service, the signaling RB has

higher scheduling priority. The mapping of scheduling priority is related to the QoS

mapping of the RRM. Section 3.4 provides more details. Section 3.5.2 provides details

on the scheduling mechanism of the Node B. This function can be controlled by

parameter srbOnEdchSwch. For more details, refer to ZTE UMTS DRBC Algorithm

Feature Guide.

3.3.19 ZWF25-05-002 HSUPA Nominal Bit Rate for I/B Service

When the UMTS RAN of ZTE uses the E-DCH to carry the interactive/background

services, it supports configuring the nominal bit rate edchNormBitRate. For more details,

refer to ZTE UMTS QoS Feature Guide. The RNC configures GBR for

interactive/background services according to the edchNormBitRate and sends the

setting to the Node B. When performing HSUPA fast scheduling, the Node B provides

minimum GBR for interactive/background services. The edchNormBitRate can be

configured as 0.


The UMTS RAN of ZTE supports the running of 192 HSUPA users in a single cell, which



is controlled by the parameter of EdchTrafLimit. For details of the parameter, refer to ZTE


3.4 Key Algorithms in the RNC

3.4.1 HSUPA Mobility Management

The UMTS RAN of ZTE supports seamless handover of a UE inside the coverage of

HSUPA, between the coverage of HSUPA and R5/R99, and between the coverage of

HSUPA and 2G. The cell attribute (hspaSptMeth) of the HSUPA coverage can be set to

Support HSUPA, HSDPA and DCH, or Support HSUPA and HSDPA; the cell attribute

(hspaSptMeth) of the HSDPA coverage can be set to Support HSDPA and DCH, Support

HSDPA only, Support HSUPA, HSDPA and DCH, or Support HSUPA and HSDPA; the

cell attribute (hspaSptMeth) of R99 can be set to Not Support HSUPA and HSDPA.

If the cell attribute hsuStat is Inactive, the RNC considers the cell doesnt support

HSUPA.

For improving the compatibility of HSUPA over Iur, the UMTS RAN of ZTE supplies two

more parameters RncFeatSwitch2 and RncFeatSwitch4 which can be configured based

on office direction. The RncFeatSwitch2 is used to configure whether the neighbor RNC

supports HSUPA or not. If the neighbor RNC doesnt support HSUPA, ZTE RNC will

transfer EDCH to DCH before processing the Iur signaling flow. The RncFeatSwitch4 is

used to configure whether DSCR is adopted or not when doing hard handover SRNS

relocation for HS-DSCH configuration.

For details on the algorithm related to HSUPA mobility, refer to ZTE UMTS Handover

Control Feature Guide.

Similar to DCH, E-DCH is a dedicated uplink channel that supports SHO. Most mobility

algorithms of the E-DCH are the same as those of the DCH. The only difference between

them lies in the fact that the E-DCH supports E-DCH serving cell variation and switching

from the E-DCH to the DCH caused by the mobility.

The following takes the intra-RNC E-DCH handover as an example to describe the flow.

The inter-RNC E-DCH handover is similar to the intra-RNC E-DCH handover.



3.4.1.1 ZWF25-03-002 E-DCH Serving Cell Change inside Active Set

Similar to the HSDPA, the HSUPA also has a serving cell change flow. The difference lies

in the fact that the E-DCH is an uplink link that supports SHO. The bearer of the E-DCH

serving cell is the same as that of the E-DCH non-serving cell. When the E-DCH serving

cell varies within the active set, the Iub/Iur interface does not need to set up a new

E-DCH bearer.

The following figure shows the E-DCH serving cell change flow.

Figure 3-8 E-DCH Intra-frequency Cell Change Flow

Before the E-DCH serving cell changes, the UE has maintained connections with

multiple cells:

1. The UE measures the quality of the intra-frequency cells in the neighboring cell list

according to the measurement control mechanism of the RNC, judges the

occurrence of intra-frequency events, and sends the measurement report to the

RNC.

2. The RNC decides to change the E-DCH serving cell according to the events

reported by the UE and availability of the radio resources.

3. The RNC sends the NBAP message Radio Link Reconfiguration Prepare to the

serving Node B and reconfigures it as the non-serving E-DCH RL.

UETarget

NodeB

1. Measurement Report 1D

Serving

NodeBRNC

2. Decide to

Change E-DCH

Serving Cell

3. Radio Link Reconfiguration Prepare

5. Radio Link Reconfiguration Ready



7. Radio Link Reconfiguration Commit


9. Physical Channel Reconfiguration

10. Physical Channel Reconfiguration Complete




destination Node B and reconfigures it as the serving E-DCH RL.

5. The serving Node B returns the Radio Link Reconfiguration Ready message to the

RNC.

6. The destination Node B returns the Radio Link Reconfiguration Ready message to

the RNC.

7. The RNC sends the Radio Link Reconfiguration Commit message with the time of

changing the E-DCH serving RL to the serving Node B.


changing the E-DCH serving RL to the destination Node B.

9. The RNC sends the RRC message Physical Channel Reconfiguration to the UE

and instructs it to change the E-DCH serving cell.

10. The UE switches to the new E-DCH serving RL at the time specified by the RNC

and sends the RRC message Physical Channel Reconfiguration Complete to the

RNC.

3.4.1.2 ZWF25-03-003 & ZWF25-03-004 Switching between E-DCH and DCH

The switching between E-DCH and DCH includes intra-cell switching and inter-cell

switching.

The following figure shows the flow of intra-cell switching between E-DCH and DCH. For

example, the UE supports handover from the cell that supports the E-DCH to an

inter-frequency neighboring cell that does not supports the E-DCH. In this case, it is

necessary to enable the compression mode. Because the UE does not support

concurrent processing of the E-DCH and compression mode, it is necessary to perform

intra-cell fallback from the E-DCH to the DCH.



Figure 3-9 Intra-cell Fallback from E-DCH to DCH

UE NodeB RNC




4. Transport Channel Reconfiguration

5. Transport Channel Reconfiguration Complete


Node B to reconfigure the E-DCH as a DCH.

2. The Node B returns the Radio Link Reconfiguration Ready message to the RNC.


channel switching to the Node B.

4. The RNC sends the RRC message Transport Channel Reconfiguration to the UE to

reconfigure the E-DCH as a DCH.

5. The UE switch the E-DCH to the DCH at the time specified by the RNC and sends

the RRC message Transport Channel Reconfiguration Complete to the RNC.

Figure 3-10 shows the flow of inter-cell switching between E-DCH and DCH. This

example describes a scenario of fallback from the inter-cell E-DCH to the DCH. The UE

takes the hard handover from a cell that supports the E-DCH to an intra-frequency

neighboring cell that does not support the E-DCH.

Figure 3-10 Inter-cell Fallback from E-DCH to DCH

UESource

NodeBRNC

1. Radio Link Setup Request

2. Radio Link Setup Response

3. Transport Channel Reconfiguration

4. Transport Channel Reconfiguration Complete

Target

NodeB

5. Radio Link Deletion Request

6. Radio Link Deletion Response



1. The RNC sends the NBAP message Radio Link Setup Request to the target Node

B to set up a radio link of the DCH.

2. The destination Node B returns the Radio Link Setup Response message to the

RNC.

3. The RNC sends the RRC message Transport Channel Reconfiguration to the UE to

reconfigure the E-DCH as a DCH.

4. The UE sends the RRC message Transport Channel Reconfiguration Complete to

the RNC to switch the E-DCH to a DCH.

5. The RNC sends the NBAP message Radio Link Deletion Request to the source

NdoeB to delete the bearer of the original E-DCH.

6. The source Node B returns the Radio Link Deletion Response message to the

RNC.

3.4.2 ZWF25-04-005 HSUPA Dynamic Channel Adjustment

For details on the HSUPA channel dynamic adjustment algorithms, refer to ZTE UMTS

DRBC Algorithm Feature Guide.

3.4.3 ZWF25-04-007 Code Allocation for HSUPA

For details on the HSUPA code resources management algorithms, refer to ZTE UMTS

Code Resource Feature Guide.

3.4.4 ZWF25-04-006 Power Allocation for HSUPA

For details on the HSUPA power control algorithms, refer to ZTE UMTS Power Control

Feature Guide.

3.4.5 ZWF25-04-001 Admission Control for HSUPA Service

For details on the HSUPA admission control algorithms, refer to ZTE UMTS Admission




3.4.6 ZWF25-04-002 Overload Control for HSUPA Service

For details on the HSUPA load control algorithms, refer to ZTE UTMS Overload Control

Feature Guide.

3.4.7 ZWF25-04-003 Load Balance for HSUPA Service

For details on the HSUPA load balance algorithms, refer to ZTE UMTS Load Balance

Feature Guide.

3.4.8 ZWF25-04-004 Congestion Control Strategy for HSUPA

For details on the HSUPA congestion control algorithms, refer to ZTE UMTS Congestion


3.4.9 ZWF25-05-001 QoS Mapping for HSUPA Service

For details on the HSUPA QoS mapping algorithms, refer to ZTE UMTS QoS Feature

Guide.

3.5 Key Calculations and Algorithms in Node B

3.5.1 Introduction to HARQ

HARQ integrates the Forward Error Correction (FEC) and Automatic Repeat Request

(ARQ). HARQ adjusts the bit rate of a channel according to the condition of the link and

integrates the FEC with retransmission. HARQ allows the receiver to save the received

data when decoding fails and requests the transmitter to retransmit data. The receiver

combines the retransmitted data with the previously-received data. The HARQ

technology can improve the system performance, effectively adjust the bit rate of valid

code elements, and compensate the code errors brought about by the link adaptation.

Introduced to HSUPA by the 3GPP, HARQ can effectively reduce the transmission time

delay and improve the retransmission efficiency.

A basic principle of the fast HARQ of HSUPA is to add a HARQ entity to the Node B. In

case of receiving failure, the Node B requests the UE to retransmit the uplink packets. In



the uplink direction, the HARQ adopts N channels SAW protocol (NSAW), which is

similar to the protocols used by HSDPA. Additionally, the Node B can also use different

methods to combine the retransmission tasks of a packet and reduce the reception

Ec/No of each transmission requirement. The HARQ function of HSUPA is mainly

applied in the MAC-e and physical layer of the Node B. Through the HARQ, the Node B

can effectively improve the data transmission speed and reduce the time delay.

In HSUPA, 10ms TTI corresponds to 4 HARQ processes; and 2ms TTI corresponds to 8

HARQ processes.

The HARQ technology has two implementation modes: If the retransmitted data is the

same as the data transmitted initially, this mode is referred to as Chase Combine (CC) or

soft combining; if the retransmitted data is different from the data transmitted initially, this

mode is referred to as Incremental Redundancy (IR).The later mode is better than the

former in performance and requires larger memory in the terminal. The default memory

of a terminal is designed according to the MBR and soft combining mode supported by

the terminal. When the terminal works at the MBR, it can only use the soft combining.

When working at lower transmission rate, the terminal supports both of the two modes.

The IR mode needs a more complex memory of the UE. The 3GPP does not impose

limitations on the specific mode. The CC mode can be viewed as a special form of the IR

mode. The parameter harqRvConfig is used to specify which HARQ mode should be

used (for neighboring RNC cell, by the parameter edchHarqCombCap).

The system adopting the fast HARQ may have a higher Block Error Rate (BLER) in the

first transmission. This is because the time delay of the packets with retransmission

reception errors drops obviously in comparison with the RLC retransmission. Higher

BLER target can reduce the transmission power requirement on the UE when it transmits

data at a certain bit rate. If two cells have the same payload, the application of the fast

HARQ can improve the capacity of the cell. When the data rate is invariable, reducing the

energy of each bit helps to improve the coverage. Certainly, improving the BLER target

excessively is costly because the time delay at the peak rate does not occur frequently

when the RLC retransmission is not started, but data is retransmitted in large quantity,

the user can feel the average time delay. Because more and more packets need to be

retransmitted, the valid throughput of invariable bit rate also drops with the increase of

the BLER.



In the SHO process, the HSUPA HARQ introduces a complex process that is unavailable

in the HSDPA HARQ. In the CDMA system, the SHO gain comes from the correct

reception of packets at a Node B while another Node B is unable of decoding. Therefore,

one Node B sends an ACK and another Node B sends a NACK. On this occasion, the

network has received the packet, and the UE shall no longer send the same packet. See

Figure 3-11. Accordingly, in the Node B with reception failure, the HARQ process can

recover from the incorrect reception. The RNC must ensure the sequence of packet

transmission and combine the packets received from different Node Bs selectively.

Figure 3-11 SHO of HSUPA HARQ

3.5.2 Node B Based Quick Packet Scheduling Technology

The fast scheduling is a key technology of the HSUPA and is realized in the MAC-e of

the Node B. For details on the HSUPA fast scheduling function, refer to ZTE UMTS Node

B HSUPA Packet Scheduling Feature Guide.

3.5.3 ZWF25-04-010 HSUPA E-AGCH CLPC

E-AGCH closed-loop power control which can make a closed-loop according to the

feedback of DPCCH and CQI will apply the service channel power control on the control

channels. When the channel quality information obtained by DPCCH or CQI forms the

power control command, this command will not only be transmitted to service channel

but also to the corresponding control channel in order to implement the consistent



association of service channel and corresponding control channel and ensure the

reliable transfer of control information. The power control can be used to resist the

modification of radio environment.

The advantages of E-AGCH closed-loop power control are shown as below:

To effectively reduce the network interference from the channel without power

control to increase system capacity

To effectively use downlink transmit power, reduce interference and improve

HSUPA performance

From the protocol description, E-AGCH power control is controlled by Node B. ZTE

adopts two methods in the following:

Fixed power control

Concomitant CQI/HS-SCCH power control

If the concomitant CQI/HS-SCCH power control method is used for E-AGCH, RNC will

change the power-offset value during the soft hand-over because E-AGCH has no soft

hand-over combination. HS-SCCH can control the channel quality due to the

outer-power control. Therefore the concomitant CQI/HS-SCCH power control for

E-AGCH can provide better performance.

The first method is directly controlled by HSUPA scheduler to adjust E-AGCH power

value. For the second method, HSDPA will report the latest scheduled HS-SCCH power

to HSUPA. The last E-AGCH power is derived from the sum of HS-SCCH power and the

fixed power offset of HS-SCCH relative to E-AGCH.

The power control method selection is configured by OAM.

Fixed power control arithmetic

The purpose of fixed power control arithmetic is to use high enough fixed transmit power

for each HSUPA user (The fixed power transmission must be satisfied with the

performance when the UE is located in the cell margin). The power configuration is

easier for this method. However, it will possibly waste Node B power resources and

create unnecessary interference in the cell.



Concomitant CQI/HS-SCCH power control arithmetic

E-AGCH is HSUPA control channel which is transmitted to UE by Node B. Based on an

overall consideration of E-AGCH, the power control strategy is described in the following.

According to the description of 3GPP protocol, one UE can be HSUPA user and HSDPA

user simultaneously because the same serving cell exists between HSUPA and HSDPA.

The E-AGCH which belongs to HSUPA serving cell can use CQI and HS-SCCH of

HSDPA information to implement E-AGCH power control and can adjust E-AGCH

transmit power according to CQI information reported by UE and HS-SCCH power

control.

CQI is the HS-SCCH quality indicator and will not be affected by the handover state and

service type. Due to the feedback of HS-SCCH demodulation in Node B, the influence of

the receiver performance and the speed of different UE can be shielded by the outer

power control arithmetic to control the channel quality.

Because of the same demodulation requirement between E-AGCH and HS-SCCH, the

concomitant HS-SCCH power control for E-AGCH power based on the blinding of

E-AGCH and HS-SCCH transmit power can effectively use HS-SCCH outer power

control to dynamically adjust E-AGCH transmit power with the channel quality. This

method can save E-AGCH power loss and reduce unnecessary interference to other

downlink channels.

3.5.4 ZWF25-04-011 HSUPA E-RGCH/HICH CLPC

E-RGCH/HICH closed-loop power control which can make a closed-loop according to

the feedback of DPCCH and CQI will apply the service channel power control on the

control channels. When the channel quality information obtained by DPCCH or CQI

forms the power control command, this command will not only be transmitted to service

channel but also to the corresponding control channel in order to implement the

consistent association of service channel and corresponding control channel and ensure

the reliable transfer of control information. The power control can be used to resist the

modification of radio environment.

The advantages of E-RGCH/HICH closed-loop power control are shown as below:



To effectively reduce the network interference from the channel without power

control to increase system capacity

To effectively use downlink transmit power, reduce interference and improve

HSUPA performance

From the protocol description, E-RGCH/HICH power control is controlled by Node B.

ZTE adopts two methods in the following:

Fixed power control

Concomitant DPCCH outer power control

The method of concomitant DPCCH outer power control will achieve better performance

because E-RGCH/HICH has soft handover combination to ensure the performance

without power-offset change.

For the method 1, E-RGCH/HICH power value is directly controlled by HSUPA scheduler.

For the method 2, the association between E-RGCH/HICH and DPCCH channel power

is directly implemented by hardware.

The power control method selection is configured by OAM.

4 Parameters and Configurations

4.1 Parameter List

Logic Name Parameter Name

hspaSptMeth(UUtranCellF

DD) HSPA Support Method

hspaSptMeth(UExternalUtr

anCellFDD) HSPA Support Method

edchNormBitRate E-DCH Uplink Nominal Bit Rate

RncFeatSwitchBit2 Support HSUPA Iur Interface Process

RncFeatSwitchBit4 Support Hard Handover DSCR

harqRvConfig HARQ RV Configuration



fourEChAllowedInd Four E-DPDCHs Allowed Indicator

srbOnEdchSwch Switch of supporting SRB on E-DCH

tti2msSuptInd Cell HSUPA 2ms TTI Support Indicator

hsuStat HSUPA Function Status

edchHarqCombCap

(UExternalUtranCellFDD) E-DCH HARQ Combining Capability

edchSfCap

(UExternalUtranCellFDD) E-DCH SF Capability

edchTti2SuptInd

(UExternalUtranCellFDD) 2ms E-TTI Support Indicator

4.2 Parameter Configurations

4.2.1 HSPA Support Method

OMC path

Path: GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN

Cell->HSPA Support Method

Parameter configuration

The serving cell supports the HSPA capability.

4.2.2 HSPA Support Method (Neighboring RNC Cell)

OMC path

Path: GUI: Managed Element ->UMTS Logical Function Configuration->External

Resource Configuration->External RNC Function->External UTRAN Cell->HSPA

Support Method


The neighboring RNC cell supports the HSPA capability.



4.2.3 E-DCH Uplink Nominal Bit Rate

OMC path

GUI: Managed Element ->UMTS Logical Function Configuration->Service

Configuration->QOS Function->Qos Basic Configuration->E-DCH Uplink Nominal Bit

Rate


When the interactive/background service is carried over the E-DCH, the uplink nominal

bit rate is equivalent to the GBR configured by the RNC for the Node B.

4.2.4 Support HSUPA Iur Interface Process

OMC path

Path: GUI: Managed Element->UMTS Logical Function Configuration->Link

Configuration->Iur Link->Whether Support HSUPA Iur Interface Process


It is based on the capability of DRNC. The parameter of RncFeatSwitch2 is set to 1 if the

DRNC supports HSUPA. Otherwise, it is set to 0.

4.2.5 Support Hard Handover DSCR

OMC path

Path: GUI: Managed Element->UMTS Logical Function Configuration->Link

Configuration->Iur Link->Whether Support Hard Handover DSCR


It is based on the capability of DRNC. The parameter of RncFeatSwitch4 is set to 1 if the

DRNC needs DSCR to do hard handover. Otherwise, it is set to 0.

4.2.6 HARQ RV Configuration

OMC path



Path: GUI: Managed Element ->UMTS Logical Function Configuration->HARQ RV

Configuration.


The default configuration is used.

4.2.7 Four E-DPDCHs Allowed Indicator

OMC path

Path: GUI: Managed Element ->UMTS Logical Function Configuration->PLMN Relating

Configuration->Logic RNC Configuration->Four E-DPDCHs Allowed Indicator.



4.2.8 Switch of supporting SRB on E-DCH

OMC path

Path: GUI: Managed Element ->UMTS Logical Function Configuration->PLMN Relating

Configuration->Logic RNC Configuration->Switch of supporting SRB on E-DCH.



4.2.9 Cell HSUPA 2ms TTI Support Indicator

OMC path


Cell->Cell HSUPA 2ms TTI Support Indicator



4.2.10 HSUPA Function Status

OMC path




Cell->HSUPA Function Status



4.2.11 E-DCH HARQ Combining Capability (Neighboring RNC Cell)

OMC path


Resource Configuration->External RNC Function->External UTRAN Cell->E-DCH HARQ

Combining Capability.


It is set according to the actual HARQ combining capability of the neighboring cell of the

DRNC.

4.2.12 E-DCH SF Capability (Neighboring RNC Cell)

OMC path


Resource Configuration->External RNC Function->External UTRAN Cell->E-DCH SF

Capability


It is set according to the actual E-DCH SF capability of the neighboring cell of the DRNC.

4.2.13 2ms E-TTI Support Indicator (Neighboring RNC Cell)

OMC path


Resource Configuration->External RNC Function->External UTRAN Cell->2ms E-TTI

Support Indicator




It is set according to the actual E-DCH 2ms TTI capability of the neighboring cell of the

DRNC.

5 Counter and Alarm

5.1 Counter List

5.1.1 Setup/Drop Rate Statistics

Counter No. Description

C310080056 Number of RRC connection attempt,UE Support HSDPA & EDCH

C310080198 Number of RRC connection access success,UE Support HSDPA +

EDCH

C310080219 Number of RRC connection access success by UE HSUPA categories 1







C310110345 Number of Failed RAB establishment in cell for CS domain,HSUPA user

number limit

C310110402 Number of Failed RAB establishment in cell for PS domain,HSUPA user

number limit

C310170483 Number of Failed HSUPA RAB establishment for PS

domain,Conversational Class

C310170495 Number of Failed HSUPA RAB establishment for PS domain,Streaming

Class


Class,UE hsupa category 1
















C310170514 Number of Failed HSUPA RAB establishment for PS domain,Interactive

Class















C310170533 Number of Failed HSUPA RAB establishment for PS domain,Background

Class


















C310170666 Number of Failed HSUPA RAB establishment in cell for PS

domain,Invalid RAB Parameters Value


domain,Failure in the Radio Interface Procedure

C310170668 Number of Failed HSUPA RAB establishment in cell for PS domain,UE

send rb setup fail


domain,Timeout of UU rb setup.


domain,TQUEUING Expiry


domain,Requested Traffic Class not Available


domain,Requested Guaranteed Bit Rate not Available


domain,Requested Guaranteed Bit Rate for DL not Available

C310170674 Number of Failed HSUPA RAB establishment in cell for PS domain,No

Resource Available


Resource Available In SRNC


domain,Downlink CE Congestion


domain,Downlink CE Congestion


domain,Downlink Power Resource Congestion

C310170679 Number of Failed HSUPA RAB establishment in cell for PS domain,Other

Downlink Resource Congestion





domain,Uplink CE Congestion


domain,Uplink Power Resource Congestion

C310170682 Number of Failed HSUPA RAB establishment in cell for PS domain,Other

Uplink Resource Congestion


domain,HSUPA user number limit


Resource Available In DRNC


domain,Access Restricted Due to Shared Networks


domain,Non-Standard Cause

C310170688 Number of Failed HSUPA RAB establishment in cell for PS domain,Due

to NodeB

C310170689 Number of Failed HSUPA RAB establishment in cell for PS domain,RL

Setup or Reconfig Fail

C310170690 Number of Failed HSUPA RAB establishment in cell for PS domain,RL

Setup or Reconfig Timeout


to IUB

C310170692 Number of Failed HSUPA RAB establishment in cell for PS domain,Iub

Congestion


UL Congestion


DL Congestion


TB Failure


FB Cause

C310170697 Number of Failed HSUPA RAB establishment in cell for PS domain,Iur

Congestion





Congestion


TB Failure


FB Failure

C310170701 Number of Failed HSUPA RAB establishment in cell for PS domain,UP

CE Limit


to RNC

C310220703 Number of Failed HSUPA RAB establishment in cell for PS domain,RB

Fail,UP Fail


domain,UCPMC Exception


domain,RLMM Exception

C310220706 Number of Failed HSUPA RAB establishment in cell for PS domain,CRM

Exception


domain,SCPM Exception

C310220708 Number of Failed HSUPA RAB establishment in cell for PS domain,RPM

Exception


domain,Othere RNC Cause


domain,Unspecified failure

C310170831 Number of Successful HSUPA RAB establishment for PS

domain,Conversational Class


domain,Streaming Class


domain,Streaming Class,UE hsupa category 1

















domain,Interactive Class


domain,Interactive Class,UE hsupa category 1














domain,Background Class,UE hsupa category 1


















C310180965 Attempted HSUPA RB setup number

C310171135 Attempted HSUPA MAC-d setup number

C310171149 Failed HSUPA MAC-d setup number,UL SF not supported

C310171150 Failed HSUPA MAC-d setup number,DL SF not supported

C310171151 Failed HSUPA MAC-d setup number,compressed mode not supported

C310171152 Failed HSUPA MAC-d setup number,invalid CM settings

C310171153 Failed HSUPA MAC-d setup number,requested configulation not

supported

C310171154 Failed HSUPA MAC-d setup number,nodeB Resources unavailable

C310171155 Failed HSUPA MAC-d setup number,power balancing status not

compatible

C310171156 Failed HSUPA MAC-d setup number,cell not available

C310171157 Failed HSUPA MAC-d setup number,transport resource unavailable

C310171158 Failed HSUPA MAC-d setup number,message not compatible with

receiver state

C310171159 Failed HSUPA MAC-d setup number,hardware faliure

C310171160 Failed HSUPA MAC-d setup number,uncertainty failure

C310171161 Failed HSUPA MAC-d setup number,none response

C310251515 Number Of RAB release for UTRAN Abnormal Reason for HSUPA:UE

HSUPA categories 1,conversation


HSUPA categories 1,streaming


HSUPA categories 1,interactive


HSUPA categories 1,backgroud

















C310251543 Number Of RAB normal release for UTRAN :UE HSUPA categories

1,conversation


1,streaming


1,interactive


1,backgroud


2,conversation


2,streaming


2,interactive


2,backgroud


3,conversation


3,streaming


3,interactive


3,backgroud





4,conversation


4,streaming


4,interactive


4,backgroud


5,conversation


5,streaming


5,interactive


5,backgroud


6,conversation


6,streaming


6,interactive


6,backgroud


7,conversation


7,streaming


7,interactive


7,backgroud

C310251571 Total number Of RAB release for UTRAN for PS-HSUPA

domain,conversation





domain,streaming


domain,interactive


domain,background

C310251583 Number of RNC initiate HSUPA release by Rab Release Request for

PS domain,conversation

C310251584 Number of RNC initiate HSUPA release by Rab Release Request for PS

domain,streaming


domain,interactive


domain,backgroud

C310251587 Number of RAB HSUPA release by RNC receive Iu-release :

conversation

C310251588 Number of RAB HSUPA release by RNC receive Iu-release : streaming

C310251589 Number of RAB HSUPA release by RNC receive Iu-release : interactive

C310251590 Number of RAB HSUPA release by RNC receive Iu-release : backgroud

C310281856 Number of RAB release by RNC initiate RAB release request for

PS-HSUPA by uesr inactive


PS-HSUPA by repeat integrity check


PS-HSUPA by UE initiate release


PS-HSUPA by lost UE connection


PS-HSUPA by relocation complete timer exceed


PS-HSUPA by radio interface fail


Documents

Document HSUPA