HSPA Evolution

HSPA Evolution RAN12.
Feature Parameter Description
Issue Date
02 2010-06-20
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. 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: Email: http://www.huawei.com support@huawei.com
WCDMA RAN HSPA Evolution
Contents
Contents
1 Introduction ................................................................................................................................1-1
1.1 Scope ............................................................................................................................................ 1-1 1.2 Intended Audience ........................................................................................................................ 1-1 1.3 Change History.............................................................................................................................. 1-1
2 Overview of HSPA and HSPA+ ..............................................................................................2-1 3 HSPA Introduced in RAN10.0 .................................................................................................3-1

3.1 F-DPCH ......................................................................................................................................... 3-1 3.1.1 Overview ............................................................................................................................... 3-1 3.1.2 Basic Principle ...................................................................................................................... 3-1 3.2 SRB over HSDPA .......................................................................................................................... 3-3 3.2.1 Overview ............................................................................................................................... 3-3 3.2.2 Basic Principle ...................................................................................................................... 3-4 3.2.3 Radio Bearers ....................................................................................................................... 3-4 3.3 SRB over HSUPA .......................................................................................................................... 3-4 3.3.1 Overview ............................................................................................................................... 3-4 3.3.2 Basic Principle ...................................................................................................................... 3-5 3.3.3 Radio Bearers ....................................................................................................................... 3-5 3.4 IMS Signaling over HSPA.............................................................................................................. 3-6 3.4.1 Overview ............................................................................................................................... 3-6 3.4.2 Basic Principle ...................................................................................................................... 3-6 3.4.3 Radio Bearers ....................................................................................................................... 3-6 3.4.4 Scheduling ............................................................................................................................ 3-6 3.5 HSDPA over Iur ............................................................................................................................. 3-7 3.5.1 Overview ............................................................................................................................... 3-7 3.5.2 Basic Principle ...................................................................................................................... 3-7 3.6 HSUPA over Iur ............................................................................................................................. 3-8 3.6.1 Overview ............................................................................................................................... 3-8 3.6.2 Basic Principle ...................................................................................................................... 3-8 3.7 HSUPA 2ms TTI ............................................................................................................................ 3-9 3.8 HS-DPCCH Preamble Support ..................................................................................................... 3-9 3.8.1 Overview ............................................................................................................................... 3-9 3.8.2 Basic Principle .................................................................................................................... 3-10
4 HSPA+ Introduced in RAN 11.0 .............................................................................................4-1

4.1 Overview ....................................................................................................................................... 4-1 4.2 Downlink Enhanced L2 ................................................................................................................. 4-2 4.2.1 Overview ............................................................................................................................... 4-2 4.2.2 Basic Principle ...................................................................................................................... 4-2 4.2.3 Radio Bearers ....................................................................................................................... 4-3
Issue 02 (2010-06-20)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd
iii
Contents
4.3 Downlink MIMO ............................................................................................................................. 4-4 4.4 Downlink 64QAM........................................................................................................................... 4-4 4.4.1 Overview ............................................................................................................................... 4-4 4.4.2 Basic Principle ...................................................................................................................... 4-5 4.4.3 Downlink 64QAM Selection .................................................................................................. 4-6 4.5 Downlink Enhanced CELL_FACH Operation ................................................................................ 4-8 4.5.1 Overview ............................................................................................................................... 4-8 4.5.2 Basic Principle ...................................................................................................................... 4-8 4.5.3 Radio Bearers ....................................................................................................................... 4-9 4.5.4 State Transition ................................................................................................................... 4-10 4.5.5 Power Control ..................................................................................................................... 4-11 4.5.6 Scheduling .......................................................................................................................... 4-12 4.5.7 Flow Control ....................................................................................................................... 4-12 4.6 CPC DTX-DRX ............................................................................................................................ 4-13 4.6.1 Overview ............................................................................................................................. 4-13 4.6.2 Basic Principle .................................................................................................................... 4-13 4.6.3 Radio Bearers ..................................................................................................................... 4-14 4.6.4 Transmission Pattern .......................................................................................................... 4-15 4.7 CPC HS-SCCH Less Operation .................................................................................................. 4-16 4.7.1 Overview ............................................................................................................................. 4-16 4.7.2 Basic Principle .................................................................................................................... 4-17 4.7.3 Radio Bearers ..................................................................................................................... 4-18
5 HSPA+ Introduced in RAN12.0 ..............................................................................................5-1

5.1 Overview ....................................................................................................................................... 5-1 5.2 Downlink MIMO with 64QAM ........................................................................................................ 5-2 5.2.1 Overview ............................................................................................................................... 5-2 5.2.2 Basic Principle ...................................................................................................................... 5-2 5.2.3 Radio Bearer Scheme .......................................................................................................... 5-3 5.2.4 Scheduling Method ............................................................................................................... 5-4 5.3 DC-HSDPA .................................................................................................................................... 5-4 5.4 Uplink Enhanced L2 ...................................................................................................................... 5-4 5.4.1 Overview ............................................................................................................................... 5-5 5.4.2 Basic Principle ...................................................................................................................... 5-5 5.4.3 Radio Bearer Scheme .......................................................................................................... 5-6 5.5 Uplink 16QAM ............................................................................................................................... 5-6 5.5.1 Overview ............................................................................................................................... 5-6 5.5.2 Basic Principle ...................................................................................................................... 5-7 5.5.3 Radio Bearer Scheme .......................................................................................................... 5-8 5.5.4 Scheduling Method ............................................................................................................... 5-9
6 Parameters .................................................................................................................................6-1 7 Counters ......................................................................................................................................7-1

iv Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 02 (2010-06-20)
Contents
8 Glossary ......................................................................................................................................8-1 9 Appendix .....................................................................................................................................9-1

9.1 HS-DSCH Category ...................................................................................................................... 9-1 9.2 E-DCH Category ........................................................................................................................... 9-2 9.3 Improved CE Mapping for E-DCH ................................................................................................. 9-3 9.4 HSPA and HSPA+ Specifications .................................................................................................. 9-3
10 Reference Documents .........................................................................................................10-1
Issue 02 (2010-06-20)
1 Introduction
1 Introduction
1.1 Scope
This document describes the HSPA evolution features introduced in RAN10.0 and later versions. The features included in versions earlier than RAN10.0 are not described in this document.
1.2 Intended Audience

This document is intended for:

Personnel who are familiar with WCDMA basics Personnel who need to understand HSPA+ Personnel who work with Huawei products
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:

Feature change: refers to the change in the HSPA+ 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:

02 (2010-06-20) 01 (2010-03-30) Draft (2009-12-05)
02 (2010-06-20)
This is the document for the second commercial release of RAN12.0. Compared with issue 01 (2010-03-30) of RAN12.0, this issue optimizes the description. Change Type Change Description Parameter Change
Feature change The description of downlink enhanced L2 is optimized. None For details, see 4.2 Downlink Enhanced L2. The information about MIMO is optimized, and the information about performance Improvement in MIMO+HSDPA scenario is added. And the section about MIMO in this document is transferred to the MIMO Feature Parameter Description. Editorial change None. None.
None.
01 (2010-03-30)
This is the document for the first commercial release of RAN12.0.
Issue 02 (2010-06-20) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 1-1
1 Introduction
Compared with issue Draft (2009-12-05) of RAN12.0, this issue optimizes the description.
Draft (2009-12-05)
This is the draft of the document for RAN12.0. Compared with issue 02 (2009-06-30) of RAN11.0, this issue incorporates the changes described in the following table. Change Type Change Description Parameter Change The parameters added are as follows:

Feature change The information about the HSPA+ in RAN12.0 is added. For details, see 5 "HSPA+ Introduced in RAN12.0."
MIMOor64QAMSwitch MIMO64QAMorDCHSDPASwitch RlcPduMaxSizeForUlL2Enhance RlcPduMinSizeForUlL2Enhance
Editorial change The organization of the document is None. optimized. The description of the requirements of each HSPA+ technology for the original system is added.
1-2
Issue 02 (2010-06-20)
2 Overview of HSPA and HSPA+

3GPP introduces a series of new features to enhance HSPA (including HSDPA and HSUPA). All the enhanced HSPA features of release 7 and beyond are collectively termed HSPA+. With regard to network performance, HSPA+ helps to reduce service delay, increase peak data rates, improve spectral efficiency, increase system capacity, and reduce UE power consumption. HSPA+ technologies are enhanced accordingly with the evolution of 3GPP releases. Figure 2-1 shows the development of HSPA and HSPA+ technologies. Figure 2-1 Development of 3GPP HSPA and HSPA+ technologies
Table 2-1 lists the HSPA and HSPA+ technologies implemented in Huawei RAN. The features provided in versions earlier than RAN10.0 are described in HSDPA Feature Parameter Description and HSUPA Feature Parameter Description. Table 2-1 HSPA and HSPA+ technologies implemented in Huawei RAN 3GPP Version Release 5 Release 6 HSPA and HSPA+ Technology HSDPA over Iur HSUPA Over Iur SRB over HSDPA SRB over HSUPA F-DPCH Release 7 Downlink enhanced L2 2x2 MIMO Downlink 64QAM RAN Version RAN10.0 RAN10.0 RAN10.0 RAN10.0 RAN10.0 RAN 11.0 RAN 11.0 RAN 11.0
Issue 02 (2010-06-20)
2-1
3GPP Version
HSPA and HSPA+ Technology Downlink enhanced CELL_FACH operation Continuous packet connectivity (CPC) Uplink 16QAM
RAN Version RAN 11.0 RAN 11.0 RAN 12.0 RAN 12.0 RAN 12.0 RAN 12.0
Release 8
Uplink enhanced L2 Downlink MIMO+64QAM DC-HSDPA
2-2
Issue 02 (2010-06-20)
3 HSPA Introduced in RAN10.0

3.1 F-DPCH
3.1.1 Overview
F-DPCH is a fractional dedicated physical channel in the downlink. It carries only transmit power control (TPC) commands for associated UEs. The F-DPCH can help to save the downlink code resource used by the associated dedicated physical channel (A-DPCH). Up to 10 UEs can share one F-DPCH and the F-DPCH uses a single channelization code. Table 3-1 lists the requirements of the F-DPCH. Table 3-1 Requirements of the F-DPCH Item CN RNC Requirement None The RNC needs to support the F-DPCH and the bearer scheme of signaling radio bearer (SRB) over HSDPA. If a UE is configured with an F-DPCH, the RNC needs to configure all the radio bearers (RBs) of this UE on the high-speed downlink shared channel (HS-DSCH) but does not need to configure any dedicated channel (DCH) for this UE. The RNC needs to support the open-loop power control and outer-loop power control of the F-DPCH. NodeB UE The NodeB needs to support the F-DPCH and inner-loop power control. The UE needs to support the F-DPCH and the bearer scheme of SRB over HSDPA.
3.1.2 Basic Principle

In 3GPP Release 5, each HSDPA UE must have an A-DPCH to carry the TPC command and SRBs. In Release 6, the F-DPCH is introduced to save the code resource.
F-DPCH Frame Format

Figure 3-1 shows the frame format of the F-DPCH. If a UE is configured with an F-DPCH, all the RBs of this UE are mapped onto the HS-DSCH instead of the dedicated physical data channel (DPDCH). The F-DPCH carries only the TPC command because the pilot and transport format combination indicator (TFCI) are no more required.
Issue 02 (2010-06-20)
3-1
Figure 3-1 Frame format of the F-DPCH
The number of bits in each TX OFF period and the number of NTPC bits are listed in Table 3-2 . Each slot format corresponds to a set of TX OFF periods within an F-DPCH slot. Slot format 0 is the legacy of 3GPP Release 6, and other nine slot formats are introduced in Release 7. Table 3-2 F-DPCH Frame Format Slot Format Channel Bit Rate (kbps) 0 1 2 3 4 5 6 7 8 9 3 3 3 3 3 3 3 3 3 3 Channel Symbol Rate (ksps) 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5 256 256 256 256 256 256 256 256 256 256 20 20 20 20 20 20 20 20 20 20 2 4 6 8 10 12 14 16 18 0 2 2 2 2 2 2 2 2 2 2 16 14 12 10 8 6 4 2 0 18 SF Bits per Slot NOFF1 (bits/slot) NTPC NOFF2
(bits/slot) (bits/slot)
F-DPCH Multiplexing
The F-DPCH is specified by a single channelization code and can be shared by up to 10 UEs through time division multiplexing, as shown in Figure 3-2. The original timing is retained. Therefore, there is no need to adjust the timing for inner-loop power control.
3-2
Issue 02 (2010-06-20)
Figure 3-2 F-DPCH multiplexing
If the uplink DPCCH is not transmitted in some slots, the NodeB cannot estimate the uplink signal-to-interference ratio (SIR). Therefore, the NodeB does not transmit a TPC command in the downlink, and the UE cannot receive any TPC command on the F-DPCH. The F-DPCH is not used if the services of a UE need to be mapped onto the DPCH or if all the downlink services and signaling of a UE cannot be mapped onto the HS-DSCH. In 3GPP Release 6, the F-DPCH TPCs sent from different cells to a UE must have the same offset timing. In Release 7, however, these TPCs can have different timings with the introduction of the enhanced F-DPCH with slot formats of 1 to 9. For these slot formats, RRC signaling is handled separately. To support the enhanced F-DPCH, the HspaEnhSwitch parameter needs to be set to E_F_DPCH_ON. When a UE configured with an F-DPCH is admitted to a cell, the RNC dynamically allocates a symbol on the F-DPCH. Here, a symbol corresponds to a TPC command. If the RNC cannot find the proper symbol, it dynamically allocates a new F-DPCH channelization code for the UE. The F-DPCH power is controlled through open-loop power control and closed-loop power control. For details, see the Power Control Feature Parameter Description. To support the F-DPCH, the NodeB protocol version (NodeBProtclVer) needs to be set to Release 6 or later.
3.2 SRB over HSDPA

3.2.1 Overview
SRB over HSDPA (WRFD-010652 SRB over HSDPA) is a feature that enables downlink SRBs to be carried on HSDPA. The SRB over HSDPA feature has the following benefits, compared with SRB over DCH:

Provides higher signaling rates and thereby shortening call processing delay Reduces the consumption of code and transmission resources Lightens the cell load
The requirements of SRB over HSDPA are listed in Table 3-3.
Issue 02 (2010-06-20)
3-3
Table 3-3 Requirements of SRB over HSDPA Item CN RNC Requirement None The RNC needs to control the bearer scheme of SRB over HSDPA. If the SRBs of a UE need to be carried on HSDPA, the RNC must configure an F-DPCH for the UE. NodeB UE The NodeB needs to preferentially schedule the SRBs that are carried on HSDPA. The UE needs to support the F-DPCH and SRB over HSDPA.

