HSDPA Parameter Description PDF

RAN
HSDPA
Parameter Description
Issue
02
Date
2009-06-30
Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided AS IS without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
RAN
HSDPA
Contents
Contents
1 Introduction to This Document .......................................................................................... 1-1
1.1 Scope ..................................................................................................................................................... 1-1
1.2 Intended Audience.................................................................................................................................. 1-1
1.3 Change History ...................................................................................................................................... 1-1
2 Overview of HSDPA ............................................................................................................ 2-1

2.1 General Principles of HSDPA ................................................................................................................. 2-1
2.2 HSDPA Channels ................................................................................................................................... 2-2
2.2.1 HS-DSCH and HS-PDSCH............................................................................................................ 2-3
2.2.2 HS-SCCH ..................................................................................................................................... 2-3
2.2.3 HS-DPCCH................................................................................................................................... 2-4
2.2.4 DPCCH and DPCH/F-DPCH......................................................................................................... 2-4
2.3 Impact of HSDPA on NEs....................................................................................................................... 2-4
2.4 HSDPA Functions................................................................................................................................... 2-4
2.4.1 HSDPA Control Plane Functions.................................................................................................... 2-4
2.4.2 HSDPA User Plane Functions ........................................................................................................ 2-6
3 Control Plane......................................................................................................................... 3-1

3.1 Bearer Mapping...................................................................................................................................... 3-1
3.2 Access Control ....................................................................................................................................... 3-2
3.3 Mobility Management ............................................................................................................................ 3-2
3.4 Channel Switching ................................................................................................................................. 3-3
3.5 Load Control .......................................................................................................................................... 3-5
3.6 Power Resource Management................................................................................................................. 3-5
3.7 Code Resource Management................................................................................................................... 3-6
3.7.1 HS-SCCH Code Resource Management......................................................................................... 3-6
3.7.2 HS-PDSCH Code Resource Management ...................................................................................... 3-7
4 User Plane .............................................................................................................................. 4-1

4.1 Flow Control and Congestion Control..................................................................................................... 4-1
4.1.1 Flow Control ................................................................................................................................. 4-2
4.1.2 Congestion Control........................................................................................................................ 4-3
4.2 RLC and MAC-d.................................................................................................................................... 4-3
4.2.1 RLC .............................................................................................................................................. 4-3
4.2.2 MAC-d.......................................................................................................................................... 4-4
Issue 02 (2009-06-30)
Huawei Proprietary and Confidential
iii
RAN
HSDPA
Contents
4.3 MAC-hs Scheduling ............................................................................................................................... 4-4

4.3.1 Determining the Candidate Set....................................................................................................... 4-4
4.3.2 Calculating Priorities ..................................................................................................................... 4-5
4.4 HARQ.................................................................................................................................................... 4-5
4.4.1 HARQ Retransmission Principles .................................................................................................. 4-5
4.4.2 Soft Combining During HARQ...................................................................................................... 4-6
4.4.3 Preamble and Postamble ................................................................................................................ 4-6
4.5 TFRC Selection...................................................................................................................................... 4-7
4.5.1 Basic Procedure of TFRC Selection ............................................................................................... 4-7
4.5.2 Determining the TBSmax ................................................................................................................. 4-8
4.5.3 Determining the TBSused, Modulation Scheme, Power, and Codes................................................... 4-9
4.5.4 Determining the Number of MAC-d PDUs....................................................................................4-10
5 Parameters.............................................................................................................................. 5-1
6 Counters ................................................................................................................................. 6-1
7 Glossary.................................................................................................................................. 7-1
8 Reference Documents.............................................................................................................. 2
Issue 02 (2009-06-30)
iv
RAN
HSDPA
1 Introduction to This Document
Introduction to This Document
1.1 Scope
This document describes the HSDPA functional area. It provides an overview of the main
functions and goes into details regarding HSDPA control and user plane functions.
1.2 Intended Audience

It is assumed that users of this document are familiar with WCDMA basics and have a
working knowledge of 3G telecommunication.
This document is intended for:
l
System operators who need a general understanding of HSDPA
Personnel working on Huawei products or systems
1.3 Change History

This section provides information on the changes in different document versions.
There are two types of changes, which are defined as follows:
l
Feature change: refers to the change in the HSDPA feature.
Editorial change: refers to the change in wording or the addition of the information that
was not described in the earlier version.
Document Issues
The document issues are as follows:
l
02 (2009-06-30)
01 (2009-03-30)
Draft (2009-03-10)
Draft (2009-01-15)
Issue 02 (2009-06-30)
1-1
RAN
HSDPA
02 (2009-06-30)
This is the document for the second commercial release of RAN11.0.
Compared with 01 (2009-03-30) of RAN11.0, this issue incorporates the changes described in
the following table.
Change Type
Change Description
Parameter Change
Feature change
None.
None.
Editorial change
The description of MAC-hs Scheduling is

optimized. For details, see section 4.3
MAC-hs Scheduling.
The deleted parameters

are as follows:
l
MaxDchVoipHarqRt
MaxDchAmrHarqRt
The added parameters

are as follows:
The structure of the document is adjusted.
8KRSCLMT
16KRSCLMT
32KRSCLMT
64KRSCLMT
128KRSCLMT
256KRSCLMT
384KRSCLMT
None.
01 (2009-03-30)
This is the document for the first commercial release of RAN11.0.
Compared with draft (2009-03-10), this issue incorporates the following changes:
Change Type
Change Description
Parameter Change
Feature change
None
None
Editorial change
The structure of the docuement is adjusted.
None
Draft (2009-03-10)
This is the second draft of the document for RAN11.0.
Compared with draft (2009-01-15), draft (2009-03-10) optimizes the description.
Draft (2009-01-15)
This is the initial draft of the document for RAN11.0.
Issue 02 (2009-06-30)
1-2
RAN
HSDPA
Compared with issue 03 (2008-11-30) of RAN10.0, draft (2009-01-15) incorporates the

following changes:
Change
Type
Editorial
change
Issue 02 (2009-06-30)
Change Description
Parameter Change
The description of setting the

maximum number of retransmissions
on a service basis is added to section
4.3.1 "Determining the Candidate
Set."
The added parameters are as follows:
The description of a new resource

allocation method is added to section
4.5.3 "Determining the TBSused,
Modulation Scheme, Power, and
Codes."
The parameter RscAllocM is added

with a new value PowerCode_Bal.
The description of HSDPA is

rewritten for readability.
None
All the parameter names are replaced

with the corresponding parameter IDs.
None
MaxDchVoipHarqRt
MaxDchAmrHarqRt
MaxNonConverHarqRt
1-3
Overview of HSDPA
2.1 General Principles of HSDPA

To meet the rapidly growing demands for data services on the mobile network, 3GPP Release
5 introduced HSDPA in 2005. HSDPA improves the downlink capacity, increases the user data
rate greatly, and reduces the transmission delay on the WCDMA network.
The characteristics of HSDPA are as follows:
Issue 02 (2009-06-30)
2-1
Fast scheduling
Fast scheduling introduced into the NodeB determines the UEs for
data transmission in each TTI (2 ms) and dynamically allocates
resources to these UEs. It improves the usage of system resources
and increases the system capacity.
For details about how Huawei RAN implements fast scheduling, see
section 4.3 "MAC-hs Scheduling."
Fast HARQ
Fast hybrid automatic repeat request (HARQ) is used to rapidly

request the retransmission of erroneously received data.
Specifically, when the UE detects an erroneous data transmission, it
saves the received data and requests the NodeB to retransmit the
original data at the physical layer. Before decoding, the UE
performs soft combining of the saved data and the retransmitted
data. The combining makes full use of the data transmitted each
time and thus increases the decoding success rate. In addition, the
retransmission delay at the physical layer is reduced greatly,
compared with that at the RLC layer.
For details about how Huawei RAN implements fast HARQ, see
section 4.4 "HARQ."
Fast AMC
To compensate for channel variations, the DCH performs power

