Professional Documents
Culture Documents
Hsdpa Parameter Description Huawei
Hsdpa Parameter Description Huawei
HSDPA
Parameter Description
Issue
02
Date
2009-06-30
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.
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
Issue 02 (2009-06-30)
iii
RAN
HSDPA
Contents
6 Parameters ...................................................................................................................................6-1
7 Counters .......................................................................................................................................7-1
8 Glossary .......................................................................................................................................8-1
9 Reference Documents ...............................................................................................................9-1
iv
Issue 02 (2009-06-30)
RAN
HSDPA
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.
Document Issues
The document issues are as follows:
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
1-2
Issue 02 (2009-06-30)
RAN
HSDPA
Change Type
Change Description
Parameter Change
ARP14Priority
TrafficClass
THP
USERPRIORITY
UlGBR
DlGBR
SPI
FACTOR
HappyBR
THPClass
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
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.
Compared with issue 03 (2008-11-30) of RAN10.0, draft (2009-01-15) incorporates the
following changes:
Change
Type
Change Description
Parameter Change
Feature
change
Issue 02 (2009-06-30)
CodeAdjForHsdpaUserNumThd
CodeAdjForHsdpaSwitch
1-3
RAN
HSDPA
Change
Type
Change Description
Parameter Change
Editorial
change
1-4
MaxDchVoipHarqRt
MaxDchAmrHarqRt
MaxNonConverHarqRt
None
None
Issue 02 (2009-06-30)
RAN
HSDPA
2 Overview of HSDPA
Overview of HSDPA
Issue 02 (2009-06-30)
2-1
RAN
HSDPA
2 Overview of HSDPA
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 AMC
The MAC-hs, a new MAC sublayer, is introduced into the UE and NodeB to support HSDPA.
2-2
Issue 02 (2009-06-30)
RAN
HSDPA
2 Overview of HSDPA
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.
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
Issue 02 (2009-06-30)
2-3
RAN
HSDPA
2 Overview of HSDPA
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-4
Issue 02 (2009-06-30)
RAN
HSDPA
2 Overview of HSDPA
Issue 02 (2009-06-30)
2-5
RAN
HSDPA
2 Overview of HSDPA
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."
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.
2-6
Issue 02 (2009-06-30)
RAN
HSDPA
3 Control Plane
Control Plane
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
RAN
HSDPA
3 Control Plane
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. For details, see the Radio Bearers Parameter Description.
Huawei supports bearer management of HSDPA over Iur. "HSDPA over Iur" is an optional
feature.
3-2
Issue 02 (2009-06-30)
RAN
HSDPA
3 Control Plane
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.
Table 3-2 lists new state transition and new channel switching.
Table 3-2 New state transition and new channel switching
New State Transition
Issue 02 (2009-06-30)
3-3
RAN
HSDPA
3 Control Plane
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:
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:
3-4
Issue 02 (2009-06-30)
RAN
HSDPA
3 Control Plane
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."
Issue 02 (2009-06-30)
3-5
RAN
HSDPA
3 Control Plane
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-6
Issue 02 (2009-06-30)
RAN
HSDPA
3 Control Plane
Issue 02 (2009-06-30)
3-7
RAN
HSDPA
3 Control Plane
purpose of this setting is to prevent too many codes from being allocated for the HS-PDSCH
and to prevent DCH users from preempting codes during admission.
The number of codes that can be shared between HS-PDSCH and DPCH is equal to the value
of HsPdschMaxCodeNum minus the value of HsPdschMinCodeNum, as shown in Figure
3-5. When a code that can be shared is idle, it can be allocated to the HS-PDSCH if the idle
code is adjacent to the allocated HS-PDSCH codes.
Figure 3-5 RNC-controlled dynamic code allocation
After a DCH RL is released or reconfigured (for example, because the spreading factor
becomes larger), the RNC adds an HS-PDSCH code if the following conditions are met:
The code adjacent to the allocated HS-PDSCH codes is idle.
After the code is added, the minimum spreading factor of the remaining codes is smaller
than or equal to the value of CellLdrSfResThd.
The parameter CellLdrSfResThd set on the RNC side is used to reserve codes for new users,
to avoid congestion due to code insufficiency, and to avoid unnecessary reshuffling of the
code tree.
3-8
Issue 02 (2009-06-30)
RAN
HSDPA
3 Control Plane
If idle DPCH codes are insufficient when a DCH RL is set up, added, or reconfigured (for
example, because the spreading factor becomes smaller), the RNC preempts HS-PDSCH
codes in the shared codes for the DPCH. In addition, if the minimum spreading factor of idle
DPCH codes is greater than the value of CellLdrSfResThd, the RNC can also reallocate
some HS-PDSCH codes to the DPCH. The reallocated code number must be the smallest one
of the available shared codes.
Every TTI, the NodeB detects the SF16 codes that are not allocated to the HS-PDSCH. If
such an SF16 code or any of its subcodes is allocated by the RNC to the DCH or a common
channel, this SF16 code is regarded as occupied. Otherwise, it is regarded as unoccupied.
Therefore, the available HS-PDSCH codes include the codes reserved by the RNC and the
idle codes adjacent to the allocated HS-PDSCH codes. Every time the RNC allocates or
release HS-PDSCH codes, it notifies the NodeB through Iub signaling and the NodeB
performs the corresponding processes.
For example, the RNC reserves the SF16 codes numbered 11 to 15 for the HS-PDSCH and
those numbered 0 to 5 for the DCH and common channels in a TTI. Thus, the HS-PDSCH can
use the codes numbered 6 to 15 in this TTI.
Issue 02 (2009-06-30)
3-9
RAN
HSDPA
3 Control Plane
If the setup of an RL requires a DPCH code that is already allocated by the NodeB to the
HS-PDSCH, the NodeB releases this code and sends an NBAP message to the RNC,
indicating that the RL is set up successfully. Then, the DCH uses this code. After the DCH
releases it, the HS-PDSCH can use this code again.
"Dynamic Code Allocation Based on NodeB" is an optional feature.
3-10
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
User Plane
Issue 02 (2009-06-30)
4-1
RAN
HSDPA
4 User Plane
Figure 4-1 Basic principles of Iub flow control and congestion control
The NodeB measures the buffered data amount of each MAC-hs queue and the average
Uu transmission rate.
2.
3.
The NodeB adjusts the Iub bandwidth pre-allocated to the MAC-hs queue.
4-2
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
Issue 02 (2009-06-30)
4-3
RAN
HSDPA
4 User Plane
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-4
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
MAXCI Algorithm
The retransmission processes unconditionally have higher priorities than the initial
transmission queues. The retransmission processes are sorted in first-in first-out (FIFO) mode.
The initial transmission queues are sorted in the CQI order. A higher CQI means a higher data
priority.
The MAXCI algorithm aims to maximize the system capacity but cannot ensure user fairness
and differentiated services.
RR Algorithm
The retransmission processes unconditionally have higher priorities than the initial
transmission queues. The retransmission processes are sorted in FIFO mode. The initial
transmission queues are sorted in the order of the waiting time in the MAC-hs queue. A longer
waiting time means a higher data priority.
The RR algorithm aims to ensure user fairness but cannot provide differentiated services. Not
considering the CQI reported by the UE leads to lower system capacity.
PF Algorithm
The retransmission processes unconditionally have higher priorities than the initial
transmission queues. The retransmission processes are sorted in FIFO mode. The initial
transmission queues are sorted in the order of R/r. Here, R represents the throughput
corresponding to the CQI reported by the UE, and r represents the throughput achieved by the
UE. A greater R/r value means a higher data priority.
The PF algorithm aims to make a tradeoff between system capacity and user fairness. It
provides the user with an average throughput that is proportional to the actual channel quality.
The system capacity provided by PF is between the system capacity provided by RR and that
provided by MAXCI.
EPF Algorithm
The EPF algorithm can meet the requirements of telecom operators related to user fairness
and differentiated services and also provide a high system capacity.
Issue 02 (2009-06-30)
4-5
RAN
HSDPA
4 User Plane
Firstly, priorities are determined on the basis of service types. The EPF algorithm
distinguishes between delay-sensitive data and throughput-sensitive data based on the QoS
requirements.
The amount of delay-sensitive data is generally small. The transmission delay of
delay-sensitive data should be as short as possible. When the transmission delay reaches a
specified threshold, data packets are discarded. The delay-sensitive data includes the
following data:
SRB signaling
VoIP and AMR service data whose waiting time approaches the value of the discard
timer
The amount of a throughput-sensitive data is generally small. A higher transmission rate
brings greater user satisfaction. The throughput-sensitive data includes the following data:
BE service data
Streaming service data
IMS data
VoIP and AMR service data whose waiting time is far from the value of the discard timer
The EPF algorithm meets the basic QoS requirements of users. For delay-sensitive data, the
transmission delay must not exceed the maximum permissible delay. For throughput-sensitive
data, the transmission rate must not be lower than the GBR. Users require higher QoS for
delay-sensitive data. Therefore, the delay-sensitive data has a higher priority than the
throughput-sensitive data.
Secondly, for delay-sensitive data or throughput-sensitive data, the EPF algorithm
distinguishes between retransmission processes and initial transmission queues. The
retransmission processes unconditionally have higher priorities than the initial transmission
queues.
Thirdly, the priorities of the initial transmission queues are calculated for delay-sensitive data
or throughput-sensitive data. The following factors are considered: the waiting time, CQI
reported by the UE, throughput achieved by the UE, guaranteed bit rate (GBR), scheduling
priority indicator (SPI) weight, happy bit rate (HBR), and power consumed in the queue for a
certain period. The impacts of these factors on the priority calculation are as follows:
For the delay-sensitive data, a longer waiting time means a higher data priority.
For the throughput-sensitive data, a greater R/r value means a higher data priority. Here,
R represents the throughput corresponding to the CQI reported by the UE, and r
represents the throughput achieved by the UE.
The UEs with the rates lower than the GBR have higher priorities than those with the
rates already reaching the GBR.
A higher SPI weight means a higher data priority.
A larger difference between the actual rate and the HBR means a higher data priority.
When the resource limitation switch (RscLmSw) is on, the algorithm allocates the
lowest priority to a queue whose power consumption exceeds the threshold. RscLmSw
is used to prevent the users in areas with poor coverage from consuming too many cell
resources so that there is no decrease in system capacity. The ratio of the maximum
available power of a queue to the total power of the cell depends on the GBR, as listed in
Table 4-1.
By calculating the priority of each queue, the scheduling algorithm achieves the following:
4-6
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
When the system resources are sufficient to meet the basic QoS requirements of all users,
the transmission delay of delay-sensitive data is within the permissible range and the
transmission rate of throughput-sensitive data is not lower than the GBR. High-priority
users can obtain more resources for higher QoS.
When the system resources are insufficient to meet the basic QoS requirements of all
users, delay-sensitive data has higher priorities than throughput-sensitive data.
High-priority users can obtain more resources to ensure the basic QoS.
Fourthly, special processing is performed.
Differentiated services based on SPI weights are provided. Different services have
different service types, and different users have different user priorities. Therefore, the
scheduling function needs to consider these two factors to provide differentiated services.
SPI is a parameter specified on the basis of service types and users priorities. The
parameter SPIweight can be specified according to the SPI to provide differentiated
services. This parameter is specified on the RNC, and its value ranges from 0% to 100%.
The SPI weight affects the calculation of queue priorities. It is used to quantify the
differentiated services. If all the rates of throughput-sensitive services with different SPI
weights exceed or none of the rates exceeds their GBRs, the proportion of SPI weights
determines the proportion of rates among users. For example, for three
throughput-sensitive service users with the same channel quality, if their GBRs are not
configured and the proportion of SPI weights is 100:50:30, the proportion of actual rates
is close to 100:50:30.
Differentiated services based on SPI weights are optional.
Users with poor channel quality are prevented from consuming too many radio resources.
If a user in a poor-coverage area, for example, at the edge of a cell, has a high priority,
too many radio resources may be consumed to meet the QoS requirement. In this case,
the QoS of other users may be affected. To solve this problem, resource restriction
parameters such as 8KRSCLMT, 16KRSCLMT, 32KRSCLMT, 64KRSCLMT,
128KRSCLMT, 256KRSCLMT, and 384KRSCLMT are defined to restrict the
maximum power consumption of each user. They are configured on the NodeB
according to the GBRs.
Table 4-1 Default maximum ratios based on the GBR
GBR (kbit/s)
Maximum Ratio
10%
16
10%
32
15%
64
15%
128
20%
256
25%
384
30%
The HBR is configured. The HBR determines the throughput expected by the user based
on a study on user experience. When the rate for a user reaches the HBR, the scheduling
probability for the user is decreased. Therefore, the scheduling probability of the users
with rates lower than the HBR is increased. In this way, more users can obtain satisfying
Issue 02 (2009-06-30)
4-7
RAN
HSDPA
4 User Plane
services. The HBR is specified by the parameter HappyBR on the RNC side. The setting
can be based on user levels, including gold, silver, and copper.
For details on the parameters related to QoS management, such as the GBR, SPI, SPI weight,
and HBR, see section 5.3 "QoS Parameter Mapping and Configuration."
The EPF algorithm is optional.
MAXCI
RR
PF
EPF
Service type
No
No
No
Yes
Initial transmission or
retransmission
Yes
Yes
Yes
Yes
Maximum power
No
No
No
Yes
Waiting time
No
Yes
No
Yes
CQI
Yes
No
Yes
Yes
Actual throughput
No
No
Yes
Yes
SPI
No
No
No
Yes
GPR
No
No
No
Yes
HBR
No
No
No
Yes
4-8
Item
MAXCI
RR
PF
EPF
System capacity
Highest
High
Higher
Higher
User fairness
Not guaranteed
Best
Guaranteed
Guaranteed
Differentiated
services
Not guaranteed
Not guaranteed
Not guaranteed
Guaranteed
Real-time services
Not guaranteed
Not guaranteed
Not guaranteed
Guaranteed
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
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.
Issue 02 (2009-06-30)
4-9
RAN
HSDPA
4 User Plane
4-10
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
Issue 02 (2009-06-30)
4-11
RAN
HSDPA
4 User Plane
4-12
Issue 02 (2009-06-30)
RAN
HSDPA
4 User Plane
The following figure shows the backward-searching methods used when the parameter is set
to PowerCode_Bal.
Issue 02 (2009-06-30)
4-13
RAN
HSDPA
4 User Plane
4-14
Issue 02 (2009-06-30)
RAN
HSDPA
Service Connectivity
Service Delay
Service Rate
BLER
Mobility
management
HSDPA bearer
mapping
Load control
Issue 02 (2009-06-30)
5-1
RAN
HSDPA
Function
Service Connectivity
Service Delay
Service Rate
BLER
RLC
retransmission
Flow control
Congestion
control
HARQ
MAC-hs
scheduling
TFRC selection
These relations between HSDPA functions and QoS indicators are described as follows:
Mobility management
Service continuity is implemented by mobility management.
For details, see section 3.3 "Mobility Management" and the Handover Parameter
Description.
Bearer mapping
HSDPA bearers increase the service rate greatly and reduce the service delay.
For details, see section 3.1 "Bearer Mapping."
Load control
The network resources are limited. Therefore, when a large number of users attempt to
access the network, the access control function is required to control the access so as to
ensure the QoS of the admitted users.
The network resources consumed by the admitted users vary with the changed channel
qualities, which may lead to network congestion. To relieve congestion, the overload
control function is required to ensure the QoS of most users.
For details on load control, see the Load Control Parameter Description.
RLC retransmission and HARQ
To achieve error-free transmission and improve transmission efficiency, HSDPA
introduces HARQ at the physical layer. HARQ, however, cannot completely ensure
error-free transmission. Therefore, it should work with RLC retransmission and TCP
retransmission.
For details, see sections 4.2 "RLC and MAC-d" and 4.4 "HARQ."
Flow control and congestion control
By allocating appropriate Iub bandwidth to users, the flow control function reduces the
transmission time. Thus, it prevents too much data from waiting in the buffer at the
MAC-hs and avoids unnecessary RLC retransmissions. In addition, it protects service
data from overflowing from the buffer at the MAC-hs.
Through congestion detection and congestion control, the congestion control function
reduces the packet loss probability.
For details, see section 4.1 "Flow Control and Congestion Control."
MAC-hs scheduling
5-2
Issue 02 (2009-06-30)
RAN
HSDPA
Based on the waiting time, achieved service rate, and GBR, the MAC-hs scheduling
function sorts the users to meet the requirements for transmission delay and transmission
rate on the Uu interface. For details, see section 4.3 "MAC-hs Scheduling."
TFRC selection
Based on the available power, available codes, actual channel quality, and actual data
amount, the TFRC selection function selects appropriate transport blocks and modulation
schemes to increase data rates. For details, see section 4.5 "TFRC Selection."
Issue 02 (2009-06-30)
5-3
RAN
HSDPA
5-4
Issue 02 (2009-06-30)
RAN
HSDPA
Full Name
MBR
Parameter ID
SingalUlMBR
SingalDlMBR
StreamUlMBR
Description
MBR specifies the UL/DL
maximum bit rate of signals
and BE for PS domain users.
StreamDlMBR
ConverUlMBR
ConverDlMBR
ARP
Allocation/Retention
priority
ARP1Priority
~ARP14Priority
User_priority of
Allocation/Retention priority
1~14.
0 is invalid, and 15 is known
as no priority,Huaweideal the
same with APR14.
Issue 02 (2009-06-30)
5-5
RAN
HSDPA
Diff-Serv
Factor
Full Name
Parameter ID
Description
TC
traffic class
TrafficClass
THP
traffic handling
priority
THP
SPI
scheduling priority
indicator
SPI
GBR
UlGBR
DlGBR
SPI
Weight
scheduling priority
indicator weight
FACTOR
HBR
HappyBR
Issue 02 (2009-06-30)
RAN
HSDPA
Figure 5-1 Mapping between the factors considered in differentiated services management
1
0
1
1
1
2
1
3
14
15
UserPri
ority
Err
or
The mapping of TrafficClass, UserPriority and THP to SPI is set by the SET
SCHEDULEPRIOMAP command in RNC.
Table 5-4 Default mapping of user priority to SPI (Gold, Silver, and Copper correspond to user
priorities 1, 2, and 3 respectively.)
TrafficClass
UserPriority
THP
SPI
Interactive
10
3 to 15
3 to 15
3 to 15
Issue 02 (2009-06-30)
5-7
RAN
HSDPA
TrafficClass
UserPriority
THP
SPI
Background
None
None
None
The mapping of SPI to FACTOR is set on the RNC through the SET SPIFACTOR
command. Though the SPI configuration considers user priorities and service types, the
SPI weight can also be configuration according to user priorities.
Table 5-5 Default setting of algorithm based on SPI
SPI
15
100%
14
100%
13
100%
12
100%
11
100%
10
100%
100%
100%
90%
90%
90%
80%
80%
80%
The mapping of TrafficClass, THPClass and UserPriority to GBR is set by the SET
USERGBR command in RNC.
The mapping of TrafficClass and UserPriority to HappyBR is set by the SET
USERHAPPYBR command in RNC.
5-8
Issue 02 (2009-06-30)
RAN
HSDPA
6 Parameters
Parameters
Description
AllocCodeMode
ARP10Priority
ARP11Priority
ARP12Priority
ARP13Priority
ARP14Priority
ARP1Priority
ARP2Priority
ARP3Priority
ARP4Priority
ARP5Priority
ARP6Priority
ARP7Priority
ARP8Priority
ARP9Priority
Issue 02 (2009-06-30)
6-1
RAN
HSDPA
6 Parameters
Parameter ID
Description
CellLdrSfResThd
CodeAdjForHsdpaSwitch
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
ConverUlMBR
DlGBR
DynCodeSw
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
HsPdschMaxCodeNum
HsPdschMinCodeNum
6-2
Issue 02 (2009-06-30)
RAN
HSDPA
6 Parameters
Parameter ID
Description
HsPdschMPOConstEnum
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
PwrMgn
Power Margin Ratio, to prevent the total power from exceeding the 100%
power margin in 2 ms.
RscAllocM
RscLmSw
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
SPI
This parameter indicates the scheduling priority. The value 15 indicates the
highest priority and the value 0 indicates the lowest.
StreamDlMBR
StreamUlMBR
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
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)
6-3
RAN
HSDPA
6 Parameters
Parameter ID
Description
16KRSCLMT
Upper limit ratio of the power for the user with 16 kbps GBR to the total
power of the cell
32KRSCLMT
Upper limit ratio of the power for the user with 32 kbps GBR to the total
power of the cell
64KRSCLMT
Upper limit ratio of the power for the user with 64 kbps GBR to the total
power of the cell
128KRSCLMT
Upper limit ratio of the power for the user with 128 kbps GBR to the total
power of the cell
256KRSCLMT
Upper limit ratio of the power for the user with 256 kbps GBR to the total
power of the cell
384KRSCLMT
Upper limit ratio of the power for the user with 384 kbps GBR to the total
power of the cell
Default
Value
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
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
6-4
Issue 02 (2009-06-30)
RAN
HSDPA
6 Parameters
Parameter
ID
Default
Value
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)
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)
6-5
RAN
HSDPA
6 Parameters
Parameter
ID
Default
Value
Actual Value
Range
Unit
NumThd
MML Command
NE
onal)
ConverDlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
ConverUlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
DlGBR
kbit/s
SET
USERGBR(Option
al)
RNC
DynCodeS
w
None
OPEN,
OPEN,
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
6-6
CLOSE
CLOSE
Issue 02 (2009-06-30)
RAN
HSDPA
Parameter
ID
6 Parameters
Default
Value
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,
None
SET
MACHSPARA(Op
tional)
Node
B
SingalDlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
SingalUlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
SM
None
EPF (Enhanced
Proportional Fairness),
PF (Proportional
Fairness), RR
(Round Robin),
MAXCI (Max C/I)
None
SET
MACHSPARA(Op
tional)
Node
B
SPI
0~15
0~15
None
SET
SPIFACTOR(Man
datory)
SET
SCHEDULEPRIO
MAP(Mandatory)
RNC
StreamDlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
Issue 02 (2009-06-30)
CLOSE
6-7
RAN
HSDPA
6 Parameters
Parameter
ID
Default
Value
Actual Value
Range
Unit
MML Command
NE
StreamUlM
BR
kbit/s
SET
USERMBR(Option
al)
RNC
THP
1~15
1~15
None
SET
SCHEDULEPRIO
MAP(Mandatory)
RNC
THPClass
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
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
6-8
Issue 02 (2009-06-30)
RAN
HSDPA
Parameter
ID
6 Parameters
Default
Value
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)
6-9
RAN
HSDPA
7 Counters
Counters
02 (2009-06-30)
7-1
RAN
HSDPA
8 Glossary
Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
02 (2009-06-30)
8-1
RAN
HSDPA
9 Reference Documents
Reference Documents
2.
3.
3GPP TS 25.308, "UTRA High Speed Downlink Packet Access (HSDPA); Overall
description"
4.
5.
3GPP TS 25.435, "UTRAN Iub interface user plane protocols for CCH data flows"
6.
7.
8.
9.
02 (2009-06-30)
9-1