SRB over HSDPA is introduced in 3GPP Release 6. After this feature is enabled, all downlink RBs of a UE are carried on HSDPA, and the A-DPCH is replaced with the F-DPCH. SRB over HSDPA saves the code resource. When the code resource is limited prior to the power resource, the cell capacity gets affected. In this case, SRBs should be established over HSDPA rather than over DCH. SRB over HSDPA can be applied during the RRC connection setup procedure or other procedures such as mobility management. The application of SRB over HSDPA or over DCH is configurable. In addition, whether SRB over HSDPA is applied during RRC connection setup can be configured. For details about SRB bearer schemes, see the Radio Bearers Feature Parameter Description. SRB over DCH can be modified to SRB over HSDPA under some conditions, for example, if the target cell for a handover supports HSDPA but the source cell does not. SRB over HSDPA can also be modified to SRB over DCH if the source cell supports HSDPA but the target cell does not.
3.2.3 Radio Bearers

During the setup of an RRC connection, SRBs can be carried on the HS-DSCH if the following conditions are met:

The SrbChlTypeRrcEffectFlag parameter is set to TRUE. The SrbChlType parameter is set to HSDPA or HSPA.
During the setup of a traffic radio bearer (TRB), SBRs that were not carried on the HS-DSCH before can be carried on the HS-DSCH through reconfiguration if the following conditions are met:

The channel types selected by all the TRBs are HS-DSCH. The SrbChlType parameter is set to HSDPA or HSPA.
3.3 SRB over HSUPA

3.3.1 Overview
SRB over HSUPA (WRFD-010636 SRB over HSUPA) is a feature that enables uplink SRBs to be carried on HSUPA. The SRB over HSUPA feature has the following benefits, compared with SRB over DCH:
3-4
Issue 02 (2010-06-20)

Provides higher signaling rates and thereby shortening call processing delay Reduces the transmission resource consumption
The requirements of SRB over HSUPA are listed in Table 3-4. Table 3-4 Requirements of SRB over HSUPA Item CN RNC NodeB UE Requirement None The RNC needs to control the bearer scheme of SRB over HSUPA. The NodeB needs to use a non-scheduling mode for SRB over HSUPA. The UE needs to support SRB over HSUPA.
When the baseline configuration is applied, this feature saves uplink CE resources. Before a UE is handed over from a cell configured with SRB over HSUPA to a cell without it, SRB services are migrated from the E-DCH to the DCH, resulting in a handover delay and subsequent call drops. To prevent this problem, it is recommended that this feature be enabled in the entire network.

SRB over HSUPA is introduced in 3GPP Release 6. After this feature is enabled, all uplink RBs of a UE are carried on HSUPA, and the A-DPCH is replaced with the F-DPCH. SRB over HSUPA provides higher transmission rates and improves transmission resource efficiency. Therefore, it is more appropriate to map SRBs onto HSUPA rather than onto DCH. SRB over HSUPA can be applied during the RRC connection setup procedure or other procedures such as mobility management. The application of SRB over HSUPA or over DCH is configurable. In addition, whether SRB over HSUPA is applied during RRC connection setup can be configured. For details about the SRB bearer schemes, see the Radio Bearers Feature Parameter Description. SRB over DCH can be modified to SRB over HSUPA under some conditions, for example, if the target cell for a handover supports HSUPA but the source cell does not. SRB over HSUPA can also be modified SRB over DCH if the source cell supports HSUPA but the target cell does not.
3.3.3 Radio Bearers

During the setup of an RRC connection, SRBs can be carried on the E-DCH if the following conditions are met:

The SrbChlTypeRrcEffectFlag parameter is set to TRUE. The SrbChlType parameter is set to HSUPA or HSPA.
During the setup of a TRB, SBRs that were not carried on the E-DCH before can be carried on the E-DCH if the following conditions are met:

The channel types selected by all the TRBs are E-DCH. The SrbChlType parameter is set to HSUPA or HSPA.
Issue 02 (2010-06-20)
3-5
3.4 IMS Signaling over HSPA

3.4.1 Overview
IMS Signaling over HSPA (WRFD-010618 IMS Signaling over HSPA) is a feature that enables IMS signaling to be carried on HSPA. IMS signaling over HSPA can shorten the setup delay of IMS services like VoIP to save network resources for the operator. The requirements of IMS signaling over HSPA are listed in the following table. Table 3-5 Requirements of IMS signaling over HSPA Item CN RNC NodeB UE Requirement The CN needs to support the signaling indication over Iu interface. The RNC needs to provide the bearer scheme of IMS Signaling over HSPA. None The UE needs to support the IMS Signaling over HSPA.

This feature is introduced in 3GPP R5. The IP Multimedia Subsystem (IMS) is an open and standardized architectural framework for delivering Internet Protocol (IP) multimedia services to mobile users. With this feature, operators provide network-controlled multimedia services by combining voice and data in a single packet switched network. IMS uses Session Initiation Protocol (SIP) as the key control protocol, and implements service management in the UTRAN. Such SIP signaling is indicated by the CN in the RAB Assignment Request message. The RAB should be an interactive QoS class service. With F-DPCH, the signaling RB can be carried on HSPA, which improves the performance for IMS service. The type of channels carrying IMS signaling is configurable separately on the downlink and uplink at cell level. That is, when HSPA is chosen as the bearer with high priority, maximum IMS signaling will be set up on it. If the setup is not successful, for example, due to admission control, a periodical timer will be started to trigger the reconfiguration of the HSPA procedure.
3.4.3 Radio Bearers

The IMS signaling can be carried on the DCH, HS-DSCH, or E-DCH.

In the downlink, if ImsChlType is set to HSDPA or HSPA, the IMS signaling is carried on the HS-DSCH. Otherwise, the IMS signaling is carried on the DCH. In the uplink, if ImsChlType is set to HSPA, the IMS signaling is carried on the E-DCH. Otherwise, the IMS signaling is carried on the DCH.
3.4.4 Scheduling
In the downlink, HSDPA scheduler schedules IMS signaling preferentially.
3-6
Issue 02 (2010-06-20)
In the uplink, HSUPA provide the options for scheduling IMS signaling. You can set the scheduling mode through the UlIMSTransModeOnHsupa parameter.
3.5 HSDPA over Iur

3.5.1 Overview
HSDPA over Iur (WRFD-010651 HSDPA over Iur) is a feature that enables HSDPA services to be carried on the Iur interface. The HSDPA over Iur feature provides continuous HSDPA services for UEs moving between RNCs. The requirements of HSDPA over Iur are listed in Table 3-6. Table 3-6 Requirements of HSDPA over Iur Item CN RNC NodeB UE Requirement None The RNC needs to support HSDPA over Iur. None None

HSDPA over Iur is introduced in 3GPP Release 5. This feature can be applied when the HSDPA serving cell is under the drifting RNC (DRNC). HSDPA over Iur provides the following functions:
HSDPA service management over Iur HSDPA service management over Iur involves HSDPA service setup, modification, release, and state transition over the Iur interface. The HSDPA service of a UE can be set up, modified, or released over the Iur interface if one of the following conditions is met:
The The
UE is in CELL_DCH state and a DRNC cell is in the active set. UE is in CELL_FACH state and camps on a DRNC cell.
Whether the Iur interface supports HSDPA services can be set through the IurHsdpaSuppInd parameter.
HSDPA mobility management over Iur HSDPA mobility management over Iur involves hard handover, cell update due to radio link failure, and serving cell change over the Iur interface.
HSDPA static relocation When the Iur interface is congested, HSDPA static relocation function can be triggered, if the HSDPA service is carried on the Iur interface and the radio links are provided only by the target RNC.
HSDPA service pre-emption at the DRNC When a new HSDPA service cannot be admitted to the network, the controlling RNC (CRNC) may trigger a pre-emption of other HSDPA services that have lower priorities. If the CRNC is the DRNC, it
Issue 02 (2010-06-20)
3-7
sends a RADIO LINK PREEMPTION REQUIRED INDICATION message to the serving RNC (SRNC), and then the SRNC releases the HSDPA services specified in the message.
3.6 HSUPA over Iur

3.6.1 Overview
HSUPA over Iur (WRFD-010635 carried on the Iur interface. HSUPA over Iur) is a feature that enables HSUPA services to be
The HSUPA over Iur feature provides continuous HSUPA services for UEs moving between the RNCs. The requirements of HSUPA over Iur are listed in Table 3-7. Table 3-7 Requirements of HSUPA over Iur Item CN RNC NodeB UE Requirement None The RNC needs to support HSUPA over Iur. None None

HSUPA over Iur is introduced in 3GPP Release 6. This feature can be applied when the DRNC cell is in the E-DCH active set. HSUPA over Iur provides the following functions:
HSUPA service management over Iur HSUPA service management over Iur involves HSUPA service setup, modification, release, and dynamic channel configuration control (DCCC). The HSUPA service of a UE can be set up, modified, or released over the Iur interface if one of the following conditions is met:
The The
UE is in CELL_DCH state and a DRNC cell is in the E-DCH active set. UE is in CELL_FACH state and camps on a DRNC cell.
Whether the Iur interface supports HSUPA can be set through the parameter IurHsupaSuppInd.
HSUPA mobility management over Iur HSUPA mobility management over Iur includes soft handover, hard handover, cell update due to radio link failure, and serving cell change over the Iur interface.
HSUPA static relocation When the Iur interface is congested, HSUPA static relocation can be triggered, if the HSUPA service is carried on the Iur interface and the radio links are provided only by the target RNC.
HSUPA service pre-emption at the DRNC When a new HSUPA service cannot be admitted to the network, the CRNC may trigger a pre-emption of other HSUPA services that have lower priorities. If the CRNC is the DRNC, it sends a RADIO LINK PREEMPTION REQUIRED INDICATION message to the SRNC, and then the SRNC releases the HSUPA services specified in the message.
3-8
Issue 02 (2010-06-20)
3.7 HSUPA 2ms TTI

The 2ms TTI of HSUPA (WRFD-01061403 HSUPA 2ms TTI) enables a single user to obtain a higher UL throughput and to experience shorter delay. HSUPA has the followingace advantages if a shorter TTI is used on the Uu interface::

Faster data scheduling Higher UL peak data rate Lower latency
There are two Transmission Time Intervals (TTIs) defined in the 3GPP protocol for HSUPA. 10 ms TTI is mandatory for all HSUPA capable UEs while 2 ms TTI is optional. Switching between the two TTIs is performed by UTRAN through L3 signaling. HSUPA 2ms TTI enables UEs to obtain higher uplink throughput with a shorter delay. With this feature, a UE can reach a peak rate of 5.76 Mbit/s over the Uu interface, which is a significant increase compared to the peak rate of 2 Mbit/s achieved with HSUPA 10 ms TTI. HSUPA 2ms TTI has the following impacts:

Slightly decreased access success rate and increased call drop rate Increased received total wideband power (RTWP) due to a high instantaneous rate A higher probability of congestion caused by insufficient credit resources during cell access You are advised to enable switching between HSUPA 2 ms TTI and HSUPA 10 ms TTI to prevent credit congestion.
HSUPA 2 ms TTI has lower power efficiency than HSUPA 10 ms TTI because HSUPA 2 ms TTI has a smaller interleaving gain than HSUPA 10 ms TTI. With the same throughput, HSUPA 2 ms TTI causes a higher RTWP than HSUPA 10 ms TTI. To alleviate the impact of this feature on the access success rate and call drop rate, you are advised to enable the coverage-based BE service fallback from E-DCH to DCH. For details of radio bearer scheme of 2ms TTI, see Radio Bearers Feature Parameter Description. For details of handover between 2ms cells and 10ms cells, see Handover Feature Parameter Description.
3.8 HS-DPCCH Preamble Support

3.8.1 Overview
High-speed dedicated physical control channel (HS-DPCCH) preamble is a feature that enables the transmission of a special preamble subframe before an ACK/NACK subframe on the HS-DPCCH. The HS-DPCCH preamble feature has the following advantages:

Improves transmission reliability Enables the NodeB to distinguish between DTX subframe and ACK/NACK subframe without requiring high ACK/NACK transmit power
The requirements of HS-DPCCH preamble are listed in Table 3-8.
Issue 02 (2010-06-20)
3-9
Table 3-8 Requirements of HS-DPCCH preamble Item CN RNC NodeB UE Requirement None The RNC supports HS-DPCCH preamble. The NodeB supports HS-DPCCH preamble. The UE supports HS-DPCCH preamble.

The HS-DPCCH carries uplink feedback signaling related to downlink HS-DSCH transmission. The signaling consists of Hybrid-ARQ Acknowledgement (HARQ-ACK) and Channel-Quality Indication (CQI). Before the HS-DPCCH preamble feature was introduced, a UE replies with an ACK/NACK if the UE detects a high-speed shared control channel (HS-SCCH). If the UE does not detect any HS-SCCH, it replies with a DTX subframe. To reduce the probability that the NodeB decodes the DTX subframe as an ACK/NACK subframe by mistake, the UE should increase the ACK/NACK transmit power. The HS-DPCCH preamble feature provides an enhanced way to reduce decoding errors. A special preamble is sent before an ACK/NACK on the HS-DPCCH. In this way, the probability of mis-decoding is reduced, because a decoding error can occur only when the NodeB decodes at least two successive timeslots erroneously. As a result, the same performance of the HARQ-ACK field detection function is maintained with lower power. Figure 3-3 HS-DPCCH preamble
To enable this feature, activate the corresponding license without the need of setting the parameters.
3-10
Issue 02 (2010-06-20)
4 HSPA+ Introduced in RAN 11.0