control. To achieve this goal, HSDPA also performs fast adaptive
modulation and coding (AMC), that is, adjusts the modulation
scheme and coding rate in each TTI. AMC is based on the channel
quality indicator (CQI) reported by the UE, and its purpose is to
select an appropriate transmission rate so as to meet channel
conditions. When the channel conditions are good, 16QAM can be
used to provide higher transmission rates. When the channel
conditions are poor, QPSK can be used to ensure the transmission
quality.
For details about how Huawei RAN implements fast AMC, see
section 4.5 "TFRC Selection."
The MAC-hs, a new MAC sublayer, is introduced into the UE and NodeB to support HSDPA.
2.2 HSDPA Channels

To support the HSDPA technologies, 3GPP defines one transport channel (HS-DSCH) and
three physical channels (HS-PDSCH, HS-SCCH, and HS-DPCCH).
Figure 2-1 shows the physical channels of HSDPA in the shaded area.
Issue 02 (2009-06-30)
2-2
Figure 2-1 Physical channels of HSDPA
2.2.1 HS-DSCH and HS-PDSCH

HS-DSCH is a high speed downlink shared channel. Its TTI is fixed to 2 ms. It may be
mapped onto one or more HS-PDSCHs.
HS-PDSCH is a high speed physical downlink shared channel. Its spreading factor is fixed to
16. According to 3GPP TS 25.433, a maximum of 15 HS-PDSCHs can be used for
transmission at the same time. The number of HS-PDSCHs per cell is configurable.
Generally, the NodeB can use the HS-PDSCH codes only allocated by the RNC. The
NodeB-controlled dynamic code allocation, however, allows the NodeB to temporarily
allocate idle codes to the HS-PDSCH. "Dynamic Code Allocation Based on NodeB" is an
optional feature.
The use of 2 ms TTI reduces the round trip time (RTT) on the Uu interface and, together with
AMC, improves the tracking of channel variations. In addition, the use of 2 ms TTI enables
fast scheduling and resource allocation and thus improves the usage of transmission
resources.
In each TTI, HSDPA assigns the HS-PDSCHs onto which the HS-DSCH maps. More
HS-PDSCHs can provide higher transmission rates.
Unlike the DCH, the HS-DSCH cannot support soft handover. The reason is that this type of
handover requires different cells to use the same radio resource for sending the same data to
the UE, but the scheduling function can be performed only within the cell.
2.2.2 HS-SCCH
HS-SCCH is a high speed shared control channel. It carries the control information related to
the HS-DSCH. The control information includes the UE identity, HARQ-related information,
and information about transport format and resource combination (TFRC). For each
transmission of the HS-DSCH, one HS-SCCH is required to carry the related control
information. One cell can be configured with a maximum of four HS-SCCHs. The number of
HS-SCCHs determines the maximum number of UEs that can be scheduled simultaneously in
each TTI.
Issue 02 (2009-06-30)
2-3
2.2.3 HS-DPCCH
HS-DPCCH is a high speed dedicated physical control channel. In the uplink, each HSDPA
UE must be configured with an HS-DPCCH. This channel is mainly used by the UE to report
the CQI and whether a transport block is correctly received. The information about the
transport block is used for fast retransmission at the physical layer. The CQI is used for AMC
and scheduling to allocate Uu resources.
2.2.4 DPCCH and DPCH/F-DPCH

DPCCH is a dedicated physical control channel in the uplink. DPCH is a dedicated physical
channel in the downlink. F-DPCH is a fractional dedicated physical channel in the downlink.
The HSDPA UE must be configured with dedicated physical control channels in both the
uplink and the downlink. The uplink DPCCH is used for providing reference information
about the transmit power of HSDPA channels. In addition, it is used for closed-loop power
control by working with the DPCH or F-DPCH. In SRB over HSDPA mode, the downlink
channel can be established on the F-DPCH without the dedicated assisted DPCH. In this case,
a maximum of 10 UEs use an SF256 to transmit the TPC, thus saving a large amount of
downlink codes.
2.3 Impact of HSDPA on NEs

HSDPA has an impact on the RNC, NodeB, and UE.
On the control plane of the network side, the RNC processes the signaling about HSDPA cell
configuration, HS-DSCH related channel configuration, and mobility management. On the
user plane of the network side, the RLC layer and MAC-d of the RNC are unchanged. At the
NodeB, the MAC-hs is added to implement HSDPA scheduling, Uu resource allocation, AMC,
and Iub flow control. The MAC-hs implements these management functions in a short time.
Thus, it reduces both unnecessary delays and processing complexity caused by Iub message
exchange.
On the UE side, the MAC-hs is added between the MAC-d and the physical layer for data
reception. To support HSDPA, 3GPP defines 12 UE categories. These UEs support different
peak rates at the physical layer, ranging from 912 kbit/s to 14 Mbit/s. The UE of category 10
supports the highest rate. The UE of category 11 or 12 supports only the QPSK mode. For
details, see 3GPP TS 25.306. Huawei RAN supports all the UE categories.
2.4 HSDPA Functions

HSDPA functions are implemented on the HSDPA control plane and user plane.
2.4.1 HSDPA Control Plane Functions

The control plane is responsible for setting up and maintaining HS-DSCH connections and
managing cell resources.
Figure 2-2 shows the HSDPA control plane functions based on the service connection setup
and maintenance procedure.
Issue 02 (2009-06-30)
2-4
Figure 2-2 HSDPA control plane functions
The HSDPA control plane functions are described as follows:

l
Bearer mapping
The bearer mapping is used by the network side to configure the RAB during the setup
of a service connection in the cell. The network side then configures bearer channels for
the UE based on the requested service type, service rate, UE capability, and cell
capability.
For details, see section 3.1 "Bearer Mapping."
Access control
Access control, a sub-function of load control, checks whether the current resources of
the cell are sufficient for the service connection setup. If the resources are insufficient,
intelligent access control is triggered. If the resources are sufficient, the service
connection can be set up.
For details, see section 3.2 "Access Control."
Mobility management
For the established HS-DSCH connection, mobility management decides whether to
switch it to another cell for providing better services, based on the channel quality of the
UE.
For details, see section 3.3 "Mobility Management."
Channel switching
Channel switching is responsible for switching the transport channel among the
HS-DSCH, DCH, and FACH based on the requirements of mobility management or load
control.
For details, see section 3.4 "Channel Switching."
Load control
When the cell load increases, the load control function adjusts the resources configured
for the established radio connections to avoid cell overload.
For details, see section 3.5 "Load Control."
Issue 02 (2009-06-30)
Resource management
2-5
Resource management coordinates the power resource between the HS-DSCH and the
DCH and the code resource between the HS-SCCH and the HS-PDSCH. The downlink
power and codes are the bottleneck resources of the cell. Resource management can
increase the HSDPA capacity.
Power resource management reserves power for channels of different types and allocates
power for them. For details, see section 3.6 "Power Resource Management."
Code resource management allocates and reserves code resources for channels of
different types. In addition, it collects and reshuffles idle code resources.
For details, see section 3.7 "Code Resource Management."
2.4.2 HSDPA User Plane Functions

After the service is set up, the user plane is responsible for implementing data transmission.
Figure 2-3 shows the HSDPA user plane functions based on the data processing procedure.
Figure 2-3 HSDPA user plane functions
The service data carried on the HS-DSCH is passed to the RLC layer and MAC-d of the RNC
for processing and encapsulation. Then, the MAC-d PDU is formed and passed through the
Iub/Iur interface to the NodeB/RNC. To avoid congestion, the flow control and congestion
control functions control the traffic on the Iub/Iur interface through the HS-DSCH frame
protocol (3GPP TS 25.435).
After the MAC-d PDU is received by the NodeB, it is passed through the MAC-hs to the
physical layer and then sent out through the Uu interface. The MAC-hs provides MAC-hs
scheduling, TFRC selection, and HARQ. MAC-hs scheduling determines the HSDPA users in
the cell for data transmission. TFRC selection determines the transmission rates and Uu
resources to be allocated to the HSDPA UEs. HARQ is used to implement the hybrid
automatic repeat request function.
Issue 02 (2009-06-30)
2-6
Control Plane
This chapter consists of the following sections:

l
Bearer Mapping
l
l
Access Control
Mobility Management
Channel Switching
Load Control
Power Resource Management
Code Resource Management
3.1 Bearer Mapping

The HS-DSCH can carry services of multiple types and service combinations, as listed in
Table 3-1.
Table 3-1 Bearer mapping
CN
Domain
Service Type
Can Be Carried on
HS-DSCH?
Optional Feature?
Signaling (SRB)
Yes
Yes
Feature name: SRB over HSDPA
CS
Voice
Yes
Yes
Feature name: CS Voice over
HSPA/HSPA+
PS
Videophone
No
No
Streaming
No
No
Conversational
Yes
Yes
Feature name: VoIP over
HSPA/HSPA+
Issue 02 (2009-06-30)
3-1
CN
Domain
Service Type
Can Be Carried on
HS-DSCH?
Optional Feature?
Streaming
Yes
Yes
Feature name: Streaming Traffic
Class on HSDPA
Interactive
Yes
No
Background
Yes
No
IMS signaling
Yes
Yes
Feature name: IMS Signaling
over HSPA
MBMS PTP
Yes
Yes
Feature name: MBMS P2P over
HSDPA
During the service setup, the RNC selects appropriate channels based on the UE capability,
cell capability, and service parameters to optimize the use of cell resources and ensure the
QoS. Huawei RAN supports the setting of the types of RABs carried on the HS-DSCH
according to service requirements.
Huawei supports bearer management of HSDPA over Iur. "HSDPA over Iur" is an optional
feature.
3.2 Access Control

Access control determines whether an HS-DSCH connection can be set up under the
precondition that the QoS is ensured. The determination is based on the status of cell
resources and the situation of Iub/Iur congestion. When the resources are insufficient, the
HS-DSCH is switched to the DCH and only the DCH connection is set up. When the
resources are sufficient, the DCH is switched to the HS-DSCH. The implementation of this
function requires the support of channel switching.
Access control allows the HSDPA UE to access an inter-frequency neighboring cell that has
the same coverage area as the source cell. The purpose is to achieve load balance between the
cells and improve HSDPA user experience. This is HSDPA directed retry decision (DRD), an
optional feature. For details, see the Load Control Parameter Description.
3.3 Mobility Management

The DCH supports soft handover, and therefore downlink data can be concurrently sent out
from all the cells in the active set in DCH transmission. In comparison, the HS-DSCH does
not support soft handover, and therefore downlink data can be sent out only from the
HS-DSCH serving cell and inter-cell handover has to be performed through the change of the
serving cell. Thus, HSDPA mobility management focuses on the change of the HS-DSCH
serving cell.
Issue 02 (2009-06-30)
3-2
For the UE with the HS-DSCH service, the best cell in the active set acts as the HS-DSCH
serving cell. When the best cell changes, the UE disconnects the HS-DSCH from the source
cell and attempts to set up a new HS-DSCH connection with the new best cell. For details, see
the Handover Parameter Description. By changing the HS-DSCH switching threshold, you
can modify the conditions for triggering the change of the best cell. Lowering this threshold
can increase both the handover frequency and the sensitivity of HS-DSCH switching to signal
variations in the serving cell. Raising this threshold can reduce the handover frequency but
may increase the probability of the HS-DSCH service being discontinuous or even dropping
on the cell edge. For the HS-DSCH service, Huawei supports inter-cell intra-frequency
handover, inter-cell inter-frequency handover, and inter-RAT handover.
Mobility management may trigger the switching from the HS-DSCH to the DCH. If the UE
with the HS-DSCH service cannot set up the HS-DSCH connection with the target cell, the
channel switching function, together with mobility management, switches the HS-DSCH to
the DCH. When the HS-DSCH connection is available, the channel switching function
switches the DCH back to the HS-DSCH. When the HSDPA user returns from the DCH cell
to the HSDPA cell, the DCH is set up to ensure successful handover. A certain period later
after the handover, the channel switching function switches the DCH to the HS-DSCH. For
details, see section 3.4 "Channel Switching."
"HSDPA over Iur" is an optional feature.
3.4 Channel Switching

After the HS-DSCH is introduced, the UE can stay in a new state, CELL_DCH (with
HS-DSCH). Thus, there are additional transitions between CELL_DCH (with HS-DSCH) and
CELL_FACH and transitions between CELL_DCH (with HS-DSCH) and CELL_DCH even
when both the cell and the UE support the HS-DSCH, as shown in Figure 3-1.
Figure 3-1 UE state transition
Table 3-2 lists new state transition and new channel switching.
Table 3-2 New state transition and new channel switching
New State Transition
New Channel Switching
CELL_DCH (with HS-DSCH) <-> CELL_FACH
HS-DSCH <-> FACH
CELL_DCH (with HS-DSCH) <-> CELL_DCH
HS-DSCH <-> DCH
Issue 02 (2009-06-30)
3-3
Here, the switching between HS-DSCH and FACH can be triggered by traffic volume, which
is similar to the switching between DCH and FACH.
When the cell load is too high, load control may also trigger the switching from the
HS-DSCH to the FACH to relieve congestion. For details, see the Load Control Parameter
Description. When the cell load becomes low, channel switching aids load control in
attempting to switch the transport channel back to the HS-DSCH. For details, see the Rate
Control Parameter Description.
As the HS-DSCH is introduced later, it is inevitable that some cells support the HS-DSCH but
others do not. This is also the case with UEs. When a service is set up, the channel switching
function selects an appropriate bearer channel based on the cell capability and UE capability
to ensure the QoS while efficiently using the cell resources. When the user is moving, the
channel switching function adjusts the channel type based on the UE capability to ensure
service continuity while improving user experience.
Figure 3-2 Relations between channel switching and other functions
Triggers for switching from the HS-DSCH to the DCH are as follows:
l
The HS-DSCH is selected during the service setup but neither the resources of the
serving cell nor the resources of the inter-frequency same-coverage neighboring cell are
sufficient. In such a case, the HS-DSCH is switched to the DCH.
The HS-DSCH serving cell changes. The UE attempts to set up a new HS-DSCH
connection with the new best cell. In such a case, the possible scenarios are as follows:
If the new best cell does not support the HS-DSCH, the UE cannot set up the
HS-DSCH connection. In this case, the HS-DSCH is switched to the DCH.
If the new best cell supports the HS-DSCH but a new HS-DSCH connection cannot
be set up because the resources are insufficient, the DCH connection is set up and the
HS-DSCH is switched to this DCH.
The user moves from a cell supporting the DCH but not supporting the HS-DSCH to a
cell supporting the HS-DSCH. In this case, the DCH connection is also set up because
the DCH supports soft handover, which can increase the inter-cell handover success rate.
In one of the cases described previously, the DCH connection is set up in a cell supporting the
HS-DSCH or in an inter-frequency same-coverage neighboring cell supporting the HS-DSCH.
Then, the DCH is switched to the HS-DSCH by either of the following mechanisms:
Issue 02 (2009-06-30)
3-4
Channel switching based on timer

After the DCH connection is set up, this mechanism periodically attempts to switch the
DCH to the HS-DSCH.
Channel switching based on traffic volume

When the traffic volume of the UE increases and the RNC receives an event 4A report,
this mechanism attempts to switch the DCH to the HS-DSCH. For details on the event
4A report, see the Rate Control Parameter Description.
3.5 Load Control

When the cell is congested, load control selects some users (including HSDPA users) for
congestion relief. The selection is based on the integrated priority, which considers the
allocation retention priority (ARP), traffic class (TC), traffic handling priority (THP), and
bearer type. When the cell load is high, the basic congestion control selects some HSDPA
users for handover to an inter-frequency same-coverage neighboring cell or an inter-RAT
neighboring cell with lower load. When the cell load is too high, the overload congestion
control selects some HSDPA BE services for the switching to a common channel or releases
some HSDPA services. For details, see the Load Control Parameter Description.
3.6 Power Resource Management

