Professional Documents
Culture Documents
Hsdpa Parameter Description 130
Hsdpa Parameter Description 130
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.
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.
Contents
6 Parameters ...................................................................................................................................6-1
7 Counters .......................................................................................................................................7-1
8 Glossary .......................................................................................................................................8-1
9 Reference Documents ...............................................................................................................9-1
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)
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.
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:
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:
Feature The description of dynamic code tree The added parameters are as follows:
change reshuffling is added in section 3.7.6 CodeAdjForHsdpaUserNumThd
"Dynamic Code Tree Reshuffling."
CodeAdjForHsdpaSwitch
The description of setting the The added parameters are as follows:
maximum number of retransmissions
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 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.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
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.
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.
3 Control Plane
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.
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.
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.
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:
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.
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.
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.
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.
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.
4 User Plane
Figure 4-1 Basic principles of Iub flow control and congestion control
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.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.
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.
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:
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.
8 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
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.
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.
The following figure shows the backward-searching methods used when the parameter is set
to PowerCode_Bal.
Mobility
management
HSDPA bearer
mapping
Load control
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
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."
Figure 5-1 Mapping between the factors considered in differentiated services management
Table 5-3 Mapping of ARP to User Priority (Gold, Silver, and Copper correspond to user priorities
1, 2, and 3 respectively.)
ARP 0 1 2 3 4 5 6 7 8 9 1 1 1 1 14 15
0 1 2 3
UserPri Err 1 1 1 1 1 1 1 2 2 2 3 3 3 3 3
ority 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 1 1 10
1 2 9
1 3 to 15 8
2 1 7
2 2 6
2 3 to 15 5
3 1 4
3 2 3
3 3 to 15 2
15 100%
14 100%
13 100%
12 100%
11 100%
10 100%
9 100%
8 100%
7 90%
6 90%
5 90%
4 80%
3 80%
2 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.
6 Parameters
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 User_priority corresponding to Allocation/Retention priority 11.
ARP12Priority User_priority corresponding to Allocation/Retention priority 12.
ARP13Priority User_priority corresponding to Allocation/Retention priority 13.
ARP14Priority User_priority corresponding to Allocation/Retention priority 14.
ARP1Priority User_priority corresponding to Allocation/Retention priority 1.
ARP2Priority User_priority corresponding to Allocation/Retention priority 2.
ARP3Priority User_priority corresponding to Allocation/Retention priority 3.
ARP4Priority User_priority corresponding to Allocation/Retention priority 4.
ARP5Priority User_priority corresponding to Allocation/Retention priority 5.
ARP6Priority User_priority corresponding to Allocation/Retention priority 6.
ARP7Priority User_priority corresponding to Allocation/Retention priority 7.
ARP8Priority User_priority corresponding to Allocation/Retention priority 8.
ARP9Priority User_priority corresponding to Allocation/Retention priority 9.
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
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
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
Parameter Default GUI Value Range Actual Value Unit MML Command NE
ID Value Range
Parameter Default GUI Value Range Actual Value Unit MML Command NE
ID Value Range
NumThd onal)
ConverDlM - D0, D8, D16, D32, D0, D8, D16, D32, kbit/s SET RNC
BR D64, D128, D144, D64, D128, D144, USERMBR(Option
D256, D384 D256, D384 al)
ConverUlM - D0, D8, D16, D32, D0, D8, D16, D32, kbit/s SET RNC
BR D64, D128, D144, D64, D128, D144, USERMBR(Option
D256, D384 D256, D384 al)
DlGBR - D0, D8, D16, D32, 0, 8, 16, 32, 64, kbit/s SET RNC
D64, D128, D144, 128, 144, 256, 384 USERGBR(Option
D256, D384 al)
DynCodeS None OPEN, CLOSE OPEN, CLOSE None SET Node
w MACHSPARA(Op B
tional)
FACTOR - 0~100 0~100 per SET RNC
cent SPIFACTOR(Man
datory)
HappyBR - 0~5000 0~5000 kbit/s SET RNC
USERHAPPYBR(
Optional)
HspaPower 0 -500~0 -50~0, step:0.1 dB ADD RNC
CELLHSDPA(Opti
onal)
HsPdschCo 5 1~15 1~15 None ADD RNC
deNum CELLHSDPA(Opti
onal)
HsPdschMa 5 1~15 1~15 None ADD RNC
xCodeNum CELLHSDPA(Opti
onal)
HsPdschMi 1 1~15 1~15 None ADD RNC
nCodeNum CELLHSDPA(Opti
onal)
HsPdschMP 2.5dB Minus3.0DB(-3.0dB), -3~19, step:0.5 dB ADD RNC
OConstEnu Minus2.5DB(-2.5dB), CELLHSDPA(Opti
m Minus2.0DB(-2.0dB), onal)
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),
Parameter Default GUI Value Range Actual Value Unit MML Command NE
ID Value Range
3.5DB(3.5dB),
4.0DB(4.0dB),
4.5DB(4.5
HsScchCod 4 1~15 1~15 None ADD RNC
eNum CELLHSDPA(Opti
onal)
MaxNonCo None 0~10 0~10 Time SET Node
nverHarqRt s MACHSPARA(Op B
tional)
PwrMgn None 0~100 0~100 % SET Node
MACHSPARA(Op B
tional)
RscAllocM None CODE_PRI(Code CODE_PRI, None SET Node
Priority:refers to power POWER_PRI, MACHSPARA(Op B
limited cell), POWERCODE_B tional)
POWER_PRI(Power AL
Priority:refers to code
limited cell),
POWERCODE_BAL(
Balance between Code
and Power)
RscLmSw None OPEN (OPEN), OPEN, CLOSE None SET Node
CLOSE (CLOSE) MACHSPARA(Op B
tional)
SingalDlM - D3.4, D13.6, D27.2 D3.4, D13.6, D27.2 kbit/s SET RNC
BR USERMBR(Option
al)
SingalUlM - D3.4, D13.6, D27.2 D3.4, D13.6, D27.2 kbit/s SET RNC
BR USERMBR(Option
al)
SM None EPF (Enhanced EPF, PF, RR, None SET Node
Proportional Fairness), MAXCI MACHSPARA(Op B
PF (Proportional tional)
Fairness), RR
(Round Robin),
MAXCI (Max C/I)
SPI - 0~15 0~15 None SET RNC
SPIFACTOR(Man
datory)
SET
SCHEDULEPRIO
MAP(Mandatory)
StreamDlM - D0, D8, D16, D32, D0, D8, D16, D32, kbit/s SET RNC
BR D64, D128, D144, D64, D128, D144, USERMBR(Option
D256, D384 D256, D384 al)
Parameter Default GUI Value Range Actual Value Unit MML Command NE
ID Value Range
StreamUlM - D0, D8, D16, D32, D0, D8, D16, D32, kbit/s SET RNC
BR D64, D128, D144, D64, D128, D144, USERMBR(Option
D256, D384 D256, D384 al)
THP - 1~15 1~15 None SET RNC
SCHEDULEPRIO
MAP(Mandatory)
THPClass - High, Medium, Low High, Medium, None SET RNC
Low USERGBR(Manda
tory)
TrafficClass - INTERACTIVE, INTERACTIVE, None SET RNC
BACKGROUND BACKGROUND SCHEDULEPRIO
MAP(Mandatory)
SET
USERGBR(Manda
tory)
SET
FACHBANDWID
TH(Mandatory)
SET
USERHAPPYBR(
Mandatory)
SET
DTXDRXPARA(
Mandatory)
SET
HSSCCHLESSOP
PARA(Mandatory)
UlGBR - D0, D8, D16, D32, 0, 8, 16, 32, 64, kbit/s SET RNC
D64, D128, D144, 128, 144, 256, 384 USERGBR(Option
D256, D384 al)
USERPRIO - GOLD, SILVER, GOLD, SILVER, None SET RNC
RITY COPPER COPPER SCHEDULEPRIO
MAP(Mandatory)
SET
USERGBR(Manda
tory)
SET
FACHBANDWID
TH(Mandatory)
SET
USERHAPPYBR(
Mandatory)
8KRSCLM None 1~100 1~100 % SET Node
T RSCLMTPARA(O B
ptional)
16KRSCL None 1~100 1~100 % SET Node
RSCLMTPARA(O
Parameter Default GUI Value Range Actual Value Unit MML Command NE
ID Value Range
MT ptional) B
32KRSCL None 1~100 1~100 % SET Node
MT RSCLMTPARA(O B
ptional)
64KRSCL None 1~100 1~100 % SET Node
MT RSCLMTPARA(O B
ptional)
128KRSCL None 1~100 1~100 % SET Node
MT RSCLMTPARA(O B
ptional)
256KRSCL None 1~100 1~100 % SET Node
MT RSCLMTPARA(O B
ptional)
384KRSCL None 1~100 1~100 % SET Node
MT RSCLMTPARA(O B
ptional)
The Default Value column is valid for only the optional parameters.
The "-" symbol indicates no default value.
7 Counters
8 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
9 Reference Documents