4.1 Overview
HSPA+ (also known as HSPA evolution) is introduced in 3GPP Release 7. It is an enhancement of HSPA, which is introduced in 3GPP Release 6. Compared with HSPA, HSPA+ enhances both uplink and downlink transmission capabilities. Figure 4-1 shows the HSPA+ features in RAN11.0 and the relations among these features. Figure 4-1 Features in RAN11.0 and the relations among these features
The HSPA+ features in RAN11.0 are described in Table 4-1. Table 4-1 HSPA+ features in RAN11.0 Feature Name Downlink enhanced L2 Description Downlink enhanced L2 allows flexible PDU sizes at the RLC layer and segmentation at the MAC layer on the Uu interface. The feature prevents L2 from becoming the bottleneck of Uu rate increasing by multiple-input multiple-output (MIMO) and 64QAM. Downlink MIMO increases transmission rates through spatial multiplexing and improves channel qualities through space diversity. The network side can dynamically select single-stream transmission or dual-stream transmission based on channel conditions. The peak rate at the MAC layer can reach 28 Mbit/s. Downlink 64QAM allows the use of 64QAM in HSDPA to increase the number of bits per symbol and thus to obtain higher transmission rates. The peak rate at the MAC layer can reach 21 Mbit/s. Downlink enhanced CELL_FACH operation allows the use of HSDPA technologies for the UEs in CELL_FACH, CELL_PCH, and URA_PCH states. The purpose is to increase the peak rates in these states, reduce the signaling transmission delay during service setup or state transition, and improve user experience.
Downlink MIMO
Downlink 64QAM Downlink enhanced CELL_FACH operation
Issue 02 (2010-06-20)
4-1
Feature Name CPC
Description Continuous packet connectivity (CPC) allows uplink and downlink transmissions at regular intervals. CPC reduces the transmit power and thus prolongs the UE battery life because the UE does not have to monitor and transmit overhead channels in each TTl. The reduction in the transmit power also helps to increase the uplink capacity by decreasing the total interference. This improvement is significant when users such as VoIP users transmit data discontinuously. The CPC feature consists of DTX-DTX, and HS-SCCH Less Operation.
The impacts of the introduction of HSPA+ in RAN11.0 on power control are as follows:

HS-DPCCH power control is not changed. For details, see the Power Control Feature Parameter Description. HS-SCCH power control in enhanced CELL_FACH state is introduced. For details, see 4.5.5 "Power Control."
For details of the HSPA+ handover, see Handover Feature Parameter Description.
4.2 Downlink Enhanced L2

This section describes the feature WRFD-010685 Downlink Enhanced L2.
4.2.1 Overview
HSPA+ features such as downlink MIMO and downlink 64QAM increase downlink rates on the Uu interface. The original downlink L2 function cannot adapt to such high rates. To prevent L2 from becoming the bottleneck of the network, 3GPP introduces enhancements to L2, including flexible PDU sizes at the RLC layer and segmentation at the MAC layer. This section mainly describes the basic principle and the radio bearer scheme of downlink enhanced L2.

L2 initially used fixed RLC PDU sizes. The typical fixed sizes are 336 bits and 656 bits. They cannot meet the requirement of high-speed transmission for larger RLC PDU sizes or the requirement of edge coverage for smaller RLC PDU sizes. The reasons are as follows:
A small fixed RLC PDU size, together with a limited RLC sending window size, limits the maximum transmission rate at the RLC layer. Figure 4-2 shows a typical example, in which the maximum bit rate (MBR) at the RLC layer is limited to 13.4 Mbit/s. This rate is lower than the peak rates achieved by downlink 64QAM (21 Mbit/s) and downlink MIMO (28 Mbit/s).
Figure 4-2 MBR limited by a fixed PDU size
4-2
Issue 02 (2010-06-20)
A large fixed RLC PDU size limits the cell coverage because the RLC PDU cannot be segmented under the RLC layer.
The enhancements to L2 in the downlink are as follows:

Enhancing the RLC entity to support flexible RLC PDU sizes Adding a MAC entity, that is, the MAC-ehs, for data segmentation at the MAC layer and for multiplexing the queues of different priorities
Figure 4-3 shows the impact of downlink enhanced L2. Figure 4-3 Impact of downlink enhanced L2
After the introduction of flexible RLC PDU sizes, the RLC layer will not segment higher-layer packets whose sizes are smaller than the maximum RLC PDU size. The RLC layer can flexibly adapt to variations in traffic volume and reduce the overhead of the RLC PDU header. The Length Indicator field in an RLC PDU indicates the size of the PDU. This field may consist of 7 or 15 bits. 7 bits are used to transmit a small amount of data; 15 bits are used to transmit large amount of data. For details, see section "Length Indicator (LI)" in 3GPP TS 25.331. After the RLC PDU reaches the MAC layer, the MAC-ehs in the NodeB determines whether to segment this PDU into smaller PDUs based on instantaneous radio conditions. When the channel conditions of the UE are poor (for example, on the cell edge) and the Uu interface fails to transmit an entire RLC PDU, the MAC-ehs can segment the RLC PDU into smaller PDUs for transmission at lower rates to ensure service continuity. For each cell, there is one MAC-ehs entity in the NodeB. For details about the MAC-ehs entity, see section "MAC-ehs entity UTRAN Side" in 3GPP TS 25.321.
4.2.3 Radio Bearers

The RNC determines whether to select downlink enhanced L2 for the UE based on the radio bearer scheme and the capabilities of both the cell and the UE. Downlink enhanced L2 is not selected for the signaling radio bearer (SRB) during the RRC connection setup procedure. The SRB is reconfigured with downlink enhanced L2 if the SRB selects the HS-DSCH
Issue 02 (2010-06-20)
4-3
as the transport channel and the downlink enhanced L2 feature is applied to the traffic radio bearer (TRB). Downlink enhanced L2 can be applied to the SRB even after the TRB is released. During the service setup procedure, downlink enhanced L2 can be selected if the following conditions are met:
Downlink enhanced L2 is supported by both the network and the UE, and it is activated. To activate downlink enhanced L2, select DL_L2ENHANCED of the HspaPlusSwitch parameter. The service type is PS streaming service or PS BE service. The downlink HS-DSCH and uplink E-DCH/DCH are selected as the transport channels.
When downlink enhanced L2 is selected for the UE, the maximum size of downlink PDUs can be specified by the MacPduMaxSizeForDlL2Enhance parameter.
4.3 Downlink MIMO

This section describes the WRFD-010684 22 MIMO feature. HSPA+ uses 2x2 downlink MIMO to increase the single-user throughput and to improve the system performance. Downlink MIMO increases transmission rates through spatial multiplexing and improves channel qualities through space diversity. The peak rate at the MAC layer can reach 28 Mbit/s. Simulation results show that downlink MIMO achieves a relatively low gain in the macro-cell scenario and a relatively high gain in the micro-cell or indoor scenario. Therefore, downlink MIMO is recommended in the micro-cell scenario and the indoor scenario, where the cell should be well isolated from other cells. When the UE uses the Type3 receiver, downlink MIMO can achieve a high gain even in the macro-cell scenario. This type of UE has the equalization reception and interference cancellation functions. Downlink MIMO is an optional feature. A prerequisite for using it is that HSDPA and downlink enhanced L2 are activated. For details, see the MIMO Feature Parameter Description.
4.4 Downlink 64QAM

This section describes the WRFD-010683 Downlink 64QAM feature.
4.4.1 Overview
HSPA+ introduces 64QAM in the downlink. Downlink 64QAM is a new higher-order modulation scheme. Theoretically, downlink 64QAM can provide a peak rate of 21 Mbit/s for a single UE. It enables the UEs with favorable channel conditions to download data at higher rates. It also improves user experience, and increases the competitiveness of the telecom operator. Downlink 64QAM is an optional feature. A prerequisite for using downlink 64QAM is that HSDPA and downlink enhanced L2 are activated. Downlink 64QAM needs support from the CN, RAN, and UE. The requirements of 64QAM are listed in Table 4-2.
4-4
Issue 02 (2010-06-20)
Table 4-2 Requirements of downlink 64QAM Item CN Requirement The CN of 3GPP Release 6 supports 8 Mbit/s in the uplink and 16 Mbit/s in the downlink. To support the peak rate of 21 Mbit/s in downlink 64QAM mode, the CN needs to support 3GPP Release 7. 64QAM depends on downlink enhanced L2, which requires the RNC to support flexible RLC PDU sizes. The RNC also needs to control the use of 64QAM during RB setup, reconfiguration, and handover. NodeB UE The NodeB needs to select a modulation scheme (64QAM or non-64QAM) for every TTI through TFRC selection. The UE needs to support HS-DSCH category 13, 14, 17, 18, 19, or 20.
RNC

High-order modulation significantly increases the data rates of UEs with favorable channel conditions (that is, with high SNRs). Thus, UEs with low SNRs (for example, on the cell edge) can be allocated more resources. As a result, this feature increases the data rates and improves the experience of all users in the cell. AMC introduced in the HSDPA enables adaptation of modulation and coding to varying radio conditions. Figure 4-4 shows the modulation schemes for HSPA+. Figure 4-4 Modulation schemes for HSPA+
As shown in Figure 4-4, the data capacity (unit: bits/symbol) of 16QAM is 2 times that of QPSK. The data capacity of 64QAM is 1.5 times that of 16QAM. Therefore, 64QAM can provide higher transmission rates on the Uu interface. Using the 64QAM mode in the downlink of HSPA+ enables each symbol to carry six bits. In RAN11.0, a UE cannot use MIMO and 64QAM simultaneously. When both of them are supported, the parameter MIMOor64QAMSwitch specifies whether to use MIMO or 64QAM .
Issue 02 (2010-06-20)
4-5
4.4.3 Downlink 64QAM Selection

Overview
Figure 4-5 shows the process of downlink 64QAM selection. Figure 4-5 Process of downlink 64QAM selection
As shown in Figure 4-5, downlink 64QAM selection is determined by the RNC, NodeB, and UE. The selection process is as follows: 2. Based on the traffic class and radio bearer scheme, the RNC determines whether to configure downlink 64QAM for the UE. If the RNC determines to configure downlink 64QAM, it instructs the NodeB to allocate resources for the UE. 3. Based on the CQI, power resource, and code resource, the TFRC selection function of the NodeB determines whether to use downlink 64QAM and notifies the UE of the result through the HS-SCCH in each TTI. For details about TFRC selection, see the HSDPA Feature Parameter Description. This section mainly describes the changes in TFRC selection for downlink 64QAM. 4. The UE uses downlink 64QAM if the NodeB determines to use downlink 64QAM and the UE supports downlink 64QAM. In other words, the RNC determines whether the UE can be configured with downlink 64QAM and the NodeB determines when the UE can use downlink 64QAM.
Radio Bearers
During the service setup procedure, the RNC configures downlink 64QAM for the UE according to the radio bearer scheme. Downlink 64QAM can be selected if the following conditions are met.
Downlink 64QAM and downlink enhanced L2 are supported by the network and the UE, and both of them are activated. To activate downlink 64QAM, select 64QAM of the HspaPlusSwitch parameter, and CFG_HSDPA_64QAM_SWITCH of the CfgSwitch parameter.
4-6
Issue 02 (2010-06-20)
To activate downlink enhanced L2, select DL_L2ENHANCED of the HspaPlusSwitch parameter.

The service type is PS streaming service or PS BE service. The downlink HS-DSCH and uplink E-DCH/DCH are selected as the transport channels. The MIMOor64QAMSwitch parameter is set to 64QAM, or MIMO is not activated.
In the case of combined services, if one of the combined services meets the conditions of applying the downlink 64QAM, the combined services is configured with downlink 64QAM.
TFRC Selection
The TFRC selection function of the NodeB MAC-ehs can dynamically select QPSK, 16QAM, or 64QAM for transmission based on the channel conditions and available transmission resources on the Uu interface. For the UEs with favorable channel conditions, the TFRC selection function applies 64QAM to increase the data rates. For the UEs with unfavorable channel conditions, the TFRC selection function applies QPSK or 16QAM to implement lower-speed transmission and to ensure the transmission quality. The CQI, available power, and number of HS-PDSCH codes have impacts on modulation scheme selection. After a service is set up on the HS-DSCH, the UE has to monitor the HS-SCCHs in each TTI and report CQIs periodically even if there is no data on the HS-DSCH. The data of the UE is scheduled or handled by TFRC only after the NodeB receives the CQIs from the UE. For details about TFRC selection, see the HSDPA Feature Parameter Description.
Modulation Information Transmission Through HS-SCCH

Downlink 64QAM uses HS-SCCH type 1 to transmit HSDPA control information, including the modulation scheme. The HS-SCCH format in downlink 64QAM is similar to that before downlink 64QAM is introduced. The only difference is that the meaning of the modulation scheme field is changed. Before the introduction of 64QAM, the modulation scheme (QPSK or 16QAM) is indicated by the Modulation Scheme Information field of the HS-SCCH. After the introduction of 64QAM, the modulation scheme (QPSK or QAM) is also indicated by the Modulation Scheme Information field. If QAM is selected, the modulation scheme (16QAM or 64QAM) is further indicated by the last bit of the Channelization Code-Set Information field. For details, see section "Coding for HS-SCCH type 1" in 3GPP TS 25.212. Table 4-3 lists the HS-SCCH changes for 64QAM. Table 4-3 HS-SCCH changes for 64QAM HS-SCCH Part 1 Before introduction 64QAM After introduction 64QAM the of the of "Modulation Scheme" Field 0: QPSK 1: 16QAM 0: QPSK 1: QAM Not used 0: 16QAM 1: 64QAM Last Bit of "Channelization Code-Set" Field Not used
Issue 02 (2010-06-20)
4-7
4.5 Downlink Enhanced CELL_FACH Operation

This section describes the WRFD-010688 Downlink Enhanced CELL-FACH Operation feature.
4.5.1 Overview
A UE in connected mode can be in CELL_DCH, CELL_FACH, CELL_PCH, or URA_PCH state. HSPA significantly increases the uplink and downlink peak rates when the UE is in CELL_DCH state. The purpose of Downlink Enhanced CELL_FACH Operation is to allow the use of HSDPA in CELL_FACH, CELL_PCH, and URA_PCH states. The enhancements include flexible allocation of resources, increased data rates, and reduced transmission delays. RAN11.0 does not support HSDPA when UEs are in CELL_PCH or URA_PCH state. Downlink Enhanced CELL_FACH operation is an optional feature. It is dependent on HSDPA and downlink enhanced L2. Downlink Enhanced CELL_FACH operation needs support from the CN, RAN, and UE. The requirements of Downlink Enhanced CELL_FACH operation are listed in Table 4-4. Table 4-4 Requirements of Downlink Enhanced CELL_FACH Operation Item CN RNC Requirement There is no special requirement for the CN. Downlink Enhanced CELL_FACH operation depends on downlink enhanced L2. HSPA+ requires two new states: CELL_DCH (CPC) state and enhanced CELL_FACH state. The RNC needs to implement the state transitions between the two new states and the four legacy states (namely, CELL_DCH (non-CPC), CELL_FACH, CELL_PCH, and URA_PCH). The RNC needs to supplement the power control scheme for the HS-SCCH in enhanced CELL_FACH state. The RNC needs to provide a radio bearer scheme for this HSPA+ feature. NodeB The NodeB needs to consider the data priorities of UEs in enhanced CELL_FACH state during HSDPA scheduling. The NodeB needs to perform flow control to ensure that the bandwidths of UEs in enhanced CELL_FACH state are within a specified range. UE There is no special requirement for the UE.