Power resource management determines the transmit power of the HS-PDSCH, HS-SCCH,
and HS-DPCCH.
Generally, an HSDPA cell has the same coverage as the corresponding R99 cell. To improve
the resource usage in this case, the downlink power resources of HSDPA can be dynamically
allocated as follows:
1.
The downlink power resources are first reserved for common physical channels and
allocated to the DPCH. The remaining power resources are available for HSPA,
including HSUPA and HSDPA.
2.
The HSPA power resources are first allocated to the HSUPA downlink control channels,
including the E-AGCH, E-RGCH, and E-HICH. The remaining power resources are
available for HSDPA.
3.
The HSDPA power resources are first allocated to the downlink control channel
HS-SCCH. For details, see the Power Control Parameter Description. The remaining
power resources are allocated to the traffic channel HS-PDSCH.
For details on power resource allocation, see section 4.5 "TFRC Selection."
Figure 3-3 shows the dynamic HSDPA power resource allocation.
Issue 02 (2009-06-30)
3-5
Figure 3-3 Dynamic HSDPA power resource allocation
Every TTI, the NodeB detects the power usage of R99 channels to determine the power
available for HSPA. To reserve the power for R99 power control itself, the power margin
PwrMgn needs to be set on the NodeB side. In addition, the power allocated to HSPA must
not exceed the maximum permissible power HspaPower, which can be set on the RNC side.
For details on uplink HS-DPCCH power control, see the Power Control Parameter
Description.
"HSDPA over Iur" is an optional feature.
3.7 Code Resource Management

Code resource management allocates code resources to the HS-SCCH and HS-PDSCH.
The NodeB supports HS-DSCH transmissions to multiple users in parallel in a TTI. If more
than one HS-PDSCH code can be allocated by the NodeB, then code multiplexing can be used
to allocate the codes to multiple users so as to improve resource usage and system throughput.
"Time and HS-PDSCH Code Multiplexing" is an optional feature.
3.7.1 HS-SCCH Code Resource Management

Each HS-SCCH uses an SF128 code. The number of HS-SCCHs determines the maximum
number of HSDPA users that can be scheduled simultaneously in a TTI. Generally, the
number of HS-SCCHs depends on the traffic characteristics of the cell. The default number is
4, which is specified by the parameter HsScchCodeNum on the RNC side. If the default
setting is used, the HS-PDSCH can use only 14 SF16 codes. To enable the HS-PDSCH to use
15 SF16 codes, you are advised to configure 2 HS-SCCHs.
Issue 02 (2009-06-30)
3-6
3.7.2 HS-PDSCH Code Resource Management

The DPCH and the HS-PDSCH coexist in a cell. Therefore, sharing the cell code resources
between them to improve the resource usage is of critical importance in HSDPA code resource
management.
Huawei supports both RNC-level and NodeB-level code resource management.
RNC-controlled static or dynamic code allocation is enabled through the parameter
AllocCodeMode. NodeB-controlled dynamic code allocation is enabled through the
parameter DynCodeSw. For details, see the following sections.
The dynamic code allocation controlled by the NodeB is more flexible than that controlled by
the RNC. It shortens the response time and saves the Iub signaling used for code reallocation.
Huawei recommends the following code allocation modes, where the first mode is preferred:
l
Configure the RNC to use static code allocation and the NodeB to use dynamic code
allocation.
If the NodeB does not support dynamic code allocation, configure the RNC to use
dynamic code allocation.
If not all the NodeBs controlled by an RNC support dynamic code allocation, the
RNC-controlled dynamic code allocation is recommended. In this case, the NodeB-controlled
dynamic code allocation can also be enabled for those supporting NodeBs.
Issue 02 (2009-06-30)
3-7
User Plane
This chapter consists of the following sections:

l
Flow Control and Congestion Control
l
l
RLC and MAC-d

MAC-hs Scheduling
HARQ
TFRC Selection
4.1 Flow Control and Congestion Control

HSDPA flow control and congestion control are used to control the HSDPA data flow on the
Iub and Iur interfaces. HSDPA data packets are sent through the Iub interface to the NodeB
and then through the Uu interface to the UE. Thus, congestion may occur on the Uu, Iub, or
Iur interface. Flow control is used to relieve Uu congestion, and congestion control is used to
relieve Iub/Iur congestion. The two types of control are implemented by the NodeB. HSDPA
flow control and congestion control are part of the HSDPA Iub frame protocol (3GPP TS
25.435). They are implemented for each MAC-hs queue through the Capacity Request
message sent by the RNC and the Capacity Allocation message sent by the NodeB.
Figure 4-1 shows the basic principles of flow control and congestion control.
Issue 02 (2009-06-30)
4-1
Figure 4-1 Basic principles of Iub flow control and congestion control
4.1.1 Flow Control

For each MAC-hs queue, flow control calculates the pre-allocated Iub bandwidth based on the
Uu transmission rate and the amount of data buffered in the NodeB. The Uu transmission rate
of the MAC-hs queue is determined by the scheduling algorithm. For each MAC-hs queue, if
the Iub transmission rate is higher than the Uu transmission rate, the data packets are buffered.
Too much data buffered in the NodeB leads to transmission delay and even packet loss.
Therefore, each MAC-hs queue should not have too much data buffered in the NodeB. On the
other hand, it should keep a certain amount of data to avoid wasting the Uu resources due to
no data to transmit.
The flow control procedure is as follows:
1.
The NodeB measures the buffered data amount of each MAC-hs queue and the average
Uu transmission rate.
2.
The NodeB estimates the buffering time based on the measurements.
3.
The NodeB adjusts the Iub bandwidth pre-allocated to the MAC-hs queue.
The pre-allocated Iub bandwidth is adjusted as follows:

l
If the buffering time is too short, you can infer that the RNC slows down the data
transmission, that is, the Iub transmission rate is lower than the Uu transmission rate. In
such a case, the pre-allocated Iub bandwidth is adjusted to a value greater than the
average Uu transmission rate.
If the buffering time is appropriate, the pre-allocated Iub bandwidth is adjusted to the
average Uu transmission rate.
If the buffering time is too long, the pre-allocated Iub bandwidth is adjusted to a value
smaller than the average Uu transmission rate.
Issue 02 (2009-06-30)
4-2
4.1.2 Congestion Control

The Iub bandwidth may be lower than the Uu bandwidth. If the RNC uses the Iub bandwidth
pre-allocated to each MAC-hs queue, the Iub bandwidth for HSDPA is insufficient. This may
lead to congestion and even packet loss.
The amount of data to be transmitted is sent by the RNC to each MAC-hs queue through the
Capacity Request message. Based on this amount and the total Iub bandwidth available for
HSDPA, the congestion control function adjusts the bandwidth pre-allocated to each MAC-hs
queue. Thus, congestion control ensures that the total bandwidth actually allocated to all the
MAC-hs queues is not higher than the total available Iub bandwidth.
The total Iub bandwidth available for HSDPA depends on the variations in HSDPA packet
delay and the situation of packet loss. HSDPA shares the bandwidth with the DCH and control
signaling, and the DCH and control signaling has higher priorities than HSDPA. Thus, when
the HSDPA packet delay or packet loss increases, you can infer that the number of DCHs or
the amount of control signaling increases. In such a case, the bandwidth available for HSDPA
decreases and the bandwidth actually allocated for HSDPA decreases.
For the Iur interface, flow control and congestion control are also applied. The control principles and
processing procedures are the same as those for the Iub interface.
4.2 RLC and MAC-d

4.2.1 RLC
One of the main purposes of HSDPA is to reduce latency by handling retransmissions at
NodeB level. Retransmissions, however, may still be triggered at the RLC layer of the RNC
under the following circumstances:
l
The NodeB misinterprets an NACK sent by the UE.
The number of HARQ retransmissions exceeds the maximum permissible number.
The data buffered in the NodeB is lost when the HS-DSCH serving cell changes.
Therefore, HARQ retransmission cannot totally replace RLC retransmission, which is