Figure 4-6 shows the impact of Downlink Enhanced CELL_FACH operation. Figure 4-6 Impact of Downlink Enhanced CELL_FACH operation
4-8
Issue 02 (2010-06-20)
In versions earlier than RAN11.0, the data and signaling of the UE in CELL_FACH state are carried on the FACH. The resources of the channel cannot be allocated flexibly and the transmission rates are limited. In RAN11.0, the data and signaling (originally carried on the DTCH, DCCH, BCCH, and CCCH) of the UE in enhanced CELL_FACH state can be carried on the HS-DSCH. No dedicated physical connection is set up between the UE and the network. Therefore, no HSDPA CQI or HARQ information that is carried on the HS-DPCCH is reported in the uplink. The RNC sends the pilot measurement information (reported by the UE on the RACH) to the NodeB for HSDPA scheduling and resource allocation. The UE does not report whether the data is correctly received, and therefore the NodeB performs blind retransmissions of HSDPA data in the downlink to reduce the block error rate (BLER). The cell that supports Downlink Enhanced CELL_FACH operation needs to broadcast the HSDPA-related information that is commonly used in enhanced CELL_FACH state. To ensure the backward compatibility, the cell also needs to be configured with the FACH if some UEs in the cell do not support Downlink Enhanced CELL_FACH operation. Downlink Enhanced CELL_FACH operation can be widely used on the network. It increases the data rates of the UE in enhanced CELL_FACH state, greatly reduces the state transition delay, and improves the "always-on" experience of users. Downlink Enhanced CELL_FACH operation is an optional feature. It is dependent on HSDPA and downlink enhanced L2.
4.5.3 Radio Bearers

During the RRC connection setup procedure, the SRB is set up in enhanced CELL_FACH state if the EFachSwitch parameter is set to ON. Otherwise, the SRB is set up in CELL_DCH or CELL_FACH state. During the service setup procedure for PS streaming service or PS BE service, Downlink Enhanced CELL_FACH operation can be selected if the following conditions are met:
Downlink Enhanced CELL_FACH operation and downlink enhanced L2 are supported by the network and the UE, and both of them are activated. To activate downlink enhanced L2, select DL_L2ENHANCED of the HspaPlusSwitch parameter. To activate Downlink Enhanced CELL_FACH operation,
For For
the PS streaming service, select MAP_PS_STREAM_ON_E_FACH_SWITCH of the MapSwitch parameter the PS BE service, select MAP_PS_BE_ON_E_FACH_SWITCH of the MapSwitch parameter
During the RRC connection setup procedure, the SRB is set up in enhanced CELL_FACH state. The UE state transition function takes effect. For details, see the State Transition Feature Parameter Description. The downlink HS-DSCH is selected as the transport channel.
Downlink Enhanced CELL_FACH operation is selected when downlink FACH and uplink RACH are selected as the transport channels. If Downlink Enhanced CELL_FACH operation is selected for a UE, the RNC does not select other HSPA+ features for the UE. In the case of combined services, if the services already set up for the UE are all in the enhanced CELL_FACH state, the new service can also be set up in the enhanced CELL_FACH state. Otherwise, the new service cannot be set up in the enhanced CELL_FACH state.
Issue 02 (2010-06-20)
4-9
4.5.4 State Transition

After the RRC connection is set up, the RNC observes the UE activity and determines whether to trigger UE state transition. This section describes the new functions of state transition introduced in HSPA+. HSPA+ requires two new states: CELL_DCH (CPC) state and enhanced CELL_FACH state. The CELL_DCH (CPC) state corresponds to the CELL_DCH state with CPC activated, and the enhanced CELL_FACH state corresponds to the CELL_FACH state with Downlink Enhanced CELL_FACH operation activated. Figure 4-7 shows the new types of state transitions introduced in HSPA+. Figure 4-7 New types of state transitions introduced in HSPA+
These state transitions are triggered by the event 4A or event 4B. The corresponding functions are the same as those for the state transitions between CELL_DCH and CELL_FACH, except that some new parameters are introduced. For details about state transition, see the State Transition Feature Parameter Description. The only impact of the following new state transitions is that new timers to trigger event 4B are introduced:
CELL_DCH (CPC) to CELL_FACH state transition The new timers are as follows:
BeCpc2FStateTransTimer: RtCpc2FStateTransTimer:
BE service state transition timer (CPC_HS-DSCH to F/RACH) real-time service state transition timer (CPC_HSPA to F/RACH)
CELL_DCH to enhanced CELL_FACH state transition The new timers are as follows:
BeD2EFachStateTransTimer: BeH2EFachStateTransTimer:
BE service state transition timer (DCH to E_FACH) BE service state transition timer (HS-DSCH to E_FACH) real-time service state transition timer (DCH or HSPA to E_FACH)
RtDH2EFachStateTransTimer:
CELL_DCH (CPC) to enhanced CELL_FACH state transition The new timers are as follows:
BeCpc2EFachStateTransTimer: RtCpc2EFachStateTransTimer:
BE service state transition timer (CPC_HS-DSCH to E_FACH) real-time service state transition timer (CPC_HSPA to E_FACH)
Issue 02 (2010-06-20)
4-10
The only impact of the following new state transitions is that new timers and thresholds to trigger 4A are introduced:
CELL_FACH to CELL_DCH (CPC) state transition The new thresholds are as follows:
BeF2CpcHTvmThd: RtF2CpcTvmThd:
event 4A threshold for BE service state transition (F/RACH to CPC_HS-DSCH) event 4A threshold for BE service state transition (F/RACH to CPC_E-DCH) event 4A trigger time for BE service state transition (F/RACH to
event 4A threshold for real-time service state transition (F/RACH to CPC_HSPA)
BeF2CpcETvmThd:
The new timers are as follows:

BeF2CpcHTvmTimeToTrig:
CPC_HS-DSCH)
RtF2CpcTvmTimeToTrig:
event 4A trigger time for real-time service state transition (F/RACH to event 4A trigger time for real-time service state transition (F/RACH to
CPC_HSPA)
BeF2CpcETvmTimeToTrig:
CPC_E-DCH)
Enhanced CELL_FACH to CELL_DCH state transition The new thresholds are as follows:
BeEFach2DTvmThd: BeEFach2HTvmThd:
event 4A threshold for BE service state transition (E_FACH to DCH) event 4A threshold for BE service state transition (E_FACH to HS-DSCH) event 4A threshold for real-time service state transition (E_FACH to DCH or
RtEFach2DHTvmThd:
HSPA) The new timers are as follows:

BeEFach2DTvmTimeToTrig: BeEFach2HTvmTimeToTrig:
event 4A trigger time for BE service state transition (E-FACH to DCH) event 4A trigger time for BE service state transition (E_FACH to event 4A trigger time for real-time service state transition (E_FACH to
HS-DSCH)
RtEFach2DHTvmTimeToTrig:
DCH/HSPA)
Enhanced CELL_FACH to CELL_DCH (CPC) state transition The new thresholds are as follows:
BeEFach2CpcTvmThd:
event 4A threshold for BE service state transition (E_FACH to event 4A threshold for PS real-time service state transition (E_FACH to
CPC_HS-DSCH)
RtEFach2CpcTvmThd:
CPC_HSPA) The new timers are as follows:

BeEFach2CpcTvmTimeToTrig:
event 4A trigger time for BE service state transition (E_FACH to event 4A trigger time for real-time service state transition (E_FACH
CPC_HS-DSCH)
RtEFach2CpcTvmTimeToTrig:
to CPC_HSPA) The function of the state transitions between enhanced CELL_FACH and CELL_PCH is the same as that of the state transitions between CELL_FACH and CELL_PCH.
4.5.5 Power Control

When the UE is in enhanced CELL_FACH state, its data and control information can be transmitted through the HS-PDSCH and HS-SCCH. The UE in enhanced CELL_FACH state has no dedicated connection with the physical layer of the NodeB, and the UE does not report the CQI, ACK, or NACK to the NodeB. Therefore, the function of HS-SCCH power control needs to be modified.
Issue 02 (2010-06-20)
4-11
When the UE is in enhanced CELL_FACH state and the HS-PDSCH carries the BCCH, the HS-SCCH power is determined by the offset relative to the P-CPICH power. The offset is specified by the BcchHsscchPower parameter. When the UE is in enhanced CELL_FACH state and the HS-PDSCH carries the user data, the power control method for the HS-SCCH can be fixed or CQI-based, corresponding to fixed transmit power control or dynamic transmit power control respectively. The method is specified by the HsScchPwrCMInEfach parameter.
Fixed
transmit power control: The HS-SCCH power is determined by the offset relative to the P-CPICH power. The offset is specified by the BcchHsscchPower parameter. transmit power control: The NodeB converts the measured CPICH Ec/No into a CQI. The transmit power of the HS-SCCH can be estimated based on the CQI.
Dynamic
Because there is no corresponding interface for the UE to report the measured CPICH Ec/No to the NodeB, the UE obtains the measured CPICH Ec/No and reports the value to the RNC, and then the RNC assigns the measured CPICH Ec/No to the NodeB over the HS-DSCH.
4.5.6 Scheduling
Scheduling determines the users for data transmission in each TTI on the Uu interface and selects them in a certain order to provide good user experience and high system capacity. The data of the UE in enhanced CELL_FACH state, which is carried on the BCCH, CCCH, DCCH, or DTCH, has higher scheduling priority than the data of the UE in CELL_FACH state. The data carried on the BCCH is system information, and therefore it has the highest scheduling priority during initial transmission and retransmission. The UE in enhanced CELL_FACH state does not report ACK, NACK, or CQI in the uplink. The HARQ processes of the UE use the blind retransmission mechanism. The maximum number of retransmissions for the UE in enhanced CELL_FACH state is specified by the MaxEfachHarqRt parameter. Note that in the current version, the UE capability of the user in enhanced CELL_FACH state is regarded as HS-DSCH category 12 during the scheduling. For details about scheduling, see the HSDPA Feature Parameter Description.
4.5.7 Flow Control

HSPA+ flow control is used to control HSPA+ data flows on the Iub and Iur interfaces. After the introduction of flexible RLC PDU sizes in downlink enhanced L2, both data frames and control frames in flow control are changed in frame formats. HSPA+ uses new data frames and capacity allocation control frames to enable the Iub and Iur interfaces to handle higher rates on the Uu interface. The transmission quality and efficiency in enhanced CELL_FACH state are lower than those in CELL_DCH state. Therefore, when the UE in enhanced CELL_FACH state has large amount of data to transmit, it should be switched to the CELL_DCH state immediately. For this purpose, flow control of HSDPA UEs in enhanced CELL_FACH state is introduced in HSPA+. The basic procedure of the flow control is described as follows: The MAC-d in the RNC sends the data of the UEs to the MAC-c common queues within the RNC. Then, the MAC-c in the RNC sends the data to the MAC-ehs common queues at the NodeB through the Iub interface. The NodeB calculates the capacity for each of the MAC-c common queues based on the rate at the exit of each MAC-ehs common queue. In addition, the NodeB configures the highest bit rate for each MAC-c stream to avoid overflow of the MAC-c common queues in case of Iub congestion. Thus, the MAC-c ensures that the total amount of data sent by all its UEs in enhanced CELL_FACH state does
4-12
Issue 02 (2010-06-20)
not exceed the capacity allocated to the MAC-c common queues or the highest bit rates configured for the MAC-c common queues. The state transition from enhanced CELL_FACH to CELL_DCH is performed by the RNC mainly based on the RLC buffer occupancy. Therefore, the bandwidth allocated to the UE in enhanced CELL_FACH state should not be too high. If the bandwidth is too high, the data in the RLC buffer cannot reach the threshold or trigger the transition to the CELL_DCH state. On the other hand, the bandwidth allocated to the UE in enhanced CELL_FACH state should not be too low. If the bandwidth is too low, the RRC signaling delay increases. Each UE in enhanced CELL_FACH state is allocated the bandwidth specified by the BandWidthForFACH parameter. The amount of data sent to the UE cannot exceed this fixed bandwidth. In addition, differentiated services can be provided by allocating different bandwidths based on service types and user priorities.
4.6 CPC DTX-DRX

This section describes the WRFD-010686 CPC-DTX/DRX feature.
4.6.1 Overview
DTX-DRX consists of the DTX (Discontinuous Transmission of the uplink DPCCH) and the DRX (Discontinuous Reception of the downlink HS-SCCH). The feature of DTX-DRX allows a UE to discontinuously receive and transmit signal and thus reduces the uplink interference and prolongs the UE battery life. DTX-DRX needs support from the RAN, and UE. The requirements of DTX-DRX are listed in Table 4-5. Table 4-5 Requirements of DTX-DRX Item CN RNC Requirement None The RNC also needs to control the use of DTX-DRX during RB setup, reconfiguration, and handover. The RNC needs to support the configuration of the DTX-DRX transmission pattern. NodeB The NodeB needs to support the HS-SCCH type 2. The NodeB scheduler needs to determine finally whether to use this feature in transmission if a UE is configured with the feature. UE The UE needs to support the feature.

Uplink DTX
The uplink DTX function allows a UE to stop transmission on the uplink DPCCH when there is no data for transmission. As a result, uplink interference is reduced. Uplink DTX is of importance for services such as VoIP and web browsing, with intermittent data transmission. Figure 4-8 shows the impact of uplink DTX.
Issue 02 (2010-06-20)
4-13
Figure 4-8 Impact of uplink DTX
The basic principle of uplink DTX is that the UE automatically stops transmitting the DPCCH to reduce the interference from the DPCCH when there is no data transmitted on the E-DCH. Then, the UE regularly transmits a DPCCH burst in a UE DTX cycle to maintain power control signaling and link synchronization. Note that if the E-DCH data is transmitted continuously, the DPCCH has to be transmitted and DTX becomes unavailable.
Downlink DRX
The UE in connected mode needs to listen to the control channel (HS-SCCH) continuously and therefore power consumption is high. If downlink DRX is used, the UE needs to receive the HS-SCCH only at some time points. Figure 4-9 shows the impact of downlink DRX. Figure 4-9 Impact of downlink DRX
Downlink DRX depends on uplink DTX. Thus, downlink DRX can be activated only after uplink DTX is activated. Downlink DRX, together with uplink DTX, allows the UE to periodically shut down the TX and RX function in the UE, thus lowering the UE battery consumption and prolonging the UE battery life.
HS-SCCH Order
In 3GPP release 7, HS-SCCH order is introduced and carried on HS-SCCH type 1 and HS-SCCH type 3. Bit fields on HS-SCCH are fixed to a value to indicate a specific HS-SCCH order. After the RNC configure a UE with DTX-DRX, the NodeB can activate/deactivate DTX or DRX respectively by sending HS-SCCH order to this UE.
4.6.3 Radio Bearers

CPC DTX-DRX is an optional feature. A prerequisite for using CPC is that HSDPA, HSUPA, and SRB over HSPA are activated.
4-14
Issue 02 (2010-06-20)

The DCH is not configured in the uplink or downlink. The E-DCH is configured in the uplink, and the HS-DSCH and F-DPCH are configured in the downlink. Signaling and data are carried on HSPA channels. Therefore, CPC is dependent on SRB over HSDPA and SRB over HSUPA.
DTX/DRX can be selected if the following conditions are met:
DTX/DRX is supported by the network and the UE, and it is activated. To activate DTX/DRX, select DTX_DRX of the HspaPlusSwitch parameter, and CFG_HSPA_DTX_DRX_SWITCH of the CfgSwitch parameter.
The SRB is carried on HS-DSCH for the downlink and E-DCH for the uplink. For details, see the Radio Bearers Feature Parameter Description. The service type is CS voice over HSPA service, PS voice service, PS streaming service, or PS BE service. The downlink HS-DSCH and uplink E-DCH are selected as the transport channels.
4.6.4 Transmission Pattern

For details of the transmission pattern, see 3GPP 25.214. There are two UE DTX cycles, namely cycle 1 and cycle 2. Generally, the UE uses cycle 1 for uplink DTX. If the UE has no data to transmit for a long time, the UE uses cycle 2 for uplink DTX. At the beginning of each cycle, the UE sends a DPCCH burst. One burst may consist of one, two, or five subframes. Figure 4-10 Switching between cycle 1 and cycle 2
Figure 4-10 shows the switching between the two UE DTX cycles. The telecom operator can set cycle-related information by using the SET UDTXDRXPARA command for different services to increase the system capacity while ensuring QoS. The parameters are listed in the following table. Parameter MacDtxCycle InactThsForCycle2 Description This parameter specifies the DTX cycle at the MAC layer when the MAC layer supports UL EDCH inactivity. If data is not transmitted on the EDCH for several consecutive EDCH TTIs, the interval at which two consecutive patterns are transmitted on the UL DPCCH should be changed from DtxCycle1 to DtxCycle2. If the interval at which two consecutive patterns are transmitted on the UL DPCCH is DtxCycle2, a certain number of timeslots should be transmitted before data is transmitted on the DPCCH. This parameter specifies the period during which the EDCH is not activated.
DtxLongPreamble
MacInactiveThreshold
Issue 02 (2010-06-20)
4-15
Parameter DpcchBurst1 DpcchBurst2
Description This parameter specifies the number of consecutive subframes that can be transmitted on the UL DPCCH during one DtxCycle1. This parameter specifies the number of consecutive subframes that can be transmitted on the UL DPCCH during one DtxCycle2.
The telecom operator can adjust the DRX cycles by running the SET UDTXDRXPARA command to meet the requirements of the UE. The parameters are listed in the following table. Parameter Drxvalid DrxCycle InactThsForDrxCycle Description This parameter specifies whether the parameters related to the DRX are valid. This parameter specifies the size of patterns that can be received on the HS-SCCH. This parameter specifies the number of consecutive subframes that the UE should monitor on each HS-SCCH of the HS-SCCH set immediately after the data reception on the HS-SCCH or HS-PDSCH. This parameter specifies the CQI feedback cycle in DTX-DRX mode.
CQIFbCkinInDTXDRXmode
4.7 CPC HS-SCCH Less Operation

This section describes the WRFD-010687 CPC-HS-SCCH Less operation feature.
4.7.1 Overview
In the case of HSDPA, the overhead of the HS-SCCH is relatively high for small-packet services such as VoIP, and the power consumption of the HS-SCCH may be higher than that of a traffic channel. In addition, the HS-SCCH limits the maximum number of HSDPA users that can be scheduled in each TTI. This results in increasing transmission delay and decreasing user capacity of delay-sensitive services. The CPC HS-SCCH Less Operation feature allows the initial transmission with a small amount of data to take place without the HS-SCCH. Retransmission still requires the HS-SCCH. Thus, HS-SCCH Less Operation reduces the power consumption and occupation of the HS-SCCH during downlink transmission, allows more services to be scheduled at the same time, and improves the system capacity. The HS-SCCH Less Operation needs support from the RAN, and UE. The requirements of HS-SCCH Less Operation are listed in Table 4-6. Table 4-6 Requirements of HS-SCCH Less Operation Item CN Requirement None
4-16
Issue 02 (2010-06-20)
Item RNC
Requirement The RNC also needs to control the use of HS-SCCH Less Operation during RB setup, reconfiguration, and handover. RNC needs to configure all the data and signaling to the HSPA channel. DCHs are not allowed with CPC.
NodeB
The NodeB needs to support the HS-SCCH type 2. The NodeB scheduler needs to decide finally whether to use this feature in transmission if a UE is configured with the feature.
UE
The UE needs to support the feature.

Overview
Figure 4-11 shows the principle of HS-SCCH Less Operation. Figure 4-11 impact of HS-SCCH Less Operation
Initial transmission
For the initial transmission, the NodeB does not send the HS-SCCH to the UE. The NodeB adds the UE ID to the CRC information on the HS-DSCH and thus the UE can identify its data. Then, the UE decodes the data block on the HS-PDSCH. The UE is required to respond with ACK after receiving correct data, but it need not respond with NACK in other cases. There is no control information during the initial transmission. Therefore, a predefined set of transport block sizes are used in the downlink, and the UE receives the data through blind detection. In the case of HS-SCCH Less Operation, four predefined transport block sizes and QPSK modulation can be used for transmission. The peak rate is limited to 742 kbit/s. The telecom operator can set the predefined transport block sizes by using the SET UHSSCCHLESSOPPARA command for different services
Retransmission
If the NodeB does not receive ACK from the UE after the initial transmission, it retransmits the data through the HS-DSCH and the control information through the HS-SCCH. Whether the retransmitted
Issue 02 (2010-06-20)
4-17
data is received is reported by the UE through ACK or NACK. A maximum of two retransmissions are allowed. The RAN determines whether to use HS-SCCH Less Operation based on downlink traffic volume.
HS-PDSCH
The CRC process is changed to support the feature. When the HS-SCCH Less Operation is applied, the NodeB does not transmit HS-SCCH. For UE to identify the transmission on HS-PDSCH, the NodeB adds the UE ID information to the CRC of HS-DSCH block.
HS-SCCH Type 2
To implement HS-SCCH Less Operation, a new HS-SCCH frame type, that is, HS-SCCH type 2, is introduced. HS-SCCH type 2 carries the information about retransmission, such as the transport block size, pointer to the previous transmission, and number of retransmissions. For details, see section "Coding for HS-SCCH type 2" in 3GPP TS 25.212. The comparison of HS-SCCH type 1 and type 2 is listed in the following table. Bit 1-7 Part 1 HS-SCCH Type 1 HS-SCCH Type 2 CCS CCS MS MS 8 9-14 Part 2 TBS Type HAP TBS Index Pointer RV ReTX ND Reserve 15 16 17 18 19 20 21
The coding method of part 1 is not changed, but the code number indicated by CCS is limited to one or two. The MS is fixed to 0, which means the modulation is fixed to QPSK. The coding method of part 2 is changed to provide additional signaling to support HS-SCCH Less Operation.

Type field is fixed to a value so that a UE can identify the HS-SCCH type 2. TBS index is used to indicate one of the four pre-configured TBS. Pointer is used to indicate the previously transmitted position to assist soft combination. ReTX is used to indicate the transmission times. Reserve bit is not used.
4.7.3 Radio Bearers

CPC DTX-DRX is an optional feature. A prerequisite for using CPC is that HSDPA, HSUPA, and SRB over HSPA are activated.

The DCH is not configured in the uplink or downlink. The E-DCH is configured in the uplink, and the HS-DSCH and F-DPCH are configured in the downlink. Signaling and data are carried on HSPA channels. Therefore, CPC is dependent on SRB over HSDPA and SRB over HSUPA.
HS-SCCH Less Operation can be selected if the following conditions are met:
HS-SCCH Less Operation is supported by the network and the UE, and it is activated.
4-18
Issue 02 (2010-06-20)
To activate HS-SCCH Less Operation, select HS_SCCH_LESS_OPERATION of the HspaPlusSwitch parameter, and CFG_HSPA_HSSCCH_LESS_OP_SWITCH of the CfgSwitch parameter.

The SRB is carried on HS-DSCH for the downlink and E-DCH for the uplink. For details, see the Radio Bearers Feature Parameter Description. The service type is CS voice over HSPA service, PS voice service, PS streaming service, or PS BE service. The downlink HS-DSCH and uplink E-DCH are selected as the transport channels.
HS-SCCH Less Operation and MIMO cannot be used simultaneously. MIMO takes precedence over HS-SCCH Less Operation. Therefore, HS-SCCH Less Operation cannot be selected if MIMO is selected.
Issue 02 (2010-06-20)
4-19
5 HSPA+ Introduced in RAN12.0

5.1 Overview
Figure 5-1 shows the dependencies among HSPA+ features in RAN12.0. Figure 5-1 Feature dependencies
The HSPA+ features in RAN12.0 are described in Table 5-1. Table 5-1 HSPA+ features in RAN12.0 Feature Name Downlink MIMO with 64QAM DC-HSDPA Feature Description Downlink MIMO with 64QAM enables a UE to use MIMO and 64QAM simultaneously to receive HSDPA data. With this technology, the theoretical downlink peak rate can reach 42 Mbit/s. DC-HSDPA allows a UE to set up HSDPA connections with two inter-frequency time-synchronous cells that have the same coverage. Theoretically, DC-HSDPA with 64QAM can provide a peak rate of 42 Mbit/s in the downlink. Uplink enhanced L2 allows flexible PDU sizes at the RLC layer and segmentation at the MAC layer on the Uu interface. The feature improves the uplink transmission efficiency. Uplink 16QAM modulates 4 bits/symbol whereas the original QPSK modulates only 2 bits/symbol. As a result, it doubles the rate to 11.5 Mbit/s at the physical layer.
Uplink Enhanced L2 Uplink 16QAM
As shown in Table 5-1, with the 2*2MIMO+64QAM or 64QAM+DC HSDPA technologies introduced in R8 and the enhanced performance of relevant NEs, the peak downlink rate per user reaches up to 42 Mbit/s (WRFD-010689 HSPA+ Downlink 42Mbps per User). TCP protocol is widely used in data transmission. When a file is being downloaded, the TCP acknowledgement is sent in uplink. The higher the rate of download is, the larger the bandwidth is required in uplink. If the download rate reaches up to 42Mbit/s, the rate of TCP acknowledgement in uplink is much higher than 384kbit/s, which is the highest rate supported by DCH. HSUPA bearer is
Issue 02 (2010-06-20)
5-1
required to provide high bandwidth in uplink to transmit TCP acknowledgement in time. Therefore, downlink 42Mbit/s per user can be supported only if HSUPA is used.
5.2 Downlink MIMO with 64QAM

This section describes the WRFD-010693 DL 64QAM+MIMO feature.
5.2.1 Overview
The MIMO and 64QAM technologies are introduced in 3GPP Release 7. A single UE, however, cannot use these two technologies simultaneously. To further increase the downlink rate, 3GPP Release 8 introduces downlink MIMO with 64QAM (also known as MIMO+64QAM). With this technology, the theoretical downlink peak rate can reach 42 Mbit/s. Downlink MIMO with 64QAM is an optional feature, which is subject to the license. Downlink MIMO with 64QAM needs support from the CN, RAN and UE. The requirements of downlink MIMO with 64QAM are listed in Table 5-2. Table 5-2 Requirements of downlink MIMO with 64QAM Item CN RNC Requirement The CN needs to support the downlink peak rate of 42Mbit/s provided by downlink MIMO with 64QAM. The RNC needs to support downlink enhanced L2, on which downlink MIMO with 64QAM depends. The RNC also needs to control the use of downlink MIMO with 64QAM during RB setup, reconfiguration, and handover. NodeB The NodeB needs to support downlink MIMO, downlink 64QAM, and downlink enhanced L2. The TFRC selection function and scheduler of the NodeB use the new CQI mapping tables for UE categories 19 and 20. The MIMO technology uses HS-SCCH type 3. The coding method for HS-SCCH type 3 remains unchanged but some IEs are extended. UE The UE needs to support HS-DSCH category 19 or 20.
The following sections describe the basic principle, radio bearer scheme, and scheduling method of downlink MIMO with 64QAM.

Overview
Downlink MIMO with 64QAM enables a UE to use MIMO and 64QAM simultaneously to receive HSDPA data, as shown in Figure 5-2. In other words, downlink 64QAM is used in downlink MIMO mode to increase the number of bits per symbol and to obtain higher transmission rates.
5-2
Issue 02 (2010-06-20)
Figure 5-2 Principle of downlink MIMO with 64QAM
For details, see sections 4.3 "Downlink MIMO" and 4.4 "Downlink 64QAM."
HS-SCCH Type 3 for Downlink MIMO with 64QAM

HS-SCCH type 3 indicates the modulation scheme by a 3-bit field for downlink MIMO with 64QAM, as it does for dual-stream transmission in downlink MIMO. The used values 101, 010, and 001 are described in the following table. Modulation Scheme 101 010 001 Primary TB 64QAM 64QAM 64QAM Secondary TB Number of TBs
Indicated by the last bit of CCS Indicated by the last bit of CCS 64QAM 16QAM 2 2
When the three bits are 101, the modulation scheme for the secondary transport block (TB) and the transmission mode are indicated by the last bit of Channelization-Code-Set (CCS):

If the last bit of CCS is 0, the number of TBs is 2 (that is, the transmission mode is dual-stream mode) and the modulation scheme for the secondary TB is QPSK. If the last bit of CCS is 1, the number of TBs is 1 (that is, the transmission mode is single-stream mode).
5.2.3 Radio Bearer Scheme