described in 3GPP TS 25.322. For services with high requirements for data transmission
reliability, Huawei recommends that the RLC acknowledged mode (AM) also be used to
ensure correct transmission on the Uu interface even when the services such as the BE service
are carried on HSDPA channels.
Before the introduction of HSDPA, the size of an RLC PDU is usually 336 bits, where 320
bits are for the payload and 16 bits for the RLC header. Without additional overhead, the
MAC PDU is of the same size as the RLC PDU. According to the 3GPP specifications, a
maximum of 2,047 RLC PDUs can be transmitted within an RLC window, and the RTT at the
RLC layer is about 100 ms (50 TTIs). In this condition, the maximum peak rate can only be
336 bits x (2047/50)/2 ms = 6.88 Mbit/s. To reach higher rates, an RLC PDU of 656 bits is
introduced, where 640 bits are for the payload and 16 bits for the RLC header. The RLC PDU
size can be set for each typical service. For high-speed services, the size is set to 656 bits by
default.
Issue 02 (2009-06-30)
4-3
4.2.2 MAC-d
The MAC-d functionality is unchanged after the introduction of HSDPA. The HS-DSCH
bearers are mapped onto MAC-d flows on the Iub/Iur interface. Each MAC-d flow has its
own priority queue.
The theoretical peak rate of HSDPA on the Uu interface is 14.4 Mbit/s. It is calculated on the
assumption that the chip rate of WCDMA is 3.84 Mcps, the spreading factor for HSDPA is
SF16, the maximum number of available codes is 15, and the gain of 16QAM is 4. Thus, the
rate is 3.84 Mcps/16 x 15 x 4 = 14.4 Mbit/s.
Limited by many factors, the theoretical peak rate of 14.4 Mbit/s is unreachable in actual
situations. The UE capability is one factor. For example, 3GPP specifies that the UE of
category 10 can use a maximum of 15 codes and receive a transport block with a maximum of
27,952 bits. For details, see 3GPP TS 25.306. Thus, the theoretical peak rate is 27952 bits/2
ms = 13.976 Mbit/s.
In addition, the RLC PDU size is fixed to 656 bits, and a transport block of 27,952 bits can
contain a maximum of 42 PDUs. Thus, the maximum RLC payload rate is (656 bits 16 bits)
x 42/2 ms = 13.44 Mbit/s.
In practice, the radio channel quality, retransmission probability, and available power also
need to be considered. Therefore, the UE of category 10 cannot reach 13.44 Mbit/s at the RLC
layer in most tests.
4.3 MAC-hs Scheduling

With the limited Uu resources for HSDPA in a cell, the user expects to maximize the service
rate while the telecom operator expects to maximize the system capacity. MAC-hs scheduling
is used to coordinate the Uu resources, user experience, and system capacity. It is
implemented at the NodeB MAC-hs.
The scheduling algorithm consists of two steps. At first, the algorithm determines which
initial transmission queues or retransmission processes can be put into the candidate set for
scheduling. Then, the algorithm calculates their priorities based on factors such as the CQI,
user fairness, and differentiated services. If the algorithm is weighted more towards the
channel quality of the UE, the HSDPA cell can have a higher capacity but user fairness and
differentiated services may be affected. If the algorithm is weighted more towards user
fairness and differentiated services, the system capacity may be affected.
Huawei provides four scheduling algorithms: maximum C/I (MAXCI), round-robin (RR),
proportional fair (PF), and Enhanced Proportional Fair (EPF). The EPF algorithm is optional.
4.3.1 Determining the Candidate Set

The candidate for scheduling contains new data packets (hereinafter referred to as initial
transmission queues) or data packets to be retransmitted (hereinafter referred to as
retransmission processes), with the following exceptions:
l
If the UE starts the compressed mode, its data cannot be put into the candidate set during
the GAP.
If the UE category requires the UE to wait for several TTIs before it can be scheduled
again, its data cannot be put into the candidate set in this period. The UE of category 1 or
2 needs to wait for 3 TTIs, and the UE of category 3, 4, and 11 must wait for 2 TTIs.
Issue 02 (2009-06-30)
4-4
If the number of retransmissions of a data packet reaches or exceeds the maximum

number, the data of this UE cannot be put into the candidate set. The data should be
discarded.
Huawei supports that the maximum number of retransmissions is set on a service basis:
MaxNonConverHarqRt: the maximum number of non-conversational service

retransmissions in the CELL_DCH state
Other user data can be put into the candidate set.
4.3.2 Calculating Priorities

Four algorithms are available for calculating the priorities of data packets in the candidate set.
The scheduling policies vary according to the algorithms for calculating the priorities of data
packets. The algorithm to be used is specified by the parameter SM on the NodeB LMT.
4.4 HARQ
The main purpose of introducing HARQ is to reduce the retransmission delay and improve
the retransmission efficiency. HARQ enables fast retransmission at the physical layer. Before
decoding, the UE combines the retransmitted data and the previously received data, thus
making full use of the data transmitted each time. In addition, HARQ can fine-tune the
effective rate to compensate for the errors made by TFRC section.
4.4.1 HARQ Retransmission Principles

The HARQ process of HSDPA involves only the NodeB and the UE, without involving the
RNC. After receiving a MAC-hs PDU sent by the NodeB, the UE performs a CRC check and
reports an ACK or NACK on the HS-DPCCH to the NodeB:
l
If the UE reports an ACK, the NodeB transmits the next new data.
If the UE reports an NACK, the NodeB retransmits the original data. After receiving the
data, the UE performs soft combining of this data and the data received before, decodes
the combined data, and then reports an ACK or NACK to the NodeB.
RLC retransmission on the DCH involves the RNC, and therefore the RTT is relatively long.
In comparison, HARQ involves only the physical layer and MAC-hs of the NodeB and those
of the UE, and therefore the RTT is reduced to only 6 TTIs.
After a transmission, the HARQ process must wait at least 10 ms before it can transmit the
next new data or retransmit the original data. Therefore, to improve transmission efficiency,
other HARQ processes can transmit data during the waiting time. A maximum of six HARQ
processes can be configured in each of the NodeB HARQ entity and the UE HARQ entity.
Note that not all UE categories support six HARQ processes. For example, the UEs of some
categories can receive data every one or two TTIs. Thus, only two or three HARQ processes
can be configured. The RAN can automatically choose the most appropriate configuration
based on UE capability.
Issue 02 (2009-06-30)
4-5
Figure 4-2 HARQ retransmission principle
4.4.2 Soft Combining During HARQ

Before decoding a MAC-hs PDU, the UE performs soft combining of all the data received
before to improve the utilization of Uu resources and thus increase the cell capacity. The size
of the UE buffer determines the number of coded bits or the size of transport blocks.
For HARQ retransmission between the NodeB and the UE, two combining strategies are
available. They are Chase Combining (CC) and Incremental Redundancy (IR). In the case of
CC, all retransmitted data is the same as previously transmitted data. In the case of IR, the
retransmitted data may be different from the previously transmitted data. In comparison, IR
has a higher gain than CC but requires more buffer space. CC can be regarded as a special
case of IR. The IR strategy is hard-coded in Huawei RAN.
4.4.3 Preamble and Postamble

If the HS-SCCH is received, the UE checks whether the HS-PDSCH is also correctly received
and then reports an ACK or NACK in the first slot of the HS-DPCCH subframe. If the
HS-SCCH is erroneously received, the UE does not report any information in the first slot of
the HS-DPCCH subframe. This type of transmission is called DTX. In the case of high
interference, the NodeB may demodulate DTX as ACK by mistake when demodulating the
HS-DPCCH. Thus, the lost data blocks cannot be retransmitted through HARQ retransmission,
and the reception can be ensured only through RLC retransmission. To meet the requirement
of the 3GPP specifications for a low DTX misjudgment probability, more power has to be
allocated for HS-DPCCH ACK/NACK.
To solve this problem, 3GPP TS 25.214 introduces preamble and postamble. When the NodeB
demodulates an HS-DPCCH ACK/NACK, it considers the subframe prior to and the subframe
next to the HS-DPCCH subframe in addition to the HS-DPCCH subframe itself. Thus, for a
certain DTX misjudgment probability, the introduction of preamble and postamble reduces
the power required by ACK/NACK, lower the downlink load level, and increase the uplink
capacity. "HS-DPCCH Preamble Support" is an optional feature.
Issue 02 (2009-06-30)
4-6
Figure 4-3 HS-DPCCH preamble and postamble
4.5 TFRC Selection