As defined in 3GPP R8 specifications, a UE cannot use downlink MIMO and DC-HSDPA simultaneously. When both are supported, whether downlink MIMO with 64QAM or DC-HSDPA is used depends on the MIMO64QAMorDCHSDPASwitch parameter. In addition, downlink MIMO with 64QAM and HS-SCCH Less Operation cannot be used simultaneously. When both are supported, downlink MIMO with 64QAM is preferred. During the setup of a PS streaming service or PS BE service, downlink MIMO with 64QAM can be selected if the following conditions are met:

Downlink MIMO, downlink 64QAM, downlink MIMO with 64QAM, and downlink enhanced L2 are supported by both the network and the UE, and all of them are activated. The downlink HS-DSCH and uplink E-DCH/DCH are selected as transport channels. The parameter HspaPlusSwitch is set to 64QAM_MIMO. The parameter CfgSwitch is set to CFG_MIMO_AND_64QAM_SWITCH.
Issue 02 (2010-06-20)
5-3
The parameter MIMO64QAMorDCHSDPASwitch is set to MIMO_64QAM, or DC-HSDPA is not activated.
5.2.4 Scheduling Method

The UE needs to monitor all the HS-SCCHs in the cell. The maximum number of HS-SCCHs per cell is 4. The NodeB scheduler can select any HS-SCCH for the UE. The scheduling method of downlink MIMO with 64QAM is the similar to that of downlink MIMO. The difference is that the scheduler needs to use the new CQI mapping tables F, G, J, and K to perform TFRC. Table 5-3 CQI mapping table for downlink MIMO with 64QAM HS-DSCH Category Used CQI Mapping Table In case of type B or single transport block type A CQI reports 19 20 F G In case of dual transport block type A CQI reports J K
For details about the CQI mapping table, see 3GPP TS 25.214.
5.3 DC-HSDPA
Figure 5-3 shows the basic principle of DC-HSDPA. Figure 5-3 Basic principle of DC-HSDPA
To further increase the UE throughput, DC-HSDPA is introduced in 3GPP Release 8. Theoretically, DC-HSDPA with 64QAM can provide a peak rate of 42 Mbit/s in the downlink. This rate becomes the double of the peak rate obtained when only 64QAM is used. DC-HSDPA allows a UE to set up HSDPA connections with two inter-frequency time-synchronous cells that have the same coverage. In the two cells, the UE can be scheduled at the same time; it can also receive different data through the two carriers at the same time. In the uplink, however, the UE sends data only through its anchor carrier. For details, see the DC-HSDPA Feature Parameter Description.
5.4 Uplink Enhanced L2

This section describes the feature WRFD-010695 UL Layer 2 Improvement.
5-4
Issue 02 (2010-06-20)
5.4.1 Overview
Uplink enhanced L2 allows flexible PDU sizes at the RLC layer and segmentation at the MAC layer on the Uu interface. The feature improves the uplink transmission efficiency. Uplink enhanced L2 is an optional feature, which is subject to the license. Uplink enhanced L2 needs support from the CN, RAN, and UE. The requirements of uplink enhanced L2 are listed in Table 5-4. Table 5-4 Requirements of uplink enhanced L2 Item CN RNC Requirement None The RNC needs to provide the bearer scheme for uplink enhanced L2. The RNC needs to upgrade the RLC function to support flexible PDU sizes. A new sublayer, MAC-is, is introduced to replace the MAC-es. NodeB UE A new sublayer, MAC-i, is introduced to replace the MAC-e. The UE needs to support E-DCH category 7.
The following sections describe the basic principle and radio bearer scheme of uplink enhanced L2.

In RAN11.0 or earlier, the uplink RLC operates only in fixed PDU mode. In this mode, the size of PDUs never changes. Large fixed-size PDUs can support higher rates, but they lead to power limitation on the cell edge. Small fixed-size PDUs can improve network coverage, but excessive encapsulation overheads may be generated, which affects the transmission efficiency. To solve the problems caused by fixed-size PDUs, uplink enhanced L2 is introduced in RAN12.0. Figure 5-4 Basic principle of uplink enhanced L2
The basic principle of uplink enhanced L2, as shown in Figure 5-4, is described as follows:
The RLC supports flexible AM/UM RLC PDU sizes, which meet the requirements for high-speed data transmission and improve the transmission efficiency.
Issue 02 (2010-06-20)
5-5
The MAC-i/is is used at the MAC layer. The MAC-i/is supports data segmentation and concatenation at the MAC layer. It can also select an appropriate PDU size based on the air interface quality to increase the network coverage on the cell edge. The UE cannot use the MAC-i/is and MAC-e/es simultaneously.

Uplink enhanced L2 is dependent on HSUPA. The RNC determines whether to select uplink enhanced L2 for the UE according to the capabilities of both the cell and the UE and the radio bearer scheme. During the RRC connection setup procedure, uplink enhanced L2 is not selected for the signaling radio bearer (SRB). If uplink enhanced L2 is selected for the traffic radio bearer (TRB), it needs to be reconfigured for the SRB. Uplink enhanced L2 is applied to the SRB even after the TRB is released. During the service setup procedure, uplink enhanced L2 can be selected if the following conditions are met:

The service type is CS voice over HSPA service, PS voice service, PS streaming service, or PS BE service. All the links in the active set of the E-DCH support uplink enhanced L2. The uplink E-DCH is selected as the transport channel. The HspaPlusSwitch parameter is set to UL_L2ENHANCED.
When uplink enhanced L2 is selected for the UE, the RLC supports flexible PDU sizes. In this case, the maximum size and minimum size of uplink PDUs must be specified on the RNC side through the following parameters respectively:

RlcPduMaxSizeForUlL2Enhance RlcPduMinSizeForUlL2Enhance
The data in the RLC buffer can be sent even if the amount of data is smaller than the minimum size.
5.5 Uplink 16QAM

This section describes the WRFD-010694 UL 16QAM feature.
5.5.1 Overview
3GPP Release 6 introduces the HSUPA technology, which uses QPSK to increase the uplink peak rate to 5.76 Mbit/s. To further increase the peak rate of HSUPA, 3GPP Release 7 introduces uplink 16QAM. With this technology, the theoretical uplink peak rate of a single HSUPA user can reach 11.5 Mbit/s. Uplink 16QAM is an optional feature, which is subject to the license. Uplink 16QAM needs support from the CN, RAN, and UE. The requirements of uplink 16QAM are listed in Table 5-5. Table 5-5 Requirements of uplink 16QAM Item CN RNC NodeB Requirement The CN needs to support the uplink peak rate provided by uplink 16QAM. The RNC needs to provide the bearer scheme for uplink 16QAM. The NodeB needs to support the modulation scheme and scheduling of uplink 16QAM.
5-6
Issue 02 (2010-06-20)
Item UE
Requirement The UE needs to support E-DCH category 7.
The following sections describe the basic principle, radio bearer scheme, and scheduling method of uplink 16QAM.

Overview
Uplink 16QAM modulates 4 bits/symbol whereas the original QPSK modulates only 2 bits/symbol, as shown in Figure 5-5. As a result, uplink 16QAM doubles the rate to 11.5 Mbit/s at the physical layer. Figure 5-5 Comparison between 16QAM and QPSK
When the channel conditions are favorable, uplink 16QAM has a high gain. It increases the uplink throughput of both the UE and the cell and reduces the uplink transmission delay. However, uplink 16QAM increases the uplink load and noise, and reduces the uplink coverage. Therefore, uplink 16QAM is applicable to micro cells and indoor coverage areas and not applicable to macro cells. As defined in 3GPP TS 25.212, uplink 16QAM is selected only when the sum of TRB rates and SRB rate of all UE services over HSUPA is higher than 4 Mbit/s. Uplink 16QAM uses 2xSF2+2xSF4.
New E-DPDCH Slot Formats

When 16QAM is applied, 4-Pulse Amplitude Modulation (4PAM) is used on each E-DPDCH. Two new E-DPDCH slot formats 8 and 9 are introduced to support 4PAM in the case of SF4 and SF2 respectively, as described in the following table. Slot Format #i 0 1 2 3 4 5 Channel Bit Rate Bits/Symbol (kbps) 15 30 60 120 240 480 1 1 1 1 1 1 SF 256 128 64 32 16 8 Bits/ Frame 150 300 600 1200 2400 4800 Bits/ Subframe Bits/Slot 30 60 120 240 480 960 10 20 40 80 160 320
Issue 02 (2010-06-20)
5-7
Slot Format #i 6 7 8 9
Channel Bit Rate Bits/Symbol (kbps) 960 1920 1920 3840 1 1 2 2
SF 4 2 4 2
Bits/ Frame 9600 19200 19200 38400
Bits/ Subframe Bits/Slot 1920 3840 3840 7680 640 1280 1280 2560
New E-DCH Category

A new E-DCH category 7, as listed in the following table, is introduced to support uplink 16QAM. For details about the table, see 3GPP TS 25.306. E-DCH category Maximum Number of E-DCH Codes Transmitted 1 2 2 2 2 4 4 Minimum Spreading Factor Support for 10 ms or 2 ms TTI EDCH 10 ms TTI only 10 ms and 2 ms TTIs 10 ms TTI only 10 ms and 2 ms TTIs 10 ms TTI only 10 ms and 2 ms TTIs Maximum Number of Bits per E-DCH TB Transmitted Within a 10 ms E-DCH TTI 7110 14484 14484 20000 20000 20000 Maximum Number of Bits per E-DCH TB Transmitted Within a 2 ms E-DCH TTI 2798 5772 11484 22996
Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7
4 4 4 2 2 2 2
10ms and 2 20000 ms TTIs
When four codes are transmitted in parallel, two codes are transmitted with SF2 and the other two with SF4.
Uplink 16QAM has evolved smoothly from HSUPA and does not affect the technical architecture of HSUPA. Only some radio network functions such as radio bearers and mobility management, on the RNC and NodeB need to be upgraded to support uplink 16QAM.

Uplink 16QAM can be selected if the following conditions are met:
The service type is PS streaming service or PS BE service.
5-8
Issue 02 (2010-06-20)

All the links in the active set of the E-DCH support uplink 16QAM. The sum of the TRB rates and SRB rate exceeds 4 Mbit/s. When HSUPA DCCC is enabled, the TRB rates refer to the current rates. When HSUPA DCCC is disabled, the TRB rates refer to the MBRs.
The HspaPlusSwitch parameter is set to UL_16QAM. The CfgSwitch parameter is set to CFG_HSUPA_16QAM_SWITCH.
When fixed PDU sizes are allowed and the PDU size is set to 336 bits, the total rate cannot reach 4 Mbit/s. If a higher TRB rate is required, the PDU size must be set to 656 bits. If uplink enhanced L2 is enabled, the PDU size is not restricted because uplink enhanced L2 supports flexible PDU sizes. The RNC determines whether to select uplink 16QAM for the UE. The NodeB performs MAC-e/i scheduling for the UE and checks whether to allocate resources to the UE for uplink 16QAM. The conditions for selecting uplink 16QAM for combined services are similar to those for selecting uplink 16QAM for a single service. Whether to select uplink 16QAM for combined services depends on the total rate of combined services.
5.5.4 Scheduling Method

The scheduling method of uplink 16QAM is the same as that of HSUPA except that some new tables are introduced. The NodeB needs to use these new tables during scheduling. The new tables are as follows:

E-DCH Transport Block Size Tables 2 and 3, introduced in 3GPP TS 25.321 Scheduling Grant Table 2 (SG-table), introduced in 3GPP TS 25.321 Mapping of Absolute Grant Value, introduced in 3GPP TS 25.212
Issue 02 (2010-06-20)
5-9
6 Parameters
6 Parameters
Table 6-1 Parameter description Parameter NE ID MML Description
BandWidth BSC690 SET Meaning: Maximum available bandwidth for each traffic class ForFACH 0 UFACHBANDWIDT in the E-FACH state. If the actual data flow exceeds the H(Optional) maximum bandwidth, the traffic is buffered so that the buffer occupancy is increased. In this case, the state is changed from E-FACH to CELL-DCH. This parameter needs to be set according to the traffic class. GUI Value Range: 1~1000 Actual Value Range: 1~1000 Unit: kbit/s Default Value: None BcchHsscc BSC690 ADD Meaning: When UE is in Enhanced CELL_FACH state, the hPower 0 UCELLEFACH(Opti data on the BCCH is also sent on the HS-PDSCH. Meanwhile, onal) the HS-SCCH shall send signaling related to HS-PDSCH. This MOD parameter specifies the transmission power of the HS-SCCH UCELLEFACH(Opti at the time. onal) GUI Value Range: -350~150 Actual Value Range: -35~15, step:0.1 Unit: dB Default Value: -30 BeCpc2EF BSC690 SET Meaning: Timer for state transition from CPC to E_FACH of achStateTr 0 UUESTATETRANS BE services, used to check whether the UE in the ansTimer TIMER(Optional) CELL_DCH(with CPC) state with BE services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 5 BeCpc2FSt BSC690 SET Meaning: Timer for state transition from CPC to FACH of BE ateTransTi 0 UUESTATETRANS services, used to check whether the UE in the mer TIMER(Optional) CELL_DCH(with CPC) state with BE services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 5 BeD2EFac BSC690 SET Meaning: Timer for state transition from DCH to E_FACH of hStateTran 0 UUESTATETRANS BE services, used to check whether the UE in the sTimer TIMER(Optional) CELL_DCH(with DCH) state with BE services is in the stable low activity state. GUI Value Range: 1~65535
Issue 02 (2010-06-20)
6-1
6 Parameters
Parameter NE ID
MML
Description Actual Value Range: 1~65535 Unit: s Default Value: 5
BeEFach2 BSC690 SET Meaning: This parameter specifies the threshold of the traffic CpcTvmTh 0 UUESTATETRANS volume of 4A event for triggering the transition of BE services d (Optional) from E_FACH to CPC. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 BeEFach2 BSC690 SET Meaning: This parameter specifies the occurrence time of 4A CpcTvmTi 0 UUESTATETRANS event for triggering the transition of BE services from E_FACH meToTrig (Optional) to CPC. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 BeEFach2 BSC690 SET Meaning: This parameter specifies the threshold of the traffic DTvmThd 0 UUESTATETRANS volume of 4A event for triggering the transition of BE services (Optional) from E_FACH to DCH. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 BeEFach2 BSC690 SET Meaning: This parameter specifies the occurrence time of 4A DTvmTime 0 UUESTATETRANS event for triggering the transition of BE services from E_FACH ToTrig (Optional) to DCH. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0
6-2
Issue 02 (2010-06-20)
6 Parameters
Parameter NE ID
MML
Description
BeEFach2 BSC690 SET Meaning: This parameter specifies the threshold of the traffic HTvmThd 0 UUESTATETRANS volume of 4A event for triggering the transition of BE services (Optional) from E_FACH to HS-DSCH. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 BeEFach2 BSC690 SET Meaning: This parameter specifies the occurrence time of 4A HTvmTime 0 UUESTATETRANS event for triggering the transition of BE services from E_FACH ToTrig (Optional) to HS-DSCH. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 BeF2CpcE BSC690 SET Meaning: This parameter specifies the threshold of the traffic TvmThd 0 UUESTATETRANS volume of 4A event for triggering the transition of BE services (Optional) from FACH to E-DCH with CPC technology. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 BeF2CpcE BSC690 SET Meaning: This parameter specifies the occurrence time of 4A TvmTimeTo 0 UUESTATETRANS event for triggering the transition of BE services from FACH to Trig (Optional) E-DCH with CPC technology. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 BeF2CpcH BSC690 SET Meaning: This parameter specifies the threshold of the traffic
Issue 02 (2010-06-20)
6-3
6 Parameters
Parameter NE ID TvmThd 0
MML
Description
UUESTATETRANS volume of 4A event for triggering the transition of BE services (Optional) from FACH to HS-DSCH with CPC technology. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024
BeF2CpcH BSC690 SET Meaning: This parameter specifies the occurrence time of 4A TvmTimeTo 0 UUESTATETRANS event for triggering the transition of BE services from FACH to Trig (Optional) HS-DSCH with CPC technology. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 BeH2EFac BSC690 SET Meaning: Timer for state transition from HSPA to E_FACH of hStateTran 0 UUESTATETRANS BE services, used to check whether the UE in the sTimer TIMER(Optional) CELL_DCH(with HSPA) state with BE services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 5 CfgSwitch BSC690 SET Meaning: Channel configuration strategy switch. 0 UCORRMALGOS 1) CFG_DL_BLIND_DETECTION_SWITCH: When the switch WITCH(Optional) is on, the DL blind transport format detection function is used for single SRB and AMR+SRB bearers. Note that the UE is only required to support the blind transport format stipulated in 3GPP 25.212 section 4.3.1. 2) CFG_HSDPA_64QAM_SWITCH: When the switch is on, 64QAM can be configured for the HSDPA service. 3) CFG_HSDPA_DC_SWITCH: When the switch is on, DC can be configured for the HSDPA service. 4) CFG_HSDPA_MIMO_SWITCH: When the switch is on, MIMO can be configured for the HSDPA service. 5) CFG_HSDPA_MIMO_WITH_64QAM_SWITCH: When the switch is on and the switches for 64QAM and MIMO are on, 64QAM+MIMO can be configured for the HSDPA service 6) CFG_HSPA_DTX_DRX_SWITCH: When the switch is on, DTX_DRX can be configured for the HSPA service. 7) CFG_HSPA_HSSCCH_LESS_OP_SWITCH: When the
6-4
Issue 02 (2010-06-20)
6 Parameters
Parameter NE ID
MML
Description switch is on, HS-SCCH Less Operation can be configured for the HSPA service. 8) CFG_HSUPA_16QAM_SWITCH: When the switch is on, 16QAM can be configured for the HSUPA service. 9) CFG_IMS_SUPPORT_SWITCH: When the switch is on and the IMS license is activated, the RNC supports IMS signaling. 10) CFG_LOSSLESS_DLRLC_PDUSIZECHG_SWITCH: When the switch is on, DL lossless RLC PDU size change is supported. 11) CFG_LOSSLESS_RELOC_CFG_SWITCH: When the switch is on and the UE supports lossless relocation, the RNC configures lossless relocation for PDCP parameters if the requirements of RLC mode, discard mode, and sequential submission are met. Then, lossless relocation is used for the UE. 12) CFG_MULTI_RAB_SWITCH: When the switch is on, the RNC supports multi-RABs combinations such as 2CS, 2CS+1PS, 1CS+2PS, and 2PS. 13) CFG_PDCP_IPV6_HEAD_COMPRESS_SWITCH: When the switch is on and the PDCP header compression license is activated, the PDCP header compression algorithm for IPv6 is used at the RNC. 14) CFG_PDCP_RFC2507_HC_SWITCH: When the switch is on and the PDCP IPHC license is activated, the PDCP IPHC header compression algorithm is used for the RNC. 15) CFG_PDCP_RFC3095_HC_SWITCH: When the switch is on and the PDCP ROHC license is activated, the PDCP ROHC header compression algorithm is used for the RNC. 16) CFG_PTT_SWITCH: When this switch is on, the RNC identifies the PTT user based on the QoS attributes in the RAB assignment request message. Then, the PTT users are subject to special processing. 17) CFG_RAB_REL_RMV_HSPAPLUS_SWITCH: When this switch is on and if an RAB release is performed, the RNC decides whether to fall back a certain HSPA(HSPA+) feature based on the requirement of remaining traffic carried by the UE. That is, if an HSPA+ feature is required by the previously released RAB connection but is not required in the initial bearer policy of the remaining traffic, the RNC falls back the feature to save the transmission resources. The HSPA+ features that support the fallback are MIMO, 64QAM, MIMO+64QAM, UL 16QAM, DC-HSDPA, and UL TTI 2ms. GUI Value Range: CFG_DL_BLIND_DETECTION_SWITCH, CFG_HSDPA_64QAM_SWITCH, CFG_HSDPA_DC_SWITCH, CFG_HSDPA_MIMO_SWITCH, CFG_HSDPA_MIMO_WITH_64QAM_SWITCH, CFG_HSPA_DTX_DRX_SWITCH, CFG_HSPA_HSSCCH_LESS_OP_SWITCH, CFG_HSUPA_16QAM_SWITCH, CFG_IMS_SUPPORT_SWITCH,
Issue 02 (2010-06-20)
6-5
6 Parameters
Parameter NE ID
MML
Description CFG_LOSSLESS_DLRLC_PDUSIZECHG_SWITCH, CFG_LOSSLESS_RELOC_CFG_SWITCH, CFG_MULTI_RAB_SWITCH, CFG_PDCP_IPV6_HEAD_COMPRESS_SWITCH, CFG_PDCP_RFC2507_HC_SWITCH, CFG_PDCP_RFC3095_HC_SWITCH, CFG_PTT_SWITCH, CFG_RAB_REL_RMV_HSPAPLUS_SWITCH Actual Value Range: CFG_DL_BLIND_DETECTION_SWITCH, CFG_HSDPA_64QAM_SWITCH, CFG_HSDPA_DC_SWITCH, CFG_HSDPA_MIMO_SWITCH, CFG_HSDPA_MIMO_WITH_64QAM_SWITCH, CFG_HSPA_DTX_DRX_SWITCH, CFG_HSPA_HSSCCH_LESS_OP_SWITCH, CFG_HSUPA_16QAM_SWITCH, CFG_IMS_SUPPORT_SWITCH, CFG_LOSSLESS_DLRLC_PDUSIZECHG_SWITCH, CFG_LOSSLESS_RELOC_CFG_SWITCH, CFG_MULTI_RAB_SWITCH, CFG_PDCP_IPV6_HEAD_COMPRESS_SWITCH, CFG_PDCP_RFC2507_HC_SWITCH, CFG_PDCP_RFC3095_HC_SWITCH, CFG_PTT_SWITCH, CFG_RAB_REL_RMV_HSPAPLUS_SWITCH Unit: None Default Value: None
EfachDtch BSC690 ADD Meaning: This parameter specifies the maximum guaranteed Gbp 0 UCELLEFACH(Opti power of the DTCH mapped onto the EFACH. onal) MOD GUI Value Range: -350~150 UCELLEFACH(Opti Actual Value Range: -35~15, step:0.1 onal) Unit: dB Default Value: 10 HspaPlusS BSC690 ADD witch 0 UCELLALGOSWIT CH(Optional) MOD UCELLALGOSWIT CH(Optional) Meaning: If 64QAM,MIMO,E_FACH,DTX_DRX, HS_SCCH_LESS_OPERATION ,64QAM+MIMO, UL16QAM,DC-HSDPA,UL L2ENHANCED and DL L2ENHANCED are selected, the corresponding function will be enabled; otherwise, disabled. GUI Value Range: 64QAM, MIMO, E_FACH, DTX_DRX, HS_SCCH_LESS_OPERATION, DL_L2ENHANCED, 64QAM_MIMO, UL_16QAM, DC_HSDPA, UL_L2ENHANCED Actual Value Range: 64QAM, MIMO, E_FACH, DTX_DRX, HS_SCCH_LESS_OPERATION, DL_L2ENHANCED, 64QAM_MIMO, UL_16QAM, DC_HSDPA, UL_L2ENHANCED Unit: None Default Value: None MacPduMa BSC690 SET UFRC(Optional) xSizeForDl 0 Meaning: This parameter specifies the maximum size of PDUs transmitted at the MAC layer when the UE is in the
6-6
Issue 02 (2010-06-20)
6 Parameters
Parameter NE ID L2Enhance
MML
Description CELL_DCH state in the downlink L2 enhanced scenario. GUI Value Range: 4~1504 Actual Value Range: 4~1504 Unit: byte Default Value: 502
MapSwitch BSC690 SET Meaning: Service mapping strategy switch. 0 UCORRMALGOS 1) MAP_HSUPA_TTI_2MS_SWITCH: When the switch is on, WITCH(Optional) 2 ms TTI is supported for HSUPA. 2) MAP_INTER_RAT_PS_IN_CHANLE_LIMIT_SWITCH: When the switch is on, the PS services are transmitted on the DCH during the 2G-to-3G handover. When the switch is not on, the PS services can be transmitted on suitable channels according to the algorithm parameter configured for the RNC during the 2G-to-3G handover. 3) MAP_PS_BE_ON_E_FACH_SWITCH: When the switch is on, the PS BE services can be transmitted on the E-FACH. 4) MAP_PS_STREAM_ON_E_FACH_SWITCH: When the switch is on, the PS streaming services can be transmitted on the E-FACH. 5) MAP_PS_STREAM_ON_HSDPA_SWITCH: When the switch is on, a PS streaming service is mapped on the HS-DSCH if the DL maximum rate of the service is greater than or equal to the HSDPA threshold for streaming services. 6) MAP_PS_STREAM_ON_HSUPA_SWITCH: When the switch is on, a PS streaming service is mapped on the E-DCH if the UL maximum rate of the service is greater than or equal to the HSUPA threshold for streaming services. 7) MAP_SRB_6800_WHEN_RAB_ON_HSDSCH_SWITCH: When the switch is on, the signaling is transmitted at a rate of 6.8 kbit/s if all the downlink traffic is on the HSDPA channel. GUI Value Range: MAP_HSUPA_TTI_2MS_SWITCH, MAP_INTER_RAT_PS_IN_CHANLE_LIMIT_SWITCH, MAP_PS_BE_ON_E_FACH_SWITCH, MAP_PS_STREAM_ON_E_FACH_SWITCH, MAP_PS_STREAM_ON_HSDPA_SWITCH, MAP_PS_STREAM_ON_HSUPA_SWITCH, MAP_SRB_6800_WHEN_RAB_ON_HSDSCH_SWITCH Actual Value Range: MAP_HSUPA_TTI_2MS_SWITCH, MAP_INTER_RAT_PS_IN_CHANLE_LIMIT_SWITCH, MAP_PS_BE_ON_E_FACH_SWITCH, MAP_PS_STREAM_ON_E_FACH_SWITCH, MAP_PS_STREAM_ON_HSDPA_SWITCH, MAP_PS_STREAM_ON_HSUPA_SWITCH, MAP_SRB_6800_WHEN_RAB_ON_HSDSCH_SWITCH Unit: None Default Value: None MIMO64QA BSC690 SET UFRC(Optional) MorDCHSD 0 PASwitch Meaning: This switch is used to configure the priority of MIMO_64QAM or DC-HSDPA. According to different protocols, the following situations may occur: MIMO and
Issue 02 (2010-06-20)
6-7
6 Parameters
Parameter NE ID
MML
Description DC-HSDPA cannot be used together; both 64QAM and DC-HSDPA are supported, but cannot be used together. In this case, "MIMO64QAMorDCHSDPASwitch" is used to configure the priorities of the features. When the priority of MIMO is higher than that of DC-HSDPA, the priority of 64QAM is higher than that of DC-HSDPA. When the priority of DC-HSDPA is higher than that of MIMO, the priority of DC-HSDPA is higher than that of 64QAM. GUI Value Range: MIMO_64QAM, DC_HSDPA Actual Value Range: MIMO_64QAM, DC_HSDPA Unit: None Default Value: DC_HSDPA
MIMOor64 BSC690 SET QAMSwitch 0 UFRC(Optional)
Meaning: According to the R8 protocol, MIMO and 64QAM can be used together. When the condition is not met, for example the cell does not support the features, MIMO may be not used together with 64QAM. In this case, "MIMOor64QAMSwitch" is used to determine whether MIMO or 64QAM is preferentially used. GUI Value Range: MIMO, 64QAM Actual Value Range: MIMO, 64QAM Unit: None Default Value: MIMO
RlcPduMax BSC690 SET UFRC(Optional) SizeForUlL 0 2Enhance
Meaning: This parameter specifies the maximum RLC PDU size when the UE is in CELL_DCH state and UL Layer 2 Enhanced is enabled. GUI Value Range: 4~402 Actual Value Range: 4~402 Unit: byte Default Value: 302
RlcPduMin BSC690 SET UFRC(Optional) SizeForUlL 0 2Enhance
Meaning: This parameter specifies the minimum RLC PDU size when the UE is in CELL_DCH state and UL Layer 2 Enhanced is enabled. GUI Value Range: 4~402 Actual Value Range: 4~402 Unit: byte Default Value: 42
RtCpc2EFa BSC690 SET Meaning: Timer for state transition from CPC to E_FACH of chStateTra 0 UUESTATETRANS real-time services, used to check whether the UE in the nsTimer TIMER(Optional) CELL_DCH(with CPC) state with real-time services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 180
6-8
Issue 02 (2010-06-20)
6 Parameters
Parameter NE ID
MML
Description
RtCpc2FSt BSC690 SET Meaning: Timer for state transition from CPC to FACH of ateTransTi 0 UUESTATETRANS real-time services, used to check whether the UE in the mer TIMER(Optional) CELL_DCH(with CPC) state with real-time services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 180 RtDH2EFac BSC690 SET Meaning: Timer for state transition from DCH or HSPA to hStateTran 0 UUESTATETRANS E_FACH of real-time services, used to check whether the UE sTimer TIMER(Optional) in the CELL_DCH state with real-time services is in the stable low activity state. GUI Value Range: 1~65535 Actual Value Range: 1~65535 Unit: s Default Value: 180 RtEFach2C BSC690 SET Meaning: This parameter specifies the threshold of the traffic pcTvmThd 0 UUESTATETRANS volume of 4A event for triggering the transition of real-time (Optional) services from E_FACH to HSPA with CPC technology. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 RtEFach2C BSC690 SET Meaning: This parameter specifies the occurrence time of 4A pcTvmTime 0 UUESTATETRANS event for triggering the transition of real-time services from ToTrig (Optional) E_FACH to HSPA with CPC technology. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 RtEFach2D BSC690 SET Meaning: This parameter specifies the threshold of the traffic HTvmThd 0 UUESTATETRANS volume of 4A event for triggering the transition of real-time (Optional) services from E_FACH to DCH or HSPA. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k
Issue 02 (2010-06-20)
6-9
6 Parameters
Parameter NE ID
MML
Description Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024
RtEFach2D BSC690 SET Meaning: This parameter specifies the occurrence time of 4A HTvmTime 0 UUESTATETRANS event for triggering the transition of real-time services from ToTrig (Optional) E_FACH to DCH or HSPA. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 RtF2CpcTv BSC690 SET Meaning: This parameter specifies the threshold of the traffic mThd 0 UUESTATETRANS volume of 4A event for triggering the transition of real-time (Optional) services from FACH to HSPA with CPC technology. GUI Value Range: D16, D32, D64, D128, D256, D512, D1024, D2k, D3k, D4k, D6k, D8k, D12k, D16k, D24k, D32k, D48k, D64k, D96k, D128k, D192k, D256k, D384k, D512k, D768k Actual Value Range: 16, 32, 64, 128, 256, 512, 1024, 2k, 3k, 4k, 6k, 8k, 12k, 16k, 24k, 32k, 48k, 64k, 96k, 128k, 192k, 256k, 384k, 512k, 768k Unit: byte Default Value: D1024 RtF2CpcTv BSC690 SET Meaning: This parameter specifies the occurrence time of 4A mTimeToTr 0 UUESTATETRANS event for triggering the transition of real-time services from ig (Optional) FACH to HSPA with CPC technology. This parameter prevents unnecessary reports that are caused by traffic volume instability from being triggered. GUI Value Range: D0, D10, D20, D40, D60, D80, D100, D120, D160, D200, D240, D320, D640, D1280, D2560, D5000 Actual Value Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 Unit: ms Default Value: D0 STTDInd BSC690 ADD 0 UAICH(Optional) Meaning: This parameter indicates whether the SCCPCH uses STTD or not. For detailed information of this parameter, refer to 3GPP 25.346. GUI Value Range: TRUE, FALSE Actual Value Range: TRUE, FALSE Unit: None Default Value: False
6-10
Issue 02 (2010-06-20)
6 Parameters
Parameter NE ID STTDInd
MML
Description Meaning: This parameter indicates whether the SCCPCH uses STTD or not. For detailed information of this parameter, refer to 3GPP 25.346. GUI Value Range: TRUE, FALSE Actual Value Range: TRUE, FALSE Unit: None Default Value: False
BSC690 ADD 0 UCELLMBMSSCC PCH(Optional) MOD UCELLMBMSSCC PCH(Optional)
STTDInd
BSC690 SET Meaning: This parameter indicates whether the SCCPCH 0 UMBMSSCCPCH( uses STTD or not. For detailed information of this parameter, Optional) refer to 3GPP 25.346. GUI Value Range: TRUE, FALSE Actual Value Range: TRUE, FALSE Unit: None Default Value: False
STTDInd
BSC690 ADD 0 UPICH(Optional)
Meaning: This parameter indicates whether the SCCPCH uses STTD or not. For detailed information of this parameter, refer to 3GPP 25.346. GUI Value Range: TRUE, FALSE Actual Value Range: TRUE, FALSE Unit: None Default Value: False
STTDInd
BSC690 ADD Meaning: This parameter indicates whether the SCCPCH 0 USCCPCHBASIC( uses STTD or not. For detailed information of this parameter, Optional) refer to 3GPP 25.346. GUI Value Range: TRUE, FALSE Actual Value Range: TRUE, FALSE Unit: None Default Value: False
HsScchPwr NodeB CMInEfach
Meaning: CELL FACH HS-SCCH power control method SET MACHSPARA(Opti GUI Value Range: CQI(Adaptive Power Contrl Based on CQI), onal) FIXED(Fixed Power) Actual Value Range: CQI, FIXED Unit: None Default Value: Meaning: Maximum E_FACH retransmission times SET MACHSPARA(Opti GUI Value Range: 0~10 onal) Actual Value Range: 0~10 Unit: Times Default Value: -
MaxEfachH NodeB arqRt
Issue 02 (2010-06-20)
6-11
7 Counters
7 Counters
For details, see the BSC6900 UMTS Performance Counter Reference and NodeB Performance Counter Reference.
Issue 02 (2010-06-20)
7-1
8 Glossary
8 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
Issue 02 (2010-06-20)
8-1
9 Appendix
9 Appendix
9.1 HS-DSCH Category
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5 that can provide high speed service for the downlink. To provide multiple bit rate services, 18 UE categories are defined in 3GPP. Different UE categories can support different maximum codes for the HS-DSCH, which means that different maximum bit rates can be achieved. HS-DSCH Category Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10 Category 11 Category 12 Category 13 Category 14 Category 15 Category 16 Category 17 Maximum Number of Minimum Inter-TTI Maximum Number Maximum Bit Rate Interval of Bits HS-DSCH Codes (Mbit/s) Received 5 5 5 5 5 5 10 10 15 15 5 5 15 15 15 15 15 3 3 2 2 1 1 1 1 1 1 2 1 1 1 1 1 1 7298 7298 7298 7298 7298 7298 14411 14411 20251 27952 3630 3630 35280 42192 23370 27952 35280 23370 Category 18 15 1 42192 27952 Category 19 Category 20 Category 21 Category 22 15 15 15 15 1 1 1 1 35280 42192 23370 27952 3.649 3.649 3.649 3.649 3.649 3.649 7.2055 7.2055 10.1255 13.976 1.815 1.815 17.64 21.096
23.37 27.952
17.64 23.37 21.096 27.952 35.280 42.192 23.370 27.952
Issue 02 (2010-06-20)
9-1
9 Appendix
HS-DSCH Category Category 23 Category 24
Maximum Number of Minimum Inter-TTI Maximum Number Maximum Bit Rate Interval of Bits HS-DSCH Codes (Mbit/s) Received 15 15 1 1 35280 42192 35.280 42.192
Note: In the Maximum Number of Bits column, the bits refer to bits received by the HS-DSCH transport block during a TTI on the HS-DSCH.
In the table above:

UEs of category 13 and category 14 are required only to support 64QAM UEs of category 15 and category 16 are required only to support MIMO UEs of category 17 and category 18 support 64QAM and MIMO, but not simultaneously UEs of category 19 and category 20 support 64QAM+MIMO UEs of category 21 and category 22 support 16QAM+DC-HSPA UEs of category 23 and category 24 support 64QAM+DC-HSPA
In RAN11.0, UEs of Category 13, Category 14, Category 15, Category 16, Category 17 and Category 18 are introduced. In RAN12.0, UEs category from 19 to 24 are supported.
9.2 E-DCH Category

To provide services of multiple bit rates, seven HSUPA UE categories are defined in 3GPP specifications. The maximum number of codes over the E-DCH supported varies with the UE category. That is, different UE categories support different maximum bit rates. For example, in the following table, UE of category 3 supports two SF4 codes and the maximum data rate can be 1.44 Mbit/s. E-DCH Category Max Capability Combination E-DCH TTI Max. Data Rate (Mbit/s) MAC Layer 10 ms TTI Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 1 x SF4 2 x SF4 2 x SF4 2 x SF2 2 x SF2 10 ms only 10 ms and 2 ms 10 ms only 10 ms and 2 ms 10 ms only 0.71 1.44 1.44 2.0 2.0 2.0 2.0 MAC Layer 2 ms TTI 1.40 2.89 5.74 11.50 0.96 1.92 1.92 3.84 3.84 5.76 11.52 Air Interface
2 x SF4 + 2 xS F2 10 ms and 2 ms 2 x SF4 + 2 xS F2 10 ms and 2 ms
9-2
Issue 02 (2010-06-20)
9 Appendix
RAN10.0 supports SF2 and 2 ms TTI. RAN6.0 supports only SF4 and TTI of only 10 ms. Therefore, UEs of categories 2, 4, 5, and 6 can support TTI of only 10 ms in RAN6.0. RAN10.0 supports SF2 and 2 ms TTI. RAN12.0 supports UEs of categories 1-7 (2 ms TTI).
9.3 Improved CE Mapping for E-DCH

This feature (WRFD-010212 Improved CE Mapping for E-DCH) is available from RAN 11.0. This feature improves the uplink processing capability of the WBBPb board and enables HSUPA services to occupy less CE resources, thus improving the CE efficiency of the Node B and saving the investment cost of the operator. With the improved uplink processing capability of the WBBPb, HSUPA services occupy less CE resources. The following table lists the information regarding the occupation of CE resources. Only the 3900 series Node B supports this feature. The 3900 series Node B must configure WBBPb/WBBPd. Spreading Factor SF64 SF32 SF16 SF8 SF4 2SF4 2SF2 2SF2+2SF4 Former CE Mapping 1 1.5 3 5 10 20 32 48 Improved CE Mapping 1 1 2 4 8 16 32 48
9.4 HSPA and HSPA+ Specifications

HSPA and HSPA+ provides the maximum rate per user and maximum HSDPA users per cell specified in the following table. These specifications are controlled by licenses. Technology HSDPA Maximum rate per user HSDPA 1.8Mbps per User HSDPA 3.6Mbps per User HSDPA 7.2Mbps per User HSDPA 13.976Mbps per User HSPA+ downlink HSPA+ Downlink 21Mbps per User HSPA+ Downlink 28Mbps per User HSPA+ Downlink 42Mbps per User 96 HSDPA Users per Cell 128 HSDPA Users per Cell Maximum users per cell 6 HSDPA Users per Cell 32 HSDPA Users per Cell 64 HSDPA Users per Cell
Issue 02 (2010-06-20)
9-3
9 Appendix
Technology HSUPA
Maximum rate per user HSUPA 1.44Mbps per User HSUPA 5.74Mbps per User
Maximum users per cell 20 HSUPA Users per Cell 60 HSUPA Users per Cell 96 HSUPA Users per Cell 128 HSUPA Users per Cell
HSPA+ uplink
You can specify the maximum number of HSDPA users in the cell or in the NodeB through the MaxHsdpaUserNum and NodeBHsdpaMaxUserNum parameters. You can specify the the maximum number of HSUPA users in the cell or in the NodeB through the MaxHsupaUserNum and NodeBHsupaMaxUserNum parameters.
9-4
Issue 02 (2010-06-20)
10 Reference Documents
10 Reference Documents
[1] 3GPP 25.214: Multiplexing and channel coding (FDD) [2] 3GPP 25.321: Medium Access Control (MAC) protocol specification [3] 3GPP 25.212: Physical layer procedures (FDD) [4] HSDPA Feature Parameter Description [5] HSUPA Feature Parameter Description [6] Radio Bearers Feature Parameter Description [7] Transmission Resource Management Feature Parameter Description [8] Power Control Feature Parameter Description [9] Handover Feature Parameter Description [10] State Transition Feature Parameter Description [11] DC-HSDPA Feature Parameter Description
Issue 02 (2010-06-20)
10-1

HSPA Evolution

Transféré par

Informations du document

Description originale:

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

HSPA Evolution

Transféré par

Droits d'auteur :

Formats disponibles

HSPA Evolution RAN12.

Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

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

Trademarks and Permissions

Huawei Technologies Co., Ltd.

WCDMA RAN HSPA Evolution

2 Overview of HSPA and HSPA+ ..............................................................................................2-1 3 HSPA Introduced in RAN10.0 .................................................................................................3-1

4 HSPA+ Introduced in RAN 11.0 .............................................................................................4-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

5 HSPA+ Introduced in RAN12.0 ..............................................................................................5-1

6 Parameters .................................................................................................................................6-1 7 Counters ......................................................................................................................................7-1

WCDMA RAN HSPA Evolution

8 Glossary ......................................................................................................................................8-1 9 Appendix .....................................................................................................................................9-1

10 Reference Documents .........................................................................................................10-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

1.2 Intended Audience

1.3 Change History

02 (2010-06-20) 01 (2010-03-30) Draft (2009-12-05)

WCDMA RAN HSPA Evolution

MIMOor64QAMSwitch MIMO64QAMorDCHSDPASwitch RlcPduMaxSizeForUlL2Enhance RlcPduMinSizeForUlL2Enhance

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

2 Overview of HSPA and HSPA+

2 Overview of HSPA and HSPA+

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

2 Overview of HSPA and HSPA+

WCDMA RAN HSPA Evolution

Uplink enhanced L2 Downlink MIMO+64QAM DC-HSDPA

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

3 HSPA Introduced in RAN10.0

3 HSPA Introduced in RAN10.0

3.1.2 Basic Principle

F-DPCH Frame Format

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

3 HSPA Introduced in RAN10.0

WCDMA RAN HSPA Evolution

Figure 3-1 Frame format of the F-DPCH

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

3 HSPA Introduced in RAN10.0

Figure 3-2 F-DPCH multiplexing

3.2 SRB over HSDPA

The requirements of SRB over HSDPA are listed in Table 3-3.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

3 HSPA Introduced in RAN10.0

WCDMA RAN HSPA Evolution

3.2.2 Basic Principle

3.2.3 Radio Bearers

3.3 SRB over HSUPA

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

WCDMA RAN HSPA Evolution

3 HSPA Introduced in RAN10.0

3.3.2 Basic Principle

3.3.3 Radio Bearers

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

3 HSPA Introduced in RAN10.0

WCDMA RAN HSPA Evolution

3.4 IMS Signaling over HSPA

3.4.2 Basic Principle