The TFRC selection algorithm handles the MAC-hs queues in descending order of their
priorities determined by the scheduler. The main tasks of the algorithm for each queue in each
TTI are as follows:
l
Determining the amount of data that can be transmitted by the queue
Determining the modulation scheme of the queue
Allocating appropriate power and channelization codes to the queue
During the handling, the TFRC selection algorithm considers the following factors:
l
Channel conditions of the UE
Available resources
Amount of data buffered in the MAC-hs queue
Based on these factors, the algorithm allocates appropriate resources and selects appropriate
transport block sizes to ensure the transmission quality and avoid wasting the resources.
When the channel conditions are bad, the algorithm selects small transport block sizes to
ensure that the data is received correctly and transmitted continuously. When the channel
conditions are good, the algorithm selects large transport block sizes for higher transmission
rates and QoS.
4.5.1 Basic Procedure of TFRC Selection

The basic procedure of the TFRC selection algorithm is as follows:
Step 1 Based on the CQI reported by the UE, available power, and available channelization codes,
the algorithm searches a CQI mapping table for the TBSmax, that is, the maximum MAC-hs
transport block size (TBS).
Issue 02 (2009-06-30)
4-7
For details, see section 4.5.2 "Determining the TBSmax."

Step 2 Based on the TBSmax and the amount of data buffered in the queue, the algorithm determines
the most appropriate MAC-hs TBS (TBSused). Here, TBSused <= TBSmax. Based on the TBSused,
the algorithm determines the most appropriate power, codes, and modulation scheme.
For details, see section 4.5.3 "Determining the TBSused, Modulation Scheme, Power, and
Codes."
Step 3 Based on the TBSused, the algorithm calculates the number of MAC-d PDUs that can be
transmitted in the MAC-hs PDU.
For details, see section 4.5.4 "Determining the Number of MAC-d PDUs."
Step 4 The algorithm updates the records of the remaining power, codes, and HS-SCCH quantity. If
all of these resources are available and another MAC-hs queue is waiting for resource
allocation, then the algorithm repeats the previous steps. Otherwise, the algorithm ends the
handling.
----End
4.5.2 Determining the TBSmax

The UE assumes that the transmit power of the HS-PDSCH on the network side is as follows:
PHS PDSCH = PCPICH + +

where
l
l
PCPICH is the transmit power of the CPICH.
is the measurement power offset (MPO). It is specified by the parameter

HsPdschMPOConstEnum on the RNC side and sent to the NodeB and UE.
is the reference power adjustment. It is set to 0 in most cases. For details, see 3GPP
TS 25.214.
On this assumption, the UE reports the CQI through the HS-DPCCH to the NodeB. The CQI
indicates the channel conditions of the UE. A higher CQI indicates that the channel quality is
better and therefore the NodeB can send a larger MAC-hs transport block to the UE.
The NodeB creates a CQI mapping table for each UE category. For each CQI, this table
provides a corresponding MAC-hs TBS and a modulation scheme based on the assumed
power ( PHS PDSCH = PCPICH + + ) and the number of channelization codes. Such
combinations ensure that the block error rate (BLER) of MAC-hs transport blocks on the Uu
interface does not exceed 10%. The table is obtained on the basis of many simulations and test
experiences. It plays a very important role in HSDPA resource allocation.
If the available power of the HS-PDSCH is higher than the assumed power, a larger MAC-hs
TBS is allowed, which is equal to the TBS corresponding to the adjusted CQI. The adjusted
CQI is calculated as: reported CQI + (available power - assumed power). In this way, the
algorithm provides higher transmission rates.
If the available power is lower than the assumed power, the supported MAC-hs TBS needs to
be reduced to the one corresponding to the adjusted CQI. The adjusted CQI is calculated as:
reported CQI (assumed power - available power). In this way, the algorithm ensures
transmission correctness.
Issue 02 (2009-06-30)
4-8
Thus, the algorithm can determine the TBSmax of the UE in the current cell after obtaining the
CQI reported by the UE, available power, and available codes.
Here is an example. Assume that the CQI reported by the UE is 5, the available power is equal
to the assumed power, and the number of available codes is 4. Then, the TBSmax is 3,762 bits
and the modulation scheme is QPSK. The following figure shows this example.
4.5.3 Determining the TBSused, Modulation Scheme, Power, and

Codes
If the data buffered in the MAC-hs queue is much enough to fill the space for carrying data in
a transport block with the TBSmax, then the TBSmax is taken as the TBS to be used (TBSused).
Accordingly, the modulation scheme corresponds to this TBS is taken as the one to be used.
The algorithm then determines the power and channelization codes to be used, according to
the method mentioned in section 4.5.2 "Determining the TBSmax."
The TBSmax, however, may be much larger than the data buffered in the MAC-hs queue. If
this TBS is used, too many padding bits reduce the spectrum efficiency. To solve this problem,
the algorithm searches the CQI mapping table backward for the CQI or the number of codes
so as to obtain the most appropriate TBS and the corresponding modulation scheme. This
TBS should be the smallest one in the TBS set that can carry the buffered data. The power and
code resources determined through backward searching are taken as the ones for allocation.
Huawei supports three backward-searching methods, which are specified by the parameter
RscAllocM on the NodeB side:
l
If the parameter is set to Code_Pri, the algorithm prefers the use of codes. Under the
precondition that the transport block with the TBS is large enough to carry the buffered
data, the algorithm first reduces the power. If the corresponding CQI decreases to the
smallest one but the precondition is still met, the algorithm attempts to reduce the
number of codes. This setting is applicable the outdoor macro base station with limited
power.
If the parameter is set to Power_Pri, the algorithm prefers the use of power. Under the
precondition that the transport block with the TBS is large enough to carry the buffered
data, the algorithm first reduces the number of codes. If the number of codes decreases to
1 but the precondition is still met, the algorithm attempts to reduce the power. This
setting is applicable to indoor application with limited codes.
If the parameter is set to PowerCode_Bal, the algorithm balances the use of power and
the use of codes. Under the precondition that the transport block with the TBS is large
enough to carry the buffered data, the algorithm reduces the power and codes in a
Issue 02 (2009-06-30)
4-9
balanced mode. This setting protects the codes or power from being used up, thus
improving the resource usage and increasing the cell capacity.
The following figure shows the backward-searching methods used when the parameter is set
to Code_Pri or Power_Pri.
The following figure shows the backward-searching methods used when the parameter is set
to PowerCode_Bal.
4.5.4 Determining the Number of MAC-d PDUs

TBSused is the used MAC-hs PDU size. It contains a MAC-hs header and the MAC-hs payload.
The size of MAC-hs payload is equal to the total size of MAC-d PDUs. Assume that S
represents (TBSused (MAC-hs PDU header size))/(MAC-d PDU size). Then, round down S to
the nearest integer to obtain the number of MAC-d PDUs to be transmitted.
Issue 02 (2009-06-30)
4-10
Parameters
The following describes the parameters related to HSDPA.

For the meaning of each parameter, see Table 5-1. For the default value, value ranges, and
MML commands of each parameter, seeTable 5-2.
Table 5-1 HSDPA parameter description(1)
Parameter ID
Description
AllocCodeMode
If Manual is chosen, allocating [Code Number for HS-PDSCH] the equal of

configured HS-PDSCH code number. If Automatic is chosen, allocating
HS-PDSCH code number between configured HS-PDSCH Maximum code
number and HS-PDSCH Minimum code number. At the earl
ARP10Priority
User_priority corresponding to Allocation/Retention priority 10.
ARP11Priority
ARP12Priority
ARP13Priority
ARP14Priority
ARP1Priority
ARP2Priority
ARP3Priority
ARP4Priority
ARP5Priority
ARP6Priority
ARP7Priority
ARP8Priority
ARP9Priority
Issue 02 (2009-06-30)
5-1
Parameter ID
Description
CellLdrSfResThd
Cell SF reserved threshold. The code load reshuffling could be triggered

only when the minimum available SF of a cell is higher than this threshold.
The lower the code resource LDR trigger threshold is, the easier the
downlink code resource enters the ini
CodeAdjForHsdpaSwitch
Code reshuffle switch based on H. If the switch is enabled, code occupied

by the R99 service is adjusted toward codes with small numbers. When
[Allocate Code Mode] is set to Automatic, code can be used by HSDPA
increases and HSDPA throughput is improved.
CodeAdjForHsdpaUserNumThd
H-based code tree reshuffle user number threshold. When the switch is
enabled, if the number of users on the tree to be reshuffled is no greater
than this parameter, the reshuffle is allowed. Otherwise, the reshuffle is
given up. This parameter limits the
ConverDlMBR
This parameter specifies the DL maximum bit rate of conversation for PS

domain user.
ConverUlMBR
This parameter specifies the UL maximum bit rate of conversation for PS

domain user.
DlGBR
This parameter specifies the DL GBR of the BE service.
DynCodeSw
Dynamic Code Resource Distribuiton Switch of HSDPA
FACTOR
This parameter specifies the factor associated with the scheduling priority
indicator. This factor is used to calculate the step of rate upsizing.
HappyBR
This parameter specifies the Happy bit rate of the best-effort (BE) service
with different user priorities. The Happy bit rate is the private information
element on the Iub interface and it is used for the flow control by the
NodeB. When resource is limit
HspaPower
This parameter specifies the difference between the total HSPA power and
the maximum transmission power of a cell. The maximum value of HSPA
dynamical power can be adjusted to the total amount of HSPA power. If the
parameter value is set too low, the tota
HsPdschCodeNum
The parameter specifies the number of HS-DPSCH codes. This parameter is

valid only when "Allocate Code Mode" is set to "Manual". If the parameter
value is set too low, the HSDPA code resources are restricted and the
HSDPA performance is affect. If the par
HsPdschMaxCodeNum
The parameter determines the maximum number of HS-PDSCH codes

(SF=16). This parameter is valid only when "Allocate Code Mode" is set to
"Automatic". The number of codes used by the HS-PDSCH is dynamically
set between "Code Max Number for HS-PDSCH" and "Co
HsPdschMinCodeNum
The parameter specifies the minimum number of the HS-PDSCH codes

(SF=16). This parameter is valid only when "Allocate Code Mode" is set to
Automatic. The number of codes used by the HS-PDSCH is dynamically
set between "Code Max Number for HS-PDSCH" and "C
Issue 02 (2009-06-30)
5-2
Parameter ID
Description
HsPdschMPOConstEnum
Measure Power Offset (MPO) Constant is used to compute Measure Power

Offset, as shown in Measure Power Offset = Max(-6,
Min(13,CellMaxPower - PcpichPower - Measure Power OffsetConstant)).
If the parameter value is unreasonable, the CQI in some scenarios w
HsScchCodeNum
This parameter decides the maximum number of subscribers that the NodeB
can schedule in a TTI period. In the scenarios like outdoor macro cells with
power restricted, it is less likely to schedule multiple subscribers
simultaneously, so two HS-SCCHs are c
MaxNonConverHarqRt
Max HARQ Retransmission Times of Non-Conversational serive in Cell

DCH state
PwrMgn
Power Margin Ratio, to prevent the total power from exceeding the 100%
power margin in 2 ms.
RscAllocM
Resource Allocate Method of HSDPA
RscLmSw
Resource Limiting Switch of HSDPA
SingalDlMBR
This parameter specifies the DL maximum bit rate of signal for PS domain
user.
SingalUlMBR
This parameter specifies the UL maximum bit rate of signal for PS domain
user.
SM
Scheduling Method of HSDPA
SPI
This parameter indicates the scheduling priority. The value 15 indicates the
highest priority and the value 0 indicates the lowest.
StreamDlMBR
This parameter specifies the DL maximum bit rate of streaming for PS

domain user.
StreamUlMBR
This parameter specifies the UL maximum bit rate of streaming for PS

domain user.
THP
This parameter specifies the Traffic Handling Priority (THP) of each traffic
class carried on the logical channel. The value 1 means the highest priority,
the value 14 means the lowest priority, and the value 15 means no priority.
THPClass
This parameter specifies the Traffic Handling Priority (THP) class that the
THP priority is mapped to. This parameter is valid for only interactive
services.
TrafficClass
This parameter specifies the traffic class that the service belongs to. Based
on Quality of Service (QoS), there are two traffic classes: interactive,
background.
UlGBR
This parameter specifies the UL GBR of the BE service.
USERPRIORITY
This parameter specifies the user priority. The user classes in descending
order of priority are Gold, Silver, and then Copper.
8KRSCLMT
Upper limit ratio of the power for the user with 8 kbps GBR to the total
power of the cell
Issue 02 (2009-06-30)
5-3
Parameter ID
Description
16KRSCLMT
power of the cell
32KRSCLMT
power of the cell
64KRSCLMT
power of the cell
128KRSCLMT
power of the cell
256KRSCLMT
power of the cell
384KRSCLMT
power of the cell
Table 5-2 HSDPA parameter description (2)

Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
MML Command
NE
AllocCode
Mode
Automatic
Manual(Manual),
Automatic(Automatic)
Manual, Automatic
None
ADD
CELLHSDPA(Opti
onal)
RNC
ARP10Prior
ity
Gold, Silver, Copper
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP11Prior
ity
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP12Prior
ity
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP13Prior
ity
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP14Prior
ity
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP1Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP2Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
Issue 02 (2009-06-30)
5-4
Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
MML Command
NE
ARP3Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP4Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP5Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP6Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP7Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP8Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
ARP9Priori
ty
Gold,Silver,Copper
None
SET
USERPRIORITY(
Optional)
RNC
CellLdrSfR
esThd
SF8
SF4(SF4), SF8(SF8),
SF16(SF16),
SF32(SF32),
SF64(SF64),
SF128(SF128),
SF256(SF256)
SF4, SF8, SF16,

SF32, SF64,
SF128, SF256
None
ADD
CELLLDR(Option
al)
RNC
CodeAdjFo
rHsdpaSwit
ch
ON
OFF(OFF), ON(ON)
To enlarge the
throughout of
HSDPA when the
NodeB automatic
code algorithem is
enabled, it's
recommended that
the sharing codes
adjacent to HSDPA
code to be free as
possible as it can,
when the [Code
Adjust switch for
Hsdpa] is set to
ON,the RNC will
sel
None
ADD
CELLHSDPA(Opti
onal)
RNC
CodeAdjFo
rHsdpaUser
1~16
1~16
None
ADD
CELLHSDPA(Opti
RNC
Issue 02 (2009-06-30)
5-5
Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
NumThd
MML Command
NE
onal)
ConverDlM
BR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
kbit/s
SET
USERMBR(Option
al)
RNC
ConverUlM
BR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
kbit/s
SET
USERMBR(Option
al)
RNC
DlGBR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
0, 8, 16, 32, 64,

128, 144, 256, 384
kbit/s
SET
USERGBR(Option
al)
RNC
DynCodeS
w
None
OPEN,
OPEN, CLOSE
None
SET
MACHSPARA(Op
tional)
Node
B
FACTOR
0~100
0~100
per
cent
SET
SPIFACTOR(Man
datory)
RNC
HappyBR
0~5000
0~5000
kbit/s
SET
USERHAPPYBR(
Optional)
RNC
HspaPower
-500~0
-50~0, step:0.1
dB
ADD
CELLHSDPA(Opti
onal)
RNC
HsPdschCo
deNum
1~15
1~15
None
ADD
CELLHSDPA(Opti
onal)
RNC
HsPdschMa
xCodeNum
1~15
1~15
None
ADD
CELLHSDPA(Opti
onal)
RNC
HsPdschMi
nCodeNum
1~15
1~15
None
ADD
CELLHSDPA(Opti
onal)
RNC
HsPdschMP
OConstEnu
m
2.5dB
Minus3.0DB(-3.0dB),
Minus2.5DB(-2.5dB),
Minus2.0DB(-2.0dB),
Minus1.5DB(-1.5dB),
Minus1.0DB(-1.0dB),
Minus0.5DB(-0.5dB),
0.0DB(0.0dB),
0.5DB(0.5dB),
1.0DB(1.0dB),
1.5DB(1.5dB),
2.0DB(2.0dB),
2.5DB(2.5dB),
3.0DB(3.0dB),
-3~19, step:0.5
dB
ADD
CELLHSDPA(Opti
onal)
RNC
Issue 02 (2009-06-30)
CLOSE
5-6
Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
MML Command
NE
3.5DB(3.5dB),
4.0DB(4.0dB),
4.5DB(4.5
HsScchCod
eNum
1~15
1~15
None
ADD
CELLHSDPA(Opti
onal)
RNC
MaxNonCo
nverHarqRt
None
0~10
0~10
Time
s
SET
MACHSPARA(Op
tional)
Node
B
PwrMgn
None
0~100
0~100
SET
MACHSPARA(Op
tional)
Node
B
RscAllocM
None
CODE_PRI(Code
Priority:refers to power
limited cell),
POWER_PRI(Power
Priority:refers to code
limited cell),
POWERCODE_BAL(
Balance between Code
and Power)
CODE_PRI,
POWER_PRI,
POWERCODE_B
AL
None
SET
MACHSPARA(Op
tional)
Node
B
RscLmSw
None
OPEN (OPEN),
CLOSE (CLOSE)
OPEN, CLOSE
None
SET
MACHSPARA(Op
tional)
Node
B
SingalDlM
BR
D3.4, D13.6, D27.2
D3.4, D13.6, D27.2
kbit/s
SET
USERMBR(Option
al)
RNC
SingalUlM
BR
D3.4, D13.6, D27.2
D3.4, D13.6, D27.2
kbit/s
SET
USERMBR(Option
al)
RNC
SM
None
EPF (Enhanced
Proportional Fairness),
PF (Proportional
Fairness), RR
(Round Robin),
MAXCI (Max C/I)
EPF, PF, RR,

MAXCI
None
SET
MACHSPARA(Op
tional)
Node
B
SPI
0~15
0~15
None
SET
SPIFACTOR(Man
datory)
SET
SCHEDULEPRIO
MAP(Mandatory)
RNC
StreamDlM
BR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
kbit/s
SET
USERMBR(Option
al)
RNC
Issue 02 (2009-06-30)
5-7
Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
MML Command
NE
StreamUlM
BR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
kbit/s
SET
USERMBR(Option
al)
RNC
THP
1~15
1~15
None
SET
SCHEDULEPRIO
MAP(Mandatory)
RNC
THPClass
High, Medium, Low
High, Medium,
Low
None
SET
USERGBR(Manda
tory)
RNC
TrafficClass
INTERACTIVE,
BACKGROUND
INTERACTIVE,
BACKGROUND
None
SET
SCHEDULEPRIO
MAP(Mandatory)
SET
USERGBR(Manda
tory)
SET
FACHBANDWID
TH(Mandatory)
SET
USERHAPPYBR(
Mandatory)
SET
DTXDRXPARA(
Mandatory)
SET
HSSCCHLESSOP
PARA(Mandatory)
RNC
UlGBR
D0, D8, D16, D32,

D64, D128, D144,
D256, D384
0, 8, 16, 32, 64,

128, 144, 256, 384
kbit/s
SET
USERGBR(Option
al)
RNC
USERPRIO
RITY
GOLD, SILVER,
COPPER
GOLD, SILVER,
COPPER
None
SET
SCHEDULEPRIO
MAP(Mandatory)
SET
USERGBR(Manda
tory)
SET
FACHBANDWID
TH(Mandatory)
SET
USERHAPPYBR(
Mandatory)
RNC
8KRSCLM
T
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
16KRSCL
None
1~100
1~100
SET
RSCLMTPARA(O
Node
Issue 02 (2009-06-30)
5-8
Parameter
ID
Default
Value
GUI Value Range
Actual Value
Range
Unit
MT
MML Command
NE
ptional)
32KRSCL
MT
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
64KRSCL
MT
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
128KRSCL
MT
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
256KRSCL
MT
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
384KRSCL
MT
None
1~100
1~100
SET
RSCLMTPARA(O
ptional)
Node
B
The Default Value column is valid for only the optional parameters.
The "-" symbol indicates no default value.
Issue 02 (2009-06-30)
5-9
Counters
The following describes the counters related to HSDPA.

For details, see the RNC Performance Counter Reference and NodeB Performance Counter
Reference.
Issue 02 (2009-06-30)
6-1
Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
Issue 02 (2009-06-30)
7-1
Reference Documents
The following lists the reference documents related to the feature:

1.
3GPP TS 25.214, "Physical layer procedures (FDD)"
2.
3GPP TS 25.306, " UE Radio Access capabilities "
3.
3GPP TS 25.308, "UTRA High Speed Downlink Packet Access

(HSDPA); Overall description"
4.
3GPP TS 25.433, "UTRAN Iub interface NBAP signaling"
5.
3GPP TS 25.435, "UTRAN Iub interface user plane protocols for CCH
data flows"
6.
Load Control Parameter Description
7.
Rate Control Parameter Description
8.
Power Control Parameter Description
9.
Handover Parameter Description
10. Basic Feature Description of Huawei UMTS RAN11.0

11. Optional Feature Description of Huawei UMTS RAN11.0
12. RNC Performance Counter Reference
13. NodeB Performance Counter Reference.
Issue 02 (2009-06-30)
8-1

HSDPA Parameter Description PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HSDPA Parameter Description PDF

Transféré par

Droits d'auteur :

Formats disponibles

RAN

Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

2 Overview of HSDPA ............................................................................................................ 2-1

3 Control Plane......................................................................................................................... 3-1

4 User Plane .............................................................................................................................. 4-1

Huawei Proprietary and Confidential

4.3 MAC-hs Scheduling ............................................................................................................................... 4-4

Huawei Proprietary and Confidential

1 Introduction to This Document

Introduction to This Document

1.2 Intended Audience

System operators who need a general understanding of HSDPA

Personnel working on Huawei products or systems

1.3 Change History

Feature change: refers to the change in the HSDPA feature.

Huawei Proprietary and Confidential

1 Introduction to This Document

The description of MAC-hs Scheduling is

The deleted parameters

The added parameters

The structure of the document is adjusted.

The structure of the docuement is adjusted.

Huawei Proprietary and Confidential

1 Introduction to This Document

Compared with issue 03 (2008-11-30) of RAN10.0, draft (2009-01-15) incorporates the

The description of setting the

The added parameters are as follows:

The description of a new resource

The parameter RscAllocM is added

The description of HSDPA is

All the parameter names are replaced

Huawei Proprietary and Confidential

2.1 General Principles of HSDPA

Huawei Proprietary and Confidential

Fast hybrid automatic repeat request (HARQ) is used to rapidly

To compensate for channel variations, the DCH performs power

2.2 HSDPA Channels

Huawei Proprietary and Confidential

Figure 2-1 Physical channels of HSDPA

2.2.1 HS-DSCH and HS-PDSCH

Huawei Proprietary and Confidential

2.2.4 DPCCH and DPCH/F-DPCH

2.3 Impact of HSDPA on NEs

2.4 HSDPA Functions

2.4.1 HSDPA Control Plane Functions

Huawei Proprietary and Confidential

Figure 2-2 HSDPA control plane functions

The HSDPA control plane functions are described as follows:

Huawei Proprietary and Confidential

2.4.2 HSDPA User Plane Functions

Huawei Proprietary and Confidential

This chapter consists of the following sections:

Power Resource Management

Code Resource Management

3.1 Bearer Mapping

Huawei Proprietary and Confidential

3.2 Access Control

3.3 Mobility Management

Huawei Proprietary and Confidential

3.4 Channel Switching